RFR: 8028357: Unnecessary allocation in AliasFileParser

[Jaroslav Bachorik]

On 30.12.2014 17:07, Claes Redestad wrote:
> Hi Jaroslav, thanks for looking at this!
>
> On 2014-12-30 14:43, Jaroslav Bachorik wrote:
>>
>> While it's good to see the dead code gone I would prefer keeping the
>> logging code just commented out - the logging code could be useful
>> when investigating any future failures.
>
> Do you mean all of it, or just the utility methods? I'm in the habit of
> not checking in commented out code (due to potential for bit rot etc)
> and instead rely on recreating from VCS history, but I have no strong
> preference.

As a matter of fact I don't like the commented out code much either.

>
> How about leaving the non-trivial dumpAll/dump_entry_fixed-methods
> (which use the DEBUG flag but not the log/logln methods), but removing
> all log/logln calls?

The affected files are pretty stable so we could remove *all* the 
logging related methods. When a necessity arises to have a configurable 
logging we would just need to re-introduce it properly. This got me 
thinking - a comment warning about the possible performance issues when 
adding logging could be added as a courtesy to the later maintainers.

-JB-

>
>>
>> Converting to j.u.l. wouldn't probably completely remove the
>> unnecessary allocation (due to object arrays for varargs) unless you
>> guard each log call for the required logging level.
>
> Guards or simply using only single-parameter log methods in j.u.l is
> generally doable workarounds when performance matters so much that even
> the varargs allocation matters. I can only hope
> https://bugs.openjdk.java.net/browse/JDK-8013269 or similar will deal
> with removing that overhead generally, though.
>
> /Claes
>
>>
>> -JB-
>