holy-lambda

Benjamin 2021-10-19T09:03:42.064300Z

I'm trying to compile for graalvm using this https://github.com/http-kit/http-kit how do I add to reflection-config.json because it get's auto generated by hl:native:conf right?

Karol Wójcik 2021-10-19T09:21:41.064500Z

It's auto generated via hl:native:conf. See https://fierycod.github.io/holy-lambda/#/native-backend Configuration is auto-added 😉 Regarding the --initialize-at-build-time. The commit with the configuration on http-kit side has not been yet released.

Karol Wójcik 2021-10-19T09:21:56.064800Z

Try adding:

Karol Wójcik 2021-10-19T09:22:15.065Z

--initialize-at-build-time=org.httpkit.client.ClientSslEngineFactory\$SSLHolder
or
--initialize-at-build-time=org.httpkit.client.ClientSslEngineFactory$SSLHolder

Karol Wójcik 2021-10-19T09:22:25.065200Z

to bb.edn native-image-args 🙂

Karol Wójcik 2021-10-19T09:22:40.065400Z

Reflection != init flags

Benjamin 2021-10-19T09:41:03.065600Z

tried with the initialize at build flag. It throws this:

Error: Detected an instance of Random/SplittableRandom class in the image heap. Instances created during image generation have cached seed values and don't behave as expected.  To see how this object got instantiated use --trace-object-instantiation=java.security.SecureRandom. The object was probably created by a class initializer and is reachable from a static field. You can request class initialization at image runtime by using the option --initialize-at-run-time=<class-name>. Or you can write your own initialization methods and call them explicitly from your main entry point.
Detailed message:
Trace: Object was reached by 
	reading field sun.security.ssl.SSLContextImpl.secureRandom of
		constant sun.security.ssl.SSLContextImpl$TLSContext@7f03e44d reached by 
	reading field javax.net.ssl.SSLContext.contextSpi of
		constant javax.net.ssl.SSLContext@49504750 reached by 
	scanning method org.httpkit.client.ClientSslEngineFactory.getContextInstance(ClientSslEngineFactory.java:29)
Call path from entry point to org.httpkit.client.ClientSslEngineFactory.getContextInstance(): 
	at org.httpkit.client.ClientSslEngineFactory.getContextInstance(ClientSslEngineFactory.java:29)
	at org.httpkit.client.ClientSslEngineFactory.trustAnybody(ClientSslEngineFactory.java:33)
	at org.httpkit.client$coerce_req.invokeStatic(client.clj:68)
	at org.httpkit.client$request.invokeStatic(client.clj:242)
	at org.httpkit.client$request.doInvoke(client.clj:180)
	at clojure.lang.RestFn.applyTo(RestFn.java:139)
	at org.singularity_group.bot_announce.core.main(Unknown Source)
	at com.oracle.svm.core.JavaMainWrapper.runCore(JavaMainWrapper.java:146)
	at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:182)
	at com.oracle.svm.core.code.IsolateEnterStub.JavaMainWrapper_run_5087f5482cc9a6abc971913ece43acb471d2631b(generated:0)

Karol Wójcik 2021-10-19T09:44:45.065800Z

Add tracing for Secure Random and show the trace

Karol Wójcik 2021-10-19T09:46:45.066Z

What GraalVM version do you use?

Benjamin 2021-10-19T09:48:21.066200Z

graalvm-ce-java8-21.2.0

Benjamin 2021-10-19T09:48:26.066400Z

ah maybe it's old

Karol Wójcik 2021-10-19T09:48:43.066600Z

No

Benjamin 2021-10-19T09:48:47.066800Z

Trace: Object was reached by 
	reading field sun.security.ssl.SSLContextImpl.secureRandom of
		constant sun.security.ssl.SSLContextImpl$TLSContext@1beff060 reached by 
	reading field javax.net.ssl.SSLContext.contextSpi of
		constant javax.net.ssl.SSLContext@1d491df0 reached by 
	scanning method org.httpkit.client.ClientSslEngineFactory.getContextInstance(ClientSslEngineFactory.java:29)
