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, 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 #"
>>>
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,
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.
@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
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
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,
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
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 Res
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
>
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 Res
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 Res
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
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
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 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
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
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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
>>
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
>
On Thu, 23 Nov 2023 16:42:35 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 Thu, 23 Nov 2023 17:05:29 GMT, suchismith1993 wrote:
> > I'm not a big fan of this approach. We accumulate more and more "#ifdef
> > AIX" in shared code because of many recent AIX additions. No other platform
> > has such a large ifdef footprint in shared code.
> > I argue that all of this
On Thu, 23 Nov 2023 14:15:54 GMT, Thomas Stuefe wrote:
>> @dholmes-ora
>>> Can't we just check method->method_holder() for null rather than passing in
>>> a parameter like this?
>>
>> I have removed the argument and I am now performing the ch
On Thu, 23 Nov 2023 13:37:41 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 Thu, 23 Nov 2023 08:44:08 GMT, Jaroslav Bachorik
wrote:
>> Jaroslav Bachorik has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - Clean up imports
>> - Simplify Method::clear_jmethod_id()
>> - Use correct copyrights
>
>
On Thu, 23 Nov 2023 05:55:28 GMT, Thomas Stuefe wrote:
>> suchismith1993 has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> change macro position
>
> src/hotspot/os/aix/os_aix.cpp line 3069:
>
>&g
On Wed, 22 Nov 2023 16:24:24 GMT, suchismith1993 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, 22 Nov 2023 16:24:24 GMT, suchismith1993 wrote:
>> JDK-8320005 : Native library suffix impact on hotspot code in AIX
>
> suchismith1993 has updated the pull request incrementally with one additional
> commit since the last revision:
>
> change macro position
Hi, is this patch meant
On Tue, 24 Oct 2023 07:08:07 GMT, Thomas Stuefe wrote:
> When using 'MemStat' CompileCommand, we accidentally register the command if
> an invalid suboption had been specified. Fixed, added regression test
> (verified).
This pull request has now been integrated.
Changeset: 2e34a2
On Wed, 15 Nov 2023 06:22:58 GMT, Thomas Stuefe wrote:
>> When using 'MemStat' CompileCommand, we accidentally register the command if
>> an invalid suboption had been specified. Fixed, added regression test
>> (verified).
>
> Thomas Stuefe has updated the pull reques
> When using 'MemStat' CompileCommand, we accidentally register the command if
> an invalid suboption had been specified. Fixed, added regression test
> (verified).
Thomas Stuefe has updated the pull request incrementally with one additional
commit since the last revision:
feedb
On Tue, 14 Nov 2023 15:03:42 GMT, Aleksey Shipilev wrote:
>> Thomas Stuefe has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains six commits:
>>
>> - Merge branch 'master' into
>> JDK-8318671-Potential-u
On Mon, 13 Nov 2023 13:33:26 GMT, Thomas Stuefe wrote:
>> When using 'MemStat' CompileCommand, we accidentally register the command if
>> an invalid suboption had been specified. Fixed, added regression test
>> (verified).
>
> Thomas Stuefe has updated the pull reques
> When using 'MemStat' CompileCommand, we accidentally register the command if
> an invalid suboption had been specified. Fixed, added regression test
> (verified).
Thomas Stuefe has updated the pull request with a new target base due to a
merge or a rebase. The pull request now con
On Mon, 13 Nov 2023 11:51:30 GMT, Tobias Hartmann wrote:
> I think this is ready for integration given that both @dholmes-ora and
> @jdksjolen are okay with it.
Well, they did not approve yet; @jdksjolen or @dholmes-ora, if you are happy
with this, could you hit the big green button please?
1 - 100 of 358 matches
Mail list logo
