Program size, linking matter, and static this()

[Steven Schveighoffer]

On Fri, 16 Dec 2011 17:00:45 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 12/16/11 3:28 PM, Steven Schveighoffer wrote:
>> On Fri, 16 Dec 2011 14:48:33 -0500, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> On 12/16/11 1:23 PM, Steven Schveighoffer wrote:
>>>> I disagree with this assessment. It's good to know the cause of the
>>>> problem, but let's look at the root issue -- reflection. The only  
>>>> reason
>>>> to include class information for classes not being referenced is to be
>>>> able to construct/use classes at runtime instead of at compile time.  
>>>> But
>>>> if you look at D's runtime reflection capabilities, they are quite  
>>>> poor.
>>>> You can only construct a class at runtime if it has a zero-arg
>>>> constructor.
>>>>
>>>> So essentially, we are paying the penalty of having runtime reflection
>>>> in terms of bloat, but get very very little benefit.
>>>
>>> I'd almost agree, but the code showed doesn't use Object.factory(). So
>>> that shouldn't be linked in, and shouldn't pull vtables.
>>
>> You cannot know until link time whether factory is used when compiling
>> individual files. By then it's probably too late to exclude them.
>
> I'm not an expert in linkers, but my understanding is that linkers  
> naturally remove unused object files. That, coupled with dmd's ability  
> to break compilation output in many pseudo-object files, would take care  
> of the matter. Truth be told, once you link in Object.factory(), bam -  
> all classes are linked.

Factory doesn't directly reference classes, it does so through the  
moduleinfo tree/array (not sure what it is).  So the way it works is, the  
linker includes the module info because it's defined as static data, which  
includes the vtable functions, and factory can instantiate non-referenced  
classes because of this fact, not the other way around.

>> I'm not pushing for runtime reflection, all I'm saying is, I don't think
>> it's worth changing how the library is written to work around something
>> because the *compiler* is incorrectly implemented/designed.
>>
>> So why don't we just leave the code size situation as-is? 500kb is not a
>> terribly significant amount, but dlls are on the horizon (Walter has
>> publicly said so). Then size becomes a moot point.
>>
>> If we get reflection, then you will find that having excluded all the
>> runtime information when not used is going to hamper D's reflection
>> capability, and we'll probably have to start putting it back in anyway.
>>
>> In short, dlls will solve the problem, let's work on that instead of
>> shuffling around code.
>
> I think there are more issues with static this() than simply executable  
> size, as discussed. Also, adding dynamic linking capability does not  
> mean we give up on static linking. A lot of programs use static linking  
> by choice, and for good reasons.

Even statically linked programs might use runtime reflection.

I agree the issue is not static linking vs. dynamic linking, but dynamic  
linking would hide the problem quite well.

Note that on Linux today, the executable is not truly static -- OS libs  
are dynamically linked.

Another option is to disable runtime reflection via a compiler switch  
(which would sever the ties between moduleinfo and classinfo).  Then we  
simply must make sure we don't use factory in the library anywhere.

-Steve