Hi Aleksey,
On 11/11/2014 12:19 AM, Aleksey Shipilev wrote:
Hi David, Chris,
On 11/10/2014 04:53 PM, Chris Hegarty wrote:
On 10/11/14 12:56, David Holmes wrote:
On 10/11/2014 9:52 PM, Chris Hegarty wrote:
I have only looked at the libraries changes, and I think they make sense
. As in, I can
Repeating my response due to the subject mangling in the other "thread":
This is a known issue:
https://bugs.openjdk.java.net/browse/JDK-6900441
fixed in 7u60, 8 and 9.
What version were you running?
David
On 7/11/2014 6:22 PM, wuwen.55 wrote:
call .await(10, TimeUnit.SECONDS) and change th
This is a known issue:
https://bugs.openjdk.java.net/browse/JDK-6900441
fixed in 7u60, 8 and 9.
What version were you running?
David
On 11/11/2014 6:59 AM, Bernd Eckenfels wrote:
Hm, how did you change the time? (normal date command?) System.nanoTime is
supposed to be monotonic. I think on
Hi David,
Looks good to me.
Thanks,
Joe
On 11/10/2014 3:05 PM, david buck wrote:
Hi!
May I please have a review of this fix:
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8064516
WEBREV: http://cr.openjdk.java.net/~dbuck/8064516/webrev00/
Cheers,
-Buck
Hi!
May I please have a review of this fix:
BUGURL: https://bugs.openjdk.java.net/browse/JDK-8064516
WEBREV: http://cr.openjdk.java.net/~dbuck/8064516/webrev00/
Cheers,
-Buck
Hm, how did you change the time? (normal date command?) System.nanoTime is
supposed to be monotonic. I think on linux it even uses a timer for exactly
that.
i think there was a open bug around park(), but the nanoTime should be find
(and negative difference are sonewhat normal with it anyway)
g
On 10/11/2014 19:09, Mark Sheppard wrote:
Hi
please oblige and review the follow minor change
diff -r c0d1026bff6f src/java.base/share/native/libfdlibm/k_standard.c
--- a/src/java.base/share/native/libfdlibm/k_standard.c Tue Nov 04
15:10:38 2014 +
+++ b/src/java.base/share/native/libfdlibm
On 10 Nov 2014, at 17:37, Mark Sheppard wrote:
> Hi
> please oblige and review the follow change
Looks find to me Mark.
-Chris.
> diff -r c0d1026bff6f src/java.base/windows/native/libnio/MappedByteBuffer.c
> --- a/src/java.base/windows/native/libnio/MappedByteBuffer.cTue Nov 04
> 15:10:3
Hi
please oblige and review the follow minor change
diff -r c0d1026bff6f src/java.base/share/native/libfdlibm/k_standard.c
--- a/src/java.base/share/native/libfdlibm/k_standard.c Tue Nov 04
15:10:38 2014 +
+++ b/src/java.base/share/native/libfdlibm/k_standard.c Mon Nov 10
19:02:57 2014 +00
thanks Alan ... grand, I'll replace the "if (clazz == null) return; "
with a CHECK_NULL(clazz);
regards
Mark
On 10/11/2014 17:59, Alan Bateman wrote:
On 10/11/2014 17:37, Mark Sheppard wrote:
Hi
please oblige and review the follow change
diff -r c0d1026bff6f
src/java.base/windows/native/li
On 10.11.2014 19:39, Staffan Larsen wrote:
>> On 10 nov 2014, at 15:55, Aleksey Shipilev
>> wrote:
>> Ow, it seems very like it.
>> So, what testlist have I missed to catch this?
>
> Probably vm.tmtools.testlist and/or nsk.sajdi.testlist. Just a warning that
> these tests are far from stable. S
On 10/11/2014 17:37, Mark Sheppard wrote:
Hi
please oblige and review the follow change
diff -r c0d1026bff6f
src/java.base/windows/native/libnio/MappedByteBuffer.c
--- a/src/java.base/windows/native/libnio/MappedByteBuffer.c Tue Nov
04 15:10:38 2014 +
+++ b/src/java.base/windows/native/lib
call .await(10, TimeUnit.SECONDS) and change the time one hours back.
i.e. start at 13:00 call .await and at 13:05 change the time to 12:05
you will notice that the wait does not return.
when change the time to the current time . change the time to 13:05.
the wait still does not return.
test c
Hi
please oblige and review the follow change
diff -r c0d1026bff6f src/java.base/windows/native/libnio/MappedByteBuffer.c
--- a/src/java.base/windows/native/libnio/MappedByteBuffer.cTue Nov
04 15:10:38 2014 +
+++ b/src/java.base/windows/native/libnio/MappedByteBuffer.cMon Nov
10 17:
> On 10 nov 2014, at 15:55, Aleksey Shipilev
> wrote:
>
> Hi Staffan,
>
> Ow, it seems very like it.
> So, what testlist have I missed to catch this?
Probably vm.tmtools.testlist and/or nsk.sajdi.testlist. Just a warning that
these tests are far from stable. Sorry about that.
/Staffan
>
>
On 11/07/2014 11:48 PM, Martin Buchholz wrote:
Hi Joel,
Thanks for volunteering. I foisted all I have in
https://bugs.openjdk.java.net/browse/JDK-8064391
I volunteer to be your reviewer for the backports.
Hi Martin,
Sorry I haven't checked this earlier, but there are still some data
races
On 11/10/2014 06:13 PM, roger riggs wrote:
> On 11/10/2014 9:54 AM, Aleksey Shipilev wrote:
>> Again, I don't quite understand. Is it about storing the reference to
>> String as the thread name, that can potentially be used for external
>> synchronization?
>>
>> If so, I have a hard time devising a
Hi,
On 11/10/2014 9:54 AM, Aleksey Shipilev wrote:
Hi Roger,
On 11/10/2014 05:31 PM, roger riggs wrote:
1) The Thread class javadoc says:
" Unless otherwise noted, passing a {@code null} argument to a constructor
* or method in this class will cause a {@link NullPointerException} to be
* t
Approved
thanks Eric,
cheers
/Joel
On 2014-11-10, Eric McCorkle wrote:
> Ok, the test has been revised as you suggested.
>
> A new version is posted (webrev.03).
>
> On 11/10/14 06:45, Joel Borggrén-Franck wrote:
> > Hi Eric,
> >
> > The changes to Executable.java and Parameter.java looks goo
Hi Staffan,
Ow, it seems very like it.
So, what testlist have I missed to catch this?
-Aleksey.
On 11/10/2014 05:51 PM, Staffan Larsen wrote:
> I’m afraid this change requires changes in the Serviceability Agent as well.
> See OopUtilities.threadOopGetName() for example.
>
> /Staffan
>
>> On
Hi Roger,
On 11/10/2014 05:31 PM, roger riggs wrote:
> 1) The Thread class javadoc says:
> " Unless otherwise noted, passing a {@code null} argument to a constructor
> * or method in this class will cause a {@link NullPointerException} to be
> * thrown."
>
> So, NPE is already specified for set
Ok, the test has been revised as you suggested.
A new version is posted (webrev.03).
On 11/10/14 06:45, Joel Borggrén-Franck wrote:
> Hi Eric,
>
> The changes to Executable.java and Parameter.java looks good. The test
> could still need some cleaning up:
>
> @summary should be before "action ta
I’m afraid this change requires changes in the Serviceability Agent as well.
See OopUtilities.threadOopGetName() for example.
/Staffan
> On 10 nov 2014, at 15:19, Aleksey Shipilev
> wrote:
>
> Hi David, Chris,
>
> On 11/10/2014 04:53 PM, Chris Hegarty wrote:
>> On 10/11/14 12:56, David Holme
Vladimir, thanks for reviewing
I have updated the webrev:
http://cr.openjdk.java.net/~kshefov/8059070/webrev.02
I have added DEFAULT_TEST_TIMEOUT constant to Utils class.
-Konstantin
On 10.11.2014 14:33, Vladimir Ivanov wrote:
Kontantin, sorry for the late response.
In general, the fix look
Hi Aleksey,
1) The Thread class javadoc says:
" Unless otherwise noted, passing a {@code null} argument to a constructor
* or method in this class will cause a {@link NullPointerException} to be
* thrown."
So, NPE is already specified for setThreadName(null) or any other method.
I'm not infavo
On 10/11/2014 13:53, Chris Hegarty wrote:
If there was previous discussion on this, that revealed some
substantial issue, that would be great, but I can't recall, or find,
it now.
Hotspot express, and the desire for hotspot to run with different
library versions, would certainly cause compl
Hi David, Chris,
On 11/10/2014 04:53 PM, Chris Hegarty wrote:
> On 10/11/14 12:56, David Holmes wrote:
>> On 10/11/2014 9:52 PM, Chris Hegarty wrote:
>>> I have only looked at the libraries changes, and I think they make sense
>>> . As in, I can find no reason why the name cannot be changed to be
Hi Chris,
Thanks for taking a look!
On 11/10/2014 02:52 PM, Chris Hegarty wrote:
> Trivially, after your changes will NPE be thrown if setName(null), as it
> is today ?
There is no way it could throw NPE now, therefore the behavior is
different. The spec says nothing about NPE though, but it fee
On 10/11/14 12:56, David Holmes wrote:
On 10/11/2014 9:52 PM, Chris Hegarty wrote:
Aleksey,
I have only looked at the libraries changes, and I think they make sense
. As in, I can find no reason why the name cannot be changed to be a
String.
Very quick response, but IIRC this has been examine
On 10/11/2014 9:52 PM, Chris Hegarty wrote:
Aleksey,
I have only looked at the libraries changes, and I think they make sense
. As in, I can find no reason why the name cannot be changed to be a
String.
Very quick response, but IIRC this has been examined in the past and
there were reasons wh
Kontantin, sorry for the late response.
In general, the fix looks good.
I'd move timeout computation logic to Utils:
+private static final long TIMEOUT =
Utils.adjustTimeout(TimeUnit.SECONDS.toMillis(120));
Default value (120s) isn't specific to the tests, but an implementation
detail of
Hi Eric,
The changes to Executable.java and Parameter.java looks good. The test
could still need some cleaning up:
@summary should be before "action tags", put it right after @bug
I don't think you need a separate file for InnerClassToStringNoParameters.java
, should be able to accomplish the s
Aleksey,
I have only looked at the libraries changes, and I think they make sense
. As in, I can find no reason why the name cannot be changed to be a String.
Trivially, after your changes will NPE be thrown if setName(null), as it
is today ?
-Chris.
On 09/11/14 18:45, Aleksey Shipilev wro
On 10/11/14 09:43, Paul Sandoz wrote:
On Nov 6, 2014, at 8:07 PM, Martin Buchholz wrote:
Sorry, Paul, I missed your offer on the other thread to take this to
CCC. It's yours.
On Thu, Nov 6, 2014 at 10:50 AM, Martin Buchholz wrote:
Hi Joe,
I'd like you to do a code review.
https://bugs.ope
On Nov 6, 2014, at 8:07 PM, Martin Buchholz wrote:
> Sorry, Paul, I missed your offer on the other thread to take this to
> CCC. It's yours.
>
> On Thu, Nov 6, 2014 at 10:50 AM, Martin Buchholz wrote:
>> Hi Joe,
>>
>> I'd like you to do a code review.
>>
>> https://bugs.openjdk.java.net/brows
That would be great
cheers
/Joel
On 2014-11-09, Ivan Gerasimov wrote:
> Hi!
>
> I think I can handle the backport to jdk7, if you still need a volunteer.
>
> Sincerely yours,
> Ivan
>
> On 08.11.2014 1:48, Martin Buchholz wrote:
> >Hi Joel,
> >
> >Thanks for volunteering. I foisted all I have
36 matches
Mail list logo
