HotSpot Bashing (was RE: [spinnaker] Announce)

[Eric Hodges <ha...@swbell.net>]

> -----Original Message-----
> From: James Duncan Davidson [mailto:james.davidson@eng.sun.com]
> Sent: Monday, July 10, 2000 4:33 PM
> To: general@xml.apache.org
> Subject: Re: [spinnaker] Announce
>
>
> on 7/10/00 1:44 PM, Eric Hodges at harmony2@swbell.net wrote:
>
> > It's as if Sun thought we wouldn't use Java for the first 5
> years.  Now they
> > want a do-over.  Sun can't expect the world to re-write all
> code for each
> > new release of the VM.  One of the selling points of Java is
> that code won't
> > have to be constantly re-written.
>
> What you are asking for is that Sun would have kept Java inside
> for another
> 5 years to make it perfect. That would have been the right answer.

That isn't what I'm asking for.

>
> > Why can't HotSpot figure out that it's slowing down execution
> and put itself
> > into -classic mode for specific classes?
>
> That's what it's doing.. Running the code it can't optimize interpreted,
> which is about as -classic as you can get.
>
> Note -- the code doesn't slow down, it just doesn't benifit.

But it *does* slow down.  HotSpot has to be able to optimize the code enough
to overcome its own overhead before you see gains.  It doesn't recognize
un-optimizable code quickly enough, and it doesn't save that information for
the next time the code is executed.

<snip>

>So, my argument is, when building a
> next gen parser, why take the pain of optimizing hellishly if it
> doesn't buy
> you something.

How do you know when you're building a next gen parser?  Wasn't Xerces a
next gen parser at some point?

If Sun releases a new VM while Spinnaker is still being developed, will you
go back and change the way it was written?

When do we get to write and use a current gen parser?

>
> Disclaimer -- there are some interesting cases in Xerces on
> Hotspot where it
> isn't this simple I believe -- but for the purposes of this mail which is
> bashing Hotspot on principle, the generalities are good enough.

I come to praise HotSpot, not to bash it.  Well, a little bashing.  HotSpot
is way cool.  I've seen the light.  I'm convinced that someday HotSpot or a
similar technology will prove that virtual machines can outperform real
machines for most useful computing tasks.  But HotSpot should take the
Hippocratic oath.  "First, do no harm."

> If you want a way to send some classes to Hotspot, and others to a
> traditional JITC, then you are asking for something that's way too complex
> and would never ship reasonably bug free.

No, I just want HotSpot to quickly learn that class X can't benefit from run
time optimizations and remeber that the next time I load class X.  I can
think of several schemes for doing this.  They don't seem too complex to me,
but I may be missing something.

Re: HotSpot Bashing (was RE: [spinnaker] Announce)

[James Duncan Davidson <ja...@eng.sun.com>]

on 7/10/00 3:17 PM, Eric Hodges at harmony2@swbell.net wrote:

>> What you are asking for is that Sun would have kept Java inside
>> for another
>> 5 years to make it perfect. That would have been the right answer.
> 
> That isn't what I'm asking for.

Maybe I was being a tad sarcastic for humor's sake. Of course it wasn't what
you were asking for. But there's been a lot of people who have asked "why
couldn't you get it right to start with". It's *hard*. Software development
is never as pretty as the marketing makes it out to be. Or even our best
hopes.

> How do you know when you're building a next gen parser?  Wasn't Xerces a
> next gen parser at some point?

Of course. Everything is NG at some point. Alll software goes through
genesis --> development --> stable --> maturing --> established.

> If Sun releases a new VM while Spinnaker is still being developed, will you
> go back and change the way it was written?

Hopefully writing simply will take care of things. I don't really want to
see much in the way of Hotspot optimizations either though. I believe that
code clarity is first and formost. If you lose 10% perf, 20% perf, then I
can live with that.

But if in 2 years we ended up with a new VM coming out which the NG parser
couldn't live with, then I'd probably look at redoing again.

> When do we get to write and use a current gen parser?

You've got one right now. Crimson is pretty close to being a parser that
works *really* well on Hotspot. It however isn't as featured as Xerces.
Also, I didn't want to waltz in and propose doing a lot of work on Crimson
as I felt that you'd all attack me for starting a Sun vs. IBM war. In
retrospect though.. :)

> I come to praise HotSpot, not to bash it.  Well, a little bashing.  HotSpot
> is way cool.  I've seen the light.  I'm convinced that someday HotSpot or a
> similar technology will prove that virtual machines can outperform real
> machines for most useful computing tasks.  But HotSpot should take the
> Hippocratic oath.  "First, do no harm."

Note -- I've talked about as authoritatively for HotSpot as I can. I'm not a
HotSpot team member and to go any deeper is dangerous. I have asked that
somebody from the Hotspot team contribute... But... I do contribute from the
standpoint of somebody who wrote a hellish amount of optimized code for 1.1,
and then watched as Hotspot hated it (over 2 years ago in early HotSpot
days), worked with the HotSpot team on it, and was convinced by argument
that premature optimization was the root of all evil. I just wish I could
remember the arguments. :)

> No, I just want HotSpot to quickly learn that class X can't benefit from run
> time optimizations and remeber that the next time I load class X.  I can
> think of several schemes for doing this.  They don't seem too complex to me,
> but I may be missing something.

It would be interesting to hear the results of this. I've wondered myself
why there wasn't a cache of tweaked code held away for inter-run storage.

.duncan

Re: HotSpot Bashing (was RE: [spinnaker] Announce)

[co...@eng.sun.com]

> How do you know when you're building a next gen parser?  Wasn't Xerces a
> next gen parser at some point?
> 
> If Sun releases a new VM while Spinnaker is still being developed, will you
> go back and change the way it was written?


You are right, HotSpot is not the last or only VM, and we want to be able
to optimize for JDK1.1, HotSpot, or any other VM - or not optimize at
all. This is not possible in xerces, which has JDK1.1 optimizations and
nothing else.

Having HotSpot detect JDK1.1 optimizations is not a solution, we need to
use JDK1.1 optimizations in JDK1.1 and normal ( unoptimized ) code in
HotSpot ( or even Hot-Spot optimized code for hotspot and jit optimized
code when a JIT is used ). 

This will also help a lot with the code clarity: 
  try {
    fgTempBuffer[outOffset] = (char)ch;
    outOffset++;
  } catch (NullPointerException ex) {
    fgTempBuffer = new char[CHUNK_SIZE];
    fgTempBuffer[outOffset++] = (char)ch;
  } catch (ArrayIndexOutOfBoundsException ex) {
     char[] newBuffer = new char[outOffset * 2];
     System.arraycopy(fgTempBuffer, 0, newBuffer, 0, outOffset);
     fgTempBuffer = newBuffer;
     fgTempBuffer[outOffset++] = (char)ch;
  }

Is equivalent with:
  
  if( fgTempBuffer == null ) 
       fgTempBuffer = new char[CHUNK_SIZE];
  if( outOffset == fgTempBuffer.length ) 
       realloc();
  fgTempBuffer[ outOffset ++ ] = ch;

The first piece can't be optimized by hotspot ( AFAIK ). It is a great
optimization for JDK1.1, and it should be used in 1.1 VMs.

This kind of code is used all over xerces, in all classes. I don't think
it's bad code, but you don't have to pay the price of 1.1 optimizations in
1.3 VMs ( even if HotSpot could detect it's 1.1).

Costin