The locking macro fails bytecode verification on Graal native-image and ART runtime

Question

Android ART runs compile time verification on bytecode and fails on any usage of the locking macro. The error looks like that seen in CLJ-1829 (in that case clojure.core.server/stop-server calls the locking macro):

10-16 14:49:26.801 2008-2008/? E/AndroidRuntime: java.lang.VerifyError: Rejecting class clojure.core.server$stop_server because it failed compile-time verification (declaration of 'clojure.core.server$stop_server' appears in /data/app/com.clojure_on_android-1/base.apk)

Cause: From discussion on an Android issue (https://code.google.com/p/android/issues/detail?id=80823), it seems this is due to more strictly enforcing the "structural locking" provisions in the JVM spec (https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-2.html#jvms-2.11.10).

It appears that the mixture of monitor-enter, monitor-exit, and the try/finally block in locking create paths that ART is flagging as not having balanced monitorenter/monitorexit bytecode. Particularly, monitorenter and monitorexit themselves can throw (on a null locking object). The Java bytecode does some tricky exception table handling to cover these cases which (afaict) is not possible to do without modifying the Clojure compiler.

Approach: One possible approach is to have locking invoke the passed body in the context of a synchronized block in Java. This avoids the issue of the tricky bytecode by handing it over to Java but has unknown performance impacts.

Patch: clj-1472-3.patch

See also: Examination of the bytecode as compared to a java synchronized block shows up a number of differences:
https://gist.github.com/AdamClements/2ae6c4919964b71eb470

Screened by: Alex Miller - I'm marking this screened as I think it is a viable approach that fixes the issue and due to the infrequency of its use, I'm not really that concerned about it being a performance problem. I will flag that I think another way to handle this would be to make locking a special form with compiler support, but I'm not sure whether that's worth doing or not, so I will leave that to Rich to decide.

Answer 1

Comment made by: eraserhd

With clj-1472-3.patch, I can get builds working sometimes. Other times I get this error:

`
fatal error: com.oracle.svm.core.util.VMError$HostedError: Objects with relocatable pointers must be immutable

    at com.oracle.svm.core.util.VMError.guarantee(VMError.java:85)                                                      
    at com.oracle.svm.hosted.image.NativeImageHeap.choosePartition(NativeImageHeap.java:492)                            
    at com.oracle.svm.hosted.image.NativeImageHeap.addObjectToBootImageHeap(NativeImageHeap.java:451)                   
    at com.oracle.svm.hosted.image.NativeImageHeap.addObject(NativeImageHeap.java:271)                                  
    at com.oracle.svm.hosted.image.NativeImageCodeCache.addConstantToHeap(NativeImageCodeCache.java:369)                
    at com.oracle.svm.hosted.image.NativeImageCodeCache.addConstantsToHeap(NativeImageCodeCache.java:356)               
    at com.oracle.svm.hosted.NativeImageGenerator.doRun(NativeImageGenerator.java:882)                                  
    at com.oracle.svm.hosted.NativeImageGenerator.lambda$run$0(NativeImageGenerator.java:401)                           
    at java.util.concurrent.ForkJoinTask$AdaptedRunnableAction.exec(ForkJoinTask.java:1386)                             
    at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)                                                  
    at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)                                      
    at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)                                              
    at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)                                     

`

I'm on Graal rc10, and the shortest code I can find to generate that error is:

`
(ns rep.core
(:gen-class))

(defn- foo [s]
(locking s

42))

(defn -main
[& args]
(foo))
`

Locking on something which isn't a parameter, like a var, works around the issue.

This seems like it might be a Graal issue, so I'll report it there.

Answer 2

_Comment made by: alexmiller_

Ok, please update. We’ve got probably a long while before the next release that might include this so good to get more feedback.

Answer 3

Comment made by: bronsa

I'll vote against making locking into a new special form if possible. It would make any analysis-related library forward-incompatible and likely cause pains in dependency upgrade

Answer 4

Comment made by: eraserhd

With Graal VM rc11 (just released), clj-1472-3.patch works without issue.

Answer 5

Comment made by: jare

Started getting this error with GraalVM native compilation when migrated from Clojure 1.9 to 1.10
Minimal repro is:

`
(ns clj10-graal-repro.core
(:require [clojure.spec.alpha :as s])
(:gen-class))

(s/def ::foo (s/coll-of string?))

(defn -main
[& args]
(println (s/valid? ::foo ["bar"]))
(println clojure-version))
`

I think the problem is that Clojure 1.10 depends on spec.alpha 0.2.176 that (link: https://github.com/clojure/spec.alpha/commit/31165fec69ff86129a1ada8b3f50864922dfc88a text: uses locking)

More details in CLJ-2482

Answer 6

Comment made by: gshayban

I've added a patch (link: ^CLJ-1472-reentrant-finally.patch) that makes the locking macro emit exactly the same control flow as a javac emitted synchronized block. This required some assistance from the compiler.

for this code

synchronized (o) { int i = 400L; }

javac output

0: aload_0

   1: dup
   2: astore_1
   3: monitorenter
   4: ldc2_w        #7           // BEGIN TRY       // long 400l
   7: lstore_2
   8: aload_1
   9: monitorexit               // END TRY
  10: goto          20           // GOTO RET
  13: astore        4         // BEGIN FINALLY
  15: aload_1                     // store exception
  16: monitorexit           // END FINALLY
  17: aload         4             // rethrow
  19: athrow
  20: return
Exception table:
   from    to  target type
       4    10    13   any
      13    17    13   any

Note

1. the finally block is its own exception handler in the exception table
2. the monitorenter is outside the try body region
3. as usual, the finally body is duplicated to the try body (just like in a normal TryExpr)

I tested on Graal 19.0.2 with this patched clojure, by AOT-compiling the previous comment's repro, then calling Graal:

native-image -cp src:clojure.jar --initialize-at-build-time=clojure --no-server -H:+ReportUnsupportedElementsAtRuntime --no-fallback clj10_graal_repro.core

It successfully produces a binary with no error during compilation. However, Graal users will be thrilled to discover that the binary doesn't run:
Could not locate clojure/core/server__init.class

probably due to Clojure 1.10.1's delay of the initialization of clojure.core.server + user

Answer 7

Comment made by: gshayban

These seem like promising to native-image users:

https://github.com/oracle/graal/blob/master/substratevm/CONFIGURE.md

https://github.com/wololock/graalvm-groovy-examples/blob/master/hello-world/compile.sh

Answer 8

Comment made by: gshayban

that patch is busted in a subtle way -- fixing.

Answer 9

Comment made by: gshayban

(link: ^CLJ-1472-reentrant-finally2.patch)

Answer 10

Reference: https://clojure.atlassian.net/browse/CLJ-1472 (reported by adamclements)

Answer 11

Hi there,

I hit this issue in one of my projects that uses Clojure Spec. I made a simple project to reproduce the issue: https://github.com/alzadude/cljc-hello-world/tree/graalvm-spec-issue

I'm trying to use Graal native-image with the Clojure patch applied to create a working binary. However, when I used the patched Clojure jar, I am still getting the "unbalanced monitors" error. What am I doing wrong?

Thanks!

1 Build clojure with the patch applied

cd /mnt/d/Projects/clojure
patch -p1 < /mnt/c/Users/alex/Downloads/CLJ-1472-reentrant-finally2.patch
mvn clean
mvn -Plocal install -Dmaven.test.skip=true

2 Try and create Graalvm native image using clj/deps.edn

cd /mnt/d/Projects/cljc-hello-world
GRAALVM_HOME=/usr/local/graalvm-ce-19.2.0.1/ clojure -Anative-image

I still get "unbalanced monitors", even though the patch is applied:

Cleaning target
Creating target/classes
  Compiling hello-world.core
Creating target/cljc-hello-world
ERROR! Warning: Aborting stand-alone image build. unbalanced monitors: mismatch at monitorexit, 96|LoadField#lockee__5436__auto__ != 3|LoadField#lockee__5436__auto__
Detailed message:
Call path from entry point to clojure.spec.gen.alpha$dynaload$fn__2628.invoke():
        at clojure.spec.gen.alpha$dynaload$fn__2628.invoke(alpha.clj:21)
        at clojure.lang.AFn.run(AFn.java:22)
        at java.lang.Thread.run(Thread.java:748)
        at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:460)
        at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:193)
        at com.oracle.svm.core.code.IsolateEnterStub.PosixJavaThreads_pthreadStartRoutine_e1f4a8c0039f8337338252cd8734f63a79b5e3df(generated:0)

