fniephaus

BTW: We (the GraalVM team) maintain a full-blown LLVM bitcode runtime that can be embedded in Spring or any other JVM application and compiled to native: https://github.com/oracle/graal/tree/master/sulong

Hi @edburns,

As Thomas mentioned, we continue our mission to run programs faster and more efficiently. So yes, the GraalVM Docker images are still maintained and now include images with the new GraalVM 25 release.

-- Fabio

Fabio from the GraalVM team here.

I hope it isn't used in production yet because we still consider the use of native extensions experimental in GraalPy. However, we definitely see a need for this and will push it forward. If anyone wants to give this a try, please feel free to reach out to us.

In the meantime, you may want to take a look at this: https://blogs.oracle.com/ateam/post/want-to-use-llm-python-f...

Fabio from the GraalVM team here.

You may want to take a look at this: https://blogs.oracle.com/ateam/post/want-to-use-llm-python-f...

Thanks for the question, nurettin.

Although GraalPy can create standalone applications [1], you don't have to turn your hello world script into a self-contained binary. You can, of course, create a JAR that depends on GraalPy, or a fat JAR that contains it, and deploy it just like any other Java application.

We are still updating our docs to mention more details on this and publish some guides, apologies for the delay.

[1] https://www.graalvm.org/latest/reference-manual/python/stand...

For anyone interested, here's the PyPI repository with additional binary wheels for GraalPy: https://www.graalvm.org/python/wheels/

We also want to make it easy for Python package maintainers to test and build wheels for GraalPy. It's already available via setup-python, and we are adding GraalPy support to cibuildwheel. If you need any help, please reach out to us!

OP here.

More details about this particular release are in the blog post at https://medium.com/graalvm/whats-new-in-graal-languages-24-1...

Happy to answer any additional questions!

Correct:

> ... the JVM can intercept the resulting SIGSEGV ("Signal: Segmentation Fault"), look at the return address for that signal, and figure out where that access was made in the generated code. Once it figures that bit out, it can then know where to dispatch the control to handle this case — in most cases, throwing NullPointerException or branching somewhere.

https://shipilev.net/jvm/anatomy-quarks/25-implicit-null-che...

The GFTC [1] is a new license for GraalVM modelled on Oracle JDK's successful NFTC [2] license which was launched in 2021.

[1] https://www.oracle.com/downloads/licenses/graal-free-license... [2] https://www.oracle.com/downloads/licenses/no-fee-license.htm...

Also, reflection is supported in AOT mode. The analysis, however, does require reachability metadata in some cases. In the best case, libraries provide and maintain appropriate configuration for this. Reachability metadata can also be shared via https://github.com/oracle/graalvm-reachability-metadata.

GraalVM JDK19 dev builds are available at https://github.com/graalvm/graalvm-ce-dev-builds/releases/la....

We are working on a Python runtime as well: https://github.com/oracle/graalpython

Apparently, someone has managed to compile the Minecraft client to native: https://medium.com/@kb1000/what-youve-done-with-the-server-i...

The students used both, the community and enterprise editions of GraalVM. Indeed, G1 is an enterprise feature: https://www.graalvm.org/22.2/reference-manual/native-image/o...

It fails for some reason when reading user data from disk. The error also goes away if you nuke the user data but that's less convenient.

Just look at the 22.2 release notes [1]:

> Updated the OpenJDK release on which GraalVM Community Edition is built ...

and

> Updated the Oracle JDK release on which GraalVM Enterprise Edition is built ...

[1] https://www.graalvm.org/release-notes/22_2/

JIT compilation requires additional CPU and memory resources at run-time, which AOT compilation can avoid. This also means that for a native executable, the compilation work only needs to be done once at build-time and not per process.

Thanks for the info! Seems like it's worth trying to compile the Java client with GraalVM Native Image then, given that this exists: https://github.com/chirontt/lwjgl3-helloworld-native

Disclaimer: I work on the GraalVM team.

The students "measured noticeable reductions in terms of memory footprint of up to 43%" [1] in some preliminary experiments. More from the accompanying blog post:

