Background and motivation
I've been exploring the possibility of detouring the GC (through the standalone GC interface) for a diagnostic tool, but the current contract makes it really hard to build something that works across versions.
Basically, when loading the GC, the EE asks the GC what version of the contract it supports, as described here. Because of this, unless the GC somehow detects the version of the runtime (which is non-trivial), it is not possible to have a single library that supports multiple version.
Instead, we could have the runtime ask the GC whether it supports version X.Y of the contract. This way, the GC can return the right implementation if available (similar to COM QueryInterface).
API Proposal
extern"C"boolGC_VersionInfo2(
/* In */ VersionInfo
);
API Usage
extern"C"boolGC_VersionInfo2(VersionInfo versionInfo)
{
if (versionInfo.MajorVersion == 4 || versionInfo.MajorVersion == 5)
{
m_expectedVersion = versionInfo.MajorVersion;
returntrue;
}
returnfalse;
}
extern"C"HRESULTGC_Initialize(
void* gcToCLR,
void** gcHeap.
void** gcHandleManager,
void* gcDacVars
)
{
if (m_expectedVersion == 4)
{
InitializeGCv4(gcToCLR, gcHeap, gcHandleManager, gcDacVars);
returnS_OK;
}
elseif (m_expectedVersion == 5)
{
InitializeGCv5(gcToCLR, gcHeap, gcHandleManager, gcDacVars);
returnS_OK;
}
else
{
returnE_NOINTERFACE;
}
}Alternative Designs
Alternatively, GC_VersionInfo and GC_Initialize could be merged:
extern"C"HRESULTGC_Initialize2(
/* In */ VersionInfo,
/* In */ IGCToCLR*,
/* Out */ IGCHeap**.
/* Out */ IGCHandleManager**,
/* Out */ GcDacVars*
);
But this solution does not allow adding more parameters in the future (short of introducing GC_Initialize3 and so on).
Or we could implement a COM interface with QueryInterface.
Risks
Compatibility wouldn't be an issue, as the new API could be introduced with the next major version change of the GC contract.
The custom GC could lie, ending up on random crashes later during the application lifetime.
Background and motivation
I've been exploring the possibility of detouring the GC (through the standalone GC interface) for a diagnostic tool, but the current contract makes it really hard to build something that works across versions.
Basically, when loading the GC, the EE asks the GC what version of the contract it supports, as described here. Because of this, unless the GC somehow detects the version of the runtime (which is non-trivial), it is not possible to have a single library that supports multiple version.
Instead, we could have the runtime ask the GC whether it supports version X.Y of the contract. This way, the GC can return the right implementation if available (similar to COM QueryInterface).
API Proposal
API Usage
Alternative Designs
Alternatively, GC_VersionInfo and GC_Initialize could be merged:
But this solution does not allow adding more parameters in the future (short of introducing
GC_Initialize3and so on).Or we could implement a COM interface with
QueryInterface.Risks
Compatibility wouldn't be an issue, as the new API could be introduced with the next major version change of the GC contract.
The custom GC could lie, ending up on random crashes later during the application lifetime.