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

[Truffle] Limit the number of methods available for runtime compilation #3226

Merged
merged 2 commits into from
Aug 5, 2015

Conversation

bbelleville
Copy link
Contributor

This pull request lowers the number of methods available for runtime
compilation from over 33,000 to less than 15,000. Some methods that
could not be annotated with TruffleBoundary were split in order to
introduce a boundary.

I used a static analysis tool to determine what methods were causing a large number of other methods to be included for runtime compilation and added Truffle boundaries to limit this.

Removing this keeps printStackTrace from being inlined during
compilation. An ArrayIndexOutOfBoundsException will still be thrown in
the case of an invalid index.
This change lowers the number of methods available for runtime
compilation from over 33,000 to less than 15,000. Some methods that
could not be annotated with TruffleBoundary were split in order to
introduce a boundary.
@chrisseaton
Copy link
Contributor

These all seem fine.

chrisseaton added a commit that referenced this pull request Aug 5, 2015
[Truffle] Limit the number of methods available for runtime compilation
@chrisseaton chrisseaton merged commit 746f24f into jruby:master Aug 5, 2015
@chrisseaton chrisseaton added this to the truffle-dev milestone Aug 5, 2015
@chrisseaton chrisseaton self-assigned this Aug 5, 2015
@@ -114,6 +115,7 @@ public BacktraceNode(RubyContext context, SourceSection sourceSection) {
readCustomBacktrace = new ReadHeadObjectFieldNode("@custom_backtrace");
}

@TruffleBoundary
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

asRubyStringArray() should probably be the boundary, the rest should not have too many nodes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, the tool shows that asRubyStringArray is the method that makes a lot reachable for compilation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I'll fix on master 😃

@eregon
Copy link
Member

eregon commented Aug 5, 2015

It is a bit unfortunate that ThreadLocal.get() must be a boundary (probably only the slow path of it needs it). It might not matter much in practice though.
The rest looks fine, but it would be nice to reconsider the couple ones I highlighted.

@chrisseaton
Copy link
Contributor

ThreadLocal.get() is a map lookup so will also have to be boundary. It isn't just a native call.

@eregon
Copy link
Member

eregon commented Aug 5, 2015

And with that I forgot:
very good job finding those @bbelleville!

@eregon
Copy link
Member

eregon commented Aug 5, 2015

@chrisseaton if we get in getEntryAfterMiss() then yeah it is not pretty, but otherwise it looks all fine.
We should probably have a way to annotate existing JDK methods.

@bbelleville bbelleville deleted the boundaries branch August 6, 2015 18:04
@enebo enebo added this to the Non-Release milestone Dec 7, 2017
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

Successfully merging this pull request may close these issues.

None yet

4 participants