#How are variables implemented?

13 messages · Page 1 of 1 (latest)

long path
#

I get the part about variables where they can contain a primitive value, or where they can reference an object on the heap, but I would like to know how variables are implemented -- what, exactly, is put on the stack when I declare and initiatie a variable? Is it like a vector segment of memory, storing the variable name, the type of the variable and then the actual value or reference? Is there any other information that gets stored?

I realize this might be too much to type an answer to, but I'd be grateful for links or book references that I can check out, too!

edgy patioBOT
#

Hey, @long path!
Please remember to /close this post once your question has been answered!

pine timber
#

Variable names don't exist after compilation. That's one of the reasons why decompilation isn't a great process: variable names are lost.

#

Variable types aren't exactly put on the stack, only the variable contents. It's just the code puts it on stack by using the right type, and gets it from stack using the right type too. Object types are lost however, we only know they're objects (and the value stored is a reference to the object)

#

Of course, objects know their own classes. Just not what variables may point to them.

long path
# long path I get the part about variables where they can contain a primitive value, or wher...

Your Java code gets turned into Java bytecode before being run. Java bytecode specifies the number of max local variables that particular method will use, and the JVM implementation is responsible for keeping track of those variables. Since methods are JIT compiled to native code, it will be implementation-dependent how those actual local variables are stored. I've never looked into how JITs are implemented, but if I were designing a JIT, I'd probably have some methods just use CPU registers if possible, and then overflow into stack space if necessary, or possibly malloc system memory in some cases? (CPUs generally have a concept of a stack pointer, and therefore a built in concept of an active stack)

long path
long path
small seal
pine timber
long path
# long path Thanks! But if an object doesn't know what points to it, how does it get garbage...

Any object that is not "reachable" is subject to garbage collection. "Reachable" means there is an active reference to the object in some place that can be possibly reached by an active Thread (hit pause in the debugger or use the "jstack" utility and you will see a list of active threads); e.g. an object stored directly in a static variable/an object referenced in a field of another reachable object/an object referenced in a local variable of a method on the stack of a living Thread, etc. In particular, reference counting is NOT used, as this would cause circular references to cause memory leaks, such as in Objective C. This is not a problem in Java, because reachability is used instead, which is a bit of a blessing and a curse, because it's a lot more labor intensive than simple reference counting, but it works really well at this point as they've improved the garbage collectors over the years.

long path
#

Thank you all very much for these answers -- I think I have a solid grip on it now!