Fix unsafe edge cases for in-place update of records #8539
Conversation
The JIT could do unsafe in-place updates of records in relatively rare circumstances. As well as correcting the bug, also add the test cases that should have been there in the first place.
When GC was temporarily disabled (for example during the execution of some BIFs), an unsafe in-place update of a record could occur.
CT Test Results 3 files 143 suites 50m 20s ⏱️ Results for commit a180597. ♻️ This comment has been updated with latest results. To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts// Erlang/OTP Github Action Bot |
|
@bjorng we have noticed a performance degradation (execution time) after this change. I don't have any more information than this at the moment. Since I don't have yet any more information at the moment I just want to ask if you'd be expecting that a performance degradation would occur after this change? |
|
Yes, a performance degradation can occur if the change disabled an unsafe in-place tuple update in your code. |
|
@bjorng thanks! We must be doing some kind of anti pattern because for certain test cases we are seeing 36% execution time increase with OTP 27.0.1 compared to the -12% gain we had when we switched to OTP 27.0. |
|
@bjorng I am trying to see if any such thing is happening in our code atm but I have hard time detecting it. Do you happen to have a simple method to detect the disabling of an unsafe in-place tuple update? |
|
There is a change in the compiler in Erlang/OTP 27.0.1 that could potentially explain the slowdown: 28d0a97. If you have re-compiled your source code with Erlang/OTP 27.0.1, it is possible that some record update operations are no longer optimized. If you have not re-compiled your source, the change in the compiler is not responsible. To check whether a record update operation uses the in-place optimization, compile using the |
|
I have recompiled my code with the fix from 5dccb45 and with it the performance degrades a bit. If I revert that commit my code runs faster. I checked the assembly listings of my module that is affected and I did see a few locations with So can the above mentioned commit impact performance even if the assembly listing becomes the same? |
|
Sorry I mentioned the wrong commit. Rather it is this commit that made my performance degrade: a180597. And I can notice it by just recompiling OTP and not my own code. |
|
@bjorng Specifically this line in
If I comment this out and recompile OTP I can get back the loss. However I haven't got a clue how this relates to my code but would like to know how it can be investigated :) |
|
FYI! I tried adding this line: The commit mentions JIT which I'm not using so it feels like it has impact outside of that. |
a180597 in erlang#8539, a correction for an unsafe in-place update of a record, had the side effect of causing a major (fullsweep) garbage collection when GC has been temporarily disabled and then again enabled. Since many BIFs, such a `term_to_binary/1` and `iolist_to_binary/1, may temporarily disable GC, this could lead to noticeable performance regressions. This commit ensures that it is again possible to do a minor collection when GC is being enabled.
a180597 in erlang#8539, a correction for an unsafe in-place update of a record, had the side effect of causing a major (fullsweep) garbage collection when GC has been temporarily disabled and then again enabled. Since many BIFs, such a `term_to_binary/1` and `iolist_to_binary/1`, may temporarily disable GC, this could lead to noticeable performance regressions. This commit ensures that it is again possible to do a minor collection when GC is being enabled.
a180597 in erlang#8539, a correction for an unsafe in-place update of a record, had the side effect of causing a major (fullsweep) garbage collection when GC has been temporarily disabled and then again enabled. Since many BIFs, such as `term_to_binary/1` and `iolist_to_binary/1`, may temporarily disable GC, this could lead to noticeable performance regressions. This commit ensures that it is again possible to do a minor collection when GC is being enabled.
|
Will try it 👍 |
|
My performance issues disappeared :-D great! |
a180597 in erlang#8539, a correction for an unsafe in-place update of a record, had the side effect of causing a major (fullsweep) garbage collection when GC has been temporarily disabled and then again enabled. Since many BIFs, such as `term_to_binary/1` and `iolist_to_binary/1`, may temporarily disable GC, this could lead to noticeable performance regressions. This commit ensures that it is again possible to do a minor collection when GC is being enabled.
a180597 in erlang#8539, a correction for an unsafe in-place update of a record, had the side effect of causing a major (fullsweep) garbage collection when GC has been temporarily disabled and then again enabled. Since many BIFs, such as `term_to_binary/1` and `iolist_to_binary/1`, may temporarily disable GC, this could lead to noticeable performance regressions. This commit ensures that it is again possible to do a minor collection when GC is being enabled.
|
Thanks for reporting this performance regression! |
|
Thank you for fixing it :) |
a180597 in erlang#8539, a correction for an unsafe in-place update of a record, had the side effect of causing a major (fullsweep) garbage collection when GC has been temporarily disabled and then again enabled. Since many BIFs, such as `term_to_binary/1` and `iolist_to_binary/1`, may temporarily disable GC, this could lead to noticeable performance regressions. This commit ensures that it is again possible to do a minor collection when GC is being enabled.
a180597 in erlang#8539, a correction for an unsafe in-place update of a record, had the side effect of causing a major (fullsweep) garbage collection when GC has been temporarily disabled and then again enabled. Since many BIFs, such as `term_to_binary/1` and `iolist_to_binary/1`, may temporarily disable GC, this could lead to noticeable performance regressions. This commit ensures that it is again possible to do a minor collection when GC is being enabled.
No description provided.