Do you know if these are just Java features, or if they're backed by new JVM bytecode intrinsics to ensure that these destructuring matches are able to be performed efficiently? (Think e.g. Erlang's recent "fused checks", where it can figure out whether something is an integer and whether it's non-negative using a single abstract-machine instruction.)
That is, for languages that already have features like this (e.g. Scala), will those languages be getting any benefits as a byproduct of Java getting these features?
There is no @IntrinsicCandidate, so I don't expect Hotspot to special-case any of this yet. The machinery described so far merely computes an array index, and there is a subsequent lookupswitch opcode that selects the appropriate case body to run.
I'd be somewhat surprised if Hotspot could unroll the checking loop and eliminate the subsequent switch. So the Java implementation looks rather bad from a performance point of view (but it's obviously designed for compact bytecode and future optimization). Scala could certainly do the same (the magic of invokedynamic is that it's not magic), and probably much better in many cases, even on current Hotspot.
Haha, it's already merged. I should have run “git pull” before writing my comment. The “Dumbest possible strategy” comment is already gone, and appropriately so.
This is one reason why invokedynamic is so interesting: it is possible to switch implementations without recompiling everything.
I don't think you need any byte code intrinsics for pattern matching. Special cases aside, there is no generic efficient way to describe them. Java byte code is badly designed anyway so it's up to the VM compiler to do the heavy lifting.
I don't think it's that badly designed. JVM bytecode is not much more than AST serialization, a post-order traversal of expression trees. It's designed for verification - every control flow needs the same typed stack - rather than speed of interpretation, though it's easy to write an interpreter. It's zipped, so it doesn't need to be optimized for space.
I didn't like how it did exceptions, that seemed a bit too much like its own little mini VM. JSR/RET etc, return addresses on the operand stack. But that's gone now.
This is actually a core concept of the Java runtime. The compilers and what not “know” about idiomatic Java. The trivial example is things like the getter/setter pattern so prevalent in Java.
But the compiler doesn’t treat them as anything special, it’s just a method. But the runtime is well aware of this pattern, and what the resulting, straightforward byte code looks like, and can make optimization decisions from there.
So where, perhaps, you may want try and write “clever” code to bend the compiler to your will, Java promotes “just write Java, no reason for the code to be tricky, let the compiler and VM implementations be tricky”.
That is, for languages that already have features like this (e.g. Scala), will those languages be getting any benefits as a byproduct of Java getting these features?