RFR: 8251850: Simplify ResourceMark constructors using delegation

[David Holmes]

On 18/08/2020 7:40 pm, Thomas Stüfe wrote:
> On Tue, Aug 18, 2020 at 9:52 AM Kim Barrett <kim.barrett at oracle.com 
> <mailto:kim.barrett at oracle.com>> wrote:
> 
>      > On Aug 17, 2020, at 10:44 PM, David Holmes
>     <david.holmes at oracle.com <mailto:david.holmes at oracle.com>> wrote:
>      >
>      > Hi Kim,
>      >
>      > Not a full review - sorry. Have you tested what happens if a
>     resource leak is introduced? The _warned variable was used, IIUC, to
>     avoid hitting recursive errors during error reporting.
> 
>     OH!  The recursive case hadn’t occurred to me!
> 
>     Poorly named and poorly commented variable from before the beginning
>     of the mercurial age,
>     so hard to track down the changeset that introduced it to see if
>     that shed some light.  Good
>     thing we have some institutional memory :)
> 
>     I will do something about that, and then try to figure out how to
>     trigger it.
> 
> 
> You could rig up something using -XX:ErrorHandlerTest 
> (VMError::controlled_crash) and allocate from the same ResourceArea 
> again inside the error handler. There are tests for similar things, e.g. 
> SafeFetch, see hotspot/jtreg/runtime/ErrorReporting.
> 
> But I am not sure this is worthwhile. IMHO it would be better to fix the 
> places where ResourceAreas are used in error reporting instead of muting 
> this warning for recursive calls. Because ideally we do not want 
> allocations to happen at all during error reporting.

I think that is impractical given all the information we try to print as 
part of the error report. I expect a lot of it - e.g register and memory 
contents - to require ResourceMarks (e.g. to print class names).

David
-----

> BTW at SAP we have generic tests which scan hs-err files for secondary 
> errors, but they are high maintenance.
> 
> Cheers, Thomas
>