JDK 7 Features.

[Paul Hohensee]

As you note, it's available in 6u14, and is also available in 6u6p, the 
current
performance release (for which see http://java.sun.com/performance).

It'll be on the feature list for 6u14, but it's off by default for now 
because while
it's pretty reliable, it's not yet reliable enough for us to turn make 
it the default.
It does get turned on when you use -XX:+AggressiveOpts though.

Scalar replacement is actually an optimization enabled by something called
Escape Analysis, which latter finds all the objects that are used only 
by the
thread that allocated them.  I.e., they don't 'escape' the thread that 
allocated
them.  Such objects are candidates for object explosion, which splits an
object up into its component fields and allocates them in registers (that's
what scalar replacement is) or on the thread stack (which we don't do yet
for various reasons, not least of which is that it's almost as fast to 
allocate
in the heap as on the thread stack, and that the thread stack is rather 
small).

You're right that scalar replacement has the potential to make some code 
much
faster, assuming there's enough registers available.  AggressiveOpts is our
catchall flag for performance features that will eventually become the 
default.
Scalar replacement (and escape analysis) are on the list.  Anyone want to
help us out? :)

Paul

Ismael Juma wrote:
> Hi all,
>
> I am happy to see an initial plan for JDK 7 that includes features,
> milestones and dates.
>
> Mark suggested in his blog entry[1], that follow-ups should be directed
> to this list. I suggest adding "Scalar replacement" as one of the new VM
> features. It's already available in JDK 6 Update 14, but not enabled by
> default (along with Compressed 64-bit object pointers and the G1
> collector). I believe it's a major new feature and it can have a
> substantial performance benefit[2].
>
> Best,
> Ismael
>
> [1] http://blogs.sun.com/mr/entry/jdk7
> [2]
> http://blog.juma.me.uk/2008/12/17/objects-with-no-allocation-overhead/
>
>