vm status update

[Andy Wingo <wingo@pobox.com>]

Greets!

So, yes, it's Saturday night: but I do love Guile hacking so. (Also: my
partner is away.) So a VM status update it is!

  * The parts of the instruction stream that are mapped directly to
    "struct scm_objcode" are now aligned to 8-byte boundaries, and
    written in native endianness.

  * Much more source information propagates through the compiler and
    into the metadata now. In short, whereas before it was "expressions
    are only marked as coming from a source location if they are eq? to
    an expression read in by guile", now it is "expressions are marked
    with the source location of their containing expression, unless they
    are eq? to an expression read by guile".

    The upshot is that original source information is preserved to a
    much broader extent than before, as macro-expanded or transformed
    expressions all have some kind of anchor to the original source.

    Another ramification of this is that procedures have source
    information corresponding to where they were really defined, in
    addition to locations of their subexpressions. (program-source foo
    0) will give you that.

  * The in-bytecode metadata representation has been compressed. Now we
    associate bytecode offsets with line-column pairs, and only record
    that information when it changes. The idea is, byte N in the
    instruction stream corresponds to source info for byte M, where M <=
    N. Also, we only record the filename when it changes.

    This means that we can have more source information, as mentioned
    above, but still have objcode files of similar size.

  * The VM dispatches to signal handlers (asyncs) more often,
    specifically: on return from a call, just before a call, and on a
    tail call.

  * Stack captures are much more reliable. Before there were some bugs.
    This allows statprof to work properly, capturing the whole stack up
    to a common root.

  * I set out to optimize GOOPS, and ended up writing a new call tree
    visualizer:

    http://wingolog.org/archives/2009/02/09/visualizing-statistical-profiles-with-chartprof

    It turns out that most of the time loading GOOPS is in the compiler,
    which comes from those dynamic recompilation bits I mentioned in the
    past. So I focused on optimizing the compiler -- it is much faster
    now.

    But still, for the uses that GOOPS has, a closure is better than a
    compiler. I changed thing in GOOPS so that it doesn't compile at
    runtime any more, and now on this machine GOOPS loads in something
    like 40ms. That's pretty good! Though improvements are possible, of
    course.

  * The VM now has support for separate engines. Currently the engines
    are just "regular" and "debug", defaulting to "debug". There are not
    interfaces to change this at runtime, yet. But it turns out there's
    not much difference. See vm-engine.c for more details. It seems that
    native compilation would be much better than a "reckless" engine.

Well, that's about it as far as changes go. And as far as status? I'm
going to update the docs for changes in the last month, then talk
seriously about a merge to master. I think it's ready.

Happy hacking,

Andy

ps. Guile finally loads faster than Python now. It's about time...
-- 
http://wingolog.org/