FourthGraalAdventures
From APIDesign
| Line 1: | Line 1: | ||
| - | Yet another year or two passed since [[TwoYearsWithTruffle]] article was written and it is time to summarize list of my [[Graal]] adventures again. | + | Yet another year or two passed since [[TwoYearsWithTruffle]] article was written and it is time to summarize list of my recent [[Graal]] adventures again. |
| + | |||
| + | === Collecting profiles for guided optimizations === | ||
| + | |||
| + | [[SubstrateVM]] (enterprise edition) had an ability to instrument its code and dump profiling information to disk. While useful in a testing environment, the requirements of a [[cloud]] based deployments are different. The same application is supposed to be distributed among multiple docker containers running on multiple nodes. As such [[I]] was working on enhancing our central agent server - called **gemasrv** - to be able to request, obtain and track the PGO data over the wire from multiple applications. | ||
| + | |||
| + | However even this simplification wasn't good enough for projects like [[Helidon]] or [[FnProject]]. People don't want to debug and test the [[HotSpot]] version of the application, then build first (and slow) native image with profiling on to gather data about real usage from the VM and only then produce the production ready version. That is too complex and requires orchestration between developers, admins and operations. Rather than that let's collect the profiles in [[HotSpot]] mode of [[GraalVM]] EE! As such I introduced '''-Dgraal.ProfilesCollectExperimental=true''' option that collects the profiling data and exposes them via dedicated [[Graal]] compiler [[JMX]] bean. The option can even be turned on remotely, when needed. | ||
| + | |||
| + | With this kind of setup the whole orchestration of the containers is simplified. Developement produces [[JAR]] files of the application and operations can distribute them to [Docker]] containers. When needed, they can selectively enable the profiles gathering via a remote JMX connection. Later they can retrieve the collected data via the same JMX connection and provide them back to development to use them when generating the final [[NativeImage]] binary. | ||
| + | |||
| + | This all was working in [[GraalVM]] EE 1.0 RC14. Since RC15 it needs an additional option ''--jvmci:-UseNativeCompiler'' to (temporarily) disable the '''libgraal''' compiler. | ||
| + | <!-- GR-13626 --> | ||
| + | |||
| + | |||
| + | === Universal Scripting API === | ||
| + | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
| - | |||
** incompatibility of JavaScript engine with Nashorn | ** incompatibility of JavaScript engine with Nashorn | ||
** NetBeans & Nashorn deprecation and security vulnerability | ** NetBeans & Nashorn deprecation and security vulnerability | ||
** Graal.js relicensed to UPL | ** Graal.js relicensed to UPL | ||
** HostAccess & co. - security by default - EXPLICIT | ** HostAccess & co. - security by default - EXPLICIT | ||
| - | + | ||
| + | === Write JNI in Java with [[SubstrateVM]] === | ||
| + | |||
** API improvement: StackValue.get(clazz) | ** API improvement: StackValue.get(clazz) | ||
** Forget Go! Go, Java, go! - Panama now. | ** Forget Go! Go, Java, go! - Panama now. | ||
** Matrix the Ultimate sample demonstrates interaction between JVM and Native Java | ** Matrix the Ultimate sample demonstrates interaction between JVM and Native Java | ||
* Graal.js maven archetype | * Graal.js maven archetype | ||
Revision as of 09:55, 26 April 2019
Yet another year or two passed since TwoYearsWithTruffle article was written and it is time to summarize list of my recent Graal adventures again.
Collecting profiles for guided optimizations
SubstrateVM (enterprise edition) had an ability to instrument its code and dump profiling information to disk. While useful in a testing environment, the requirements of a cloud based deployments are different. The same application is supposed to be distributed among multiple docker containers running on multiple nodes. As such I was working on enhancing our central agent server - called **gemasrv** - to be able to request, obtain and track the PGO data over the wire from multiple applications.
However even this simplification wasn't good enough for projects like Helidon or FnProject. People don't want to debug and test the HotSpot version of the application, then build first (and slow) native image with profiling on to gather data about real usage from the VM and only then produce the production ready version. That is too complex and requires orchestration between developers, admins and operations. Rather than that let's collect the profiles in HotSpot mode of GraalVM EE! As such I introduced -Dgraal.ProfilesCollectExperimental=true option that collects the profiling data and exposes them via dedicated Graal compiler JMX bean. The option can even be turned on remotely, when needed.
With this kind of setup the whole orchestration of the containers is simplified. Developement produces JAR files of the application and operations can distribute them to [Docker]] containers. When needed, they can selectively enable the profiles gathering via a remote JMX connection. Later they can retrieve the collected data via the same JMX connection and provide them back to development to use them when generating the final NativeImage binary.
This all was working in GraalVM EE 1.0 RC14. Since RC15 it needs an additional option --jvmci:-UseNativeCompiler to (temporarily) disable the libgraal compiler.
Universal Scripting API
- incompatibility of JavaScript engine with Nashorn
- NetBeans & Nashorn deprecation and security vulnerability
- Graal.js relicensed to UPL
- HostAccess & co. - security by default - EXPLICIT
Write JNI in Java with SubstrateVM
- API improvement: StackValue.get(clazz)
- Forget Go! Go, Java, go! - Panama now.
- Matrix the Ultimate sample demonstrates interaction between JVM and Native Java
- Graal.js maven archetype
Follow
