On Sat, 13 Feb 2021 21:53:51 GMT, Daniel D. Daugherty
wrote:
>> A minor fix to add a new function:
>>
>> bool Thread::is_JavaThread_protected(const JavaThread* p)
>>
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() t
On Wed, 17 Feb 2021 03:47:04 GMT, Daniel D. Daugherty
wrote:
>> A minor fix to add a new function:
>>
>> bool Thread::is_JavaThread_protected(const JavaThread* p)
>>
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() t
On Wed, 17 Feb 2021 06:46:27 GMT, Yasumasa Suenaga wrote:
> Linux kernel seems to separate final segment (0xbc78) into RO and RW segments
> when it attempts to load shared library. (but I'm not sure)
I know I've seen this brought up before, if not with SA then with hotspot
itself. Maybe it was
On Wed, 17 Feb 2021 00:13:02 GMT, Chris Plummer wrote:
>> I should add that the failures Dan is seeing are with #id3, which is no
>> -Xcomp, but with a core file instead of a live process. With -Xcomp this
>> part of the test is not run, so possibly this is just an issue with the dso
>> size c
> This PR relates to
> [JDK-8261702](https://bugs.openjdk.java.net/browse/JDK-8261702) ( #2562 )
> When SA creates a DSO object, which is used to represent a shared object file
> (.so), it initializes the "size" to be the size of the shared object file.
> This usually results in the size being t
On Wed, 17 Feb 2021 04:30:45 GMT, Chris Plummer wrote:
> > May I say that we all agreed that "noparallel" is not necessary at present?
> > I think the PR #2519 and related CSR and issue could be all closed.
>
> Yes, assuming we get approval for `dumpheapext`. Unfortunately the email that
> wen
On Thu, 11 Feb 2021 02:43:46 GMT, Lin Zang wrote:
>> 8261482: Adjust jmap histo command to accept noparallel option to inspect
>> heap serially
>
> Dear All,
> Stories and discussions related with this PR could be found at #2379 and
> #2261. Just FYI.
> BRs,
> Lin
>From the discussion of
On Thu, 11 Feb 2021 02:36:01 GMT, Lin Zang wrote:
> 8261482: Adjust jmap histo command to accept noparallel option to inspect
> heap serially
This pull request has been closed without being integrated.
-
PR: https://git.openjdk.java.net/jdk/pull/2519
On Wed, 17 Feb 2021 03:14:51 GMT, Lin Zang wrote:
> May I say that we all agreed that "noparallel" is not necessary at present?
> I think the PR #2519 and related CSR and issue could be all closed.
Yes, assuming we get approval for `dumpheapext`. Unfortunately the email that
went out did not
On Tue, 16 Feb 2021 21:24:32 GMT, Daniel D. Daugherty
wrote:
>> @coleenp and @sspitsyn - Thanks for the re-reviews!
>
> @dholmes and @fisk - did either or both of you plan to review this one?
Merged with master and retested with Mach5 Tier1.
-
PR: https://git.openjdk.java.net/jdk/
> A minor fix to add a new function:
>
> bool Thread::is_JavaThread_protected(const JavaThread* p)
>
> that returns true when the target JavaThread* is protected and false
> otherwise. Update JavaThread::get_thread_name() to create a
> ThreadsListHandle and use the new is_JavaThread_protected
On Sat, 13 Feb 2021 07:10:03 GMT, Chris Plummer wrote:
>>> > Yes, It is not known at present, but the heapInspect and heapDumper
>>> > accept an outputStream, and the actual parallel thread number can be got
>>> > by gang->active_workers() after WithUpdatedActiveWorkers. Then maybe some
>>> >
On Tue, 16 Feb 2021 22:24:19 GMT, Chris Plummer wrote:
>> lookup_symbol implementation contains FIXME comment about object_name.
>> I suppose you want to make this argument ignorance permanent. Then I think
>> this FIXME should be removed (or updated) and it would be nice to add
>> comment abou
> Add "findsym" to clhsdb. See the CR and CSR for details. The
> [CSR](https://bugs.openjdk.java.net/browse/JDK-8261101) still needs a
> reviewer.
>
> There is a fix in LinuxDebuggerLocal_lookupByName0() to allow passing in NULL
> for the dso name. This is allowed, and in fact even not null it
On Tue, 16 Feb 2021 23:28:28 GMT, Chris Plummer wrote:
>> Dan included the logs of the failures in the CR. This is what they show:
>>
>> + findpc 0x2b77f084d116
>> Address 0x2b77f084d116: /lib/x86_64-linux-gnu/libnss_files.so.2 +
>> 0x21b116
>> ...
>> java.lang.RuntimeException: Test
On Tue, 16 Feb 2021 22:51:34 GMT, Chris Plummer wrote:
>>> I updated patch for macOS. I cannot test it, but all of tier 1
>>> servicerbility tests were passed on GitHub Actions. Could you review again?
>>
>> The OSX changes look good and passed my testing. However as Dan indicated
>> above, it
On Tue, 16 Feb 2021 12:19:38 GMT, Yasumasa Suenaga wrote:
> I updated patch for macOS. I cannot test it, but all of tier 1 servicerbility
> tests were passed on GitHub Actions. Could you review again?
The OSX changes look good and passed my testing. However as Dan indicated
above, it seems wit
On Tue, 16 Feb 2021 22:50:58 GMT, Chris Plummer wrote:
>> Thanks for explanation!
>> I understood Marc-O is complex, and to use `lib->memsz` is reasonable as you
>> said.
>>
>> I updated patch for macOS. I cannot test it, but all of tier 1
>> servicerbility tests were passed on GitHub Actions.
On Sun, 14 Feb 2021 09:14:43 GMT, Chris Plummer wrote:
> See CR for details. There's no test for `versioncheck`, and I don't think
> it's worth adding, especially for this trivial fix. Here's how I tested:
> hsdb> versioncheck
> versioncheck is true
> hsdb> versioncheck false
> hsdb> versionchec
On Tue, 16 Feb 2021 22:07:04 GMT, Alex Menkov wrote:
>> The point is the argument is ignored, so it doesn't really matter if
>> AutoJavaString can handle NULL. I assume with your suggested fix that also
>> want me to pass objectName_cstr to lookup_symbol() rather than an explicit
>> NULL. I w
On Tue, 16 Feb 2021 21:43:53 GMT, Chris Plummer wrote:
>> While I was characterizing:
>>
>> JDK-8261844 serviceability/sa/ClhsdbFindPC.java#id1 failed with "'In
>> code in NMethod for LingeredAppWithTrivialMain.main' missing from
>> stdout/stderr"
>>
>> I determined that I could easily re
On Tue, 16 Feb 2021 12:19:38 GMT, Yasumasa Suenaga wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8250750 has some interesting
>> details that I forgot about. Note this is referencing the state of the code
>> before fixing JDK-8250750, which changed how `lib->memsz` is calculated.
>>
>>> `
On Sun, 14 Feb 2021 09:14:43 GMT, Chris Plummer wrote:
> See CR for details. There's no test for `versioncheck`, and I don't think
> it's worth adding, especially for this trivial fix. Here's how I tested:
> hsdb> versioncheck
> versioncheck is true
> hsdb> versioncheck false
> hsdb> versionchec
On Tue, 16 Feb 2021 01:26:46 GMT, Chris Plummer wrote:
>> src/jdk.hotspot.agent/linux/native/libsaproc/LinuxDebuggerLocal.cpp line 350:
>>
>>> 348: // Note, objectName is ignored, and may in fact be NULL.
>>> 349: // lookup_symbol will always search all objects/libs
>>> 350: //AutoJavaStri
> Dear community,
> may I please request reviews for this fix, improving the usefulness of method
> invocation counters.
> - aggregation counters are retyped as uint64_t, shifting the overflow
> probability way out (185 days in case of a 1 GHz counter update frequency).
> - counters for individua
On Tue, 16 Feb 2021 21:29:23 GMT, Daniel D. Daugherty
wrote:
>> Looks good.
>
> While I was characterizing:
>
> JDK-8261844 serviceability/sa/ClhsdbFindPC.java#id1 failed with "'In code
> in NMethod for LingeredAppWithTrivialMain.main' missing from stdout/stderr"
>
> I determined that I c
On Tue, 16 Feb 2021 09:10:17 GMT, Kevin Walls wrote:
>> See bug description for details. The fix is simple and just a matter of
>> moving some code to avoid incorrectly thinking an address is in a .so when
>> it is in some other area of VM memory that occurs just after the last .so.
>
> Looks g
On Tue, 16 Feb 2021 21:23:48 GMT, Daniel D. Daugherty
wrote:
>> Thanks!
>
> @coleenp and @sspitsyn - Thanks for the re-reviews!
@dholmes and @fisk - did either or both of you plan to review this one?
-
PR: https://git.openjdk.java.net/jdk/pull/2535
On Tue, 16 Feb 2021 12:35:28 GMT, Coleen Phillimore wrote:
>> Daniel D. Daugherty has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address coleenp CR0 comments.
>
> Thanks!
@coleenp and @sspitsyn - Thanks for the re-reviews!
---
On Mon, 15 Feb 2021 06:00:29 GMT, Chris Plummer wrote:
> Delete some localrefs to avoid -Xcheck:jni warnings. See CR for details.
This pull request has now been integrated.
Changeset: 55d7bbce
Author:Chris Plummer
URL: https://git.openjdk.java.net/jdk/commit/55d7bbce
Stats: 23 li
> 8080272 Refactor I/O stream copying to use
> InputStream.transferTo/readAllBytes and Files.copy
Andrey Turbanov has updated the pull request incrementally with one additional
commit since the last revision:
8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
cleanu
On Tue, 9 Feb 2021 11:40:09 GMT, Philippe Marschall
wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>> fix review comments
>
> src/ja
On Mon, 8 Feb 2021 21:18:44 GMT, Philippe Marschall
wrote:
>> Andrey Turbanov has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>> fix review comments
>
> src/ja
On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov
wrote:
> 8080272 Refactor I/O stream copying to use
> InputStream.transferTo/readAllBytes and Files.copy
Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have
they been addressed?
https://github.com/openjdk/jdk/pull/
> Dear community,
> may I please request reviews for this fix, improving the usefulness of method
> invocation counters.
> - aggregation counters are retyped as uint64_t, shifting the overflow
> probability way out (185 days in case of a 1 GHz counter update frequency).
> - counters for individua
> Dear community,
> may I please request reviews for this fix, improving the usefulness of method
> invocation counters.
> - aggregation counters are retyped as uint64_t, shifting the overflow
> probability way out (185 days in case of a 1 GHz counter update frequency).
> - counters for individua
On Thu, 4 Feb 2021 22:49:23 GMT, Gerard Ziemski wrote:
>> Anton Kozlov has updated the pull request incrementally with six additional
>> commits since the last revision:
>>
>> - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>> - Add comments to WX transitions
>>
>>
On Sat, 13 Feb 2021 21:53:51 GMT, Daniel D. Daugherty
wrote:
>> A minor fix to add a new function:
>>
>> bool Thread::is_JavaThread_protected(const JavaThread* p)
>>
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() t
On Sat, 13 Feb 2021 15:42:32 GMT, Daniel D. Daugherty
wrote:
>> And it looks like making is_JavaThread_protected() a protected function
>> doesn't work either since `JavaThread::get_thread_name()` can't call it:
>>
>> ./open/src/hotspot/share/runtime/thread.cpp:2857:15: error:
>> 'is_JavaThre
On Tue, 16 Feb 2021 02:45:23 GMT, Chris Plummer wrote:
>> @plummercj Thanks for the review!
>>
>>> These changes look good, but it would be nice to fix OSX too. Fortunately
>>> it should be easier. As part of the fix for
>>> [JDK-8247515](https://bugs.openjdk.java.net/browse/JDK-8247515), I ad
On Mon, 15 Feb 2021 20:10:02 GMT, Chris Plummer wrote:
>> Delete some localrefs to avoid -Xcheck:jni warnings. See CR for details.
>
> Chris Plummer has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fix comment
Marked as reviewed by sgehwolf
On Sat, 13 Feb 2021 21:53:51 GMT, Daniel D. Daugherty
wrote:
>> A minor fix to add a new function:
>>
>> bool Thread::is_JavaThread_protected(const JavaThread* p)
>>
>> that returns true when the target JavaThread* is protected and false
>> otherwise. Update JavaThread::get_thread_name() t
On Sat, 13 Feb 2021 19:05:17 GMT, Chris Plummer wrote:
> See bug description for details. The fix is simple and just a matter of
> moving some code to avoid incorrectly thinking an address is in a .so when it
> is in some other area of VM memory that occurs just after the last .so.
Looks good.
> This PR relates to
> [JDK-8261702](https://bugs.openjdk.java.net/browse/JDK-8261702) ( #2562 )
> When SA creates a DSO object, which is used to represent a shared object file
> (.so), it initializes the "size" to be the size of the shared object file.
> This usually results in the size being t
> This PR relates to
> [JDK-8261702](https://bugs.openjdk.java.net/browse/JDK-8261702) ( #2562 )
> When SA creates a DSO object, which is used to represent a shared object file
> (.so), it initializes the "size" to be the size of the shared object file.
> This usually results in the size being t
45 matches
Mail list logo
