Hacker News Reader

Comment by The_rationalist | Hacker News Reader

I wonder if Openjdk or other VMs could benefit from a similar optimization.

Java knows at compile time exactly how many arguments are passed to a method, so presumably there's no adapter layer.

Wrong, Java Varargs functions can take spreaded arrays as Var parameters hence the number for this not uncommon case (e.g jdbc apis, format(), etc) is only known at runtime

But in Java (and similar), you have to be explicit about varargs. In JavaScript, every function supports varargs. This will run just fine:

    function print(arg) {
        console.log(arg);
    }
    print("a", "b", "c");

It’ll only output "a", obviously. In fact, this will run just fine too:

    print();

You’ll get "undefined" in the console, but it’ll work.

JavaScript’s nature is that arguments are in the "arguments" pseudo-array, and the parameters are just fancy names for different values in "arguments". See:

    function count() {
        console.log(arguments.length);
    }
    count();
    count("a");
    count("a", "b");

In order, you’ll get: 0, 1, and 2. Despite the fact that "count" has no parameters in the definition.

In the first function ("print"), "arg" is just syntax sugar for "arguments[0]".

What I’m getting at is: in C, Java, etc., the compiler knows what is a varargs function and what isn’t. In JavaScript, the interpreter/compiler doesn’t and has to assume everything is.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Hence, “pseudo-array”

Great explanation and I think you are right for Java, Kotlin, etc. But what about dynamic languages on the JVM such as GraalJS, groovy, etc?

> In the first function ("print"), "arg" is just syntax sugar for "arguments[0]".

So much so that they reflect one another: you can set `arguments[0]` and retrieve that value from `arg`, and the other way around:

    function foo(arg0, arg1) {
      arg0 = "foo";
      arguments[1] = "bar";
      console.log(Array.from(arguments), arg0, arg1);
    }
    foo(1, 2)

will log

    [ "foo", "bar" ] foo bar

Although in reality optimising engines treat `arguments` as a keyword of sorts: they will not reify the object if they don't have to. However this meant they had to deoptimise a fair bit before the "spread" arguments arrived as that was how you'd call your "super".

Note that there's no such thing as spreaded arrays in Java. Instead, varargs are just syntactic sugar for arrays.

> Java Varargs functions can take spreaded arrays as Var parameters

That's syntactic sugar for an array, in the most literal way possible: when you define `func(Object… args)` the actual bytecode is that of `func(Object[] args)`, and you can pass in an array to stand in for the entire varargs.

So no, they're right. The varags just counts as 1 formal parameter.

Yep! One can even define the `main` method using either:

    public static void main(String[] args)
    public static void main(String... args)

I'd imagine not. Assuming the JVM's semantics aren't too different from those of the Java language, you always know at compile time how many arguments a function takes[1], so this optimization wouldn't be relevant.

[1]: Java does have variadic functions, but we also know at compile time which functions have such a signature, so it probably just desugars to a normal array as the final argument.

well, there's also invokedynamic, but call site selection is in user space, so one can implement this optimization for it's own dynamic language without violating the JVM own static invocation rules.

The whole problem this solves doesn't exist in the JVM.

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

Graal uses a complete different implementation model.

Never heard about nashorn, jruby, groovy then ? It all use the same C2 JIT as Java

None of them relate to Graal, they just pretend to be Java to the JVM.

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?

Except Graal isn't the JVM, quite trivial to understand by anyone that knows a little bit about compilers.

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?

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

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

And Graal uses a completely other execution model for Ruby, TruffleRuby, 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.

Reply on news.ycombinator.com