On Thu, 13 Jun 2024 09:47:25 GMT, Christoph Langer wrote:
> It seems the error is gone meanwhile. So we can reenable the test.
Okay. Any idea what fixed the test?
-
Marked as reviewed by stuefe (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19691#pullrequestreview-2115358
On Thu, 13 Jun 2024 09:05:07 GMT, Christoph Langer wrote:
> The test is failing currently and the JBS issue could not be resolved since
> about a month, so let's exclude the test for now.
+1
-
Marked as reviewed by stuefe (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/19
On Wed, 12 Jun 2024 14:04:41 GMT, Sonia Zaldana Calles
wrote:
>> Hi all,
>>
>> This PR addresses [8333685](https://bugs.openjdk.org/browse/JDK-8333685).
>>
>> I have added the following enhancements:
>> - Removed uses of `fgrep` and `egrep` with `grep -F` and `grep -E`
>> respectively.
>>
On Tue, 11 Jun 2024 18:07:10 GMT, Robert Toyonaga wrote:
>> ### Summary
>> This change ensures we don't get undefined behavior when
>> calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).
>> `isspace` accepts an `int` argument that "the application shall
On Tue, 11 Jun 2024 18:07:10 GMT, Robert Toyonaga wrote:
>> ### Summary
>> This change ensures we don't get undefined behavior when
>> calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).
>> `isspace` accepts an `int` argument that "the application shall
On Tue, 11 Jun 2024 13:34:24 GMT, Sonia Zaldana Calles
wrote:
>> Hi all,
>>
>> This PR addresses [8333685](https://bugs.openjdk.org/browse/JDK-8333685).
>>
>> I have added the following enhancements:
>> - Removed uses of `fgrep` and `egrep` with `grep -F` and `grep -E`
>> respectively.
>>
On Mon, 10 Jun 2024 12:30:59 GMT, Matthias Baesken wrote:
> When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure
> flag --enable-ubsan), in a lot of jfr related tests like
> compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr
> serviceability/jvmti/RedefineClasses/Re
On Mon, 10 Jun 2024 12:30:59 GMT, Matthias Baesken wrote:
> When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure
> flag --enable-ubsan), in a lot of jfr related tests like
> compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr
> serviceability/jvmti/RedefineClasses/Re
On Tue, 11 Jun 2024 14:46:10 GMT, Matthias Baesken wrote:
> My maximum JfrEventId is 163 , see the generated
> hotspot/variant-server/gensrc/jfrfiles/jfrEventIds.hpp
>
> ```
>
> enum JfrEventId {
> JfrMetadataEvent = 0,
> JfrCheckpointEvent = 1,
> JfrDurationEvent = 2,
> JfrInstantEven
On Tue, 11 Jun 2024 13:12:48 GMT, Pavel Rappo wrote:
> Opinion: while it's good to see improvements to the existent script, since
> JEP 330, we can now conveniently implement a similar script in Java. That'll
> also automatically take care of OS specifics.
Sure, but the script is here, it work
On Mon, 10 Jun 2024 12:30:59 GMT, Matthias Baesken wrote:
> When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure
> flag --enable-ubsan), in a lot of jfr related tests like
> compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr
> serviceability/jvmti/RedefineClasses/Re
On Fri, 7 Jun 2024 19:01:45 GMT, Sonia Zaldana Calles
wrote:
> Hi all,
>
> This PR addresses [8333685](https://bugs.openjdk.org/browse/JDK-8333685).
>
> I have added the following enhancements:
> - Removed uses of `fgrep` and `egrep` with `grep -F` and `grep -E`
> respectively.
> - Altere
On Fri, 7 Jun 2024 19:01:45 GMT, Sonia Zaldana Calles
wrote:
> Hi all,
>
> This PR addresses [8333685](https://bugs.openjdk.org/browse/JDK-8333685).
>
> I have added the following enhancements:
> - Removed uses of `fgrep` and `egrep` with `grep -F` and `grep -E`
> respectively.
> - Altere
On Tue, 4 Jun 2024 13:46:16 GMT, Inigo Mediavilla Saiz wrote:
>> src/hotspot/share/runtime/threads.cpp line 1336:
>>
>>> 1334: oop vt = p->vthread();
>>> 1335: assert(vt != nullptr, "");
>>> 1336: st->print_cr(" \tMounted virtual thread #"
>>> INT64_FORMAT,
On Fri, 7 Jun 2024 10:40:07 GMT, Thomas Stuefe wrote:
> @dholmes-ora this is one of yours.
>
> This was a tad annoying to fix (fix is simple though), since the jcmd
> framework has no good way to allow for default parameters that are not used
> literally. E.g. in this case, the
On Mon, 10 Jun 2024 08:35:06 GMT, Kevin Walls wrote:
>> @dholmes-ora this is one of yours.
>>
>> This was a tad annoying to fix (fix is simple though), since the jcmd
>> framework has no good way to allow for default parameters that are not used
>> literally. E.g. in this case, the real value
On Mon, 10 Jun 2024 08:20:38 GMT, David Holmes wrote:
> > "To use these functions safely with plain chars (or signed chars), the
> > argument should first be converted to unsigned char"
>
> @tstuefe wow! Okay. That is a surprise to me. A cast to unsigned char doesn't
> actually do anything. Ev
On Mon, 10 Jun 2024 08:20:38 GMT, David Holmes wrote:
> > "To use these functions safely with plain chars (or signed chars), the
> > argument should first be converted to unsigned char"
>
> @tstuefe wow! Okay. That is a surprise to me. A cast to unsigned char doesn't
> actually do anything. Ev
@dholmes-ora this is one of yours.
This was a tad annoying to fix (fix is simple though), since the jcmd framework
has no good way to allow for default parameters that are not used literally.
E.g. in this case, the real value for the file name will contain the process
pid, which of course canno
On Thu, 6 Jun 2024 21:21:23 GMT, David Holmes wrote:
>> ### Summary
>> This change ensures we don't get undefined behavior when
>> calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).
>> `isspace` accepts an `int` argument that "the application shall ensu
On Thu, 6 Jun 2024 21:21:23 GMT, David Holmes wrote:
>> ### Summary
>> This change ensures we don't get undefined behavior when
>> calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).
>> `isspace` accepts an `int` argument that "the application shall ensu
On Tue, 4 Jun 2024 13:23:59 GMT, Inigo Mediavilla Saiz wrote:
>> Note that We are in the process of adding better and saner auto-indentation
>> to outputStream. See https://github.com/openjdk/jdk/pull/19461 . I don't
>> think that PR is going to take long.
>>
>> If you don't want to wait, plea
On Fri, 31 May 2024 14:34:16 GMT, Sonia Zaldana Calles
wrote:
>> Sonia Zaldana Calles has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Decreasing diff size addressing unnecessary changes
>
> Hi all,
>
> I think there's some consensus
On Tue, 4 Jun 2024 13:34:30 GMT, Sonia Zaldana Calles
wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>>
>> In the is
On Tue, 4 Jun 2024 05:30:36 GMT, David Holmes wrote:
>> src/hotspot/share/runtime/javaThread.cpp line 1832:
>>
>>> 1830: st->print("\t");
>>> 1831: indentation--;
>>> 1832: }
>>
>> Suggestion:
>>
>> while (indentation-- > 0) {
>> st->print("\t");
>> }
>>
>> Though not
On Tue, 4 Jun 2024 07:25:41 GMT, Inigo Mediavilla Saiz wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> Inigo Mediavilla Saiz has updated the pull request incrementally with two
> additional commits since the last revision:
>
> - Cleanup te
On Mon, 3 Jun 2024 08:30:15 GMT, Inigo Mediavilla Saiz wrote:
>> Print the stack traces of mounted virtual threads when calling `jcmd
>> Thread.print`.
>
> Inigo Mediavilla Saiz has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Add missing
On Tue, 28 May 2024 12:36:41 GMT, Thomas Stuefe wrote:
> In `JvmtiUtil::single_threaded_resource_area()`, we create a resource area
> that is supposed to work even if the current thread is not attached yet and
> there is no associated Thread or the Thread has no valid ResourceArea
On Wed, 29 May 2024 07:42:01 GMT, Johan Sjölen wrote:
>> In `JvmtiUtil::single_threaded_resource_area()`, we create a resource area
>> that is supposed to work even if the current thread is not attached yet and
>> there is no associated Thread or the Thread has no valid ResourceArea.
>>
>> It
On Wed, 29 May 2024 18:12:25 GMT, Sonia Zaldana Calles
wrote:
> Hi folks,
>
> This PR addresses [8332785](https://bugs.openjdk.org/browse/JDK-8332785)
> replacing all naked uses for ```UseSharedSpaces``` with
> ```CDSConfig::is_using_archive```.
>
> Testing:
> - [x] Tier 1 with GHA.
>
>
On Wed, 29 May 2024 09:09:16 GMT, Matthias Baesken wrote:
> When running with ubsan - enabled binaries (--enable-ubsan),
> in the vmTestbase/nsk/jdi tests some cases of memset on nullptr destinations
> are detected in get_object_monitor_usage .
>
> // null out memory for robustness
> memset(ret
On Tue, 28 May 2024 12:36:41 GMT, Thomas Stuefe wrote:
> In `JvmtiUtil::single_threaded_resource_area()`, we create a resource area
> that is supposed to work even if the current thread is not attached yet and
> there is no associated Thread or the Thread has no valid ResourceArea
On Tue, 28 May 2024 12:36:41 GMT, Thomas Stuefe wrote:
> In `JvmtiUtil::single_threaded_resource_area()`, we create a resource area
> that is supposed to work even if the current thread is not attached yet and
> there is no associated Thread or the Thread has no valid ResourceArea
In `JvmtiUtil::single_threaded_resource_area()`, we create a resource area that
is supposed to work even if the current thread is not attached yet and there is
no associated Thread or the Thread has no valid ResourceArea.
It contains a workaround:
// lazily create the single threaded resou
On Fri, 10 May 2024 09:06:08 GMT, Thomas Stuefe wrote:
> MEMFLAGS, as well as its enum constants, should live in its own include.
>
> The constants are used throughout the code base, often without needing the
> allocation APIs exposed through allocation.hpp.
>
> The ME
On Tue, 14 May 2024 07:19:32 GMT, Thomas Stuefe wrote:
>> MEMFLAGS, as well as its enum constants, should live in its own include.
>>
>> The constants are used throughout the code base, often without needing the
>> allocation APIs exposed through allocation.hpp.
>
On Mon, 13 May 2024 10:17:57 GMT, Stefan Karlsson wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update mallocLimit.hpp
>
> Changes requested by stefank (Reviewer).
@stefank New ve
out the dependencies (e.g.,
> fixing all places where we rely on indirect includes), I added memflags.hpp
> to allocation.hpp.
>
> I tested (built) on:
> - MacOS aarch64, no precompiled headers, fastdebug
> - Linux x64, no precompiled headers, fastdebug, release, fastdebug cros
On Mon, 13 May 2024 18:01:25 GMT, Sonia Zaldana Calles
wrote:
> > This mostly looks good. I'm just puzzled CHECK_EXCEPTION_NULL_FAIL. The JNI
> > functions GetStaticMethodID, GetMethodID and NewObject return NULL with a
> > pending exception when they fail. So I would expect
> > CHECK_EXCEPTI
On Mon, 13 May 2024 15:48:43 GMT, Stefan Karlsson wrote:
>> I tend to agree with that. My earlier question still stands: is there a
>> better place to put it? Right now the "enforced with code" in a stand-alone
>> file doesn't tell me "why" this rule is important.
>
> If you want to keep the st
On Mon, 13 May 2024 14:47:18 GMT, Stefan Karlsson wrote:
>> I don't feel like starting that particular bike shedding discussion :) But
>> sure, sometime in the future we should do this. Here, I want it to be a
>> simple renaming change.
>
> Right. That's why I prefixed this with "Open-ended com
On Mon, 13 May 2024 10:13:50 GMT, Stefan Karlsson wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update mallocLimit.hpp
>
> src/hotspot/share/nmt/memflags.cpp line 31:
>
>&
On Mon, 13 May 2024 10:16:36 GMT, Stefan Karlsson wrote:
>> Thomas Stuefe has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update mallocLimit.hpp
>
> src/hotspot/share/nmt/memflags.hpp line 30:
out the dependencies (e.g.,
> fixing all places where we rely on indirect includes), I added memflags.hpp
> to allocation.hpp.
>
> I tested (built) on:
> - MacOS aarch64, no precompiled headers, fastdebug
> - Linux x64, no precompiled headers, fastdebug, release, fastdebug cros
On Fri, 10 May 2024 09:06:08 GMT, Thomas Stuefe wrote:
> MEMFLAGS, as well as its enum constants, should live in its own include.
>
> The constants are used throughout the code base, often without needing the
> allocation APIs exposed through allocation.hpp.
>
> The ME
MEMFLAGS, as well as its enum constants, should live in its own include.
The constants are used throughout the code base, often without needing the
allocation APIs exposed through allocation.hpp.
The MEMFLAGS enum def is often needed within NMT itself, again often without
needing allocation.hp
On Thu, 9 May 2024 19:52:12 GMT, Sonia Zaldana Calles
wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>>
>> In the is
On Thu, 9 May 2024 19:48:53 GMT, Sonia Zaldana Calles
wrote:
> > This may be food for another RFE, to keep this patch minimal. But a good
> > solution, to me, would be like this:
> >
> > * have the same logic for return codes (1 = error, 0 = success) to ease
> > understanding
> > * have clear
On Thu, 9 May 2024 17:05:40 GMT, Ioi Lam wrote:
>> On Linux aarch64, a JVM may encounter three different page sizes: 4K, 64K,
>> and (when run on Mac M1 hardware) 16K.
>>
>> Since forgetting to specify `--enable-compatible-cds-alignment` is a common
>> error that is only noticed when running t
On Wed, 8 May 2024 15:14:16 GMT, Thomas Stuefe wrote:
> On Linux aarch64, a JVM may encounter three different page sizes: 4K, 64K,
> and (when run on Mac M1 hardware) 16K.
>
> Since forgetting to specify `--enable-compatible-cds-alignment` is a common
> error that is only notic
On Thu, 9 May 2024 05:04:47 GMT, Thomas Stuefe wrote:
>> On Linux aarch64, a JVM may encounter three different page sizes: 4K, 64K,
>> and (when run on Mac M1 hardware) 16K.
>>
>> Since forgetting to specify `--enable-compatible-cds-alignment` is a common
>> e
On Wed, 8 May 2024 15:14:16 GMT, Thomas Stuefe wrote:
> On Linux aarch64, a JVM may encounter three different page sizes: 4K, 64K,
> and (when run on Mac M1 hardware) 16K.
>
> Since forgetting to specify `--enable-compatible-cds-alignment` is a common
> error that is only notic
On Wed, 8 May 2024 17:01:26 GMT, Andrew Haley wrote:
> This is obviously correct. Otherwise, the CDS archive will only work if the
> JDK happens to have been built on a machine with greater or equal page size.
>
> Does the default `compatible-cds-alignment=false` make any sense anywhere on
> o
On Linux aarch64, a JVM may encounter three different page sizes: 4K, 64K, and
(when run on Mac M1 hardware) 16K.
Since forgetting to specify `--enable-compatible-cds-alignment` is a common
error that is only noticed when running the produced JVM on hardware with
different page size, we propose
On Mon, 6 May 2024 19:06:10 GMT, Sonia Zaldana Calles
wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>>
>> In the is
On Thu, 25 Apr 2024 13:22:01 GMT, Matthias Baesken wrote:
>> We have already good JLI tracing capabilities. But GetApplicationHome and
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional com
On Tue, 23 Apr 2024 14:31:44 GMT, Matthias Baesken wrote:
>> We have already good JLI tracing capabilities. But GetApplicationHome and
>> GetApplicationHomeFromDll lack some tracing and should be enhanced.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional com
On Wed, 17 Apr 2024 07:22:55 GMT, David Holmes wrote:
>> I think it makes the code more flexible - it allows to distinguish between
>> "use default value" and "I don't care" cases.
>
> I'm not sure it is a worthwhile distinction. Not passing an actual parameter
> means "I don't care - take the
On Sat, 13 Apr 2024 18:29:59 GMT, Thomas Stuefe wrote:
>> Severin Gehwolf 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 conta
On Thu, 11 Apr 2024 12:08:02 GMT, Severin Gehwolf wrote:
>> Please review this enhancement to the container detection code which allows
>> it to figure out whether the JVM is actually running inside a container
>> (`podman`, `docker`, `crio`), or with some other means that enforces
>> memory/c
On Sat, 13 Apr 2024 18:29:59 GMT, Thomas Stuefe wrote:
>> Severin Gehwolf 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 conta
On Thu, 11 Apr 2024 12:08:02 GMT, Severin Gehwolf wrote:
>> Please review this enhancement to the container detection code which allows
>> it to figure out whether the JVM is actually running inside a container
>> (`podman`, `docker`, `crio`), or with some other means that enforces
>> memory/c
On Tue, 16 Apr 2024 07:55:26 GMT, Thomas Stuefe wrote:
>> Hi folks,
>>
>> This PR aims to fix
>> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>>
>> I think the regression got introduced in
>> [JDK-8315458](https://bugs.openjdk.org
On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles
wrote:
> Hi folks,
>
> This PR aims to fix
> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>
> I think the regression got introduced in
> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>
> In the issue link
On Mon, 15 Apr 2024 18:25:02 GMT, Sonia Zaldana Calles
wrote:
> Hi folks,
>
> This PR aims to fix
> [JDK-8329581](https://bugs.openjdk.org/browse/JDK-8329581).
>
> I think the regression got introduced in
> [JDK-8315458](https://bugs.openjdk.org/browse/JDK-8315458).
>
> In the issue link
On Fri, 12 Apr 2024 14:40:05 GMT, Sergey Nazarkin wrote:
> An alternative for preemptively switching the W^X thread mode on macOS with
> an AArch64 CPU. This implementation triggers the switch in response to the
> SIGBUS signal if the *si_addr* belongs to the CodeCache area. With this
> approa
On Fri, 12 Apr 2024 18:50:37 GMT, Alex Menkov wrote:
> > I am curious: what is the memory overhead for parallel mode, and (I am not
> > familiar with the logic) how many threads are involved? Is the number of
> > thread bounded?
> > I ask because, especially for the OnOOM handling, we may alrea
On Fri, 12 Apr 2024 10:07:48 GMT, Claes Redestad wrote:
> I guess Lilliput adds some hard or soft limit on the number of classes loaded?
Yes, we are concerned with that, especially for a possible future where
Lilliput is the sole default. Atm we can address about 4 million classes. There
are t
On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad wrote:
> This patch suggests a workaround to an issue with huge SCF MH expression
> trees taking excessive JIT compilation resources by reviving (part of) the
> simple bytecode-generating strategy that was originally available as an
> all-or-noth
On Tue, 9 Apr 2024 12:01:49 GMT, Claes Redestad wrote:
> There are a few trade-offs at play here which influence the choice of
> threshold. The simple high arity strategy will for example not see any reuse
> of LambdaForms but strictly always generate a class per indy callsite, which
> means w
On Fri, 12 Apr 2024 02:17:34 GMT, Alex Menkov wrote:
> The fix makes VM heap dumping parallel by default.
> `jcmd GC.heap_dump` and `jmap -dump` had parallel dumping by default, the fix
> affects `HotSpotDiagnosticMXBean.dumpHeap()`, `-XX:+HeapDumpBeforeFullGC`,
> `-XX:+HeapDumpAfterFullGC` and
On Wed, 10 Apr 2024 13:46:11 GMT, Martin Doerr wrote:
>> In my humble opinion the inclusion of alloca.h was slightly cleaner, but I
>> guess it doesn't matter. Out of curiosity, why do you guys prefer not
>> including it?
>
> When only looking at AIX code, I think the inclusion of alloca.h was
On Wed, 10 Apr 2024 12:15:34 GMT, Joachim Kern wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus t
On Tue, 2 Apr 2024 09:19:16 GMT, Joachim Kern wrote:
>> Hi Thomas,
>> I would like to get totally rid of this, because as I mentioned IBM already
>> modified the `stdlib.h` header not using `#define malloc vec_malloc` any
>> more (and all the other vec_... defines). We have to ask the adoptium
On Tue, 2 Apr 2024 16:14:12 GMT, Joachim Kern wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus th
On Tue, 2 Apr 2024 10:26:42 GMT, Joachim Kern wrote:
>> src/hotspot/os/aix/os_aix.cpp line 314:
>>
>>> 312: ErrnoPreserver ep;
>>> 313: log_trace(os, map)("disclaim failed: " RANGEFMT " errno=(%s)",
>>> 314: RANGEFMTARGS(p, (long)maxDisclaimSize),
>>
>> Wait
On Thu, 28 Mar 2024 17:15:26 GMT, Kevin Walls wrote:
>>> In my opinion, UnlockDiagnosticVMOptions is not a good enough safeguard
>>> since it guards a whole swathe of switches that we may instruct the
>>> customer to enable. Once enabled, my experience is that
>>> UnlockDiagnosticVMOptions oft
On Fri, 29 Mar 2024 07:56:10 GMT, Thomas Stuefe wrote:
>> src/hotspot/share/utilities/globalDefinitions_gcc.hpp line 50:
>>
>>> 48: #undef malloc
>>> 49: extern void *malloc(size_t) asm("vec_malloc");
>>> 50: #endif
>>
>> This
On Thu, 28 Mar 2024 16:57:00 GMT, Joachim Kern wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the JDK build.
>> Thus t
On Fri, 29 Mar 2024 07:18:47 GMT, Thomas Stuefe wrote:
>> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
>> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
>> clang by another name, and it uses the clang toolchain in the J
On Thu, 28 Mar 2024 16:50:20 GMT, Joachim Kern wrote:
> As of [JDK-8325880](https://bugs.openjdk.org/browse/JDK-8325880), building
> the JDK requires version 17 of IBM Open XL C/C++ (xlc). This is in effect
> clang by another name, and it uses the clang toolchain in the JDK build. Thus
> the o
On Tue, 19 Mar 2024 16:23:27 GMT, Kevin Walls wrote:
> Client.java has a fixed 30-second timeout on the CountDownLatch to wait for
> 10 notifications.
>
> If it fails, you can't tell if CountDownLatch.await threw, or returned false
> and the app threw InterruptedException, due to the way Clien
On Tue, 19 Mar 2024 16:23:27 GMT, Kevin Walls wrote:
> Client.java has a fixed 30-second timeout on the CountDownLatch to wait for
> 10 notifications.
>
> If it fails, you can't tell if CountDownLatch.await threw, or returned false
> and the app threw InterruptedException, due to the way Clien
On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an
>> additional mode where th
On Tue, 26 Mar 2024 21:55:38 GMT, Kevin Walls wrote:
>> Introduce the jcmd "VM.inspect" to implement access to detailed JVM object
>> information.
>>
>> Not recommended for live production use. Requires UnlockDiagnosticVMOptions
>> and not included in jcmd help output, to remind us this is no
On Mon, 18 Mar 2024 13:14:41 GMT, Richard Reingruber wrote:
>> This pr changes `JfrJvmtiAgent::retransform_classes()` and
>> `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm.
>>
>> Testing:
>> make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java
>> TEST_VM_OPTS=
On Tue, 19 Mar 2024 12:17:22 GMT, David Holmes wrote:
>> Instead, could we tag code that needs one or the other, keep track of the
>> current WX state in thread-local memory, and flip WX only when we know we
>> need to?
The first part we already do.
I wonder wheter we could - at least as wor
On Fri, 8 Mar 2024 10:17:08 GMT, Magnus Ihse Bursie wrote:
> We should match the building of jspawnhelper in
> make/modules/java.base/Launcher.gmk with the usage for all unix platforms in
> src/java.base/unix/classes/java/lang/ProcessImpl.java.
>
> Granted, the list of OSes in the makefile amo
On Fri, 8 Mar 2024 10:17:08 GMT, Magnus Ihse Bursie wrote:
> We should match the building of jspawnhelper in
> make/modules/java.base/Launcher.gmk with the usage for all unix platforms in
> src/java.base/unix/classes/java/lang/ProcessImpl.java.
>
> Granted, the list of OSes in the makefile amo
On Tue, 5 Mar 2024 11:31:13 GMT, Kevin Walls wrote:
>> Introduce the jcmd "VM.debug" to implement access to a useful set of the
>> established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
>>
>> Not recommended for live production use. Calling these "debug" utilities,
>> and n
On Mon, 4 Mar 2024 22:02:53 GMT, Kevin Walls wrote:
>> Kevin Walls has updated the pull request incrementally with three additional
>> commits since the last revision:
>>
>> - Usage correction
>> - Help to clarify this is VM inspection. Comment to relate source to
>> debug.cpp.
>> - jcheck
On Mon, 4 Mar 2024 15:10:12 GMT, Kevin Walls wrote:
>> Introduce the jcmd "VM.debug" to implement access to a useful set of the
>> established debug.cpp utilities, with "jcmd PID VM.debug subcommand ...".
>>
>> Not recommended for live production use. Calling these "debug" utilities,
>> and n
On Mon, 26 Feb 2024 11:24:13 GMT, Suchismith Roy wrote:
>> J2SE agent does not start and throws error when it tries to find the shared
>> library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load
>> fails.It fails to identify the shared library ibm_16_am
On Tue, 20 Feb 2024 09:27:15 GMT, Suchismith Roy wrote:
>> J2SE agent does not start and throws error when it tries to find the shared
>> library ibm_16_am.
>> After searching for ibm_16_am.so ,the jvm agent throws and error as dll_load
>> fails.It fails to identify the shared library ibm_16_am
On Mon, 19 Feb 2024 05:52:22 GMT, Varada M wrote:
> DeCapo Benchmark Results (3 runs) :
>
> Before :
> = DaCapo 9.12 h2 PASSED in 281402 msec =
> = DaCapo 9.12 h2 PASSED in 269818 msec =
> = DaCapo 9.12 h2 PASSED in 279279 msec =
>
> After:
> = DaCapo 9.12 h2 PAS
On Mon, 19 Feb 2024 13:25:28 GMT, Joachim Kern wrote:
>> Thanks for the detailed explanation @JoKern65 . Do then in this errno check
>> may not be necessary ? or can we still set errno and access it some way ?
>
> In this special case here I would not use errno, but the string returned in
> ebu
On Fri, 16 Feb 2024 12:25:39 GMT, Suchismith Roy wrote:
> > > > Hi,
> > > > some remarks:
> > > >
> > > > * there is no need for a copy for the first call to dll_load_library.
> > > > Just hand in the string 1:1.
> > > > * I would only do the *.a fallback loading if the error indicates that
>
On Thu, 15 Feb 2024 17:50:23 GMT, Suchismith Roy wrote:
> > Hi,
> > some remarks:
> >
> > * there is no need for a copy for the first call to dll_load_library. Just
> > hand in the string 1:1.
> > * I would only do the *.a fallback loading if the error indicates that the
> > *.so file had not
On Fri, 16 Feb 2024 04:46:24 GMT, Kim Barrett wrote:
> > Unfortunately this will break my workflow on Linux - I use clang to build
> > on Ubuntu 20.04, which is not that old, but it ships with clang 12. This is
> > not a deal breaker, just annoying.
>
> That's unfortunate, but I think the [[no
On Mon, 5 Feb 2024 09:44:02 GMT, Magnus Ihse Bursie wrote:
> > Sure, you can always install a newer GCC than the system one, but it's
> > another thing that makes it harder for people to build OpenJDK. Having said
> > that, C++17 is nice to have.
>
> @theRealAph I am still just hearing hand-wa
201 - 300 of 1265 matches
Mail list logo