Next generation of GC #4149

Kubuxu · 2017-08-17T16:22:08Z

Introduce GC rework with concurrent mark phase, tricolor set and rework
that in future will allow to incremental and/or concurrent mark and
sweep phases.

Currently it is made a bit difficult by direct pins.

It will also allow for reuse of colorset for improved performance and no
set reallocation.

From observations pre-rewrok it should reduce GC lock time by half as
about 50% of the time is spent in mark phase.
This is consistent with observations made after the implementation.

Kubuxu · 2017-08-17T16:24:02Z

@whyrusleeping direct pins are a bit of a problem currently. I can introduce this concept to tricolor set (make it four color) but it complicates things a lot. If we want to do it, I would also have to introduce one more color for internal pins (recursive but stopping on direct pins).

This version of GC should reduce the pause time by about 50% (or even more) but I can't make the sweep phase incremental without tackling the direct pins.

What do you think? Do you think it is ok to treat direct pins as best effort pins?

Kubuxu · 2017-08-18T11:56:13Z

Looks like core/coreunix.TestAddGCLive resolved itself. I will add more unittests soon. I would like to merge it soon as this works and we can figure out what to do with direct pins latter.

Short live feature branches. 😄

kevina · 2017-08-18T22:54:46Z

@Kubuxu so are direct pins being handled correctly right now? That is if there is nothing but a direct pin pinning a node, will all of its children still be garbage collected?

Kubuxu · 2017-08-18T23:29:36Z

Yes, I am currently using the same "cheat" as the older GC was using.
I don't like it, but it can be fixed in future as this isn't a new issue.

whyrusleeping · 2017-08-28T23:34:21Z

pin/gc/gc.go

