-
Notifications
You must be signed in to change notification settings - Fork 516
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
[runtime] Move xamarin_create_managed_ref internal call to managed code. #11271
[runtime] Move xamarin_create_managed_ref internal call to managed code. #11271
Conversation
Move the xamarin_create_managed_ref internal call to managed code, to ease things with CoreCLR. In order to preserve performance, this wasn't a straight forward port. * monotouch_create_managed_ref used to detect if there already was a GCHandle for a native object. To avoid a managed->native transition, this logic has now been moved into the code that sets the GCHandle (the xamarinSetGCHandle:flags: / xamarin_set_gchandle_trampoline code), and these methods return a value saying whether the GCHandle was set or not. * xamarin_create_gchandle will check the retain count to determine whether to create a weak or a strong GCHandle for the managed object. In this particular case we should never need to create a strong GCHandle, which means that we don't need to check the retain count (saving a managed->native transition). Performance measurements: slightly faster in all test cases I could come up with. * 'new NSObject ()': 3% faster * 'new CustomObject ()': 6% faster * Creating an NSObject in native code, and getting the managed wrapper: 0.6% faster * Creating a CustomObject in native code (the type being defined in managed code): 2% faster All measurements done in an iOS simulator on an iMac Pro.
❌ Tests failed on Build ❌Tests failed on Build. API diff✅ API Diff from stable View API diffTest results22 tests failed, 77 tests passed.Failed tests
|
✅ Tests passed on Build. ✅Tests passed on Build. API diff✅ API Diff from stable View API diff🎉 All 102 tests passed 🎉 |
bool | ||
xamarin_set_gchandle_with_flags_safe (id self, GCHandle gchandle, enum XamarinGCHandleFlags flags) | ||
{ | ||
// COOP: no managed memory access: any mode |
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.
This comment sounds outdated.
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.
Small stupid question.
enum XamarinGCHandleFlags : uint32_t { | ||
XamarinGCHandleFlags_None = 0, | ||
XamarinGCHandleFlags_WeakGCHandle = 1, | ||
XamarinGCHandleFlags_HasManagedRef = 2, | ||
XamarinGCHandleFlags_InitialSet = 4, |
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.
What happened with 3?
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.
These are flags, so 1 + 2 = 3.
Move the xamarin_create_managed_ref internal call to managed code, to ease things
with CoreCLR.
In order to preserve performance, this wasn't a straight forward port.
monotouch_create_managed_ref used to detect if there already was a GCHandle for
a native object. To avoid a managed->native transition, this logic has now been
moved into the code that sets the GCHandle (the
xamarinSetGCHandle:flags:
/xamarin_set_gchandle_trampoline
code), and these methods return a value saying whether the GCHandle was set or
not.
xamarin_create_gchandle will check the retain count to determine whether to create
a weak or a strong GCHandle for the managed object. In this particular case we
should never need to create a strong GCHandle, which means that we don't need to
check the retain count (saving a managed->native transition).
Performance measurements: slightly faster in all test cases I could come up with.'new NSObject ()': 3% faster'new CustomObject ()': 6% fasterCreating an NSObject in native code, and getting the managed wrapper: 0.6% fasterCreating a CustomObject in native code (the type being defined in managed code): 2% fasterAll measurements done in an iOS simulator on an iMac Pro.Using the new perftest (#11298), I get very similar numbers for both old code and new code: https://gist.github.com/rolfbjarne/e0fc2ae0f21da15062b4f051138679af (multiple runs). Sometimes the old code is faster, sometimes the new code is faster (although the old code tends to be the one who wins).
In any case there aren't any significant performance hits due to this change, so it should be good to go.
The next failure is now: