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