| Title | Scanning rate is way too high |
| Status | open |
| Priority | optional |
| Assigned user | David Lovemore |
| Organization | Ravenbrook |
| Description | Looking at scan rates in CVM, I found that there were rates of over 1Mb. That is more than 1Mb was scanned during a collection for every 64K allocated (more than 16 times as much scanning as allocation). |
| Analysis | Digging further I determined that about half of the scanning was attributable to segments that had been written to and so the remembered set was lost, so they needed scanning anyway. The other half were segments in high generations that referred to objects in the nursery because they were pinned due to ambiguous references. These appeared to be genuine ambiguous references to objects created at the cold end of the stack and passed as parameters to long running functions. So these ambiguous references are causing the remembered sets to be ineffective: we have objects in high generations that refer to objects in a low generation, and that means we can't avoid scanning the high generations as we would be able to if all references were exact. Possible solutions include: 1. Avoid these particular ambiguous references, by for example using a proxy object. [This might solve the immediate problem for the customer, but wouldn't be very general. The MPS ought to get this right ought of the box.] 2. Exact stack scanning of particular frames. [Again, not a general solution; and moreover very hard given the way the just-in-time compilation works.] 3. [The favoured solution.] Remember a time for when each segment is protected. We can be sure any objects that are allocated after this time are not referred to by the segment. Then we won't need to scan the segment again if it was protected before the condemned set was allocated. |
| How found | manual_test |
| Evidence | [1] <https://info.ravenbrook.com/mail/2014/01/28/12-37-10/0/> |
| Created by | David Lovemore |
| Created on | 2014-04-14 16:20:32 |
| Last modified by | Gareth Rees |
| Last modified on | 2014-04-14 18:45:29 |
| History | 2014-04-14 DL Created. |