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

Karen Kinnear karen.kinnear at oracle.com
Thu Jan 19 14:28:17 UTC 2017


Harold, that matches my understanding. Start with date when the file was created, and span any year that the file was modified.

thanks,
Karen

> On Jan 19, 2017, at 7:45 AM, harold seigel <harold.seigel at oracle.com> wrote:
> 
> Hi David,
> 
> So if a file, such as modules.cpp, was added to the JVM for JDK-9, but written in 2016, then its copyright should be "2016, 2017," even though the file hasn't yet been part of an actual release?
> 
> Thanks, Harold
> 
> 
> On 1/18/2017 8:04 PM, David Holmes wrote:
>> Hi Harold,
>> 
>> Not a review but noticed the copyright updates are not correct - should now be "2016, 2017," for most of the files not just "2017,"
>> 
>> Thanks,
>> David
>> 
>> On 19/01/2017 1:05 AM, 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/
>>> 
>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8171971
>>> 
>>> The fix was tested with the hotspot, java/lang, java/util, java/io, JFR,
>>> and other JTReg tests, the JCK lang and VM tests, RBT tier2 - tier5
>>> tests on LinuxX64, and the colocated and non-colocated NSK tests.
>>> 
>>> Thanks, Harold
>>> 
> 



More information about the hotspot-runtime-dev mailing list