st filed JDK-8349083.
David
- Larry
*From:* Laurence Cable
*Sent:* Thursday, January 30, 2025 9:14:53 AM
*To:* Kemper, William; serviceability-dev; David Holmes; hotspot-
runtime-...@openjdk.org
*Subject:* RE: [EXTERNAL
On Fri, 24 Jan 2025 09:53:43 GMT, SendaoYan wrote:
> Hi all,
> This PR fix a undefined behaviour in 'CollisionsReceiveDifferentIndexes'
> testcase
> locate in 'test/hotspot/gtest/nmt/test_nmt_nativecallstackstorage.cpp' file
> when call `NativeCallStack::NativeCallStack` function. Before this
Adding back serviceability-dev
David
On 30/01/2025 11:55 am, David Holmes wrote:
Plus one to what Kevin says. The current specified behaviour seems to me
to be what would be generally desired. If there is a desire for a
different kind of timestamp to be used then a proposal to add that would
On Thu, 23 Jan 2025 20:15:35 GMT, Chris Plummer wrote:
> If you run hotspot with -XX:+DeoptimizeObjectsALot, it will create one or
> more DeoptimizeObjectsALotThread threads. This is one of many JavaThread
> subclasses that SA needs to know about, but in this case it does not. When SA
> tries
On Tue, 21 Jan 2025 18:48:13 GMT, William Kemper wrote:
> This is a clean backport and addresses a fairly critical issue where in a
> mistimed heap dump may cause heap corruption or vm crashes for Shenandoah GC.
@earthling-amzn and @ysramakrishna JDK 24 is already in RDP2 and as such this
P3
On Tue, 21 Jan 2025 21:19:06 GMT, Coleen Phillimore wrote:
> Please review this change to remove debug printing code that was added
> temporarily for the ClassFileReconstituter to debug constant pool copying a
> long time ago, that is now unused.
> Tested with tier1 locally.
Looks fine. Thanks
On Fri, 17 Jan 2025 21:00:31 GMT, Serguei Spitsyn wrote:
> Can the test fails because clock on the host were changed? There are some
> similar test failures happened when host update clock time during test
> execution.
There should be nothing in the test that interacts with the time-of-day clo
On Thu, 16 Jan 2025 17:53:48 GMT, Leonid Mesnik wrote:
>> test/lib/jdk/test/lib/hprof/parser/ReadBuffer.java line 46:
>>
>>> 44: public int getInt(long pos) throws IOException;
>>> 45: public long getLong(long pos) throws IOException;
>>> 46: public void close() throws IOExceptio
On Thu, 16 Jan 2025 18:18:15 GMT, Leonid Mesnik wrote:
>> There few compiler warning disabled in the testlibary build.
>> They should be fixed or localized and removed from build to prevent new
>> possible issues.
>>
>> The main goal is to avoid new such issues in the testlibrary.
>> Tested wi
On Thu, 16 Jan 2025 16:48:02 GMT, Coleen Phillimore wrote:
> Please review this change to replace SIZE_FORMAT with %zu in the runtime
> code. The second and third commits are hand editing for fixing up formats of
> the code, not the output. After this, there'll be a separate change to
> remo
On Wed, 15 Jan 2025 23:48:33 GMT, Leonid Mesnik wrote:
> There few compiler warning disabled in the testlibary build.
> They should be fixed or localized and removed from build to prevent new
> possible issues.
>
> The main goal is to avoid new such issues in the testlibrary.
> Tested with tie
On Tue, 14 Jan 2025 17:40:20 GMT, Robert Toyonaga wrote:
>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824)
>> which was backed out by
>> [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems
>> documented in [JDK-8343244](https://bugs.openjdk.
On Mon, 13 Jan 2025 17:49:27 GMT, Robert Toyonaga wrote:
>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824)
>> which was backed out by
>> [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems
>> documented in [JDK-8343244](https://bugs.openjdk.
On Mon, 13 Jan 2025 15:49:15 GMT, Coleen Phillimore wrote:
>> There are a lot of format modifiers that are noisy and unnecessary in the
>> code. This change removes the INTX variants. It's not that disruptive even
>> for backporting because %z modifier has been available for a long time so
>
On Mon, 13 Jan 2025 20:53:32 GMT, Robert Toyonaga wrote:
> I think it would still be problem that NonJavaThreads (such as WatcherThread
> and AsyncLogWriter) may use NMT before main_thread is "attached"
Sorry yes of course that is how we started on this current round - the
WatcherThread is cr
On Mon, 13 Jan 2025 13:31:44 GMT, Magnus Ihse Bursie wrote:
>> To be able to properly support static builds on Windows in
>> [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use
>> `DllMain`, for two reasons:
>>
>> 1) This is not called for statically linked libraries, and
On Mon, 13 Jan 2025 15:49:15 GMT, Coleen Phillimore wrote:
>> There are a lot of format modifiers that are noisy and unnecessary in the
>> code. This change removes the INTX variants. It's not that disruptive even
>> for backporting because %z modifier has been available for a long time so
>
On Tue, 7 Jan 2025 12:51:33 GMT, Coleen Phillimore wrote:
>> There are a lot of format modifiers that are noisy and unnecessary in the
>> code. This change removes the INTX variants. It's not that disruptive even
>> for backporting because %z modifier has been available for a long time so
>>
On Tue, 17 Dec 2024 11:10:01 GMT, Magnus Ihse Bursie wrote:
> To be able to properly support static builds on Windows in
> [JDK-8346377](https://bugs.openjdk.org/browse/JDK-8346377), we cannot use
> `DllMain`, for two reasons:
>
> 1) This is not called for statically linked libraries, and
> 2)
On Fri, 10 Jan 2025 19:15:29 GMT, Robert Toyonaga wrote:
> For JavaThreads:
In attach_current_thread, create_stack_guard_pages() and
register_thread_stack_with_NMT() are called before Threads::add.
You can't attach to a VM until a certain point deep into initialization has
been reached.
> For
On Thu, 9 Jan 2025 20:48:21 GMT, Simon Tooke wrote:
>> This test fixes an issue with incomplete Windows threads not yet having a
>> stack. A test for a null stack_base is added to guard against the potential
>> null dereference. An additional test using ZGC is added to the jtreg
>> SystemMap
On Thu, 9 Jan 2025 16:34:08 GMT, Robert Toyonaga wrote:
> Say **thread_A** is the only thread started. It does not acquire the lock
> (since single threaded) and enters the critical section. While **thread_A**
> is in the critical section, **thread_B** is started,
Hold on there - who is starti
On Wed, 8 Jan 2025 07:45:24 GMT, Ramkumar Sunderbabu
wrote:
>> Trivial logging message change.
>
> Ramkumar Sunderbabu has updated the pull request incrementally with one
> additional commit since the last revision:
>
> incorporated review comments
Looks good. Thanks
-
Marked
On Wed, 8 Jan 2025 21:01:37 GMT, Simon Tooke wrote:
>> This test fixes an issue with incomplete Windows threads not yet having a
>> stack. A test for a null stack_base is added to guard against the potential
>> null dereference. An additional test using ZGC is added to the jtreg
>> SystemMap
On Wed, 8 Jan 2025 16:38:50 GMT, Robert Toyonaga wrote:
>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824)
>> which was backed out by
>> [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems
>> documented in [JDK-8343244](https://bugs.openjdk.o
On Tue, 7 Jan 2025 07:58:18 GMT, Ramkumar Sunderbabu
wrote:
> Trivial logging message change.
Changes requested by dholmes (Reviewer).
test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001.java
line 2:
> 1: /*
> 2: * Copyright (c) 2007, 2024, Oracle and/or its affiliates
On Wed, 8 Jan 2025 00:04:31 GMT, David Holmes wrote:
> Revert "8339113: AccessFlags can be u2 in metadata"
>
> This reverts commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1.
>
> The integration of the original change needs to be coordinated with a change
> to Graal
On Wed, 8 Jan 2025 00:10:25 GMT, Coleen Phillimore wrote:
>> Revert "8339113: AccessFlags can be u2 in metadata"
>>
>> This reverts commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1.
>>
>> The integration of the original change needs to be coordinated with a change
>> to Graal so backing out til
Revert "8339113: AccessFlags can be u2 in metadata"
This reverts commit 098afc8b7d0e7caa82999fb9d4e319ea8aed09a1.
The integration of the original change needs to be coordinated with a change to
Graal so backing out till that is ready.
Thanks
-
Commit messages:
- Revert "8339113:
On Tue, 7 Jan 2025 04:46:16 GMT, Leonid Mesnik wrote:
>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted003/TestDescription.java
>> line 43:
>>
>>> 41: * -agentlib:resexhausted=-waittime=5
>>> 42: * -Xms64m
>>> 43: * -Xmx64m
>>
>> Don't you need these t
On Tue, 7 Jan 2025 03:09:59 GMT, Leonid Mesnik wrote:
> Test nsk/jvmti/ResourceExhausted/resexhausted003 limits metaspace size. 9m
> is not enough if sharing classes are disabled.
> It starts failing with -XX:+UseCompactObjectHeaders just because CDS archives
> are no built this mode. Never
On Mon, 6 Jan 2025 19:19:23 GMT, Robert Toyonaga wrote:
> However, it looks like `WatcherThread::stop()` is called early in
> `before_exit` -- after which point NMT can still be used.
Yeah good catch. I just find it frustrating that we already have so many
initialization-progress markers but
On Tue, 7 Jan 2025 03:09:59 GMT, Leonid Mesnik wrote:
> Test nsk/jvmti/ResourceExhausted/resexhausted003 limits metaspace size. 9m
> is not enough if sharing classes are disabled.
> It starts failing with -XX:+UseCompactObjectHeaders just because CDS archives
> are no built this mode. Never
On Mon, 6 Jan 2025 14:12:56 GMT, Coleen Phillimore wrote:
>> Please review this change that makes AccessFlags and modifier_flags u2 types
>> and removes the last remnants of Hotspot adding internal access flags. This
>> change moves AccessFlags and modifier_flags in Klass to alignment gaps
>>
On Mon, 6 Jan 2025 16:41:21 GMT, Patricio Chilano Mateo
wrote:
> Please review the following fix. In method
> `JvmtiEventControllerPrivate::recompute_thread_enabled()`, we are missing to
> call `leave_interp_only_mode()` for the case where `should_be_interp` is
> computed as false and `state-
On Wed, 25 Dec 2024 02:34:16 GMT, Qizheng Xing wrote:
>> This patch fixes unmatched brackets in some files, mostly in comments, docs
>> and man pages.
>
> Qizheng Xing has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revert fix in the CTW M
On Thu, 2 Jan 2025 19:14:56 GMT, Simon Tooke wrote:
>> This test fixes an issue with incomplete Windows threads not yet having a
>> stack. A test for a null stack_base is added to guard against the potential
>> null dereference. An additional test using ZGC is added to the jtreg
>> SystemMap
On Mon, 23 Dec 2024 15:26:13 GMT, Robert Toyonaga wrote:
>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824)
>> which was backed out by
>> [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems
>> documented in [JDK-8343244](https://bugs.openjdk.
On Fri, 3 Jan 2025 22:00:34 GMT, Coleen Phillimore wrote:
>> Please review this change that makes AccessFlags and modifier_flags u2 types
>> and removes the last remnants of Hotspot adding internal access flags. This
>> change moves AccessFlags and modifier_flags in Klass to alignment gaps
>>
On Fri, 20 Dec 2024 18:22:53 GMT, Thomas Stuefe wrote:
> Hotspot loading and CreateJavaVM may happen on different threads
??? What are you referring to as "hotspot loading"? To me that _is_
CreateJavaVM.
> Or, we could move it to the thread subsystem
We already have `Threads::number_of_thread
On Thu, 19 Dec 2024 22:22:13 GMT, Coleen Phillimore wrote:
>> Please review this change that makes AccessFlags and modifier_flags u2 types
>> and removes the last remnants of Hotspot adding internal access flags. This
>> change moves AccessFlags and modifier_flags in Klass to alignment gaps
>
On Thu, 19 Dec 2024 12:47:19 GMT, Coleen Phillimore wrote:
> I could change the name to as_unsigned_short(). Would that be less confusing?
How about `as_u2()` as that is what it is? (less typing :) ).
-
PR Comment: https://git.openjdk.org/jdk/pull/22246#issuecomment-2555777513
On Wed, 18 Dec 2024 19:58:58 GMT, Kim Barrett wrote:
> You don't change ConditionalMutexLocker at all. Just change how it's used:
Doh! @kimbarrett don't know what I was thinking. Thanks
-
PR Comment: https://git.openjdk.org/jdk/pull/22745#issuecomment-2552637884
On Wed, 18 Dec 2024 14:36:41 GMT, Robert Toyonaga wrote:
>> src/hotspot/os/windows/os_windows.cpp line 3624:
>>
>>> 3622: #ifdef ASSERT
>>> 3623: fileStream fs(stdout);
>>> 3624: os::print_memory_mappings((char*)start, bytes, &fs);
>>
>> Why was this change made? tty could be stdout
> The commit being backported was authored by Chris Plummer on 17 Dec 2024 and
> was reviewed by Serguei Spitsyn and David Holmes.
>
> Thanks!
Marked as reviewed by dholmes (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/22805#pullrequestreview-2512981785
On Tue, 17 Dec 2024 15:46:01 GMT, Robert Toyonaga wrote:
>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824)
>> which was backed out by
>> [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems
>> documented in [JDK-8343244](https://bugs.openjdk.
On Tue, 17 Dec 2024 04:01:26 GMT, Kim Barrett wrote:
>> You should be able to use a ConditionalMutexLocker directly to handle this
>> situation - it is one of the usecases that caused CML to be introduced.
>
> CML could perhaps be used has-a (though that might be messy), but should not
> be used
On Tue, 17 Dec 2024 02:25:07 GMT, Chris Plummer wrote:
>> This seems like an unrelated change. ???
>
> jdk.test.lib.thread.VThreadPinner has a native library that must be loaded.
Ah I see. Thanks
-
PR Review Comment: https://git.openjdk.org/jdk/pull/22620#discussion_r1887874661
On Sat, 7 Dec 2024 07:33:38 GMT, Alan Bateman wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rename run1() to test()
>
> test/hotspot/jtreg/vmTestbase/nsk/share/jdb/Launcher.java line 142:
>
>> 140:
On Wed, 11 Dec 2024 17:39:14 GMT, Chris Plummer wrote:
>> This test fails after
>> [JDK-8338713](https://bugs.openjdk.org/browse/JDK-8338713) when using
>> JTREG_TEST_THREAD_FACTORY=Virtual. The test uses JVMTI StopThread on a
>> thread expecting it to be mounted. Before
>> [JDK-8338713](http
etaspace leak with this larger
>> MaxMetaspaceSize.
>
> Coleen Phillimore has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Update
> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineLeakThrowable.java
>
On Mon, 16 Dec 2024 22:15:45 GMT, Kim Barrett wrote:
>> This is a redo of [JDK-8304824](https://bugs.openjdk.org/browse/JDK-8304824)
>> which was backed out by
>> [JDK-8343726](https://bugs.openjdk.org/browse/JDK-8343726) due to problems
>> documented in [JDK-8343244](https://bugs.openjdk.org/
On Fri, 13 Dec 2024 22:25:24 GMT, Coleen Phillimore wrote:
> This increases MaxMetaspaceSize for this test so that it can be run with CDS
> turned off. This change is upstreamed from the valhalla repo from when it
> didn't have CDS on. The test still finds a metaspace leak with this larger
>
On Thu, 12 Dec 2024 12:41:28 GMT, Matthias Baesken wrote:
>> We should output more information about the JVMTI agents in the hserr file.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit since the last revision:
>
> infos -> info
Seems okay. Someone
On Wed, 11 Dec 2024 14:10:27 GMT, Coleen Phillimore wrote:
>> To be clear I would expect arrayKlass to define a pure virtual function for
>> this, and then each subclass overrides as required. Otherwise you can't
>> generally operate on an arrayKlass but must always know what subtype you are
>
On Tue, 10 Dec 2024 13:29:21 GMT, Coleen Phillimore wrote:
>> This moves the modifier_flag computation to when InstanceKlass,
>> ObjArrayKlass and TypeArrayKlass are created.
>>
>> Tested with jck:vm and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one
> addit
On Mon, 9 Dec 2024 12:47:29 GMT, Magnus Ihse Bursie wrote:
> Some files have been modified in 2024, but the copyright year has not been
> properly updated. This should be fixed.
>
> I have located these modified files using:
>
> git log --since="Jan 1" --name-only --pretty=format: | sort -u >
On Tue, 10 Dec 2024 21:53:24 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/oops/arrayKlass.hpp line 123:
>>
>>> 121:
>>> 122: // jvm support
>>> 123: jint compute_modifier_flags() const;
>>
>> I would have expected this to be defined as a virtual function here and then
>> overridden
On Tue, 10 Dec 2024 13:29:21 GMT, Coleen Phillimore wrote:
>> This moves the modifier_flag computation to when InstanceKlass,
>> ObjArrayKlass and TypeArrayKlass are created.
>>
>> Tested with jck:vm and tier1-4.
>
> Coleen Phillimore has updated the pull request incrementally with one
> addit
On Mon, 9 Dec 2024 13:09:50 GMT, Coleen Phillimore wrote:
>> I thought the comment was referring to this code below that late calculates
>> the modifier flags. Don't know why system dictionary was called out though.
>
> And they're not the same as access flags.
The "recalculate" is what is thr
On Tue, 10 Dec 2024 09:08:07 GMT, David Holmes wrote:
>> ObjArrayKlass computes the modifier flags based on the bottom_klass, and
>> there is a place that calls compute_modifier_flags in an assert that
>> requires the virtual function, albeit for an assert, otherwise I woul
On Mon, 9 Dec 2024 13:02:48 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/oops/typeArrayKlass.hpp line 76:
>>
>>> 74: void copy_array(arrayOop s, int src_pos, arrayOop d, int dst_pos,
>>> int length, TRAPS);
>>> 75:
>>> 76: // jvm support
>>
>> "jvm support" for what? I'm not even s
On Mon, 9 Dec 2024 13:27:37 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/classfile/verifier.cpp line 137:
>>
>>> 135: return (should_verify_class &&
>>> 136: // Override parameter (return false) if -Xverify:none
>>> 137: BytecodeVerificationRemote &&
>>
>> Sorry but I don't unde
On Mon, 9 Dec 2024 21:09:41 GMT, Magnus Ihse Bursie wrote:
>> Some files have been modified in 2024, but the copyright year has not been
>> properly updated. This should be fixed.
>>
>> I have located these modified files using:
>>
>> git log --since="Jan 1" --name-only --pretty=format: | sor
On Fri, 6 Dec 2024 18:02:53 GMT, Fabian Meumertzheim wrote:
>> The return value of Metrics#getCpuSetCpus may change over time, including
>> from non-null to null across the two calls in this method.
>
> Fabian Meumertzheim has updated the pull request incrementally with one
> additional commit
On Fri, 6 Dec 2024 22:00:14 GMT, Coleen Phillimore wrote:
> This moves the modifier_flag computation to when InstanceKlass, ObjArrayKlass
> and TypeArrayKlass are created.
>
> Tested with jck:vm and tier1-4.
This seems reasonable, but I wonder if we can simplify things further for
arrays - se
On Fri, 6 Dec 2024 21:34:14 GMT, Coleen Phillimore wrote:
> This change only verifies redefined classes if Verification is enabled.
> BytecodeVerificationRemote will be false for verification turned off. If
> someone turns it off but BytecodeVerificationLocal on (which is
> non-sensical), th
On Tue, 3 Dec 2024 20:16:33 GMT, Chris Plummer wrote:
> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804)
> seems to be some JNI Checker warnings. I decided to resolve all the warnings
> in the debug agent and debugger tests that start with "in native method".
> This
On Wed, 4 Dec 2024 04:53:08 GMT, Chris Plummer wrote:
>> src/jdk.jdwp.agent/share/native/libjdwp/ModuleReferenceImpl.c line 56:
>>
>>> 54: JNI_FUNC_PTR(env,ExceptionClear)(env); // keep -Xcheck:jni happy
>>> 55: ERROR_MESSAGE(("JNI Exception occurred calling
>>> Module.getName()
On Tue, 3 Dec 2024 20:16:33 GMT, Chris Plummer wrote:
> The root cause of [JDK-8344804](https://bugs.openjdk.org/browse/JDK-8344804)
> seems to be some JNI Checker warnings. I decided to resolve all the warnings
> in the debug agent and debugger tests that start with "in native method".
> This
On Tue, 3 Dec 2024 19:10:55 GMT, Patricio Chilano Mateo
wrote:
> Please review this small renaming patch. During the review of JDK-8338383
> there were some comments about improving the naming for
> `ObjectMonitor::owner_from()` and `JavaThread::_lock_id`. These originate
> from the changes i
On Fri, 29 Nov 2024 11:12:22 GMT, Alan Bateman wrote:
>> Adds `jcmd Thread.vthread_scheduler` to print the virtual thread
>> scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers
>> that support virtual threads doing blocking network I/O operations.
>>
>> This is a subset of t
On Thu, 28 Nov 2024 15:54:54 GMT, Alan Bateman wrote:
>> Adds `jcmd Thread.vthread_scheduler` to print the virtual thread
>> scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers
>> that support virtual threads doing blocking network I/O operations.
>>
>> This is a subset of t
On Tue, 26 Nov 2024 06:36:44 GMT, David Holmes wrote:
> After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was
> integrated, the handling of certain symbol lookup code can be simplified. The
> old code needed to support 32-bit Windows, where names had a
On Thu, 28 Nov 2024 02:21:55 GMT, David Holmes wrote:
>> After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783)
>> was integrated, the handling of certain symbol lookup code can be
>> simplified. The old code needed to support 32-bit Windows, where names
On Thu, 28 Nov 2024 01:54:10 GMT, Kim Barrett wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update src/java.base/share/native/libjava/NativeLibraries.c
>>
>> Co-author
d"}
> #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"}
> #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"}
>
> are all singletons and so the actual strings can just be inlined directly
> into the code that uses them.
>
> Testing:
> - GHA
> - Tiers 1-4
d"}
> #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"}
> #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"}
>
> are all singletons and so the actual strings can just be inlined directly
> into the code that uses them.
>
> Testing:
> - GHA
> - Tiers 1-
On Wed, 27 Nov 2024 01:43:34 GMT, Alex Menkov wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update src/java.base/share/native/libjava/NativeLibraries.c
>>
>> Co-author
On Tue, 26 Nov 2024 06:36:44 GMT, David Holmes wrote:
> After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was
> integrated, the handling of certain symbol lookup code can be simplified. The
> old code needed to support 32-bit Windows, where names had a
On Tue, 26 Nov 2024 06:36:44 GMT, David Holmes wrote:
> After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was
> integrated, the handling of certain symbol lookup code can be simplified. The
> old code needed to support 32-bit Windows, where names had a
On Tue, 26 Nov 2024 06:36:44 GMT, David Holmes wrote:
> After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was
> integrated, the handling of certain symbol lookup code can be simplified. The
> old code needed to support 32-bit Windows, where names had a
After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was
integrated, the handling of certain symbol lookup code can be simplified. The
old code needed to support 32-bit Windows, where names had a trailing
`@`. When this special case now is removed, some streamlining is
poss
On Tue, 26 Nov 2024 01:38:55 GMT, David Holmes wrote:
>> c.f:
>> [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420)
>>
>> Summary
>> ---
>>
>> Add `jcmd Thread.vthread_summary` to print summary information
On Thu, 14 Nov 2024 21:34:08 GMT, Larry Cable wrote:
> c.f:
> [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420)
>
> Summary
> ---
>
> Add `jcmd Thread.vthread_summary` to print summary information that is
> useful when trying to diagnose issues wi
On Mon, 4 Nov 2024 07:00:38 GMT, David Holmes wrote:
> This is mostly an audit of the callers of `Exceptions::fthrow` to ensure
> unbounded strings can't appear.
>
> There is a code change in DiagnosticCmd parsing to extend the string length
> limit already used
On Mon, 25 Nov 2024 19:47:38 GMT, Johan Sjölen wrote:
>> David Holmes 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 contain
On Sat, 23 Nov 2024 13:08:13 GMT, SendaoYan wrote:
> Hi all,
> The newly added test
> `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java`
> intermittent fails `the return value of
> "jdk.test.lib.apps.LingeredApp.getProcess()" is null`. This PR check
> `getProcess()` is nu
On Thu, 21 Nov 2024 06:33:30 GMT, Leonid Mesnik wrote:
>> Okay but just to be clear, this change means that the maximum value of this
>> parameter is no longer limited to a 32-bit integer maximum, but is now a
>> 64-bit maximum - the old `parse_integer` function was passed `int` not
>> `jlong`
On Tue, 19 Nov 2024 10:12:15 GMT, Kevin Walls wrote:
>> src/hotspot/share/services/diagnosticCommand.hpp line 892:
>>
>>> 890: protected:
>>> 891: DCmdArgument _log;
>>> 892: DCmdArgument _max;
>>
>> Why `jlong` and not `jint`?
>
> Everything which parses an integer option uses
>
> DCmdAr
On Wed, 20 Nov 2024 12:52:45 GMT, Coleen Phillimore wrote:
>> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineVerifyError.java
>> line 96:
>>
>>> 94: throw new RuntimeException("This should throw VerifyError");
>>> 95: } catch (VerifyError e) {
>>> 96:
On Fri, 15 Nov 2024 15:30:05 GMT, Coleen Phillimore wrote:
>> This change adds a couple of comments, removes some ancient bootstrapping
>> code, and adds an old test that we call the verifier for redefining a class,
>> even one in the bootclass path.
>>
>> The fix for always verifying redefine
your format string can take a
> potentially arbitrary (usually from outside) string then it needs to put its
> own size guard in place using `%*s`.
>
> Testing:
> - tier 1-3 (sanity)
>
> Thanks
David Holmes has updated the pull request with a new target base due to a merge
o
On Tue, 19 Nov 2024 22:14:45 GMT, Coleen Phillimore wrote:
>> David Holmes has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Restore previous behaviour for zero length strings
>
> Okay, I understand the ch
On Wed, 6 Nov 2024 05:16:47 GMT, David Holmes wrote:
>> src/hotspot/share/utilities/exceptions.cpp line 264:
>>
>>> 262: // will be within reasonable limits - specifically we will never hit
>>> the INT_MAX limit
>>> 263: // of os::vsnprintf when
On Mon, 18 Nov 2024 20:56:27 GMT, Leonid Mesnik wrote:
>> Hi
>> Could you please review the the fix that add locks information into SA jhsdb
>> stack --mixed output.
>>
>> Here is the motivation for this rfe and explanation why I add it into SA now.
>>
>> The information about current owners o
On Mon, 18 Nov 2024 12:39:32 GMT, Coleen Phillimore wrote:
>> I don't see any difference in the callers in relation to this PR and the
>> function is not presently declared `extern`. ??
>
> There was an extern trace_class_resolution() function that called this _impl
> function that I removed, s
On Tue, 19 Nov 2024 00:40:09 GMT, Leonid Mesnik wrote:
> The jcmd VM.events max parameter type is changed to INT.
> Also,I noted the max <= 0 is ignored, so I updated documentation and set "0"
> as a default value.
> The jcmd exists if parameter is negative now.
>
> The `max` is `int` while re
On Sat, 16 Nov 2024 05:21:40 GMT, Leonid Mesnik wrote:
>> Hi
>> Could you please review the the fix that add locks information into SA jhsdb
>> stack --mixed output.
>>
>> Here is the motivation for this rfe and explanation why I add it into SA now.
>>
>> The information about current owners o
On Fri, 15 Nov 2024 12:04:37 GMT, Coleen Phillimore wrote:
>> src/hotspot/share/prims/jvm.cpp line 154:
>>
>>> 152: */
>>> 153:
>>> 154: extern void trace_class_resolution(Klass* to_class) {
>>
>> why `extern` ?
>
> jni.cpp functions call this.
I don't see any difference in the callers in rel
1 - 100 of 1309 matches
Mail list logo
