4 ms·

> Due to the way JVM does bytecode verification. In CLR you can selectively switch off the verification. > www.docjar.com/docs/api/sun/misc/Unsafe.htm I do n

by sklogic 12y ago

> Due to the way JVM does bytecode verification. In CLR you can selectively switch off the verification. > www.docjar.com/docs/api/sun/misc/Unsafe.htm I do not want an inefficient API. I want a low level functionality which can be mapped efficiently to what the real hardware does. > http://openjdk.java.net/jeps/169 http://openjdk.java.net/jeps/169 > This work is not intended to change the Java Language Specification or JVM bytecode instruction set. Okay... It's not going to be anything useful. > Java Virtual Machine And that's exactly why it sucks. There are much more universal VMs out there.

pjmlp 12y ago
> In CLR you can selectively switch off the verification. Why open the door to security exploits?! C derived languages are already enough. > I do not want an inefficient API. I want a low level functionality which can be mapped efficiently to what the real hardware does. Ever heard of intrinsics? Just because it looks like a method call, doesn't mean it is one. > Okay... It's not going to be anything useful. The final form is still ongoing work. > And that's exactly why it sucks. There are much more universal VMs out there Except for the CLR, I don't know any other. The universal VM has been pursuit since UNCOL was presented to the world.
- sklogic 12y ago
  > Why open the door to security exploits?! Why limit your VM expressive power? Restrict only untrusted loadable modules, do whatever you want in the trusted realm. > C derived languages are already enough. Not nearly. You won't have a managed VM with fast run-time code generation with C. > Just because it looks like a method call, doesn't mean it is one. Problem with intrinsics is that the majority of your optimisation passed do not know anything about them. See LLVM as an unfortunate example. Most of the SIMD intrinsics are not even used in a simplest constant folding there. > Except for the CLR Bingo! CLR is better. Scrap JVM.
  - pjmlp 12y ago
    > Not nearly. You won't have a managed VM with fast run-time code generation with C. I was speaking about security exploits. C should never have happened. > Bingo! CLR is better. Scrap JVM. Yes the CLR does quite a few things better than the JVM compatible VMs do currently. However, the JVM being a specification means I can find a JVM for anything has that a CPU, from smart cards up, servers, mainframes, cars, weapon guiding systems, factory robots, anything. So while technically better than the reference implementation, it doesn't cover the application spectrum JVM compatible VMs do. People tend to forget that Sun (now Oracle) JDK is just the reference implementation. Note I use both eco-systems since the beginning.
    - sklogic 12y ago
      > I was speaking about security exploits. C should never have happened. I see. I sort of agree - C should never have been exposed to the programmers. But a C-level VM is an extremely useful thing for implementing high level languages. I'd rather move safety checks a number of levels up, and leave VM level to performance-related stuff.
      - pjmlp 12y ago
        While I agree with you, I rather have AOT compilers, no need for VMs. And both Microsoft and Oracle are realizing this. .NET has native compilation on WP, with .NET Native coming on .NET 5. NGEN is a very simple compiler just for optimizing startup time. Java always had AOT compilers in commercial JVMs, but not on Sun. Now Oracle has SubstrateVM, and there are plans for AOT compilation at least in Java 10 timeframe.
        sklogic 12y ago
        VMs should be available in runtime (no matter if an AOT is present or not) in order to allow an efficient run-time code generation. And VMs should also be available during compilation to make it possible to efficiently implement reflective compile-time meta-languages (e.g., like Common Lisp). And the difference between abstract machines, intermediate representations and virtual machines is very elusive (see all the confusion around LLVM for example).

by sklogic 12y ago

pjmlp 12y ago

> In CLR you can selectively switch off the verification. Why open the door to security exploits?! C derived languages are already enough. > I do not want an inefficient API. I want a low level functionality which can be mapped efficiently to what the real hardware does. Ever heard of intrinsics? Just because it looks like a method call, doesn't mean it is one. > Okay... It's not going to be anything useful. The final form is still ongoing work. > And that's exactly why it sucks. There are much more universal VMs out there Except for the CLR, I don't know any other. The universal VM has been pursuit since UNCOL was presented to the world.

sklogic 12y ago
> Why open the door to security exploits?! Why limit your VM expressive power? Restrict only untrusted loadable modules, do whatever you want in the trusted realm. > C derived languages are already enough. Not nearly. You won't have a managed VM with fast run-time code generation with C. > Just because it looks like a method call, doesn't mean it is one. Problem with intrinsics is that the majority of your optimisation passed do not know anything about them. See LLVM as an unfortunate example. Most of the SIMD intrinsics are not even used in a simplest constant folding there. > Except for the CLR Bingo! CLR is better. Scrap JVM.
- pjmlp 12y ago
  > Not nearly. You won't have a managed VM with fast run-time code generation with C. I was speaking about security exploits. C should never have happened. > Bingo! CLR is better. Scrap JVM. Yes the CLR does quite a few things better than the JVM compatible VMs do currently. However, the JVM being a specification means I can find a JVM for anything has that a CPU, from smart cards up, servers, mainframes, cars, weapon guiding systems, factory robots, anything. So while technically better than the reference implementation, it doesn't cover the application spectrum JVM compatible VMs do. People tend to forget that Sun (now Oracle) JDK is just the reference implementation. Note I use both eco-systems since the beginning.
  - sklogic 12y ago
    > I was speaking about security exploits. C should never have happened. I see. I sort of agree - C should never have been exposed to the programmers. But a C-level VM is an extremely useful thing for implementing high level languages. I'd rather move safety checks a number of levels up, and leave VM level to performance-related stuff.
    - pjmlp 12y ago
      While I agree with you, I rather have AOT compilers, no need for VMs. And both Microsoft and Oracle are realizing this. .NET has native compilation on WP, with .NET Native coming on .NET 5. NGEN is a very simple compiler just for optimizing startup time. Java always had AOT compilers in commercial JVMs, but not on Sun. Now Oracle has SubstrateVM, and there are plans for AOT compilation at least in Java 10 timeframe.
      - sklogic 12y ago
        VMs should be available in runtime (no matter if an AOT is present or not) in order to allow an efficient run-time code generation. And VMs should also be available during compilation to make it possible to efficiently implement reflective compile-time meta-languages (e.g., like Common Lisp). And the difference between abstract machines, intermediate representations and virtual machines is very elusive (see all the confusion around LLVM for example).