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

[Archie Cobbs]

Jeroen Frijters wrote:
> > As specified, static initializers run on first active use. In JC,
> > each potential first active use checks whether the target class is
> > initialized, and if not, initializes it. So there is overhead to
> > do this check, but the checking overhead doesn't depend on whether
> > the target class actually has a <clinit> method or not.
> 
> But the question on my mind is, is it fundamentally impossible for you
> to elimate the check for classes that don't have a <clinit> or is that
> just something you haven't implemented?

[ For the purpose of discussion imagine class A has an active use
  of class B, and class B may or may not have a <clinit>. ]

It hasn't been implemented. But it's not quite that simple. If this
were to be implemented, that introduces another dependency between
the classes. The result is that if someone adds <clinit> to class
B but class A does not change, then if A has this optimization, it
will have to be regenerated even though it didn't change. So the
"optimization" could actually slow things down dramatically. This
is not an issue for a JIT compiler (which always generates code at
runtime) but is for a WAT compiler where code generation at runtime
is to be avoided. This is kindof a contrived example but an example
nonetheless.

> My (somewhat nasty) point is that I think we shouldn't be making
> Classpath decisions based on missed optimization opportunities in some
> VMs. I do realize that this is a gray area too.

Whether or not you can optimize away the 'active use' check depends
on when you link things together and how dependent you want your
generated classes to be on other classes.

E.g., one might want to pregenerate an optimized object containing
all of package 'foo.bar', with lots of internal dependencies, but
without any dependencies on classes outside that package. This would
then guarantee at runtime that 'foo.bar' would never have to be
regenerated, allowing you to guarantee performance, not ship any
'foo.bar' classes, etc.

I agree with the spirit of your point, my only request is that in
general people keep the big picture in mind and try to avoid making
assumptions about things based on limited experience.

-Archie

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