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.
|