search

gluon-lang / gluon

A static, type inferred and embeddable language written in Rust.
https://gluon-lang.org
MIT License
3.2k stars 145 forks source link

Generational GC #175

Open DemiMarie opened 7 years ago

DemiMarie commented 7 years ago

Gluon may want to get a generational moving GC, for performance.

Marwes commented 7 years ago

Since this is an optimization we definitely need to add more benchmarks for different workloads as a first step (its going to be an improvement but measuring how much is also important).

The current collector is not a straight a straight mark and sweep collector however as to some extent it is possible to limit how much is scanned in each collection by spawning new threads which may give similiar improvements to a generational collector https://github.com/Marwes/gluon/blob/e9f9de9734428da3e8afcf15d027146f1fb58174/vm/src/gc.rs#L110-L129.

brendanzab commented 7 years ago

Would be interesting to look into how best to do a GC, seeing as Gluon is meant to be pretty lightweight. We might want some way to control when collection happens, and prevent pauses where in critical places. Might want to look at how luajit does it. But bear in mind that we have the advantage of purity, which could make some things much simpler. (see GHC's collector)

DemiMarie commented 7 years ago

@brendanzab I did not know that Gluon is purely functional! Does it provide anything analogous to the IO or ST monad, or is it more like Erlang? I feel like mutable arrays – at least of primitive types – would be helpful for some tasks, such as building strings using more efficient data structures than linked lists. Haskell might be a good source of inspiration for libraries.

If everything is immutable, then concurrent compacting collection is easy.

brendanzab commented 7 years ago

Actually, I think we have references. Not sure if we will have that forever though... it would be easier to have a simple GC implementation without mutable state. We do have ST and IO. I would like us to get a nice effect system at some stage though, which will mean we can avoid the insanity of monad transformers and free monads - ugh.

brendanzab commented 7 years ago

Feel free to chat with us on https://gitter.im/Marwes/gluon by the way!

Marwes commented 7 years ago

For the record, a copying collector will cause some headaches when it comes to FFI (which will be common) since any pointers to gluon values passed to a native function must be in a stable location for at least the duration of the call. Been looking for a satisfying solution for this but so far I have only found problems.

DemiMarie commented 7 years ago

One solution is to only pass indirect handles (pointers to stack/heap allocated variables which can't move). This might require some ugly callback-based APIs OR a heap-allocated handle table. It may also be slower.

On Oct 13, 2016 11:03, "Markus Westerlind" notifications@github.com wrote:

For the record, a copying collector will cause some headaches when it comes to FFI (which will be common) since any pointers to gluon values passed to a native function must be in a stable location for at least the duration of the call. Been looking for a satisfying solution for this but so far I have only found problems.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gluon-lang/gluon/issues/175#issuecomment-253540389, or mute the thread https://github.com/notifications/unsubscribe-auth/AGGWB16goDtOb9Op36qNuSWw2IX7dYl9ks5qzkhcgaJpZM4KMQoM .

Marwes commented 7 years ago

Yeah, forcing the use of handles is far from ideal as it prevents passing &str, &[u8], etc directly to native functions which is really convenient.

To be fair, one could 'lock' a handle for a scope where it guarantees that no garbage collection may be run, and allow references to the value in the handle during that scope (such as with RefCell). But then we might as well not force the use of handles and just track whether a reference to some moveable data exists.

DemiMarie commented 7 years ago

What about generational quad-color mark-region GC? LuaJIT 3.0 will use it; the algorithm can be found somewhere on https://luajit.org.

On Oct 14, 2016 9:27 AM, "Markus Westerlind" notifications@github.com wrote:

Yeah, forcing the use of handles is far from ideal as it prevents passing &str, &[u8], etc directly to native functions which is really convenient.

To be fair, one could 'lock' a handle for a scope where it guarantees that no garbage collection may be run, and allow references to the value in the handle during that scope (such as with RefCell). But then we might as well not force the use of handles and just track whether a reference to some moveable data exists.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gluon-lang/gluon/issues/175#issuecomment-253798559, or mute the thread https://github.com/notifications/unsubscribe-auth/AGGWB10KZSYUfLEmte0QavKrCHYeBPOEks5qz4M7gaJpZM4KMQoM .

Marwes commented 7 years ago

Actually meant to add a link to it but I forgot. It has no implementation at all currently so its hard to tell how good it actually is, definitely interesting though. http://wiki.luajit.org/New-Garbage-Collector