RFR (M) JDK-8163406: The fixup_module_list must be protected by Module_lock when inserting new entries

Coleen Phillimore coleen.phillimore at oracle.com
Sat Sep 10 13:13:45 UTC 2016



On 9/9/16 6:29 PM, Lois Foltan wrote:
>
> On 9/8/2016 7:15 PM, Coleen Phillimore wrote:
>>
>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8163406/webrev/src/share/vm/classfile/javaClasses.cpp.udiff.html 
>>
>>
>> + assert(!Universe::is_module_initialized(), "Incorrect 
>> java.lang.reflect.Module pre module system initialization");
>>
>>
>> Can you assert this here?  Can another thread initialize the module 
>> before this line?  It's not locked.
> Hi Coleen,
> The only time within java_lang_Class::create_mirror() a module should 
> be NULL is during pre module system initialization, so it is important 
> to make this assertion.  How is this any different than checking for 
> Universe::is_fully_initialized()?
>
>>
>> Also, could you make the module fixup list logic a function called 
>> from create_mirror()?  It's too long with too many different things 
>> happening.  We'd gotten it nice, short and concise at one point!
>>
>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8163406/webrev/src/share/vm/classfile/moduleEntry.cpp.html 
>>
> Will do.
>
>>
>> Can you add a comment before
>>
>> ModuleEntryTable::patch_javabase_entries
>>
>> to make it clear that there's a module field in java.lang.Class 
>> instances?
> Will do.
>
>>
>> Also, this line should be pulled out of the loop:
>>
>> 399     Thread* THREAD = Thread::current();
>> 400     KlassHandle kh(THREAD, k);
>>
>>
>> Or better yet, remove both and use the implicit constructor for 
>> KlassHandles in the call to fixup_module_field (KlassHandle doesn't 
>> use THREAD for anything).
> Ok, this is very similar to the code that is used in 
> Universe::fixup_mirrors which I suspect this code was copied from. 
> Would you like me to change fixup_mirrors as well?

No need.   It'll get cleaned up soon.  I just wanted new code to not use 
this idiom.

thanks,
Coleen
>
>>
>> I think everything except these small comments looks good.
> Thanks for the review!
> Lois
>
>>
>> Coleen
>>
>> On 9/7/16 11:31 AM, Lois Foltan wrote:
>>> Hello,
>>>
>>> Please review the following fix:
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~lfoltan/bug_jdk8163406/webrev/
>>>
>>> Bug: The fixup_module_list must be protected by Module_lock when 
>>> inserting new entries
>>> https://bugs.openjdk.java.net/browse/JDK-8163406
>>>
>>> Summary:
>>> During bootstrapping, after the load of java.lang.Class, the method 
>>> java_lang_Class::create_mirror() is multi-threaded. Before java.base 
>>> is defined to the VM, the fixup_module_list stores all classes that 
>>> once java.base is defined, must have their module field patched with 
>>> java.base's java.lang.reflect.Module. Insertion of a class into the 
>>> fixup_module_list must be protected via Module_lock. Included in 
>>> this fix is correct order access store and load of the 
>>> java.lang.reflect.Module field for java.base's ModuleEntry. Thank 
>>> you to David Holmes for guidance on this piece.
>>>
>>> Testing:
>>> Full hotspot nightly testing, JCK vm & lang, several iterations of 
>>> jaxp tests to test JDK-8164721
>>
>



More information about the hotspot-runtime-dev mailing list