> We were running into this error :
> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
>
> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from
> address 0x34144e30 (expected type JavaThread, CompilerThread,
> MonitorDeflationThread, AttachL
On Thu, 16 Jan 2025 12:20:14 GMT, Kevin Walls wrote:
> Classes should not override
> javax.management.openmbean.OpenType.getClassName(), and this was made illegal
> (caused an Exception) in JDK6. A System Property jmx.extend.open.types was
> introduced to allow such an override, for compatibi
On Tue, 14 Jan 2025 09:39:49 GMT, Kevin Walls wrote:
> The System Property "jdk.jmx.mbeans.allowNonPublic" was added with
> JDK-8010285, to optionally be compatible with a time before JDK-8, when
> Management Interfaces being public was not enforced.
>
> From JDK-8010285:
> _The system propert
On Thu, 16 Jan 2025 13:05:58 GMT, Kevin Walls wrote:
> Remove the System Property "jmx.tabular.data.hash.map" which was introduced
> historically for JMX compatibility with JDK 1.3 clients.
Thanks for the reviews, on all these old-property-removal changes!
-
PR Comment: https://gi
On Wed, 15 Jan 2025 10:59:29 GMT, Kevin Walls wrote:
> Remove the System Property "jmx.mxbean.multiname" which was introduced in
> JDK-7 for compatibility with code which may have depended on previous
> incorrect behaviour. Removal is long overdue.
This pull request has now been integrated.
On Thu, 16 Jan 2025 10:31:09 GMT, Kevin Walls wrote:
> jmx.remote.x.buffer.size was a previous and incorrect name for the
> jmx.remote.x.notification.buffer.size property.
>
> The old name was still recognised to aid compatibility.
> That was 2004. We should only recognise the correct name a
On Thu, 16 Jan 2025 13:05:58 GMT, Kevin Walls wrote:
> Remove the System Property "jmx.tabular.data.hash.map" which was introduced
> historically for JMX compatibility with JDK 1.3 clients.
This pull request has now been integrated.
Changeset: c00557f8
Author:Kevin Walls
URL:
https
On Wed, 22 Jan 2025 10:05:11 GMT, Kevin Walls wrote:
> Redundant after Security Manager removal, remove the Subject.callAs() call on
> a MashalledObject.cast().
> Previously, a Policy could possibly have restricted permissable classes
> available to the cast().
>
> Nothing in our tests fails i
On Wed, 22 Jan 2025 10:05:11 GMT, Kevin Walls wrote:
> Redundant after Security Manager removal, remove the Subject.callAs() call on
> a MashalledObject.cast().
> Previously, a Policy could possibly have restricted permissable classes
> available to the cast().
>
> Nothing in our tests fails i
java.util.logging.LoggingMXBean and
java.util.logging.LogManager::getLoggingMXBean are deprecated since JDK-8139982
in JDK 9.
These deprecations should be uprated to state they are for future removal.
java.util.logging.Logging (implements LoggingMXBean) should also be deprecated
for removal.
On Thu, 23 Jan 2025 15:23:37 GMT, Kevin Walls wrote:
> java.util.logging.LoggingMXBean and
> java.util.logging.LogManager::getLoggingMXBean are deprecated since
> JDK-8139982 in JDK 9.
>
> These deprecations should be uprated to state they are for future removal.
>
> java.util.logging.Logging
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 to
create a mirror of one of these threads, it fails with:
std
> When doing a STEP_OVER, the debug agent does a NotifyFramePop() on the
> current frame as a safety net. After the STEP_OVER completes, the
> NotifyFramePop() is usually still in place. This keeps the thread in
> interp_only mode, which hurts performance. JVMTI has added a new
> ClearAllFrame
On Wed, 22 Jan 2025 07:27:48 GMT, Serguei Spitsyn wrote:
>> Chris Plummer has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Some minor cleanup.
>
> src/jdk.jdwp.agent/share/native/libjdwp/stepControl.c line 940:
>
>> 938:
>> 939:
On Wed, 22 Jan 2025 20:35:22 GMT, Phil Race wrote:
>> Only the `writeExternal` method is required to have a `@serialData` tag in
>> order to keep javadoc running with `-serialwarn` option from complaining. I
>> guess the thinking is that the `readExternal` logic can be derived from that.
>>
>>
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 Did you see David's question? I think this should not have been
in
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 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 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 Thu, 23 Jan 2025 22:03:45 GMT, Dean Long wrote:
> Overall the changes seem fine, however it would be nice if the vmStructs.cpp
> registration mechanism was modular and extensible, instead of monolithic.
> That would make it easier to register private types, or even types outside of
> libjvm
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
21 matches
Mail list logo
