On Mon, 18 Nov 2024 15:44:14 GMT, Magnus Ihse Bursie wrote:
>> Hi all,
>>
>> Some developers want to run some initial scripts locally when the debugger
>> (gdb or lldb) starts. So they often add a file named `.gdbinit` or
>> `.lldbinit` in the project root path. It is good to ignore them.
>>
On Mon, 18 Nov 2024 08:47:24 GMT, Matthias Baesken wrote:
>> I asked the same question. But as further discussion has indicated, we
>> might need this define for
>> disabling the poisoning of selected C library functions when building with
>> LTO, because LTO doesn't
>> support the mechanism u
On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote:
> Currently, the man pages are stored as troff (a text format) in the open
> repo, and a content-wise identical copy is stored as markdown (another text
> format) in the closed repo.
>
> Since markdown is preferred to troff in terms o
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
On Fri, 8 Nov 2024 17:42:24 GMT, Roman Kennke wrote:
>> Could you please cherry pick
>> https://github.com/mur47x111/jdk/commit/c45ebc2a89d0b25a3dd8cc46386e37a635ff9af2
>> for the JVMCI support?
>
> @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-)
@rkennke I have now looked
On Fri, 8 Nov 2024 17:42:24 GMT, Roman Kennke wrote:
>> Could you please cherry pick
>> https://github.com/mur47x111/jdk/commit/c45ebc2a89d0b25a3dd8cc46386e37a635ff9af2
>> for the JVMCI support?
>
> @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-)
@rkennke How important is
On Fri, 8 Nov 2024 17:42:24 GMT, Roman Kennke wrote:
>> Could you please cherry pick
>> https://github.com/mur47x111/jdk/commit/c45ebc2a89d0b25a3dd8cc46386e37a635ff9af2
>> for the JVMCI support?
>
> @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-)
> @rkennke How important i
On Tue, 3 Sep 2024 19:51:39 GMT, Erik Joelsson wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Also include information about where generated data is consumed.
>> - Document how and why we keep track of na
On Mon, 18 Nov 2024 16:02:39 GMT, Matthias Baesken wrote:
>> When trying LTO (configure flag --enable-jvm-feature-link-time-opt=yes) on
>> Linux x86_64, gcc 11.3.0, we run into a lot of warnings and finally into
>> this error :
>>
>> .. tons of free and malloc related warnings ...
>>
>>
>>
On Mon, 18 Nov 2024 12:38:37 GMT, Matthias Baesken wrote:
> A first nice advantage seems to be the smaller size of libjvm.so coming from
> the lto build; lto build
>
> ```
> du -sh images/jdk/lib/server/libjvm.so
> 22M images/jdk/lib/server/libjvm.so
> ```
>
> normal build
>
> ```
> du -sh
On Mon, 18 Nov 2024 11:19:11 GMT, Matthias Baesken wrote:
>> When trying LTO (configure flag --enable-jvm-feature-link-time-opt=yes) on
>> Linux x86_64, gcc 11.3.0, we run into a lot of warnings and finally into
>> this error :
>>
>> .. tons of free and malloc related warnings ...
>>
>>
>>
On Mon, 18 Nov 2024 08:50:59 GMT, Matthias Baesken wrote:
>> The old LTO used to set -O3 directly on both LDFLAGS and CFLAGS, bypassing
>> OPTIMIZATION variable entirely. Just wanted to put this out there, since the
>> topic of traditional gcc LTO came up. I changed that to set OPTIMIZATION to
On Mon, 18 Nov 2024 11:19:11 GMT, Matthias Baesken wrote:
>> When trying LTO (configure flag --enable-jvm-feature-link-time-opt=yes) on
>> Linux x86_64, gcc 11.3.0, we run into a lot of warnings and finally into
>> this error :
>>
>> .. tons of free and malloc related warnings ...
>>
>>
>>
On Thu, 30 May 2024 13:00:21 GMT, Magnus Ihse Bursie wrote:
> This patch contains a set of changes to improve static builds. They will pave
> the way for implementing a full static-only java launcher. The changes here
> will:
>
> 1) Make sure non-exported symbols are made local in the static l
On Mon, 18 Nov 2024 14:34:13 GMT, Quan Anh Mai wrote:
>> @rkennke
>>> BTW, this problem is not specific to UseCompactObjectHeaders - I think the
>>> same problem would happen with -UseCompressedClassPointers. With
>>> uncompressed class-pointers, byte[] would start at offset 20, while long[]
>
On Mon, 18 Nov 2024 14:36:17 GMT, Emanuel Peter wrote:
>> @eme64 Tbh I don't see how `AlignVector` can mitigate the issue if strict
>> alignment is required unless the object base is guaranteed to be aligned at
>> least as much as the vector length.
>
> @merykitty the object base is always at l
On Mon, 18 Nov 2024 14:35:41 GMT, Roman Kennke wrote:
>>> @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care
>>> about strict alignment `AlignVector`. But maybe other people care, and have
>>> to make that tradeoff between vectorization and small object headers.
>>
>> B
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
On Fri, 15 Nov 2024 04:49:51 GMT, David Holmes wrote:
>> Roman Kennke has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 107 commits:
>>
>> - Merge branch 'master' into JDK-8305895-v4
>> - Merge tag 'jdk-25+23' into JDK-8305895-v4
On Mon, 18 Nov 2024 14:31:52 GMT, Emanuel Peter wrote:
>>> @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care
>>> about strict alignment `AlignVector`. But maybe other people care, and have
>>> to make that tradeoff between vectorization and small object headers.
>>
>>
On Mon, 18 Nov 2024 13:57:29 GMT, Magnus Ihse Bursie wrote:
>> As a prerequisite for Hermetic Java, we need a statically linked `java`
>> launcher. It should behave like the normal, dynamically linked `java`
>> launcher, except that all JDK native libraries should be statically, not
>> dynamic
On Mon, 18 Nov 2024 14:23:24 GMT, Roman Kennke wrote:
>>> @rkennke How important is the 4-byte saving on `byte, char, short, int,
>>> float` arrays? I'd assume they are not generally that small, at least a few
>>> elements? So could we make an exception, and have a `16-byte` offset to the
>>>
On Sat, 16 Nov 2024 16:29:20 GMT, Guoxiong Li wrote:
> Hi all,
>
> Some developers want to run some initial scripts locally when the debugger
> (gdb or lldb) starts. So they often add a file named `.gdbinit` or
> `.lldbinit` in the project root path. It is good to ignore them.
>
> Thanks for
On Mon, 21 Oct 2024 13:07:34 GMT, Magnus Ihse Bursie wrote:
>> src/java.base/unix/native/libjli/java_md.c line 279:
>>
>>> 277:char jvmpath[], jint so_jvmpath,
>>> 278:char jvmcfg[], jint so_jvmcfg) {
>>> 279: /* Compute/set the name o
On Mon, 18 Nov 2024 14:13:17 GMT, Roman Kennke wrote:
>> @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-)
>
>> @rkennke How important is the 4-byte saving on `byte, char, short, int,
>> float` arrays? I'd assume they are not generally that small, at least a few
>> elements?
On Mon, 18 Nov 2024 14:13:17 GMT, Roman Kennke wrote:
>> @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-)
>
>> @rkennke How important is the 4-byte saving on `byte, char, short, int,
>> float` arrays? I'd assume they are not generally that small, at least a few
>> elements?
On Mon, 18 Nov 2024 15:20:17 GMT, Quan Anh Mai wrote:
>> @merykitty I guess we can always use
>> [vmovdqu](https://www.felixcloutier.com/x86/movdqu:vmovdqu8:vmovdqu16:vmovdqu32:vmovdqu64).
>>
>> And in fact that is exactly what we do:
>>
>> public class Test {
>> static int RANGE = 1024*10
On Mon, 18 Nov 2024 15:00:51 GMT, Roman Kennke wrote:
>>> @rkennke It just will (silently) not vectorize, thus running slower but
>>> still correct.
>>
>> Ok, I think we can live with that for now.
>>
>> As said elsewhere, we are currently working on 4-byte-headers, which would
>> make that p
On Mon, 18 Nov 2024 15:30:14 GMT, Magnus Ihse Bursie wrote:
>> test/hotspot/jtreg/gtest/MetaspaceUtilsGtests.java line 1:
>>
>>
>> This file was reduced to empty but not actually deleted. Can you fix it
>> please.
>
> @rkennke Just making sure this is not being missed. Can you please open a JB
On Mon, 18 Nov 2024 14:23:24 GMT, Roman Kennke wrote:
>>> @rkennke How important is the 4-byte saving on `byte, char, short, int,
>>> float` arrays? I'd assume they are not generally that small, at least a few
>>> elements? So could we make an exception, and have a `16-byte` offset to the
>>>
On Mon, 18 Nov 2024 14:35:41 GMT, Roman Kennke wrote:
>>> @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care
>>> about strict alignment `AlignVector`. But maybe other people care, and have
>>> to make that tradeoff between vectorization and small object headers.
>>
>> B
This fix deprecates for removal java.awt.Window.getWarningString() and also
javax.swing.JInternalFrame.getWarningString()
l java.awt.Window.getWarningString() is only relevant with a SecurityManager
and javax.swing.JInternalFrame.getWarningString() is just there for symmetry.
A few other spec ch
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
> When trying LTO (configure flag --enable-jvm-feature-link-time-opt=yes) on
> Linux x86_64, gcc 11.3.0, we run into a lot of warnings and finally into this
> error :
>
> .. tons of free and malloc related warnings ...
>
>
> inlined from 'pop_segment' at
> src/hotspot/share/utilities/sta
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
On Mon, 18 Nov 2024 11:19:11 GMT, Matthias Baesken wrote:
>> When trying LTO (configure flag --enable-jvm-feature-link-time-opt=yes) on
>> Linux x86_64, gcc 11.3.0, we run into a lot of warnings and finally into
>> this error :
>>
>> .. tons of free and malloc related warnings ...
>>
>>
>>
On Mon, 18 Nov 2024 11:19:11 GMT, Matthias Baesken wrote:
>> When trying LTO (configure flag --enable-jvm-feature-link-time-opt=yes) on
>> Linux x86_64, gcc 11.3.0, we run into a lot of warnings and finally into
>> this error :
>>
>> .. tons of free and malloc related warnings ...
>>
>>
>>
Some makefiles include JavaCompilation.gmk when they really want to include
ZipArchive.gmk. (Currently, JavaCompilation.gmk includes ZipArchive.gmk
indirectly to keep backwards compatibility from when these were implemented in
the same file.)
Also, all files that calls SetupJarArchive should in
On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote:
>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>>
>> It is also a follow-up to #20640, which now also includes (and supersedes)
>> #20603 and #20605, plus the Tiny Class-Pointers parts that have been
>> previ
On Mon, 18 Nov 2024 15:00:51 GMT, Roman Kennke wrote:
>>> @rkennke It just will (silently) not vectorize, thus running slower but
>>> still correct.
>>
>> Ok, I think we can live with that for now.
>>
>> As said elsewhere, we are currently working on 4-byte-headers, which would
>> make that p
On Mon, 18 Nov 2024 14:38:20 GMT, Quan Anh Mai wrote:
>> @merykitty the object base is always at least `8-byte` aligned, see
>> `ObjectAlignmentInBytes` - this also holds for all arrays. But the issue is
>> the offset from the object base to the array payload.
>>
>> @rkennke yes, working on fi
On Mon, 18 Nov 2024 14:41:25 GMT, Emanuel Peter wrote:
>> @eme64 Please correct me if I'm wrong but the issue is you need the base to
>> be aligned at 32 bytes on AVX2 machines for any alignment for vector
>> instruction to be meaningful, so I don't see the value of vector alignment
>> at all.
On Mon, 18 Nov 2024 11:19:11 GMT, Matthias Baesken wrote:
>> When trying LTO (configure flag --enable-jvm-feature-link-time-opt=yes) on
>> Linux x86_64, gcc 11.3.0, we run into a lot of warnings and finally into
>> this error :
>>
>> .. tons of free and malloc related warnings ...
>>
>>
>>
> When trying LTO (configure flag --enable-jvm-feature-link-time-opt=yes) on
> Linux x86_64, gcc 11.3.0, we run into a lot of warnings and finally into this
> error :
>
> .. tons of free and malloc related warnings ...
>
>
> inlined from 'pop_segment' at
> src/hotspot/share/utilities/sta
On Wed, 13 Nov 2024 01:40:23 GMT, Jiangli Zhou wrote:
>> @jianglizhou Thank you for your assistance in figuring out the problem. I
>> guess I throw out too much code from the hermetic-java-runtime branch when
>> trying to minimize the changes to only build-related stuff. The jimage
>> changes
On Mon, 18 Nov 2024 14:43:48 GMT, Quan Anh Mai wrote:
>> @merykitty
>>> Please correct me if I'm wrong but the issue is you need the base to be
>>> aligned at 32 bytes on AVX2 machines for any alignment for vector
>>> instruction to be meaningful, so I don't see the value of vector alignment
On Mon, 18 Nov 2024 14:48:22 GMT, Emanuel Peter wrote:
>> @eme64 You will need the alignment for the whole vector (which means 32
>> bytes for a `ymm` load), not alignment only on its elements. Vector element
>> is the artefact of ALU units, not the load/store units that actually care
>> about
On Mon, 18 Nov 2024 14:50:51 GMT, Quan Anh Mai wrote:
>> @merykitty In `AlignmentSolver::solve` /
>> `src/hotspot/share/opto/vectorization.cpp` you can see how I compute if
>> vectors can be aligned.
>
> @eme64 If you load a 32-byte (256-bit) vector, then the load is aligned if
> the address i
On Mon, 18 Nov 2024 14:23:24 GMT, Roman Kennke wrote:
>>> @rkennke How important is the 4-byte saving on `byte, char, short, int,
>>> float` arrays? I'd assume they are not generally that small, at least a few
>>> elements? So could we make an exception, and have a `16-byte` offset to the
>>>
On Mon, 18 Nov 2024 15:01:09 GMT, Emanuel Peter wrote:
>> @eme64 If you load a 32-byte (256-bit) vector, then the load is aligned if
>> the address is divisible by 32, otherwise the load is misaligned. That's why
>> [`vmovdqua`](https://www.felixcloutier.com/x86/movdqa:vmovdqa32:vmovdqa64)
>>
On Mon, 18 Nov 2024 11:19:11 GMT, Matthias Baesken wrote:
>> When trying LTO (configure flag --enable-jvm-feature-link-time-opt=yes) on
>> Linux x86_64, gcc 11.3.0, we run into a lot of warnings and finally into
>> this error :
>>
>> .. tons of free and malloc related warnings ...
>>
>>
>>
> See the discussion in the bug. I think we can stop testing Mac x86 in GHA,
> leaving only the build jobs.
>
> Additional testing:
> - [x] GHA passes
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains two commits:
-
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
On Mon, 18 Nov 2024 11:19:11 GMT, Matthias Baesken wrote:
>> When trying LTO (configure flag --enable-jvm-feature-link-time-opt=yes) on
>> Linux x86_64, gcc 11.3.0, we run into a lot of warnings and finally into
>> this error :
>>
>> .. tons of free and malloc related warnings ...
>>
>>
>>
On Mon, 18 Nov 2024 12:07:04 GMT, Aleksey Shipilev wrote:
>> See the discussion in the bug. I think we can stop testing Mac x86 in GHA,
>> leaving only the build jobs.
>>
>> Additional testing:
>> - [x] GHA passes
>
> Aleksey Shipilev has updated the pull request with a new target base due to
On Fri, 15 Nov 2024 18:36:51 GMT, Julian Waters wrote:
>> Catching up with the discussion...
>>
>> LTO has been working before, and was indeed enabled for the old embedded
>> platform. Since then, it has not been regularly tested and has certainly
>> bit-rottet.
>>
>> I think it is a good thi
On Fri, 15 Nov 2024 22:33:24 GMT, Kim Barrett wrote:
>> make/hotspot/lib/JvmFeatures.gmk line 173:
>>
>>> 171: JVM_OPTIMIZATION := HIGHEST_JVM
>>> 172: ifeq ($(call isCompiler, gcc), true)
>>> 173: JVM_CFLAGS_FEATURES += -DINCLUDE_LINK_TIME_OPTIMIZATION=1
>>> -flto=auto -fuse-linker-plu
On Wed, 16 Oct 2024 07:39:06 GMT, Magnus Ihse Bursie wrote:
>> Yes, I just pushed a commit that does that. I have manually inspected the
>> values and it looks sane, but I need to verify it on our CI system as well.
>> The reasoning for us setting some of the ld flags are less than clear, so it
On Mon, 18 Nov 2024 10:06:05 GMT, Magnus Ihse Bursie wrote:
> Some makefiles include JavaCompilation.gmk when they really want to include
> ZipArchive.gmk. (Currently, JavaCompilation.gmk includes ZipArchive.gmk
> indirectly to keep backwards compatibility from when these were implemented
> in
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically, linked.
>
> This patch is the first step towards this goal.
On Mon, 18 Nov 2024 10:06:05 GMT, Magnus Ihse Bursie wrote:
> Some makefiles include JavaCompilation.gmk when they really want to include
> ZipArchive.gmk. (Currently, JavaCompilation.gmk includes ZipArchive.gmk
> indirectly to keep backwards compatibility from when these were implemented
> in
61 matches
Mail list logo
