Yeah, I remember reading through that when he published it. Worth having another look at...
On Fri, Oct 23, 2015 at 6:59 AM, Joshua Ballanco <[email protected]> wrote: > 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 ( > [email protected]) 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. > > >
