+1 more
Thanks,
David
On 27/11/2018 3:57 am, serguei.spit...@oracle.com wrote:
Hi Thomas,
+1
Thanks,
Serguei
On 11/26/18 06:53, Daniel D. Daugherty wrote:
On 11/26/18 8:07 AM, Thomas Stüfe wrote:
Hi guys,
latest webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8213834-jvmti-reourceexh
Hi Thomas,
+1
Thanks,
Serguei
On 11/26/18 06:53, Daniel D. Daugherty wrote:
On 11/26/18 8:07 AM, Thomas Stüfe wrote:
Hi guys,
latest webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8213834-jvmti-reourceexhausted-shall-not-be-posted-from-compiler-thread/webrev.02/webrev/
src/hotspot/sh
Thanks Dan!
On Mon, Nov 26, 2018 at 3:54 PM Daniel D. Daugherty
wrote:
>
> On 11/26/18 8:07 AM, Thomas Stüfe wrote:
> > Hi guys,
> >
> > latest webrev:
> > http://cr.openjdk.java.net/~stuefe/webrevs/8213834-jvmti-reourceexhausted-shall-not-be-posted-from-compiler-thread/webrev.02/webrev/
>
> src/
On 11/26/18 8:07 AM, Thomas Stüfe wrote:
Hi guys,
latest webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8213834-jvmti-reourceexhausted-shall-not-be-posted-from-compiler-thread/webrev.02/webrev/
src/hotspot/share/prims/jvmtiExport.cpp
No comments.
Thumbs up.
Dan
Back to can_call_j
Hi guys,
latest webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8213834-jvmti-reourceexhausted-shall-not-be-posted-from-compiler-thread/webrev.02/webrev/
Back to can_call_java(), since this seems to be the consensus, with a
comment added.
As for the Thread::can_send_jvmti_events() property i
Okay, I created an RFE for this:
https://bugs.openjdk.java.net/browse/JDK-8214294
And for now I will prepare a new minimal patch based on our
discussions and post it shortly.
..Thomas
On Mon, Nov 26, 2018 at 12:28 PM David Holmes wrote:
>
> On 26/11/2018 6:58 pm, Thomas Stüfe wrote:
> > Hi all
On 26/11/2018 6:58 pm, Thomas Stüfe wrote:
Hi all,
just a general question, would a
virtual bool Thread::can_post_JVMTI_events();
(similar to can_call_java()) not be a clearer solution? It clearly
expresses what we want, and we can, in every Thread child class,
explicitly specify the behavior.
Hi Thomas,
I like this idea.
It will help to control it better and avoid confusions next time.
Thanks,
Serguei
On 11/26/18 00:58, Thomas Stüfe wrote:
Hi all,
just a general question, would a
virtual bool Thread::can_post_JVMTI_events();
(similar to can_call_java()) not be a clearer solutio
Hi all,
just a general question, would a
virtual bool Thread::can_post_JVMTI_events();
(similar to can_call_java()) not be a clearer solution? It clearly
expresses what we want, and we can, in every Thread child class,
explicitly specify the behavior.
..Thomas
On Mon, Nov 26, 2018 at 9:51 A
On Mon, Nov 26, 2018 at 4:58 AM serguei.spit...@oracle.com
wrote:
>
> Hi guys,
>
> On 11/25/18 06:17, Daniel D. Daugherty wrote:
> > On 11/25/18 6:57 AM, David Holmes wrote:
> >>
> >>
> >> On 25/11/2018 12:41 am, Daniel D. Daugherty wrote:
> >>> On 11/22/18 5:24 PM, David Holmes wrote:
> Hi T
On 11/25/18 19:58, serguei.spit...@oracle.com wrote:
Hi guys,
On 11/25/18 06:17, Daniel D. Daugherty wrote:
On 11/25/18 6:57 AM, David Holmes wrote:
On 25/11/2018 12:41 am, Daniel D. Daugherty wrote:
On 11/22/18 5:24 PM, David Holmes wrote:
Hi Thomas,
On 23/11/2018 2:16 am, Thomas Stüfe w
Hi guys,
On 11/25/18 06:17, Daniel D. Daugherty wrote:
On 11/25/18 6:57 AM, David Holmes wrote:
On 25/11/2018 12:41 am, Daniel D. Daugherty wrote:
On 11/22/18 5:24 PM, David Holmes wrote:
Hi Thomas,
On 23/11/2018 2:16 am, Thomas Stüfe wrote:
Hi all,
would such a patch be acceptable:
htt
Hi David,
On 11/22/18 00:12, David Holmes wrote:
Hi Serguei,
Must be a mail system issue. This is the reply I wrote in response to
the two replies you had attached:
http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-November/025927.html
In fact, I saw this reply from you.
Sorr
On 11/25/18 6:57 AM, David Holmes wrote:
On 25/11/2018 12:41 am, Daniel D. Daugherty wrote:
On 11/22/18 5:24 PM, David Holmes wrote:
Hi Thomas,
On 23/11/2018 2:16 am, Thomas Stüfe wrote:
Hi all,
would such a patch be acceptable:
http://cr.openjdk.java.net/~stuefe/webrevs/8213834-jvmti-reo
On 25/11/2018 12:41 am, Daniel D. Daugherty wrote:
On 11/22/18 5:24 PM, David Holmes wrote:
Hi Thomas,
On 23/11/2018 2:16 am, Thomas Stüfe wrote:
Hi all,
would such a patch be acceptable:
http://cr.openjdk.java.net/~stuefe/webrevs/8213834-jvmti-reourceexhausted-shall-not-be-posted-from-co
On 11/22/18 5:24 PM, David Holmes wrote:
Hi Thomas,
On 23/11/2018 2:16 am, Thomas Stüfe wrote:
Hi all,
would such a patch be acceptable:
http://cr.openjdk.java.net/~stuefe/webrevs/8213834-jvmti-reourceexhausted-shall-not-be-posted-from-compiler-thread/webrev.01/webrev/
?
As has been propo
On 11/22/18 5:11 PM, David Holmes wrote:
Hi Dan,
On 23/11/2018 1:21 am, Daniel D. Daugherty wrote:
On 11/22/18 2:42 AM, David Holmes wrote:
I read your combined response to this as not in conflict with what I
said.
The last line of your response:
> So my preferred point solution is still
Hi Thomas,
On 23/11/2018 2:16 am, Thomas Stüfe wrote:
Hi all,
would such a patch be acceptable:
http://cr.openjdk.java.net/~stuefe/webrevs/8213834-jvmti-reourceexhausted-shall-not-be-posted-from-compiler-thread/webrev.01/webrev/
?
As has been proposed, I am now using
thread->is_hidden_from_ex
Hi Dan,
On 23/11/2018 1:21 am, Daniel D. Daugherty wrote:
On 11/22/18 2:42 AM, David Holmes wrote:
I read your combined response to this as not in conflict with what I said.
The last line of your response:
> So my preferred point solution is still to skip posting
ResourceExhausted
> if t
Hi all,
would such a patch be acceptable:
http://cr.openjdk.java.net/~stuefe/webrevs/8213834-jvmti-reourceexhausted-shall-not-be-posted-from-compiler-thread/webrev.01/webrev/
?
As has been proposed, I am now using
thread->is_hidden_from_external_view() to suppress the event.
Side note, this fun
On 11/22/18 2:42 AM, David Holmes wrote:
On 22/11/2018 5:36 pm, Thomas Stüfe wrote:
Hi JC,
On Wed, Nov 21, 2018 at 6:03 PM JC Beyler wrote:
Hi Thomas,
I actually agree with not using the service thread to be honest,
resource exhaustion seems to be something you'd want to know sooner
Hi Serguei,
Must be a mail system issue. This is the reply I wrote in response to
the two replies you had attached:
http://mail.openjdk.java.net/pipermail/serviceability-dev/2018-November/025927.html
"Hi Dan, Serguei,
I'm going to combine my response to you both into one as it's the same
dis
On 11/21/18 23:42, David Holmes wrote:
On 22/11/2018 5:36 pm, Thomas Stüfe wrote:
Hi JC,
On Wed, Nov 21, 2018 at 6:03 PM JC Beyler wrote:
Hi Thomas,
I actually agree with not using the service thread to be honest,
resource exhaustion seems to be something you'd want to know sooner
t
On 22/11/2018 5:36 pm, Thomas Stüfe wrote:
Hi JC,
On Wed, Nov 21, 2018 at 6:03 PM JC Beyler wrote:
Hi Thomas,
I actually agree with not using the service thread to be honest, resource
exhaustion seems to be something you'd want to know sooner than later.
How about we do both?
- F
Hi JC,
On Wed, Nov 21, 2018 at 6:03 PM JC Beyler wrote:
>
> Hi Thomas,
>
>
> I actually agree with not using the service thread to be honest, resource
> exhaustion seems to be something you'd want to know sooner than later.
>
> How about we do both?
> - Fix it now so that the compiler thread
Hi all,
David and JC already outlined the options we have nicely.
I'd like to add that I do not favor the ServiceThread delayed
deliverance since a common reaction to ResourceExhausted would to
print call stack of the thread running into it or to print a heap
histogram, as jvmkill does. For the f
Hi Dan, Serguei,
I'm going to combine my response to you both into one as it's the same
discussion ...
On 15/11/2018 9:28 am, Daniel D. Daugherty wrote:
On 11/14/18 6:01 PM, David Holmes wrote:
On 15/11/2018 6:13 am, Daniel D. Daugherty wrote:
I do not have a better idea at the moment.
The
Hi David,
On 11/14/18 15:05, David Holmes wrote:
Hi Serguei,
On 15/11/2018 5:20 am, serguei.spit...@oracle.com wrote:
Hi Thomas,
Thank you for taking care about this issue!
We recently also saw a couple of problems related to the compiler
thread not being hidden.
I have several comments t
On 11/14/18 6:01 PM, David Holmes wrote:
On 15/11/2018 6:13 am, Daniel D. Daugherty wrote:
I do not have a better idea at the moment.
The ResourceExhausted event is one of many JVM/TI events. So we put in a
special case for this event because an agent out in the world tries
to do
something th
Hi Serguei,
On 15/11/2018 5:20 am, serguei.spit...@oracle.com wrote:
Hi Thomas,
Thank you for taking care about this issue!
We recently also saw a couple of problems related to the compiler thread
not being hidden.
I have several comments to the fix.
It would be really nice if there is any
On 15/11/2018 6:13 am, Daniel D. Daugherty wrote:
I do not have a better idea at the moment.
The ResourceExhausted event is one of many JVM/TI events. So we put in a
special case for this event because an agent out in the world tries to do
something that is not expressly forbidden by the spec, b
Hi Dan,
I thought the same event is going to be posted again on a different thread.
It was wrong assumption, so you are right, it is not a good approach to
fix this issue.
Thanks,
Serguei
On 11/14/18 11:32, Daniel D. Daugherty wrote:
I have a philosophical problem with a fix like this.
The
I do not have a better idea at the moment.
The ResourceExhausted event is one of many JVM/TI events. So we put in a
special case for this event because an agent out in the world tries to do
something that is not expressly forbidden by the spec, but it is a bad
thing to do with HotSpot. Okay. What
Hi Dan,
On Wed, Nov 14, 2018 at 8:32 PM Daniel D. Daugherty
wrote:
>
> I have a philosophical problem with a fix like this.
>
> The fix is making the assumption that the handler for this event will want
> to run Java code and if the event is posted from a Java thread that cannot
> run Java code,
I have a philosophical problem with a fix like this.
The fix is making the assumption that the handler for this event will want
to run Java code and if the event is posted from a Java thread that cannot
run Java code, then we skip posting the event.
If I happen to have a more conservative agent
On 11/14/18 11:20,
serguei.spit...@oracle.com wrote:
Hi Thomas,
Thank you for taking care about this issue!
We recently also saw a couple of problems related to the
compiler thread not being hidden.
I have several co
Hi Thomas,
Thank you for taking care about this issue!
We recently also saw a couple of problems related to the compiler
thread not being hidden.
I have several comments to the fix.
It would be really nice if there is any chance to have
Adding serviceability-dev@...
Since the proposed solution to the bug is to not post an event, I think
the Serviceability Team (which owns JVM/TI) needs to be involved directly
in the review.
Dan
On 11/14/18 9:28 AM, Thomas Stüfe wrote:
Dear all,
may I please have reviews on this small patch.
38 matches
Mail list logo
