Re: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space"

2020-06-02 Thread Daniel Fuchs

Hi David,

On 01/06/2020 23:43, David Holmes wrote:

Sorry the weekend got in the way :)


No problem David. I pushed with your suggestion (not using
SoftReference) since that appeared to be working too.

If it fails again I can revisit :-)

best regards,

-- daniel


Re: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space"

2020-06-01 Thread David Holmes

Hi Daniel,

Sorry the weekend got in the way :)

On 29/05/2020 7:01 pm, Daniel Fuchs wrote:

Hi David,

Thanks for the feedback!

On 29/05/2020 00:36, David Holmes wrote:
This seems to be assuming that the GC will clear all SoftReferences 
when it needs to clear any SoftReference. I don't think that is at all 
guaranteed. In theory your memory eating loop could be satisfied by 
clearing only the SoftReference added in the previous iteration of the 
loop.


I was wondering about that.


I would have expected the fix here to be simply to clear memory ie:

} catch (OutOfMemoryError oome) {
   stop = true;
   memory = null;
   System.gc();
}


Do you think this would be more reliable?
It was my first thought as well - and that was the
first thing I tested, and it seemed to work as well.

If you think it's a better solution I can revert to that.

My rationale for using SoftReference is that they
then could be cleared any time by the GC, and
possibly avoid unexpected OOME elsewhere in the test
machinery.


Yes understood, but it was relying on all soft references being released 
at the same time.


For these OOME related tests it is hard to come up with a guaranteed way 
to trigger bugs that stands the test of time. So keep things simple and 
go with what works now across the set of GCs we are currently support.


Cheers,
David


best regards,

-- daniel


Re: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space"

2020-05-29 Thread Daniel Fuchs

On 29/05/2020 16:53, Lance Andersen wrote:

Hi Daniel,

Do you still need the SoftReference import given you are no longer using 
it with memory.add()?


No - I removed it.

cheers,

-- daniel



Best
Lance


Re: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space"

2020-05-29 Thread Lance Andersen
Hi Daniel,

Do you still need the SoftReference import given you are no longer using it 
with memory.add()?

Best
Lance

> On May 29, 2020, at 11:39 AM, Daniel Fuchs  wrote:
> 
> Hi,
> 
> I have updated the webrev as suggested by David:
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.01
> 
> Unless I hear any objection I'll push that new version if the
> tests come back successful.
> 
> best regards,
> 
> -- daniel
> 
> (tier1 and 2 passed, tier5 still running)
> 
> On 29/05/2020 00:36, David Holmes wrote:
>>> webrev:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.00/
>> I would have expected the fix here to be simply to clear memory ie:
>> } catch (OutOfMemoryError oome) {
>>   stop = true;
>>   memory = null;
>>   System.gc();
>> }
>> Cheers,
>> David

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com 





Re: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space"

2020-05-29 Thread Daniel D. Daugherty

On 5/29/20 11:39 AM, Daniel Fuchs wrote:

Hi,

I have updated the webrev as suggested by David:

http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.01


test/jdk/java/util/logging/Logger/bundleLeak/BundleTest.java
    No comments.

Thumbs up.

Dan



Unless I hear any objection I'll push that new version if the
tests come back successful.

best regards,

-- daniel

(tier1 and 2 passed, tier5 still running)

On 29/05/2020 00:36, David Holmes wrote:

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.00/


I would have expected the fix here to be simply to clear memory ie:

} catch (OutOfMemoryError oome) {
   stop = true;
   memory = null;
   System.gc();
}

Cheers,
David




Re: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space"

2020-05-29 Thread Daniel Fuchs

Hi,

I have updated the webrev as suggested by David:

http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.01

Unless I hear any objection I'll push that new version if the
tests come back successful.

best regards,

-- daniel

(tier1 and 2 passed, tier5 still running)

On 29/05/2020 00:36, David Holmes wrote:

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.00/


I would have expected the fix here to be simply to clear memory ie:

} catch (OutOfMemoryError oome) {
   stop = true;
   memory = null;
   System.gc();
}

Cheers,
David


Re: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space"

2020-05-29 Thread Daniel Fuchs

Hi David,

Thanks for the feedback!

On 29/05/2020 00:36, David Holmes wrote:
This seems to be assuming that the GC will clear all SoftReferences when 
it needs to clear any SoftReference. I don't think that is at all 
guaranteed. In theory your memory eating loop could be satisfied by 
clearing only the SoftReference added in the previous iteration of the 
loop.


I was wondering about that.


I would have expected the fix here to be simply to clear memory ie:

} catch (OutOfMemoryError oome) {
   stop = true;
   memory = null;
   System.gc();
}


Do you think this would be more reliable?
It was my first thought as well - and that was the
first thing I tested, and it seemed to work as well.

If you think it's a better solution I can revert to that.

My rationale for using SoftReference is that they
then could be cleared any time by the GC, and
possibly avoid unexpected OOME elsewhere in the test
machinery.

best regards,

-- daniel


Re: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space"

2020-05-28 Thread David Holmes

Hi Daniel,

This caught my eye ...

On 28/05/2020 6:50 pm, Daniel Fuchs wrote:

Hi,

Please find an almost trivial fix for:

8245867: Logger/bundleLeak/BundleTest.java fails due
  to "OutOfMemoryError: Java heap space"
https://bugs.openjdk.java.net/browse/JDK-8245867

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.00/

My new test for JDK-8239013 has been observed failing
intermittently in OutOfMemory. The test needs to trigger
the clearing of SoftReferences, and does so by eating
up heap memory in order to trigger a GC that will
clear them.


This seems to be assuming that the GC will clear all SoftReferences when 
it needs to clear any SoftReference. I don't think that is at all 
guaranteed. In theory your memory eating loop could be satisfied by 
clearing only the SoftReference added in the previous iteration of the loop.


I would have expected the fix here to be simply to clear memory ie:

} catch (OutOfMemoryError oome) {
  stop = true;
  memory = null;
  System.gc();
}

Cheers,
David


The issue is that the test didn't release the memory
when it no longer needed it, which caused trouble for
the test harness when it tried to clean up after the
test.

The fix is to use SoftReference to retain the eaten-up
memory (instead of strong references) so that it can
be reclaimed at the time the full GC that clear soft
references is triggered, and also to release the heap
memory as soon as it is no longer needed.

best regards,

-- daniel


Re: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space"

2020-05-28 Thread Lance Andersen
Hi Daniel,

The change looks reasonable.  Thank you for addressing so quickly.

Best
Lance

> On May 28, 2020, at 4:50 AM, Daniel Fuchs  wrote:
> 
> Hi,
> 
> Please find an almost trivial fix for:
> 
> 8245867: Logger/bundleLeak/BundleTest.java fails due
> to "OutOfMemoryError: Java heap space"
> https://bugs.openjdk.java.net/browse/JDK-8245867
> 
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.00/
> 
> My new test for JDK-8239013 has been observed failing
> intermittently in OutOfMemory. The test needs to trigger
> the clearing of SoftReferences, and does so by eating
> up heap memory in order to trigger a GC that will
> clear them.
> The issue is that the test didn't release the memory
> when it no longer needed it, which caused trouble for
> the test harness when it tried to clean up after the
> test.
> 
> The fix is to use SoftReference to retain the eaten-up
> memory (instead of strong references) so that it can
> be reclaimed at the time the full GC that clear soft
> references is triggered, and also to release the heap
> memory as soon as it is no longer needed.
> 
> best regards,
> 
> -- daniel

 
  

 Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com