Does anybody know if typical JVMs have a particular preference for dealing with slots or the operand stack? For example, if I store a reference in a slot, as opposed to duplicating it on the stack, how much more time is that going to take? (At the minimum, there is an additional load instruction or two, but will these tend to be optimized out during recompilation?)
Azeem, do you have any insight?
God bless,
-Toby Reyelts
Sorry no clue
I believe Shirazi has done such opcode micr0-benchmarking.
You might check his site as it soudsn like you have one of the rare projects (byte code generators) where this is actually useful information. Keep in mind though you’ll have to track it for changes over VM versions 
[quote]I believe Shirazi has done such opcode micr0-benchmarking.
You might check his site as it soudsn like you have one of the rare projects (byte code generators) where this is actually useful information. Keep in mind though you’ll have to track it for changes over VM versions
[/quote]
Ok, long time learker, first posting. I can safely say that my partner in crime has not done this type of benchmarking. I normally do that level of benchmarking and the last time that I did this was in an attempt to validate some of the tips in our tips database. I can safely say that I could not see any precevable differences between either technique. Later on I discovered that the compiler may have “optimized” my benchmark for me… As the saying goes… beware the microbenchmark ;D I still do them and I believe that they are useful but man can you get stung really badly if you’re not careful.
For example, I almost blogged a 1.5 MBM that I did the other night I was in the middle of the write up and a I had a nagging question. So, I went back in and tried a twiddle with the benchmark only to discover that the alteration resulted in a 60% reduction in run time. Ran the benchmark baseline in the 1.4.2_04 only to see the same effect.
The bizzare thing is; the twiddle was the removal of a call to sleep that occured after a forced GC and these calls are made outside of the metered section of code! Furthermore, because I didn’t force a full GC at controlled points, it ran during the metered portion of the code.
I’m currently wondering if the thread priority has been set in XP such that it’s often interruped after sleeping. That said, I shutdown just about everything running on the machine before starting the benchmark (including explorer :))
While writing this, I finished a test in W2K only to discover that the effect appears to be absent. So it would seem that this effect is a JVM/XP interaction. :-/
You mean you got rid of the startbar, the desktop, everything? Or do you just mean the IE and windows-explorer parts? (the “second-instance” bits)
I got out of NT admin around the time they introduced the “auto-restart of explorer”, so never got around to discovering how you kill it and prevent it from coming back, phoenix-like, a minute later.
Yup but don’t ask me why the auto-restart doesn’t