>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes:Archie> In JCVM for example, there is a bit in type->flags that Archie> determines whether the class is initialized or not. This bit Archie> has to be checked before every static method invocation or Archie> static field access. You could reserve an entire byte instead Archie> of a bit, but I don't know if that would make it any easier to Archie> do this optimization. My plan for this in my JIT is to just recompile the bytecode for the function after class initializations, constant pool resolutions, and the like. This is somewhat crude, but seems like it should work fine. The full plan is to have some kind of heuristic so we don't go around recompiling functions that are rarely called. Thoughts on that? Archie> I.e., my question is the more general one: Archie> how do optimizations that are specific to the front-end language get Archie> done? How does the front-end "secret knowledge" get passed through Archie> somehow so it can be used for optimization purposes? I was thinking that I would write some extra JVM-specific LLVM passes and add them to the pass manager I construct. I haven't started this, so I have no idea how I would handle passing the information back and forth. Tom
On Wed, 26 Apr 2006, Tom Tromey wrote:> My plan for this in my JIT is to just recompile the bytecode for the > function after class initializations, constant pool resolutions, and > the like. This is somewhat crude, but seems like it should work fine. > The full plan is to have some kind of heuristic so we don't go around > recompiling functions that are rarely called.I think this makes the most sense. In a static compilation environment, unless you can prove some sort of ordering, you have little choice but to do dynamic checks. In a JIT environment, you don't :)> Archie> I.e., my question is the more general one: > Archie> how do optimizations that are specific to the front-end language get > Archie> done? How does the front-end "secret knowledge" get passed through > Archie> somehow so it can be used for optimization purposes? > > I was thinking that I would write some extra JVM-specific LLVM passes > and add them to the pass manager I construct. > > I haven't started this, so I have no idea how I would handle passing > the information back and forth.This approach should work fine. There are multiple different approaches you can take, when you start digging in and have specific questions or needs, let us know! -Chris -- http://nondot.org/sabre/ http://llvm.org/
Tom Tromey wrote:>>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes: > > Archie> In JCVM for example, there is a bit in type->flags that > Archie> determines whether the class is initialized or not. This bit > Archie> has to be checked before every static method invocation or > Archie> static field access. You could reserve an entire byte instead > Archie> of a bit, but I don't know if that would make it any easier to > Archie> do this optimization. > > My plan for this in my JIT is to just recompile the bytecode for the > function after class initializations, constant pool resolutions, and > the like. This is somewhat crude, but seems like it should work fine. > The full plan is to have some kind of heuristic so we don't go around > recompiling functions that are rarely called. > > Thoughts on that?Which bytecode will you recompile? In particular I'm thinking about active use checks: as you know the checks for class A have to be implemented in every other class B, C, D, ... that references a static field or method of A. Presumably you won't recompile every class that references A after A is initialized...> Archie> I.e., my question is the more general one: > Archie> how do optimizations that are specific to the front-end language get > Archie> done? How does the front-end "secret knowledge" get passed through > Archie> somehow so it can be used for optimization purposes? > > I was thinking that I would write some extra JVM-specific LLVM passes > and add them to the pass manager I construct. > > I haven't started this, so I have no idea how I would handle passing > the information back and forth.With no annotation support, it doesn't seem like you can. This is the problem. I'm not saying annotations are good, just that they represent one (sub-optimal) solution to the problem. Without them, we have zero solutions to the problem. Of course the ideal is to come up with the "right way" (if such exists) to solve this issue, which people are starting to think about, which is good. It's definitely a challenging and interesting question and I'm not sure what would be the best answer. -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com
>>>>> "Archie" == Archie Cobbs <archie at dellroad.org> writes:Archie> Which bytecode will you recompile? In particular I'm thinking Archie> about active use checks: as you know the checks for class A have to Archie> be implemented in every other class B, C, D, ... that references a Archie> static field or method of A. Presumably you won't recompile every Archie> class that references A after A is initialized... In libgcj, static methods initialize their declaring class. So it is only static fields we have to worry about. This may not be the best choice but for the time being I'm just trying to fit my jit into the existing world. Optimizations are still a ways off for me, but my thinking was, we'd have a flag per method indicating whether it may make sense to recompile it. This flag would be set if we see an uninitialized class, unresolved constant pool entry, etc. If the flag is set and the method is called frequently enough, then we try to recompile. I'm also considering having multiple pass managers, and promoting methods from one manager to the next, depending on how heavily the method is used. Maybe this is all naive. Feel free to let me know :-) My plan in general is just to experiment with different things and see what works. Archie> I.e., my question is the more general one: Archie> how do optimizations that are specific to the front-end language get Archie> done? How does the front-end "secret knowledge" get passed through Archie> somehow so it can be used for optimization purposes? Archie> With no annotation support, it doesn't seem like you can. This is Archie> the problem. I'm not saying annotations are good, just that they Archie> represent one (sub-optimal) solution to the problem. Without them, Archie> we have zero solutions to the problem. I think the simpler optimizations (class initialization, constant pool resolution, division by zero check elimination, null pointer check elimination, array bounds check elimination) can all be done pretty simply without needing special LLVM support, either by generating different LLVM code up front (and arranging to recompile on demand), or by having a simple JVM-specific LLVM optimization pass. I haven't thought much about more complicated optimizations like escape analysis or devirtualization or whatnot. What kinds of things are you thinking of? Tom
On Wed, 26 Apr 2006, Archie Cobbs wrote:>> I haven't started this, so I have no idea how I would handle passing >> the information back and forth. > > With no annotation support, it doesn't seem like you can. This is > the problem. I'm not saying annotations are good, just that they > represent one (sub-optimal) solution to the problem. Without them, > we have zero solutions to the problem.Why do you believe this? -Chris -- http://nondot.org/sabre/ http://llvm.org/