[9] RFR(M): 8029799: vm/mlvm/anonloader/stress/oome prints warning: CodeHeap: # of free blocks > 10000
Chris Plummer
chris.plummer at oracle.com
Sun Feb 16 22:40:08 PST 2014
Ok by me.
Chris
On 2/16/14 10:29 PM, Albert wrote:
> Chris, David, thanks for your comments.
>
> Is it OK for you if we come back to this later? I filed
> https://bugs.openjdk.java.net/browse/JDK-8034052
> which aims at optimizing code cache allocation details once we
> integrate segmented code cache.
> I've added your suggestions to the bug description.
>
> Best,
> Albert
>
>
> On 02/14/2014 09:05 PM, David Chase wrote:
>> On 2014-02-10, at 5:43 PM, Chris Plummer <chris.plummer at oracle.com>
>> wrote:
>>
>>> Hi Albert,
>>>
>>> Sorry I'm a bit late getting back to this. Thanks for the data. From
>>> this it looks like the larger CodeCacheSegmentSize is wasting some
>>> memory in the CodeBlob, but that is made up for not needing as large
>>> of a segmap. Sounds good to me.
>>>
>>> Regarding first fit vs best fit, my understanding is that the former
>>> is best when performance is critical and sizes vary greatly (typical
>>> C app with many mallocs). I think best fit is probably better for
>>> codecache usage since performance is less critical and the sizes
>>> don't vary so much. One thing you might want to consider is having a
>>> array of freelists for the smaller sizes so you can quickly index to
>>> the size you need (or the next size up that is big enough) and then
>>> have a general free list for the larger sizes.
>> I'm also late to this. There's plenty of work that's been done on
>> memory allocation for C, trading off speed and fragmentation. The
>> size-indexed freelist trick works pretty well; very good speed, and
>> consumption not that bad. That's what we used back in the days of
>> silly C benchmark wars. If you're willing to spend the time, it is
>> my recollection that "Cartesian Trees" are very good at space, but
>> not so good at speed.
>>
>> David
>>
>
More information about the hotspot-compiler-dev
mailing list