Call path from entry point to org.httpkit.client.ClientSslEngineFactory.getContextInstance(): 
	at org.httpkit.client.ClientSslEngineFactory.getContextInstance(ClientSslEngineFactory.java:29)
	at org.httpkit.client.ClientSslEngineFactory.trustAnybody(ClientSslEngineFactory.java:33)
	at org.httpkit.client$coerce_req.invokeStatic(client.clj:68)
	at org.httpkit.client$request.invokeStatic(client.clj:242)
	at org.httpkit.client$request.doInvoke(client.clj:180)
	at clojure.lang.RestFn.applyTo(RestFn.java:139)
	at org.singularity_group.bot_announce.core.main(Unknown Source)
	at com.oracle.svm.jni.JNIJavaCallWrappers.jniInvoke_VA_LIST:Lorg_singularity_1group_bot_1announce_core_2_0002emain_00028_3Ljava_lang_String_2_00029V(generated:0)

Karol Wójcik 2021-10-19T09:49:39.067Z

It's not about graalvm. It's about http-kit that stopped supporting GraalVM cc @borkdude. Here the regression was introduced: https://github.com/http-kit/http-kit/commit/1caddcf162de9ec92d320875dcb6a1a9d188f29f#diff-6b66607e20f6598724bd4dd94521a74eecafaec6c995331b3164e0ba89f1f70d

Karol Wójcik 2021-10-19T09:50:19.067200Z

Which version of http-kit do you use? @benjamin.schwerdtner

Benjamin 2021-10-19T09:50:45.067500Z

I see. So I could try downgrading for now

Karol Wójcik 2021-10-19T09:51:00.067700Z

Right.

Benjamin 2021-10-19T09:51:02.067900Z

http-kit/http-kit {:mvn/version "2.5.3"}

borkdude 2021-10-19T09:51:34.068100Z

No, this is wrong. http-kit does support graalvm and you should in fact be using the newest alpha which has built-in native image config

borkdude 2021-10-19T09:53:04.068300Z

however you should probably not be creating http clients on the top level which will initialize this class at build time, which is never supported

borkdude 2021-10-19T09:53:15.068500Z

and that might be the case in your code.

Karol Wójcik 2021-10-19T09:53:35.068700Z

But still if @borkdude says you should upgrade, you should upgrade 😄

Benjamin 2021-10-19T09:54:52.068900Z

to 2.6.0-alpha1 ? Toplevel means in def right but now inside functions @borkdude

Karol Wójcik 2021-10-19T09:55:16.069200Z

Or use a delay

borkdude 2021-10-19T09:55:28.069800Z

correct

Benjamin 2021-10-19T10:03:37.070Z

huehue worked now 🙂

2021-10-19T12:39:10.070300Z

@ouvasam has joined the channel

👋 1
steveb8n 2021-10-19T05:25:29.052300Z

Q: I just added Timbre for logging and now my HL native:executable is exceeding CI memory limits. Any tricks for getting around this?

steveb8n 2021-10-19T05:26:16.052400Z

When run on local machine it uses just over 6Gb. The CI system claims to provide 8Gb but I suppose there is some overhead

steveb8n 2021-10-19T05:26:41.052600Z

probably because the Docker daemon needs the other 2Gb

Karol Wójcik 2021-10-19T05:48:20.057Z

Try setting maximum heap size up to 5-6gb.

Karol Wójcik 2021-10-19T05:51:53.058200Z

Sorry. It should be -J-Xmx5G set in native-image-args

steveb8n 2021-10-19T05:53:27.058400Z

ok. will do. looks like I can reduce the docker daemon mem also

steveb8n 2021-10-19T05:53:32.058600Z

will try both

Karol Wójcik 2021-10-19T05:55:39.061100Z

Don’t do it by limiting memory size of your daemon. Native image does not utilize full all the available memory. Better to set memory limit to native-image and check if the argument is there by using —verbose

