RFR(XS): 8152119: Event-based tracing to allow for tracing Klass definition
Markus Gronlund
markus.gronlund at oracle.com
Fri Mar 18 09:33:13 UTC 2016
Hi David,
Thanks for noticing, of course it should go outside the INCLUDE_TRACE macro. I should have checked this better - cheers.
Both tracing.hpp and traceMacro.hpp can be unconditionally included, but I think I will just move out the traceMacros.hpp.
Agree it will look a bit strange, but maybe not so much if it is moved outside of all the extra #defines:
...
#include "services/threadService.hpp"
#include "trace/traceMacros.hpp" <<--------
#include "utilities/macros.hpp"
#include "utilities/ticks.hpp"
#if INCLUDE_CDS
#include "classfile/sharedClassUtil.hpp"
#include "classfile/systemDictionaryShared.hpp"
#endif
#if INCLUDE_JVMCI
#include "jvmci/jvmciRuntime.hpp"
#endif
#if INCLUDE_TRACE
#include "trace/tracing.hpp"
#endif
Thanks again
Markus
-----Original Message-----
From: David Holmes
Sent: den 18 mars 2016 01:10
To: Markus Gronlund; serviceability-dev at openjdk.java.net
Subject: Re: RFR(XS): 8152119: Event-based tracing to allow for tracing Klass definition
Hi Markus,
On 18/03/2016 4:43 AM, Markus Gronlund wrote:
> Greetings,
>
> Kindly asking for reviews for the following change to allow for
> tracing Klass definitions.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8152119
>
> Webrev: http://cr.openjdk.java.net/~mgronlun/8152119/webrev01/
You either need to change this:
77 #if INCLUDE_TRACE
78 #include "trace/tracing.hpp"
79 #include "trace/traceMacros.hpp"
80 #endif
to include outside the INCLUDE_TRACE guard, or else this:
1501 TRACE_KLASS_DEFINITION(k, THREAD);
needs to be inside an INCLUDE_TRACE guard.
Based on existing code it should be the former, though I realize this will look strange:
#if INCLUDE_TRACE
#include "trace/tracing.hpp"
#endif
#include "trace/traceMacros.hpp"
Thanks,
David
> This change complements the change associated with Klass creation
> which is already integrated:
>
> https://bugs.openjdk.java.net/browse/JDK-8147442
>
> Thanks
>
> Markus
>
More information about the serviceability-dev
mailing list