EG help please with getting to LW1 re: Value Types Consistency Checking
john.r.rose at oracle.com
Thu Jul 12 19:02:02 UTC 2018
Thanks, Tobi and Remi, for the helpful observations.
On Jul 10, 2018, at 2:43 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> I think the answer to the question of lazy loading of method parameter types is rooted to the question of what is a value type exactly for Java.
> Is it an optimization, a first class concept i.e one that should work as if it was integrated in the language from the beginning ?
> The other problem is the more we diverge from the class behavior, the harder it will be to allow a class to become a value type.
> I firmly believe that value type should be first class because they are useless in a lot of scenario if they are not. The main limitation of a value type is its immutable characteristic, what save them from uselessness is that their creation cost should be zero or very close to zero alleviating the burden of think in term of object creation and making us, developers, free to use functional idioms.
> With that in mind, i believe a value type should not be "boxed" because it's not loaded yet (it can still be boxed due to separate compilation but that's another story) so value type present in method descriptor should be loaded eagerly.
So value types should diverge from object types enough to allow accurate unboxing in hot paths.
But they should not diverge more than necessary. That means no eager loading that's not needed.
> About loading all value type of the attribute ValueTypes, from one side Java has a strong tradition to not pay for the code you do not use. This power today's applications, an average application has an hundred jars as dependencies, if all value types are preloaded it's at waste of memory and cpu cycles. BTW, it's also what's make jaotc useless in its current incarnation because it AOTs things your application don't care.
This is a very specific set of reasons why eager loading is a bad idea: Against Java tradition,
harmful to startup, and liable to tickle bugs that otherwise would sleep quietly.
On Jul 12, 2018, at 11:41 AM, Tobi Ajila <Tobi_Ajila at ca.ibm.com> wrote:
> > I'm looking for reasons that
> > this is a *bad* idea, so we can say in the end, "here's exactly why we had to make
> > the loading logic for VTs so tricky"–if we must.
> Karen's initial post mentions our two biggest concerns. If there is no guarantee that the VTs in the method descriptors will be used, loading them is an overhead. We would like to minimize the cost to startup as much as possible. The other reason is eager loading may trigger failures that would otherwise never occur if the method wasn't run, which is change from how the JVM normally behaves.
OK, those points align with the discussion above.
IMO there's still a possibility that we will want to eagerly load signature types
declared as value types, at preparation time. This could happen if two bad
things happen first: (a) We can't figure out how to assign calling sequences
properly to virtual methods (including those connected by v-table/override
relations) without preparation time loadings, and (b) we regretfully realize
that we would rather get the calling sequences right than follow the Java
traditions noted above.
(For the moment, let's define the term "method family" to mean any group
of methods which is connected by override/v-table relations in such a way
that the methods are all constrained to have a common calling sequence.
I can't think offhand of a standard term for this, but we need a term.)
To solve (a) we need a story, for any given method family F, how the
common calling sequence (including unboxed values) is assigned during
startup, even if dynamically loaded class hierarchies are being loaded
in a data-dependent fashion, concurrently with executions of members
I don't think appealing to speculation and deoptimization is a good answer
for (a), because it slows startup unpredictably. If that's the answer, I'd
rather just take the predictable startup hit of loading signature value types.
That is, given an inaccurate solution for (a), I think we'd decide in the end,
regarding point (b), to regretfully break tradition.
So, is there a reasonably simple way to get good enough calling sequences
The answer might be yes, along the lines you mentioned Tobi, but I don't
see it yet. I think maybe the whole family F needs a linkage barrier,
which involves delayed loading of signature value types used in F.
Although preparation of F's various classes would have assigned
v-table slots (or whatever preconstructed dictionary V8 might use
instead of v-tables), the calling sequences of those v-table slots would
remain mysterious until the first execution of a method in F.
Can we do that? It sort of feels like a mini-preparation pass just for F.
More information about the valhalla-spec-observers