RFR: 8013117: Thread-local trace_buffer has wrong type and name

[David Holmes]

On 24/04/2013 7:09 PM, Rickard Bäckman wrote:
> Nils,
>
> no it doesn't matter. Rather intended. By initializing it to NULL we forced implementors to use a pointer that would have to be initialized at some point. Now it can be a class / struct
> that is instead initialized by a default constructor.

So that addressed my question on the missing setter. But doesn't this 
also mean that you are now prohibiting it from being a simple 
pointer-type as there is no way to set it? Isn't maintaining the setter 
more flexible as it can be used in either case (direct assignment or 
copy constructor). Though lack of initialization in the current code 
still looks wrong.

David

> /R
>
> On Apr 24, 2013, at 10:45 AM, Nils Loodin wrote:
>
>> Does it matter that the pointer gets initialized to NULL before, but not now? There isn't any null checks anywhere that depends on that?
>>
>> Regards,
>> Nils
>>
>> On 04/24/2013 09:51 AM, Rickard Bäckman wrote:
>>> Hi all,
>>>
>>> can I have a couple of reviews for this small change. The short story is that the current way the thread-local _trace_buffer is somewhat inflexible.
>>> By changing the type of the getter this structure gets more flexible for different implementations. I also think that the name is misused. Just naming it
>>> to _trace_data is more generic and less implementation-specific.
>>>
>>> The webrev: http://cr.openjdk.java.net/~rbackman/8013117/
>>>
>>> Thanks
>>> /R
>>>
>>
>