-
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
Allow mono to reuse the shared memmove implementation #98133
Conversation
Tagging subscribers to this area: @BrzVlad Issue Detailsnull
|
The mono changes look ok. |
b4215ce
to
e62fcc6
Compare
@@ -958,9 +958,17 @@ void | |||
ves_icall_System_Buffer_BulkMoveWithWriteBarrier (guint8 *destination, guint8 *source, size_t len, MonoType *type) |
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.
I think this method is always called when type contains references. We can probably discard the type
argument and have a new GC api method, something like mono_gc_move_with_write_barrier
that ends up calling wbarrier_value_copy
. mono_gc_wbarrier_range_copy
could also be reused.
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.
@BrzVlad, thanks for the idea. I am not sure if it is possible to drop the type
argument though. It looks like the function mono_gc_wbarrier_value_copy_internal
relies critically on the klass
to get GC description for scan_object_for_binary_protocol_copy_wbarrier
, am I missing something?
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.
The binary protocol is our mechansim to internally log gc activity to a file, for debugging purposes. The heavy binary protocol contains very verbose logging for frequent gc activity (like allocation, write barrier etc) and it is statically disabled by default in the runtime so it doesn't slow down hot paths (even if the logging itself is not enabled by env var). We haven't even ported yet the binary protocol file viewer for dotnet runtime. For now we can ignore it and just add a FIXME in case we want to get back to it.
No description provided.