null checks vs. class resolution, and translation strategy for casts
john.r.rose at oracle.com
Thu Apr 9 21:56:45 UTC 2020
On Apr 9, 2020, at 2:31 PM, forax at univ-mlv.fr wrote:
> yes, indy is a way to create any new bytecode, but it also has some restrictions,
> the major one being that you can not using it before it has been bootstrapped.
Good point; we found that with string concatenation, didn’t we?
If we use indy for this, we’ll run into similar bootstrapping issues.
Which reminds me that Brian has been pondering javac intrinsics
for some time, as a way of replacing method calls that would
ordinarily be linked and run the normal way, with preferable
alternative implementations. This game could also be played
(very carefully) with BSMs. That (like javac intrinsics) would
sidestep the usual bootstrapping orders.
So, here’s a recommendation: Use indy, and use a clunkier
fallback in the same places that today use a clunkier fallback
for string concatenation. And, record a line item of technical
debt that we should further explore indy intrinsics, after we
figure out what javac intrinsics look like.
More information about the valhalla-spec-observers