| Title | AWL is awkward to use |
| Status | open |
| Priority | nice |
| Assigned user | Richard Brooksby |
| Organization | Ravenbrook |
| Description | AWL makes it possible to write weak hash tables, but the resulting code is quite ugly. You divide a hash table into three objects: 1. Metadata, including the location dependency. 2. The array of keys 3. The array of values The keys have a "dependent object" of the values, and vice versa. The awkwardness comes from deciding where to store various items of metadata, like the table length, the counts of used and unused buckets, and so on. They belong in object (1), but unfortunately they can't go there, because while we are scanning the keys (say), we need to know the length, but only have access to objects (2) and (3). Similarly for the bucket counts: these get updated during scanning (because that's when you detect a splat), and so need to be in the keys/values too. |
| Analysis | See also job001151. It would be nice if there were a more general way for a scan method for one object to expose other objects. That would allow the keys/values to look at the table metadata. Can we give users some kind of abstraction that will let them do this? What can we guarantee about the state of the other object? Maybe we can only read its value fields and not its references? GDR 2014-05-16: An alternative (and better?) idea is to have multi-rank scanning. The approach is as follows: 1. Add a keyword argument to mps_ap_create_t that allows you to create allocation points with a rank set (not just a single rank as at present). 2. Provide a way for the client to determine which ranks are being scanned in the current band. (There might be multiple ranks being scanned because of the possibility of hitting a weak segment and having to scan it exactly -- this would be communicated as the set {EXACT, WEAK}.) This could be a lookup method on the scan state. 3. This would mean that a weak hash table wouldn't need to have two buckets lists (one weak, one strong). It could have one bucket list and scan the side(s) indicated by the rank(s) currently being scanned. There would then be no need for it to have a dependent object method. 4. If done generally, it would mean that the only reason to allocate in AWL would be the SingleAccess optimization. |
| How found | manual_test |
| Evidence | See implementation of weak hash tables in scheme-advanced.c: <https://info.ravenbrook.com/project/mp...-guide/example/scheme/scheme-advanced.c> |
| Observed in | 1.110.0 |
| Created by | Gareth Rees |
| Created on | 2012-11-01 17:34:35 |
| Last modified by | Gareth Rees |
| Last modified on | 2014-05-16 13:29:09 |
| History | 2012-11-01 GDR Created. |