3 ms·

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

• whartung 3y ago
  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”.
  • avgcorrection 3y ago
    I think getters/setters are more tricky than just reading and writing the fields. But all sorts of libraries except get/set so we often end up generating them.
• barrkel 3y ago
  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.