JVM implementation of null-restricted value class types for cast and array

[forax at univ-mlv.fr]

----- Original Message -----
> From: "daniel smith" <daniel.smith at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "valhalla-spec-experts" <valhalla-spec-experts at openjdk.java.net>
> Sent: Monday, October 30, 2023 6:29:42 PM
> Subject: Re: JVM implementation of null-restricted value class types for cast and array

>> On Oct 30, 2023, at 2:25 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Hello,
>> in https://bugs.openjdk.org/browse/JDK-8317766,
>> cast and array creation are specified using the usual opcodes checkcast and
>> anewarray but with the constant pool constant is a condy.
>> 
>> While I like the fact that those opcodes directly use a condy unlike in the
>> parametrized VM proposal where there are intermediary constant pool constants,
>> I think this is too early to introduce suck non backward compatible design.
> 
> Possibly you're misunderstanding here: the idea would be for checkcast and
> anewarray to support *both* a CONSTANT_Class and a CONSTANT_Dynamic (of the
> appropriate shape). Fully backward compatible.

It's backward compatible in term of data structure not in term of semantics.

All libraries that are reading/writing bycodes strongly type the method that read/write opcodes. Enhancing an opcode to allow another constant pool constant is something that was already done in 8 when invokestatic/invokespecial were enhanced to support calling method of interfaces. This required all bytecode libraries that read/write bytecode to have their API updated.

Here the change is worst because CheckedType is a full dynamic type so its value is fully opaque from the POV of a bytecode libraries.
For example, libraries like ASM usually provide ways to repackage/shade classes, for that the class name need to be available at bytecode level, here, because CheckedType is opaque, we can not provide such feature anymore.

In term fo impact, it means that all tools that are manipulating the bytecode without running the condy bootstrap methods are now second class citizens.

> 
>> given that we will need something like that for the parametrized VM anyway. So I
>> would prefer to introduce this kind of constant pool description all at once
>> instead of saying, it currently only work with CheckedType and we will extend
>> this design later.
> 
> CheckedType is the mechanism that we envision for expressing, e.g., a cast to a
> species type. Agree we should not introduce one thing now, something different
> later—avoiding that is one of our goals.

My gut feeling is that for all languages that are using erasure Java, Kotlin or Scala, allowing a cast to a species means that now casts have teeth, you are forcing everybody that want to compile to the new java version to re-audit all the code because there will be new CCE at runtime. I do no think you can do that. It's a migration which is equivalent to the migration from Python 2 to Python 3.

I've no proof of that but we now at least in the JDK that there is a lot of code that will not work if species are fully reified. You can take a look to the methods called by List.copyOf() to have an idea of the issues.

Rémi