Marc,
I read your paper "A compacting incremental collector and its performance in a production quality compiler": www.iro.umontreal.ca/~feeley/papers/ismm98.ps.gz
- Is (or will) this incremental collector available for Gambit v4? Soft-realtime behavior is important in my app. - The paper is quite old. Does the description of the blocking collector in section 3 still apply to Gambit v4?
(I only ask the second question because under "Main new features" in http://www.iro.umontreal.ca/~boucherd/mslug/meetings/20040519/mslug1.pdf.gz, it mentions "Better GC (safe for space)".)
The hybrid approach in this Erlang paper is interesting: http://user.it.uu.se/~kostis/Papers/ismm04.pdf
thanks,
Chris
Afficher les réponses par date
On 22-Dec-05, at 7:02 PM, Chris Newcombe wrote:
Marc,
I read your paper "A compacting incremental collector and its performance in a production quality compiler": www.iro.umontreal.ca/~feeley/papers/ismm98.ps.gz
- Is (or will) this incremental collector available for Gambit v4?
Soft-realtime behavior is important in my app.
- The paper is quite old. Does the description of the blocking
collector in section 3 still apply to Gambit v4?
(I only ask the second question because under "Main new features" in http://www.iro.umontreal.ca/~boucherd/mslug/meetings/20040519/ mslug1.pdf.gz, it mentions "Better GC (safe for space)".)
The hybrid approach in this Erlang paper is interesting: http://user.it.uu.se/~kostis/Papers/ismm04.pdf
A more up-to-date description of Gambit's GC is
"A Case for the Unified Heap Approach to Erlang Memory Management" (http://www.erlang.se/workshop/feeley.ps)
It also compares Gambit's GC with the one used by Erlang/Hipe.
Unfortunately the incremental collector described in the ISMM98 paper has suffered from bit-rot, and is not distributed with Gambit. I may resurect the code if there is sufficient interest in this (I know some people are interested in developing video-games with Gambit, and an incremental GC would be very useful for this).
Marc
On 12/30/05, Marc Feeley feeley@iro.umontreal.ca wrote:
Unfortunately the incremental collector described in the ISMM98 paper has suffered from bit-rot, and is not distributed with Gambit. I may resurect the code if there is sufficient interest in this (I know some people are interested in developing video-games with Gambit, and an incremental GC would be very useful for this).
For anyone who is interested in modern GC research: I found [1] to be very enjoyable. [1] http://www.uwtv.org/programs/displayevent.asp?rid=2168 (it's a video, but serves as an introduction to the papers).
I spent an hour of so bumbling through the Gambit code last night and it's pretty tough going. This is, of course, because Gambit is a lot more involved than many programs. But a document in the tradition of the HACKING files which can sometimes be found would be very useful. Maybe then researchers will improve your GC for you, rather than hacking yet another JVM :)
AGL
-- Adam Langley agl@imperialviolet.org http://www.imperialviolet.org 650-283-9641
On 12/31/05, Marc Feeley feeley@iro.umontreal.ca wrote:
Unfortunately the incremental collector described in the ISMM98 paper has suffered from bit-rot, and is not distributed with Gambit. I may resurect the code if there is sufficient interest in this (I know some people are interested in developing video-games with Gambit, and an incremental GC would be very useful for this).
For reasons other than video games, count my vote as interested :)
david rush -- DIsruptive Technology!
Great! Anyone else? :)
More rhetoric: Isn't this almost a practical necessity for applications that want fine-grained (millisecond) timeouts SRFI 21?
I don't see garbage collection mentioned at all in SRFI 21 or 18, and I agree that it is a theorectically transparent issue. But it could easily be a major practical issue for long-running soft-realtime applications that have hard service-level agreements on latency.
Other systems (e.g. Orbitz, point #9 in http://www.paulgraham.com/carl.html) work around this by having custom versions of cons etc. that use statically-sized pools, and they die if the pool is consumed (i.e. a standard embedded-systems approach). It would be great to not have to go that route!
Thanks,
Chris
----- Original Message ----- From: "david rush" kumoyuki@gmail.com To: "Marc Feeley" feeley@iro.umontreal.ca Cc: gambit-list@iro.umontreal.ca Sent: Saturday, December 31, 2005 10:21 AM Subject: Re: [gambit-list] Incremental garbage collector
On 12/31/05, Marc Feeley feeley@iro.umontreal.ca wrote:
Unfortunately the incremental collector described in the ISMM98 paper has suffered from bit-rot, and is not distributed with Gambit. I may resurect the code if there is sufficient interest in this (I know some people are interested in developing video-games with Gambit, and an incremental GC would be very useful for this).
For reasons other than video games, count my vote as interested :)
david rush -- DIsruptive Technology! _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca http://mailman.iro.umontreal.ca/mailman/listinfo/gambit-list
-
Adam Langley -
Chris Newcombe -
david rush -
Marc Feeley