Description
#95959 is cleaning up code and working towards all JS object handles having an associated 'proxy context' that represents the thread they belong to. This is a good approach, but it occurred to me that we should probably also encode the thread affinity into the JSHandle itself, if only to make debugging much easier.
In the current model we have two handle spaces, where some handles are negative numbers and some handles are positive numbers. The meaning of these handles depends on the current thread, since each JS thread has its own JS state and as a result values for each possible handle. i.e. the handles -7 and 4 can point to different objects depending on the current thread.
On the managed side if you have a ProxyContext and numeric handle pair, you can figure out how to get to the correct thread in order to touch the object you care about. But if code incorrectly flows contexts around or something otherwise goes wrong, when you're in the JS debugger you may only have the JSHandle in front of you, or otherwise be unable to examine the managed state. That will make it unclear whether you're dealing with a thread confusion issue (right handle, wrong thread), a double free (this was the right handle once, but it isn't anymore) or memory corruption (this is just not a valid handle).
My thinking is that all JSHandles should probably have a new representation, either 32-bit IDs with the shape 0xMMNNNNNN where MM is the tid, or 53-bit IDs where the first 32 bits are the handle and the upper 21 bits are the tid. We could validate the tid explicitly in debug builds, and in release builds for performance we could ignore it while still getting the benefit of having it there in failure cases.
cc @pavelsavara