Skip to main content

Dolphin: play nice with non-java languages

36 replies [Last post]
suryad
Offline
Joined: 2005-02-23
Points: 0

One of the major things I'd like to see from Dolphin is the ability to host a much wider range of languages with in the JVM, without effectively needing a VM within a VM.

To support ML-style languages efficiently, it would realy help if methods could return tuples. At the moment, methods can have a return type that is void or a java type. This works by leaving any value on the top of an empty stack in the called method, and then popping the stack-frame and setting the top-of-stack index to the return value if there is one. Tuples could be directly supported by just setting the stack-frame to include n values from the invoked method's stack.

I guess this would require some changes.

* the method signatures return value string would need changing to allow a list of types (in the same way that the method arguments list does)

* the vm would need altering to implement returning numbers of arguments other than 0 and 1.

* a return opcode would need to be added that was parameterised with an int in the bytecode for how many values to return (or how many 32 bit words to return?). It would be a validation constraint that the method return signature had as many components as this int. Presumably, using 0 or 1 would be the same as using the existing opcodes.

I'm not sugesting that tuples be added to Java (although I wouldn't object to this) but that the vm be modified to aid in supporting non-java languages.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
robilad
Offline
Joined: 2004-05-05
Points: 0

Given that the JVM language has remained extremely static in the past 10 years, despite numerous calls to extend it to do this or that in past (almost since the beginning, I think), I am not sure where the hope comes from that something can change if people only lobby hard enough for it. It can't. It hasn't. It won't.

Millions of US dollars have been sunk into JVMs. There are many things one could do to the JVM to make it a better platform for Java, in the first place (serialization, or handling of inner classes in the JVML type system, or ...), but they can't really be done without potentially breaking a lot of the existing code left and right, messing with security model, making the verification cumbersone, etc. They are hard problems, and you can see with generics that coming up with something that's sort of working on top of the original design can take ~10 years, and still be sub-optimal. So the hard things are not really going to happen.

The JVM has been designed to solve specific problems with a specific programming language. Making it solve different problems is possible, if one spends enough time on it, but it is unnecessary, since other, better solutions for those problems already exist.

There is a very good reason why, despite almost 10 years of history of alternative languages for the JVM, not a single one of them has actually managed to get mindshare that is comparable to the non-JVM based, primary implementations of those languages. Discuss.

Making the JVM play better with other languages means fundamentally misunderstanding the direction in which developers are progressing in their careers: they go to dynamic languages from Java, and want to interact with their 'legacy' Java code, rather than the other way round.

cheers,
dalibor topic

leouser
Offline
Joined: 2005-12-12
Points: 0

well, that doesn't explain folks like me who have done programming in dynamic languages and still prefers working in Java. I still am just a class and method man, so Java fits my bill quite well. When I use Jython/Python Im still using classes and methods. From my usage of Jython, it sure seems like the VM can play nice with other langauges. Im fairly happy with that tool, so I can't see where the JVM is getting in the way of it. It works Im happy. Java works, Im happy.

leouser

sjasja
Offline
Joined: 2004-08-15
Points: 0

> I suggest anyone who wants to contribute suggestions of
> new bytecodes just ignore the uninformed posters who
> want to convince us that the JVM bytecode is feature complete.
>
> They're probably just Microsoft shills put here to
> waste our time, as anyone with any experience in
> computer science knows that platforms do anything but
> remain static.

Bollocks. If Microsoft wants to sabotage Java they'd flood it with requests for features that break a maximum amount of things for a minimum amount of return value. Multiple inheritance, const, and a few others that routinely surface here come to mind...

Making Java a junkyard of every feature imaginable is the way to doom. See C++.

Keep it simple. Find new features that benefit the maximum number of people. That's why I tend to ask about suggested features: "where is there evidence that this is a big problem for a large number of users? Can this be solved some better way?"

coxcu
Offline
Joined: 2003-06-11
Points: 0

Please, suggest new bytecodes. I'm interested in what people would like to add.

However, consider that every new bytecode increases the complexity of existing JVMs and decreases the available implementation options. Before adding bytecodes, we should be reasonably certain that:

a) they pose no security threat
b) they are essential for the efficient support of some language construct

