Re: JIT optimization framework (was: Re: [Sablevm-user] bug report...)
Brought to you by:
egagnon
From: John L. <je...@pi...> - 2000-08-01 06:26:44
|
> > I'm a bit sceptical about making the JIT compatible with a range of > > VMs (like the classic VM), because there are so many VM-specific > > optimisations to be made. But I love the idea of modularisation and > > flexibility. > > I think the essential idea is a framework where one can write a "plug > in" transformation that can be run on a number of VMs, if it is > something that can be performed at a high enough level. It is true that > those kinds of things alone are not enough to produce the best > attainable code for a particular environment, but that is not a problem > as a particular VM's JIT (hopefully) would know a few tricks about > optimizing for the local environment. Well there will be things that will be portable, but there will also be things that need to be customized for the VM. > >> I'm investigating if that status also applies to work with Java in > >> general. > > > > I'm not sure I understand the last line? > > My employer (NAI Labs) cannot claim "clean room" status and I need to > determine if there is a legal distinction between my role as an > employee of the company and my personal projects. So have you worked on tainted code yourself? > > I initially wanted to do a little bit of optimisation (such as register > > allocation), but was so depressed with the IA32's pitiful registers and > > different instructions for addressing the different sets of registers (MMX > > etc) that I decided to leave that for later. > > Yes, that is why it is much more fun to work with the Alphas, even > though producing code for them is actually harder (w.r.t. instruction > scheduling). I would love to get my hands on an Alpha. I'll have to start saving up for one. > I think most JITs are invoked indiscriminantly and are therefore > limited by the need for speed to variations on simple bytecode to > native code mapping. Etienne would like to see a VM invoke a JIT for > a particular method only if there is a clear benefit. I think that's > the only way to go if the JIT will be spending time aggressively > optimizing the result. Yes, but to do useful profiling it might be beneficial to do a minial translation first. > > > - Code straightening and jump threading. > > > > What is this? > > Code straightening and jump threading both have to do with improving > how branches are taken through the code. Code straightening takes > the code over what appears to be the most likely path of execution > through a procedure and arranges the corresponding basic blocks > sequentially -- so the most likely case is the fall through case. > This means that it is more likely than not that prefetched > instructions can be executed rather than discarded. Jump threading > looks at branch targets. For example, if the target of an > unconditional branch is another unconditional branch, then the > natural thing to do is make the first branch point to the second > branch's target. As another example, branches which point to the > very next instruction (commonly a result of other optimizations) can > be simply removed. Cases involving conditional branches are more > interesting. Would it be useful to actually record which branch is taken and use it for a later optimisation. Or is this too low-level. How does the CPU do branch-predicition? > > Yes, the whole issue of having the compiler substitute special code for > > marked methods is also something I'm very keen on. Specifically I want to > > avoid the overhead of native method calls for doing things like file IO > > etc. > > You should look at the work the Jaguar project has done in this area: > http://www.cs.berkeley.edu/~mdw/proj/jaguar/ Interesting. I'm thinking more along the lines of an interface to a general-purpose kernel (linux syscalls). One of my other projects is to create a OS based around the JVM as the kernel. The compiler will obviously help a lot with accessing raw hardware and compiling device drivers. (See www.jos.org). Recently I started compiling parts of kissme into the linux kernel as an experiment. I've also tried out the oskit, see cs.utah.edu, which is a project aimed at facilitating OS research. > > Yes, again there is a need for an initial translator which is very fast, > > but which will be superseded by a more advanced version at a later stage. > > Yes, or a VM with a fast interpreter which invokes the JIT > selectively. Well in my arrangement I currently first wait for the invokevirtual to be replaced by invokevirtual_quick before I think of optimising. But this is just a single method call. The problem is that it is probably common to have a thread like this: public void run() { while(true) { socket.accept(); service request; } } So how do you replace a running thread with native code? > > Remember that objects in the java heap move around. (I suppose you could > > pin these down). > > Hmm. Marking code object storage involatile is one option. Creatively > fixing up what code can't be made position independent as required > is another. I haven't thought too much about this yet, but I certainly > will be. :) Another issue I'm dealing with is that I want to make some of the compiled code persistent. (Ie resuable when the VM fires up again). But currently my native code stores direct pointers to things like JNIEnv environment pointers and to class structures. It would nice to be able to patch these when restarting the VM. (This will enable parts of the JVM to be rewritten in Java, something I'ld really like to do.) Of course it gets complicated when you start having absolute jumps to other functions etc. > > Yip, and if you're willing to bend the rules a bit you can also cache > > field accesses. I haven't looked much at what optimisation is possible > > from an OO point of view, but there is definitely a great potential for > > speedup in this area. > > Etienne worked in the past on a Java optimizer that did various OO > optimizations -- e.g. inlining, transforming virtual calls to static > ones, etc. (http://www.sable.mcgill.ca/soot/) I'm looking at this as > a starting point. I'll have a look at it too. John |