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

[Ioi Lam]

On 07/07/2013 11:51 PM, David Holmes wrote:
> 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 <= ? )
>

It needs to be exact match, or else malloc would be used.

|void* Chunk::operator new(size_t requested_size, size_t length) {||
||  ...||
||  switch (length) {||
||   case Chunk::size:        return 
ChunkPool::large_pool()->allocate(bytes);||
||   case Chunk::medium_size: return 
ChunkPool::medium_pool()->allocate(bytes);||
||   case Chunk::init_size:   return 
ChunkPool::small_pool()->allocate(bytes);||
||   case Chunk::tiny_size:   return 
ChunkPool::tiny_pool()->allocate(bytes);||
||   default: {||
||     void *p =  os::malloc(bytes, mtChunk, CALLER_PC);||
|
- Ioi

>> (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||
>>>> ||
>>>> |
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130708/750105bc/attachment.html