From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: vm status update Date: Sat, 14 Feb 2009 23:32:46 +0100 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1234650814 25049 80.91.229.12 (14 Feb 2009 22:33:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Feb 2009 22:33:34 +0000 (UTC) To: guile-devel Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Feb 14 23:34:48 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LYT5z-0000V6-1I for guile-devel@m.gmane.org; Sat, 14 Feb 2009 23:34:47 +0100 Original-Received: from localhost ([127.0.0.1]:47665 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LYT4e-0003oN-UF for guile-devel@m.gmane.org; Sat, 14 Feb 2009 17:33:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LYT4Z-0003o4-0k for guile-devel@gnu.org; Sat, 14 Feb 2009 17:33:19 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LYT4X-0003nQ-Ll for guile-devel@gnu.org; Sat, 14 Feb 2009 17:33:18 -0500 Original-Received: from [199.232.76.173] (port=53343 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LYT4X-0003nK-DX for guile-devel@gnu.org; Sat, 14 Feb 2009 17:33:17 -0500 Original-Received: from a-sasl-fastnet.sasl.smtp.pobox.com ([207.106.133.19]:51338 helo=sasl.smtp.pobox.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LYT4X-00051J-2q for guile-devel@gnu.org; Sat, 14 Feb 2009 17:33:17 -0500 Original-Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTP id DF00299C44 for ; Sat, 14 Feb 2009 17:33:16 -0500 (EST) Original-Received: from unquote (unknown [81.39.163.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-fastnet.sasl.smtp.pobox.com (Postfix) with ESMTPSA id 1E2E999C43 for ; Sat, 14 Feb 2009 17:33:15 -0500 (EST) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-Pobox-Relay-ID: 793534F6-FAE7-11DD-BFE6-0433C92D7133-02397024!a-sasl-fastnet.pobox.com X-detected-operating-system: by monty-python.gnu.org: Solaris 10 (beta) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8165 Archived-At: 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/