This repository has been archived by the owner on Mar 15, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 153
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
@AndyAyersMS, @pgavlin: Please review. Thanks |
// JitContext->HotCodeSize is the size of the allocated code block. | ||
// It is not the actual length of the current function's code. | ||
Encoder->SetCodeLength(JitContext->HotCodeSize); | ||
Encoder->SetSizeOfStackOutgoingAndScratchArea(0); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs to be updated to have the true size at some point, right? Should there be an issue for this?
uint8_t *CodeBlkStart, GcInfoAllocator *Allocator) | ||
: JitContext(JitCtx), LLVMStackMapData(StackMapData), | ||
CodeBlockStart(CodeBlkStart), | ||
Encoder(JitContext->JitInfo, JitContext->MethodInfo, Allocator) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The encoder constructor causes allocation using the GcInfoAllocator passed in.
swaroop-sridhar
force-pushed
the
Section
branch
2 times, most recently
from
July 8, 2015 09:04
174c674
to
a0b00ac
Compare
Please review changes in: swaroop-sridhar@a0b00ac |
LGTM. |
LGTM too. |
Translate GcInfo from __llvm.stackmaps section to CoreCLR GCInfo Encoding. Testing: 1) We can now build and a few tests in a precise-GC environment. The correctness of generated GCInfo is verified by: a) Examining the GcInfo dump in the debugger (SOS) and comparing it against the assembly dump. b) Stepping through the debugger and watch it scan through the reported GC-Roots. c) The execution crashes for the same functions if the liveness information is not reported. 2) The execution crashes if we try to build MsCorLib for precise-GC. There are a few known issues (as noted in the comments) and the remaining issues need to be fixed via debugging. 3) The standard LLILC testig is still done using conservative-gc So, no testing impact is expected for the lab. A separate test-leg will be added to run tests with precise-GC. Fixes dotnet#31
swaroop-sridhar
added a commit
that referenced
this pull request
Jul 8, 2015
Implement GC-Table generation
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Translate Gc-pointer liveness information from __llvm.stackmaps section
to CoreCLR GCInfo Encoding.
Testing:
We can now build and a few tests in a precise-GC environment.
The correctness of generated GCInfo is verified by:
a) Examining the GcInfo dump in the debugger (SOS) and comparing
it against the assembly dump.
b) Stepping through the debugger and watch it scan through the
reported GC-Roots.
c) The execution crashes for the same functions if the liveness
information is not reported.
The execution crashes if we try to build MsCorLib for precise-GC.
There are a few known issues (as noted in the comments) and the
remaining issues need to be fixed via debugging.
The standard LLILC testing is still done using conservative-gc.
So, no testing impact is expected for the lab. A separate test-leg will
be added to run tests with precise-GC.