Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8013662 | 8 | Jiangli Zhou | P3 | Resolved | Fixed | b88 |
int _interpreter_invocation_count;
u2 _interpreter_throwout_count;
u2 _number_of_breakpoints;
InvocationCounter _invocation_counter;
InvocationCounter _backedge_counter;
#ifdef TIERED
float _rate;
jlong _prev_time;
#endif
Move those fields into a separate MethodCounters object referenced from Method. The counter object for a specific method can be allocated upon the first time when any of the fields is modified.
A separate data structer is used for the interpreter counters instead of adding the counters to MethodData, because the MethodData might not have the same life span as the interpreter counters. For example when TieredCompilation is not enabled, the MethodData is not allocated until the interpreter counter reaches InterpreterProfileLimit. Allocating the MethodData early would waste memory for non-hot methods which only execute a few times. Also the MethodData is only allocated when ProfileInterpreter is enabled, which is the default case for c2 but not for c1. Under TieredCompilation, there are cases where MethodData exist but the interpreter counters are never accessed.
- backported by
-
JDK-8013662 The Method counter fields used for profiling can be allocated lazily
- Resolved
- relates to
-
JDK-8194859 Bad backport of 8024468 breaks Zero build due to lack of 8010862 in OpenJDK 7
- Resolved
-
JDK-8013129 Possible deadlock with Metaspace locks due to mixed usage of safepoint aware and non-safepoint aware locking
- Closed
-
JDK-8068627 Change _constMethod and _method_counters in hotspot Method class from pointers to 32-bit values
- Closed
-
JDK-8013168 extend the set of code pointers from Method to support multiple architectures
- Closed
-
JDK-8013169 consolidate MethodData and MethodCounters pointers in Method struct
- Closed
-
JDK-8013036 vm/runtime/simpleThresholdPolicy.cpp: assert(mcs != NULL)
- Closed