Hi,
Please review fixes for launcher correctness wrt. JNI calls.
http://cr.openjdk.java.net/~ksrini/8031494/webrev.0/
Thanks
Kumar
Hi Peter the version you provided ran indefinitely(i put a 10 minute
timeout) and the program got interrupted(no error), even if there were
to be an error you cannot print the "string" of thread to console(these
have been attempted earlier).
- The test's running on interpreter mode, what i am wa
Thank you for all the feedback. I have updated my changes to use
"CHECK_EXCEPTION_RETURN" and "CHECK_EXCEPTION" macro recently added into
jni_util.h. I also removed else block in function setStaticIntField() in
Version.c since (*env)->GetStaticFieldID will throw a same exception if
the field ca
On Jan 10 2014, at 10:09 , Chris Hegarty wrote:
> On 10 Jan 2014, at 18:05, Dan Xu wrote:
>
>> Hi Roger,
>>
>> My macro is a little different from yours, which compares with -1 instead of
>> NULL. I also see CHECK_EXCEPTION macro. Thanks for adding them, which are
>> useful when I cannot de
On Jan 10, 2014, at 7:11 PM, Mike Duigou wrote:
>>
>> The second tweak is to consolidate the reporting of elements to within the
>> ForEachOrderedTask.tryComplete method.
>>
>> I have also removed the inconsistently applied synchronized block. Either we
>> apply it consistently to reporting o
Yes, you are right. I just found this macro. It looks very handy to use.
Thanks!
-Dan
On 01/10/2014 09:59 AM, roger riggs wrote:
Hi Dan,
One other comment, instead of changing the return type of the
setStaticIntField
just return and the caller should check for exceptions and return.
See jni
On Jan 10 2014, at 05:42 , Paul Sandoz wrote:
> Hi,
>
> Some tweaks to the Stream forEachOrdered operation:
>
> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8029452-ForEachOrdered/webrev/
>
> The first tweak is to size the CHM used in ForEachOrderedTask, this avoids
> concurrent resizes and
On 10 Jan 2014, at 18:05, Dan Xu wrote:
> Hi Roger,
>
> My macro is a little different from yours, which compares with -1 instead of
> NULL. I also see CHECK_EXCEPTION macro. Thanks for adding them, which are
> useful when I cannot decide the pending exception state by just using return
> val
Hi Mandy,
Good point; I'll create another issue to do that update.
(I should have waited a bit longer for comments.)
Roger
On 1/10/2014 12:41 PM, Mandy Chung wrote:
On 1/10/2014 7:37 AM, roger riggs wrote:
Please review:
To enable native code checking consistently for thrown exceptions,
the
Hi Roger,
My macro is a little different from yours, which compares with -1
instead of NULL. I also see CHECK_EXCEPTION macro. Thanks for adding
them, which are useful when I cannot decide the pending exception state
by just using return values.
As for the style, actually I prefer the (!poin
Hi Dan,
One other comment, instead of changing the return type of the
setStaticIntField
just return and the caller should check for exceptions and return.
See jni.h: CHECK_EXCEPTION(env)
Roger
On 1/10/2014 11:40 AM, roger riggs wrote:
Hi Dan,
Just pushed are macros in jni_util.h to do the
The implementation looks good. I would move construction of the listIterator to
before the toArray() for detection of concurrent modification (growing of the
list).
I believe we should fix this for 8 if possible.
Mike
On Jan 10 2014, at 03:21 , Paul Sandoz wrote:
> Hi,
>
> When we added the
Looks good to me Daniel.
-Chris.
On 10 Jan 2014, at 17:47, Daniel Fuchs wrote:
> Hi,
>
> Please find below a trivial fix for
> 8031525: Logger created in test/tools/jar/UpdateManifest.java might
> get gc'ed too early.
>
> https://bugs.openjdk.java.net/browse/JDK-8031525
>
> Hopefully
On 01/10/2014 02:32 AM, Alan Bateman wrote:
On 10/01/2014 06:31, Dan Xu wrote:
Hi All,
Please review the fix for JNI pending exception issues reported in
jdk-8029007. Thanks!
Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8029007
Thi
Thanks, Chris.
Right, I don't find any usage of getThreadStateValues, so it is simpler
to just remove it.
-Dan
On 01/09/2014 11:49 PM, Chris Hegarty wrote:
Looks ok to me.
I presume getThreadStateValues is simply no longer needed.
-Chris.
On 10 Jan 2014, at 06:31, Dan Xu wrote:
Hi All
Hi,
Please find below a trivial fix for
8031525: Logger created in test/tools/jar/UpdateManifest.java might
get gc'ed too early.
https://bugs.openjdk.java.net/browse/JDK-8031525
Hopefully that's the last of its kind - (see
https://bugs.openjdk.java.net/browse/JDK-8029595).
webrev:
On 1/10/2014 7:37 AM, roger riggs wrote:
Please review:
To enable native code checking consistently for thrown exceptions,
the macros in net_util.h and java/util/jar/pack/coding.cpp are
made consolidated and promoted to jni_util.h
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-check-exceptio
On 10/01/14 15:37, roger riggs wrote:
Please review:
To enable native code checking consistently for thrown exceptions,
the macros in net_util.h and java/util/jar/pack/coding.cpp are
made consolidated and promoted to jni_util.h
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8
Hi,
this is about fixing copyright years for jdk8 (!); the incorrect years
found for both 2012 and 2013, so not to confuse script
jdk8/make/scripts/update_copyright_year.sh
it is necessary to use option -d "" for commit. I tested that and
it seems to work perfect.
I used following:
[2012 modi
Hi Dan,
Just pushed are macros in jni_util.h to do the same function as your new
macros.
Please update to use the common macros instead of introducing new ones.
Style wise, I would avoid mixing binary operators (!) with pointers.
it is clearer to compare with NULL. (The CHECK_NULL macro will
On 10/01/2014 15:37, roger riggs wrote:
Please review:
To enable native code checking consistently for thrown exceptions,
the macros in net_util.h and java/util/jar/pack/coding.cpp are
made consolidated and promoted to jni_util.h
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-check-exception
On 10 Jan 2014, at 16:36, Alan Bateman wrote:
> On 10/01/2014 15:08, Iaroslav Savytskyi wrote:
>> Hi, Alan,
>>
>> You are absolutely right. Unfortunately the things a little bit more
>> complicated. The reason why I’m fixing this now is, that some time ago I fix
>> this synchronization issue (
Thank you Roger, much appreciated.
I think Dan has a change in flight that could be simplified a bit by
using these.
-Chris.
On 10/01/14 15:37, roger riggs wrote:
Please review:
To enable native code checking consistently for thrown exceptions,
the macros in net_util.h and java/util/jar/pac
On 10/01/2014 15:08, Iaroslav Savytskyi wrote:
Hi, Alan,
You are absolutely right. Unfortunately the things a little bit more
complicated. The reason why I’m fixing this now is, that some time ago I fix
this synchronization issue (synchronized setter without synchronized getter).
After that I
Please review:
To enable native code checking consistently for thrown exceptions,
the macros in net_util.h and java/util/jar/pack/coding.cpp are
made consolidated and promoted to jni_util.h
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-check-exception-8030875/
[1] https://bugs.openjdk.java.
Hi, Alan,
You are absolutely right. Unfortunately the things a little bit more
complicated. The reason why I’m fixing this now is, that some time ago I fix
this synchronization issue (synchronized setter without synchronized getter).
After that I got this bug. We had internal discussions if I c
On 10/01/2014 14:26, Iaroslav Savytskyi wrote:
Hello,
I would like to request for approval for this fix. This is simple revert of the
changes which caused the issue. I’ve returned back synchronization and removed
volatile. So now serialVersionUID is the same as before.
Bug:
https://bugs.openj
Hello,
I would like to request for approval for this fix. This is simple revert of the
changes which caused the issue. I’ve returned back synchronization and removed
volatile. So now serialVersionUID is the same as before.
Bug:
https://bugs.openjdk.java.net/browse/JDK-8031488
Webrev:
http://
On Jan 10, 2014, at 3:01 PM, Alan Bateman wrote:
> The implementation changes look good. I agree that the javadoc needs changing
> as it's otherwise misleading as to what the implementation actually does. I
> would think that this should go with the implementation change rather than as
> a sepa
On 10/01/2014 11:21, Paul Sandoz wrote:
Hi,
When we added the List.sort method the default implementation deferred to
Collections.sort.
This is the wrong way around, since any existing use of Collections.sort say
with ArrayList will not avail of the optimal implementation provided by
ArrayLi
Hi,
Some tweaks to the Stream forEachOrdered operation:
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8029452-ForEachOrdered/webrev/
The first tweak is to size the CHM used in ForEachOrderedTask, this avoids
concurrent resizes and the costs associated with those.
The second tweak is to consol
Changeset: 6f3a3bd78c57
Author:erikj
Date: 2014-01-10 10:25 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f3a3bd78c57
8031300: No jdeps.1 and jjs.1 man pages in jdk8 b122 build and jvisualvm.1 and
jcmd.1 missing on macosx
8030946: No jmc.1 for man page of JMC
Reviewed-by:
Hi,
Many thanks for the investigation and suggested workarounds.
Bean Validation recommends to declare an inner @List annotation to specify
several constraints of the same type on a given element, but its ok to
deviate from that pattern in the rare cases of package-private constraint
types.
> I
On Jan 10, 2014, at 12:48 PM, Chris Hegarty wrote:
> Looks fine to me.
Thanks.
> I don't think AtomicLong was ever needed here.
>
It was crudely used as a holder of the count, since captured refs are
(effectively) final, and not for it's concurrent properties as i wanted to
avoid using any
Looks fine to me. I don't think AtomicLong was ever needed here.
-Chris.
On 10/01/14 10:01, Paul Sandoz wrote:
Hi,
A small tweak is required to a recent Stream-based test i added to stop some
internal lambda-based ser/derialization (SAND) tests barfing since the test is
hostile to ser/derial
Hi,
When we added the List.sort method the default implementation deferred to
Collections.sort.
This is the wrong way around, since any existing use of Collections.sort say
with ArrayList will not avail of the optimal implementation provided by
ArrayList.sort.
To resolve this the implementati
On 01/10/2014 09:31 AM, Peter Levart wrote:
Since we suspect there's something wrong with exception handling in
interpreter, I devised a hypothetical reproducer that tries to
simulate ReferenceHandler in many aspects, but doesn't require to be a
ReferenceHandler:
http://cr.openjdk.java.net/~p
On 10/01/2014 10:37, David Holmes wrote:
I'm not sure what is actually being proposed. I don't really see
anything that would help diagnoze the original issue. But bring back
the test - maybe this was a bug elsewhere that has now been fixed.
I think the proposal is as we said, more diagnostic
On 10/01/2014 6:40 PM, Staffan Larsen wrote:
On 10 jan 2014, at 09:34, Alan Bateman wrote:
On 09/01/2014 23:20, Tristan Yan wrote:
Hi David
I wasn't able to reproduce this failure either in local or in our same binaries
running(This is a continuous running with same JDK binaries). So intent
On 10/01/2014 06:31, Dan Xu wrote:
Hi All,
Please review the fix for JNI pending exception issues reported in
jdk-8029007. Thanks!
Webrev: http://cr.openjdk.java.net/~dxu/8029007/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8029007
This looks good, the only one that isn't clear (t
Hi,
A small tweak is required to a recent Stream-based test i added to stop some
internal lambda-based ser/derialization (SAND) tests barfing since the test is
hostile to ser/derialization, and infact i should have probably written the
test like below in the first place.
Kumar has verified it
On 10 jan 2014, at 09:34, Alan Bateman wrote:
> On 09/01/2014 23:20, Tristan Yan wrote:
>> Hi David
>> I wasn't able to reproduce this failure either in local or in our same
>> binaries running(This is a continuous running with same JDK binaries). So
>> intention for this code change is bringi
On 09/01/2014 23:20, Tristan Yan wrote:
Hi David
I wasn't able to reproduce this failure either in local or in our same
binaries running(This is a continuous running with same JDK binaries).
So intention for this code change is bringing this test back; add
some debug info and try to avoid pos
On 01/10/2014 12:59 AM, srikalyan chandrashekar wrote:
David/Peter you are right, the logs trace came from passed run, i am
trying to simulate the failure and get the logs for failed runs(2000+
runs done and still no failure), will get back to you once i have the
data from failed run. Sorry fo
44 matches
Mail list logo
