Speakers Todd Turnidge (turnidge) and Bill Pataky (Bill.Pataky)
Moderator Edward Ort (MDR-edort)
This is a moderated forum.
MDR-edort: Welcome to Java Live!
Today's guests are Todd Turnidge and Bill Pataky,
members of Sun's HotSpotTM
team. They'll answer your questions about the Java HotSpot
Performance Engine. It's a little before the hour, but
people are already joining the session. So let's begin.
Who has the first question?
David: Hi, can you give few samples of HotSpot Engine?
MDR-edort: David, can you be a bit more specific?
David: Do HotJava and HotSpot E. have same meaning?
Bill.Pataky: Here's an overview of HotSpot since
there seems to be some confusion. The Java
HotSpotTM performance engine
is Sun's next-generation Java1
Virtual Machine technology which compiles only performance critical
code. HotSpot 1.0 and 1.0.1 have been shipped and are available for
download on the web at
http://java.sun.com/products/hotspot .
HotSpot 1.0 delivers the highest server-side performance.
We've developed a client version of HotSpot which is part of the
JavaTM 2 SDK version 1.3. That's
now in beta (again available for free). You'll see dramatically
improved interactive performance, faster startup and smaller memory footprint.
turnidge: David, although their names are similar,
they are unrelated. HotSpot is the name for our latest new VM technology.
Okidoky: I'd imagine an ideal VM would
compile extremely close to machine language and cache the compiled
code to disk, so that next time it won't have to compile. And it
would use self-modifying code to handle sub-routine calls.
Spiff: Integer performance on the HS
shipped with 1.3b1 is much better than before, but floating point
performance is still lacking. I have some simple benchmarks that
show the 1.2.2 jit (-classic) to be twice as fast at floating point
than HotSpot on 1.3b1. Is this problem being worked on?
turnidge: Okidoky, we currently
do not cache our compiled code. If we did we would have to verify
the cached code, which would take quite a bit of time anyway. We
work hard on getting our compile times fast to reduce the overhead
from compilation. Our generated code is not self-modifying.
Bill.Pataky: In response to spliff, Floating point
performance is indeed something we're working on for the future releases.
Okidoky: I didn't see any performance
increase in the first HotSpot release at
all. Is the HotSpot VM in JDK1.3beta better than the 1st hotspot?
Mike Schrag: Are there more enhancements
planned for the final release that haven't made it into the beta?
How about HotSpot plans beyond this version?
Bill.Pataky: response to Okidoky Be careful you're
not comparing apples and oranges. HotSpot 1.0 and 1.0.1 are server-side
solutions. The Java 2 SDK 1.3 has the client side solution, and
emphasizes smaller memory footprint, faster interactive performance
and faster startup.
Spiff: I've noticed that the symantec JIT
is not included in 1.3b1. Will it be included in the final 1.3 release?
Bill.Pataky: response to spiff We will not be shipping
the Symantec JIT with Java 2 SE 1.3.
turnidge: Mike, the client VM will have further
enhancements past the beta. As for future plans our next release
of the HotSpot Server VM (2.0) will have substantial performance
improvements over 1.0 -- say 30%
Okidoky: I think this chat program
should become open source so that someone can
fix the bugs in it.
MDR-edort: To Okidoky, We are investigating
other (better) tools for the chat. We
should be implementing a new front end soon.
Bill.Pataky: Has anyone had any reliability
issues with HotSpot? We've had over 40,000 downloads.
Mike: Schrag Are there any performance
increase estimates for HotSpot Client 2.0 yet? Also, will HotSpot
have a separate release cycle like Swing (did) or will
it be released along with JDK's?
Bill.Pataky: We've had over 40,000 downloads and
extremely few bugs reported.
vince: Any comments as to TowerJ, I've
been looking at the latest Volano tests.
turnidge: Mike, the HotSpot client vm releases
will be part of the SDK release.
As for Client 2.0 performance in the future, I currently have no estimate --
we're working on getting the current version out. This is only the first
release of that (client) compiler technology and I have every confidence
performance will increase.
Bill.Pataky: About towerJ, They can't run all
Java programs - SPECjvm98 (the industry standard benchmark).
On a meatier benchmark (one that executes bytecodes) you'll
see pretty poor performance from tower. About Volano - It's
really a strange benchmark - very few bytecodes are actually
executed - all volano does is move a few bytes from one thread
to another in a chatserver . It
doesn't do much actual Java programming at all.
Bill.Pataky: More on tower; I meant to say,
they can't even run the SPEC mark.
MDR-edort We've had a good dialog so far, with
some interesting questions. But the number of questions in the
queue right now are few. So if you have a question
about Hotspot, please submit it now.
Spiff: Do you think that Hotspot
floating point performance will be as good as the symantec JIT
by the time of final release? I am concerned that the symantec
JIT will be removed from 1.3 and that Hotspot will not be as fast
(currently there is a factor of 2 difference on purely floating point code).
turnidge: Spiff, we are always looking for
areas where our perofmrance can be improved. If you could send a
message to hotspot-feedback@eng.sun.com and
mention that we talked on the chat session, maybe we can look
at getting your code in house and tracking down your performance
loss. What kind of program is it?
Bill.Pataky: Does anyone have any questions about
the Client VM vs Server VM?
Spiff: My benchmark simply adds a very
large number of floating point
numbers. It's a silly benchmark, but it is representative of the code I am
working on, a lot of floating point calculations and very little object
allocation. Btw, great job on the object allocation, Temporary object creation
is an order of magnitude better than the previous JIT.
Bill.Pataky: Spiff, Turnidge is addressing your
benchmark question, but I want
to address the object allocation comment. Thanks for the compliment. Objects
are allocated very quickly in an object nursery. Basically all we do to
allocate an object is bump a nursery pointer by the size of the object. If
the object persists (only a small percentage do), it's copied out of the
nursery into an older object store.
javadude: I am developping a client
server application using java as client and
server and oracle as back end. Sometimes I get the error message no more data
to read from socket my server is on the aix box and I am using oracle thin
driver can some one answer my question.
turnidge: Spiff, it's possible that you are running
into some problems with the
fact that you are running a microbenchmark. Benchmarks that sit and spin in
tight loops used to be a problem for our Server VM until we added an
optimization known as On Stack Replacement. Unfortunately, I do not recall if
the beta of the client VM has this optimization yet -- I'd bet that you are
running into this problem with your benchmark. For a workaround, you can put
the body of your main loop into a method call and see if your numbers change.
MDR-edort: Javadude, this isn't a HotSpot question.
You probably want to post your
question to an appropriate forum on the JDC site.
Bill.Pataky: Spiff, more on the benchmark.
It's possible that you're not
crossing the compilation threshold. Remember HotSpot starts running apps in
interpreted mode, and compiles the critical sections after a given number of
passes through the code (different for client and server)
marmot: Could you comment BEA Weblogic
App Server problems running on JDK1.2.
and Hotspot BEA advises dont use JDK1.2. and/or Hotspot for production systems.
mtk: Can you characterize the performance
problems with Java clients? Is it
JNI? Object creation? Something else? Can you explain (if it hasn't been
covered already) what client-specific optimizations are in the 1.3 beta release?
Bill.Pataky: About BEA, we haven't heard anything
about this from BEA. Can you
send me specific info via email? I'm at pataky@eng.sun.com. I'll track it
down and get you an answer.
turnidge: mtk, our client VM is made with the
view that snappy interactive performance is essential to a client
app. 1.3 saw improvements in
swing performance, memory footprint, and startup time. The startup
time improvement is visually apparent -- try the 1.3 beta (against 1.2) on
Java2Demo and I believe you'll be impressed.
Mike Azzi: What's the speedup in
synchronization over the classic VM? Any
specific benchmark numbers?
Spiff: I believe I took care
to make sure my method gets called several
hundred times. Also, the speed difference between the JITs
is not an order of
magnitude (as it would be if one was being interpreted) but more like a factor
of 2, as if the native code being generated by one wasn't as good as the native
code generated by the other.
Bill.Pataky: Spiff, If you're only executing
them a couple of hundred times
(most real critical code paths).
Bill.Pataky: More on spiff, HotSpot 1.0
isn't even compiling them - you're
executing purely in interpreted mode. Try bumping your counters up to 10,000,000
and you'll see different results, I believe. Your benchmark doesn't seem to be
typical of real world apps that have performance issues - especially for FP
calculations.
turnidge: Mike, the synchronization code is better. We've paid a lot of
attention to making the common cases fast. I wish I could tell you some numbers
here but I don't have any handy. We know how important synchronization speed is
for Java -- we've seen dramatic benchmark improvements just from squeezing a
couple of cycles out of the locking code. My advice is to just try our VM on
your code and see if synchronization is still an issue. I believe that a lot of
the concerns over synchronization speed are becoming a thing of the past.
Mike Azzi: What's the unit of code
that you compile at any given time? is it
an object, a method in an object, or a block of code within a method? And
where do you save it for later reuse? in main memory? or on disk? Also do you
plan on reusing that compiled code between various runs, or do you start
from scratch all over again?
Spiff: Well, the method is being
called several hundred times, but the
method itself runs for a long time (it loops 10^8 times).
turnidge: Mike, Good Question. We compile
on a method granularity. We save the
code in memory and do not reuse it on later runs.
Bill.Pataky: Spiff, Send us the benchmark and
we'll take a look and give you
some definite answers. Send it to hotspot-feedback@Sun.com.
Spiff: Alright, I'll send it over.
Bill.Pataky Thanks, we appreciate it.
turnidge: An amendment -- we compile on
a method granularity but we do a lot
of inlining. So the unit of compilation ends up being a tree of methods rooted
at some caller.
mtk: Java GUI's (even the demos
running under the 1.3 beta) feel 'sluggish.' I
realize that's a ridiculously imprecise comment. That is, popping down a menu
seems slower in a swing GUI than popping down a menu in a native motif or win32
gui. There are other similarly imprecise characterizations, but it's this
perception that leads to the shooting down of a lot of Java GUI proposals within
my development group. Does anyone else have this perception? Or a more precise
characterization?
Bill.Pataky: MTK, Have you noticed a dramatic
improvement from 1.2.2 to 1.3
beta?
MDR-edort: We're in the last 10 minutes of
the session. If you have questions for Bill
and Todd, send them now.
Spiff: A non-floating point question:
When you generate your native code,
do you generate additional code to keep track of method usage? Will you
reoptimize the code if you see that it is getting used a lot? I'm just
wondering if you perform multiple levels of optimization depending on how much
some code gets used.
Okidoky: I've had a few problems with
beta1.3 jdk. I use jikes to compile, and
if I run projects compiled under 1.2, and run them under 1.3, the VM craps out
now and then. You may want to make jikes as part of the testing procedure, it
puts out code in different orders, especially with regards to exception
handling.
Bill.Pataky: Okidoky, it looks like you
might have found a bug for us. Can you
please log it on JDC?
turnidge: Spiff, we currently do not have
multiple levels of optimization, so we
do not reoptimize code for performance. However, we do keep track of a number
of other things that may necessitate recompilation of the code -- for example,
class loading may invalidate our inlining decisions and we may need to
deoptimize the method and compile in the new class context. This is an
approach that we attempt to model to see if we can get any juice out of it.
While it may be a future direction for our technology, we are currently focused
on keeping it simple, making it fast.
Spiff: Is someone working on a port
of HotSpot to IA-64?
Bill.Pataky Spiff, we do have plans to support
IA-64. We're still waiting for
silicon at this point. (no questions about why we're not using a simulator
please 8-)
turnidge: Well, it's been fun answering your
questions. Thanks for running our
code!
Bill.Pataky: Thanks for your questions and
interest in HotSpot. Our time is up
here. Any further feedback, please sent to hotspot-feedback@Sun.com. We're
hungry for bugs!! Bye.
MDR-edort: The session is now over. Thanks
for your participation.
MDR-edort: Last moderator (me) signing off.
The forum is now unmoderated
Forum closed at Tue Sep 14 12:17:06 1999
Max number of users at any time 17
_______
1 As used on this web site,
the terms "Java virtual
machine" or "JVM" mean a virtual machine
for the Java platform.
Reader Feedback
Tell us what you think of this transcript.
