escape analysis friendly very small objects

[Tobias Hartmann]

Hi Andy,

I think the problem you are explaining is really a use case for value types:
http://cr.openjdk.java.net/~jrose/values/shady-values.html

We are currently working on Minimal Value Types and have an early prototype available that you can try out:
http://mail.openjdk.java.net/pipermail/valhalla-dev/2017-August/003091.html

If you declare your classes as value types, C2 will keep the fields in registers or on the stack whenever possible 
(especially in case (1) that you described). We don't need to rely on escape analysis which, as Andrew mentioned, is 
very limited.

Case (2) is also solved by value types with flattening of value type fields into the holder class.

Best regards,
Tobias

On 05.09.2017 14:35, Andy Nuss wrote:
> I have a variety of classes which just contain a couple scalar primitives and possibly a reference to an object that is 
> clearly on the heap, all of these small number of data members are private and all of them mutable.  Much like the Point 
> class in Brian Goetz's article on escape analysis on whether the vm uses the stack or heap for class instances.
> 
> There are two use cases for these objects:  (1) create with new such a small object as a local variable and use it 
> thriughout the function, mutating it, etc.  (2) create a class with lots of these small objects as private or possibly 
> protected members.
> 
> The hope in the first case is under what conditions will hotspot put the object's 2 or 3 fields onto the stack and 
> ideally without the hidden headers needed to make it a heap object.  hashCode, equals, and clone are not implemented or 
> used if that is important.  I.e. will hotspot ever make it a simple C++ like object on the stack.  Does it help if I do 
> defensive copy if I return one of these small objects from the function?
> 
> In the second case, my hope is that for a class that contains 5 such small objects, and would definitely be on the heap, 
> hotspot would be smart enough not to create 5 small objects on the heap and then 5 references to them in the containing 
> class.  Instead, it would explode into the containing class ala C++ just the 2 or 3 primitive datamembers of the object, 
> and again, ideally without headers.