[RESUMED] Re: RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated
Derek White
derek.white at oracle.com
Tue Jun 21 22:27:27 UTC 2016
Here's a more complete solution to the problem.
As Kim mentioned, the new version sets the object size field of a
java.lang.Class object before it sets the object's header, so GC can
reliably get the size of any object with it's header set.
This fix works by adding a CollectedHeap::class_allocate() method and
associated helpers. These are implemented in CollectedHeap.inline.hpp
only because they share so much structure and code with
CollectedHeap::obj_allocate() that I thought it best to keep them
together (even though there is no performance reason to have the new
code inlined).
Webrev: http://cr.openjdk.java.net/~drwhite/8158946/webrev.02
jprt in progress...
- Derek
On 6/21/16 4:24 PM, Derek White wrote:
> Kim and I just sketched out a more principled solution to this
> problem. I'll see if it works out and get a new webrev in a bit.
>
> Thanks for pushing on this Kim, and not vomiting too much :-)
>
> - Derek
>
> On 6/21/16 2:46 PM, Derek White wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8158946
>>
>> This bug is a race between an assertion in the CMS sweeper and a Java
>> thread loading a class. See the bug report for full description of
>> the race.
>>
>> The fix is to bypass the assertion in CMS for this case, and add
>> extra assertions to catch similar data races in the future.
>>
>> Webrev: http://cr.openjdk.java.net/~drwhite/8158946/webrev.01
>>
>> Tests: jprt
>>
>> - Derek
>>
>
More information about the hotspot-gc-dev
mailing list