Helidon
From APIDesign
(→Debugging) |
(→Helidon MP 2.0 supports GraalVM NativeImage) |
||
| (7 intermediate revisions not shown.) | |||
| Line 3: | Line 3: | ||
=== [[Helidon]] MP 2.0 supports [[GraalVM]] [[NativeImage]] === | === [[Helidon]] MP 2.0 supports [[GraalVM]] [[NativeImage]] === | ||
| - | [[Helidon]] MP implements the [[MicroProfile]] specification based on various other standard [[JavaEE]] subspecifications including [[CDI]]. Getting [[Weld]] (the reference [[CDI]] specification) running on top of [[NativeImage]] is particularly tricky. Not only [[Weld]] dynamically scans for various annotations, but it also dynamically emits [[bytecode]] for its helper classes during runtime. Solving this required more insight into [[JavaEE]] than available among compiler engineers - not that [[I]] had it initially, but the close co-operation with Tomáš Langer (the [[Helidon]] lead engineer) helped us | + | [[Helidon]] MP implements the [[MicroProfile]] specification based on various other standard [[JavaEE]] subspecifications including [[CDI]]. Getting [[Weld]] (the reference [[CDI]] specification) running on top of [[NativeImage]] is particularly tricky. Not only [[Weld]] dynamically scans for various annotations, but it also dynamically emits [[bytecode]] for its helper classes during runtime. Solving this required more insight into [[JavaEE]] than available among compiler engineers - not that [[I]] had it initially, but the close co-operation with Tomáš Langer (the [[Helidon]] lead engineer) helped us get started. Tomáš prepared various trivial [[CDI]] sample projects and [[I]] was then able to get them running on [[NativeImage]] by writing a dedicated '''WeldFeature'''. Once the initial road block was gone the [[Helidon]] team was able to move forward on their own and get their enhanced [[Weld]] running on top of [[NativeImage]]. |
| + | |||
| + | [[Helidon]] 2.0 [https://medium.com/helidon/announcing-helidon-2-0-19c245f5488a was released] on June 24, 2020. It's [[MicroProfile]] edition (including compatible [[CDI]] implementation) works with [[NativeImage]]. | ||
=== [[Debugging]] === | === [[Debugging]] === | ||
| - | Particularly tricky issue related to [[NativeImage]] is [[debugging]]. It is not easy to debug [[Java]] code with [[gdb]]. People tend to avoid doing so as much as possible. In certain situations that's however unavoidable and [[I]] tried to be as helpful as possible. I remember spending a week in [[debugging]] a [[race condition]] in the database connection driver just to find out that the | + | Particularly tricky issue related to [[NativeImage]] is [[debugging]]. It is not easy to debug [[Java]] code with [[gdb]]. People tend to avoid doing so as much as possible. In certain situations that's however unavoidable and [[I]] tried to be as helpful as possible. I remember spending a week in [[debugging]] a [[race condition]] in the database connection driver just to find out that the sample is buggy and works in [[HotSpot]] mode just because [[HotSpot]] [[JVM]] is too slow when booting up. |
| - | One thread was connecting to a database to re-create sample table. E.g. dropping the previous one and creating new one. This worked without issues on [[HotSpot]] [[JVM]]. However with [[NativeImage]] generated executable (that boots and executes in microseconds), it was failing in 50% of cases. At the end, it turned out that while the first thread was re-populating new content of the table, another | + | One thread was connecting to a database to re-create sample table. E.g. dropping the previous one and creating new one. This worked without issues on [[HotSpot]] [[JVM]]. However with [[NativeImage]] generated executable (that boots and executes in microseconds), it was failing in 50% of cases. At the end, it turned out that while the first thread was re-populating new content of the table, another thread was querying the table and might get empty results, if it queried too fast. The [[race condition]] was always there, but it only manifested on [[NativeImage]] as the second thread was ready to run at full speed since beginning and ''run ahead'' the initializing code - something that never happened with classing [[JVM]] setup. |
=== Related === | === Related === | ||
[[GraalVM]] offers not only [[NativeImage]] compilation, but also [[polyglot]] capabilities. During the [[FifthGraalAdventures]] we also prepared sample [[Helidon]] application that successfully use [[GraalVM]]'s [[Ruby]] and [[JavaScript]] interpreters to handle incoming connections. | [[GraalVM]] offers not only [[NativeImage]] compilation, but also [[polyglot]] capabilities. During the [[FifthGraalAdventures]] we also prepared sample [[Helidon]] application that successfully use [[GraalVM]]'s [[Ruby]] and [[JavaScript]] interpreters to handle incoming connections. | ||
Current revision
helidon.io is a microservices framework developed four meters away from me (my seat in Oracle Prague office). As such I felt as the natural fit for solving complex tasks that require understanding of both sides - the JavaEE landscape as well as the GraalVM internals.
Helidon MP 2.0 supports GraalVM NativeImage
Helidon MP implements the MicroProfile specification based on various other standard JavaEE subspecifications including CDI. Getting Weld (the reference CDI specification) running on top of NativeImage is particularly tricky. Not only Weld dynamically scans for various annotations, but it also dynamically emits bytecode for its helper classes during runtime. Solving this required more insight into JavaEE than available among compiler engineers - not that I had it initially, but the close co-operation with Tomáš Langer (the Helidon lead engineer) helped us get started. Tomáš prepared various trivial CDI sample projects and I was then able to get them running on NativeImage by writing a dedicated WeldFeature. Once the initial road block was gone the Helidon team was able to move forward on their own and get their enhanced Weld running on top of NativeImage.
Helidon 2.0 was released on June 24, 2020. It's MicroProfile edition (including compatible CDI implementation) works with NativeImage.
Debugging
Particularly tricky issue related to NativeImage is debugging. It is not easy to debug Java code with gdb. People tend to avoid doing so as much as possible. In certain situations that's however unavoidable and I tried to be as helpful as possible. I remember spending a week in debugging a race condition in the database connection driver just to find out that the sample is buggy and works in HotSpot mode just because HotSpot JVM is too slow when booting up.
One thread was connecting to a database to re-create sample table. E.g. dropping the previous one and creating new one. This worked without issues on HotSpot JVM. However with NativeImage generated executable (that boots and executes in microseconds), it was failing in 50% of cases. At the end, it turned out that while the first thread was re-populating new content of the table, another thread was querying the table and might get empty results, if it queried too fast. The race condition was always there, but it only manifested on NativeImage as the second thread was ready to run at full speed since beginning and run ahead the initializing code - something that never happened with classing JVM setup.
Related
GraalVM offers not only NativeImage compilation, but also polyglot capabilities. During the FifthGraalAdventures we also prepared sample Helidon application that successfully use GraalVM's Ruby and JavaScript interpreters to handle incoming connections.
Follow
