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
On Thu, 15 Feb 2024 15:54:56 GMT, Magnus Ihse Bursie wrote:
> > I would like it if toolchain version bumps were discussed somewhere else
> > first, not in a PR. (And apologies if it was and I missed that discussion).
>
> Yes, it definitely was. I posted a separate [mail to
> build-dev](https:/
On Thu, 11 Jan 2024 13:23:45 GMT, Julian Waters wrote:
>> Compile the JDK as C++17, enabling the use of all C++17 language features
>
> Julian Waters has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Require clang 13 in toolchain.m4
Just on
On Thu, 15 Feb 2024 05:19:45 GMT, Kim Barrett wrote:
> Please review this change that updates the minimum supported version of Clang
> to be used for building OpenJDK from 3.5 to 13.
>
> This permits enabling C++17 (JDK-8314488), though Clang 5 might suffice for
> that. A minimum of Clang 13 als
On Mon, 12 Feb 2024 18:04:21 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 Wed, 31 Jan 2024 13:17:21 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, 30 Jan 2024 10:47:22 GMT, Sebastian Lövdahl wrote:
> 8307977: jcmd and jstack broken for target processes running with elevated
> capabilities
ping @jerboaa
-
PR Comment: https://git.openjdk.org/jdk/pull/17628#issuecomment-1916676356
On Thu, 25 Jan 2024 12:02:35 GMT, Aleksey Shipilev wrote:
> When looking at [JDK-8324647](https://bugs.openjdk.org/browse/JDK-8324647), I
> was surprised to see that GHA has this output:
>
>
> Running test 'jtreg:test/lib-test:tier1'
> /home/runner/work/jdk/jdk/test/lib-test/TEST.groups: group
On Thu, 25 Jan 2024 11:04:03 GMT, Suchismith Roy wrote:
> > For me the unresolved question is still:
> >
> > * do we want an unconditional load of *.a for a given *.so (have yet to see
> > any documentation for this a-file duality)
>
> Yes. The documentation link -
> https://www.ibm.com/docs/
On Thu, 25 Jan 2024 12:30:15 GMT, Matthias Baesken wrote:
> The get_total_or_available_swap_space_size coding misses AIX support, we only
> return 0. This should be enhanced.
> The perfstat API can be used, see
> https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-memory-total-interfa
On Thu, 25 Jan 2024 12:30:15 GMT, Matthias Baesken wrote:
> The get_total_or_available_swap_space_size coding misses AIX support, we only
> return 0. This should be enhanced.
> The perfstat API can be used, see
> https://www.ibm.com/docs/pt/aix/7.2?topic=interfaces-perfstat-memory-total-interfa
On Tue, 16 Jan 2024 08:36:49 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 Wed, 10 Jan 2024 09:18:53 GMT, Matthias Baesken wrote:
> There have been concerns raised about
> [JDK-8276809](https://bugs.openjdk.org/browse/JDK-8276809) , so bring back
> the old behavior.
okay
-
Marked as reviewed by stuefe (Reviewer).
PR Review: https://git.openjdk.org/j
On Tue, 2 Jan 2024 15:03:12 GMT, Matthias Baesken wrote:
> The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced
> with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni , and
> shows on Windows server 2019 the following JNI warning , so the test fails on
>
On Tue, 2 Jan 2024 15:03:12 GMT, Matthias Baesken wrote:
> The new test java/awt/font/JNICheck/FreeTypeScalerJNICheck.java introduced
> with https://bugs.openjdk.java.net/browse/JDK-8269223 adds -Xcheck:jni , and
> shows on Windows server 2019 the following JNI warning , so the test fails on
>
On Fri, 22 Dec 2023 14:50:16 GMT, Joachim Kern wrote:
>> On AIX, repeated calls to dlopen referring to the same shared library may
>> result in different, unique dl handles to be returned from libc. In that it
>> differs from typical libc implementations that cache dl handles.
>>
>> This cause
On Thu, 21 Dec 2023 11:54:17 GMT, Martin Doerr wrote:
>> Dynamic allocation also opens us up to potential initialization issues,
>> unless we explicitly use raw ::malloc. It should work, but I think its
>> better avoided unless we really need it.
>
> Well we're fixing an academic issue by intro
On Thu, 21 Dec 2023 11:23:46 GMT, Joachim Kern wrote:
>> I don't like introducing unnecessary limitations. Are we sure nobody will
>> ever need more than 1024 handles?
>> Can't we at least use a GrowableArray or something like that?
>
> In principle you are right, but in my opinion 1024 is an ac
On Thu, 21 Dec 2023 09:37:55 GMT, Suchismith Roy wrote:
> > > > What happens if we accidentally attempt to load a "real" static
> > > > library, which is also named *.a? Would dlopen() then crash? What would
> > > > happen?
> >
> >
> > > I don't think the problem is with *.a . They would load
On Thu, 21 Dec 2023 09:37:57 GMT, Joachim Kern wrote:
>> src/hotspot/os/aix/porting_aix.cpp line 916:
>>
>>> 914: constexpr int max_handletable = 1024;
>>> 915: static int g_handletable_used = 0;
>>> 916: static struct handletableentry g_handletable[max_handletable] = {{0,
>>> 0, 0, 0}};
>>
>>
On Thu, 21 Dec 2023 08:16:22 GMT, Suchismith Roy wrote:
>> What happens if we accidentally attempt to load a "real" static library,
>> which is also named *.a? Would dlopen() then crash? What would happen?
> I don't think the problem is with *.a . They would load as the default
> behaviour of
On Wed, 20 Dec 2023 14:53:06 GMT, Joachim Kern wrote:
>> On AIX, repeated calls to dlopen referring to the same shared library may
>> result in different, unique dl handles to be returned from libc. In that it
>> differs from typical libc implementations that cache dl handles.
>>
>> This cause
On Wed, 20 Dec 2023 11:16:03 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 Fri, 15 Dec 2023 16:20:02 GMT, Kim Barrett wrote:
>> Julian Waters has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains five additional
>> commits
On Tue, 19 Dec 2023 12:47:53 GMT, Goetz Lindenmaier wrote:
> …g exception
>
> After leaving the method by throwing an exception the data can not be cleaned
> any more.
Seems reasonable.
-
Marked as reviewed by stuefe (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/17156#
On Tue, 19 Dec 2023 12:37:33 GMT, Suchismith Roy wrote:
>> The libpath parsing code is from me, so no license problems.
>
> Hi @JoKern65 Is this good to integrate now ?
@suchismith1993
> Once this code goes in I can push in my changes. We are targeting the fix for
> January.
If you talk abo
On Mon, 18 Dec 2023 13:33:46 GMT, Thomas Stuefe wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Followed Thomas proposals
>
> Well done.
>
> Releasing the mutex before asser
On Mon, 18 Dec 2023 11:12:23 GMT, Joachim Kern wrote:
>> src/hotspot/os/aix/porting_aix.cpp line 1097:
>>
>>> 1095: }
>>> 1096:
>>> 1097: pthread_mutex_lock(&g_handletable_mutex);
>>
>> You can make your life a lot easier by defining an RAII object at the start
>> of the file:
>>
>> stru
On Mon, 18 Dec 2023 10:35:48 GMT, Joachim Kern wrote:
>> src/hotspot/os/aix/porting_aix.cpp line 990:
>>
>>> 988: if (env == nullptr) {
>>> 989: // no LIBPATH, try with LD_LIBRARY_PATH
>>> 990: env = getenv("LD_LIBRARY_PATH");
>>
>> Is LD_LIBRARY_PATH a thing on AIX? I thought it is o
On Mon, 18 Dec 2023 11:30:59 GMT, Joachim Kern wrote:
>> On AIX, repeated calls to dlopen referring to the same shared library may
>> result in different, unique dl handles to be returned from libc. In that it
>> differs from typical libc implementations that cache dl handles.
>>
>> This cause
On Mon, 18 Dec 2023 10:06:34 GMT, Thomas Stuefe wrote:
>> Joachim Kern has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - trailing whitespace
>> - Following most of Thomas proposals
>
> src/hot
On Fri, 15 Dec 2023 11:57:51 GMT, Joachim Kern wrote:
>> On AIX, repeated calls to dlopen referring to the same shared library may
>> result in different, unique dl handles to be returned from libc. In that it
>> differs from typical libc implementations that cache dl handles.
>>
>> This cause
On Fri, 15 Dec 2023 10:18:53 GMT, Joachim Kern wrote:
>> src/hotspot/os/aix/os_aix.cpp line 206:
>>
>>> 204: constexpr int max_handletable = 1024;
>>> 205: static int g_handletable_used = 0;
>>> 206: static struct handletableentry g_handletable[max_handletable] = {{0,
>>> 0, 0, 0}};
>>
>> I wo
On Fri, 15 Dec 2023 09:57:19 GMT, Joachim Kern wrote:
> If we omit the xcoff32 we have to ensure that no xcoff32 executable file
> comes into play.
xcoff32 is for 32-bit binaries. The AIX port only exists for 64-bit, and there
will never be a 32-bit AIX port, so there is no reason for handlin
On Fri, 15 Dec 2023 06:22:39 GMT, Thomas Stuefe wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> followed the proposals
>
> src/hotspot/os/aix/os_aix.cpp line 1129:
>
>> 11
On Tue, 12 Dec 2023 14:05:48 GMT, Joachim Kern wrote:
>> On AIX, repeated calls to dlopen referring to the same shared library may
>> result in different, unique dl handles to be returned from libc. In that it
>> differs from typical libc implementations that cache dl handles.
>>
>> This cause
On Tue, 5 Dec 2023 13:21:35 GMT, Thomas Stuefe wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> encapsulate everything in os::Aix::dlopen
>
> src/hotspot/os/aix/os_aix.cpp line 31
On Mon, 4 Dec 2023 12:33:26 GMT, Joachim Kern wrote:
>> On AIX, repeated calls to dlopen referring to the same shared library may
>> result in different, unique dl handles to be returned from libc. In that it
>> differs from typical libc implementations that cache dl handles.
>>
>> This causes
On Tue, 5 Dec 2023 12:11:46 GMT, Joachim Kern wrote:
>> On AIX, repeated calls to dlopen referring to the same shared library may
>> result in different, unique dl handles to be returned from libc. In that it
>> differs from typical libc implementations that cache dl handles.
>>
>> This causes
On Mon, 4 Dec 2023 00:41:23 GMT, David Holmes wrote:
> From the blog:
>
> > Yes! The methods are being deallocated for a class loader that is still
> > alive.
>
> Okay so why does this happen and is it a reasonable thing to be happening? On
> the surface it sounds wrong to deallocate anything
On Sat, 2 Dec 2023 00:38:58 GMT, Ioi Lam wrote:
>> This is a simple clean up that moves the code for initializing the CDS
>> config states from arguments.cpp to cdsConfig.cpp
>>
>> I renamed a few functions, but otherwise the code is unchanged.
>>
>> - `get_default_shared_archive_path()` -> `d
On Wed, 29 Nov 2023 11:49:31 GMT, Jaroslav Bachorik
wrote:
>> Please, review this fix for a corner case handling of `jmethodID` values.
>>
>> The issue is related to the interplay between `jmethodID` values and method
>> redefinitions. Each `jmethodID` value is effectively a pointer to a `Meth
On Tue, 28 Nov 2023 18:15:56 GMT, Aleksey Shipilev wrote:
> In current GHA, `hotspot_compiler` testing takes a long time, and often takes
> the longest. On MacOS and Windows it routinely takes 60..80 minutes, while
> other test groups run in 30..40 minutes. This often drags the total wall
> cl
On Tue, 28 Nov 2023 11:27:33 GMT, suchismith1993 wrote:
> >
>
> @tstuefe 3rd parameter to pass the either of 2 things:
>
> 1. The JvmTiAgent object "agent", so that after shifting the
> save_library_signature to os_aix,we can still access the agent object.-> For
> this i tried importing
On Mon, 27 Nov 2023 15:44:58 GMT, suchismith1993 wrote:
> > > > i would have to repeat the line 1132 and 1139 in os_aix.cpp again , if
> > > > the condition fails for .so files, because i have to reload it again
> > > > and check if the .a exists. In the shared code i had repeat less number
>
On Mon, 27 Nov 2023 13:23:42 GMT, Thomas Stuefe wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> adopt types
>
> This now causes problems with
>
> https://github.com/openjdk/jd
On Fri, 15 Sep 2023 07:22:32 GMT, Joachim Kern wrote:
>> After push of [JDK-8307478](https://bugs.openjdk.org/browse/JDK-8307478) ,
>> the following test started to fail on AIX :
>> com/sun/tools/attach/warnings/DynamicLoadWarningTest.java;
>> The problem was described in
>> [JDK-8309549](https
On Fri, 24 Nov 2023 10:34:02 GMT, Stefan Karlsson wrote:
> Tests using ProcessTools.executeProcess gets the following output written to
> stdout:
> [2023-11-24T09:58:16.797540608Z] Gathering output for process 2517117
> [2023-11-24T09:58:23.070781345Z] Waiting for completion for process 2517117
On Fri, 24 Nov 2023 11:45:25 GMT, suchismith1993 wrote:
> > i would have to repeat the line 1132 and 1139 in os_aix.cpp again , if the
> > condition fails for .so files, because i have to reload it again and check
> > if the .a exists. In the shared code i had repeat less number of lines i
> >
301 - 400 of 1317 matches
Mail list logo
