From: Basile Starynkevitch <basile@starynkevitch.net>
To: jit@gcc.gnu.org
Cc: gcc@gcc.gnu.org
Subject: GCC/JIT and precise garbage collection support?
Date: Thu, 01 Jan 2015 00:00:00 -0000 [thread overview]
Message-ID: <559EF2F1.6000000@starynkevitch.net> (raw)
Hello All,
(this is triggered by a question on the Ocaml mailing list asking about
SystemZ backend in Ocaml; SystemZ is today a backend for GCC & probably
GCCJIT)
We might want to support better good garbage collection schemes in GCC,
particularily in GCCJIT. This is a
thing that LLVM is known to be weak at, and we might aim to do much
better. If we did, good frontends for
good functional languages (e.g. F#, Ocaml, Haskell) might in the future
profit of GCC technology. And even a Javascript engine based on GCCJIT
could profit.
A good GC is very probably a precise (sometimes generational copying) GC
with write barriers
(read the http://gchandbook.org/ for more, or at least the wikipage
about garbage collection). So a good GC is changing pointers.
So we need to know where, and provide a mechanism for, pointer values
are located in the call stack (of the GCCJIT generated code), and
probably provide some write barrier machinery.
In my incomplete understanding, this requires cooperation between GCC
backend and middle-end; it perhaps mean in the GIMPLE level that we mark
some trees for local variables as been required to be spilled (by the
backend) at some well defined location in the call frame, and be able to
query that location (i.e. its offset).
Perhaps a possible approach might be to add, at the C front-end level,
an extra variable attribute telling that the variable should be spilled
always at the same offset in the call frame, to have some machinery to
query the value of that fixed offset, and to also have a GCC builtin
which flushes all the registers into the call frame?
This is just food for thoughts and still fuzzy in my head. Comments are
welcome (including things like we should not care at all about GC).
Notice that if we had such support for garbage collection, the (dying)
Java front-end could be resurrected to provide a faster GC than Boehm
GC. And GCC based compilers for languages like Go or D which have
garbage collection could also profit. (even MELT might take advantage of
that).
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
next reply other threads:[~2015-07-09 22:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-01 0:00 Basile Starynkevitch [this message]
2015-01-01 0:00 ` David Malcolm
2015-01-01 0:00 ` Armin Rigo
2015-01-01 0:00 ` David Malcolm
2015-01-01 0:00 ` Armin Rigo
2015-01-01 0:00 ` Jeff Law
2015-01-01 0:00 ` Andrew Haley
2015-01-01 0:00 ` Trevor Saunders
2015-01-01 0:00 ` Andrew Haley
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=559EF2F1.6000000@starynkevitch.net \
--to=basile@starynkevitch.net \
--cc=gcc@gcc.gnu.org \
--cc=jit@gcc.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).