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
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
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
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: 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
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
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: 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: 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: 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: 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: 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.
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
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
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
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 -
