On Mon, 13 Jun 2022 18:04:34 GMT, Alan Bateman wrote:
>> This test connects to http://openjdk.java.net/ so it's not reliable if the
>> host name can't be resolved or a HTTP connection cannot be established. I've
>> changed the test to use a local HTTP server so the original test works as
>> be
On Tue, 14 Jun 2022 07:01:33 GMT, Serguei Spitsyn wrote:
>> SonarCloud reports a few uninitialized fields in new VM_Virtual* ops. Those
>> fields are used, and therefore this is a serious bug. These ops seem to be
>> used only from a few corner cases, which is probably
On Mon, 13 Jun 2022 18:14:56 GMT, Aleksey Shipilev wrote:
> SonarCloud reports a few uninitialized fields in new VM_Virtual* ops. Those
> fields are used, and therefore this is a serious bug. These ops seem to be
> used only from a few corner cases, which is probably why this was never
> actua
On Mon, 13 Jun 2022 11:42:43 GMT, David Holmes wrote:
> Maybe we actually need to backtrack and restore an invariant that there is
> always a TLH even for the current thread and fix the JVMTI code that did
> things differently?
This will make JVMTI code unnecessarily ugly in a couple of spots.
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov
On Sat, 4 Jun 2022 17:28:33 GMT, Andrey Turbanov wrote:
> No need to separately perform HashMap.containsKey before HashMap.remove call.
> If key is present - it will be removed anyway. If it's not present, nothing
> will be deleted.
> https://github.com/openjdk/jdk/blob/a6fc485a22484b70daf170e9
On Fri, 3 Jun 2022 17:02:44 GMT, Daniel D. Daugherty wrote:
> A trivial fix that deletes an errant `debugee.resume()` call that causes a
> race
> between the debugger and debuggee. I've also corrected incorrect line number
> values mentioned in comments.
>
> This fix has been tested with the up
On Tue, 7 Jun 2022 00:49:29 GMT, Leonid Mesnik wrote:
> Please review following fix which exclude failing test.
Marked as reviewed by sspitsyn (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/9050
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov
On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote:
> A part of this issue was contributed with the following changeset:
>
> commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
> Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
> Date: Mon Nov
A part of this issue was contributed with the following changeset:
commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2
Author: Daniel D. Daugherty <[dcu...@openjdk.org](mailto:dcu...@openjdk.org)>
Date: Mon Nov 8 14:45:04 2021 +
8249004: Reduce ThreadsListHandle overhead in relation to direct
On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn wrote:
> It was a typo when the original CLEARING_MASK was initially introduced:
>
>
> // Mask to clear normal event bits.
> const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL -
> TOTAL_MIN_EVENT_TYPE_
On Wed, 25 May 2022 00:20:48 GMT, Serguei Spitsyn wrote:
>> It was a typo when the original CLEARING_MASK was initially introduced:
>>
>>
>> // Mask to clear normal event bits.
>> const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL -
On Tue, 24 May 2022 23:49:41 GMT, Serguei Spitsyn wrote:
>> Thanks, Alex! You are right - fixed.
>> I was stupid enough to confuse the direction. Minimal tracing helps in such
>> cases.
>
> Clearing event bits to make it more readable looks like a good idea.
&g
al JVMTI event types but keep the extension event
> bits (0-2) unchanged.
>
> Testing:
> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti
> tests including those added in Loom for virtual thread coverage.
Serguei Spitsyn has updated the pull reques
On Tue, 24 May 2022 23:31:36 GMT, Serguei Spitsyn wrote:
>> Maybe it would be clearer to turn off the bits when there are no events:
>>
>> jlong enabled_bits =
>> env->env_event_enable()->_event_callback_enabled.get_bits();
>> for (i
al JVMTI event types but keep the extension event
> bits (0-2) unchanged.
>
> Testing:
> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti
> tests including those added in Loom for virtual thread coverage.
Serguei Spitsyn has updated the pull request increm
On Tue, 24 May 2022 22:31:16 GMT, Alex Menkov wrote:
>> src/hotspot/share/prims/jvmtiEventController.cpp line 775:
>>
>>> 773: env->set_event_callbacks(callbacks, size_of_callbacks);
>>> 774: // Mask to clear normal event bits.
>>> 775: const jlong CLEARING_MASK = (1L >> (JVMTI_MIN_EVENT_T
al JVMTI event types but keep the extension event
> bits (0-2) unchanged.
>
> Testing:
> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti
> tests including those added in Loom for virtual thread coverage.
Serguei Spitsyn has updated the pu
On Tue, 24 May 2022 22:00:01 GMT, Chris Plummer wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> add extra test coverage for JVMTI extension events:
>> VirtualThreadMount/Virtual
On Tue, 24 May 2022 21:47:54 GMT, Serguei Spitsyn wrote:
>> It was a typo when the original CLEARING_MASK was initially introduced:
>>
>>
>> // Mask to clear normal event bits.
>> const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL -
On Tue, 24 May 2022 20:45:09 GMT, Chris Plummer wrote:
>> It was a typo when the original CLEARING_MASK was initially introduced:
>>
>>
>> // Mask to clear normal event bits.
>> const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL -
>> TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
>> // Avoid
al JVMTI event types but keep the extension event
> bits (0-2) unchanged.
>
> Testing:
> I'll run all JVMTI tests including nsk.jvmti tests and serviceability/jvmti
> tests including those added in Loom for virtual thread coverage.
Serguei Spitsyn has updated the pull reque
On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn wrote:
> It was a typo when the original CLEARING_MASK was initially introduced:
>
>
> // Mask to clear normal event bits.
> const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL -
> TOTAL_MIN_EVENT_TYPE_
On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn wrote:
> It was a typo when the original CLEARING_MASK was initially introduced:
>
>
> // Mask to clear normal event bits.
> const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL -
> TOTAL_MIN_EVENT_TYPE_
On Tue, 24 May 2022 05:45:17 GMT, Serguei Spitsyn wrote:
> It was a typo when the original CLEARING_MASK was initially introduced:
>
>
> // Mask to clear normal event bits.
> const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL -
> TOTAL_MIN_EVENT_TYPE_
It was a typo when the original CLEARING_MASK was initially introduced:
// Mask to clear normal event bits.
const jlong CLEARING_MASK = (1L >> (TOTAL_MIN_EVENT_TYPE_VAL -
TOTAL_MIN_EVENT_TYPE_VAL)) - 1L;
// Avoid cleaning extension event bits.
jlong enabled_bits = CLEARING_MASK &
env->en
On Fri, 20 May 2022 20:09:59 GMT, Leonid Mesnik wrote:
>> The fix disables EscapeBarrier and EscapeAnalysis when certain JVMTI
>> capabilities are enabled and --enable-preview.
>>
>> It restores the same behavior as it was before
>> https://bugs.openjdk.java.net/browse/JDK-8227745 "Enable Esca
On Tue, 10 May 2022 20:23:01 GMT, Leonid Mesnik wrote:
> 8283001: windows-x86-cmp-baseline fails in some jvmti native libs
Looks good.
Thanks,
Serguei
-
Marked as reviewed by sspitsyn (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/8641
On Wed, 4 May 2022 12:12:48 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview).
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the HotSpot VM are disabled by default an
On Wed, 4 May 2022 03:40:03 GMT, Alex Menkov wrote:
>> The test counts all "system" threads before the execution and expects that
>> this number remains the same during test execution.
>> This makes the test fragile - JVM may start internal threads, some threads
>> may end.
>>
>> The fix updat
On Mon, 2 May 2022 23:20:52 GMT, Alex Menkov wrote:
> The test counts all "system" threads before the execution and expects that
> this number remains the same during test execution.
> This makes the test fragile - JVM may start internal threads, some threads
> may end.
>
> The fix updates the
On Fri, 29 Apr 2022 21:39:20 GMT, Alex Menkov wrote:
> The test counts calls of intercepted JNI functions, but doesn't completely
> filter out calls from other threads.
> Function isThreadExpected is used only for ExceptionOccurred function and the
> function checks only some known JFR/Graal th
On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the
On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the
On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the
On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the
On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the
On Wed, 27 Apr 2022 14:24:20 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the
On Wed, 27 Apr 2022 19:00:52 GMT, Coleen Phillimore wrote:
>> Alan Bateman has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Refresh 7965cc6b168e567ac2596f2fbc3b00a7d99b7e1e
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 2388:
>
>> 238
On Tue, 26 Apr 2022 17:27:35 GMT, Alan Bateman wrote:
>> This is the implementation of JEP 425: Virtual Threads (Preview); TBD which
>> JDK version to target.
>>
>> We will refresh this PR periodically to pick up changes and fixes from the
>> loom repo.
>>
>> Most of the new mechanisms in the
On Thu, 21 Apr 2022 20:14:49 GMT, Chris Plummer wrote:
> The test is testing that EventSets for ThreadStartEvents have the proper
> suspendPolicy. When there is more than one ThreadStartRequest and a thread is
> started, each ThreadStartRequest results in a ThreadStartEvent being created,
> an
On Thu, 21 Apr 2022 11:22:48 GMT, Magnus Ihse Bursie wrote:
> I ran `codespell` on modules owned by the serviceability team
> (`java.instrument java.management.rmi java.management jdk.attach
> jdk.hotspot.agent jdk.internal.jvmstat jdk.jcmd jdk.jconsole jdk.jdi
> jdk.jdwp.agent jdk.jstatd jdk.
On Fri, 8 Apr 2022 22:15:21 GMT, Leonid Mesnik wrote:
> The tests serviceability/jvmti/RedefineClasses start failing in loom-repo
> with CNFE like "java.lang.NoClassDefFoundError:
> jdk/test/lib/compiler/InMemoryJavaCompiler"
>
> It is not a loom specific bug, it might happen in jdk/jdk also.
On Sat, 19 Mar 2022 19:34:23 GMT, Chris Plummer wrote:
> `isInNewGen()` is throwing an NPE because "heap" is null:
>
>
> public boolean isInNewGen() {
> return ((gen != null) && (gen == ((GenCollectedHeap)heap).getGen(0)));
> }
>
>
> The call came from here:
>
>
> } else if (isI
JBS issue after the commit.
Thanks,
Paul
-Original Message-
From: serviceability-dev on
behalf of Serguei Spitsyn
Date: Tuesday, January 4, 2022 at 3:05 PM
To: hedongbo , jdk8u-dev
Cc: "serviceability-dev@openjdk.java.net"
Subject:
On Mon, 28 Mar 2022 22:19:49 GMT, Alex Menkov wrote:
> After pushing fix for JDK-8282241 (https://github.com/openjdk/jdk/pull/7676)
> random tests from serviceability/jvmti/RedefineClasses start to fail with
> java.lang.NoClassDefFoundError:
> jdk/test/lib/helpers/ClassFileInstaller$Manifest
>
On Mon, 28 Mar 2022 19:58:59 GMT, Chris Plummer wrote:
> In this test the debuggee creates a couple of threads, and the debugger
> checks to make sure it gets a ThreadStartEvent for each of these threads,
> plus one for the main debuggee thread. Once it has done this, it disables the
> ThreadS
On Tue, 29 Mar 2022 04:24:15 GMT, Ioi Lam wrote:
>> `JvmtiEnv::SetSystemProperty` eventually calls `PathString::set_value` in
>> arguments.cpp, which aborts the VM when it fails to allocate a string copy
>> of the property value.
>>
>>
>> bool PathString::set_value(const char *value) {
>> i
On Mon, 28 Mar 2022 22:06:12 GMT, David Holmes wrote:
>> Ioi Lam has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> @dholmes-ora comments: changed implementation to work with
>> JvmtiEnv::SetSystemProperty
>
> src/hotspot/share/prims/jvmti
On Thu, 24 Mar 2022 01:31:42 GMT, Alex Menkov wrote:
> The change reverts the fix for JDK-8282241 which causes regression
Hi Alex,
The back out is clean.
Thanks,
Serguei
-
Marked as reviewed by sspitsyn (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/7934
On Fri, 4 Mar 2022 17:12:51 GMT, Alex Menkov wrote:
>> JDK-8238048 (fixed in jdk15) moved major_version, minor_version,
>> generic_signature_index and source_file_name_index from InstanceKlass to
>> ConstantPool.
>> We still have some incorrect code in CP merge during class redefinition.
>>
>>
On Tue, 8 Mar 2022 18:37:45 GMT, Aleksey Shipilev wrote:
>> There are few bugs in SetBreakpoint when it reaches for metaspace
>> allocation, notably
>> [JDK-8214992](https://bugs.openjdk.java.net/browse/JDK-8214992) and
>> [JDK-8264149](https://bugs.openjdk.java.net/browse/JDK-8264149). This a
On Fri, 11 Feb 2022 08:54:51 GMT, Leo Korinth wrote:
>> Remove unused imports under test/lib and jtreg/gc. They create lots of
>> warnings if editing using an IDE. Tests in hotspot_gc passed.
>
> Leo Korinth has updated the pull request incrementally with one additional
> commit since the last
On Mon, 7 Feb 2022 15:40:11 GMT, Kevin Walls wrote:
> Test failed many years ago.
> Cannot provoke a failure today in hundreds of runs.
> Initial failure may have been specific to Solaris.
Hi Kevin,
Looks good and trivial.
Thanks,
Serguei
-
Marked as reviewed by sspitsyn (Reviewer)
On Fri, 4 Feb 2022 11:18:39 GMT, Alex Menkov wrote:
> The test expects ClassFileReconstituter restores exactly the same bytes as
> original classbytes.
> This can be wrong if the class has more than 1 method (due to method sorting
> in the VM).
> MethodParametersTarget class had only 1 method (
On Wed, 2 Feb 2022 21:35:59 GMT, Kevin Walls wrote:
> Reduce noise in test output by adding the @SuppressWarnings("removal")
> annotation (which has already been widely applied).
Marked as reviewed by sspitsyn (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/7328
On Wed, 2 Feb 2022 19:34:14 GMT, Roman Kennke wrote:
>> We observe a native memory leak when repeating JDI operations from Eclipse
>> in a debuggee JVM. See bug report for details.
>>
>> AFAICT, this happens because we override methodSignature of a possible
>> pre-existing request object. I am
On Wed, 2 Feb 2022 12:03:47 GMT, Alex Menkov wrote:
>> Changes:
>> - ClassFileReconstituter is updated to restore "MethodParameters" attribute;
>> - handling of the attribute in VM_RedefineClasses is moved to be consistent
>> with other code (like local variable table);
>> - copied ClassTransfor
On Tue, 1 Feb 2022 05:29:36 GMT, Chris Plummer wrote:
> The test is failing to find certain types in the scanoops output when run
> with -Xcomp. This is happening in the loom repo. The reason it is happening
> there is because loom introduced a full GC during codecache sweeping. The
> test onl
On Tue, 1 Feb 2022 05:29:36 GMT, Chris Plummer wrote:
> The test is failing to find certain types in the scanoops output when run
> with -Xcomp. This is happening in the loom repo. The reason it is happening
> there is because loom introduced a full GC during codecache sweeping. The
> test onl
On Thu, 27 Jan 2022 11:32:18 GMT, Alex Menkov wrote:
>> Changes:
>> - ClassFileReconstituter is updated to restore "MethodParameters" attribute;
>> - handling of the attribute in VM_RedefineClasses is moved to be consistent
>> with other code (like local variable table);
>> - copied ClassTransfo
On Fri, 28 Jan 2022 04:07:40 GMT, Chris Plummer wrote:
>> It's possible for an address to be in the codecache but not in any CodeBlob.
>> Don't assert in this case.
>>
>> Also I ran into a couple of other asserts listed below. It looks like since
>> dumping the threadcontext can result in usin
On Fri, 28 Jan 2022 07:34:21 GMT, Chris Plummer wrote:
> The test does a "threadcontext -v -a", and from the following output
> determines the threadID of the SteadyStateThread:
>
> `Thread "SteadyStateThread" id=23 Address=0x01dc51749420`
>
> It then tries threadcontext on this id, but
On Fri, 28 Jan 2022 01:53:09 GMT, Ioi Lam wrote:
> The discussion of CDS in the man pages need to be cleaned up and updated to
> match the latest functionalities and intended usage.
>
> For java.md:
>
> - Reorganized the flow of the doc: Overview -> How to use -> How to create ->
> Restricti
On Fri, 28 Jan 2022 15:37:59 GMT, Aleksey Shipilev wrote:
> Recent test regression after adding new cases in the test. Without compressed
> oops, ~1G elements `Object[]` array takes >8G of memory, which fails the
> test. The fix cuts it down to 512M when reference size is 8 bytes.
> Additional
On Wed, 26 Jan 2022 20:15:59 GMT, Chris Plummer wrote:
> This test is failing in the loom repo when using -Xcomp. The reason is
> because loom introduced doing a full GC in the codecache sweeper, which
> causes some of the Objects referenced by ObjectMonitors to be GC'd. The fix
> is to check
On Tue, 25 Jan 2022 22:07:37 GMT, Chris Plummer wrote:
> It's possible for an address to be in the codecache but not in any CodeBlob.
> Don't assert in this case.
>
> Note I couldn't reproduce this failure. Not sure why since it seemed to
> reproduce pretty readily in our CI tier7, and I ran w
On Wed, 26 Jan 2022 04:35:58 GMT, Jaikiran Pai wrote:
> Can I please get a review for this cleanup that's requested in
> https://bugs.openjdk.java.net/browse/JDK-8076089?
>
> The change here removes a package private method
> `sun.management.Util.newException(Exception e)` and inlines its
> i
On Mon, 24 Jan 2022 10:40:44 GMT, Alex Menkov wrote:
>> Changes:
>> - ClassFileReconstituter is updated to restore "MethodParameters" attribute;
>> - handling of the attribute in VM_RedefineClasses is moved to be consistent
>> with other code (like local variable table);
>> - copied ClassTransfo
On Fri, 21 Jan 2022 15:40:07 GMT, Alex Menkov wrote:
> Changes:
> - ClassFileReconstituter is updated to restore "MethodParameters" attribute;
> - handling of the attribute in VM_RedefineClasses is moved to be consistent
> with other code (like local variable table);
> - copied ClassTransformer
On Tue, 18 Jan 2022 18:33:29 GMT, Aleksey Shipilev wrote:
> While working on JDK-8280003, I noticed that
> java/lang/instrument/GetObjectSizeIntrinsicsTest.java does not test arrays
> with more than 1-byte size elements, and no large arrays (past 4G limit) are
> tested either. It would be bett
On Fri, 14 Jan 2022 16:25:09 GMT, Thomas Stuefe wrote:
>> Very trivial fix to a handle/memory leak.
>>
>> JDK-8215624 added parallel heap iteration to both `jmap -histo` and `jcmd
>> GC.class_histogram`. When called with an explicit file and an invalid
>> argument for number of threads, it le
On Mon, 10 Jan 2022 20:46:36 GMT, Andrey Turbanov wrote:
> `Properties.load` uses `java.util.Properties.LineReader`. LineReader already
> buffers input stream. Hence wrapping InputStream in BufferedInputStream is
> redundant.
Marked as reviewed by sspitsyn (Reviewer).
-
PR: https
On Thu, 13 Jan 2022 14:01:04 GMT, Pavel Rappo wrote:
>> - Most of the typos are of a trivial kind: missing whitespace.
>> - If any of the typos should be fixed in the upstream projects instead,
>> please say so; I will drop those typos from the patch.
>> - As I understand it, ` ` in ImageInputSt
On Wed, 12 Jan 2022 15:04:04 GMT, Kevin Walls wrote:
> The HotSpotAgent.java setupDebugger method has a commmented out section
> relating to possibly using RMISecurityManager.
> The comment is from pre-jdk7. As RMISecurityManager has been deprecated for
> a while the comments should be removed
On Wed, 1 Dec 2021 19:19:02 GMT, zzambers wrote:
> Condition is obviously wrong, because if name starts with "java." other 2
> conditions are always true. Intent, as I understand it, was to redefine class
> where debug event took place (in case of test classes), unless it took place
> in class
Hi,
Just some addition to the below comment.
The man page also has this:
RATIONALE top
In a conforming environment, getegid() will always succeed. It is
possible for implementations to provide an extension where a
process in a non-conforming environment will not be a
On Sun, 2 Jan 2022 04:06:05 GMT, Chris Plummer wrote:
> The test is failing because it is detecting an extra instance of
> `TestClass1`. The test (the debugger side) first tells the debuggee to create
> 10 instances of `TestClass1`. The debugger then uses JDI
> `ClassType.newInstance()` to cre
Hi Hedongbo,
The backport looks okay to me.
But I do not see where I can mark it as approved.
Do you have a PR (Pool Request) or a backport bug number?
Thanks,
Serguei
On 12/29/21, 7:58 PM, "jdk8u-dev on behalf of hedongbo"
wrote:
This problem has affected the customer's use at present.
On Mon, 3 Jan 2022 18:33:40 GMT, Chris Plummer wrote:
>> HSDB has a Memory Viewer feature that brings up a window that shows the
>> memory contents in a specific address range. It basically looks just like
>> the clhsdb "mem" output. The recently revived "mem" command (see
>> [JDK-824466](http
On Sun, 2 Jan 2022 00:56:49 GMT, Chris Plummer wrote:
>> SA has the ability to fetch the thread's registers via the thread context.
>> It would be nice to allow access to the registers from clhsdb. This plays in
>> well with the enhancements being done to PointerFinder as part of
>> JDK-824751
On Fri, 24 Dec 2021 02:44:10 GMT, Chris Plummer wrote:
>> test/hotspot/jtreg/serviceability/sa/ClhsdbThreadContext.java line 34:
>>
>>> 32: * @test
>>> 33: * @bug 8190198
>>> 34: * @summary Test clhsdb where command
>>
>> Should the bug number be 8250801 and the summary say "Test clhsdb
>>
On Thu, 23 Dec 2021 03:31:44 GMT, Chris Plummer wrote:
> HSDB has a Memory Viewer feature that brings up a window that shows the
> memory contents in a specific address range. It basically looks just like the
> clhsdb "mem" output. The recently revived "mem" command (see
> [JDK-824466](https:/
On Thu, 23 Dec 2021 04:06:58 GMT, Chris Plummer wrote:
> SA has the ability to fetch the thread's registers via the thread context. It
> would be nice to allow access to the registers from clhsdb. This plays in
> well with the enhancements being done to PointerFinder as part of
> JDK-8247514.
On Thu, 23 Dec 2021 17:58:56 GMT, Chris Plummer wrote:
>> The SA src/jdk.hotspot.agent/doc/index.html file contains a table of SA
>> scripts and their descriptions. All of these scripts are now gone. They were
>> used to make it easier to launch what today we would call SA tools. Now all
>> th
On Tue, 21 Dec 2021 23:01:20 GMT, Chris Plummer wrote:
>> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java
>> line 560:
>>
>>> 558: } else {
>>> 559: out.println();
>>> 560: }
>>
>> I wonder if it is possi
On Tue, 21 Dec 2021 23:12:45 GMT, Chris Plummer wrote:
>> clhsdb lost support for the "mem" command when javascript support was
>> removed from SA. This PR is re-adding it by implementing it in Java. The
>> description of the CR contains all the details.
>>
>> Regarding the clhsdb.html changes
On Tue, 21 Dec 2021 20:51:04 GMT, Coleen Phillimore wrote:
> This is the fix for https://github.com/openjdk/jdk/pull/6900 retargeted to
> JDK 18.
>
> Thanks to @stefank and @fisk for the diagnosis. ZGC is looking at metadata in
> unloaded nmethods, but redefinition doesn't keep this metadata f
On Tue, 21 Dec 2021 19:58:53 GMT, Chris Plummer wrote:
>> clhsdb lost support for the "mem" command when javascript support was
>> removed from SA. This PR is re-adding it by implementing it in Java. The
>> description of the CR contains all the details.
>>
>> Regarding the clhsdb.html changes
On Tue, 21 Dec 2021 19:58:53 GMT, Chris Plummer wrote:
>> clhsdb lost support for the "mem" command when javascript support was
>> removed from SA. This PR is re-adding it by implementing it in Java. The
>> description of the CR contains all the details.
>>
>> Regarding the clhsdb.html changes
On Tue, 21 Dec 2021 20:28:52 GMT, Kevin Walls wrote:
>> jstatd now in jdk18 fails to start unless we specifically allow or set a
>> SecurityManager.
>> This update to the launcher makefile adds JAVA_ARGS to permit a
>> SecurityManager.
>
> Kevin Walls has updated the pull request incrementally
On Tue, 21 Dec 2021 19:56:07 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList jdk/jfr/event/oldobject/TestLargeRootSet.java on
> 2 platforms
Hi Dan,
This is good and trivial.
Thanks,
Serguei
-
Marked as reviewed by sspitsyn (Reviewer).
PR: https://git.openjdk.java.
On Tue, 21 Dec 2021 02:17:10 GMT, Chris Plummer wrote:
> clhsdb no longer supports javascript. Remove some remaining references in the
> docs. I also removed some script references.
Marked as reviewed by sspitsyn (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/6903
On Sat, 18 Dec 2021 01:08:04 GMT, Chris Plummer wrote:
> "whatis" is one of the old clhsdb commands that was written in javascript and
> lost when Nashorn support was removed. The old "whatis" is the same as the
> old "findpc", but also called LoadObject.lookup() on the address and also
> trie
On Fri, 17 Dec 2021 13:44:01 GMT, Harold Seigel wrote:
>> Please review this fix for JDK-8225093 to set the default value of property
>> jdk.boot.class.path.append to NULL instead of "". This fix was tested by
>> running Mach5 tiers 1-2 on Linux, Mac OS, and Windows, and Mach5 tiers 3-5
>> on
1 - 100 of 840 matches
Mail list logo
