Thanks Igor,
On 24/01/2019 15:59, Igor Ignatyev wrote:
Hi Daniel,
it might be a better idea to scale sleep time using
jdk.test.lib.Utils::adjustTimeout, so it will remain the same on configuration
w/ timeout-factor=1, and scaled proportionally to timeout-factor on slow
configurations. the rest looks good.
I've chosen a slightly different path and adjusted the number of
iterations instead:
http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.01
best regards,
-- daniel
Thanks,
-- Igor
On Jan 24, 2019, at 4:20 AM, Daniel Fuchs <daniel.fu...@oracle.com> wrote:
Thanks Lance.
Meanwhile I noticed that the first loop calling gc() used
a sleep(100) - which is probably not enough in those
greedy configurations - so I extended that to 1000.
(webrev updated in place).
http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.00/
Hopefully that will reduce the frequency of failures.
Re testing in progress...
best regards,
-- daniel
On 24/01/2019 12:14, Lance Andersen wrote:
Morning Daniel,
The change seems like a good approach
Best
Lance
On Jan 24, 2019, at 6:42 AM, Daniel Fuchs <daniel.fu...@oracle.com
<mailto:daniel.fu...@oracle.com>> wrote:
Hi,
Please find below a fix for:
8217353:
java/util/logging/LogManager/Configuration/updateConfiguration/HandlersOnComplexResetUpdate.java
fails with Unexpected reference: java.lang.ref.WeakReference
https://bugs.openjdk.java.net/browse/JDK-8217353
webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8217353/webrev.00/
This test has been seen failing from time to time with an
exception originating from the finally { } clause of the
main method. The suspicion is that this exception in fact
hides another exception previously thrown in the try { }
body.
This is only a fix in so far that it will ensure that the
real exception - if any - is added to the suppressed list
of the secondary exception so that we eventually see it in
the log.
As to why the test failed in the first place - I am not quite
sure, but it might be due to -Xcomp or some other combination
of options preventing the WeakReference to be cleared within
the time (and number of gc() calls) expected by the test
(the test has never been seen failing without these combinations).
best regards,
-- daniel
<http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
<http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen|
Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com <mailto:lance.ander...@oracle.com>
