Struct/value types + stack allocations

[David Holmes]

Getting somewhat OT for this list but the Real-Time Specification for 
Java's ScopedMemory started out from a basic desire to be able to do 
stack allocation. But it morphed into something immensely complex which 
didn't support stack allocation afterall (some implementations and 
derivations constrain its use in a way that allows stack allocation but 
it isn't part of the spec).

Unmanaged languages require the programmer to take full control of 
memory management. Managed languages go to the other extreme and have 
the GC take full control. There has always been a middle ground where 
knowledgeable programmers could assume some memory management 
responsibilities safely and efficiently. In a managed language like Java 
the platform would have to be able to enforce/verify the safety aspect 
eg. not allowing references to stack-allocated objects to escape.

Cheers,
David
-----

On 18/01/2012 2:00 PM, Vitaly Davidovich wrote:
> Hi David,
>
> Yeah, I completely appreciate how much work this would entail, but I do
> see some awesome work being done in the various areas of the JVM (and
> java the language) so thought I'd ask :).
>
> The reason I ask is because I think the achilles heal of java
> performance is the memory consumption (this is something you often hear
> in discussions about java performance).  Granted, some of this is
> probably poor data structure/data modeling choices, but I definitely
> think there's some truth to it.  For example, as I mentioned in my
> original email to hotspot-compiler-dev, there are a lot of
> utility/wrapper classes in the wild that are thin veneers over a
> primitive or two (e.g. Apache Commons HashCodeBuilder, EqualsBuilder).
>   People use these inside hashCode()/equals(), and then lo and behold,
> you start getting significant GC pressure when the # of instances goes
> up.  Another example of this is iterators -- they should be cheap but
> use them enough, across multiple cores, and you'll be doing young GC
> before long, with possibly premature promotion and such and then you're
> either removing these abstractions somehow, or tuning the GC algorithm.
>
> Now, escape analysis may eliminate these allocations, but that's still a
> bit of a black box and hard to count on for sure.  So then you're left
> with a choice of basically removing the wrapper and inlining the code or
> creating static helper methods.  It would be nice if these types of
> constructs could be modeled with a struct, stack allocated, still
> provides some abstraction, and very low cost (basically, CLR's struct).
>
> Additionally, there's a paper published recently about how to build
> memory efficient java applications:
> http://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf.
>   It's nothing revolutionary, but it is astounding, when you think about
> it, just how much space is wasted due to JVM object overhead and
> delegation/references (compressed oops help, but still).  It's
> unfortunate that there's no good way to model certain abstractions in a
> very lightweight manner without incurring GC penalty (write
> barriers/card marks on pointer refs, extra
> marking/copying/scanning/etc), cpu penalty (pointer chasing memory
> fetches instead of "inline" members), and other things of the sort.  RAM
> is cheap these days, but the cpu caches haven't grown that much, and
> cache lines are still in the 64 (and 128) bytes range.
>
> Anyway, it would be great to see something where these heap costs could
> be reduced explicitly (i.e. escape analysis is awesome, but explicit
> control is nice too).  But, I totally understand that it's a large
> undertaking, so feel free to ignore ... :)
>
> Thanks!
>
> On Tue, Jan 17, 2012 at 10:21 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Vitaly,
>
>
>     On 18/01/2012 10:09 AM, Vitaly Davidovich wrote:
>
>         I asked this question on hotspot-compiler dev mailing list (it
>         was tied
>         in with an escape analysis question) but Vladimir Kozlov
>         suggested I try
>         this group instead.  Copy/paste of my question:
>
>         Also, are there any plans to support struct/value-type like (ala
>         CLR's
>         struct) constructs in the JVM (presumably java can then target
>         it)? This
>         would allow developer to control where something gets allocated
>         without
>         relying on EA, and it would also reduce the amount of indirection in
>         object graphs (and the mem/cpu performance hit of them) since struct
>         members of a heap allocated object could be allocated "inline".
>
>
>     I would say that anything in this direction would have to be driven
>     by languages running on the JVM. In particular if Java doesn't
>     propose to add stack-allocation (it doesn't) then it seems unlikely
>     to me that the VM would add support for it. I'm pretty sure this
>     would require new bytecodes.
>
>     David
>
>
>         Thanks
>
>         Sent from my phone
>
>
>
>
> --
> Vitaly
> 617-548-7007 <tel:617-548-7007> (mobile)