{ Monthly Archives }
So here it is, the first method from the all new Shark, String.hashCode(). And the same method from old Shark for comparison. Some highlights:
All in all I’m pretty pleased with myself.
I started tearing Shark apart yesterday. I had a chat with Tom Tromey on Saturday and he mentioned some properties of Java bytecode of which I was unaware — like, you can compile it without using a stack pointer. I was trying to figure out how to modify my first pass to generate some of this stuff when a reply to a seemingly unrelated question made me realise that not only does the server JIT have a pass that does all this and more, but it’s been abstracted out for easy reuse! So stay tuned for the Shark that keeps its stack and locals in registers :)
Today I got my second method working, String.hashCode(). Now I have conditional and unconditional branching, field access, array loads, a whole bunch of integer operators, and returning with a result implemented and (somewhat) tested. The bytecode coverage chart says I’m 50% done, but I don’t believe it.
Well, it’s taken a month and a half — and over 2000 lines of code — but I finally got a method out of Shark.
I made a chart showing which bytecodes are implemented, which I’ll keep updated as I progress. The estimated total coverage of 18% is slightly fanciful as it treats all bytecodes as equally complex, with nop having the same weight as new for example. Some codes are marked as complete but untested too. The way the compiler is structured means that in simple cases I can copy and paste whole blocks of bytecodes from the server compiler, so where I was doing one bytecode in a block I’ve copied the lot across. Most of them ought to be fine, but a couple are dubious. I’m still shuffling things around to try and make things less so.
Onwards…