How come nobody pointed to the JVM Spec?

Question

Apologize for not knowing where the "usual channels" are to unlock this thread so the hearing of technical facts can continue.
From the [JVM spec 3.6|http://java.sun.com/docs/books/jvms/second_edition/html/Overview.doc.html#17257] third paragraph:
"The sizes of the local variable array and the operand stack are *determined at compile time* and are supplied along with the code for the method associated with the frame (4.7.3). Thus the size of the frame data structure depends only on the implementation of the Java virtual machine, and the *memory for these structures can be allocated simultaneously on method invocation*." (emphasis mine)
The two principals in the locked thread both have support in the JVM spec- local variables are allocated statically at compile time but the actual physical memory for them is allocated dynamically at runtime. Am I understanding that paragraph correctly?

Answer 1

pete_d wrote:
jverd wrote:
The closest Java comes to C++'s #1 static memory allocation is String literals. The compiler stores them in the .class file, and the "address" (the reference value) of the String objects remains the same throughout program execution, as far as I know. Granted, what's in the .class file still has to get allocated on the heap when the class loads--unless it's already there--but if you view that as an implementation detail, and squint real hard, and maybe hit yourself on the head with a hammer, you could almost imagine that String constants are "statically allocated."I'm sensing that the JVM has a very different architecture than a ordinary computer and thus the problem with the regular definitions.I don't see that.
First it isn't that different. There isn't anything special about the VM. Interpreters existed before Java and have continued to exist. I am pretty sure interpreters existed at least in the 70s. Perl at least up until 6 was based on an intermediate form. You could actually save the intermediate form and run that rather than the 'normal' way of executing the perl script every time.
Second one still needs to look at what is going on in terms of something resembling standard definitions.
If one wishes to restrict oneself to the Java language itself, then regardless of the implementation details of the compiler it doesn't "allocate" anything. Because until the code runs there is no allocation.
If one wishes to include the VM specification (rather than implementation) then one can note that there is nothing specifically that indicates any static allocation either and certainly nothing that the compiler controls.
Consider a bytecode - istore, which takes an index. It stores into the position defined by the index. This is an instruction created by the compiler. The instruction itself does not suggest allocation. A direction to store is not a direction to allocate. The instruction presumes the allocation has already been done.
Consider a method call defined in the following.
        // Basic java code
        test(1);
        static int test(int i){ return i; }
        //byte codes for call
       0:   iconst_1
       1:   invokestatic    #2; //Method test:(I)V
       // byte codes for method
       public static int test(int);
       0:   iload_0
       1:   ireturnThe above represent byte codes emitted by the compiler. I see nothing that suggests allocation. Again at that point the compiler assumes that the stack frame exists.
Consider the class file structure which is generated by the compiler. From that the code_attribute defines code and it has the max_stack is nothing but a 16 int.
It is just a size. One needs the size to do the allocation but the size is not the allocation.
In terms of the above and what the compiler does it assumes that something will do correct allocations based on the data that it provides. Still isn't the same as doing the allocation.