Weblogs Forum - The JVM as an (Un)Common Language Runtime

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
The JVM as an (Un)Common Language Runtime

30 replies on 3 pages. Most recent reply: Sep 29, 2006 7:53 AM by G B

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 30 replies on 3 pages [ « | 1 2 3 | » ]

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

sour grapes

Posted: Sep 20, 2006 10:15 AM

Patrick Wright wrote
> I could care less if Sun had already great programmers
> in-house 10 years ago or if they hired them for somewhere
> else. I assume both are true.

Both are true.

Todd, the rants against Java contain so little detail or information that they come across as sour grapes.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

We all have opinions

Posted: Sep 20, 2006 11:10 AM

> the rants against Java contain so little detail or
> information that they come across as sour grapes.

What detail or information are you looking for?

I was just rebutting the point that constraining a language feature set in order to make it "optimizable" is a fool's errand today given the power of the processors we have today.

The JVM is exactly that - the J vm. Its not good at other languages, it has far too much bias built in. InvokeDynamic might improve a few things (among them, I suppose some optimizations may become invalid), but in general, I view the efforts as likely a waste of time.

What do we hope to achieve by running other languages on the JVM? I see only the possibility of being able to call existing java libraries as beneficial. Everything else ends up being emulated at a higher level and thus not performant, or crippled (as in the loss of continuations in JRuby).

I'll leave with just this - which is my opinion - which is all anyone else posts here anyhow - the JVM is a rotten starting point for doing a "universal" VM. It is already far too warped. It would probably be better to build a generic VM designed to implement a set of features common to dynamic languages and then target a java compiler at that.

IOW, I think the really interesting research topic would be to see if Java can be targeted to something like the Parrot, or Squeak (or some other research) VMs. Force fitting richer languages into the VM of a feature poor language looks to me like a losing game.

That's the last I'll say about that.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: We all have opinions

Posted: Sep 20, 2006 1:17 PM

> I'll leave with just this - which is my opinion - which is
> all anyone else posts here anyhow - the JVM is a rotten
> starting point for doing a "universal" VM. It is already
> far too warped. It would probably be better to build a
> generic VM designed to implement a set of features common
> to dynamic languages and then target a java compiler at
> that.

In a perfect world you are probably right. But as the success of Windows has shown, the best technology doesn't always win. The acceptance of software often has more to do with momentum and marketing than with quality and innovation.

Dalibor Topic

Posts: 26
Nickname: robilad
Registered: Mar, 2006

Re: We all have opinions

Posted: Sep 20, 2006 4:40 PM

See Myth #2 in http://www.sun.com/executives/realitycheck/reality-031303.html

Replace CLR with JVM, and enjoy the irony.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: We all have opinions

Posted: Sep 20, 2006 7:00 PM

> > the rants against Java contain so little detail or
> > information that they come across as sour grapes.

Todd Blanchard wrote

> What detail or information are you looking for?
>
> I was just rebutting the point that constraining a
> language feature set in order to make it "optimizable" is
> a fool's errand today given the power of the processors we
> have today.
>
> The JVM is exactly that - the J vm. Its not good at other
> languages, it has far too much bias built in.
> InvokeDynamic might improve a few things (among them, I
> I suppose some optimizations may become invalid), but in
> general, I view the efforts as likely a waste of time.
>
> What do we hope to achieve by running other languages on
> the JVM? I see only the possibility of being able to call
> existing java libraries as beneficial. Everything else
> ends up being emulated at a higher level and thus not
> performant, or crippled (as in the loss of continuations
> in JRuby).

Yes the JVM is the Java VM. For years there was no suggestion that the JVM (unlike the CLR) would be any good for other languages.

Which leaves us to explain all those language implementations that have targeted the JVM over the last decade (including some that are actually used like Jython and Rhino).

> I'll leave with just this - which is my opinion - which is
> all anyone else posts here anyhow - the JVM is a rotten
> starting point for doing a "universal" VM. It is already
> far too warped. It would probably be better to build a
> generic VM designed to implement a set of features common
> to dynamic languages and then target a java compiler at
> that.
>
> IOW, I think the really interesting research topic would
> be to see if Java can be targeted to something like the
> Parrot, or Squeak (or some other research) VMs. Force
> fitting richer languages into the VM of a feature poor
> language looks to me like a losing game.
>
> That's the last I'll say about that.

How much credence we give to an opinion depends a good deal on what we think the opinion is based upon.

Suggesting that Java might be targeted to something like Parrot is only a little odd given that Parrot is intended to support other dynamic bytecode-compiled languages as-well-as Perl.