Warning: Use -H:+ReportExceptionStackTraces to print stacktrace of underlying exception
Warning: Image 'target/cljc-hello-world' is a fallback image that requires a JDK for execution (use --no-fallback to suppress fallback image generation).

3 Try and create Graalvm native image using native-image and explicit classpath, to rule out issues with deps.edn/cambada etc

cd /mnt/d/Projects/cljc-hello-world
clojure -Auberjar
/usr/local/graalvm-ce-19.2.0.1/bin/native-image --class-path ../clojure/target/clojure-1.11.0-master-SNAPSHOT.jar --report-unsupported-elements-at-runtime --initialize-at-build-time -jar ./target/cljc-hello-world-1.0.0-SNAPSHOT-standalone.jar -H:Name=./target/cljc-hello-world

I still get "unbalanced monitors":

Build on Server(pid: 10328, port: 64314)*
[./target/cljc-hello-world:10328]    classlist:   5,817.52 ms
[./target/cljc-hello-world:10328]        (cap):   2,576.68 ms
[./target/cljc-hello-world:10328]        setup:   3,923.40 ms
[./target/cljc-hello-world:10328]     analysis:  11,800.59 ms
Warning: Aborting stand-alone image build. unbalanced monitors: mismatch at monitorexit, 96|LoadField#lockee__5436__auto__ != 3|LoadField#lockee__5436__auto__
Detailed message:
Call path from entry point to clojure.spec.gen.alpha$dynaload$fn__2628.invoke():
        at clojure.spec.gen.alpha$dynaload$fn__2628.invoke(alpha.clj:21)
        at clojure.lang.AFn.run(AFn.java:22)
        at java.lang.Thread.run(Thread.java:748)
        at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:460)
        at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:193)
        at com.oracle.svm.core.code.IsolateEnterStub.PosixJavaThreads_pthreadStartRoutine_e1f4a8c0039f8337338252cd8734f63a79b5e3df(generated:0)

