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
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
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 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
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 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
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.
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
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,
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.
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'
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
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 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: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
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
:
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
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
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:
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
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.
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
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
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
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
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 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
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
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
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
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
- 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
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
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
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()
##
ubmit repo
(mach5-one-ysuenaga-JDK-8248362-20200722-1249-12859056), and
vmTestbase/nsk/{jdi,jdw,jvmti}, serviceability/{jdwp,jvmti} .
Thanks,
Yasumasa
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
37 matches
Mail list logo
