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

[Daniel D. Daugherty]

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.

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
>