From: "Brian Goetz" <brian.go...@oracle.com>
To: "Remi Forax" <fo...@univ-mlv.fr>
Cc: "Jim Laskey" <james.las...@oracle.com>, "amber-spec-experts"
<amber-spec-experts@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
