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
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
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
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
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
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
>
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
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
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
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
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
>>
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
>>
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
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
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
>
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
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
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
>
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
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`
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
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
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),
>>
>>
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
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
>>
>> T
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
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
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
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
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
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
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
>>
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
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
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
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
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.
>> -
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
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
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
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
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
>
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
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
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
>
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
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
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
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:
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 -
>
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
>
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
>
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
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:
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
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
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
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
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
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
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
>>
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:
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
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(_handletable_mutex);
>>
>> You can make your life a lot easier by defining an RAII object at the start
>> of the file:
>>
>>
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
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
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
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
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
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
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
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
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
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()` ->
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
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
>
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
>
1 - 100 of 1016 matches
Mail list logo
