[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
vm status update
vm status update
Sat, 14 Feb 2009 23:32:46 +0100
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)
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
* 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
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
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
* 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.
ps. Guile finally loads faster than Python now. It's about time...
- vm status update,
Andy Wingo <=