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