Suggesting that Java might be targeted to something like Squeak is really odd given that there don't seem to be any other languages that have targeted the Squeak VM over the decade it's existed - did the E implementation on Squeak ever come to anything?

I'd be more sanguine about your previous comments optimizations applied to the JVM are at least 20 years old and well understood if there was some detail or information about a widely available dynamic language implementation that included those optimizations - but it seems that adaptive optimisation takes a lot of implementation work.

http://www.cincomsmalltalk.com/blog/blogView?showComments=true&entry=3236397054

http://video.google.com/videoplay?docid=-8988857822906068209

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

I don't get your point

Posted: Sep 20, 2006 9:18 PM

Since you seem to have dug up the links that make mine. I met Eliot a few years ago and was aware of his work. There are

My suggestion isn't remotely odd if the goal is having java interop with other languages. It would be better to host the Java code on a more capable VM than force fit crippled languages on the JVM.

Java the language has clearly hit the wall in terms of popularity and Sun seems to know iit - else why would they be funding new languages on their infrastructure?

There are a plethora of new VM's being done, I just named a few. I'll be attending the dynamic languages symposium running concurrent with oopsla. I'm interested to see what Ian has been cooking up (a new VM) and see what else is new there.

http://www.oopsla.org/2006/program/program/dynamic_languages_symposium.html

As for dynamic optimization, there are other projects in the works, but its just one guy with a vision just now.
http://minnow.cc.gatech.edu/squeak/5720

Patrick Wright

Posts: 15
Nickname: pdoubleya
Registered: Jun, 2005

Re: I don't get your point

Posted: Sep 21, 2006 1:33 AM

> My suggestion isn't remotely odd if the goal is having
> java interop with other languages. It would be better to
> host the Java code on a more capable VM than force fit
> crippled languages on the JVM.

Todd, the most obvious reason to try and host languages other than Java on the JVM is that there are a number of very large, well-funded programming teams working on extending, optimizing, porting and testing the JVM. This is true to a lesser extent of the CLR.

Just writing a VM and getting it to perform well is one task; getting it ported to multiple architectures, testing it thoroughly, writing external tools to interface with it complicates the effort greatly.

For me, the issue is only partly that there is a large library base written in Java; the larger issue is that JVMs run on many platforms, run well, and that I've never had a problem moving my code between JVMs on different platforms. Plus, without changing my code at all, performance just improves with each release because of all the work being done on them. That's what we can take advantage of.

That's not to say there isn't room for new players, or for older VMs to become competetive, but the cool thing about the JVM is, as other people already went through the hard work of convincing the market to embrace it, we have a lot of programmers being funded to improve the thing.

Which just goes to say that in the medium term, it seems to make sense to settle for the warts-and-all JVM, and make other languages run well on it, while keeping in mind what we'd want the next VMs to have that the JVM never will.

Best regards
Patrick

Marcin Kowalczyk

Posts: 40
Nickname: qrczak
Registered: Oct, 2004

Re: I don't get your point

Posted: Sep 21, 2006 7:28 AM

I've implemented a compiler of my language Kogut which translates it to C. I feel that it's easier than targetting JVM, even though the language is nothing like C. JVM has too many Java-specific limitations.

It uses garbage collection, dynamic typing, tail call optimization, exceptions, big integers, Unicode strings, lightweight threads, etc.

Tail calls are implemented by postprocessing the assembler output generated by a C compiler (or portably with a driver loop). The union of small integers and pointers to other objects is implemented by tagging small integers in the lowest bit. The system stack is almost unused; there is a custom stack, useful because of GC, tail calls, threads, stack traces on an unhandled exception, and detection of stack overflow.

These hacks, even though some of them are theoretically unportable and violate the letter of C rules, work quite well. JVM neither provides appropriate mechanisms itself nor allows to cheat in order to implement them.

JVM would require extremely stupid workarounds to implement tail calls. JVM has no way to put small integers along with pointers in a single pointer-sized field. Type safety on this level would do more harm than good. JVM has heavy exceptions, heavy threads, UTF-16 strings (I want UCS-4, and the implementation uses an alternative ISO-8859-1 representation of some strings for space optimization), and makes each object one field larger in order to support a per-object mutex and address hash that I wouldn't use. JVM has a wrong semantics of finalizers.

JVM is poorly suited for implementing languages which don't want to compromise in order to be JVM-compatible.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

unfunded one person research projects

Posted: Sep 21, 2006 11:40 AM

I met Eliot a few years ago and was aware of his work
Is that work funded or is it in the "one guy with a vision" category? The corresponding work has been done for JVM and appeared years ago as the HotSpot VM - that's the point.

