RFR (S): 8024974 - Incorrect use of GC_locker::is_active()

[Per Liden]

Thanks Dan!

On 09/19/2013 05:41 PM, Daniel D. Daugherty wrote:
> On 9/19/13 12:03 AM, Per Liden wrote:
>> Webrev: http://cr.openjdk.java.net/~pliden/8024974/webrev.01/
>
> Thumbs up!
>
>
> src/share/vm/memory/gcLocker.hpp
>      No comments.
>
> src/share/vm/memory/gcLocker.cpp
>      By switching from is_active() to is_active_internal(), you lose
>      the "assert(SafepointSynchronize::is_at_safepoint(), ...)". I'm
>      pretty sure that is intentional and a "good thing" for the
>      GC_locker::jni_unlock() function, but I just wanted to be sure.

Correct, jni_unlock is called outside of safepoints so we want to call 
the internal function to avoid that assert. This is safe because this 
function is also in control of switching _needs_gc from true to false.

cheers,
/Per

>
> src/share/vm/classfile/symbolTable.cpp
>      No comments.
>
> Dan
>
>
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8024974
>>
>> SymbolTable and StringTable can make calls to GC_locker::is_active()
>> outside a safepoint. This isn't safe because the GC_locker active
>> state (lock count) is only updated at a safepoint and only remains
>> valid as long as _needs_gc is true. However, outside a safepoint
>> _needs_gc can change to false at any time, which makes it impossible
>> to do a correct call to is_active() in that context. In this case
>> these calls can just be removed since the input argument to
>> basic_add() should never be on the heap and so there's no need to
>> check the GC_locker state. This change also adjusts the assert() in
>> is_active() to makes sure all calls to this function are always done
>> under a safepoint.
>>
>> cheers,
>> /Per
>>
>