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

attempt to share loader for JIT-ed classes #5880

Merged
merged 2 commits into from Sep 27, 2019
Merged

attempt to share loader for JIT-ed classes #5880

merged 2 commits into from Sep 27, 2019

Conversation

@kares
Copy link
Member

kares commented Sep 17, 2019

introduces a -Xjit.loader.mode which is either UNIQUE (default), SHARED or SHARED_SOURCE

most of it is making WeakValueMap implement Map as I originally did something else here ...
so I've kept that code and just did a fake Map for the single (shared) global class-loader.
that can be changed as needed to a cleaner (proper oop) way.

the SHARED_SOURCE was so far only tested with jruby's test suite, the JITed class-loader count went down to 10% ... and meta-space was much less fragmented - saving around 8% of allocated space.

was not sure whether we should attempt to somehow detect eval-ed pieces
and not share them with the same source file but rather always on their own?
given that SHARED_SOURCE isn't changed to be the new default, we can also decide later.

also if you have suggestions for better naming the option or the enum values.

@kares kares changed the title an attempt to share loader for JIT-ed classes attempt to share loader for JIT-ed classes Sep 17, 2019
@kares kares requested review from headius and enebo Sep 20, 2019
Copy link
Member

headius left a comment

This all seems good to me!

I don't know what to say about eval methods; in order for them to be a problem, they'd have to:

  • Be continually generated at runtime. This is very uncommon.
  • Be called enough to JIT. This seems unlikely now and even more unlikely with our time-based threshold changes.

On the flip side, many methods get generated using eval in a "safe" way (only once, usually to lazily metaprogram some methods) and we definitely want those to be eligible for JIT without a whole separate classloader (when running in a shared mode).

I think we go with this for now as-is. Folks that opt into shared classloading can help us uncover any weird eval edge cases.

@enebo
enebo approved these changes Sep 26, 2019
@kares kares added this to the JRuby 9.2.9.0 milestone Sep 27, 2019
@kares kares added the jit label Sep 27, 2019
either for every JIT-ed class or based on source file
@kares kares force-pushed the jit-max-pp branch from 7270e7a to f07b095 Sep 27, 2019
@kares kares merged commit a88704f into master Sep 27, 2019
1 of 6 checks passed
1 of 6 checks passed
jruby.jruby Build #20190927.3 failed
Details
jruby.jruby (Job mac) Job mac failed
Details
jruby.jruby (Job windows) Job windows failed
Details
continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
continuous-integration/travis-ci/push The Travis CI build is in progress
Details
jruby.jruby (Job linux) Job linux succeeded
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.