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

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