Hacker News Reader

Comment by moondowner | Hacker News Reader

> 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.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..

View on HN

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).

Most of it is supported in Scala, without much problems.

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

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, ...

No, Scala cannot optimize all forms of tail recursion (such as mutually tail-recursive functions). In that case, you have to use scala.util.control.TailCalls to do it via trampolines.

The proposed value classes in Scala do not solve the overhead problem for complex numbers. As specified in SIP-15, they have exactly one field, and basically are designed to give you information hiding for classes with a single field without boxing overhead.

Edit: By the way, you don't have to sell me on Scala. I have been using it since 1.x (I have forgotten the exact version number).

Sorry, if I appeared as I tried to sell you something.

> No, Scala cannot optimize all forms of tail recursion (such as mutually tail-recursive functions). In that case, you have to use scala.util.control.TailCalls to do it via trampolines.

I guess we are just nick-picking each other here. :-) I think be both understand what the compiler can do, cannot do, what it does automatically and what not.

Have you seen the Complex implementation which uses an underlying Long as Floats? (Sounds ugly but seems to work quite nicely.)

The biggest problem at the moment is putting value types in an array. Currently it seems like some ugly clutch/work-around ill be used. I hope SIP-15 gets either rejected or delayed until there is a better solution, Because the difference between an array of references and an array of primitives really matters imho.

> > 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.

> 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.

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.

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.

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.

these are scheduled to be addressed in java 8 & 9

Reply on news.ycombinator.com