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

[Srinivas Ramakrishna]

Ah, OK. Thx  for the clarification!

Reviewed!
-- ramki


On Fri, Jun 28, 2013 at 12:58 AM, Per Liden <per.liden at oracle.com> wrote:
> Hi,
>
> There are no non-JavaThreads doing this currently (to the best of my
> knowledge), so that path should never be executed at the moment. But that
> path could be executed in the future. While doing some
> experimenting/prototyping I had introduced such a thread and that's when I
> ran into the issue.
>
> /Per
>
>
> On 2013-06-28 09:36, Srinivas Ramakrishna wrote:
>>
>> Per, this seems reasonable, but can you give an example of a non-Java
>> thread that executes this code and when? (not knowing enough of the
>> implementation details of G1, this might be a somewhat naive question,
>> but bear with me.)
>>
>> thanks.
>> -- ramki
>>
>> On Thu, Jun 27, 2013 at 6:00 AM, Per Liden <per.liden at oracle.com> 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)
>
>