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

Handle super.x++ and similar #1738

Closed
wants to merge 7 commits into from

Conversation

andreabergia
Copy link
Contributor

This PR, co-authored with @0xe, adds support for super.x++ and similar. It is stacked on top of #1735.

Rhino has special opcodes (and similar in compiled classes) for a.b++, probably for historical reasons. Given the number of bytecodes already added by #1735, we have decided to implement this one differently - we just replace super.x++ with super.x = super.x + 1 in the bytecode.

andreabergia and others added 2 commits December 2, 2024 08:29
Copy link
Collaborator

@gbrail gbrail left a comment

Choose a reason for hiding this comment

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

This is fine but I'm not sure that you need to unwrap and re-wrap that value, rather than using the methods we already have that can operate directly.

FWIW, I have considered adding "MATH:INCREMENT" and "MATH:DECREMENT" INDY instructions, and getting rid of all the "elemIncrDecr" and "propIncrDecr" stuff, which I think is overcomplicated and doesn't help performance. If I do that it would clean this up too.

}

// Increment or decrement the value
addObjectToDouble(); // Unbox
Copy link
Collaborator

Choose a reason for hiding this comment

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

I'm not sure that this is more efficient than leaving the object as it was, and adding a "MATH:ADD" instruction, or a call to ScriptRuntime.subtract, instead.

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've copy&pasted the code from the pre-existing visitIncDec. If we want to change the approach, it would be better to do it in both places (so, IMHO in a different PR)

Copy link
Collaborator

Choose a reason for hiding this comment

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

I did some experimenting with increment stuff last week and it's both not simple to completely change this stuff, and not faster to do it the way that I suggested. So I think that the way you have it here is fine. Thanks!

andreabergia and others added 2 commits December 9, 2024 10:42
This reverts commit b845d14.

Co-authored-by: Satish Srinivasan <[email protected]>
Co-authored-by: Satish Srinivasan <[email protected]>
@andreabergia
Copy link
Contributor Author

Merged onto #1735

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.

3 participants