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