JDK-8199746 : NMT: Breakup overused mtInternal into more fine grained categories.
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 11
  • Priority: P4
  • Status: Resolved
  • Resolution: Other
  • Submitted: 2018-03-16
  • Updated: 2019-06-20
  • Resolved: 2019-02-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 13
13Resolved
Related Reports
Relates :  
Sub Tasks
JDK-8219244 :  
JDK-8219370 :  
JDK-8219392 :  
Description
From Coleen's comment:

Yay, a quick code review.  Is there a better mt tag than mtInternal though?  There are too many mtInternal allocations.  Can you add mtSafepoint or mtSynchronize (or better name?) and we could have an RFE to make some of these into the same:

share/runtime/semaphore.hpp:class Semaphore : public CHeapObj<mtInternal> {
share/runtime/mutex.hpp:class Monitor : public CHeapObj<mtInternal> {
share/runtime/objectMonitor.cpp:  return AllocateHeap(size, mtInternal);
share/runtime/objectMonitor.cpp:  char * knobs = (char *) os::malloc(sz + 2, mtInternal);
share/runtime/monitorChunk.cpp:  _monitors           = NEW_C_HEAP_ARRAY(BasicObjectLock, number_on_monitors, mtInternal);

Or even mtOS so we can move some of the os allocations to this category?

Why is nothing simple?!

Comments
Since this is an umbrella bug, I'm resolving it as "Other".
22-02-2019

Only bugs associated with changesets should be closed as "Fixed".
22-02-2019