help with changes to hotspot runtime to implement sealed types

[Karen Kinnear]

Vicente,

Just catching up. Had missed the evolution of sealed types. Is there anything written about any future
plans for sealed types or does your description capture current and future plans? Is there a requirement
that Sealed and Sub are loaded by the same class loader - that is implied by your comment about same package or module, but not currently a requirement for super/sub types in general.  Will there be any
connection with nestmates? Or any plans for dynamically extending sealed types?

When you get to the point of clarifying the JVMS, can you also talk to us about JVMTI
and restrictions for class redefinition/retransformation - I would start with a proposal that you 
can NOT change the new PermittedSubtypes attribute via redefinition. If that is too strong a restriction,
disallow removing any existing attribute members and disallow adding the attribute if it does not
currently exist.

An implementation note - I do not see a change to oops/method.cpp in your diff below.
If you look in Method::is_final_method today the result is “true” if class_access_flags.is_final().
That logic will require changing since it will NOT be true if you have this PermittedSubtypes attribute.
This could cause problems - e.g. we do not leave space in the vtable so method overriding would not work.

I did not do a full search of all places in which we make assumptions based on class_access_flags.is_final(),
but I would assume you would need to do that, e.g. opto/type.cpp - but I assume you are starting out -Xint, 
and will get the compiler team involved to remove any optimizations that aren’t pertinent anymore.

thanks,
Karen

> On Dec 11, 2018, at 8:53 PM, Vicente Romero <vicente.romero at oracle.com> wrote:
> 
> Hi HS runtime,
> 
> I'm working on the implementation of sealed types one of the projects under the Amber umbrella. A sealed type is one that can only be subtyped by a set of classes declared by the sealed type in Java:
> 
> final class Sealed permits Sub {}
>    class Sub extends Sealed {}
> 
> Both Sealed and Sub can coexist in the same compilation unit, package or module. The class file for Sealed have an attribute named PermittedSubtypes that contains a list with the, well, permitted subtypes. In the case of the example it will be Sub only. On top of that class Sealed will be final. So when loading / parsing class file for Sub, we need to check, given that its supertype is final, if Sub is listed as one of the permitted subtypes of Sealed or fail in other case. And here is when I'm finding a roadblock. Currently the VM doesn't allow any class to subtype a final class and this is checked at:
> 
> ClassFileParser::post_process_parsed_stream
> 
> so I removed the code that was doing this check at `ClassFileParser` and created a separate method to do the checking at InstanceKlass with the idea of enforcing the check after the class file was parsed and the given class loaded. But regardless of my intents I always get a SOE. The SOE happens when the subclass ask the super class if the subclass is listed as one of its permitted subtypes. To answer this, the superclass tries to load the subclass so I have a deadlock that I suspect could be hard to solve, if possible. Please see attached what I have done so far. Any ideas?
> 
> Thanks,
> Vicente
> 
> PD, the code runs with no error with the slowdebug configuration
> <sealed.runtime.diff>