That sounds reasonable, but I'd like to hear from people that are
actually putting the "jmap --heap print" output to use. Although the
exact format of the output is not specified, it's possible that users
could be parsing the output by looking for an actual numeric size. There
might even be tes
Thanks Alex!
Chris
On 12/17/19 1:30 PM, Alex Menkov wrote:
LGTM
--alex
On 12/16/2019 21:36, Chris Plummer wrote:
Hello,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8236062
http://cr.openjdk.java.net/~cjplummer/8236062/webrev.00/
Since SA javascript support is bro
Hi Serguei,
The review thread should be "RFR 8235829: graal crashes with Zombie.java
test".
On 12/17/19 8:17 PM, serguei.spit...@oracle.com wrote:
Hi Coleen,
Is this webrev v2 right to look at? :
http://cr.openjdk.java.net/~coleenp/2019/8235829.02/webrev/
Actually, this one was something I t
Hi Coleen,
Is this webrev v2 right to look at? :
http://cr.openjdk.java.net/~coleenp/2019/8235829.02/webrev/
It looks good to me.
Just one nit (sorry, if it is a duplicated comment):
http://cr.openjdk.java.net/~coleenp/2019/8235829.02/webrev/src/hotspot/share/prims/jvmtiImpl.cpp.frames.html
LGTM
--alex
On 12/16/2019 21:36, Chris Plummer wrote:
Hello,
Please review the following:
https://bugs.openjdk.java.net/browse/JDK-8236062
http://cr.openjdk.java.net/~cjplummer/8236062/webrev.00/
Since SA javascript support is broken as described in [1] JDK-8235594,
and we'll likely remove
On 12/16/19 11:04 PM, David Holmes wrote:
Clarification ...
On 17/12/2019 12:40 pm, coleen.phillim...@oracle.com wrote:
Short answer below.
On 12/16/19 5:51 PM, David Holmes wrote:
Hi Coleen,
A quick initial response ...
On 16/12/2019 11:26 pm, coleen.phillim...@oracle.com wrote:
On
Hi David,
> >> Some further queries/concerns:
> >>
> >> src/hotspot/share/runtime/objectMonitor.cpp
> >>
> >> Can you please explain the changes to ObjectMonitor::wait:
> >>
> >> ! _recursions = save // restore the old recursion count
> >> !
On 12/17/19 3:14 AM, Per Liden wrote:
Hi Coleen,
The "nmethod entry barrier"-part looks good to me. Just one minor nit,
maybe JvmtiDeferredEventQueue::run_nmethod_entry_barrier should have
an "s" on it (i.e.
JvmtiDeferredEventQueue::run_nmethod_entry_barriers) since it loops
over all entr
On 12/17/19 4:21 AM, Robbin Ehn wrote:
Hi Coleen,
On 12/16/19 9:21 PM, coleen.phillim...@oracle.com wrote:
http://cr.openjdk.java.net/~rehn/8235912/v1/webrev/src/hotspot/share/prims/jvmtiImpl.cpp.udiff.html
+ NativeAccess<>::oop_store(_class_holder, class_holder_oop);
This should prob
Hi Richard,
On 12/17/19 11:24 AM, Reingruber, Richard wrote:
> So adding asynch handshakes and a per thread handshake queue, we can.
> (which this test prototype does)
Yes, should work for my use case too.
Great.
> The issue I'm thinking of is if we need selective polling first.
Hi Robbin,
> Sorry I don't immediately see what issue there is in doing a handshake
> instead of:
> VM_GetOwnedMonitorInfo op(this, calling_thread, java_thread,
> owned_monitors_list);
VM_GetOwnedMonitorInfo /can/ be replaced by a handshake, but the calling_thread
T1 needs to walk
java
Hi Coleen,
On 12/16/19 9:21 PM, coleen.phillim...@oracle.com wrote:
http://cr.openjdk.java.net/~rehn/8235912/v1/webrev/src/hotspot/share/prims/jvmtiImpl.cpp.udiff.html
+ NativeAccess<>::oop_store(_class_holder, class_holder_oop);
This should probably be:
41 NativeAccess::oop_store(hand
Hi Coleen,
The "nmethod entry barrier"-part looks good to me. Just one minor nit,
maybe JvmtiDeferredEventQueue::run_nmethod_entry_barrier should have an
"s" on it (i.e. JvmtiDeferredEventQueue::run_nmethod_entry_barriers)
since it loops over all entries in the queue?
But I don't dare to com
13 matches
Mail list logo
