On Mon, 2 Nov 2020 11:26:51 GMT, Maurizio Cimadamore
wrote:
>> I looked through the changes in this update.
>>
>> The shared memory segment support looks sound and the mechanism to close a
>> shared memory segment is clever (albeit a bit surprising at first that it
>> does global handshake
Hi Thomas,
Some initial comments as this is quite big - but thanks for all the
detailed explanations.
On 4/11/2020 1:57 am, Thomas Stuefe wrote:
Hi all,
may I please have opinions and reviews on this cleanup-fix-patch for the
hotspot signal handlers.
Its main intent is to simplify coding
On Wed, 4 Nov 2020 02:15:52 GMT, Serguei Spitsyn wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Code review comments from Kim and Albert.
>
> Hi Coleen,
>
> Wow, there are a lot of simplifications and code
On Wed, 4 Nov 2020 00:08:10 GMT, Coleen Phillimore wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>>
Hi Magnus,
On 4/11/2020 6:50 am, Magnus Ihse Bursie wrote:
The man pages in src/$module/man/*.1 is generated from the (unfortunately
still) closed markdown sources.
These needs to be updated for JDK 16. During this updating, a typo in the GPL
header is also fixed (which caused Oracle's
> This change turns the HashTable that JVMTI uses for object tagging into a
> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
> rehashing. Instead of pointing directly to oops so that GC has to walk the
> table to follow oops and then to rehash the table, this table
On Tue, 3 Nov 2020 21:12:49 GMT, Albert Mingkun Yang wrote:
>> Coleen Phillimore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into jvmti-table
>> - Merge branch 'master' into
On Tue, 3 Nov 2020 21:47:24 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/gc/shared/weakProcessorPhases.hpp line 50:
>>
>>> 48: };
>>> 49:
>>> 50: typedef uint WeakProcessorPhase;
>>
>> This was originally written with the idea that WeakProcessorPhases::Phase
>> (and WeakProcessorPhase)
On Tue, 3 Nov 2020 20:06:35 GMT, Erik Joelsson wrote:
> After building the JDK from clean, the first incremental build of hotspot
> will recompile all of it. This is caused by a difference in the CFLAGS
> generated on the second go. The difference is generated in
> JdkNativeCompilation.gmk,
On Tue, 3 Nov 2020 22:36:34 GMT, John Paul Adrian Glaubitz
wrote:
>> With clang 10.0, the compiler now detects a new class of warnings. The
>> `misleading-indentation` warning has previously been disabled on gcc for
>> hotspot and libfdlibm. Now we need to disable it for clang as well.
>
>
On Tue, 3 Nov 2020 22:25:08 GMT, Magnus Ihse Bursie wrote:
> With clang 10.0, the compiler now detects a new class of warnings. The
> `misleading-indentation` warning has previously been disabled on gcc for
> hotspot and libfdlibm. Now we need to disable it for clang as well.
Why do we
With clang 10.0, the compiler now detects a new class of warnings. The
`misleading-indentation` warning has previously been disabled on gcc for
hotspot and libfdlibm. Now we need to disable it for clang as well.
-
Commit messages:
- 8253892: Disable misleading-indentation on
On Tue, 3 Nov 2020 21:41:55 GMT, Coleen Phillimore wrote:
> > @coleenp - please make sure you hear from someone on the Serviceability team
> > for this PR...
>
> I've asked @sspitsyn to review this.
Yes, I'm reviewing this. Still need another pass.
-
PR:
On Tue, 3 Nov 2020 20:43:01 GMT, Magnus Ihse Bursie wrote:
> The man pages in src/$module/man/*.1 is generated from the (unfortunately
> still) closed markdown sources.
>
> These needs to be updated for JDK 16. During this updating, a typo in the GPL
> header is also fixed (which caused
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
On Tue, 3 Nov 2020 20:43:01 GMT, Magnus Ihse Bursie wrote:
> The man pages in src/$module/man/*.1 is generated from the (unfortunately
> still) closed markdown sources.
>
> These needs to be updated for JDK 16. During this updating, a typo in the GPL
> header is also fixed (which caused
On Tue, 3 Nov 2020 13:45:57 GMT, Kim Barrett wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> More review comments from Stefan and ErikO
>
> src/hotspot/share/gc/shared/weakProcessorPhases.hpp line 50:
>
>>
On Mon, 2 Nov 2020 13:19:08 GMT, Coleen Phillimore wrote:
>> Coleen Phillimore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into jvmti-table
>> - Merge branch 'master' into
On Tue, 3 Nov 2020 13:43:32 GMT, Kim Barrett wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> More review comments from Stefan and ErikO
>
> src/hotspot/share/gc/shared/weakProcessorPhases.hpp line 41:
>
>>
On Tue, 3 Nov 2020 16:17:58 GMT, Kim Barrett wrote:
>> Coleen Phillimore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into jvmti-table
>> - Merge branch 'master' into jvmti-table
On Tue, 3 Nov 2020 16:12:21 GMT, Kim Barrett wrote:
>> Coleen Phillimore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into jvmti-table
>> - Merge branch 'master' into jvmti-table
On Mon, 2 Nov 2020 13:19:08 GMT, Coleen Phillimore wrote:
>> Coleen Phillimore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into jvmti-table
>> - Merge branch 'master' into
On Tue, 3 Nov 2020 14:50:36 GMT, Kim Barrett wrote:
>> Coleen Phillimore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into jvmti-table
>> - Merge branch 'master' into jvmti-table
On 11/2/20 8:22 AM, Coleen Phillimore wrote:
On Mon, 2 Nov 2020 08:34:17 GMT, Stefan Karlsson wrote:
src/hotspot/share/prims/jvmtiTagMap.cpp line 126:
124: // concurrent GCs. So fix it here once we have a lock or are
125: // at a safepoint.
126: // SetTag and GetTag should not post
On Tue, 3 Nov 2020 14:53:12 GMT, Coleen Phillimore wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>>
On Tue, 3 Nov 2020 14:47:35 GMT, Kim Barrett wrote:
>> Coleen Phillimore has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains five commits:
>>
>> - Merge branch 'master' into jvmti-table
>> - Merge branch 'master' into jvmti-table
The man pages in src/$module/man/*.1 is generated from the (unfortunately
still) closed markdown sources.
These needs to be updated for JDK 16. During this updating, a typo in the GPL
header is also fixed (which caused Oracle's internal header verification tool
to complain) -- a double space
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
On Tue, 3 Nov 2020 19:08:05 GMT, Jorn Vernee wrote:
>> I knew this looks familiar. Look at [existing macros in
>> jlong_md.h](https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjava/jlong_md.h#L67-L81)
>> and use/match them? There is a little difference in casting through
> 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 due to pack200, but since
> this has been removed [1], it
On Tue, 3 Nov 2020 20:06:35 GMT, Erik Joelsson wrote:
> After building the JDK from clean, the first incremental build of hotspot
> will recompile all of it. This is caused by a difference in the CFLAGS
> generated on the second go. The difference is generated in
> JdkNativeCompilation.gmk,
On Tue, 3 Nov 2020 19:41:49 GMT, Jorn Vernee wrote:
>> Yes, that sounds good. I did not notice this (still not used to github
>> reviews, which I think has too little context by default).
>
> Ok, will do. (FWIW, you can expand the context of the diff with the arrow
> buttons on the left side
After building the JDK from clean, the first incremental build of hotspot will
recompile all of it. This is caused by a difference in the CFLAGS generated on
the second go. The difference is generated in JdkNativeCompilation.gmk, where
the module specific java header dir is always added to the
On Tue, 3 Nov 2020 19:16:02 GMT, Magnus Ihse Bursie wrote:
>> Thanks for the suggestion.
>>
>> Note the code that adds _LP64 for the JVM (below):
>>
>> if test "x$FLAGS_OS" != xaix; then
>> # xlc on AIX defines _LP64=1 by default and issues a warning if we
>> redefine it.
>>
On Tue, 3 Nov 2020 18:52:52 GMT, Jorn Vernee wrote:
>> make/autoconf/flags-cflags.m4 line 667:
>>
>>> 665:
>>> 666: if test "x$FLAGS_CPU_BITS" = x64; then
>>> 667: if test "x$FLAGS_OS" = xlinux || test "x$FLAGS_OS" = xmacosx ||
>>> test "x$FLAGS_OS" = xwindows; then
>>
>> At this
On Tue, 3 Nov 2020 18:30:46 GMT, Aleksey Shipilev 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
On Thu, 15 Oct 2020 15:00:47 GMT, Bernhard Urban-Forster
wrote:
> Use r18 as allocatable register on Linux only.
>
> A bootstrap works now (it has been crashing before due to r18 being
> allocated):
> $ ./windows-aarch64-server-fastdebug/bin/java.exe
> -XX:+UnlockExperimentalVMOptions
On Tue, 3 Nov 2020 18:46:29 GMT, Magnus Ihse Bursie 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
On Mon, 2 Nov 2020 18:36:32 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 due to
On Mon, 2 Nov 2020 18:36:32 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 due to
On Tue, 3 Nov 2020 14:53:12 GMT, Coleen Phillimore wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>>
On Tue, 3 Nov 2020 12:58:22 GMT, Coleen Phillimore wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>>
On Mon, 2 Nov 2020 18:36:32 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 due to
On Tue, 3 Nov 2020 17:42:08 GMT, Jorn Vernee wrote:
>> test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/libJNIPoint.c
>> line 32:
>>
>>> 30: #define PTR_TO_JLONG(value) ((jlong) (value))
>>> 31: #else
>>> 32: #define JLONG_TO_PTR(value, type) ((type*) (jint) (value))
>>
>>
On Tue, 3 Nov 2020 17:40:32 GMT, Coleen Phillimore 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
On Tue, 3 Nov 2020 17:40:38 GMT, Coleen Phillimore 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
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 due to pack200, but since
this has been removed [1], it seemed safe to
Hi all,
may I please have opinions and reviews on this cleanup-fix-patch for the
hotspot signal handlers.
Its main intent is to simplify coding and to commonize some of it across all
Posix platforms where possible. Also to fix a number of smaller issues.
This will have a number of benefits,
On Tue, 3 Nov 2020 08:21:22 GMT, Magnus Ihse Bursie wrote:
> The variable BUILD_HEADLESS_ONLY is no longer set. And sun/applet does not
> exist anymore.
This pull request has now been integrated.
Changeset: 64a98112
Author:Magnus Ihse Bursie
URL:
On Tue, 3 Nov 2020 13:39:19 GMT, Magnus Ihse Bursie wrote:
> There is a race when compiling build.tools.symbolgenerator.CreateSymbols:
>
> [2020-11-03T07:21:12,118Z] Error: LinkageError occurred while loading main
> class build.tools.symbolgenerator.CreateSymbols
> [2020-11-03T07:21:12,119Z]
> This change turns the HashTable that JVMTI uses for object tagging into a
> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
> rehashing. Instead of pointing directly to oops so that GC has to walk the
> table to follow oops and then to rehash the table, this table
On Tue, 3 Nov 2020 13:39:19 GMT, Magnus Ihse Bursie wrote:
> There is a race when compiling build.tools.symbolgenerator.CreateSymbols:
>
> [2020-11-03T07:21:12,118Z] Error: LinkageError occurred while loading main
> class build.tools.symbolgenerator.CreateSymbols
> [2020-11-03T07:21:12,119Z]
On Tue, 3 Nov 2020 13:21:24 GMT, Michael Keck
wrote:
>> @erikj79
>>
>> Ok, here is a completely rewritten portion, which highlights the differences
>> between Cygwin git and Git for Windows.
>>
>> Suggestion:
>>
>> * You need to install a git client. You have two choices, Cygwin git
There is a race when compiling build.tools.symbolgenerator.CreateSymbols:
[2020-11-03T07:21:12,118Z] Error: LinkageError occurred while loading main
class build.tools.symbolgenerator.CreateSymbols
[2020-11-03T07:21:12,119Z] java.lang.ClassFormatError: Truncated class file
On Tue, 3 Nov 2020 08:21:22 GMT, Magnus Ihse Bursie wrote:
> The variable BUILD_HEADLESS_ONLY is no longer set. And sun/applet does not
> exist anymore.
Marked as reviewed by erikj (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/1031
On Tue, 3 Nov 2020 11:41:20 GMT, Magnus Ihse Bursie wrote:
>> I would recommend putting in a link to the instructions on the Skara wiki
>> page. They actually recommend Git for Windows and I have switched too. The
>> main reason is to be able to use the token manager. To just clone and build,
On Tue, 3 Nov 2020 12:58:22 GMT, Coleen Phillimore wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>>
> This change turns the HashTable that JVMTI uses for object tagging into a
> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
> rehashing. Instead of pointing directly to oops so that GC has to walk the
> table to follow oops and then to rehash the table, this table
On Tue, 3 Nov 2020 10:33:16 GMT, Stefan Karlsson wrote:
>> Since I went back and forth about what this function did (it posted events
>> at one time), I thought the generic _processing name would be better. GC
>> callers shouldn't really have to know what processing we're doing here.
>>
On Tue, 3 Nov 2020 10:36:21 GMT, Stefan Karlsson wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Code review comments from StefanK.
>
> src/hotspot/share/prims/jvmtiTagMapTable.cpp line 185:
>
>> 183: //
On Tue, 3 Nov 2020 10:22:09 GMT, Erik Österlund wrote:
>> Ok, will I run afoul of the ZGC people putting the parameter name after the
>> parameter and the rest of the code, it is before?
>
> ZGC people passionately place the comment after the argument value.
I see that but in the non-zgc code
On Mon, 26 Oct 2020 12:50:59 GMT, Erik Joelsson wrote:
>> @jddarcy Recommended new wording:
>> Suggestion:
>>
>> * Clone the JDK repository using the Cygwin command line `git` client
>> as instructed in this document.
>>
>> Using the Cygwin `git` client is the recommended
On Mon, 2 Nov 2020 15:58:15 GMT, Coleen Phillimore wrote:
>> This change turns the HashTable that JVMTI uses for object tagging into a
>> regular Hotspot hashtable - the one in hashtable.hpp with resizing and
>> rehashing. Instead of pointing directly to oops so that GC has to walk the
>>
On Mon, 2 Nov 2020 12:58:49 GMT, Coleen Phillimore wrote:
> GC callers shouldn't really have to know what processing we're doing here.
I completely disagree with this. It's extremely important that the GC and
Runtime code agrees on what this code does and where the GC *must* call it.
Knowing
On Mon, 2 Nov 2020 16:22:57 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/prims/jvmtiTagMap.cpp line 345:
>>
>>> 343:
>>> 344: // Check if we have to process for concurrent GCs.
>>> 345: check_hashmap(false);
>>
>> Maybe add a comment stating the parameter name, as was done in other
On 02/11/2020 18:37, Bernhard Urban-Forster wrote:
> @theRealAph what gcc version?
>
> I can reproduce with
> $ gcc --version
> gcc (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008
> which ships in Ubuntu 19.10 as default
My mistake: I think it only triggers with a debug build, because assert
is a macro.
On Tue, 3 Nov 2020 08:21:22 GMT, Magnus Ihse Bursie wrote:
> The variable BUILD_HEADLESS_ONLY is no longer set. And sun/applet does not
> exist anymore.
Looks fine and trivial.
-
Marked as reviewed by shade (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/1031
The variable BUILD_HEADLESS_ONLY is no longer set. And sun/applet does not
exist anymore.
-
Commit messages:
- 8255798: Remove dead headless code in CompileJavaModules.gmk
Changes: https://git.openjdk.java.net/jdk/pull/1031/files
Webrev:
68 matches
Mail list logo
