On Thu, 21 Dec 2023 06:11:03 GMT, Emanuel Peter wrote:
>> src/hotspot/share/memory/arena.hpp line 209:
>>
>>> 207:
>>> 208: #ifdef ASSERT
>>> 209: bool Arena_contains(const Arena* arena, const void* ptr);
>>
>> This function doesn't seem necessary. Directly calling arena->contains(ptr)
>> in
On Thu, 21 Dec 2023 11:10:43 GMT, Johan Sjölen wrote:
> ... I also asked for some "length"/"size" naming to be changed to "capacity",
> you don't have to do this as it's pre-existing, but it would make that code
> clearer.
I think I only commented on one in my pass over the code, but I agree w
On Fri, 22 Dec 2023 00:44:16 GMT, David Holmes wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> feedback: reimplemented ThreadDumpe::is_vthread_mounted()
>
> src/hotspot/share/services/heapDumper.cpp line 1934:
>
>>
> HeapDumper dumps virtual threads in 2 places:
> - dumping platform threads (mounted virtual threads are dumped as separate
> thread object);
> - dumping heap objects when the object is `java.lang.VirtualThread`.
>
> In the 2nd case mounted virtual threads should be skipped (as they are
> alrea
On Fri, 22 Dec 2023 00:31:51 GMT, Alex Menkov wrote:
>> HeapDumper dumps virtual threads in 2 places:
>> - dumping platform threads (mounted virtual threads are dumped as separate
>> thread object);
>> - dumping heap objects when the object is `java.lang.VirtualThread`.
>>
>> In the 2nd case mo
> HeapDumper dumps virtual threads in 2 places:
> - dumping platform threads (mounted virtual threads are dumped as separate
> thread object);
> - dumping heap objects when the object is `java.lang.VirtualThread`.
>
> In the 2nd case mounted virtual threads should be skipped (as they are
> alrea
On Thu, 21 Dec 2023 12:23:35 GMT, Serguei Spitsyn wrote:
>> I mean race between virtual thread state change and the thread stack switch
>> (to/from carrier).
>> Correct condition here is "dump the virtual thread if it was not dumped as
>> mounted virtual thread".
>> Most likely for RUNNABLE/PI
> Compiler Control (https://openjdk.org/jeps/165) provides method-context
> dependent control of the JVM compilers (C1 and C2). The active directive
> stack is built from the directive files passed with the
> `-XX:CompilerDirectivesFile` diagnostic command-line option and the
> Compiler.add_dir
On Tue, 19 Dec 2023 21:34:10 GMT, Alex Menkov wrote:
> I mean race between virtual thread state change and the thread stack switch
> (to/from carrier).
I'm not sure if I understand you correctly or if we can call it a race. Alan
will correct me if I'm wrong.
You are talking about thread state
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:45:36 GMT, Thomas Stuefe wrote:
>> In principle you are right, but in my opinion 1024 is an academical limit. I
>> never saw processes with more than a few dozen loaded libraries.
>
> Dynamic allocation also opens us up to potential initialization issues,
> unless we expl
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 10:17:18 GMT, Martin Doerr wrote:
>> Let's keep it simple. A linear array of only a few items is easily scanned,
>> probably faster than pointer hopping hash table entries. Not that it matters
>> in any way for the few calls to dlopen.
>>
>> Also, avoiding hotspot structure
On Thu, 21 Dec 2023 10:48:30 GMT, Johan Sjölen wrote:
>> [JDK-8247755](https://bugs.openjdk.org/browse/JDK-8247755) introduced the
>> `GrowableArrayCHeap`. This duplicates the current C-Heap allocation
>> capability in `GrowableArray`. I now remove that from `GrowableArray` and
>> move all usa
On Wed, 20 Dec 2023 20:39:27 GMT, Kim Barrett wrote:
>> [JDK-8247755](https://bugs.openjdk.org/browse/JDK-8247755) introduced the
>> `GrowableArrayCHeap`. This duplicates the current C-Heap allocation
>> capability in `GrowableArray`. I now remove that from `GrowableArray` and
>> move all usag
On Tue, 19 Dec 2023 16:59:05 GMT, Emanuel Peter wrote:
> [JDK-8247755](https://bugs.openjdk.org/browse/JDK-8247755) introduced the
> `GrowableArrayCHeap`. This duplicates the current C-Heap allocation
> capability in `GrowableArray`. I now remove that from `GrowableArray` and
> move all usages
> Compiler Control (https://openjdk.org/jeps/165) provides method-context
> dependent control of the JVM compilers (C1 and C2). The active directive
> stack is built from the directive files passed with the
> `-XX:CompilerDirectivesFile` diagnostic command-line option and the
> Compiler.add_dir
On Thu, 21 Dec 2023 09:57:08 GMT, Thomas Stuefe wrote:
>> There will be only few libraries in the list. With this assumption Thomas
>> suggested to use just a simple array.
>
> Let's keep it simple. A linear array of only a few items is easily scanned,
> probably faster than pointer hopping has
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 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 problems in the JVM with code that assumes equality of hand
On Wed, 20 Dec 2023 23:45:16 GMT, Martin Doerr wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> improve error handling
>
> src/hotspot/os/aix/porting_aix.cpp line 916:
>
>> 914: constexpr int max_handletable = 1024
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 Wed, 20 Dec 2023 23:10:29 GMT, Martin Doerr wrote:
>> Joachim Kern has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> improve error handling
>
> src/hotspot/os/aix/porting_aix.cpp line 25:
>
>> 23: */
>> 24: // needs to be defined firs
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:30:18 GMT, Thomas Stuefe wrote:
> Hi,
>
> some requests and questions:
>
> * Please modify the JBS title, PR title, and JBS issue text to reflect that
> this adds an alternative shared object loading path for shared objects on
> AIX. Something like "Allow loading shared
26 matches
Mail list logo
