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
Hi,
I agree, this could be very useful…
— Kirk
> On Nov 14, 2018, at 10:29 AM, Simon Roberts
> wrote:
>
> I would say this could be pretty useful. It's almost like a
> platform-independent, process specific vmstat, with JVM extras. Given the
> existence of jps, this seems to fit in that
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 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
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.
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.
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,
It seems what we do with other events that might have this type of "risk"
is to defer the event to the ServiceThread, which is a Java thread, no? But
perhaps for a resource exhausted just ignoring it for the compiler thread
and letting another "Java thread" be aware of it and posting is a better
Hi JC,
On Wed, Nov 14, 2018 at 3:56 PM JC Beyler wrote:
>
> It seems what we do with other events that might have this type of "risk" is
> to defer the event to the ServiceThread, which is a Java thread, no? But
> perhaps for a resource exhausted just ignoring it for the compiler thread and
>
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
Hi all,
We have that feature in our port which we would like to contribute,
and I would like to gauge opinions.
First off, I am not sure which list is correct. This is more of a
serviceability issue, but implementation wise it fit hs-runtime
better. I'll start with serviceability, but feel free
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.
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
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
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
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 would say this could be pretty useful. It's almost like a
platform-independent, process specific vmstat, with JVM extras. Given the
existence of jps, this seems to fit in that ecosystem well. I find myself
having to work with windows just rarely enough that I'd have to look up how
to get this
Looks good Thomas, what would be the typical memory usage with the Default
Settings? Does the downsampling support min/max style rollups?
--
http://bernd.eckenfels.net
Von: Thomas Stüfe
Gesendet: Mittwoch, 14. November 2018 16:29
An: serviceability-dev@openjdk.java.net
Hi Bernd,
On Wed, Nov 14, 2018 at 10:07 PM Bernd Eckenfels wrote:
>
> Looks good Thomas,
thanks!
> what would be the typical memory usage with the Default Settings?
~ 80 Kb. Its very small.
> Does the downsampling support min/max style rollups?
Not sure what you mean. Do you mean does it
Hi Simon,
thank you. Yes, I combined vmstat/pidstat like features etc with
internal JVM statistics. Note that part of that table is platform
specific, so it looks slightly different on BSD/Windows/Solaris etc.
The JVM values are always the same.
Best Regards, Thomas
On Wed, Nov 14, 2018 at 7:29
20 matches
Mail list logo
