Skip to content
This repository has been archived by the owner on Mar 15, 2022. It is now read-only.

Implement GC-Table generation #680

Merged
merged 1 commit into from
Jul 8, 2015

Conversation

swaroop-sridhar
Copy link
Contributor

Translate Gc-pointer liveness information 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 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.

@swaroop-sridhar
Copy link
Contributor Author

@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);
Copy link
Member

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) {
Copy link
Contributor Author

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 swaroop-sridhar force-pushed the Section branch 2 times, most recently from 174c674 to a0b00ac Compare July 8, 2015 09:04
@swaroop-sridhar
Copy link
Contributor Author

@pgavlin, @AndyAyersMS:

Please review changes in: swaroop-sridhar@a0b00ac

@pgavlin
Copy link
Contributor

pgavlin commented Jul 8, 2015

LGTM.

@AndyAyersMS
Copy link
Member

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
@swaroop-sridhar swaroop-sridhar merged commit 9daf59c into dotnet:master Jul 8, 2015
@swaroop-sridhar swaroop-sridhar deleted the Section branch February 11, 2016 01:45
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants