Does jmap force garbage collection when the live option is used?

Question

I've been experimenting with jmap -histo and jmap -dump today

When run in this sequence

jmap -dump:format=b,file=heap.1 [pid]
jmap -dump:live,format=b,file=heap.2 [pid]
jmap -dump:format=b,file=heap.3 [pid]

heap.3 resembles heap.2 more than heap.1. In particular, the "dead" objects that I'm interested in in heap.1 are absent from heap.3.

Seeing this, I started looking for documentation that would tell me what I should expect. The closest I managed to get was this discussion, where the comments from briand and alanb imply that in practice I can expect this GC to occur when I use the live option; but the answers are five years old, and posts to a forum seem a bit informal for a specification.

Where can I find the current behavior documented?

Solution

In order to determine liveness, Java has to run full GC, so yes, it does.

---

To put the question to sleep... here is the answer, if anyone needs to dig deeper. Feel free.

part of /hotspot/agent/src/share/vm/services/attachListener.cpp taken from

openjdk http://download.java.net/openjdk/jdk7/ and you must accept http://www.gnu.org/licenses/gpl-2.0.html

// Implementation of "inspectheap" command
//
// Input arguments :-
//   arg0: "-live" or "-all"
static jint heap_inspection(AttachOperation* op, outputStream* out) {
  bool live_objects_only = true;   // default is true to retain the behavior before this change is made
  const char* arg0 = op->arg(0);
  if (arg0 != NULL && (strlen(arg0) > 0)) {
    if (strcmp(arg0, "-all") != 0 && strcmp(arg0, "-live") != 0) {
      out->print_cr("Invalid argument to inspectheap operation: %s", arg0);
      return JNI_ERR;
    }
    live_objects_only = strcmp(arg0, "-live") == 0;
  }
  VM_GC_HeapInspection heapop(out, live_objects_only /* request full gc */, true /* need_prologue */);
  VMThread::execute(&heapop);
  return JNI_OK;
}

in vmGCOperations.hpp it's the definition

`VM_GC_HeapInspection(outputStream* out, bool request_full_gc,
                   bool need_prologue) :`

Comments

[Hanno Fietz]

I couldn't find sources quickly, do you have any?

[bestsss]

i can look in the source itself, but the only way java to determine liveness is running full GC.

[Hanno Fietz]

Edited that into the answer itself.

[Voo]

The way that java does a young GC is "simple": We have a remembered set containing all pointers of old objects pointing into the young GC (and have some mechanism to catch changes to old objects). This means that if you run only a young GC you just assume that every object in the remembered set is still alive. Ergo you don't destroy a young object even if the only pointer to it is from a dead old object. For that reason alone you need a full GC even if you were only interested in liveness of the young heap.

[VoiceOfUnreason]

Makes sense. Is the only documentation of this the source? If so, edit the answer and I'll tie this off.

[David Lantos]

"Similar to the -histo option, the live suboption is optional and specifies that only live objects should be dumped." from java.sun.com/developer/technicalArticles/J2SE/monitoring ; agreed, this is not directly telling us GC runs, but as mentioned before, it's possibly the only (and most convenient) way.

[bestsss]

@Hanno, any idea why I get the bounty on community wiki... also since you gave it I feel obliged to drop the source as well.

[Hanno Fietz]

@bestsss - No idea, doesn't matter. The answer is probably fine, but if you have source, go ahead.

[bestsss]

@HannoFietz, ok, i got you the source.

[bestsss]

@VoiceOfUnreason, source if you need reassurance.

[Will Hartung]

Also, if you run verbose GC logging, and run a jmap against the app, you'll see it trigger a Full GC in the log.

[bestsss]

@Will, the easiest way is monitoring the survivors (heap pool), it's very well noticeable. i was perfectly sure about the GC anyways.

[GargantuChet]

Really minor correction -- accepting the GPL isn't necessary. "You are not required to accept this License, since you have not signed it." But if you don't accept it, you're still bound by copyright law.