graalvm

borkdude 2023-06-13T15:51:35.698159Z

GraalVM release stream is now live on youtube. Seems like I have to update all my CI stuff to use new urls and paths: https://www.oracle.com/java/technologies/jdk-script-friendly-urls/

lread 2023-06-13T16:03:06.621939Z

A bit late, just started watching, is new Oracle GraalVM OSS friendly or do we stick with the GraalVM Community Edition?

borkdude 2023-06-13T16:56:52.137369Z

I think it is, not sure

borkdude 2023-06-13T17:18:47.721119Z

I think I'll stay with the community edition since I get a smaller binary and lower compile time

lread 2023-06-13T17:20:09.953849Z

Hmmm... interesting!

lread 2023-06-13T17:20:54.667799Z

And I guess some licence-smart folks will opine eventually on the practical differences between these two licence-wise.

borkdude 2023-06-13T17:28:29.851509Z

Got my question answered. With the -Ob flag you will get smaller binaries (bb shrinks to 65mb now) but less optimizations as well

borkdude 2023-06-13T17:29:20.177719Z

the -Ob flag is much closer to what CE was like

borkdude 2023-06-13T17:29:27.253389Z

but without it you just get better performance

borkdude 2023-06-13T17:29:40.500199Z

I guess I should do a poll then or run some benchmarks ;)

borkdude 2023-06-13T17:31:44.114199Z

I guess I could just time how long the lib tests take (although there are some random generator stuff in there which may mess with the timings and http requests etc)

borkdude 2023-06-13T17:34:43.230349Z

There's also O1, O2, etc

borkdude 2023-06-13T17:37:29.568609Z

Just tested with 01: 63mb, 1M loop in 550ms (with -Ob I got 600ms)

borkdude 2023-06-13T17:41:21.327429Z

This seems to be the sweet spot

borkdude 2023-06-13T17:50:02.829059Z

https://github.com/babashka/babashka/issues/1577 also cc @ericdallo, just FYI

ericdallo 2023-06-13T17:57:15.125479Z

Quite interesting!

ericdallo 2023-06-13T17:57:57.163319Z

Probably performance is more important for clojure-lsp if we change that

borkdude 2023-06-13T16:57:13.407059Z

I'm getting a 20mb binary size increase with GraalVM 20 😫

borkdude 2023-06-14T07:23:28.653919Z

10mb less

👍 1
Colin (fosskers) 2023-06-14T07:24:52.024979Z

Still a net increase 🤔

borkdude 2023-06-14T07:44:09.277169Z

No, compared to the previous version

Colin (fosskers) 2023-06-14T07:44:18.506749Z

Oh, dang!

borkdude 2023-06-13T17:31:14.868739Z

Answer: use -Ob for smaller binary size (but less performance)

Colin (fosskers) 2023-06-14T05:19:18.399749Z

How much of a size decrease are you seeing with -Ob?

kulminaator 2023-06-16T18:17:25.257439Z

it's evolving 🙂

kulminaator 2023-06-16T18:17:36.918939Z

are the compile times still the same as a few years ago?

borkdude 2023-06-16T18:17:49.994549Z

probably better

borkdude 2023-06-16T18:18:02.587549Z

especially with -Ob

DrTalos 2023-06-13T17:11:38.456069Z

I'm having a bit of trouble figuring out the best pattern for freeing memory allocated in a shared library built with graal and returned to a C caller. For instance, if you return the value of a CCharPointerHolder, as is done here: https://github.com/babashka/sci/blob/master/doc/libsci.md, would you have to hang onto the CCharPointerHolder and do some bookkeeping to associate it with the pointer, so the caller could ask for close to be called on it?

borkdude 2023-06-13T17:13:41.729159Z

Probably best to ask in the graalvm community slack, native-image channel

borkdude 2023-06-13T17:17:22.174979Z

I think they have an API where you can "pin" the pointer so it doesn't get GC-ed

DrTalos 2023-06-13T17:30:14.536429Z

OK, thank you very much! I think the CCharPointerHolder result does get pinned, from looking at the docs. I just don't see a straightforward way to free it once I'm done with it in C. I will ask in the Graal slack. Thanks again!

👍 1
borkdude 2023-06-13T17:30:50.152289Z

What are you creating, if you want to share?

DrTalos 2023-06-13T17:40:01.899859Z

I am writing a plugin for the Unreal Engine that's related to character animation.

borkdude 2023-06-13T17:41:07.381349Z

cool