JEP 271: Unified GC Logging - Second pre-review

[Kirk Pepperdine]

> On Nov 12, 2015, at 2:40 PM, Charlie Hunt <charlie.hunt at oracle.com> wrote:
> 
> 
>> On Nov 11, 2015, at 10:07 AM, Kirk Pepperdine <kirk.pepperdine at gmail.com> wrote:
>> 
>> Hi Charlie,
>> 
>>> 
>>> To be quite honest, my motivation for jumping in on this thread was to highlight that there are many use cases where manually looking logs are useful, i.e. GC log information shouldn’t be tailored only for tooling. It should also be easily human readable too.
>>> 
>>> In other words, both general uses are useful, needed, and should be accounted for in Bengt’s unified GC logging implementation.
>> 
>> Sure, but IME people simply don’t read them. I ask people to read them in my workshop and they still avoid doing so. That said, I’ve not been suggesting the logs be completely unreadable. I still read individual events myself. However, I am still concerned about the overall gross effects of the UL from all sources (not just GC) on JVM performance. IME, logging frequency is the #1 problem that I often run into. This gets especially bad if there is a lock involved. #2 is bulk and even worse, bulk and frequency are often combined.
> 
> I’m not surprised people don’t read them. It’s hard to get anyone to look at, or do something they feel uncomfortable with. 

Can’t explain it.. but it’s an observation….. Charlie, you were with me in Chicago with a group of smart developers. They simply didn’t naturally want to look at GC logs, the whole lot of them!!!

> 
> As for the performance, I’m confident (and comfortable) that between Bengt and the performance team that the overhead of logging is something that will be closely monitored. Areas at risk can be prototyped, measured and mitigated before committed.

My concern is that you won’t see problems that you see in prod with a synthetic benchmark running in a lab. You know yourself, h*t happen and it’s often things can you can’t possibly imagine.

Regards,
Kirk