RFR: 8153659: Create a CHeap backed LogStream class

Marcus Larsson marcus.larsson at oracle.com
Mon Apr 11 09:24:00 UTC 2016


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