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