Warning: Use -H:+ReportExceptionStackTraces to print stacktrace of underlying exception
Build on Server(pid: 10328, port: 64314)
[./target/cljc-hello-world:10328]    classlist:     217.19 ms
[./target/cljc-hello-world:10328]        (cap):   1,244.81 ms
[./target/cljc-hello-world:10328]        setup:   1,535.89 ms
[./target/cljc-hello-world:10328]   (typeflow):   1,309.40 ms
[./target/cljc-hello-world:10328]    (objects):   1,430.65 ms
[./target/cljc-hello-world:10328]   (features):     120.57 ms
[./target/cljc-hello-world:10328]     analysis:   2,906.19 ms
[./target/cljc-hello-world:10328]     (clinit):      88.70 ms
[./target/cljc-hello-world:10328]     universe:     250.93 ms
[./target/cljc-hello-world:10328]      (parse):     315.62 ms
[./target/cljc-hello-world:10328]     (inline):     739.40 ms
[./target/cljc-hello-world:10328]    (compile):   3,100.68 ms
[./target/cljc-hello-world:10328]      compile:   4,401.60 ms
[./target/cljc-hello-world:10328]        image:     296.36 ms
[./target/cljc-hello-world:10328]        write:     195.80 ms
[./target/cljc-hello-world:10328]      [total]:   9,868.80 ms
Warning: Image './target/cljc-hello-world' is a fallback image that requires a JDK for execution (use --no-fallback to suppress fallback image generation).