Hi Ralf,
On 12/02/2020 6:41 pm, Schmelter, Ralf wrote:
Hi David,
I see little point in subclassing NonJavaThread (via NamedThread) but
then overriding pre_run() and post_run() so that you don't do anything
that NonJavaThread is supposed to do regarding the NJT iterator
capabilities.
The prob
Hi Alex,
LGTM++
Thanks,
Serguei
On 2/12/20 3:45 PM, Chris Plummer wrote:
Ok. LGTM.
Chris
On 2/12/20 1:58 PM, Alex Menkov wrote:
Hi Chris,
thanks for the review.
finishApp is also called from startApp(String... cmd) method
and appProcess can be not initialized there.
In the case finishApp w
yes, I'm fine w/ that.
-- Igor
> On Feb 12, 2020, at 3:48 PM, Chris Plummer wrote:
>
> On 2/12/20 2:15 PM, David Holmes wrote:
>> On 13/02/2020 5:02 am, Chris Plummer wrote:
>>> Hi David,
>>>
What you have below is a mix of #2 and #3 - you convert to a generic
exception but also re-
On 2/12/20 2:15 PM, David Holmes wrote:
On 13/02/2020 5:02 am, Chris Plummer wrote:
Hi David,
What you have below is a mix of #2 and #3 - you convert to a generic
exception but also re-assert the interrupt state. That's a little
unusual.
That what I also thought which is why I was suggesting
Ok. LGTM.
Chris
On 2/12/20 1:58 PM, Alex Menkov wrote:
Hi Chris,
thanks for the review.
finishApp is also called from startApp(String... cmd) method
and appProcess can be not initialized there.
In the case finishApp will throw NPE (calling appProcess.exitValue())
--alex
On 02/12/2020 13:53,
On 13/02/2020 5:02 am, Chris Plummer wrote:
Hi David,
What you have below is a mix of #2 and #3 - you convert to a generic
exception but also re-assert the interrupt state. That's a little
unusual.
That what I also thought which is why I was suggesting not doing the
interrupt() call and only
Hi Chris,
thanks for the review.
finishApp is also called from startApp(String... cmd) method
and appProcess can be not initialized there.
In the case finishApp will throw NPE (calling appProcess.exitValue())
--alex
On 02/12/2020 13:53, Chris Plummer wrote:
Hi Alex,
Thanks for doing this. Not
Hi Alex,
Thanks for doing this. Not having output from a spawned process that
failed is an issue with more than just LingeredApp tests. This is a good
start in getting those fixed.
I'm a little unclear on one part of your fix. Why did you move the
"appProcess != null" into finishApp(). You a
Hi all,
Please review small fix for
https://bugs.openjdk.java.net/browse/JDK-8238710
webrev:
http://cr.openjdk.java.net/~amenkov/jdk15/LingeredApp_log_error/webrev/
--alex
I'll take a look next couple days. I was out last few days and am
catching up on other things.
Mandy
On 2/11/20 10:04 AM, Severin Gehwolf wrote:
Hi Mandy, Bob,
Thanks again for the reviews and patience on this. Sorry it took me so
long to get back to this :-/
Updated webrev:
Full: http://cr
Hi David,
What you have below is a mix of #2 and #3 - you convert to a generic
exception but also re-assert the interrupt state. That's a little
unusual.
That what I also thought which is why I was suggesting not doing the
interrupt() call and only throwing the RuntimeException. I agree that
Hi,
On Wed, 2020-02-12 at 12:29 -0500, Bob Vandette wrote:
> I applied the delegation change that you recommended and now all container
> tests pass.
>
> Here’s the change that I applied.
>
> echo +cpu +cpuset +io +memory +pids > /sys/fs/cgroup/cgroup.subtree_control
> echo +cpu +cpuset +io +me
I applied the delegation change that you recommended and now all container
tests pass.
Here’s the change that I applied.
echo +cpu +cpuset +io +memory +pids > /sys/fs/cgroup/cgroup.subtree_control
echo +cpu +cpuset +io +memory +pids >
/sys/fs/cgroup/user.slice/cgroup.subtree_control
echo +cpu +
On 2/12/20 4:17 AM, Schmelter, Ralf wrote:
Hi Serguei,
the use case is being able to get a heap dump from big Java servers. These
usually run on machines with a lot of memory and CPUs, but not much disk space
(which they don't need apart from some trace files and the server code itself).
A
> On Feb 12, 2020, at 6:22 AM, Severin Gehwolf wrote:
>
> Hi Bob,
>
> On Tue, 2020-02-11 at 16:59 -0500, Bob Vandette wrote:
>> I applied your patch to the latest JDK 15 sources and ran the container
>> tests on Oracle Linux 8.1 with podman/cgroupv2 enabled. There were some
>> issues.
>> I’m
Hi Chris,
I think you are overthinking this. :)
What you have observed is that the code that actually uses this method
does not utilise interrupts, or expect them, so if you artifically
inject one in this library method then you see things failing in
unexpected ways. That also means that if t
Hi Serguei,
the use case is being able to get a heap dump from big Java servers. These
usually run on machines with a lot of memory and CPUs, but not much disk space
(which they don't need apart from some trace files and the server code itself).
And if we can get the customer to mount some NFS
Hi Bob,
On Tue, 2020-02-11 at 16:59 -0500, Bob Vandette wrote:
> I applied your patch to the latest JDK 15 sources and ran the container
> tests on Oracle Linux 8.1 with podman/cgroupv2 enabled. There were some
> issues.
> I’m not sure if its my setup or not.
Looking over them, they appear 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 h
Hi Serguei,
the problem is, that if I make the -gz flag a jlong argument, I cannot just use
'-gz'. This causes DCmdArgument::parse_value() to be called with a NULL
string, which leads to an error. That is why a used a string argument in my
code. But using a string when I really mean an integer
Hi David,
> I see little point in subclassing NonJavaThread (via NamedThread) but
> then overriding pre_run() and post_run() so that you don't do anything
> that NonJavaThread is supposed to do regarding the NJT iterator
> capabilities.
The problem is the post_run() method of NamedThread call
Hi Zhengyu,
On 2020-02-07 16:53, Zhengyu Gu wrote:
Hi,
I would like purpose this change that allows GC to provide ObjectMarker
during JVMTI heap walk.
Currently, JVMTI heap walk uses oop markword's 'marked' pattern to
indicate 'visited' oop.
Unfortunately, it conflicts with Shenandoah, wh
Hi Igor,
I think it might be best to the interrupt() call out. I wanted to
see what would happen if we ever got an InterruptedException, so I
added the following to the start of Platform.shouldSAAttach():
try {
throw new Int
24 matches
Mail list logo