Fork me on GitHub

@cfleming GraalVM added HTTPS support a few months ago, but it looks like there’s another issue here preventing native image generation:

Error: unbalanced monitors: mismatch at monitorexit, 96|LoadField#lockee__5699__auto__ != 3|LoadField#lockee__5699__auto__
Call path from entry point to$dynaload$fn__637.invoke():
	at clojure.lang.AFn.applyToHelper(
	at clojure.lang.Ref.applyTo(
	at aws_api_cli.core.main(Unknown Source)
IIRC there was a ticket/patch for this in Clojure? I tried with 1.9 and 1.10 but got the same error (w/diff stack traces)

taylor01:03:00 this is the patch I was thinking of, and this ticket isn’t the one I remember but seems relevant


FWIW I was able to build a native image after replacing that dynaload with a patched version, but then it fails at run-time with Cannot find resource cognitect/aws/s3/service.edn. {} (because I used S3 as an example call). I might take a deeper look at this if I have time later this week :man-shrugging:


@U3DAE8HMG Thanks! I’d appreciate any info you can provide after digging a bit.

Alex Miller (Clojure team)02:03:51

1472 is the relevant ticket

Alex Miller (Clojure team)02:03:22

that service.edn is from one of the other deps that needs to be included as a resource on the classpath (not sure what graal does about stuff like that)


thinking that resources looked up at runtime are out of scope of the static analysis that Graal native images performs


so those should be instructed for graal to keep


Not of immediate gain regarding graal/aws-api, but @U3E46Q1DG did something a bit similar with bytecode analysis in the #portkey project, in which we had an option to specify keeps for resources/classes that were dynamically loaded. I think some forms can be captured by static analysis, say .getResource("path/to/resources"), where the resource is a compile time literal


@cfleming I presume CLJS is not an option? I have a couple of CLJS/Shadow lambdas that do AWS calls and cold start in a couple of seconds


they are not in a VPC which dramatically improves cold-start. The VPC ENI cold start can add up to 8 secs to a cold start. I suspect a Graal based Lambda would suffer that as well if VPC is required in your case

☝️ 5

@steveb8n Yes, I’m currently using CLJS for my lambdas. But I like the new Cognitect API and AFAIK that’s not available for CLJS yet. And I would dearly love to leave all the funky async bit behind me forever (promesa helps, but it’s still not as nice as blocking)

👍 4

I agree with that. The new AWS lib is much nicer. I’ll be interested to hear how fast you can make the cold start work. Although nothing we can do about ENI - for that we (keep on) wait for AWS


Yeah, I’d like to switch from Dynamo to RDS but the VPC has put me off.


Also interesting is that Graal is 50% slower than JVM once loaded (was mentioned at ClojuTre last year) so by using Graal we are favouring cold starts over warmed up invocations. I suppose 50% slower is ok if total time is some 100's of ms, users won’t notice that


hum, isn’t jaotc is running on the c2/hotspot and the graalvm throughput is probably going to be better in the future?


was remembering this 🙂 > What is the typical performance profile on the SVM? > Right now peak performance is a bit worse than HotSpot, but we don’t want to advertise that (and we want to fix it of course).