Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
During the code review for: JDK-8222295 more baseline cleanups from Async Monitor Deflation project Some comments came up about this function: src/hotspot/share/oops/markOop.cpp: markOopDesc::print_on() Here's the email thread: On 4/23/19 11:41 AM, coleen.phillimore@oracle.com wrote: > http://cr.openjdk.java.net/~dcubed/8153224-webrev/4-for-jdk13.8222295/src/hotspot/share/oops/markOop.cpp.frames.html > > 37 if (mon == NULL) { > 38 st->print("NULL (this should never be seen!)"); > 39 } else { > 40 st->print("{contentions=0x%08x,waiters=0x%08x" > 41 ",recursions=" INTPTR_FORMAT ",owner=" INTPTR_FORMAT "}", > 42 mon->contentions(), mon->waiters(), mon->recursions(), > 43 p2i(mon->owner())); > 44 } > > > Following convention, it seems like this code should be in ObjectMonitor::print_on(outputStream* st) so markOop doesn't have to know objectMonitor fields/accessors. That's a really interesting point... When you take a look at the whole of the markOopDesc::print_on() function, it is trying to give _some_ visibility into the interpretation of the various things that we have encoded into the mark oop word/header. For example, if the mark "is locked", it has this code: 45 } else if (is_locked()) { 46 st->print(" locked(" INTPTR_FORMAT ")->", value()); 47 if (is_neutral()) { 48 st->print("is_neutral"); 49 if (has_no_hash()) { 50 st->print(" no_hash"); 51 } else { 52 st->print(" hash=" INTPTR_FORMAT, hash()); 53 } 54 st->print(" age=%d", age()); 55 } else if (has_bias_pattern()) { 56 st->print("is_biased"); 57 JavaThread* jt = biased_locker(); 58 st->print(" biased_locker=" INTPTR_FORMAT, p2i(jt)); 59 } else { 60 st->print("??"); 61 } and if the mark "is unlocked", it has this code: 62 } else { 63 assert(is_unlocked() || has_bias_pattern(), "just checking"); 64 st->print("mark("); 65 if (has_bias_pattern()) st->print("biased,"); 66 st->print("hash " INTPTR_FORMAT ",", hash()); 67 st->print("age %d)", age()); 68 } So I understand the reasons for the limited peek into the ObjectMonitor for the mark "has monitor" case since we do that limited level of detail for the other interpretations of the mark oop header. Summary: I'm not planning on changing that for this bug. However, now that I've pasted these code snippets, I think I see some confusion here. The mark "is locked" and mark "is unlocked" branches both have code for biased locking. That seems strange to me, but that should be looked at separately. > Otherwise looks like a good self-contained cleanup to me. Thanks! You'll see some of your other requested changes in the review thread for JDK-8153224 (CR1/v2.01/4-for-jdk13). Dan > > Coleen
|