A faster C implementation on the JVM would be really useful to me. It seems likely that additional JVM bytecodes could help with this. Yet, given the relatively tiny amount of effort that has gone into making C run fast on the JVM, I don't think it is justified.

Justifying the addition of a bytecode should be based on profiling and performance data of multiple implementations. Programmers are often very bad at guessing where the bottlenecks truly are. Premature optimization is the root of all evil.

A JVM extension that intrigues me is the addition of a "meta" bytecode. The basic concept would be to have some mechanism where new bytecodes could be defined on-the-fly. It would be a way of telling the JVM "you're going to see stuff like this a lot, so I'm going to use a shorthand for it and you should try to optimize it". That sounds cool and useful to me, but is totally unjustified at this point.

Here's an RFE that sheds some light on the subject, even though it's talking about a language change rather than a JVM change.
"Please allow Multiple Return Values"
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4222792

rizzix
Offline
Joined: 2004-08-21
Points: 0

I agree. We need improvements.

If you don't want to "improve" the Java language (for the various, but _good_ reasons), at least improve the JVM so that folks can implement better languages.

angben
Offline
Joined: 2004-10-07
Points: 0

I suggest anyone who wants to contribute suggestions of new bytecodes just ignore the uninformed posters who want to convince us that the JVM bytecode is feature complete.

They're probably just Microsoft shills put here to waste our time, as anyone with any experience in computer science knows that platforms do anything but remain static.

Don't feed the trolls.

Message was edited by: angben

leouser
Offline
Joined: 2005-12-12
Points: 0

isn't there an invoke_dynamic byte code going into the VM? Maybe Im thinking of something else.

leouser

jwenting
Offline
Joined: 2003-12-02
Points: 0

> I think some of you are missing the point here. This
> is not a request for the JVM to do special to-native
> compilation for each language. It is not a request
> for Sun to put in a special hook for each and every
> language.
>
It is, effectively.

> There are patterns of behavior across many different
> languages which are expensive to "fudge around" in
> bytecode. Dynamic invokation and multiple-return
> values have been mentioned already in this thread,
> but there are plenty more.
>
So you want the JVM to have native support for every single programming paradigm out there whether Java supports it or not.
That's exactly what you claimed you are not calling for...

Why should Sun introduce support for multiple return values from a method if Java itself doesn't support it?
Your operating system doesn't support it either, it's your compiler's task to transform your sourcecode into something the OS can understand.
The JVM is an operating system, except it takes bytecode instructions from a well published instruction set instead of CPU calls.
Learn to use the tools at your disposal rather than scream bloody murder because the tool doesn't support your pet feature.

suryad
Offline
Joined: 2005-02-23
Points: 0

> Why should Sun introduce support for multiple return
> values from a method if Java itself doesn't support
> it?

Because Java is not the only language that runs on the JVM, and some/many of those that do could benefit from this change. Because Sun has stated that they wish to make the JVM more attractive to a wider range of languages. Because developers and projects that require multiple language solutions are moving to .net. You should be asking "why not" consider changes to the JVM.

> Your operating system doesn't support it [multiple return values] either, it's
> your compiler's task to transform your sourcecode
> into something the OS can understand.

Are you the acting "don't change it 'cause it ain't broken", "Java == Java 1.4.2", "JVM == Java" troll? Otherwise, I don't realy see what you are driving at.

Your operating system doesn't "support" stack-frame based function invocation. The OS has no notion of a function, or a return type. It doesn't "support" garbage collection, or continuations. All this is implemented by the language you are writing in and the run-time environment it is linked to. However, the operating system does provide functionality that helps in implementing these things e.g. giving you memory pages to do what you want with, giving you an OS thread/process that can execute code and jump to new code, and a mechanism for loading/linking code to be executed. When the semantics of what the OS provides matches more closely to the language implementation, applications run faster (e.g. green vs native threads in Java).

robilad
Offline
Joined: 2004-05-05
Points: 0

You can't really educate a 14bn USD company into being a 'benevolent dictator' by posting on their message board.

O'Caml obviosly makes more sense than Java for certain tasks, but Sun is not selling anything O'Caml, so they don't need it.

Your best bet is to wait for/help Microsoft to make F# rock, and then hope that Sun emulates that in order to better compete with C# 3.0 in Java 10.

