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.spit...@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.usha...@jetbrains.com <mailto:egor.usha...@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
