-
Notifications
You must be signed in to change notification settings - Fork 40
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
Avoid using object pinning in native blackhole #132
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
Well, there's a critical flaw in asm-based implementation: even though the native no-op function with inline assembly will be inlined into a benchmark, it's still a native call and its thread state transitions will surround inlined body (that's two CASes in total + potential runtime call, which undermine the whole idea). So I'll rewrite it using Kotlin-only solution. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice job!
@fzhinkin could you update benchmark results in PR description with latest changes? |
… 4 (Kotlin#132) Bumps [mikepenz/release-changelog-builder-action](https://github.com/mikepenz/release-changelog-builder-action) from 3 to 4. - [Release notes](https://github.com/mikepenz/release-changelog-builder-action/releases) - [Commits](mikepenz/release-changelog-builder-action@v3...v4) --- updated-dependencies: - dependency-name: mikepenz/release-changelog-builder-action dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Re-implemented native blackhole without using object pinning as it affects performance and leads to unstable results as each time GC has to spend more and more time scanning all pinned values.
Instead, primitive values consumption is implemented as a comparison of the value for equality with two fields and publishing the value in case when comparison succeeds. The values themselves are never the same and one of the fields is volatile, thus the condition is always false and it could not be omitted because of volatility. That should prevent both dead code elimination and movement of the code computing the consumed value into an effectively unreachable branch.
For the objects, identifyHashCode is used to obtain an int-value that is then passed into a regular consumption routine. That function is an intrinsic that simply gets an address of the object, so it has no performance impact, yet it requires an object.
Verified stability and correctness using the reproducer mentioned here: #114 (comment)
With old implementation of the blackhole results looked like this:
With the new one:
Fixes #114