When you invoke a process, APPX pushes a stack frame onto the process execution stack. A stack frame contains a set of objects. Important point: a process (actually an EM) contains a set of references, a stack frame contains a set of objects.

Data sharing matches each reference to the appropriate object.

When a process is invoked, APPX walks through the list of references and determines which stack frame should contain the corresponding object.

If a process has no parent (i.e. it is the first process), all objects are created in the first stack frame. If a process has a parent, we look at the sharing characteristics of the object and of the ancestor processes. If the object is shared with subprocesses, we stop traversing the stack as soon as we encounter a related or detached invocation. If the object is shared with related processes, we stop traversing the stack as soon as we find a detached invocation. If the object is shared with detached processes, we stop when we find the first stack frame.

For example:

  Process A
          |
       detached
          |
  Process B
          |
       related
          |
  Process C
          |
      subprocess
          |
  Process D
          |
      subprocess
          |
  Process E

We now process the list of references in process E's EM. If we find a reference to a private object (i.e., one that should never be shared, such as --- PROCESS TYPE), we create the object in process E's stack frame. If we find a reference to an object that should be shared with subprocesses, we look back up the stack until we find the most recently invoked related or detached process; in this case, process C. We create any subprocess-scoped objects in the stack frame for process C. If we find a reference to a related object, we look back until we find the most recently invoked detached process (in this case process B) and create related-scope objects in that stack frame. If we find a reference to an object when should be shared with detached invocations (such as --- USER ID), we create them in the first stack frame.

As we process each reference, we locate the desired object (creating it required) and point the reference to the object. That means that the references for a particular invocation can point into four different stack frames (private, subprocess, related, and detached).

Looking back at the stack frame above, consider what will happen when process E ends. All objects private to E are destroyed, but what about other objects? Any subprocess-scoped objects were created in the stack frame for process C so they are not destroyed until process C ends. There are some interesting consequences to this. First, the stack frame for any given invocation can contain objects that are not referenced by that process.

For example, if process E refers to a field named WORK TOTAL (subprocess-scoped), that object is created in C's stack frame even if process C does not refer to WORK TOTAL. Now when process E ends, WORK TOTAL is not destroyed - it lives in C's stack frame until C ends. Let's say that, after process E ends, process D invokes process F (so E and F are siblings even though E dies before F was born). If process F refers to WORK TOTAL, it will find that object in process C's stack frame - in fact, WORK TOTAL will reflect the last value assigned by process D.