RFR: 8060130: Simplify the synchronization of defining and getting java.lang.Package
David M. Lloyd
david.lloyd at redhat.com
Wed Oct 15 12:43:43 UTC 2014
On 10/14/2014 07:22 PM, Mandy Chung wrote:
> On 10/13/2014 5:50 AM, David M. Lloyd wrote:
>> On 10/10/2014 07:31 PM, Mandy Chung wrote:
>>> On 10/10/2014 8:10 AM, Claes Redestad wrote:
>>>> Hi all,
>>>> please review this patch which attempts to clean up synchronization
>>>> and improve scalability when
>>>> defining and getting java.lang.Package objects.
>>> I agree with David that getting Package objects are not performance
>>> critical. On the other hand, the code defining/getting Packages is
>>> old and deserves some cleanup especially the synchronization part.
>> I have a little more information on this subject. We've a possible
>> (and somewhat likely) deadlock which occurs because one thread can
>> attempt to define a system class while holding the
>> java.lang.Package#pkgs lock, while another thread can attempt to get a
>> package while defining a system class (while holding the class loader
>> lock). I do not recall whether parallel class loading alleviates this
>> issue. We solved the problem by loading Packages.getPackages() in
>> early (single-threaded) bootstrap.
> Do you recall what JDK version you observed this possible deadlock? I
> wonder if the fix for 7001933  in JDK 7 and 6u25 resolved the
> deadlock problem you ran into.
>  http://hg.openjdk.java.net/jdk9/dev/jdk/rev/4a7da412db38
The change would have been observed in early 2011 so I think it was
probably a JDK 6 version before 25 (which I did not install until April
of that year) - looks like most likely candidate based on my JDK
directory is 1.6.0_22.
>> So from my perspective, just getting rid of the synchronization on
>> that field alone makes this change worthwhile.
> Yes that's what I think too.
More information about the core-libs-dev