GC Bridge for Android scenarios #114184
GC Bridge for Android scenarios #114184
Conversation
Prior to check-in, update all places with "!TODO-JAVA!".
Implement scanning of the new GC Handle and calling a new VM callout to process the resulting data.
Implement the VM side of the GC Handle processing and callout to mark cross references.
|
Note regarding the |
1 similar comment
|
Note regarding the |
|
Tagging subscribers to this area: @dotnet/interop-contrib |
AaronRobinsonMSFT
added
the
NO-MERGE
| @@ -161,6 +161,11 @@ if(FEATURE_OBJCMARSHAL) | |||
| add_compile_definitions(FEATURE_OBJCMARSHAL) | |||
| endif() | |||
|
|
|||
| if(FEATURE_JAVAMARSHAL) | |||
| add_compile_definitions(FEATURE_JAVAMARSHAL) | |||
| add_compile_definitions(FEATURE_GCBRIDGE) | |||
There was a problem hiding this comment.
Why do we need two different FEATURE_... ifdefs for this?
There was a problem hiding this comment.
At this point there aren't any. While I was implementing it the logic was clearly distinct though. There is the general concept of the GC Bridge and also the specific Java API and infrastructure that exposes that data. It was natural to separate the two given how we've implemented other interop scenarios involving the GC. It is entirely reasonable to collapse them, but making them distinct now is much easier than retroactively splitting them in the future.
| @@ -14,7 +14,7 @@ | |||
| #endif | |||
|
|
|||
| #define INITIAL_HANDLE_TABLE_ARRAY_SIZE 10 | |||
| #define HANDLE_MAX_INTERNAL_TYPES 12 | |||
| #define HANDLE_MAX_INTERNAL_TYPES 16 | |||
There was a problem hiding this comment.
Are there perf consequences from bumping this limit? Should we start recycling deprecated HDNTYPE values (e.g. HNDTYPE_ASYNCPINNED)?
There was a problem hiding this comment.
just need to be careful that recycling wouldnt cause backcompat issues for standalone gc.
| GCScan::GcScanWithBridge(GCHeap::Promote, | ||
| condemned_gen_number, max_generation, | ||
| &sc); | ||
| drain_mark_queue(); |
There was a problem hiding this comment.
wonder whether drain_mark_queue is required after each scan or can it be combined with the one above ?
| condemned_gen_number, max_generation, | ||
| &sc); | ||
| drain_mark_queue(); | ||
| // fire_mark_event (ETW::???, current_promoted_bytes, last_promoted_bytes); |
There was a problem hiding this comment.
assume this will be a TODO to enable later?
| } | ||
| CONTRACTL_END; | ||
|
|
||
| #ifdef FEATURE_GCBRIDGE |
There was a problem hiding this comment.
shouldnt the full function be under a #ifdef ?
|
I don't think changes on the GC side need to be reviewed at this point. I know they will be different but we will address those when we actually start implementation. |
This PR contains the VM side of the work and the introduction of a new GC Handle type.
The GC work still needs to be completed. This is currently just a place to share work.