[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