Java shared memory

Vladimir Ivanov vladimir.x.ivanov at
Tue May 31 11:31:27 UTC 2016


Unfortunately, I don't see any source file changes in the project you 

It seems your project can be split into 2 independent parts:
   (1) accessing off-heap memory;
   (2) representing off-heap region as primitive array.

As I understand, it should cover all use cases you mentioned.

Off-heap memory access is already supported by NIO (MappedByteBuffer & 
DirectByteBuffer). In Java 9 VarHandles will provide int[]/long[]/... 
views over ByteBuffers (see MethodHandles.byteBufferViewVarHandle [1]) 
with impressive performance characteristics.

Forward compatibility aspect (represent off-heap region as 
byte[]/int[]/... instance) fits perfectly into Arrays 2.0 project (see 
John's presentation at JVMLS 2012 for more details [2]). As Paul already 
mentioned, David Simms has been working on j.l.Arrayish [2] support and 
made impressive progress (the idea is the JVM can link *aload/*astore 
bytecode instructions to methods on Arrayish interface).

Have you had a chance to look into ByteBuffers/Varhandles & 
j.l.Arrayish? It would be very interesting to hear about your experience.

Best regards,
Vladimir Ivanov




On 5/30/16 9:48 PM, Radek wrote:
> Dear all,
> Please don’t think I’m so crazy. Recently I was working on JVM changes to add shared memory / memory mapping support.
> I’m able to map part of files as primitive java arrays. First performance results are very optimistic (40% boost in searching min-max long in 1GB file) with mapped long[] as a replacement to LongBuffer. The work is not finished. I have adopted G1, c1 and c2, but I have got mainly stable solution (or I think so).
> I see three possible benefits of shared memory:
> 1. Shared memory and interprocess communication.
> 2. Mapping large files.
> 3. Aggressive inter-JVM string de-duplication.
> I’m looking for sponsorship for this change, with some guidelines how I can move forward with possible adoption into JDK. If solution would be viable, I would like to open JSR for JDK API modification.
> I use as umbrella repo, but I don’t update it quite often.
> Thanks in advance,
> Radek

More information about the valhalla-dev mailing list