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

[Derek White]

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::clean_method_data(BoolObjectClosure* is_alive) {
>>>> + ResourceMark rm;
>>>>     for (ProfileData* data = first_data();
>>>>          is_valid(data);
>>>>          data = next_data(data)) {
>>>>       data->clean_weak_klass_links(is_alive);
>>>>     }
>>>
>>> The clean_weak_klass_links() above has a ResourceMark in it.
>>>
>>>> void DataLayout::clean_weak_klass_links(BoolObjectClosure* cl) {
>>>>   ResourceMark m;
>>>>   data_in()->clean_weak_klass_links(cl);
>>>> }
>>>
>>> It's not clear to me where space is being allocated in 
>>> clean_method_data() 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 first_data()/next_data() allocate 
>> also, as well as other functions called further down: 
>> parameters_type_data(), clean_extra_data(), clean_extra_data().
>
> 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::clean_method_data() (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>