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

Derek White derek.white at oracle.com
Wed Mar 23 21:02:38 UTC 2016

On 3/23/16 4:10 PM, Jon Masamitsu wrote:

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?

I did try NMT. I never got it to run in a reproduced failure. And I struggled to see any real issues when I captured some logs in non-failing tests. Could it be, because this was a temporary memory spike, that NMT didn't show the "high-water mark", but the currently used memory? Neither the "arena" subsections or the "Arena Chunk" section show that much use. Here's a subset of the data:

Native Memory Tracking 

Reserved 	Committed

Total 1053487 136079 *- Java Heap * 716800 65536 mmap 716800 65536

*- Class * 7672 7416 classes 1691 malloc 120 1224 mmap 7552 7296

*- Thread * 37798 37798 thread 80 stack 35840 35840 malloc 135 451 arena 1824 159

*- Code * 248817 8529 malloc 1073 43760 mmap 247744 7456

*- GC * 30344 6152 malloc 3336 964 mmap 27008 2816

*- Compiler * 264 264 malloc 5 61 arena 260 4

*- Internal * 4736 4736 malloc 4672 2596 mmap 64 64

*- Symbol * 2187 2187 malloc 1124 6039 arena 1064 1

*- Native Memory Tracking * 547 547 malloc 97 2010 tracking overhead 450

*- Shared class space * 2 2 malloc 2 1

*- Arena Chunk * 2908 2908 malloc 2908

*- Logging * 1 1 malloc 1 96

*- Unknown * 1408 0 mmap 1408 0

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

Thanks 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/2aabd0d4/attachment.htm>

More information about the hotspot-gc-dev mailing list