3 ms·

Interesting that the challenge they felt particularly worth calling out wasn't about solving hard algorithms or design problems, but rather making those solutio

by Ralith 14y ago

mindcrime 14y ago
Interesting that the challenge they felt particularly worth calling out wasn't about solving hard algorithms or design problems, but rather making those solutions function on the limited JVM platform. Perhaps this will give pause to the next language developer tempted to target the JVM for no reason other than its popularity. From Guy Steele's blog post[1]: "Nevertheless, over the last few years, as we have focused on implementing a compiler targeted to the Java Virtual Machine, we encountered some severe technical challenges having to do with the mismatch between the (rather ambitious) Fortress type system and a virtual machine not designed to support it (that would be every currently available VM, not just JVM)." So it doesn't sound like this is any particular indictment of the JVM. [1]: https://blogs.oracle.com/projectfortress/entry/fortress_wrapping_up https://blogs.oracle.com/projectfortress/entry/fortress_wrap...
- scott_s 14y ago
  They published a paper on it last year, "Type-checking Modular Multiple Dispatch with Parametric Polymorphism and Multiple Inheritance": http://www.mpi-sws.org/~skilpat/papers/multipoly.pdf http://www.mpi-sws.org/~skilpat/papers/multipoly.pdf (LtU discussion: http://lambda-the-ultimate.org/node/4236 http://lambda-the-ultimate.org/node/4236)
- mariusmg 14y ago
  If you're doing an "ambitious" type system, you might as well do your own VM. Trying to shoehorn stuff into jvm/clr/parrot/whatever is hardly ideal.
- Ralith 14y ago
  An indictment of VMs in general, then. They're almost universally targeted at supporting a particular language, and cause problems when more advanced concepts (such as cutting-edge type systems) must be implemented.
  - bascule 14y ago
    With InvokeDynamic the JVM is pretty much the first to open up its full set of compiler optimizations to any language that implements its method dispatch semantics using InDy's set of tools. InDy allows language implementers to define their own method dispatch semantics, polymorphic inline caches, and deoptimization in the event that assumptions change e.g. the class hierarchy has been modified.
    - Ralith 14y ago
      There is rather more to type systems than method dispatch.
      - bascule 14y ago
        Type checking at method dispatch is the only part of the equation (literally, in the case of Fortress) where the JVM would come into play. Everything else happens ahead of time in the compiler. With InDy, the JVM can do a one-time check, verifying whatever security invariants the language has put in place, and after that, the MethodHandle is in InDy's polymorphic inline cache and the security checks can be skipped on subsequent calls. All subsequent calls dispatch at Java speed and can be inlined by HotSpot just like any other Java method. Writing your compiler on top of the JVM using InDy might help make this clearer!
  - michaelcampbell 14y ago
    > that would be every currently available VM, not just JVM Perhaps of just the current VM's, and not some intrinsic limitation of VM's in general.
felipemnoa 14y ago
I do wonder what about the JVM makes it harder as opposed to using any other platform? Would it have been easier on Javascript or Ruby?
- Ralith 14y ago
  It's not about the language their implementation is written in (although many people find MLs and Lisps to make compilers and interpreters much easier to implement), it's about the machine that their implementation targets. The JVM imposes many restrictions on and makes many assumptions about the behavior of client languages as a direct result from being built to host Java. I have no doubt that the CLR is similar. Javascript and Ruby are not typically compilation targets, bar things like ClojureScript.
bascule 14y ago
I'm curious if the impedance mismatch Guy Steele describes between Fortress's type system and the JVM could be remedied by InvokeDynamic. Unfortunately he didn't mention anything about it in his blog post.

by Ralith 14y ago

mindcrime 14y ago

Interesting that the challenge they felt particularly worth calling out wasn't about solving hard algorithms or design problems, but rather making those solutions function on the limited JVM platform. Perhaps this will give pause to the next language developer tempted to target the JVM for no reason other than its popularity. From Guy Steele's blog post[1]: "Nevertheless, over the last few years, as we have focused on implementing a compiler targeted to the Java Virtual Machine, we encountered some severe technical challenges having to do with the mismatch between the (rather ambitious) Fortress type system and a virtual machine not designed to support it (that would be every currently available VM, not just JVM)." So it doesn't sound like this is any particular indictment of the JVM. [1]: https://blogs.oracle.com/projectfortress/entry/fortress_wrapping_up https://blogs.oracle.com/projectfortress/entry/fortress_wrap...

scott_s 14y ago
They published a paper on it last year, "Type-checking Modular Multiple Dispatch with Parametric Polymorphism and Multiple Inheritance": http://www.mpi-sws.org/~skilpat/papers/multipoly.pdf http://www.mpi-sws.org/~skilpat/papers/multipoly.pdf (LtU discussion: http://lambda-the-ultimate.org/node/4236 http://lambda-the-ultimate.org/node/4236)
mariusmg 14y ago
If you're doing an "ambitious" type system, you might as well do your own VM. Trying to shoehorn stuff into jvm/clr/parrot/whatever is hardly ideal.
Ralith 14y ago
An indictment of VMs in general, then. They're almost universally targeted at supporting a particular language, and cause problems when more advanced concepts (such as cutting-edge type systems) must be implemented.
- bascule 14y ago
  With InvokeDynamic the JVM is pretty much the first to open up its full set of compiler optimizations to any language that implements its method dispatch semantics using InDy's set of tools. InDy allows language implementers to define their own method dispatch semantics, polymorphic inline caches, and deoptimization in the event that assumptions change e.g. the class hierarchy has been modified.
  - Ralith 14y ago
    There is rather more to type systems than method dispatch.
    - bascule 14y ago
      Type checking at method dispatch is the only part of the equation (literally, in the case of Fortress) where the JVM would come into play. Everything else happens ahead of time in the compiler. With InDy, the JVM can do a one-time check, verifying whatever security invariants the language has put in place, and after that, the MethodHandle is in InDy's polymorphic inline cache and the security checks can be skipped on subsequent calls. All subsequent calls dispatch at Java speed and can be inlined by HotSpot just like any other Java method. Writing your compiler on top of the JVM using InDy might help make this clearer!
- michaelcampbell 14y ago
  > that would be every currently available VM, not just JVM Perhaps of just the current VM's, and not some intrinsic limitation of VM's in general.

felipemnoa 14y ago

I do wonder what about the JVM makes it harder as opposed to using any other platform? Would it have been easier on Javascript or Ruby?

Ralith 14y ago
It's not about the language their implementation is written in (although many people find MLs and Lisps to make compilers and interpreters much easier to implement), it's about the machine that their implementation targets. The JVM imposes many restrictions on and makes many assumptions about the behavior of client languages as a direct result from being built to host Java. I have no doubt that the CLR is similar. Javascript and Ruby are not typically compilation targets, bar things like ClojureScript.

bascule 14y ago

I'm curious if the impedance mismatch Guy Steele describes between Fortress's type system and the JVM could be remedied by InvokeDynamic. Unfortunately he didn't mention anything about it in his blog post.