Dealing with Nested Scopes at Run-time

Dealing with Nested Scopes at Run-time

• Suppose we are compiling a program with static nesting like that shown in Figure *. As discussed in a previous lecture, we can represent the static nesting of scopes using a tree diagram like that shown in Figure *.

  public class NestingExample {   
  
  
      int x; int y;  
  
  
          class One {   
  
  
            Two y;  int z;
  
  
            
  
  
            class In1 {
  
  
                One y;
  
  
              }
  
  
              
  
  
            void m1() { int y;  y = 1;  x = y;  }
  
  
          }
  
  
          
  
  
       class Two {
  
  
          Three x;
  
  
          void m2()  x.m3();  
  
  
          }
  
  
          
  
  
        class Three {
  
  
            Two x; One y;
  
  
            
  
  
            class In3 extends One {
  
  
                void mIn3() {
  
  
                    x.m2();
  
  
                    m1();  
  
  
                }
  
  
            }
  
  
              
  
  
            void m3() { /* ... */ }
  
  
          }    
  
  
  }
  

  A class definition skeleton illustrating nested declarations
   

  

  Tree of scopes corresponding to Figure *
   
• Now, consider the dynamic behavior of such a program. In particular, suppose that while it is running the program constructs one object of each of the classes declared, and then constructs an additional object of class Three and an additional object of class In3.
• When executing the code of mIn3, the variable y is referenced. This is a reference to the y declared in Three. There are, however, two allocated objects of class Three (and, of course, there could be hundreds). How do we determine at run-time which copy of Three to use?
• Rather than really answer this question, we will simply provide a mechanism to solve it. Just as the tree in Figure * can represent the static structure, a tree like that shown in Figure * could be used to represent the dynamic nesting. That is, for each object of a class like In3, we could store a pointer to the object of class Three that should be used when a non-local reference to a variable like x is encountered.
• We will assume in our compiler that every object in the heap will contain such a pointer to the correct object of any surrounding class. We will call these pointers static links. Each static link must be stored at a fixed, known location within its object. Therefore, we will store it before all the variables (before or after the dispatch table pointer).
• Given such static links, we can follow a path to access any variable accessible from the current object, as long as we have a pointer for the current object! We will assume that such a pointer is stored in a register. In fact, to ensure that we can efficiently represent local variables and the instance variables of the active object we will assume that one register holds a pointer to the current method frame and another to the current object.
• We won't worry about how the static links gets set for now. We will just assume they are there when considering how to generate code for references to non-local variables.
• We will have to consider how to set these pointers when implementing the new operation.

  

  Tree of run-time objects corresponding to Figure *
   

Dealing with Nested Scopes at Run-time