On Fri, 10 Mar 2023 21:21:56 GMT, Roger Riggs wrote:
>> Improvements to support OS specific customization for JDK internal use:
>> - To select values and code; allowing elimination of unused code and values
>> - Optionally evaluated by build processes, compilation, or archiving (i.e.
>> CDS)
>
On Wed, 8 Mar 2023 19:15:16 GMT, Roger Riggs wrote:
> Improvements to support OS specific customization for JDK internal use:
> - To select values and code; allowing elimination of unused code and values
> - Optionally evaluated by build processes, compilation, or archiving (i.e.
> CDS)
> - S
On Thu, 9 Mar 2023 16:11:19 GMT, Roger Riggs wrote:
> > Has this totally killed of BSD support on the JDK side? I thought building
> > non-macOS BSD was still viable, but perhaps not - certainly not after this
> > change.
>
> I haven't found any use of BSD and I don't think the build supports
Let's please not kill generic BSD support if at all possible. There is
NetBSD, OpenBSD, FreeBSD, and DragonflyBSD. I know FreeBSD and NetBSD have
OpenJDK 19 and 17 respectively.
On Wed, Mar 8, 2023, 6:54 PM David Holmes wrote:
> On Wed, 8 Mar 2023 19:15:16 GMT, Roger Riggs wrote:
>
> > Improvem
On Wed, 22 Feb 2023 14:02:28 GMT, Justin King wrote:
> Fix trivial memory leak that occurs during tests.
This pull request has now been integrated.
Changeset: 83d77b1c
Author: Justin King
URL:
https://git.openjdk.org/jdk/commit/83d77b1cbb6d0179e9c130d51b7fada2e76e86d3
Stats:
On Wed, 22 Feb 2023 14:02:28 GMT, Justin King wrote:
> Fix trivial memory leak that occurs during tests.
Failing test is unrelated and from an already fix at head issue.
-
PR: https://git.openjdk.org/jdk/pull/12715
Fix trivial memory leak that occurs during tests.
-
Commit messages:
- Memory leak in exeNullCallerTest.cpp
Changes: https://git.openjdk.org/jdk/pull/12715/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12715&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8303072
S
On Sun, 5 Feb 2023 19:04:24 GMT, Alan Bateman wrote:
> Are you planning to include benchmark results to go with this change?
>
> It should be okay to change readFullyAt to use pread, and ReadFile with an OV
> with the position. The latter has a side effect that it changes the file
> pointer bu
Avoid using `lseek` + `read` in favor of `pread`. For Windows, we can do the
same thing by using `OVERLAPPED`, as we are in synchronous mode we can use
`Offset` and `OffsetHigh` to achieve the same thing.
Additionally I updated open to use `O_CLOEXEC` when available, as that really
should be us
On Fri, 9 Dec 2022 06:53:31 GMT, Justin King wrote:
> Allow building OpenJDK with UBSan. Currently the build fails when optimizing
> the image due to lots of undefined behavior (it invokes the built JVM).
> Follow up PRs will either replace the undefined behavior with well defined
&
On Sat, 17 Dec 2022 06:39:48 GMT, Justin King wrote:
>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing
>> the image due to lots of undefined behavior (it invokes the built JVM).
>> Follow up PRs will either replace the undefined behavior
On Sat, 17 Dec 2022 06:39:48 GMT, Justin King wrote:
>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing
>> the image due to lots of undefined behavior (it invokes the built JVM).
>> Follow up PRs will either replace the undefined behavior
On Sat, 17 Dec 2022 06:33:43 GMT, Justin King wrote:
>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing
>> the image due to lots of undefined behavior (it invokes the built JVM).
>> Follow up PRs will either replace the undefined behavior
On Fri, 16 Dec 2022 15:56:44 GMT, Magnus Ihse Bursie wrote:
> However, I do think the included source files should be treated like the
> autoheaders, and reside in data rather than in `src`. The latter is intended
> for buildtools, even though they are a bit scattered at the moment (there is
>
The goal is to make
> OpenJDK more well defined and thus more portable across compilers and
> architectures.
Justin King has updated the pull request incrementally with one additional
commit since the last revision:
Delete unintended addition of files from previous commit
Signed-o
The goal is to make
> OpenJDK more well defined and thus more portable across compilers and
> architectures.
Justin King has updated the pull request incrementally with one additional
commit since the last revision:
Update approach based on feedback from @magicus
Signed-o
On Tue, 13 Dec 2022 16:55:09 GMT, Robbin Ehn wrote:
> > I guess the advantage to putting this in the build machinery (as opposed to
> > using `--with-extra-cflags=-fsanitize=undefined
> > --with-extra-ldflags=-fsanitize=undefined`) is that we can turn some of
> > these onn by default once we'v
On Mon, 12 Dec 2022 10:42:22 GMT, Justin King wrote:
>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing
>> the image due to lots of undefined behavior (it invokes the built JVM).
>> Follow up PRs will either replace the undefined behavior
On Mon, 12 Dec 2022 10:42:22 GMT, Justin King wrote:
>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing
>> the image due to lots of undefined behavior (it invokes the built JVM).
>> Follow up PRs will either replace the undefined behavior
On Mon, 12 Dec 2022 10:42:22 GMT, Justin King wrote:
>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing
>> the image due to lots of undefined behavior (it invokes the built JVM).
>> Follow up PRs will either replace the undefined behavior
On Tue, 13 Dec 2022 00:37:42 GMT, David Holmes wrote:
>> Primarily, but its not a requirement. We should also be able to invoke
>> `java` as is. The environment variables should be used to force specific
>> behavior for a single invocation. Otherwise, if one forgets to pass the
>> environment
On Mon, 12 Dec 2022 09:58:54 GMT, Justin King wrote:
>> src/java.base/share/native/launcher/main.c line 49:
>>
>>> 47: #endif // UNDEFINED_BEHAVIOR_SANITIZER
>>> 48:
>>> 49: /*
>>
>> As I said we have more launcher than 'java', if
The goal is to make
> OpenJDK more well defined and thus more portable across compilers and
> architectures.
Justin King has updated the pull request incrementally with one additional
commit since the last revision:
Simplify logic for including __ubsan_default_options
Signed-o
The goal is to make
> OpenJDK more well defined and thus more portable across compilers and
> architectures.
Justin King has updated the pull request incrementally with one additional
commit since the last revision:
Support both C and C++
Signed-off-by: Justin King
-
On Mon, 12 Dec 2022 09:50:33 GMT, Justin King wrote:
>> Allow building OpenJDK with UBSan. Currently the build fails when optimizing
>> the image due to lots of undefined behavior (it invokes the built JVM).
>> Follow up PRs will either replace the undefined behavior
On Mon, 12 Dec 2022 08:14:51 GMT, Robbin Ehn wrote:
>> Justin King has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add comment explaining __ubsan_default_options and UBSAN_OPTIONS
>>
>> Signed-of
The goal is to make
> OpenJDK more well defined and thus more portable across compilers and
> architectures.
Justin King has updated the pull request incrementally with one additional
commit since the last revision:
Put __ubsan_default_options in C++
Signed-o
The goal is to make
> OpenJDK more well defined and thus more portable across compilers and
> architectures.
Justin King has updated the pull request incrementally with one additional
commit since the last revision:
Use RESULT for UTIL_ARG_ENABLE
Signed-off-by: Justin King
The goal is to make
> OpenJDK more well defined and thus more portable across compilers and
> architectures.
Justin King has updated the pull request incrementally with one additional
commit since the last revision:
Move __ubsan_default_options to be automagically included via
Setu
On Mon, 12 Dec 2022 07:26:21 GMT, David Holmes wrote:
>> Justin King has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add comment explaining __ubsan_default_options and UBSAN_OPTIONS
>>
>>
On Mon, 12 Dec 2022 06:48:25 GMT, David Holmes wrote:
>> Justin King has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove UBSAN_ENABLED From spec.gmk.in
>
> src/java.base/share/native/launcher/main.c lin
On Mon, 12 Dec 2022 06:47:44 GMT, David Holmes wrote:
>> Yeah, it is unfortunate. However there is no other way to actually set the
>> defaults nicely. The other alternative is to use environment variables, but
>> they are easy to forget when invoking the launcher manually.
>
> Does the env-var
The goal is to make
> OpenJDK more well defined and thus more portable across compilers and
> architectures.
Justin King has updated the pull request incrementally with one additional
commit since the last revision:
Add comment explaining __ubsan_default_options and UBSAN_OPTIONS
On Mon, 12 Dec 2022 04:34:07 GMT, David Holmes wrote:
>>> I think it requires much broader discussion as to whether OpenJDK is
>>> actively seen to endorse these tools. Why these tools? What if there are
>>> other tools, should we support them all?
>>>
>>> I'm not saying use of these tools may
On Mon, 12 Dec 2022 01:29:14 GMT, David Holmes wrote:
>> Justin King has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove UBSAN_ENABLED From spec.gmk.in
>
> src/java.base/share/native/launcher/main.c line
On Mon, 12 Dec 2022 05:02:12 GMT, David Holmes wrote:
>> make/autoconf/spec.gmk.in line 459:
>>
>>> 457:
>>> 458: # UndefinedBehaviorSanitizer
>>> 459: UBSAN_ENABLED:=@UBSAN_ENABLED@
>>
>> I don't see anything reading this. ??
>
> To be clear there was a reason that `ASAN_ENABLED` was original
On Mon, 12 Dec 2022 05:48:41 GMT, Justin King wrote:
>>> I think it requires much broader discussion as to whether OpenJDK is
>>> actively seen to endorse these tools. Why these tools? What if there are
>>> other tools, should we support them all?
>>>
>&
On Mon, 12 Dec 2022 03:26:15 GMT, Justin King wrote:
>> I think it requires much broader discussion as to whether OpenJDK is
>> actively seen to endorse these tools. Why these tools? What if there are
>> other tools, should we support them all?
>>
>> I'm no
The goal is to make
> OpenJDK more well defined and thus more portable across compilers and
> architectures.
Justin King has updated the pull request incrementally with one additional
commit since the last revision:
Remove UBSAN_ENABLED From spec.gmk.in
-
Chang
On Mon, 12 Dec 2022 01:31:38 GMT, David Holmes wrote:
> I think it requires much broader discussion as to whether OpenJDK is actively
> seen to endorse these tools. Why these tools? What if there are other tools,
> should we support them all?
>
> I'm not saying use of these tools may not be us
On Fri, 9 Dec 2022 06:53:31 GMT, Justin King wrote:
> Allow building OpenJDK with UBSan. Currently the build fails when optimizing
> the image due to lots of undefined behavior (it invokes the built JVM).
> Follow up PRs will either replace the undefined behavior with well defined
&
Allow building OpenJDK with UBSan. Currently the build fails when optimizing
the image due to lots of undefined behavior (it invokes the built JVM). Follow
up PRs will either replace the undefined behavior with well defined behavior or
suppress errors which are intentional. The goal is to make O
On Mon, 28 Nov 2022 03:23:01 GMT, Justin King wrote:
> Fix memory leaks by making `AddOption` unconditionally duplicate passed in
> strings, taking ownership. Callers using dynamic memory free their storage
> after calling `AddOption`. This ensures no memory is dropped on the floor
on` as it is unused and
> shifts it into the source file.
Justin King has updated the pull request incrementally with one additional
commit since the last revision:
Remove unnecessary NULL assignment in FreeOptions
Signed-off-by: Justin King
-
Changes:
- all: https://
on` as it is unused and
> shifts it into the source file.
Justin King has updated the pull request incrementally with one additional
commit since the last revision:
Maintain separate list of dynamically allocated option strings
Signed-off-by: Justin King
-
Changes:
On Mon, 28 Nov 2022 03:23:01 GMT, Justin King wrote:
> Fix memory leaks by making `AddOption` unconditionally duplicate passed in
> strings, taking ownership. Callers using dynamic memory free their storage
> after calling `AddOption`. This ensures no memory is dropped on the floor
On Mon, 28 Nov 2022 04:02:33 GMT, David Holmes wrote:
> Doesn't this just "leak" the duplicated string now instead of the original?
No, this frees all the strings in `FreeOptions()`.
-
PR: https://git.openjdk.org/jdk/pull/11384
Fix memory leaks by making `AddOption` unconditionally duplicate passed in
strings, taking ownership. Callers using dynamic memory free their storage
after calling `AddOption`. This ensures no memory is dropped on the floor. This
also removes the second argument to `AddOption` as it is unused an
48 matches
Mail list logo
