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

David Holmes david.holmes at oracle.com
Thu Nov 19 09:09:18 UTC 2015

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.

Cheers, David

Kind regards, Kirk Pepperdine

More information about the hotspot-runtime-dev mailing list