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

[Derek White]

On 6/28/16 11:26 AM, Thomas Schatzl wrote:
> Hi again,
>
> On Tue, 2016-06-28 at 15:09 +0200, Thomas Schatzl wrote:
>> Hi,
>>
>> On Mon, 2016-06-27 at 10:10 -0400, Derek White wrote:
>>> I'd like to split out the memory fence issue from the race fixed by
>>> this webrev. I think the fence issue may require more performance
>>> testing and several attempts to get something satisfactory.
>>>
>>> New bug created:
>>>      JDK-8160369 Memory fences needed around setting and reading
>>> object lengths.
>>>
>>> How do reviewers feel about this patch to fix the initial race
>>> condition?
>>    looking at the 02 webrev:
>>
>    another question:
>
> - http://cr.openjdk.java.net/~drwhite/8158946/webrev.02/src/share/vm/gc
> /shared/collectedHeap.inline.hpp.frames.html
>
> Why does CollectedHeap::post_allocation_setup_class() use
> post_allocation_install_obj_klass() instead of
> post_allocation_setup_common(), effectively skipping setup of the mark
> word?

Hi Thomas,

I rewrote this in webrev.03 after your earlier comments, so this is a 
moot point, but the webrev.02 version it called 
bothpost_allocation_setup_no_klass_install() /AND/ 
post_allocation_install_obj_klass(). So it did the mark work also. At 
one point I was concerned that post_allocation_setup_common() did the 
object zeroing, so I tried to avoid that call (unnecessarily).

  - Derek


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160628/2a26d23d/attachment.htm>