3 ms·

The JVM isn't limited to Java, for example GraalJs is also an ecmascript compliant JS engine

by The_rationalist 6y ago

pjmlp 6y ago
Graal uses a complete different implementation model.
- The_rationalist 6y ago
  Never heard about nashorn, jruby, groovy then ? It all use the same C2 JIT as Java
  - pjmlp 6y ago
    None of them relate to Graal, they just pretend to be Java to the JVM.
    - The_rationalist 6y ago
      The whole problem this solves doesn't exist in the JVM. The JVM isn't limited to Java, for example: nashorn, jruby, groovy Hence the optimization would make sense for the JVM for those client languages: nashorn, jruby, groovy, etc Quite trivial to understand, isn't it?
      - pjmlp 6y ago
        Except Graal isn't the JVM, quite trivial to understand by anyone that knows a little bit about compilers.
        The_rationalist 6y ago
        Graalvm is an optional component for the jdk that communicate with others (the garbage collector, TLS, etc through the JVMCI AKA jvm component interface. But that doesn't matter at all it is pointless to talk about graal, my other examples such as nashorn/jruby do not use graalvm they use the standard jdk C2 and would still benefit from the optimization from the v8 blog because they have the same semantics as they implement dynamic languages. It is useful for the jdk to implement optimizations that have no use for Java because the jdk is much more than that. I'm being downvoted for stating this truism and educating people. Edit: off topic but I randomly stumbled on upon an interesting comment about CoreCLR and it happen that it was yours (2019), do you have news regarding the development/improvements of RyuJIT?
        pjmlp 6y ago
        Sorry, wrong again, you are the one that need to update your information. Graal JIT compiler as used in OpenJDK, is a subset of GraalVM, and it has been such a burden to keep in sync with proper GraalVM, that it was decided to drop it and invest into improving C2 instead. https://bugs.openjdk.java.net/issues/?jql=labels+%3D+graal https://bugs.openjdk.java.net/issues/?jql=labels+%3D+graal Second, nashorn tricks with invokedynamic and pretending to be Java never worked to the extent achieved by V8, hence why its development was dropped and everyone got told to migrate to GraalVM JavaScript. https://www.graalvm.org/reference-manual/js/NashornMigrationGuide/ https://www.graalvm.org/reference-manual/js/NashornMigration... Third, JRuby always suffered to pretend to be Java to achieve acceptable performance on the JVM, even with invokedynamic. "JRuby: The Hard Parts with Charles Nutter" https://www.youtube.com/watch?v=RvUouqLxgrY https://www.youtube.com/watch?v=RvUouqLxgrY And Graal uses a completely other execution model for Ruby, TruffleRuby, https://www.graalvm.org/reference-manual/ruby/ https://www.graalvm.org/reference-manual/ruby/ As for CLR, yes there have been plenty of progress, .NET Native (which uses VC++ C2 compiler), CoreRT, and now the upcoming .NET 6 AOT compiler that is supposed to replace them. There are a series of blog posts related to .NET 5 improvements, including C++ runtime code being replaced by modern C# features, and future roadmap.

The JVM isn't limited to Java, for example GraalJs is also an ecmascript compliant JS engine

pjmlp 6y ago

Graal uses a complete different implementation model.

The_rationalist 6y ago
Never heard about nashorn, jruby, groovy then ? It all use the same C2 JIT as Java
- pjmlp 6y ago
  None of them relate to Graal, they just pretend to be Java to the JVM.
  - The_rationalist 6y ago
    The whole problem this solves doesn't exist in the JVM. The JVM isn't limited to Java, for example: nashorn, jruby, groovy Hence the optimization would make sense for the JVM for those client languages: nashorn, jruby, groovy, etc Quite trivial to understand, isn't it?
    - pjmlp 6y ago
      Except Graal isn't the JVM, quite trivial to understand by anyone that knows a little bit about compilers.
      - The_rationalist 6y ago
        Graalvm is an optional component for the jdk that communicate with others (the garbage collector, TLS, etc through the JVMCI AKA jvm component interface. But that doesn't matter at all it is pointless to talk about graal, my other examples such as nashorn/jruby do not use graalvm they use the standard jdk C2 and would still benefit from the optimization from the v8 blog because they have the same semantics as they implement dynamic languages. It is useful for the jdk to implement optimizations that have no use for Java because the jdk is much more than that. I'm being downvoted for stating this truism and educating people. Edit: off topic but I randomly stumbled on upon an interesting comment about CoreCLR and it happen that it was yours (2019), do you have news regarding the development/improvements of RyuJIT?
        pjmlp 6y ago
        Sorry, wrong again, you are the one that need to update your information. Graal JIT compiler as used in OpenJDK, is a subset of GraalVM, and it has been such a burden to keep in sync with proper GraalVM, that it was decided to drop it and invest into improving C2 instead. https://bugs.openjdk.java.net/issues/?jql=labels+%3D+graal https://bugs.openjdk.java.net/issues/?jql=labels+%3D+graal Second, nashorn tricks with invokedynamic and pretending to be Java never worked to the extent achieved by V8, hence why its development was dropped and everyone got told to migrate to GraalVM JavaScript. https://www.graalvm.org/reference-manual/js/NashornMigrationGuide/ https://www.graalvm.org/reference-manual/js/NashornMigration... Third, JRuby always suffered to pretend to be Java to achieve acceptable performance on the JVM, even with invokedynamic. "JRuby: The Hard Parts with Charles Nutter" https://www.youtube.com/watch?v=RvUouqLxgrY https://www.youtube.com/watch?v=RvUouqLxgrY And Graal uses a completely other execution model for Ruby, TruffleRuby, https://www.graalvm.org/reference-manual/ruby/ https://www.graalvm.org/reference-manual/ruby/ As for CLR, yes there have been plenty of progress, .NET Native (which uses VC++ C2 compiler), CoreRT, and now the upcoming .NET 6 AOT compiler that is supposed to replace them. There are a series of blog posts related to .NET 5 improvements, including C++ runtime code being replaced by modern C# features, and future roadmap.