Browse Prior Art Database

Method to schedule workload based on JVM garbage collection activity Disclosure Number: IPCOM000141083D
Original Publication Date: 2006-Sep-30
Included in the Prior Art Database: 2006-Sep-30
Document File: 8 page(s) / 238K

Publishing Venue




This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 24% of the total text.

Page 1 of 8

Method to schedule workload based on JVM garbage collection activity

1. Background: What is the problem solved by your invention? Describe known solutions to this problem (if any). What are the drawbacks of such known solutions, or why is an additional solution required? Cite any relevant technical documents or references.

1.1 What is the problem?

The problem is that in Java-based web servers, JVM Garbage Collection ("GC") produces a great challenge for request scheduling.

Figure 1 shows a brief scheduling mechanism of classical web servers.

Figure 1: Brief scheduling mechanism of a web server.

A web receives clients' requests from the network and then uses a scheduler to schedule them, choosing appropriate ones to be executed by the backup threads continuously. Threads are in charge of executing requests assigned from the scheduler and, when finished, sending responses back to the clients. Commonly, the server maintains a thread pool that has an upper limit of the thread number. By this manner, a number of requests can be executed simultaneously on the server.

However, for a Java-based web server, GC activity imposes a great challenge upon the above mechanism. This is because that when GC starts, all the application threads would be halted until the GC work is over. That is to say, those requests received just before GC starts will be postponed for a period. Commonly this period takes tens to thousands of milliseconds, depending on the workload pattern and the memory size allocated to JVM. Figure 2 shows an illustration of this phenomenon.


[This page contains 1 picture or other non-text object]

Page 2 of 8

Figure 2: All the application threads halts when GC is running.

The reason that this phenomenon is harmful to a web server is that for most commercial services requests have their QoS (Quality of Service) requirement, which prescribes an upper bound of response time for each request (commonly a value less than 300 milliseconds). As a result, the delay of the request execution generated by the GC activity will make a lot of requests not able to meet their response time requirements. Therefore, methods are needed to reduce the amount of requests that cannot meet their response time requirements due to the GC activity.

1.2 Related work

Few existing solutions are focused on this problem. Two related works that consider the influence of JVM GC upon server running are GC prediction and real-time JVM. Nevertheless, both of them are orthogonal to the problem described above.

GC prediction attempts to predict when GC starts and how long it takes, according to history logs, memory utilization measurements, code analyzing, or other information.

Real-time JVM attempts to limit the consumed time of GC activity (for each time) with a determined upper bound.

The reason that these two works are orthogonal to the problem in...