This sub-task captures updates to the baseline code that are not
directly related to Async Monitor Deflation.
The cleanups include:
- comment corrections and clarifications, fix typos
- implied boolean expression corrections
- delete/fix whitespace/blank lines
- remove unecessary "ObjectSynchronizer::" prefix from calls
- add additional info to existing asserts; this info was useful during
my debugging of the Async Monitor Deflation code port.
- use a consistent style for Thread::muxAcquire() id tags
- ObjectSynchronizer::inflate_helper() return value is always
ignore by callers so remove it.
- add missing "else" to logical if-else-statement in
ObjectSynchronizer::get_lock_owner()
- guarantee that header() is NULL when
ObjectSynchronizer::omRelease() is called
- code cleanup/motion in ObjectSynchronizer::omFlush()
- cleanup guarantee() and assert() calls
- move some field resets to NULL to when they are needed
and group them together
- reorder global and per-thread code blocks to be the same
instead of arbitrarily different
- move some per-thread code out of the gListLock critical
section since that lock protects the global monitor list
- update existing 'monitorinflation' logging to:
- be clear about the originating source of the log mesg
- use 'Self' in ResourceMark ctrs which is more efficient
- Replace a set_owner(NULL) call with a set_header(NULL)
call in the "CASE: neutral" part of ObjectSynchronizer::inflate()
when the object->cas_set_mark() fails. This is a rare race.
- Update runtime/logging/MonitorInflationTest.java to match the
modified output.
In all of the above cleanups, there are only three real logic changes:
- add missing "else" to logical if-else-statement in
ObjectSynchronizer::get_lock_owner()
- guarantee that header() is NULL when
ObjectSynchronizer::omRelease() is called
- Replace a set_owner(NULL) call with a set_header(NULL)
call in the "CASE: neutral" part of ObjectSynchronizer::inflate()
when the object->cas_set_mark() fails. This is a rare race.
The first logic change is simply more efficient. The second and
third logic changes are related to not leaving a bad or stale header
value in a free ObjectMonitor. I have not been able to hypothesize
any bad effects from this stale header value, but by cleaning it up,
the upcoming ObjectMonitor audit code is more strict.