straw man for conversion bytecode (from EG meeting)

[John Rose]

Yesterday we bumped (for the Nth time) into the subject of bytecode 
shape for the new conversions (mostly implicit conversions) between 
primitives (both legacy and user-defined) and their (nullable) box 
types.

(This connects to the recurring question, which recurred yesterday, of 
whether we need a third int type, of the form `Qjava/lang/Integer;`, to 
accompany `Ljava/lang/Integer;` and `I`, in various kinds of bytecode 
translating tricky Java code.  To which I always say, “No”, and 
“but show me a real job for the Q-descriptor of int”, and then 
follow some suggestions which I debunk as unnecessary.  Where we end is 
at this point, where we know we need conversion code at least between 
the remaining two VM types.)

We know we can just use various JDK API points to do these jobs, 
possibly with extra `checkcast` instructions to clean up the verifier 
types.  We asked, early in the Valhalla design process, “do we want or 
need a general conversion bytecode?” and dubbed it `a2b` at some 
points.  IMO, if such a bytecode were truly necessary in full 
generality, it would indicate that our verifier type system was 
unmanageably complex, so I’m glad to see we are not reaching for it.

But I do want to write, for the record, a proposal (probably not to be 
adopted) for how we might fill a small and modest niche in the 
translation strategy, the one occupied by those library calls and 
`checkcast` uses, with a bytecode enhancement.  So we can know more 
clearly what we are rejecting, or (if we were to adopt it) so we can 
know the cost sooner rather than later.

So, here it is.  I have tried to write it in a tone that is *very 
tentative*.  Please do not try to read it as something I am enthusiastic 
about.  But, have a look.

enhanced checkcast for Valhalla type unification
https://bugs.openjdk.org/browse/JDK-8297236

(I think the problem statement part is pretty good, actually.)

P.S. We also discussed how to attach null-rejection to variables that 
are not naturally null-rejecting.  The above proposal gives a nicer way 
to do it than we have today.  And a variation on the “lazy static” 
theme gives yet another way, which is attaching initialization-detection 
logic to fields and array elements.  That is very expensive, so again 
I’m not proposing it for today, but rather just putting it on the 
table.  Here is that note:

low-level control of field initialization
https://bugs.openjdk.org/browse/JDK-8297156
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/valhalla-spec-experts/attachments/20221117/c804346e/attachment.htm>