From: Stefan Monnier <monnier@iro.umontreal.ca>
To: guile-devel@gnu.org
Subject: Re: Imporved cons representatoin in guile
Date: Fri, 10 Jul 2015 13:31:02 -0400 [thread overview]
Message-ID: <jwv7fq8q6f6.fsf-monnier+gmane.lisp.guile.devel@gnu.org> (raw)
In-Reply-To: CAGua6m3yb8Z8OeLeHbnEHURE64C3+MJ0Onn03rGZHaMce2hoeg@mail.gmail.com
> To compress even further we need a way to could use
> x ->[SCM/2/SCM/2], witt SCM/2 the same tagging half the size as the normal
Note that this is not specific to cons-cells. I've been meaning to try
and experiment with such a box-compression scheme for several years, but
it never got high enough on the todo list (tho I did get a student to
look at it, but he gave up his MSc before getting far enough).
Note that because of set-car! and set-cdr! you need those SCM/2 fields
to be able to hold *any* value. So an SCM/2 field can hold 3 different
things:
- an immediate value.
- a compressed reference, typically using relative addressing, where
you'll want the GC to know about them, so it tries to keep/bring
related objects near each other.
- a "proxy reference", which identifies a full SCM cell which contains
the actual value. It can be a relative pointer or an index in some
table.
I imagined it working by dividing the heap into zones whose size
corresponds to the "reachability" of an SCM/2 relative pointer (so an
SCM/2 field can point to any other object within the same zone without
going through a proxy), and have each zone come with an array
of proxies.
I was thinking about this mostly in the context of 64bit boxes where the
SCM/2 references would basically only ever need to go through proxies once
the process size passes the 4GB limit. But for small-memory systems
using 32bit pointers, the same idea might work as well.
Interestingly, this split into zones+proxies would also allow the GC to
operate on each zone independently (you don't need to trace the objects
in the other zones, only their proxies).
Stefan
next prev parent reply other threads:[~2015-07-10 17:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-10 11:20 Imporved cons representatoin in guile Stefan Israelsson Tampe
2015-07-10 11:37 ` Stefan Israelsson Tampe
2015-07-10 17:31 ` Stefan Monnier [this message]
2015-07-14 13:18 ` Stefan Israelsson Tampe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwv7fq8q6f6.fsf-monnier+gmane.lisp.guile.devel@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=guile-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).