News for hackers. Stuff that matters.
Re:Crystal: Fast as C, Slick as Ruby by jerven on Thursday August 04, 2016 @05:53AM (#12224475)
For the JVM Shenandoah GC [1] can do so as well (or at least very low consistent pauses) and is available via EA builds or the OpenJDK in fedora 24 [2].

This is with pointer happy java code, not with special effort to have pointer less data.

[1] http://openjdk.java.net/jeps/189 [2] https://fedoraproject.org/wiki/Changes/Shenandoah

Re:Crystal: Fast as C, Slick as Ruby by quotemstr on Thursday August 04, 2016 @12:15PM (#12226537)
> The key to performing concurrent evacuation is having the Java Threads and the GC threads agree on the location of objects. This is accomplished in Shenandoah by the use of a Brooks forwarding pointer. All reads by the Java Threads indirect through this forwarding pointer. All writes to objects in targeted regions must first copy the object and then write to the object in its new location.

I'm a bit surprised that indirection is efficient enough to be worth the trouble (since you need reads and writes to branch for the indirected-object case), but I can't argue with results.

Re:Crystal: Fast as C, Slick as Ruby by mike_hearn on Friday August 05, 2016 @09:00AM (#12231921)
Bear in mind that's a conceptual description. The read/write barriers are implemented as compiler node graphs and thus can be optimised.