Changeset: d587a5c30bd8
Author:coleenp
Date: 2013-04-24 16:19 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/d587a5c30bd8
8011803: release_C_heap_structures is never called for anonymous classes.
Summary: Call this function from the ClassLoaderData destructor inste
Changeset: fbca7eaeac2e
Author:zgu
Date: 2013-04-24 14:55 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/fbca7eaeac2e
8011218: Kitchensink hanged, likely NMT is to blame
Summary: Made NMT query safepoint aware.
Reviewed-by: dholmes, coleenp
! src/share/vm/services
Changeset: 8c06a38aa2c5
Author:sherman
Date: 2013-04-24 21:27 +
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c06a38aa2c5
8012638: test/java/time/test/java/util/TestFormatter fails in UTC TZ
Summary: updated the offending test case
Reviewed-by: alanb
! test/java/time/test/ja
Hi Frederic,
I reviewed the jdk webrev that is looking good. I reviewed
com.sun.management.DiagnosticCommandMBean spec almost half a year ago.
Reviewing it now with a fresh memory has some benefit that I have a few
comments on the spec.
java.lang.management.PlatformManagedObject is specifi
Changeset: bbcebf893b83
Author:alanb
Date: 2013-04-24 19:03 +0100
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bbcebf893b83
800: TEST_BUG: java/io/Serializable/accessConstants/AccessConstants.java
should be removed
Reviewed-by: chegar
- test/java/io/Serializable/accessConst
Hi David,
It was an urgent fix and didn't go through the "normal" route.
Thanks,
Jiangli
On 04/23/2013 09:32 PM, David Holmes wrote:
Jiangli,
I do not see a public Request for Review for this change.
David
On 24/04/2013 9:11 AM, jiangli.z...@oracle.com wrote:
Changeset: 1ea6a35dcbe5
Author
Changeset: cc70cbbd422e
Author:hseigel
Date: 2013-04-24 09:00 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/cc70cbbd422e
8012695: Assertion message displays %u and %s text instead of actual values
Summary: USe err_msg() to create a proper assertion message.
Review
Changeset: 754c9bb4f085
Author:sla
Date: 2013-04-24 14:49 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/754c9bb4f085
8009985: [parfait] Uninitialised variable at
jdk/src/solaris/native/com/sun/management/UnixOperatingSystem_md.c
Reviewed-by: sla, rbackman, alanb, dholmes, r
On 24/04/2013 10:40 PM, Rickard Bäckman wrote:
On Apr 24, 2013, at 2:25 PM, David Holmes wrote:
On 24/04/2013 9:05 PM, Rickard Bäckman wrote:
On Apr 24, 2013, at 12:11 PM, David Holmes wrote:
On 24/04/2013 7:09 PM, Rickard Bäckman wrote:
no it doesn't matter. Rather intended. By initializing
David,
On Apr 24, 2013, at 2:25 PM, David Holmes wrote:
> On 24/04/2013 9:05 PM, Rickard Bäckman wrote:
>> David,
>>
>> On Apr 24, 2013, at 12:11 PM, David Holmes wrote:
>>
>>> On 24/04/2013 7:09 PM, Rickard Bäckman wrote:
Nils,
no it doesn't matter. Rather intended. By initiali
Peter
You may not know me and I may not be an official reviewer of your code.
I have looked at your change and it looks good .
Ron Durbin
> -Original Message-
> From: Peter Allwin
> Sent: Wednesday, April 24, 2013 3:31 AM
> To: serviceability-dev serviceability-dev@openjdk.java.net;
>
On 24/04/2013 9:05 PM, Rickard Bäckman wrote:
David,
On Apr 24, 2013, at 12:11 PM, David Holmes wrote:
On 24/04/2013 7:09 PM, Rickard Bäckman wrote:
Nils,
no it doesn't matter. Rather intended. By initializing it to NULL we forced
implementors to use a pointer that would have to be initiali
Indeed!
Thank you all for your reviews,
/peter
David HolmesWednesday, April 24, 2013 12:16 PM
+1 from me but I'm surprised this code doesn't
always report an error -
must be pure chance that the uninitialized value == KERN_SUCCESS
David
Peter AllwinWednesday, April 24, 2013 11
David,
On Apr 24, 2013, at 12:11 PM, David Holmes wrote:
> On 24/04/2013 7:09 PM, Rickard Bäckman wrote:
>> Nils,
>>
>> no it doesn't matter. Rather intended. By initializing it to NULL we forced
>> implementors to use a pointer that would have to be initialized at some
>> point. Now it can be
+1 from me but I'm surprised this code doesn't always report an error -
must be pure chance that the uninitialized value == KERN_SUCCESS
David
On 24/04/2013 7:31 PM, Peter Allwin wrote:
Hi all, I'm looking for reviews of this change:
Parfait has identified an incorrect return code comparison
On 24/04/2013 7:09 PM, Rickard Bäckman wrote:
Nils,
no it doesn't matter. Rather intended. By initializing it to NULL we forced
implementors to use a pointer that would have to be initialized at some point.
Now it can be a class / struct
that is instead initialized by a default constructor.
Hi Rickard,
On 24/04/2013 5:51 PM, Rickard Bäckman wrote:
Hi all,
can I have a couple of reviews for this small change. The short story is that
the current way the thread-local _trace_buffer is somewhat inflexible.
By changing the type of the getter this structure gets more flexible for
diffe
On 24/04/2013 10:31, Peter Allwin wrote:
Hi all, I'm looking for reviews of this change:
Parfait has identified an incorrect return code comparison in
UnixOperatingSystemMXBean getOpenFileDescriptorCount on OSX. Very
simple fix is to check against the correct variable.
CR: http://cr.openjdk.
Peter,
the change looks good to me (not a Reviewer).
I know it is against the local style of the file, but I would prefer if we
declared and initialized the variables at first use, and in that way reduced
chances of this kind of mistakes.
/R
On Apr 24, 2013, at 11:31 AM, Peter Allwin wrote:
>
Hi all, I'm looking for reviews of this change:
Parfait has identified an incorrect return code comparison in
UnixOperatingSystemMXBean getOpenFileDescriptorCount on OSX. Very simple
fix is to check against the correct variable.
CR: http://cr.openjdk.java.net/~sla/peter/8009985/webrev.00/
JBS
Nils,
no it doesn't matter. Rather intended. By initializing it to NULL we forced
implementors to use a pointer that would have to be initialized at some point.
Now it can be a class / struct
that is instead initialized by a default constructor.
/R
On Apr 24, 2013, at 10:45 AM, Nils Loodin wro
Does it matter that the pointer gets initialized to NULL before, but not
now? There isn't any null checks anywhere that depends on that?
Regards,
Nils
On 04/24/2013 09:51 AM, Rickard Bäckman wrote:
Hi all,
can I have a couple of reviews for this small change. The short story is that
the curr
Hi all,
can I have a couple of reviews for this small change. The short story is that
the current way the thread-local _trace_buffer is somewhat inflexible.
By changing the type of the getter this structure gets more flexible for
different implementations. I also think that the name is misused.
23 matches
Mail list logo
