help with changes to hotspot runtime to implement sealed types

[Vicente Romero]

sure, thanks for all the feedback and comments
Vicente

On 1/3/19 2:04 PM, Karen Kinnear wrote:
> Thanks Vicente,
>
> Let us know if you need any more runtime or compiler assistance.
>
> thanks,
> Karen
>
>> On Jan 3, 2019, at 2:02 PM, Vicente Romero <vicente.romero at oracle.com> wrote:
>>
>> Hi Karen,
>>
>> On 1/2/19 5:37 PM, Karen Kinnear wrote:
>>> 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?
>> my initial implementation has just trying to capture the current description which is still under development. So this is a prototype for users to start playing with the concept.
>>
>>> 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.
>> the assumption is that they should share the same class loader, I will take a look at enforcing this.
>>
>>>    Will there be any
>>> connection with nestmates?
>> this is an open option so a sealed type could allow its nestmates to extend it without having to enumerate all of them
>>
>>>   Or any plans for dynamically extending sealed types?
>> the current proposal is that the compiler most know all the subtypes in advance and they should be explicitly enumerated
>>
>>> 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,
>> sounds like a sensible 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.
>> thanks I will take a look at this
>>> 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
>> I will search for all uses
>>
>>>   - 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
>> Thanks,
>> Vicente
>>>> 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>