On Jul 13, 2018, at 1:00 PM, Karen Kinnear <karen.kinn...@oracle.com> wrote:
>
> Tobi - I owe you a response to your proposal - we are prototyping the
> proposal I sent out and learning a lot
> which may help inform where we end up.
I think we all agree that pre-loading VT classfiles is necessary to drive at
least some of the
critical optimizations that justify VTs. The main optimization that require
pre-loading is
certainly flattened fields. Another one is (almost certainly) scalarized
parameters and
returns (for out-of-line calls).
("Pre-loading" simply means loading the VT classfile before the other JVMS
rules would
force loading. Those rules pertain to instantiation, static member resolution,
etc.)
The ValueTypes attribute is the (current) starting point for deciding which
classes
are *candidates* for pre-loading. We could load *all* of them as early as
possible,
but that is thought to require too much class loading activity at start-up
time. I'm
not fully convinced this would be so bad, but let's try to do better. Doing
better
means (a) loading fewer of the VT types, and/or (b) loading them later. The
latest possible point is, as noted above, when at VT class is actually used
in some way that triggers loading and <clinit>. The best possible win would
be deferring *all* VT loading to that required point, but we know that's
impossible.
So LW1 will eagerly load VT classfiles in some ad hoc fashion driven by
optimization
needs. Karen is writing up the rules for this, even as they seem to change
under
her feet. (Thanks Karen!)
If the LW1 prototype loads VT classes too eagerly, we will try to dial it back,
perhaps along the lines Tobi proposes. The LW1 prototype is intended
in part to give us experience with performance models, so we may load
VT classes eagerly if we think it helps with specific optimizations. We'll
collect the performance win, and then go back and see if the loading
can be made less eager, to collect a startup win also. The startup wins
might well wait until post-LW1, depending on how much tricky experimentation
and redesign is required.
— John
P.S. The above discussion mentions field flattening and out-of-line parameter
scalarization as the key optimizations that require pre-loading. These
may, in the end, be the only such optimizations, not just the key ones.
But we should be ready for a third shoe to drop. :-)
