diff options
author | dotnet-bot <dotnet-bot@microsoft.com> | 2016-09-14 20:44:33 +0300 |
---|---|---|
committer | dotnet-bot <dotnet-bot@microsoft.com> | 2016-09-14 20:44:33 +0300 |
commit | 2747062395320c98a1c89517d74846c32a6c7a44 (patch) | |
tree | d68902b54a474336af3fadc49c3fbc1fe8484449 /src/Native/Runtime/arm64 | |
parent | 7317131c00a93dd7705f51c4b0068b3e546c4b79 (diff) |
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]
Diffstat (limited to 'src/Native/Runtime/arm64')
-rw-r--r-- | src/Native/Runtime/arm64/AsmMacros.h | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/src/Native/Runtime/arm64/AsmMacros.h b/src/Native/Runtime/arm64/AsmMacros.h index 44f91cf7f..c7903d141 100644 --- a/src/Native/Runtime/arm64/AsmMacros.h +++ b/src/Native/Runtime/arm64/AsmMacros.h @@ -26,6 +26,6 @@ GC_ALLOC_ALIGN8 equ 8 ;; ;; Rename fields of nested structs ;; -OFFSETOF__Thread__m_alloc_context__alloc_ptr equ OFFSETOF__Thread__m_rgbAllocContextBuffer + OFFSETOF__alloc_context__alloc_ptr -OFFSETOF__Thread__m_alloc_context__alloc_limit equ OFFSETOF__Thread__m_rgbAllocContextBuffer + OFFSETOF__alloc_context__alloc_limit +OFFSETOF__Thread__m_alloc_context__alloc_ptr equ OFFSETOF__Thread__m_rgbAllocContextBuffer + OFFSETOF__gc_alloc_context__alloc_ptr +OFFSETOF__Thread__m_alloc_context__alloc_limit equ OFFSETOF__Thread__m_rgbAllocContextBuffer + OFFSETOF__gc_alloc_context__alloc_limit |