Hi, since holding the Threads_lock while growing can block out safepoints for a
longer period, I would suggest just skip growing when holding Threads_lock.
E.g. return before creating the GrowTask.
/Robbin
On 2019-10-02 08:46, David Holmes wrote:
Hi Daniil,
On 2/10/2019 4:13 pm, Daniil Titov w
Hi David,
What if the table is full and must be grown?
The table uses chaining, it just means load factor tip over what is considered a
good backing array size.
That aside, I'd like to know how expensive it is to grow this table. What are we
talking about here?
We use global counter whic
Hi David,
On 2019-10-02 15:25, David Holmes wrote:
Hi Robbin,
On 2/10/2019 7:58 pm, Robbin Ehn wrote:
Hi David,
What if the table is full and must be grown?
The table uses chaining, it just means load factor tip over what is considered
a good backing array size.
Coleen raised a good
On 10/2/19, 6:25 AM, "David Holmes" wrote:
Hi Robbin,
On 2/10/2019 7:58 pm, Robbin Ehn wrote:
> Hi David,
>
>> What if the table is full and must be grown?
>
> The table uses chaining, it just means load factor tip over what
iil
>
>
> On 10/2/19, 6:25 AM, "David Holmes" wrote:
>
> Hi Robbin,
>
> On 2/10/2019 7:58 pm, Robbin Ehn wrote:
> > Hi David,
> >
> >> What if the table is full and must b
>> So this change does concern me. But go ahead and trial it.
>> Thanks,
>> David
>> > Thank you,
>> > Daniil
>> >
>> >
>> > On 10/2/19, 6:25
][info][thread,table] Grown to size:512
The test finished.
Execution time:15673 ms
[1] https://cr.openjdk.java.net/~dtitov/tests/ThreadStartupTest.java
Thanks!
Daniil
On 10/7/19, 12:34 AM, "Robbin Ehn" wrote:
Hi Daniil,
Yes, good, but:
>> &g
Looks good, thanks David!
/Robbin
On 11/18/19 3:30 AM, David Holmes wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8215355
webrev: http://cr.openjdk.java.net/~dholmes/8215355/webrev/
This was a very difficult bug to track down and I want to publicly acknowledge
and thank the jemalloc fo
Hi all, please review.
From issue, https://bugs.openjdk.java.net/browse/JDK-8235912:
JvmtiBreakpoints are walked via VMThread oops_do (the breakpoint is in a vm
operation) before they are installed in the safeopint and after they have been
installed, walked with JvmtiCurrentBreakpoints::oops_d
Hi Richard, as mentioned it would be better if you could do this with
handshakes, instead of using _suspend_flag (since they are going away).
But I can't think of a way doing it without blocking safepoints, so we need to
add some more features in handshakes first.
When possible I hope you are will
ims/jvmtiImpl.hpp.udiff.html
+ oop* _class_holder; // keeps _method memory from being deallocated
We created the class OopHandle to encapsulate strong oopStorage references,
although it's missing oop_store. Can you use that?
Coleen
On 12/16/19 4:47 AM, Robbin Ehn wrote:
Hi all, please revie
art_thread() {
15 _wait.signal();
16 while(!Atomic::load(&_started)) {
17 os::naked_yield();
18 }
19 }
20 };
-Original Message-
From: Robbin Ehn
Sent: Montag, 16. Dezember 2019 11:21
To: Reingruber, Richard ;
serviceability-dev@openjdk.j
ou use that?
Coleen
On 12/16/19 4:47 AM, Robbin Ehn wrote:
Hi all, please review.
From issue, https://bugs.openjdk.java.net/browse/JDK-8235912:
JvmtiBreakpoints are walked via VMThread oops_do (the breakpoint is in a vm
operation) before they are installed in the safeopint and after th
anks, Richard.
[1]
https://docs.oracle.com/en/java/javase/13/docs/specs/jvmti.html#SuspendThreadList
-Original Message-
From: Robbin Ehn
Sent: Montag, 16. Dezember 2019 18:21
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspo
.hpp.udiff.html
+ oop* _class_holder; // keeps _method memory from being deallocated
We created the class OopHandle to encapsulate strong oopStorage references,
although it's missing oop_store. Can you use that?
Coleen
On 12/16/19 4:47 AM, Robbin Ehn wrote:
Hi all, ple
Hi Coleen,
I looked at v2:
http://cr.openjdk.java.net/~coleenp/2019/8235829.01/webrev
Seems good.
But we do a lot of work to keep the nmethod alive while in queue.
Instead we should try copy the data from nmethod and enqueue this copy.
Thus not having to keep the nmethod alive.
Not for this cha
ssues, thanks!
/Robbin
Thanks,
Serguei
On 12/16/19 01:47, Robbin Ehn wrote:
Hi all, please review.
From issue, https://bugs.openjdk.java.net/browse/JDK-8235912:
JvmtiBreakpoints are walked via VMThread oops_do (the breakpoint is in a vm
operation) before they are installed in the safeopin
Hi,
On 2/24/20 5:39 PM, Lindenmaier, Goetz wrote:
Hi,
I had a look at the progress of this change. Nothing
happened since Richard posted his update using more
handshakes [1].
But we (SAP) would appreciate a lot if this change could
be successfully reviewed and pushed.
I think there is basic un
as_nmethod() in not_global_escape_in_scope() and arg_escape()
should better be under #ifdef ASSERT or inside the assert statement (no need for
code cache walking in product build).
Done.
jvmtiDeferredLocalVariableSet::update_monitors:
Please add a comment explaining that owner referenced by origi
Hi, adding the same comment as in the bug regarding
GetThreadListStackTraces.
Please note that there is a semantic difference taking samples in a
safepoint and in handshakes, if there are mutiple thread sampled.
With a safepoint; stacktraces are taken from the same exact moment (from
a Java muta
cks between the sampling one thread and the
next. The threads need not be suspended.
```
Thus I think we don't need describe release notes about it.
Thanks,
Yasumasa
On 2020/04/09 16:03, Robbin Ehn wrote:
Hi, adding the same comment as in the bug regarding
GetThreadListStackTraces.
Please
Ok, thanks for looking into it!
/Robbin
On 2020-04-09 09:39, Yasumasa Suenaga wrote:
On 2020/04/09 16:19, Robbin Ehn wrote:
Hi Yasumasa,
We have had internal requests doing GetThreadListStackTraces with
multiple threads with handshakes. Since you can sample hundreds of times
per second using
Hi all,
If the direct handshake is executed by the target thread, the JNI
local(s) are created in that thread but returned in the handshaking
thread.
They thus are not safe to use. (thread might even have exited by this
point)
Code:
http://cr.openjdk.java.net/~rehn/8247248/v1/webrev/
Unfortunat
Hi David,
On 2020-06-10 04:30, David Holmes wrote:
Hi Robbin,
On 10/06/2020 2:15 am, Robbin Ehn wrote:
Hi all,
If the direct handshake is executed by the target thread, the JNI
local(s) are created in that thread but returned in the handshaking
thread.
They thus are not safe to use. (thread
Hi Serguei, thanks!
Yes I'll add a comments.
Thanks, Robbin
On 2020-06-09 20:30, serguei.spit...@oracle.com wrote:
Hi Robbin,
Nice catch!
The fix looks good in general.
I'd be nice to add comments to explain why these global refs are created.
Thanks,
Serguei
On 6/9/20 09:15,
Hi David,
Honestly I think I'd like to see things reverted to the use of
calling_thread as done for the VMOperation previously. We know it is
functionally correct and it should also have the same performance profile.
Ok, sure. But I don't have time to do that before fork.
I'll fix that in 16 a
Hi Dan,
On 2020-06-10 15:09, Daniel D. Daugherty wrote:
This is a P2 bug so it can be pushed after the FC cutoff right?
Not sure, I put in P2 so I could do that if necessary.
/Robbin
Dan
Thanks,
David
Thanks, Robbin
Thanks,
David
Thanks, Robbin
Thanks,
David
-
Issue:
ht
Hi David and Serguei, (Dan feel free to chime in)
Honestly I think I'd like to see things reverted to the use of calling_thread as done for the VMOperation previously. We
know it is functionally correct and it should also have the same performance profile.
Done:
http://cr.openjdk.java.net/~reh
Hi Serguei,
Great, thanks!
FYI:
Now passed t1-5 (no new failures).
/Robbin
On 2020-06-10 19:54, serguei.spit...@oracle.com wrote:
Hi Robbin,
I like this variant and it looks good to me.
Thanks,
Serguei
On 6/10/20 06:57, Robbin Ehn wrote:
Hi David and Serguei, (Dan feel free to chime in
Hi Dan, fixed, thanks!
/Robbin
On 2020-06-10 21:59, Daniel D. Daugherty wrote:
On 6/10/20 9:57 AM, Robbin Ehn wrote:
Hi David and Serguei, (Dan feel free to chime in)
Honestly I think I'd like to see things reverted to the use of calling_thread as done for the VMOperation previously
Thanks Yasumasa!
/Robbin
On 2020-06-11 03:36, Yasumasa Suenaga wrote:
Hi Robbin,
Thanks for catch up this issue.
It looks good to me.
Yasumasa
On 2020/06/10 22:57, Robbin Ehn wrote:
Hi David and Serguei, (Dan feel free to chime in)
Honestly I think I'd like to see things reverted t
repo fork is happening, so am unclear whether this will
head to the right repo in time. :)
Thanks,
David
-
On 10/06/2020 11:57 pm, Robbin Ehn wrote:
Hi David and Serguei, (Dan feel free to chime in)
Honestly I think I'd like to see things reverted to the use of calling_thread as do
Hi Yasumasa,
Thanks for your effort doing this.
#1
GetFrameLocation
GetStackTrace
GetCurrentLocation (need to add BCI)
Should use exactly the same code since a stack trace with max_count = 1
and start_depth = depth/0 is the frame location and jvmtiFrameInfo
contain the correct information (+ ad
e
1592 } else {
I do not see any issues, so it seem reasonable, thanks.
Thanks, Robbin
Thanks,
Yasumasa
On 2020/06/30 19:23, Robbin Ehn wrote:
Hi Yasumasa,
Thanks for your effort doing this.
#1
GetFrameLocation
GetStackTrace
GetCurrentLocation (need to add BCI)
Should use exactly the
Hi Yasumasa,
You cannot take the MutexLocker mu(JvmtiThreadState_lock) with safepoint
checks inside a handshake.
We are missing a NoSafepointVerifier for handshakes.
(I have added this in my work in progress asynchronous handshake patch)
Also this can deadlock with the handshake semaphore.
(In
State_lock because it has a different locking
range from SR lock.
Thanks,
Yasumasa
On 2020/08/26 18:13, Robbin Ehn wrote:
Hi Yasumasa,
You cannot take the MutexLocker mu(JvmtiThreadState_lock) with
safepoint checks inside a handshake.
We are missing a NoSafepointVerifier for handshakes.
(I
2020/08/26 21:32, Robbin Ehn wrote:
Hi Yasumasa,
Yes that should work.
Can you please add assert where you removed the:
- MutexLocker mu(JvmtiThreadState_lock);
E.g.
+ // If we are in a handshake we only know that the requesting thread
should have locked it.
+ assert(SafepointSynchronize
Hi,
On 10/23/18 10:34 AM, David Holmes wrote:
Hi Serguei,
The VMThread is executing VM_HandshakeAllThreads which is not a safepoint
operation. There's no real way to tell from the stacks what it's stuck on.
I cannot find a thread that is not considered safepoint safe or is_ext_suspended
(th
e same deadlock scenario that I've already explained but
more sophisticated.
I suspect a scenario with JvmtiThreadState_lock that the flag
Monitor::_safepoint_check_always does not help much.
It can be verified by checking what monitors are used by the blocked threads.
Thanks,
Serguei
On
n 24/10/2018 5:18 PM, Robbin Ehn wrote:
Hi, truncate:
On 24/10/2018 02:00, serguei.spit...@oracle.com wrote:
One thing I noticed which Robbin should be able to expand upon is that
Thread 101 is terminating and has called ThreadsSMRSupport::smr_delete and
is blocked here:
// Wait for a releas
the places. Maybe it's just a couple.
/Robbin
Thanks,
Serguei
On 10/24/18 00:18, Robbin Ehn wrote:
Hi, truncate:
On 24/10/2018 02:00, serguei.spit...@oracle.com wrote:
One thing I noticed which Robbin should be able to expand upon is that
Thread 101 is terminating and has called Th
Hi sorry, the assert should be
assert(!t->have_threads_list(),)
We should not have a threads list :)
/Robbin
On 24/10/2018 11:18, Robbin Ehn wrote:
Hi Serguei,
On 24/10/2018 11:00, serguei.spit...@oracle.com wrote:
Hi Robbin and David,
There is no JvmtiEnv::SuspendThreadList call
leted(false /* !called_by_wait */,
SuspendRetryDelay, &debug_bits)) {
return;
}
}
VM_ThreadSuspend vm_suspend;
VMThread::execute(&vm_suspend);
}
I'll check with Leonid tomorrow if we can check if your patch below can fix
this deadlock.
Than
om:10067/mdash/jobs/lmesnik-ks-short-test-20181025-1842-7762?search=result.status%3APASSED
>
>I haven't run any other tests.
>
>Leonid
>> On Oct 25, 2018, at 6:15 AM, Robbin Ehn
>wrote:
>>
>> Hi, here is a fix, which allows ThreadsList to be used over a VM
Hi, please review.
When the VM thread executes a handshake it uses different ThreadsLists during
the execution. A JavaThread that is armed for the handshake when it is already
in the exit path in VM will cancel the handshake. Even if the VM thread cannot
see this thread after the initial ThreadsL
Thanks Erik!
/Robbin
On 26/10/2018 16:37, Erik Österlund wrote:
Hi Robbin,
Looks good.
Thanks,
/Erik
On 2018-10-26 16:33, Robbin Ehn wrote:
Hi, please review.
When the VM thread executes a handshake it uses different ThreadsLists during
the execution. A JavaThread that is armed for the
, Robbin Ehn wrote:
Hi, please review.
When the VM thread executes a handshake it uses different ThreadsLists during
the execution. A JavaThread that is armed for the handshake when it is already
in the exit path in VM will cancel the handshake. Even if the VM thread cannot
see this thread after the
Hi Dan,
Thanks for looking at this, here is the update:
Inc: http://cr.openjdk.java.net/~rehn/8212933/v2/inc/webrev/
Full: http://cr.openjdk.java.net/~rehn/8212933/v2/webrev/
/Robbin
On 26/10/2018 17:38, Daniel D. Daugherty wrote:
On 10/26/18 10:33 AM, Robbin Ehn wrote:
Hi, please review
Hi David,
On 29/10/2018 07:20, David Holmes wrote:
Hi Robbin,
On 29/10/2018 6:08 AM, Robbin Ehn wrote:
Hi Dan,
Thanks for looking at this, here is the update:
Inc: http://cr.openjdk.java.net/~rehn/8212933/v2/inc/webrev/
Full: http://cr.openjdk.java.net/~rehn/8212933/v2/webrev/
I can'
Thanks Dan!
/Robbin
On 29/10/2018 14:52, Daniel D. Daugherty wrote:
On 10/28/18 4:08 PM, Robbin Ehn wrote:
Hi Dan,
Thanks for looking at this, here is the update:
Inc: http://cr.openjdk.java.net/~rehn/8212933/v2/inc/webrev/
src/hotspot/share/runtime/handshake.cpp
No comments.
test
7:05 PM, Robbin Ehn wrote:
Hi David,
On 29/10/2018 07:20, David Holmes wrote:
Hi Robbin,
On 29/10/2018 6:08 AM, Robbin Ehn wrote:
Hi Dan,
Thanks for looking at this, here is the update:
Inc: http://cr.openjdk.java.net/~rehn/8212933/v2/inc/webrev/
Full: http://cr.openjdk.java.net/~rehn/8212933
Thanks Serguei, Robbin
On 10/29/18 6:35 PM, serguei.spit...@oracle.com wrote:
Hi Robbin,
+1
Thanks,
Serguei
On 10/29/18 06:52, Daniel D. Daugherty wrote:
On 10/28/18 4:08 PM, Robbin Ehn wrote:
Hi Dan,
Thanks for looking at this, here is the update:
Inc: http://cr.openjdk.java.net/~rehn
/browse/JDK-8221584
webrev: http://cr.openjdk.java.net/~dholmes/8221584/webrev/
I'm really just sponsoring this fix as the problem was diagnozed by Robbin
Ehn and Stefan Karlsson - thanks guys! :) So they are the contributors and
I'm already one Reviewer.
There's a missing lo
Hi, please review.
Old threads linked list remove and updated SA to use ThreadsList array instead.
Issue:
https://bugs.openjdk.java.net/browse/JDK-8223306
Webrev:
http://cr.openjdk.java.net/~rehn/8223306/webrev/
Passes t1-3 (which includes SA tests).
Thanks, Robbin
early
returns.
Thanks, Robbin
Thanks,
David
On 6/05/2019 5:31 pm, Robbin Ehn wrote:
Hi, please review.
Old threads linked list remove and updated SA to use ThreadsList array instead.
Issue:
https://bugs.openjdk.java.net/browse/JDK-8223306
Webrev:
http://cr.openjdk.java.net/~rehn/8223306/webrev/
Passes t1-3 (which includes SA tests).
Thanks, Robbin
hanks, it should not have been converted then.
I'll revisit CommandProcessor.java and the other sites.
/Robbin
Cheers,
David
-
Thanks, Robbin
Thanks,
David
On 6/05/2019 5:31 pm, Robbin Ehn wrote:
Hi, please review.
Old threads linked list remove and updated SA to
/inc/webrev/
Passes t1-2
Thanks, Robbin
On 2019-05-07 09:47, David Holmes wrote:
Hi Robbin,
On 7/05/2019 4:50 pm, Robbin Ehn wrote:
Hi David,
On 5/7/19 12:40 AM, David Holmes wrote:
Hi Robbin,
I have a few concerns here.
First I can't see how you are actually integrating the SA wit
/cr_mirror/8223306/v2/inc/webrev/
Passes t1-2
Thanks, Robbin
On 2019-05-07 09:47, David Holmes wrote:
Hi Robbin,
On 7/05/2019 4:50 pm, Robbin Ehn wrote:
Hi David,
On 5/7/19 12:40 AM, David Holmes wrote:
Hi Robbin,
I have a few concerns here.
First I can't see how you are actually integratin
. I hate it when my debugger crashes!
I removed all lambdas!
Thanks for looking at this, Robbin
That said, SA is pretty much standalone so use of lambdas in this
debugging tool shouldn't affect the JVM or core file being debugged.
Again, thumbs up!
Dan
/Robbin
On 2019-05-08 11:17, Rob
here you can. But you know my thoughts on it. :)
Removed!
Thanks, Robbin.
Thanks,
David
-
http://cr.openjdk.java.net/~rehn/8223306/v2/inc/webrev/
http://cr.openjdk.java.net/~rehn/8223306/v2/webrev/
/Robbin
On 2019-05-08 11:17, Robbin Ehn wrote:
Hi David,
I changed to normal for:
htt
8223306/v2/webrev/
/Robbin
On 2019-05-08 11:17, Robbin Ehn wrote:
Hi David,
I changed to normal for:
http://rehn-ws.se.oracle.com/cr_mirror/8223306/v2/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java.sdiff.html
Full:
http://rehn-ws.se.oracle.com/cr_mirror/8223306
Thanks Serguei!
/Robbin
On 2019-05-16 02:10, serguei.spit...@oracle.com wrote:
Hi Robbin,
Looks good to me.
Thanks,
Serguei
On 5/14/19 07:02, Robbin Ehn wrote:
Hi Dan,
Full:
http://cr.openjdk.java.net/~rehn/8223306/v3/webrev/index.html
Inc:
http://cr.openjdk.java.net/~rehn/8223306/v3/inc
~rehn/8223306/v3/inc/webrev/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java.sdiff.html
/Robbin
Coleen
On 5/15/19 9:20 AM, Robbin Ehn wrote:
On 2019-05-15 14:59, David Holmes wrote:
Lambdas removed!
I got caught out by the cumulative patch file again :(
Chan
Hi Dan,
Fixed below, thanks!
/Robbin
On 2019-05-20 20:20, Daniel D. Daugherty wrote:
On 5/14/19 10:02 AM, Robbin Ehn wrote:
Hi Dan,
Full:
http://cr.openjdk.java.net/~rehn/8223306/v3/webrev/index.html
Inc:
http://cr.openjdk.java.net/~rehn/8223306/v3/inc/webrev/index.html
src
Hi Daniil,
On 8/3/19 12:16 AM, Daniil Titov wrote:
The is_dead parameter still bothers me here. I can't make enough sense
out of the template code in ConcurrentHashtable to see why we have to
have it, but I'm concerned that its very existence means we perhaps
should not be trying to extend CHT i
de in ConcurrentHashtable to see why we have to
>> have it, but I'm concerned that its very existence means we perhaps
>> should not be trying to extend CHT in this context. ??
>
> My understanding is that is_dead parameter provides a mechanism for
>
Hi David,
Comments/opinions appreciated.
Had I quick look, seems reasonable.
And totally worth it since you removed the dependency on object monitors!
-#include "runtime/objectMonitor.hpp"
:)
Thanks for not giving up!
/Robbin
Thanks,
David
[1]
https://docs.oracle.com/en/java/javase/11
Hi Daniil,
Looks good, thanks!
/Robbin
On 9/25/19 12:45 AM, David Holmes wrote:
Looks good to me.
Thanks,
David
On 25/09/2019 2:36 am, Daniil Titov wrote:
Hi Daniel, David and Serguei,
Please review a new version of the fix (webrev.08) that as Daniel suggested
renames
ThreadTable to Threa
Hi,
To me the compiler changes looks what is expected.
It would be good if someone from compiler could take a look at that.
Added compiler to mail thread.
Also adding Serguei, It would be good with his view also.
My initial take on it, read through most of the code and took it for a ride.
TRANSPORT_VERSION_1_1:
+ err = (*trans)->StartListening11(trans, address, &retAddress,
info->allow);
+ break;
+ default:
+ err = JNI_EVERSION;
+ }
-Dmitry
Thanks, Serguei On 3/29/17 08:10, Dmitry Samersoff wrote:
Robbin,
One follow-up issue is that if you start suspended
and than
elease/images/jdk ../hotspot/test/serviceability/jvmti/HeapMonitor/
I'll test it out!
/Robbin
On Thu, May 4, 2017 at 11:21 PM, serguei.spit...@oracle.com
<mailto:serguei.spit...@oracle.com> mailto:serguei.spit...@oracle.com>> wrote:
Robbin,
Thank you f
Hi of those:
One more alternate solution to suggest is to add new function:
jdwpTransportError SetTransportConfiguration(jdwpTransportConfiguration config);
Where:
typedef struct {
const char* allowed_peers;
} jdwpTransportConfiguration;
This approach allows to extend the jdwpTra
Hi,
On 05/19/2017 08:27 AM, serguei.spit...@oracle.com wrote:
On 5/18/17 04:05, Robbin Ehn wrote:
Hi of those:
One more alternate solution to suggest is to add new function:
jdwpTransportError SetTransportConfiguration(jdwpTransportConfiguration config);
Where:
typedef struct
Hi,
The text stream originates from:
void Threads::print_on(outputStream* st, bool print_stacks, bool
internal_format, bool print_concurrent_locks) {
in hotspot/src/share/vm/runtime/thread.cpp L4491
and jstack only forwards that to your terminal.
/Robbin
On 05/25/2017 05:07 PM, Kirk Pepperdi
mvent AsyncGetCallTrace yet
- Still have to double check the stack walker a bit more
Looking forward to this.
Could someone from compiler take a look please?
Thanks!
/Robbin
Happy webrev perusal!
Jc
On Tue, May 16, 2017 at 5:20 AM, Robbin Ehn mailto:robbin@oracle.com>> wrote:
o see that it is consistent and
does gather the right samples, right frequency, etc.
- Have to check the GC elements and what that produces
- Run a slowdebug run and ensure I fixed all those issues you saw Robbin
As always, your comments and feedback are greatly appreciated! H
Hi again,
Forgot to say added Dan, he might be interested in JVMTI changes at least.
On 06/13/2017 11:19 AM, Robbin Ehn wrote:
To get a more potential users it's nice with a Java API and as you say
simplifies tests, good.
Obviously this is not a public API, but the code for doing it
Hi,
On 06/21/2017 10:45 PM, JC Beyler wrote:
Hi all,
First off: Thanks again to Robbin and Thomas for their reviews :)
Next, I've uploaded a new webrev:
http://cr.openjdk.java.net/~rasbold/8171119/webrev.06/
Here is an update:
- @Robbin, I forgot to say that yes I need to look at implementin
Hi,
On 06/28/2017 12:04 AM, JC Beyler wrote:
Dear Thomas et al,
Here is the newest webrev:
http://cr.openjdk.java.net/~rasbold/8171119/webrev.07/
You have some more bits to in there but generally this looks good and really
nice with more tests.
I'll do and deep dive and re-test this when I g
) Go to 1
Does that seem correct to you?
Note that when I do this, I only see the full change of a file in the full change set (Side note here: now the page says change set and not patch, which is maybe why
Serguei was having issues?).
Thanks!
Jc
On Wed, Jun 28, 2017 at 1:12 AM, Robbin Ehn
Hi Thomas,
First I want to thank you for helping out with this!
On 07/03/2017 02:44 PM, Thomas Schatzl wrote:
Hi,
On Wed, 2017-06-28 at 09:51 +0200, Robbin Ehn wrote:
Hi,
On 06/21/2017 10:45 PM, JC Beyler wrote:
Hi all,
First off: Thanks again to Robbin and Thomas for their reviews
Samersoff ; serviceability-
d...@openjdk.java.net; Robbin Ehn ; Daniel
Daugherty ; Alan Bateman
Subject: Re: RFR(M): 8061228 Allow JDWP socket connector to accept
connections from certain ip addresses only
Thanks, Dmitry!
I'm not sure, who is a reviewer in our case? :)
You are the author, aren
Hi,
FYI: It's been long since duke:
0: nonstatic_field(nmethod, _stack_traversal_mark,
long) \
It's now also volatile.
The correct type should/could probably be some like (u)int_fast32_t/intx or
whatever.
If there is
--
changeset: 47219:fd36993f7bf5
tag: tip
user: ihse
date: Fri Sep 15 09:18:00 2017 -0700
summary: 8187542: Remove superfluous *_TOPDIR variables
----
I've tested jshell and HSDB from this source.
Yasumasa
On 2017/09/18 2
Hi, if you use class file load hook you can add/remove public methods.
Since this is before the class have been published we don't know how it should
look.
Whether this is according to spec or not, I have no clue.
Is it on CFLH ?
/Robbin
On 10/16/2017 01:20 PM, David Holmes wrote:
Hi Thomas,
On 10/16/2017 03:31 PM, Alan Bateman wrote:
On 16/10/2017 14:21, Robbin Ehn wrote:
Hi, if you use class file load hook you can add/remove public methods.
Since this is before the class have been published we don't know how it should
look.
Whether this is according to spec or not, I ha
Thanks,
Jc
On Thu, Jun 29, 2017 at 10:01 PM, JC Beyler mailto:jcbey...@google.com>> wrote:
Thanks Robbin,
This seems to have worked. When I have the next webrev
ready, we will find out but I'm fairly confident it will work!
On 10/16/2017 05:44 PM, Alan Bateman wrote:
On 16/10/2017 14:55, Robbin Ehn wrote:
There is actually an issue, we start all transformation with 'on' disk version.
If the agent that did the addition of a public method e.g.
exits(removeTransformer) we can never re-transform it, inst
t easier to follow so I'm going
to take a stab at it this week.
Any other issues/comments?
Thanks!
Jc
On Mon, Oct 16, 2017 at 8:46 AM, Robbin Ehn mailto:robbin@oracle.com>> wrote:
Hi JC,
I saw a webrev.12 in the directory, with only test chan
for the initial prototype and for all your patches. Erik,
hopefully we got far enough in your crazy vision... :-)
Thanks to my co-contributor Robbin Ehn for proposing that we do early
code reviews in the form of patches. Don't like something? Fix it with
a patch and a new test if appropriate!!
Looks good, Robbin
On 11/24/2017 09:01 AM, Per Liden wrote:
Hi,
jstat is designed to handle the case where a perf counter doesn't exits. In the
output jstat will then print a "-" instead of the perf counter value to indicate
that the counter doesn't exist. However, jstat also prints an unnece
Hi JC, great to see another revision!
heapMonitoring.cpp
StackTraceData should not contain the oop for 'safety' reasons.
When StackTraceData is moved from _allocated_traces:
L452 store_garbage_trace(trace);
it contains a dead oop.
_allocated_traces could instead be a tupel of oop and StackT
emaining = pointer_delta(tlab.hard_end(), tlab.top());
I inlined my answers:
On Thu, Jan 25, 2018 at 1:15 AM, Robbin Ehn wrote:
Hi JC, great to see another revision!
heapMonitoring.cpp
StackTraceData should not contain the oop for 'safety' reasons.
When StackTraceData is
Hi JC, thanks!
I'm happy with current state, looks good!
Truncated:
On 01/27/2018 05:01 AM, JC Beyler wrote:
This is strange but I'm assuming it is because we are not working on
the same repo?
I used:
hg clone http://hg.openjdk.java.net/jdk/hs jdkhs-heap
I'll try a new clone on Monday and se
just rollback to the previously version.
Thanks for having a look at it!
/Robbin
On Mon, Jan 29, 2018 at 1:29 AM, Robbin Ehn wrote:
Hi JC, thanks!
I'm happy with current state, looks good!
Truncated:
On 01/27/2018 05:01 AM, JC Beyler wrote:
This is strange but I'm assuming it is
and I look forward to your pointers for
the questions I now have raised!
Jc
Thanks,
/Erik
On 2018-01-26 06:45, JC Beyler wrote:
Thanks Robbin for the reviews :)
The new full
Hi JC, I found a .19 which I looked at:
src/hotspot/share/gc/shared/collectedHeap.inline.hpp
CollectedHeap::allocate_memory
This is the only place I found which calls the
~JvmtiSampledObjectAllocEventCollector
It is not intuitive with creating a handle for the destructor, I suggest
something li
,
we preferred (3).
What do you and the community think?
Thanks again for your review!
Jc
On Mon, May 14, 2018 at 2:13 AM Robbin Ehn <mailto:robbin@oracle.com>> wrote:
Hi JC, I found a .19 which I looked at:
src/hotspot/share/gc/shared/collectedHeap.inline.hpp
CollectedHeap
w the
webrev please? :)
http://cr.openjdk.java.net/~jcbeyler/8171119/heap_event.19/
Thanks a lot!
Jc
On Mon, May 14, 2018 at 11:47 AM Robbin Ehn <mailto:robbin@oracle.com>> wrote:
Hi JC,
On 2018-05-14 17:09, JC Beyler wrote:
> Hi Robbin,
>
>
Hi Bob,
On 06/07/2018 07:43 PM, Bob Vandette wrote:
Can I get one more reviewer for this RFE so I can integrate it?
http://cr.openjdk.java.net/~bobv/8203357/webrev.01
Seems okay.
Metrics.java
"Returns the length of the operating system time slice"
Note that is is only true if you are using
1 - 100 of 514 matches
Mail list logo