Or of course, you could take an existing VM, and extend it, or write your own to do what you need to do. LLVM would be a nice choice, these days.

cheers,
dalibor topic

ahmetaa
Offline
Joined: 2003-06-21
Points: 0

"Not going to happen. Sun is iterested in you rewriting your code in Java, a platform they can control, not in making it easy for people to migrate away from it to nicer environments outside of Sun's sphere of influence."

Of course they will use Java the language as the main language.. Come on now, Sun does not have resources for trying to plese every open source cry baby. Nevertheless, they said they will make it easier, there are already other languages working on JVM. what is you point again? "Nicer" environments as what? you think language is the first priority for a platform?

coxcu
Offline
Joined: 2003-06-11
Points: 0

mpocock,

My questions are:
1) What languages did you have in mind?
2) Why do you think this would be faster than any existing mechanism?
3) How much faster would it be? 10%? 10x? 100x?

Almost any computer langauge can have a huge range of implementations. A change that would make 10 percent of all JVM programs run 100 times faster, is much easier to justify than one that would make 0.01 percent run 10 percent faster.

- Curt

suryad
Offline
Joined: 2005-02-23
Points: 0

Hi Curt,

> My questions are:
> 1) What languages did you have in mind?

Standard ML, OCAML - any of the eagerly evaluated MLs. Not sure things like Haskel can be implemented tollerably well in a Java VM.

> 2) Why do you think this would be faster than any
> existing mechanism?

The alternative is to box the tuple into an instance with one field per tuple member. This has several overheads.

a) memory allocation & garbage collection of the instance

b) pass-by-reference rather than pass-by-value

c) book-keeping to store all the tuple classes e.g. those to store:
(int, int), (int, float), (int, Object), ...
(float, int), (float, float), (float, object), ...
...
(int, int, int) ...

> 3) How much faster would it be? 10%? 10x? 100x?

The cost of returning e.g. (String,int) from a method would be: put the String reference at the base of the stack; put the int value at position 1 in the stack ; return, setting the stack pointer to +2 from the method invocation. As far as I can tell, this has exactly one opcode more overhead than returning 1 value, and two opcodes more than returning no value (void).

Compare this to the overhead of creating a new tuple instance, intializing the fields, returning the reference and then accessing these fields in the calling method, and it's clear there is a big win.

> A change that would make 10 percent
> of all JVM programs run 100 times faster, is much
> easier to justify than one that would make 0.01
> percent run 10 percent faster.

Agreed. Again, I'm not sudgesting that this is a change that affects Java code. It is a very small change to the vm that would make compiling ML languages to the jvm substantially easier.

>
> - Curt

hlovatt
Offline
Joined: 2003-11-18
Points: 0

The main thing you seem to want is the ability to pass a tuple back. You can do this with an instance of a Tuple class and as of the next release of Java, 6, if it is safe to allocate an instance of a class on the stack it will do so. Therefore Sun seem to have this one covered.

alexlamsl
Offline
Joined: 2004-09-02
Points: 0

> You can do this with an instance
> of a Tuple class and as of the next release of Java,
> 6, if it is safe to allocate an instance of a class
> on the stack it will do so.

Really? Which issue is this in the bugs parade? Is there any information I can read about this cool thing?

hlovatt
Offline
Joined: 2003-11-18
Points: 0

The inlining technique is called escape analysis. If you google "escape analysis java" you turn up quite a bit of stuff. EG:

http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html

alexlamsl
Offline
Joined: 2004-09-02
Points: 0

Sorry for causing confusion.

I do know about the method. I mean which ID in the Bug Parade corresponse to the implementation of the technique.

And the last time I've heard about this I think they have only implemented escape analysis in Mustang - but haven't implemented any linked optimisations (e.g. stack allocation) with it yet.

hlovatt
Offline
Joined: 2003-11-18
Points: 0

I am not a Sun insider so I don't know what has made it into Mustang and what has been left to Dolphin. You could well be right that only the escape analysis is in Mustang and that we will have to wait for Dolphin for stack allocation. Either way, Sun are addressing the issue as an when resources allow.

tackline
Offline
Joined: 2003-06-19
Points: 0

I'm not from Sun, but as I understand it:

