On 26/02/2014 19:34, Brent Christian wrote:
:
The change is:
# @bug 5088398
-# @ignore until bug 6835233 dealt with
# @summary Test parallel class loading by parallel transformers.
This looks okay to me too, I assume that if there is any residual issue
that it will show up quickly once the t
> On Feb 26, 2014, at 8:55 PM, Brian Burkhalter
> wrote:
>> If it looks worth doing, I'll file another issue to track the idea.
>> I already have it on my list anyway to follow up on Alan Eliasen's
>> comment in the BigInteger code:
>>
>> * This could be changed to a more complicated caching meth
On 26/02/2014 21:47, Seán Coffey wrote:
Good points Alan. Changes uploaded here :
http://cr.openjdk.java.net/~coffeys/webrev.8035618.v2/webrev/
This looks much better. Are you sure that pmLock is needed? Is there any
reason not to synchronize on the AppContext when adding the
PresentationManage
On 27/02/2014 5:30 PM, Peter Levart wrote:
On 02/27/2014 08:29 AM, Peter Levart wrote:
On 02/26/2014 09:54 PM, Martin Buchholz wrote:
I don't recall having added this particular wart
to test/java/lang/ProcessBuilder/Basic.java, and history suggests that
others did that.
It does seem that being
On 02/27/2014 08:29 AM, Peter Levart wrote:
On 02/26/2014 09:54 PM, Martin Buchholz wrote:
I don't recall having added this particular wart
to test/java/lang/ProcessBuilder/Basic.java, and history suggests that
others did that.
It does seem that being able to tell whether a java object monitor
On 02/26/2014 09:54 PM, Martin Buchholz wrote:
I don't recall having added this particular wart
to test/java/lang/ProcessBuilder/Basic.java, and history suggests that
others did that.
It does seem that being able to tell whether a java object monitor is
currently locked is useful for debugging a
Looks good!
Thanks,
/Staffan
On 26 feb 2014, at 20:34, Brent Christian wrote:
> File under "chipping away at test stabilization issues."
>
> https://bugs.openjdk.java.net/browse/JDK-6835233
>
> I've done some repeated runs of this test on my Linux machine. The test
> fails every time with 6
On 2/26/2014 7:09 PM, Roger Riggs wrote:
Hi Mandy,
Yes, it might be more productive to switch the tests to TestNG.
But it did provide support in cases where TestNG could not be used,
for example in a directory of existing tests that had custom reporting.
But I remember there is a problem with T
Hi Mandy,
Yes, it might be more productive to switch the tests to TestNG.
But it did provide support in cases where TestNG could not be used,
for example in a directory of existing tests that had custom reporting.
But I remember there is a problem with TestNG having a dependency for XML
which is
Hi Roger,
On 2/26/2014 12:34 PM, roger riggs wrote:
The testlibrary for the jdk should be printing the values in the failed
assertions to make debugging easier and quicker.
The webrev adds the printing of the failed assertions and added methods
for formatting and unconditional fail methods.
We
Hi Stuart,
Looks good to go back; thanks,
-Joe
On 2/26/2014 4:44 PM, Stuart Marks wrote:
Hi all,
Any takers for this review?
s'marks
On 2/18/14 6:47 PM, Stuart Marks wrote:
Hi all,
Please review this change to remove a redundant timing-retry loop
from the
rmidRunning() routine of the RMI
Hi all,
Any takers for this review?
s'marks
On 2/18/14 6:47 PM, Stuart Marks wrote:
Hi all,
Please review this change to remove a redundant timing-retry loop from the
rmidRunning() routine of the RMI test library. It is replaced with a simple rmid
registry lookup that returns status immediate
On Feb 26, 2014, at 3:51 PM, Brian Burkhalter wrote:
>>> * This could be changed to a more complicated caching method using
>>> * {@code Future}.
>>> */
>>> private static BigInteger getRadixConversionCache(int radix, int exponent)
>>> {
>>>
>>
>> Not quite sure what that would entail.
>
On Feb 26, 2014, at 1:53 PM, Paul Sandoz wrote:
>> Thanks for the suggestion, Paul. Assuming it is correct, in what way would
>> this be a better approach? (I apologize for being obtuse.)
>>
>
> IMHO it is a simpler solution. It's a cache line that requires updating not
> the cache line*s*, a
On 2/26/2014 12:54 PM, Martin Buchholz wrote:
I don't recall having added this particular wart
to test/java/lang/ProcessBuilder/Basic.java, and history suggests that
others did that.
It does seem that being able to tell whether a java object monitor is
currently locked is useful for debugging a
On Feb 26, 2014, at 1:29 PM, Paul Sandoz wrote:
>> I made all suggested changes except the third line below. Why do we test for
>> equality with -3? If the primitive int default value of zero is used, for
>> firstNonzeroIntNumPlusTwo, as it is, then we should still test whether fn
>> equals -2
Changeset: 0683ee308085
Author:coffeys
Date: 2014-02-26 23:04 +
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/0683ee308085
8035618: Four api/org_omg/CORBA TCK tests fail under plugin only
Reviewed-by: mchung, chegar
! src/share/classes/com/sun/corba/se/spi/orb/ORB.java
On 26/02/2014 21:47, Seán Coffey wrote:
Good points Alan. Changes uploaded here :
http://cr.openjdk.java.net/~coffeys/webrev.8035618.v2/webrev/
Looks ok to me Sean.
-Chris.
regards,
Sean.
On 26/02/14 18:54, Alan Bateman wrote:
On 26/02/2014 16:50, Seán Coffey wrote:
Looking to push a fix
On 2/26/2014 2:12 PM, Ivan Gerasimov wrote:
Good point, thank you Mandy. I should have added comments at the very
beginning.
Would you take a look at the last updated webrev, with the suggested
changes?
http://cr.openjdk.java.net/~igerasim/6853696/3/webrev/
thanks for making the change. It
Hi Ivan,
A few comments on UnixCommands:
- The trailing "_" on the method names looks very odd, they could all
use some suffix "Pgm" "X", etc.
- I'm not sure the specific command methods do you any good
(over a method with a string argument). since they immediately
revert to the string
Looks good to me.
Mandy
On 2/26/2014 1:47 PM, Seán Coffey wrote:
Good points Alan. Changes uploaded here :
http://cr.openjdk.java.net/~coffeys/webrev.8035618.v2/webrev/
regards,
Sean.
On 26/02/14 18:54, Alan Bateman wrote:
On 26/02/2014 16:50, Seán Coffey wrote:
Looking to push a fix to JDK
On 26.02.2014 22:43, Mandy Chung wrote:
On 2/25/2014 11:08 PM, Ivan Gerasimov wrote:
I missed that you remove the strong reference (line 57). I think
it's good to hold the strong reference so that
ReferenceQueue.remove(timeout) will timeout and the test can verify
reliably.
This is an im
On Feb 26, 2014, at 8:55 PM, Brian Burkhalter
wrote:
>
> On Feb 26, 2014, at 5:38 AM, Paul Sandoz wrote:
>
Not sure the static powerCache field, in the original code, needs to be
volatile either:
1137 private static volatile BigInteger[][] powerCache;
>>>
>>> Is there
Good points Alan. Changes uploaded here :
http://cr.openjdk.java.net/~coffeys/webrev.8035618.v2/webrev/
regards,
Sean.
On 26/02/14 18:54, Alan Bateman wrote:
On 26/02/2014 16:50, Seán Coffey wrote:
Looking to push a fix to JDK 8. A CORBA issue was discovered during
TCK-Plugin testing. The NPE
On 24.02.2014 23:38, Martin Buchholz wrote:
Thanks for working on these ancient Process tests.
I would prefer to see them using "feature tests".
You wanna do "cat /dev/zero"? Then look for cat in /bin and /usr/bin
and check for /dev/zero as well, e.g. using File.isExecutable
OK. Here's ano
On Feb 26, 2014, at 8:35 PM, Brian Burkhalter
wrote:
>> […]
>> private int firstNonzeroIntNum() {
>> int fn = firstNonzeroIntNumPlusTwo - 2;
>
> I made all suggested changes except the third line below. Why do we test for
> equality with -3? If the primitive int default value of zero is
The testlibrary for the jdk should be printing the values in the failed
assertions to make debugging easier and quicker.
The webrev adds the printing of the failed assertions and added methods
for formatting and unconditional fail methods.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-testli
On Feb 26, 2014, at 5:38 AM, Paul Sandoz wrote:
>>> Not sure the static powerCache field, in the original code, needs to be
>>> volatile either:
>>>
>>> 1137 private static volatile BigInteger[][] powerCache;
>>
>> Is there consensus on whether "volatile" is necessary here?
>>
>
> Lookin
On Feb 26, 2014, at 4:56 AM, Peter Levart wrote:
>>> Not sure the static powerCache field, in the original code, needs to be
>>> volatile either:
>>>
>>> 1137 private static volatile BigInteger[][] powerCache;
>> Is there consensus on whether "volatile" is necessary here?
>
> I think it ha
On Feb 26, 2014, at 2:15 AM, Paul Sandoz wrote:
>> I have posted a new webrev taking this approach:
>>
>> http://cr.openjdk.java.net/~bpb/8035279/webrev.01/
>>
>> A review would be appreciated.
>>
Thanks for the suggestions …
> […]
>private int firstNonzeroIntNum() {
>int fn = fi
File under "chipping away at test stabilization issues."
https://bugs.openjdk.java.net/browse/JDK-6835233
I've done some repeated runs of this test on my Linux machine. The test
fails every time with 6u3. It fails intermittently on 7 (after 145
iterations for 7u45, and 62 iterations for 7u60
I will do JPRT control build and push this fix into ppc-aix-port/stage
Thanks,
Vladimir
On 2/26/14 11:00 AM, Alan Bateman wrote:
On 26/02/2014 18:51, Volker Simonis wrote:
Hi,
please review the following small AIX-only change for
ppc-aix-port/stage (and eventually jdk8u) which became necessar
On 26/02/2014 18:51, Volker Simonis wrote:
Hi,
please review the following small AIX-only change for
ppc-aix-port/stage (and eventually jdk8u) which became necessary after
we have synced the following two changes from jdk8u:
8028293: Check local configuration for actual ephemeral port range
713
On 26/02/2014 16:50, Seán Coffey wrote:
Looking to push a fix to JDK 8. A CORBA issue was discovered during
TCK-Plugin testing. The NPE seen should be handled and the
defaultPresentationManager should be returned where necessary.
Bug ID : https://bugs.openjdk.java.net/browse/JDK-8035618
webrev
Hi,
please review the following small AIX-only change for
ppc-aix-port/stage (and eventually jdk8u) which became necessary after
we have synced the following two changes from jdk8u:
8028293: Check local configuration for actual ephemeral port range
7133499: (fc) FileChannel.read not preempted by
On 2/25/2014 11:08 PM, Ivan Gerasimov wrote:
I missed that you remove the strong reference (line 57). I think
it's good to hold the strong reference so that
ReferenceQueue.remove(timeout) will timeout and the test can verify
reliably.
This is an important part.
If we didn't remove the stro
On 26/02/2014 16:22, Xueming Shen wrote:
Hi, please help review the trivial doc typo fix.
https://bugs.openjdk.java.net/browse/JDK-8035814
http://cr.openjdk.java.net/~sherman/8035814/webrev
Looks fine. You might want to correct the package name in the issue
synopsis before you create the change
Seems like a symbolic victory, at least :) It's less unsafe than some
unsafe methods (you can use it to create a DoS but not to violate safety
constraints like bounds checking or pointer casting) but its a start!
On 2/26/2014 10:12 AM, Paul Sandoz wrote:
Hi,
Out of all the methods on Unsafe
Looks fine, (not a Reviewer)
On 2/26/2014 11:22 AM, Xueming Shen wrote:
Hi, please help review the trivial doc typo fix.
https://bugs.openjdk.java.net/browse/JDK-8035814
http://cr.openjdk.java.net/~sherman/8035814/webrev
Thanks!
-Sherman
Looking to push a fix to JDK 8. A CORBA issue was discovered during
TCK-Plugin testing. The NPE seen should be handled and the
defaultPresentationManager should be returned where necessary.
Bug ID : https://bugs.openjdk.java.net/browse/JDK-8035618
webrev : http://cr.openjdk.java.net/~coffeys/we
Hi, please help review the trivial doc typo fix.
https://bugs.openjdk.java.net/browse/JDK-8035814
http://cr.openjdk.java.net/~sherman/8035814/webrev
Thanks!
-Sherman
Hi,
A common reason why Unsafe is used is to more efficiently compare two unsigned
byte arrays, viewing those byte arrays as long arrays. See Guava [1] and a
number of apache frameworks for similar code.
One solution is to provide such functionality in Arrays for all primitives and
probably re
Hi,
Out of all the methods on Unsafe i think the
monitorEnter/monitorExit/tryMonitorEnter are the least used and are very strong
candidates for removal.
99% of use-cases are supported by classes in the java.util.concurrent.locks
package.
Within the JDK itself it is only used in one JDK test
On Feb 25, 2014, at 9:38 PM, Brian Burkhalter
wrote:
>
> On Feb 20, 2014, at 1:42 AM, Paul Sandoz wrote:
>
>> Not sure the static powerCache field, in the original code, needs to be
>> volatile either:
>>
>> 1137 private static volatile BigInteger[][] powerCache;
>
> Is there consensus
On 02/25/2014 09:38 PM, Brian Burkhalter wrote:
On Feb 20, 2014, at 1:42 AM, Paul Sandoz wrote:
Not sure the static powerCache field, in the original code, needs to be
volatile either:
1137 private static volatile BigInteger[][] powerCache;
Is there consensus on whether "volatile" is nec
On Feb 25, 2014, at 9:36 PM, Brian Burkhalter
wrote:
>
> On Feb 25, 2014, at 4:26 AM, Paul Sandoz wrote:
>
>> Might as well just remove the @Deprecated stuff. I think it is fine under
>> the circumstances to have offsets and getter methods that return the correct
>> values.
>
> I have post
John, Chris, thanks for review!
Best regards,
Vladimir Ivanov
On 2/26/14 5:34 AM, John Rose wrote:
On Feb 25, 2014, at 4:16 PM, Vladimir Ivanov
wrote:
As an interim fix, I moved castReference method into
java.lang.invoke.MethodHandleImpl class and added new entry point
ValueConversions::cas
47 matches
Mail list logo
