For reference, examination severely narrowed this patent application before it was granted.
Claim 1 as originally filed was quite broad. USPTO found quite good prior art with:
Examiner's argument against claim 1 as originally filed was that Goldin teaches all of claim 1 except requesting the at least one runtime to claim the first call stack frame, which would be obvious based on Ciernak.
Applicant denied this with an argument that stack frames in Ciernak were within a wrapper, which is indeed one way to make each runtime able to identify their own stack frames. Eventually, Examiner suggested amendments to claim 1 by adding the limitation where each runtime has a stack frame map which is used to determine if they should claim the stack frame. In other words, each runtime maintain a list of all stack frame. This makes perfectly sense, is probably obvious and/or ineffective, yet it is indeed supported by the description and not found in Ciernak.
However, we can find prior art on this very feature (and actually more of Claim 1) in:
Our argument is two-fold: (a) Alpern teaches that virtual machine maintains a list of routines and arguments (stack frames) and (b) the notion of stack frame map does refer to any additional technical feature.
Alpern describes a system with a centralized debugger for distributed virtual machines, where the code of one virtual machine may invoke code in another virtual machine, and thus we have a single stack. In some embodiments, each virtual machine maintains a list of routines and arguments on the stack:
In other examples, the debug request message is a request to execute a single step, or a request to list all loaded classes, or a request to list the routines on the stack, or a request to list the IDs of the variable objects associated with each routine on the stack.
Stack frame maps are not (technically) defined in the specification but by their usage, e.g.:
These memory addresses are recorded in a call stack frame map
Each runtime may consult its call stack frame map
They are additionally pictured and referenced as 172, 174, 176 in figure 7 (below) and as 182, 184 and 186 in figure 5B.
Applicant actually agrees that the notion of stack frame map is vague and does not refer to any specific technical feature (e.g. a hash map with a O(1) amortized access time), based on the following extract of the description:
However, it will be appreciated that those having ordinary skill in the art may devise a number of variations in runtime identification and claiming of call stack frames that utilize the techniques described herein.