[External] : Re: Proposal: java.lang.runtime.Carrier

[forax at univ-mlv.fr]

> From: "John Rose" <john.r.rose at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "Jim Laskey"
> <james.laskey at oracle.com>, "amber-spec-experts"
> <amber-spec-experts at openjdk.java.net>
> Sent: Tuesday, March 8, 2022 9:52:00 PM
> Subject: Re: [External] : Re: Proposal: java.lang.runtime.Carrier

> On 7 Mar 2022, at 16:07, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:

>> Not necessarily, while java.lang.Object appears in the bytecode a JIT like c2
>> propagates the real type of the constants (here empty() is typed with the type
>> of the carrier not with java.lang.Object at runtime) so introducing null may
>> introduce some stupid nullchecks.
> Null checks are usually cheap, because they are usually done implicitly in
> parallel with the first access that requires a non-null value. This works for
> true references, but not scalarized values.

> We want scalarized values, of course. So what I might worry more about here is
> forcing the JVM to buffer the value object on the heap because of possibility
> of null. (B3 primitives/bare values are designed to make that less likely.) I
> think even here null is OK, because all B2 types are both nullable and
> scalarizable (if not null), so it is very likely the JVM is going to do extra
> work to adjoin (the technical term is “cram in”) a null representation into the
> scalarized representation, using an extra register if necessary.

> Bottom line: Nullability doesn’t concern me here, since I assume we are going to
> continue to work hard (because of B2 value types like ju.Optional) to support
> both nullability and scalarization.

What i was proposing is for switch to cram "not match" and the index of the matching case into one int because using -1 seems natural and it will work well with the tableswitch. 

Anyway, as i said earlier, i don't think it's a bid deal to use "null" to mean "do not match" because "do not match" need to be tested at two different stages, inside the matching pipeline here using null is easier and in the end to nourish the tableswitch/instanceof, in that case null need to be transformed to -1 / false. 

The other thing is that for the deconstructor call, here i believe we have to go to the B2 representation anyway (a nullable record) because it is part of the public API, not necessary in the language but from the binary compatibility POV, so at least users will be able to see it with a debugger. So it may make sense to always use 'null' to mean "do not match", in the matching pipeline and as result of a deconstructor call. 

To come back to the carrier API, does it means that the carrier class is always a nullable value type or does it mean that we need to knob to select between a primitive type or a value type ? 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220309/00f3764d/attachment.htm>