I'd say yes, it's better to still call Thread::interrupt.
-- Igor
> On Feb 11, 2020, at 10:19 PM, Chris Plummer wrote:
>
> Ok. Should I still call interrupt()?
>
> Chris
>
> On 2/11/20 10:07 PM, Igor Ignatyev wrote:
>> Hi Chris,
>>
>> that's a common practice for any kind of library-ish code
Ok. Should I still call interrupt()?
Chris
On 2/11/20 10:07 PM, Igor Ignatyev wrote:
Hi Chris,
that's a common practice for any kind of library-ish
code, if there are no explicit check of interrupt status, it
Hi Chris,
that's a common practice for any kind of library-ish code, if there are no
explicit check of interrupt status, it will be checked a by next operation
which might be interrupted. in this particular case, I agree rethrowing it as
an unchecked exception might be a good alternative.
-- I
Hi Igor,
I guess I fail to see the benefit of this. Who is going to check
the interrupt status of this thread and do something meaningful
with it? It seems we would want to immediately propagate the
failure by throwing a RuntimeException. This will work wel
Hi Ralf,
I agree with Serguei and Laurence.
+1 to -gz[=level] only.
Yasumasa
On 2020/02/12 0:35, Schmelter, Ralf wrote:
Hi Yasumasa,
I think I've tried too much by using the -gz flag as a boolean plus a int
value. I've decided to use two options instead: -gz as a boolean option to turn
co
As this is a decades old FAQ ...
On 12/02/2020 8:50 am, David Holmes wrote:
On 11/02/2020 10:55 pm, Yasumasa Suenaga wrote:
Hi Ralf,
On 2020/02/11 0:33, Schmelter, Ralf wrote:
Hi Yasumasa,
You can use `DCmdArgument` for -gz option.
That is what I originally tried. But then you always h
rather like this :
> } catch (InterruptedException e) {
>Thread.currentThread().interrupt();
>return false; // assume not signed
> }
— Igor
> On Feb 11, 2020, at 6:15 PM, Chris Plummer wrote:
>
>
> Like this?
>
> } catch (InterruptedException e) {
> Thread.curren
Like this?
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw new RuntimeException(e);
}
Chris
On 2/11/20 2:23 PM, Igor Ignatyev wrote:
no, I
Hi Chris,
This looks okay to me.
Thanks,
Serguei
On 2/11/20 1:49 PM, Chris Plummer wrote:
Hi Igor,
Here's an updated webrev:
http://cr.openjdk.java.net/~cjplummer/8238196/webrev.01/index.html
I rebased to JDK 15 and made all the changes you suggested except for
(3). I did not think it is
On 11/02/2020 10:55 pm, Yasumasa Suenaga wrote:
Hi Ralf,
On 2020/02/11 0:33, Schmelter, Ralf wrote:
Hi Yasumasa,
You can use `DCmdArgument` for -gz option.
That is what I originally tried. But then you always have to supply a
compression level (just specifying -gz doesn't work). Since I
no, I meant to call Thread.currentThread().interrupt(), calling that will
restore interrupted state of the thread, so an user of Platform class will be
able to response to it appropriately, w/ your current code, the fact that the
thread was interrupted will be missed, and in most cases it is not
Hi Igor,
I'm not sure what you mean by restore the interrupt state. Do you
mean loop back to the waitFor() call?
thanks,
Chris
On 2/11/20 1:55 PM, Igor Ignatyev wrote:
Hi Chris,
I don't i
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.
I also ran the same build on Ubuntu with docker/cgroupv1. I didn't see any
failures on
the cgroupv1 syst
Hi Chris,
I don't insist on (3), so I'm fine if you don't want to change that part. one
thing I'd change though is to restore thread interrupted state at L#266 of
Platform.java (no need to publish new webrev)
Thanks,
-- Igor
> On Feb 11, 2020, at 1:49 PM, Chris Plummer wrote:
>
> Hi Igor,
>
Hi Igor,
Here's an updated webrev:
http://cr.openjdk.java.net/~cjplummer/8238196/webrev.01/index.html
I rebased to JDK 15 and made all the changes you suggested except for
(3). I did not think it is necessary since the code is only executed on
OSX. However, if you still feel allowing flexibil
On 2/11/20 11:49 AM, serguei.spit...@oracle.com wrote:
Ralf,
I see this feature adds a lot of code. In fact, I'm not sure, it is
worth to add this kind of complexity (including new compressing
threads) into the VM implementation. What is a real use case behind
it? Could this compressing be
On 2/11/20 11:41 AM, serguei.spit...@oracle.com wrote:
Hi Ralf,
I'd suggest for the option format something like this:
-gz[=level]
where level is an int. The part [=level] is optional.
The level is 0 by default (if it is not set).
+1!
Thanks,
Serguei
On 2/11/20 7:35 AM, Schmelter, Ral
Ralf,
I see this feature adds a lot of code. In fact, I'm not sure, it is
worth to add this kind of complexity (including new compressing threads)
into the VM implementation. What is a real use case behind it? Could
this compressing be done separately from VM implementation?
Thanks,
Serguei
Hi Ralf,
I'd suggest for the option format something like this:
-gz[=level]
where level is an int. The part [=level] is optional.
The level is 0 by default (if it is not set).
Thanks,
Serguei
On 2/11/20 7:35 AM, Schmelter, Ralf wrote:
Hi Yasumasa,
I think I've tried too much by using the -
Hi Matthias,
It looks good.
Thanks,
Serguei
On 2/6/20 8:06 AM, Baesken, Matthias wrote:
Hello,
the link time section gc (see
https://bugs.openjdk.java.net/browse/JDK-8236714 , on linux s390x it
prints the removed sections) showed some obsolete / unused functions
in FileSystemSupport_md.
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.openjdk.java.net/~sgehwolf/webrevs/JDK-823/10/webrev/
incremental:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-823/10/incremental/webrev
You might want to have some runtime/GC folks look at the handshake changes.
dl
On 2/6/20 4:39 AM, Reingruber, Richard wrote:
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/bro
Hi Yasumasa,
I think I've tried too much by using the -gz flag as a boolean plus a int
value. I've decided to use two options instead: -gz as a boolean option to turn
compression on and -gz-level to specify the compression level. E.g.
GC.heap_dump -gz -gz-level=3 test.hprof.gz
Best regards,
Ra
Hi Serguei,
> Two reviews has to be good enough unless anyone else did not want to
> review it as well.
> I guess, it is good to push.
Ok. I'll wait a little longer and on Thursday I'll push it.
Thanks, Richard.
-Original Message-
From: serguei.spit...@oracle.com
Sent: Montag,
Hi Ralf,
On 2020/02/11 0:33, Schmelter, Ralf wrote:
Hi Yasumasa,
You can use `DCmdArgument` for -gz option.
That is what I originally tried. But then you always have to supply a
compression level (just specifying -gz doesn't work). Since I would expect most
users never caring about the
Hi David,
thanks for the feedback. I fear you are right, the current code is not safe.
During much of the development I actually used a global lock. But then I
thought it would look strange, that more than one CompressionBackend would use
the same. But apart from aesthetics, this would pose no
Hi Christoph, thanks for the review !
Will push it as XS in case no objections show up .
Best regards, Matthias
From: Langer, Christoph
Sent: Montag, 10. Februar 2020 10:01
To: Baesken, Matthias ;
serviceability-dev@openjdk.java.net
Subject: RE: RFR [XS]: 8238602: remove obsolete functions fro
27 matches
Mail list logo