steveb8n 2021-10-19T06:15:17.061300Z

0.5.0 fixed it. used about 1Gb less memory

steveb8n 2021-10-19T06:15:19.061500Z

happy days

Karol Wójcik 2021-10-19T06:17:25.063Z

New version will be compatible with 0.5.0, but also slightly faster and more memory efficient. ;)

steveb8n 2021-10-19T06:18:03.063200Z

great news

steveb8n 2021-10-19T05:30:44.053200Z

I’m also curious if anyone has successfully used Timbre with HL? I suspect it uses reflection in some layers

steveb8n 2021-10-19T23:02:52.070600Z

hmm, I need a little help with this config. I think you mean that I should use the props from the native-image.properties file in that repo. but where do I add these props? somewhere in bb.edn?

Karol Wójcik 2021-10-20T06:14:22.073Z

You have to add the dependency. Readme.md of the project should help you understand what you should do.

Karol Wójcik 2021-10-20T06:16:08.074800Z

Alternatively you can pass the params from native-image.properties to bb.edn native-image-args

Karol Wójcik 2021-10-20T06:29:31.079800Z

Do you know how to do this? @steveb8n

steveb8n 2021-10-20T06:31:17.080300Z

I’ve added the dep. and the lambdas are working and logging so it’s not a big deal

steveb8n 2021-10-20T06:31:40.080500Z

I didn’t realise the readme at the root of the project was where the instructions exist

steveb8n 2021-10-20T06:32:21.080700Z

I was looking in the example project of the link you added above

Karol Wójcik 2021-10-20T07:00:30.082500Z

Nope. native-image automatically gathers all native-image.properties and merges them together. This is not a feature of HL :D

Karol Wójcik 2021-10-20T07:12:54.083500Z

Basically you have to add a dependency to a classpath and everything is done automatically

Karol Wójcik 2021-10-20T07:42:22.083700Z

Anyway. Everything works fine? @steveb8n

steveb8n 2021-10-20T07:42:56.083900Z

yeah. it’s all working great

steveb8n 2021-10-20T07:43:32.084100Z

I’ve added the simple dep but still get the warning. however logging works properly so I don’t really care about the warning

steveb8n 2021-10-20T07:43:38.084300Z

I’ll leave it alone for now

Karol Wójcik 2021-10-20T07:51:19.084500Z

What is the warning?

Karol Wójcik 2021-10-20T07:51:32.084700Z

It's probably easy to fix with one line of configuration

steveb8n 2021-10-20T07:55:06.084900Z

hmm. I can’t find it now. maybe it’s already fixed

steveb8n 2021-10-20T07:56:13.085100Z

let’s forget it in that case. false alarm 🙂

Karol Wójcik 2021-10-20T08:01:34.085300Z

Ok 🙂

steveb8n 2021-10-20T08:15:48.085500Z

ah found it….

steveb8n 2021-10-20T08:15:51.085700Z

+ bb native:executable --runtime native
Could not find /project/.holy-lambda/clojure-tools-1.10.3.967.jar
Attempting download from 
Checking out:  at 5eaccc18337b6d875cc81d5908432d4df57899bc
Downloading: clojure-term-colors/clojure-term-colors/0.1.0/clojure-term-colors-0.1.0.pom from clojars
Downloading: clojure-term-colors/clojure-term-colors/0.1.0/clojure-term-colors-0.1.0.jar from clojars
[holy-lambda] Executable /root/.graalvm/bin/java does not exists! Using fallback: java instead! Did you set up GRAALVM_HOME?
[holy-lambda] Executable /root/.graalvm/bin/native-image does not exists! Using fallback: native-image instead! Did you set up GRAALVM_HOME?
[holy-lambda] Command <native:executable>
Warning: Ignoring server-mode native-image argument --no-server.
[output:164]    classlist:   6,913.00 ms,  2.23 GB
--initialize-at-build-time without arguments has been deprecated and will be removed in GraalVM 22.0.
[output:164]        (cap):     651.52 ms,  2.23 GB
WARNING: Could not resolve fierycod.holy_lambda.core$entrypoint$fn__6578 for reflection configuration. Reason: java.lang.ClassNotFoundException: fierycod.holy_lambda.core$entrypoint$fn__6578.
[output:164]        setup:   2,515.74 ms,  2.23 GB
Warning: class initialization of class org.apache.commons.logging.impl.Log4JLogger failed with exception java.lang.NoClassDefFoundError: org/apache/log4j/Priority. This class will be initialized at run time because option --allow-incomplete-classpath is used for image building. Use the option --initialize-at-run-time=org.apache.commons.logging.impl.Log4JLogger to explicitly request delayed initialization of this class.
WARNING: Could not register reflection metadata for org.apache.commons.logging.impl.Log4JLogger. Reason: java.lang.NoClassDefFoundError: org/apache/log4j/Priority.
[output:164]     (clinit):   2,187.24 ms,  5.27 GB
[output:164]   (typeflow):  57,038.49 ms,  5.27 GB
[output:164]    (objects):  69,540.11 ms,  5.27 GB

