Java ready for number crunching? - Java

Mark Thornton wrote:
> Unfortunately the use of == for object identity makes it difficult to
> invisibly convert real objects to 'values'. Objects which don't escape
> can be held on the stack, but it is harder to merge objects into others.
> The fact that reflection can see private fields means that it isn't
> possible to just ****yse the visible java code and verify that the field
> is never exposed.
>
> As far as I can see, with the current language specification, HotSpot
> can't safely do this type of optimisation.

Hotspot wouldn't optimize portions of the code that contained idioms that
forced a heap allocation, but in blocks that don't do the sorts of things you
mention is most certainly could.

Remember that Hotspot is dynamic, and will de-optimize code at need as runtime
conditions vary. So an object reference might be optimized to register values
in one method but not in another, even though it be the same object.

If Java were limited to static ****ysis your objections would carry more weight.

--
Lew

Tom Anderson wrote:
> On Thu, 22 May 2008, Kenneth P. Turvey wrote:
>
>> I was thinking about this thread a bit and what kind of improvements
>> could be made to Java to handle math better and one that hadn't been
>> mentioned yet, that I would very much like to see in Java, is the
>> ability to handle objects without references.
>
> As Lew said, this is something you should leave to the compiler; it's
> something it can often do if a class is final, and only has final
> fields. Introducing explicit pass-objects-by-value, as in C, leads to a
> huge mess of extra complexity.
>
> However, there are some fairly unobstrusive changes that could be made
> to the language that would make it much easier for the compiler to do
> its magic. The key stumbling block is, i believe, object identity: if a
> compiler can't prove that an object will never be subjected to an
> identity test (==) which might succeed, it can't inline/unbox it. I

Which compiler, javac or Hotspot?

Hotspot most certainly can determine whether an object is subject to an ==
comparison. It doesn't need to determine that it never is subject to it, only
that it's not subject to it for a while.

--
Lew

On Thu, 22 May 2008 20:42:26 -0400, Lew wrote:

> Which compiler, javac or Hotspot?
>
> Hotspot most certainly can determine whether an object is subject to an
> == comparison. It doesn't need to determine that it never is subject to
> it, only that it's not subject to it for a while.

I must admit that I find this assurance unconvincing. Recently there was
a thread in which boxed and unboxed performance of integer math was
compared (this thread?). Anyway, if the compiler were really smart there
wouldn't be any difference in performance for most of the tests we might
run on these. The compiler would just substitute an unboxed int for the
Integer object we specified and all would be happy.

The fact that the compiler can't see this simple optimization leads me to
believe that relying on the compiler to make these kinds of
optimizations, just isn't reliable yet.

I used to program in Lisp quite a bit. I loved the language. There were
some serious drawbacks to using it though that were mostly solved by
using Java instead. One of the problems with Lisp was that essentially
every variable reference required going through a pointer. In Common
Lisp, type declaration was optional and didn't guarantee that type errors
would be detected. It was solely used to give the compiler hints on how
to optimize code. There were no guarantees it would work, but it made it
possible for the compiler to do some very complex type inference that
could lead to performance on par with C. The problem was that making
Lisp code perform as well as C code was very expensive in terms of
developer time. Usually it was much more expensive than simply rewriting
the code in C. Java is very similar in this regard. Java can perform as
well as C for most applications, but it certainly won't if the code is
developed in a way that would be natural for Java. Making it perform as
well as C is quite expensive and is often more expensive than simply
rewriting the code in the other language. This really eliminates Java
for many kinds of applications. It is too bad that things work out this
way, but it is the truth of the matter.

The language providing constructs that would allow those that really need
to get the most performance possible out of Java would be really nice,
but maybe it is best left to a new language, like Fortress. I must admit
that I'm skeptical that Fortress will be the language we are waiting
for. From what I've read about it, it just doesn't sound like what I
would want to program in. But then it isn't really anywhere near stable
yet, so who knows.


--
Kenneth P. Turvey <kt-usenet@squeakydolphin.com>

Lew wrote:
> Mark Thornton wrote:
>> Unfortunately the use of == for object identity makes it difficult to
>> invisibly convert real objects to 'values'. Objects which don't escape
>> can be held on the stack, but it is harder to merge objects into
>> others. The fact that reflection can see private fields means that
>> it isn't possible to just ****yse the visible java code and verify
>> that the field is never exposed.
>>
>> As far as I can see, with the current language specification, HotSpot
>> can't safely do this type of optimisation.
>
> Hotspot wouldn't optimize portions of the code that contained idioms
> that forced a heap allocation, but in blocks that don't do the sorts of
> things you mention is most certainly could.
>
> Remember that Hotspot is dynamic, and will de-optimize code at need as
> runtime conditions vary. So an object reference might be optimized to
> register values in one method but not in another, even though it be the
> same object.
>
> If Java were limited to static ****ysis your objections would carry more
> weight.
>

Dynamic code optimisation is one thing, but this would require dynamic
object layout changes. That is most unlikely in the foreseeable future.
It just isn't practical to back out merging an object into a parent
object. It is possible to do this for the stack because the allocation
has a well defined lifetime and you have located all references.

