Skip to content
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

Closed
wants to merge 4 commits into from

Conversation

cshung
Copy link
Member

@cshung cshung commented Feb 7, 2024

No description provided.

@ghost
Copy link

ghost commented Feb 7, 2024

Tagging subscribers to this area: @BrzVlad
See info in area-owners.md if you want to be subscribed.

Issue Details

null

Author: cshung
Assignees: -
Labels:

area-GC-mono

Milestone: -

@ghost ghost assigned cshung Feb 7, 2024
@cshung cshung marked this pull request as draft February 7, 2024 22:36
@vargaz
Copy link
Contributor

vargaz commented Feb 8, 2024

The mono changes look ok.

@@ -958,9 +958,17 @@ void
ves_icall_System_Buffer_BulkMoveWithWriteBarrier (guint8 *destination, guint8 *source, size_t len, MonoType *type)
Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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.

@github-actions github-actions bot locked and limited conversation to collaborators Apr 9, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants