Just for the record ...
On 23/11/2017 6:20 PM, Robbin Ehn wrote:
Thanks Dan for dragging this freight train to the docks, it's time to
ship it!
I agree. The latest delta seems fine to me.
Created follow-up bug:
8191809: Threads::number_of_threads() is not 'MT-safe'
https://bugs.openjdk.java.
Hi Kumar,
Thanks for looking at my change!
> I looked at some of the components I maintain, and they look good.
May I ask which these are? So I can account whether all parts have been
reviewed?
> 1. The local variables/fields don't comply with the coding conventions,
> we have been
> fo
Thank you very much, Serguei and Sharath, for the quick reviews.
- Jini.
On 11/28/2017 12:42 PM, serguei.spit...@oracle.com wrote:
Hi Jini,
Looks good.
Thanks,
Serguei
On 11/27/17 22:54, Jini George wrote:
Hello,
Please review the following simple modification to unquarantine the SA
test
Hi,
I uploaded a new webrev:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.04/
This includes the changes
- to jshell requested by Robert
- to the test as requested by Kumar.
See also incremental patch and the test output including all the
help messages referenced in the
Hi Serguei,
Thanks for the review.
/Erik
On 2017-11-28 06:43, serguei.spit...@oracle.com wrote:
Hi Erik,
This looks good to me.
Thanks,
Serguei
On 11/27/17 05:22, Daniel D. Daugherty wrote:
Adding serviceability-dev@... since this is JVM/TI related...
Dan
On 11/27/17 6:28 AM, Erik Öste
Hi Erik,
Thanks for your review!
All of the things that you mentioned should be addressed in the
following changes:
Differential:
http://cr.openjdk.java.net/~rkennke/8191564/webrev.05.diff/
Full:
http://cr.openjdk.java.net/~rkennke/8191564/webrev.05/
Also, Erik D (H) was so kind to contribut
On 11/28/17 3:01 AM, David Holmes wrote:
Just for the record ...
On 23/11/2017 6:20 PM, Robbin Ehn wrote:
Thanks Dan for dragging this freight train to the docks, it's time to
ship it!
I agree. The latest delta seems fine to me.
Thanks!
Created follow-up bug:
8191809: Threads::number_o
Hi Roman,
This looks better now. Nice job.
I wonder though, is it possible to extract the creation of managers and
pools to a separate function for each collected heap?
Now I see managers are created in e.g. CMS constructor, and the pools
are created in CMSHeap::initialize(). Perhaps initialize
Hi Yasumasa,
This isn't code I know very well, and I'm not a Reviewer. Just a
couple of observations.
I wonder if the person who originally suggested this change
realized the disruption it would have to existing switch
statements. I'm not sayin
On 28/11/2017 5:35 PM, Yasumasa Suenaga wrote:
http://cr.openjdk.java.net/~ysuenaga/JDK-8165736/webrev.06/
The update looks good to me.
Serguei, do we need CSR?
After some thinking, I'd say - Not.
Thanks Serguei!
David, can I list you as a reviewer?
I guess that latest webrev is re
Hi Erik,
thank you for reviewing!
You are right. I think this is a leftover from when we tried to pass the
GCMemoryManager* into the Generation constructor. The way it is done now
(installing the GCMmemoryManager* later through set_memory_manager()) we
can group all serviceability related set
Hi Sharath,
Do we have any other examples of testing SA tool classes in this
manner? I couldn't find any. I don't see any tests that directly
test the classes in the sun/jvm/hotspot/tools. Instead I think we
rely on testing the tools that use them such as j
Hi Chris,
2017-11-29 5:32 GMT+09:00 Chris Plummer :
> Hi Yasumasa,
>
> This isn't code I know very well, and I'm not a Reviewer. Just a couple of
> observations.
>
> I wonder if the person who originally suggested this change realized the
> disruption it would have to existing switch statements. I
On 11/28/17 4:51 PM, Yasumasa Suenaga wrote:
Hi Chris,
2017-11-29 5:32 GMT+09:00 Chris Plummer :
Hi Yasumasa,
This isn't code I know very well, and I'm not a Reviewer. Just a couple of
observations.
I wonder if the person who originally suggested this change realized the
disruption it would h
Hi Chris,
> I understood the reason for getting rid of the case statements. I was just
> wondering if you weighed this code disruption vs. the value of what you are
> fixing.
Jini has pointed it as below and I agree with him:
http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-October
On 11/28/17 5:23 PM, Yasumasa Suenaga wrote:
Hi Chris,
I understood the reason for getting rid of the case statements. I was just
wondering if you weighed this code disruption vs. the value of what you are
fixing.
Jini has pointed it as below and I agree with him:
http://mail.openjdk.java.net
Hi Chris,
> What I'm asking is
> now that you've implemented it and seen the disruption to the switch
> statements (which I assume you and Jini were not aware of before embarking
> on this), is it still worth doing? It's not really that big of a deal to me.
> I just want to make sure it's been tak
Hi Chris,
Thank you for raising this. I agree it is disruptive, but we are trying
to address the issue of frequent SA breakages with hotspot changes, and
the causes of these breakages. One of the reasons is the redefinition of
constants, which is extremely error prone. There have been multiple
On 29/11/2017 4:19 PM, Jini George wrote:
Hi Chris,
Thank you for raising this. I agree it is disruptive, but we are trying
to address the issue of frequent SA breakages with hotspot changes, and
the causes of these breakages. One of the reasons is the redefinition of
constants, which is extr
Hi Roman,
Looks good now. Thanks for doing this.
Thanks,
/Erik
On 2017-11-28 22:26, Roman Kennke wrote:
Hi Erik,
thank you for reviewing!
You are right. I think this is a leftover from when we tried to pass
the GCMemoryManager* into the Generation constructor. The way it is
done now (insta
20 matches
Mail list logo
