Skip to main content

How fast is the new verifier?

2 replies [Last post]
linuxhippy
Offline
Joined: 2004-01-07

Hi there,

I am currently developing a quite "large" applet which is targeted to java-1.1 and up, consiting of about 800kb of classes (about 1000) withought resources or other non-class files.

Since there were some improvements from release to release I would like to deploy two versions of the applet, one targetted at 1.1->1.5 and one for mustang and up only.
This way users with mustang could use all the 1.5 improvements (StringBuilder) and the new verifier.

But I wonder how much this would speed up anything, the biggest problem is still jre startup (io-bound) time except on Laptops with pentium-m in battery mode (600mhz) - here the jre is spending mysterious much time somewhere loading the applet, leaving the hdd idle.

Is it really worth all the trouble? How much time does it need to verify 1000 "average" classes.

Thank you in advance, lg Clemens

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
tmarble
Offline
Joined: 2003-08-22

Ig:

Sorry for the delay in responding.

Several data points for you:

- We originally wanted to do a "Tune the verifier" competition like the "Crack the verifier" competition, but it didn't happen (at least not yet).

- We have some data that suggests that the new verifier
offers a 30%-40% reduction in verification time.
However, this only translates to about 5% startup
improvement (as you have noted... startup is
dominated by i/o).

- It's important to know that we have a cross-organizational team dedicated to improving startup and footprint. We've made a great deal of progress and are continuing to make these better.

- One of the challenges in doing this measurement is
that you really have to compare old/new classfile
formats with the old/new verifier.

- Measuring applet startup, in particular, is tricky.
We have benchmarks that log timestamps at different
points in the process (plugin initialization, JVM start,
AWT initialization, etc.) It would be good for us
to develop public applet benchmarks as part of
the performance project so that everyone could
benefit from them (and improve them).

- Prior to launching a performance subproject
(or static docs) we should probably put together
a list of goals, issues, etc. on the wiki...
I propose that we use a wiki page for this...
I made a starter page here:
http://wiki.java.net/bin/view/Projects/PerformanceNewVerifier
(NOTE: new pages should start with PerformanceWikiWord
instead of just WikiWord until we get our own
performance Wiki)

As I get time I'll try to add the pointers I've
got to that page.

Regards,

--Tom

linuxhippy
Offline
Joined: 2004-01-07

Hi tmarble,

well my response is even more delayed - I am always glad to get some feedback, if its as valueable as yours i am even happier :)
Thanks a lot for answering it that much in detail.

1.) Thanks for beeing that honest about the new verifier - I guess for now I stick to the old one.
Something which would be definitivly good would be something like a post-compilation verifier utility like its available for J2ME - this would make the build process much easier and would not cause that many troubles for bytecode-modification utilities (i am using proguard for example).

2.) I really appreciate Sun is still working on footprint and startup performance.
1.4.2 was pretty good but 1.5 is still slower because of its startup-animation. This has been better since 1.5.0_u4 but its still slower than 1.4.2 - till _u3 it has been catastrophic.
Sorry for beeing that harsh and unpolite but how can this happen at all?
Are there no regression tests for things like this?
(Even more brutal is when I talked to a Sun engineer about the problem (about 40% regression) and was told that they don't care about 800mhz CPUs))
The stuation as whole confuses me, you tell me that there are teams working hard to squeeze out every ms and every kb - on the other hand a simply animation introduces a 50% regression on some systems and nobody notices... :-/

So I hope there is still room for improvements and best whishes for those teams.

3.) I don't exactly know what I should write on the wiki but the idea sounds interesting. I am sure I'll fill it with garbage form time to time.

Thanks a lot for answering and beeing that patient with me ;)

Clemens