5 ms·

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 a

by dkhenry 13y ago

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)

lmm 13y ago
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.
- dkhenry 13y ago
  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 )
  - pjmlp 13y ago
    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.
    - TylerE 13y ago
      My understanding is that the bulk of JVM startup time is NOT compiling or loading the actual application code, but loading the classpath.
      - pjmlp 13y ago
        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.
        TylerE 13y ago
        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
        pjmlp 13y ago
        Sure, however you are still speaking of a specific implementation.
        TylerE 13y ago
        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.
        pjmlp 13y ago
        Just read my OP carefully and you will find you answer.
        TylerE 13y ago
        No, read MINE carefully. Even loading cached data isn't free.
        pjmlp 13y ago
        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.
- laureny 13y ago
  > 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.
  - meddlepal 13y ago
    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?
    - eeperson 13y ago
      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.
TylerE 13y ago
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.
- dkhenry 13y ago
  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.
  - etrain 13y ago
    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.
gtani 13y ago
- llvm backend project (tho mail list is pretty quiet): http://greedy.github.io/scala-llvm/ http://greedy.github.io/scala-llvm/ - compiler backend page (info about CLR: http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/ http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded... - scala to JS (one of multiple projects): http://www.infoq.com/news/2013/06/scalajs 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/_SHcssJXep0J https://groups.google.com/forum/#!msg/akka-user/0Z-9_Bmt8p4/...
- fedvasu 13y ago
  llvm backend, seems very sleepy if not dead. I thought it was a cool project.

by dkhenry 13y ago

lmm 13y ago

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.

dkhenry 13y ago
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 )
- pjmlp 13y ago
  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.
  - TylerE 13y ago
    My understanding is that the bulk of JVM startup time is NOT compiling or loading the actual application code, but loading the classpath.
    - pjmlp 13y ago
      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.
      - TylerE 13y ago
        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
        pjmlp 13y ago
        Sure, however you are still speaking of a specific implementation.
        TylerE 13y ago
        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.
        pjmlp 13y ago
        Just read my OP carefully and you will find you answer.
        TylerE 13y ago
        No, read MINE carefully. Even loading cached data isn't free.
        pjmlp 13y ago
        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.
laureny 13y ago
> 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.
- meddlepal 13y ago
  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?
  - eeperson 13y ago
    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.

TylerE 13y ago

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.

dkhenry 13y ago
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.
- etrain 13y ago
  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.

gtani 13y ago

- llvm backend project (tho mail list is pretty quiet): http://greedy.github.io/scala-llvm/ http://greedy.github.io/scala-llvm/ - compiler backend page (info about CLR: http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/ http://lampwww.epfl.ch/~magarcia/ScalaCompilerCornerReloaded... - scala to JS (one of multiple projects): http://www.infoq.com/news/2013/06/scalajs 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/_SHcssJXep0J https://groups.google.com/forum/#!msg/akka-user/0Z-9_Bmt8p4/...

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