When the compiler creates the variable?

[hitesh_public]

Hello Friends,
This may sound a stupid question but this question crept in my mind while reading about variables in java. This may be a question about compiler in general but I am not sure.

While java compiler compiles the source code and enters the method, does it creates all the variable at once or the variable is created when the control passes to that particular statement.

[PhHein]

The compiler never creates variables, it creates bytecode.

[Norm]

I think local variables are created/storage allocated as they come into scope.
But it could depend on the version of the compiler.

What difference does it make when storage is allocated for them?

[PhHein]

But then it's down to the JIT compiler/ runtime VM, no?

[Norm]

I guess it could be. Not something I've worried about. Knowing scope handles most problems.

[JosAH]

But then it's down to the JIT compiler/ runtime VM, no?

As you already know local variables are stored on the stack and the compiler calculates how many slots are needed for a method and (generates code that) pushes the stack top so many slots when the method is started. It's quite a cheap operation ...

kind regards,

Jos

[Zack]

I know for sure that in C++ the stack is appended to when the local variable is initialized, not at the start of the function. That is,

void x() { // nothing is allocated to stack
    int a = 5; // 5 is on the stack
    int b = 8; // 8 is on the stack
} // stack is 8, 5

Because Java runs under a VM I assume it operates with similar logic. I don't believe they would run through the method once to find memory allocation data, and again to add data to the allocation.

However, I cannot find any whitepapers or documentation on the VM's behavior in this case.

[JosAH]

I know for sure that in C++ the stack is appended to when the local variable is initialized, not at the start of the function. That is,

void x() { // nothing is allocated to stack
    int a = 5; // 5 is on the stack
    int b = 8; // 8 is on the stack
} // stack is 8, 5

Because Java runs under a VM I assume it operates with similar logic. I don't believe they would run through the method once to find memory allocation data, and again to add data to the allocation.

However, I cannot find any whitepapers or documentation on the VM's behavior in this case.

Read paragraph 3.6 in this link.

kind regards,

Jos

[Zack]

Ugh... one more reason to dislike Java.

Thanks for the link though, Jos.

[JosAH]

Ugh... one more reason to dislike Java.

Thanks for the link though, Jos.

What is there to dislike? C and C++ both do the same thing: upon entry of a method/function a few slots are reserved on the stack for the local variables; on top of that the stack is used for calculations etc. When the method/function returns all the local variables are gone in one sweep.

kind regards,

Jos

[Zack]

No, C++ allocates it on an as-you-go basis. It takes up more space in the program but increases efficiency in the program's execution.

A function like this, in C++:

int x() {
	int a = 5;
	if (a <= 5)
		int b = someFunc(a);
	return b;
}

Will become something like this in ASM:

00400000 MOV EAX,5
00400002 MOV EDX,6
00400004 CMP EAX,5
00400008 JG 00400013
0040000A PUSH EAX	; This is where a spot on the stack is allocated for the *next* function.
0040000B CALL someFunc(int)
00400011 MOV EDX,EAX
00400013 MOV EAX,EDX
00400015 RETN 4		; This is where the parameters are deallocated

This is, of course, with only parameters. There are only two local variables, so registers are used instead of the stack.

Let's imagine a more complex example:

int x(int c) {
	int a = 5;
	int b = c;
	int q = a;
	int r = 17;
	if (a <= 5)
		return 0;
	int s = 18;
	return s;
}

00400000 MOV EAX,5
00400002 MOV EDX,[ESP+4]
; Now we start to run out of registers, so the compiler does some other stuff.
00400004 MOV EBP,ESP		; Save the stack pointer (ESP)
00400006 PUSH EAX		; a
00400007 PUSH EDX		; b
00400008 MOV EDX,EAX
0040000A PUSH EDX		; q
0040000B MOV EDX,17
0040000D PUSH EDX		; r
0040000E CMP [EBP-4],5
00400012 JG 00400019
00400014 MOV EAX,0
00400016 MOV ESP,EBP		; Restore stack pointer
00400018 RETN 4			; Deallocate parameters--notice how local parameters are not touched.
00400019 MOV EAX,18
0040001B MOV ESP,EBP
0040001D RETN 4

You can see now that the stack is allocated one bit at a time by PUSHing each element onto the stack. At the end, at 40001B, the stack pointer is restored. You could still technically see that the data pushed onto the stack was still there after the function, however the compiler will overlook it due to scope.

I hope this helps to illustrate the point I was getting at. I also hope you understand a bit of assembly to help you read the code examples above.

PS: Thanks for making me think; it's been a while since I did any C++ to ASM writing--by hand, anyway.

[JosAH]

; Now we start to run out of registers, so the compiler does some other stuff.
00400004 MOV EBP,ESP		; Save the stack pointer (ESP)

The moment I wanted to reply to your post I noticed that you edited your comments (see above); first it said "ignore this; it's just syntactical"; it isn't just syntactical, that's where the function frame is set up. The compiler optimizes the code by using registers for the first few local variables but uses the stack (pointed to by EBP) to store the other local variables.

Your first example was just too simple to set up a stack frame so the compiler didn't generate code for it. The way the stack frame is filled depends on the (optional) initialization of the local variables.

The single decision to be made is: should EBP point to the end of the frame (on the stack) or to the start of the frame? I think your C++ compiler makes EBP point to the start of the frame.

kind regards,

Jos

[Zack]

I don't know why I put those comments the way I did. I revised them after I posted because I realized how stupid it was to ignore those lines. They were the most important in the whole example.

The first example was just to demonstrate passing the variable to another function.

As for the second example: EBP means the base pointer, which is the base of the current stack frame. In this case, it points to the bottom (I guess you'd call that the start) of the frame, and everything atop that is allocated one-by-one to facilitate the function. I've never seen a compiler say, "MOV EBP,ESP ; ADD ESP,someValue" then place everything allocated below ESP.

Occasionally you will see a function do the ADD ESP line at the start, then SUB it at the end. This is rare though, and even in cases that it is done, you will notice that it's usually with values of 0xFF or higher.

[JosAH]

Occasionally you will see a function do the ADD ESP line at the start, then SUB it at the end. This is rare though, and even in cases that it is done, you will notice that it's usually with values of 0xFF or higher.

Ok, I think our little discussion has become moot: your C++ compiler blurs the distinction because of its register optimization of local variables. It does use a frame for its local variables pointed to by the EBP register though ...

b.t.w. what do diesel engine parts have to do with this? ;-)

kind regards,

Jos

[Zack]

@ engine parts:
He's just a spam bot. Fubarable should remove him by morning.

@ Jos:
It seems that the compiler knows which is more useful: allocating a chunk of the stack or allocating each variable individually. Either way though, the C++ method seems faster as it is determined at compile time instead of run through the VM.

Either way, we've successfully determined that the OP's question is answered--in Java, all variables are allocated at once by the virtual machine.