On Fri, 4 Feb 2022 00:25:43 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK ๐
>>
>> ### Implementation notes and alternatives considered
>>
>> After modi
On Fri, 4 Feb 2022 16:05:02 GMT, Tyler Steele wrote:
> I like the idea of adding the IBM copyright line more judiciously, and only
> when the changes I've made are significant. ProblemList.txt, where I've made
> a single line change, stands out in my mind as an example of where this line
> cou
On Fri, 4 Feb 2022 00:25:43 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK ๐
>>
>> ### Implementation notes and alternatives considered
>>
>> After modi
On Wed, 2 Feb 2022 22:42:47 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK ๐
>>
>> ### Implementation notes and alternatives considered
>>
>> After modi
On Wed, 2 Feb 2022 16:30:56 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK ๐
>>
>> ### Implementation notes and alternatives considered
>>
>> After modi
On Tue, 1 Feb 2022 21:36:56 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK ๐
>>
>> ### Implementation notes and alternatives considered
>>
>> After modi
On Fri, 21 Jan 2022 09:28:27 GMT, Martin Doerr wrote:
>> Tyler Steele has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Revert changes to jfrThreadSampler.cpp
>> - Update copyright years. Remove
On Fri, 21 Jan 2022 17:35:14 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK ๐
>>
>> ### Implementation notes and alternatives considered
>>
>> After mod
On Thu, 20 Jan 2022 22:51:28 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK ๐
>>
>> ### Implementation notes and alternatives considered
>>
>> After mod
On Tue, 11 Jan 2022 16:53:05 GMT, Tyler Steele wrote:
>> Just in time for the holidays I have completed an implementation of the JFR
>> functionality for AIX. As a side note, this is my first submission to
>> OpenJDK ๐
>>
>> ### Implementation notes and alternatives considered
>>
>> After mod
On Thu, 18 Nov 2021 17:22:28 GMT, Niklas Radomski wrote:
>> Port the Shenandoah garbage collector
>> (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on
>> ppc64le.
>
> Niklas Radomski has updated the pull request incrementally with one
> additional commit since the las
On Wed, 10 Nov 2021 09:00:04 GMT, Niklas Radomski wrote:
> Port the Shenandoah garbage collector
> (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on
> ppc64le.
src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp line
536:
> 534: if (!preserve_g
On Thu, 11 Nov 2021 11:32:49 GMT, Roman Kennke wrote:
>> Port the Shenandoah garbage collector
>> (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on
>> ppc64le.
>
> src/hotspot/cpu/ppc/gc/shenandoah/c1/shenandoahBarrierSetC1_ppc.cpp line 83:
>
>> 81: LIRGenerator*
On Wed, 10 Nov 2021 09:00:04 GMT, Niklas Radomski wrote:
> Port the Shenandoah garbage collector
> (JDK-8241457)[https://bugs.openjdk.java.net/browse/JDK-8241457] to linux on
> ppc64le.
Nice work! Looks correct.
For others: Note that this change already contains feedback from my offline
revie
On Fri, 8 Oct 2021 15:41:47 GMT, Niklas Radomski wrote:
>> Port the Z garbage collector
>> ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux
>> on ppc64le.
>
> Niklas Radomski has updated the pull request incrementally with three
> additional commits since the last rev
On Thu, 7 Oct 2021 08:27:47 GMT, Niklas Radomski wrote:
>> Port the Z garbage collector
>> ([JDK-8209683](https://bugs.openjdk.java.net/browse/JDK-8209683)) to linux
>> on ppc64le.
>
> Niklas Radomski has updated the pull request incrementally with two
> additional commits since the last revis
On Wed, 28 Apr 2021 17:23:18 GMT, Andrew Leonard wrote:
>> Signed-off-by: Andrew Leonard
>
> Andrew Leonard has refreshed the contents of this pull request, and previous
> commits have been removed. The incremental views will show differences
> compared to the previous content of the PR. The p
On Mon, 25 Jan 2021 14:00:42 GMT, Andrew Leonard wrote:
>> @andrew-m-leonard (Seems I can't get github to tag you???)
>>
>> That sounds good. I think you could move the IncludeCustomExtension to after
>> all *.conf files, to future-proof it and to make it a bit more consistent --
>> "first inc
Hi Christoph,
thanks for reviewing, testing and for the approval. Pushed.
Best regards,
Martin
From: Langer, Christoph
Sent: Samstag, 16. Januar 2021 12:03
To: Doerr, Martin ; jdk-updates-...@openjdk.java.net;
build-dev@openjdk.java.net
Cc: Lindenmaier, Goetz
Subject: RE: [11u] RFR: 8257633
Hi Gรถtz,
thanks for the review.
Best regards,
Martin
From: Lindenmaier, Goetz
Sent: Freitag, 15. Januar 2021 11:29
To: Doerr, Martin ; jdk-updates-...@openjdk.java.net;
build-dev@openjdk.java.net
Cc: Langer, Christoph
Subject: RE: [11u] RFR: 8257633: Missing -mmacosx-version-min=X flag when
jdk/commit/51d325e6
11u backport:
http://cr.openjdk.java.net/~mdoerr/8257633_build_11u/webrev.00/
Please review.
Best regards,
Martin
Hi Roland,
> Sure. Is a comment stating that this was backported what you have in mind?
Preferrably comment + link "backportet by" to your backport issue.
> Would you mind reviewing my RFR given you've already taken a look at
> this area?
I'll take a look.
Best rega
Hi Roland,
thanks for letting me know. My plan was to backport both changes in the
original order, but I'm fine if you do change to the new version at once.
May I ask you to flag both issues as backported once you're done?
Best regards,
Martin
> -Original Message-
&
t/4c86e46d
11u backport:
http://cr.openjdk.java.net/~mdoerr/8256810_build_11u/webrev.00/
Please review.
Best regards,
Martin
On Thu, 7 Jan 2021 09:34:09 GMT, Matthias Baesken wrote:
>> Hello, for a while the AIX build fails with the following error in the
>> harfbuzz build
>> 1500-004: (U) INTERNAL COMPILER ERROR while compiling
>> OT::MarkBasePosFormat1::collect_variation_indices(hb_collect_variation_indices_c
On Thu, 26 Nov 2020 15:18:04 GMT, Aleksey Shipilev wrote:
> Sample build log sizes:
>
> PPC64 fastdebug, 200 kilobytes:
>
> https://builds.shipilev.net/openjdk-jdk/build-logs/build-linux-ppc64le-fastdebug.log
>
> S390X fastdebug, 20 megabytes!
>
> https://builds.shipilev.net/openjdk-jdk
On Wed, 11 Nov 2020 21:02:38 GMT, Magnus Ihse Bursie wrote:
>> Aleksey Shipilev 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 six additional
>
On Tue, 10 Nov 2020 19:05:31 GMT, Aleksey Shipilev wrote:
> It is
> [possible](https://github.com/openjdk/jdk/blob/master/doc/building.md#creating-and-using-sysroots-with-qemu-deboostrap)
> to efficiently cross-compile to foreign architectures on current GH actions
> that are driven by Ubuntu.
On Tue, 3 Nov 2020 20:37:07 GMT, Jorn Vernee wrote:
>> Add 32-bit-safe version of jlong <-> casts to libJNIPoint.c
>>
>> This removes the reported warning.
>>
>> Note that the _LP64 macro was not being propagated to the benchmark native
>> libraries on Windows. The comment says that this is du
On Fri, 18 Sep 2020 13:58:57 GMT, Matthias Baesken wrote:
>> hello, this fixes the build when using VS2017. VS2019 does not have the
>> issue as far as I know.
>> failure was
>>
>>> ./test/hotspot/gtest/utilities/test_align.cpp(96): error C2220: warning
>>> treated as error - no 'object' file
k.
Thanks and best regards,
Martin
> -Original Message-
> From: Yasumasa Suenaga
> Sent: Dienstag, 18. August 2020 05:03
> To: David Holmes ; Baesken, Matthias
> ; hotspot-runtime-...@openjdk.java.net;
> build-dev@openjdk.java.net; Doerr, Martin
> Subject: Re: PING: RF
n_VM" because I usually
think about the Java Thread state "_thread_in_vm".
Nevertheless, I appreciate improvements in virtualization detection. Sometimes,
problems or crashes are related to the virtualization layer, so having precise
information is helpful.
Best regards,
Martin
Hi Matthias,
Looks good. Thanks for fixing it.
Best regards,
Martin
> Am 26.06.2020 um 09:59 schrieb David Holmes :
>
> ๏ปฟHi Matthias,
>
> That all seems fine to me.
>
> David
>
>> On 26/06/2020 5:06 pm, Baesken, Matthias wrote:
>> Hello, please revi
Hi Kim,
builds out of the box on AIX with IBM XL C/C++ for AIX, V16.1.0 (We already use
clang frontend by default.)
Very cool!
Best regards,
Martin
> -Original Message-
> From: build-dev On Behalf Of Kim
> Barrett
> Sent: Freitag, 5. Juni 2020 09:53
> To: buil
Thanks for the reviews! Pushed.
Best regards,
Martin
> -Original Message-
> From: Baesken, Matthias
> Sent: Dienstag, 12. Mai 2020 11:01
> To: build-dev@openjdk.java.net
> Cc: Doerr, Martin
> Subject: RE: RFR(XS): 8244756: Build broken with some awk version af
Hi Magnus,
thank you for proposing a fix which allows building with old awk on AIX. Works
fine.
Here's the webrev:
http://cr.openjdk.java.net/~mdoerr/8244756_AIX_fix_awk_expr/webrev.00/
Would you like to be mentioned as author?
Best regards,
Martin
fyi
Build reproducibility has become more important over the years.
That is especially true at Google, where reproducible builds are
more efficient.
We have modified versions of various archivers that can generate
deterministic metadata in the archive.
And that includes the "jar" command.
The file
Hi Matthias,
thanks for removing no longer existing files from the list.
I guess the list will need further updates to become really useful, but your
change looks good.
Best regards,
Martin
> -Original Message-
> From: hotspot-dev On Behalf Of
> Erik Joelsson
> Sent:
LGTM
On Fri, Jan 17, 2020 at 2:59 AM Severin Gehwolf wrote:
> Hi,
>
> Could I get a second review from an JDK 8u Reviewer, please?
>
> Thanks,
> Severin
>
> On Mon, 2019-09-30 at 11:36 +0200, Magnus Ihse Bursie wrote:
> > On 2019-09-27 17:48, Severin Gehwolf wrote:
> > > Hi,
> > >
> > > Could I
Hi Christoph,
looks good. Thanks for fixing this part in 11u.
Best regards,
Martin
> -Original Message-
> From: build-dev On Behalf Of
> Langer, Christoph
> Sent: Montag, 23. Dezember 2019 15:30
> To: jdk-updates-dev
> Cc: build-dev
> Subject: [11u] RFR: 8236
Hi Christoph,
looks good. Thanks for backporting.
Best regards,
Martin
> -Original Message-
> From: jdk-updates-dev On
> Behalf Of Langer, Christoph
> Sent: Montag, 23. Dezember 2019 15:00
> To: jdk-updates-dev
> Cc: build-dev
> Subject: [11u] RFR: 8232167:
On Sun, Dec 15, 2019 at 1:49 AM John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:
>
> I tried both variants as below, but autoconf is failing me when I try to
> regenerate
> configure.
>
You didn't say how.
>
> Can anyone remind me what the proper way of regenerating the configur
Looks good ... but please add a comment pointing to
https://pandoc.org/MANUAL.html
"""Pandoc uses the UTF-8 character encoding for both input and output."""
On Wed, Dec 4, 2019 at 3:30 PM Dan Smith wrote:
> > On Dec 3, 2019, at 5:24 PM, Jonathan Gibbons <
> jonathan.gibb...@oracle.com> wrote:
>
Hi Claes,
yeah, that makes sense.
> Hopefully we don't have to do one RFE per file.. :-)
๐
I should have written set of files or directories or whatever.
Thanks for your input.
Best regards,
Martin
> -Original Message-
> From: Claes Redestad
> Sent: Mittwoch, 27.
The ubiquitous use of UTF-8 is one of the few clear successes in the
software world.
In 2019, most software projects should declare that all their source files
are encoded in UTF-8, not US-ASCII.
On Wed, Nov 27, 2019 at 9:04 AM Dan Smith wrote:
> Please review this patch to make explicit use of
n makes
sense to me, though.
Best regards,
Martin
> -Original Message-
> From: Claes Redestad
> Sent: Mittwoch, 27. November 2019 18:57
> To: Baesken, Matthias ; Doerr, Martin
> ; Erik Joelsson ; 'build-
> d...@openjdk.java.net' ; 'hotspot-
> d...@openjd
forms would be not so good.
We should only make sure the exported symbols are set up properly to avoid that
this optimization throws out too much.
My 50 Cents.
Best regards,
Martin
> -Original Message-
> From: build-dev On Behalf Of
> Baesken, Matthias
> Sent: Freitag, 22.
Hi Matthias,
thanks for fixing xlc16 support for jdk11u. I appreciate it.
Fix looks good to me.
Best regards,
Martin
From: Baesken, Matthias
Sent: Mittwoch, 30. Oktober 2019 15:38
To: jdk-updates-...@openjdk.java.net; 'build-dev@openjdk.java.net'
Cc: Langer, Christoph ; Doe
Hi Matthias,
> Not sure if there are any plans to support OptimizeFill on ppc64 ?
This question is not related to this issue.
Commenting out parts of it is not a good style.
Thank you for your update. The new webrev looks good to me.
Best regards,
Martin
From: Baesken, Matthias
S
mance critical.
stubGenerator_ppc.cpp:
Code should better be protected by #ifdef COMPILER2 than commenting out.
Otherwise, looks good to me.
Thanks,
Martin
From: Baesken, Matthias
Sent: Dienstag, 29. Oktober 2019 12:42
To: 'hotspot-...@openjdk.java.net'
Cc: 'build-dev@openjdk.java.
I recall years ago running into troubles with regex character ranges, e.g.
https://unix.stackexchange.com/questions/15980/does-should-lc-collate-affect-character-ranges
but my build script wrapper has been setting LC_ALL=C for a long time,
and I set LC_COLLATE=C in my normal use shell environment
(
Looks good, ... although I question whether any Unix program other than the
shell itself should be trying to do tilde-path-expansion.
Consider fixing the code by deleting it.
On Fri, Sep 27, 2019 at 3:42 PM Erik Joelsson
wrote:
> In my recent change JDK-8206125, I introduced a bash conditional t
Hi Matthias,
looks good to me. I think this makes sense for jdk14 where we only support
xlclang++ on AIX.
Best regards,
Martin
> -Original Message-
> From: build-dev On Behalf Of
> Baesken, Matthias
> Sent: Montag, 22. Juli 2019 12:03
> To: Baesken, Matthia
CPPFLAGS) $(LDFLAGS) $(TARGET_MACH)
--
# default
COMPILE.S = $(CC) $(ASFLAGS) $(CPPFLAGS) $(TARGET_MACH) -c
--
# default
COMPILE.s = $(AS) $(ASFLAGS) $(TARGET_MACH)
--
# default
LINK.s = $(CC) $(ASFLAGS) $(LDFLAGS) $(TARGET_MACH)
... which agrees with your patch !
On Mon, Jul 8, 2019 at 11:14 AM Severin Ge
(not really a review ...)
I'm confused because the assembler is invoked when compiling any sort of
source file - C, C++, or .s/.S.
Wouldn't we want assembler flags passed uniformly, no matter when the
assembler is invoked?
It looks like this patch only affects compilation of .s/.S files in hotspot
+1
Thanks,
Martin
> -Original Message-
> From: build-dev On Behalf Of
> Langer, Christoph
> Sent: Montag, 8. Juli 2019 15:26
> To: Baesken, Matthias ; Thomas Stรผfe
>
> Cc: build-dev@openjdk.java.net; ppc-aix-port-...@openjdk.java.net
> Subject: [CAUT
Thanks!
(OPT is harder to parse out than I expected ...)
On Fri, Jun 14, 2019 at 12:57 PM Erik Joelsson
wrote:
> Hello Martin,
>
> It is intentional. The extra number is our internal CI build number. From
> JDK 14 we have decided to stop rebuilding for promotion and instead u
The first jdk14 build reports:
openjdk full version "14-ea+1-1"
while jdk13 has:
openjdk full version "13-ea+25"
The trailing "-1" looks like a bug - is it intentional?
s long as the certs and their aliases are
> unchanged, the output cacerts will always be the same. I can send out a
> code review today.
> >
> > Thanks,
> > Max
> >
> >> On Jun 12, 2019, at 10:59 AM, Weijun Wang
> wrote:
> >>
> >> Good idea
Google culture really likes build output determinism, and we recently built
our own cacerts generator.
To get determinism, we are using cert digest as alias (must have a unique
alias, but value doesn't seem to matter much), and using cert notBefore
instead of current (build) timestamp.
On Mon, Ju
we can put some constraints given reality.
Kind regards,
Martin.-
--
[1] - http://hg.openjdk.java.net/jdk/jdk/rev/0804f29e8be7
known-font only. However, shipping a font is not allowed by
licenses and that's why we changed the test a bit.
We should probably limit the scope somehow.
Despite the test failure, I'm still confident that we did the right
thing in 8218854 [1].
Kind regards,
Martin.-
Hi Matthias,
the change looks good to me.
According to an old redbook [1], this flag makes stacks and r/w sections of the
lib non-executable. This makes sense.
Best regards,
Martin
[1] AIX 5L Differences Guide Version 5.3 Edition
-Original Message-
From: Erik Joelsson
On Thu, Mar 28, 2019 at 4:55 AM Alan Bateman
wrote:
> I'm curious who these "stakeholders" are and what they use these JRE
> bundle for? As you know, moving to a modular platform has blurred the
> historical distinction between what we knew as the JRE and JDK in the
> past. Are they concerned abo
Probably it's because glibc deprecated readdir, and we don't have
--disable-warnings-as-errors by default?
(I think warnings should not be errors except as opt-in by openjdk
developers/maintainers)
On Tue, Mar 19, 2019 at 7:47 AM Andrew Haley wrote:
> On 3/19/19 12:25 PM, Jie Fu wrote:
> > To f
Looks good to me.
On Fri, Mar 15, 2019 at 12:05 PM Andrew John Hughes
wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8193764
> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8193764/webrev.01/
>
> This one applies pretty much as-is, when adjustments are made to use the
> jdk-option
Hi Volker,
the wiki is already up to date, so I like your new version which just refers to
it. Reviewed.
Best regards,
Martin
-Original Message-
From: build-dev On Behalf Of Volker Simonis
Sent: Dienstag, 5. Mรคrz 2019 16:17
To: build-dev
Subject: RFR(XS): 8220164: Fix build
https://openjdk.markmail.org/thread/q3layufiyjivu42c
On Tue, Feb 19, 2019 at 5:03 PM Ioi Lam wrote:
> For the impatient engineers
>
> I did some measurement between the default GNU linker "ld" vs "ld.gold".
> I am trying to get the fastest rebuild time after I modify one cpp file.
> With go
On Tue, Feb 19, 2019 at 10:37 AM Jorn Vernee wrote:
>
> I'm a committer on project Panama, but I'm not sure if I have write
> access to jdk/jdk as well.
You don't
https://openjdk.java.net/census#jvernee
Hi Matthias,
excellent. Looks good to me. This should make AIX ready for JEP 347.
Thanks
Martin
From: Baesken, Matthias
Sent: Montag, 18. Februar 2019 13:53
To: Magnus Ihse Bursie ;
'build-dev@openjdk.java.net'
Cc: Doerr, Martin
Subject: RE: RFR : 8218965: aix: support xlclan
election mechanism is clearified?
Best regards,
Martin
-Original Message-
From: Baesken, Matthias
Sent: Freitag, 15. Februar 2019 14:31
To: Magnus Ihse Bursie ;
'build-dev@openjdk.java.net'
Cc: Doerr, Martin
Subject: RE: RFR : 8218965: aix: support xlclang++ in the compiler de
Looks good to me.
On Mon, Feb 11, 2019 at 3:42 AM Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> From the bug report:
>
> "Suppose PATH points to an out-of date autoconf.
> We can use the AUTOCONF environment variable with configure to override
> finding autoconf on PATH, but that
Hi Matthias,
looks good to me, too.
Best regards,
Martin
-Original Message-
From: hotspot-dev On Behalf Of Baesken,
Matthias
Sent: Donnerstag, 7. Februar 2019 10:13
To: Magnus Ihse Bursie ;
'hotspot-...@openjdk.java.net' ;
'build-dev@openjdk.java.net'
I agree with Andrew Hughes.
On Wed, Jan 30, 2019 at 9:27 AM Andrew Hughes wrote:
>
> I'm aware of the benefits of using gold, and also occasional issues with
> it, but that's not the debate here. It's already perfectly possible to
> build with gold by using --with-ldflags="-fuse-ld=gold", as I'v
Another, more productionized, version of my benchmark:
processors=12
g++ (Debian 7.3.0-5) 7.3.0
--- -fuse-ld=bfd ---
6.559 user 1.180 system 7.740 total
--- -fuse-ld=gold ---
4.575 user 0.600 system 5.176 total
--- -fuse-ld=gold -Wl,-threads ---
9.355 user 5.062 system 4.289 total
--- -fuse-ld=lld
On Fri, Jan 25, 2019 at 10:07 AM Andrew Haley wrote:
>
> On 1/25/19 5:01 PM, Martin Buchholz wrote:
> > I re-ran my linker performance experiment using configure
> > --with-native-debug-symbols="internal"
> > lld is a big winner here:
>
> It looks to me l
In our own wrappers around configure, we've introduced the concept of
a "developer mode". But this thread suggests there are 3 populations
of users invoking configure:
1. release engineers
2. hotspot developers
3. java library developers
Category 1 doesn't care about edit-compile-debug cycle - t
m 326% cpu 1.146 total
On Thu, Jan 24, 2019 at 10:49 AM Martin Buchholz wrote:
>
> Here's an experiment using the 3 competing open source linkers to link
> hotspot. This confirms that lld is faster than gold is faster than
> bfd, but is the one second saving worth the engineeri
On Thu, Jan 24, 2019 at 2:28 PM Erik Joelsson wrote:
> > Do the constituent object files have debugging information? Sub-second
> > processing times for ~350 MiB of output are rather impressive.
>
> Ah! That must be it. I just tried with --with-native-debug-symbols=none
> and then I get comparab
s is in line with what hotspot developers I have talked to also see
> (and they have similar hardware).
>
> My workstation has a few years on it, but surely machines haven't gotten
> 17 times faster? There must be something else at play here.
>
> /Erik
>
> On 2019-01-24
Here's an experiment using the 3 competing open source linkers to link
hotspot. This confirms that lld is faster than gold is faster than
bfd, but is the one second saving worth the engineering effort?
$ (BUILDDIR=$HOME/ws/jdk/build/linux-x86_64-server-release; for
linker in bfd gold lld; do ech
On Thu, Jan 24, 2019 at 7:46 AM Magnus Ihse Bursie
wrote:
> So, we already tacitly assume a specific linker with the gcc toolchain; we
> have just not made that check explicitly.
gcc runs on almost every system, but it's harder to replace the
compiler than the linker, so gcc ends up being used
Getting into the business of choosing the linker is big trouble.
The system default toolchain may have already chosen a linker.
BFD might be configured to have either bfd ld or gold.
# Handle --enable-gold, --enable-ld.
# --disable-gold [--enable-ld]
# Build only ld. Default option.
# --enab
>
> LGTM
On Tue, Nov 27, 2018 at 7:25 PM, Nick Gasson wrote:
> > I missed one thing then looking at this. In TimeZone_md.c it should be
> > #ifdef MACOSX rather than #ifndef. I can sponsor the change for you but
> > I need to change this one line before pushing.
>
> Hi Alan,
>
> Yes feel free to modify it
I vote for disabling precompiled headers by default - they simply make the
build less reliable.
It seemed like precompiled headers did not work when using different
optimization levels for different source files, which in turn was needed
for building with clang, so I've been disabling precompiled
sion from 'jlong' to 'HCRYPTPROV', possible
loss of data
)
But that's unrelated to your fix. It works fine.
Best regards,
Martin
-Original Message-
From: Severin Gehwolf
Sent: Freitag, 12. Oktober 2018 11:20
To: build-dev
Cc: Doerr, Martin ; Baesken, Matthias
+1
Thanks for improving the code.
Best regards,
Martin
-Original Message-
From: Lindenmaier, Goetz
Sent: Montag, 8. Oktober 2018 12:36
To: Volker Simonis ; Doerr, Martin
Cc: build-dev ;
hotspot-runtime-...@openjdk.java.net runtime
Subject: RE: RFR(XS): 8211837: Creation of the
Hi Volker,
looks good. Thanks for fixing.
Of course, it would be great if this could be used to fix minimal/zero build,
too.
Best regards,
Martin
-Original Message-
From: hotspot-runtime-dev On
Behalf Of Volker Simonis
Sent: Montag, 8. Oktober 2018 10:19
To: build-dev ;
hotspot
Thanks for the reviews. Pushed.
Best regards,
Martin
-Original Message-
From: Erik Joelsson
Sent: Mittwoch, 26. September 2018 20:02
To: Doerr, Martin ; 'build-dev@openjdk.java.net'
Subject: Re: RFR(XS): 8211097: aix: fix build after JDK-8210919
Looks good.
/Erik
On
Hi,
we need to fix the build on AIX as suggested by Magnus.
Webrev:
http://cr.openjdk.java.net/~mdoerr/8211097_aix_fix_build_after_8210919/webrev.00/
Please review.
Thanks,
Martin
Unfortunately, my gmail marked Arthur's emails to this thread as spam,
with ensuing confusion.
I retargeted this fix to the new bug
8209817: stack is executable when building with Clang on Linux
http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/
https://bugs.openjdk.java.net/brows
We haven't yet agreed on how to fix
https://bugs.openjdk.java.net/browse/JDK-8186780
You can locally apply any of the fixes from the bug report and you can
give an opinion on which fix you like.
On Mon, Sep 17, 2018 at 6:26 AM, Leslie Zhai wrote:
> https://bugs.openjdk.java.net/browse/JDK-818678
On Thu, Sep 13, 2018 at 12:48 PM, Magnus Ihse Bursie
wrote:
>>
>> http://cr.openjdk.java.net/~martin/webrevs/jdk/noexecstack/noexecstack.patch
>
> I'm not entirely happy, but it'll have to do. The problem here is that the
> underlying structure of the flags han
On Wed, Sep 12, 2018 at 4:01 AM, Magnus Ihse Bursie
wrote:
> On 2018-09-05 20:59, Martin Buchholz wrote:
>
> So ... Magnus, are you happy with the current state of the proposed patch?
>
> I'm sorry Martin, but I can't figure out what the current state is. I tried
> bac
https://openjdk.markmail.org/thread/rwfcd6df6vhzli5m
hat about ASan?
> https://bugs.openjdk.java.net/browse/JDK-8189800
>
>
> ๅจ 2018ๅนด09ๆ06ๆฅ 09:12, Martin Buchholz ๅ้:
>
>> it's difficult to use llvm tools like sanitizers on openjdk sources,
>> because of the "cheating" - relying on undefined behavior, and
The unshuffle infrastructure in
./bin/unshuffle_patch.sh
./bin/unshuffle_list.txt
is highly version specific, and has naturally bitrotted. Maybe it should
simply be removed from openjdk-current.
Maybe a more flexible version of unshuffle could be built that would work
for any source and dest ve
it's difficult to use llvm tools like sanitizers on openjdk sources,
because of the "cheating" - relying on undefined behavior, and the JIT.
On Wed, Sep 5, 2018 at 6:09 PM, Leslie Zhai wrote:
> Hi Martin,
>
> Thanks for your response!
>
> I haven't tested
So ... Magnus, are you happy with the current state of the proposed patch?
On Tue, Sep 4, 2018 at 11:50 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
>
> For the gcc toolchain this can not be the case:
> # Minimum supported linker versions, empty means unspecified
> TOOLCHAIN_MIN
1 - 100 of 378 matches
Mail list logo
