RFR(xs): 8151993: Remove inclusion of inline.hpp in log.hpp

Robbin Ehn robbin.ehn at oracle.com
Thu Mar 17 06:44:32 UTC 2016


Hi Kim,

On 03/16/2016 05:13 PM, Kim Barrett wrote:
>> On Mar 16, 2016, at 8:33 AM, Robbin Ehn <robbin.ehn at oracle.com> wrote:
>>
>> Hi, please review this small change.
>>
>> This also change allocation methods.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151993/
>> Webrev: http://cr.openjdk.java.net/~rehn/8151993/webrev/
>>
>> Thanks!
>>
>> /Robbin
>
> ------------------------------------------------------------------------------
> src/share/vm/logging/log.hpp
> Changing this:
>   138       char* newbuf = NEW_C_HEAP_ARRAY(char, newbuf_len, mtLogging);
> to this:
>   137       char* newbuf = (char*) os::malloc(sizeof(char) * newbuf_len, mtLogging);
>
> New code is missing out of memory handling that was present in the old
> code.  New code will just try to use newbuf, with bad results if the
> allocation failed.

Yes

>
> New code is missing ASSERT-conditionalized PrintMallocFree support
> that was present in the old.  I don't know how important this is,
> given that we also have PrintMalloc.  (And I have to wonder why we
> have both PrintMalloc (develop) and PrintMallocFree (notproduct).)
>
> ------------------------------------------------------------------------------
>

I wonder if this is even is the right path, we have 25 hpp including 
allocation.inline.
The other ones seem to do their allocation from their inline.hpp file.

Making me believe that we should either ignore this or do log.inline.hpp.

Either way this patch should be dropped, thoughts?

Thanks for having a look Kim!

/Robbin


More information about the serviceability-dev mailing list