... better to host the Java code on a more capable VM
That was done back in the day when Java VMs were little more than interpreters - IBM VisualAge for Java originally provided a "Universal" VM that executed both Smalltalk and Java bytecodes. And then came the HotSpot Java VM.

...else why would they be funding new languages on their infrastructure?
Because their competitor Microsoft makes a big deal about cross-language development with CLR!

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: unfunded one person research projects

Posted: Sep 21, 2006 11:57 AM

>Is that work funded?

I believe he was working for Cincom on the Visualworks VM. I did meet him at a little Smalltalk event and he was sharing optimization work he'd been doing.

I'm aware of the IBM history - IBM had bet the future on Smalltalk (VisualAge) and was about to push it hard across their entire line - until they got wind of Sun's plans to drop $$$$'s on pushing Java and figured they'd rather follow than lead. Most of IBM's early Java tools/VM were written in/for Smalltalk.

Basically, Java arose to prominence because IBM was too wishy washy to stand their ground and take a position and bet on their superior technology (they figured they would win the Java game with their head start).

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: unfunded one person research projects

Posted: Sep 21, 2006 12:26 PM

> >Is that work funded?
>
> I believe he was working for Cincom on the Visualworks VM.
> I did meet him at a little Smalltalk event and he was
> s sharing optimization work he'd been doing.

So you don't know if AOStA was funded or a free time project.

http://groups.google.com/group/comp.lang.smalltalk/msg/906f324f62acad13

> I'm aware of the IBM history - IBM had bet the future on
> Smalltalk (VisualAge) and was about to push it hard across
> their entire line - until they got wind of Sun's plans to
> drop $$$$'s on pushing Java and figured they'd rather
> follow than lead. Most of IBM's early Java tools/VM were
> written in/for Smalltalk.
>
> Basically, Java arose to prominence because IBM was too
> wishy washy to stand their ground and take a position and
> bet on their superior technology (they figured they would
> win the Java game with their head start).

Nice rant, which does nothing to alter the existence of JVMs with adaptive optimization, and the non-existence (besides cancelled research projects) of other VMs with adaptive optimization.

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: unfunded one person research projects

Posted: Sep 21, 2006 1:58 PM

>does nothing to alter the existence of JVMs with adaptive optimization, and the non-existence (besides cancelled research projects) of other VMs with adaptive optimization.

Nor does it alter the JVM's unsuitability to host other languages as efficiently as their native VMs.

Point?

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: unfunded one person research projects

Posted: Sep 21, 2006 2:16 PM

> >does nothing to alter the existence of JVMs with adaptive
> optimization, and the non-existence (besides cancelled
> research projects) of other VMs with adaptive
> optimization.
>
> Nor does it alter the JVM's unsuitability to host other
> languages as efficiently as their native VMs.
>
> Point?

Is that generally true? Is Rhino uniformly slower than SpiderMonkey?

Things change. From the original posting:

"... However our recent efforts have aimed toward componentizing these pieces; as the JVM evolves to support them, we'll be able to toss them out one by one."

"We are getting pretty close to matching parity with the C implementation, but some of the last cases will be a challenge."

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

Re: unfunded one person research projects

Posted: Sep 21, 2006 2:49 PM

> Is Rhino uniformly slower than
> SpiderMonkey?

No idea. I don't hear anyone claiming it will be faster though. Also, JS is a relatively pathological case. Its not what you would call "highly optimized".

Lets see what JRuby comes up with. I wont really consider it a win until all of Ruby is supported (yes that includes continuations).

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: unfunded one person research projects

Posted: Sep 21, 2006 3:10 PM

> > Is Rhino uniformly slower than
> > SpiderMonkey?
>
> No idea. I don't hear anyone claiming it will be faster
> though. Also, JS is a relatively pathological case. Its
> not what you would call "highly optimized".

"Another clue: Rhino (JS implemented in Java) outperforms SpiderMonkey on well-JITed Java VMs."
Brendan Eich at June 15, 2004 04:34 PM

"Recently I ported some massive XSLT+JS apps of mine from Xalan+Rhino+SunsJVM1.3 to libXslt+SpiderMonkey. I did this in persue for greater speed. Both running on HP-UX11.

The result was that there was _almost_no_ difference in exec time between them (expect starting time and some memory consumption) and this after -O2/9 compile optimizations."
fikin at August 30, 2004 04:46 AM

http://weblogs.mozillazine.org/roadmap/archives/2004/06/mozilla_20_virt.html

Is Ruby 'what you would call "highly optimized"' ?

Flat View: This topic has 30 replies on 3 pages [ « | 1 2 3 | » ]

Previous Topic

Next Topic