Program size, linking matter, and static this()

[Timon Gehr]

On 12/16/2011 08:41 PM, Jonathan M Davis wrote:
> On Friday, December 16, 2011 12:29:18 Andrei Alexandrescu wrote:
>> Jonathan, could I impose on you to replace all static cdtors in
>> std.datetime with lazy initialization? I looked through it and it
>> strikes me as a reasonably simple job, but I think you'd know better
>> what to do than me.
>>
>> A similar effort could be conducted to reduce or eliminate static cdtors
>> from druntime. I made the experiment of commenting them all, and that
>> reduced the size of the baseline from 218KB to 200KB. This is a good
>> amount, but not as dramatic as what we can get by working on std.datetime.
>
> Hmm. I had reply for this already, but it seems to have disappeared, so I'll
> try again.
>
> You could make core.time use property functions instead of the static
> immutable variables that it's using now for ticksPerSec and appOrigin, but in
> order to do that right would require introducing a mutex or synchronized block
> (which is really just a mutex under the hood anyway), and I'm loathe to do
> that in time-related code. ticksPerSec gets used all over the place in
> TickDuration, and that could have a negative impact on performance for
> something that needs to be really fast (since it's used in stuff like StopWatch
> and benchmarking). On top of that, in order to maintain the current semantics,
> the property functions would have to be pure, which they can't be without
> doing some nasty casting to convince the compiler that stuff which isn't pure
> is actually pure.

lazy variables would resolve this.

>
> For std.datetime, the problem would be reduced if a class could be created in
> CTFE and still be around at runtime, but we can't do that yet, and it wouldn't
> completely solve the problem, since the shared static constructor related to
> LocalTime has to call tzset. So, some sort of runtime initialization must be
> done. And the instances for the singleton are not only immutable, but the
> functions for getting them are pure. So, once again, some nasty casting would
> be required to get it to work without breaking purity. And once again, we'd
> have introduce a mutex. And for both core.time and std.datetime we're talking
> about a mutex would be needed only briefly to ensure that we don't end up with
> two threads trying to initialize the variable at the same time. After that, it
> would just be impeding performance for no value. They're classic situations
> for static constructors - initializing static immutable variables - and
> really, they _should_ be using static constructors. If we have to get rid of
> them, it's to get around other problems in the language or compiler instead of
> fixing those problems. So, on some level, that seems like a failure on the part
> of the language

no.

> and the compiler.

yes. Although I am not severely affected by 500kb of bloat.

> If we _have_ to find a workaround, then we
> have to find a workaround, but I find the need to be distasteful to say the
> least. I previously tried to get rid of the static constructors in
> std.datetime and couldn't precisely because they're needed unless you play
> major casting games to get around immutable and pure.
>
> If we play nice, it's impossible to get rid of the static constructors in
> std.datetime. It probably is possible if we do nasty casting, but (much as I
> hate to use the word) it seems like this is a hack to get around the fact that
> the compiler isn't dealing with static constructors as well as we'd like. I'd
> _really_ like to see this fixed at the compiler level.
>
> And honestly, I think that a far worse problem with static constructors is
> circular dependencies. _That_ is something that needs to be addressed with
> regards to static constructors.

Circular dependencies are not to be blamed on the design of static 
constructors.

> In general at this point, it's looking like
> static constructors are turning out to be a bit of a failure on some level,
> given the issues that we're having because of them, and I think that we should
> fix the language and/or compiler so that they _aren't_ a failure.
>
> - Jonathan M Davis


We are having (minor!!) problems because the task of initializing global 
data in a modular way is inherently hard.

Just have a look how other languages handle initialization of global 
data and you'll notice that the D solution is actually very sensible.