Mustang can use escape analysis to move objects onto the finalisation queue without gc and, IIRC, to remove locks. The stack allocation is scheduled for Dolphin, but may be backported to later updates of Mustang. Remember that short-lived allocations are surprisingly cheap.

lacusodii
Offline
Joined: 2006-02-21
Points: 0

I was at JavaONE conference August last year, and as a matter of fact Sun said they were interested in adding bytecode support for dynamic and functional languages in the upcoming "Dolphin" release. This would be a godsend for people who want to implement things like continuations and closures, for which there is not an analog in Java (inner classes are a hack that pass outer aroperties via invisible parameters and are not natively supported in bytecode.) You simply cannot do these things in Java, and the bytcode doesn't support them, since behind the scenes they are just condensed OO. Implementing these languages for the JVM is a pain in the butt because you're forced to hack them on top of the OO paradigm.

The reason why it matters is because 1) there is a significant subset of programmers who want it 2) there is a subset of programmers who would happily port their favorite language to the Sun platform if it was feasible to do, and 3) Microsoft's .NET CLI can already do this, so anybody in groups 1 and 2 have reason to jump to .NET or Project Mono and skip Java. Sun wants EVERYONE on their platform, and especially not on .NET.

Making the JVM support other language paradigms is a good way for them to protect themselves for the future. There will come a day when Java will be the leftover language that COBOL is now, and making the JVM support functional languages is a way to ensure they aren't up a creek when the industry moves onto the next big thing. The JVM is Sun's platform, not the Java language per se. Java won't last forever, but the JVM could last a very long time if they make it flexible.

Someday lisp-like languages are going to catch on, just as soon as Java programmers figure out that by the time you're using inner-classes, passing in Maps of parameters and returning Lists, and using Reflection to dynamically query and set properties that you're already badly simulating them anyway.

Don't worry about it breaking the JVM, that's Sun's problem and they won't let it filter down to the user. If enough people ask for this feature, we might get it.

robilad
Offline
Joined: 2004-05-05
Points: 0

The invokedynamic bytecode, if it ever actually sees the light of day in a few years[1], would be just a way to avoid being too constrained by Java's type system at compile time, you would simply delegate the actual type checks to runtime.

Your language's type system would have to be close to the JVML in order to profit from it. The JVM does not support type systems that are different from Java efficiently. It can't be done, without pessimizing its performance for Java, so it won't happen.

See the goals and constraints section of JSR 14, the generics JSR that brought us erasure instead of reification after almost 10 years of trying, if you believe there is an easy way to extend the JVM to implement some novel, cool feature it has not been designed for. The constraints make it pretty hard to do so.

The JVM will last exactly as long as Java lasts, which is going to be a while, anyway, despite all the fear and loathing going on. The JVM is not broken for the primary target of its design, mobile runtime envirnments for proprietary binaries, i.e. running Java apps, and coincidentally, that's one area where it is finally possible for Sun to monetize their investment into the Java technology. There is no reason to break it, as long as it brings in cash in the J2ME/J2SE space with the current design.

cheers,
dalibor topic

[1] It's a long way from a blog entry about a neat idea to something that actually works and can be shipped as part of the JVM. Right now, invokedynamic is just good sounding vaporware. Like, say, isolation was a few years ago, and still is.

angben
Offline
Joined: 2004-10-07
Points: 0

I think some of you are missing the point here. This is not a request for the JVM to do special to-native compilation for each language. It is not a request for Sun to put in a special hook for each and every language.

There are patterns of behavior across many different languages which are expensive to "fudge around" in bytecode. Dynamic invokation and multiple-return values have been mentioned already in this thread, but there are plenty more.

These changes aren't necessarily simple for the JVM team, especially in regards to insuring the security of the sandbox, but the alternative is having the JVM become a second-class platform for the next "big thing" in languages. That's already happening in a sense with the surge in popularity of dynamic languages, and Sun is responding, albeit slowly. So to the cynical comment at the start of the thread, I'd say -- the jury is still out.

sjasja
Offline
Joined: 2004-08-15
Points: 0

An URL a few replies back lists ~200 language implementations running on the JVM. Which ones are you all using actively in production software systems? Is it specifically a tuple-returning language you need and you can't do it the OO way where tuple==object? Or is this more of an academic thought experiment (not that there is anything wrong with that)?

