Assembly for Java VM
category: general [glöplog]
Surely it must be possible to assemble (as opposed to compile) Java VM bytecode. What resources are available to get me started with this.
That could only be for size matters. Doing lowlevel VM-specific byte code makes no sense otherwise :-)
Thanks Elsewhere, that's got me started.
Why? well...
1) Pedantic case sensitivity pisses me off!
2) I hope to get things running a little faster (has anyone else noticed that an A1200 has much faster display HW than JVM!-)
3) So I can feel superior to most other Java developers!
Why? well...
1) Pedantic case sensitivity pisses me off!
2) I hope to get things running a little faster (has anyone else noticed that an A1200 has much faster display HW than JVM!-)
3) So I can feel superior to most other Java developers!
The VM is case-sensitive, so I don't think Jasmin helps with that.
Writing byte code assembler also triggered so many JIT bugs that it's actually better to code in plain Java. Either the code crashed or the "optimized" (less operations) version ran dog slow.
My experience is from 10 years ago, maybe it's got better, maybe not.
Writing byte code assembler also triggered so many JIT bugs that it's actually better to code in plain Java. Either the code crashed or the "optimized" (less operations) version ran dog slow.
My experience is from 10 years ago, maybe it's got better, maybe not.
It's not better. At least not by much.
Java asm is a bad idea for lots of reason (sorry, I studied that too long ago):
I have no time for a complete answer but:
- don't compare the a1200 arch' to the java one !!! the asm speed on amiga is due to chip access, cpu doesn't makes the speed (...).
- the .java sources are compiled as they are in byte code almost without optimization (6+6 will be compiled as 12, but "str"+"str" will always makes a stringbuffer.append() , so you can apply all your asm-optimization directly in java sources.
- you cannot access more methods or more memories with java ASM. So asm or java sources are almost the same thing.
- the java bytecode is re-compiled and re-linked (and some code inlined) by the JVM, so the optims are made there. (code a JVM in intel asm would be smarter)
- the table access tests (read or write) to manage IndexOutOfBoundException can't be avoided with java ASM. (they are done by the jvm moves)
- plus:java asm syntax does not officially exist: you have asms with different syntaxes...
- the classic way of optimizing java are way more efficient than all you will get with java asm:
1. don't bother the garbage collector:
do most if not all alloc at init, not during effects,
don't alloc new objects in loop, try to re-use object without "new", when you need temp objects, init them once as statics, make a call to System.gc() after init before effect.
2. use final/static words the best way, it will allow the JVM JIT class loader to inline (like the inline word in C/++) some of your methods. There is a lot to do with it.
3. use System.arrayCopy() as much as you can, this is the only way to access tables with no IndexOutOfBoundException tests...
+ like C/C++, learn how the caches works (L1,L2 what happens when a cache line is only read) , cache issue are determinant for speed JSYK.
I have no time for a complete answer but:
- don't compare the a1200 arch' to the java one !!! the asm speed on amiga is due to chip access, cpu doesn't makes the speed (...).
- the .java sources are compiled as they are in byte code almost without optimization (6+6 will be compiled as 12, but "str"+"str" will always makes a stringbuffer.append() , so you can apply all your asm-optimization directly in java sources.
- you cannot access more methods or more memories with java ASM. So asm or java sources are almost the same thing.
- the java bytecode is re-compiled and re-linked (and some code inlined) by the JVM, so the optims are made there. (code a JVM in intel asm would be smarter)
- the table access tests (read or write) to manage IndexOutOfBoundException can't be avoided with java ASM. (they are done by the jvm moves)
- plus:java asm syntax does not officially exist: you have asms with different syntaxes...
- the classic way of optimizing java are way more efficient than all you will get with java asm:
1. don't bother the garbage collector:
do most if not all alloc at init, not during effects,
don't alloc new objects in loop, try to re-use object without "new", when you need temp objects, init them once as statics, make a call to System.gc() after init before effect.
2. use final/static words the best way, it will allow the JVM JIT class loader to inline (like the inline word in C/++) some of your methods. There is a lot to do with it.
3. use System.arrayCopy() as much as you can, this is the only way to access tables with no IndexOutOfBoundException tests...
+ like C/C++, learn how the caches works (L1,L2 what happens when a cache line is only read) , cache issue are determinant for speed JSYK.
still useful if java decompilers don't work :p
anakirob : it won't run any faster and it might often end up running much slower as Jmagic mentioned it.
You will also lose compatibility with some JVMs that will expect a precise bytecode in a precise order. If you mess with it, you will get JVM exceptions or encounter bugs you won't be able to figure out.
The good news is that if you do it slightly at well chosen places, it will render decompilers useless, which means the first guy showing up won't be able to recompile your applet and reuse it like that. Keep in mind that those decompilers will still be able to output the bytecode anyway.
Messing with the bytecode is a long and boring process that will only bring issues and will make you lose your time.
You will also lose compatibility with some JVMs that will expect a precise bytecode in a precise order. If you mess with it, you will get JVM exceptions or encounter bugs you won't be able to figure out.
The good news is that if you do it slightly at well chosen places, it will render decompilers useless, which means the first guy showing up won't be able to recompile your applet and reuse it like that. Keep in mind that those decompilers will still be able to output the bytecode anyway.
Messing with the bytecode is a long and boring process that will only bring issues and will make you lose your time.
