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

[David Holmes]

On 8/07/2013 4:40 PM, Ioi Lam wrote:
> David,
>
> I searched for these:
>
> [1] subclasses of Arena (only 2 classes: HandleArea and ResourceArea,
> from the output ofgcc -fdump-class-hierarchy).
>
> [2] All source code lines that matchthese patterns
>      new.*Arena
>      new.*HandleArea
>      new.*ResourceArea
>      new.*Chunk
> Arena[ \t]*[(].+[)]
>
> and I can't find anything that would use a size that would exactly match
> the newly added Chunk::tiny_size. So I think nothing else would use the
> new tiny Chunk pool.

Ok - thanks for verifying. (I assume it wouldn't need to exactly match 
but simple be <= ? )

> (And even if such allocation sites had existed, what harm would have
> been caused?)

Not necessarily any "harm" but it could have changed allocation 
behaviour in a way that might have had unanticipated side-effects. I'm 
not clear on how these chunks are used in detail so it may be that it 
would have no affect other than potentially reducing other wasted chunk 
space. Or maybe it would introduce additional fragmentation. Or ...

Cheers,
David

> I'll fix the comment as you suggested.
>
> Thanks
> - Ioi
>
> On 07/07/2013 06:31 PM, David Holmes wrote:
>> 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||
>>> ||
>>> |
>