Hacker News Reader

Comment by pavanky | Hacker News Reader

This is not "differences between CLR and JVM", but more of "why I think CLR is better than JVM".

Anyway the biggest issue I have seen in my line of work (building GPU software, and people want GPU acceleration from their language of choice) is that JVM does not provide a way to handle external resources properly. Calling garbage collection does not guarantee that the out of scope objects will be finalized. This results in either code that uses up a lot of memory or code that is very un-java like.

Yes I know try with resources exist, but the problem still exists for any temporary variables you create within the block.

If anyone here has a better solution, I am all ears.

View on HN

I suggest never to call the garbage collector with the expectation that anything in particular will happen--not in CLR and not in the JVM. Also, do not use finalizers for this!

JNI and P/Invoke are not really that different except that P/Invoke is a lot easier to implement. But CLR does not know how to cleanup unmanaged resources automagically.

edit: I removed my notes about "try with resource" and AutoCloseable

Well the only solution remaining is writing C like code, where users have to allocate and free memory manually which is not a solution if you ask me.

May I interest you in Rust? https://www.rust-lang.org/

We already have a wrapper for rust[1] and C++, fortran, python and various other languages[2].

I was talking about people not wanting to move away from their language of choice which results in us having to try and support them as well.

[1] https://github.com/arrayfire/arrayfire-rust

[2] https://github.com/arrayfire

The trick is to write a managed wrapper that takes care of the housekeeping with AutoCloseable / IDisposable, exception flow control, etc. Careful use of arrays, nonboxed types, and statics instead of beating up the heap space... it can be tedious but someone's got to do the dirty work.

You can use a NextStep style object pool.

  try (ObjectPool pool = new ObjectPool()) {
    ...
    Foo foo = pool.register(new Foo());
    ...
    Bar bar = pool.register(new Bar());
  }

When ObjectPool is closed, it closes all its registered objects too.

Note that this would be a lot easier with a language like Scala or Kotlin.

We are implementing a numerical library. The problem is with temporary buffers when you are chaining functions.

    Array C = Array.Add(A, Array.sin(B))

The output C and the output of Array.sin(B) have not been allocated from the object pool.

This is quite difficult and puts you more into the realm of DSL's. Have you tried adding a fluent Builder interface? It's one of the better ways to handle these types of problems in Java. For example:

``` ArrBuilder = arrs; arrs.add(A, arrs.sin(B)); Array C = arrs.get(); ```

Otherwise if you're willing to do Lombok style AST manipulation you could of course do most anything you wanted, perhaps even proper operator overloading:

``` @Arrays public void test() { Array C = A + sin(B); } ```

(Just be ready for the Java programmers to rebel on you and your "dark arts" ;) )

Well for constructs like that, it's what escape analysis is meant to be good at, as those functions would be small and inlineable.

How does something like Graal handle memory when emulating C? I imagine using JVM 1.9 will help?

You can do manual memory allocation in Java using the "unsafe" API. It's relatively common in high performance libraries.

There are actually three implementations of C on top of Graal/Truffle by now.

TruffleC was the first and it maps malloc to the JVM's Unsafe malloc equivalent. So if you double free you trash the VM basically.

ManagedC ignores calls to free() and garbage collects the C programs heap.

Sulong interprets LLVM bytecode. I don't know how it does memory management.

Reply on news.ycombinator.com