GCInfo: Support versioning. #6325
Conversation
swaroop-sridhar
force-pushed
the
R2Rver
branch
5 times, most recently
from
c9beefd to
cd6ca95
Compare
|
@dotnet-bot test Ubuntu x64 Checked Build and Test |
|
@jkotas please review |
|
cc: @dotnet/jit-contrib |
|
We have always called this GCInfo. What's the point in renaming it to GCTable? |
|
GCInfo is the data format written to the disk -- that structure is unchanged, and still called GcInfo. |
|
Using |
|
@jkotas: I renamed the |
| @@ -3130,13 +3130,13 @@ BOOL JITNotifications::UpdateOutOfProcTable() | |||
|
|
|||
| GPTR_IMPL(GcNotification, g_pGcNotificationTable); | |||
|
|
|||
| GcNotifications::GcNotifications(GcNotification *gcTable) | |||
There was a problem hiding this comment.
This looks like find&replace mistake. This class has nothing to with GCInfo
|
LGTM otherwise. |
This change enables the VM to support multiple versions GCInfo concurrently.
This is necessary in light of upcoming work to add ReturnType and other
modifications to the GCInfo format -- so that existing ReadyToRun images
will continue to run correctly.
The version# is not stored in the GcInfo structure -- because it is
wasteful to store the version once for every method. Instead, it is
tracked per range-section of generated/loaded methods.
The GCInfo version is computed as:
1) The current GCINFO_VERSION for JITted and Ngened images
2) A function of the Ready-to-run major version stored in READYTORUN_HEADER
for ready-to-run images. ReadyToRunJitManager::JitTokenToGCInfoVersion()
provides the GcInfo version for any Method. Currently, there's only one
version of GCInfo.
An abstraction GCInfoToken is added to the GcInfo interface, which tracks the
{GcInfo, Version} pair in-memory. Several GcInfo APIs are
modified to use GCInfoToken in place of GcInfo pointers.
Notes:
1) SOS GcDump: The GCDump API has separate dump routines for Header and the
pointer-liveness information (DumpGCTable and DumpGCHeader) each of which
advance a pointer to the GCInfo block. These APIs are not changed to
recieve a GCInfoToken in place of the GcInfo block pointer. Instead, they
recieve the GcInfo version at the time of construction.
2) Some routines that are specific to x86 gcInfo (ex: crackMethodInfoHdr)
are not yet updated to use versioning, since the development plan is to
update the Non-x86 GcInfo structure first.
3) The x86 specific structs defining GcInfo headers are moved to GcInfoTypes.h,
along with the non-x86 GcInfo type definitions.
GCInfo: Support versioning. Commit migrated from dotnet/coreclr@0d5eac0
This change enables the VM to support multiple versions GCInfo concurrently.
This is necessary in light of upcoming work to add ReturnType and other
modifications to the GCInfo format -- so that existing ReadyToRun images
will continue to run correctly.
The version# is not stored in the GcInfo structure -- because it is
wasteful to store the version once for every method. Instead, it is
tracked per range-section of generated/loaded methods.
The GCInfo version is computed as:
for ready-to-run images. ReadyToRunJitManager::JitTokenToGCInfoVersion()
provides the GcInfo version for any Method. Currently, there's only one
version of GCInfo.
An abstraction GCTable is added to the GcInfo interface, which tracks the
{GcInfoBlock, GcInfoVersion} pair in-memory. Several GcInfo APIs are
modified to use GcTable in place of GcInfo pointers.
Notes:
pointer-liveness information (DumpGCTable and DumpGCHeader) each of which
advance a pointer to the GCInfo block. These APIs are not changed to
recieve a GCTable in place of the GcInfo block pointer. Instead, they
recieve the GcInfo version at the time of construction.
are not yet updated to use versioning, since the development plan is to
update the Non-x86 GcInfo structure first.