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

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