-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Introduce RuntimeHelpers.GetObjectHeader and Optimize Object.GetHashCode() with it #100999
Conversation
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
I tried non-intrinsic version ealier and measured a significant regression. |
with pinning? no wonder then 🙂 |
No pinning. I was not sure about how GC deals with exterior pointer. I reverted it then in #97641 |
I don't see why my version could be slower (and it's not according to benchmarks) - the codegen has a small CQ problem (#101000) but I am not even sure it can change the result. |
...coreclr/System.Private.CoreLib/src/System/Runtime/CompilerServices/RuntimeHelpers.CoreCLR.cs
Show resolved
Hide resolved
Yeah, I realized it may need intrinsic handling like retrieving method table. |
Looks like this PR is a regression when object has a syncblock and I don't think I can surface |
We would be need both reads and interlocked writes for this. To enable rewriting methods like there in C#, I think it would be better to look into general pinning optimizations (#63397) rather than specialized intrinsics. |
It can be done once we have a good reason to. |
A GC-hole free version of #55273, should slightly speed up object.GetHashCode, e.g.:
Example:
Current codegen:
New codegen:
This should allow us to convert Monitor.Enter/Exit to C# as well (thin lock, etc).