Program size, linking matter, and static this()

[Jonathan M Davis]

On Friday, December 16, 2011 21:06:49 Timon Gehr wrote:
> 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.

True, but we don't have them.

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

Yes they are. static constructors completely chicken out on them. Not only is 
there no real attempt to determine whether the static constructors are 
actually dependent (which granted, isn't an easy problem), but there is _zero_ 
support in the language for resolving such circular dependencies. There's no 
way to say that they _aren't_ dependent even if you can clearly see that they 
aren't. The solution used in Phobos (which won't work in std.datetime due to 
the use of immutable and pure) is to create a C module which has the code from 
the static constructor and then have a separate module which calls it in its 
static constructor. It works, but it's not pretty (and it doesn't always work 
- e.g. std.datetime), and it would be _far_ better if you could just mark a 
static constructor as not depending on anything or mark it as not depending on 
a specific module or something similar. And given how disgusting it generally 
is to even figure out what's causing a circular dependency when the runtime 
won't start your program because of it, I really think that this is a problem 
which should resolved. static constructors need to be improved.

> > 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.

Yes. The situation with D is better than that of many other languages, but 
what prodblems we do have can be _really_ annoying to deal with. Have to deal 
with circular dependencies due to static module constructors which aren't 
actually interdependent is one of the most annoying issues in D IMHO.

- Jonathan M Davis