[9] RFR(M): 8029799: vm/mlvm/anonloader/stress/oome prints warning: CodeHeap: # of free blocks > 10000

[David Chase]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140214/629a75be/signature.asc