I think (based on our most recent conversations)
that `aconst_init` can return a Q-type for B3 types
and an L-type for B2 types. And likewise for the input
and output of `withfield`.
The net result is that both bytecodes need to be
permissive about L and Q types, because B2 and B3
translation strategies require distinct parallel use
cases.
This is probably not clear in the docs, but I think
it makes sense.
Can you mix and match both modes in the same method?
Probably, since the interpreter doesn’t care about
multi-bytecode patterns. Dunno if this causes a testing
problem, and if so how to fix it. I think it’s probably
OK, especially if we require the two-way checkcast
(Q-Foo not a subtype of L-Foo in the verifier) so that
each mode stays “in its own lane”.
More explicitly, this is a set of use cases for using
Q-types in C_Class entries in the constant pool to switch
to Q-mode for bytecodes that refer to classes, including
`withfield` and `aconst_init`.
On 12 Jan 2022, at 4:31, Remi Forax wrote:
I've some troubles to wrap my head around those two sentences
"""
aconst_init is the analogue of new for value objects; it leaves a
reference to the initial value for a value class on the stack. This
initial value is guaranteed to not be equal to null. The sole operand
of this bytecode is a reference to a CONSTANT_Class item giving the
internal binary name of the value class (not its Q descriptor).
"""
and
"""
Both withfield and aconst_init return a Q type if and only if their
class is a primitive class.
"""
The second is ambiguous because it's not clear if aconst_init can
return a L-type. I suppose it can not but this is not clear at all.
If this is the case, what is the use case for withfield taking a
L-type as parameter ??
regards,
Rémi
