Packed object in Java

[Kevin Burton]

http://medianetwork.oracle.com/video/player/2623645005001

[Richard Warburton]

Hi,

http://medianetwork.oracle.com/video/player/2623645005001

At the LJC we tried out the Packed Objects prototype that they've put out in the IBM J9 builds.  Its a little early in its development to fairly judge the direction they were going in since there were some bugs.  My preliminary conclusions were:

 * People had very little issue with the idea of objects without identity: suggesting that developers would be happy with some kind of structs on the JVM.

 * There were potential issues around both pointer chasing and GC with the proxy objects that get generated if you dereference a PackedObject.

 * There was no support for concurrency primitives such as atomic operations or compare and swap.  At the time it was pointed out that some of these features could be addressed by effectively exposing a Fences API.

 * I also found it hard to understand the exact layout of the objects in memory, since there were certain situations where they could back off into being a kind of Mixed Object.  For all of the added complexity of Unsafe layout is quite clear.

Martin Thompson was also there, so he's probably in a good position to comment on the prototype as well.

regards,

  Dr. Richard Warburton

  http://insightfullogic.com

  @RichardWarburto

[Kirk Pepperdine]

My views on the IBM J9 packed object implementation is I'm not sure that this is the right approach to the problem.

-- Kirk

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Jaromir Hamala]

What is your definition of the problem? I'm genuinely interested as I see it as an attempt to solve multiple different problems(off-heap data inside a single JVM + passing data between JVM and another process)

Cheers,

Jaromir

--
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
Antoine de Saint Exupéry

[Kirk Pepperdine]

I don't know but I feel that this sudden need to move to off-heap memory is either an admission that GC has failed or people don't get how to tune it. I don't except either to be true and thus I really feel that off-heap memory is a fad that will/can potentially destabilize JVMs. The biggest value of a JVM is that it is stable.. take that away and....

Regards,

Kirk

[Martin Thompson]

From what I've seen we have 3 major needs that can possibly be addressed by various PackedObject, ObjectLayout, or Value Objects proposals

1. GC is one issue that can be ameliorated by this proposals but is not a driving force. 
   
2. Memory Layout is for me the most important feature missing in the JVM for large datasets. We experience far too many cache misses given how Java lays out graphs of objects.  I want to have better tables, hashmap, b* trees, etc. To ignore memory layout given current hardware, and future trends, would just be naive.
   
3. Interop with off-help data sources. For example it costs far too much copying data for GGPUs, data stores, TP systems, IPC, etc. structure layout that is accessible across the heap boundary greatly simplifies JNI and improves performance. C# has taken care of this long ago with Java looking tired by comparison.

I'm hoping that by working with both Azul and IBM I can get some progress on issues 2 and 3 particularly.  I think the ideal solution will come from these groups learning from each other and proposing something informed.

Regards,

Martin...

Jaromir

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
Antoine de Saint Exupéry

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Peter Lawrey]

While I am a fan of off heap memory, I do feel it is a solution of last resort.  It should be the option you take only when you have tried everything else and you have proven to yourself that there is a compelling reason to use off heap.

If you do use off heap, you should expect to wrap it up in a well tested library and hide the off heap-ness from the rest of your Java code.  You should also consider you will need an order magnitude more testing to be confident in such a solution.

Using off heap from Java can be a better alternative to using JNI to do the same thing. IMHO, If you can do much the same thing on heap, even if its a bit slower, you should stick to "natural" Java.

Regards,

   Peter.

[Gil Tene]

Off-heap is a very valid and very necessary thing to do when sharing binary data with non-Java code. E.g. this often comes up in the context of high performance shared memory transports and direct hardware interactions (e.g. frame buffers, variations of kernel-bypass network stacks, etc.). I see Packed Objects as a good potential step forward on this context, especially when you compare it with the the roll-your-own thing everybody tends to deal with today in these very valid use cases. 

But outside of directly sharing state with non-Java players, and outside of dealing with state that has prescribed binary layouts and must be interacted with without transformation, I think of off-heap as being "off-Java". A necessary evil for some, and an unnecessary folly for most.

As Peter notes, there are valid, necessary, and very current last-resort uses for off heap state. I'm certainly not trying to say people doing this are wrong or lack something in the IQ department. It's quite the opposite actually: people able to actually use off heap state well tend to be very very smart. That's probably the best indication of how problematic it is.

The key issue is that every time you choose to use off heap state you also choose to leave the entire Java echosystem behind and rely on a very limited set of code and capabilities that can manipulate and interact with the state stored off heap. You can write it all yourself, of course, and you can do it in the Java syntax as long as you don't use reference fields. You can even use some of the small sets of libraries out there that deal with off heap state as long as you follow their rules and don't stray. But it ain't Java. It's not the Java other people know how to read and write. And it's not the Java that all the core libraries and the hyper-multitude of leverage-able non-core Java stuff out there know how to interact with. There are no POJOs off heap and [by definition] there never will be. And with that statement goes all practical use of java.util.* and any other code you might want to pass your data to, store it in, track it, or manipulate it with if it stored off heap.

Caveat inventor

Jaromir

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
Antoine de Saint Exupéry

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Rüdiger Möller]

For infrastructure libraries there is no alternative IMO.

I have implemented a struct emulation (http://code.google.com/p/fast-serialization/wiki/StructsIntroduction) and I am currently (re-)implementing a high performance messaging based on it, and found it pretty convenient to use (though I had some VM crashes along the way).

Having a convenient way to access packed structures let's me 

 * send up to ~4GByte / second through localhost socket/shared mem queue/ tcp over infiniband

 * do up to 8 million (reliable) remote calls per second (single-topic incl. method dispatch)

 * nearby allocationf free

This would be impossible using standard java. For basic infrastructure libraries this is very useful as it exactly profits from the 3 points martin mentioned above

 * very low Full GC cost, only ~1000 objects allocated (even with >1GB of message buffers). A messaging layer should be mostly GC-neutral.

 * very fast filtering of messages as no decoding is required to access partial data of a message

 * high locality for fast processing of retransmission requests and packet/message filtering

 * easy to read from non-java code

The "beauty" of the dedicated structs approach is, that it addresses several issues at once (IPC, GC, performance). While other approaches excel in a single area (e.g.locality), structs catch several things at once.

On the other hand i agree this won't be a main stream tool to represent ordinary business data as the notion of 'pointer' and objects-which-aren't-objects will mess up any multi-person project in a few weeks. However it comes in handy in the 5% of performance/throughput/latency critical code and will work there well encapsulated without any problem.

One can see it as a tool to avoid C/C++ mix ins in many cases, not as a common "language extension". After all the code stays somewhat maintainable and readable, it's not that ugly as direct getInt/putInt stuff frequently used.

 

Am Montag, 9. September 2013 04:04:12 UTC+2 schrieb Kevin Burton:

http://medianetwork.oracle.com/video/player/2623645005001