Re: CR 6860309 - solaris timing issue on thread startup
On 16/11/2011 00:47, Iris Clark wrote: Hi. The current practice may be different, but... The original intent was that every bug would either have a unit/regression test or a BugTraq keyword explaining why a test was not provided. See step 6 on this page for the list of valid keywords: http://openjdk.java.net/guide/changePlanning.html#bug This is the still the current practice and of course a specific regression test may be for several bugs (as often it make more sense to add to an existing test rather than add a new test each time). In the case of bugs against regression tests I've seen two approaches: 1. Addition of the bugid to the @bug tag 2. Addition of the "noreg-self" keyword to bugtraq Both technically fulfill the original intent. At one point there were audits to enforce this. There are still checks that noreg-self is added to the bug. I don't think the option of adding the bug number to @bug has been written down as an option, or at least I don't recall it coming up. I don't think it matters too much, the main intent is to give future maintainers the list of interesting bugs in the event of a test failure. -Alan
Re: what is the most precise time I can get in JDK?
Hi Max, On 16/11/2011 2:55 PM, Weijun Wang wrote: I need a precise time, and is currently using java.util.Date, which knows about milliseconds, but unfortunately the precision is only 10-15 milliseconds on a Windows. In fact, I don't really need it to be so correct. My requirements are: 1. It's enough correct, say, at least as correct as Date. 2. It's precise in a relative sense, i.e. it changes fast 3. It should be monotonic, i.e. it grows, unless the user adjusts the system clock There are only two time source available: 1. The time-of-day clock This is what Date reports and is also what System.currentTimeMillis reports. It only has millisecond precision. It's rate of update is dependent on the OS - for Windows that is typically every 10ms or every 15ms depending on version. 2. The high resolution time source This is what System.nanoTime reports. It has nanosecond precision, but again depending on the OS it's resolution (update rate) will vary. The update rate should easily be in the tens of microseconds. It should be monotonic non-decreasing but it is not connected to the time-of-day clock (and so should not be affected by any changes therein). I have an old blog entry on this: http://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks David -
what is the most precise time I can get in JDK?
Hi All I need a precise time, and is currently using java.util.Date, which knows about milliseconds, but unfortunately the precision is only 10-15 milliseconds on a Windows. In fact, I don't really need it to be so correct. My requirements are: 1. It's enough correct, say, at least as correct as Date. 2. It's precise in a relative sense, i.e. it changes fast 3. It should be monotonic, i.e. it grows, unless the user adjusts the system clock Thanks Max
hg: jdk8/tl/jdk: 2 new changesets
Changeset: cd6d236e863b Author:okutsu Date: 2011-11-16 12:57 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd6d236e863b 7111903: (tz) Windows-only: tzmappings needs update for KB2570791 Reviewed-by: peytoia ! src/windows/lib/tzmappings Changeset: 1266e72f7896 Author:okutsu Date: 2011-11-16 13:17 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1266e72f7896 Merge
hg: jdk8/tl/jdk: 7111579: klist starttime, renewtill, ticket etype
Changeset: c740519fe83a Author:weijun Date: 2011-11-16 11:53 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c740519fe83a 7111579: klist starttime, renewtill, ticket etype Reviewed-by: mullan ! src/share/classes/sun/security/krb5/internal/ccache/Credentials.java ! src/windows/classes/sun/security/krb5/internal/tools/Klist.java
Re: CR 6860309 - solaris timing issue on thread startup
Hi Iris, Still seems to me, based on the FAQ, http://openjdk.java.net/jtreg/faq.html that the intent is for @bug to refer to the bug that the test is testing. But as it is looking like this has been used in an ad-hoc manner anyway I'll shut up now. ;-) Cheers, David On 16/11/2011 10:47 AM, Iris Clark wrote: Hi. The current practice may be different, but... The original intent was that every bug would either have a unit/regression test or a BugTraq keyword explaining why a test was not provided. See step 6 on this page for the list of valid keywords: http://openjdk.java.net/guide/changePlanning.html#bug In the case of bugs against regression tests I've seen two approaches: 1. Addition of the bugid to the @bug tag 2. Addition of the "noreg-self" keyword to bugtraq Both technically fulfill the original intent. At one point there were audits to enforce this. Knowing how the audits worked (I personally preformed them for a while), I tended to favor adding the bugid to @bug as that would minimize the number of BugTraq queries. Even when the network and BugTraq were functioning perfectly, a BugTraq query always took longer than just looking at the source (which we were already looking at). Again, the above may no longer be the current practice or recommendation. Thanks, iris -Original Message- From: Alan Bateman Sent: Tuesday, November 15, 2011 2:37 PM To: David Holmes Cc: Gary Adams; core-libs-dev@openjdk.java.net Subject: Re: CR 6860309 - solaris timing issue on thread startup On 15/11/2011 21:29, David Holmes wrote: That was somewhat non-committal :) To me @bug says "these are the bugs that this test is checking the fix for" hence not applicable in any of the recent timing/race test fixes. It's non-committal because I don't think this has come up before, it's really something for the developer's guide. In any case, I don't think this discussion should stop us pushing Gary's fixes as he can easily revert the @bug tags for now. -Alan.
Re: Passing time factor to tests run under jtreg
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've been able to learn so far individual bugs can use the "timeout" parameter to indicate to the test harness an expected time to run. The test harness has command line arguments where it can filter out tests that take too long (timelimit) or can apply a multiplier to to the timeout when conditions are known to slow down the process (timeoutFactor). e.g. 8X for a slow machine or running with -Xcomp I see that there are some wrappers that can be applied around running a particular test to allow processing before main(). Could this mechanism be exploited so the harness command line options could be made known to the time dependent tests as command line arguments or as system properties? My thought is the current timeout granularity is too large and only applies to the full test execution. If a test knew that a timeoutFactor was to be applied, it could internally adjust the time dependent delays appropriately. e.g. not every sleep(), await(), join() with timeouts would need the timeoutFactor applied. I don't quite get what you mean about the timeouts applied to sleeps, awaits etc. Depending on the test some of these are delays (eg sleep is usually used this way) because it may not be feasible (or even possible) to coordinate the threads directly; while others (await, wait etc) are actual timeouts - if they expire it is an error because something appears to have gone wrong somewhere (of course this can be wrong because the timeout was too short for a given situation). As many of these tests have evolved along with the testing infrastructure it isn't always very clear who has responsibility for programming defensive timeouts. And many tests are designed to be run stand-alone or under a test harness, where exceptions due to timeouts are preferable to hangs. Further, while we can add a scale factor for known retarding factors - like Xcomp - there's no general way to assess the target machine capability (# cores, speed) and load, as it may impact a given test. And historically there has been a lack of resources to investigate and solve these issues. Cheers, David Before any test could be updated the information would need to be available from the test context. Any feedback/pointers appreciated! See timeoutFactorArg jtreg/src/share/classes/com/sun/javatest/regtest/Main.java runOtherJVM() jtreg/src/share/classes/com/sun/javatest/regtest/MainAction.java maxTimeoutValue jtreg/src/share/classes/com/sun/javatest/regtest/RegressionParameters.java
Re: Code Review Request for 6578042
On 16/11/2011 8:29 AM, Alan Bateman wrote: On 15/11/2011 19:51, Darryl Mocek wrote: I've modified the fix per feedback (thanks all). System.clearProperty now attempts to get the property with the specified key. If there is such a property, and the value is a String, remove the property and return the value removed, otherwise return null (if it is null) or throw CCE (if it's not null and is not a String...do not remove the property here). Webrev can be found here: http://cr.openjdk.java.net/~sherman/darryl/6578042/webrev Thanks for changing the approach, I think this is much better. On the implementation then I assume you need to synchronize around the get+remove. Yes - as it stands this is not thread-safe. Ideally I'd prefer to see the desired behaviour encapsulated in the Properties class (override Hashtable.remove) so that the synchronization is handled there too - but that may be too big an ask. Also needs a CCC for the spec change. Thanks, David The regression tests isn't in this webrev but you might want to go back over the comments on the original test. Also didn't we agree to also update Properties.getProperty to make it clear that it returns null when the value is not a String? -Alan
RE: CR 6860309 - solaris timing issue on thread startup
Hi. The current practice may be different, but... The original intent was that every bug would either have a unit/regression test or a BugTraq keyword explaining why a test was not provided. See step 6 on this page for the list of valid keywords: http://openjdk.java.net/guide/changePlanning.html#bug In the case of bugs against regression tests I've seen two approaches: 1. Addition of the bugid to the @bug tag 2. Addition of the "noreg-self" keyword to bugtraq Both technically fulfill the original intent. At one point there were audits to enforce this. Knowing how the audits worked (I personally preformed them for a while), I tended to favor adding the bugid to @bug as that would minimize the number of BugTraq queries. Even when the network and BugTraq were functioning perfectly, a BugTraq query always took longer than just looking at the source (which we were already looking at). Again, the above may no longer be the current practice or recommendation. Thanks, iris -Original Message- From: Alan Bateman Sent: Tuesday, November 15, 2011 2:37 PM To: David Holmes Cc: Gary Adams; core-libs-dev@openjdk.java.net Subject: Re: CR 6860309 - solaris timing issue on thread startup On 15/11/2011 21:29, David Holmes wrote: > > That was somewhat non-committal :) To me @bug says "these are the bugs > that this test is checking the fix for" hence not applicable in any of > the recent timing/race test fixes. It's non-committal because I don't think this has come up before, it's really something for the developer's guide. In any case, I don't think this discussion should stop us pushing Gary's fixes as he can easily revert the @bug tags for now. -Alan.
Re: Garbage collection race condition before final checks
Gary: Please do not start discussing other bugs in this thread - please keep them distinct. Remi: please add any comments to the discussion threads on those other bugs. Thanks David On 16/11/2011 12:30 AM, Rémi Forax wrote: On 11/15/2011 01:26 PM, Gary Adams wrote: Added PlatformLoggingMXBeanTest to the 7067691 bug fix, e.g. instance variables for Logger variables to prevent premature weak reference collection. http://cr.openjdk.java.net/~gadams/7067691/ Hi Garry, Fresh webrevs for the other work in progress bug fixes. http://cr.openjdk.java.net/~gadams/6731620/ You can declare and initialize elapsed at the same place : final long elapsed = System.currentTimeMillis() - start; otherwise, it looks ok. http://cr.openjdk.java.net/~gadams/6818464/ if you want to have a variable changed in an inner class, the usual idiom is to use an array of one element. public static void main (String[] args) throws Exception { + final Thread[] tdThread = new Thread[1]; Timer t = new Timer(); // Start a mean event that kills the timer thread t.schedule(new TimerTask() { public void run() { + tdThread[0] = Thread.currentThread(); throw new ThreadDeath(); } }, 0); // Wait for mean event to do the deed and thread to die. try { + do { Thread.sleep(100); + } while(tdThread[0] == null); } catch(InterruptedException e) { } + tdThread[0].join(); // Try to start another event try { // Timer thread is dead now t.schedule(new TimerTask() { http://cr.openjdk.java.net/~gadams/6860309/ This one is ok for me :) http://cr.openjdk.java.net/~gadams/7084033/ Thumb up for this one too ! cheers, Rémi 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. 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/LoggingMXBeanTest.java. I haven't looked in details but I wonder why the test/java/util/logging tests don't have this intermittent issue and I suspect it holds a strong reference. I attempted to break PlatformLoggingMXBeanTest.java with a generous application of GC calls, but I could not get it to fail in the same manner as the other test. It may be failing due to a different condition.
Re: Passing time factor to tests run under jtreg
Gary - this might be something to bring up on the jtreg-use list. Ideally the tests wouldn't have any hardcoded timeouts but sometimes there isn't any other choice. -Alan On 15/11/2011 20:14, 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've been able to learn so far individual bugs can use the "timeout" parameter to indicate to the test harness an expected time to run. The test harness has command line arguments where it can filter out tests that take too long (timelimit) or can apply a multiplier to to the timeout when conditions are known to slow down the process (timeoutFactor). e.g. 8X for a slow machine or running with -Xcomp I see that there are some wrappers that can be applied around running a particular test to allow processing before main(). Could this mechanism be exploited so the harness command line options could be made known to the time dependent tests as command line arguments or as system properties? My thought is the current timeout granularity is too large and only applies to the full test execution. If a test knew that a timeoutFactor was to be applied, it could internally adjust the time dependent delays appropriately. e.g. not every sleep(), await(), join() with timeouts would need the timeoutFactor applied. Before any test could be updated the information would need to be available from the test context. Any feedback/pointers appreciated! See timeoutFactorArg jtreg/src/share/classes/com/sun/javatest/regtest/Main.java runOtherJVM() jtreg/src/share/classes/com/sun/javatest/regtest/MainAction.java maxTimeoutValue jtreg/src/share/classes/com/sun/javatest/regtest/RegressionParameters.java
Re: CR 6860309 - solaris timing issue on thread startup
On 15/11/2011 21:29, David Holmes wrote: That was somewhat non-committal :) To me @bug says "these are the bugs that this test is checking the fix for" hence not applicable in any of the recent timing/race test fixes. It's non-committal because I don't think this has come up before, it's really something for the developer's guide. In any case, I don't think this discussion should stop us pushing Gary's fixes as he can easily revert the @bug tags for now. -Alan.
Re: Code Review Request for 6578042
On 15/11/2011 19:51, Darryl Mocek wrote: I've modified the fix per feedback (thanks all). System.clearProperty now attempts to get the property with the specified key. If there is such a property, and the value is a String, remove the property and return the value removed, otherwise return null (if it is null) or throw CCE (if it's not null and is not a String...do not remove the property here). Webrev can be found here: http://cr.openjdk.java.net/~sherman/darryl/6578042/webrev Thanks for changing the approach, I think this is much better. On the implementation then I assume you need to synchronize around the get+remove. The regression tests isn't in this webrev but you might want to go back over the comments on the original test. Also didn't we agree to also update Properties.getProperty to make it clear that it returns null when the value is not a String? -Alan
Re: CR 6860309 - solaris timing issue on thread startup
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 4820217 6860309 As per other emails and still waiting from confirmation from Alan. I don't think the @bug should be updated for any of these test fixes. The @bug tag is intended to list the bug numbers of bugs that are useful when you have a test failure and sometimes there can be really useful information in a bug that turns out to be a test bug. I'm not aware of any rule that says that the bug numbers shouldn't include bugs that were test only bugs but it's almost always bug numbers of bugs that caused the test to be extended to cover additional scenarios. For the tests being discussed here then I think we should just use our best judgment. Worse case it's easy to dig into the history with hg. That was somewhat non-committal :) To me @bug says "these are the bugs that this test is checking the fix for" hence not applicable in any of the recent timing/race test fixes. David -Alan.
Re: CR 6860309 - solaris timing issue on thread startup
Alan, On 15/11/2011 11:26 PM, Alan Bateman wrote: On 15/11/2011 00:56, David Holmes wrote: : 25 * @bug 4820217 6860309 As per other emails and still waiting from confirmation from Alan. I don't think the @bug should be updated for any of these test fixes. The @bug tag is intended to list the bug numbers of bugs that are useful when you have a test failure and sometimes there can be really useful information in a bug that turns out to be a test bug. I'm not aware of any rule that says that the bug numbers shouldn't include bugs that were test only bugs but it's almost always bug numbers of bugs that caused the test to be extended to cover additional scenarios. For the tests being discussed here then I think we should just use our best judgment. Worse case it's easy to dig into the history with hg. That was somewhat non-committal :) To me @bug says "these are the bugs that this test is checking the fix for" hence not applicable in any of the recent timing/race test fixes. David -Alan.
Passing time factor to tests run under jtreg
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 harness an expected time to run. The test harness has command line arguments where it can filter out tests that take too long (timelimit) or can apply a multiplier to to the timeout when conditions are known to slow down the process (timeoutFactor). e.g. 8X for a slow machine or running with -Xcomp I see that there are some wrappers that can be applied around running a particular test to allow processing before main(). Could this mechanism be exploited so the harness command line options could be made known to the time dependent tests as command line arguments or as system properties? My thought is the current timeout granularity is too large and only applies to the full test execution. If a test knew that a timeoutFactor was to be applied, it could internally adjust the time dependent delays appropriately. e.g. not every sleep(), await(), join() with timeouts would need the timeoutFactor applied. Before any test could be updated the information would need to be available from the test context. Any feedback/pointers appreciated! See timeoutFactorArg jtreg/src/share/classes/com/sun/javatest/regtest/Main.java runOtherJVM() jtreg/src/share/classes/com/sun/javatest/regtest/MainAction.java maxTimeoutValue jtreg/src/share/classes/com/sun/javatest/regtest/RegressionParameters.java
Re: Code Review Request for 6578042
I've modified the fix per feedback (thanks all). System.clearProperty now attempts to get the property with the specified key. If there is such a property, and the value is a String, remove the property and return the value removed, otherwise return null (if it is null) or throw CCE (if it's not null and is not a String...do not remove the property here). Webrev can be found here: http://cr.openjdk.java.net/~sherman/darryl/6578042/webrev Darryl On 11/12/2011 04:14 AM, Alan Bateman wrote: On 11/11/2011 19:37, Darryl Mocek wrote: Returning null if the value is not a String gives the impression that there was no property with that key when the property may have been there and may in fact have been removed. That's a fair point and probably enough to conclude that this approach should be dismissed. The toString approach is inconsistent so I think this brings us back to the original suggestion which is to specify that CCE is thrown (as it always has) but without side effects (meaning it doesn't remove the property). I think this is the best we can do with this broken API. : I would prefer it if Properties didn't allow non-String keys and values at all since they're supposed to be Strings (by API implication) and that Properties not extend Hashtable or extends Hashtable, but I digress. Properties goes back to JDK1.0 and has a warning in its javadoc for many years to discourage inserting keys or values that are not Strings. I'm not sure whether we can do much about it now without risking compatibility issues. -Alan.
Re: Garbage collection race condition before final checks
Updated the webrev - renamed variable to "test" - removed reset to null - removed extra parens in exception message - updated @bug tag I have never seen the failure with PlatformLoggingMXBeanTest, and I had previously done a gc right after the Logger assignment. Seems 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 variables for Logger variables to prevent premature weak reference collection. http://cr.openjdk.java.net/~gadams/7067691/ LoggingMXBeanTest.java: As Alan suggests, it'd be better to rename "lmxbeantest". I think simply "test" would do it. L70: resetting null is not needed. L232, 234: "(" and ")" brackets don't seem to be needed PlatformLoggingMXBeanTest.java: Similar comments as I gave to LoggingMXBeanTest.java: need to add the CR # to @bug. L48-49: a comment will prevent someone to back out this change to keep a strong reference in the future. Are you able to reproduce the test failure without moving L140-141? Mandy
Re: Garbage collection race condition before final checks
On 11/15/11 04:26, Gary Adams wrote: Added PlatformLoggingMXBeanTest to the 7067691 bug fix, e.g. instance variables for Logger variables to prevent premature weak reference collection. http://cr.openjdk.java.net/~gadams/7067691/ LoggingMXBeanTest.java: As Alan suggests, it'd be better to rename "lmxbeantest". I think simply "test" would do it. L70: resetting null is not needed. L232, 234: "(" and ")" brackets don't seem to be needed PlatformLoggingMXBeanTest.java: Similar comments as I gave to LoggingMXBeanTest.java: need to add the CR # to @bug. L48-49: a comment will prevent someone to back out this change to keep a strong reference in the future. Are you able to reproduce the test failure without moving L140-141? Mandy
Re: Garbage collection race condition before final checks
On 11/15/2011 01:26 PM, Gary Adams wrote: Added PlatformLoggingMXBeanTest to the 7067691 bug fix, e.g. instance variables for Logger variables to prevent premature weak reference collection. http://cr.openjdk.java.net/~gadams/7067691/ Hi Garry, Fresh webrevs for the other work in progress bug fixes. http://cr.openjdk.java.net/~gadams/6731620/ You can declare and initialize elapsed at the same place : final long elapsed = System.currentTimeMillis() - start; otherwise, it looks ok. http://cr.openjdk.java.net/~gadams/6818464/ if you want to have a variable changed in an inner class, the usual idiom is to use an array of one element. public static void main (String[] args) throws Exception { +final Thread[] tdThread = new Thread[1]; Timer t = new Timer(); // Start a mean event that kills the timer thread t.schedule(new TimerTask() { public void run() { +tdThread[0] = Thread.currentThread(); throw new ThreadDeath(); } }, 0); // Wait for mean event to do the deed and thread to die. try { +do { Thread.sleep(100); +} while(tdThread[0] == null); } catch(InterruptedException e) { } +tdThread[0].join(); // Try to start another event try { // Timer thread is dead now t.schedule(new TimerTask() { http://cr.openjdk.java.net/~gadams/6860309/ This one is ok for me :) http://cr.openjdk.java.net/~gadams/7084033/ Thumb up for this one too ! cheers, Rémi 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. 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/LoggingMXBeanTest.java. I haven't looked in details but I wonder why the test/java/util/logging tests don't have this intermittent issue and I suspect it holds a strong reference. I attempted to break PlatformLoggingMXBeanTest.java with a generous application of GC calls, but I could not get it to fail in the same manner as the other test. It may be failing due to a different condition.
Re: A method with return type size_t returns negative value
On 15/11/2011 08:09, Jing Lv wrote: Hello, I search the E:\workspace\openjdk\jdk\src\windows\native but find nothing similar (please tell me if I miss something), so I suggest we have a quick fix for now, like: I'm not around this week but I will get back to you next week on this (as I may have mentioned, I had hoped we would change all of this as part of other cleanup that includes removing dependencies on the JVM* functions). -Alan.
Re: CR 6860309 - solaris timing issue on thread startup
On 15/11/2011 00:56, David Holmes wrote: : 25 * @bug 4820217 6860309 As per other emails and still waiting from confirmation from Alan. I don't think the @bug should be updated for any of these test fixes. The @bug tag is intended to list the bug numbers of bugs that are useful when you have a test failure and sometimes there can be really useful information in a bug that turns out to be a test bug. I'm not aware of any rule that says that the bug numbers shouldn't include bugs that were test only bugs but it's almost always bug numbers of bugs that caused the test to be extended to cover additional scenarios. For the tests being discussed here then I think we should just use our best judgment. Worse case it's easy to dig into the history with hg. -Alan.
Re: Garbage collection race condition before final checks
Added PlatformLoggingMXBeanTest to the 7067691 bug fix, e.g. instance variables for Logger variables to prevent premature weak reference collection. http://cr.openjdk.java.net/~gadams/7067691/ Fresh webrevs for the other work in progress bug fixes. http://cr.openjdk.java.net/~gadams/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. 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/LoggingMXBeanTest.java. I haven't looked in details but I wonder why the test/java/util/logging tests don't have this intermittent issue and I suspect it holds a strong reference. I attempted to break PlatformLoggingMXBeanTest.java with a generous application of GC calls, but I could not get it to fail in the same manner as the other test. It may be failing due to a different condition.
Re: CR 6860309 - solaris timing issue on thread startup
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 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. http://cr.openjdk.java.net/~gadams/6860309/ Tested with -Xcomp, but still may need a older slow solaris/sparc machine to confirm the fix works for the original bug submitter.
Re: A method with return type size_t returns negative value
Hello, I search the E:\workspace\openjdk\jdk\src\windows\native but find nothing similar (please tell me if I miss something), so I suggest we have a quick fix for now, like: --- E:\workspace\openjdk\jdk\src\windows\native\java\io\io_util_md.h~ 2011-11-15 15:53:21.0 +0800 +++ E:\workspace\openjdk\jdk\src\windows\native\java\io\io_util_md.h 2011-11-15 15:56:27.0 +0800 @@ -36,14 +36,14 @@ WCHAR* currentDir(int di); int currentDirLength(const WCHAR* path, int pathlen); void fileOpen(JNIEnv *env, jobject this, jstring path, jfieldID fid, int flags); int handleAvailable(jlong fd, jlong *pbytes); JNIEXPORT int handleSync(jlong fd); int handleSetLength(jlong fd, jlong length); -JNIEXPORT size_t handleRead(jlong fd, void *buf, jint len); -JNIEXPORT size_t handleWrite(jlong fd, const void *buf, jint len); +JNIEXPORT SSIZE_T handleRead(jlong fd, void *buf, jint len); +JNIEXPORT SSIZE_T handleWrite(jlong fd, const void *buf, jint len); jint handleClose(JNIEnv *env, jobject this, jfieldID fid); jlong handleLseek(jlong fd, jlong offset, jint whence); /* * Returns an opaque handle to file named by "path". If an error occurs, * returns -1 and an exception is pending. --- E:\workspace\openjdk\jdk\src\windows\native\java\io\io_util_md.c~ 2011-11-15 16:02:55.0 +0800 +++ E:\workspace\openjdk\jdk\src\windows\native\java\io\io_util_md.c 2011-11-15 16:03:08.0 +0800 @@ -484,13 +484,13 @@ } if (SetEndOfFile(h) == FALSE) return -1; return 0; } JNIEXPORT -size_t +SSIZE_T handleRead(jlong fd, void *buf, jint len) { DWORD read = 0; BOOL result = 0; HANDLE h = (HANDLE)fd; if (h == INVALID_HANDLE_VALUE) { @@ -509,13 +509,13 @@ return -1; } return read; } JNIEXPORT -size_t +SSIZE_T handleWrite(jlong fd, const void *buf, jint len) { BOOL result = 0; DWORD written = 0; HANDLE h = (HANDLE)fd; if (h != INVALID_HANDLE_VALUE) { I will put it on the bug system. On 2011/11/9 16:57, Jing Lv wrote: Hello Alan, (Sorry that haven't check this for months) I check with the bug 7030624 but see no progress now. What's the current status? Shall we go on with a simple patch to fix the problem? On 2011/7/21 21:32, Alan Bateman wrote: Jing LV wrote: Ping, anyone notice this? :) My plan is that we'd search all source to find all kinds of such issues, and then refine them in a uniform solution. If jint is not good enough, how about ssize_t? ACK, saw your mails and will get back to you soon on this. -Alan