RFR: 8152711: Create a non-template Log wrapper class

Stefan Karlsson stefan.karlsson at oracle.com
Tue Apr 5 05:31:38 UTC 2016


Hi Kim,

On 2016-04-05 02:07, Kim Barrett wrote:
>> On Apr 4, 2016, at 8:20 AM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
>>
>> Hi all,
>>
>> I've created a new patch to use LogTagSets instead of function pointers:
>>
>> http://cr.openjdk.java.net/~stefank/8152711/webrev.02.delta/
>> http://cr.openjdk.java.net/~stefank/8152711/webrev.02/
>>
>> The patch is rebased against the LogTagSet enhancements in:
>>
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-April/022368.html
>>
>> I've also updated the unit tests after feedback on earlier UL patches.
> A couple of minor comments.  I don't need a new webrev for these.
>
> Otherwise, looks good.
>
> ------------------------------------------------------------------------------
> src/share/vm/logging/logStream.inline.hpp
>    81   // LogTargt(Debug, gc) log;
>
> LogTargt => LogTarget

OK.

>
> ------------------------------------------------------------------------------
> src/share/vm/gc/shared/gcTraceTime.inline.hpp
>   137 #define INJECT_START_TAG(T1, T2, T3, T4) \
>
> This macro is injected into all including code.  I'd prefer a name
> that is tied to GCTraceTime, like GC_TRACE_TIME_INJECT_START_TAG.
> Being paranoid about macro name capture is generally a good thing.

I prefer the shorter name. I'll undef the macro after its usage instead.

I understand that leaking macros in header files that are shipped to 
third-parties, is a problem. However, this is used internally within 
HotSpot and we can easily fix any (unlikely) conflict. Or are we afraid 
that the macro name would accidentally end up in, say, jni.h? Is there 
another reason to not leak the macro names?

I was considering promoting this macro into the UL headers, and rename 
it to LOG_INJECT_TAG_START, since other places might want to use it. 
That would also leak the macro name, but to many more places.

Thanks for the review!

StefanK

>
> ------------------------------------------------------------------------------
>



More information about the hotspot-dev mailing list