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

[Carsten Varming]

Dear Robbin,

It would be much nicer if the code was changed to call a new method in a
cpp file (this is clearly a slow path) and the new method could use a
bufferedStream to automatically expand the needed buffer. You would need to
implement vprint on bufferedStream to make is expand when needed, but that
should be doable.

Carsten

On Wed, Mar 16, 2016 at 12:13 PM, Kim Barrett <kim.barrett at oracle.com>
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.
>
> 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).)
>
>
> ------------------------------------------------------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20160316/297e2e20/attachment.html>