Thanks, Christian!
Serguei
On 2/25/14 5:55 PM, Christian Thalinger wrote:
Looks good.
On Feb 25, 2014, at 12:43 PM, serguei.spit...@oracle.com wrote:
Please, review the fix for:
https://bugs.openjdk.java.net/browse/JDK-6471769
Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2014
Looks good.
On Feb 25, 2014, at 12:43 PM, serguei.spit...@oracle.com wrote:
> Please, review the fix for:
> https://bugs.openjdk.java.net/browse/JDK-6471769
>
>
> Open webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1
>
> Summary:
>
> This is another
I concur with Markus. Pairing JVM_CONSTANT_UnresolvedClassInError with
JVM_CONSTANT_UnresolvedClass in the ConstantPool::copy_entry_to()
switch looks like the right thing to do.
The usual questions:
- why wasn't this failure mode seen before JDK8?
- was this failure caught somewhere else before
Thanks for the review!
Dan
On 2/25/14 5:20 PM, serguei.spit...@oracle.com wrote:
Dan,
The fix looks good to me.
I like the comments.
They help to understand this aspect of the protocol.
Thanks,
Serguei
On 2/25/14 8:03 AM, Daniel D. Daugherty wrote:
Ping! Still haven't heard from anyone on
Dan,
The fix looks good to me.
I like the comments.
They help to understand this aspect of the protocol.
Thanks,
Serguei
On 2/25/14 8:03 AM, Daniel D. Daugherty wrote:
Ping! Still haven't heard from anyone on this backport...
Dan
On 2/21/14 8:40 PM, Daniel D. Daugherty wrote:
Greetings,
On 2/25/14 2:57 PM, Daniel D. Daugherty wrote:
On 2/25/14 1:43 PM, serguei.spit...@oracle.com wrote:
Please, review the fix for:
https://bugs.openjdk.java.net/browse/JDK-6471769
Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1
src/share/vm/runt
On 2/25/14 2:54 PM, serguei.spit...@oracle.com wrote:
Will review it today.
You know, your fix is tricky. :)
Thanks. I will wait for your review.
Dan
Thanks,
Serguei
On 2/25/14 8:03 AM, Daniel D. Daugherty wrote:
Ping! Still haven't heard from anyone on this backport...
Dan
On 2/21/14
On 2/25/14 4:11 PM, Karen Kinnear wrote:
Dan,
Code looks good. This makes sense to me. Thank you for the detailed comments
and testing.
Thanks for the review!
thanks,
Karen
p.s. sorry - you would think getting three copies of the review request would
mean
I would not completely overlook
Dan,
Code looks good. This makes sense to me. Thank you for the detailed comments
and testing.
thanks,
Karen
p.s. sorry - you would think getting three copies of the review request would
mean
I would not completely overlook this in my emails :-)
On Feb 21, 2014, at 10:40 PM, Daniel D. Daugher
On 2/25/14 1:43 PM, serguei.spit...@oracle.com wrote:
Please, review the fix for:
https://bugs.openjdk.java.net/browse/JDK-6471769
Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1
src/share/vm/runtime/vm_operations.hpp
No comments.
src/shar
Will review it today.
You know, your fix is tricky. :)
Thanks,
Serguei
On 2/25/14 8:03 AM, Daniel D. Daugherty wrote:
Ping! Still haven't heard from anyone on this backport...
Dan
On 2/21/14 8:40 PM, Daniel D. Daugherty wrote:
Greetings,
This is a code review request for the JDK8u-hs-dev b
Thanks Ron!
Dan
On 2/25/14 1:00 PM, Ron Durbin wrote:
Code looks good.
Thx for the local in person review.
Thx Ron
-Original Message-
From: Daniel D. Daugherty
Sent: Tuesday, February 25, 2014 9:04 AM
To: David Holmes; Serguei Spitsyn; Dave Dice; Karen Kinnear
Cc: serviceability-dev
Please, review the fix for:
https://bugs.openjdk.java.net/browse/JDK-6471769
Open webrev:
http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6471769-JVMTI-DEPTH.1
Summary:
This is another Test Stabilization issue.
The fix is very similar to other JVMTI stabilization fixes.
It is
Code looks good.
Thx for the local in person review.
Thx Ron
> -Original Message-
> From: Daniel D. Daugherty
> Sent: Tuesday, February 25, 2014 9:04 AM
> To: David Holmes; Serguei Spitsyn; Dave Dice; Karen Kinnear
> Cc: serviceability-dev@openjdk.java.net; hotspot-runtime-...@openjdk.jav
Ping! Still haven't heard from anyone on this backport...
Dan
On 2/21/14 8:40 PM, Daniel D. Daugherty wrote:
Greetings,
This is a code review request for the JDK8u-hs-dev backport of the
following ObjectMonitor-JVM/TI hang fix:
8028073 race condition in ObjectMonitor implementation causi
Thumbs up. (not a "reviewer", though)
-JB-
On 19.2.2014 12:05, taras ledkov wrote:
Hi,
Imports are fixed:
http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.04/
On 05.02.2014 17:20, Jaroslav Bachorik wrote:
Hi Taras,
thanks for taking care of this.
The changes look fine to me.
One m
On 20.2.2014 18:04, Martin Buchholz wrote:
I think David is too pessimistic about Thread.yield being ineffective on
Java SE implementations (OTOH David is a Java Embedded expert). In
practice an implementation that never thread switched out of a yield() loop
would not pass the tck. As for theor
Hi -
I'm going to backport this (8028623 hashcode change, and testcase tweak
8032466) to jdk8u (and after that, to jdk7u). The same changesets work
and test fine.
8u webrev, planning to push to
http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot:
http://cr.openjdk.java.net/~kevinw/8028623/802
18 matches
Mail list logo
