RFR: 8153659: Create a CHeap backed LogStream class

[Stefan Karlsson]

Hi all,

The last suggestion to move stringStreamWithResourceMark into 
ostream.hpp causes include circularities in the latest hs-rt code. I'd 
like to proceed with webrev.02 for now.

Thanks,
StefanK

On 2016-04-07 18:49, Stefan Karlsson wrote:
> Hi again,
>
> I decided to fix the resourceArea.hpp problem, so that I could move 
> the stringStreamWithResourceMark class into ostream.hpp.
>
> http://cr.openjdk.java.net/~stefank/8153659/webrev.03.delta
> http://cr.openjdk.java.net/~stefank/8153659/webrev.03
>
> The patch is applied on top of the thread.inline.hpp patch in:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-April/022511.html
>
> Thanks
> StefanK
>
> On 2016-04-07 13:30, Stefan Karlsson wrote:
>> Hi all,
>>
>> I've updated the patch:
>>  http://cr.openjdk.java.net/~stefank/8153659/webrev.02
>>
>> The previous patch created the embedded ResourceMark after the 
>> stringStream instance was created. I discussed the layout of the 
>> classes with Bengt, and have decided to restructure this patch. I've 
>> changed the code so that the ResourceMark is embedded in a new 
>> stringStreamWithResourceMark class. This allows me to use the same 
>> LogStreamBase class, but different stringClass template parameters, 
>> for all three classes.
>>
>> I've put the stringStreamWithResourceMark class in logStream.hpp 
>> instead of ostream.hpp, to prevent the include of resourceArea.hpp to 
>> propagate through the ostream.hpp header. The resourceArea.hpp file 
>> is problematic, since it includes and uses thread.inline.hpp. The 
>> alternative would be to move the implementation of resourceArea.hpp 
>> into a resource.inline.hpp file, so that header files could create 
>> ResourceMark instances, without having to include thread.inline.hpp. 
>> I'm leaving that exercise for another RFE.
>>
>> Thanks,
>> StefanK
>>
>> On 2016-04-06 19:54, Stefan Karlsson wrote:
>>> Hi all,
>>>
>>> Please review this patch to add a LogStream class that allocates its 
>>> backing buffer from CHeap memory instead of Resource memory.
>>>
>>> http://cr.openjdk.java.net/~stefank/8153659/webrev.01
>>> https://bugs.openjdk.java.net/browse/JDK-8153659
>>>
>>> The main motivation for this is that we can't use Resource allocated 
>>> memory during initialization, until Thread::current() has been 
>>> initialized. So, a CHeap backed LogStream is desirable when we 
>>> execute, for example, the following code during large pages 
>>> initialization:
>>>
>>> void os::trace_page_sizes(const char* str, const size_t* page_sizes, 
>>> int count)
>>> {
>>>   if (TracePageSizes) {
>>>     tty->print("%s: ", str);
>>>     for (int i = 0; i < count; ++i) {
>>>       tty->print(" " SIZE_FORMAT, page_sizes[i]);
>>>     }
>>>     tty->cr();
>>>   }
>>> }
>>>
>>> The patch restructures the code and creates a LogStreamBase template 
>>> base class, which takes the backing outputStream class as a template 
>>> parameter. We then have three concrete LogStream classes:
>>>
>>>  LogStream - Buffer resource allocated with an embedded ResourceMark
>>>  LogStreamNoResourceMark - Buffer resource allocated without an 
>>> embedded ResourceMark
>>>  LogStreamCHeap - Buffer CHeap allocated
>>>
>>> I moved the LogStream class from the logStream.inline.hpp file to 
>>> logStream.hpp, for consistency. If that's causing problems while 
>>> reviewing this, I can move it in a separate patch.
>>>
>>> Tested with JPRT with the TracePageSizes patch ( JDK-8152491) and 
>>> internal VM tests.
>>>
>>> Thanks,
>>> StefanK
>>
>