[LLVMdev] Re: Newbie questions

[Archie Cobbs]

Tom Tromey wrote:
>>> In the JIT, devirtualization looks doable, though somewhat fiddly.  At
>>> least, that is true for straightforward things like calls to methods
>>> in final classes, or calls to methods on objects allocated with 'new'
>>> in the current function.  (The latter could be done AOT, at least if
>>> you defined a way to do the appropriate runtime link; I've considered
>>> it for gcj.)
> 
> Archie> I'm not that familiar with how your stuff works, but it sounds like
> Archie> you would have to do these optimizations before converting to LLVM
> Archie> format, right?
> 
> Nope, I do all the optimizations after converting to LLVM, and in
> particular after the "promote memory to registers" pass has run (this
> fits into an implementation detail of my jit...).  It is just much
> simpler to do these kinds of things on the SSA representation.
> 
> I thought more about what you are saying, and I think I understand the
> problem.  E.g., suppose we want to devirtualize not because a method
> is being called on the result of 'new' (since this is a particularly
> simple case) but because a method is being called on an object whose
> class happens to be 'final'.  In this case we need to know some
> properties of the java type.  (And, you can construct plenty of
> examples where java type information yields optimization
> opportunities.)
> 
> But, I don't think this sort of thing is a big deal to deal with.  In
> fact it seems to me that the only possible cases are method return
> types and field types (both instance and static of course).  Like
> Chris said, you could have annotations for things on the side.  E.g.,
> map from functions to their java types, a map from global variables to
> their java types, etc.  I think this plan wouldn't work so well if we
> had to annotate arbitrary values this way, since we wouldn't know
> whether passes might create or destroy values behind our back, but it
> seems to suffice to be able to map back to these four kinds of
> objects, and this is pretty easy.
> 
> For precompilation, the situation is a bit different.  But again, for
> precompilation of java you need to think about your linking strategy.
> And, if you want to preserve java semantics and allow multiple class
> loaders to load the "same" code, then you end up in the same kind of
> scenario -- the compiled form of a class has to indirectly refer to
> other classes, and this indirection can be used to recover "lost" type
> information.

I see.. I hadn't thought of it that way, but you're right: knowing the
java type of a LLVM object for optimization purposes is just a special
case of a more general problem that you'd have to solve anyway, namely,
knowing the java type of any LLVM variable or function for linking
purposes.

Instead of carrying the information along explicitly via annotations (or
some equivalent), you just recompute it each time you need it. As long
as that process is efficient, it's a perfectly valid strategy. So e.g.
you would define symbols whose names encode the associated type info
This is in fact what JCVM does inside ELF objects, using symbols such
as "java_lang_Thread$class_object", for the same reason.

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com