Struct/value types + stack allocations

[Vitaly Davidovich]

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