RFR 8171971: Fix timing bug in JVM management of package export lists

[harold seigel]

Hi Alan,

The VM was already lockng the Module_lock during an access check when 
doing a qualified exports check.  This change expands the scope of the 
of that lock to also cover checking if the packing is unqualifiedly 
exported.

Can JVMTI be used to change a package's export state from qualified to 
unqualified?

Thanks, Harold


On 1/18/2017 10:16 AM, Alan Bateman wrote:
>
>
> On 18/01/2017 15:05, harold seigel wrote:
>> Hi,
>>
>> Please review this fix for the package export timing holes discussed 
>> in JDK-8171971.  The fix reduces the number of PackageEntry fields 
>> that are used to maintain a package's export state and uses the 
>> Module_lock to protect all access to these fields.
>>
>> Also, in cases where a package transitions from having qualified 
>> exports to being unqualifiedly exported, it fixes the cleanup of its 
>> qualified export list by removing the _exported_pending_delete field 
>> and using just is_unqual_exported() to determine when the qualified 
>> exports list can be purged (at a safepoint).
>>
>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8171971/webrev/
> Does this mean that everyone doing an access check needs Module_lock?
>
> BTW: There is no API support for changing a module to export a package 
> unconditionally. Only qualified exports can be added at runtime. Just 
> mentioning in case this helps to consider options that would avoid 
> contention on the mutex during access checks.