llvm dev - Feb 2011 - [LLVMdev] bytecode cache

Hi!

Is it possible to implement a byte code cache for a llvm-jit?
This way the compile time occurs only once and the next time
the compiled machine code can simply be loaded from disk.
Of course care has to be taken with function pointers that are
used as constants since they may change on the next run.

-Jochen

I think the way to do this is to generate a shared library which you
reload.  Shared libraries already handle the problems of PIC code and
relocatable globals, so I think it would be best to leverage that.

However, there's obviously some issues here.  Presumably you don't
have all the code up front, or you wouldn't be using a JIT in the
first place.  I don't think you can update the shlib as you go along,
so you'd have to either spit out bitcode or a shlib at process exit
(which would be fragile and expensive).  If you spit out bitcode,
which is probably cheaper and less complicated, you could codegen it
(in the background?) to a shlib next time you launch.

If you want a persistent code cache that you can update incrementally,
I think you'll need to come up with something that looks quite
different from LLVM's JIT.

Finally, this reminds me of the work done on DynamoRIO to persist
application code caches for use between processes and after reloading
the app:
http://www.burningcutlery.com/derek/docs/procshared-VEE08.pdf

They've had to solve some of the same problems.

Reid

On Wed, Feb 16, 2011 at 4:47 PM, Jochen Wilhelmy <j.wilhelmy at arcor.de>
wrote:
> Hi!
>
> Is it possible to implement a byte code cache for a llvm-jit?
> This way the compile time occurs only once and the next time
> the compiled machine code can simply be loaded from disk.
> Of course care has to be taken with function pointers that are
> used as constants since they may change on the next run.
>
> -Jochen
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

> I think the way to do this is to generate a shared library which you
> reload.  Shared libraries already handle the problems of PIC code and
> relocatable globals, so I think it would be best to leverage that.
yes, I also think that this is the way to go. By the way I always have a 
complete
"module" that is fixed and therefore I don't need to extend the
shlib.
One problem is how to load the shlib. I'd like to load it by hand and then
execute it as e.g. windows lacks real shared libs. The same as a jit
does but just loading the precompiled code and then executing it.

-Jochen