Found this when working on JOL support
([CODETOOLS-7903364](https://bugs.openjdk.org/browse/CODETOOLS-7903364)). If
you try to attach to VM running with -XX:ObjectAlignmentInBytes=32, then SA
would fail with:
Caused by: java.lang.RuntimeException: Object alignment 32 not yet supported
at jdk.h
On Wed, 19 Oct 2022 12:04:49 GMT, Aleksey Shipilev wrote:
> Found this when working on JOL support
> ([CODETOOLS-7903364](https://bugs.openjdk.org/browse/CODETOOLS-7903364)). If
> you try to attach to VM running with -XX:ObjectAlignmentInBytes=32, then SA
> would fail with:
>
>
> Caused by:
On Wed, 19 Oct 2022 13:03:53 GMT, Thomas Stuefe wrote:
> Looks fine. Curious, how well are all these alignments tested? E.g. do they
> work with all GCs?
I tested `serviceability/sa` with default (G1) and all acceptable alignments,
seems to work fine. We can run the tests with other GCs, if an
> Set the management.properties
> "com.sun.management.jmxremote.serial.filter.pattern" value by default, to
> restrict types that can be deserialized.
>
> Use the example value from the Core Libraries guide (see section 2.
> Serialization Filtering / Built-in Filters / Filters for JMX), plus S
On Fri, 30 Sep 2022 11:00:28 GMT, Kevin Walls wrote:
> Set the management.properties
> "com.sun.management.jmxremote.serial.filter.pattern" value by default, to
> restrict types that can be deserialized.
>
> Use the example value from the Core Libraries guide (see section 2.
> Serialization
On Wed, 19 Oct 2022 16:14:16 GMT, Kevin Walls wrote:
>> Set the management.properties
>> "com.sun.management.jmxremote.serial.filter.pattern" value by default, to
>> restrict types that can be deserialized.
>>
>> Use the example value from the Core Libraries guide (see section 2.
>> Serializ
> Set the management.properties
> "com.sun.management.jmxremote.serial.filter.pattern" value by default, to
> restrict types that can be deserialized.
>
> Use the example value from the Core Libraries guide (see section 2.
> Serialization Filtering / Built-in Filters / Filters for JMX), plus S
On Wed, 19 Oct 2022 16:36:35 GMT, Daniel Fuchs wrote:
> Trivially you should probably add `8283093` in the list of bugs that the test
> helps verify. Also I see the test is using `Utils.getFreePort()` which is a
> recipe for intermittent failures (not something you should change here,
> unless
On Wed, 19 Oct 2022 16:14:16 GMT, Kevin Walls wrote:
>> Set the management.properties
>> "com.sun.management.jmxremote.serial.filter.pattern" value by default, to
>> restrict types that can be deserialized.
>>
>> Use the example value from the Core Libraries guide (see section 2.
>> Serializ
On Wed, 19 Oct 2022 13:09:59 GMT, Aleksey Shipilev wrote:
> Looks fine. Curious, how well are all these alignments tested? E.g. do they
> work with all GCs?
We have gc/TestObjectAlignment.java. I don't see any indication that this test
is not run with all GCs.
-
PR: https://git.o
On Wed, 19 Oct 2022 12:04:49 GMT, Aleksey Shipilev wrote:
> Found this when working on JOL support
> ([CODETOOLS-7903364](https://bugs.openjdk.org/browse/CODETOOLS-7903364)). If
> you try to attach to VM running with -XX:ObjectAlignmentInBytes=32, then SA
> would fail with:
>
>
> Caused by:
On Wed, 19 Oct 2022 12:04:49 GMT, Aleksey Shipilev wrote:
> Found this when working on JOL support
> ([CODETOOLS-7903364](https://bugs.openjdk.org/browse/CODETOOLS-7903364)). If
> you try to attach to VM running with -XX:ObjectAlignmentInBytes=32, then SA
> would fail with:
>
>
> Caused by:
On Wed, 19 Oct 2022 00:04:43 GMT, Alex Menkov wrote:
>> Failures of the test are usually caused by unexpected frame in the stack.
>> Also the failures are intermittent, so it makes sense to report more details
>> on error to simplify analysis.
>> The fix adds stack trace printing if the test fai
On Wed, 19 Oct 2022 19:42:31 GMT, Chris Plummer wrote:
>> Found this when working on JOL support
>> ([CODETOOLS-7903364](https://bugs.openjdk.org/browse/CODETOOLS-7903364)). If
>> you try to attach to VM running with -XX:ObjectAlignmentInBytes=32, then SA
>> would fail with:
>>
>>
>> Caused
On Wed, 19 Oct 2022 12:04:49 GMT, Aleksey Shipilev wrote:
> Found this when working on JOL support
> ([CODETOOLS-7903364](https://bugs.openjdk.org/browse/CODETOOLS-7903364)). If
> you try to attach to VM running with -XX:ObjectAlignmentInBytes=32, then SA
> would fail with:
>
>
> Caused by:
On Wed, 19 Oct 2022 20:25:32 GMT, Aleksey Shipilev wrote:
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VM.java line 505:
>>
>>> 503:
>>> 504: minObjAlignmentInBytes = getObjectAlignmentInBytes();
>>> 505: if (minObjAlignmentInBytes < 8 || minObjAlignmentInBytes > 256 |
On Wed, 19 Oct 2022 20:26:33 GMT, Aleksey Shipilev wrote:
> As I stated in "Additional testing" in the PR description, I did ran
> `serviceability/sa` with different alignments. What other tests we should run?
Sorry, I missed that. There are also some SA tests in test/jdk/sun/tools/jhsdb.
On Wed, 19 Oct 2022 20:59:29 GMT, Chris Plummer wrote:
>> I don't think there is anything specific in SA that prohibits it to follow
>> what Hotspot is capable of. Are you proposing to drop the range check
>> altogether? I can do that.
>
> Yes. I don't see a need for it.
You could keep in the
On Wed, 19 Oct 2022 20:02:55 GMT, Chris Plummer wrote:
>> Alex Menkov has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> merged serviceability/jvmti and nsk/share/jvmti shared code
>
> test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h
> Failures of the test are usually caused by unexpected frame in the stack.
> Also the failures are intermittent, so it makes sense to report more details
> on error to simplify analysis.
> The fix adds stack trace printing if the test fails
Alex Menkov has updated the pull request incrementally
On Wed, 19 Oct 2022 22:58:32 GMT, Serguei Spitsyn wrote:
>> test/hotspot/jtreg/vmTestbase/nsk/share/jni/jni_tools.h line 136:
>>
>>> 134: * Declared and defined in jvmti_common.h
>>> 135: */
>>> 136: //char *jlong_to_string(jlong value, char *string);
>>
>> It seems odd to have jlong_to_strin
On Sun, 18 Sep 2022 11:52:28 GMT, Jaikiran Pai wrote:
> Can I please get a review of this test only change which proposes to fix the
> recent intermittent failures in `RmiBootstrapTest` reported in
> https://bugs.openjdk.org/browse/JDK-8030616?
>
> The test has been intermittently failing with
On Thu, 20 Oct 2022 00:18:10 GMT, Alex Menkov wrote:
>> The fix resolved conflicts between jvmti test shared code:
>> test/lib/jdk/test/lib/jvmti/jvmti_common.h and
>> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/* to allot NSK tests to use
>> jvmti_common.h
>>
>> testing: test native librar
On Tue, 18 Oct 2022 01:20:15 GMT, Serguei Spitsyn wrote:
> The JDI ClassUnloadEvent events are synthesized by the JDWP agent from the
> JVM TI ObjectFree events.
> The JVM TI ObjectFree events are flushed when the JVM TI
> SetEvenNotificationMode is used to disable the ObjectFree events. It is
On Tue, 18 Oct 2022 01:20:15 GMT, Serguei Spitsyn wrote:
> The JDI ClassUnloadEvent events are synthesized by the JDWP agent from the
> JVM TI ObjectFree events.
> The JVM TI ObjectFree events are flushed when the JVM TI
> SetEvenNotificationMode is used to disable the ObjectFree events. It is
On Thu, 20 Oct 2022 00:18:10 GMT, Alex Menkov wrote:
>> The fix resolved conflicts between jvmti test shared code:
>> test/lib/jdk/test/lib/jvmti/jvmti_common.h and
>> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/* to allot NSK tests to use
>> jvmti_common.h
>>
>> testing: test native librar
On Tue, 18 Oct 2022 01:20:15 GMT, Serguei Spitsyn wrote:
> The JDI ClassUnloadEvent events are synthesized by the JDWP agent from the
> JVM TI ObjectFree events.
> The JVM TI ObjectFree events are flushed when the JVM TI
> SetEvenNotificationMode is used to disable the ObjectFree events. It is
On Thu, 20 Oct 2022 00:18:10 GMT, Alex Menkov wrote:
>> The fix resolved conflicts between jvmti test shared code:
>> test/lib/jdk/test/lib/jvmti/jvmti_common.h and
>> test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/* to allot NSK tests to use
>> jvmti_common.h
>>
>> testing: test native librar
On Thu, 20 Oct 2022 01:21:19 GMT, Chris Plummer wrote:
> The debug agent needs to keep track of all loaded classes, and also be
> notified when they are unloaded. It tracks classes loading by getting
> CLASS_PREPARE events and it tracks their unloading by tagging them, which
> triggers OBJECT_
The debug agent needs to keep track of all loaded classes, and also be notified
when they are unloaded. It tracks classes loading by getting CLASS_PREPARE
events and it tracks their unloading by tagging them, which triggers
OBJECT_FREE events when they are unloaded. The tagging and OBJECT_FREE e
30 matches
Mail list logo
