Julia garbage collection - question on status and future (and interaction when using with other languages)

[Páll Haraldsson]

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.

[Stefan Karpinski]

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.

[Joshua Ballanco]

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.

[Stefan Karpinski]

Yeah, I remember reading through that when he published it. Worth having another look at...

[Jonathan Malmaud]

On Tuesday, October 20, 2015 at 8:10:07 AM UTC-4, Páll Haraldsson 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?

I don't think the throughput of Go's GC is all that much better than better than Julia's - it's really its latency that is much better. But latency is fairly irrelevant for large batch jobs, which I suspect is what most people using Julia are concerned with.  

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..

You can use Libc.malloc if you want and it will work for fine: x=pointer_to_array(convert(Ptr{Float64}, Libc.malloc(10sizeof(Float64))), 10, false)

x[4]=5.2

...

You don't have disable the GC For this to work: the last parameter to 'pointer_to_array' indicates to the GC to not touch this memory.

 

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?).

Python is indeed reference-incremented. PyCall.jl manually increments and decrements the reference count of Python objects as they're created and freed.

Nothing in general though stops two different GCs from two different libraries (eg, libgo and libjulia) from running in the same process, each responsible for its own objects.

-- 

Palli.

[Yichao Yu]

You probably want to pass `true`, which will let the GC call `free` on
it automatically.

If you want to manually manage the pointer, you can pass `false`. Note
that this will
still allocate the `Array` object and pass `false` will probably not
make the GC run
less frequently.

Also note that `malloc/free` are not hard real time either, you
basically cannot have
any sort of memory allocation for that.

[Uwe Fechner]

You wrote:
"... note that `malloc/free` are not hard real time either, you

basically cannot have any sort of memory allocation for that. "

It is an old myth, that you cannot have any memory allocation for hard
real-time applications.

For me, and probably also for other people who do real-time simulations
or audio processing, lower latencies are always welcome.

Julia 0.4 is already much better then Julia 0.3, but the garbage collector
of Lua has still at least one order of magnitude less latency and is suitable
for "Hard real-time Control and Coordination of Robot Tasks".

Having (optionally) such a garbage collector in Julia would increase the user
base of Julia in the control community a lot.

For more details see:
https://github.com/JuliaLang/julia/issues/8543