suryad
Offline
Joined: 2005-02-23
Points: 0

At the risk of repeating myself...

> Or is this more of an academic
> thought experiment (not that there is anything wrong
> with that)?

I'm interested in standard ML, or OCAML, which unfortunately aren't among those listed at the URL given above. I have code in SML that does some AI stuff, and it's a shame to have to interact with it through files and System.exec, especially since it is embedded in a web-service.

This lead me to trying to find an ml interpreter or compiler for the JVM, and when that looked like it would be fruitless, to think about how you would implement one.

> Is it specifically a tuple-returning
> language you need and you can't do it the OO way
> where tuple==object?

It is possible to wrap tuples up as objects with fields. This has overheads. Firstly, you must keep strack of the tuple classes. You can't start with a library of all possible tuples - that would be infinitely big, so some book-keeping is needed to generate the ones needed only. Secondly, the cost of allocating the tuple, just to return it through the jvm method invocation and then un-wrap the field values again is significant. Hotspot will eventually inline this all away if it happens in a hotspot, but in a typical ML application, there will be many functions returning tuples, so there will be a large but spread-out cost to this, which hotspot may not notice. The alternative is for the jvm to allow methods to leave 0, 1, or n items on the stack. This costs n opcodes more in performance than the current return void opcode.

peterkehl
Offline
Joined: 2005-01-28
Points: 0

You probably know that Tuples and Agents are type-safe language structures native to Eiffel.

There is an implementation of Tuples and Agents as generic Java classes. It uses different syntax than Eiffel, but it provides same functionality. It also includes Collectors - a reusable abstraction of Agents.

Thanks to escape analysis, these objects can be frequently used in next JDKs.

See http://reuse.sourceforge.net/eiffel

> It is possible to wrap tuples up as objects with
> fields.

robilad
Offline
Joined: 2004-05-05
Points: 0

Not going to happen. Sun is iterested in you rewriting your code in Java, a platform they can control, not in making it easy for people to migrate away from it to nicer environments outside of Sun's sphere of influence.

cheers,
dalibor topic

suryad
Offline
Joined: 2005-02-23
Points: 0

Hi dalibor

> Not going to happen. Sun is iterested in you
> rewriting your code in Java, a platform they can
> control, not in making it easy for people to migrate
> away from it to nicer environments outside of Sun's
> sphere of influence.

Well, I am posting in response to the "what would you like to see?" - isn't the point of this to educate Sun towards being a more benevolant dictator? These forums are at least in part a platform for us, the users, to lobby Sun.

My friends who use .net write nearly everything in c# but the ability to use some other language when it is the right thing to do, and have it play nicely with their c# app is good. They can stay within the .net platform because the CLR supports a range of languages.

I love Java but who wants to write a compiler in it? Manipulating ASTs and code generation is just so much easier in some other languages. If Sun are trying to lock me in to Java, then in this case it's having the opposite effect becuase I now have to run some code outside of the VM, and once you start running parts of your system outside in native code then it's a slippery slope for the rest to follow.

coxcu
Offline
Joined: 2003-06-11
Points: 0

Sun is definitely not of one mind on this.

C runs on the JVM right now, but not thanks to Sun. Sun funded a tiny bit of research to use GCC to target the JVM, but never pursued it to the point of usability. They have pursued various emulation projects, but haven't tried to produce Java versions of any of them.

Execution speed is generally a minor concern when running non-Java languages on the JVM. Ease of development is the primary concern. Development is hardest when you have to provide your own language implementation. On the other end of the spectrum is a language that is fast, well documented, relatively bug-free and has good tool support.

BeanShell is quite slow and doesn't have much IDE support. However, it is well documented, relatively bug free and fast enough for some uses--so it has a reasonably strong following.

Sun isn't doing nearly enough to promote non-Java languages on the JVM, but lack of necessary bytecodes isn't the major issue facing any language. If there was a community for Haskell on the JVM comparable to the Jython community, it would be possible to lobby Sun into making JVM changes to support it. That might mean new bytecodes, or it might just mean optimizing the bytecodes as the language uses them.

As for your .net using friends--what languages do they use?

