RFR(xs): 8014022: G1: Non Java threads should lock the shared SATB queue lock without safepoint checks.

[Jon Masamitsu]

Per,

Change looks good.

Jon

On 6/28/2013 12:29 AM, Per Liden wrote:
> Hi Jon,
>
> I only saw this with debug builds of my experimantal repo, where a 
> No_Safepoint_Verifier I had noticed the issue. In product builds there 
> should be a window for silent oop corruption, but I never managed to 
> provoke that.
>
> /Per
>
> On 2013-06-27 19:46, Jon Masamitsu wrote:
>> Per,
>>
>> In a product build what was the symptom of this bug that
>> you observed?
>>
>> Jon
>>
>> On 6/27/13 6:00 AM, Per Liden wrote:
>>> Hi,
>>>
>>> Could I please have a couple of reviews on this small fix.
>>>
>>> Summary: If a non-Java thread writes to an object field the G1
>>> pre-barrier can potentially safepoint when acquiring the shared
>>> pointer queue lock (Shared_SATB_Q_lock). This is problematic if e.g.
>>> the non-Java thread has joined the STS. The solution is to grab the
>>> lock without a safepoint check.
>>>
>>> Testing: I ran into this bug while doing some (unrelated) experiments
>>> with G1, where I had a non-JavaThread do calls to
>>> oop->obj_field_put(). Hotspot doesn't currently have any
>>> non-JavaThread which does this, so it can't currently be provoked by a
>>> test. However, after fixing this in my experimental repo I stopped
>>> running into this issue.
>>>
>>> Webrev: http://cr.openjdk.java.net/~pliden/8014022/webrev.00/
>>>
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014022
>>>
>>> /Per
>>>
>>> (btw, Bengt volunteered to sponsor the change)
>>
>