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

[Karen Kinnear]

Lois,

Thank you for fixing this.

I had a couple of questions/comments.

1) I was delighted with your finding that the hash table entries already handle order access correctly.
Thank you for adding the clarifying comment.

2) In moduleEntry.hpp
Did you want to remove module() and set_module() so we always go through the accessors that take order_access into account?
When is it safe not to use them?

3) in javaClasses

Lines 856, 865: do you need a load_module_acquire when you read javabase_entry->module() in the assertion?

thanks,
Karen


> On Sep 7, 2016, at 11:31 AM, Lois Foltan <lois.foltan at oracle.com> 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