Hi Kevin,
Thanks for the review. Unfortunately there was yet another bug
which I have now addressed. Although testing with mach5 went fine,
when I tried with a local build I had issues. SA couldn't even get
past an early part of the core file handling which
ubmit repo
(mach5-one-ysuenaga-JDK-8248362-20200722-1249-12859056), and
vmTestbase/nsk/{jdi,jdw,jvmti}, serviceability/{jdwp,jvmti} .
Thanks,
Yasumasa
Hi Paul,
Thanks for your help, that all looks good to me.
Just 2 minor changes:
• delete the final return in ParHeapInspectTask::work, you mentioned it
but seems not include in the webrev :-)
• delete a unnecessary blank line in heapInspect.cpp at merge_entry()
##
ation() JVMTI functions.
This change has passed all tests on submit repo
(mach5-one-ysuenaga-JDK-8248362-20200722-1249-12859056), and
vmTestbase/nsk/{jdi,jdw,jvmti}, serviceability/{jdwp,jvmti} .
Thanks,
Yasumasa
d not fire.
Yasumasa
Thanks,
David
This change has passed all tests on submit repo
(mach5-one-ysuenaga-JDK-8248362-20200722-1249-12859056), and
vmTestbase/nsk/{jdi,jdw,jvmti}, serviceability/{jdwp,jvmti} .
Thanks,
Yasumasa
- VM_GetFrameLocation
They affects both GetFrameCount() and GetFrameLocation() JVMTI functions.
This change has passed all tests on submit repo
(mach5-one-ysuenaga-JDK-8248362-20200722-1249-12859056), and
vmTestbase/nsk/{jdi,jdw,jvmti}, serviceability/{jdwp,jvmti} .
Thanks,
Yasumasa
target thread is suspended");
and that assert must surely fire if called by the current thread for
itself! ???
Thanks,
David
This change has passed all tests on submit repo
(mach5-one-ysuenaga-JDK-8248362-20200722-1249-12859056), and
vmTestbase/nsk/{jdi,jdw,jvmti}, serviceability/{j
Forwarded Message
Subject: Re: jdk/submit maintenance, July 23rd - July 27th
Date: Wed, 22 Jul 2020 21:39:40 -0400
From: Stanislav Smirnov
To: jdk-dev
Hello,
Due to circumstances beyond our control the planned maintenance is
called off.
This means, that jdk/submit will c
tFrameLocation() JVMTI functions.
This change has passed all tests on submit repo
(mach5-one-ysuenaga-JDK-8248362-20200722-1249-12859056), and
vmTestbase/nsk/{jdi,jdw,jvmti}, serviceability/{jdwp,jvmti} .
Thanks,
Yasumasa
changes, I do not need to see another webrev.
Dan
Migrate JVMTI frame operations to Thread-Local Handshakes from VM
Operations.
- VM_GetFrameCount
- VM_GetFrameLocation
They affects both GetFrameCount() and GetFrameLocation() JVMTI functions.
This change has passed all tests o
Hi Coleen,
The fix looks good to me.
On 7/22/20 13:55, coleen.phillim...@oracle.com wrote:
Summary: Add an assert to OopHandle assigment operator to catch
leaking OopHandles, and fix code accordingly.
There are some jvmtiRedefineClasses.cpp changes here - basically, I
moved the RedefineVeri
oth GetFrameCount() and GetFrameLocation() JVMTI
functions.
This change has passed all tests on submit repo
(mach5-one-ysuenaga-JDK-8248362-20200722-1249-12859056), and
vmTestbase/nsk/{jdi,jdw,jvmti}, serviceability/{jdwp,jvmti} .
Thanks,
Yasumasa
Hi Thomas,
Thank you for the update, reply and 15 backport clarification.
The update looks good and the testing looks sufficient to me.
One minor suggestion:
http://cr.openjdk.java.net/~tschatzl/8249192/webrev.2/src/hotspot/share/runtime/biasedLock
Just in case people don't see the jdk-dev email.
David
-
Forwarded Message
Subject: jdk/submit maintenance, July 23rd - July 27th
Date: Wed, 22 Jul 2020 15:26:30 -0400
From: Stanislav Smirnov
To: jdk-dev
Hello,
A planned maintenance will happen this week, July 23rd - 2
Summary: Add an assert to OopHandle assigment operator to catch leaking
OopHandles, and fix code accordingly.
There are some jvmtiRedefineClasses.cpp changes here - basically, I
moved the RedefineVerifyMark and comments into jvmtiRedefineClasses.cpp
because I needed a Handle.
Ran tier1-6 tes
Hi Goetz,
> Thanks for the quick reply.
Yes, this time it didn't take that long...
[... snip ...]
> > > > > I understand you annotate at safepoints where the escape analysis
> > > > > finds out that an object is "better" than global escape.
> > > > > This are the cases where the analysis identi
Hi Goetz,
> > I'll answer to the obvious things in this mail now.
> > I'll go through the code thoroughly again and write
> > a review of my findings thereafter.
> As promised a detailed walk-throug, but without any major findings:
> c1_IR.hpp: ok
> ci_Env.h|cpp: ok
> compiledMethod.cpp, nmethod.
jdk15:
http://cr.openjdk.java.net/~tschatzl/8249192/webrev.jdk15.2/ (full)
src/hotspot/share/prims/jvmtiEnvBase.cpp
old L1029: ResourceMark rm;
It's not clear (to me anyway) why this ResourceMark is removed.
Update: I saw the discussion of "ResourceMark rm" in JDK15
Thank you, Serguei and Alex, for reviewing this change. I will apply suggested
corrections before pushing the fix.
Best regards,
Daniil
From: "serguei.spit...@oracle.com"
Date: Tuesday, July 21, 2020 at 10:53 PM
To: Daniil Titov , Alex Menkov
, serviceability-dev
Subject: Re: RFR:
Hi Richard,
Thanks for the quick reply.
> > > With DeoptimizeObjectsALot enabled internal threads are started that
> > > deoptimize frames and
> > > objects. The number of threads started are given with
> > > DeoptimizeObjectsALotThreadCountAll and
> > > DeoptimizeObjectsALotThreadCountSing
:
Hi all,
I'm working for fixing JDK-8248362, but I saw some errors on submit repo.
Someone can share the details of
mach5-one-ysuenaga-JDK-8248362-20200722-0550-12850261 ?
I wonder why build task of linux-x64 was failed because I can do it on my
Fedora 32 box.
[2020-07-22T06:21:49
affects both GetFrameCount() and GetFrameLocation() JVMTI functions.
This change has passed all tests on submit repo
(mach5-one-ysuenaga-JDK-8248362-20200722-1249-12859056), and
vmTestbase/nsk/{jdi,jdw,jvmti}, serviceability/{jdwp,jvmti} .
Thanks,
Yasumasa
On 7/22/20 8:11 AM, coleen.phillim...@oracle.com wrote:
On 7/22/20 4:21 AM, Thomas Schatzl wrote:
Hi,
On 22.07.20 02:42, David Holmes wrote:
Hi Thomas,
I've looked at the incremental update and I am happy with that.
In the response to Serguei's review there were some comment updates
and
On 7/22/20 8:44 AM, Erik Österlund wrote:
Hi Coleen,
This looks good to me. It's still a bit shady to me that assignment of
OopHandles overwrites the oop*, potentially causing memory leaks (the
previous oop* is not released).
Therefore, it is implied that setters are only used once, to stor
On 7/22/20 8:42 AM, David Holmes wrote:
On 22/07/2020 9:50 pm, coleen.phillim...@oracle.com wrote:
On 7/22/20 2:32 AM, David Holmes wrote:
Hi Coleen,
On 22/07/2020 12:19 am, coleen.phillim...@oracle.com wrote:
On 7/20/20 10:47 PM, David Holmes wrote:
Hi Coleen,
cc'ing serviceability du
On 22/07/2020 9:50 pm, coleen.phillim...@oracle.com wrote:
On 7/22/20 2:32 AM, David Holmes wrote:
Hi Coleen,
On 22/07/2020 12:19 am, coleen.phillim...@oracle.com wrote:
On 7/20/20 10:47 PM, David Holmes wrote:
Hi Coleen,
cc'ing serviceability due to SA changes.
On 21/07/2020 6:53 am, col
a-JDK-8248362-20200722-0550-12850261 ?
I wonder why build task of linux-x64 was failed because I can do it
on my Fedora 32 box.
[2020-07-22T06:21:49,141Z]
./open/src/hotspot/share/prims/jvmtiThreadState.cpp:222:45: error: no
member named 'active_handshaker' in 'JavaThread'
Ok, looks good to me.
Colen
On 7/21/20 10:46 PM, David Holmes wrote:
Hi Coleen,
On 22/07/2020 4:01 am, coleen.phillim...@oracle.com wrote:
This looks like a nice cleanup.
Thanks for looking at this.
http://cr.openjdk.java.net/~dholmes/8249650/webrev.v2/src/hotspot/share/runtime/jniHandles.
On 7/22/20 4:21 AM, Thomas Schatzl wrote:
Hi,
On 22.07.20 02:42, David Holmes wrote:
Hi Thomas,
I've looked at the incremental update and I am happy with that.
In the response to Serguei's review there were some comment updates
and new webrevs.
I also, prompted by you mentioning it,
On 7/22/20 2:32 AM, David Holmes wrote:
Hi Coleen,
On 22/07/2020 12:19 am, coleen.phillim...@oracle.com wrote:
On 7/20/20 10:47 PM, David Holmes wrote:
Hi Coleen,
cc'ing serviceability due to SA changes.
On 21/07/2020 6:53 am, coleen.phillim...@oracle.com wrote:
Summary: Move static oop
Thanks Chris, yes looks good, I like that we check the library bounds
before calling nearest_symbol.
--
Kevin
On 21/07/2020 21:05, Chris Plummer wrote:
Hi Serguei and Kevin,
The webrev has been updated:
http://cr.openjdk.java.net/~cjplummer/8247515/webrev.02/index.html
https://bugs.openjdk.
Hi Goetz,
> I'll answer to the obvious things in this mail now.
> I'll go through the code thoroughly again and write
> a review of my findings thereafter.
Sure. If trimmed my citations to relevant parts.
> > The delta includes many changes in comments, renaming of names, etc. So
> > I'd like t
Hi,
On 22.07.20 02:42, David Holmes wrote:
Hi Thomas,
I've looked at the incremental update and I am happy with that.
In the response to Serguei's review there were some comment updates and
new webrevs.
I also, prompted by you mentioning it, took a deeper look at the
biased-locking code
Hi Serguei,
thanks for your review.
On 22.07.20 04:13, serguei.spit...@oracle.com wrote:
Hi Thomas,
The fix looks okay to me.
The 15 fix is identical to 16.
no :) It is very subtle. As mentioned, in jvmtiEnvBase.cpp in the
original code, in jdk15 we had:
line 1029: ResourceMark
On 2020/07/22 16:57, David Holmes wrote:
Hi Yasumasa,
On 22/07/2020 5:39 pm, Yasumasa Suenaga wrote:
Hi all,
I'm working for fixing JDK-8248362, but I saw some errors on submit repo.
Someone can share the details of
mach5-one-ysuenaga-JDK-8248362-20200722-0550-12850261 ?
I wonder why
Hi Yasumasa,
On 22/07/2020 5:39 pm, Yasumasa Suenaga wrote:
Hi all,
I'm working for fixing JDK-8248362, but I saw some errors on submit repo.
Someone can share the details of
mach5-one-ysuenaga-JDK-8248362-20200722-0550-12850261 ?
I wonder why build task of linux-x64 was failed beca
Hi all,
I'm working for fixing JDK-8248362, but I saw some errors on submit repo.
Someone can share the details of
mach5-one-ysuenaga-JDK-8248362-20200722-0550-12850261 ?
I wonder why build task of linux-x64 was failed because I can do it on my
Fedora 32 box.
Thanks,
Yasumasa
37 matches
Mail list logo