+ finished, err := tri.EnumerateStep(ctx, bestEffortGetLinks, getLinks)
+ if err != nil {
+ output <- Result{Error: err}
+ criticalError = ErrCannotFetchAllLinks


we dont want to halt here? Whats the point in continuing?

To collect all errors like that. Instead of doing it one by one.

I would add that this is how I modified the GC to work in #3712. It make it easier for the user to figure out and fix the problem in one go.

whyrusleeping · 2017-08-29T00:00:56Z

pin/gc/gc.go

- output <- Result{Error: &CannotFetchLinksError{cid, err}}
+ // Reenumerate, fast as most will be duplicate
+ for {
+ finished, err := tri.EnumerateStep(ctx, getLinks, bestEffortGetLinks)


shouldnt we technically loop back up to the top of the function? technically you're supposed to just keep doing all that until you end up with an empty gray set, no?

I don't understand, Line 156 loops this until finished is true L162.

nvm, i see that we do loop up above.

whyrusleeping · 2017-08-29T00:01:55Z

pin/gc/gc.go

+ c, err := cid.Cast([]byte(v))
+ if err != nil {
+ // this should not happen
+ panic("error in cast of cid, inpossibru " + err.Error())


lol, probably want to un-meme this panic.

whyrusleeping · 2017-08-29T21:31:40Z

pin/gc/triset.go

+ // colors are per triset allowing fast color swap after sweep,
+ // the update operation in map of structs is about 3x as fast
+ // as insert and requres 0 allocations (keysize allocation in case of insert)
+ white, gray, black trielement


how is this different from just having constants?

#4149 (comment)

whyrusleeping · 2017-08-29T21:46:28Z

pin/gc/triset.go

+ colmap: make(map[string]trielement),
+ }
+
+ tr.freshColor = tr.white


something feels too complicated here...

It is future proofing for concurrent/incremental GC and lower overhead for re-GCing.

whyrusleeping · 2017-08-29T21:47:33Z

pin/gc/triset.go

+// InsertFresh inserts fresh item into a set
+// it marks it with freshColor if it is currently white
+func (tr *triset) InsertFresh(c *cid.Cid) {
+ e := tr.colmap[c.KeyString()]


e, ok := ...., right? i guess its just a uint8, and 0 is colorNull?

yes, 0 is null value

whyrusleeping · 2017-08-29T21:47:57Z

pin/gc/triset.go

+ cl := e.getColor()
+ // conditions are:
+ // 1. empty
+ // 2. while


s/while/white/ ?

whyrusleeping · 2017-08-29T21:50:01Z

pin/gc/triset.go

+ // select getLinks method
+ gL := getLinks
+ if strict {
+ gL = getLinksStrict


should the strict thing wrap the passed in getLinks? or maybe strict gets passed into getLinks?

whyrusleeping · 2017-08-29T22:00:28Z

pin/pin.go

+ {
+ Get: nilErr(p.InternalPins),
+ Strict: true,
+ Inernal: true,


whyrusleeping · 2017-08-29T22:01:32Z

pin/pinsource.go

+ Strict bool
+ // Direct marks the pinned object as the final object in the traversal
+ Direct bool
+ // Inernal marks the pin source which recursive enumeration should be


s/Inernal/Internal/

whyrusleeping · 2017-08-29T22:04:25Z

pin/gc/gc.go

+ close(output)
+ return output
+ }
+ addRoots(tri, pn, bestEffortRoots)

 go func() {


this goroutine should probably be its own function now

I am working on refactoring the GC to not be just a function but to have structure, so it will be changed.

whyrusleeping

This looks like it will be a really great improvement. Needs some cleanup I think, and probably more testing.

whyrusleeping · 2017-09-02T19:12:07Z

ref #3679

whyrusleeping · 2017-10-14T14:13:59Z

@Kubuxu update here?

Kubuxu · 2017-10-14T15:47:31Z

I will fix the conflict and it should be good for merge IIRC.

Introduce GC rework with concurrent mark phase, tricolor set and rework that in future will allow to incremental and/or concurrent mark and sweep phases. Currently it is made a bit difficult by direct pins. It will also allow for reuse of colorset for improved performance and no set reallocation. From observations pre-rewrok it should reduce GC lock time by half as about 50% of the time is spent in mark phase. This is consistent with observations made after the implementation. License: MIT Signed-off-by: Jakub Sztandera <[email protected]>

Stebalien

First pass. Mostly naming gripes (not really your fault but we should fix them. As-is, they'll confuse everyone who looks at this code except @whyrusleeping). I'll make another pass at the actual logic later tonight.

Stebalien · 2017-10-27T00:03:36Z

mfs/system.go

+func (kr *Root) PinSource() *pin.Source {
+ return &pin.Source{
+ Get: func() ([]*cid.Cid, error) {
+ err := kr.Flush()


I assume this won't trigger a recursive GC. We take a lock, right? However, this can cause us to go over the GC limit even more. We should probably document the fact that the "max repo size" isn't really the max.

We can also get in a bad state here where we can't flush (no disk space) and can't GC (can't flush). Not sure if we can do something about it now but...

There isn't much we can do here to recoverm I think, I need the actual state of the tree to perform the GC without data loss and I can't get it unless I flush the tree so it propagates the DAG updates.

Stebalien · 2017-10-27T00:17:52Z

pin/source.go

+ Direct bool
+ // Internal marks the pin source which recursive enumeration should be
+ // terminated by a direct pin
+ Internal bool


Can we have better names for these? I'm still confused, even after reading the comments.

I understand Strict and can't think of a better name.

Direct, IIRC, means non-recursive. That comment is technically correct but leads one to believe that it's a terminal pin in a DAG (Internal). Maybe invert this and use Recursive?

Internal -> Terminal? Or, maybe, Never (i.e., never pin)? Technically, it's a pin that's "internal" to a recursive pin but the name doesn't indicate anything about it being a "terminal" pin.

Also, "internal" is a rather big hammer. I guess it's a decent starting point (for, e.g., excluding large files globally) but, really, I'd like to be able to say, e.g., "pin A recursively but stop at X and Y" and have this pin not mess with other pins (that may want X/Y). Are pins like this expressible with this GC without major surgery? This isn't a reason to hold this PR (future work) up but we're going to want to be able to express constraints like this (and, eventually, arbitrary IPLD selectors for, e.g., ipfs-cluster).

Maybe invert this and use Recursive?

Direct works much nicer with default values (false).

"pin A recursively but stop at X and Y"

This might be a bit hard and we will have to think carefully about it. If we are able to sort the selectors according to their reach (some may be super-sets of others, so may have parts in common but then select different objects).

Big optimization that comes from color set (it was already implemented before but not explicit) is that we don't need to enumerate parts of the tree that were already enumerated

we're going to want to be able to express constraints like this

The color system allows for a lot of flexibility and having it here explicitly is IMO great step forward. Right now internal means "enumerate it last", which means it stops as elements that are already marked black (as they are supposedly fully enumerated but it is not the case in case of Direct pins).

EDIT: for selectors we might just have additional marking overhead of marking parts of the tree we already have marked.

I am note sure how extensive selectors are planned to be but being able to simplify selectors as we go deeper into the DAG to would allow for some nice GC optimizations in future. Shift as in: Selector on node A is X and on node B is Y, they have both selected node C (the same node) and they both simplify to Z. Then if we marked node C (and its children) with selector Z already while marking node A with selector X we don't have to remark children of node C with while marking node B with selector Y.

I hope I was able to convey myself.

Direct works much nicer with default values (false).
Right now internal means "enumerate it last", which means it stops as elements that are already marked black (as they are supposedly fully enumerated but it is not the case in case of Direct pins).

Oh, now I understand. Direct is an overloaded term/variable. Direct pins act as both non-recursive pins and stop-pins for internal pins. Is that right? At the very least, this algorithm needs to be documented somewhere. Personally, I'd prefer something like:

type PinKind int const ( PinRecursive PinKind = iota PinTerminal // Terminates an internal pin. PinInternal // Better name... PinSingle // one-of pins, add these last. ) // sort order is const order. struct PinSource { Kind PinKind // Can only be one type. Strict bool Get GetFunc }

Big optimization that comes from color set (it was already implemented before but not explicit) is that we don't need to enumerate parts of the tree that were already enumerated

So, I know of a way to make this work but it will be a lot of work and will require storing extra data; we can deal with it later. The TL;DR is to maintain a (semi-accurate) topological sort of the DAG and operate over that. We'll have to see how much extra work maintaining this datastructure will be but it will make executing IPLD queries much faster (IMO, it makes sense to optimize for this).

However, that's not something we'll need to deal with now.

Shift as in: Selector on node A is X and on node B is Y, they have both selected node C (the same node) and they both simplify to Z.

With topological sorting, I believe we can do this. Without it, we have the problem where we may have already marked C and it's children with respect to query X rooted at A by the time we get around to processing query Y rooted at B.

Stebalien · 2017-10-27T00:33:28Z

pin/source.go

+ if p.Direct {
+ v |= 1 << 1
+ }
+ if p.Internal {


Can internal be combined with the other two options?

It should not be combined with Direct as it might lead to not enumerating internal tree fully. I will add runtime panic (on PinSource registration) and comment as they should never really be used together.

It can be used with Strict without any issues.

I mostly care for documentation purposes.

Stebalien · 2017-10-27T00:38:59Z

pin/gc/triset.go

+ }
+}
+
+func (tr *triset) blacken(c *cid.Cid, strict trielement) {


Any reason this isn't exported while the other functions are?

blaken has to be handled with care (as it can lead to tree not being enumerated fully), ideally the GC itself would not be using it but it is a "workaround" for the Direct pins (in future we can make Direct pins separate color and this will allow fully concurrent or incremental GC).

whyrusleeping · 2017-10-28T22:03:47Z

pin/gc/gc.go

- elock.Done()
- elock = log.EventBegin(ctx, "GC.locked")
- emark := log.EventBegin(ctx, "GC.mark")
+type gctype struct {


maybe a more descriptive name? like triColorGc?

whyrusleeping · 2017-10-28T22:27:23Z

pin/gc/triset.go

+// InsertFresh inserts fresh item into a set
+// it marks it with freshColor if it is currently white
+func (tr *triset) InsertFresh(c *cid.Cid) {
+ e := tr.colmap[c.KeyString()]


You probably want to bind c.KeyString() to a variable and reuse it.

whyrusleeping · 2017-10-28T22:33:11Z

Still reviewing, but doesnt this changeset make it so that we now hold every single cid in the blockstore in memory? (as opposed to currently just holding the pinned objects set)

Kubuxu · 2017-10-29T08:06:51Z

You are right, it does. This is Memory vs Time needed during locked phase compromise. In future we will have to probably keep even the pinned set on disk. I can change if you think it is needed.

Stebalien

Another pass. Sorry, I still haven't fully read everything.

Stebalien · 2017-10-31T04:18:27Z

pin/gc/triset.go

+// 8bit color is overkill, 3 bits would be enough, but additional functionality
+// will probably increase it future
+// if ever it blows over 64bits total size change the colmap in triset to use
+// pointers onto this structure


I'd not use pointers, even if this grows large. Allocations are expensive and we already have to do a lot here.

Stebalien · 2017-10-31T04:23:34Z

pin/gc/gc.go

+ return
+ }
+ for _, c := range cids {
+ if !r.Direct {


I'm not sure how good the go optimizer is but, assuming it isn't, I'd invert this. That is, put the if statement on the outside and have two loops, one in each branch.

Stebalien · 2017-10-31T04:24:36Z

pin/gc/gc.go

+ tri.InsertGray(c, r.Strict)
+ } else {
+ // this special case prevents incremental and concurrent GC
+ tri.blacken(c, enumStrict)


Don't we have to wait until after we've re-enumerated before we can do this? Otherwise, we can blacken a direct pin before we've explored it.

Good catch.

Stebalien · 2017-10-31T04:26:18Z

pin/gc/gc.go

+// Any calls to AddPinSource have to be done before any calls to Run.
+func (g *gctype) AddPinSource(s ...pin.Source) error {
+ g.roots = append(g.roots, s...)
+ sort.SliceStable(g.roots, func(i, j int) bool {


Instead of sorting these, have you considered just storing them in separate arrays/sets? IMO, that would be simpler.

Stebalien · 2017-10-31T04:38:02Z

pin/gc/triset.go

+func (tr *triset) EnumerateStep(ctx context.Context, getLinks dag.GetLinks, getLinksStrict dag.GetLinks) (bool, error) {
+ var c *cid.Cid
+ var e trielement
+ for next := true; next; next = e.getColor() != tr.gray {


Uh... is this a do { } while () loop? Why not just use a for {} loop and put an if e.getColor() != tr.gray { break } at the end of it?

Stebalien · 2017-10-31T05:03:10Z

pin/source.go

+ Direct bool
+ // Internal marks the pin source which recursive enumeration should be
+ // terminated by a direct pin
+ Internal bool


Direct works much nicer with default values (false).
Right now internal means "enumerate it last", which means it stops as elements that are already marked black (as they are supposedly fully enumerated but it is not the case in case of Direct pins).

Oh, now I understand. Direct is an overloaded term/variable. Direct pins act as both non-recursive pins and stop-pins for internal pins. Is that right? At the very least, this algorithm needs to be documented somewhere. Personally, I'd prefer something like:

type PinKind int const ( PinRecursive PinKind = iota PinTerminal // Terminates an internal pin. PinInternal // Better name... PinSingle // one-of pins, add these last. ) // sort order is const order. struct PinSource { Kind PinKind // Can only be one type. Strict bool Get GetFunc }

Big optimization that comes from color set (it was already implemented before but not explicit) is that we don't need to enumerate parts of the tree that were already enumerated

So, I know of a way to make this work but it will be a lot of work and will require storing extra data; we can deal with it later. The TL;DR is to maintain a (semi-accurate) topological sort of the DAG and operate over that. We'll have to see how much extra work maintaining this datastructure will be but it will make executing IPLD queries much faster (IMO, it makes sense to optimize for this).

However, that's not something we'll need to deal with now.

Shift as in: Selector on node A is X and on node B is Y, they have both selected node C (the same node) and they both simplify to Z.

With topological sorting, I believe we can do this. Without it, we have the problem where we may have already marked C and it's children with respect to query X rooted at A by the time we get around to processing query Y rooted at B.

Stebalien · 2017-10-31T05:15:33Z

pin/gc/triset.go

+
+// this const is used to enable runtime check for things that should never happen
+// will cause panic if they happen
+const pedantic = true


Stebalien · 2017-10-31T05:18:58Z

pin/gc/gc.go

- gcs.Add(k)
+ // Reenumerate, fast as most will be duplicate
+ for {
+ finished, err := tri.EnumerateStep(ctx, getLinks, bestEffortGetLinks)


Are getLinks and bestEffortGetLinks flipped?

kevina · 2017-10-31T18:53:18Z

@whyrusleeping said:

Still reviewing, but doesnt this changeset make it so that we now hold every single cid in the blockstore in memory? (as opposed to currently just holding the pinned objects set)

@Kubuxu said:

You are right, it does. This is Memory vs Time needed during locked phase compromise. In future we will have to probably keep even the pinned set on disk. I can change if you think it is needed.

This concerns me. For very large repositories this could be a problem. This could also be a problem if the in-memory data structures are larger. Do we have some sort of estimate on the memory usage with the orig and this GC for a large repository that is say 20% pinned, 50% pinned, 80% pinned?

whyrusleeping · 2017-10-31T18:55:24Z

Kinda makes me think we should have a --light mode where we use bloom filters instead of full sets.

Kubuxu · 2017-11-01T20:14:52Z

pin/gc/gc.go

+ return unlocker, elock
+}
+
+func addRoots(tri *triset, pn pin.Pinner, bestEffortRoots []*cid.Cid) {


This is cruft, removed in working branch (not pushing yet because I am afraid of loosing code comments).

I'd just push it now. The comments should stay.

Kubuxu · 2017-11-01T23:48:56Z

@kevina

Do we have some sort of estimate on the memory usage with the orig and this GC for a large repository that is say 20% pinned, 50% pinned, 80% pinned?

Worst case scenario it will be total size of all keys + number of keys * 1b.

Kubuxu · 2017-11-01T23:50:42Z

So in case of sha-256 and CIDv1 it would be about 28M keys per GiB.

Stebalien · 2017-11-02T00:50:51Z

pin/gc/gc.go

+ if !ok {
+ break loop
+ }
+ tri.InsertFresh(c)


I think there's a bug here (well, not here but this is where I started writing the comment...). Specifically, what happens if I add a node (e.g., from the network) after the above EnumerateStep calls? I believe it will be garbage collected even if it shouldn't be.

The solution, as far as I can tell, is to leave unexplored gray nodes in the gray set and try to re-explore them after taking the GC lock.

Ideally, we'd have some nice way to subscribe to events from the blockstore so we could just process new blocks...

InsertFresh in this inserts as white. I will change it to InsertWhite for time being.

what happens if I add a node (e.g., from the network) after the above EnumerateStep calls

If it is pinned it will be enumerated and marked black by enumeration when the lock is taken.

You sure? I'm pretty sure those roots won't be re-enumerated because they're already black. I'm worried about the a (pinned) -> b -> c (added late) case. That is, a is a pin root and we only add c to the repo after the initial enumeration. I believe, in this case, we'll never mark c as black because a is already black.

b can't be black as it references a white (or null, treated as white) node c.

If a is pinned strictly (by recursive pin) then marking b would fail with an error.
if a is pinned non-strictly (by Files API) then it is still better than it was before.

b can't be black as it references a white (or null, treated as white) node c.

No, if you have b, you'll definitely blacken it. getLinks will succeed because you have it (even if you don't have c). Yes, if you're pinning strictly you'll fail out.

if a is pinned non-strictly (by Files API) then it is still better than it was before.

It's still not correct. Actually, can't you just add the white nodes first (before you enumerate reachable nodes)? IIRC, that's how this algorithm usually works (for this reason).

No, if you have b, you'll definitely blacken it. getLinks will succeed because you have it (even if you don't have c). Yes, if you're pinning strictly you'll fail out.

Yes, then the c will be marked gray and processed in the next EnumerateStep.

can't you just add the white nodes first (before you enumerate reachable nodes)?

I treat every node that doesn't exist in the tricolor set as white. They are being added here as it reduced time needed what we take the repo's GC lock.

Not if it isn't strict. In that case, it will be marked gray, in the first EnumerateStep and then removed (and assumed to have no children).

They are being added here as it reduced time needed what we take the repo's GC lock.

That doesn't mean you can't add them before the first enumerate step. Then, you'd follow the standard algorithm of moving nodes from the white set to the gray set to the black set until the gray set is empty.

That is true, let's do that.

frrist · 2017-11-02T01:01:32Z

pin/gc/gc.go

- return err
+ defer close(output)
+
+ bestEffortGetLinks := func(ctx context.Context, cid *cid.Cid) ([]*node.Link, error) {


Can we combine this with the below getLinks function, using a flag to handle the err != dag.ErrNotFound case?

You are right, two types of GetLinks is cruft from previous (or currently used GC), I should had eliminated it.

frrist · 2017-11-02T01:10:19Z

pin/gc/triset.go

+ if len(tr.grays) == 0 {
+ return true, nil
+ }
+ // get element from top of queue


I think we mean to say get element from stack here - based on line 54 of this file.

Kubuxu · 2017-11-02T02:28:25Z

@whyrusleeping @kevina for future we might just switch to using something like badger for GC, especially if we nail down incremental/concurrent GCing. In case of extremely bit repos the GC process could take days so having it done incrementally and being resumable would be a requirement.

Stebalien · 2017-11-02T03:39:47Z

pin/gc/gc.go

 }

- for _, k := range pn.DirectKeys() {
- gcs.Add(k)
+ // Reenumerate, fast as most will be duplicate


Not true for Internal pins as far as I can tell. Do we use them a lot?

No, there will be very little as they are used only for building sharding of the pinset.

Stebalien · 2017-11-02T03:42:51Z

pin/gc/gc.go

+
+func getGCLock(ctx context.Context, bs bstore.GCBlockstore) (bstore.Unlocker, *logging.EventInProgress) {
+ elock := log.EventBegin(ctx, "GC.lockWait")
+ unlocker := bs.GCLock()


Do we actually need to lock the entire repo or can we just lock the pins/roots?

Yes, to prevent for example blocks for being added. In future we can have incremental GC where those pauses (this is what taking major lock by GC is called) are short but spread over time.

Or to highlight the problem more cleanly, to prevent ipfs add from adding blocks that are referencing some white marked nodes.

I see. I was thinking that that case might be equivalent to doing the GC before adding the block but that's not true because the fact that we had both blocks at the same time can be observed. Having a GCed system where something can go from unreachable (by a root) to reachable in the middle of a GC run is weird.

parkan · 2018-12-10T21:58:59Z

seems like there is some overlap with #5765

Stebalien · 2018-12-10T22:30:13Z

Possibly. The primary issue with this PR is that it loads the entire pin-set into memory. That's not going to scale.

parkan · 2018-12-10T23:31:42Z

@Stebalien that makes sense

let's close this with that explanation, unless you or @Kubuxu have objections

there's a lot of interest in improved GC, but it seems that this branch has diverged enough that basing any further work on it will probably be counterproductive

Stebalien · 2018-12-11T00:28:46Z

SGTM. However, let's not delete this branch (the logic is still good).

Kubuxu requested review from whyrusleeping and Stebalien August 17, 2017 16:28

Kubuxu added the status/in-progress In progress label Aug 17, 2017

Kubuxu force-pushed the feat/gc/next-gen branch from 4d6702e to 4e8803f Compare August 17, 2017 17:09

Kubuxu requested a review from kevina August 18, 2017 11:53

whyrusleeping reviewed Aug 28, 2017

View reviewed changes

whyrusleeping reviewed Aug 29, 2017

View reviewed changes

pin/gc/triset.go Outdated

cl := e.getColor()

// conditions are:

// 1. empty

// 2. while

Copy link

Member

whyrusleeping Aug 29, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/while/white/ ?

whyrusleeping reviewed Aug 29, 2017

View reviewed changes

pin/pin.go Outdated

{

Get: nilErr(p.InternalPins),

Strict: true,

Inernal: true,

Copy link

Member

whyrusleeping Aug 29, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo

whyrusleeping reviewed Aug 29, 2017

View reviewed changes

whyrusleeping mentioned this pull request Sep 3, 2017

More intelligent blockstore garbage collection #3092

Open

Kubuxu force-pushed the feat/gc/next-gen branch from cafb902 to d292196 Compare September 11, 2017 11:02

Kubuxu mentioned this pull request Oct 12, 2017

GC is slower with badger (with syncwrites enabled) #4298

Open

whyrusleeping added the P0 Critical: Tackled by core team ASAP label Oct 17, 2017

whyrusleeping mentioned this pull request Oct 17, 2017

go-ipfs high priority issue list #4312

Closed

18 tasks

Kubuxu force-pushed the feat/gc/next-gen branch from af03696 to deec07d Compare October 18, 2017 13:30

ghost added the status/in-progress In progress label Oct 26, 2017

Kubuxu force-pushed the feat/gc/next-gen branch from dc27017 to e26bae6 Compare October 26, 2017 13:25

Stebalien reviewed Oct 27, 2017

View reviewed changes

Kubuxu requested a review from whyrusleeping October 27, 2017 01:22

whyrusleeping reviewed Oct 28, 2017

View reviewed changes

Stebalien requested changes Oct 31, 2017

View reviewed changes

Kubuxu commented Nov 1, 2017

View reviewed changes

Stebalien reviewed Nov 2, 2017

View reviewed changes

frrist reviewed Nov 2, 2017

View reviewed changes

Stebalien reviewed Nov 2, 2017

View reviewed changes

Stebalien closed this Dec 11, 2018

ghost removed the status/in-progress In progress label Dec 11, 2018

gammazero mentioned this pull request Nov 4, 2020

[META] Garbage Collection Enhancement/Rework #7752

Open

hacdias deleted the feat/gc/next-gen branch May 9, 2023 10:54

Next generation of GC #4149

Next generation of GC #4149

Conversation

Kubuxu commented Aug 17, 2017 • edited Loading

Kubuxu commented Aug 17, 2017 • edited Loading

Kubuxu commented Aug 18, 2017

kevina commented Aug 18, 2017

Kubuxu commented Aug 18, 2017

Choose a reason for hiding this comment

Kubuxu Aug 28, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

whyrusleeping left a comment

Choose a reason for hiding this comment

whyrusleeping commented Sep 2, 2017

whyrusleeping commented Oct 14, 2017

Kubuxu commented Oct 14, 2017

Stebalien left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kubuxu Oct 27, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kubuxu Oct 27, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kubuxu Oct 27, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

whyrusleeping commented Oct 28, 2017

Kubuxu commented Oct 29, 2017 • edited Loading

Stebalien left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kevina commented Oct 31, 2017

whyrusleeping commented Oct 31, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kubuxu commented Nov 1, 2017

Kubuxu commented Nov 1, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Kubuxu commented Aug 17, 2017 •

edited

Loading

Kubuxu commented Aug 17, 2017 •

edited

Loading

Kubuxu Aug 28, 2017 •

edited

Loading

Stebalien left a comment •

edited

Loading

Kubuxu Oct 27, 2017 •

edited

Loading

Kubuxu Oct 27, 2017 •

edited

Loading

Kubuxu Oct 27, 2017 •

edited

Loading

Kubuxu commented Oct 29, 2017 •

edited

Loading