RFR: 8261268: LOAD_INSTANCE placeholders unneeded for parallelCapable class loaders

[David Holmes]

Hi Coleen,

On 9/02/2021 11:36 pm, Coleen Phillimore wrote:
> On Tue, 9 Feb 2021 12:27:12 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:
> 
>>> src/hotspot/share/classfile/placeholders.cpp line 107:
>>>
>>>> 105: // Doubly-linked list of Threads per action for class/classloader pair
>>>> 106: // Class circularity support: links in thread before loading superclass
>>>> 107: // bootstrap loader support:  links in a thread before load_instance_class
>>>
>>> I don't think the loader is what the comment is referring to. The reference to bootstrapsearchpath relates to this comment in SD::resolve_instance_class_or_null:
>>>      // add placeholder entry to record loading instance class
>>>      // Five cases:
>>>      // All cases need to prevent modifying bootclasssearchpath
>>>      // in parallel with a classload of same classname
>>
>> I don't see any code that does this though.  The code used to compute_loader_lock_object() and return NULL in JVMTI where it was modifying the bootclass search path.  I wonder if that code should have a wait on the placeholder.  I'll investigate.
> 
> ClassLoader::load_class reads the bootstrapsearchpath lock free.  If it's modified after it's read, then the new entry isn't found.  I don't think there's a requirement for locking.

I looked through the JDK 6 code and it has these comments connecting the 
bootclass search path, but no actual code that shows any  connection 
between that path and the placeholder table. So it seems fine to expunge 
all those comments in the placeholder and SD code.

Thanks,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2469
>