Thanks, Tobi and Remi, for the helpful observations. On Jul 10, 2018, at 2:43 AM, Remi Forax <fo...@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_aj...@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 of F. 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 non-speculatively? 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. — John
