On Thu, 23 May 2024 18:52:53 GMT, Alan Bateman wrote:
> Yes, I want to help you get this one over the line.
Thanks! Appreciate that.
-
PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2133375454
On Thu, 16 May 2024 13:47:20 GMT, Alan Bateman wrote:
>>> If I understand you correctly, this would be no longer a build-time only
>>> approach to produce the "linkable runtime"? It would be some-kind of
>>> jlink-option driven approach (as it would run some code that should only
>>> run when
On Wed, 22 May 2024 12:25:09 GMT, Severin Gehwolf wrote:
>> I did some testing and it turns out that this is indeed not checked. I
>> believe this is a miss in the Skara reimplementation of jcheck. I've opened
>> https://bugs.openjdk.org/browse/SKARA-2265 to track this.
&
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.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.ag
On Wed, 22 May 2024 08:07:59 GMT, Magnus Ihse Bursie wrote:
>> Actually, this is a bit strange. I thought jcheck would look for missing
>> newline at EOF, and that properties files were included in the check
>> nowadays. I'll need to check this out.
>
> I did some testing and it turns out that
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.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.ag
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.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.hotsp
On Wed, 8 May 2024 22:36:51 GMT, Magnus Ihse Bursie 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 105 commits:
>>
>> - Generate the runtime image link diff at jlink time
On Thu, 4 Apr 2024 20:56:55 GMT, Magnus Ihse Bursie wrote:
>> Severin Gehwolf has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Use shorter name for the build tool
>> - Review feedback from Erik J.
On Tue, 7 May 2024 16:52:12 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` ev
On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman wrote:
>>> > @mlchung @AlanBateman Any thoughts on this latest version? Is this going
>>> > into the direction you had envisioned? Any more blockers? The CSR should
>>> > be up-to-date and is open for review as well. If no more blockers I'll go
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.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.ag
On Tue, 7 May 2024 09:36:10 GMT, Jan Kratochvil wrote:
> Should JDK still support `memory.use_hierarchy == 0`?
IMO, no. Just get rid of it and assume hierarchical everywhere. We'd be walking
the hierarchy for other (lower limits), which should cover this case on those
legacy systems.
On Fri, 3 May 2024 15:58:11 GMT, Severin Gehwolf wrote:
>> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 375:
>>
>>> 373: if (!c.isContainerized()) {
>>> 374: ostream.println(INDENT + "System not containerized.");
On Mon, 22 Apr 2024 13:56:23 GMT, Jan Kratochvil
wrote:
> Anyway in this patch one could unify naming across variables/parameters, the
> same value is called `_is_ro`, `is_read_only`, `ro_opt`, `read_only`, `ro`.
I've tried to unify the naming a bit. Thanks for the review!
-
PR
situation of
> claiming a containerized system being present when it's actually just a
> regular Linux system.
>
> Testing:
>
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including
> gtests)
&
On Tue, 16 Apr 2024 18:21:29 GMT, Thomas Stuefe wrote:
> Why return here?
Because it's not useful to see containerized settings (other than the cg
version in use) after this patch. The JVM won't use them (uses the physical
settings instead). Why would you want to show the settings?
On Tue, 16 Apr 2024 18:10:08 GMT, Thomas Stuefe wrote:
>> src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 351:
>>
>>> 349: //
>>> 350: // We collect the read only mount option in the cgroup infos so as
>>> to have that
>>> 351: // info ready when determining is_containerized().
On Tue, 16 Apr 2024 18:16:33 GMT, Thomas Stuefe 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 conta
On Sun, 10 Mar 2024 14:40:09 GMT, Jan Kratochvil
wrote:
>> The testcase requires root permissions.
>>
>> Designed by Severin Gehwolf, implemented by Jan Kratochvil.
>
> Jan Kratochvil has updated the pull request with a new target base due to a
> merge or a r
On Tue, 30 Apr 2024 07:01:16 GMT, Jan Kratochvil
wrote:
> * Will the patch be accepted only for memory or it has to support also CPU?
It should be fine for memory only for a start, but we should allow for
on-boarding of other controllers as well.
> * Should I code it on top of OpenJDK trunk
On Sun, 10 Mar 2024 14:40:09 GMT, Jan Kratochvil
wrote:
>> The testcase requires root permissions.
>>
>> Designed by Severin Gehwolf, implemented by Jan Kratochvil.
>
> Jan Kratochvil has updated the pull request with a new target base due to a
> merge or a r
On Thu, 11 Apr 2024 12:08:02 GMT, Severin Gehwolf wrote:
>> Please review this enhancement to the container detection code which allows
>> it to figure out whether the JVM is actually running inside a container
>> (`podman`, `docker`, `crio`), or with some other means that e
On Thu, 18 Apr 2024 13:27:38 GMT, Jan Kratochvil
wrote:
> Could not we rename `is_containerized()` to `use_container_limit()` ? As that
> is the current only purpose of `is_containerized()`.
I'm not sure. There is value to have `is_containerized()` like it would behave
after this patch.
On Wed, 17 Apr 2024 01:07:04 GMT, Jan Kratochvil
wrote:
>>> IMHO `is_containerized()` is OK to return `false` even when running in a
>>> container but with no limitations set.
>>
>> The idea here is to use this property to tune OpenJDK for in-container,
>> specifically k8s, use. In such a
On Tue, 16 Apr 2024 13:54:53 GMT, Alan Bateman wrote:
> I think it continues to build time, it's just using some hidden jlink option.
> So yes, it similar to a previous iteration except that it doesn't run as a
> plugin the pipeline and the delta goes to the lib directory.
OK. If a hidden
On Tue, 16 Apr 2024 14:40:46 GMT, Jan Kratochvil
wrote:
> IMHO `is_containerized()` is OK to return `false` even when running in a
> container but with no limitations set.
The idea here is to use this property to tune OpenJDK for in-container,
specifically k8s, use. In such a setup it's
On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move CreateLinkableRuntimePlugin to build folder
>>
>> Keep runtim
situation of
> claiming a containerized system being present when it's actually just a
> regular Linux system.
>
> Testing:
>
> - [x] GHA (risc-v failure seems infra related)
> - [x] Container tests on Linux x86_64 of cgroups v1 and cgroups v2 (including
> gtests)
&
On Mon, 11 Mar 2024 16:55:36 GMT, Severin Gehwolf wrote:
> Please review this enhancement to the container detection code which allows
> it to figure out whether the JVM is actually running inside a container
> (`podman`, `docker`, `crio`), or with some other means that enforces
>
On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move CreateLinkableRuntimePlugin to build folder
>>
>> Keep runtim
On Fri, 5 Apr 2024 09:25:49 GMT, Magnus Ihse Bursie wrote:
>> Thanks. Yes, the long name was my doing. Sorry.
>
> Kind of aligning with the "Donaudampfschiffahrtsgesellschaftskapitän"
> prejudice of German. ;-)
>
>
>
> (In Sweden, we have "flaggstångsknoppsförgyllare" so you are not alone)
On Thu, 4 Apr 2024 20:56:02 GMT, Magnus Ihse Bursie wrote:
>> I was not aware of such a convention and I can't say I agree with it. It
>> just seems redundant and unnecessary, but I suppose we should wait for
>> Magnus to respond.
>
> Just to clarify: I did not say the name needed to be long,
On Tue, 19 Mar 2024 12:16:29 GMT, Viktor Klang wrote:
> This is a draft PR with a potential solution to 8328366 without regressing
> 8327501.
>
> @DougLea To avoid regressions in the future, where would regression tests for
> this ideally be located?
FWIW, I've tested this with the quarkus
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.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.
On Thu, 4 Apr 2024 12:56:41 GMT, Erik Joelsson 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 100 commits:
>>
>> - Fix coment
>> - Fix comment
>> - Fix typo
On Thu, 4 Apr 2024 13:00:33 GMT, Erik Joelsson 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 100 commits:
>>
>> - Fix coment
>> - Fix comment
>> - Fix typo
On Tue, 19 Mar 2024 12:16:29 GMT, Viktor Klang wrote:
> This is a draft PR with a potential solution to 8328366 without regressing
> 8327501.
>
> @DougLea To avoid regressions in the future, where would regression tests for
> this ideally be located?
Is there any update on this PR?
On Thu, 21 Mar 2024 15:35:06 GMT, Severin Gehwolf wrote:
>> Ok, fine. Will the new solution still include a build-time only tool?
>
> Yes, but I'll likely go with the interim solution and that would only require
> the a single "driver" class in the build tree with a
On Thu, 21 Mar 2024 15:30:01 GMT, Magnus Ihse Bursie wrote:
>> Thanks! This will also likely change. I'm thinking of just generating the
>> diff file and putting it into `lib/` of the JDK image. That avoids needing
>> to call this build-time only jlink plugin and this `FixPath` magic.
>
> I
On Thu, 21 Mar 2024 15:29:45 GMT, Severin Gehwolf wrote:
>> make/Images.gmk line 145:
>>
>>> 143: $(eval $(call SetupJavaCompilation, BUILD_JDK_RUNLINK_CLASSES, \
>>> 144: COMPILER := buildjdk, \
>>> 145: DISABLED_WARNINGS := try, \
>>
On Thu, 14 Mar 2024 17:46:19 GMT, Erik Joelsson wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix comment in autoconf file
>
> make/Images.gmk line 126:
>
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.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.ag
On Wed, 3 Apr 2024 22:31:39 GMT, Mandy Chung wrote:
> Thanks for the investigation w.r.t. extending jimage. It does not seem worth
> the effort in pursuing the support of adding resources to an existing jimage
> file. To me, putting the diff data under `lib` directory as a private file is
> a
On Tue, 19 Mar 2024 16:55:14 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` ev
On Mon, 11 Mar 2024 16:55:36 GMT, Severin Gehwolf wrote:
> Please review this enhancement to the container detection code which allows
> it to figure out whether the JVM is actually running inside a container
> (`podman`, `docker`, `crio`), or with some other means that enforces
>
On Thu, 21 Mar 2024 15:28:23 GMT, Magnus Ihse Bursie wrote:
>>> First question, do this class really need to be in a separate module? (I'm
>>> afraid the answer is "yes" but I need to ask it anyway).
>>
>> Yes, because it uses the `Plugin` ServiceLoader extension using the boot
>>
On Thu, 21 Mar 2024 14:54:15 GMT, Magnus Ihse Bursie wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move CreateLinkableRuntimePlugin to build folder
>>
>> Keep runtim
On Tue, 19 Mar 2024 18:05:31 GMT, Mandy Chung wrote:
> Thanks for the details. I feel the pain in extending jlink for this work as
> the current jlink implementation is not easily understandable and has been
> yearning for rewrite in my perspective (looking forward to Project Leyden's
>
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.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.hotsp
On Tue, 19 Mar 2024 14:59:19 GMT, Goetz Lindenmaier wrote:
> …rve enough space for 2097152KB object heap
>
> I would like to fix this as the two related issues mentioned in the JBS bug.
> We see it currently in most GHA runs.
Marked as reviewed by sgehwolf (Reviewer).
-
PR
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.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.ag
On Mon, 18 Mar 2024 20:18:09 GMT, Mandy Chung wrote:
> This is what I understand from your implementation:
>
> 1. create a regular JDK image under
> `support/images/runtime-link-initial-jdk` using jlink from the exploded JDK
> build
>
> 2. create a linkable JDK image under
On Mon, 18 Mar 2024 18:08:23 GMT, Mandy Chung wrote:
> > Yes we do. The main reason being that the `jdk` image has more to it than
> > just the image. `src.zip`, CDS data, `demo` and so on. We don't want to
> > duplicate that. To us, including the `jmods` folder is something that comes
> >
On Fri, 15 Mar 2024 18:09:36 GMT, Mandy Chung wrote:
> > Wasn't the intention to make "creating a linkable runtime image" a build
> > only decision and make the relevant infrastructure classes build-only
> > artefacts?
>
> Build-only decision means that the linkable runtime image is only
On Fri, 15 Mar 2024 19:29:49 GMT, Mandy Chung wrote:
> > > If `--enable-runtime-link-image` is enabled, the JDK image does not
> > > include the packaged modules.
> >
> >
> > That's not true. Right now `--enable-runtime-link-image` modifies how the
> > `lib/modules` image looks like (adds a
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.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.hotsp
On Thu, 14 Mar 2024 20:54:32 GMT, Mandy Chung wrote:
> > The updated patch uses a **build-only** `jlink` plugin, still called
> > `--create-linkable-runtime` which is _a)_ added only at build time with
> > `--add-modules` and _b)_ now generates the diff and prepares the image for
> > runtime
On Thu, 14 Mar 2024 21:16:04 GMT, Erik Joelsson wrote:
> About the configure options,
>
> ```
> --enable-keep-packaged-modules
> enable keeping of packaged modules in jdk image
> [enabled]
> --enable-runtime-link-image
> enable producing
On Thu, 14 Mar 2024 14:24:57 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` ev
On Tue, 27 Feb 2024 22:04:47 GMT, Erik Joelsson wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Only show runtime image suffix for JDK modules
>
> make/autoconf/jdk-
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.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.hotsp
On Tue, 12 Mar 2024 14:07:32 GMT, Magnus Ihse Bursie wrote:
>> I don't see a race. The `rm` was there in the original code and is no
>> scarier in the modified version. The jdk image is constructed by a
>> combination of targets and recipes. The first one to run has to be jlink,
>> then we
On Fri, 8 Mar 2024 17:25:18 GMT, Severin Gehwolf wrote:
>> make/Images.gmk line 96:
>>
>>> 94:
>>> 95: ifeq ($(JLINK_KEEP_PACKAGED_MODULES), true)
>>> 96: ifeq ($(JLINK_PRODUCE_RUNTIME_LINK_JDK), true)
>>
>> I don't get it. Why don
On Tue, 27 Feb 2024 22:06:12 GMT, Erik Joelsson wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Only show runtime image suffix for JDK modules
>
> make/autoconf/spec.gm
On Fri, 8 Mar 2024 19:49:19 GMT, Mandy Chung wrote:
>>> > @AlanBateman @mlchung I've now pushed an update of this patch which now
>>> > uses a build-time approach as discussed elsewhere. In order to produce a
>>> > linkable runtime JDK image, one needs to set --enable-runtime-link-image
>>> >
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.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.ag
Please review this enhancement to the container detection code which allows it
to figure out whether the JVM is actually running inside a container (`podman`,
`docker`, `crio`), or with some other means that enforces memory/cpu limits by
means of the cgroup filesystem. If neither of those
On Mon, 11 Mar 2024 13:24:54 GMT, Erik Joelsson wrote:
> Based on that I agree with the choice of using a configure argument.
Thanks. The intention is that without the extra configure argument you'd get
`jdk-image` as is today. Not modified. *With* `--enable-runtime-link-image` the
result of
On Wed, 21 Feb 2024 11:32:46 GMT, Jan Kratochvil
wrote:
> After internal discussion I have realized the patch has overgrown its
> intended scope. And one should also consider how easy it would be for a
> backport down to JDK-8. I am going to split it into:
>
> 1. cgroup1 bugfix to always
On Wed, 21 Feb 2024 13:37:22 GMT, Jan Kratochvil
wrote:
> > One goal of this patch would be to unify how this works for cgroup v1 and
> > cgroup v2.
>
> That is not much possible anyway as currently cgroup2 has to traverse the
> directories while after the kernel patch gets accepted it will
On Fri, 8 Mar 2024 17: 35: 45 GMT, Severin Gehwolf wrote: >> make/Images. gmk line 144: >> >>> 142: OUTPUT_DIR := $(JDK_IMAGE_DIR), \ >>> 143: SUPPORT_DIR := $(JDK_RUN_TIME_IMAGE_SUPPORT_DIR),
ZjQcmQRYFpfptBannerStart
This Mess
On Fri, 8 Mar 2024 16: 51: 11 GMT, Magnus Ihse Bursie wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Only show runtime
ZjQcmQRYFpfptBannerStart
This Message Is From
On Fri, 8 Mar 2024 16:52:33 GMT, Magnus Ihse Bursie wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Only show runtime image suffix for JDK modules
>
> make/Images.gmk l
On Fri, 8 Dec 2023 15:44:07 GMT, Alan Bateman 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 46 commits:
>>
>> - Add @enablePreview for JImageValidator that uses
On Wed, 6 Mar 2024 17:28:01 GMT, Magnus Ihse Bursie wrote:
>> Severin Gehwolf has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Only show runtime image suffix for JDK modules
>
> make/ToolsJdk.gmk line 8
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.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.hotsp
On Fri, 8 Dec 2023 15:44:07 GMT, Alan Bateman 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 46 commits:
>>
>> - Add @enablePreview for JImageValidator that uses
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.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.ag
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.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.ag
On Tue, 23 Jan 2024 15:46:04 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` ev
On Wed, 31 Jan 2024 15:33:01 GMT, Jan Kratochvil
wrote:
>> It looks like this patch needs a bit more discussion. Generally, it would be
>> good to have the functionality, but I'm unsure about the proposed
>> implementation.
>>
>> Walking the directory hierarchy (**and** interface files) on
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.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.hotsp
On Thu, 18 Jan 2024 21:35:06 GMT, Mandy Chung wrote:
> > > If I read the code correctly, the image created with this option will
> > > enable multi-hops unconditionally? i.e. no timestamp file created and
> > > disable the check completely. I think the .stamp file should be present
> > > in
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.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.ag
On Tue, 23 Jan 2024 13:04:43 GMT, sendaoYan wrote:
>> 8323640: [TESTBUG]testMemoryFailCount in
>> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail
>> because OOM killed
>
> sendaoYan has updated the pull request incrementally with one additional
> commit since the last
On Tue, 23 Jan 2024 01:58:40 GMT, sendaoYan wrote:
>> 8323640: [TESTBUG]testMemoryFailCount in
>> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail
>> because OOM killed
>
> sendaoYan has updated the pull request incrementally with one additional
> commit since the last
On Mon, 22 Jan 2024 09:31:43 GMT, sendaoYan wrote:
> 8323640: [TESTBUG]testMemoryFailCount in
> jdk/internal/platform/docker/TestDockerMemoryMetrics.java always fail because
> OOM killed
`1k` increments for a total of `512k` times seems overkill. Are you sure that's
needed to make the test
On Tue, 19 Dec 2023 19:14:42 GMT, Mandy Chung wrote:
>> Severin Gehwolf has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Disallow packaged modules and run-time image link
>> - Only check for existin
On Thu, 28 Dec 2023 15:19:23 GMT, Jan Kratochvil
wrote:
>> The testcase requires root permissions.
>
> Jan Kratochvil has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fix gtest testcases compilation errors
It looks like this patch needs a
On Thu, 28 Dec 2023 15:19:23 GMT, Jan Kratochvil
wrote:
>> The testcase requires root permissions.
>
> Jan Kratochvil has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fix gtest testcases compilation errors
I'm looking at it. Review should
On Tue, 19 Dec 2023 19:14:42 GMT, Mandy Chung wrote:
>> Severin Gehwolf has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Disallow packaged modules and run-time image link
>> - Only check for existin
On Mon, 11 Dec 2023 16:37:38 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` ev
On Mon, 11 Dec 2023 15:01:06 GMT, Severin Gehwolf wrote:
> NVM. Reproduced it.
... and fixed with
[b21585b](https://github.com/openjdk/jdk/pull/14787/commits/b21585bac17cdfe46ac3f2f6587b8a6b43a1cd56)
-
PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1850473199
r.jmodjava.rmi.jmodjava.xml.crypto.jmod
> jdk.editpad.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.hotsp
On Mon, 11 Dec 2023 09:56:49 GMT, Severin Gehwolf wrote:
> > Blowing away the generated image and retrying with --verbose tripped this
> > assert
> > ```
> > java.lang.AssertionError: handling of scratch options failed
&
On Tue, 5 Dec 2023 19:15:53 GMT, Severin Gehwolf wrote:
>> Please review this patch which adds a jlink mode to the JDK which doesn't
>> need the packaged modules being present. A.k.a run-time image based jlink.
>> Fundamentally this patch adds an option to use `jlink` ev
On Tue, 5 Dec 2023 19:15:53 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 packag
d 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
> jdk.jl
On Wed, 29 Nov 2023 23:31:56 GMT, Mandy Chung wrote:
> Thanks. I'll continue the review on the revised version.
@mlchung I've pushed the updates now. Please take another look. I'll merge
latest master in the next couple of hours.
-
PR Comment:
1 - 100 of 226 matches
Mail list logo
