RFR: 8153659: Create a CHeap backed LogStream class

Stefan Karlsson stefan.karlsson at oracle.com
Mon Apr 11 09:23:44 UTC 2016


Thanks, Marcus.

StefanK

On 2016-04-11 11:24, Marcus Larsson wrote:
> Hi Stefan,
>
> On 04/11/2016 11:19 AM, Stefan Karlsson wrote:
>> 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.
>
> webrev.02 looks good to me as well.
>
> Thanks,
> Marcus
>
>>
>> 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
>>>>
>>>
>>
>



More information about the hotspot-dev mailing list