[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: vm status update

From: Marijn Schouten (hkBst)
Subject: Re: vm status update
Date: Mon, 16 Feb 2009 12:47:45 +0100
User-agent: Thunderbird (X11/20081231)

Hash: SHA1

Andy Wingo wrote:
> 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:
>     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...

Always a pleasure to read your updates.



ps Kill, kill the snake ;p

- --
Sarcasm puts the iron in irony, cynicism the steel.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<>, #gentoo-{lisp,ml} on FreeNode
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


reply via email to

[Prev in Thread] Current Thread [Next in Thread]