RFR(xs): 8149405: OOM Error running java/lang/invoke/MethodHandlesTest.java on windows-x86 (original) (raw)

Jon Masamitsu jon.masamitsu at oracle.com
Wed Mar 23 20:10:11 UTC 2016

On 03/23/2016 11:59 AM, Derek White wrote:

Hi Jon,

On 3/23/16 2:12 PM, Jon Masamitsu wrote: Derek,

http://cr.openjdk.java.net/~drwhite/8149405/webrev.01/src/share/vm/oops/methodData.cpp.udiff.html

void MethodData::cleanmethoddata(BoolObjectClosure* isalive) { + ResourceMark rm; for (ProfileData* data = firstdata(); isvalid(data); data = nextdata(data)) { data->cleanweakklasslinks(isalive); } The cleanweakklasslinks() above has a ResourceMark in it. void DataLayout::cleanweakklasslinks(BoolObjectClosure* cl) { ResourceMark m; datain()->cleanweakklasslinks(cl); } It's not clear to me where space is being allocated in cleanmethoddata() so that the ResourceMark helps. My understanding of ResourceMarks is thin so don't assume there is anything deep about this question. Jon You're right, it isn't clear where space is being allocated without doing detective work. I didn't see any conventions w.r.t documentation, naming, type signatures, etc that would help.

Right. I don't have any ideas either. Just out of curiosity, did you try Native-Memory-Tracking with any enlightening results?

The problem is that the iterators firstdata()/nextdata() allocate also, as well as other functions called further down: parameterstypedata(), cleanextradata(), cleanextradata().

I think the change itself is correct and reasonable given the circumstances.

Reviewed.

Jon

- Derek On 03/23/2016 08:02 AM, Derek White wrote:

This is a very small fix that adds ResourceMarks to MethodData::cleanmethoddata() (and two similar functions nearby).

Basically an iteration over all classes in all methods in all classes was occurring in one ResourceMark during a full gc, so we occasionally ran out of malloc space. Once again, x86 builds running on Win64 are the "canary in the coal mine" for these kinds of temp. memory leaks, so it's a great test case even if not a very realistic one! BUG: https://bugs.openjdk.java.net/browse/JDK-8149405 WEBREV: http://cr.openjdk.java.net/~drwhite/8149405/webrev.01/ TESTS: jprt Thanks for looking, - Derek

-------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20160323/0933e670/attachment.htm>

More information about the hotspot-gc-dev mailing list