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