Mark Thornton

Mark Thornton wrote:
> Lew wrote:
>> Mark Thornton wrote:
>>> Unfortunately the use of == for object identity makes it difficult to
>>> invisibly convert real objects to 'values'. Objects which don't
>>> escape can be held on the stack, but it is harder to merge objects
>>> into others. The fact that reflection can see private fields means
>>> that it isn't possible to just ****yse the visible java code and
>>> verify that the field is never exposed.
>>>
>>> As far as I can see, with the current language specification, HotSpot
>>> can't safely do this type of optimisation.
>>
>> Hotspot wouldn't optimize portions of the code that contained idioms
>> that forced a heap allocation, but in blocks that don't do the sorts
>> of things you mention is most certainly could.
>>
>> Remember that Hotspot is dynamic, and will de-optimize code at need as
>> runtime conditions vary. So an object reference might be optimized to
>> register values in one method but not in another, even though it be
>> the same object.
>>
>> If Java were limited to static ****ysis your objections would carry
>> more weight.
>>
>
> Dynamic code optimisation is one thing, but this would require dynamic
> object layout changes. That is most unlikely in the foreseeable future.
> It just isn't practical to back out merging an object into a parent
> object. It is possible to do this for the stack because the allocation
> has a well defined lifetime and you have located all references.
>
> Mark Thornton

From John Rose (in a comment at
http://blogs.sun.com/jrose/entry/fixnums_in_the_vm)

"The key question is always the deoptimization cost. In this case, it
looks like a full GC could be required to reformat the affected
object(s). It's the Smalltalk "become" primitive, the nasty version
which can change an object's size and layout. I don't think I'm brave
enough to make these transformations automagically. Maybe they would be
justified in the presence of assurances from the user."

You might also look at the comment from Howard Lovatt to the same blog
entry. That refers to the language changes necessary to allow such
optimisations without any fear of having to later deoptimize them.

Mark Thornton

On Thu, 22 May 2008, Lew wrote:

> Tom Anderson wrote:
>> On Thu, 22 May 2008, Kenneth P. Turvey wrote:
>>
>>> I was thinking about this thread a bit and what kind of improvements could
>>> be made to Java to handle math better and one that hadn't been mentioned
>>> yet, that I would very much like to see in Java, is the ability to handle
>>> objects without references.
>>
>> As Lew said, this is something you should leave to the compiler; it's
>> something it can often do if a class is final, and only has final fields.
>> Introducing explicit pass-objects-by-value, as in C, leads to a huge mess
>> of extra complexity.
>>
>> However, there are some fairly unobstrusive changes that could be made to
>> the language that would make it much easier for the compiler to do its
>> magic. The key stumbling block is, i believe, object identity: if a
>> compiler can't prove that an object will never be subjected to an identity
>> test (==) which might succeed, it can't inline/unbox it. I
>
> Which compiler, javac or Hotspot?

Hotspot.

> Hotspot most certainly can determine whether an object is subject to an
> == comparison.

No. Not in all cases. In many useful cases, it can, and can then do
unboxing (provided the handful of other restrictions are met too), but
there will be cases where the escape ****ysis fails, and it just can't
decide whether it will get =='d.

> It doesn't need to determine that it never is subject to it, only that
> it's not subject to it for a while.

Wrong.

tom

--
You are in a twisty maze of directories, all alike. In front of you is
a broken pipe...

On Fri, 23 May 2008, Mark Thornton wrote:

>> Lew wrote:
>>> Mark Thornton wrote:
>>>
>>>> As far as I can see, with the current language specification, HotSpot
>>>> can't safely do this type of optimisation.
>>>
>>> If Java were limited to static ****ysis your objections would carry more
>>> weight.
>
> From John Rose (in a comment at
> http://blogs.sun.com/jrose/entry/fixnums_in_the_vm)
>
> "The key question is always the deoptimization cost. In this case, it
> looks like a full GC could be required to reformat the affected
> object(s). It's the Smalltalk "become" primitive, the nasty version
> which can change an object's size and layout. I don't think I'm brave
> enough to make these transformations automagically. Maybe they would be
> justified in the presence of assurances from the user."

Bingo.

> You might also look at the comment from Howard Lovatt to the same blog
> entry. That refers to the language changes necessary to allow such
> optimisations without any fear of having to later deoptimize them.

You mean the link to:

http://bugs.sun.com/bugdatabase/view...bug_id=4617197

? He covers all the important things, but also a lot of crazy ideas.

tom

--
You are in a twisty maze of directories, all alike. In front of you is
a broken pipe...

Kenneth P. Turvey wrote:
> I really don't think it would take much in terms of language changes to
> really make Java a good language for these applications. I don't know
> why Sun has decided not to target these applications.

For good and for worse: there is more money in a bank application
than in a simulator that will discover how the universe started.

Arne

Mark Thornton wrote:
> Unfortunately the use of == for object identity makes it difficult to
> invisibly convert real objects to 'values'. Objects which don't escape
> can be held on the stack, but it is harder to merge objects into others.

C# took a different approach from Java. And it seems to work
pretty well.

Arne