4837564: (bf) Please make DirectByteBuffer performance enhancements

[Chris Hegarty]

Seems fine, some minor comments:

// The "-XX:+PageAlignDirectMemory" option can be used to force
// *buffer*, allocated by ByteBuffer.allocateDirect, to be page aligned.

typo? buffer -> buffers


Could we cache the value of VM.isDirectMemoryPageAligned() as a private 
static final rather than always invoking isDirectMemoryPageAligned from 
the constructor? Dito for Bits.pageSize? Or is it possible for these 
classes to be loaded before these values are initialized?

Also, is there an issue with the publication of pageAlignDirectMemory? I 
can't see that it is every referenced within a sync block or from a 
volatile.

int size = Math.max(1, cap + (pa ? ps : 0));
Are you concerned with overflow when page alignment is on? I'm just 
trying to understand what this is for, and what will happen if 
<init>(Integer.MAX_VALUE - 1)

-Chris.


Alan Bateman wrote:
> 
> A long standing gripe for many is that direct buffers are page aligned 
> with the result that the memory usage can be significantly higher than 
> expected. We've never documented the alignment and I'm not aware of 
> anyone that depends on it (if you do then speak up now!).  The patches 
> here change the implementation so these buffers aren't page aligned by 
> default. A new VM option is introduced to force page alignment if  
> really needed. Mapped buffers will of course continue to be page aligned.
> 
> A related issue is that the addition of the management interface for 
> buffer pools subtly changed the semantics of the MaxDirectMemorySize 
> option. That option used to set a limit on the total capacity of all 
> direct buffers, whereas now it limits the total memory size. This is bug 
> 6743526, and the webrev includes the changes to restore the original 
> semantics (which is course is only interesting when these buffers are 
> page aligned).
> 
> The webrev with the changes is here. I'm only looking for a reviewer for 
> the changes to the jdk repo as I will be going to hotspot-runtime-dev 
> for the hotspot change.
>  http://cr.openjdk.java.net/~alanb/4837564/
> 
> Thanks,
> Alan.