Hacker News Reader

Comment by dkhenry | Hacker News Reader

So now I am really wondering. What is the sub java parts of the JVM that need to be implemented to completely free Scala from the JVM ( i.e. what C interfaces are needed to allow scalc to compile to LLVM or comparable VM)

View on HN

Why would you want to? The JVM is pretty awesome. There's already a scala implementation for .net, so it's got at least some level of VM independence, but the JVM is the primary target and I'd expect it to remain so.

As well as the VM there's the runtime library to consider. There was a project recently here that compiled scala to javascript to use on web pages, but unfortunately it needed a 16mb standard library.

Speed and size would be the two biggest.

The start up time of the JVM and the size of the generated executables ( jar files ) make scala not terribly useful for those small programming tasks ( scripting and such )

It is a matter of using the right JVM for the job.

Many do allow for AOT compilation, or caching the generated JIT code between invocations. IBM J9 is one of them, for example.

My understanding is that the bulk of JVM startup time is NOT compiling or loading the actual application code, but loading the classpath.

As I said, not all JVMs are made alike, don't confuse Java virtual machines, with Oracle's or OpenJDK implementation.

JVMs that cache JITed code don't spend time loading the classpath if the cache is still valid.

You misunderstand me...it has to read and decompress (jars are basically zip files) those 50MB are so (just for the system jars) on every startup before it can even think about validating the cache

Sure, however you are still speaking of a specific implementation.

And which implementation that you seem to imply exists DOESN'T suffer from this seemingly fundamental issue? You built this strawman, now defend it or stop waving your hands.

Just read my OP carefully and you will find you answer.

No, read MINE carefully. Even loading cached data isn't free.

Of course not, all the code and data that go into the processor needs to go through the processor cache first.

My OP comment has an example of a JVM that doesn't read jar files as you mentioned, while executing native code stored in a JIT cache present in the hard disk, between invocations.

Google is your friend if you look for the respective documentation. Or, who knows, you could even download it and play around with it.

I'm out, please turn the lights off on the way out.

> There's already a scala implementation for .net,

Scala.net was abandoned a while ago. It's close to impossible to get it to run because .Net's generics are reified.

I've heard this before in the context of why .NET tends to have less alternate language implementations on it than the JVM. I don't understand why though. Why do reified generics make it near impossible?

My understanding is that it gives you less flexibility in how your type system works. To a certain extant you are stuck with the C# type system no matter what the language is because it is baked in to the VM. I assume this doesn't apply as much to dynamic languages but still makes interoperability a pain.

- llvm backend project (tho mail list is pretty quiet): http://greedy.github.io/scala-llvm/

- compiler backend page (info about CLR: http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded...

- scala to JS (one of multiple projects): http://www.infoq.com/news/2013/06/scalajs

- akka is (i think) tightly bound to Oracle JVM/openJDK, https://groups.google.com/forum/#!msg/akka-user/0Z-9_Bmt8p4/...

llvm backend, seems very sleepy if not dead. I thought it was a cool project.

Huge amounts. Practical scala apps leverage huge parts of the Java infrastructure. The Scala types are often thin wrappers over the Java types, JDBC, NIO, etc. It'd be a bit like trying to write a C++ app without access to, say, the STL, or Boost.

Right but if i can convert the java types to be scala code I can use the scala compiler to compile to whatever my target is.

The point is that currently the Scala compiler provides one target - the JVM. Support for .NET was officially dropped last year, and nobody seems to care.

Scala and the JVM are very tightly coupled - targeting LLVM or something should be possible, but getting that to run with high performance would be very difficult.

Reply on news.ycombinator.com