Different selectable GCs would be a reasonable thing to have – it's unclear whether a single GC strategy can be sufficiently good to satisfy all possible requirements. That being said, the eventual standard Julia GC ought to be good enough for most use cases. I also dislike having too many knobs to turn.
On Tue, Oct 20, 2015 at 8:10 AM, 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. > > >
