Four ways objects enter the old age

  • After minor GC, survivor space cannot hold all surviving objects
  • The age threshold of a viable object has been reached. Procedure Such as 15
  • The big object
  • Dynamic age judgment

The big object

First, a quick review.

Books, too, don’t say how big an object is, it’s abstract.

Let’s be more specific here:

-XX:PretenureSizeThreshold=3m

An object larger than 3m is a large object.

JVM configuration Parameters

-XX:NewSize=10m -XX:MaxNewSize=10m -XX:InitialHeapSize=20m -XX:MaxHeapSize=20m -XX:SurvivorRatio=8 -XX:PretenureSizeThreshold=3m -XX:MaxTenuringThreshold=15 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:bigobject.log
Copy the code

Code:

byte[] array1 = new byte[2*_1MB];

byte[] array2 = new byte[3*_1MB];

Because the object 2m is not a large object, it is allocated to the Eden area. The objects of 3M are large and therefore allocated to the old section.

All of this is what we’re guessing based on theory.

Next, we run the code and query the log file bigObject.log

Java HotSpot(TM) 64-bit Server VM (25.261-B12) for BSD-AMD64 JRE (1.8.0_261-B12) Built on Jun 18 2020 06:38:55 by "java_re" with GCC 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5) Memory: 4k page, physical 33554432k(382392k free) /proc/meminfo: CommandLine flags: -XX:InitialHeapSize=20971520 -XX:MaxHeapSize=20971520 -XX:MaxNewSize=10485760 -XX:MaxTenuringThreshold=15 -XX:NewSize=10485760 -XX:OldPLABSize=16 -XX:PretenureSizeThreshold=3145728 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:SurvivorRatio=8 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseParNewGC Heap par new generation total 9216K, used 4849K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000) eden space 8192K, 59% used [0x00000007bec00000, 0x00000007bf0bc580, 0x00000007bf400000) from space 1024K, 0% used [0x00000007bf400000, 0x00000007bf400000, 0x00000007bf500000) to space 1024K, 0% used [0x00000007bf500000, 0x00000007bf500000, 0x00000007bf600000) concurrent mark-sweep generation total 10240K, used 3072K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000) Metaspace used 3074K, capacity 4496K, committed 4864K, reserved 1056768K class space used 337K, capacity 388K, committed 512K, reserved 1048576KCopy the code

Now, let’s analyze the logs to see if our guess is correct.

CommandLine flags: -XX:InitialHeapSize=20971520 -XX:MaxHeapSize=20971520 -XX:MaxNewSize=10485760 -XX:MaxTenuringThreshold=15 -XX:NewSize=10485760 -XX:OldPLABSize=16 -XX:PretenureSizeThreshold=3145728 -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:SurvivorRatio=8 -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+UseParNewGC Heap

These are the JVM parameters that we set ourselves, and some systems add for us. Such as: – XX: XX: + UseCompressedClassPointers – + UseCompressedOops

That’s not the point. You just need to know.

The point is this:

Heap  
 par new generation   total 9216K, used 4849K [0x00000007bec00000, 0x00000007bf600000, 0x00000007bf600000)
  eden space 8192K,  59% used [0x00000007bec00000, 0x00000007bf0bc580, 0x00000007bf400000)
  from space 1024K,   0% used [0x00000007bf400000, 0x00000007bf400000, 0x00000007bf500000)
  to   space 1024K,   0% used [0x00000007bf500000, 0x00000007bf500000, 0x00000007bf600000)
 concurrent mark-sweep generation total 10240K, used 3072K [0x00000007bf600000, 0x00000007c0000000, 0x00000007c0000000)
Copy the code

The heap after GC is collected. I want to emphasize it here.

Par New Generation total 9216K, used 4849K represents the new generation. Now the total space size is 9216K, and the used space size is 4849K.

In fact, we know that 2M objects enter Eden area, but now 4849K is obviously greater than 2048K (2M).

What does that tell us?

In addition to loading our own written objects, the JVM also loads some unknown objects. Unknown objects, which are mostly generated by the JVM itself, should be ignored for now

Back to the main question: will big objects go straight to the old days?

Let’s take a look at this log:

concurrent mark-sweep generation total 10240K, used 3072K

The total size of the old space is 10240K, 3072K has been used.

See here, in fact, I believe you can already understand. We define a large object as an object of 3m or greater. The logs also tell us that 3072K, or 3m, of the old age has been used.

So, we’ve already verified this with code: large objects go straight into the old age.