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
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
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
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
ests 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
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
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
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
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
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
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),
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),
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),
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),
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,
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
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
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-development co
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-development co
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
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
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-development co
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
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-development co
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
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
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
gt; 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
The recent cdb versions do not support `.dump /f`:
*
* .dump /f is not supported on a user mode process. *
* *
* .dump /ma
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%) o
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%) o
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 on
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 \
>>>
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.
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
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
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
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,
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
>
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 wi
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
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:
On Mon, 18 Sep 2023 17:30:25 GMT, Daniel Jeliński wrote:
> WinHTTP functions are only used when an application:
> - uses DefaultProxySelector to resolve proxies, and
> - is run with -Djava.net.useSystemProxies=true
>
> In all other cases, loading winhttp.dll is a was
On Tue, 19 Sep 2023 07:02:32 GMT, Daniel Jeliński wrote:
>> WinHTTP functions are only used when an application:
>> - uses DefaultProxySelector to resolve proxies, and
>> - is run with -Djava.net.useSystemProxies=true
>>
>> In all other cases, loading winht
On Mon, 18 Sep 2023 14:44:13 GMT, Daniel Jeliński wrote:
> Please review this patch that makes java.dll load shell32.dll earlier.
> Delay-loading requires some additional code (delayimp.lib), and offers no
> benefits since we always load shell32 during JVM startup.
>
> Othe
On Thu, 21 Sep 2023 06:08:27 GMT, Daniel Jeliński wrote:
>> Please review this patch that makes java.dll load shell32.dll earlier.
>> Delay-loading requires some additional code (delayimp.lib), and offers no
>> benefits since we always load shell32 during JVM startup.
On Wed, 20 Sep 2023 14:42:40 GMT, Jorn Vernee wrote:
>> src/java.base/windows/native/libjava/java_props_md.c line 214:
>>
>>> 212: HRESULT hr;
>>> 213: WCHAR *tmpPath = NULL;
>>> 214: hr = SHGetKnownFolderPath(_Profile,
>>> KF_FLAG_DONT_VERIFY, NULL, );
>>
>> I'd say
ll by 2KB on my
> machine.
> No new tests. Existing tier1-2 tests continue to pass.
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
Inline variable declaration
-
Changes:
- all: https://git.openjdk.org/jdk/pull/
On Wed, 20 Sep 2023 12:44:05 GMT, Erik Joelsson wrote:
>> make/modules/java.base/Lib.gmk line 55:
>>
>>> 53: LDFLAGS := $(LDFLAGS_JDKLIB) \
>>> 54: $(call SET_SHARED_LIBRARY_ORIGIN), \
>>> 55: LDFLAGS_windows := -delayload:secur32.dll -delayload:iphlpapi.dll \
>>
>> Wonder if
On Mon, 18 Sep 2023 18:10:12 GMT, Daniel Jeliński wrote:
>> Please review this patch that makes java.dll load shell32.dll earlier.
>> Delay-loading requires some additional code (delayimp.lib), and offers no
>> benefits since we always load shell32 during JVM startup.
d tier2 tests still pass
> - the same system proxies are returned with and without this patch
> - WinHTTP is not loaded unless DefaultProxySelector is used
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
Revert test changes
-
On Tue, 19 Sep 2023 06:41:11 GMT, Alan Bateman wrote:
>> Daniel Jeliński has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert test changes
>
> test/jdk/java/net/ProxySelector/SystemProxies.java line 26
WinHTTP functions are only used when an application:
- uses DefaultProxySelector to resolve proxies, and
- is run with -Djava.net.useSystemProxies=true
In all other cases, loading winhttp.dll is a waste of resources.
Verified that:
- existing tier1 and tier2 tests still pass
- the same system
ll by 2KB on my
> machine.
> No new tests. Existing tier1-2 tests continue to pass.
Daniel Jeliński has updated the pull request incrementally with one additional
commit since the last revision:
Remove unused define
-
Changes:
- all: https://git.openjdk.org/jdk/pull/15789/files
On Mon, 18 Sep 2023 14:44:13 GMT, Daniel Jeliński wrote:
> Please review this patch that makes java.dll load shell32.dll earlier.
> Delay-loading requires some additional code (delayimp.lib), and offers no
> benefits since we always load shell32 during JVM startup.
>
> Othe
On Mon, 18 Sep 2023 14:44:13 GMT, Daniel Jeliński wrote:
> Please review this patch that makes java.dll load shell32.dll earlier.
> Delay-loading requires some additional code (delayimp.lib), and offers no
> benefits since we always load shell32 during JVM startup.
>
> Othe
Please review this patch that makes java.dll load shell32.dll earlier.
Delay-loading requires some additional code (delayimp.lib), and offers no
benefits since we always load shell32 during JVM startup.
Other than removing the delayload clause, the patch also cleans up the
`getHomeFromShell32`
On Tue, 8 Aug 2023 18:28:36 GMT, Erik Joelsson wrote:
> it's unfortunate that we need to repeat so much.
Right. The default make convention uses `CPPFLAGS` for flags shared between
preprocessor and both C and C++ compilers. We don't have any shared variable as
far as I could tell.
Thanks for
On Mon, 3 Jul 2023 17:15:17 GMT, Daniel Jeliński wrote:
> Please review this patch that configures C++ arguments on build jobs that
> involve compiling CPP files. As a result of this change, CPP files are
> compiled with `-std:c++14` command line argument instead of `-std:c1
On Mon, 3 Jul 2023 17:15:17 GMT, Daniel Jeliński wrote:
> Please review this patch that configures C++ arguments on build jobs that
> involve compiling CPP files. As a result of this change, CPP files are
> compiled with `-std:c++14` command line argument instead of `-std:c1
On Mon, 3 Jul 2023 20:17:23 GMT, Alexey Ivanov wrote:
>> Please review this patch that configures C++ arguments on build jobs that
>> involve compiling CPP files. As a result of this change, CPP files are
>> compiled with `-std:c++14` command line argument instead of `-std:c11`,
>> which is
Please review this patch that configures C++ arguments on build jobs that
involve compiling CPP files. As a result of this change, CPP files are compiled
with `-std:c++14` command line argument instead of `-std:c11`, which is used
when C++ arguments are not configured.
While at it, I simplified
On Tue, 27 Jun 2023 12:22:43 GMT, Daniel Jeliński wrote:
> Please review this attempt to fix ignored-qualifiers warning.
>
> Example warnings:
>
> src/hotspot/share/oops/method.hpp:413:19: warning: 'volatile' type qualifier
> on return type has no effect [-W
On Tue, 27 Jun 2023 12:22:43 GMT, Daniel Jeliński wrote:
> Please review this attempt to fix ignored-qualifiers warning.
>
> Example warnings:
>
> src/hotspot/share/oops/method.hpp:413:19: warning: 'volatile' type qualifier
> on return type has no effect [-W
On Mon, 3 Jul 2023 06:47:04 GMT, Daniel Jeliński wrote:
>> src/hotspot/cpu/aarch64/aarch64.ad line 2288:
>>
>>> 2286:
>>> //=
>>> 2287:
>>> 2288: const bool Matcher
On Mon, 3 Jul 2023 00:19:56 GMT, David Holmes wrote:
>> Please review this attempt to fix ignored-qualifiers warning.
>>
>> Example warnings:
>>
>> src/hotspot/share/oops/method.hpp:413:19: warning: 'volatile' type qualifier
>> on return type has no effect [-Wignored-qualifiers]
>>
1 - 100 of 176 matches
Mail list logo
