x on a 300MHz linux/arm device.
I'll provide a proper webrev as soon as I have author rights
confirmed. I'm looking for reviewer and a committer,
once I get the fix tested locally.
Thanks
Gary Adams
I'm taking a look at some older timing based bugs that may cause problems
on slower machines
6818464: TEST_BUG: Timeout values in several java/util tests are insufficient
I'd like to split this bug into two, based on the example problems that are
mentioned in the bug report.
The first example
On 11/ 6/11 08:05 PM, David Holmes wrote:
Hi Gary,
On 4/11/2011 11:36 PM, Gary Adams wrote:
I've started to look at timing related bugs that have been open
for a while, but have not had sufficient priority to make it to the
top of the list of bugs to be fixed. Thought I'd start wit
Here's another test with race conditions built into the test
that can be easily avoided
CR#7084033 - TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails intermittently
There are at least two race conditions in the test as currently written.
The test uses sleeps as a way to yield time to other
stop is issued.
Thanks,
-Chris.
On 07/11/2011 16:03, Gary Adams wrote:
Here's another test with race conditions built into the test
that can be easily avoided
CR#7084033 - TEST_BUG: test/java/lang/ThreadGroup/Stop.java fails
intermittently
There are at least two race conditions in t
Let's see if this captures all the comments and
is a bit more robust in the face of the original
race conditions mentioned.
- threads are started before they are recorded in local variables
- second is now volatile
- stop thread group is triggered by first thread once second thread is
Here's another intermittent bug that is attributed
to the garbage collection of the loggers before the
final static check can be applied in the test.
CR#7067691 : java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
failing intermittently
I'd like to implement the recommended sol
he intermittent bugs to reproduce quickly
with a strategic GC in the worst possible place.
A couple comment to the fix:
On 11/8/2011 7:35 AM, Gary Adams wrote:
diff --git
a/test/java/lang/management/PlatformLoggingMXBean/LoggingMXBeanTest.java
b/test/java/lang/management/P
On 11/9/11 4:08 AM, Alan Bateman wrote:
On 08/11/2011 15:35, Gary Adams wrote:
Here's another intermittent bug that is attributed
to the garbage collection of the loggers before the
final static check can be applied in the test.
CR#7067691 :
java/lang/management/PlatformLoggingM
Captured the latest round of comments
- more readable initialization
- allow sleep interruption to terminate main thread
- added current CR# to @bug tag
24/**
25 * @test
26 * @bug 4176355 7084033
27 * @summary Stopping a ThreadGroup that contains the c
+check(elapsed < 500);
t.cancel();
On 11/ 4/11 09:36 AM, Gary Adams wrote:
I've started to look at timing related bugs that have been open
for a while, but have not had sufficient priority to make it to the
top of the list of bugs to be fixed. Thought I'd start wi
.equals(mxbean2.getParentLoggerName(logger)))
throw new RuntimeException(
On 11/ 9/11 04:08 AM, Alan Bateman wrote:
On 08/11/2011 15:35, Gary Adams wrote:
Here's another intermittent bug that is attributed
to the garbage collection of the loggers before the
final st
Alan Bateman wrote:
On 04/11/2011 15:52, Gary Adams wrote:
:
I'll attempt a simple fix for the KillThread case by replacing :
Thread.sleep(100);
with a simple loop
do {
Thread.sleep(100);
} while (waiting);
where the TimerTask runnable will clear the flag
with "waiting = false &qu
On 11/10/11 2:22 AM, David Holmes wrote:
Aside: it would be good if whomever is going to do the commits for you
could assist with publishing webrevs for these changes.
There was a bulk request to add Vivian's team to the openjdk
authors list that may have taken a longer route by way of Bob
to
On 11/ 8/11 11:13 PM, Mandy Chung wrote:
Thanks for picking up this bug and fixing this intermittent issue.
PlatformLoggingMXBeanTest.java in the same directory has the same issue. It'd
be good to fix that with the same CR. These tests were copied from
test/java/util/logging/LoggingMXBea
CR 6860309 - TEST_BUG: Insufficient sleep time in
java/lang/Runtime/exec/StreamsSurviveDestroy.java
A timing problem is reported for slow solaris systems for this
test to start up a process and systematically torture the underlying
threads processing data from the running process.
On my fast s
On 11/12/11 6:58 AM, Alan Bateman wrote:
On 11/11/2011 16:56, Gary Adams wrote:
CR 6860309 - TEST_BUG: Insufficient sleep time in
java/lang/Runtime/exec/StreamsSurviveDestroy.java
A timing problem is reported for slow solaris systems for this
test to start up a process and systematically
I've updated the webrev for CR#6860309 using a CountDownLatch.
The main thread will wait til both worker threads are ready to
block on the read() before the process is destroyed.
http://cr.openjdk.java.net/~gadams/6860309/
Tested with -Xcomp, but still may need a older slow solaris/sparc
mac
Updated to move static latch to Copier
constructor argument.
On 11/14/11 11:09 AM, Gary Adams wrote:
I've updated the webrev for CR#6860309 using a CountDownLatch.
The main thread will wait til both worker threads are ready to
block on the read() before the process is destroyed.
Updated again with comment and cosmetic changes.
Waiting for Alan's input on whether @bug tag
includes bugfixes against the test or only the original
functional bug report.
On 11/14/11 03:32 PM, Gary Adams wrote:
Updated to move static latch to Copier
constructor argument.
On 11/14/11
/6731620/
http://cr.openjdk.java.net/~gadams/6818464/
http://cr.openjdk.java.net/~gadams/6860309/
http://cr.openjdk.java.net/~gadams/7084033/
On 11/10/11 09:41 AM, Gary Adams wrote:
On 11/ 8/11 11:13 PM, Mandy Chung wrote:
Thanks for picking up this bug and fixing this intermittent issue
eems to be a reasonable update to use the instance variables
in case the previous failures were caused by the logger being gc'ed.
On 11/15/11 12:57 PM, Mandy Chung wrote:
On 11/15/11 04:26, Gary Adams wrote:
Added PlatformLoggingMXBeanTest to the 7067691 bug fix,
e.g. instance varia
I've been scanning a number of the slow machine test
bugs that are reported and wanted to check to see if
anyone has looked into time dependencies in the regression
tests previously. From what I've been able to learn so far
individual bugs can use the "timeout" parameter to indicate to
the test h
Where can we find the definition of the tag contents?
Whichever way this discussion goes, we should
update that documentation with the conclusions.
On 11/15/11 4:29 PM, David Holmes wrote:
Alan,
On 15/11/2011 11:26 PM, Alan Bateman wrote:
On 15/11/2011 00:56, David Holmes wrote:
:
25 * @bug 4
On 11/15/11 8:33 PM, David Holmes wrote:
Hi Gary,
On 16/11/2011 6:14 AM, Gary Adams wrote:
I've been scanning a number of the slow machine test
bugs that are reported and wanted to check to see if
anyone has looked into time dependencies in the regression
tests previously. From what I&#x
The jtreg tests that use othervm along with a timeout argument should be
fairly reliable in getting a consistent result. The tests that did not specify
othervm may run into problems, if they are run concurrently with other tests.
Here's a quick sampling of the java/util and java/lang tests that
On 11/16/11 11:56 AM, Alan Bateman wrote:
On 16/11/2011 16:29, Gary Adams wrote:
The jtreg tests that use othervm along with a timeout argument should be
fairly reliable in getting a consistent result. The tests that did not specify
othervm may run into problems, if they are run concurrently
On 11/16/11 11:59 AM, Kelly O'Hair wrote:
On Nov 16, 2011, at 8:29 AM, Gary Adams wrote:
The jtreg tests that use othervm along with a timeout argument should be
fairly reliable in getting a consistent result. The tests that did not specify
othervm may run into problems, if they ar
On 11/16/11 12:29 PM, Alan Bateman wrote:
On 16/11/2011 17:21, Kelly O'Hair wrote:
:
But if the test naturally runs long enough, any win from using samevm for
that particular testcase is kind of minimal.
And if using samevm makes the test less reliable or makes the other tests
sharing it's c
On 11/17/11 4:14 AM, Chris Hegarty wrote:
On 17/11/2011 08:29, Alan Bateman wrote:
.
I see Chris's mail points out that some tests do have an unusually small
timeout. For those tests then I would be tempted to just remove the
timeout. Most likely the original author of the test put a small
On 11/17/11 6:36 AM, Chris Hegarty wrote:
On 17/11/2011 11:22, Gary Adams wrote:
On 11/17/11 4:14 AM, Chris Hegarty wrote:
On 17/11/2011 08:29, Alan Bateman wrote:
.
I see Chris's mail points out that some tests do have an unusually
small
timeout. For those tests then I wou
second timeout recognize that additional
processing time may be required.
I'll try a longer overnight run at 300MHz to see if I can catch some
other tests that are close to the 120 second threshold.
...
On 11/15/11 08:33 PM, David Holmes wrote:
Hi Gary,
On 16/11/2011 6:14 AM, Gary Adam
I think this change is ready to commit, just need
a sponsor for the last push (Mandy/David?).
http://cr.openjdk.java.net/~gadams/6731620/
I think this change is ready to commit, just need
a sponsor for the last push (Mandy/David?).
http://cr.openjdk.java.net/~gadams/6818464/
I think this change is ready to commit, just need
a sponsor for the last push (Mandy/David?).
http://cr.openjdk.java.net/~gadams/6860309/
I think this change is ready to commit, just need
a sponsor for the last push (Mandy/David?).
http://cr.openjdk.java.net/~gadams/7084033/
On 11/21/11 5:37 AM, Alan Bateman wrote:
On 21/11/2011 01:39, David Holmes wrote:
Never mind - Alan already tracked down reviews and did push.
Yes, I pushed the three that I thought had been reviewed and
thoroughly battered to death. There is a fourth one
(test/java/lang/ThreadGroup/Stop.java)
On 11/21/11 05:44 AM, Gary Adams wrote:
On 11/21/11 5:37 AM, Alan Bateman wrote:
On 21/11/2011 01:39, David Holmes wrote:
Never mind - Alan already tracked down reviews and did push.
Yes, I pushed the three that I thought had been reviewed and thoroughly
battered to death. There is a fourth
The original complaint about the flakey mutex regression test is
that it was failing on slower machines. The delay at the end of
the processing is unnecessarily restrictive. Since the test harness
will terminate after 120 seconds if the test hangs, the test does
not have to terminate more quickly
Not quite as sure about the internal timeouts in this regression test.
Here's a proposed change that cranks up the timeouts. Since the test
harness defaults to 2 minutes there's no reason the service termination
should timeout more quickly. For the thread startup, I added a countdown latch
so th
monitor unexpected slowdowns in
the system as a whole, but there are better tools for that analysis
in the standard performance benchmarks.
On 11/21/11 09:08 PM, David Holmes wrote:
Hi Gary,
On 22/11/2011 5:26 AM, Gary Adams wrote:
The original complaint about the flakey mutex regression test is
will be updated.
http://cr.openjdk.java.net/~gadams/6957683/
On 11/21/11 09:33 PM, David Holmes wrote:
Gary,
On 22/11/2011 6:26 AM, Gary Adams wrote:
Not quite as sure about the internal timeouts in this regression test.
Here's a proposed change that cranks up the timeouts. Since the
Here's another test that had an assumption that the threads
would terminate within a 10 second window. On a busy or
slow machine this limit may not be sufficient. Since the jtreg
harness uses 120 second default value for terminating a
test, the test should not be more restrictive.
http://cr.op
I think you want to add 6990617 to the @bug tag in RegExTest.
On 12/10/11 01:05 AM, Stephen Flores wrote:
Please review the following webrev (includes new test to demonstrate the bug):
http://cr.openjdk.java.net/~sflores/6990617/
for bug: 6990617 Regular expression doesn't match if unicode
A number of regression tests have designated short timeouts
and have been the cause of intermittent test failures on
slow machines or on builds with slower runtime execution
speeds, e.g. -Xcomp, etc.
The jtreg regression harness uses 2 minutes as the default
timeout value for forcing a test failu
The LargeFileAvailable regression test had intermittent failures
when there was not sufficient space available to create
a 7G temp file. This webrev presents a simple check to
see if the available usable space is less than 7G and
scales the test back accordingly.
The original bug report suggests
I see in the webrev the removal of drops.dir from the ant build.xml.
Should similar updates be applied to README-builds.html for
ALT_DROPS_DIR and ALLOW_DOWNLOADS?
Might be good to put a note in
$(ALT_JDK_DEVTOOLS_PATH)/share/jdk8-drops
indicating the files are now include directly
in the jdk8
On 01/ 5/12 08:30 AM, Alan Bateman wrote:
On 23/12/2011 16:19, Gary Adams wrote:
The LargeFileAvailable regression test had intermittent failures
when there was not sufficient space available to create
a 7G temp file. This webrev presents a simple check to
see if the available usable space is
On 01/ 6/12 03:32 PM, Alan Bateman wrote:
On 06/01/2012 19:47, Gary Adams wrote:
I've updated the webrev with the temp file created in the current directory.
I'm not sure what to do about the case if there is only a little space available
only a small file will be used. Should the
Doesn't the generated javadoc include an h2 for Class LogManager?
That would make the h3 for LogManager Configuration the correct nesting
level,
even though it does not appear in the individual source file.
On 3/12/19, 8:06 AM, Daniel Fuchs wrote:
Hi,
Please find below a trivial doc fix for:
Here's an updated webrev that includes the change to bind to the stub.
The jstatd tests continue to pass after this change.
Webrev: http://cr.openjdk.java.net/~gadams/8203026/webrev.01/
It would be good to have a second reviewer from the serviceability team.
Longer term it would be good to rep
This fix will not work for the macosx static build.
e.g. configure --enable-static-build=yes
When linking static libraries the entry point for
JNI_OnLoad_zip is needed to inform the symbol lookups
to be performed on the current executable,
rather than a dynamic library.
On 05/24/16 19:47, Naoto
sed fix applied. I see the symbol "_JNI_OnLoad_zip" in
it. Am I missing something?
Naoto
On 5/25/16 9:01 AM, Gary Adams wrote:
This fix will not work for the macosx static build.
e.g. configure --enable-static-build=yes
When linking static libraries the entry point for
JNI_OnLoad_zi
53 matches
Mail list logo
