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

[forax at univ-mlv.fr]

From: "Brian Goetz" <brian.goetz at oracle.com> 
To: "Remi Forax" <forax at univ-mlv.fr> 
Cc: "Jim Laskey" <james.laskey at oracle.com>, "amber-spec-experts" <amber-spec-experts at openjdk.java.net> 
Sent: Monday, March 7, 2022 4:08:00 PM 
Subject: Re: [External] : Re: Proposal: java.lang.runtime.Carrier 




BQ_BEGIN


BQ_BEGIN

Adding more information, 
we want the carrier to be a primitive type (to be able to optimize it away), which means that we can not use null to represent "do_not_match", 
we have to have a flag inside the carrier for that. 

BQ_END

The alternate approach is to use a .ref class for partial patterns (using null for "no match") and a B3 class for total patterns (since it needs no failure channel.) 
BQ_END


yes, 
we still need an int to indicate which case of the switch match and using B3 in Valhalla already give us the performance we want. 
Anyway changing from one representation to the other is not a big deal. 


BQ_BEGIN


I think its pretty important that the static name of the carrier class not appear in generated bytecode. 
BQ_END


Yes, that why i'm using java.lang.Object in the bytecode visible code. 


BQ_BEGIN
As a result, we will have to use a reference type (object or interface), which means we get the null channel "for free". 
BQ_END

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. 

Rémi 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220308/0c7c7953/attachment.htm>