I'm withdrawing this RFR for 12.
dl
On 1/28/19 5:13 PM, dean.l...@oracle.com wrote:
http://cr.openjdk.java.net/~dlong/8195635/webrev.5/
https://bugs.openjdk.java.net/browse/JDK-8195635
Please see the bug report for all the gory details. Here's the short
version:
If we allow any safepoint t
Ok, so you can't do a "cont" because threads are not suspended. That
means someone resumed them. When/where was this done?
Regarding threadIDs changing, my guess is that debugLoop_run() is
re-entered when the new connection is established. This will result in
commonRef_reset() being called, wh
Issuing a "cont" in the second session does not work, because
the threads are not suspended.
It's interesting that the thread ids have all changed in
the reconnected session.
...
main[1] threads
Group system:
(java.lang.ref.Reference$ReferenceHandler)0x374 Reference Handler running
(java.la
Thank you Chris and JC for reviewing this change.
Best regards,
Daniil
From: Jean Christophe Beyler
Date: Tuesday, January 29, 2019 at 12:09 PM
To: Daniil Titov
Cc: OpenJDK Serviceability , Chris Plummer
Subject: Re: RFR 8163127: Debugger classExclusionFilter does not work correctly
w
Hi Daniil,
I like this fix much better to be honest :)
Jc
On Tue, Jan 29, 2019 at 11:40 AM Daniil Titov
wrote:
> Hi JC,
>
> Could you please say are you OK with this new version of the fix?
>
> Thanks!
> --Daniil
>
>
> On 1/26/19, 11:35 AM, "Chris Plummer" wrote:
>
> Looks good.
>
> t
Hi JC,
Could you please say are you OK with this new version of the fix?
Thanks!
--Daniil
On 1/26/19, 11:35 AM, "Chris Plummer" wrote:
Looks good.
thanks,
Chris
On 1/26/19 11:23 AM, Daniil Titov wrote:
> Hi Chris,
>
> Please review a new version of
What is the state of the threads after the detach? If they are all
automatically resumed by the agent, then I think the unblocking should
be done by the same code that resumes the threads. If they are still
suspended, then why would we want to unblock when the next connection
comes in? It shoul
As far as I can tell, the quit and exit commands are only handled locally
on the debugger side of the connection. There is no packet sent to the
libjdwp agentlib.
On 1/29/19, 12:17 PM, Chris Plummer wrote:
Hi Gary,
When the "exit" or "quit" is done, aren't all threads resumed at that
point, an
Hi Gary,
When the "exit" or "quit" is done, aren't all threads resumed at that
point, and shouldn't that result in the command loop being unblocked?
thanks,
Chris
On 1/29/19 8:09 AM, Gary Adams wrote:
Significant protections are put in place to protect the commandLoop
from multiple events t
Oops, ignore that last message!
On Tue, 29 Jan 2019 at 15:41, David Griffiths wrote:
>
> Oh, I'm looking at the jdk8u code which has the following code commented out:
>
> /*
> if (map.getUpdateMap()) {
> // Tell GC to use argument oopmaps for some runtime stubs that need it.
>
Significant protections are put in place to protect the commandLoop
from multiple events that that have a suspend-all policy. The
commandLoop uses a special block variable to ensure only
a VirtualMachine or ThreadReference call to resume() will unblock
the commandLoop. See
src/jdk.jdwp.agent/sh
Oh, I'm looking at the jdk8u code which has the following code commented out:
/*
if (map.getUpdateMap()) {
// Tell GC to use argument oopmaps for some runtime stubs that need it.
// For C1, the runtime stub might not have oop maps, so set this flag
// outside of update_re
On 1/29/19 11:24 AM, David Griffiths wrote:
> Hi, in CompiledVFrame.createStackValue there is the following code:
>
> // First find address of value
> Address valueAddr = loc.isRegister()
> // Value was in a callee-save register
> ? getRegisterMap().getLocation(new VMRe
Hi, in CompiledVFrame.createStackValue there is the following code:
// First find address of value
Address valueAddr = loc.isRegister()
// Value was in a callee-save register
? getRegisterMap().getLocation(new VMReg(loc.getRegisterNumber()))
// Else value was di
14 matches
Mail list logo
