-
-
Notifications
You must be signed in to change notification settings - Fork 921
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
jit.codeCache doesn't work #1585
Milestone
Comments
I guess this one can be closed. |
We did actually deprecate and move jit.codeCache out of --properties at some point, so I think this is resolved. I'm auditing the other properties now and will push a PR for review. |
Seems it was deprecated at least by July 25, 2015, which puts it roughly around 9.0.1.0 timeframe. |
headius
added a commit
to headius/jruby
that referenced
this issue
Jul 10, 2020
Most of these were completely unused. A few were still used but the features they referred to did not work anymore, or were otherwise nonnfunctional in some way. There's some related cleanup of RubyInstanceConfig here but I have not done a full audit of unused fields and methods there. At least a few of these may have meaning in the future, if the functionality they used to refer to is restored: * REFLECTED_HANDLES: we may want to add back reflected DynamicMethod handles to core class methods to support platforms that do not allow bytecode generation (e.g. GraalVM AOT). * FIBER_COROUTINES: The Loom project is moving fast and we will definitely take advantage of it. We will probably want a more Loom-specific property name at that time, though. * FFI_COMPILE_INVOKEDYNAMIC: We are not currently binding Ruby to FFI calls as directly as we could, and we should probably restore this functionality at some point. * THREAD_DUMP_SIGNAL: We used to register a trap for dumping all Ruby stack traces. We may want to restore this functionality. * ENUMERATOR_LIGHTWEIGHT: We may want to make it possible to turn off lightweight enumerators, of which we currently have none? Seems unlikely. * INVOKEDYNAMIC*: most of the capabilities of invokedynamic have been always-on (in indy mode) since they stabilized in Java 8, but being able to configure them at a finer grain may be useful in the future. * COMPILE*: as with INVOKEDYNAMIC*, most optimizations are always- on, and we may want to restore the ability to turn them off. This cleanup was inspired by jruby#1585.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
I'm using jruby 1.7.11 (1.9.3p392) 2014-02-24 86339bb on Java HotSpot(TM) Client VM 1.7.0_10-b18 [Windows XP-x86]
I run
jruby -Xcompile.mode=FORCE -Xjit.debug=true -Xjit.codeCache=c:\tmp test.rb
and many
will be printed. And in the rerun the same, but the cached files exists in the directory.
I looked into the source and I found that the JRubyClassLoader is used to load the cached classes. But I can't find the location in the code where the codeCache directory is added to the JRubyClassLoader.
After I patched the getJRubyClassLoader method in the Ruby class, and add the code cache directory to the Classloader, everything works fine for me.
Maybe this is an possible patch for the Ruby class.
Thanks,
André
The text was updated successfully, but these errors were encountered: