RFR (S) 8216136: Don't take Compile_lock for SystemDictionary::_modification_counter

[dean.long at oracle.com]

Hi Coleen.  You still can't safely call notice_modification() outside of 
Compile_lock, (at least not without other changes), so this:

- static inline void notice_modification() { 
assert_locked_or_safepoint(Compile_lock); ++_number_of_modifications; }
+ static inline void notice_modification() { 
Atomic::inc(&_number_of_modifications); }

should be:

static inline void notice_modification() { 
assert_locked_or_safepoint(Compile_lock); 
Atomic::inc(&_number_of_modifications); }


Are you trying to eventually remove Compile_lock completely?  If so, 
then notice_modification() would have to be called *before* the
class hierarchy is changed, not after, and probably other changes would 
be needed as well.

dl


On 1/16/19 8:43 AM, coleen.phillimore at oracle.com wrote:
> Summary: make SystemDictionary::modification_counter atomic so not to 
> require Compile_lock.
>
> I moved updating the modification counter when the class is defined 
> and added to the hierarchy.  I didn't remove the Compile_lock 
> completely because there may be other code currently under the lock 
> that needs it (flush_dependencies).   Can someone from the compiler 
> area also review this?
>
> Made Compile_lock an always safepointing lock.
>
> Tested with mach5 tier1-6.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8216136.01/webrev
> bug link https://bugs.openjdk.java.net/browse/JDK-8216136
>
> Thanks,
> Coleen