This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

GCC/JIT and precise garbage collection support?


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} ***


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]