In case anyone is interested, JumpTables made it into Java6 B55 (should be available wednesday or thursday). If you have large switch statements this should help a bit. Give it shot and report any bugs. Thanks.

If you have switch statements so large that you're required to optimise them than your code is broken and you should fix it.Switch statements are jump tables.

All properly written Java code will not see a performance increase with this "feature" in Mustang.

You show me how to create a *performing" interpreted CPU emulator without switches.

Hm... maybe with a HashMap<Integer, Runnable> ? Better to roll your own hashmap implementation then, to support <int, Runnable> (without autoboxing). You'd safe yourself from a massive jump-table, but the Runnables might slow you don't a bit. I suspect it aint worth the effort for JEmu2

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

I think you're correct that jumptables have been there all along, at least at a bytecode level. There's even an instruction dedicated to this (tableswitch). Maybe what Azeem is refering to is that the tableswitch bytecode instruction is now also JIT'ed to a native jumptable?

Correct, the bytecodes generated from a switch statement can either be a tableswitch or a lookupswitch (depending on size, sparseness,etc). The previous implementation would create a binary search tree to calculate which branch of the switch statement to take. The Jumptable implementation creates a table in the constant section of the generated code, and in most cases its just a load address of the base of the table, calculate the index and jump to the new destination. The larger the table, the faster the implementation.

I just gave it a try (Java HotSpot(TM) Client VM (build 1.6.0-ea-b56, mixed mode):

On JEmu2, with Z80 based emulators I see a nice overal performance boost of almost 6%. Pretty impressive With one MC68000 based emulator I see an overal performance gain of about 9-10% , but in another MC68000 emulator, I see a tiny performance degredation of about 2% .However, the latter emulator spends much less time in large switches (more time is spent in video emulation compared to CPU emulation), so I guess this little loss has to do with something else. I'll try to put my finger on the cause of this degradation (really hard to tell at this point).

3rd year now.What does that have to do with jump tables?I believe they are completely unreasonable even when you want to parse large amounts of data.Just because I can't think of something better at this time doesn't mean a better way doesn't exist.

I believe they are completely unreasonable even when you want to parse large amounts of data.Just because I can't think of something better at this time doesn't mean a better way doesn't exist.

Maybe you should first think of a reason why jump tables are unreasonable before claiming that my code is broken.As long as you can't think of something, I believe you are wrong. Remember we're talking about raw performance here, which is not always the same as pretty code.

Quote

My memory (back since 1.0.x/1.1.x days) is that you could get something like up to 16 int before it switched to the less direct impl?

I remember that when you have a properly ordered switch, you get a tableswitch (even if it's quite large), otherwise you get a lookup switch.

Thanks! You can play with the flags to change how large the switch statement has to be before Jumptables are used. The flag is -XX:MinJumpTableSize=The default is at 16, you can try smaller but I've found 16 to be about the right size.

Thanks! You can play with the flags to change how large the switch statement has to be before Jumptables are used. The flag is -XX:MinJumpTableSize=The default is at 16, you can try smaller but I've found 16 to be about the right size.

Thanks, I'll play with that.

Just one more question:Why is there even a lookup switch? Isn't a JumpTable always faster?

b) Degenerated cases like 2-4 switch targets, speculative path on CPU can cover most of the paths, depending on architecture, while having a jump to address taken from memory location is bound to be 100% stopping any kind of lookahead/pipelining.

BTW, I noticed that there is no server VM in the 1.6 snapshot. Is there going to be one?I just did a performance comparison of JEmu2 with MAME, and found that one game runs about 18% slower than MAME on the 1.6 client VM while it runs as fast as MAME using the 1.4.2 server VM. I'd be really interested to soo how a 1.6 server VM would compare here

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org