Struct/value types + stack allocations

[Vitaly Davidovich]

David,

I think if the VM allowed for structs which are copied by value then you
wouldn't have to worry about stack allocated objects escaping - it would
behave just like a primitive.  You would need to have generic boxing
ability for them but I don't think that's too difficult.  This is basically
how .NET's structs behave.  I think the CLR struck a nice balance between
managed/safe features yet allowing developer room for more control in
certain situations.  I realize that the CLR has just one os platform to
worry about (and as a result fewer CPU architectures) but it would be great
to have something similar in the JVM.  Wishful thinking pehaps ... :)

Thanks

Sent from my phone
On Jan 17, 2012 11:38 PM, "David Holmes" <david.holmes at oracle.com> wrote:

> 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<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 <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)
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120118/c4327089/attachment.html