Java Virtual machine JVM Local Variables table combat

The Java Local Variables table is one of the important groups in the stack frame. He mainly preserves the parameters of the function and the local variable information. A variable scope in a local variable table is a function that is currently called. After the function call finishes, the function stack frames are destroyed. The local variable table is also destroyed, freeing up space.

Because the local variable table exists in the stack frame. Therefore, if the function parameters and local variables are more, the local variable table will swell, each call will occupy more stack space. The end result is that the stack space memory must be called less often.

1.1.1. local variable table variable effects

The following code shows the effect of the parameters and the size of the local variable on the number of function calls in case the stack space memory is certain. The first function recursion () does not contain any arguments and local variables , the second function recursion () contains 3 parameters and 4 Local variables, So we can also figure out that the local variable table contains the variables in the variable information. The first local variable table has a deeper call hierarchy. The code is as follows:

private static int count=0;public static void recursion (int a,int b,int c) {long l1=12;short sl=1;byte b1=1; String s= "1"; System.out.println ("count=" +count); Count++;recursion (a);} public static void recursion () {System.out.println ("count=" +count); Count++;recursion ();}

Using the JVM parameter-xss128k executes the first parameterless recursion () function above, the output is as follows:

Count=4495exception in thread "main" Java.lang.StackOverflowErrorat sun.nio.cs.UTF_8.updatePositions (utf_8.java:77)

Use the JVM parameter-xss128k to execute the second recursion () function above, the output is as follows:

Count=3865exception in thread "main" Java.lang.StackOverflowErrorat sun.nio.cs.UTF_8.updatePositions (utf_8.java:77) At Sun.nio.cs.utf_8$encoder.encodearrayloop (utf_8.java:564) at Sun.nio.cs.utf_8$encoder.encodeloop (UTF_8.java:619 )

It can be concluded that:

In the same stack capacity, functions with fewer local variables can support deeper function calls. The number of calls is also more.

How to prove that the conclusion is correct? Here we use the jclasslib tool to view local variable information for a local variable table.

The largest local variable table size that shows the recursion () function with no parameters is 0 characters. the largest local variable table size for the recursion () function with a parameter is 8 characters. Here is a description:

An int,short,byte, object reference, and so on occupies a single word. long and double are required to occupy 2 characters in local variables .

( word A word in the 4 - byte length of the computer )

Let's count recursion. method local variable table size.

Three parameters are int so it's 3 .

Long L1= 12; 2

Short SL= 1; 1

byte B1= 1; 1

String s="1"; 1

So that's 8 words altogether.

One thing to emphasize is that the local variable table here refers to a portion of the Java stack space, not to be confused with the local variable table in the Classs bytecode below.

The contents of the Local variables table in the class bytecode are shown below:

To see some information:

In the local variable table definition of the Class file, the scope of each local variable, the index information for the slot ( index column information ) is displayed.

The name of the variable ( name column ) and data type information (descriptor column )

Data type information mapping:

I---int type

D--double Type

B-byte Type

Ljava/lange/integer--integer Type

ljava/lange/string--string Type

S--short Type

The slot of a local variable in a stack frame can be reused. If a declared variable is over its scope, then the variable requested after its scope can reuse the slot of the expired local variable, thus saving resources.

1.1.2. re-use of local variable table slots

The following code shows the reuse of the local variable table slot. LOCALVAR1 ()in a function, a local variableaand thebThe range is at the end of the function, sobThere's no way to reuse it .aWhere the card slot is located. LocalVar2 () function, local variablesain the}It's not working anymore, sobIt can be reused .athe position of the card slot isinttype So yes1a word. The program looks like this:

Public void localVar1 () {

int a= 0;

System. out. println (a);

int b= 0;

}

Public void localVar2 () {

{

int a= 0;

System. out. println (a);

}

int b= 0;

}

Use the jclasslib tool to view local variable localVar1 () information for local variable tables such as:

The maximum local variable size of the function is 3 characters , and the card slot 0 bits is a thsi reference ( The first local variable of the instance method is this ), the first card slot variable is A, the second card slot variable is B, each variable is 1 words so altogether is three words.

Use the jclasslib tool to view local variable localVar2 () information for local variable tables such as:

The maximum local variable size of the function2a word, card slot0bit isthsiReferences(the first local variable of an instance method isThis ), the first card slot variable isA,a second card slot variable isB,each variable is1a word, butbthe variable is reused.acard slots So it's all2a word.

The local variable table is also an important reference point for garbage collection GC , as long as the objects referenced directly or indirectly by the local variable table are not recycled. Therefore, it is necessary to understand the local variable table to understand the GC recycling mechanism.

The following main explanations explain the effects of local variables on garbage collection.

1.1.3. effects of local variables on garbage collection

The program code looks like this:

JVM parameter -xx:+printgc parameter garbage collection before and after the heap size

JVMTESTLOCALVARGC t=new jvmtestlocalvargc ();

T. LOCALVARGC1 ();

Result output: [Full GC 3875k->3546k (15872K), 0.0050719 secs]

The GC garbage collection is called immediately after the space is applied, and it is clear that This space cannot be reclaimed because byte is referenced by a strong B.

JVMTESTLOCALVARGC t=new jvmtestlocalvargc ();

T. LOCALVARGC2 ();

Result output: [Full GC 3875k->474k (15872K), 0.0036066 secs]

Before garbage collection, B is now set to null so that the byte array picks up the reference, so a byte array after the GC is garbage collected directly.

JVMTESTLOCALVARGC t=new jvmtestlocalvargc ();

T. LOCALVARGC3 ();

Result output: [Full GC 3875k->3546k (15872K), 0.0069622 secs]

The local variable B is implemented before garbage collection, although B leaves the scope, but the variable b is stored in the local variable table. and points to a byte array, so the byte array is not recycled.

JVMTESTLOCALVARGC t=new jvmtestlocalvargc ();

T. LOCALVARGC4 ();

Result output: [Full GC 3875k->474k (15872K), 0.0037666 secs]

Before garbage collection, not only B was invalidated, C reused the word of variable B, because B was destroyed, so the byte array was destroyed.

JVMTESTLOCALVARGC t=new jvmtestlocalvargc ();

T. localvarGc5 ();

Result output: [Full GC 3875k->3546k (15872K), 0.0054367 secs]

[Full GC 3546k->474k (15936K), 0.0036164 secs]

For LOCALVARGC5 () calls the LocalvarGc1 () method, it is clear that the byte array was not reclaimed in localvarGc1 (), but after its return, his stack frame was destroyed, and all local variables in the natural stack frame were not destroyed. , the container is gone , the value of course does not exist.

So the byte array loses its drinking. was recycled in localvarGc5 ().

If you have any questions, please feel free to join our Java architect cluster number 523988350. There are many Daniel architects inside.

Java Virtual machine JVM Local Variables table combat