On Thu, 9 May 2024 17:05:40 GMT, Ioi Lam wrote:
>> On Linux aarch64, a JVM may encounter three different page sizes: 4K, 64K,
>> and (when run on Mac M1 hardware) 16K.
>>
>> Since forgetting to specify `--enable-compatible-cds-alignment` is a common
>> error that is only noticed when running
On Wed, 8 May 2024 15:14:16 GMT, Thomas Stuefe wrote:
> On Linux aarch64, a JVM may encounter three different page sizes: 4K, 64K,
> and (when run on Mac M1 hardware) 16K.
>
> Since forgetting to specify `--enable-compatible-cds-alignment` is a common
> error that is only notic
On Thu, 9 May 2024 05:04:47 GMT, Thomas Stuefe wrote:
>> On Linux aarch64, a JVM may encounter three different page sizes: 4K, 64K,
>> and (when run on Mac M1 hardware) 16K.
>>
>> Since forgetting to specify `--enable-compatible-cds-alignment` is a common
>> e
On Wed, 8 May 2024 15:14:16 GMT, Thomas Stuefe wrote:
> On Linux aarch64, a JVM may encounter three different page sizes: 4K, 64K,
> and (when run on Mac M1 hardware) 16K.
>
> Since forgetting to specify `--enable-compatible-cds-alignment` is a common
> error that is only notic
On Wed, 8 May 2024 17:01:26 GMT, Andrew Haley wrote:
> This is obviously correct. Otherwise, the CDS archive will only work if the
> JDK happens to have been built on a machine with greater or equal page size.
>
> Does the default `compatible-cds-alignment=false` make any sense anywhere on
>
On Linux aarch64, a JVM may encounter three different page sizes: 4K, 64K, and
(when run on Mac M1 hardware) 16K.
Since forgetting to specify `--enable-compatible-cds-alignment` is a common
error that is only noticed when running the produced JVM on hardware with
different page size, we
On Wed, 10 Apr 2024 13:46:11 GMT, Martin Doerr wrote:
>> In my humble opinion the inclusion of alloca.h was slightly cleaner, but I
>> guess it doesn't matter. Out of curiosity, why do you guys prefer not
>> including it?
>
> When only looking at AIX code, I think the inclusion of alloca.h was
On Wed, 10 Apr 2024 12:15:34 GMT, Joachim Kern wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus
On Tue, 2 Apr 2024 09:19:16 GMT, Joachim Kern wrote:
>> Hi Thomas,
>> I would like to get totally rid of this, because as I mentioned IBM already
>> modified the `stdlib.h` header not using `#define malloc vec_malloc` any
>> more (and all the other vec_... defines). We have to ask the adoptium
On Tue, 2 Apr 2024 16:14:12 GMT, Joachim Kern wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus
On Tue, 2 Apr 2024 10:26:42 GMT, Joachim Kern wrote:
>> src/hotspot/os/aix/os_aix.cpp line 314:
>>
>>> 312: ErrnoPreserver ep;
>>> 313: log_trace(os, map)("disclaim failed: " RANGEFMT " errno=(%s)",
>>> 314: RANGEFMTARGS(p, (long)maxDisclaimSize),
>>
>>
On Fri, 29 Mar 2024 07:56:10 GMT, Thomas Stuefe wrote:
>> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 50:
>>
>>> 48: #undef malloc
>>> 49: extern void *malloc(size_t) asm("vec_malloc");
>>> 50: #endif
>>
>> T
On Thu, 28 Mar 2024 16:57:00 GMT, Joachim Kern wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus
On Fri, 29 Mar 2024 07:18:47 GMT, Thomas Stuefe wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the J
On Thu, 28 Mar 2024 16:50:20 GMT, Joachim Kern wrote:
> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
> clang by another name, and it uses the clang toolchain in the JDK build. Thus
> the
On Fri, 8 Mar 2024 10:17:08 GMT, Magnus Ihse Bursie wrote:
> We should match the building of jspawnhelper in
> make/modules/java.base/Launcher.gmk with the usage for all unix platforms in
> src/java.base/unix/classes/java/lang/ProcessImpl.java.
>
> Granted, the list of OSes in the makefile
On Fri, 16 Feb 2024 04:46:24 GMT, Kim Barrett wrote:
> > Unfortunately this will break my workflow on Linux - I use clang to build
> > on Ubuntu 20.04, which is not that old, but it ships with clang 12. This is
> > not a deal breaker, just annoying.
>
> That's unfortunate, but I think the
On Mon, 5 Feb 2024 09:44:02 GMT, Magnus Ihse Bursie wrote:
> > Sure, you can always install a newer GCC than the system one, but it's
> > another thing that makes it harder for people to build OpenJDK. Having said
> > that, C++17 is nice to have.
>
> @theRealAph I am still just hearing
On Thu, 15 Feb 2024 15:54:56 GMT, Magnus Ihse Bursie wrote:
> > I would like it if toolchain version bumps were discussed somewhere else
> > first, not in a PR. (And apologies if it was and I missed that discussion).
>
> Yes, it definitely was. I posted a separate [mail to
>
On Thu, 11 Jan 2024 13:23:45 GMT, Julian Waters wrote:
>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Require clang 13 in toolchain.m4
Just on
On Thu, 15 Feb 2024 05:19:45 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of Clang
> to be used for building OpenJDK from 3.5 to 13.
>
> This permits enabling C++17 (JDK-8314488), though Clang 5 might suffice for
> that. A minimum of Clang 13
On Thu, 25 Jan 2024 12:02:35 GMT, Aleksey Shipilev wrote:
> When looking at [JDK-8324647](https://bugs.openjdk.org/browse/JDK-8324647), I
> was surprised to see that GHA has this output:
>
>
> Running test 'jtreg:test/lib-test:tier1'
> /home/runner/work/jdk/jdk/test/lib-test/TEST.groups:
On Fri, 15 Dec 2023 16:20:02 GMT, Kim Barrett wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains five additional
>>
On Tue, 28 Nov 2023 18:15:56 GMT, Aleksey Shipilev wrote:
> In current GHA, `hotspot_compiler` testing takes a long time, and often takes
> the longest. On MacOS and Windows it routinely takes 60..80 minutes, while
> other test groups run in 30..40 minutes. This often drags the total wall
>
On Fri, 24 Nov 2023 09:51:07 GMT, Daniel Jeliński wrote:
>> test/failure_handler/src/share/conf/windows.properties line 60:
>>
>>> 58:
>>> 59: native.core.app=cdb
>>> 60: native.core.args=-c ".dump /ma core.%p;qd" -p %p
>>
>> Just to double check that this is the right option. `/ma`
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 mode process. *
> *
On Tue, 14 Nov 2023 11:04:43 GMT, Aleksey Shipilev wrote:
>> Looking at why GHA did not catch
>> [JDK-8320050](https://bugs.openjdk.org/browse/JDK-8320050), even though it
>> builds hotspot, I realized we do not configure the build with gtest, which
>> means we skip the build checks for gtest
ause really rare but
> tricky problems when combining static assembly and C++ code (See e.g.
> JDK-8288719).
>
> I propose to always specify `-marm` as default, unless an ABI profile is
> given, to prevent such errors.
>
> Thanks to @marchof for testing this.
Thomas Stuefe has
On Fri, 27 Oct 2023 11:59:59 GMT, Andrew Haley wrote:
>> A bug in GCC causes shared libraries linked with -ffast-math to disable
>> denormal arithmetic. This breaks Java's floating-point semantics.
>>
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>>
>> One solution is to
On Wed, 1 Nov 2023 06:58:23 GMT, David Holmes wrote:
>> I've removed the goto, but would like to wait until Thomas is back
>
> No response from @tstuefe but I think the empty block is pointless and we
> should just check `if (!InterceptOSException) {`.
Sure, remove the empty block.
On Tue, 31 Oct 2023 08:37:44 GMT, Julian Waters wrote:
>> Ick! I hadn't followed https://github.com/openjdk/jdk/pull/15096 closely, so
>> hadn't noticed the discussion there. Not sure why this is using a literal 0
>> rather than `(T) '\n'` as in that PR?
>>
>> So the literal "0" (or
See [JDK-8288719](https://bugs.openjdk.org/browse/JDK-8288719) and subsequent
[discussion](https://mail.openjdk.org/pipermail/build-dev/2022-May/034635.html)
back in 2022.
On Arm, we can generate either arm- or thumb-code (`-marm` or `-mthumb`).
At the moment, if we don't specify an ABI
On Fri, 27 Oct 2023 11:49:16 GMT, Andrew Haley wrote:
> > One more thought, it would be good to add the FTZ_mode_enabled check to
> > `os::run_periodic_checks()`.
> > We already do signal handler checks there, and it is the right place to
> > check for "global things third party native code
On Thu, 26 Oct 2023 14:17:02 GMT, Andrew Haley wrote:
>> A bug in GCC causes shared libraries linked with -ffast-math to disable
>> denormal arithmetic. This breaks Java's floating-point semantics.
>>
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>>
>> One solution is to
On Thu, 26 Oct 2023 14:17:02 GMT, Andrew Haley wrote:
>> A bug in GCC causes shared libraries linked with -ffast-math to disable
>> denormal arithmetic. This breaks Java's floating-point semantics.
>>
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>>
>> One solution is to
On Mon, 9 Oct 2023 10:21:58 GMT, Frederic Thevenet
wrote:
>> When building OpenJDK on Windows using "--with-native-debug-info=external",
>> the resulting debug symbols are saved in files located in the same folder as
>> the corresponding executable or library and named by swapping the
On Wed, 11 Oct 2023 17:20:18 GMT, Andrew Haley wrote:
>> src/hotspot/os/bsd/os_bsd.cpp line 976:
>>
>>> 974: // same architecture as Hotspot is running on
>>> 975:
>>> 976: void *os::Bsd::dlopen_helper(const char *filename, int mode) {
>>
>> I thought BSD is switching to clang.
>
> What
On Wed, 11 Oct 2023 13:36:01 GMT, Andrew Haley wrote:
>> A bug in GCC causes shared libraries linked with -ffast-math to disable
>> denormal arithmetic. This breaks Java's floating-point semantics.
>>
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>>
>> One solution is to
On Wed, 11 Oct 2023 13:38:57 GMT, Andrew Haley wrote:
> > I'm seeing one automated test failure on Linux x86, which I don't
> > understand because I've excluded that test for generic-i586. If anyone
> > understands this, please shout up.
>
> For avoidance of doubt, the test doesn't run
On Wed, 11 Oct 2023 02:18:15 GMT, Julian Waters wrote:
> Once integrated, this is going to spam everyone on GitHub with Windows test
> failures until the issue is fixed separately :/ (Could we perhaps split the
> test out into another change?)
I don't think @fthevenet plans on checking in a
On Mon, 9 Oct 2023 14:02:19 GMT, Frederic Thevenet
wrote:
> OK, so unsurprisingly I was indeed wrong... The test ran as part or tier1 in
> the GHA checks - and failed. I'll let other advise on whether or not running
> this is tier1 is appropriate or not, but in the meantime I'll try to figure
On Mon, 9 Oct 2023 13:35:58 GMT, Frederic Thevenet
wrote:
> Yes, of course. Please note that, like many other tests in the same group, it
> will not be run in non-debug builds; this is because it relies on
> `-XX:ErrorHandlerTest` to cause a controlled crash of the JVM (so that the
> hs_err
On Tue, 22 Aug 2023 02:14:54 GMT, Andrew John Hughes wrote:
> GHA regularly breaks because we specify a very explicit GCC version, even
> down to the release versioning of the Ubuntu package. In just this last
> week, it has caused issues with the testing of PRs on 11u
>
On Thu, 17 Aug 2023 12:37:03 GMT, Coleen Phillimore wrote:
>> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion
>> warnings in runtime code. This is the last one I'm going to do for runtime
>> for a while.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the
On Mon, 24 Jul 2023 01:41:16 GMT, Julian Waters wrote:
> Implementation of [JEP draft: Compile the JDK as
> C++17](https://bugs.openjdk.org/browse/JDK-8310260)
I disagree with this change. This should be discussed more broadly before
trying to get a PR in. The associated JEP has been closed
On Wed, 16 Aug 2023 13:48:35 GMT, Coleen Phillimore wrote:
>> Fix MaxElementPrintSize and casts. Also fixed miscellaneous -Wconversion
>> warnings in runtime code. This is the last one I'm going to do for runtime
>> for a while.
>> Tested with tier1-4.
>
> Coleen Phillimore has updated the
On Fri, 11 Aug 2023 22:24:00 GMT, Mikael Vidstedt wrote:
> As part of the ongoing work to enable -Wconversion with gcc there are a
> number of occurrences of code in the GoogleTest code itself which need
> fixing. These have been addressed in version 1.14.0 of GoogleTest. This
> change is
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
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
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
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
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
On Mon, 31 Jul 2023 18:17:03 GMT, Aleksey Shipilev wrote:
> Some GHA runs are now running into configuration problems after runner
> update. We need to bump the GCC versions to unbreak them.
>
> Additional testing:
> - [x] GHA
Im not a build folk but looks good. Thanks for fixing.
On Wed, 26 Jul 2023 10:29:25 GMT, Andreas Steiner wrote:
>> On AIX the 'nm' needs -X64 option.
>
> Andreas Steiner has updated the pull request incrementally with one
> additional commit since the last revision:
>
> correction of comment
+1
-
Marked as reviewed by stuefe
On Tue, 23 May 2023 08:59:02 GMT, Thomas Stuefe wrote:
> Trivial fix to get Alpine to build again after
> https://bugs.openjdk.org/browse/JDK-8306983
Duplicate. https://github.com/openjdk/jdk/pull/14080
-
PR Comment: https://git.openjdk.org/jdk/pull/14097#issuecomment-1558981267
On Tue, 23 May 2023 08:59:02 GMT, Thomas Stuefe wrote:
> Trivial fix to get Alpine to build again after
> https://bugs.openjdk.org/browse/JDK-8306983
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.org/jdk/pull/14097
On Fri, 21 Jul 2023 11:38:13 GMT, Andreas Steiner wrote:
> When using xlc17 to build on AIX , the mentioned tool is
> /opt/IBM/openxlC/17.1.1/tools/ibm-llvm-cxxfilt instead of c++filt to check
> that global operators new and delete are not present in hotspot objects.
Seems okay.
On Thu, 13 Jul 2023 07:41:00 GMT, David Holmes wrote:
> [JDK-8295974](https://bugs.openjdk.org/browse/JDK-8295974) modified
> print_jni_stack to print the native stack when there are no Java frames. To
> do that it used VMError::print_native_stack, however that function is only
> for
On Fri, 16 Jun 2023 11:08:41 GMT, Jaikiran Pai wrote:
> Can I please get a review of this change which proposes to address the recent
> github actions failures?
>
> As noted in https://bugs.openjdk.org/browse/JDK-8310259 the commit in this PR
> pins the `msys2/setup-msys2` to a previous
On Fri, 16 Jun 2023 06:05:16 GMT, Christian Stein wrote:
> Please review this change to use the boot JDK for building jtreg when running
> on GitHub Actions.
>
> This is a best-effort follow-up change to
> - #14448
> which didn't have the desired results - the `Bad address` error does still
>
On Wed, 14 Jun 2023 10:04:43 GMT, Christian Stein wrote:
> > Will you downport this to JDK 17 too?
>
> No. JDK 17 is archived and it uses JDK 8 to build jtreg within a single-file
> workflow definition:
>
> *
> https://github.com/openjdk/jdk17/blob/master/.github/workflows/submit.yml#L88
On Tue, 13 Jun 2023 13:52:53 GMT, Christian Stein wrote:
>> Please review this change to use the pre-installed JDK 17 for building jtreg
>> when running on GitHub Actions.
>
> Christian Stein has updated the pull request incrementally with one
> additional commit since the last revision:
>
>
On Wed, 7 Jun 2023 14:06:31 GMT, Kelvin Nilsen wrote:
> Hi Thomas,
>
> Thank you for your followup comments. I am in total agreement that it is a
> shame the challenges we have faced and the progress we have made is not
> better documented in the history of JBS tickets. I have been the worst
On Wed, 7 Jun 2023 16:51:38 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>>
On Wed, 7 Jun 2023 00:39:52 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>>
On Sun, 4 Jun 2023 21:39:58 GMT, Kelvin Nilsen wrote:
>> OpenJDK Colleagues:
>>
>> Please review this proposed integration of Generational mode for Shenandoah
>> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>>
>> Generational mode of Shenandoah is enabled by adding
>>
On Fri, 26 May 2023 20:46:29 GMT, Kelvin Nilsen wrote:
> OpenJDK Colleagues:
>
> Please review this proposed integration of Generational mode for Shenandoah
> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>
> Generational mode of Shenandoah is enabled by adding
>
On Fri, 26 May 2023 20:46:29 GMT, Kelvin Nilsen wrote:
> OpenJDK Colleagues:
>
> Please review this proposed integration of Generational mode for Shenandoah
> GC under https://bugs.openjdk.org/browse/JDK-8307314.
>
> Generational mode of Shenandoah is enabled by adding
>
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
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
On Mon, 15 May 2023 13:22:12 GMT, Aleksey Shipilev wrote:
> > Thank you for fixing this
>
> Thanks for looking at it. Trivial, right?
Trivial.
-
PR Comment: https://git.openjdk.org/jdk/pull/13981#issuecomment-1547890912
On Mon, 15 May 2023 10:00:42 GMT, Aleksey Shipilev wrote:
> Currently failing at host configuration step with:
>
>
> The following packages have unmet dependencies:
> libc6:i386 : Depends: libgcc-s1:i386 but it is not going to be installed
> libtiffxx5:i386 : Depends: libstdc++6:i386 (>= 5)
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
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,
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
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
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
>>
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,
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,
On Tue, 28 Mar 2023 15:05:41 GMT, Justin King wrote:
> This change fixes or skips some NMT tests when running under ASan, as well as
> fixing a leak.
>
> - `allocator_may_return_null=1` is added as the default is `0`, meaning ASan
> will never return `nullptr` and will instead crash. NMT
On Thu, 30 Mar 2023 23:38:12 GMT, Julian Waters wrote:
>> A previous argument against link time optimization support that we have for
>> gcc is that it was extremely slow. After some checks it turns out we are
>> passing rather inefficient flags to gcc in optimized builds. Changing these
>>
On Wed, 15 Feb 2023 17:53:49 GMT, Justin King wrote:
> Update build-related infrastructure to support building with ASan under
> Microsoft Visual C++.
LGTM. Build error on Mac x64 seems unrelated.
-
Marked as reviewed by stuefe (Reviewer).
PR:
On Tue, 14 Feb 2023 14:32:10 GMT, Julian Waters wrote:
> Full details in linked entry, man did this give me a scare on my local branch
>
> All C++ compilers for the build operating system are under the name c++ (when
> selected compiler is gcc), but when searching for BUILD_CXX the compiler
>
On Fri, 10 Feb 2023 05:26:38 GMT, Kim Barrett wrote:
> Please review this change to permit the use of noreturn attributes in HotSpot
> code.
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf
> https://en.cppreference.com/w/cpp/language/attributes/noreturn
>
> This will
On Wed, 8 Feb 2023 15:39:17 GMT, Justin King wrote:
> > I read through your explanation, and through the [design
> > docs](https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizerDesignDocument),
> > but my question remains unanswered. See below.
> > > > Metaspace objects hold
On Tue, 7 Feb 2023 15:40:34 GMT, Justin King wrote:
>> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been
>> used to identify multiple leaks so far. It can run most of the test suite
>> except those that also fail with ASan, which is being looked at separately.
>> It is
On Wed, 8 Feb 2023 03:11:32 GMT, Justin King wrote:
> > The bot can only check the required number of Reviewers (strictly 1 per
> > OpenJDK rules but changeable as here via `/reviewers` command) but it
> > doesn't know about the informal rules such as having reviewers from each
> > affected
On Thu, 2 Feb 2023 06:34:56 GMT, Thomas Stuefe wrote:
>> Justin King has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Support CDS
>>
>> Signed-off-by: Justin King
>
> Think
On Wed, 1 Feb 2023 15:26:27 GMT, Justin King wrote:
>> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been
>> used to identify multiple leaks so far. It can run most of the test suite
>> except those that rely on testing compressed oops or compressed class
>> pointers.
On Wed, 1 Feb 2023 15:26:27 GMT, Justin King wrote:
>> Adds initial LSan (LeakSanitizer) support to Hotspot. This setup has been
>> used to identify multiple leaks so far. It can run most of the test suite
>> except those that rely on testing compressed oops or compressed class
>> pointers.
On Tue, 10 Jan 2023 23:17:06 GMT, Justin King wrote:
>> This change instruments Metaspace for ASan. Metaspace allocates memory using
>> `mmap`/`munmap` which ASan is not aware of. Fortunately ASan supports
>> applications [manually poisoning/unpoisoning
>>
On Thu, 12 Jan 2023 05:44:55 GMT, Ioi Lam wrote:
>> Justin King has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update sanitizers/address.h based on review
>>
>> Signed-off-by: Justin King
>
>
On Tue, 10 Jan 2023 06:57:01 GMT, David Holmes wrote:
> > Forcing 2 reviewers to ensure @dholmes-ora can chime in before moving
> > forward.
>
> Well I won't be able to Review as not familiar enough with the code, so
> you'll need a second reviewer anyway. I don't hate this to the point of
>
On Mon, 9 Jan 2023 15:57:53 GMT, Justin King wrote:
>> This change instruments Metaspace for ASan. Metaspace allocates memory using
>> `mmap`/`munmap` which ASan is not aware of. Fortunately ASan supports
>> applications [manually poisoning/unpoisoning
>>
On Thu, 5 Jan 2023 16:29:13 GMT, Justin King wrote:
>> This change instruments Metaspace for ASan. Metaspace allocates memory using
>> `mmap`/`munmap` which ASan is not aware of. Fortunately ASan supports
>> applications [manually poisoning/unpoisoning
>>
On Thu, 5 Jan 2023 02:53:54 GMT, David Holmes wrote:
>> This helps with maintenance. All builds will still compile the `addr` and
>> `size` statements, ensuring they are valid, but will strip them when ASan is
>> not enabled. In the event that refactoring occurs and one of the statements
>>
On Wed, 4 Jan 2023 18:41:05 GMT, Justin King wrote:
> > Does Asan assume 8-byte-alignment? I'm hesitant to set this alignment in
> > stone since Metaspace could be allocated, at least now, with smaller
> > alignments. We don't do this now, but I'd like to keep the option open. But
> > see my
1 - 100 of 130 matches
Mail list logo
