help with changes to hotspot runtime to implement sealed types

David Holmes david.holmes at oracle.com
Wed Dec 12 02:21:36 UTC 2018


Hi Vincente,

On 12/12/2018 11:53 am, Vicente Romero 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 {}

This has evolved :) I was expecting it to be restricted to subclassing 
by nestmates.

> 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?

+      if (name == k->name()) {
+        log_trace(class, sealed)("- Found it at permitted_subtypes[%d] 
=> cp[%d]", i, cp_index);
+        // names match so check actual klass - this may trigger class 
loading if
+        // it doesn't match (but that should be impossible)
+        Klass* k2 = _constants->klass_at(cp_index, CHECK_false);

You can't check the actual class in your case as if the names match then 
it refers to the subclass you are currently trying to load.

HTH,
David


> Thanks,
> Vicente
> 
> PD, the code runs with no error with the slowdebug configuration


More information about the amber-dev mailing list