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

[Stefan Karlsson]

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