4 ms·
One proposed strategy (https://wiki.openjdk.org/display/lilliput#Main-Hashcode https://wiki.openjdk.org/display/lilliput#Main-Hashcode) for dealing with hashes
by moonchild 3y ago
One proposed strategy (https://wiki.openjdk.org/display/lilliput#Main-Hashcode https://wiki.openjdk.org/display/lilliput#Main-Hashcode) for dealing with hashes is to compute them lazily, taking advantage of the fact that most objects are never hashed: initially use the object's address, but also set a flag on the object when it is first hashed; when the gc next moves the object, it adds an extra field in which the original address is cached.
Another strategy, used by sbcl, is to rehash identity hash tables after each gc cycle.
How could I implement either of these with wasm?
- derefr 3y ago> when the gc next moves the object, it adds an extra field in which the original address is cached. Under this scheme, if I allocate object A at address 0, then GC-move it to address 100 (such that it caches that it was "originally at" address 0); and then, with object A still alive, I allocate object B at address 0... then don't objects A and B both now have 0 as their identity hashcode? (I'm guessing the answer here is "this only works with generational GC, and the GC generation sequence-number is an implicit part of the stateless-address hashcodes and an explicit part of the cached-in-member hashcodes")
- kaba0 3y agoMoving GCs usually copy the object to a new region, and redirect accesses to the old one to the new region. These regions are often used as generations, but they could just be two halves of the heap that flip between active and inactive state.