RFR: JDK-8143255: Remove debug logging from SymbolTable::unlink() and SymbolTable::possibly_parallel_unlink()
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