This is the mail archive of the
mailing list for the GCC project.
Re: ivopts vs. garbage collection
- From: Tom Tromey <tom at tromey dot com>
- To: Michael Matz <matz at suse dot de>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Jeff Law <law at redhat dot com>, Ian Lance Taylor <iant at golang dot org>, GCC Development <gcc at gcc dot gnu dot org>, Lynn Boger <laboger at linux dot vnet dot ibm dot com>
- Date: Mon, 11 Jan 2016 13:51:25 -0700
- Subject: Re: ivopts vs. garbage collection
- Authentication-results: sourceware.org; auth=none
- References: <CAOyqgcWphMUdS7pMyo9STBChnimJEWm0Ou+wmRtFM2Z500BiJg at mail dot gmail dot com> <568D3217 dot 6050802 at redhat dot com> <CAFiYyc0L0rduOMicug53bxx3-n2DGF-_1D1bEGw4oDWo3wo4vw at mail dot gmail dot com> <alpine dot LSU dot 2 dot 20 dot 1601111840370 dot 19289 at wotan dot suse dot de>
>>>>> "Michael" == Michael Matz <firstname.lastname@example.org> writes:
Michael> Well, that's a hack. A solution is to design something that
Michael> works generally for garbage collected languages with such
Michael> requirements instead of arbitrarily limiting transformations
Michael> here and there. It could be something like the notion of
Michael> derived pointers, where the base pointer needs to stay alive as
Michael> long as the derived pointers are.
This was done once in GCC, for the Modula 3 compiler.
There was a paper about it, but I can't find it any more.
The basic idea was to emit a description of the stack frame that their
GC could read. They had a moving GC that could use this information to
rewrite the frame when moving objects.