RFR: 8179040: Avoid Ticks::now calls when EventClassLoad is not enabled
david.holmes at oracle.com
Tue May 9 21:25:38 UTC 2017
On 10/05/2017 4:06 AM, Claes Redestad wrote:
> Hi David,
> On 2017-04-25 22:58, David Holmes wrote:
>> Hi Claes,
>> On 25/04/2017 11:21 PM, Claes Redestad wrote:
>>> this patch removes calling Ticks::now when EventClassLoad isn't enabled,
>>> which has an effect on class loading performance:
>>> When tracing isn't enabled trace/tracing.hpp has dummy
>>> implementations which are easily optimized away by a compiler, which
>>> I've verified happens on linux OpenJDK builds with tracing disabled.
>> What you have done achieves your goal and could be pushed as-is.
>> That said, I would consider revisiting the conditional versus
>> unconditional use of trace-related code in general. So that things like:
>> 649 EventClassLoad class_load_start_event;
>> 895 post_class_load_event(&class_load_start_event, k, loader_data);
>> were done using TRACE_ONLY, so that all trace-related code was
>> completely excluded when not using INCLUDE_TRACE.
> Is your concern here that some compilers won't be smart enough to
> completely remove these allocations and calls
> from the generated code?
Just a code cleanliness issue. But at the time I wrote the above I
hadn't realized that TRACE_ONLY macros only exist in the closed sources.
Markus is/was looking more generally at this issue so any cleanup can be
left for that work.
>  Evidently there might always be some minute trace somewhere, e.g.,
> gcc seems to compile and leave unused methods around
> in the compiled binary, so if there's a footprint concern when building
> minimal VMs then it seems methods should be completely
> enveloped in INCLUDE_TRACE and all inline code be wrapped in TRACE_ONLY,
> aesthetic concerns notwithstanding.
>>> On builds with tracing enabled then the changes means the call to
>>> get the time only happen if the event is enabled, which achieves the
>>> sought after startup optimization. >
More information about the hotspot-runtime-dev