RFR: 8149383: Convert TraceBiasedLocking to Unified Logging

[Daniel D. Daugherty]

 > If Kim or John is okay with this proposal of enhancing later,
 > should it be necessary, are we all okay with moving forward
 > with this latest version?

I'm good with moving forward here.

Dan


On 2/17/16 8:40 AM, Rachel Protacio wrote:
> Thanks, David, for reiterating my earlier comment. If it's okay with 
> everyone, I think this falls again into the category of "works now, 
> can be enhanced with a future RFE". Especially since John's suggestion 
> of using LogMessage seems the most likely fix if any (and perhaps an 
> equivalent way to accomplish what Kim's code was getting at?). But 
> LogMessage framework has not yet been committed, so it would make 
> sense to upgrade this implementation, should we deem it necessary, 
> after the framework is added and after the primary task of creating a 
> working "-Xlog:biasedlocking" option has been accomplished.
>
> To reduce the confusion that some have had regarding the fact that the 
> two conditionals differ just in level and not message (for now), I've 
> added the comment
>
>     // Log at "info" level if not bulk, else "trace" level
>
> before each of the four instances. See 
> http://cr.openjdk.java.net/~rprotacio/8149383.02/
>
> I have Dan and David as reviewers. If Kim or John is okay with this 
> proposal of enhancing later, should it be necessary, are we all okay 
> with moving forward with this latest version?
>
> Many thanks,
> Rachel
>
>
> On 2/16/2016 8:25 PM, David Holmes wrote:
>> Folks,
>>
>> Rachel already covered this in her original email:
>>
>>> A comment on the code: in order to maintain the existing functionality
>>> of the "(TraceBiasedLocking && (Verbose || !is_bulk))" portions of 
>>> code,
>>> it was necessary to create two separate cases in the conversion, one
>>> each for the info (regular) and trace (verbose) levels. It has been
>>> asked that the functionality be maintained. The logging statements in
>>> these chunks do not necessarily have to stay equal to each other in the
>>> future, which this would facilitate.
>>
>> As she says the logging statements for the two cases need not stay 
>> the same, so jumping through hoops to try and print the same message 
>> under two different conditions seems like a waste of cycles to me.
>>
>> Cheers,
>> David
>>
>> On 17/02/2016 8:12 AM, John Rose wrote:
>>> On Feb 16, 2016, at 1:16 PM, Daniel D. Daugherty
>>> <daniel.daugherty at oracle.com <mailto:daniel.daugherty at oracle.com>> 
>>> wrote:
>>>>
>>>>        I really don't like the duplication, but if I remember 
>>>> correctly
>>>>        these are macros so we really can't do something like function
>>>>        pointers or some other trick here. Ouch! This duplication 
>>>> pattern
>>>>        is repeated in several places where the old logging was 
>>>> conditional
>>>>        on two different option variables and a biased locking 
>>>> operational
>>>>        state variable (is_bulk).
>>>>
>>>>        I suppose the logging framework doesn't have an API that says
>>>>        to log at different levels based on a parameter. Something 
>>>> like:
>>>
>>> I agree with Dan.  There's got to be a way to factor this code.
>>>
>>> Perhaps this is a job for LogMessage:  You compose the message,
>>> and then conditionally commit it to two places.
>>>
>>> — John
>