[10] RFR: 8179040: Avoid Ticks::now calls when EventClassLoad is not enabled

Claes Redestad claes.redestad at oracle.com
Tue May 9 18:06:19 UTC 2017


Hi David,

On 2017-04-25 22:58, David Holmes wrote:
> Hi Claes,
>
> On 25/04/2017 11:21 PM, Claes Redestad wrote:
>> Hi,
>>
>> this patch removes calling Ticks::now when EventClassLoad isn't enabled,
>> which has an effect on class loading performance:
>>
>> http://cr.openjdk.java.net/~redestad/8179040/hotspot.01/
>>
>> 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.

Thanks!

>
> 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[1] remove these allocations and calls
from the generated code?

/Claes

[1] 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.

>
> Thanks,
> David
>
>> 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. >
>> Thanks!
>>
>> /Claes



More information about the hotspot-runtime-dev mailing list