Re: [racket-users] garbage collection
On Sun, Oct 25, 2020 at 04:41:41PM -0400, 'John Clements' via Racket Users wrote: > It depends a lot on what you mean by a “Lisp-y” language. I’m certainly not > going to disagree with the sentiments expressed in the stack overflow post > that Dan Prager posted… after all, I wrote the top-posted one! You’re asking > a question about persuading a co-worker, though. In my opinion, the best line > of argument to use with people like this is that you could be trading CPU > time against human developer time. I think it’s moderately non-controversial > to suggest that writing code in languages without a garbage collector creates > new opportunities for things to break, and therefore incurs a higher > development and maintenance cost. If the software is going to be run enough, > then maybe you can make an argument that the tradeoff is worth it. If it’s > not on a critical path, though, then reducing development time is probably > the better choice. > > In my opinion, moving the discussion up one level (cost benefit analysis) > reduces the opportunity for banging heads on the merits of garbage collection > itself. > > And, with that said, changing peoples’ minds is generally impossible. The big question is: Is this a program where short pauses would be critical? If not, you can afford a garbage collector. If so, you should use a language without a garbage collector, perhaps Rust, or else not have any tricky data structures that have to be freed. P.S. If the lists are noncircular, reference counting works. Provided your languages manages it properly. I suspect Rust does. Limbo uses it as the preferred means for garbage collection, with a regular garbage collector as a backup, needed only when there are lost circular lists. -- hendrik > > John > > > > On Oct 25, 2020, at 10:10, Tim Meehan wrote: > > > > I'm in a very small programming operation, and I am trying to get my > > co-workers to try out Racket, or at least tolerate some of the tools being > > written in Racket. One of them has a very simple decision tree that he uses > > to evaluate programming languages: "does it have a garbage collector?", if > > yes, reject ... > > > > It doesn't seem to be a speed thing, it seems to be that he is convinced > > that the designers of the garbage collectors look for bad times to go to > > work and screw up what he's doing. (You guys don't do that, right? ) > > > > It got me thinking though - is it possible to run modern Lisp-y languages > > without a garbage collector? Is it even smart to try? I know that there > > must be a trade off, I just didn't know enough about what was traded off to > > explain it to him. > > > > -- > > You received this message because you are subscribed to the Google Groups > > "Racket Users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to racket-users+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/racket-users/CACgrOxLZXa%2BLUhX4sWbdg8PtjnoiSw_yeSDMg7OoV9HSEMRweA%40mail.gmail.com. > > > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/22ce3dfa-b2bb-4484-a43f-ff190461fbdb%40mtasv.net. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/20201025210826.vhanbgcjs77qrkea%40topoi.pooq.com.
Re: [racket-users] garbage collection
It depends a lot on what you mean by a “Lisp-y” language. I’m certainly not going to disagree with the sentiments expressed in the stack overflow post that Dan Prager posted… after all, I wrote the top-posted one! You’re asking a question about persuading a co-worker, though. In my opinion, the best line of argument to use with people like this is that you could be trading CPU time against human developer time. I think it’s moderately non-controversial to suggest that writing code in languages without a garbage collector creates new opportunities for things to break, and therefore incurs a higher development and maintenance cost. If the software is going to be run enough, then maybe you can make an argument that the tradeoff is worth it. If it’s not on a critical path, though, then reducing development time is probably the better choice. In my opinion, moving the discussion up one level (cost benefit analysis) reduces the opportunity for banging heads on the merits of garbage collection itself. And, with that said, changing peoples’ minds is generally impossible. John > On Oct 25, 2020, at 10:10, Tim Meehan wrote: > > I'm in a very small programming operation, and I am trying to get my > co-workers to try out Racket, or at least tolerate some of the tools being > written in Racket. One of them has a very simple decision tree that he uses > to evaluate programming languages: "does it have a garbage collector?", if > yes, reject ... > > It doesn't seem to be a speed thing, it seems to be that he is convinced that > the designers of the garbage collectors look for bad times to go to work and > screw up what he's doing. (You guys don't do that, right? ) > > It got me thinking though - is it possible to run modern Lisp-y languages > without a garbage collector? Is it even smart to try? I know that there must > be a trade off, I just didn't know enough about what was traded off to > explain it to him. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/CACgrOxLZXa%2BLUhX4sWbdg8PtjnoiSw_yeSDMg7OoV9HSEMRweA%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/22ce3dfa-b2bb-4484-a43f-ff190461fbdb%40mtasv.net.
Re: [racket-users] garbage collection
> is it possible to run modern Lisp-y languages without a garbage collector? Is it even smart to try? This seems to cover it ... https://stackoverflow.com/questions/16240183/not-using-garbage-collector-in-scheme-lisp-implementation Dan -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAFKxZVUku1i7HFZxuFpzW2L5YZaHoxFz-pXN64RoHpa3CadbSQ%40mail.gmail.com.
Re: [racket-users] Garbage Collection of Places
At Mon, 17 Aug 2015 12:21:41 -0700 (PDT), Jack Firth wrote: On Monday, August 17, 2015 at 9:07:15 AM UTC-7, Matthew Flatt wrote: That's an especially basic mistake, and it slipped by because low-level locks are rarely allocated in the run-time system. Place channels are probably the simplest way to trigger new locks, but the test that checks for leaks with place channels uses the GC's count. Would it be worthwhile to hook up a tool like Valgrind for catching these sorts of VM memory bugs to the Travis CI builds and tests of Racket? (Or is there already some such process in the builds, in which case why didn't it catch this?) From my limited experience with C, I've learned it's pretty much impossible to expect any sane human to keep track of memory perfectly. The last time I tried Valgrind was in March. I got it to work with some small adjustments to Racket: http://lists.racket-lang.org/users/archive/2015-March/066287.html I'm sure more could be done with Valgrind. Catching a bug like the one with place channels in an automated way would be difficult; it would be a matter of calling the right function enough to distinguish it from once-per-process allocations that are intended to be cleaned up implicitly by the process exiting. Although the runtime system has a lot of C code, memory leaks are relatively rare because most allocation is through the GC --- even for internal data structures. In other words, I mostly work in garbage-collected dialect of C. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Garbage Collection of Places
Sam, I don’t see the leak with (display (current-memory-use)) -- sorry for leaving it in the example, it’s misleading since your numbers behave like mine did when I used that function. I *do*, however, see the leak on my gnome-system-monitor; which looks like something that’s invisible to the GC falling off its radar. Could you see if your favourite system memory monitor shows any growth? Thanks, Tim On 17/08/15 15:45, Sam Tobin-Hochstadt wrote: Hi Tim, I just tried this out on HEAD, and I don't see the leak you mention. Here's some representative output, with somewhat fewer printouts. 987 19197408 23120744 22890272 22708784 22102128 29001640 27675528 21492328 22373784 29436848 28895592 I've never seen a number starting with 3 in running this program. I know Matthew has fixed some leaks recently, so maybe that's what's reduced this. Sam On Mon, Aug 17, 2015 at 10:03 AM Tim Brown tim.br...@cityc.co.uk mailto:tim.br...@cityc.co.uk wrote: Folks, I am observing a memory leak with place-channels. I have long-lived (or very busy server “places”) which I think are exhausting VM memory and causing spectacular failures -- core dumps, spins and other fun I came to Racket to avoid. Please could someone more familiar with the code take a look at this? I would like to have absolute confidence in places and place channels since they will be holding my application together. - #lang racket/base (require racket/place) (let mloop ((m 1000)) (collect-garbage) (displayln m) (let kloop ((k 1000)) ;(display #\tab) (displayln (current-memory-use)) (let iloop ((i 1000)) (place-channel) (cond [( i 0) (iloop (sub1 i))] [( k 0) (kloop (sub1 k))] [( m 0) (mloop (sub1 m))] - When I run the above program, using a stripped, non-debug version of racket-6.2.1 (3m) it grows 0.5GB in 5 (998-993) “m” loops. (i.e. 5,000,000 calls to place-channel). When I run it in a debug version, it doesn’t survive 140 “k” loops (i.e. 140,000 calls to place channel). No matter where I explicitly call (collect-garbage). I do believe that the places are being GCed, just they’re leaving something of themselves behind. The documentation states: Place channels are subject to garbage collection, like other Racket values, and a thread that is blocked reading from a place channel can be garbage collected if place channel’s writing end becomes unreachable. However, unlike normal channel blocking, if otherwise unreachable threads are mutually blocked on place channels that are reachable only from the same threads, the threads and place channels are all considered reachable, instead of unreachable. And I don’t see how a call to (place-channel) can put it in a state as described above. Verision info: racket-6.2.1 (3m) $ uname -a Linux tim-8 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u1 x86_64 GNU/Linux (debug version built with) $ ../src/configure --prefix=/usr/local/racket/6.2.1-d --enable-backtrace --disable-strip --enable-noopt Tim -- Tim Brown CEng MBCS tim.br...@cityc.co.uk mailto:tim.br...@cityc.co.uk City Computing Limited · www.cityc.co.uk http://www.cityc.co.uk City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB T:+44 20 8770 2110 · F:+44 20 8770 2130 City Computing Limited registered in London No:1767817. Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE VAT No: GB 918 4680 96 -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com mailto:racket-users%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Tim Brown CEng MBCS tim.br...@cityc.co.uk City Computing Limited · www.cityc.co.uk City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB T:+44 20 8770 2110 · F:+44 20 8770 2130 City Computing Limited registered in London No:1767817. Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE VAT No: GB 918 4680 96 -- You received this message because you are subscribed
Re: [racket-users] Garbage Collection of Places
The problem is in the clean-up of OS-level locks. A lock is allocated using a combination of malloc() and pthread_mutex_init(), for example. The clean up was usually missing the free() to go along with pthread_mutex_destroy(). That's an especially basic mistake, and it slipped by because low-level locks are rarely allocated in the run-time system. Place channels are probably the simplest way to trigger new locks, but the test that checks for leaks with place channels uses the GC's count. I've pushed a repair as commit 641c56b6e9. I expect that patch would apply cleanly to v6.2.1. At Mon, 17 Aug 2015 15:02:35 +0100, Tim Brown wrote: Folks, I am observing a memory leak with place-channels. I have long-lived (or very busy server “places”) which I think are exhausting VM memory and causing spectacular failures -- core dumps, spins and other fun I came to Racket to avoid. Please could someone more familiar with the code take a look at this? I would like to have absolute confidence in places and place channels since they will be holding my application together. - #lang racket/base (require racket/place) (let mloop ((m 1000)) (collect-garbage) (displayln m) (let kloop ((k 1000)) ;(display #\tab) (displayln (current-memory-use)) (let iloop ((i 1000)) (place-channel) (cond [( i 0) (iloop (sub1 i))] [( k 0) (kloop (sub1 k))] [( m 0) (mloop (sub1 m))] - When I run the above program, using a stripped, non-debug version of racket-6.2.1 (3m) it grows 0.5GB in 5 (998-993) “m” loops. (i.e. 5,000,000 calls to place-channel). When I run it in a debug version, it doesn’t survive 140 “k” loops (i.e. 140,000 calls to place channel). No matter where I explicitly call (collect-garbage). I do believe that the places are being GCed, just they’re leaving something of themselves behind. The documentation states: Place channels are subject to garbage collection, like other Racket values, and a thread that is blocked reading from a place channel can be garbage collected if place channel’s writing end becomes unreachable. However, unlike normal channel blocking, if otherwise unreachable threads are mutually blocked on place channels that are reachable only from the same threads, the threads and place channels are all considered reachable, instead of unreachable. And I don’t see how a call to (place-channel) can put it in a state as described above. Verision info: racket-6.2.1 (3m) $ uname -a Linux tim-8 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u1 x86_64 GNU/Linux (debug version built with) $ ../src/configure --prefix=/usr/local/racket/6.2.1-d --enable-backtrace --disable-strip --enable-noopt Tim -- Tim Brown CEng MBCS tim.br...@cityc.co.uk City Computing Limited · www.cityc.co.uk City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB T:+44 20 8770 2110 · F:+44 20 8770 2130 City Computing Limited registered in London No:1767817. Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE VAT No: GB 918 4680 96 -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Garbage Collection of Places
I'm looking into this. I can confirm that the GC thinks there's no leak, but the OS thinks there is. Thanks for the example and info! At Mon, 17 Aug 2015 16:09:00 +0100, Tim Brown wrote: Sam, I don’t see the leak with (display (current-memory-use)) -- sorry for leaving it in the example, it’s misleading since your numbers behave like mine did when I used that function. I *do*, however, see the leak on my gnome-system-monitor; which looks like something that’s invisible to the GC falling off its radar. Could you see if your favourite system memory monitor shows any growth? Thanks, Tim On 17/08/15 15:45, Sam Tobin-Hochstadt wrote: Hi Tim, I just tried this out on HEAD, and I don't see the leak you mention. Here's some representative output, with somewhat fewer printouts. 987 19197408 23120744 22890272 22708784 22102128 29001640 27675528 21492328 22373784 29436848 28895592 I've never seen a number starting with 3 in running this program. I know Matthew has fixed some leaks recently, so maybe that's what's reduced this. Sam On Mon, Aug 17, 2015 at 10:03 AM Tim Brown tim.br...@cityc.co.uk mailto:tim.br...@cityc.co.uk wrote: Folks, I am observing a memory leak with place-channels. I have long-lived (or very busy server “places”) which I think are exhausting VM memory and causing spectacular failures -- core dumps, spins and other fun I came to Racket to avoid. Please could someone more familiar with the code take a look at this? I would like to have absolute confidence in places and place channels since they will be holding my application together. - #lang racket/base (require racket/place) (let mloop ((m 1000)) (collect-garbage) (displayln m) (let kloop ((k 1000)) ;(display #\tab) (displayln (current-memory-use)) (let iloop ((i 1000)) (place-channel) (cond [( i 0) (iloop (sub1 i))] [( k 0) (kloop (sub1 k))] [( m 0) (mloop (sub1 m))] - When I run the above program, using a stripped, non-debug version of racket-6.2.1 (3m) it grows 0.5GB in 5 (998-993) “m” loops. (i.e. 5,000,000 calls to place-channel). When I run it in a debug version, it doesn’t survive 140 “k” loops (i.e. 140,000 calls to place channel). No matter where I explicitly call (collect-garbage). I do believe that the places are being GCed, just they’re leaving something of themselves behind. The documentation states: Place channels are subject to garbage collection, like other Racket values, and a thread that is blocked reading from a place channel can be garbage collected if place channel’s writing end becomes unreachable. However, unlike normal channel blocking, if otherwise unreachable threads are mutually blocked on place channels that are reachable only from the same threads, the threads and place channels are all considered reachable, instead of unreachable. And I don’t see how a call to (place-channel) can put it in a state as described above. Verision info: racket-6.2.1 (3m) $ uname -a Linux tim-8 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u1 x86_64 GNU/Linux (debug version built with) $ ../src/configure --prefix=/usr/local/racket/6.2.1-d --enable-backtrace --disable-strip --enable-noopt Tim -- Tim Brown CEng MBCS tim.br...@cityc.co.uk mailto:tim.br...@cityc.co.uk City Computing Limited · www.cityc.co.uk http://www.cityc.co.uk City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB T:+44 20 8770 2110 · F:+44 20 8770 2130 City Computing Limited registered in London No:1767817. Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE VAT No: GB 918 4680 96 -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com mailto:racket-users%2bunsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Tim Brown CEng MBCS tim.br...@cityc.co.uk City Computing Limited · www.cityc.co.uk City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB
Re: [racket-users] Garbage Collection of Places
Thank you Matthew. On 17/08/15 17:07, Matthew Flatt wrote: That's an especially basic mistake, and it slipped by because low-level locks are rarely allocated in the run-time system. Place channels are probably the simplest way to trigger new locks, but the test that checks for leaks with place channels uses the GC's count. The sad thing is that years of C programming don't improve one's (I mean my) ability to spot broken malloc/free pairs. So although you say it's a basic mistake -- it doesn't mean that wasn't inevitable! That's why we all rely on the GC; because the alternative is just too horrible to contemplate :-O . And send brave souls like you to face the horrors. Thanks for volunteering. I've pushed a repair as commit 641c56b6e9. I expect that patch would apply cleanly to v6.2.1. Tim -- Tim Brown CEng MBCS tim.br...@cityc.co.uk City Computing Limited · www.cityc.co.uk City House · Sutton Park Rd · Sutton · Surrey · SM1 2AE · GB T:+44 20 8770 2110 · F:+44 20 8770 2130 City Computing Limited registered in London No:1767817. Registered Office: City House, Sutton Park Road, Sutton, Surrey, SM1 2AE VAT No: GB 918 4680 96 -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Garbage Collection of Places
On Monday, August 17, 2015 at 9:07:15 AM UTC-7, Matthew Flatt wrote: That's an especially basic mistake, and it slipped by because low-level locks are rarely allocated in the run-time system. Place channels are probably the simplest way to trigger new locks, but the test that checks for leaks with place channels uses the GC's count. Would it be worthwhile to hook up a tool like Valgrind for catching these sorts of VM memory bugs to the Travis CI builds and tests of Racket? (Or is there already some such process in the builds, in which case why didn't it catch this?) From my limited experience with C, I've learned it's pretty much impossible to expect any sane human to keep track of memory perfectly. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] Garbage Collection of Places
Jack Firth wrote on 08/17/2015 03:21 PM: From my limited experience with C, I've learned it's pretty much impossible to expect any sane human to keep track of memory perfectly. That's a helpful impression. C must be feared and respected, before it can be tamed. That said, I think it's feasible for an sane, non-genius software engineer to do memory in C pretty much perfectly. They need experience, to have figured out viable conventions, to be very disciplined, to own the code, and to frequently think hard about how to do things in a manageable way. Anecdotally, lot of the security vulnerability memory bugs we see in, say, servers appear to just be either from someone who knows better but is overextending themselves, or someone who hasn't yet taken C difficulty as seriously as they need to. Then there is also the weakest link problem: in this kind of software, everyone could be perfect, but one person who is inexperienced/sloppy/fatigued/drugged/rushed can crash the system, in a way that unit testing won't catch. A poorly-manageable interface by one person can also lead to very disciplined other people making mistakes. Of course, there will pretty much always be bugs in any code, but C code doesn't have to be as buggy as it is. Neil V. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] garbage collection
whenever I get the itch to dream about gc, inevitably I end up at a paper or other by Bacon; seems like Bacon is one of the go-to guys on GC. random e.g. http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon04Unified.pdf -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] garbage collection
At Sat, 04 Jul 2015 17:55:29 -0400, Neil Van Dyke wrote: Neil Toronto wrote on 07/04/2015 05:29 PM: I don't know, but I want most of these things. I assume this is related to your earlier question about games? :) Partly. :) I've also been dealing with GC for years in non-game HTTP servers in which some requests are time-sensitive, and even just being able to temporarily inhibit GC (or temporarily greatly increase the GC trigger conditions) seems like it would help with some strategies. Possibly relevant in that space, see the ISMM'15 paper by Cody Cutler and Robert Morris, as applied to the HN server: http://conf.researchr.org/home/ismm-2015 (next-to-last link there) -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] garbage collection
Some high water mark on the stack might be another improvement - it would only need to scan above it for changes - but on a second thought: that wouldn't work or change wouldn't mean anything anymore because of the Lazy Sweep. Have you ever seen such a thing segfault after exactly 9000 cells and exactly 16 vectors. That was way too much C code fore me today ... Usually you don't say they leak - they conserve. Sounds much better, right? It's just the same. On 05/07/2015 20:36, Yuhao Dong wrote: One thing to note, though, is that collectors like Boehm do support marking regions of memory as not containing pointers. IIRC, Boehm is actually quite performant, ignoring the fact that it might leak (and usually leaks for functional languages) - it's generational and incremental. The Unity game engine actually uses it (it uses an old version of Mono, which can only use Boehm) Date: Sun, 5 Jul 2015 07:38:48 +0200 From: michael.tied...@o2online.de To: racket-users@googlegroups.com Subject: Re: [racket-users] garbage collection It's better to think about the malloc/gc duo as a memory manager. Some traditional approaches just seem awfully dumb and wrong like conservative marksweep. Treating every byte word on each and every call stack (every thread has one) as a valid reference to a Scheme object just doesn't scale well. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com mailto:racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] garbage collection
On 07/04/2015 05:26 PM, Neil Van Dyke wrote: Any plans for new interesting GC/memory features in Racket? For example, being able to inhibit GC for a time, being able to adjust the GC trigger parameters dynamically, different ways to minimize GC pauses or slowdown in the app behavior, real-time constraints on GC, special support to help programmers avoid/reduce garbage generation, etc.? Neil V. I don't know, but I want most of these things. I assume this is related to your earlier question about games? :) As far as I can tell, GC is the only thing keeping Racket from being suitable for making serious games. Neil ⊥ -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] garbage collection
Neil Toronto wrote on 07/04/2015 05:29 PM: I don't know, but I want most of these things. I assume this is related to your earlier question about games? :) Partly. :) I've also been dealing with GC for years in non-game HTTP servers in which some requests are time-sensitive, and even just being able to temporarily inhibit GC (or temporarily greatly increase the GC trigger conditions) seems like it would help with some strategies. As far as I can tell, GC is the only thing keeping Racket from being suitable for making serious games. Seems that way, on current-gen targets. On last-gen consoles and older mobile devices, I suppose that a programmer would have to get fancy to get past tight RAM footprint constraints, but fast RAM is so cheap now. I'm also interested in minimizing garbage generation. Right now, it seems to involve hard systems-programming-type thinking, like coding performance-sensitive stuff in C or C++ does (contrasted with naive C/C++ application programming), although the tools you're dealing with are different. Neil ⊥ Neil ∨ -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] garbage collection
On 07/04/2015 05:26 PM, Neil Van Dyke wrote: Any plans for new interesting GC/memory features in Racket? For example, being able to inhibit GC for a time, being able to adjust the GC trigger parameters dynamically, different ways to minimize GC pauses or slowdown in the app behavior, real-time constraints on GC, special support to help programmers avoid/reduce garbage generation, etc.? Neil V. I'd be interested to know where people think future GC benefits might come from. Does the GC need more research/work to be smarter, or do programmers need to manage the GC more explicitly? Thanks, Dave -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] garbage collection
On 05/07/2015 01:00, Neil Van Dyke wrote: Matthew Flatt wrote on 07/04/2015 06:40 PM: That is, unlike so many other things in our infrastructure, the GC is not so tangled with everything else that it would be difficult to change by itself. Granted, Good about GC not so tangled. I don't know the current state of GC research, nor what GC ideas PLTers could come up with, but maybe there is a doctoral dissertation, or at least some MS projects, waiting to happen. Separate from research activity, anyone know of existing off-the-shelf GCs that would be interesting to hook up to Racket? There is the Memory Pool System Kit Readme (but I didn't have any time to test it yet): https://www.ravenbrook.com/project/mps/ (Perhaps SCM or even hobbit has a better GC: http://people.csail.mit.edu/jaffer/SCM) It's better to think about the malloc/gc duo as a memory manager. Some traditional approaches just seem awfully dumb and wrong like conservative marksweep. Treating every byte word on each and every call stack (every thread has one) as a valid reference to a Scheme object just doesn't scale well. But computers are dumb machines anyway - fortunately they had a working power on/off switch back in those days when ... (nowadays you have to kill these beasts three times: pull the plug, remove the battery and wait at least 15 times n seconds for capacitors to ...) GC implementation can be fairly challenging on its own. Systems programming is hard, as you know. :) Neil V. That depends on the presence of the system manual and a good mental scheme of what one wants to achieve. I'd just start out with a flat addressing scheme implemented as one huge Scheme vector called RAM-emulation and try some algorithms in Scheme on it. Then segmentation and alignment and C pointers have never been the truth ... -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] garbage collection
Matthew Flatt wrote on 07/04/2015 06:40 PM: That is, unlike so many other things in our infrastructure, the GC is not so tangled with everything else that it would be difficult to change by itself. Granted, Good about GC not so tangled. I don't know the current state of GC research, nor what GC ideas PLTers could come up with, but maybe there is a doctoral dissertation, or at least some MS projects, waiting to happen. Separate from research activity, anyone know of existing off-the-shelf GCs that would be interesting to hook up to Racket? GC implementation can be fairly challenging on its own. Systems programming is hard, as you know. :) Neil V. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-users] garbage collection
I have no plans myself, but I think many applications would benefit from incremental collection. I also think that implementing an incremental GC for Racket is within reach --- as much as for any runtime system. That is, unlike so many other things in our infrastructure, the GC is not so tangled with everything else that it would be difficult to change by itself. Granted, GC implementation can be fairly challenging on its own. At Sat, 04 Jul 2015 17:26:00 -0400, Neil Van Dyke wrote: Any plans for new interesting GC/memory features in Racket? For example, being able to inhibit GC for a time, being able to adjust the GC trigger parameters dynamically, different ways to minimize GC pauses or slowdown in the app behavior, real-time constraints on GC, special support to help programmers avoid/reduce garbage generation, etc.? Neil V. -- You received this message because you are subscribed to the Google Groups Racket Users group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
