Please Review (S): CR 6782663: Data produced by PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime is not accurate

[John Coomes]

David Holmes - Sun Microsystems (David.Holmes at Sun.COM) wrote:
> John,
> 
> John Coomes said the following on 07/22/09 10:57:
> > Your original webrev (webrev.00) removed the print statements in
> > vmThread.cpp.  Based upon David Holmes' comments (I believe) this
> > version restores them, which keeps the existing (buggy) behavior of
> > missing time in jdk6 when the old names are used.  I think that's
> > taking compatibility too far; we should get rid of the buggy behavior
> > completely.
> 
> The intent was to give JDK6 users a transition path to the new flags 
> which perform a different (albeit better) measurement than the current 
> flags, without simply changing the meaning of the existing flags in 
> mid-stream via a JDK6 update release.
> 
> If a customer uses these flags to track performance changes across 
> releases then changing the meaning of them under-the-covers is not a 
> user-friendly thing to do. This might seem overly conservative but it is 
> the safer option.

Hi David,

The info we are currently providing is inaccurate and misleading.
Certainly the bug submitter felt that way.  By fixing it, we can avoid
others wasting time on the problem; to do so we have to give up at
least some degree of compatibility.

> If we were only interested in fixing the bug with the current flags then 
> we'd be tracking only GC safepoint ops, and we'd keep the old flag names.

We're interested in providing sensible data; the current flags don't.
And the names are terrible.

In any approach we take, we're going to at least

	- add new options that track all safepoints
	- deprecate the old option names, and issue a warning or message
	  if they're used

The question becomes what data to produce when the old option names
are used.  You are recommending (a) leave the buggy behavior intact.
I am advocating (b) print the same data that the new options print
(data on all safepoints).  But there is also (c) change the behavior
to accurately track GC and only GC safepoints.

I still prefer (b), with (c) as a second choice.  But we have to at
the very least get rid of the buggy behavior.

-John