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

[Robbin Ehn]

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
>>>
>>
>