吞吐量垃圾收集

Question

I am going through Hotspot JVM garbage collection, i have a question ,

First article says

The throughput goal is measured in terms of the time spent collecting garbage and the time spent outside of garbage collection (referred to as application time).

Second one says,

Throughput is the percentage of total time not spent in garbage collection , considered over long periods of time. Throughput includes time spent in allocation (but tuning for speed of allocation is generally not needed).

Also the Second article says

throughput is inversely proportional to the amount of memory available.

I am confused whether throughput is a measure of time spent in garbage collection or not spent in garbage collection and how does it relate to the total amount of memory available.

Appreciate your help!

Answer 1

how does it relate to the total amount of memory available ==> In most cases (non-IO bound systems), as the memory available to any process increases, it's performance and hence throughput increases. In case of JVM, as size of heap increases, GC will have little work to do. Thus, throughput is inversely proportional to memory (not always. Remember this).

Next, throughput is the total time available to the non GC threads to do their tasks.

Answer 2

I think the Oracle guide referenced ("second article") unfortunately has an error in this paragraph, or is very misleading (and define throughput as something different without making this clear). You reference the Java SE 6 HotSpot gc tuning guide, but the error is also in the Java 11 version: Java SE11, HotSpot Virtual Machine Garbage Collection Tuning Guide, chapter 4, Factors Affecting Garbage Collection Performance :

Chapter 4, "Factors Affecting Garbage Collection Performance":

Total Heap The most important factor affecting garbage collection performance is total available memory. Because collections occur when generations fill up, throughput is inversely proportional to the amount of memory available.

The rest of the guide does use the term as application/system throughput , and throughput generally is one of three GC tuning goals, so I consider this to be an error. (I think the rest of the guide is good).

As far as I understand this should generally be the opposite:

Throughput is generally proportional to the amount of memory available.

(Not considering tuning specific effects, - it is possible in some cases to add memory and get less throughput.)

I choose to cite from an authority on this, Java Performance by Charlie Hunt and Binu John , which I think presents the definitions and relations between throughput , memory and latency quite clear in chapter 7 "Tuning the JVM, Step by Step" page 256-257:

Throughput Throughput is a measure of the amount of work that can be performed per unit time. A throughput requirement ignores latency or responsiveness. Usually, increased throughput comes at the expense of either an increase in latency and/or an increase in memory footprint.

An example of a performance throughput requirement is “the application shall execute 2500 transactions per second.”

Latency and Responsiveness Latency, or responsiveness, is a measure of the elapsed time between when an application receives a stimulus to do some work and that work is completed. A latency or responsiveness requirement ignores throughput. Usually, increased responsiveness or lower latency, comes at the expense of lower throughput and/or an increase in memory footprint.

An example of a latency or responsiveness requirement is “the application shall execute trade requests to completion within 60 milliseconds.”

Memory Footprint Memory footprint is a measure of the amount of memory required to run an application at a some level of throughput, some level of latency, and/or some level of availability and manageability. Memory footprint is usually expressed as either the amount of Java heap required to run the application and/or the total amount of memory required to run the application. Usually, an increase in memory footprint via an increase in Java heap size can improve throughput or reduce latency, or both. As the memory made available for an application is decreased, throughput or latency is generally sacrificed.