|Title||Allocation frame protocol not safe for general pools|
|Assigned user||Nick Barnes|
|Description||The allocation frame protocol is not safe for general pools. Among possible problems: (a) frames are (opaquely) untagged roots, and the manual doesn't specify any rules about where and how they may be stored or used. This is probably OK for manual pools (such as SNC, which is the pool class implementing the motivating use case for frames) but probably not OK for (say) AMC. (b) the memory between an AP's buffer's Base and the AP's init address doesn't really "belong" to the AP: it belongs to the buffer, which might (in principle) be tripped at any point, so a lightweight restore to the Base might not be safe. Saying BufferBase() in mps_ap_frame_pop() outside the arena lock is either unsafe or at least a broach of the Buffer API.|
|Analysis||On (b): consider the symmetry between 'limit' (on one side of init/alloc) and 'base' (on the other side). If we want the mutator to be able to go back to 'base' (or to a 'frame' between 'base' and 'init') then we probably need to make the 'base' part of the AP (call this ap_base). Then 'trip' should affect ap_base and 'pop' should check ap_base for tripping.|
There may be other problems! Spend more time thinking about this.
It's not OK to lower an AP's init in general. The memory below init can be used by the pool for any purpose the moment init is raised. (Consider a GC pool that evacuates objects.) A pool must have a protocol for handing over that memory to the mutator and claiming it back. This is symmetrical with "limit". I therefore think that to do this right *in genral* the AP needs a "base" field down to which init can be reset, and a trap mechanism on that to force the mutator to co-operate. (It might be possible to save a few cycles by using a base value of (Addr)-1 for this.) In the meantime, we can state that not all pools support mps_ap_frame_pop(). Only those pools which promise that it's OK to re-use memory down to BufferBase() can support it. RB 2015-09-21
|Evidence||I just know.|
|Created by||Nick Barnes|
|Created on||2015-09-16 12:32:18|
|Last modified by||Gareth Rees|
|Last modified on||2016-09-13 10:37:08|
|History||2015-09-16 NB Created following discussion with RB after review of branch/2014-10-11/snc.|
2016-04-13 GDR Revised following merge of branch/2014-10-11/snc.