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

Further Truffle-related clean ups and simplifications. #2425

Merged
merged 8 commits into from Jan 8, 2015
Merged

Further Truffle-related clean ups and simplifications. #2425

merged 8 commits into from Jan 8, 2015

Conversation

thomaswue
Copy link
Contributor

Please review, @chrisseaton @nirvdrum @eregon.

@@ -67,6 +65,7 @@ public boolean executeRepeating(VirtualFrame frame) {
break;
} catch (RedoException e) {
// Just continue in the while(true) loop.
context.getSafepointManager().poll();
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We do not need a safepoint if the block is executed only once. In general, doing the safepoint only after the first iteration reduces the number of safepoints compiled/executed.

Copy link
Member

Choose a reason for hiding this comment

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

But the RedoException branch is only taken when using the redo, keyword, no?
And that is quite rare, so there is no more safepoint in a typical loop with this code if I see right (or is it done with instrumentation by the LoopNode?).

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes redo is unusual - most loops will run this inner while loop just once per actual loop iteration. I think we need to poll the safepoint before the return as well. This duplication of safepoints might be why I put it at the head in the first place.

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 are right. I will put the safepoints back to the original places.

@chrisseaton
Copy link
Contributor

Perhaps we want an ArrayUtils class in com.oracle.truffle.api.util, that are all amenable to PE. Even if some of the cases like System.arraycopy work fine anyway, it would mean that people don't have to figure out if they're safe or not for every array utility method in the JDK. Maybe the same for BigInteger - a set of helper methods that add @TruffleBoundary on those that need them, but not those that don't.

@eregon
Copy link
Member

eregon commented Jan 8, 2015

Can we merge this?

chrisseaton added a commit that referenced this pull request Jan 8, 2015
Further Truffle-related clean ups and simplifications.
@chrisseaton chrisseaton merged commit b5c82e4 into jruby:master Jan 8, 2015
@chrisseaton chrisseaton modified the milestone: truffle-dev May 4, 2015
@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

5 participants