[PATCH] 6822627: NPE at ReferenceTypeImpl.constantPool
serguei.spitsyn at oracle.com
serguei.spitsyn at oracle.com
Wed Jul 20 07:36:43 UTC 2016
Hi Egor,
Thank you for providing the test!
A couple of nits to the test:
56 if (!Arrays.equals(cpbytes, cpbytes2)) {
57 failure("Consequent constantPool results vary, first was : " + cpbytes + ", now: " + cpbytes2);
58 };
Last semicolon is not need.
74 if (!testFailed) {
75 println("ConstantPoolInfoGC: passed");
76 } else {
77 throw new Exception("ConstantPoolInfoGC: failed");
78 }
I'd suggest to rearrange the statement above to something like this:
74 if (testFailed) {
75 throw new Exception("ConstantPoolInfoGC: failed");
76 }
77 println("ConstantPoolInfoGC: passed");
But I leave it up to you. No need to see another webrev. I can
sponsor your fix, if needed. Thanks, Serguei On 7/19/16 00:07, Egor
Ushakov wrote:
>
> Hi Serguei,
>
> here's a new webrev with a test included:
> http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.01/
>
> Egor
>
> On 15.07.2016 12:22, serguei.spitsyn at oracle.com wrote:
>> Hi Egor, The fix looks good modulo the synchronization issue. Do you
>> have a jtreg unit test reproducing this failure mode? We have a rule
>> to provide a test coverage for the fixes. Thanks, Serguei On 7/15/16
>> 00:03, Egor Ushakov wrote:
>>>
>>> Thanks for your comments!
>>>
>>> I totally agree that the code there requires major refactoring. In
>>> the fix I tried not to make it worse and fix the NPE.
>>>
>>> On 14.07.2016 20:06, Martin Buchholz wrote:
>>>> The lack of volatile or synchronization, plus the use of multiple
>>>> mutable fields, suggests that a deeper fix is necessary to be truly
>>>> correct. For comparison, much of the similar code implementing
>>>> reflection has been changed to use volatile. But that's a big job,
>>>> for the serviceability team.
>>>> On Thu, Jul 14, 2016 at 2:33 AM, Egor Ushakov
>>>> <egor.ushakov at jetbrains.com <mailto:egor.ushakov at jetbrains.com>>
>>>> wrote:
>>>>
>>>> Hi, I'm a developer from IDEA debugger (we have company OCA).
>>>> We've increased usage of ReferenceTypeImpl.constantPool and now
>>>> facing JDK-6822627 more often. Please review and sponsor the
>>>> fix. The problem was that constantPoolBytesRef SoftReference
>>>> value coud be GCed and there was no check for that. I've added
>>>> it to the check inside getConstantPoolInfo to request the bytes
>>>> again in this case. BUGURL:
>>>> https://bugs.openjdk.java.net/browse/JDK-6822627 WEBREV:
>>>> http://cr.openjdk.java.net/~avu/JDK-6822627/webrev.00/
>>>> <http://cr.openjdk.java.net/%7Eavu/JDK-6822627/webrev.00/>
>>>> Thanks!-- Egor Ushakov Software Developer JetBrains
>>>> http://www.jetbrains.com The Drive to Develop
>>>>
>>> --
>>> Egor Ushakov
>>> Software Developer
>>> JetBrains
>>> http://www.jetbrains.com
>>> The Drive to Develop
> --
> Egor Ushakov
> Software Developer
> JetBrains
> http://www.jetbrains.com
> The Drive to Develop
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160720/e51648be/attachment.html>
More information about the serviceability-dev
mailing list