[DGD] importance of bytecode compatibility

[Shentino]

On Sun, Aug 7, 2011 at 8:54 AM, Felix A. Croes <felix at dworkin.nl> wrote:

> Carter Cheng <cartercheng at gmail.com> wrote:
>
> > I am curious how important bytecode compatibility is with older
> > versions- since a very direct way of implementing a JIT on LLVM would
> > be to modify codegeni.c to generate llvm bitcode and store this
> > information instead of the bytecode in the control block data. Would
> > this be acceptable since the new vm breaks the compat anyhow?
>

Skipping out on generation of the normal bytecode would probably also break
compatibility with hydra.


> It is not older, but newer versions that you should be concerned about.
>
> When you provide JIT v1, people will use it.  If you make improvements
> and create JIT v1.1 that is incompatible with v1, people will use it
> only if there is an upgrade path from v1 -- maybe.
>
> What I've seen with the existing precompiler (from LPC to C) is that
> people who want persistence will start off using the precompiler,
> but eventually abandon it because it is too much of a hassle in
> combination with snapshots and live upgrading.
>

I personally never used the precompiler very much.

The inability to use your object manager to customize the compilation
process (specialized "second auto" objects, among other things) has caused
me to shun it.

Also, even the suggestion of a legal grey area with regards to the resulting
generated C makes me nervous.  I've personally considered it a non issue but
it's still a bit chilling to realize others might not.

If your JIT code is stored in snapshots, then you either have to
> guarantee forward compatibility or abandon a part of your userbase
> with each incompatible change.  Guaranteed compatibility leads to
> the sort of thing you can now see in dgd/src/interpret.c: two
> different interpreter loops, one for old bytecode, and one for
> the new bytecode.
>

I'm also curious how you plan to store JIT code.

If it's machine code of the variety that java will generate, how can you be
sure of architecture compatiblity?

I don't think it would go over well if you generated JIT code on a Pentium 4
and restored from snapshot on a SPARC chip, for example.

If JIT code is not stored in snapshots but is compiled from DGD
> bytecode rather than LPC source code, forward compatibility is
> automatic.
>

Additionally the availability of LPC source is not even guaranteed.

In particular, long term muds of the kind you see on Skotos are persistent
muds, which means that source doesn't get fed to the compiler very often, so
in many cases you'll be working with already compiled bytecode being pulled
in from a snapshot on a warm boot.

You simply cannot reliably assume that you will have anything but bytecode
at your disposal when you generate JIT.  Your pioneering user that's trying
out JIT for the first time may well have nothing but a five year old
statedump being loaded and have such a crack team of coders that
compilations are more rare than a blue moon.

How important this is, you'll have to decide for yourself.  My
> personal preference is to compile from bytecode rather than
> source code, and to keep JIT code out of the snapshots.
>
> Regards,
> Felix Croes
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>