4 ms·

Does anyone have any idea what "problems" one "inherits", per the article, in building dynamic languages on bytecode VMs like Parrot and the JVM? It seems to be

by rosser 14y ago

Does anyone have any idea what "problems" one "inherits", per the article, in building dynamic languages on bytecode VMs like Parrot and the JVM? It seems to be talking about the fact that the JVM was designed for Java the language, and how that's induced some kind of drag on porting other kinds of languages to it, but I really don't see how that's relevant to Parrot, which was designed to be language agnostic (modulo its bias towards supporting the needs of dynamic languages) from the get-go.

bascule 14y ago
He's just wrong about the JVM, specifically with statements like this: "the benefits of the JVM only apply to languages that map well onto Java concepts" With InvokeDynamic (InDy) this is no longer true at all. InDy lets you manage the entire lifecycle of method dispatch at a particular call site in a way that HotSpot can optimize across. This lets you define your own dispatch semantics that can potentially do things like complicated argument conversions (e.g. rolling all of the arguments up into an array) and it will still dispatch as fast as Java. This is true because InDy lets you define your own polymorphic inline method caches at call sites, so you can have a slow lookup for a method handle which is cached and invokes as fast as InvokeVirtual the next time it's called. HotSpot can also inline code using InDy just like it can inline virtual method dispatch in Java. This lets the JIT compiler optimize across several methods, potentially implemented in many languages, as if they were a single body of code. InDy will play a particularly important role in JDK8, where it's used to implement lambdas.
Nitramp 14y ago
To be fair, while there is invoke dynamic, he might be alluding to other aspects of the JVM (and referencing Parrot hints to that). Eg. class loading in the JVM is (afaik) still static, classes once loaded cannot be modified, which is a problem for languages such as Ruby and JS, the basic data types of the JVM might not match your language, etc. Not sure if that makes a big difference, in essence you'll have to implement those semantics in either case, be it in RPython for PyPy or Java for the JVM.
- bascule 14y ago
  Classes can be changed after loading using HotSwap, it's just their method signature can't change: http://docs.oracle.com/javase/1.4.2/docs/guide/jpda/enhancements.html http://docs.oracle.com/javase/1.4.2/docs/guide/jpda/enhancem...
fijal 14y ago
I tried to pinpoint down some problems, but let me elaborate on this. As far as Parrot goes, it's not done despite years of development and it has lots and lots of problems, some with the approach, some with the actual implementation. But the truth is you can't do much with it today. As for JVM, which is definitely "done", you don't get access to low level concepts and you don't get support for most dynamic language concepts. For example in Jython escape analysis does not work at all, because everything escapes via frames (which in python is accessable from application level using sys._getframe). Invokedynamic only helps marginally here - you still need a JIT that can optimistically remove unlikely paths of the execution or a very smart compiler-to-the-JVM, which is unnecessary in PyPy. The other element is low level stuff. JVM is opaque, you can't code in terms of C structures. RPython as well, but it allows you if you insist and sometimes there are very good reasons to insist. Look in rpython/ directory in the hippy checkout for an implementation of an ordered dict with all it's oddities. In the JVM if such a primitive does not come (and it's unlikely enough), you're out of luck.

by rosser 14y ago

bascule 14y ago

He's just wrong about the JVM, specifically with statements like this: "the benefits of the JVM only apply to languages that map well onto Java concepts" With InvokeDynamic (InDy) this is no longer true at all. InDy lets you manage the entire lifecycle of method dispatch at a particular call site in a way that HotSpot can optimize across. This lets you define your own dispatch semantics that can potentially do things like complicated argument conversions (e.g. rolling all of the arguments up into an array) and it will still dispatch as fast as Java. This is true because InDy lets you define your own polymorphic inline method caches at call sites, so you can have a slow lookup for a method handle which is cached and invokes as fast as InvokeVirtual the next time it's called. HotSpot can also inline code using InDy just like it can inline virtual method dispatch in Java. This lets the JIT compiler optimize across several methods, potentially implemented in many languages, as if they were a single body of code. InDy will play a particularly important role in JDK8, where it's used to implement lambdas.

Nitramp 14y ago

To be fair, while there is invoke dynamic, he might be alluding to other aspects of the JVM (and referencing Parrot hints to that). Eg. class loading in the JVM is (afaik) still static, classes once loaded cannot be modified, which is a problem for languages such as Ruby and JS, the basic data types of the JVM might not match your language, etc. Not sure if that makes a big difference, in essence you'll have to implement those semantics in either case, be it in RPython for PyPy or Java for the JVM.

bascule 14y ago
Classes can be changed after loading using HotSwap, it's just their method signature can't change: http://docs.oracle.com/javase/1.4.2/docs/guide/jpda/enhancements.html http://docs.oracle.com/javase/1.4.2/docs/guide/jpda/enhancem...

fijal 14y ago

I tried to pinpoint down some problems, but let me elaborate on this. As far as Parrot goes, it's not done despite years of development and it has lots and lots of problems, some with the approach, some with the actual implementation. But the truth is you can't do much with it today. As for JVM, which is definitely "done", you don't get access to low level concepts and you don't get support for most dynamic language concepts. For example in Jython escape analysis does not work at all, because everything escapes via frames (which in python is accessable from application level using sys._getframe). Invokedynamic only helps marginally here - you still need a JIT that can optimistically remove unlikely paths of the execution or a very smart compiler-to-the-JVM, which is unnecessary in PyPy. The other element is low level stuff. JVM is opaque, you can't code in terms of C structures. RPython as well, but it allows you if you insist and sometimes there are very good reasons to insist. Look in rpython/ directory in the hippy checkout for an implementation of an ordered dict with all it's oddities. In the JVM if such a primitive does not come (and it's unlikely enough), you're out of luck.