RFR: 8152711: Create a non-template Log wrapper class
Stefan Karlsson
stefan.karlsson at oracle.com
Wed Mar 30 08:18:17 UTC 2016
On 2016-03-29 19:10, Kim Barrett wrote:
>> On Mar 29, 2016, at 9:48 AM, Stefan Karlsson <stefan.karlsson at oracle.com> wrote:
>>
>> Hi all,
>>
>> Please review this patch to introduce type-erased Log and LogTarget wrapper classes. These classes can be used where we don't want or can't use the template parameters associated with the Log and LogTarget classes.
>>
>> http://cr.openjdk.java.net/~stefank/8152711/webrev.01
>> https://bugs.openjdk.java.net/browse/JDK-8152711
>>
>> The patch is applied on top of the patch in:
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-March/022304.html
>>
>> I've received internal feedback that we probably want to reuse the LogTagSet instances. I'd prefer if that could be prototyped and implemented as a separate RFE.
> I don't think the change being proposed by this RFE should be made.
> Instead, I think the approach of using existing LogTagSet should be
> taken. Introducing the new classes here and starting to use them will
> just make it harder to to adopt the LogTagSet approach, which I feel
> is superior, and is not hard. I already provided a prototype last
> week.
I've talked to Kim about this offline.
Kim envisioned the direct usage of the LogTagSet when logging in our
code. But I see a value in having a smaller, simpler Log[Target]Handle
interface instead of exposing the rather big LogTagSet interface to the
rest of our code. I think Kim now agrees on this.
What this then boils down to is the difference of using function
pointers vs LogTagSet and LogLevels, to implement the Log[Target]Handle
wrapper classes. IMHO, that's not enough of a reason to block my patch.
We could easily have changed the Log[Target]Handle implementation to use
LogTagSets without changing code outside the UL framework. And that was
what I had asked for, both in this RFR and in offline communications.
I worked with Kim yesterday to provide a prototype to use LogTagSets
instead of function pointers:
http://cr.openjdk.java.net/~stefank/8152711/webrev.logHandleWithLogTagSetsImpl/
I'm pretty happy with this change.
The plan to get this pushed is to:
1) Kim, or someone else, will send out an RFR regarding the
infrastructural changes to LogTagSet
2) I'll update my LogStream patch to use LogTagSets
3) I'll update my LogHandle patch to use LogTagSets
So, until (1) is done, this RFR will be put on hold.
StefanK
>
>> I've changed the implementation of GCTraceTime to show how LogHandles can be used to lower the amount of template parameters used throughout the implementation.
>>
>> Test: new internal vm test, jprt
>>
>> Thanks,
>> StefanK
>
More information about the hotspot-dev
mailing list