On Thu, 2020-07-30 at 05:28 +, Baesken, Matthias wrote:
> > The only reason why a 0 was observed, was because the cgroup interface
> > files were missing and the old code mapped that to a 0. That's no
> > longer the case and, thus, it seems it would make the code clearer if
> > it wouldn't be t
>The only reason why a 0 was observed, was because the cgroup interface
>files were missing and the old code mapped that to a 0. That's no
>longer the case and, thus, it seems it would make the code clearer if
>it wouldn't be there any more.
>
>I don't feel strongly about this, though, and can jus
ed that to a 0. That's no
longer the case and, thus, it seems it would make the code clearer if
it wouldn't be there any more.
I don't feel strongly about this, though, and can just drop this patch.
The fix of JDK-8236617 has been superseded by JDK-8244500.
Thanks,
Seve
So the check you want to clean up does no harm, and might handle "strange"
cases - why not keep it?
Best regards, Matthias
-Original Message-
From: Severin Gehwolf
Sent: Mittwoch, 15. Juli 2020 11:47
To: core-libs-dev ; serviceability-dev
Cc: Baesken, Matthias ; Bob
Anyone?
On Mon, 2020-06-29 at 17:53 +0200, Severin Gehwolf wrote:
> Hi,
>
> Could I please get a review of this dead-code removal? During review of
> JDK-8244500 it was discovered that with the new cgroups implementation
> supporting v1 and v2 Metrics.getMemoryAndSwapLimit() will never return
> 0
