Essentially, what I'm proposing is that emplace should set a flag to block recursive updates to the same map or weak map, whether it be through set, delete, or emplace. This enables implementations to not have to do nearly the bookkeeping when managing updates.

• In the current form, engines may have to re-look up the hash - this is always necessary if the entry is deleted on the update callback, and engines optimizing for space may end up doing a second hash table lookup always anyways as it's just simpler and smaller to implement.*
• With this suggestion, they can just do it once and know for certain it will continue to exist at that exact position when the callback returns.
  • This also means all they need to keep around on the stack is a pointer to the target hash table entry, and all they do before returning is a single pointer-sized store. They need neither the map itself nor the hash key to store, and so it becomes a very lightweight process overall.

It also exposes potential bugs to the user - recursive updates are rarely intended, and if absolutely desired, you can just do something like this to still work around the lock and avoid it:

let deleteMarker = Symbol("deleteMarker")
// Push `[key, deleteMarker]` to trigger delete or `[key, value]` to trigger set
let queued = [[initialKey, initialValue]]

while (queued.length) {
  let [key, value] = queued.shift()
  if (value === deleteMarker) {
    map.delete(key)
  } else {
    map.emplace(key, {
      insert: () => {
        // do insert things
        return newValue
      },
      update: v => {
        // do update things
        return newValue
      },
    })
  }
}

*This is only technically the case if the hash table is represented as an array of inline key/value pairs (as in something like std::vector<HashTable>) rather than an array of pointers to entries (as in something like std::vector<std::shared_ptr<HashTable>>). For efficiency, nearly every hash table implementation in practice does the former if they want to aim for any serious performance, and of course, every engine I'm aware of also does it that way, and so yeah, it's widely enough applicable for me to say "always" here as that's in practice the case because of how everyone implements it.