On 1/07/2013 9:44 PM, Aleksey Shipilev wrote:
On 07/01/2013 03:37 PM, David Holmes wrote:
On 1/07/2013 8:14 PM, Aleksey Shipilev wrote:
The same "thou shalt not do multiple volatile reads" applies to
"(r.queue == NULL) || (r.queue == ENQUEUED)" now.
Doesn't that just reduce to "r.queue != thi
This looks fine to me.
Thanks,
David
On 1/07/2013 9:51 PM, Thomas Schatzl wrote:
Hi all,
On Mon, 2013-07-01 at 15:44 +0400, Aleksey Shipilev wrote:
On 07/01/2013 03:37 PM, David Holmes wrote:
On 1/07/2013 8:14 PM, Aleksey Shipilev wrote:
The same "thou shalt not do multiple volatile reads"
In a JPRT test job I just ran:
RedefineBigClass.sh passed on 9 platforms and failed on Linux 64-bit.
RetransformBigClass.sh passed on all 10 platforms.
Does your own testing only showing failure on the Linux 64-bit VM
and passed on the Linux 32-bit VM?
Dan
On 7/4/13 10:35 PM, Daniel D. Daugh
Ivan,
The changes look fine, I can sponsor your commit, looks like your
OpenJDK user name is 'igerasim', but I need to know a little bit
more about your testing of these fixes. Did you do a test JPRT
job to run the JLI tests (or just the two tests themselves)?
Based on e-mail about this bug fix,
On 07/03/2013 11:04 AM, Shi Jun Zhang wrote:
On 7/1/2013 11:49 PM, Chris Hegarty wrote:
On 1 Jul 2013, at 17:22, Remi Forax wrote:
On 07/01/2013 09:43 AM, Shi Jun Zhang wrote:
On 6/29/2013 12:05 AM, Shi Jun Zhang wrote:
On 6/28/2013 9:02 PM, Alan Bateman wrote:
On 27/06/2013 22:13, Remi Fo
Changeset: ed111451b77a
Author:zhangshj
Date: 2013-07-05 10:51 +0800
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ed111451b77a
8019381: HashMap.isEmpty is non-final, potential issues for get/remove
Reviewed-by: chegar, mduigou
! src/share/classes/java/util/HashMap.java
+ test/ja
Thank you, Daniel!
Please find an updated webrev at
http://cr.openjdk.java.net/~igerasim/8016838/2/webrev/.
It now includes the RetransformBigClass test modified in the same way as
RedefineBigClass.
If the changes look fine, may I ask you to sponsor the commit, as I'm
not a committer?
Here'
Hi Peter,
On 2/07/2013 5:19 PM, Peter Levart wrote:
Looking at original code once again, I think this was actually a bug.
The WeakReference instance constructed in (old) line 82, can be GCed
right away, since nobody is using the local variable after assignment.
Of course. Doh! I was to busy th
On 7/4/2013 3:28 AM, Alan Bateman wrote:
On 04/07/2013 10:11, huizhe wang wrote:
Daniel has helped adding many tests. The 1st one of the two scenarios
above are tested. It appeared that the properties set through the
factory or parser are always taken into account the last, therefore
take p
On 03/07/2013 22:10, Henry Jen wrote:
Yes, when I looked at it, there are other places as well. But I decided to
leave those alone as for delimiter/prefix/suffix, 'supplied' seems to be fine
and consistent.
add() is perhaps a good change. I updated the webrev with this simple change,
then I'l
Changeset: aa9fefb5d9c4
Author:alanb
Date: 2013-07-04 20:00 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/aa9fefb5d9c4
8017231: Add StringJoiner.merge
Reviewed-by: psandoz, alanb
Contributed-by: brian.go...@oracle.com, henry@oracle.com
! src/share/classes/java/util/Stri
On 04/07/2013 14:41, Rob McKenna wrote:
Hi Alan,
I've just uploaded the latest changes which rebase the fix to the
current repo.
Thank you (as you know I've been wanting us to move to posix_spawn on
Mac and Solaris for a long time).
(required post 8008118) I've also swapped out useFork for
On 07/04/2013 07:34 PM, Joel Borggrén-Franck wrote:
>>Also, can you please explain to me why the update race is safe. I have done
the/some research myself but I would like to know which angles you have covered.
>
>Well, one thing is that AnnotationType class is now effectively final, meaning t
On 7/4/13 11:19 AM, Ivan Gerasimov wrote:
Daniel, thank you for review!
Here's the updated with all all your suggestions adopted.
http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/
Looks good.
I haven't yet considered applying the approach to RetransformBigClass.
Do you want me to incl
Hi Peter,
On 4 jul 2013, at 16:40, Peter Levart wrote:
> Answers inline...
>>
>> There's another usage of AnnotationParser.parseAnnotation in
>> TypeAnnotationParser that will need to be updated (I only noticed it when I
>> grabbed your patch to try it).
>
> I rather restored the package-pr
Daniel, thank you for review!
Here's the updated with all all your suggestions adopted.
http://cr.openjdk.java.net/~igerasim/8016838/1/webrev/
I haven't yet considered applying the approach to RetransformBigClass.
Do you want me to include this into this same change set or should I
make it sepa
On 04/07/2013 15:44, Florian Weimer wrote:
Is there a way to prevent future calls to
AccessController.doPrivileged() from the same thread from actually
increasing privilege?
No. If the code has the relevant permissions it can call doPrivileged
together with the 1.0/1.1 legacy and new caller-se
On 03/07/2013 22:17, BILL PITTORE wrote:
These changes address bug 8014135 which adds support for statically
linked agents in the VM. This is a followup to the recent JNI spec
changes that addressed statically linked JNI libraries( 8005716).
The JEP for this change is the same JEP as the JNI ch
On 7/3/13 11:12 AM, Ivan Gerasimov wrote:
Hello everybody!
We have a request to improve jtreg test.
The test had been written to verify fix for memory leak during class
redefinition.
The problem is that it always is reported as PASSED even in the
presence of the leak.
The proposed change is
Is there a way to prevent future calls to
AccessController.doPrivileged() from the same thread from actually
increasing privilege?
I'm specifically concerned about code whose calls would otherwise
succeed because the containing class has the required permissions.
Reducing these privileges wi
Hi Alan, Joel,
Thanks to both for taking time to review the patch.
Here's the 3rd revision:
http://cr.openjdk.java.net/~plevart/jdk8-tl/AnnotationType/webrev.03/
Answers inline...
On 07/03/2013 04:51 PM, Alan Bateman wrote:
Sorry for the delay getting back to you on this, I've been busy with
Changeset: dd69273a0240
Author:alanb
Date: 2013-07-04 14:38 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd69273a0240
8019622: (sl) ServiceLoader.next incorrect when creation and usages are in
different contexts
Reviewed-by: mchung, ahgross, forax, psandoz
! src/share/cla
Hello again!
We have a request to improve jtreg test.
The test had been written to verify fix for memory leak during class
redefinition.
The problem is that it always is reported as PASSED even in the
presence of the leak.
The proposed change is platform specific.
It allows memory leak detec
On 03/07/2013 20:35, Alan Bateman wrote:
:
That should fix it but I worry that this might be a bit brittle and
maybe there be other code paths that will trigger loading of providers
when building call sites that result in the same thing. It might be
safer for now to just use inner classes her
Hi Alan,
I've just uploaded the latest changes which rebase the fix to the
current repo. (required post 8008118) I've also swapped out useFork for
jdk.lang.Process.launchMechanism. (it affords us the flexibility to
enable or disable other mechanisms on the various platforms at a later
date) I
Just to note that I am supportive of this bug fix (compared to the
previous proposal)
Stephen
On 3 July 2013 19:09, Brian Burkhalter wrote:
> On Jul 3, 2013, at 10:47 AM, Brian Burkhalter wrote:
>
>> I'll update this only to change the one public method and to modify its
>> specification.
>
> I'
On 04/07/2013 10:11, huizhe wang wrote:
Daniel has helped adding many tests. The 1st one of the two scenarios
above are tested. It appeared that the properties set through the
factory or parser are always taken into account the last, therefore
take preference in consistence with the spec. We
Hi Bill,
I've already had a chance to read your webrev several weeks ago, but
need more time.
Thanks,
Serguei
On 7/3/13 2:17 PM, BILL PITTORE wrote:
These changes address bug 8014135 which adds support for statically
linked agents in the VM. This is a followup to the recent JNI spec
changes
Changeset: 79c3146e417b
Author:vromero
Date: 2013-07-04 10:41 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/79c3146e417b
6356530: -Xlint:serial does not flag abstract classes with concrete
methods/members
Reviewed-by: mcimadamore
! src/share/classes/com/sun/tools/jav
Changeset: d6158f8d7235
Author:vromero
Date: 2013-07-04 10:35 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d6158f8d7235
8009924: some langtools tools do not accept -cp as an alias for -classpath
Reviewed-by: jjg
! src/share/classes/com/sun/tools/doclets/internal/tool
On 7/1/2013 12:54 PM, Alan Bateman wrote:
On 01/07/2013 19:33, huizhe wang wrote:
:
I've updated the jaxp 1.5 tests. I'll send a separate link since it's
internal. Indeed, I missed a couple of scenarios: 1) FSP can be set
after jaxp 1.5 properties are set through the API; 2) Validator does
On Jul 4, 2013, at 9:31 AM, Henry Jen wrote:
> Hi,
>
> I updated the test, and split the ConcatTest.java so we don't encounter
> the ClassNotFoundException issue on test-ng.
>
> Please review the webrev at
>
> http://cr.openjdk.java.net/~henryjen/ccc/8015315.1/webrev/
>
Looks good. I would li
Hi,
I updated the test, and split the ConcatTest.java so we don't encounter
the ClassNotFoundException issue on test-ng.
Please review the webrev at
http://cr.openjdk.java.net/~henryjen/ccc/8015315.1/webrev/
Cheers,
Henry
On Jul 4, 2013, at 12:51 AM, Henry Jen wrote:
> Hi,
>
> Please review the webrev at
>
> http://cr.openjdk.java.net/~henryjen/tl/8017141.0/webrev/
>
Note that the same change has already been fixed/pushed forrelevant
implementations in j.u.c.
This change in part of a wider change to fix rampa
34 matches
Mail list logo
