On Wed, 16 Nov 2022 05:45:34 GMT, Xue-Lei Andrew Fan wrote:
>> A result of -1 only occurs for an encoding error. An encoding error is only
>> possible with multi-byte / wide characters. (See the definition of "encoding
>> error" in C99 7.19.3/14.) We don't use those, so there won't be any encod
On Wed, 16 Nov 2022 08:46:15 GMT, Christian Hagedorn
wrote:
> Yes, I think it would be good to get a second review of the DWARF parser
> changes. Maybe @tstuefe?
I'm a bit swamped, but try to take a look later today.
-
PR: https://git.openjdk.org/jdk/pull/10287
On Tue, 15 Nov 2022 07:13:49 GMT, Kim Barrett wrote:
>> Xue-Lei Andrew Fan has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> delete swp file
>
> src/hotspot/os/bsd/attachListener_bsd.cpp line 294:
>
>> 292: (atoi(buf) != ATT
On Mon, 14 Nov 2022 19:44:17 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have this update reviewed?
>>
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the
>> use of it causing building failure. The build could pass if warnings are
>> disabled for codes that u
On Mon, 14 Nov 2022 05:32:20 GMT, Xue-Lei Andrew Fan wrote:
>> Hi,
>>
>> May I have this update reviewed?
>>
>> The sprintf is deprecated in Xcode 14 because of security concerns, and the
>> use of it causing building failure. The build could pass if warnings are
>> disabled for codes that u
On Mon, 14 Nov 2022 04:14:24 GMT, Julian Waters wrote:
>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and
>> [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++
>> code across the JDK can be replaced and simplified with cleaner language
>> features t
On Mon, 14 Nov 2022 04:14:24 GMT, Julian Waters wrote:
>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and
>> [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++
>> code across the JDK can be replaced and simplified with cleaner language
>> features t
On Mon, 14 Nov 2022 04:14:24 GMT, Julian Waters wrote:
>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and
>> [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++
>> code across the JDK can be replaced and simplified with cleaner language
>> features t
On Mon, 14 Nov 2022 04:14:24 GMT, Julian Waters wrote:
>> After [JDK-8292008](https://bugs.openjdk.org/browse/JDK-8292008) and
>> [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283), some C and C++
>> code across the JDK can be replaced and simplified with cleaner language
>> features t
On Sun, 13 Nov 2022 22:55:52 GMT, Xue-Lei Andrew Fan wrote:
> Please don't add uses of `jio_snprintf` or `::snprintf` to hotspot. Use
> `os::snprintf`.
I did not know this was our policy now. Sorry for giving the wrong advice.
Maybe we should add this to the hotspot style guide since I'm proba
ce
> [JDK-8268893](https://bugs.openjdk.org/browse/JDK-8268893). This patch
> reshapes this code, cleaning it up in an OS-agnostic way. That will allow us
> to add implementions for other platforms (I have this on my list for AIX at
> least) and make review of 8293114 easier.
Thom
On Mon, 14 Nov 2022 01:35:35 GMT, David Holmes wrote:
> This looks good for doing what it says, but I have to wonder whether it is
> actually worthwhile doing this unless most OS/lib will support it? What will
> the implementation be in AIX?
I think C-Heap trimming is useful even if only Linux
On Thu, 10 Nov 2022 13:23:34 GMT, Thomas Stuefe wrote:
> This is a breakout from
> [JDK-8293114](https://bugs.openjdk.org/browse/JDK-8293114), which is starved
> for reviews. So I attempt to break up that fix into smaller units which are
> hopefully easier to review separately.
On Sun, 13 Nov 2022 08:25:57 GMT, Xue-Lei Andrew Fan wrote:
> > could you use `jio_snprintf` instead (see include/jvm_io.h)? That is what
> > we usually do for snprintf. jio_snprintf hides platform particularities wrt
> > snprintf.
>
> Good to know that. Thank you!
>
> While I was doing the r
On Fri, 11 Nov 2022 22:41:19 GMT, Xue-Lei Andrew Fan wrote:
> Hi,
>
> May I have this update reviewed?
>
> The sprintf is deprecated in Xcode 14 because of security concerns, and the
> use of it causing building failure. The build could pass if warnings are
> disabled for codes that use spri
On Thu, 10 Nov 2022 13:23:34 GMT, Thomas Stuefe wrote:
> This is a breakout from
> [JDK-8293114](https://bugs.openjdk.org/browse/JDK-8293114), which is starved
> for reviews. So I attempt to break up that fix into smaller units which are
> hopefully easier to review separately.
This is a breakout from
[JDK-8293114](https://bugs.openjdk.org/browse/JDK-8293114), which is starved
for reviews. So I attempt to break up that fix into smaller units which are
hopefully easier to review separately.
We can trim the C-heap manually using jcmd since
[JDK-8268893](https://bugs.op
On Wed, 26 Oct 2022 10:07:12 GMT, Julian Waters wrote:
>> Eclipse is a popular and very well-known IDE in the world of Java
>> development, utilized widely in many contexts, by beginners and experienced
>> teams alike. Although a relatively lightweight IDE, it features surprisingly
>> powerful
On Wed, 19 Oct 2022 12:04:49 GMT, Aleksey Shipilev wrote:
> Found this when working on JOL support
> ([CODETOOLS-7903364](https://bugs.openjdk.org/browse/CODETOOLS-7903364)). If
> you try to attach to VM running with -XX:ObjectAlignmentInBytes=32, then SA
> would fail with:
>
>
> Caused by:
On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters wrote:
> Some external libraries required by native code are linked via linker
> comments embedded in pragmas. Searching for which libraries are linked can
> then become frustrating and confusing since they may be included in an
> obscure place,
On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters wrote:
> Some external libraries required by native code are linked via linker
> comments embedded in pragmas. Searching for which libraries are linked can
> then become frustrating and confusing since they may be included in an
> obscure place,
On Mon, 10 Oct 2022 14:15:37 GMT, Julian Waters wrote:
> Some external libraries required by native code are linked via linker
> comments embedded in pragmas. Searching for which libraries are linked can
> then become frustrating and confusing since they may be included in an
> obscure place,
On Mon, 8 Aug 2022 13:45:06 GMT, Roman Kennke wrote:
> The bar for acceptance for a brand new locking scheme with no fallback is
> extremely high and needs a lot of bake time and broad performance
> measurements, to watch for pathologies. That bar is lower if the scheme can
> be reverted to th
On Sun, 7 Aug 2022 12:50:01 GMT, Roman Kennke wrote:
> > Happens when the main thread detaches itself upon VM exit. VM attempts to
> > release OMs that are owned by the finished main thread (side note: if that
> > is the sole surviving thread, maybe that step could be skipped?). That
> > happe
On Thu, 28 Jul 2022 19:58:34 GMT, Roman Kennke wrote:
> This change replaces the current stack-locking implementation with a
> fast-locking scheme that retains the advantages of stack-locking (namely fast
> locking in uncontended code-paths), while avoiding the overload of the mark
> word. Tha
On Thu, 22 Sep 2022 22:41:21 GMT, Roger Riggs wrote:
>> Clear the signal mask of the child when launching with posix_spawn.
>>
>> SIGQUIT signals are handled on non-Java Threads by the VM.
>> For Java threads the signal mask blocks SIGQUIT.
>> The ProcessBuilder uses posix_spawn on all platfor
On Thu, 22 Sep 2022 22:41:21 GMT, Roger Riggs wrote:
>> Clear the signal mask of the child when launching with posix_spawn.
>>
>> SIGQUIT signals are handled on non-Java Threads by the VM.
>> For Java threads the signal mask blocks SIGQUIT.
>> The ProcessBuilder uses posix_spawn on all platfor
On Thu, 22 Sep 2022 14:26:51 GMT, Roger Riggs wrote:
> Hi Roger, Using the spawn attributes seems more far reaching than simply
> temporarily changing the signal mask of the calling thread. I'd be concerned
> this has some unintended side-effects.
I don't think that is a good idea. If the thre
On Fri, 16 Sep 2022 14:55:42 GMT, Thomas Stuefe wrote:
> Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be
> omitted from the output if a parent class loader never loaded any class and
> therefore had no associated DCmd.
>
> The fix changes the command
On Wed, 21 Sep 2022 16:32:30 GMT, Chris Plummer wrote:
>> Thomas Stuefe has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Fix test error in GHAs
>> - feedback dholmes
>> - childs->child
On Tue, 20 Sep 2022 05:37:44 GMT, Thomas Stuefe wrote:
>> Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be
>> omitted from the output if a parent class loader never loaded any class and
>> therefore had no associated DCmd.
>>
>> The fix c
On Tue, 20 Sep 2022 05:33:10 GMT, Thomas Stuefe wrote:
> Hi @plummercj , thanks for your Review. I worked most of your your feedback.
>
> .. Thomas
-
PR: https://git.openjdk.org/jdk/pull/10312
Thanks to @dholmes-ora for finding this bug.
Thomas Stuefe has updated the pull request incrementally with three additional
commits since the last revision:
- Fix test error in GHAs
- feedback dholmes
- childs->children
-
Changes:
- all: https://git.openjdk.org/jdk/pull/10
On Wed, 21 Sep 2022 02:26:02 GMT, David Holmes wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> cjplummer feedback
>
> src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp l
On Mon, 19 Sep 2022 18:45:35 GMT, Chris Plummer wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> cjplummer feedback
>
> src/hotspot/share/classfile/classLoaderHierarchyDCmd.cpp l
Thanks to @dholmes-ora for finding this bug.
Thomas Stuefe has updated the pull request incrementally with one additional
commit since the last revision:
cjplummer feedback
-
Changes:
- all: https://git.openjdk.org/jdk/pull/10312/files
- new: https://git.openjdk.org/jdk/pull/
On Fri, 16 Sep 2022 14:55:42 GMT, Thomas Stuefe wrote:
> Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be
> omitted from the output if a parent class loader never loaded any class and
> therefore had no associated DCmd.
>
> The fix changes the command
On Thu, 15 Sep 2022 17:56:09 GMT, Mandy Chung wrote:
>> When trying to load a x64 lib on macOS aarch64 one got previously this
>> detailed message before
>> [JDK-8275703](https://bugs.openjdk.org/browse/JDK-8275703):
>>
>> java.lang.UnsatisfiedLinkError: /testing/jco3/macOsx64/libsapjco3.dylib
Fixes a bug in the `VM.classloaders` jcmd that causes class loaders to be
omitted from the output if a parent class loader never loaded any class and
therefore had no associated DCmd.
The fix changes the command to not rely on the existence of a CLD structure for
the loader; instead, all inform
On Fri, 26 Aug 2022 07:54:24 GMT, Matthias Baesken wrote:
>> https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
>> states about MultiByteToWideChar : "The function returns 0 if it does not
>> succeed" and lists a few failure cases.
>> However we m
Found during code review of
[JDK-8292695](https://bugs.openjdk.org/browse/JDK-8292695).
We have two bugs in libjsig when we install hotspot signal handlers. Relevant
code in libjsig:
int sigaction(int sig, const struct sigaction *act, struct sigaction *oact) {
sigused = sigismember(&jvmsig
On Mon, 5 Sep 2022 07:18:09 GMT, Christian Stein wrote:
> > Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes,
> > down to which version?
>
> Yes, down to JDK 11.
>
> Quote from [Coming soon: jtreg
> 7](https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006869.html)
On Mon, 5 Sep 2022 07:18:09 GMT, Christian Stein wrote:
> > Is jtreg 7 downward compatible? Can I use it to test older JDKs, if yes,
> > down to which version?
>
> Yes, down to JDK 11.
>
> Quote from [Coming soon: jtreg
> 7](https://mail.openjdk.org/pipermail/jdk-dev/2022-August/006869.html)
On Mon, 5 Sep 2022 06:12:18 GMT, Christian Stein wrote:
>> Please review the change to update to using jtreg 7.
>>
>> The primary change is to the `jib-profiles.js` file, which specifies the
>> version of jtreg to use, for those systems that rely on this file. In
>> addition, the `requiredVers
On Mon, 5 Sep 2022 06:12:18 GMT, Christian Stein wrote:
>> Please review the change to update to using jtreg 7.
>>
>> The primary change is to the `jib-profiles.js` file, which specifies the
>> version of jtreg to use, for those systems that rely on this file. In
>> addition, the `requiredVers
fix for Hotspot's
>> [JDK-8292083](https://bugs.openjdk.org/browse/JDK-8292083)
>> (https://github.com/openjdk/jdk/pull/9880)
>
> Jonathan Dowland has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Address nit
On Thu, 25 Aug 2022 12:41:31 GMT, Jonathan Dowland wrote:
>> src/java.base/linux/native/libjava/CgroupMetrics.c line 41:
>>
>>> 39: Java_jdk_internal_platform_CgroupMetrics_getTotalMemorySize0
>>> 40: (JNIEnv *env, jclass ignored)
>>> 41: {
>>
>> Why not do it the same way hotspot does?
>>
On Thu, 25 Aug 2022 10:07:15 GMT, Jonathan Dowland wrote:
>> When the container memory exceeds the physical host's memory, the Java
>> metrics reporting is wrong.
>>
>> https://bugs.openjdk.org/browse/JDK-8292541
>>
>> This is the equivalent core-libs fix for Hotspot's
>> [JDK-8292083](https:
On Tue, 23 Aug 2022 21:31:24 GMT, Tyler Steele wrote:
> Adds Classpath exception to assemblyprefix.h. Affects copyright header only.
LGTM
-
Marked as reviewed by stuefe (Reviewer).
PR: https://git.openjdk.org/jdk/pull/9990
On Tue, 23 Aug 2022 16:57:20 GMT, Ioi Lam wrote:
> > Stupid question, does that not mean that the CDS dump generated at build
> > time is not usable with the VM at runtime if that is started with default
> > options?
>
> The CDS archive is still useable.
>
> * If G1 is used at runtime, the sh
On Tue, 23 Aug 2022 15:56:35 GMT, Ioi Lam wrote:
> ZERO uses UseSerialGC by default. When we dump the default CDS archive during
> the build process, it fails to dump the shared heap (which requires G1GC).
>
> The fix is to force -XX:+UseG1GC when dumping the default CDS archive during
> the b
On Thu, 18 Aug 2022 15:46:04 GMT, Julian Waters wrote:
> Initially I did intend to do that, but a raw GetLastError wouldn't exactly be
> very helpful when a failure does occur
I disagree. Error codes are well documented, unlike posix errno with defined
numerical values, and often more helpful
On Thu, 18 Aug 2022 15:11:22 GMT, Harold Seigel wrote:
>> Please review this small change to add a test that option -XX:+CheckJNICalls
>> shows changed signal handlers. This new test is a copy of the recently
>> deleted TestPosixSig.java with small changes. This version of the test only
>> c
On Thu, 18 Aug 2022 11:23:00 GMT, Julian Waters wrote:
> I don't quite get what you mean?
The only thing JLI_ReportErrorMessageSys has above JLI_ReportErrorMessage is
that it prints the error code for you, and that is a very slim win. It turns
into a loss quickly if it does that one thing wron
On Thu, 18 Aug 2022 12:48:30 GMT, Harold Seigel wrote:
> Please review this small change to add a test that option -XX:+CheckJNICalls
> shows changed signal handlers. This new test is a copy of the recently
> deleted TestPosixSig.java with small changes. This version of the test only
> check
On Thu, 18 Aug 2022 09:46:56 GMT, Julian Waters wrote:
>> Let's back up a bit.
>>
>> I looked again, and think @dholmes-ora was originally right when he wrote
>> that this coding does not get called on Windows. Not sure why I thought
>> differently, but I cannot find a single callsite on windo
On Thu, 18 Aug 2022 08:10:34 GMT, Julian Waters wrote:
>> src/java.base/windows/native/libjli/java_md.c line 621:
>>
>>> 619: char *errtext = NULL;
>>> 620:
>>> 621: char* const conflict = "Java detected conflicting Windows and C
>>> Runtime errors and is unable to provide an accurate
On Thu, 18 Aug 2022 08:23:22 GMT, Julian Waters wrote:
>> Second attempt at resolving
>> [JDK-8292016](https://bugs.openjdk.org/browse/JDK-8292016) with a less
>> intrusive approach this time
>>
>> Side note: While it might be preferred to remove this entirely, other areas
>> of the JDK also
On Wed, 17 Aug 2022 11:05:50 GMT, Aleksey Shipilev wrote:
> > I'm confused. How does adding EnsureCapacity in newString646_US fix the
> > compiler warning mentioned in JBS?
>
> I think this is a bona-fide compiler static analyzer bug. GCC 12 compiles
> this code fine. So, we have two options:
On Mon, 15 Aug 2022 13:56:38 GMT, Aleksey Shipilev wrote:
>> See bug report for reproducer and error message. The warning looks quite
>> superficial, and I initially suspected that it complains about `int len =
>> (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the
>> simil
On Mon, 15 Aug 2022 13:56:38 GMT, Aleksey Shipilev wrote:
>> See bug report for reproducer and error message. The warning looks quite
>> superficial, and I initially suspected that it complains about `int len =
>> (int)strlen(str)` cast of `size_t`. But what is confusing is nearly the
>> simil
On Tue, 16 Aug 2022 08:07:52 GMT, Christian Hagedorn
wrote:
>> When printing the native stack trace on Linux (mostly done for hs_err
>> files), it only prints the method with its parameters and a relative offset
>> in the method:
>>
>> Stack: [0x7f6e01739000,0x7f6e0183a000], sp=0x000
On Mon, 15 Aug 2022 11:16:06 GMT, Aleksey Shipilev wrote:
> The affected file was added by
> [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059), and the code that
> fails the compilation is under `#ifdef _WIN32`, and it only (?) gets compiled
> for tests. Looks like we really need the
On Mon, 15 Aug 2022 18:38:51 GMT, Ioi Lam wrote:
> Do you know how much testing is done by the community with zero? We don't
> test it that much in our pipeline.
You could ask the Debian people (Adrian Glaubitz), IIRC they have test farms
with broad platform support and use a lot of zero.
---
On Mon, 15 Aug 2022 14:26:38 GMT, Aleksey Shipilev wrote:
>>> Why? `arguments.hpp` transitively includes it.
>>
>> I thought the rule is not to rely on transitive includes. Unless it is an
>> explicit umbrella header. If you need it, include it - that way if someone
>> changes the include tree
On Mon, 15 Aug 2022 10:57:04 GMT, Aleksey Shipilev wrote:
> Why? `arguments.hpp` transitively includes it.
I thought the rule is not to rely on transitive includes. Unless it is an
explicit umbrella header. If you need it, include it - that way if someone
changes the include tree, we minimize
On Sun, 14 Aug 2022 05:52:01 GMT, Ioi Lam wrote:
>> Enable CDS for zero builds. `java --version` is about 2x faster now.
>>
>>
>> $ perf stat -r 40 ./images/jdk/bin/java -Xshare:off -version
>> 0.034645 +- 0.44 seconds time elapsed ( +- 0.13% )
>> $ perf stat -r 40 ./images/jdk/bin/java -
On Thu, 11 Aug 2022 12:38:50 GMT, David Holmes wrote:
>> Please review this fix for a problem discovered by @stuart-marks in the
>> course of examining the VM shutdown behaviour. The VM code assumed that only
>> unattached threads called JNI's DestroyJavaVM and so they were always
>> attached
On Thu, 11 Aug 2022 02:31:21 GMT, David Holmes wrote:
>> Please review this fix for a problem discovered by @stuart-marks in the
>> course of examining the VM shutdown behaviour. The VM code assumed that only
>> unattached threads called JNI's DestroyJavaVM and so they were always
>> attached
On Thu, 11 Aug 2022 08:26:53 GMT, David Holmes wrote:
>> I disagree. Splitting the test leads causes better runtime (on my 24 core
>> machine: 10.5 seconds vs 16 seconds). It also makes the jtr file easier to
>> read, since it only contains one test. It also is simpler to run a selected
>> tes
On Thu, 11 Aug 2022 02:13:00 GMT, David Holmes wrote:
>> test/hotspot/jtreg/runtime/jni/daemonDestroy/TestDaemonDestroy.java line 36:
>>
>>> 34: * @run main/native TestDaemonDestroy
>>> 35: * @run main/native TestDaemonDestroy daemon
>>> 36: */
>>
>> If you do two @test sections, you can giv
On Tue, 9 Aug 2022 06:10:40 GMT, David Holmes wrote:
> Please review this fix for a problem discovered by @stuart-marks in the
> course of examining the VM shutdown behaviour. The VM code assumed that only
> unattached threads called JNI's DestroyJavaVM and so they were always
> attached as no
On Mon, 8 Aug 2022 13:25:22 GMT, Julian Waters wrote:
>> JLI_ReportErrorMessageSys has a number of issues, as listed below:
>>
>> - The windows variant prints message, then extra-info if available, but the
>> Unix variant prints first extra-info, then message on a newline. Standardize
>> both
On Sun, 7 Aug 2022 06:10:21 GMT, Julian Waters wrote:
> Nothing I could find in the tests that suggest they use this message as
> input, and none of them have failed with this patch, so I guess that's a good
> thing? :P
Oh, that is fine :) Thanks for looking. I just mentioned it since you are
On Sun, 7 Aug 2022 06:10:21 GMT, Julian Waters wrote:
> I don't quite get what you mean by that, should I revert the changes made to
> the freeit checks?
I looked over this function and found a number of issues with it. I created
https://bugs.openjdk.org/browse/JDK-8292016 to track those (if y
On Sat, 6 Aug 2022 00:11:08 GMT, Ioi Lam wrote:
> To improve modularity and build time, move the declaration of the following
> accessor from classfile/javaClasses.hpp to runtime/threadJavaClasses.hpp:
>
> + java_lang_Thread_FieldHolder
> + java_lang_Thread_Constants
> + java_lang_ThreadGroup
>
On Thu, 4 Aug 2022 17:42:45 GMT, Julian Waters wrote:
>> Please review a small patch for dumping the failure reason when the MSVCRT
>> libraries or the Java Virtual Machine fails to load on Windows, which can
>> provide invaluable insight when debugging related launcher issues. This also
>> fi
On Sat, 6 Aug 2022 11:14:55 GMT, Julian Waters wrote:
>> src/java.base/share/native/libjli/emessages.h line 111:
>>
>>> 109: #define DLL_ERROR2 "Error: failed %s, because %s"
>>> 110: #define DLL_ERROR3 "Error: could not find executable %s"
>>> 111: #define DLL_ERROR4 "Error: Fail
On Thu, 4 Aug 2022 17:42:45 GMT, Julian Waters wrote:
>> Please review a small patch for dumping the failure reason when the MSVCRT
>> libraries or the Java Virtual Machine fails to load on Windows, which can
>> provide invaluable insight when debugging related launcher issues. This also
>> fi
On Wed, 27 Jul 2022 14:34:49 GMT, Jorn Vernee wrote:
>> This patch removes the use of std::thread from the `java.lang.foreign`
>> tests, and switches to the OS specific thread APIs, in order to change
>> things such as the stack size on some platforms where this is required in
>> the future (s
On Wed, 27 Jul 2022 14:34:49 GMT, Jorn Vernee wrote:
>> This patch removes the use of std::thread from the `java.lang.foreign`
>> tests, and switches to the OS specific thread APIs, in order to change
>> things such as the stack size on some platforms where this is required in
>> the future (s
On Fri, 22 Jul 2022 16:45:55 GMT, Jorn Vernee wrote:
>> This patch removes the use of std::thread from the `java.lang.foreign`
>> tests, and switches to the OS specific thread APIs, in order to change
>> things such as the stack size on some platforms where this is required in
>> the future (s
On Fri, 22 Jul 2022 16:45:55 GMT, Jorn Vernee wrote:
>> This patch removes the use of std::thread from the `java.lang.foreign`
>> tests, and switches to the OS specific thread APIs, in order to change
>> things such as the stack size on some platforms where this is required in
>> the future (s
On Mon, 18 Jul 2022 14:21:19 GMT, Thomas Stuefe wrote:
> Until [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059) is solved,
> I'd like to disable
>
> - java/foreign/TestUpcallAsync.java
> - java/foreign/enablenativeaccess/TestEnableNativeAccess.java
>
> on m
On Mon, 18 Jul 2022 22:21:44 GMT, Jorn Vernee wrote:
>> Until [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059) is solved,
>> I'd like to disable
>>
>> - java/foreign/TestUpcallAsync.java
>> - java/foreign/enablenativeaccess/TestEnableNativeAccess.java
>>
>> on muslc to take load from
Until [JDK-8290059](https://bugs.openjdk.org/browse/JDK-8290059) is solved, I'd
like to disable
- java/foreign/TestUpcallAsync.java
- java/foreign/enablenativeaccess/TestEnableNativeAccess.java
on muslc to take load from our CIs.
Tests: tested locally that the tests are excluded on Alpine, and
On Thu, 14 Jul 2022 00:42:55 GMT, Ichiroh Takiguchi
wrote:
>> AIX build was failed by following messages:
>>
>> * For target hotspot_variant-server_libjvm_objs_BUILD_LIBJVM_link:
>> ld: 0711-317 ERROR: Undefined symbol: collector_func_load
>> ld: 0711-317 ERROR: Undefined symbol: .collector_fun
On Tue, 12 Jul 2022 18:38:33 GMT, Ioi Lam wrote:
>> src/hotspot/os/posix/perfMemory_posix.cpp line 807:
>>
>>> 805: // Hold the lock until here to prevent other JVMs from using this
>>> file
>>> 806: // while we are in the middle of deleting it.
>>> 807: ::close(fd);
>>
>> I don't
On Tue, 12 Jul 2022 19:12:01 GMT, Ioi Lam wrote:
>> Some Kubernetes setups share the /tmp directory across multiple containers.
>> On rare occasions, the JVM may crash when it tries to write to
>> `/tmp/hsperfdata_/` when a process in a separate container
>> decides to do the same thing (becau
On Sat, 9 Jul 2022 06:49:03 GMT, Ioi Lam wrote:
>> Some Kubernetes setups share the /tmp directory across multiple containers.
>> On rare occasions, the JVM may crash when it tries to write to
>> `/tmp/hsperfdata_/` when a process in a separate container
>> decides to do the same thing (becaus
On Thu, 7 Jul 2022 21:21:27 GMT, Ioi Lam wrote:
>> Some Kubernetes setups share the /tmp directory across multiple containers.
>> On rare occasions, the JVM may crash when it tries to write to
>> `/tmp/hsperfdata_/` when a process in a separate container
>> decides to do the same thing (becaus
On Thu, 7 Jul 2022 21:58:55 GMT, Ioi Lam wrote:
>> src/hotspot/os/posix/perfMemory_posix.cpp line 781:
>>
>>> 779: // signal the process, then the file is assumed to
>>> 780: // be stale and is removed because the files for such a
>>> 781: // process should be in a different user spe
On Thu, 7 Jul 2022 06:01:58 GMT, Ioi Lam wrote:
> Some Kubernetes setups share the /tmp directory across multiple containers.
> On rare occasions, the JVM may crash when it tries to write to
> `/tmp/hsperfdata_/` when a process in a separate container decides
> to do the same thing (because th
On Mon, 4 Jul 2022 07:05:03 GMT, Matthias Baesken wrote:
> Currently the ProcessBuilder/Basic.java test fails on musl.
> We run into
>>'java.io.IOException: Cannot run program "./prog": error=8, Exec format error
> at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
> at java.ba
On Mon, 4 Jul 2022 07:05:03 GMT, Matthias Baesken wrote:
> Currently the ProcessBuilder/Basic.java test fails on musl.
> We run into
>>'java.io.IOException: Cannot run program "./prog": error=8, Exec format error
> at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
> at java.ba
On Fri, 1 Jul 2022 09:10:07 GMT, Christoph Langer wrote:
> This pull request contains a backport of
> [JDK-8287672](https://bugs.openjdk.org/browse/JDK-8287672), commit
> [7e211d7d](https://github.com/openjdk/jdk/commit/7e211d7daac32dca8f26f408d1a3b2c7805b5a2e)
> from the [openjdk/jdk](https:/
On Mon, 27 Jun 2022 08:15:01 GMT, Yi Yang wrote:
>> It seems that calculation of
>> MemoryMXBean.getNonHeapMemoryUsage(jmm_GetMemoryUsage) is wrong.
>>
>> Currently,
>> `NonHeapUsage=CodeCache+Metaspace(ClassTypeSpace+NonClassTypeSpace)+CompressedClassSpace(ClassTypeSpace)`
>>
>> ==> CodeHeap
On Tue, 28 Jun 2022 11:43:42 GMT, Kevin Walls wrote:
>> Test has been problemlisted for a long time due to intermittent failures.
>>
>> This is a difficult test as it tries to monitor usage thresholds on Memory
>> Pools which are outside its control.
>> Not just Java heap pools, where the alloc
On Wed, 22 Jun 2022 01:05:47 GMT, Coleen Phillimore wrote:
>> This changes splits thread.hpp/cpp into javaThread, and threads files.
>>
>> I left the commits intact to see better the progression of changes, but most
>> files are include file changes. The only tricky parts are that some files
On Tue, 21 Jun 2022 11:30:49 GMT, Yi Yang wrote:
> > > > I would have thought that since we don't have the pool anymore, we can
> > > > just remove this test line. The lines above already
> > > > test against MaxMetaspaceSize.
> > >
> > >
> > > Okay.
> > > > I think you may be right, we need a
801 - 900 of 1265 matches
Mail list logo
