Clojurians Log v2
clojure-madison
It's been a while! Hope ya'll don't mind if I use this Slack to keep up with ya'll 🙂 I wanted to share a simple example of how state can make things weird to reason about - the thing that surprised me was finding it in the HotSpot code. It seems that to invoke the C1 or C2 compiler for a JVM method, callers need to https://github.com/openjdk/jdk/blob/cc65836d00de7041e7d32e7f15d98108b1ae47a0/src/hotspot/share/compiler/compileBroker.cpp#L1185`CompileBroker::compile_method_base`https://github.com/openjdk/jdk/blob/cc65836d00de7041e7d32e7f15d98108b1ae47a0/src/hotspot/share/compiler/compileBroker.cpp#L1185. The code around this area seems to determine when a method is compilable or not, so you should explore if you're curious. In any case, before compilation is started, it seems like some state needs to be set up https://github.com/openjdk/jdk/blob/cc65836d00de7041e7d32e7f15d98108b1ae47a0/src/hotspot/share/compiler/compileBroker.cpp#L1244, which was weird because the return value was never used! I definitely got some whiplash from that after being away from big C++ codebases for so long.
wow I had no idea! brings up whether clojure's collections are really immutable.
omg this section name: https://docs.oracle.com/javase/specs/jls/se25/html/jls-17.html#jls-17.5.3`final`https://docs.oracle.com/javase/specs/jls/se25/html/jls-17.html#jls-17.5.3
Hi Sayan! Along these lines in terms of state management, some Java features just landed in JVM 25, https://openjdk.org/jeps/513 and https://openjdk.org/jeps/502. AFAICT both help being more flexible in initializing state in the Java language.
I found this to be interesting, at the end of the Stable Values proposal:
> Unfortunately, the core reflection API allows instance final fields to be updated arbitrarily, except for fields that are members of hidden classes or records. In the long term we intend to limit the reflection API so that all instance final fields can be trusted, as part of the broader shift toward integrity by default. Until then, however, the mutability of most instance final fields will limit the constant-folding optimizations enabled by stable values.
>
I wonder how many nice optimizations were lost because of that. I'm sure it would be a cool experiment to have a branch of the JDK that did treat final fields as immutable if a certain flag was passed, and seeing what kind of gains could be observed in real programs.