steveb8n 2021-10-20T08:16:48.085900Z

strange warning about HL entrypoint as well

Karol Wójcik 2021-10-20T08:17:12.086100Z

Ah. Right. The first one regarding entrypoint will be fixed in the next release. Ignore it for now.

Karol Wójcik 2021-10-20T08:17:51.086300Z

Could you remove this: org.apache.commons.logging.impl.Log4JLogger and fierycod.holy_lambda.core$entrypoint$fn__6578 from reflection configurations?

Karol Wójcik 2021-10-20T08:18:19.086500Z

Also add this option --initialize-at-run-time=org.apache.commons.logging.impl.Log4JLogger to bb.edn 😄

steveb8n 2021-10-20T08:37:09.086700Z

can add the option easily. removing those entries means extra CI complexity because I run native:conf in CI as well

steveb8n 2021-10-20T08:37:19.086900Z

I’ll meet you halfway 🙂

Karol Wójcik 2021-10-20T08:37:58.087100Z

This one should work just fine: --initialize-at-run-time=org.apache.commons.logging.impl.Log4JLogger

steveb8n 2021-10-20T08:44:15.087300Z

yep. running that one through CI now

steveb8n 2021-10-20T08:54:03.087500Z

WARNING: Could not register reflection metadata for org.apache.commons.logging.impl.Log4JLogger. Reason: java.lang.NoClassDefFoundError: org/apache/log4j/Priority.

steveb8n 2021-10-20T08:54:12.087700Z

same for that class?

Karol Wójcik 2021-10-20T09:22:02.087900Z

This warning you get, because :conf generates an entry for Log4JLogger, but the class is not in the classpath. You should remove the entry from reflect-configurations 😄

steveb8n 2021-10-20T09:45:09.088100Z

Roger that. Thanks

steveb8n 2021-10-19T05:31:17.053300Z

SLF4J: Failed to load class “org.slf4j.impl.StaticLoggerBinder”. SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. WARNING: Could not register reflection metadata for org.apache.commons.logging.impl.Log4JLogger. Reason: java.lang.NoClassDefFoundError: org/apache/log4j/Priority. Warning: class initialization of class org.apache.commons.logging.impl.Log4JLogger failed with exception java.lang.NoClassDefFoundError: org/apache/log4j/Priority. This class will be initialized at run time because option --allow-incomplete-classpath is used for image building. Use the option --initialize-at-run-time=org.apache.commons.logging.impl.Log4JLogger to explicitly request delayed initialization of this class. [

Karol Wójcik 2021-10-19T05:44:44.054400Z

Add slf4j-simple and the following configuration https://github.com/clj-easy/graal-config/tree/master/config/org.slf4j/slf4j-simple

Karol Wójcik 2021-10-19T05:46:05.055900Z

Btw could you remove Log4JLogger from the reflection-config.json?

steveb8n 2021-10-19T05:53:57.058800Z

I’ll look into that once mem is fixed