Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2023-06-13

Channels

#graalvm
<
2023-06-13
>
borkdude15:06:35

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/

lread16:06:06

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

borkdude16:06:52

I think it is, not sure

borkdude17:06:47

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

lread17:06:09

Hmmm... interesting!

lread17:06:54

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

borkdude17:06:29

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

borkdude17:06:20

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

borkdude17:06:27

but without it you just get better performance

borkdude17:06:40

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

borkdude17:06:44

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)

borkdude17:06:43

There's also O1, O2, etc

borkdude17:06:29

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

borkdude17:06:21

This seems to be the sweet spot

ericdallo17:06:15

Quite interesting!

ericdallo17:06:57

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

borkdude16:06:13

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

borkdude17:06:14

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

Colin (fosskers)05:06:18

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

borkdude07:06:28

10mb less

👍 2
Colin (fosskers)07:06:52

Still a net increase :thinking_face:

borkdude07:06:09

No, compared to the previous version

kulminaator18:06:25

it's evolving 🙂

kulminaator18:06:36

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

borkdude18:06:49

probably better

borkdude18:06:02

especially with -Ob

DrTalos17:06:38

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?

borkdude17:06:41

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

borkdude17:06:22

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

DrTalos17:06:14

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!

👍 2
borkdude17:06:50

What are you creating, if you want to share?

DrTalos17:06:01

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