Michael Knyszek

> Hi, will the new GC implement a method to remove/re-add an object completely from the allocated objects list? No, that's out of scope. This is just changing the implementation,...

With the release of Go 1.25 RC1, it should be substantially easier to try out Green Tea, since a tip toolchain is no longer needed. I updated the [comment containing...

Ugh, my apologies. I ran the command in the instructions myself, but with a toolchain that understood the `GOEXPERIMENT`. I will fix up the instructions. Thanks for reporting so promptly!...

@bep A regression that large is very unlikely to be the result of the garbage collector becoming wildly slow. Plus, the large object scanning path hasn't changed at all, so...

> Hello everyone, when do you think this gc can be officially put into golang as a formal prod environment? [@mknyszek](https://github.com/mknyszek) It's an experiment that's part of an upcoming official...

> [@bep](https://github.com/bep) A regression that large is very unlikely to be the result of the garbage collector becoming wildly slow. Plus, the large object scanning path hasn't changed at all,...

@bep Here's some more data. `gctrace` without Green Tea: ``` gc 1 @0.005s 0%: 0.016+0.59+0.042 ms clock, 1.0+0.11/0.89/0+2.7 ms cpu, 4->4->1 MB, 4 MB goal, 0 MB stacks, 0 MB...

> > If it's watching runtime metrics to make decisions, then a faster GC (leading to less floating garbage, hnce less of a ballast, etc. etc.) could lead to very...

I've essentially ruled out the "more memory is zeroed" hypothesis. I patched in some code to count the number of zeroed bytes, and the difference is

> If it's watching runtime metrics to make decisions, then a faster GC (leading to less floating garbage, hnce less of a ballast, etc. etc.) could lead to very different...