www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2642] New: .init contains zeroes

reply d-bugmail puremagic.com writes:
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.


--
Feb 02 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2642






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.


--
Feb 02 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2642


maxmo pochta.ru changed:

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





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 :)


--
Feb 03 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2642







 1. Move zero memory to bss section and zero it at startup.


This will be efficient in terms of both time and storage requirements.


--
Feb 03 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2642






Intializing to zero won't work for floats and char (which init to 0xFF...).
But it'd be a nice optimisation for other cases.


--
Feb 03 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2642






The .init block is never all zero, as the first member is the vtpr initializer.


--
Feb 20 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2642






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.


--
Feb 21 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2642








 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!


--
Feb 21 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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





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.


--
Feb 22 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2642






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: -------
Jul 09 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2642






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.


Though setting of main vptr can be done in user code and other fields
initialization can be moved to constructor (including interface fixups). Though
this hardly makes difference in the case of inlining.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 09 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2642






PDT ---
oops... *fix
there's no interface fixups in the object, only vptrs.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 09 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2642


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|spec                        |



00:13:57 PST ---
Not a spec issue.

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