Hi Pavel,
JTREG=MAX_OUTPUT=9 is what you're looking for.
Cheers,
Daniel
czw., 2 paź 2025 o 20:37 Pavel Rappo napisał(a):
>
> Hello,
>
> This has been probably asked multiple times, but I cannot quickly find
> anything. I'm running a set of tests as follows:
>
> make test TEST="test/jd
On Wed, 9 Apr 2025 18:35:12 GMT, Mikael Vidstedt wrote:
> [JDK-8342984](https://bugs.openjdk.org/browse/JDK-8342984) bumped the minimum
> boot jdk to JDK 24, and update the boot JDKs used in GHA in the process.
> Unfortunately the boot jdk for alpine-linux-x64 was incorrectly changed to
> use
On Thu, 3 Apr 2025 10:04:59 GMT, Magnus Ihse Bursie wrote:
> When running configure on WSL, the following error message is printed,
> instead of proper Linux environment info:
>
>
> /build/.configure-support/generated-configure.sh: line 13102: -d: command
> not found
>
>
> This is due
On Sat, 11 Mar 2023 15:10:09 GMT, Julian Waters wrote:
>> Was: sunmscapi.dll cannot compile with Visual C++
>>
>> `-Zc:wchar_t-` has, until now, been passed to switch off wchar_t as a
>> distinct C++ type when compiling with Visual C++ so jchar and wchar_t are
>> typedef'd to shorts on Windows
On Tue, 11 Feb 2025 07:46:54 GMT, Daniel Jeliński wrote:
> `make test TEST=gtest` fails to run gtest on WSL. This is because we're
> looking for a nonexistent file `gtestLauncher`; on Windows the file is named
> `gtestLauncher.exe`.
>
> This PR adds `$EXECUTABLE_SUFFIX` to
On Tue, 11 Feb 2025 07:46:54 GMT, Daniel Jeliński wrote:
> `make test TEST=gtest` fails to run gtest on WSL. This is because we're
> looking for a nonexistent file `gtestLauncher`; on Windows the file is named
> `gtestLauncher.exe`.
>
> This PR adds `$EXECUTABLE_SUFFIX` to
`make test TEST=gtest` fails to run gtest on WSL. This is because we're looking
for a nonexistent file `gtestLauncher`; on Windows the file is named
`gtestLauncher.exe`.
This PR adds `$EXECUTABLE_SUFFIX` to the executable path, similar to what
[GtestImage.gmk already
does](https://github.com/o
On Tue, 4 Feb 2025 08:51:43 GMT, Matthias Baesken wrote:
> Looks like the binary size optimization flags are not ideal when compiling
> with MSVC.
> On other compilers (gcc/clang) the current size optimization flags lead in
> most cases to smaller libraries. On MSVC this seems to be not the cas
On Tue, 4 Feb 2025 08:51:43 GMT, Matthias Baesken wrote:
> Looks like the binary size optimization flags are not ideal when compiling
> with MSVC.
> On other compilers (gcc/clang) the current size optimization flags lead in
> most cases to smaller libraries. On MSVC this seems to be not the cas
On Fri, 13 Sep 2024 20:41:27 GMT, Brian Burkhalter wrote:
>> This proposed change would move the native objects required for NIO file
>> interaction from the libnio native library to the libjava native library on
>> Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request in
On Thu, 12 Sep 2024 02:10:00 GMT, Brian Burkhalter wrote:
>> This proposed change would move the native objects required for NIO file
>> interaction from the libnio native library to the libjava native library on
>> Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request in
On Tue, 10 Sep 2024 19:58:45 GMT, Brian Burkhalter wrote:
>> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 575:
>>
>>> 573: * Used to trigger loading of native libraries
>>> 574: */
>>> 575: public static void load() { }
>>
>> do we still need this method?
>
> Yes, it st
On Wed, 11 Sep 2024 16:33:28 GMT, Brian Burkhalter wrote:
>> Right. This PR moves FileDispatcherImpl.c to libjava, so
>> FileDispatcherImpl.obj is no longer there. I'm guessing that our makefiles
>> don't detect source files that were removed, and Brian didn't run `make
>> clean`.
>
> From a c
On Tue, 10 Sep 2024 21:42:08 GMT, Magnus Ihse Bursie wrote:
>> well I'm not satisfied with the answers :) I removed mswsock.lib from libnio
>> dependencies
>> [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89)
>> and the buil
On Tue, 10 Sep 2024 13:30:05 GMT, Magnus Ihse Bursie wrote:
>> make/modules/java.base/lib/CoreLibraries.gmk line 71:
>>
>>> 69: -framework Foundation \
>>> 70: -framework SystemConfiguration, \
>>> 71: LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib
>>> versio
On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter wrote:
>> This proposed change would move the native objects required for NIO file
>> interaction from the libnio native library to the libjava native library on
>> Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request inc
On Wed, 21 Aug 2024 06:15:43 GMT, Jan Lahoda wrote:
>> Currently incremental builds for the microbenchmarks may take notable amount
>> of time, like:
>>
>> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java;
>> time make test TEST=jaxp:tier1
>> Building target 'test' in c
On Tue, 20 Aug 2024 14:51:03 GMT, Jan Lahoda wrote:
>> also interesting, but probably preexisting, and might be platform-specific
>> (tested on Cygwin):
>> - compile benchmarks with `make test TEST=jaxp:tier1`
>> - edit `test/micro/org/openjdk/bench/javax/crypto/full/AESGCMBench.java`
>> - touch
On Fri, 16 Aug 2024 12:24:19 GMT, Jan Lahoda wrote:
> Currently incremental builds for the microbenchmarks may take notable amount
> of time, like:
>
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java;
> time make test TEST=jaxp:tier1
> Building target 'test' in configu
On Fri, 16 Aug 2024 12:24:19 GMT, Jan Lahoda wrote:
> Currently incremental builds for the microbenchmarks may take notable amount
> of time, like:
>
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java;
> time make test TEST=jaxp:tier1
> Building target 'test' in configu
On Fri, 16 Aug 2024 12:24:19 GMT, Jan Lahoda wrote:
> Currently incremental builds for the microbenchmarks may take notable amount
> of time, like:
>
> $ touch test/micro/org/openjdk/bench/java/io/BlackholedOutputStream.java;
> time make test TEST=jaxp:tier1
> Building target 'test' in configu
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of thr
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of thr
Hi Anil,
Can you check what the following command prints on your machine?
$ cygpath -d "C:\Program Files\Microsoft Visual
Studio\2022\Community\VC\Auxiliary\Build"
I assume you have this directory on your machine, and it contains a
file named "vcvars64.bat"
The above command should print a path w
Hi,
If you want to know a Windows path to the Cygwin directory you're in,
you can use the following command:
$ cygpath -w `pwd`
C:\cygwin64\home\anil
If you want to know a Cygwin path without spaces for a Windows
directory, you can use the following:
$ cygpath `cygpath -d 'C:\Program Files\Micros
Hi Anil,
I can confirm that building on Windows 11 + cygwin + VS 2022 Community
installed with default settings and in the default location works just
fine without any extra command line parameters. The only parameter you
need is --with-boot-jdk, and even that can be omitted if you have the
right J
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of thr
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of thr
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of thr
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of thr
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of thr
On Tue, 18 Jun 2024 21:01:15 GMT, Daniel Jeliński wrote:
> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
> freed, but they are recycled when a thread dies, so the number of live
> ParkEvent instances is proportional to the maximum number of threads that
&g
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of thr
On Wed, 19 Jun 2024 16:50:22 GMT, Daniel Jeliński wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of thr
passed. Performance tests were... inconclusive. For example,
> `ThreadOnSpinWaitProducerConsumer` reported 30% better results, while
> `LockUnlock.testContendedLock` results were 50% worse.
>
> Thoughts?
Daniel Jeliński has updated the pull request incrementally with on
On Wed, 19 Jun 2024 13:59:23 GMT, Viktor Klang wrote:
>> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
>> freed, but they are recycled when a thread dies, so the number of live
>> ParkEvent instances is proportional to the maximum number of threads that
>> were live
On Wed, 19 Jun 2024 12:09:41 GMT, Thomas Stuefe wrote:
> With UseHeavyMonitors, even uncontended locks are inflated to OMs.
I don't think that matters much for the changed code; only the implementation
of park/unpark methods changed, and these methods are called for contended
locks only.
I ra
On Tue, 18 Jun 2024 21:01:15 GMT, Daniel Jeliński wrote:
> We use 2 ParkEvent instances per thread. The ParkEvent objects are never
> freed, but they are recycled when a thread dies, so the number of live
> ParkEvent instances is proportional to the maximum number of threads that
&g
We use 2 ParkEvent instances per thread. The ParkEvent objects are never freed,
but they are recycled when a thread dies, so the number of live ParkEvent
instances is proportional to the maximum number of threads that were live at
any time.
On Windows, the ParkEvent object wraps a kernel Event
On Fri, 24 May 2024 21:05:27 GMT, Mikael Vidstedt wrote:
>> Update the testing doc to remove some stale information (AOT_MODULES,
>> removed in [JDK-8264805](https://bugs.openjdk.org/browse/JDK-8264805)) and
>> fix some spelling issues.
>>
>> Testing: tier1
>
> Mikael Vidstedt has updated the
On Thu, 23 May 2024 23:22:51 GMT, Mikael Vidstedt wrote:
> Update the testing doc to remove some stale information (AOT_MODULES, removed
> in [JDK-8264805](https://bugs.openjdk.org/browse/JDK-8264805)) and fix some
> spelling issues.
>
> Testing: tier1
doc/testing.html line 366:
> 364: to se
On Thu, 2 May 2024 08:23:38 GMT, Vladimir Petko wrote:
> Hi,
>
> The `.type _SafeFetch32_impl,@function` symbol declaration contains a
> spurious underscore causing an undefined symbol in libjvm.so.
>
> I am not sure about change in default flags. I have removed the flag that
> allows li
On Wed, 10 Apr 2024 11:32:43 GMT, Daniel Jeliński wrote:
> The "Connection attempt failed: Connection refused" error may happen if the
> client tries to connect to a server that is no longer listening, which in
> turn may happen if the server shuts down without removi
On Wed, 10 Apr 2024 11:32:43 GMT, Daniel Jeliński wrote:
> The "Connection attempt failed: Connection refused" error may happen if the
> client tries to connect to a server that is no longer listening, which in
> turn may happen if the server shuts down without removi
The "Connection attempt failed: Connection refused" error may happen if the
client tries to connect to a server that is no longer listening, which in turn
may happen if the server shuts down without removing the port file. I added a
check that the delete operation succeeded, and retry as necessa
On Mon, 8 Apr 2024 09:20:44 GMT, Daniel Jeliński wrote:
> The RejectedExecutionException was thrown when the thread executing
> `Server.start` managed to shut down the `compilerThreadPool` before the
> thread executing `Server.handleRequest` submitted the compilation task.
>
On Mon, 8 Apr 2024 09:20:44 GMT, Daniel Jeliński wrote:
> The RejectedExecutionException was thrown when the thread executing
> `Server.start` managed to shut down the `compilerThreadPool` before the
> thread executing `Server.handleRequest` submitted the compilation task.
>
On Mon, 8 Apr 2024 09:20:44 GMT, Daniel Jeliński wrote:
> The RejectedExecutionException was thrown when the thread executing
> `Server.start` managed to shut down the `compilerThreadPool` before the
> thread executing `Server.handleRequest` submitted the compilation task.
>
The RejectedExecutionException was thrown when the thread executing
`Server.start` managed to shut down the `compilerThreadPool` before the thread
executing `Server.handleRequest` submitted the compilation task.
This patch removes the extra thread used for `Server.handleRequest`, and
executes t
On Tue, 27 Feb 2024 21:46:17 GMT, Magnus Ihse Bursie wrote:
>> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been
>> integrated, it is possible to do some cleanup. The goal of
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change
>> any behavior,
On Tue, 27 Feb 2024 11:19:59 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
>
On Mon, 26 Feb 2024 20:21:55 GMT, Magnus Ihse Bursie wrote:
>> The idea of setting up general "toolchains" in the native build was good,
>> but it turned out that we really only need a single toolchain, with a single
>> twist: if it should use CC or CPP to link. This is better described by a
>
On Mon, 26 Feb 2024 16:18:14 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), wa
On Fri, 23 Feb 2024 12:38:23 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), wa
On Fri, 23 Feb 2024 12:38:23 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), wa
On Thu, 22 Feb 2024 16:15:23 GMT, Magnus Ihse Bursie wrote:
>> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
>> compiler options and `JNIEXPORT` on all platforms.
>>
>> The bug that this PR solves,
>> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), wa
On Thu, 22 Feb 2024 16:28:20 GMT, Magnus Ihse Bursie wrote:
> Once [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) has been
> integrated, it is possible to do some cleanup. The goal of
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234) was to not change
> any behavior, eve
On Thu, 22 Feb 2024 09:41:45 GMT, Magnus Ihse Bursie wrote:
>> src/hotspot/share/utilities/debug.cpp line 71:
>>
>>> 69:
>>> 70: #if defined(TARGET_COMPILER_gcc)
>>> 71: #undef JNIEXPORT
>>
>> This partially reverts
>> [JDK-8264593](https://bugs.openjdk.org/browse/JDK-8264593); @kevinjwalls
On Wed, 21 Feb 2024 23:32:15 GMT, Magnus Ihse Bursie wrote:
> **Summary:** Finally get rid of the mapfiles in Hotspot, and replace it with
> compiler options and `JNIEXPORT` on all platforms.
>
> The bug that this PR solves,
> [JDK-8017234](https://bugs.openjdk.org/browse/JDK-8017234), was cre
Hi Magnus,
The "massive generated mapfile" is used on Windows. As you noticed, on
Linux symbols are exported if they are both JNIEXPORT and listed in
the mapfile. On Windows, the symbols are exported if they are either
JNIEXPORT or listed in the mapfile. The Windows symbolicator needs to
see the v
On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeliński wrote:
> I'd like to propose a new toolchain for Windows using the clang-cl compiler
> frontend.
>
> Clang-cl is available as an optional feature in all Visual Studio editions,
> including the free-for-OSS-developme
On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeliński wrote:
> I'd like to propose a new toolchain for Windows using the clang-cl compiler
> frontend.
>
> Clang-cl is available as an optional feature in all Visual Studio editions,
> including the free-for-OSS-developme
On Mon, 11 Dec 2023 14:37:35 GMT, Magnus Ihse Bursie wrote:
>> I'd like to propose a new toolchain for Windows using the clang-cl compiler
>> frontend.
>>
>> Clang-cl is available as an optional feature in all Visual Studio editions,
>> including the free-for-OSS-development community edition.
On Mon, 11 Dec 2023 03:42:21 GMT, Kim Barrett wrote:
>> I'd like to propose a new toolchain for Windows using the clang-cl compiler
>> frontend.
>>
>> Clang-cl is available as an optional feature in all Visual Studio editions,
>> including the free-for-OSS-development community edition.
>>
>>
On Fri, 8 Dec 2023 15:56:40 GMT, Magnus Ihse Bursie wrote:
> Do I understand you correctly that clang-cl uses "mostly" the same arguments
> as cl, but uses the clang warnings system, e.g. -Wno-foo-loops instead of
> C1234?
That's correct.
Clang-cl only supports the following cl warning paramet
On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeliński wrote:
> I'd like to propose a new toolchain for Windows using the clang-cl compiler
> frontend.
>
> Clang-cl is available as an optional feature in all Visual Studio editions,
> including the free-for-OSS-developme
On Fri, 8 Dec 2023 08:00:45 GMT, Julian Waters wrote:
> Is it possible to fold clang-cl into the microsoft toolchain instead, and
> just pass clang-cl as the compiler instead of cl?
I suppose it's possible; clang-cl output is supposed to be compatible with link
& lib, and most command line opt
On Thu, 7 Dec 2023 15:52:46 GMT, Daniel Jeliński wrote:
> I'd like to propose a new toolchain for Windows using the clang-cl compiler
> frontend.
>
> Clang-cl is available as an optional feature in all Visual Studio editions,
> including the free-for-OSS-developme
I'd like to propose a new toolchain for Windows using the clang-cl compiler
frontend.
Clang-cl is available as an optional feature in all Visual Studio editions,
including the free-for-OSS-development community edition.
Clang-cl command line is mostly compatible with cl. However, clang-cl offer
On Fri, 24 Nov 2023 09:58:17 GMT, Daniel Jeliński wrote:
>> The recent cdb versions do not support `.dump /f`:
>>
>> *
>> * .dump /f is not supporte
On Fri, 24 Nov 2023 07:58:18 GMT, Daniel Jeliński wrote:
> The recent cdb versions do not support `.dump /f`:
>
> *
> * .dump /f is not supported on a user
On Fri, 24 Nov 2023 11:36:27 GMT, Alan Bateman wrote:
>> It's ignoring the rest of the command line after `/f`, which means it
>> ignores the `;qd` (quit and detach) part and enters the interactive mode.
>
>> It's ignoring the rest of the command line after `/f`, which means it
>> ignores the `
On Fri, 24 Nov 2023 10:28:30 GMT, Alan Bateman wrote:
>> good point, 10 minutes should be more than enough. I'll update.
>
> Out of curiosity, do we know why it takes more than an hour? Is it attempting
> to connect to the Microsoft symbol server?
It's ignoring the rest of the command line afte
On Fri, 24 Nov 2023 09:09:03 GMT, Alan Bateman wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review comments
>
> test/failure_handler/src/share/conf/windows.proper
This PR updates the dump command to use the recommended `/ma` parameter. This
> allows the command to produce a dump and complete in a timely manner.
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
Address review comments
On Fri, 24 Nov 2023 09:17:47 GMT, Jaikiran Pai wrote:
>> test/failure_handler/src/share/conf/windows.properties line 61:
>>
>>> 59: native.core.app=cdb
>>> 60: native.core.args=-c ".dump /ma core.%p;qd" -p %p
>>> 61: native.core.params.timeout=360
>>
>> Hello Daniel, I found it surprising t
The recent cdb versions do not support `.dump /f`:
*
* .dump /f is not supported on a user mode process. *
* *
* .dump /ma c
On Tue, 31 Oct 2023 21:32:26 GMT, Daniel Jeliński wrote:
> hb-subset and hb-style APIs are not used and not exported by libfontmanger.
> We can cut the compilation time by not compiling the unused files.
>
> The added exclusions reduce the build time by ~1 minute (~8%) on my mach
On Tue, 31 Oct 2023 21:32:26 GMT, Daniel Jeliński wrote:
> hb-subset and hb-style APIs are not used and not exported by libfontmanger.
> We can cut the compilation time by not compiling the unused files.
>
> The added exclusions reduce the build time by ~1 minute (~8%) on my mach
On Tue, 31 Oct 2023 21:32:26 GMT, Daniel Jeliński wrote:
> hb-subset and hb-style APIs are not used and not exported by libfontmanger.
> We can cut the compilation time by not compiling the unused files.
>
> The added exclusions reduce the build time by ~1 minute (~8%) on my mach
On Mon, 6 Nov 2023 13:09:08 GMT, Daniel Jeliński wrote:
>> @djelinski Just curious; what would the effect be to both include this
>> change and setting the NO_* defines?
>>
>> If all the references to these defines are made in the excluded files then
>> the only
On Mon, 6 Nov 2023 12:26:58 GMT, Magnus Ihse Bursie wrote:
>> FWIW, I compiled the code without this PR, but with `HARFBUZZ_CFLAGS +=
>> -DHB_NO_SUBSET_LAYOUT -DHB_NO_SUBSET_CFF` instead, and checked `make
>> LOG=profile` output. Results:
>> - without this change, compiling `hb-subset.cc` took
On Wed, 1 Nov 2023 21:31:02 GMT, Daniel Jeliński wrote:
>> These two
>> #define HB_NO_SUBSET_LAYOUT
>> #define HB_NO_SUBSET_CFF
>
> You can find the file here:
> https://github.com/openjdk/jdk/blob/f262f06c97b9ea94cd6119b3a8beb16bf804d083/src/java.desktop/share/native
On Wed, 1 Nov 2023 18:52:15 GMT, Phil Race wrote:
>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 499:
>>
>>> 497:LIBFONTMANAGER_EXCLUDE_FILES += hb-ft.cc hb-subset-cff-common.cc \
>>> 498:hb-subset-cff1.cc hb-subset-cff2.cc hb-subset-input.cc
>>> hb-subset-plan.cc \
>>> 49
hb-subset and hb-style APIs are not used and not exported by libfontmanger. We
can cut the compilation time by not compiling the unused files.
The added exclusions reduce the build time by ~1 minute (~8%) on my machine.
This is with harfbuzz 8, with harfbuzz 7 the improvement was ~30 seconds.
C
On Thu, 26 Oct 2023 22:17:45 GMT, Claes Redestad wrote:
> The binutils build of libiberty is put in `$BINUTILS_INSTALL_DIR/lib64` on
> some Linux distributions (e.g. Fedora, Oracle Linux),
> `$BINUTILS_INSTALL_DIR/lib` on others (e.g. Ubuntu).
>
> This PR suggest simply adding logic to look fo
On Thu, 19 Oct 2023 13:49:21 GMT, Robbin Ehn wrote:
>> Hi please consider.
>>
>> This works with 2.30, 2.34, 2.38, 2.39, 2.40, 2.41 and current master head.
>> (tested x64 and some RV)
>>
>> There are 4 changes in binutils we work around.
>> - zstd compressed debug sections
>> - libsframe adde
On Thu, 19 Oct 2023 13:49:21 GMT, Robbin Ehn wrote:
>> Hi please consider.
>>
>> This works with 2.30, 2.34, 2.38, 2.39, 2.40, 2.41 and current master head.
>> (tested x64 and some RV)
>>
>> There are 4 changes in binutils we work around.
>> - zstd compressed debug sections
>> - libsframe adde
On Wed, 18 Oct 2023 09:31:22 GMT, Daniel Jeliński wrote:
> hsdis-binutils.c doesn't use any functions from libiberty.h. This header is
> absent on Ubuntu (installed separately, and under a different path), so
> removing the include fixes the hsdis compilation on Ubuntu.
>
&g
On Wed, 18 Oct 2023 09:54:21 GMT, Andrew Haley wrote:
>> hsdis-binutils.c doesn't use any functions from libiberty.h. This header is
>> absent on Ubuntu (installed separately, and under a different path), so
>> removing the include fixes the hsdis compilation on Ubuntu.
>>
>> Additionally, the
hsdis-binutils.c doesn't use any functions from libiberty.h. This header is
absent on Ubuntu (installed separately, and under a different path), so
removing the include fixes the hsdis compilation on Ubuntu.
Additionally, the static link library for libiberty is not needed on Ubuntu; I
changed
On Fri, 6 Oct 2023 10:17:25 GMT, Andrew Leonard wrote:
> [JDK-8317340](https://bugs.openjdk.org/browse/JDK-8317340) introduced
> -pathmap'ing of VS_INCLUDE paths to enable reproducible Windows builds that
> are not dependent on the Visual Studio tooling install location. This however
> require
On Fri, 29 Sep 2023 10:01:42 GMT, Daniel Jeliński wrote:
> Please review this patch that reenables `delete-null-pointer-checks`
> optimization in GCC and Clang.
>
> It also disables `nonnull-compare` warning that is now triggered in debug
> builds. The problematic code will
On Mon, 2 Oct 2023 14:01:10 GMT, Julian Waters wrote:
>> I reverted the quotes.
>> Didn't get your question; are you suggesting to rename the variable? I'd
>> rather not do that, because 1) it increases the patch size, 2) all variables
>> are global, so renaming might have unintended consequenc
On Mon, 2 Oct 2023 08:38:45 GMT, Julian Waters wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix typo
>
> make/autoconf/flags-cflags.m4 line 928:
>
>> 926:
> Please review this patch that reenables `delete-null-pointer-checks`
> optimization in GCC and Clang.
>
> It also disables `nonnull-compare` warning that is now triggered in debug
> builds. The problematic code will be addressed by #15927.
>
> Mach5 Tier1-5 testing cl
On Mon, 2 Oct 2023 07:24:06 GMT, Daniel Jeliński wrote:
>> make/hotspot/lib/CompileJvm.gmk line 165:
>>
>>> 163: DISABLED_WARNINGS_gcc := $(DISABLED_WARNINGS_gcc), \
>>> 164: DISABLED_WARNINGS_gcc_ad_$(HOTSPOT_TARGET_CPU_ARCH).
On Sun, 1 Oct 2023 05:13:25 GMT, Kim Barrett wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix typo
>
> make/autoconf/flags-cflags.m4 line 923:
>
>> 921: AC_DEFUN([F
> Please review this patch that reenables `delete-null-pointer-checks`
> optimization in GCC and Clang.
>
> It also disables `nonnull-compare` warning that is now triggered in debug
> builds. The problematic code will be addressed by #15927.
>
> Mach5 Tier1-5 testing cl
Please review this patch that reenables `delete-null-pointer-checks`
optimization in GCC and Clang.
It also disables `nonnull-compare` warning that is now triggered in debug
builds. The problematic code will be addressed by #15927.
Mach5 Tier1-5 testing clean.
-
Commit messages:
1 - 100 of 200 matches
Mail list logo
