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

[Per Liden]

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)