4

I am running multiple runs of the same scenario on a Java product with same JVM arguments. Every run gives a different GC behavior both in terms of its duration and its 'start time'. Is this expected?

Aleš
  • 8,896
  • 8
  • 62
  • 107
Rahul
  • 51
  • 2
  • 6
    Yes, it is. Java GC is not deterministic. – Matthias Meid May 17 '13 at 11:42
  • At the very least, Java's JIT / VM use heuristics for optimisations. Also, your program isn't the only one running on the computer, so you can't really meaningfully compare the timing between single runs at all. – millimoose May 17 '13 at 11:48
  • There is a lot of "magic" going on when and what the GC will process. The GC depends on too many factors to be analyzed just by watching what is happening from the outside (heuristics, load, ...). – Ortwin Angermeier May 17 '13 at 11:50
  • Why the close votes? The question is pretty clear (as the answer). Which debate is expected? – Matteo May 17 '13 at 12:00
  • Without detailing which JVM you are using the answer can only be generic. – assylias May 17 '13 at 22:53
  • Yes, it is deterministic in the sense, that it doesn't use random numbers. But the actual details of the GC depends heavily on circumstances which we can see practically undetermined (f.e. how many cpu cycles has run your program since the last interrupt, etc) . Good quality java code can't depend on them. – peterh Dec 02 '13 at 01:08

3 Answers3

2

Are you manually running System.gc()? Becuase that's not guaranteed to actually do the garbage collection immediately (or even at all).

For automatic garbage collection, I'd assume it's the same where the JVM determines a good time to do the garbage collection.

austin
  • 5,816
  • 2
  • 32
  • 40
2

The Java VM specifications do not specify how garbage collection should be implemented. So you cannot assume any deterministic behavior.

From: The Java® Virtual Machine Specification, Java SE 7 Edition: 2.5.3. Heap

The heap is created on virtual machine start-up. Heap storage for objects is reclaimed by an automatic storage management system (known as a garbage collector); objects are never explicitly deallocated. The Java Virtual Machine assumes no particular type of automatic storage management system, and the storage management technique may be chosen according to the implementor's system requirements. The heap may be of a fixed size or may be expanded as required by the computation and may be contracted if a larger heap becomes unnecessary. The memory for the heap does not need to be contiguous.

Summarizing: yes the behavior you are observing is normal and expectable.

Matteo
  • 14,696
  • 9
  • 68
  • 106
  • The question is not so much if the specs promise determism, but whether, for a specific JVM, one could expect the GC to be deterministic. – assylias May 17 '13 at 22:53
  • 1
    @assylias Not really: the question (this question) does not even mention a specific JVM. – Matteo May 18 '13 at 06:09
1

Java Hotspot VM does not implement a deterministic GC algorithm.

In general, deterministic GC algorithms do exist for Java. For example in the following JVMs:

  • Metronome GC (IBM VM)
  • BEA JRockit
  • Azul's Pauseless Garbage Collector
  • FijiVM and its Schism: Fragmentation-Tolerant Real-Time Garbage Collection
Aleš
  • 8,896
  • 8
  • 62
  • 107
  • 1
    Note that none of them are deterministic (in a lexical scoped way). They are just more efficient than the traditional ones. – drowa Jul 16 '14 at 22:00
  • Good point there. I would not say that are more efficient, they just have smaller latencies, the actual throughput is usually lower than traditional GCs. – Aleš Jul 16 '14 at 22:07
  • Either they are deterministic or they are not. Azul's is for sure not deterministic. – devoured elysium Oct 10 '19 at 20:28