RFR (XXS) 8008964 - Thread::_metadata_handles uses 1 KB per thread

[Coleen Phillimore]

Ioi,
Code looks good.   We can also reduce the HandleArea per thread now that 
metadata aren't oops.
I'll file a bug for that or have you already?

Thanks,
Coleen

On 6/19/2013 12:40 PM, Ioi Lam wrote:
> Please review a very small fix:
>
> http://cr.openjdk.java.net/~iklam/8008964/metadata_handles_001/
>
> Bug: NPG: Memory regression: Thread::_metadata_handles uses 1 KB per 
> thread.
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008964
>     https://jbs.oracle.com/bugs/browse/JDK-8008964
>
> Background:
>
>     Thread::_metadata_handles is a GrowableArray that keeps class 
> metadata
>     alive during class redefinitions. See metadataOnStackMark.cpp.
>
>     The initial allocation size is 300 elements per Thread. This seems 
> too big.
>
> Summary of fix:
>
>     I changed the initial allocation of 300 elements to 30 elements.
>
>     I added traces in a private build and found that the max array length
>     is usually around 100, and most of the threads never use more than
>     30 elements.
>
>     For Eclipse:
>
>         metadata_handles expanded from [  0] = 34 time(s) // a total 
> 34 threads have been created
>         metadata_handles expanded from [ 30] =  9 time(s)
>         metadata_handles expanded from [ 60] =  2 time(s)
>         _metadata_handles_max_len = 114
>
>     For MedRec:
>
>         metadata_handles expanded from [  0] = 156 time(s)
>         metadata_handles expanded from [ 30] =  19 time(s)
>         metadata_handles expanded from [ 60] =   4 time(s)
>         _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.
>
> Tests:
>
>     UTE (vm.runtime.testlist, vm.quick.testlist, 
> vm.parallel_class_loading.testlist)
>
> Thanks
> - Ioi
>