You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 8, 2023. It is now read-only.
Currently we explicitly mark + store indirect pins. @tv42 brought up that we perhaps should mark-and-sweep. the discussion on ipfs/kubo#1274 puts me strongly in favor of that approach. let's use this note to coordinate discussion + potential upgrades to do.
The text was updated successfully, but these errors were encountered:
jbenet
changed the title
Repo GC stragtegy.
Repo GC strategy.
May 29, 2015
I've pondered this a bunch for https://bazil.org/ , though I'm not at the point where I'd have written anything yet. Quick notes on what differentiates CAS GC from normal:
immutable objects
you can memoize all referred objects of a root with bloom filters etc
can view storage as append-only; links can only point backward in time
if you rely on time-based grace for new objects, linking to an object must refresh that timer
Good background material to read:
Erlang GC
papers on the Foundation project
the Train algorithm
There's tons more there, but I've barely scratched the surface myself.
@whyrusleeping @wking @tv42
Currently we explicitly mark + store
indirect
pins. @tv42 brought up that we perhaps should mark-and-sweep. the discussion on ipfs/kubo#1274 puts me strongly in favor of that approach. let's use this note to coordinate discussion + potential upgrades to do.The text was updated successfully, but these errors were encountered: