Request for review: 7150058: Allocate symbols from null boot loader to an arena for NMT
coleen.phillimore at oracle.com
Thu Mar 8 15:22:25 PST 2012
On 3/8/2012 5:37 PM, David Holmes wrote:
> Hi Coleen,
> On 9/03/2012 1:55 AM, Coleen Phillimore wrote:
>> Please review this change to allocate symbols from the boot class loader
>> into a global arena. This change reduces reporting traffic at startup
>> for the native memory tracking project in development. It is also useful
>> for class data sharing in the permgen elimination project, also in
>> development. I had to increase the SharedMiscSize because ResourceObj in
>> debug mode is 2 extra pointers.
>> open webrev at http://cr.openjdk.java.net/~coleenp/symbol-arena
>> bug link at http://bugs.sun.com/view_bug.do?bug_id=7150058
> The reasoning behind this might be a bit clearer if people knew that
> the permgen removal uses per-class-loader arenas, which is why the
> classloader has to be passed through everywhere - right?
For permgen removal class data sharing (CDS) work, when dumping the
shared archive in DumpSharedSpaces, I plan to allocate all symbols in a
read-only mmap space directly, along with the other metadata that is
read only. The read-write metadata will be directly allocated in
another mmap space. If allocated directly to the shared spaces, which
are then dumped, we don't have to move the metadata and relocate the
pointers, which greatly simplified CDS. So this code is useful for that.
The other motivators for this code is two things. One is for native
memory tracking, which tracks individual CHeapObj allocations.
Allocating symbols during startup and class loading creates native
memory tracking records for each one. Reporting the symbols as a
region is much less noisy. The other motivator is that with individual
mallocs, these symbols have malloc headers and would use more memory
overall, although I wasn't able to measure any improvements.
> It seems kind of odd to push this through stand-alone.
More information about the hotspot-runtime-dev