Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Compatability with Quarkus. #5665

Open
whitingjr opened this Issue Mar 25, 2019 · 4 comments

Comments

Projects
None yet
2 participants
@whitingjr
Copy link

whitingjr commented Mar 25, 2019

Hi,
Is there any thoughts on making JRuby compatible with Quarkus ?
It makes jvm boot speed issues go away. Great for command line gems.

@headius

This comment has been minimized.

Copy link
Member

headius commented Mar 28, 2019

Yes, we'd love to work with Quarkus! I actually have been hoping to try compiling a trimmed version of JRuby that uses less (or zero) reflection and no invokedynamic. JRuby 1.7 could also fully AOT compile Ruby code to JVM bytecode (9k does not do that yet) so it might be possible to precompile JRuby and your Ruby code.

Are you interested in helping us identify issues and getting JRuby working on Quarkus?

@whitingjr

This comment has been minimized.

Copy link
Author

whitingjr commented Mar 29, 2019

@headius thanks for the offer to help out. Beyond trying the basics and reporting any issues that's about all I can do. I've enough on my plate at the moment as it is.

@whitingjr

This comment has been minimized.

Copy link
Author

whitingjr commented Apr 2, 2019

@headius In an attempt to help progress the project forward I'll ask a question. About strategy. The question is a difficult one that involves a non-trivial amount of work. That I can't commit to solving.
When I see the direction of OpenJDK and in particular JSR 260 becoming rigidly enforced it presents an issue for JRuby. The adoption of Quarkus hinges on no dependencies on reflection. The question I have (wearing my observer Hat) is what is the strategy for removing the reliance on Reflection in the JRuby project?

@headius

This comment has been minimized.

Copy link
Member

headius commented Apr 9, 2019

The adoption of Quarkus depends on predictable reflection. It is always possible for us to mark up code or configure the build to know about the (relatively few) invasive reflections we have to do. More interesting will be to see how closely the class library followed OpenJDK...for AOT there must be some internal classes they had to rework.

My general thoughts for supporting Quarkus:

  • Push forward plans to do ahead-of-time code generation, from precompiled Ruby code to pre-generated specialized objects to direct call sites that assume one or two static targets before doing a dynamic lookup.

This will allow us to have most call sites be direct, possibly inlined and specialized by the GraalVM AOT compiler, while avoiding most reflection.

  • Rig up a system for users to specify the classes they reflect from Ruby code (or to gather that information during e.g. a test run) so those classes are known to the GraalVM AOT.

This will allow us to do many of the Java integration features we depend on, since the reflective parts will already have been handled.

  • Build a new mechanism for doing dynamic calls that does not use invokedynamic, and instead uses the generated call sites above.

This eliminates the need for invokedynamic, which is unlikely to ever be supported on GraalVM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.