-
Notifications
You must be signed in to change notification settings - Fork 5.1k
GC Bridge for Android scenarios #114184
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
GC Bridge for Android scenarios #114184
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why do we need two different FEATURE_... ifdefs for this? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. |
||
endif() | ||
|
||
add_compile_definitions($<$<NOT:$<BOOL:$<TARGET_PROPERTY:DAC_COMPONENT>>>:FEATURE_PROFAPI_ATTACH_DETACH>) | ||
|
||
add_definitions(-DFEATURE_READYTORUN) | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -51,7 +51,7 @@ namespace SVR { | |
#else // SERVER_GC | ||
namespace WKS { | ||
#endif // SERVER_GC | ||
|
||
#include "gcimpl.h" | ||
#include "gcpriv.h" | ||
|
||
|
@@ -6456,9 +6456,9 @@ class heap_select | |
if (GCToOSInterface::CanGetCurrentProcessorNumber()) | ||
{ | ||
uint32_t proc_no = GCToOSInterface::GetCurrentProcessorNumber(); | ||
// For a 32-bit process running on a machine with > 64 procs, | ||
// even though the process can only use up to 32 procs, the processor | ||
// index can be >= 64; or in the cpu group case, if the process is not running in cpu group #0, | ||
// For a 32-bit process running on a machine with > 64 procs, | ||
// even though the process can only use up to 32 procs, the processor | ||
// index can be >= 64; or in the cpu group case, if the process is not running in cpu group #0, | ||
// the GetCurrentProcessorNumber will return a number that's >= 64. | ||
proc_no_to_heap_no[proc_no % MAX_SUPPORTED_CPUS] = (uint16_t)heap_number; | ||
} | ||
|
@@ -6482,9 +6482,9 @@ class heap_select | |
if (GCToOSInterface::CanGetCurrentProcessorNumber()) | ||
{ | ||
uint32_t proc_no = GCToOSInterface::GetCurrentProcessorNumber(); | ||
// For a 32-bit process running on a machine with > 64 procs, | ||
// even though the process can only use up to 32 procs, the processor | ||
// index can be >= 64; or in the cpu group case, if the process is not running in cpu group #0, | ||
// For a 32-bit process running on a machine with > 64 procs, | ||
// even though the process can only use up to 32 procs, the processor | ||
// index can be >= 64; or in the cpu group case, if the process is not running in cpu group #0, | ||
// the GetCurrentProcessorNumber will return a number that's >= 64. | ||
int adjusted_heap = proc_no_to_heap_no[proc_no % MAX_SUPPORTED_CPUS]; | ||
// with dynamic heap count, need to make sure the value is in range. | ||
|
@@ -30281,6 +30281,15 @@ void gc_heap::mark_phase (int condemned_gen_number) | |
drain_mark_queue(); | ||
fire_mark_event (ETW::GC_ROOT_HANDLES, current_promoted_bytes, last_promoted_bytes); | ||
|
||
#ifdef FEATURE_GCBRIDGE | ||
dprintf(3,("GCBridge to mark handles")); | ||
GCScan::GcScanWithBridge(GCHeap::Promote, | ||
condemned_gen_number, max_generation, | ||
&sc); | ||
drain_mark_queue(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. wonder whether |
||
// fire_mark_event (ETW::???, current_promoted_bytes, last_promoted_bytes); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. assume this will be a TODO to enable later? |
||
#endif // FEATURE_GCBRIDGE | ||
|
||
if (!full_p) | ||
{ | ||
#ifdef USE_REGIONS | ||
|
@@ -42233,7 +42242,7 @@ void gc_heap::mark_through_cards_for_segments (card_fn fn, BOOL relocating CARD_ | |
size_t card_last_obj = card_of (last_object_processed); | ||
clear_cards(card, card_last_obj); | ||
|
||
// We need to be careful of the accounting here because we could be in the situation where there are more set cards between end of | ||
// We need to be careful of the accounting here because we could be in the situation where there are more set cards between end of | ||
// last set card batch and last_object_processed. We will be clearing all of them. But we can't count the set cards we haven't | ||
// discovered yet or we can get a negative number for n_card_set. However, if last_object_processed lands before what end_card | ||
// corresponds to, we can't count the whole batch because it will be handled by a later clear_cards. | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. just need to be careful that recycling wouldnt cause backcompat issues for standalone gc. |
||
|
||
/*--------------------------------------------------------------------------*/ | ||
|
||
|
Uh oh!
There was an error while loading. Please reload this page.