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

jit.codeCache doesn't work #1585

Closed
areman opened this issue Mar 26, 2014 · 4 comments
Closed

jit.codeCache doesn't work #1585

areman opened this issue Mar 26, 2014 · 4 comments
Milestone

Comments

@areman
Copy link
Contributor

areman commented Mar 26, 2014

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

... Ruby: no jitted code in classloader for ...
... JITCompiler: writing jitted code to to ...

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.

public synchronized JRubyClassLoader getJRubyClassLoader() {
    // FIXME: Get rid of laziness and handle restricted access elsewhere
    if (!Ruby.isSecurityRestricted() && jrubyClassLoader == null) {
        jrubyClassLoader = new JRubyClassLoader(config.getLoader());

        // if jit code cache is used, we need to add the cache directory to the classpath
        // so the previously generated class files can be reused.
        if( config.JIT_CODE_CACHE != null && !config.JIT_CODE_CACHE.trim().isEmpty() ) {
            File file = new File( config.JIT_CODE_CACHE );

            if( file.exists() == false || file.isDirectory() == false ) {
                getWarnings().warning("The jit.codeCache '" + config.JIT_CODE_CACHE + "' directory doesn't exit.");
            } else {
                try {
                    URL url = file.toURI().toURL();
                    jrubyClassLoader.addURL( url );
                } catch (MalformedURLException e) {
                    getWarnings().warning("Unable to add the jit.codeCache '" + config.JIT_CODE_CACHE + "' directory to the classpath." + e.getMessage());
                }
            }
        }
    }

    return jrubyClassLoader;
}   

Maybe this is an possible patch for the Ruby class.

Thanks,
André

@MSNexploder
Copy link
Contributor

I guess this one can be closed.
"jit.codeCache" is deprecated in 9k and (as far as I can see) does nothing nowadays.

@kares kares added this to the Won't Fix milestone Jun 10, 2017
@kares
Copy link
Member

kares commented Jun 10, 2017

@headius @enebo for 9.2 we shall move options that do nothing from being printed on --properties ?

@headius headius changed the title jit.codeCode doesn't work jit.codeCache doesn't work Jul 9, 2020
@headius
Copy link
Member

headius commented Jul 10, 2020

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.

@headius headius closed this as completed Jul 10, 2020
@headius
Copy link
Member

headius commented Jul 10, 2020

Seems it was deprecated at least by July 25, 2015, which puts it roughly around 9.0.1.0 timeframe.

449377c

@headius headius modified the milestones: Won't Fix, JRuby 9.0.1.0 Jul 10, 2020
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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants