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

[Derek White]

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.

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().

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