5 ms·

> "The new background server GC in the .NET Framework 4.5 offloads much of the GC work associated with a full blocking collection to dedicated background GC thr

> "The new background server GC in the .NET Framework 4.5 offloads much of the GC work associated with a full blocking collection to dedicated background GC threads that can run concurrently with user code, resulting in much shorter (less noticeable) pauses. One customer reported a 70% decrease in GC pause times. " Concurrent garbage collection. Not that impressive in 2012. Java has had concurrent GC for at least a decade: JDK 1.2.2 Java had a switch for that in the late 90's already: -Xconcgc Use concurrent garbage collector (1.2.2_07+) JDK 1.4.2 http://java.sun.com/docs/hotspot/gc1.4.2/#4.3.%20When%20to%20Use%20the%20Concurrent%20Low%20Pause%20Collector|outline http://java.sun.com/docs/hotspot/gc1.4.2/#4.3.%20When%20to%2... also: http://research.sun.com/techrep/2000/abstract-88.html http://research.sun.com/techrep/2000/abstract-88.html The world has moved on: http://www.oracle.com/technetwork/java/javase/tech/g1-intro-jsp-135488.html http://www.oracle.com/technetwork/java/javase/tech/g1-intro-... http://researcher.watson.ibm.com/researcher/view_project_subpage.php?id=175 http://researcher.watson.ibm.com/researcher/view_project_sub...

kevingadd 14y ago
The world has moved on from using threads? Citation, please. ;)
- thebluesky 14y ago
  The world has moved on to more advanced concurrent GC implementations. Citations above.
  - thebluesky 14y ago
    Another citation from 4 years ago for good measure: http://www.oracle.com/us/technologies/java/oracle-jrockit-real-time-1517310.pdf http://www.oracle.com/us/technologies/java/oracle-jrockit-re...
tinco 14y ago
Many other languages still don't have it, as I understand it implementing a concurrent garbage collector is always impressive, whether you did it 20 years ago or now. I think this is indicative of their priorities. Java has had to fight the general opinion that it is a slow platform, so they built the best garbage collecting vm you could imagine. .Net has had to fight the opinion that it is just Java but on windows, so they built a multiple language oriented vm that enables language features so varied that even the standard java-like language C# rivals ruby and python in expression.
- thebluesky 14y ago
  > built a multiple language oriented vm that enables language features so varied that even the standard java-like language C# rivals ruby and python in expression Since the JVM happily runs Ruby, Groovy, Clojure, Python, Scala the point it moot. Aside from that C# does not rival Ruby in expressiveness.
  - tinco 14y ago
    The point is not moot that .Net was designed to support multiple languages, regardless of wether multiple languages run on the JVM. The JVM was designed to support only one language, Java, it is generic enough to run any language, but not efficiently or easily per se. The bytecode language is not standardized, and there is no standard assembler language for it. New features to the JVM are only added when they are required for Java. In contrast the instruction language and bytecode of .net are standardized and it has a standard assembler language, with an actual assembler and disassembler. Design of the CLR is actually driven by multiple languages like F# and the Iron projects. I'll bet you that the creators of JRuby and Clojure would love to have the features the CLR offers. I say it does rival ruby, you say it doesn't, good discussion.
    - thebluesky 14y ago
      The point my original post makes is that .NET having concurrent GC is not exactly groundbreaking. This doesn't have anything to do with the so-called expressiveness of C# relative to Ruby. >The bytecode language is not standardized, and there is no standard assembler language for it There is a formal spec here: http://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdf http://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdf > New features to the JVM are only added when they are required for Java. This is another false assumption: http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html http://blog.headius.com/2008/09/first-taste-of-invokedynamic... >I say it does rival [the expressiveness of] ruby, you say it doesn't, good discussion. Not really, is more like a generally accepted fact. e.g. Ruby typically uses 2-3x less code than C# to do the same thing: http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=csharp&lang2=yarv http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...
