| Title | Pointers from MPS stack pin down user objects |
| Status | closed |
| Priority | optional |
| Assigned user | Richard Brooksby |
| Organization | Ravenbrook |
| Description | When the MPS scans the stack of the mutator thread that calls the MPS (the only thread in single-threaded uses) it starts at the current stack pointer and register contents. This means that it scans its own stack as well as the mutator's. We know that the MPS stack is not part of the mutator's graph of objects, but it is very likely to contain pointers to base addresses of pages and segments, causing them to be pinned down. This causes zone pollution. We know this really happens, as it has been observed in a commercial customisation of the MPS. |
| Analysis | The MPS should scan the mutator's registers and stack only. That is, the stack above the entry point to the MPS, and the register contents that the mutator had on call. We can get at these in a semi-portable manner by calling setjmp at any entry point to the MPS that might scan the stack, and scanning the jmp_buf and the stack it refers to. Adapt sc.h (stack context) for the open source MPS (needs platform-specific research). Apply it on those entry points at least. Possibly on every ArenaEnter. See orginal e-mail thread [1] [2] [3] [4] [5] [6] [7] and review thread [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19]. GDR 2014-05-01: Note that if we implement this then we will be in a position to fix job003780. Here's some analysis of which entry points might call StackScan (and so need the stack context to have been recorded at ArenaEnter). StackScan is called by ThreadScan ← mps_stack_scan_ambig ← RootScan ← traceScanRootRes ← traceScanRoot ← rootFlip ← traceFlip ← TraceStart ← TracePoll, and then: - TracePoll - ArenaPoll - mps_alloc - mps_ap_fill - mps_ap_fill_with_reservoir_permit - mps_ap_alloc_pattern_end - mps_ap_alloc_pattern_reset - ArenaRelease - mps_arena_release - ArenaStartCollect - mps_arena_start_collect - ArenaCollect - mps_arena_collect - ArenaStep - mps_arena_step - TraceStartCollectAll - ArenaStep. - ArenaStartCollect. - TracePoll. so only these nine entry points might flip, and so need the stack context. This kind of analysis is delicate, though -- it will be a good idea to assert in StackScan that we have the stack context, but if we don't, then get it anyway. |
| How found | inspection |
| Evidence | [1] <https://info.ravenbrook.com/mail/2012/08/01/21-38-32/0/>[2] < https://info.ravenbrook.com/mail/2012/08/03/10-00-15/0/>[3] < https://info.ravenbrook.com/mail/2012/08/03/13-03-45/0/>[4] < https://info.ravenbrook.com/mail/2012/08/03/13-48-54/0/>[5] < https://info.ravenbrook.com/mail/2012/08/03/14-36-35/0/>[6] < https://info.ravenbrook.com/mail/2012/08/06/10-27-18/0/>[7] < https://info.ravenbrook.com/mail/2012/08/06/10-42-43/0/>[8] < https://info.ravenbrook.com/mail/2012/09/10/14-56-23/0/>[9] < https://info.ravenbrook.com/mail/2012/09/10/15-06-03/0/>[10] < https://info.ravenbrook.com/mail/2012/09/10/17-18-25/0/>[11] < https://info.ravenbrook.com/mail/2012/09/10/19-05-25/0/>[12] < https://info.ravenbrook.com/mail/2012/09/10/19-46-27/0/>[13] < https://info.ravenbrook.com/mail/2012/09/10/19-48-39/0/>[14] < https://info.ravenbrook.com/mail/2012/09/10/19-49-37/0/>[15] < https://info.ravenbrook.com/mail/2012/09/11/17-38-54/0/>[16] < https://info.ravenbrook.com/mail/2012/09/12/17-45-44/0/>[17] < https://info.ravenbrook.com/mail/2012/09/12/22-00-06/0/>[18] < https://info.ravenbrook.com/mail/2012/09/12/22-23-40/0/>[19] < https://info.ravenbrook.com/mail/2012/09/12/22-55-41/0/> |
| Observed in | 1.109.0 |
| Created by | Richard Brooksby |
| Created on | 2013-06-20 17:05:19 |
| Last modified by | Gareth Rees |
| Last modified on | 2018-07-11 15:21:33 |
| History | 2013-06-20 RB Created. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 194595 | closed | 2018-07-11 15:20:49 | Gareth Rees | Merge branch/2014-10-26/sc into the master sources. |
| 187412 | open | 2014-10-26 22:18:57 | Gareth Rees | Save mutator context on entry to the MPS. |