wu-sheng opened a new issue, #11279: URL: https://github.com/apache/skywalking/issues/11279
### Search before asking - [X] I had searched in the [issues](https://github.com/apache/skywalking/issues?q=is%3Aissue) and found no similar feature requirement. ### Description # Backgroup GraalVM Build is a proposal of the OSPP 2023 created and owned by @yswdqz, mentored by @kezhenxu94 officially, and me as an assistant from time to time. GraalVM provides a native build for Java, to get rid of runtime VM and JIT. # Progress There are a lot of discussions among the three of us to get this working out, and many PoC attempts were made @yswdqz. Right now, the biggest challenge is `groovy` relative stack is hard to compile in GraalVM and the Apache Groovy community has little interest in providing a native solution. I would say, it makes sense for Groovy community to make this decision. A generally available solution for groovy compiling in native and statically seems to violate the purpose of creating/choosing this tech stack. Meanwhile, I still think this kind of compiling would have potential long-term benefits for the SkyWalking community. # Solution Recently, we have had an agreement about the solution and plans to get this out. ## Abstract Groovy is not a hard-requirement logically from SkyWalking OAP's perspective. We never change the groovy script in the runtime, furthermore, it is super rare to change it after the dev stage. For us, it provides a super powerful script and high-performance kernel to write logic without recompiling the whole project. So, we could try to provide an alternative compiling time mechanism to convert/compile the MAL and LAL scripts to native Java files or classes, which should be GraalVM friendly. ## Plans There are several steps we should take to land this. - [ ] Set up the GraalVM compiling pipeline in the CI, and make the compiling passed with MAL and LAL excluded. - [ ] Build the MAL script based compiling mechanism to support GraalVM build. - [ ] Build the LAL script based compiling mechanism to support GraalVM build. ### compiling Workflow Once MAL and LAL are involved in the GraalVM build, we should at least follow this workflow to make the build process transparent and easy to debug. 1. Support a new package profile to replace the MAL and LAL's groovy kernel with a new implementation. This should not be easy as MAL and LAL interfaces and groovy implementations are bundled closely. 2. Support MAL scripts are compiled to new Java source files and further as class files, which are included and running in the final Java tar 3. Similar to <2>, but for LAL scripts. 4. Make GraalVM successfully built for <1> <2> <3> step by step. @yswdqz @kezhenxu94 Let me know if you want to add more or I miss any key info. ### Use case To all @apache/skywalking-committers, we had faced a lot of issues to implement this, and we just got this basic idea out, So, I have to say, there is still no guarantee we could work this out. As that, we haven't set any milestone yet. But basically, we will try our best, as we believe this kind of native build has advantages. ### Related issues _No response_ ### Are you willing to submit a pull request to implement this on your own? - [ ] Yes I am willing to submit a pull request on my own! ### Code of Conduct - [X] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
