Assault by GC - Hackdot

Re:Assault by GC by stcredzero on Monday October 24, 2011 @12:50PM (#3150407)

GEN-2 is the final lurking place for all your long-lived data..., checking GEN-2 is a “stop the world” event – it (usually briefly) pauses your code, and does what it needs to. Now imagine you have a huge set of objects which will never be available to collect

For many years now, some Smalltalk VMs have had "permspace." You just send a message to a long lived object, and it's moved to a different part of memory considered permanent, and the GC never looks at it. No structs. Just call a function on the permanent objects. Since it's in a different space, this is also very efficient for the VM, since identifying a permanent object is just a comparison of addresses.

[ Parent | on HN ]

Re:Assault by GC by JoachimSchipper on Monday October 24, 2011 @03:10PM (#3151053)

Wouldn't the GC still need to check for references from permspace objects? (It's probably still a noticeable performance boost.)

[ Parent | on HN ]

Re:Assault by GC by eru on Monday October 24, 2011 @03:33PM (#3151179)

Your language could disallow references from permspace to normal space. Or even make permspace objects immutable.

[ Parent | on HN ]

Re:Assault by GC by fpgeek on Monday October 24, 2011 @10:31PM (#3152564)

Or just track the (presumably few) mutations of permspace objects for special handling. In that case, permspace effectively becomes an infinitely long-lived generation that is never collected, only used as a source of roots.

[ Parent | on HN ]

Re:Assault by GC by stcredzero on Tuesday October 25, 2011 @09:13AM (#3153925)

Bingo. I should have written "GC only uses it as a source of roots."

[ Parent | on HN ]

Re:Assault by GC by dmpk2k on Monday October 24, 2011 @07:45PM (#3152117)

Some Schemes have this too. I'd be surprised if an industrial VM, like the CLR, didn't support this.

[ Parent | on HN ]