JDK-8008962 : NPG: Memory regression: One extra Monitor per ConstantPool
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-02-26
  • Updated: 2014-06-26
  • Resolved: 2013-04-26
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 8 Other
8Fixed hs25Fixed
Related Reports
Relates :  
JDK-8026977 - NPG: Remove ConstantPool::lock
Relates :  
JDK-8001590 - NPG: Footprint increase when running Jetty
Description
With the PermGen removal, the ConstantPool stopped being a Java object. They still need to be locked, so we added a Monitor to each ConstantPool.

This shows up as a memory regression when running Jetty.
Comments
Thanks, Ioi.
21-10-2013
Ioi fixed the bug 8026977 report to have the deferral request and NPG in the title and it's linked to this bug. So I think it will be tracked properly.
21-10-2013
No. The 8026977 RFE is too risky for this stage in a release. Correctness and stability win over performance and memory usage.
21-10-2013
This changeset needs to be reverted to avoid deadlock (JDK-8014910) To address the memory regression, a new bug is created: JDK-8026977.
21-10-2013
This is a pretty big increase to metadata size.
28-02-2013
We lock the constant pool to record resolution information mostly for classes. The tag and the klass has to be updated in the right order, but I don't know why this is special and needs a lock where other fields don't. We also lock the constant pool to look up previous resolution errors, but we use the SystemDictionary_lock on the resolution error table too. There's a place in ci/ciEnv.cpp that locks the constant pool with the comment: // We have to lock the cpool to keep the oop from being resolved // while we are accessing it. There's another place for MethodHandles (jsr292) that tells of a data race updating the method in the cpCache. There are several fields that must be updated together at the same time. It may still be possible to change these to be lock-free with ordering dependencies, but it would have to be done carefully. The other thing is that this Monitor should be a Mutex. I didn't see a wait/notify. Mutex's are the same sizes as monitors. One thing that takes up a lot of space in the Monitor is that there's a 64 character array for the name, which for our case is a waste of space. If there was a superclass of monitor without the name, that would save a lot of space for all the classes loaded. Or we could keep InstanceKlass::init_lock() around and use that instead to lock the constant pool. There are several things we should investigate to resolve this bug. The extra memory consumption is a bug we should worry about.
28-02-2013
I'm not suggesting a solution, only reporting the regression. We now use 152 bytes extra (sizeof(Monitor)) per ConstantPool. I think this is enough to have a bug tracking this regression.
27-02-2013
What actions require the constant-pool to be locked? Is it only instrumentation/redefineClasses ?
27-02-2013
Not clear what the bug is? Are you suggesting a different approach to locking the constant pool? What would that be? Would that be an RFE?
26-02-2013