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

[Jon Masamitsu]

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?


>
> 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

>
>  - 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/0933e670/attachment.htm>