-
-
Notifications
You must be signed in to change notification settings - Fork 925
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
Return values from Java are converted to Ruby even if you're not using them #1407
Comments
I appreciate the problem, but this is probably not going to be easy to fix. The problem is that the value is produced in one place, converted in another, and then used (or not) somewhere else. To elide the conversion based on a missing use, we have to inform the conversion site. One way to do this would be to introduce lazy conversion and shift the conversion site so it's in the same place as the use - we return an object that knows how to convert to Ruby if it ever needs to do so. But that introduces an extra layer of indirection, and so will probably significantly harm overall performance. The other way to do this would be to use some data flow analysis to determine that a value is never used and does not need to be converted. We would then also need to inline the conversion so that it can be specialised based on that analysis. Unfortunately this just isn't something that JRuby is designed to do at the moment. It would be nice if the JVM could do this automatically from our generated byte code, but again that just isn't going to happen at the moment. Your problem is probably compounded here by using I would suggest a workaround of writing a wrapper method in Java that returns @enebo or @headius might want to considering marking this as a nice idea but not going to happen any time soon (won't fix), or they might have some ideas of their own. |
I botched the previous patch a bit by unconditionally re-assigning the secureRandom local to a default JDK new SecureRandom. This could cause systems without the default preferred PRNG (NativePRNGNonBlocking, Java 8+) to have slower thread startup and/or random number generation.
I botched the previous patch a bit by unconditionally re-assigning the secureRandom local to a default JDK new SecureRandom. This could cause systems without the default preferred PRNG (NativePRNGNonBlocking, Java 8+) to have slower thread startup and/or random number generation.
We do detect unused values in our IR but our IR knows nothing of Java Integration features so our ability to detect this now is not there. |
Something I found quite by accident while benchmarking a method of ours. We had a test along these lines:
I was profiling to see where it was spending its time and over 90% of the time, it was here:
It seems like JRuby is spending over 90% of the time preparing the return value so that the Ruby script can use it, even though the script doesn't use it.
The text was updated successfully, but these errors were encountered: