RFR(s): 8224193: stringStream should not use Resouce Area

[Thomas Stüfe]

Hi Goetz,

thanks for the review. Remarks inline.

On Mon, May 20, 2019 at 4:56 PM Lindenmaier, Goetz <
goetz.lindenmaier at sap.com> wrote:

> Hi Thomas,
>
> this looks good and it would be great to get rid of the
> limitation to nested ResourceMarks.
>
> But I see two advantages of the resource allocation we
> lose with your change:
>   * Cache locality. Repeated allocations will all use the same
>     memory in the arena keeping cache misses (even cold misses)
>     minimal.

  * The resource area is designed to have very low overhead of
>      the memory management.
>
> What do you think?
>
>
I think the existing design is fundamentally broken and discussing the
theoretical performance benefits of a broken design is useless :)

See bug report. Both points I made are total deal breakers. Do you see any
way around them while still using RA?

... I like the optimization of as_String() you propose in the other
> change :)
>

Thank you.


>
> Best regards,
>   Goetz.
>

Thanks, Thomas


>
> > -----Original Message-----
> > From: hotspot-runtime-dev <hotspot-runtime-dev-bounces at openjdk.java.net>
> > On Behalf Of Thomas Stüfe
> > Sent: Montag, 20. Mai 2019 15:25
> > To: Hotspot dev runtime <hotspot-runtime-dev at openjdk.java.net>
> > Subject: RFR(s): 8224193: stringStream should not use Resouce Area
> >
> > Hi all,
> >
> > may I please have reviews for the following bug fix:
> >
> > issue: https://bugs.openjdk.java.net/browse/JDK-8224193
> > cr:
> >
> http://cr.openjdk.java.net/~stuefe/webrevs/8224193-stringstream-shall-not-
> > use-resource-array/webrev.00/webrev/
> >
> > In short, stringStream uses resource area which is a poor choice -
> > depending on the logging we do, this may crash or assert and if it does
> not
> > it at least wastes memory.
> >
> > Note that I kept the change as simple as possible. There are other
> possible
> > improvements beside pure code cleanup, for which I opened follow up
> issues
> > https://bugs.openjdk.java.net/browse/JDK-8224212 and
> > https://bugs.openjdk.java.net/browse/JDK-8224213.
> >
> > Thanks, Thomas
>