# [SERVER] JIT compilation of MOO code

Michael Brundage (brundage@laurel.ipac.caltech.edu)
Mon, 11 Nov 1996 16:37:44 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    On Mon, 11 Nov 1996, Christopher Unkel wrote:
    > On Mon, 11 Nov 1996, Michael Brundage wrote:
    > >    - differentiate between constant and mutable strings (String and
    > >      StringBuffer in Java)
    >
    > I don't see how this can be accomplished in a weakly-typed language such a
    > MOO; without declarations, how can we get to "constant" strings?

    Perhaps I wasn't clear -- I don't mean that the MOO programmer should
    know the difference, but that the VM should, in order to more efficiently
    handle strings (and possibly other constant values).  Again, I'm not
    sufficiently proficient in the server internals to even know if this
    would be a significant improvement, but it seems that if the VM
    distinguished between constant and mutable variables could easily
    produces some savings.  I.e., distinguish between the left and right hand
    sides of somemutablestring = "someconstantstring"

    > >    - differentiate between property fetches and stores so that
    > >      property values could be cached if known to not be altered during
    > >      task execution. This would obviate the need for things like
    > >        ou = $object_utils; for each in ([1..max_object()])
    > >        player:tell(ou:ancestors(each)); endfor
    >
    > Hmm.  Not nearly as easy as you might think.
    [points out that lazy evaluations across verb calls like I suggest
    above are not possible]
    [...]
    > Perhaps there are optimizations that could be made at the VM/DB interface
    > that would make it faster, however.

    Oh, I don't think it's easy at all!  The idea of an optimized VM is
    mostly a fantasy which I doubt will ever come to reality (unless, ha ha, I
    do it myself).  Also, since Pavel rewrote it to handle the
    error-catching expressions, I'm sure it's pretty close to optimal
    already.  I don't know.  It just seems like a natural thing to suggest,
    and whether it could be done or is worth being done I don't have enough
    information to evaluate.

    > There are also other issues, like how does the decompiler get your
    > original code back.

    Depends on the kinds of optimizations being done.  If subexpressions
    were eliminated, function calls inlined, and that sort of thing,
    I guess it would be tricky, but surely it can be done.

    > >    - provide a mechanism for just-in-time compilation into native
    > >      object code.  I wouldn't expect this to be fully implemented for
    > >      any given architecture, but it would allow motivated individuals
    > >      an opportunity to add support for it without each such person
    > >      rewriting it themselves.
    >
    > Yeah, this would be cool, presuming it was done in a way such that it
    > resulted in very fast and RELIABLE code.  The problem is, it is anything
    > but easy.  I wouldn't hold your breath... ;>

    Oh, I'm not.  The only reason I suggested it at all is because I would
    like to play around with doing that on a PowerMac, if I can ever find the
    time.  Every time I watch a large-scale simulation zip by at 500
    particles per second, I think, gee, this baby could really run a fast MOO...

    michael
    brundage@ipac.caltech.edu