Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.

Modify conservative GC code for unaligned InlinedCallFrames #1215

Merged
merged 1 commit into from
Jul 9, 2015
Merged

Modify conservative GC code for unaligned InlinedCallFrames #1215

merged 1 commit into from
Jul 9, 2015

Conversation

richardlford
Copy link

When making pinvoke calls the JITs allocate InlinedCallFrames
within their stack frames to record the location
of the managed stack frame. These were being used
as the topStack in src/vm/gcenv.cpp, in the method
GCToEEInterface::ScanStackRoots. But they are not
really the top of the stack, but they can be used to find
the real top of the stack.

This change checks to see if a frame is an InlinedCallFrame.
If so then its GetCallSiteSP method is used to
get the real top of stack.

@richardlford
Copy link
Author

@Maoni0, @pgavlin, please take a look.

@Maoni0
Copy link
Member

Maoni0 commented Jul 8, 2015

@jkotas would be a better person to review this as this is stackwalking code.

@jkotas
Copy link
Member

jkotas commented Jul 8, 2015

I think you should make the InlinedCallFrame 8-byte aligned even with conservative GC instead of trying to compensate for it in the runtime. The alignment should naturally fall out: InlinedCallFrame has pointer sized fields that you are filling in. These pointer sized fields should cause the right alignment to happen.

@pgavlin
Copy link

pgavlin commented Jul 8, 2015

Making the InlinedCallFrame 8-byte aligned doesn't solve the whole problem: the original code also makes an assumption that the address of the InlinedCallFrame corresponds to the top of the stack, which is not necessarily true.

As far as alignment goes: I agree that 8-byte aligning InlinedCallFrame values would be good. Since the InlinedCallFrame type is opaque to the JIT, the alignment information will have to be exposed through a change to the JIT/EE interface.

@jkotas
Copy link
Member

jkotas commented Jul 8, 2015

Fixing the assumption about InlinedCallFrame corresponding to the top of the stack sound good - the PR description should be fixed to match.

The alignment for InlinedCallFrame has always been pointer size, and the structure is not really opaque to the JIT - offsets of most of the fields are exposed on the JIT-EE interface for JIT to work with. I think hardcoding the alignment should be pretty reasonable. If you prefer to go through the troubles of exposing the alignment on JIT-EE interface instead of hardcoding it, I am fine with it too.

When making pinvoke calls the JITs allocate InlinedCallFrames
within their stack frames to record the location
of the managed stack frame. These InlinedCallFrames are
not necessarily 8-byte aligned. These were being used
as the topStack in src/vm/gcenv.cpp, in the method
GCToEEInterface::ScanStackRoots.

This change checks to see if a frame is an InlinedCallFrame.
If so then its GetCallSiteSP method is used to
get the real top of stack. This will always be aligned.

There were two problem before this change wwhen the
frame was misaligned (e.g. ending with 4 or c):

1. GCToEEInterface::ScanStackRoots starts at the
topStack and look at every 8-byte chunk as if it were a
pointer. But if topStack is unaligned it is not really
finding the pointers on the stack.

2. When it gets to the bottom the 8-byte access
read the first 4 bytes ok, but the last 4 bytes
go beyond mapped addresses and an access violation
results.
@richardlford
Copy link
Author

I've updated the PR description so that the issue being solved is that
InlinedCallFrames are not really the top of the stack, but can be
used to find the real top.

@richardlford
Copy link
Author

I've pushed a rebase of the change.
@jkotas, does this updated PR description and these changes
seem acceptable?

@jkotas
Copy link
Member

jkotas commented Jul 9, 2015

LGTM. Thanks!

jkotas added a commit that referenced this pull request Jul 9, 2015
Modify conservative GC code for unaligned InlinedCallFrames
@jkotas jkotas merged commit eed62e3 into dotnet:master Jul 9, 2015
@richardlford richardlford deleted the rosfix branch July 9, 2015 16:50
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants