perf: Don't clone method body when adapting it for isOverriding #4862
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Cloning is quite slow and method bodies can be large - this results in the isOverriding check taking quite a bit longer than needed. Removing the type adaption is not possible as the javadoc explains: If we do not adapt the method, we have no CtTypeParameter declaration lying around our references can attach to. This results in getTypeErasure() potentially entering an infinite recursion.
I-Al-Istannen
changed the title
SirYwell
approved these changes
Sep 10, 2022
MartinWitt
changed the title
|
Thanks @I-Al-Istannen |
I-Al-Istannen
pushed a commit
that referenced
this pull request
Jan 17, 2024
When checking whether a method overrides another, we need to adapt both methods to a common ground. In an early version this required cloning the entire method, including its body, to perform the adaption. PR #4862 fixed this by nulling the body before cloning the method and then restoring it afterwards. This operation is not thread safe, as it may write concurrently and also modifies what other parallel threads might see when traversing the model. This patch now introduces a private override specifying whether we are only interested in the signature. If that is the case, we explicitly construct a new method using the factory instead of cloning the original. Closes: #5619
I-Al-Istannen
added a commit
that referenced
this pull request
Jan 17, 2024
When checking whether a method overrides another, we need to adapt both methods to a common ground. In an early version this required cloning the entire method, including its body, to perform the adaption. PR #4862 fixed this by nulling the body before cloning the method and then restoring it afterwards. This operation is not thread safe, as it may write concurrently and also modifies what other parallel threads might see when traversing the model. This patch now introduces a private override specifying whether we are only interested in the signature. If that is the case, we explicitly construct a new method using the factory instead of cloning the original. Closes: #5619
SirYwell
pushed a commit
that referenced
this pull request
Jan 22, 2024
When checking whether a method overrides another, we need to adapt both methods to a common ground. In an early version this required cloning the entire method, including its body, to perform the adaption. PR #4862 fixed this by nulling the body before cloning the method and then restoring it afterwards. This operation is not thread safe, as it may write concurrently and also modifies what other parallel threads might see when traversing the model. This patch now introduces a private override specifying whether we are only interested in the signature. If that is the case, we explicitly construct a new method using the factory instead of cloning the original. Closes: #5619 Co-authored-by: I-Al-Istannen <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cloning is quite slow and method bodies can be large - this results in the
isOverridingcheck taking quite a bit longer than needed.Removing the type adaption is not possible as the javadoc explains: If we do not adapt the method, we have no
CtTypeParameterdeclaration lying around our references can attach to. This results ingetTypeErasure()potentially entering an infinite recursion.There are some more gains to be had if one really wants to, but I currently don't see the need. This one is quite unobtrusive and doesn't really make the code more confusing.
Side effects
This creates an unnecessary change event for the Sniper printer (body changed), but it seems to ignore that and properly print it anyways.