RFR: 8336919: Cleanup and rename tags in placeholders code [v3]

Coleen Phillimore coleenp at openjdk.org
Thu Jul 25 18:12:32 UTC 2024


On Thu, 25 Jul 2024 15:03:21 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> If you're doing a parallel super load, it could be the super class but not necessarily, it could also be an interface class.  I thought it was an optimization, because if you add the circularity placeholder, and look up the existing super class, it should immediately find it an return.  Now I'm wondering if it's more than an optimization based on the comment in resolve_with_circularity_check.  I'll check this.
>> 
>> I added the assert above it for the place in static dumping that used this flag as either klass->super or interface, ie where it differentiated based on this flag.
>
> Yes, this looks like an optimization, that we could do unconditionally if we want or not at all.  The comment mentions that we'll get a linkage error if we don't do it but I think it's talking about something else.
> 
>       // To support parallel loading: if class is done loading, just return the superclass
>       // if the next_name matches class->super()->name() and if the class loaders match.
>       // Otherwise, a LinkageError will be thrown later.
>       if (klassk != nullptr && is_superclass &&
>           ((quicksuperk = klassk->java_super()) != nullptr) &&
>            ((quicksuperk->name() == next_name) &&
>               (quicksuperk->class_loader() == class_loader()))) {
>              return quicksuperk;
>        } else {
>         // Must check ClassCircularity before checking if superclass is already loaded.

I reverted this with a new comment because the optimization won't succeed if it's an interface or a loadedDescriptor, but it doesn't hurt to check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20279#discussion_r1691927453


More information about the hotspot-runtime-dev mailing list