[LLVMdev] Saving/restoring executable code from the the JIT?

[Renato Golin]

2009/9/12 Reid Kleckner <rnk at mit.edu>:
> It's not clear how valuable the feature is if users start to do things
> like inlining pointers to heap allocated objects with guards as
> optimizations.

or what about register variables, or objects half as registers half in
memory, or optimizations that exists on one machine (presence of FPU,
MMU, etc) and not on others, byte sex, word size and many other
problems... All of this is the job of serialization engine.

I suppose the JIT vm has already many solutions for the cross-platform
compatibility, but there will still be some lost context from one
place/time to another.


> I could imagine an IR class representing a pointer to an object on the
> heap that gets serialized to bitcode as some kind of relocatable
> symbol, and then re-resolved at runtime.  If the corresponding symbol
> doesn't exist at runtime, the implementation could choose to drop the
> particular function on the floor and recompile from source.

You could loose the program's state with that, which I think is the
whole point. Maybe having a class that saves all values marked with a
specific metadata (all the rest could potentially be reinitialized) as
a globally accessed symbol and re-read (and deleted) at restart.

It's responsibility of the programmer to say what's to be saved and
what can be safely reinitialized. The IRBuilder could annotate during
allocation, so the JIT would know which ones to save on suspend and
keep track where they are.

cheers,
--renato

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm