[vm] Expose isolate's origin id (the id of the spawning isolate or (if no other isolate spawned it, it's own isolate id)

[mkustermann]

We should consider exposing the isolate spawn topolology in the vm-service protocol. That would allow debugging tools such as DevTools to display all isolates of an isolate group as a spawning tree (or forest, if some intermediary ones have died).

The spawner of an isolate is the originId, if there was no spawner (the isolate wasn't created via Isolate.spawn() API) then it's the isolate's own mainPort id.

One may also consider exposing on the isolate group object the isolate id of the first isolate in the group.

/cc @bkonyi

[rmacnak-google]

If we want to display which isolates are in which group, there's already enough information in the service for this (Observatory already displays it).

If we want to display the spawn tree, then the origin id doesn't capture that because the original id for every isolate in the group will be the first isolate in that group instead of the isolate that spawned it. The VM would need to start recording the parent somewhere.

[mkustermann]

If we want to display the spawn tree, then the origin id doesn't capture that because the original id for every isolate in the group will be the first isolate in that group instead of the isolate that spawned it. The VM would need to start recording the parent somewhere.

I must have misremembered this. @rmacnak-google Is there any use of the "origin id" concept (which then more or less means same isolate group)? We could then either make "origin id" to be "spawner id" or have both.

[rmacnak-google]

It's used to implement the check for a within-group message (sendport.originid == currentisolate.originid). Adding a "spawner Id" seems useful enough.

[liamappelbe]

FYI without this feature, my main isolate detection heuristic is about 1-2% flaky in coverage collection in g3. See internal bug b/411490560