Just to throw this out there… A number of years ago Mike Pall (creator and former maintainer of LuaJIT) outlined the beginnings of what seemed (to me at least) to be a very interesting variation on the tricolor GC: http://wiki.luajit.org/New-Garbage-Collector . Originally this was intended for LuaJIT v3.0, but given Mike’s recent decision to step down from LuaJIT maintenance, I’ve not heard what the status of further work on this idea is.
For a number of reasons I think the general idea of his “arena-based, quad-color incremental, generational, non-copying, high-speed, cache-optimized garbage collector” could potentially be a good fit for Julia. On October 20, 2015 at 15:10:12, Páll Haraldsson (pall.haralds...@gmail.com) wrote: A. I know Julia had stop the world garbage collection (GC) and changed to generational GC in 0.4 that is faster (I've seen 10x mentioned). As far as I know, there are no knobs to turn (except possible to just to turn if off..), and the GC algorithm isn't selectable (except by choosing the older 0.3 version, but seems to be no upside to that..). In Go 1.5, they changed their GC (and have some impressive latency (of GC) numbers): "To create a garbage collector for the next decade, we turned to an algorithm from decades ago. Go's new garbage collector is a concurrent, tri-color, mark-sweep collector, an idea first proposed by Dijkstra in 1978. This is a deliberate divergence from most "enterprise" grade garbage collectors of today, and one that we believe is well suited to the properties of modern hardware and the latency requirements of modern software. [..] At a higher level, one approach to solving performance problems is to add GC knobs, one for each performance issue. The programmer can then turn the knobs in search of appropriate settings for their application. The downside is that after a decade with one or two new knobs each year you end up with the GC Knobs Turner Employment Act. Go is not going down that path. Instead we provide a single knob, called GOGC" They are not going for hard real-time GC (a hard problem.. there are hard real-time JVMs), it seems, but soft real-time. Just do get an overview picture, do we have a similar implementation? Generational, pushes down latency, but I think the focus in Julia is still throughput more than latency (or both?). Without being an expert on Go (or Julia) it seems the languages are similar enough, that we could have a GC with the same properties if we just wanted. But maybe the Julia community just doesn't want to, or at least as a priority.. Would selectable GC algorithms with different properties be desirable? B. A side question, I've noticed Libc.malloc etc. Say for hard (or just soft) real-time stuff. It seems you could use manual memory management/malloc/free (and would have to disable the GC I guess?). Is it just crazy talk/very naive that you could run Julia without the GC continuously (say in a game)? Or is that the intention of Libc.malloc access? It seems the D language allows both GC and without, is Julia just similar, or "not recommended in Julia"? I do not know about Go, if it allows both.. C. An idea I had, and see the D guys also: http://dlang.org/garbage.html "Garbage collection should be implemented as a basic operating system kernel service. But since it is not, garbage collecting programs must carry around with them the garbage collection implementation." I do not really see that happening, even though memory is a global resource.., and ideally shouldn't be left to individual programs. Even just sharing a GC between say Julia and Go, I see not happening.., if you could get Julia and Go to work together. At best I see you could reuse Go code, as you can Java/JVM code, by calling it in a different process. Am I wrong? Strictly speaking, Python also has a GC and Julia works with Python in the same process. I'm not sure, but I think it may have to do with that Python uses reference counting (and then only full GC on top of that, is that part then effectively disabled by PyCall.jl?). -- Palli.
