1

This question is duplicate of Is it possible to change the priority of garbage Collector thread?

It is an old question and things might have changed a lot since then. Also it doesn't clarifies everything.

Is it possible to change GC thread priority? I have seen thread dumps with different GC thread priority. How does that happen if we cannot change it? Also, I understand that High frequency trading platforms want to keep GC thread priority very low so that main threads run most of the time and "Stop the world" event doesn't occur very often.

Community
  • 1
  • 1
de.coding.myth
  • 125
  • 1
  • 9

2 Answers2

2

Is it possible to change GC thread priority?

I really think that this is the wrong question. You don't want to affect the priority of such a critical background operation. This could, depending on the thread architecture, starve the GC thread and bring down the JVM.

I think the right way to reduce the amount of CPU that the GC system uses is to reduce your object bandwidth -- reduce the number of objects that are being created and reclaimed. You should use a memory profiler to see what parts of your system are consuming too much memory or using too many temporary objects.

There are many ways to reduce the object bandwidth:

  • changing to use mutable objects when appropriate (i.e. where the objects aren't shared between threads)
  • clearing and reusing collections as opposed to reconstructing them
  • using StringBuilder as opposed to serial String appends
  • using slf4j type {} logging
  • possibly using ThreadLocal to store state objects that can be reset and reused
  • etc..

There are many ways to reduce the object bandwidth of your code and that ultimately will have much more impact on the memory performance of the JVM as opposed to playing with the thread priorities of the background system threads.

See @Voo's comment below for a good caveat to this however.

Gray
  • 115,027
  • 24
  • 293
  • 354
  • 2
    Better be *very* careful when "optimizing" in this area though. One example: Short-lived small objects are what the GC is tuned to work with, so introducing object pools to reuse objects can often lead to worse performance (especially latency) down the roads on modern JVMs. Young gen GCs are really cheap! – Voo Jan 18 '14 at 17:32
  • Somewhat agreed @Voo. I'm not sure using object pools ever leads to worse performance (unless it's implemented poorly or requires synchronization locks or something) but it certain can mean much more code with no performance improvement. – Gray Jan 18 '14 at 17:34
  • Thanks. In that case, the reason we have different priorities for GC threads in thread dump is because JVM decided to put different priorities for different applications? – de.coding.myth Jan 19 '14 at 04:42
  • I don't know @user2748525. Where are you seeing different GC thread priorities? If true then the JVM implementation did that for a reason. Again, fooling with the priorities without fulling understanding the reasoning and the ramifications is not recommended. – Gray Jan 19 '14 at 15:52
  • @Gray Depends on how you define "performance". Whether it leads to worse throughput may be argued, but what it can easily do is lead to worse latency. All the objects in the pool will end up in the oldest generation sooner or later which then leads to an unusally large old gen and that influences the time for the full GC. Also we don't profit from doing minor GCs in parallel in this case. – Voo Jan 19 '14 at 17:59
  • @Gray, I see different thread priorities at the end of thread dump. – de.coding.myth Jan 19 '14 at 18:07
1

Short answer : thread priorities cannot be used to avoid GC interference with the application threads.

Long answer:

The Java thread priorities are not respected by the JVM and the underlying OS. This is a well known problem which was addressed e.g. by RTSJ.

Java thread priority requirements are:

  • specially designed VM that supports Java priorities, and
  • a real-time OS.

Without both of these, the thread priorities will be used only as a hint and there are no guarantees that a higher priority thread will not be preempted by a lower priority thread.

GC threads priorities are set by the VM when creating the GC threads and cannot be modified from the user space.

Finally, the key techniques for high frequency trading or avoiding the GC stop-the-world pauses in general are a careful GC tuning and selecting a proper GC algorithm - both of these can be done in a comodity VM (e.g. HotspotVM).

Aleš
  • 8,896
  • 8
  • 62
  • 107