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

[Stefan Karlsson]

Thanks, Robbin.

StefanK

On 2016-04-04 17:17, Robbin Ehn wrote:
> Hi Stefan,
>
> This also looks better than before, thanks!
>
> /Robbin
>
> On 04/04/2016 02:20 PM, Stefan Karlsson 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.
>>
>> Thanks,
>> StefanK
>>
>> On 2016-03-30 10:18, Stefan Karlsson wrote:
>>> 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
>>>>
>>>
>>