Fwd: RFR: 8158946 - btree009 fails with assert(s > 0) failed: Bad size calculated

[Derek White]

On 6/30/16 7:17 PM, Coleen Phillimore wrote:
>
> http://cr.openjdk.java.net/~drwhite/8158946/webrev.04/src/share/vm/classfile/javaClasses.hpp.udiff.html 
>
> http://cr.openjdk.java.net/~drwhite/8158946/webrev.04/src/share/vm/gc/cms/concurrentMarkSweepGeneration.cpp.udiff.html 
>
>
> Since there are no changes, can you hg revert thes file?
Sure, if folding the patches doesn't do it first (I'll double check).
>
> http://cr.openjdk.java.net/~drwhite/8158946/webrev.04/src/share/vm/oops/instanceMirrorKlass.cpp.udiff.html 
>
>
> Wow, what a small race!
>
> Nice fix.  The code looks good.
>
> Coleen

Thanks Colleen!
>
>
> On 6/30/16 5:15 PM, Derek White wrote:
>> New webrev goes back to using java_lang_Class::set_oop_size(new_cls, 
>> size);
>>
>> http://cr.openjdk.java.net/~drwhite/8158946/webrev.04/
>>
>> jprt run in progress. Built w/ and w/o PCH.
>>
>> On 6/30/16 7:56 AM, Derek White wrote:
>>> On 6/30/16 12:28 AM, David Holmes wrote:
>>>> Hi Derek,
>>>>
>>>> Understand the fix in principle.
>>>>
>>>> But I don't understand why you got rid of 
>>>> java_lang_Class::set_oop_size, and instead exposed 
>>>> java_lang_Class::oop_size_offset(), then had 
>>>> InstanceMirrorKlass::allocate_instance pass the offset to 
>>>> CollectedHeap::class_allocate, which passes it to 
>>>> CollectedHeap::post_allocation_setup_class - that seems rather 
>>>> convoluted. Can CollectedHeap::post_allocation_setup_class not call 
>>>> java_lang_Class::set_oop_size directly?
>>>
>>> Short answer is I didn't think so. collectedHeap.inline.hpp has a 
>>> very small include set, and I was concerned about circular 
>>> dependencies. Another approach would be to push ::set_oop_size() 
>>> over to instanceKlassMirror.hpp, and see if the includes seem saner 
>>> that way. I'll try some alternatives...
>>
>> OK, doing the simple and obvious thing worked out after all. Thanks 
>> David!
>>
>>  - Derek
>