Hacker News new | comments | show | ask | jobs | submit login

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.

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

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

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.

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

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

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact