RFR: JDK-8143255: Remove debug logging from SymbolTable::unlink() and SymbolTable::possibly_parallel_unlink() (original) (raw)

Coleen Phillimore coleen.phillimore at oracle.com
Thu Nov 19 15:31:51 UTC 2015

On 11/19/15 4:09 AM, David Holmes wrote:

On 19/11/2015 6:56 PM, kirk.pepperdine at gmail.com wrote:

Hi,

That's my point. Not that the cycle repeats, but that it is very easy to implement this code again if it would ever be needed. The benefit of having it checked in is very little compared to the negative effect on the reading speed for all developers that have to read this code. Something to consider on a case by case basis I hope. Else, as I said, a lot of non-product logging should go. My assumption is that the non-product debug logging would be highly transient in that it would be there as long as there is a problem but would be removed once the problem was resolved. If logging is in “non-product” for a long time there might be a strong case that there is some residual value that is useful in a production environment. I can think of a few non-product flags that I wish were in the product. Often such logging is put in during feature development or when trying to track down a bug. As it is useful for testing and debugging it is left in. It isn't flagged with an expiration date to be removed at some later time. Perhaps it should be - though keeping track of active use is problematic.

Right. We have lots of code that is past it's expiration date.

Coleen

Cheers, David

Kind regards, Kirk Pepperdine

More information about the hotspot-runtime-dev mailing list