Ports dotnet/coreclr PR#6764 (https://github.com/dotnet/coreclr/pull/6764) to ProjectN. The nature of the changes in this changelist is very similar to the changes done in CoreCLR described in the linked PR:

       1) This change synchronizes the ndp/FxCore/CoreRT/Native/gc and src/vm/gc directories of ProjectN and coreclr, respectively. There is one additional change present in this changelist that was not done to CoreCLR (and will need to be ported to CoreCLR), and that is the addition of IGCHeap::RegisterFrozenSegment and IGCHeap::UnregisterFrozenSegment to the interface. These functions are invoked from RedhawkGCInterface::RegisterFrozenSection and as such must be present on the interface. This is a very minor change that involved ensuring that Register/UnregisterFrozenSegment are defined for all builds (not just defined when FEATURE_BASICFREEZE is defined) and propagating the definition of those two functions to IGCHeap, instead of IGCHeapInternal where they resided on CoreCLR. Calling either of those two methods with FEATURE_BASICFREEZE not defined results in an assert.

       2) Like the changes to the VM in CoreCLR, uses of GCHeap in CoreRT/Native/Runtime are redirected to the GCHeapUtilities class, which maintains the singular IGCHeap instance and provides a number of static methods used by the runtime to access and query the state of the heap. For most cases in Native/Runtime, this meant renaming uses of GCHeap to GCHeapUtilities. There is a notable exception to this in that GetMaxGeneration is turned into a virtual method call on IGCHeap on non-DAC code paths (see https://github.com/dotnet/coreclr/pull/6764#issuecomment-245462736 for details on why I chose to expose a virtual and non-virtual version of GetMaxGeneration)

       3) This set of changes broke SOS GC heap dumping on CoreCLR when FEATURE_SVR_GC is defined, so this change contains a fix for that particular issue. As far as I know, FEATURE_SVR_GC is not defined on the ProjectN build, so this has no effect for now, but it will fix an issue that would be present if/when we enable Server GC. This particular fix is located in request.cpp.

     There should be no surprises in this changelist except for portable.cpp, which declares a complete alloc_context struct out-of-line from the GC interface - this change updates the declared alloc_context struct to match the one exposed by the interface.

[tfs-changeset: 1627236]

1 files changed, 2 insertions, 2 deletions

diff --git a/src/Native/Runtime/thread.h b/src/Native/Runtime/thread.h
index 56b22d6f9..5d4d39fcf 100644
--- a/src/Native/Runtime/thread.h
+++ b/src/Native/Runtime/thread.h
@@ -3,7 +3,7 @@
 // See the LICENSE file in the project root for more information.
 #include "forward_declarations.h"
 
-struct alloc_context;
+struct gc_alloc_context;
 class RuntimeInstance;
 class ThreadStore;
 class CLREventStatic;
@@ -154,7 +154,7 @@ public:
 
     bool                IsInitialized();
 
-    alloc_context *     GetAllocContext();  // @TODO: I would prefer to not expose this in this way
+    gc_alloc_context *     GetAllocContext();  // @TODO: I would prefer to not expose this in this way
 
 #ifndef DACCESS_COMPILE
     UInt64              GetPalThreadIdForLogging();