RFR (S) 8016903 - Thread::_handle_area initial size too big

David Holmes david.holmes at oracle.com
Sun Jul 7 18:31:48 PDT 2013


Hi Ioi,

On 6/07/2013 12:54 AM, Ioi Lam wrote:
> |Please review a small fix:||

This is may not be so small! You haven't just changed the size of the 
_handle_area but have added a new Chunk pool. So if there are other 
allocation sites that were using "tiny" values these will now use the 
new Tiny pool. If there are no such uses then fine. Have you determined 
if any other allocation sites will use the new Tiny pool?

This comment will need fixing:

  239   // Our three static pools

as there are four pools now.

Thanks,
David

> ||
> ||http://cr.openjdk.java.net/~iklam/8016903/reduce_handle_area_002/||
> ||
> ||Bug: Thread::_handle_area initial size too big||
> ||
> ||http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016903||
> ||https://jbs.oracle.com/bugs/browse/JDK-8016903||
> ||
> ||Summary of fix:||
> ||
> ||    I have reduced the Thread::_handle_area from 1KB to 256 bytes
> (which can now ||
> ||    hold 27 handles on 64-bit VM before we need to allocate an extra
> chunk).||
> ||
> ||    Traces in Eclipse start-up showed that about 1.5% of calls to
> HandleMark::~HandleMark()||
> ||    would pop an extra chunk.||
> ||
> ||    I ran refworkload and there are no significant performance
> differences.||
> ||
> ||Tests:||
> ||
> ||    JPRT||
> ||    UTE (vm.runtime.testlist, vm.quick.testlist,
> vm.parallel_class_loading.testlist)||
> ||    refworkload||
> ||
> ||Thanks||
> ||- Ioi||
> ||
> |


More information about the hotspot-runtime-dev mailing list