ass after the product fix.
> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still
> pass.
> - [x] GHA all pass.
>
> Please review! Many thanks in advance.
Severin Gehwolf has updated the pull request incrementally with one additional
commit since the last
ass after the product fix.
> - [x] Some manual testing using `cgcreate` and `cgexec` on cg1 and cg2. Still
> pass.
> - [x] GHA all pass.
>
> Please review! Many thanks in advance.
Severin Gehwolf has updated the pull request with a new target base due to a
merge or a rebase. T
On Tue, 13 Sep 2022 13:06:10 GMT, Severin Gehwolf wrote:
> Similar issue to the hotspot change discussed in
> https://bugs.openjdk.org/browse/JDK-8293472. The Java metrics implementation
> may get the resource limits wrong if there are additional cgroup fs mounts.
> Apparently
On Wed, 18 Jan 2023 13:20:06 GMT, Jonathan Dowland wrote:
> This is a fix for https://bugs.openjdk.org/browse/JDK-8300119
> (CgroupMetrics.getTotalMemorySize0() can report invalid results on 32 bit
> systems). Thanks to @jerboaa Severin Gehwolf for figuring out the solution.
>
&
On Fri, 20 Jan 2023 15:53:09 GMT, Severin Gehwolf wrote:
> Please review this fix to
> [JDK-8292541](https://bugs.openjdk.org/browse/JDK-8292541) which adds the
> same handling for swap values exceeding what's possible in the non-container
> case. I.e. treats it as unlimi
Please review this fix to
[JDK-8292541](https://bugs.openjdk.org/browse/JDK-8292541) which adds the same
handling for swap values exceeding what's possible in the non-container case.
I.e. treats it as unlimited and fixes the reporting. This has been handled on
the hotspot side similarly with
[
on the hotspot side similarly with
> [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083).
>
> Testing:
> - [x] Container tests on linux x86_64 with cg v1
> - [x] Container tests on linux x86_64 with cg v2
> - [ ] GHA (seem to have had some infra issues, so re-running)
Severi
on the hotspot side similarly with
> [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083).
>
> Testing:
> - [x] Container tests on linux x86_64 with cg v1
> - [x] Container tests on linux x86_64 with cg v2
> - [ ] GHA (seem to have had some infra issues, so re-running)
Severi
On Wed, 25 Jan 2023 13:05:06 GMT, Thomas Stuefe wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains one commit:
>>
>> 8299858: [Metrics] Swap memory limit reported incorrectl
On Wed, 25 Jan 2023 13:08:28 GMT, Thomas Stuefe wrote:
> (I know you do an assert in java, but that has to be switched on explicitly -
> do we run tests with asserts enabled?)
Yes. That's why `-esa` is being added here:
https://github.com/openjdk/jdk/pull/12118/files#diff-597a72f91945acae784afe
on the hotspot side similarly with
> [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083).
>
> Testing:
> - [x] Container tests on linux x86_64 with cg v1
> - [x] Container tests on linux x86_64 with cg v2
> - [ ] GHA (seem to have had some infra issues, so re-running)
Severi
On Wed, 25 Jan 2023 13:14:22 GMT, Thomas Stuefe wrote:
> Mostly good, small nits.
Thanks for the review, @tstuefe! I've updated the patch. Please let me know if
you want me to change anything else.
-
PR: https://git.openjdk.org/jdk/pull/12118
On Wed, 25 Jan 2023 13:14:22 GMT, Thomas Stuefe wrote:
> Mostly good, small nits.
Thanks for the review, @tstuefe! I've updated the patch. Please let me know if
you want me to change anything else.
-
PR: https://git.openjdk.org/jdk/pull/12118
On Wed, 25 Jan 2023 13:45:28 GMT, Severin Gehwolf wrote:
>> Please review this fix to
>> [JDK-8292541](https://bugs.openjdk.org/browse/JDK-8292541) which adds the
>> same handling for swap values exceeding what's possible in the non-container
>> case. I.e. treats
On Fri, 20 Jan 2023 15:53:09 GMT, Severin Gehwolf wrote:
> Please review this fix to
> [JDK-8292541](https://bugs.openjdk.org/browse/JDK-8292541) which adds the
> same handling for swap values exceeding what's possible in the non-container
> case. I.e. treats it as unlimi
Could I please get a review of this trivial comment-only change? `imageFile.hpp`
describes some properties of the jimage file `lib/modules`. However, I don't
think
the comment example matches current code in the JDK.
[`ATTRIBUTE_OFFSET`](https://github.com/openjdk/jdk/blob/master/src/java.base/sh
The `jimage` location attributes are terminated with `ATTRIBUTE_END`-kinds.
However,
the byte containing `ATTRIBUTE_END` (most significant 5 bits, represent
`kind`), might
be non-zero in the lower 3 bits (values up to `0x07` represent
`ATTRIBUTE_END`). The JDK code
handles this case correctly in
On Mon, 13 Feb 2023 19:50:24 GMT, Alan Bateman wrote:
> The change looks good, I'm just curious whether you observed a crash or
> whether this was noticed by inspection.
Noticed by exploration. Changed the java code on the jlink side and observed
the crash.
-
PR: https://git.open
On Mon, 13 Feb 2023 16:57:17 GMT, Severin Gehwolf wrote:
> The `jimage` location attributes are terminated with `ATTRIBUTE_END`-kinds.
> However,
> the byte containing `ATTRIBUTE_END` (most significant 5 bits, represent
> `kind`), might
> be non-zero in the lower 3 bits (val
On Mon, 13 Feb 2023 16:57:17 GMT, Severin Gehwolf wrote:
> The `jimage` location attributes are terminated with `ATTRIBUTE_END`-kinds.
> However,
> the byte containing `ATTRIBUTE_END` (most significant 5 bits, represent
> `kind`), might
> be non-zero in the lower 3 bits (val
On Tue, 14 Feb 2023 10:40:31 GMT, Alan Bateman wrote:
> Can you update the end date of the copyright headers as this is the first
> change in 2023. imageFile.cpp by missed by the other change so it could be
> done here too.
Absolutely! Thanks for the review.
-
PR: https://git.ope
d `0x00` and `0x07` or any value in between.
>
> Thoughts?
Severin Gehwolf has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains three additional
com
On Tue, 14 Feb 2023 10:40:31 GMT, Alan Bateman wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contain
On Tue, 14 Feb 2023 16:47:15 GMT, Jim Laskey wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contain
On Tue, 14 Feb 2023 16:59:03 GMT, Severin Gehwolf wrote:
>> src/java.base/share/native/libjimage/imageFile.hpp line 218:
>>
>>> 216: // Notes:
>>> 217: // - Even though ATTRIBUTE_END is used to mark the end of the
>>> attribute stream,
>>>
On Tue, 14 Feb 2023 17:17:53 GMT, Jim Laskey wrote:
>> To me it sounded like it wanted to say: Since the `ATTRIBUTE_END` isn't a
>> full byte (only 5 bits in a byte), it might be represented as a non-zero
>> value. For example a byte containing `0x07` would equally be `ATTRIBUTE_END`
>> as wou
On Tue, 14 Feb 2023 17:18:00 GMT, Jim Laskey wrote:
>> Severin Gehwolf has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contain
On Tue, 14 Feb 2023 18:10:11 GMT, Jim Laskey wrote:
>> Got it. How about we change this comment from:
>>
>> // - Even though ATTRIBUTE_END is used to mark the end of the attribute
>> stream,
>> // streams will contain zero byte values to represent lesser
>> significant bits.
>> // T
d `0x00` and `0x07` or any value in between.
>
> Thoughts?
Severin Gehwolf has updated the pull request incrementally with three
additional commits since the last revision:
- Another fixup.
- Correct comment in imageFile.hpp
- Copyright update in PerfectHashBuilder
-
Change
On Tue, 14 Feb 2023 19:30:19 GMT, Severin Gehwolf wrote:
>> Could I please get a review of this trivial comment-only change?
>> `imageFile.hpp`
>> describes some properties of the jimage file `lib/modules`. However, I don't
>> think
>> the comment exam
On Mon, 13 Feb 2023 14:12:15 GMT, Severin Gehwolf wrote:
> Could I please get a review of this trivial comment-only change?
> `imageFile.hpp`
> describes some properties of the jimage file `lib/modules`. However, I don't
> think
> the comment example matches cur
Please review this change for symbol visibility of static library artefacts.
This fixes an issue when
OpenJDK is being used as a base for generating native images preventing the
symbols from being
exported and looked up from the executable. Note that symbol visibity is now
controlled by a
linker
On Mon, 27 Mar 2023 05:23:26 GMT, David Holmes wrote:
>> Please review this change for symbol visibility of static library artefacts.
>> This fixes an issue when
>> OpenJDK is being used as a base for generating native images preventing the
>> symbols from being
>> exported and looked up from t
On Mon, 27 Mar 2023 08:56:15 GMT, Severin Gehwolf wrote:
>> make/autoconf/flags-cflags.m4 line 639:
>>
>>> 637: STATIC_LIBS_CFLAGS="-DSTATIC_BUILD=1"
>>> 638: if test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TY
visibity is now
> controlled by a
> linker version script downstream. This changes nothing for the regularly
> shipped dynamic libraries.
>
> Thoughts?
Severin Gehwolf has updated the pull request incrementally with one additional
commit since the last revision:
Explicitly set the JNI
On Mon, 27 Mar 2023 13:04:28 GMT, Erik Joelsson wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Explicitly set the JNI_EXPORT define for static libs
>
> Marked as reviewed by eri
On Tue, 28 Mar 2023 04:40:24 GMT, David Holmes wrote:
> I also added this to JBS:
>
> JDK-8239563 was also done to support Graal, and this change is now undoing
> that. Do the Graal folk who want this understand it will restore the problem
> that JDK-8239563 fixed?
I have no insight as to why
On Mon, 27 Mar 2023 09:40:22 GMT, Severin Gehwolf wrote:
>> Please review this change for symbol visibility of static library artefacts.
>> This fixes an issue when
>> OpenJDK is being used as a base for generating native images preventing the
>> symbols from being
&
On Fri, 24 Mar 2023 15:31:32 GMT, Severin Gehwolf wrote:
> Please review this change for symbol visibility of static library artefacts.
> This fixes an issue when
> OpenJDK is being used as a base for generating native images preventing the
> symbols from being
> exported and
On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou wrote:
> This PR is branched from the makefile changes for
> https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for
> handling the JDK/VM static libraries:
>
> - Create libjvm.a together with other JDK static libraries when buil
On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou wrote:
> This PR is branched from the makefile changes for
> https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for
> handling the JDK/VM static libraries:
>
> - Create libjvm.a together with other JDK static libraries when buil
On Wed, 3 May 2023 18:40:52 GMT, Jiangli Zhou wrote:
>> I'm hoping to get input from the graal team on the impact of this change.
>> The exact usage of the new libjvm.a file is still under discussion so I
>> share you concern about changing things for the current static libs usecase
>> before
On Thu, 4 May 2023 09:40:31 GMT, Paul Woegerer wrote:
>> GraalVM native-image has it's own `libjvm.a` shim which would likely
>> conflict or produce undesirable results. So I'd prefer the approach where
>> `static-libs-image` wouldn't produce hotspot `libjvm.a` as part of it. For
>> new uses-c
On Fri, 5 May 2023 16:52:22 GMT, Jiangli Zhou wrote:
>> This PR is branched from the makefile changes for
>> https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for
>> handling the JDK/hotspot static libraries:
>>
>> - Introduce new make target(s) for creating image/bundle c
On Fri, 5 May 2023 20:43:41 GMT, Erik Joelsson wrote:
> All of that said, I think we can get away with a smaller subset of targets
> and deliverables. AFAIK, graal needs the combined `graal-builder-image` as
> input to their build anyway, so they should not have any dependency on what
> the ta
On Tue, 9 May 2023 23:06:23 GMT, Jiangli Zhou wrote:
>> This PR is branched from the makefile changes for
>> https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for
>> handling the JDK/hotspot static libraries:
>>
>> - Introduce new make target(s) for creating image/bundle c
Please review these test changes which implement automatic testing of container
resource updates without JVM restart. Note that this merely tests container
detection code handling this case. It doesn't do anything special for the JVM
itself, though it might make sense to add some sanity checks s
der to make them cooperate. Note that the
> new test needs `podman` version `4.3.0` and better (`4.5` is current).
>
> Testing:
> - [ ] GHA (still running)
> - [x] Linux x86_64 container tests on cg v1 and cg v2 system
> - [x] Newly added tests on Linux x86_64 cg v1 and cg
On Wed, 18 May 2022 18:14:52 GMT, Severin Gehwolf wrote:
>> Please review this change to the cgroup v1 subsystem which makes it more
>> resilient on some of the stranger systems. Unfortunately, I wasn't able to
>> re-create a similar system as the reporter. The id
On Wed, 6 Jul 2022 03:52:30 GMT, xpbob wrote:
>> Container configuration information is useful for troubleshooting
>> problems,Exposing information in MBeans is ideal for monitoring, jConsole,
>> and other scenarios.
>> Results the following
>>  {
>>> 110: String[] tokens = line.split("\t");
>>
>> With this chang
On Tue, 6 Jun 2023 10:10:38 GMT, Aleksandar Pejovic
wrote:
>> I'm not convinced this is a good change. Going by that mailing list thread,
>> it suggests that people considered changing it. If one of those attempts
>> were successful, it would have broken this code. It makes it rather fragile.
Please review this patch which adds a "jmodless" jlink mode to the JDK.
Fundamentally this patch adds an option to use `jlink` even though your JDK
install might not come with the packaged modules (directory `jmods`). This is
particularly useful to further reduce the size of a jlinked runtime. A
On Thu, 6 Jul 2023 17:34:10 GMT, Severin Gehwolf wrote:
> Please review this patch which adds a "jmodless" jlink mode to the JDK.
> Fundamentally this patch adds an option to use `jlink` even though your JDK
> install might not come with the packaged modules (director
d.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotspot.agent.jmod jdk.internal.vm.compiler.management.jmod
> j
d.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotspot.agent.jmod jdk.internal.vm.compiler.management.jmod
&
On Tue, 8 Aug 2023 16:34:09 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a "jmodless" jlink mode to the JDK.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>> install might not come with the packaged modules (dir
On Tue, 30 May 2023 13:03:27 GMT, Aleksandar Pejovic
wrote:
> The current code for cgroup support in the JDK has large and expensive
> dependencies: it uses NIO, streams, and regular expressions. This leads to
> unnecessary class loading and slows down startup, especially when the code is
> e
Please review this rather trivial fix to not use `nio` in `CgroupUtil`, part of
the
JDK's Metrics API. The primary motivating factor is that it allows one to use
the
JDK's version of `Metrics` in GraalVM. See the bug for details as to why this is
needed.
Testing:
- [x] GraalVM builds with/withou
On Thu, 24 Aug 2023 13:37:36 GMT, Alan Bateman wrote:
> Something fishy here, is this working around a bug in GraaVM native image or
> why does this change need to be in JDK?
I've now realized that the bug had an incorrect statement in the description.
The cycle happens due to the `Runtime.get
On Tue, 30 May 2023 13:03:27 GMT, Aleksandar Pejovic
wrote:
> The current code for cgroup support in the JDK has large and expensive
> dependencies: it uses NIO, streams, and regular expressions. This leads to
> unnecessary class loading and slows down startup, especially when the code is
> e
On Fri, 25 Aug 2023 10:04:28 GMT, Alan Bateman wrote:
> In this case, it seems a bit fragile to do it in CgroupUtil as it should be
> allowed to use any of the file system APIs to access cgroups or proc files.
In theory, yes. It should be able to use any file system APIs. Practically, it
doesn
On Fri, 25 Aug 2023 10:04:28 GMT, Alan Bateman wrote:
>>> Something fishy here, is this working around a bug in GraaVM native image
>>> or why does this change need to be in JDK?
>>
>> I've now realized that the bug had an incorrect statement in the
>> description. The cycle happens due to the
On Mon, 28 Aug 2023 15:29:32 GMT, Alan Bateman wrote:
> > @AlanBateman Is there anything else you need me to do? If so, please let me
> > know. Thanks!
>
> I don't think the JDK is the right place to workaround this issue. Also, we
> really need to get back re-implementing FileInputStream and
On Thu, 24 Aug 2023 13:16:16 GMT, Severin Gehwolf wrote:
> Please review this rather trivial fix to not use `nio` in `CgroupUtil`, part
> of the
> JDK's Metrics API. The primary motivating factor is that it allows one to use
> the
> JDK's version of `Metrics` in
On Thu, 10 Aug 2023 17:21:31 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a "jmodless" jlink mode to the JDK.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>> install might not come with the packaged modul
On Tue, 29 Aug 2023 17:31:00 GMT, Alan Bateman wrote:
> > @AlanBateman Gentle ping.
>
> On my list, it's a lot to get through and a number of aspects to this that I
> think will require refinement and discussion.
Thanks for the heads-up! Your input is much appreciated.
-
PR Comme
On Tue, 19 Sep 2023 17:39:04 GMT, Alan Bateman wrote:
> I did a pass over this to see where this proposal is currently at. At a
> high-level I think good progress since the discussion on leyden-dev some time
> ago. A few comments this from this pass:
Thanks, Alan!
> If I read it correctly, th
d.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotspot.agent.jmod jdk.internal.vm.compiler.management.jmod
> j
On Fri, 29 Sep 2023 16:42:37 GMT, Severin Gehwolf wrote:
> The command line options to override and change the error to a warning or
> silently ignore seems to be "-run-time-ignore-single-hop" and
> "--run-image-only-warnings". Maybe it should be reduced to ju
d.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotspot.agent.jmod jdk.internal.vm.compiler.management.jmod
> j
d.jmod jdk.internal.vm.compiler.jmod
> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod
> java.desktop.jmod java.scripting.jmod java.xml.jmod
> jdk.hotspot.agent.jmod jdk.internal.vm.compiler.management.jmod
&g
Hi,
Could I please get some reviews on the CSR for a feature that would
allow runtime image-based jlinks (no need for the packaged modules -
jmods folder - being present)?
https://bugs.openjdk.org/browse/JDK-8317420
It would be particularly helpful to get consensus on the naming (it's
hard!) and
On Wed, 18 Oct 2023 17:37:30 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a "jmodless" jlink mode to the JDK.
>> Fundamentally this patch adds an option to use `jlink` even though your JDK
>> install might not come with the packaged modul
On Thu, 2023-10-19 at 14:27 +0100, Alan Bateman wrote:
> > Could I please get some reviews on the CSR for a feature that would
> > allow runtime image-based jlinks (no need for the packaged modules -
> > jmods folder - being present)?
> >
> > https://bugs.openjdk.org/browse/JDK-8317420
> >
> > It
101 - 200 of 677 matches
Mail list logo