kenjackson 14y ago
You do realize that .NET has had concurrent garbage collection for a decade? It was workstation-only until recently (now?). But background GC is different than concurrent GC (in the .NET world) in that background GC can collect ephemeral generations in the middle of a gen 2 background collection (this was a restriction of concurrent GC in the past). Background GC is in the current version of .NET, but it sounds like they've extended background GC to the server now. While there are some great JVM GCs, I wouldn't walk away with the impression that the .NET folks are behind by any means.
- thebluesky 14y ago
  Fair point. Thanks for pointing that out. > "While there are some great JVM GCs, I wouldn't walk away with the impression that the .NET folks are behind by any means. " Can the .NET GC provide deterministic real-time collection pauses? e.g.: http://www.oracle.com/us/technologies/java/oracle-jrockit-real-time-1517310.pdf http://www.oracle.com/us/technologies/java/oracle-jrockit-re...
  - kenjackson 14y ago
    I doubt it. .NET GC tends to have a lot fewer knobs than the bigger Java JVMs.

kevingadd 14y ago

The world has moved on from using threads? Citation, please. ;)

thebluesky 14y ago
The world has moved on to more advanced concurrent GC implementations. Citations above.
- thebluesky 14y ago
  Another citation from 4 years ago for good measure: http://www.oracle.com/us/technologies/java/oracle-jrockit-real-time-1517310.pdf http://www.oracle.com/us/technologies/java/oracle-jrockit-re...

tinco 14y ago

Many other languages still don't have it, as I understand it implementing a concurrent garbage collector is always impressive, whether you did it 20 years ago or now. I think this is indicative of their priorities. Java has had to fight the general opinion that it is a slow platform, so they built the best garbage collecting vm you could imagine. .Net has had to fight the opinion that it is just Java but on windows, so they built a multiple language oriented vm that enables language features so varied that even the standard java-like language C# rivals ruby and python in expression.

thebluesky 14y ago
> built a multiple language oriented vm that enables language features so varied that even the standard java-like language C# rivals ruby and python in expression Since the JVM happily runs Ruby, Groovy, Clojure, Python, Scala the point it moot. Aside from that C# does not rival Ruby in expressiveness.
- tinco 14y ago
  The point is not moot that .Net was designed to support multiple languages, regardless of wether multiple languages run on the JVM. The JVM was designed to support only one language, Java, it is generic enough to run any language, but not efficiently or easily per se. The bytecode language is not standardized, and there is no standard assembler language for it. New features to the JVM are only added when they are required for Java. In contrast the instruction language and bytecode of .net are standardized and it has a standard assembler language, with an actual assembler and disassembler. Design of the CLR is actually driven by multiple languages like F# and the Iron projects. I'll bet you that the creators of JRuby and Clojure would love to have the features the CLR offers. I say it does rival ruby, you say it doesn't, good discussion.
  - thebluesky 14y ago
    The point my original post makes is that .NET having concurrent GC is not exactly groundbreaking. This doesn't have anything to do with the so-called expressiveness of C# relative to Ruby. >The bytecode language is not standardized, and there is no standard assembler language for it There is a formal spec here: http://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdf http://docs.oracle.com/javase/specs/jvms/se7/jvms7.pdf > New features to the JVM are only added when they are required for Java. This is another false assumption: http://blog.headius.com/2008/09/first-taste-of-invokedynamic.html http://blog.headius.com/2008/09/first-taste-of-invokedynamic... >I say it does rival [the expressiveness of] ruby, you say it doesn't, good discussion. Not really, is more like a generally accepted fact. e.g. Ruby typically uses 2-3x less code than C# to do the same thing: http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=csharp&lang2=yarv http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

kenjackson 14y ago

You do realize that .NET has had concurrent garbage collection for a decade? It was workstation-only until recently (now?). But background GC is different than concurrent GC (in the .NET world) in that background GC can collect ephemeral generations in the middle of a gen 2 background collection (this was a restriction of concurrent GC in the past). Background GC is in the current version of .NET, but it sounds like they've extended background GC to the server now. While there are some great JVM GCs, I wouldn't walk away with the impression that the .NET folks are behind by any means.

thebluesky 14y ago
Fair point. Thanks for pointing that out. > "While there are some great JVM GCs, I wouldn't walk away with the impression that the .NET folks are behind by any means. " Can the .NET GC provide deterministic real-time collection pauses? e.g.: http://www.oracle.com/us/technologies/java/oracle-jrockit-real-time-1517310.pdf http://www.oracle.com/us/technologies/java/oracle-jrockit-re...
- kenjackson 14y ago
  I doubt it. .NET GC tends to have a lot fewer knobs than the bigger Java JVMs.