VM model and aconst_init

[John Rose]

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