I’ve been working on DaCapo for nearly two weeks now, so I took a bit of time out today to figure out where I am with it:
| Status | Detail | Unimplemented bytecodes | |
|---|---|---|---|
| antlr | FAIL | too many open files | jsr (once) |
| bloat | pass | 718149ms | multianewarray (once) |
| chart | pass | 337240ms | |
| eclipse | FAIL | requires deoptimization | |
| fop | pass | 37126ms | |
| hsqldb | pass | 178120ms | |
| jython | FAIL | requires deoptimization | jsr (21 times) |
| luindex | pass | 149362ms | jsr (3 times) |
| lusearch | FAIL | segfault | |
| pmd | pass | 457936ms | jsr (15 times) |
| xalan | pass | 174340ms | jsr (8 times) |
Note that this is a debug build, with no optimization and assertions enabled, so the times are in no way representative.
These DaCapo benchmarks are all about running complex apps in “real-world” scenarios. In French, we call this “Le baptème du Feu” (does the expression baptised by fire exist in English ?) !!! It seems that Shark is behaving well here !!!
Check out the previous post, you may find that expression there ;)
thanks !!! My mistake ;-)
what exactly does “requires deoptimization” mean?
Sometimes (quite often, actually) the JIT hits things it cannot compile because some class or another has not been loaded. Rather than deferring compiling the entire method (which may never be completely resolved) you compile the bits you can and insert a trap which, when hit, causes the function to be interpreted temporarily until you’ve recompiled it with the new bit.
What benchmark size did you use?
Default.