4 ms·

I understand with class methods you can just jump to them, but how are class instances treated in Java? Where are they stored in a JVM? I assume the templates f

I understand with class methods you can just jump to them, but how are class instances treated in Java? Where are they stored in a JVM? I assume the templates for them are stored in the constant pool, but I'm having a hard time finding exactly what is stored and then from there, how they're instantiated. Edit: In an attempt to answer my own question, I came across this blog [0] which is helpful. 0. http://blog.jamesdbloom.com/JVMInternals.html#constant_pool http://blog.jamesdbloom.com/JVMInternals.html#constant_pool

jacobwilliamroy 9y ago
Here's an excerpt from Bruce Eckel's Thinking in Java (4th Edition), pg. 42-43 The stack This lives in the general random -access memory (RAM) area, but has direct support from the processor via its stack pointer The stack pointer is moved down to create new memory and moved up to release that memory. This is an extremely fast and efficient way to allocate st orage, second only to registers. The Java system must know, while it is creating the program, the exact lifetime of all the items that are stored on the stack. This constraint places limits on the flexibility of your programs, so while some Java storage exis ts on the stack—in particular, object references—Java objects themselves are not placed on the stack. The heap This is a general-purpose pool of me mory (also in the RAM area) where all Java objects live. The nice thing about the he ap is that, unlike the stack, the compiler doesn’t need to know how long that storag e must stay on the heap. Thus, there’s a great deal of flexibility in using storage on the heap. Whenever you need an object, you simply write the code to create it by using new, and the storage is allocated on the heap when that code is executed. Of course th ere’s a price you pay for this flexibility: It may take more time to allocate and clean up heap storage than stack storage (if you even could create objects on the stack in Java, as you can in C++). Not sure if this answers your question. I've only gotten through about 5% of the book, and I can't tell from the table of contents, if he ever goes into more detail on these explanations.

jacobwilliamroy 9y ago

Here's an excerpt from Bruce Eckel's Thinking in Java (4th Edition), pg. 42-43 The stack This lives in the general random -access memory (RAM) area, but has direct support from the processor via its stack pointer The stack pointer is moved down to create new memory and moved up to release that memory. This is an extremely fast and efficient way to allocate st orage, second only to registers. The Java system must know, while it is creating the program, the exact lifetime of all the items that are stored on the stack. This constraint places limits on the flexibility of your programs, so while some Java storage exis ts on the stack—in particular, object references—Java objects themselves are not placed on the stack. The heap This is a general-purpose pool of me mory (also in the RAM area) where all Java objects live. The nice thing about the he ap is that, unlike the stack, the compiler doesn’t need to know how long that storag e must stay on the heap. Thus, there’s a great deal of flexibility in using storage on the heap. Whenever you need an object, you simply write the code to create it by using new, and the storage is allocated on the heap when that code is executed. Of course th ere’s a price you pay for this flexibility: It may take more time to allocate and clean up heap storage than stack storage (if you even could create objects on the stack in Java, as you can in C++). Not sure if this answers your question. I've only gotten through about 5% of the book, and I can't tell from the table of contents, if he ever goes into more detail on these explanations.