Re: vm status update

[Marijn Schouten (hkBst)]

-----BEGIN PGP SIGNED MESSAGE-----
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:
> 
>     
> 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...

Always a pleasure to read your updates.

Thanks,

Marijn

ps Kill, kill the snake ;p

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

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEUEARECAAYFAkmZUmEACgkQp/VmCx0OL2yoBgCYzGAJt3+u+OBBpWdsQt9RaYlR
ygCdFRv7CQr+ed0Q/gz5X6nL0Zy3xuo=
=yzOq
-----END PGP SIGNATURE-----