On Fri, 16 May 2025 09:52:28 GMT, Lutz Schmidt wrote:
> This change enables new gcc optimizations which fully kick in only in the
> release build.
locally both fastdebug + release builds are totally fine, I did build + tier1
test run and didn't see any issue.
> do you see any performance ga
On Mon, 5 May 2025 15:02:49 GMT, Magnus Ihse Bursie wrote:
> GHA is using gcc 10.5.0 and it does not work. Maybe you can try building
> locally with 10.5.0 and see if you can reproduce the problem? Otherwise I
> have no suggestions to offer. But if you want to integrate this change, it
> canno
> updated march level from z10 to z13.
>
> Testing: tier1 (fastdebug-vm)
Amit Kumar 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 two a
On Mon, 28 Apr 2025 19:35:46 GMT, Magnus Ihse Bursie wrote:
> This is a failure when building the gtest framework.
>
> Could this different arch flag be sensitive to different gcc versions? When
> you say you tested locally, what gcc version did you use?
This is the config: gcc version 11.4.0
On Fri, 25 Apr 2025 06:24:31 GMT, Amit Kumar wrote:
> updated march level from z10 to z13.
>
> Testing: tier1 (fastdebug-vm)
That's weird, the build for s390x is failing in cross compile:
=== Output from failing command(s) repeated here ===
* For target h
updated march level from z10 to z13.
Testing: tier1 (fastdebug-vm)
-
Commit messages:
- z10 -> z15
Changes: https://git.openjdk.org/jdk/pull/24869/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24869&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8355570
Stats: 1
On Tue, 5 Nov 2024 16:43:35 GMT, Roman Kennke wrote:
>Hi Amit,
sorry I only now get to reply to this, I have been traveling. What does the
change do? Is it critical? Would it be possible to fix it after I intergrated
the JEP? Because any change that I do now invalidates existing reviews, and
m
On Tue, 22 Oct 2024 16:22:20 GMT, Roman Kennke wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Update copyright
>> - Avoid assert/endless-loop in JFR code
>
> @egahlin / @mgronlun could you please review the JFR
On Tue, 22 Oct 2024 16:22:20 GMT, Roman Kennke wrote:
>> Roman Kennke has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Update copyright
>> - Avoid assert/endless-loop in JFR code
>
> @egahlin / @mgronlun could you please review the JFR
On Thu, 24 Oct 2024 09:22:34 GMT, Thomas Stuefe wrote:
>>> This code causes test errors in
>>> `CompressedClassPointersEncodingScheme.java` on s390 and PPC64. It forces
>>> the shift to `log_cacheline` which is 7 on PPC64 and 9 on s390. The test
>>> passes when we remove "s > log_cacheline &&
On Mon, 14 Oct 2024 21:47:00 GMT, Martin Doerr wrote:
>@offamitkumar: It could still be done after this PR is integrated, but I guess
>you want to provide an s390 implementation.
I haven't looked into it yet. I am looking into other issues for now, but I
will if I can get time to work on this.
On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Wed, 20 Sep 2023 10:21:36 GMT, Deepa Kumari wrote:
>> Previously [JDK-8304364](https://github.com/openjdk/jdk/pull/13066/files) ,
>> the AIX build process raised complaints about the disk location detection,
>> incorrectly determining that the build wasn't on a local disk. However, a
>> par
On Mon, 17 Apr 2023 20:59:06 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, X
On Wed, 19 Apr 2023 13:22:54 GMT, Martin Doerr wrote:
>> Roger Riggs has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 17 commits:
>>
>> - Merge branch 'master' into 8304915-arch-enum
>> - ArchTest on Debian RISC-V 64 confirmed by
On Tue, 11 Apr 2023 18:07:41 GMT, Martin Doerr wrote:
> Another remark: Old JDK on s390 used "os.arch = zArch_64", current one
> "os.arch = s390x". @offamitkumar: You probably want to take a look.
Martin, only concern was that I didn't have a good experience with `s390x`
string in
[past](http
On Wed, 29 Mar 2023 13:04:39 GMT, Amit Kumar wrote:
> As stated in JBS-issue, `dtrace` functionality is not available on s390x. So
> disabling it explicitly in the build.
This pull request has now been integrated.
Changeset: 7fe5bd2b
Author: Amit Kumar
Committer: Matthias Baeske
On Wed, 29 Mar 2023 13:04:39 GMT, Amit Kumar wrote:
> As stated in JBS-issue, `dtrace` functionality is not available on s390x. So
> disabling it explicitly in the build.
Hi all, it appears that checks were already succeeded, but this is not
reflected here. Can we do an
On Wed, 29 Mar 2023 13:04:39 GMT, Amit Kumar wrote:
> As stated in JBS-issue, `dtrace` functionality is not available on s390x. So
> disabling it explicitly in the build.
Changes are trivial, so /integrate (ing). I request **R**eviewer/committer to
sponsor my changes 😊
---
On Wed, 29 Mar 2023 13:04:39 GMT, Amit Kumar wrote:
> As stated in JBS-issue, `dtrace` functionality is not available on s390x. So
> disabling it explicitly in the build.
Still you can see output is different for these strings.
But thanks for pointing out the line number. Mistakenly
On Wed, 29 Mar 2023 13:04:39 GMT, Amit Kumar wrote:
> As stated in JBS-issue, `dtrace` functionality is not available on s390x. So
> disabling it explicitly in the build.
@MBaesken , @erikj79 , @RealLucy Please review. 🙂
Probably I'm missing something, But I'm a bit conf
As stated in JBS-issue, `dtrace` functionality is not available on s390x. So
disabling it explicitly in the build.
-
Commit messages:
- disable dtrace feature
Changes: https://git.openjdk.org/jdk/pull/13228/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13228&range=00
Is
On Fri, 24 Mar 2023 12:19:17 GMT, Matthias Baesken wrote:
>> Currently the support for the JVM feature 'dtrace' is not implemented in the
>> HS codebase on ppc, so we should disable it in the jvm-features make
>> detection as well. Otherwise we could run into building with dtrace feature
>> su
On Thu, 9 Feb 2023 15:21:42 GMT, Amit Kumar wrote:
> We don't need NUM_LCPU, it's just a small code change which removes this
> variable. I've tested it on AIX and cores are detected successfully with
> changes.
> @backwaterred please take look at it.
> Sug
On Mon, 13 Feb 2023 16:17:15 GMT, Magnus Ihse Bursie wrote:
>> Amit Kumar 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 contain
> We don't need NUM_LCPU, it's just a small code change which removes this
> variable. I've tested it on AIX and cores are detected successfully with
> changes.
> @backwaterred please take look at it.
> Suggestions are welcomed :)
Amit Kumar has updated the
We don't need NUM_LCPU, it's just a small code change which removes this
variable. I've tested it on AIX and cores are detected successfully with
changes.
@backwaterred please take look at it.
Suggestions are welcomed :)
-
Commit messages:
- could be removed
Changes: https://gi
On Mon, 30 Jan 2023 08:42:14 GMT, Amit Kumar wrote:
> Beside any specific reason which I'm unaware of, IMO FOUND_CORES variable
> serves no purpose. So probably we could remove it, without any issue.
>
> Any suggestion/thoughts are appreciated :)
This pull request has no
On Mon, 30 Jan 2023 13:52:48 GMT, Erik Joelsson wrote:
>> Beside any specific reason which I'm unaware of, IMO FOUND_CORES variable
>> serves no purpose. So probably we could remove it, without any issue.
>>
>> Any suggestion/thoughts are appreciated :)
>
> There is one subtle change in behavi
Beside any specific reason which I'm unaware of, IMO FOUND_CORES variable
serves no purpose. So probably we could remove it, without any issue.
Any suggestion/thoughts are appreciated :)
-
Commit messages:
- FOUND_CORES variable could be removed
Changes: https://git.openjdk.org/j
On Wed, 14 Dec 2022 04:29:06 GMT, Amit Kumar wrote:
> cpuinfo on s390x architecture contains additional header information on
> Linux/Z which is not seen on GNU Linux:
>
>
> vendor_id : IBM/S390
> # processors: 8
>
> due to this one extra build job is creat
On Wed, 14 Dec 2022 04:29:06 GMT, Amit Kumar wrote:
> cpuinfo on s390x architecture contains additional header information on
> Linux/Z which is not seen on GNU Linux:
>
>
> vendor_id : IBM/S390
> # processors: 8
>
> due to this one extra build job is creat
cpuinfo on s390x architecture contains additional header information on Linux/Z
which is not seen on GNU Linux:
vendor_id : IBM/S390
# processors: 8
due to this one extra build job is created.
Reported Issue can be found here :
[JDK-8298038](https://bugs.openjdk.org/browse/JDK-8298
33 matches
Mail list logo
