On Fri, 17 Jan 2025 16:27:40 GMT, Gerard Ziemski wrote:
> I'm really not sure what this is actually trying to benchmark - who will be
> collecting this data and analysing it and what will they do with their
> results?
+1. Gerard, could provide a description of what this benchmark does, without
On Wed, 23 Oct 2024 05:08:47 GMT, Julian Waters wrote:
>> After 8339120, gcc began catching many different instances of unused code in
>> the Windows specific codebase. Some of these seem to be bugs. I've taken the
>> effort to mark out all the relevant globals and locals that trigger the
>> u
On Thu, 12 Dec 2024 04:32:14 GMT, SendaoYan wrote:
> Hi all,
> This PR fix file src/java.desktop/unix/native/libawt/awt/awt_LoadLibrary.c
> reported compile warning "ignoring return value of function" by clang17,
> which add check the return value of `realpath` function. Risk is low.
Drive-By
On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev wrote:
>> Magnus Ihse Bursie has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove FIXME
>
> I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A
> future me chasing
On Wed, 6 Nov 2024 09:12:02 GMT, Thomas Stuefe wrote:
> > I think you may be throwing the baby out with the bath water when it comes
> > to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see
> > anything that states `__stdcall` is ONLY for 32-bit!
On Wed, 6 Nov 2024 04:40:24 GMT, Julian Waters wrote:
> I think you may be throwing the baby out with the bath water when it comes to
> `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see
> anything that states `__stdcall` is ONLY for 32-bit!
stdcall and cdecl are 32-bit Wi
On Mon, 4 Nov 2024 09:28:50 GMT, Alan Bateman wrote:
> > Can we get rid of `JNICALL` too, please?
> > Or would that change be too big?
>
> There's >1000 in java.base, lots more elsewhere, so it would be a lot of
> files and would hide the core changes. So maybe for a follow-up PR that does
> t
On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Thu, 11 Jul 2024 08:41:28 GMT, Julian Waters wrote:
>> In [JDK-8302671](https://bugs.openjdk.org/browse/JDK-8302671) I fixed a
>> memmove decay bug by rewriting a sizeof on an array to an explicit size of
>> 256, but this is a bit of a band aid fix. It's come to my attention that in
>> C++,
On Wed, 3 Jul 2024 13:34:38 GMT, Julian Waters wrote:
>> In [JDK-8302671](https://bugs.openjdk.org/browse/JDK-8302671) I fixed a
>> memmove decay bug by rewriting a sizeof on an array to an explicit size of
>> 256, but this is a bit of a band aid fix. It's come to my attention that in
>> C++,
On Wed, 10 Jan 2024 09:18:53 GMT, Matthias Baesken wrote:
> There have been concerns raised about
> [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) , so bring back
> the old behavior.
okay
-
Marked as reviewed by stuefe (Reviewer).
PR Review: https://git.openjdk.org/j
On Tue, 2 Jan 2024 15:03:12 GMT, Matthias Baesken wrote:
> The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced
> with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni , and
> shows on Windows server 2019 the following JNI warning , so the test fails on
>
On Tue, 2 Jan 2024 15:03:12 GMT, Matthias Baesken wrote:
> The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced
> with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni , and
> shows on Windows server 2019 the following JNI warning , so the test fails on
>
On Thu, 2 Nov 2023 11:02:27 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes
>> the Visual C compiler much less accepting
On Wed, 9 Aug 2023 06:53:49 GMT, David Holmes wrote:
>> I wrote this code ages ago. I'm not sure what's weird or suspicious about
>> it, though. The comment at the file's beginning explains this code's
>> motivation.
>>
>> The buffer was never thought to be used for something different than HA
On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done
>> with some effort, given that the signific
On Wed, 9 Aug 2023 04:00:03 GMT, Julian Waters wrote:
>> src/hotspot/os/windows/os_windows.cpp line 2888:
>>
>>> 2886: LONG WINAPI topLevelUnhandledExceptionFilter(struct
>>> _EXCEPTION_POINTERS* exceptionInfo) {
>>> 2887: if (!InterceptOSException) {
>>> 2888: DWORD exception_code =
>>>
On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done
>> with some effort, given that the signific
On Mon, 7 Aug 2023 06:42:41 GMT, Julian Waters wrote:
>> We should set the -permissive- flag for the Microsoft Visual C compiler, as
>> was requested by the now backed out
>> [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). It can be done
>> with some effort, given that the signific
On Mon, 7 Aug 2023 08:14:41 GMT, Julian Waters wrote:
>> There are currently only 2 possible types of HMODULE and char/uint8_t for T
>> at the moment. Weirdly enough only line 126 errors out without the cast
>> while line 114, despite having the same problem, doesn't, but I added the
>> cast t
On Wed, 26 Jul 2023 10:43:20 GMT, Matthias Baesken wrote:
> In src/java.desktop/windows/native/libawt/windows/awt_Robot.cpp GetRGBPixels
> we release some resources at the end of the function by calling
> DeleteObject/DeleteDC. This is recommended by the MS API docs.
> However this should be do
On Mon, 19 Jun 2023 06:55:52 GMT, Axel Boldt-Christmas
wrote:
>> The current implementation for testing generational ZGC with jtreg is
>> implemented with a filter on the mode flag `ZGenerational`. Because of this
>> only environments which set this flag explicitly will run most of the tests.
On Sat, 27 May 2023 11:25:41 GMT, Thomas Stuefe wrote:
>> This one is not just to get rid of a warning. We get real test errors
>> because malloc gets replaced by vec_malloc in log tags.
>
>> This one is not just to get rid of a warning. We get real test errors
>> b
On Fri, 26 May 2023 20:27:12 GMT, Martin Doerr wrote:
> This one is not just to get rid of a warning. We get real test errors because
> malloc gets replaced by vec_malloc in log tags.
That does not invalidate my argument, nor does it answer my question. Those
test errors could be also fixed by
On Thu, 25 May 2023 18:18:43 GMT, Martin Doerr wrote:
>> src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 47:
>>
>>> 45: #undef malloc
>>> 46: extern void *malloc(size_t) asm("vec_malloc");
>>> 47: #endif
>>
>> Wow! And I don't mean that in a good way. I'm not questioning whethe
On Wed, 5 Apr 2023 13:58:48 GMT, Jonathan Dowland wrote:
> This is one proposed solution for https://bugs.openjdk.org/browse/JDK-8304350
>
> `java.awt.Font.getStringBounds(char[],int,int,FontRenderContext)` applies a
> heuristic to determine whether the question it's answering is "simple" or
>
On Wed, 5 Apr 2023 13:58:48 GMT, Jonathan Dowland wrote:
> This is one proposed solution for https://bugs.openjdk.org/browse/JDK-8304350
>
> `java.awt.Font.getStringBounds(char[],int,int,FontRenderContext)` applies a
> heuristic to determine whether the question it's answering is "simple" or
>
On Fri, 7 Apr 2023 21:15:11 GMT, Roger Riggs wrote:
> Refactored the way that build time architecture values are mapped to the
> Architecture enum.
Thank you for this, Roger.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/13357#discussion_r1161075537
On Fri, 7 Apr 2023 10:52:47 GMT, Jaikiran Pai wrote:
>> src/java.base/share/classes/jdk/internal/util/Architecture.java line 41:
>>
>>> 39: AARCH64(),
>>> 40: RISCV64(),
>>> 41: S390(),
>>
>> Why getting rid of the X in s390x? There has not been an s390 linux kernel
>> in almost te
On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X8
On Fri, 7 Apr 2023 07:42:51 GMT, Alan Bateman wrote:
> > What I meant was: You define PPCLE. PPCLE specifies ppc, little endian. We
> > also have PPC big-endian, it is used by AIX (and you can also run Linux
> > with PPC big-endian). Why omit that?
> > os.arch for AIX is "ppc64".
>
> So I thin
On Thu, 6 Apr 2023 20:39:41 GMT, Roger Riggs wrote:
> > What about PPC (big endian)? Used on AIX?
>
> I'm not aware of any code (in OpenJDK) related to big/little endian that is
> derived from `os.arch`.
>
> > On Arm, it may be useful to know whether we built for thumb mode (We
> > recently h
On Thu, 6 Apr 2023 21:17:25 GMT, Glavo wrote:
>> The point of Architecture is reflect the architecture as supported by the
>> build and the runtime mutually and to reflect dependencies on the target
>> hardware.
>>
>> What did you use as the example that would not compile on the other
>> arc
On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X8
On Thu, 6 Apr 2023 19:25:19 GMT, Roger Riggs wrote:
>> Define an internal jdk.internal.util.Architecture enumeration and static
>> methods to replace uses of the system property `os.arch`.
>> The enumeration values are defined to match those used in the build.
>> The initial values are: `X64, X8
On Sat, 11 Mar 2023 17:16:46 GMT, Daniel D. Daugherty
wrote:
> Trivial fixes to ProblemList 3 different tests:
> [JDK-8304017](https://bugs.openjdk.org/browse/JDK-8304017) ProblemList
> com/sun/jdi/InvokeHangTest.java on windows-x64 in vthread mode
> [JDK-8304018](https://bugs.openjdk.org/brows
On Wed, 7 Dec 2022 21:25:11 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have this update reviewed?
>>
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the
>> use of it causing building failure. The build could pass if warnings are
>> disabled for codes that us
On Wed, 7 Dec 2022 16:27:43 GMT, Roger Riggs wrote:
>
> Good idea, though perhaps the return (and value if any) could be explicit in
> the macro invocation, instead of implicit (plus arg). A single macro would
> suffice, instead of multiples.
>
> Usage Example:
>
> ```
> JNU_CHECK_EXCEPT
On Tue, 29 Nov 2022 07:57:36 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have this update reviewed?
>>
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the
>> use of it causing building failure. The build could pass if warnings are
>> disabled for codes that u
On Tue, 22 Nov 2022 08:02:51 GMT, Kim Barrett wrote:
> Given all the near-duplicated checking of os::snprintf results, I think there
> is a place for a helper function to package this up. Maybe something like
>
> ```
> // in class os
> // Performs snprintf and asserts the result is non-negative
On Fri, 25 Nov 2022 09:15:08 GMT, Matthias Baesken wrote:
> There are still a few places where GetPrimitiveArrayCritical calls miss the
> result check. This should be adjusted.
> A similar case was recently adjusted here :
> https://bugs.openjdk.org/browse/JDK-8297480
Hi Matthias,
But all thi
On Fri, 18 Nov 2022 13:38:47 GMT, Matthias Baesken wrote:
> The image related test UnexpectedSourceImageSize test introduced with
> https://bugs.openjdk.org/browse/JDK-8264666
> sometimes times out on slow machines when fastdebug is used. This happens
> especially in 11 and 17; in 20 it seems t
On Fri, 18 Nov 2022 06:42:24 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have this update reviewed?
>>
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the
>> use of it causing building failure. The build could pass if warnings are
>> disabled for codes that u
On Sun, 13 Nov 2022 22:55:52 GMT, Xue-Lei Andrew Fan wrote:
>> Please don't add uses of `jio_snprintf` or `::snprintf` to hotspot. Use
>> `os::snprintf`.
>>
>> Regarding `jio_snprintf`, see https://bugs.openjdk.org/browse/JDK-8198918.
>> Regarding `os::snprintf` and `os::vsnprintf`, see
>> htt
On Wed, 16 Nov 2022 07:03:12 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have this update reviewed?
>>
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the
>> use of it causing building failure. The build could pass if warnings are
>> disabled for codes that u
On Wed, 16 Nov 2022 07:03:12 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have this update reviewed?
>>
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the
>> use of it causing building failure. The build could pass if warnings are
>> disabled for codes that u
On Wed, 16 Nov 2022 05:45:34 GMT, Xue-Lei Andrew Fan wrote:
>> A result of -1 only occurs for an encoding error. An encoding error is only
>> possible with multi-byte / wide characters. (See the definition of "encoding
>> error" in C99 7.19.3/14.) We don't use those, so there won't be any encod
On Tue, 15 Nov 2022 07:13:49 GMT, Kim Barrett wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> delete swp file
>
> src/hotspot/os/bsd/attachListener_bsd.cpp line 294:
>
>> 292: (atoi(buf) != ATT
On Mon, 14 Nov 2022 19:44:17 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have this update reviewed?
>>
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the
>> use of it causing building failure. The build could pass if warnings are
>> disabled for codes that u
On Mon, 14 Nov 2022 05:32:20 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have this update reviewed?
>>
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the
>> use of it causing building failure. The build could pass if warnings are
>> disabled for codes that u
On Sun, 13 Nov 2022 22:55:52 GMT, Xue-Lei Andrew Fan wrote:
> Please don't add uses of `jio_snprintf` or `::snprintf` to hotspot. Use
> `os::snprintf`.
I did not know this was our policy now. Sorry for giving the wrong advice.
Maybe we should add this to the hotspot style guide since I'm proba
On Sun, 13 Nov 2022 08:25:57 GMT, Xue-Lei Andrew Fan wrote:
> > could you use `jio_snprintf` instead (see include/jvm_io.h)? That is what
> > we usually do for snprintf. jio_snprintf hides platform particularities wrt
> > snprintf.
>
> Good to know that. Thank you!
>
> While I was doing the r
On Fri, 11 Nov 2022 22:41:19 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have this update reviewed?
>
> The sprintf is deprecated in Xcode 14 because of security concerns, and the
> use of it causing building failure. The build could pass if warnings are
> disabled for codes that use spri
On Fri, 26 Aug 2022 07:54:24 GMT, Matthias Baesken wrote:
>> https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
>> states about MultiByteToWideChar : "The function returns 0 if it does not
>> succeed" and lists a few failure cases.
>> However we m
56 matches
Mail list logo
