Allow mono to reuse the shared memmove implementation#98133
Allow mono to reuse the shared memmove implementation#98133cshung wants to merge 4 commits intodotnet:mainfrom
Conversation
cshung
requested review from
lambdageek,
marek-safar,
thaystg and
vargaz
as code owners
|
Tagging subscribers to this area: @BrzVlad Issue Detailsnull
|
ghost
assigned
|
The mono changes look ok. |
cshung
force-pushed
the
public/reuse-memmove
branch
from
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.
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.
@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.
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.
3 participants
No description provided.