"We also hope that the Minecraft community builds on our work and helps benchmark different configurations for native Minecraft servers in more detail and in larger settings."

Please feel free to share any numbers on CPU/memory usage with us!

[1] https://medium.com/graalvm/native-minecraft-servers-with-gra...

I don't think the student looked into that at all, but I guess it depends on what the Java client uses for drawing. GraalVM Native Image currently doesn't support AWT on Linux/JDK17+, but we are working on fixing that soon.

Do you have any feedback on how we could improve the docs? If so, please let us know.

I believe the easiest way to start a new Truffle language implementation is to fork SimpleLanguage [1] and turn it into your language. Did you try to do that?

[1] https://github.com/graalvm/simplelanguage

I agree! Our work on TruffleSqueak [1] and on Polyglot Live Programming [2] has shown that it's possible to build language-agnostic live programming tools with GraalVM. If Espresso implements the required Truffle APIs correctly, our tools should also just work for Java. :)

[1] https://github.com/hpi-swa/trufflesqueak/ [2] https://github.com/hpi-swa/polyglot-live-programming

Espresso's README.md contains some interesting details, for example:

> ... it already passes >99.99% of the Java Compatibility Kit ...

> Running HelloWorld on three nested layers of Espresso takes ~15 minutes.

Link: https://github.com/oracle/graal/tree/6dd83cd94763b8736b42063...

Previous discussion: https://news.ycombinator.com/item?id=25461760

I played around with "Find My" last night... similar to Location Sharing, it seems to allow me to look at the location of all devices connected with my account as long as they are online. But that's not necessarily what I want. Before I can access someone else's location, I want to inform them that I'd like to know where they are and give them a couple of minutes to respond. That's the key missing feature here...or am I the one missing something?

First paragraph of the corresponding email announcement:

> Over three years ago, we launched the Trusted Contacts app as a way to help people stay up to date with their loved ones’ whereabouts. Since then, we’ve built this functionality directly into Google Maps with Location Sharing - making it even easier to share your live location with trusted friends and family.

Correct me if I'm wrong, but location sharing doesn't seem to provide the same functionality. It's an always on feature for sharing your location with others, not a "request someone's location" feature and if that person doesn't respond in 15min, enable location sharing for some time.

The obvious question is: what's a good/trustworthy alternative?

Oracle Labs is actively working on a Python for GraalVM: https://github.com/graalvm/graalpython/

> Is there an overview somewhere which allows comparison with fig. 4 of your ACM 2019 publication?

We have set up a benchmarking infrastructure for performance tracking, but it is unfortunately not public (yet). Also, we have switched from GraalVM EE/JDK8 to GraalVM CE/JDK11 a couple of months ago, which makes it hard to compare recent with older results. But what I can say it that performance on GraalVM CE/JDK11 is currently better than on GraalVM EE/JDK8 a year ago. I expect it to be faster on EE as well, but I'd need to measure by how much.

> Anyway in that publication SOMns using the same technology - as far as I understand - showed a completely different performance pattern; does this still apply, and what is/was the reason for this?

Correct. First, SOMns does not support a real Smalltalk system and does not support some crucial mechanisms (e.g. changing the class of an object). So TruffleSqueak must check the class of an object in quite some cases, which is a slight, unavoidable overhead. More importantly, SOMns has some primitives that Squeak does not, for example for comparing strings. That's for example another reason why SOMns is so much faster in the JSON benchmark. For your curiosity, here's a screenshot of the benchmark results for a current TruffleSqueak and SOMns (note that they ran on different versions of GraalVM, I think you can somewhat compare the TruffleSqueak numbers to "GraalSqueak-CE" in fig. 4 of the paper):

https://user-images.githubusercontent.com/2368856/90402527-d...

s/derived/deviated/

Thanks for the feedback! We have plans to create a tutorial soon and run it virtually during SPLASH/ECOOP'20 [1] (I have to check why the tutorial page is no longer public).

[1] https://web.archive.org/web/20200319123703/https://2020.ecoo...