The 185-Microsecond Type Hint

EdNutting

Wild speculation: Could the extra speedup be due to some kind of JIT hotpath optimisation that the previous reflective non-inlinable call prevented, and which the new use of the single `arrayLength` bytecode enabled? E.g. in production maybe you're seeing the hotpath hit a JIT threshold for more aggressive inlinng of the parent function, or loop unrolling, or similar, which might not be triggered in your test environment (and which is impossible when inlining is prevented)?

zahlman

> the compiler had enough static information to emit a single arraylength bytecode instruction. I'm skeptical. If it can prove that the input actually matches the hint, then why does it need the hint ? If it can't, what happens at runtime if the input is something else? > We replaced a complex chain of method calls with one CPU instruction. JVM bytecodes and CPU instructions really shouldn't be conflated like that, although I assume this was just being a bit casual with the prose.

TacticalCoder

> When a client asks for the time, it sends a random nonce. The server replies with a signed certificate containing both the nonce and a timestamp, proving the response happened after the request. Oh that's cool. Apparently one of the protocol's goal is to catch lying parties and to prove they were lying about the (rough) time.