Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable

Jorn Vernee jorn.vernee at oracle.com
Fri Mar 20 17:49:09 UTC 2020


W.r.t. the source type being needed, I see the following 4 major cases:

1. src=Prim & dst=Prim -> cast convert. For boolean the 
least-significant-bit is used to convert it to/from an integer type.
2. src=Prim & dst=Ref   -> box the source value and potentially cast
3. src=Ref   & dst=Prim -> apply an unboxing conversion if possible and 
then a casting conversion (with same trick for boolean as (1))
4. src=Ref   & dst=Ref   -> reference cast

Without the source type we can't disambiguate between cases (2) and (4), 
or (1) and (3) because the bootstrap takes Object as an input. For (2) 
and (4) the bootstrap invocation mechanism takes care of the boxing for 
us, and the cast is performed by (4). For (1) and (3) the conversion 
code for the latter handles conversion of wrapper types to Number and 
then to the target primitive per (1). In the end things seems to work 
out to the same result (though maybe I'm missing some subtle difference 
in a failure case).

What I'm mostly worried about is that the source type already affects 
_how_ the conversion is done, and the fact that this difference is not 
observable seems somewhat incidental.... Coupled with the fact that 
asType and explicitCastArguments also have access to both the source and 
destination type, I think maybe the new bootstrap method should as well. 
After all, what if the set of cases is extended (valhalla?) and/or not 
being able to disambiguate starts to matter?

---

I've written a more in-depth specification for the bootstrap, and 
re-implemented it using explicitCastArguments, since that helps to catch 
discrepancies between the input value and the source type. Here is the 
next iteration: http://cr.openjdk.java.net/~jvernee/8241100/webrev.01

I've kept the source type for now, if it should be removed the 
specification can be trimmed down (since there would be less cases to 
specify).

As for the name; I think "asType" might be confusing since the applied 
conversion is not quite the same as MethodHandle::asType. Since the 
bootstrap is implemented in terms of explicitCastArguments I went with 
"explicitCast", how is that?

Thanks,
Jorn



More information about the core-libs-dev mailing list