RFR: 8251850: Simplify ResourceMark constructors using delegation

Kim Barrett kim.barrett at oracle.com
Fri Aug 21 16:26:12 UTC 2020


> On Aug 18, 2020, at 5:40 AM, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
> 
> 
> 
> On Tue, Aug 18, 2020 at 9:52 AM Kim Barrett <kim.barrett at oracle.com> wrote:
> > On Aug 17, 2020, at 10:44 PM, David Holmes <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.

Thanks for the testing hints.

I've reinstated the check for resource allocation without a ResourceMark,
though with more descriptive naming and comments.  Also dealt with the flag
being potentially concurrently accessed, because I'm paranoid.

I added a test for reporting of allocation without a ResourceMark.  I didn't
add a test for the recursion case, though I hand-tested it.

New webrevs:
full: https://cr.openjdk.java.net/~kbarrett/8251850/open.02/
incr: https://cr.openjdk.java.net/~kbarrett/8251850/open.02.inc/

Ran tier1 testing.



More information about the hotspot-runtime-dev mailing list