Here are some relevant links you might find interesting. Most of it is stuff Sun could build on, rather than stuff they funded.

Walkabout
http://www.experimentalstuff.com/Technologies/Walkabout/

A backend of EGCS/GCC targeting the Java Virtual Machine.
http://sourceforge.net/projects/egcs-jvm

QEMU
http://fabrice.bellard.free.fr/qemu/

The LLVM Compiler Infrastructure
http://llvm.cs.uiuc.edu/

Survey of Migration tools for JNI
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5087416

AMPC (Axiomatic Multi-Platform C)
C compiler suite that generates Java Bytecode.
http://www.axiomsol.com/

MIPS emulator, which can be used to run many languages
http://darcs.brianweb.net/nestedvm/

One Haskell for the JVM
http://darcs.brianweb.net/yhcjvm/

BeanShell
http://beanshell.org/

Performance benchmarks for some JVM languages
http://www.javaworld.com/javaworld/jw-03-2005/jw-0314-scripting-p2.html

jwenting
Offline
Joined: 2003-12-02
Points: 0

And there's a LOT of languages that run fine on the JVM. Python and Ruby come to mind.

All you need is a decent compiler to generate classfiles out of your sources.
If one doesn't exist, don't go whining at Sun that the JVM doesn't understand your favourite language, go to the language owners and whine there for a compiler that generates Java classfiles (or better yet, write your own).

It's not called the JAVA virtual machine for nothing.

coxcu
Offline
Joined: 2003-06-11
Points: 0

jwenting,

In practice Java is easily the fastest language on the JVM. Most other JVM langauges are implemented using an interpreter, rather than compiled to bytecode, but it is generally issues other than speed that hinders their adoption. That's not to say that compiled must be faster than interpreted, or that all runtime environments can be adequately described by either term. Despite its faults, Java is an extremely well supported language on the JVM and tough to compete with. Still, certain people will be attracted by speed and nobody will be attracted by slowness.

Why would it be better to write a new compiler than file a performance RFE against an existing one?

Just for the sake of completeness:
http://www.robert-tolksdorf.de/vmlanguages.html

jwenting
Offline
Joined: 2003-12-02
Points: 0

If other languages don't use a compiler but an interpreter to run on the JVM, don't blame Sun for that, blame the creators of that interpreter for not creating a compiler instead.
There is no existing C compiler, C++ compiler, or whatever compiler on the JVM that's supplied by Sun except a Java compiler...
If Sun supplied those other compilers and they were slow, then you might have a point, but Sun doesn't.

coxcu
Offline
Joined: 2003-06-11
Points: 0

Can you elaborate about what ML-style languages you have in mind and how this would be an improvement? How much of a performance hit would using the current JVM instruction set be?

suryad
Offline
Joined: 2005-02-23
Points: 0

Well, I already have. Allowing JVM methods to return n values rather than 0 or 1 woudl make a big difference, unless I've mis-understood how functional languages work

leouser
Offline
Joined: 2005-12-12
Points: 0

Usually if Ive wanted to return multiple items Ive either returned a Collection type or a special value class if the values were heterogenous.

So I suppose you should be able to do this already by just returning a List. No args returned, the EMPTY_LIST gets returned.

Im not a big fan of methods/functions that depending upon how they execute can return:
A Can of Coke, A Doctor or a Mouse.

Not fun!
leouser

jwenting
Offline
Joined: 2003-12-02
Points: 0

anything that compiles to classfiles already runs fine in the JVM, nothing else is needed.
You can't expect the JVM to play nice with C++ sourcefiles, Fortran code, Cobol units, etc. and be expected to parse and run them all.

suryad
Offline
Joined: 2005-02-23
Points: 0

> nothing else is needed.

Well, it is if you want to compile non-java languages to run efficiently inside a JVM. Whitness the addition of invoke_dynamic to dolphin, explicitly to handle non-java languages such as python and ruby.

> You can't expect the JVM to play nice with C++
> sourcefiles, Fortran code, Cobol units, etc. and be
> expected to parse and run them all.

The JVM doesn't have to parse anything. It has to execute bytecode. If by making relatively minor changes to the bytecode, a much wider range of efficiently implementable source languages become available, surely this is a good thing?