RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx
Coleen Phillimore
coleen.phillimore at oracle.com
Tue Feb 3 16:57:06 UTC 2015
Thanks, Dan.
Coleen
On 2/3/15, 9:54 AM, Daniel D. Daugherty wrote:
> Claes,
>
> Coleen filed the following bug yesterday:
>
> JDK-8072128 mutexLocker.cpp _mutex_array[] initialization broken
> with safepoint check change
> https://bugs.openjdk.java.net/browse/JDK-8072128
>
> I've closed JDK-8072406 as a dup of JDK-8072128.
>
> Dan
>
>
> On 2/3/15 5:21 AM, Claes Redestad wrote:
>> Filed https://bugs.openjdk.java.net/browse/JDK-8072406, thanks!
>>
>> /Claes
>>
>> On 02/02/2015 06:07 PM, Coleen Phillimore wrote:
>>>
>>> That appears unintentional. Yes, that is a bug. Do you want to
>>> file one, or we could?
>>> Thanks!
>>> Coleen
>>>
>>> On 2/2/15, 11:54 AM, Claes Redestad wrote:
>>>> Hi,
>>>>
>>>> I know this has been pushed, but I wonder if the removal of
>>>> _num_mutex++ from
>>>> the def macro in mutexLocker.cpp was really intentional?
>>>>
>>>> It seems to me this means _mutex_array won't initialize properly in
>>>> the current
>>>> code, breaking print_owned_locks_on_error (always prints None). Bug?
>>>>
>>>> /Claes
>>>>
>>>> On 2014-12-12 17:02, Max Ockner wrote:
>>>>> OK, I have made these changes.
>>>>> Thanks to everyone who helped me through this, especially Dan,
>>>>> David, and Coleen.
>>>>>
>>>>> On 12/10/2014 4:11 PM, Daniel D. Daugherty wrote:
>>>>>> On 12/10/14 9:56 AM, Max Ockner wrote:
>>>>>>> New webrev:
>>>>>>> http://cr.openjdk.java.net/~coleenp/8047290absolutely_final/
>>>>>>
>>>>>> Thumbs up! No need for a re-review if you address any of the
>>>>>> formatting comments below.
>>>>>>
>>>>>> Repeat from last time (I've seen trailing white space in this
>>>>>> round; haven't checked for the other jcheck-ish things).
>>>>>>
>>>>>> - jcheck is going to complain about some of your lines that
>>>>>> have trailing white space:
>>>>>>
>>>>>> $ grep -n ' *$' `cat files.list`
>>>>>> $ grep -n '\t' `cat files.list`
>>>>>>
>>>>>> Don't know if you have any tabs, but I included that one also.
>>>>>> Not all platforms like '\t' for the grep parameter.
>>>>>>
>>>>>> - jcheck may also complain about the blank lines at the end
>>>>>> of the new tests
>>>>>>
>>>>>> src/share/vm/runtime/mutex.hpp
>>>>>> line 197: SafepointCheckRequired
>>>>>> safepoint_check_required = _safepoint_check_always);
>>>>>> One space too many after the '='.
>>>>>>
>>>>>> Also, I see an extra space at the end of the line; jcheck
>>>>>> will not be happy.
>>>>>>
>>>>>> src/share/vm/runtime/mutex.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/runtime/mutexLocker.cpp
>>>>>> line 174: }
>>>>>> Should be moved left by two spaces (i.e., one indent to the
>>>>>> left of the code block above it).
>>>>>>
>>>>>> src/share/vm/runtime/thread.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/runtime/vmThread.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/os/aix/vm/osThread_aix.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/os/bsd/vm/osThread_bsd.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/os/linux/vm/osThread_linux.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/classfile/classLoaderData.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/memory/metaspace.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/runtime/vm_operations.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/memory/sharedHeap.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
>>>>>>
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
>>>>>>
>>>>>> line 6391: _lock(mutex_rank >= 0 ? new Mutex(mutex_rank,
>>>>>> mutex_name, true ,
>>>>>> Extra space before the last comma.
>>>>>>
>>>>>> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp
>>>>>>
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/services/diagnosticFramework.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/services/memoryManager.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/utilities/decoder.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/utilities/events.hpp
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/utilities/workgroup.cpp
>>>>>> No comments.
>>>>>>
>>>>>> src/share/vm/prims/whitebox.cpp
>>>>>> line 1045: WB_END
>>>>>> Please add a blank line after this line.
>>>>>>
>>>>>> test/testlibrary/whitebox/sun/hotspot/WhiteBox.java
>>>>>> No comments.
>>>>>>
>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java
>>>>>> line 42:
>>>>>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(true, true);
>>>>>> Java code indent is four spaces.
>>>>>>
>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java
>>>>>> line 42:
>>>>>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(false, false);
>>>>>> Java code indent is four spaces.
>>>>>>
>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java
>>>>>> line 42:
>>>>>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(false, true);
>>>>>> Java code indent is four spaces.
>>>>>>
>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java
>>>>>> line 42:
>>>>>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(true, false);
>>>>>> Java code indent is four spaces.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> I have addressed dan's suggestions. I also removed unnecessary
>>>>>>> "this->" occurrences from the assert statements.
>>>>>>>
>>>>>>> Though I realize that I have unnecessarily duplicated code in my
>>>>>>> tests, I do not want to combine the tests into one right now
>>>>>>> because (1) They work as they are, (2) They can fail
>>>>>>> independently, (3) The amount of code needed to run all four
>>>>>>> tests in one file without crashing out after the first failure
>>>>>>> is not as small as you might think, and (4) I want to commit
>>>>>>> this before someone else messes with the locks to avoid more
>>>>>>> merge conflicts. To be clear, I am not opposed to fixing this
>>>>>>> separately if people think it is important, but I prefer to put
>>>>>>> it off until the bulk of the fix is committed.
>>>>>>>
>>>>>>> Does this look ready?
>>>>>>>
>>>>>>> Thanks for your help,
>>>>>>> Max O
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 12/8/2014 1:39 AM, David Holmes wrote:
>>>>>>>> Hi Max,
>>>>>>>>
>>>>>>>> Just a nit with the tests - it seems to me we should be able to
>>>>>>>> write a single Java class that can process all four
>>>>>>>> combinations rather than duplicating the bulk of the code.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>> On 5/12/2014 7:50 AM, Max Ockner wrote:
>>>>>>>>> Hello once again...
>>>>>>>>> I have a new (and suggestively titled) webrev:
>>>>>>>>> http://cr.openjdk.java.net/~coleenp/8047290final/
>>>>>>>>>
>>>>>>>>> Ran aurora tests.
>>>>>>>>>
>>>>>>>>> Here is a list of "sometimes" locks:
>>>>>>>>>
>>>>>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>>>>>>>> "SLTMonitor"
>>>>>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>>>>>>>> "CompactibleFreeListSpace._lock"
>>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
>>>>>>>>>
>>>>>>>>> "freelist par lock"
>>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
>>>>>>>>>
>>>>>>>>> "SR_lock" share/vm/runtime/thread.cpp
>>>>>>>>> "CMS_markBitMap_lock"
>>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The remaining "sometimes" locks can be found in
>>>>>>>>> share/vm/runtime/mutexLocker.cpp:
>>>>>>>>>
>>>>>>>>> ParGCRareEvent_lock
>>>>>>>>> Safepoint_lock
>>>>>>>>> Threads_lock
>>>>>>>>> VMOperationQueue_lock
>>>>>>>>> VMOperationRequest_lock
>>>>>>>>> Terminator_lock
>>>>>>>>> Heap_lock
>>>>>>>>> Compile_lock
>>>>>>>>> PeriodicTask_lock
>>>>>>>>> JfrStacktrace_lock
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Max Ockner
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 11/25/2014 3:03 AM, David Holmes wrote:
>>>>>>>>>> Hi Max,
>>>>>>>>>>
>>>>>>>>>> On 21/11/2014 7:56 AM, Max Ockner wrote:
>>>>>>>>>>> Hello again,
>>>>>>>>>>>
>>>>>>>>>>> I have made changes based on all comments. There is now a
>>>>>>>>>>> pair of assert
>>>>>>>>>>> statements in the Monitor/Mutex wait() methods. When I reran
>>>>>>>>>>> tests, I
>>>>>>>>>>
>>>>>>>>>> Is there an updated webrev?
>>>>>>>>>>
>>>>>>>>>>> caught another lock that I had to change to "sometimes", but
>>>>>>>>>>> the assert
>>>>>>>>>>> that caught this lock was not in wait. There are currently
>>>>>>>>>>> no locks that
>>>>>>>>>>> use try to pass an incorrect safepoint check argument to
>>>>>>>>>>> wait().
>>>>>>>>>>> Instead, gcbasher did not catch this lock last time, when
>>>>>>>>>>> the only
>>>>>>>>>>> asserts were in lock and lock_without_safepoint. This lock is
>>>>>>>>>>> "CMS_markBitMap_lock" in
>>>>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'm guessing that it was not caught by the tests because
>>>>>>>>>>> this section of
>>>>>>>>>>> code is not reached very often. My initial inspection failed
>>>>>>>>>>> to catch
>>>>>>>>>>> this lock because it is passed around between various
>>>>>>>>>>> structures and
>>>>>>>>>>> renamed 4 times. I have not yet found a good way to check
>>>>>>>>>>> for this
>>>>>>>>>>> situation, even with a debugger.
>>>>>>>>>>>
>>>>>>>>>>> Are there any tests which actually manage to hit every line
>>>>>>>>>>> of code?
>>>>>>>>>>
>>>>>>>>>> No. There is too much code that is dependent on low-level
>>>>>>>>>> details of
>>>>>>>>>> the GC used, the compilation strategy, plus the set of
>>>>>>>>>> runtime flags
>>>>>>>>>> used (and whether product or fastdebug). That's why we have
>>>>>>>>>> lots of
>>>>>>>>>> tests run in lots of different ways, to try to get coverage.
>>>>>>>>>>
>>>>>>>>>>> How should I handle this situation where I can't rely on the
>>>>>>>>>>> tests that
>>>>>>>>>>> I have run to tell me if I have missed something?
>>>>>>>>>>> At what point can I assume that everything is OK?
>>>>>>>>>>
>>>>>>>>>> Difficult to answer in general - there are a number of
>>>>>>>>>> recommended
>>>>>>>>>> test suites used by the runtime team, but your changes will also
>>>>>>>>>> impact GC and compiler code and so may not get exercised by the
>>>>>>>>>> runtime test suites (unless run with various compiler and GC
>>>>>>>>>> options).
>>>>>>>>>> Perhaps an ad-hoc test run similar to nightlies? Or you push
>>>>>>>>>> after the
>>>>>>>>>> weekly snapshot so as to maximise nightly testing, and if
>>>>>>>>>> there are
>>>>>>>>>> issues exposed then you have time to address them or revert
>>>>>>>>>> the fix.
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> David
>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Max Ockner
>>>>>>>>>>>
>>>>>>>>>>> On 11/10/2014 11:57 PM, David Holmes wrote:
>>>>>>>>>>>> Hi Max,
>>>>>>>>>>>>
>>>>>>>>>>>> On 8/11/2014 2:15 AM, Max Ockner wrote:
>>>>>>>>>>>>> Hello all,
>>>>>>>>>>>>> I have made these additonal changes:
>>>>>>>>>>>>> -Moved the assert() statements into the lock and
>>>>>>>>>>>>> lock_without_safepoint
>>>>>>>>>>>>> methods.
>>>>>>>>>>>>> -Changed Monitor::SafepointAllowed to
>>>>>>>>>>>>> Monitor::SafepointCheckRequired
>>>>>>>>>>>>> -Changed the Monitor::SafepointCheckRequired values for
>>>>>>>>>>>>> several locks
>>>>>>>>>>>>> which were locked outside of a MutexLockerEx (some were
>>>>>>>>>>>>> locked with
>>>>>>>>>>>>> MutexLocker, some were locked were locked without any
>>>>>>>>>>>>> MutexLocker* )
>>>>>>>>>>>>>
>>>>>>>>>>>>> New webrev location:
>>>>>>>>>>>>> http://cr.openjdk.java.net/~coleenp/8047290/
>>>>>>>>>>>>
>>>>>>>>>>>> Generally this is all okay - a few style and other nits below.
>>>>>>>>>>>>
>>>>>>>>>>>> However you missed adding an assert in Monitor::wait to
>>>>>>>>>>>> check if the
>>>>>>>>>>>> no_safepoint_check flag was being used correctly for the
>>>>>>>>>>>> current
>>>>>>>>>>>> monitor.
>>>>>>>>>>>>
>>>>>>>>>>>> Specific comments:
>>>>>>>>>>>>
>>>>>>>>>>>> src/share/vm/runtime/mutex.hpp
>>>>>>>>>>>>
>>>>>>>>>>>> This comment is no longer accurate with the moved check
>>>>>>>>>>>> location:
>>>>>>>>>>>>
>>>>>>>>>>>> + // MutexLockerEx checks these flags when acquiring a lock
>>>>>>>>>>>> + // to ensure consistent checking for each lock.
>>>>>>>>>>>>
>>>>>>>>>>>> The same goes for other references to MutexLockerEx in the
>>>>>>>>>>>> enum
>>>>>>>>>>>> description.
>>>>>>>>>>>>
>>>>>>>>>>>> Also copyright year needs updating.
>>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>>
>>>>>>>>>>>> src/share/vm/runtime/mutex.cpp
>>>>>>>>>>>>
>>>>>>>>>>>> 898 //Ensure
>>>>>>>>>>>> 961 //Ensure
>>>>>>>>>>>>
>>>>>>>>>>>> Space needed after //
>>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>>
>>>>>>>>>>>> src/share/vm/runtime/mutexLocker.cpp
>>>>>>>>>>>>
>>>>>>>>>>>> + var = new type(Mutex::pri, #var,
>>>>>>>>>>>> vm_block,safepoint_check_allowed); \
>>>>>>>>>>>>
>>>>>>>>>>>> space needed after comma in k,s
>>>>>>>>>>>>
>>>>>>>>>>>> ---
>>>>>>>>>>>>
>>>>>>>>>>>> src/share/vm/runtime/mutexLocker.hpp
>>>>>>>>>>>>
>>>>>>>>>>>> Whitespace only changes - looks like leftovers from removed
>>>>>>>>>>>> edits.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> David
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> Additional testing:
>>>>>>>>>>>>> jtreg ./jdk/test/java/lang/invoke
>>>>>>>>>>>>> jtreg jfr tests
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here is a list of ALL of the "sometimes" locks:
>>>>>>>>>>>>>
>>>>>>>>>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp
>>>>>>>>>>>>> "SLTMonitor"
>>>>>>>>>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp
>>>>>>>>>>>>> "CompactibleFreeListSpace._lock"
>>>>>>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> "freelist par lock"
>>>>>>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> "SR_lock" share/vm/runtime/thread.cpp
>>>>>>>>>>>>>
>>>>>>>>>>>>> The remaining "sometimes" locks can be found in
>>>>>>>>>>>>> share/vm/runtime/mutexLocker.cpp:
>>>>>>>>>>>>>
>>>>>>>>>>>>> ParGCRareEvent_lock
>>>>>>>>>>>>> Safepoint_lock
>>>>>>>>>>>>> Threads_lock
>>>>>>>>>>>>> VMOperationQueue_lock
>>>>>>>>>>>>> VMOperationRequest_lock
>>>>>>>>>>>>> Terminator_lock
>>>>>>>>>>>>> Heap_lock
>>>>>>>>>>>>> Compile_lock
>>>>>>>>>>>>> PeriodicTask_lock
>>>>>>>>>>>>> JfrStacktrace_lock
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have not checked the validity of the "sometimes" locks,
>>>>>>>>>>>>> and I
>>>>>>>>>>>>> believe
>>>>>>>>>>>>> that this should be a different project.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for your help!
>>>>>>>>>>>>> Max Ockner
>>>>>>>>>>>>> On 10/15/2014 8:54 PM, David Holmes wrote:
>>>>>>>>>>>>>> Hi Max,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This is looking good.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> A few high-level initial comments:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think SafepointAllowed should be SafepointCheckNeeded
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Why are the checks in MutexLocker when the state is
>>>>>>>>>>>>>> maintained in the
>>>>>>>>>>>>>> mutex itself and the mutex/monitor has
>>>>>>>>>>>>>> lock_without_safepoint, and
>>>>>>>>>>>>>> wait(<safepoint checking flag>) ? I would have expected
>>>>>>>>>>>>>> to see the
>>>>>>>>>>>>>> check in the mutex/monitor methods.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Checking consistent usage of the _no_safepoint_check_flag
>>>>>>>>>>>>>> is good.
>>>>>>>>>>>>>> But
>>>>>>>>>>>>>> another part of this is that a monitor/mutex that never
>>>>>>>>>>>>>> checks for
>>>>>>>>>>>>>> safepoints should never be held when a thread blocks at a
>>>>>>>>>>>>>> safepoint -
>>>>>>>>>>>>>> is there some way to easily check that? I was surprised
>>>>>>>>>>>>>> how many
>>>>>>>>>>>>>> locks
>>>>>>>>>>>>>> are actually not checking for safepoints.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Did you find any cases where the mutex/monitor was being
>>>>>>>>>>>>>> used
>>>>>>>>>>>>>> inconsistently and incorrectly?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Did you analyse the "sometimes" cases to see if they were
>>>>>>>>>>>>>> safe?
>>>>>>>>>>>>>> (Aside: just for fun check out what happens if you lock the
>>>>>>>>>>>>>> Threads_lock with a safepoint check and a safepoint has been
>>>>>>>>>>>>>> requested
>>>>>>>>>>>>>> :) ).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 16/10/2014 4:04 AM, Max Ockner wrote:
>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I am a new member of the Hotspot runtime team in
>>>>>>>>>>>>>>> Burlington, MA.
>>>>>>>>>>>>>>> Please review my first fix related to safepoint checking.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Summary: MutexLockerEx can either acquire a lock with or
>>>>>>>>>>>>>>> without a
>>>>>>>>>>>>>>> safepoint check.
>>>>>>>>>>>>>>> In some cases, a particular lock must either safepoint
>>>>>>>>>>>>>>> check
>>>>>>>>>>>>>>> always or
>>>>>>>>>>>>>>> never to avoid deadlocking.
>>>>>>>>>>>>>>> Some other locks have semantics which allow them to
>>>>>>>>>>>>>>> avoid deadlocks
>>>>>>>>>>>>>>> despite having a safepoint check only some of the time.
>>>>>>>>>>>>>>> All locks that are OK having inconsistent safepoint
>>>>>>>>>>>>>>> checks have been
>>>>>>>>>>>>>>> marked. All locks that should never safepoint check and
>>>>>>>>>>>>>>> all locks
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>> should always safepoint check have also been marked.
>>>>>>>>>>>>>>> When a MutexLockerEx acquires a lock with or without a
>>>>>>>>>>>>>>> safepoint
>>>>>>>>>>>>>>> check,
>>>>>>>>>>>>>>> the lock's safepointAllowed marker is checked to ensure
>>>>>>>>>>>>>>> consistent
>>>>>>>>>>>>>>> safepoint checking.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Webrev:
>>>>>>>>>>>>>>> http://oklahoma.us.oracle.com/~mockner/webrev/8047290/
>>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Tested with:
>>>>>>>>>>>>>>> jprt "-testset hotspot"
>>>>>>>>>>>>>>> jtreg hotspot
>>>>>>>>>>>>>>> vm.quick.testlist
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Whitebox tests:
>>>>>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java:
>>>>>>>>>>>>>>> Test
>>>>>>>>>>>>>>> expects Assert ("This lock should always have a
>>>>>>>>>>>>>>> safepoint check")
>>>>>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java:
>>>>>>>>>>>>>>> Test
>>>>>>>>>>>>>>> expects Assert ("This lock should never have a safepoint
>>>>>>>>>>>>>>> check")
>>>>>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java:
>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>> should not assert. (Lock is properly acquired with no
>>>>>>>>>>>>>>> safepoint
>>>>>>>>>>>>>>> check)
>>>>>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java:
>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>> should not assert. (Lock is properly acquired with
>>>>>>>>>>>>>>> safepoint check)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Max
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>
More information about the hotspot-dev
mailing list