5 ms·

> Poor support for functional programming. Not open source. For the concurrency model and heap I'm not competent enough to debate, but for the other stuff you

> Poor support for functional programming. Not open source. For the concurrency model and heap I'm not competent enough to debate, but for the other stuff you say I can't agree. For functional programming in Java there are a lot of ways of doing it and tutorials as well, starting from those on DeveloperWorks https://www.ibm.com/developerworks/java/library/j-fp/index.html https://www.ibm.com/developerworks/java/library/j-fp/index.h... and OpenJDK shows that it is OpenSource indeed. For example, JBoss (Red Hat's division) uses OpenJDK. And I don't get the point of redesigning the JVM? What's wrong with it now? Is it's architecture somewhat wrong? Please elaborate..

tomp 15y ago
> > Poor support for functional programming. Let me elaborate. There are no tail calls. The GC is not suited to functional programs (lots of small, short-lived allocations) (though that has been improving recently). No first class functions (you have to make an object with a method instead). I might be wrong, but that's a significant overhead.
- drstrangevibes 15y ago
  these are scheduled to be addressed in java 8 & 9
- soc88 15y ago
  > The GC is not suited to functional programs (lots of small, short-lived allocations) WUT? That's _exactly_ the thing the GC is good at, and it's that way not since yesterday. The limiting factor is the speed of allocation (no GC involved), not GC.
  - tomp 15y ago
    The design of the GC can limit the speed of allocation as well. If your VM has a copying (moving) GC for the young generation, allocating a new object is exactly two very fast machine instructions: add to the current top of young heap, and check for overflow. That's how OCaml does it. I'm not sure how to do it concurrency-safe, though. Maybe using small per-thread heaps that get collected whenever an object is shared between threads, or by statically inferring which objects can be shared and which are thread-local.
    - lemming 15y ago
      If your VM has a copying (moving) GC for the young generation, allocating a new object is exactly two very fast machine instructions... That's how OCaml does it. That's also how the JVM does it. You can criticise the JVM on some things, but GC performance is not one of them. You should really make sure you're better informed before posting FUD like this.
      - tomp 15y ago
        I'm sorry. I was reading soc88's complaint about the speed of allocation, and blindly assumed that this was the problem with JVM. Please downvote my comment so that other people won't read it.
rbehrends 15y ago
One problem is that the JVM is specifically designed to be the backend for Java (and an outdated version of Java at that). It has a number of assumptions hardcoded into its design, making it difficult to use it as a target architecture for programming languages that have different requirements. You run into problems currently if you need structs, complex numbers, unusal parameter-passing conventions (call by reference, call by name, call by value-result), currying, tail calls, multiple dispatch, multiple inheritance, structural subtyping, algebraic datatypes, continuations, fast thread-local variables, micro-threads, coroutines, ICON/Python/C#/Sather-style generators, nested functions, software transactional memory, etc. It is not that you cannot have these features (after all, the JVM is Turing-complete, and quite a few JVM languages do support them), it's that at some point using the JVM loses its advantages over, say, targeting the LLVM or CLR. On top of that you have JVM-specific downsides to deal with (such as a fairly large memory footprint even for small processes).
- soc88 15y ago
  Most of it is supported in Scala, without much problems.
  - rbehrends 15y ago
    Scala's compiler has to jump through quite a few hoops to get it done (e.g., trampolines for some forms of tail recursion). It also can't fix the overhead issues involved with, say, complex numbers (which may or may not get fixed in the future [1]). Try to do a simple Gaussian elimination on a 1000x1000 matrix of complex numbers, for example. The indirections and per-object overhead are bad for your processor cache. [1] https://blogs.oracle.com/jrose/entry/value_types_in_the_vm https://blogs.oracle.com/jrose/entry/value_types_in_the_vm
    - soc88 15y ago
      That's why I said: > Most of it is supported in Scala scalac does not use trampolining. It rewrites tail-recurisve calls into “loops” (or jumps if you look at the bytecode). This is a case where the JVM lacks the necessary feature. There are experiments with value classes in Scala, which might allow you to use arrays of primitive numbers for them, but currently it looks like it won't happen for 2.10 because it can't be made work good enough in some corner cases like reflection, toString, equality, ...

tomp 15y ago

> > Poor support for functional programming. Let me elaborate. There are no tail calls. The GC is not suited to functional programs (lots of small, short-lived allocations) (though that has been improving recently). No first class functions (you have to make an object with a method instead). I might be wrong, but that's a significant overhead.

drstrangevibes 15y ago
these are scheduled to be addressed in java 8 & 9
soc88 15y ago
> The GC is not suited to functional programs (lots of small, short-lived allocations) WUT? That's _exactly_ the thing the GC is good at, and it's that way not since yesterday. The limiting factor is the speed of allocation (no GC involved), not GC.
- tomp 15y ago
  The design of the GC can limit the speed of allocation as well. If your VM has a copying (moving) GC for the young generation, allocating a new object is exactly two very fast machine instructions: add to the current top of young heap, and check for overflow. That's how OCaml does it. I'm not sure how to do it concurrency-safe, though. Maybe using small per-thread heaps that get collected whenever an object is shared between threads, or by statically inferring which objects can be shared and which are thread-local.
  - lemming 15y ago
    If your VM has a copying (moving) GC for the young generation, allocating a new object is exactly two very fast machine instructions... That's how OCaml does it. That's also how the JVM does it. You can criticise the JVM on some things, but GC performance is not one of them. You should really make sure you're better informed before posting FUD like this.
    - tomp 15y ago
      I'm sorry. I was reading soc88's complaint about the speed of allocation, and blindly assumed that this was the problem with JVM. Please downvote my comment so that other people won't read it.

rbehrends 15y ago

One problem is that the JVM is specifically designed to be the backend for Java (and an outdated version of Java at that). It has a number of assumptions hardcoded into its design, making it difficult to use it as a target architecture for programming languages that have different requirements. You run into problems currently if you need structs, complex numbers, unusal parameter-passing conventions (call by reference, call by name, call by value-result), currying, tail calls, multiple dispatch, multiple inheritance, structural subtyping, algebraic datatypes, continuations, fast thread-local variables, micro-threads, coroutines, ICON/Python/C#/Sather-style generators, nested functions, software transactional memory, etc. It is not that you cannot have these features (after all, the JVM is Turing-complete, and quite a few JVM languages do support them), it's that at some point using the JVM loses its advantages over, say, targeting the LLVM or CLR. On top of that you have JVM-specific downsides to deal with (such as a fairly large memory footprint even for small processes).

soc88 15y ago
Most of it is supported in Scala, without much problems.
- rbehrends 15y ago
  Scala's compiler has to jump through quite a few hoops to get it done (e.g., trampolines for some forms of tail recursion). It also can't fix the overhead issues involved with, say, complex numbers (which may or may not get fixed in the future [1]). Try to do a simple Gaussian elimination on a 1000x1000 matrix of complex numbers, for example. The indirections and per-object overhead are bad for your processor cache. [1] https://blogs.oracle.com/jrose/entry/value_types_in_the_vm https://blogs.oracle.com/jrose/entry/value_types_in_the_vm
  - soc88 15y ago
    That's why I said: > Most of it is supported in Scala scalac does not use trampolining. It rewrites tail-recurisve calls into “loops” (or jumps if you look at the bytecode). This is a case where the JVM lacks the necessary feature. There are experiments with value classes in Scala, which might allow you to use arrays of primitive numbers for them, but currently it looks like it won't happen for 2.10 because it can't be made work good enough in some corner cases like reflection, toString, equality, ...