Scala Virtual Machine?

[James Lei]

If the progress for JVM is taking too slow to progress every major releases, why not probably create our own Scala Virtual Machine (Java Compatible) that is as efficient as .Net?

Here are two articles that worth the read:

http://www.infoworld.com/d/application-development/java-faces-tough-climb-catch-net-224372

http://www.infoworld.com/d/application-development/love-and-hate-java-8-223200

[Rodrigo Cano]

Of the top of my head:

 * Resource allocation to such daunting task

 * Incompatibility with one of the largest battle-tested VMs out there

 * Harder to sell (its not just a java program anymore)

 * Harder to make the jump (you no longer can start implenting parts of your app in scala and integrate with what you previously had)

 * Rewriting of all the maven libs to scala, so that you can run them in the new vm (obviously you wouldn't write them all, but you get the idea of the missing libs)

Although I expect many people to add a lot more items to the list (since this is what you asked for) I also this the possible cons to this :) .

Cheers.

--
You received this message because you are subscribed to the Google Groups "scala-language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-languag...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Withers, Robert]

Running on the jvm is nice, but having a svm - jit would be quite interesting.  It should be possible to write a scala compiler on top of the squeak vm + cog (http://www.mirandabanda.org/cogblog/category/cog/)?

 

rob

[Rich Oliver]

Well I don't think Scala should try for a VM. I'm currently writing a desktop app to run across linux, windows and OS X. However I think I'm going to deploy it as separate executables with an internal JVM, that way I don't have to worry about having the right JVM versions. So I think the target should be to compile Scala either to machine code or llvm. Is recompiling a programme really that much more work than Java's write once debug every where approach. So I would suggest the place to start would be a compiler for Linux or llvm linux. The huge wealth of C and C++ libraries would then become available as a replacement for Java libraries. The problem of type erasure would be removed. There could be properly functioning access modifiers and no doubt many other language improvements and simplifications.

I say start with linux because such a large proportion of Scala runs on linux servers. However this would not be a small project and it is understandable that Typesafe with their limited resources are not eager to jump in. However I'm sure it is quite doable, it just needs a backer with sufficient muscle. There are plenty of large companies who have no love for (ie are in competetion with) Microsoft or Apple and who might also wecome an alternative to Oracle who might potentially back a Scala Linux project. Unfortunately Google has Go and Redhat has Ceylon. Novell is already supporting Mono and I don't think they doing to well at the moment but may they could be interested. Samsung are supporting Rust, which actually looks interesting, I think it might be a better D, but I'm not sure. I did have hopes for Intel as they've started using Scala but they're developing Ct.

[Denys Shabalin]

I'd rather have a llvm-backed binary compiler like Rust than yet another vm that tries to conquer the world.

--

[Alec Zorab]

http://oss.readytalk.com/avian/

[Haoyi Li]

I think the reason's pretty simple: it's bloody hard.

If you really want to chip in, Simon Ochsenreither's been putting in a lot of work into Avian to make it work with Scala, and more help would probably be welcome.

You could also try playing around with https://github.com/lihaoyi/Metascala, which will someday be self-hosting (I hope) in additional to being metacircular.

If anything, it's not a brilliant tactical maneuver to write your own stable, high-performance VM. Probably more a decade-long slog with lots of hard work. 

[Rüdiger Klaehn]

.NET is less efficient than the JVM (no virtual method inlining, no struct inlining in the x64 version last time I checked, ...). So being "as efficient as .Net" is not something to strive for.

I think the only realistic way to do something like this would be to use existing work like LLVM or Avian.

On Fri, Aug 9, 2013 at 4:19 PM, James Lei <james...@gmail.com> wrote:

--

[Oliver Ruebenacker]

Hello,

Excuse my ignorance, but how would a Java-compatible Scala VM be
different from a Java VM?

Take care
Oliver

--
Head of Systems Biology Task Force at PanGenX (http://www.pangenx.com)
Any sufficiently advanced technology is indistinguishable from magic.

[Withers, Robert]

You could provide support for mutating references.

Thanks,
rob

Rob Withers
Staff Analyst/Developer
o: (720) 514-8963 
c: (571) 262-1873

-----Original Message-----
From: scala-l...@googlegroups.com [mailto:scala-l...@googlegroups.com] On Behalf Of Oliver Ruebenacker
Sent: Friday, August 09, 2013 10:23 AM
To: scala-l...@googlegroups.com
Subject: Re: [scala-language] Scala Virtual Machine?

[Simon Ochsenreither]

If the progress for JVM is taking too slow to progress every major releases, why not probably create our own Scala Virtual Machine (Java Compatible) that is as efficient as .Net?

Yes, I'm pretty much looking into that. See http://oss.readytalk.com/avian/.
Scala and all existing Java libraries run already perfectly well on top of it.

Next steps are:

• Getting it integrated into Scala's build process, so that changes can't break Scala on Avian without anyone noticing
• Improve the VM and implement the features we care about (currently looking into value type support and runtime specialization ("reified Generics"))

Please note that 99,99% of the existing work was done by other people, like Joel and Joshua from Avian, not by me. I have basically just combined and tested stuff ... and I'm waiting for a decent C++11/14 book to come out help me get up to speed with Avian's implementation language more efficiently, so I can't promise anything yet. :-)

Let's just say that if a day had 96 hours, I would still have plenty projects to work on.

[Rich Oliver]

On Friday, August 9, 2013 11:00:53 PM UTC+1, Simon Ochsenreither wrote:

and I'm waiting for a decent C++11/14 book to come out

You don't think Bjarne Stroustrup's latest version is up to the job?

[Scott Carey]

"as efficient as .NET" ??
.NET may have many more features, but its performance is behind the JVM.   In Java 1.3 vs .Net 1.1, .Net was faster.  java 1.4 was close to the CLR 2.0.  Java 1.5 was a little faster.  Java 1.6 was significantly faster at launch and got faster as time went on (compressed oops, escape analysis, improved loop optimization, tiered compilation).    .NET is about the same as it was at the start, with minor improvements here and there.  The biggest performance gains are if you can use its lower level features effectively (e.g. value types), but for high level application performance it is behind.

Now you say, where's your proof?   Unfortunately, this was internal corporate data for software that was ported across the platforms -- C# <-> Java conversion, sort of like how Haxe works across underlying platforms.  And of course you can probably find a dozen benchmarks / tests that favor each.  I can only speak to system level tests on large applications at a former employer.

My guess is that support for value types and tail-calls would help Scala, but perhaps there are other features in the JVM that would be more helpful.
For the java platform, project jigsaw is the most important thing in my opinion.   

It would probably take orders of magnitude less effort to push for / contribute tail calls to the JVM than to try and fork the ecosystem to get the feature.  Even for more difficult features such as value types, this is likely the case.

[Simon Ochsenreither]

It would probably take orders of magnitude less effort to push for / contribute tail calls to the JVM than to try and fork the ecosystem to get the feature.

In Avian, tail calls are already implemented and work perfectly fine.
 

Even for more difficult features such as value types, this is likely the case.

Not sure. At least the array part should be reasonably "simple".