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.
We use a GrowableArray to keep track of Metadata on the stack. This is used to prevent Metadata from being deallocated.
This memory regression can be seen when running Jetty.
Comments
This fix can be validated by running jetty in refworkload.
21-08-2013
patch.diff -- Patch for getting stats for Thread::_metadata_handles growth.
18-06-2013
Statistics (generated with the attachment patch.diff)
For eclipse:
ioi: metadata_handles expanded from [ 0] = 34 time(s) // a total 34 threads have been created
ioi: metadata_handles expanded from [ 30] = 9 time(s)
ioi: metadata_handles expanded from [ 60] = 2 time(s)
ioi: _metadata_handles_max_len = 114
For MedRec:
ioi: metadata_handles expanded from [ 0] = 156 time(s)
ioi: metadata_handles expanded from [ 30] = 19 time(s)
ioi: metadata_handles expanded from [ 60] = 4 time(s)
ioi: _metadata_handles_max_len = 104
So it looks like we can safely reduce the initialize of Thread::_metadata_handles from 300 to 30, a saving of 2160 bytes per live Thread (64-bit VM) or 1080 bytes for 32-bit VM.
18-06-2013
For this bug ID I will fix only Thread::_metadata_handles.
To reduce the size of Thread::_handle_area, see JDK-8016903.
18-06-2013
The GrowableArray is for metadata handles, which used to be oop handles. The area in the thread for oop handles can be reduced because it's only a fraction as much (add some counters and run some standard test cases). The default size for the HandleArea per thread is the same as the default size of an Arena chunk which is 1KB. This could be a bit smaller. Outside of GC I don't see any reason to pass around or use raw oops so they should all be handled once when they get into the runtime or created. This shouldn't be so many. It would be good to see the minimum size we use on some standard benchmark or application.