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

Reply via email to