xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Hodges <harmo...@swbell.net>
Subject HotSpot Bashing (was RE: [spinnaker] Announce)
Date Mon, 10 Jul 2000 22:17:00 GMT

> -----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.


>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.

View raw message