Hi Serguei,
> I tested it on Linux and Windows but not yet on MacOS.
The test succeeded now on all platforms.
Thanks, Richard.
-Original Message-
From: Reingruber, Richard
Sent: Freitag, 24. Juli 2020 15:04
To: serguei.spit...@oracle.com; serviceability-dev@openjdk.java.net
Subject:
Hi Bob,
On Fri, 2020-07-24 at 15:21 -0400, Bob Vandette wrote:
> I’ve been monitoring the discussion on your jdk8u alias and I can’t help
> wondering if
> my original decision to provide two different implementations of this
> container detection
> logic was the best way to go.
>
> I didn’t wan
> On Jul 27, 2020, at 11:32 AM, Severin Gehwolf wrote:
>
> Hi Bob,
>
> On Fri, 2020-07-24 at 15:21 -0400, Bob Vandette wrote:
>> I’ve been monitoring the discussion on your jdk8u alias and I can’t help
>> wondering if
>> my original decision to provide two different implementations of this
On Mon, 2020-07-27 at 11:52 -0400, Bob Vandette wrote:
> > On Jul 27, 2020, at 11:32 AM, Severin Gehwolf wrote:
> >
> > Hi Bob,
> >
> > On Fri, 2020-07-24 at 15:21 -0400, Bob Vandette wrote:
> > > I’ve been monitoring the discussion on your jdk8u alias and I can’t help
> > > wondering if
> > >
Thanks Kevin.
Can I get one more reviewer please?
Chris
On 7/24/20 2:17 AM, Kevin Walls wrote:
Thanks Chris - all sounds good to me. Thanks for all the MachO
insights...
On 23/07/2020 22:27, Chris
Ping! This one is pretty easy. I just changed the two tools to no longer
refuse to run on OSX if we are debugging a core file, and updated the
tests to also do a test run on a core file.
thanks,
Chris
On 7/21/20 1:13 PM, Chris Plummer wrote:
Hello,
Please help review the following:
https:/
Hello,
Another module, another set of default constructors to replace with
explicit ones. Please review the code changes and CSR to address:
JDK-8250640: Address reliance on default constructors in jdk.jdi
webrev: http://cr.openjdk.java.net/~darcy/8250640.0/
CSR: https://bugs.openj
Hi Chris,
Looks good to me.
--alex
On 07/27/2020 12:11, Chris Plummer wrote:
Ping! This one is pretty easy. I just changed the two tools to no longer
refuse to run on OSX if we are debugging a core file, and updated the
tests to also do a test run on a core file.
thanks,
Chris
On 7/21/20
Hi Chris,
LGTM++
Thanks,
Serguei
On 7/27/20 14:45, Alex Menkov wrote:
Hi Chris,
Looks good to me.
--alex
On 07/27/2020 12:11, Chris Plummer wrote:
Ping! This one is pretty easy. I just changed the two tools to no
longer refuse to run on OSX if we are debugging a core file, and
updated th
Thanks Alex and Serguei!
I still need another reviewer for JDK-8247515 before I can push this
change since it depends on the fixes done there.
Chris
On 7/27/20 3:23 PM, serguei.spit...@oracle.com wrote:
Hi Chris,
LGTM++
Thanks,
Serguei
On 7/27/20 14:45, Alex Menkov wrote:
Hi Chris,
Loo
Hi Chris,
The fix looks okay to me.
Nit:
http://cr.openjdk.java.net/~cjplummer/8247515/webrev.03/src/jdk.hotspot.agent/macosx/native/libsaproc/symtab.c.udiff.html
+uintptr_t offset = lentry.n_value; // offset of the symbol code/data in the f
Hi Joe,
The update looks okay to me too.
Thanks,
Serguei
On 7/25/20 11:18, Alan Bateman wrote:
On 25/07/2020 18:52, Joe Darcy wrote:
Hello,
I'm not positive serviceability-dev is the best alias for this
review; if not, please direct me elsewhere.
In any case, please review the changes an
On 7/27/20 4:40 PM,
serguei.spit...@oracle.com wrote:
Hi Chris,
The fix looks okay to me.
Nit:
http://cr.openjdk.java.net/~cjplummer/8247515/webrev.03/src/jdk.hotspot.agent/macosx/native/libsaproc/symtab.c.ud
Okay, thank you for explanations.
Serguei
On 7/27/20 16:53, Chris Plummer wrote:
On 7/27/20 4:40 PM, serguei.spit...@oracle.com wrote:
Hi Chris,
The fix looks okay to me.
Nit:
Hi
Could you please review following fix which suspends debugger VM while
enabling/disabling events.
All changed tests fail intermittently getting unexpected events instead of
breakpoint used for communication between debugger/debuggee VM. The tests
request different events and verify request
Hello,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8247516
http://cr.openjdk.java.net/~cjplummer/8247516/webrev.00/index.html
I put all the details in the description of the CR, including some
background on how symbol lookups are done, including what LoadObjects
are
I should have mentioned that currently there is no testing of this code.
There will with the changes for [1] JDK-8247514, which will add the lost
clhsdb "whatis" functionality, which was lost when JavaScript support
went away. "whatis" used DSO.closestSymbolToPC(), so as part of
JDK-8247514 I'm
Hi Leonid,
The fix looks good in general.
You missed to explain that the suspend/resume are added to avoid
actual generation of event that cause this issue.
The reason is that these events are not actually required.
http://cr.openjdk.java.net
On 27/07/2020 21:42, Joe Darcy wrote:
Hello,
Another module, another set of default constructors to replace with
explicit ones. Please review the code changes and CSR to address:
JDK-8250640: Address reliance on default constructors in jdk.jdi
webrev: http://cr.openjdk.java.net/~da
19 matches
Mail list logo
