Hacker News Reader

Comment by badlogic | Hacker News Reader

How's the managed runtime implemented (GC, memory model, etc.)? How did you get rid of JVM and JRE class library dependencies of Scala? What's the debugging story? I'd be great if this kind of info found its way onto th website. Is this in any way related to vmkit?

Excited about this, keep up the great work!

View on HN

> How's the managed runtime implemented (GC, memory model, etc.)?

In a first release we're going to use Boehm GC. That's just a stepping stone, not a long-term strategy. Stay tuned for news on this front.

> How did you get rid of JVM and JRE class library dependencies of Scala?

We're reimplementing / porting from Apache Harmony all the things we need.

> What's the debugging story?

We're going to integrate with lldb.

> Is this in any way related to vmkit?

Not related in any way, apart from being based on LLVM.

> We're reimplementing / porting from Apache Harmony all the things we need.

Doesn't that create licensing issues? You already seem to have code from Harmony in the project, but the project's license is neither Apache nor does it mention it.

Additionally, won't that cause trouble with Oracle, considering the lawsuit against Google?

We're are going to have an official guide on licensing in next few days.

> We're reimplementing / porting from Apache Harmony all the things we need.

Would GCJ be any use? They had native compilation over a decade ago.

(Although developers moved on to IcedTea, iirc)

Hans Boehm's GC is actually really, really good. Before you embark on a massive engineering effort that will likely lead to little gain and a lot of pain, I would measure the overheads very carefully. I am not at all convinced precise GCs buy you that much over the Boehm GC for most apps, and they fundamentally kill interop with C code.

(I can't recall for sure but I believe I had this conversation with Martin in a taxi ride not too long ago :)

Mono was a long time on Hans Boehm's GC and despite feeding it a lot of metadata never got satisfying results with it. Eventually they replaced it with a custom GC (SGen).

Looks like it's currently using the Boehm–Demers–Weiser conservative garbage collector. In scala-native/rtlib/src/main/resources/rt.cpp it includes gc.h and allocates memory using GC_malloc, i.e. not in precise mode.

Ouch.

The garbage collector is typically the most difficult part of a language implementation, so I'm not surprised. On the other hand, a simple GC can be sufficient for many projects.

They can still replace it later once they're further along with the rest of the implementation. I doubt they'll keep it.

Reply on news.ycombinator.com