converted to a PR in any case.
I hope to get the PR out later but we've got a team outing today... we haven't
seen
each other since months... :)
Cheers, Richard.
[1]
http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-April/030911.html
-Original Message-
From: D
Hello Marty,
Sure. I'd be happy if Serguei could review the change.
Thanks, Richard.
-Original Message-
From: Marty Thompson
Sent: Dienstag, 8. September 2020 18:55
To: Reingruber, Richard ; Daniel Daugherty
; serviceability-dev
; hotspot-compiler-...@openjdk.java.net;
Hotspo
augherty
Sent: Dienstag, 8. September 2020 18:16
To: Reingruber, Richard ; serviceability-dev
; hotspot-compiler-...@openjdk.java.net;
Hotspot dev runtime
Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in
the Presence of JVMTI Agents
Hi Richard,
I haven't seen a r
https://bugs.openjdk.java.net/browse/JDK-8233915
Version to be pushed:
http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
Hope to get my GIT/Skara setup going until then... :)
Thanks, Richard.
-Original Message-
From: hotspot-compiler-dev On
Behalf Of Reingruber, Richard
Sent: Mittwo
4857e/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1145
-Original Message-
From: David Holmes
Sent: Donnerstag, 3. September 2020 00:24
To: Reingruber, Richard ; serviceability-dev
Subject: Re: RFR(XS) 8252593: [TESTBUG]
serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java fai
are we sure these errors are caused by races but not bugs in the
GetLocalObject implementation?
Thanks,
Serguei
On 9/2/20 07:37, Reingruber, Richard wrote:
Hi,
please help review this fix for a TESTBUG in
serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java
Webrev: http://cr
Hi Robin,
> On 2020-09-02 15:48, Reingruber, Richard wrote:
> > Hi Robbin,
> >
> > // taking the discussion back to the mailing lists
> >
> >> I still don't understand why you don't deoptimize the objects inside
> > the
> >
Hi,
please help review this fix for a TESTBUG in
serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8252593/webrev.0/
Bug:https://bugs.openjdk.java.net/browse/JDK-8252593
With this change the JVMTI test agent silently acce
essage-
From: Robbin Ehn
Sent: Mittwoch, 2. September 2020 13:56
To: Reingruber, Richard
Cc: Lindenmaier, Goetz ; Vladimir Kozlov
; David Holmes
Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in
the Presence of JVMTI Agents
Hi,
I still don't und
feasible to use
handshakes for it.
Cheers, Richard.
-Original Message-
From: Yasumasa Suenaga
Sent: Freitag, 28. August 2020 15:15
To: Reingruber, Richard ; David Holmes
; serviceability-dev
Subject: Re: 8242427: JVMTI frame pop operations should use Thread-Local
Handshakes
Hi
Hi Yasumasa,
VM_DeoptimizeFrame can be replaced too I'd think.
Cheers, Richard.
-Original Message-
From: Yasumasa Suenaga
Sent: Freitag, 28. August 2020 10:42
To: Reingruber, Richard ; David Holmes
; serviceability-dev
Subject: Re: 8242427: JVMTI frame pop operations shoul
see the point in optimizing the uncommon case making it more
complex. But if it's just me...
Cheers, Richard.
-Original Message-
From: David Holmes
Sent: Freitag, 28. August 2020 03:53
To: Yasumasa Suenaga ; Reingruber, Richard
; serviceability-dev
Subject: Re: 8242427: JVMTI fram
Thanks a lot!
Richard.
-Original Message-
From: Lindenmaier, Goetz
Sent: Freitag, 28. August 2020 08:38
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net
Subject: RE: RFR(L) 8227745: Enable
https://bugs.openjdk.java.net/browse/JDK-8251384
-Original Message-
From: Lindenmaier, Goetz
Sent: Samstag, 22. August 2020 07:46
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net
Subject: RE: RFR(L
age-
From: Yasumasa Suenaga
Sent: Donnerstag, 27. August 2020 01:30
To: Reingruber, Richard ; serviceability-dev
Subject: Re: 8242427: JVMTI frame pop operations should use Thread-Local
Handshakes
Hi Richard,
I've described the motivation on JDK-8201641 (it is a parent task of
JDK-8242427)
``
Hi Yasumasa,
Could you explain a little bit the motivation to replace these vm operations
with handshakes?
Would be good, if you could add the goals as well to the JBS item.
Thanks, Richard.
-Original Message-
From: serviceability-dev On Behalf
Of Yasumasa Suenaga
Sent: Montag, 24. Au
he submit repo [1].
I've pushed again to submit. Will push to the jdk master repo when this job
reports success.
Thanks,
Richard.
[1]
https://mail.openjdk.java.net/pipermail/jdk-submit-changes/2020-August/012091.html
From: serguei.spit...@oracle.com
Sent: Freitag, 21. August 2020 18:48
To: Reing
2020 11:22
To: Reingruber, Richard ; David Holmes
; serviceability-dev@openjdk.java.net
Subject: Re: RFR(S) 8249293: Unsafe stackwalk in
VM_GetOrSetLocal::doit_prologue()
Hi Richard,
Thank you for the update, it looks really nice.
Just several more minor comments though (I hope, the last ones
167 printf("*** AGENT: GetLocalWithoutSuspendTestThreadLoop thread
started. Polling thread '%s' for local variables\n",
It is better to get rid of leading stars in all messages.
Ok, done.
176 // the native method
Java_GetLocalWithoutSuspendTest_notifyAgentToGetLo
-
From: Lindenmaier, Goetz
Sent: Donnerstag, 23. Juli 2020 16:20
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net
Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in
the
Thanks David, have a good time!
Richard.
-Original Message-
From: David Holmes
Sent: Dienstag, 18. August 2020 07:20
To: Reingruber, Richard ;
serguei.spit...@oracle.com; serviceability-dev@openjdk.java.net
Subject: Re: RFR(S) 8249293: Unsafe stackwalk in
VM_GetOrSetLocal
or local variables\n",
> It is better to get rid of leading stars in all messages.
Ok, done.
> 176 // the native method
> Java_GetLocalWithoutSuspendTest_notifyAgentToGetLocalAndWaitShortly
> The part 'Java_GetLocalWithoutSuspendTest_' can be removed from the f
ich/webrevs/8249293/webrev.3/
Delta: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.3.inc/
Thanks, Richard.
-Original Message-
From: David Holmes
Sent: Dienstag, 11. August 2020 04:00
To: serguei.spit...@oracle.com; Reingruber, Richard
; serviceability-dev@openjdk.java.net
Subjec
> At least, he test is missing the comments explaining all these.
The arguments to the msg() method serve as documentation too. I would not want
to repeat the msg strings in comments.
Thanks, Richard.
---------
From: serguei.spit...@oracle.com
.
> On 31/07/2020 5:28 pm, Reingruber, Richard wrote:
> > Hi,
> >
> > I rebase the fix after JDK-8250042.
> >
> > New webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.2/
> The general fix for this seems good. A minor nit:
> 588 if
Hi,
I rebase the fix after JDK-8250042.
New webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.2/
Thanks, Richard.
-Original Message-
From: serviceability-dev On Behalf
Of Reingruber, Richard
Sent: Montag, 27. Juli 2020 09:45
To: serguei.spit...@oracle.com
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
Subj
agent:
http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.1/
I tested it on Linux and Windows but not yet on MacOS.
Thanks,
Richard.
-Original Message-
From: serguei.spit...@oracle.com
Sent: Freitag, 24. Juli 2020 00:00
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net
nal". Because it is private?
> > >By the name, I would expect that EscapeBarrier::deoptimize_objects()
> > >calls it for some internal tasks. But it does not.
> >
> > Well, I'd say it is pretty internal, what's happening in that method.
e well.
> E.g. thread.cpp:2601 is an example where a simple
> 'a' helps a lot.
> "Single deoptimization is typically very short."
> I would add 'A': "A single deoptimization is typically very short (fast?)."
> An other meaning of the comment I
t;
> > >
> > > macros.hpp
> > > Good.
> > >
> > >
> > > Test coding
> > > ====
> > >
> > > compileBroker.h|cpp
> > >
> > > You introduce a third class of threads handled here and
> &g
Hi,
please help review this fix for VM_GetOrSetLocal. It moves the unsafe stackwalk
from the vm
operation prologue before the safepoint into the doit() method executed at the
safepoint.
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.0/index.html
Bug:https://bugs.openjdk.ja
I see. Thanks for the explanation :)
Richard.
-Original Message-
From: serguei.spit...@oracle.com
Sent: Freitag, 5. Juni 2020 09:31
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net; hotspot-gc
submit repo job?
Thanks,
Richard.
-Original Message-
From: serguei.spit...@oracle.com
Sent: Donnerstag, 4. Juni 2020 04:07
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net; hotspot-gc-...@ope
Excellent. Thanks!
Richard.
-Original Message-
From: serguei.spit...@oracle.com
Sent: Dienstag, 2. Juni 2020 20:02
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net; hotspot-gc
essage-
From: serguei.spit...@oracle.com
Sent: Dienstag, 2. Juni 2020 18:55
To: Vladimir Kozlov ; Reingruber, Richard
; serviceability-dev@openjdk.java.net;
hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net;
hotspot-gc-...@openjdk.java.net
Subject: Re: RFR(S) 823858
Thanks for the info, Vladimir, and for looking at the webrev.
Best regards,
Richard.
-Original Message-
From: Vladimir Kozlov
Sent: Donnerstag, 28. Mai 2020 18:03
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-runtime
40.html
-Original Message-
From: Vladimir Ivanov
Sent: Freitag, 7. Februar 2020 09:19
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net
Subject: Re: RFR(S) 8238585: Use handshake for
JvmtiEventControllerPrivate::enter_interp_only_mode() a
Sent: Donnerstag, 14. Mai 2020 00:32
To: Reingruber, Richard ; Patricio Chilano
; Vladimir Ivanov
; serviceability-dev@openjdk.java.net;
hotspot-compiler-...@openjdk.java.net; hotspot-...@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net; hotspot-gc-...@openjdk.java.net
Subject: Re: RFR
Ok. Thanks for the feedback anyways.
Cheers, Richard.
-Original Message-
From: David Holmes
Sent: Donnerstag, 14. Mai 2020 07:29
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-...@openjdk.java.net; hotspot-runtime
Hi David,
> On 4/05/2020 8:33 pm, Reingruber, Richard wrote:
> > // Trimmed the list of recipients. If the list gets too long then the
> > message needs to be approved
> > // by a moderator.
> Yes I noticed that too :) In general if you send to hotspot-dev you
> sho
Thanks Martin.
Cheers, Richard.
-Original Message-
From: Doerr, Martin
Sent: Dienstag, 12. Mai 2020 10:43
To: Reingruber, Richard ; David Holmes
; serviceability-dev@openjdk.java.net;
hotspot-compiler-...@openjdk.java.net; hotspot-...@openjdk.java.net;
hotspot-runtime
// Trimmed the list of recipients. If the list gets too long then the message
needs to be approved
// by a moderator.
Hi David,
> On 28/04/2020 12:09 am, Reingruber, Richard wrote:
> > Hi David,
> >
> >> Not a review but some general commentary ...
> >
> &
Hi David,
> Not a review but some general commentary ...
That's welcome.
> On 25/04/2020 2:08 am, Reingruber, Richard wrote:
> > Hi Yasumasa, Patricio,
> >
> >>>> I will send review request to replace VM_SetFramePop to handshake in
> >>>>
Hi Patricio,
thanks a lot for all the explanations. At least to me they are really helpful.
:)
Cheers, Richard.
-Original Message-
From: Patricio Chilano
Sent: Samstag, 25. April 2020 11:23
To: Reingruber, Richard ; Yasumasa Suenaga
; serguei.spit...@oracle.com; Vladimir Ivanov
or the processor of a direct handshake operation to do
safepoint/handshake
checks? I wouldn't see a reason, why not. But certainly I would avoid it.
> I'll look a bit more at the updated patch but at first glance looks good.
Thanks,
Richard.
-Original Message-
Fr
s://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301677&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301677
[2]
https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301763&page=com.atlassian.jira.plugin.system.iss
ichard.
[1] See question in comment
https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14302030&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14302030
-Original Message-
From: Yasumasa Suenaga
Sent: Freitag, 24. April 2020 13:34
To: R
1] An assertion in Handshake::execute_direct() fails, if called be VMThread,
because it is no JavaThread.
-Original Message-
From: hotspot-dev On Behalf Of
Reingruber, Richard
Sent: Freitag, 14. Februar 2020 19:47
To: Patricio Chilano ;
serviceability-dev@openjdk.java.net; hotspot-com
Hi Yasumasa,
I'm obviously late to this review. Still I wanted to let you know, that there's
another file in the
source tree that lists the VM operations in the VM (just found out about it
myself):
src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMOps.java
Probably you should remov
d the changes in the new webrev.
Webrev.2 looks good to me.
Cheers, Richard.
-Original Message-----
From: Schmelter, Ralf
Sent: Montag, 20. April 2020 10:14
To: Reingruber, Richard ; Ioi Lam
; Langer, Christoph ; Yasumasa
Suenaga ; serguei.spit...@oracle.com;
hotspot-runtime-...@openjdk.j
Hi Ralf,
thanks for providing this enhancement to parallel gzip-compress heap dumps!
I reckon it's safe to say that the coding is sophisticated. It would be awesome
if you could sketch
the idea of how HeapDumper, DumpWriter and CompressionBackend work together to
produce the gzipped
dump in a s
nal Message-
From: Robbin Ehn
Sent: Dienstag, 31. März 2020 16:21
To: Reingruber, Richard ; Doerr, Martin
; Lindenmaier, Goetz ; David
Holmes ; Vladimir Kozlov (vladimir.koz...@oracle.com)
; serviceability-dev@openjdk.java.net;
hotspot-compiler-...@openjdk.java.net; hotspot-runt
ne additional careful review.
Thanks a lot,
Richard.
-Original Message-
From: Doerr, Martin
Sent: Dienstag, 31. März 2020 16:01
To: Reingruber, Richard ; 'Robbin Ehn'
; Lindenmaier, Goetz ; David
Holmes ; Vladimir Kozlov (vladimir.koz...@oracle.com)
; serviceability-dev@openj
r change.
I'm keen to build the feature on async handshakes when the arive.
> You can use MutexLocker with Thread*.
Done.
> JVMTIDeferredUpdates: I agree with Robin. It'd be nice to move the class out
> of thread.hpp.
Done.
> src/hotspot/share/runtime/vframe.cpp
>
rstag, 12. März 2020 17:28
To: Reingruber, Richard ; 'Robbin Ehn'
; Lindenmaier, Goetz ; David
Holmes ; Vladimir Kozlov (vladimir.koz...@oracle.com)
; serviceability-dev@openjdk.java.net;
hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net
Subject: RE: RFR(
Hi Martin,
thanks a lot for reviewing and the feedback. I'll dig into the details as soon
as possible. Looking forward to it :)
Thanks, Richard.
-Original Message-
From: Doerr, Martin
Sent: Donnerstag, 12. März 2020 17:28
To: Reingruber, Richard ; 'Robbin Ehn'
; Lin
-Original Message-
From: Robbin Ehn
Sent: Monday, March 2, 2020 11:17 AM
To: Lindenmaier, Goetz ; Reingruber, Richard
; David Holmes ; Vladimir
Kozlov (vladimir.koz...@oracle.com) ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-runtime-...@openjdk.ja
Ping :)
Richard.
-Original Message-
From: hotspot-compiler-dev On
Behalf Of Reingruber, Richard
Sent: Dienstag, 4. Februar 2020 09:59
To: David Holmes ; Vladimir Kozlov
(vladimir.koz...@oracle.com) ; Robbin Ehn
; serviceability-dev@openjdk.java.net;
hotspot-compiler
m further
> > encouraged to do it with a handshake :)
> Ah! I think you can still do it with a handshake with the
> Deoptimization::deoptimize_all_marked() like solution. I can change the
> if-else statement with just the Handshake::execute() call in 8239084.
> But up
in intent to
replace it with a
handshake, but to avoid making the compiled methods on stack not_entrant
unless I'm further
encouraged to do it with a handshake :)
Thanks again,
Richard.
-Original Message-
From: Patricio Chilano
Sent: Donnerstag, 13. Februar 2020 18:47
To
// Repost including hotspot runtime and gc lists.
// Dean Long suggested to do so, because the enhancement replaces a vm operation
// with a handshake.
// Original thread:
http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030359.html
Hi,
could I please get reviews for this
Ok. I will repost and include hotspot runtime and gc lists.
Thanks, Richard.
-Original Message-
From: Dean Long
Sent: Dienstag, 11. Februar 2020 18:28
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net
Subject: Re: RFR(S) 8238585: Use
.com
Sent: Montag, 10. Februar 2020 19:11
To: Reingruber, Richard ; Vladimir Ivanov
; serviceability-dev@openjdk.java.net;
hotspot-compiler-...@openjdk.java.net
Subject: Re: RFR(S) 8238585: Use handshake for
JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled
meth
le.com
Sent: Freitag, 7. Februar 2020 19:06
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net
Subject: Re: RFR(S) 8238585: Use handshake for
JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled
methods on stack not_e
Hi,
could I please get reviews for this small enhancement:
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/
Bug:https://bugs.openjdk.java.net/browse/JDK-8238585
The change avoids making all compiled methods on stack not_entrant when
switching a java thread to
interpreter
(See https://bugs.openjdk.java.net/browse/JDK-8173304)
* Many copyright year changes and smaller clean-up changes of testing code
(trailing white-space and
the like).
-Original Message-
From: David Holmes
Sent: Donnerstag, 19. Dezember 2019 03:12
To: Reingruber, Richard ;
serviceability-dev@openjd
Hi Vladimir,
thanks for looking at this and providing feedback.
I though as well about using a handshake there. I'll try it.
Thanks, Richard.
-Original Message-
From: Vladimir Ivanov
Sent: Donnerstag, 30. Januar 2020 17:55
To: Reingruber, Richard ;
serviceabilit
Hi,
I noticed that VM_EnterInterpOnlyMode makes all compiled methods on stack
not_entrant. To me this
seems unnecessary. I think it would be sufficient to patch the return pc of
compiled frames and
let them return to their deopt handler. Or what would be the reason to make the
compiled methods
Hi,
webrev.3 didn't apply anymore after 8236000 [1]. I've rebased and updated in
place:
http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.3/
The change was minimal.
Cheers, Richard.
[1] JDK-8236000: VM build without C2 fails
-Original Message-----
From: Reingrube
Hi Ralf,
the enhacement you're proposing is useful I'd say. The enhancements it enables
(streaming,
compression) even more so.
Your change looks good to me. Note that I'm a JDK Committer not a Reviewer.
Best regards,
Richard.
-Original Message-
From: serviceability-dev On
Behalf Of S
> The external suspend mechanism is a royal pain in the proverbial that we
> have to carefully live with. The idea that we're duplicating that for
> use in another fringe area of functionality does not thrill me at all.
>
> To be clear, I understand the prob
tion will not return until some other thread resumes it"
Thanks, 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
s_waiting.wait(); }
14void start_thread() {
15 _wait.signal();
16 while(!Atomic::load(&_started)) {
17os::naked_yield();
18 }
19}
20 };
-Original Message-
From: Robbin Ehn
Sent: Montag, 16. Dezember 2019 11:21
To: Reingruber, Richard
d" some time ago and it is disturbing to see
it being added back (effectively). This seems like it may be something
that handshakes could be used for.
Thanks,
David
-
On 12/12/2019 7:02 am, David Holmes wrote:
> On 12/12/2019 1:07 am, Reingruber, Richard wrote:
>> Hi David,
>
. Still it would be possible to change the tests
to expect these
failures when executed with Graal. Perhaps I should do this?
Thanks, Richard.
-Original Message-
From: David Holmes
Sent: Freitag, 13. Dezember 2019 02:53
To: Vladimir Kozlov ; Reingruber, Richard
; hotsp
ichard.
-Original Message-
From: Vladimir Kozlov
Sent: Donnerstag, 12. Dezember 2019 19:20
To: David Holmes ;
hotspot-runtime-...@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
serviceability-dev@openjdk.java.net; Reingruber, Richard
Subject: Re: RFR(L) 8227745: Enable E
compilation and with just
one compiler thread.
Additionally I will make use of
compiler.whitebox.CompilerWhiteBoxTest.THRESHOLD in the tests.
Thanks,
Richard.
-Original Message-----
From: David Holmes
Sent: Mittwoch, 11. Dezember 2019 08:03
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.
Hi,
I would like to get reviews please for
http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.3/
Corresponding RFE:
https://bugs.openjdk.java.net/browse/JDK-8227745
Fixes also https://bugs.openjdk.java.net/browse/JDK-8233915
And potentially https://bugs.openjdk.java.net/browse/JDK-82
ed.
2) I think it makes sense to add requires
vm.opt.TieredCompilation != true
to just skip tests if anyone runs them with tiered compilation disabled
explicitly.
Leonid
On 11/11/19 7:29 AM, Reingruber, Richard wrote:
> Hi,
>
> I have created https://bugs.openjdk.java.net/browse/JDK-8
Hi,
I have created https://bugs.openjdk.java.net/browse/JDK-8233915
In short, a set of live objects L is not found using JVMTI FollowReferences()
if L is only reachable
from a scalar replaced object in a frame of a C2 compiled method. If L happens
to be a growing leak,
then a dynamically loaded
> I kept the 128M
That's good.
Cheers, Richard.
-Original Message-
From: Per Liden
Sent: Wednesday, October 9, 2019 8:24 PM
To: Reingruber, Richard ; hotspot-compiler-dev
Cc: serviceability-dev@openjdk.java.net
Subject: Re: RFR: 8232056: GetOwnedMonitorInfoWithEATest.ja
s, Richard.
-Original Message-
From: Per Liden
Sent: Mittwoch, 9. Oktober 2019 15:20
To: hotspot-compiler-dev
Cc: Reingruber, Richard ;
serviceability-dev@openjdk.java.net
Subject: RFR: 8232056: GetOwnedMonitorInfoWithEATest.java fails with ZGC: Heap
too small
The n
Thank you, Dan and Serguei.
Richard.
From: serguei.spit...@oracle.com
Sent: Donnerstag, 26. September 2019 16:33
To: daniel.daughe...@oracle.com; Reingruber, Richard
; Vladimir Kozlov ;
David Holmes ; hotspot-compiler-...@openjdk.java.net;
serviceability-dev@openjdk.java.net
Subject: Re: RFR
nd therefore unresponsive.
-Original Message-
From: Vladimir Kozlov
Sent: Mittwoch, 25. September 2019 18:53
To: Andrew Dinn ; Reingruber, Richard
; David Holmes ;
hotspot-compiler-...@openjdk.java.net; serviceability-dev@openjdk.java.net
Subject: Re: Should optimizations be observable for
Hi Dan and Serguei,
The change went through our nightly testing a few times, which includes these
tests and many more on all platforms.
Thanks, Richard.
From: serguei.spit...@oracle.com
Sent: Mittwoch, 25. September 2019 19:10
To: daniel.daughe...@oracle.com; Reingruber, Richard
; Vladimir
ates objects on the heap then the leaking objects are found, but it will
remain unknown what's
keeping them alive.
Thanks, Richard.
[1] https://docs.oracle.com/javase/specs/jvms/se13/html/jvms-6.html#jvms-6.5.new
-Original Message-
From: Vladimir Kozlov
Sent: Mittwoch, 25. Septem
our java debugging with gdb and
Intel (or AMD??) x86
manuals at your hand.
> We'll just have to agree to disagree here.
Agreed. All I do is offer my points to our audience hoping for a few '+1' ;)
Richard.
-Original Message-
From: David Holmes
Sent: Mittwoch, 2
adimir Kozlov
Sent: Dienstag, 24. September 2019 21:04
To: Reingruber, Richard ;
hotspot-compiler-...@openjdk.java.net; serviceability-dev@openjdk.java.net
Subject: Re: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability
can_get_owned_monitor_info was taken
I read discussion and this
Hi David,
thanks for taking part in the discussion.
> Hi Richard,
>
> Thanks for continuing the discussion. Some responses below.
>
> On 25/09/2019 7:28 am, Reingruber, Richard wrote:
> > Hi,
> >
> > I would like to get comments on the follo
x27;s already done when a thread traps
from compiled
execution to the interpreter: it reallocates and relocks objects upon
access through JVMTI.
This allows to enable EA and keep it transparent for agents.
[4] https://docs.oracle.com/javase/specs/jls/se13/html/jls-12.html#jls-12.6.1
-Origin
Hi,
I would like to get comments on the following questions:
1. Should optimizations be observable for JVMTI agents in general?
2. Should in particular optimzations based on escape analysis be observable?
(a) Should GetOwnedMonitorInfo() exclude objects with eliminated locking?
k on the
new thread.
Richard.
-Original Message-
From: David Holmes
Sent: Dienstag, 24. September 2019 02:17
To: Reingruber, Richard ;
hotspot-compiler-...@openjdk.java.net; serviceability-dev@openjdk.java.net
Subject: Re: RFR(S) 8230677: Should disable Escape Analysis
ve: this is done for deoptimization already. All tracking
information is collected at
compile time. There are no runtime costs, except size of debuginfo.
JDK-8227745 does what deoptimization does: reallocating and relocking objects.
Difference is that
JDK-8227745 does it right before JVMTI access.
.2 [2]) does not 'synchronized-with' (17.4.4
[3]) sync. action
A2, so they are not ordered.
> I'll have to ping Brian to see if he recalls exactly where this is
> covered. :)
Ok :)
Please let me know!
Richard.
[1]
https://docs.oracle.com/javase/8/docs/technotes/guid
ts
locked (interpreted),
then its not locked (compiled) and then in the same activation suddenly locked,
because an uncommon
trap was hit.
Thanks and a good weekend to you! - Actually to every reader :)
Richard.
-Original Message-
From: David Holmes
Sent: Freitag, 20. September 2019 11:07
Hi David,
> On 20/09/2019 2:42 am, Reingruber, Richard wrote:
> > Hi David,
> >
> > thanks for looking at this issue. And my appologies for the lengthy
mail...
> >
> >> > The JVMTI functions GetOwnedMonitorInfo() and
GetOwne
JDK-8227745
-Original Message-
From: David Holmes
Sent: Donnerstag, 19. September 2019 02:43
To: Reingruber, Richard ;
hotspot-compiler-...@openjdk.java.net; serviceability-dev@openjdk.java.net
Subject: Re: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability
can_get_
Hi,
could I please get reviews for
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/2019/8230956/webrev.0/
Bug:https://bugs.openjdk.java.net/browse/JDK-8230956
JVMTI provides functions to follow references beginning at the roots of the
object graph and it
provides functions to iterate all
Hi Alex,
thanks, the change looks good.
Best regards, Richard.
-Original Message-
From: Alex Menkov
Sent: Dienstag, 10. September 2019 22:33
To: Reingruber, Richard ;
serguei.spit...@oracle.com; OpenJDK Serviceability
Subject: Re: RFR: JDK-8192057: com/sun/jdi/BadHandshakeTest.java
1 - 100 of 110 matches
Mail list logo
