4 ms·

Interesting that they are publishing the algorithm before implementing it. I wish more people did this. This way, if the algorithm doesn't work out, we'll hav

Interesting that they are publishing the algorithm before implementing it. I wish more people did this. This way, if the algorithm doesn't work out, we'll have some way of knowing. If they hadn't published the algorithm, tried it, and then abandoned it, then nobody would have any way of knowing that there had been a negative result. I don't have high hopes for this algorithm, because my intuition is that transactions aren't common enough to make a big difference. Looking forward to seeing the implementation and empirical data.

deleted 10y ago
[deleted]
sctb 10y ago
Another excellent write-up ahead of implementation: http://wiki.luajit.org/New-Garbage-Collector http://wiki.luajit.org/New-Garbage-Collector.
- fsfod 10y ago
  While trying to implement the new LuaJIT GC one of the things I tested adding early on was support for explicitly creating arenas from Lua and setting the 2 active arenas allocations happen from to support this kind of allocation patten. The minor GC mode also work well with this patten only having to touch modified objects and only sweeping away fresh white objects.
twotwotwo 10y ago
"Transactions" here doesn't mean roll-back-able units like in a database, just small bits of code that terminate (and, the authors hope, leave some garbage behind that you can clean up without scanning a bunch of RAM). Request-oriented collector would have been about as good a name. This is kind of a spin on generational collection, built around the observation that a lot of Go programs are HTTP/RPC/whatever servers.
- Jweb_Guru 10y ago
  It's also not exactly original to Go... the Ur language, for instance, employs a request-oriented collector (arguably, though the documentation claims it does not use garbage collection).
  - ezyang 10y ago
    Ur/Web uses region based memory management. Details are in http://adam.chlipala.net/papers/UrWebICFP15/ http://adam.chlipala.net/papers/UrWebICFP15/ search for "memory management".
    - Jweb_Guru 10y ago
      Thanks for the link! I was actually at that talk :) To quote from the relevant slide: * Transactions are integrated into Ur/Web at a deep level, so, whenever we run out of space, we can always abort the execution, allocate a larger heap, and restart. * As a further optimization, we use region-based memory management, inferring a stack structure to allow freeing whole sets of objects at key points during execution.
- jcrites 10y ago
  Yes, I've often considered that this is probably how Java's collector tends to behave in practice, particularly with the eden and young generation. If you're handling an RPC call that returns promptly, it's probable that all of the structures you've allocated on behalf of that call will be part of the young generation and can be efficiently collected. Indeed, it's one reason why I've assumed that Rust's memory model might turn out to work well for services (not having had a chance to try it): there's a clear entry point where the request begins and ends, and all of the memory allocated from that point onward can be discretely tracked and freed upon completion. In the services that I've built, the majority of the allocations are for these short-lived objects, with a relatively smaller amount being related to long-lived objects like connections to other services or caches. I imagine that websites and services might behave like this, though I haven't studied it carefully. I'll be interested to see how transaction-specific optimization turns out, and whether it can do better than a general purpose generational collector.
sebcat 10y ago
> I don't have high hopes for this algorithm, because my intuition is that transactions aren't common enough to make a big difference. Every served request by net/http#Server, net/rpc#Server and similar gets its own goroutine. That is to say, its own transaction. Memory allocated within that transaction will be associated with it. Should make a positive difference for server software.

deleted 10y ago

[deleted]

sctb 10y ago

Another excellent write-up ahead of implementation: http://wiki.luajit.org/New-Garbage-Collector http://wiki.luajit.org/New-Garbage-Collector.

fsfod 10y ago
While trying to implement the new LuaJIT GC one of the things I tested adding early on was support for explicitly creating arenas from Lua and setting the 2 active arenas allocations happen from to support this kind of allocation patten. The minor GC mode also work well with this patten only having to touch modified objects and only sweeping away fresh white objects.

twotwotwo 10y ago

"Transactions" here doesn't mean roll-back-able units like in a database, just small bits of code that terminate (and, the authors hope, leave some garbage behind that you can clean up without scanning a bunch of RAM). Request-oriented collector would have been about as good a name. This is kind of a spin on generational collection, built around the observation that a lot of Go programs are HTTP/RPC/whatever servers.

Jweb_Guru 10y ago
It's also not exactly original to Go... the Ur language, for instance, employs a request-oriented collector (arguably, though the documentation claims it does not use garbage collection).
- ezyang 10y ago
  Ur/Web uses region based memory management. Details are in http://adam.chlipala.net/papers/UrWebICFP15/ http://adam.chlipala.net/papers/UrWebICFP15/ search for "memory management".
  - Jweb_Guru 10y ago
    Thanks for the link! I was actually at that talk :) To quote from the relevant slide: * Transactions are integrated into Ur/Web at a deep level, so, whenever we run out of space, we can always abort the execution, allocate a larger heap, and restart. * As a further optimization, we use region-based memory management, inferring a stack structure to allow freeing whole sets of objects at key points during execution.
jcrites 10y ago
Yes, I've often considered that this is probably how Java's collector tends to behave in practice, particularly with the eden and young generation. If you're handling an RPC call that returns promptly, it's probable that all of the structures you've allocated on behalf of that call will be part of the young generation and can be efficiently collected. Indeed, it's one reason why I've assumed that Rust's memory model might turn out to work well for services (not having had a chance to try it): there's a clear entry point where the request begins and ends, and all of the memory allocated from that point onward can be discretely tracked and freed upon completion. In the services that I've built, the majority of the allocations are for these short-lived objects, with a relatively smaller amount being related to long-lived objects like connections to other services or caches. I imagine that websites and services might behave like this, though I haven't studied it carefully. I'll be interested to see how transaction-specific optimization turns out, and whether it can do better than a general purpose generational collector.

sebcat 10y ago

> I don't have high hopes for this algorithm, because my intuition is that transactions aren't common enough to make a big difference. Every served request by net/http#Server, net/rpc#Server and similar gets its own goroutine. That is to say, its own transaction. Memory allocated within that transaction will be associated with it. Should make a positive difference for server software.