http://d.puremagic.com/issues/show_bug.cgi?id=2642

           Summary: .init contains zeroes
           Product: D
           Version: 2.023
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: spec
          Severity: normal
          Priority: P3
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: maxmo@pochta.ru


Typical class has its fields all set to zeroes so .init member of this class usually contains plain zeroes, which can result in intensive spam from compiler. Consider this code:
---
class A
{
    int[10] a;
}

void main()
{
    auto a=new A();
}
---
which in compiled form takes 96kb and after raising array size to 10000, compiled execatable takes 135kb. So as number of class declarations grows, object code gets polluted with zeroes.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2642





------- Comment #1 from 2korden@gmail.com  2009-02-02 15:36 -------
It works as designed. Design, however, can be given another thought.

I agree it is a bad idea of storing T.init as raw data within executable.
Instead, T.init could be made a property (function) that returns
default-initialized value. T init(ref T value); could be used to initialize
value in-place. Both would use dynamic initializer (memset etc) when
appropriate.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2642


maxmo@pochta.ru changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement




------- Comment #2 from maxmo@pochta.ru  2009-02-03 02:05 -------
Other possible optimizations:
1. Move zero memory to bss section and zero it at startup. Not only .inits
contain zeroes, all static data does.
2. If zero data is invariant, different instances of this data can refer to the
same memory location, though, if programmer casts one of these pointers to
mutable data and overwrite it, this will cause disaster :)


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2642





------- Comment #3 from maxmo@pochta.ru  2009-02-03 02:07 -------
> 1. Move zero memory to bss section and zero it at startup.
This will be efficient in terms of both time and storage requirements.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2642





------- Comment #4 from clugdbug@yahoo.com.au  2009-02-03 03:12 -------
Intializing to zero won't work for floats and char (which init to 0xFF...). But it'd be a nice optimisation for other cases.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2642





------- Comment #5 from bugzilla@digitalmars.com  2009-02-20 21:50 -------
The .init block is never all zero, as the first member is the vtpr initializer.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2642





------- Comment #6 from 2korden@gmail.com  2009-02-21 03:30 -------
One of the solutions is to introduce non-nullable types (both reference and value-types). In this case T.init would be useless (and thus may be safely removed from language*), because user will *have to* initialize it:

double d; // compare to "double? d;" which is ok to be non-initialized double dd = 100.0;

Same for structs:

Foo f; // not initialized (CT-error or write-only until initialized)
Foo ff = Foo(); // ok, default-initialized

Note that this is very close to classes (same rule - same syntax):

Bar b; // not initialized (CT-error or write-only until initialized)
Bar bb = new Bar(); // ok, default-initialized

As a general rule for all types,

T t; // is not an initialized value, a compile-time error is raised, // or just not allowed to be read until initialized (relaxed rule) T t = initializer_expression; // ok, an initialized value

--
* I don't mind if T.init will be removed from language specs altogether as I never found it useful. It may still be left for some time in compiler internals (to copy T[] prior to calling T.__ctor), just don't expose it to users.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2642





------- Comment #7 from jarrett.billingsley@gmail.com  2009-02-21 10:56 -------
(In reply to comment #6)
> One of the solutions is to introduce non-nullable types (both reference and value-types). In this case T.init would be useless (and thus may be safely removed from language*), because user will *have to* initialize it:

So, as much as I like nonnull types, and as much as I like your proposal, there's this .. kind of icky part too.

auto a = new ClassType[10];

How exactly do you allocate an array of nonnull types?

> * I don't mind if T.init will be removed from language specs altogether as I never found it useful. It may still be left for some time in compiler internals (to copy T[] prior to calling T.__ctor), just don't expose it to users.

I've found it useful!


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2642


dhasenan@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|.init contains zeroes       |ClassInfo.init contains
                   |                            |zeroes




------- Comment #8 from dhasenan@gmail.com  2009-02-22 08:09 -------
It wasn't clear to me that this is talking about ClassInfo.init rather than Type.init.

Non-nullable types do nothing for this problem. Class initialization consists
of three stages:
1. allocate appropriate size
2. memcpy ClassInfo.init to allocated space
3. run constructor

With or without explicit initialization requirements, you could put that initialization in the constructors. That is going to be slower than copying bytes in some circumstances. Of course, if there's only a few fields to set, since the allocator already zeroes out allocated memory, that's less work.

In any case, it will be convenient to have ClassInfo.init, for doing various There Be Dragons things.


-- 

http://d.puremagic.com/issues/show_bug.cgi?id=2642





--- Comment #9 from Sobirari Muhomori <maxmo@pochta.ru>  2009-07-09 02:47:55 PDT ---
> With or without explicit initialization requirements, you could put that initialization in the constructors.
.init can't be moved to constructor, because you won't be able to set vptr correctly.

Possible solution is to generate .init as a static function and inline it (or not) in the user code after call to new. Then call constructor. And trusting malloc to zero memory can be a good optimization.

And I don't think .init for primitive types is copied as an array of bytes.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------