On Sun, 22 Nov 2020 14:40:12 GMT, Aleksey Shipilev wrote:
> If you try to build `linux-mipsel-zero-fastdebug`, this happens:
>
>
>
>
>
>
>
> I think it relates to
> [JDK-8253970](https://bugs.openjdk.java.net/browse/JDK-8253970) that
> introduced `atomic_compare_exchange` on those paths,
On Sun, 22 Nov 2020 14:47:07 GMT, John Paul Adrian Glaubitz
wrote:
>> For fun, I tried to build `linux-mips64el-zero-fastdebug`, and it cannot be
>> built, because linker complains:
>>
>>
>> collect2: error: ld returned 1 exit status
>>
>> I believe it is a regression in 16, as GNU hash styl
On Wed, 23 Dec 2020 05:48:10 GMT, Hao Sun
wrote:
> The declaration sites for JVM flags were changed by JDK-8243205 and the
> subsequent JDK-8258074. As a result, undeclared identifier errors
> occurred while building VM without compiler1 or compiler2 feature.
>
> Making the corresponding header
On Wed, 23 Dec 2020 09:28:11 GMT, Hao Sun
wrote:
>> The declaration sites for JVM flags were changed by JDK-8243205 and the
>> subsequent JDK-8258074. As a result, undeclared identifier errors
>> occurred while building VM without compiler1 or compiler2 feature.
>>
>> Making the corresponding h
On Wed, 23 Dec 2020 10:09:08 GMT, Hao Sun
wrote:
>> The declaration sites for JVM flags were changed by JDK-8243205 and the
>> subsequent JDK-8258074. As a result, undeclared identifier errors
>> occurred while building VM without compiler1 or compiler2 feature.
>>
>> Making the corresponding h
On Fri, 25 Dec 2020 10:11:13 GMT, Hao Sun
wrote:
> From the error log we can see the root cause is that, develop_pd flag
> 'pd_CICompileOSR' is undeclared in zero build.
>
> Where this flag is used?
> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77
> of 'compiler_globals.
On Fri, 25 Dec 2020 10:11:13 GMT, Hao Sun
wrote:
> From the error log we can see the root cause is that, develop_pd flag
> 'pd_CICompileOSR' is undeclared in zero build.
>
> Where this flag is used?
> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77
> of 'compiler_globals.
On Sat, 26 Dec 2020 04:42:34 GMT, Hao Sun
wrote:
> Regarding the debug build, I guess it's because that flag 'pd_CICompileOSR'
> is not used for debug build.
> Please refer to
> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/globals_shared.hpp#L84
>
> I suppose macro 'DE
On Mon, 4 Jan 2021 17:19:44 GMT, Ioi Lam wrote:
> `#include "runtime/globals_shared.hpp"` should not be removed.
> compiler_globals.hpp uses the `DECLARE_FLAGS` macro, which is defined by
> globals_shared.hpp.
Since globals_shared.hpp is included in compiler_globals_pd.hpp, I think it's
fine
On Tue, 5 Jan 2021 12:03:39 GMT, Hao Sun
wrote:
>> From the error log we can see the root cause is that, develop_pd flag
>> 'pd_CICompileOSR' is undeclared in zero build.
>>
>> Where this flag is used?
>> Flag 'pd_CICompileOSR' is assigned to flag 'CICompileOSR'. See line 77
>> of 'compiler_glo
Hi all,
The VM fails to get initialized when running with `java -Xshare:on -version` on
x86_32.
The reason is that the default shared archive (classes_nocoops.jsa) doesn't
exist.
So the build system should generate classes_nocoops.jsa instead of classes.jsa
on x86_32.
Thanks.
Best regards,
Jie
On Mon, 22 Mar 2021 02:38:55 GMT, David Holmes wrote:
> Hi Jie,
>
> I don't think this is the right solution here. The logic for when to use a
> NOCOOPS archive seems inconsistent between the generate and use phases. If
> 32-bit is logically always a no-coops archive it should still be called
f
> classes.jsa on x86_32.
>
> Thanks.
> Best regards,
> Jie
Jie Fu has updated the pull request incrementally with one additional commit
since the last revision:
Fix the logic to look for the archive
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/3109/files
- n
On Mon, 22 Mar 2021 04:00:46 GMT, David Holmes wrote:
>> Jie Fu has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Fix the logic to look for the archive
>
> That looks like the right place to fix this - than
On Mon, 22 Mar 2021 01:30:43 GMT, Jie Fu wrote:
> Hi all,
>
> The VM fails to get initialized when running with `java -Xshare:on -version`
> on x86_32.
> The reason is that the default shared archive (classes_nocoops.jsa) doesn't
> exist.
> So the bu
On Mon, 3 May 2021 23:02:01 GMT, Phil Race wrote:
>> I assume the build using bundled lib is fine on all our platforms.
>
>> I assume the build using bundled lib is fine on all our platforms.
>
> Yes.
Hi @prrace ,
Our CI/CD got the following build errors on x86_64 with gcc 8.3.1:
Building tar
Hi all,
vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our
many-core machines due to `-XX:MaxRAMPercentage=0`.
This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1].
It can be reproduced by: `make test
TEST="vmTestbase/vm/mlvm/anonloader/stress/oome/
On Mon, 17 May 2021 17:17:00 GMT, Aleksey Shipilev wrote:
>> Hi all,
>>
>> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our
>> many-core machines due to `-XX:MaxRAMPercentage=0`.
>> This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1].
>>
>> It c
On Mon, 17 May 2021 13:24:16 GMT, Jie Fu wrote:
> Hi all,
>
> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our
> many-core machines due to `-XX:MaxRAMPercentage=0`.
> This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1].
>
&
s,
> Jie
>
>
> [1] https://github.com/openjdk/jdk/blob/master/make/RunTests.gmk#L741
Jie Fu has updated the pull request incrementally with one additional commit
since the last revision:
Use awk to compute MaxRAMPercentage
-
Changes:
- all: https://git.openjdk.java.net/jdk/pu
On Tue, 18 May 2021 07:54:52 GMT, Aleksey Shipilev wrote:
>> Jie Fu has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Use awk to compute MaxRAMPercentage
>
> I ran `tier1` and `tier2` on my
On Tue, 18 May 2021 23:53:51 GMT, Jie Fu wrote:
> I'll push it tomorrow since JDK-8267293 and JDK-8267311 are easier to be
> reproduced with the original code.
We can still easily reproduce JDK-8267311 as before with this patch.
So push it.
-
PR: https://git.openjdk.j
On Mon, 17 May 2021 13:24:16 GMT, Jie Fu wrote:
> Hi all,
>
> vmTestbase/vm/mlvm/anonloader/stress/oome/metaspace/Test.java fails on our
> many-core machines due to `-XX:MaxRAMPercentage=0`.
> This is because `MaxRAMPercentage` will be always 0 if JTREG_JOBS > 25 [1].
>
&
Hi all,
SVML lib shouldn't be generated when C2 is absent.
This is because it is only used by C2.
Thanks.
Best regards,
Jie
-
Commit messages:
- 8268643: SVML lib shouldn't be generated when C2 is absent
Changes: https://git.openjdk.java.net/jdk17/pull/37/files
Webrev: https://we
On Mon, 14 Jun 2021 12:54:33 GMT, Erik Joelsson wrote:
>> Hi all,
>>
>> SVML lib shouldn't be generated when C2 is absent.
>> This is because it is only used by C2.
>>
>> Thanks.
>> Best regards,
>> Jie
>
> make/autoconf/jvm-features.m4 line 571:
>
>> 569: ENABLE_CDS="true"
>> 570: INCLUDE
> Hi all,
>
> SVML lib shouldn't be generated when C2 is absent.
> This is because it is only used by C2.
>
> Thanks.
> Best regards,
> Jie
Jie Fu has updated the pull request incrementally with one additional commit
since the last revision:
Address review co
On Mon, 14 Jun 2021 13:33:26 GMT, erik.joelsson at oracle.com
wrote:
> Yes, there is still support for building multiple variants into the same
> image even though this is not something we currently do for any Oracle
> offering.
Sounds amazing.
Updated.
Thanks.
-
PR: https://git.o
On Sat, 12 Jun 2021 09:03:19 GMT, Jie Fu wrote:
> Hi all,
>
> SVML lib shouldn't be generated when C2 is absent.
> This is because it is only used by C2.
>
> Thanks.
> Best regards,
> Jie
This pull request has now been integrated.
Changeset: 4a6da99f
Author:
Hi all,
May I get reviews for this small change?
The failure is caused by incorrect flag
`-mstack-alignment=16-DMAC_OS_X_VERSION_MIN_REQUIRED=10120`.
The following command works fine with Xcode 12.0 but fails with Xcode 13.0.
clang++ -mstack-alignment=16-DMAC_OS_X_VERSION_MIN_REQUIRED=10120 a.
On Thu, 19 Aug 2021 08:04:39 GMT, David Holmes wrote:
>> Hi all,
>>
>> May I get reviews for this small change?
>>
>> The failure is caused by incorrect flag
>> `-mstack-alignment=16-DMAC_OS_X_VERSION_MIN_REQUIRED=10120`.
>>
>> The following command works fine with Xcode 12.0 but fails with X
On Thu, 19 Aug 2021 07:09:52 GMT, Jie Fu wrote:
> Hi all,
>
> May I get reviews for this small change?
>
> The failure is caused by incorrect flag
> `-mstack-alignment=16-DMAC_OS_X_VERSION_MIN_REQUIRED=10120`.
>
> The following command works fine with Xcode 12.0 b
On Fri, 27 Aug 2021 10:21:26 GMT, Magnus Ihse Bursie wrote:
> JDK-8272700 was created to fix a bug in a variable assignment in configure.
> While it fixed the bug, it kept the problematic syntax that caused the bug in
> the first place.
>
> We do not use the `FOO+="appended"` syntax for appen
On Fri, 27 Aug 2021 13:14:52 GMT, Magnus Ihse Bursie wrote:
>> JDK-8272700 was created to fix a bug in a variable assignment in configure.
>> While it fixed the bug, it kept the problematic syntax that caused the bug
>> in the first place.
>>
>> We do not use the `FOO+="appended"` syntax for
On Fri, 27 Aug 2021 13:53:56 GMT, Magnus Ihse Bursie wrote:
>> JDK-8272700 was created to fix a bug in a variable assignment in configure.
>> While it fixed the bug, it kept the problematic syntax that caused the bug
>> in the first place.
>>
>> We do not use the `FOO+="appended"` syntax for
On Thu, 23 Sep 2021 09:19:42 GMT, Aleksey Shipilev wrote:
>> Now that OpenJDK has more or less complete `tier{1,2,3,4}` definitions,
>> let's mention them in `testing.md`.
>>
>> Current patch is my braindump, I am open for suggestions :)
>
> Aleksey Shipilev has updated the pull request increm
On Thu, 23 Sep 2021 09:19:42 GMT, Aleksey Shipilev wrote:
>> Now that OpenJDK has more or less complete `tier{1,2,3,4}` definitions,
>> let's mention them in `testing.md`.
>>
>> Current patch is my braindump, I am open for suggestions :)
>
> Aleksey Shipilev has updated the pull request increm
On Thu, 23 Sep 2021 09:37:49 GMT, Aleksey Shipilev wrote:
> No, I think "every other X" puts "X" in singular form:
> https://www.merriam-webster.com/dictionary/every%20other.
Okay, I agree.
Thanks.
-
PR: https://git.openjdk.java.net/jdk/pull/5615
On Thu, 23 Sep 2021 12:53:23 GMT, Aleksey Shipilev wrote:
>> Now that OpenJDK has more or less complete `tier{1,2,3,4}` definitions,
>> let's mention them in `testing.md`.
>>
>> Current patch is my braindump, I am open for suggestions :)
>
> Aleksey Shipilev has updated the pull request increm
Hi all,
I'd like to update the testing docs for MacOS with Non-US locale.
Our experiments show that the solution mentioned for Windows with Non-US locale
also works for MacOS.
So it would be helpful to mention MacOS explicitly.
FYI: changes in doc/testing.html was made by `make update-build-doc
in doc/testing.html was made by `make update-build-docs` .
>
> Thanks.
> Best regards,
> Jie
Jie Fu has updated the pull request incrementally with one additional commit
since the last revision:
Update testing.html by hand
-
Changes:
- all: https://git.openjdk
On Fri, 24 Sep 2021 13:06:55 GMT, Erik Joelsson wrote:
> The actual change is ok, but it seems your version of pandoc is creating a
> lot of spurious changes throughout the html version. Since this change is so
> small, maybe you could just manually revert everything but the actual text
> addi
On Fri, 24 Sep 2021 13:36:51 GMT, Jie Fu wrote:
>> Hi all,
>>
>> I'd like to update the testing docs for MacOS with Non-US locale.
>>
>> Our experiments show that the solution mentioned for Windows with Non-US
>> locale also works for MacOS.
&
On Fri, 24 Sep 2021 09:50:19 GMT, Jie Fu wrote:
> Hi all,
>
> I'd like to update the testing docs for MacOS with Non-US locale.
>
> Our experiments show that the solution mentioned for Windows with Non-US
> locale also works for MacOS.
> So it would be helpful t
On Tue, 28 Sep 2021 17:31:24 GMT, Scott Gibbons
wrote:
>> Change the default code entry alignment to 64 bytes from 32 bytes. This
>> allows for maintaining proper 64-byte alignment of data within a code
>> segment, which is required by several AVX-512 instructions.
>>
>> I ran into this whil
On Wed, 29 Sep 2021 19:40:20 GMT, Vladimir Kozlov wrote:
> `RANGEBASE` was added by
> [JDK-6500501](https://bugs.openjdk.java.net/browse/JDK-6500501) and later was
> modified by [JDK-8027829](https://bugs.openjdk.java.net/browse/JDK-8027829)
>
> Note the original comment from 6500501:
>
> ```
On Thu, 30 Sep 2021 10:01:52 GMT, Magnus Ihse Bursie wrote:
> Some misc remarks from a build PoV:
>
> * We count language and region settings as a build environment requirement,
> not a portability issue.
> * It is really a shame that Microsoft is making changes to these so darned
> hard. On a
On Thu, 30 Sep 2021 17:53:39 GMT, Ioi Lam wrote:
> The current limitations of the MethodMather class are:
>
> [1] `parse_method_pattern(char*& line, ...)` requires `line` to be a
> UTF8-encoded byte sequence. Essentially, this means that for
> -XX:CompileCommand to support non-ASCII characters
On Thu, 30 Sep 2021 23:30:29 GMT, Ioi Lam wrote:
> > I will do your experiment next week. This is because it's already our
> > National Day week and I can't find an English Windows machine until next
> > week. I'll let you know the result as soon as possible. Thanks.
>
> No need to hurry :-).
On Thu, 30 Sep 2021 23:41:20 GMT, Jie Fu wrote:
> > I will do your experiment next week. This is because it's already our
> > National Day week and I can't find an English Windows machine until next
> > week. I'll let you know the result as soon as possib
thub.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L319
> [3]
> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-January/032014.html
> [4] https://jeffpar.github.io/kbarchive/kb/047/Q47369/
> [5]
> https://github.com/openjdk/jdk/blob/master/sr
On Tue, 5 Oct 2021 06:38:05 GMT, Ioi Lam wrote:
>> Hi all,
>>
>> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019).
>> However, I failed with C4474 and C4778 warnings as below:
>>
>> Compiling 100 properties into resource bundles for java.desktop
>> Compiling 3038 files for java.base
>
On Wed, 6 Oct 2021 04:30:12 GMT, Ioi Lam wrote:
> It's hard to tell what's the difference between these two RANGEBASE
> definitions. How about doing it like this to make the code more readable?
>
> ```
> #define RANGEBASE_ASCII "."
> #define RANGEBASE_NON_ASCII "."
> #ifdef WINDOWS
> #d
thub.com/openjdk/jdk/blob/master/src/hotspot/share/compiler/methodMatcher.cpp#L319
> [3]
> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-January/032014.html
> [4] https://jeffpar.github.io/kbarchive/kb/047/Q47369/
> [5]
> https://github.com/openjdk/jd
On Tue, 5 Oct 2021 06:38:05 GMT, Ioi Lam wrote:
>> Hi all,
>>
>> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019).
>> However, I failed with C4474 and C4778 warnings as below:
>>
>> Compiling 100 properties into resource bundles for java.desktop
>> Compiling 3038 files for java.base
>
On Sun, 26 Sep 2021 09:55:00 GMT, Jie Fu wrote:
> Hi all,
>
> I tried to build OpenJDK on Cygwin (Windows 2016 + VS2019).
> However, I failed with C4474 and C4778 warnings as below:
>
> Compiling 100 properties into resource bundles for java.desktop
> Compiling 3038 fi
Hi all,
gtest build fails due to stringop-overflow warning with gcc11.
This is because gcc11 seems to be smart enough to detect the following
stringop-overflow at test/hotspot/gtest/memory/test_guardedMemory.cpp:125:11.
* For target hotspot_variant-server_libjvm_gtest_objs_test_guardedMemory.o:
On Mon, 11 Oct 2021 00:47:38 GMT, David Holmes wrote:
> Hi Jie,
>
> Can we not just disable the warning in this specific test?
>
> Thanks, David
Thanks @dholmes-ora for your review.
According to this comment [1], gtest source code warnings are disabled in build
script.
Maybe, it would be bet
On Mon, 11 Oct 2021 02:35:20 GMT, David Holmes wrote:
>> Hi all,
>>
>> gtest build fails due to stringop-overflow warning with gcc11.
>>
>> This is because gcc11 seems to be smart enough to detect the following
>> stringop-overflow at test/hotspot/gtest/memory/test_guardedMemory.cpp:125:11.
>>
On Sun, 10 Oct 2021 13:05:40 GMT, Jie Fu wrote:
> Hi all,
>
> gtest build fails due to stringop-overflow warning with gcc11.
>
> This is because gcc11 seems to be smart enough to detect the following
> stringop-overflow at test/hotspot/gtest/memory/test_guardedMemory.cpp:
On Sat, 12 Mar 2022 03:26:29 GMT, Mikael Vidstedt wrote:
> Background, from JBS:
>
> In file included from
> googletest-release-1.8.1/googletest/src/gtest-all.cc:42:
> googletest-release-1.8.1/googletest/src/gtest-death-test.cc: In function
> 'bool testing::internal::StackGrowsDown()':
> goo
Hi Magnus,
Thanks a lot for your review and helpful comments.
The patch[1] had been tested with Apache NetBeans IDE 9.0 (Build
incubator-netbeans-release-334-on-20180708) on a Linux_64 (amd64) machine.
I've noticed that all files under the specified root will be scanned
automatically when the
Thanks Magnus.
On 2019/1/23 下午8:39, Magnus Ihse Bursie wrote:
On 2019-01-16 06:56, Jie Fu wrote:
Hi Magnus,
Thanks a lot for your review and helpful comments.
The patch[1] had been tested with Apache NetBeans IDE 9.0 (Build
incubator-netbeans-release-334-on-20180708) on a Linux_64 (amd64
That's great!
Thanks Adrian.
On 2019年03月01日 22:29, John Paul Adrian Glaubitz wrote:
Hello!
On 3/1/19 3:25 PM, Magnus Ihse Bursie wrote:
It's a bit difficult for me to test this patch since I don't have a sparc or
arm machine.
Both SPARC and AArch64 machines running Linux can be accessed th
Thanks Magnus and Andrew Dinn for your kind review.
On 2019年03月01日 22:47, Magnus Ihse Bursie wrote:
On 2019-03-01 15:39, Andrew Dinn wrote:
On 01/03/2019 14:25, Magnus Ihse Bursie wrote:
On 2019-02-27 03:25, Jie Fu wrote:
It's a bit difficult for me to test this patch since I don
Hi all,
To fix build failures caused by deprecated-declarations warnings, can we
make this change to jdk8u?
--
diff -r 6e2900603bc6 make/linux/makefiles/gcc.make
--- a/make/linux/makefiles/gcc.make Mon Mar 18 08:33:53 2019 +0100
+++ b/make/linux/makef
deprecated-declarations warnings.
On Tue, Mar 19, 2019 at 7:47 AM Andrew Haley <mailto:a...@redhat.com>> wrote:
On 3/19/19 12:25 PM, Jie Fu wrote:
> To fix build failures caused by deprecated-declarations
warnings, can we
> make this change to jdk8u?
This is very
n Tue, Mar 19, 2019 at 7:47 AM Andrew Haley wrote:
On 3/19/19 12:25 PM, Jie Fu wrote:
To fix build failures caused by deprecated-declarations warnings, can we
make this change to jdk8u?
This is very GCC-version dependent. We really should probe at configure
time for
these options.
--
Andrew
Thanks Andrew.
On 2019/3/20 下午11:53, Andrew John Hughes wrote:
On 19/03/2019 15:09, Martin Buchholz wrote:
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/ma
Hi all,
JBS: https://bugs.openjdk.java.net/browse/JDK-8221894
Webrev: http://cr.openjdk.java.net/~jiefu/8221894/webrev.00/
This is a follow on from 8221342 to add comments for docker tests.
The docker tests with default parameters may fail on the os newer than
oraclelinux 7.6.
For example,
Hi all,
JBS: https://bugs.openjdk.java.net/browse/JDK-8221907
For more info (e.g. the symptom & how to reproduce), please see the JBS.
It can be fixed by
-
diff -r 3326be37cd9a make/autoconf/lib-tests.m4
--- a/make/autoconf/lib-tests.m4 Tue Apr 02
Hi Erik,
Thank you for your review.
Hello Jie,
I think this kind of information would fit better under its own new
heading to make it more explicit. Then we could continue filling in
other similar notes for other tests there. At the bottom, something like:
## Notes for Specific Tests
###
the place(s)
regardless?
Thanks,
David
/Erik
On 2019-04-03 05:28, Jie Fu wrote:
Hi all,
JBS: https://bugs.openjdk.java.net/browse/JDK-8221907
For more info (e.g. the symptom & how to reproduce), please see the
JBS.
It can be fixed by
-
diff -r 3
the same behavior as the original run of
configure (which is the idea of reconfigure).
/Erik
Thanks,
David
/Erik
On 2019-04-03 05:28, Jie Fu wrote:
Hi all,
JBS: https://bugs.openjdk.java.net/browse/JDK-8221907
For more info (e.g. the symptom & how to reproduce), please see the
JBS.
Hi Erik,
Thank you so much for your review and suggestions.
Hello Jie,
Looks good, just some grammatical notes on the first paragraph. Here
is my suggestion:
Docker tests with default parameters may fail on OS versions newer
than oraclelinux 7.6.
For example, they pass on Ubuntu 16.04 but f
first paragraph. Here
is my suggestion:
Docker tests with default parameters may fail on OS versions newer
than oraclelinux 7.6.
For example, they pass on Ubuntu 16.04 but fail on Ubuntu 18.04 if run
like this:
/Erik
On 2019-04-03 20:10, Jie Fu wrote:
Hi Erik,
Thank you for your review
Hi David,
I'm so sorry that I forgot to add you as the reviewer in my previous webrev.
I have updated in http://cr.openjdk.java.net/~jiefu/8221894/webrev.02/.
Thanks a lot.
Best regards,
Jie
On 2019/4/8 上午11:44, Jie Fu wrote:
Hi Erik,
Thank you for your review and very nice sugges
Hi David and Erik,
Thank you for your review and very nice suggestions.
Here is the latest version:
http://cr.openjdk.java.net/~jiefu/8221894/webrev.03/
Please see comments inline and review.
Thanks a lot.
I have two comments on the proposed text:
1. I think "oraclelinux" should be "Oracle L
Hi Erik and David,
Thank you for your review.
Erik, could you please sponsor it?
Thanks a lot.
Best regards,
Jie
On 2019/4/8 下午9:57, Erik Joelsson wrote:
Looks good to me.
/Erik
On 2019-04-08 00:48, Jie Fu wrote:
Hi David and Erik,
Thank you for your review and very nice suggestions
Thank you so much Erik.
On 2019/4/9 下午9:06, Erik Joelsson wrote:
Sure, will do.
/Erik
On 2019-04-08 06:57, Erik Joelsson wrote:
Looks good to me.
/Erik
On 2019-04-08 00:48, Jie Fu wrote:
Hi David and Erik,
Thank you for your review and very nice suggestions.
Here is the latest version
Hi Andrew,
Is it possible that this issue be fixed in 8u222?
Or shall we just update the README to work around it like this:
-
diff -r c52bf8887eb0 README
--- a/README Tue Apr 16 21:59:20 2019 +0100
+++ b/README Thu Apr 25 17:49:36 2019 +0800
@@ -
Hi all,
May I get reviews for this one-line change?
JBS: https://bugs.openjdk.java.net/browse/JDK-8232768
Webrev: http://cr.openjdk.java.net/~jiefu/8232768/webrev.00/
This kind of configuration, with both --disable-cds and
--enable-generate-classlist, will fail.
The failure is caused by -XX
review it and give me some advice.
Thanks a lot.
Best regards,
Jie
On 2019/10/22 下午5:54, Magnus Ihse Bursie wrote:
On 2019-10-22 09:44, Jie Fu wrote:
Hi all,
May I get reviews for this one-line change?
JBS: https://bugs.openjdk.java.net/browse/JDK-8232768
Webrev: http://cr.openjdk.java.net
Hi Magnus,
Thank you very much.
Yes, I need a sponsor.
Thanks a lot.
Best regards,
Jie
On 2019/10/23 上午5:14, Magnus Ihse Bursie wrote:
On 2019-10-22 14:52, Jie Fu wrote:
Hi Magnus,
Thanks for your review and valuable comments.
It is the second case since the VM will report an error for
On Tue, 29 Sep 2020 22:00:04 GMT, Erik Joelsson wrote:
>> This pull request is for integration of the Vector API. It was previously
>> reviewed under conditions when mercurial was
>> used for the source code control system. Review threads can be found here
>> (searching for issue number 8223347
On Wed, 30 Sep 2020 18:19:53 GMT, Paul Sandoz wrote:
>> Hi @PaulSandoz ,
>>
>> This integration seems to miss
>> https://github.com/openjdk/panama-vector/pull/1, which had fixed crashes on
>> AVX512
>> machines.
>> Thanks.
>
> @DamonFool we can follow up later for that fix (and others in
> `v
On Thu, 1 Oct 2020 01:01:23 GMT, Paul Sandoz wrote:
>> Hi @PaulSandoz ,
>>
>> I think it would be better to integrate it [1] in this MR.
>>
>> I have tested this MR on our AVX512 machines and it still crashes.
>> Also, for the sake of maintenance, it seems NOT a good idea to push a
>> problema
Hi all,
The gitignore setting for netbeans project seems to be incomplete.
Only nbproject/private/ [1] is ignored.
But there are also other files under nbproject/, which should be ignored too.
$ tree -L 1 nbproject/
nbproject/
├── configurations.xml
├── private
└── p
1 nbproject/
> nbproject/
> ├── configurations.xml
> ├── private
> └── project.xml
>
>
> It would be better to fix it.
>
> Thanks.
> Best regards,
> Jie
>
>
> [1] https://github.com/openjdk/jdk/blob/master/.gitignore#L5
Jie Fu has updated the pul
On Mon, 9 Nov 2020 13:53:35 GMT, Erik Joelsson wrote:
>> Jie Fu has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Don't remove nbproject/private/
>
> .gitignore line 5:
>
>> 3: /.idea/
>>
1 nbproject/
> nbproject/
> ├── configurations.xml
> ├── private
> └── project.xml
>
>
> It would be better to fix it.
>
> Thanks.
> Best regards,
> Jie
>
>
> [1] https://github.com/openjdk/jdk/blob/master/.gitignore#L5
Jie Fu has updated the pul
On Mon, 9 Nov 2020 18:03:31 GMT, Erik Joelsson wrote:
>> You misunderstand me. Adding the following line is fine and will make git
>> ignore any nbproject dir in the root of the repository, which is what I
>> assume you want:
>>
>>
>> But removing the following existing line is not, as this m
On Mon, 9 Nov 2020 12:07:37 GMT, Jie Fu wrote:
> Hi all,
>
> The gitignore setting for netbeans project seems to be incomplete.
> Only nbproject/private/ [1] is ignored.
>
> But there are also other files under nbproject/, which should be ignored too.
>
92 matches
Mail list logo
