[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.


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