4

How does Java associate a variable name with a location in memory?

My first thought about this is there must be a static table that is used for all variable names which associates it with either it's value or a location to it's value. Does it exist and is there a formal name for this table?

Jherico
  • 28,584
  • 8
  • 61
  • 87
Dan Webster
  • 1,185
  • 1
  • 12
  • 27
  • 1
    Maybe that will help: http://www.programmerinterview.com/index.php/java-questions/difference-between-a-primitive-type-and-a-class-type/ – javadeveloper May 13 '13 at 17:54
  • 6
    Unless you are implementing a JVM yourself you should not need to ever assign or keep track of a variable's exact memory location. – DuncanACoulter May 13 '13 at 17:54
  • The variable name would have to be qualified in some way, as you can have variables with the same name not only across different classes, but also in the same class or method but in different scopes. – asteri May 13 '13 at 17:59
  • 3
    It probably doesn't; my guess (based on looking at some bytecode) is that variable names are only relevant for the compiler. – Mark Rotteveel May 13 '13 at 18:06
  • possible duplicate of [How is reference to java object is implemented?](http://stackoverflow.com/questions/1574009/how-is-reference-to-java-object-is-implemented) – Yishai May 13 '13 at 18:07
  • 3
    When your program gets compiled, essentially all of the variable names (certainly within method implementations) are removed; your program is rewritten in bytecode which only refers to variables by their position on the stack. – Louis Wasserman May 13 '13 at 19:42

2 Answers2

5

The value of variable of primitive type is some number and value of variable of reference type is a reference (usually an memory address).

Now the question is: where is stored value of given variable. It depends on the the kind of variable - there are local variables, instance variables (fields) and class variables (static fields).

Names of locals are resolved during compilation. Each variable becomes simply i-th variable in method and it will be stored as i-th variable in stack frame of some method call.

For instance variables it will be different. Field names are always present in bytecode (but will generally not be present in machine code generated by JIT compiler). All objects of given class have the same layout, so class can store offset of given field - distance from beginning of the object. Interpreter can read the address of object and add offset to calculate where is variable stored.

Class variables are similar to instance variables, but simpler. In this case, class stores both names and values of its variables.

zch
  • 14,931
  • 2
  • 41
  • 49
  • you seem to have focused on where the actual objects are stored. But what about how the connection between the variable and object happens? There has to be somewhere in memory where the variable holds data about where it's object or primitive is. – Dan Webster May 14 '13 at 00:01
  • 2
    Field & local-variable names are resolved to table offsets during compilation. At runtime, variables are owned by their containing stackframe/ instance/ class (for statics) but have no link back to it -- they don't need to. There is no such thing as a variable accessed outside of it's stackframe/ instance/ etc container. – Thomas W May 14 '13 at 00:29
0

Historically compilation includes the creation of a Symbol Table which associates variable names with their attributes determined from the source code. This is a little simplistic for purposes of illustration, but the principles have not changed since FORTRAN was useful. User-defined types in languages such as C++ and Java form part of each compilation unit's meta-data that is collected during compilation and knitted together when a run-time executable is created or loaded into memory.

Note that all of the types must be defined before they may be used to define objects of a type. This is the purpose of 'import' in Java and '#include' in C/C++. The meta-data includes definitions of methods and object (or class) data elements and is used to determine the size of objects for creation in static memory, on the stack (block entry/exit) or the heap (dynamic allocation).

Type-checking at compile time or during execution is one of the most significant developments in the last forty years and is a major reason that we are able to use autonomous robots on Mars, on California highways or on the Internet. At it's core, the central problem of programming language compilation or translation is tracking everything known about objects and placing it in memory where it can be used properly at run-time.

Ancient languages like FORTRAN and COBOL had one type of variable (static) that would have only fundamental data type attributes. They had almost trivial symbol tables. The most complex issue was linking compilation units together for execution. We've come a long way Baby!

  • The question is about Java and memory management, i.e. runtime, and there is nothing here that actually answers it. Instead all this is about 90% irrelevant, including the bizarre assertion that the 'central problem of ... compilation is tracking everything know about objects'. That's the easy part. Parsing and code generation are the central problems. – user207421 May 14 '13 at 00:51
  • The question said nothing about memory management. It indicated very little understanding of Computer Science and I threw out a bunch of keywords in the hope that you might look around and learn something. –  May 14 '13 at 01:03
  • The question said nothing about memory management. I threw out a bunch of keywords in the hope that you might look around and learn something. There are three general types of data memory used in programs of all types: static memory uses a single unit of storage for each variable. The size is determined by variable type. High level languages also provide local variables within textual blocks of statements. Advanced techniques employ dynamic memory assignment - information is stored in a memory 'pool' called the 'heap'. Name assignments to storage depend on which of these is being used. –  May 14 '13 at 01:10
  • You can't generate code to manipulate something you can't define. Parsing was solved in the 1970's with LALR(1) etc. –  May 14 '13 at 01:11