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

[Per Liden]

Thanks Jon!

/Per

On 2013-06-28 15:45, Jon Masamitsu wrote:
> 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)
>>>
>>
>