Clojurians Log v2

I'll be virtually there.

Excellent! Last year's virtual track with video conferencing in a bunch of meetups around the world seemed really cool.

Neato. I'm hanging out on discord as well atm.

Ah, yeah, I see your 🟢 there 🙂

🙂

I'm not excited at getting up so early on Wednesday (so I can make it to CLI/tools group meeting at 3:30 pm EST) but overall I'm excited about Conj! I haven't even looked at the schedule beyond that...

Seems that Rich is giving a talk? Been a while.

I think there is a lot of interesting things happening on the JVM. I wonder how it'll impact on Clojure

i.e., value classes, final meaning final, immutability and so on

brb - school run

Rich is only doing the 10 minute welcome slot -- which was what he did last year on day 2, I think?

None of the Java language stuff will affect Clojure tho', only the underlying JVM stuff and standard library additions. And even then, Clojure 1.13 is going to target JDK 17 I think (a big step forward from JDK 8 which Clojure 1.12 still supports).

I hope that with the latest enhancements to the JVM, that we'll see some improvements, even as gasp-horror side effects 🙂

Well, every JVM update tends to make GC "better" in various ways. The Compact Object Headers stuff has reduced our heap consumption in production. We tend to run the latest JDK with --enable-preview in production so we can try out new things.

Nice!

I think we should try that too

Our JVM options script (for production):

#!/bin/sh

# jvm_opts.sh job -- for fast startup etc
# jvm_opts.sh process -- for long-running processes

jvm_opts="--enable-preview"
jvm_opts="${jvm_opts} -Dclojure.compiler.direct-linking=true -Dclojure.spec.check-asserts=true"
jvm_opts="${jvm_opts} -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager"
jvm_opts="${jvm_opts} -Dlog4j2.julLoggerAdapter=org.apache.logging.log4j.jul.CoreLoggerAdapter"
jvm_opts="${jvm_opts} -Dlog4j2.formatMsgNoLookups=true"
jvm_opts="${jvm_opts} -Djdk.httpclient.allowRestrictedHeaders=host"
jvm_opts="${jvm_opts} -Djdk.traceAllThreads=false -Djdk.tracePinnedThreads=short"
jvm_opts="${jvm_opts} -XX:-OmitStackTraceInFastThrow"
jvm_opts="${jvm_opts} -XX:+HeapDumpOnOutOfMemoryError"
jvm_opts="${jvm_opts} -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders"

case "$1" in
  job)
    # since this is a cron job, we want the JVM to be fast-to-start
    jvm_opts="${jvm_opts} -client -XX:+TieredCompilation -XX:TieredStopAtLevel=1"
    ;;
  process)
    jvm_opts="${jvm_opts} -XX:+UseG1GC -XX:MaxGCPauseMillis=100"
    ;;
  *)
    echo "jvm_opts.sh job|process"
    exit 1
esac

echo ${jvm_opts}

For dev, we use the "attach self" option (so nREPL can kill long-running evals even on JDK 21+) and soon we'll start using the vthreads=target option, once the memory leak in core.async is fixed.

We're on 25 at work, so I can swing with the -XX:+UseCompat.... directly 🙂

btw, you rewrite that as an array

(well, if you're using bash)

We're waiting for New Relic to support JDK 25. All their dev work is done, so it's just a matter of churning through their release process.

ARGS=(
    --enable-native-access=ALL-UNNAMED
    -XX:+UseCompactObjectHeaders
    -XX:+UseStringDeduplication
    -XX:+AlwaysPreTouch
    -Djava.net.preferIPv4Stack=true
    -Djava.security.egd=file:/dev/./urandom
    -Dconfig=$CONFIG_EDN
    -Djna.library.path=/usr/lib/x86_64-linux-gnu
    -Dcom.sun.management.jmxremote.ssl=false
    -Dcom.sun.management.jmxremote.authenticate=false
    -javaagent:/tmp/jmx_prometheus_javaagent.jar=$JMX_EXPORTER_PORT:jmx-exporter-config.yml
#    -javaagent:/tmp/opentelemetry-agent.jar
)

exec java "${ARGS[@]}" $JVM_OPTS -jar $APPLICATION_JAR $RUN_OPTS $@

Heh, that script grew from just one or two lines, over time... and it's /bin/sh 🙂

🙂 Organic growth

Going to deploy into our staging environment with compactheaders and see what happens

deployed..will monitor zee charts!