Hi David,
On 16/07/2020 06:37, David Holmes wrote:
Hi Jamsheed,
tl;dr version: fix looks good. Thanks for working through things with
me on this one.
Long version ... for the sake of other reviewers (and myself) I'm
going to walk through the problem scenario and how the fix addresses
it,
(Thank you Dean, adding serviceability team as this issue involves JVMTI
features PopFrame, EarlyReturn features)
JBS entry: https://bugs.openjdk.java.net/browse/JDK-8246381
(testing: mach5, tier1-5 links in JBS)
Best regards,
Jamsheed
On 15/07/2020 21:25, Jamsheed C M wrote:
Hi,
Async
Hi David,
On 16/07/2020 05:20, David Holmes wrote:
Hi Jamsheed,
On 16/07/2020 8:16 am, Jamsheed C M wrote:
(Thank you Dean, adding serviceability team as this issue involves
JVMTI features PopFrame, EarlyReturn features)
It is not at all obvious how your proposed fix impacts the JVM TI
Hi David,
On 16/07/2020 05:20, David Holmes wrote:
Hi,
Async handling at method entry requires it to be aware of
synchronization(like whether it is doing async handling before lock
acquire or after)
This is required as exception handler rely on this info for
unlocking. Async handling
Hi Jamsheed,
tl;dr version: fix looks good. Thanks for working through things with me
on this one.
Long version ... for the sake of other reviewers (and myself) I'm going
to walk through the problem scenario and how the fix addresses it,
because the bug report is long and confusing and
Hi Jamsheed,
On 16/07/2020 8:16 am, Jamsheed C M wrote:
(Thank you Dean, adding serviceability team as this issue involves JVMTI
features PopFrame, EarlyReturn features)
It is not at all obvious how your proposed fix impacts the JVM TI features.
JBS entry:
Hi Coleen,
Thank you for the explanation.
Thanks,
Serguei
On 7/15/20 12:45, coleen.phillim...@oracle.com wrote:
Thank you for reviewing this, Serguei.
On 7/15/20 1:33 PM, serguei.spit...@oracle.com wrote:
Hi Coleen,
The update looks okay to me.
Also, I wonder what should happen to the
Thank you for reviewing this, Serguei.
On 7/15/20 1:33 PM, serguei.spit...@oracle.com wrote:
Hi Coleen,
The update looks okay to me.
Also, I wonder what should happen to the JvmtiExport::weak_oops_do().
Unfortunately, JvmtiExport::weak_oops_do() calls
JvmtiTagMap::weak_oops_do which ends
Thank you Zhengyu.
Coleen
On 7/15/20 2:35 PM, Zhengyu Gu wrote:
Hi Coleen,
Shenandoah part looks good.
Thanks,
-Zhengyu
On 7/15/20 11:38 AM, coleen.phillim...@oracle.com wrote:
Hi, This patch has been reviewed and I was waiting for the ability to
define different OopStorages, but I'd
Serguei, David,
thanks for your review! pushed to jdk15.
-- Igor
> On Jul 14, 2020, at 5:25 PM, serguei.spit...@oracle.com wrote:
>
> Hi Igor,
>
> LGTM++
>
> Thanks,
> Serguei
>
>
> On 7/14/20 16:41, David Holmes wrote:
>> Hi Igor,
>>
>> LGTM.
>>
>> (Sorry I skipped this one yesterday.
Thanks Serguei, pushed to jdk15.
-- Igor
> On Jul 14, 2020, at 5:38 PM, serguei.spit...@oracle.com wrote:
>
> Hi Igor,
>
> LGTM.
>
> Thanks,
> Serguei
>
>
> On 7/13/20 16:22, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev/8249034/webrev.00/
>>> 1289 lines changed: 2 ins; 652
Hi David,
thanks for your review, pushed to jdk15.
-- Igor
> On Jul 14, 2020, at 9:01 PM, David Holmes wrote:
>
> Hi Igor,
>
> Looks good to me.
>
> On 15/07/2020 9:29 am, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev/8249040/webrev.00/
>>> 135 lines changed: 2 ins; 63 del;
Hi Coleen,
Shenandoah part looks good.
Thanks,
-Zhengyu
On 7/15/20 11:38 AM, coleen.phillim...@oracle.com wrote:
Hi, This patch has been reviewed and I was waiting for the ability to
define different OopStorages, but I'd like to fix that in a further
change after the GC changes have been
Hi Coleen,
The update looks okay to me.
Also, I wonder what should happen to the JvmtiExport::weak_oops_do().
Thanks,
Serguei
On 7/15/20 08:38, coleen.phillim...@oracle.com wrote:
Hi, This patch has been reviewed and I was waiting for the ability to
define different OopStorages, but I'd
Hi, This patch has been reviewed and I was waiting for the ability to
define different OopStorages, but I'd like to fix that in a further
change after the GC changes have been agreed upon and reviewed. Adding
a new JVMTI OopStorage in the new mechanism is a smaller change.
open webrev at
Hello Severin ,
> the new cgroups implementation
> supporting v1 and v2 Metrics.getMemoryAndSwapLimit() will never return 0
Wouldn’t it be possible that the coding of getMemoryAndSwapLimit returns a
negative value (might not happen on a "healthy" system but you never know) :
Anyone?
On Mon, 2020-06-29 at 17:53 +0200, Severin Gehwolf wrote:
> Hi,
>
> Could I please get a review of this dead-code removal? During review of
> JDK-8244500 it was discovered that with the new cgroups implementation
> supporting v1 and v2 Metrics.getMemoryAndSwapLimit() will never return
>
Upload a new webrev at
http://cr.openjdk.java.net/~lzang/jmap-8214535/8215624/webrev_07/
It fix a potential issue that unexpected number of threads maybe calculated
for "parallel" option of jmap -histo in container.
As shown at
18 matches
Mail list logo
