Re: [cp-patches] Patch: support for reading directories viaURL.openConnection()

[Archie Cobbs]

Jeroen Frijters wrote:
> > > Static initializers are quite expensive, so we should try to limit
> > > them as much as reasonable.
> > 
> > I'm curious about what you mean exactly by this statement..
> 
> When a class (or its base class) has a static initializer, all static
> members accesses and instantiations (done from outside the class itself)
> from methods that are JIT compiled before the static initializer is run,
> have to be wrapped in a check to see if the static initializer needs to
> run and this check needs to be done in a thread safe fashion. Details
> obviously very for each VM, but in general a static initializer adds a
> cost and very often it is not a one time cost.

OK, I'm just pointing out that this is VM specific. For example,
because JC has a WAT compiler instead of a JIT compiler, and doesn't
try to do any fancy optimizations of "first active use", the presence
of a static initializer doesn't add any additional overhead at all.

My meta-point is that there is a grey area between a change being
obviously "good" for all VM's and being just a VM-specific optimization
or convenience change.

I see this come up all the time with Classpath, and am just pointing
out that there is always this tension between making Classpath
"fast" versus keeping it "clean", especially when each implementing VM
has a different function for "fast".

If most VMs benefit then a change is probably worth it (this thread
is a positive example), but in general we should try to be clear
when dealing with issues in this grey area.

-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com