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

[Jon Masamitsu]

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



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