<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">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.</p>
<p dir="auto">(This connects to the recurring question, which recurred yesterday, of whether we need a third int type, of the form <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">Qjava/lang/Integer;</code>, to accompany <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">Ljava/lang/Integer;</code> and <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">I</code>, 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.)</p>
<p dir="auto">We know we can just use various JDK API points to do these jobs, possibly with extra <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">checkcast</code> 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 <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">a2b</code> 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.</p>
<p dir="auto">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 <code style="margin: 0; padding: 0 0.4em; border-radius: 3px; background-color: #F7F7F7;">checkcast</code> 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.</p>
<p dir="auto">So, here it is. I have tried to write it in a tone that is <em>very tentative</em>. Please do not try to read it as something I am enthusiastic about. But, have a look.</p>
<p dir="auto">enhanced checkcast for Valhalla type unification<br>
<a href="https://bugs.openjdk.org/browse/JDK-8297236" style="color: #3983C4;">https://bugs.openjdk.org/browse/JDK-8297236</a></p>
<p dir="auto">(I think the problem statement part is pretty good, actually.)</p>
<p dir="auto">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:</p>
<p dir="auto">low-level control of field initialization<br>
<a href="https://bugs.openjdk.org/browse/JDK-8297156" style="color: #3983C4;">https://bugs.openjdk.org/browse/JDK-8297156</a></p>
</div></div></body>
</html>