On Tue, 10 May 2022 04:00:29 GMT, Ioi Lam wrote:
> The `mode` parameter for ` jdk.internal.perf.Perf.attach()` has never
> supported the value `"rw"` since the source code was imported to the openjdk
> repo more than 15 years ago. In fact HotSpot throws
> `IllegalArgumentException` when such
On Tue, 22 Mar 2022 21:19:20 GMT, Kevin Walls wrote:
> There are no uses of jdk/internal/agent/spi/AgentProvider, since the SNMP
> agent was removed ( 8071367 ): this class should be removed. It is not a
> public interface.
>
> Remove
>
On Thu, 4 Nov 2021 02:15:45 GMT, Ioi Lam wrote:
>> LocalVmManager and PerfDataFile have APIs that are supposed to look for VMs
>> owned by a specific user. No one uses these APIs, and they don't work anyway.
>>
>> The current code is very confusing to look at. Since we're likely to change
>>
On Tue, 10 Aug 2021 05:08:54 GMT, Sergey Bylokhov wrote:
> This is the continuation of JDK-8233884 and JDK-8271456. This change affects
> fewer cases so I fix all "java." modules at once.
>
> In many places standard charsets are looked up via their names, for example:
>
On Tue, 23 Mar 2021 21:43:47 GMT, Alex Blewitt
wrote:
> 8264087: Use the blessed modifier order in jdk.jconsole
Marked as reviewed by redestad (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3164
On Fri, 19 Mar 2021 17:13:58 GMT, Alex Blewitt
wrote:
>> As with #2993 changing the order of `final static` to `static final` for the
>> `java.management`, `java.management.rmi` and `java.naming` modules.
>
> Alex Blewitt has updated the pull request incrementally with one additional
> commit
On Thu, 18 Mar 2021 18:26:20 GMT, Alex Blewitt
wrote:
> As with #2993 changing the order of `final static` to `static final` for the
> `java.management`, `java.management.rmi` and `java.naming` modules.
Overall good - found a few cases where the private modifier is in the wrong
place that
On Fri, 19 Mar 2021 13:08:24 GMT, Alex Blewitt
wrote:
>> Created the subtask https://bugs.openjdk.java.net/browse/JDK-8263855 for
>> this along with an umbrella RFE.
>
> Thanks @cl4es -- do I need to update the git commit message as well, or is
> updating the title of the PR sufficient? I
On Fri, 19 Mar 2021 10:20:39 GMT, Alex Blewitt
wrote:
>> Would someone mind creating a bug for me? In addition, if it would help, we
>> could create a parent bug for applying cleanups and associate #2993 and
>> #2991.
>
> @cl4es would you mind creating a parent task of something like "Source
On Tue, 26 Jan 2021 19:34:35 GMT, Claes Redestad wrote:
> Simplify and desugar the static initialization of PlatformMBeanFinder.
>
> While arguably making the code easier to comprehend, this saves 5-6ms on
> startup in various applications such as the spring-petclinic.
This pull
On Tue, 26 Jan 2021 21:26:32 GMT, Mandy Chung wrote:
>> Simplify and desugar the static initialization of PlatformMBeanFinder.
>>
>> While arguably making the code easier to comprehend, this saves 5-6ms on
>> startup in various applications such as the spring-petclinic.
>
> Looks fine.
Simplify and desugar the static initialization of PlatformMBeanFinder.
While arguably making the code easier to comprehend, this saves 5-6ms on
startup in various applications such as the spring-petclinic.
-
Commit messages:
- Simplify PlatformMBeanFinder
Changes:
On Tue, 17 Nov 2020 12:53:48 GMT, Claes Redestad wrote:
> This moves the mirroring of vmSymbols in ciSymbols to a separate file,
> ciSymbols.hpp, to reduce includes throughout hotspot (and clean up the
> ciSymbol namespace). In a few places code is moved from .hpp to .cpp to
>
otal includes from 276949 to 276332
Claes Redestad has updated the pull request incrementally with one additional
commit since the last revision:
ciMethod needs classfile/vmIntrinsics.hpp after 8252505
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/1256/fi
otal includes from 276949 to 276332
Claes Redestad has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 13 commits:
- Merge branch 'master' into ciSymbols
- @iklam reviews, additional cleanup
- remote merge
- Prepare for 1237 changes
This moves the mirroring of vmSymbols in ciSymbols to a separate file,
ciSymbols.hpp, to reduce includes throughout hotspot (and clean up the ciSymbol
namespace). In a few places code is moved from .hpp to .cpp to facilitate this.
With PCH disabled, this reduces total includes from 276949 to
On Fri, 20 Nov 2020 12:19:48 GMT, Claes Redestad wrote:
> A few data structure in the ci allocate unconditionally created
> GrowableArrays out-of-line, have fields that are newer updated/read, or are
> unnecessarily cached. By cleaning this up we can slightly reduce memory used
On Fri, 20 Nov 2020 22:51:23 GMT, Chris Plummer wrote:
>> A few data structure in the ci allocate unconditionally created
>> GrowableArrays out-of-line, have fields that are newer updated/read, or are
>> unnecessarily cached. By cleaning this up we can slightly reduce memory used
>> for JIT
On Fri, 20 Nov 2020 22:21:04 GMT, Chris Plummer wrote:
>> A few data structure in the ci allocate unconditionally created
>> GrowableArrays out-of-line, have fields that are newer updated/read, or are
>> unnecessarily cached. By cleaning this up we can slightly reduce memory used
>> for JIT
A few data structure in the ci allocate unconditionally created GrowableArrays
out-of-line, have fields that are newer updated/read, or are unnecessarily
cached. By cleaning this up we can slightly reduce memory used for JIT
compilations while slightly speeding them up.
-
Commit
On Tue, 17 Nov 2020 18:20:17 GMT, Thomas Schatzl wrote:
>> Hi all,
>>
>> can I have reviews for this change that changes the way how archive
>> regions are managed in general and specifically by the G1 collector, fixing
>> the crashes caused by adding the module graph into the archive in
On Tue, 17 Nov 2020 10:55:19 GMT, Thomas Schatzl wrote:
>> Hi all,
>>
>> can I have reviews for this change that changes the way how archive
>> regions are managed in general and specifically by the G1 collector, fixing
>> the crashes caused by adding the module graph into the archive in
On Mon, 9 Nov 2020 15:43:09 GMT, Frederic Parain wrote:
> Please review this small cleanup code, removing the now unused allocation
> type from the fieldInfo structure.
>
> Tested with Mach5, tiers 1 to 3 and locally by running
> test/hotspot/jtreg/serviceability/sa tests.
>
> Thank you,
>
On Fri, 6 Nov 2020 14:30:14 GMT, Coleen Phillimore wrote:
>> Apply patch suggested by @cl4es in the bug report. Passes
>> linux-x86-open,linux-x64-open,linux-s390x-open,linux-arm32-debug,linux-ppc64le-debug
>> builds with this patch, and tier1.
>>
>> thanks,
>> Coleen
>
> Coleen Phillimore
On Fri, 6 Nov 2020 13:28:12 GMT, Coleen Phillimore wrote:
>> Apply patch suggested by @cl4es in the bug report. Passes
>> linux-x86-open,linux-x64-open,linux-s390x-open,linux-arm32-debug,linux-ppc64le-debug
>> builds with this patch, and tier1.
>>
>> thanks,
>> Coleen
>
> Coleen Phillimore
On Fri, 6 Nov 2020 11:58:04 GMT, Coleen Phillimore wrote:
>> The concern is when it is less than 100ms.
>
> unsigned millisecs[] = { 2, 20, 200, 1000 };
> get_time_stamp(millisecs[i], buf, sizeof(buf));
>
> gets:
>
> timestamp 06.11.2020 06:56:08.002 EST
> timestamp 06.11.2020 06:56:08.020
On Thu, 5 Nov 2020 22:11:44 GMT, David Holmes wrote:
>> Coleen Phillimore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Use Thomas's fix instead.
>
> src/jdk.jdwp.agent/share/native/libjdwp/log_messages.c line 82:
>
>> 80:
On Thu, 5 Nov 2020 20:30:05 GMT, Coleen Phillimore wrote:
>> Apply patch suggested by @cl4es in the bug report. Passes
>> linux-x86-open,linux-x64-open,linux-s390x-open,linux-arm32-debug,linux-ppc64le-debug
>> builds with this patch, and tier1.
>>
>> thanks,
>> Coleen
>
> Coleen Phillimore
On Thu, 5 Nov 2020 18:35:52 GMT, Thomas Stuefe wrote:
> ... so the problem would be that the compiler does not believe us that
> millisecs will be always <1000. And there is no way to truncate output for
> numerical format specifiers.
Interesting, and a reasonable explanation. Odd this
On Thu, 5 Nov 2020 17:26:50 GMT, Chris Plummer wrote:
> I don't think this is the case. If you assume the arguments are not null
> terminated, then there is no limit to how long the string could be, where-as
> the error messages are very specific with the (incorrectly) calculated range
> of
On Thu, 5 Nov 2020 00:37:15 GMT, Coleen Phillimore wrote:
> Apply patch suggested by @cl4es in the bug report. Passes
> linux-x86-open,linux-x64-open,linux-s390x-open,linux-arm32-debug,linux-ppc64le-debug
> builds with this patch, and tier1.
>
> thanks,
> Coleen
While you might want to wait
On Thu, 5 Nov 2020 09:12:54 GMT, Aleksey Shipilev wrote:
>>> Where did the magic numbers in
>>>
>>> "%.19s.%.3d %.50s"
>>>
>>> come from?
>>
>> The first argument is a char[DT_SIZE], which is MAXLEN_DT+1, which is 20.
>> The +1 is probably for a null. The 3rd argument is char[TZ_SIZE], which
On Fri, 30 Oct 2020 17:39:05 GMT, Ioi Lam wrote:
>> Claes Redestad 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 contains 11 addi
On Tue, 27 Oct 2020 14:00:34 GMT, Claes Redestad wrote:
> The static `ThreadHeapSampler::_log_table` is currently initialized on JVM
> bootstrap to an overhead of ~67k instructions (linux-x64). By turning the
> initialization into a constexpr, we can precalculate the helper table at
On Thu, 29 Oct 2020 20:04:11 GMT, Ioi Lam wrote:
>> Claes Redestad has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Add explicit include of logging
>> - Add const, fix copyright
>
> Marked as revi
secs
>
> I've verified that this refactoring does not affect performance in this naive
> setup.
>
> [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1
Claes Redestad has updated the pull request with a new target base due to a
merge or a rebase. Th
secs
>
> I've verified that this refactoring does not affect performance in this naive
> setup.
>
> [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1
Claes Redestad has updated the pull request incrementally with two additional
commits since the las
On Thu, 29 Oct 2020 08:56:13 GMT, Lin Zang wrote:
>> The static `ThreadHeapSampler::_log_table` is currently initialized on JVM
>> bootstrap to an overhead of ~67k instructions (linux-x64). By turning the
>> initialization into a constexpr, we can precalculate the helper table at
>> compile
secs
>
> I've verified that this refactoring does not affect performance in this naive
> setup.
>
> [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1
Claes Redestad has updated the pull request incrementally with one additional
commit since the last r
On Tue, 27 Oct 2020 23:08:21 GMT, Ioi Lam wrote:
>> Claes Redestad 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 contains three addi
secs
>
> I've verified that this refactoring does not affect performance in this naive
> setup.
>
> [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1
Claes Redestad has updated the pull request with a new target base due to a
merge or a rebase. Th
On Tue, 27 Oct 2020 23:08:13 GMT, Ioi Lam wrote:
>> Claes Redestad 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 contains three addi
secs
>
> I've verified that this refactoring does not affect performance in this naive
> setup.
>
> [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1
Claes Redestad has updated the pull request with a new target base due to a
merge or a rebase. Th
secs
>
> I've verified that this refactoring does not affect performance in this naive
> setup.
>
> [1] https://github.com/openjdk/jdk/compare/master...cl4es:log2_micro?expand=1
Claes Redestad has updated the pull request with a new target base due to a
merge or a rebase. Th
*From:* serguei.spit...@oracle.com
*Sent:* Tuesday, August 25, 2020 8:38 AM
*To:* jiefu(傅杰); serviceability-dev@openjdk.java.net; Claes Redestad
*Subject:* Re: 8251155: HostIdentifier fails to canonicalize hostnames
starting with digits(Internet mail)
Hi Jie,
I'm okay with the fix
Hi,
not sure I do, but a quick read of the relevant RFC suggests that since
a URI scheme (protocol) must start with a letter[1] it seems safe to
assume the string must be of the form hostname or hostname:port if the
first character in the string is a digit.
/Claes
[1]
On 2020-06-17 05:19, Ioi Lam wrote:
On 6/16/20 6:20 PM, David Holmes wrote:
Hi Ioi,
On 17/06/2020 6:14 am, Ioi Lam wrote:
https://bugs.openjdk.java.net/browse/JDK-8246019
http://cr.openjdk.java.net/~iklam/jdk16/8246019-avoid-PerfClassTraceTime.v01/
PerfClassTraceTime is (a rarely
On 2020-03-27 03:18, David Holmes wrote:
Yeah they confuse me. Which makes it hard to see what impact your
changes may have.
This patch removes some internal, unused code on the JVM end that is not
observable via jstat / jvmstat. I'm happy if serviceability can weigh in
though.
The other
On 2020-03-27 00:36, David Holmes wrote:
Okay so can you change the bug synopsis and description to cover this
more general cleanup and tuneup please.
I filed an addendum RFE and will add this RFE bug id to the single
changeset push:
https://bugs.openjdk.java.net/browse/JDK-8241705
On 2019-03-25 23:10, serguei.spit...@oracle.com wrote:
Hi Claes,
It looks good.
I've targeted the bug to 13.
Thanks, Serguei!
/Claes
On 2019-03-25 17:51, Jiangli Zhou wrote:
Hi Claes,
The updated change also matches with the state of shared klasses, so it
seems good to me.
Thanks!
Sorry for the delay.
No worries, I was on vacation last week. :-)
It's probably a good idea to add
an assert to make sure
[Adding hotspot-runtime-dev]
On 2019-03-15 17:26, Claes Redestad wrote:
Hi,
I ran into a few additional test issues, one exposing a crash in jmap
-histo:live in a test that seems to have been problem listed when I
ran tests earlier.
Also filtering out archived-but-not-yet-loaded classes
Ping.
Still passes tests and is necessary to unblock work to more aggressively
archive invariant heap graphs.
/Claes
On 2019-03-15 17:26, Claes Redestad wrote:
Hi,
I ran into a few additional test issues, one exposing a crash in jmap
-histo:live in a test that seems to have been problem
Hi,
I ran into a few additional test issues, one exposing a crash in jmap
-histo:live in a test that seems to have been problem listed when I
ran tests earlier.
Also filtering out archived-but-not-yet-loaded classes in
KlassInfoBucket::lookup makes tests exercising jmap etc work as intended
in
Hi Jc,
On 2019-03-15 15:55, Jean Christophe Beyler wrote:
Hi Claes,
Looks good to me.
thanks!
/Claes
For those who would want to see the patch change done
in the serviceability-agent:
http://hg.openjdk.java.net/jdk/jdk/rev/91f06b86c0da
Hi,
to allow for archiving objects in CDS that might not be loaded (e.g.,
JDK-8214712), we need to ignore objects at heap dump time that haven't
actually been loaded. This patch fixes the VM heapDumper implementation,
and is a mirror of a fix already done in the serviceability-agent heap
Hi Jini,
changes looks good, and thanks for verifying your fix unblock 8214712!
/Claes
On 2019-02-24 06:01, Jini George wrote:
Thank you very much, Jiangli! Yes, I did test
open/test/hotspot/jtreg/serviceability/sa/TestHeapDumpForLargeArray.java
after applying the changes from:
Hi,
in my opinion it's way too easy to add flags compared to how hard they
are to get rid of, so I agree with postponing the addition of the flag
until it's requested based on a real need.
Thanks!
/Claes
On 2019-02-20 23:17, serguei.spit...@oracle.com wrote:
Hi Ioi,
Sorry that I missed
Hi,
here's a case that your script seems to miss:
http://cr.openjdk.java.net/%7Ejcbeyler/8213003/webrev.00/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetClassLoaderClasses/clsldrclss002/clsldrclss002.cpp.udiff.html
if (!NSK_JNI_VERIFY(jni, (testedFieldID =
On 2018-04-30 11:33, Alan Bateman wrote:
This looks okay, at least as a short term fix. I agree it's way too
fragile to depend on such classes and needs to stick to classes that
are closer to the area that it tests.
Thanks, Alan!
/Claes
Hi,
ClhsdbJhisto has a hard-coded dependency on an
ImmutableCollections$SetN$1 appearing in the jhisto output, which is
fragile and sometimes break after JDK-8201650. I suggest removing it
from the test:
diff -r 96d4658eb7f2 test/hotspot/jtreg/serviceability/sa/ClhsdbJhisto.java
---
Hi,
it seems destroy() used nullness of _prologue to determine that
the counter has already been destroyed, should this use _destroyed
now?
165 if (_prologue == NULL) return;
/Claes
On 2017-09-26 17:01, Yasumasa Suenaga wrote:
Hi all,
I uploaded new webrev to be adapted to jdk10/hs:
Oops, seems you fixed it, nevermind :-)
/Claes
On 2016-12-19 22:43, Claes Redestad wrote:
Hi,
seems you forgot to remove the code using LIBARCH around line 82
/Claes
On 2016-12-19 22:41, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171468/webrev.00
Hi,
seems you forgot to remove the code using LIBARCH around line 82
/Claes
On 2016-12-19 22:41, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171468/webrev.00/
The test is updated to check the new location of shared libraries. lib/$ARCH
has been removed.
Hi Bengt,
I'm not Serviceability, but you know I can't leave them micro-
optimizations alone! :-)
So, reusing cached arrays could be made to work but would require
some synchronization to keep things thread-safe and tidy[1].
This will complicate the code, especially since there's another
+1
/Claes
On 2016-08-20 20:49, Erik Gahlin wrote:
Hi,
Could I have review of this fix to the event tracing metadata. The patch
touches many files, but it doesn't change the control flow, only class
and field names.
Webrev:
http://cr.openjdk.java.net/~egahlin/8164523/
Bug:
Hi,
please review this patch to clean up and make
sun.management.HotspotCompilation
behave nice if the VM would decide to no longer expose per-compiler
thread perf counters:
webrev: http://cr.openjdk.java.net/~redestad/jdk9/8134583/webrev.00/
bug:
:
On 27.8.2015 15:14, Claes Redestad wrote:
On 2015-08-27 15:04, Jaroslav Bachorik wrote:
Hi,
On 27.8.2015 14:41, Claes Redestad wrote:
Hi,
please review this patch to clean up and make
sun.management.HotspotCompilation
behave nice if the VM would decide to no longer expose per-compiler
thread
On 2015-08-27 15:04, Jaroslav Bachorik wrote:
Hi,
On 27.8.2015 14:41, Claes Redestad wrote:
Hi,
please review this patch to clean up and make
sun.management.HotspotCompilation
behave nice if the VM would decide to no longer expose per-compiler
thread perf counters:
webrev: http
Hi,
I want to raise the question if there are any known users
of these per-compiler thread perf. counters, or if they
should be removed?
sun.ci.compilerThread.#.compiles
sun.ci.compilerThread.#.method
sun.ci.compilerThread.#.time
sun.ci.compilerThread.#.type
For detailed information about
Hi Jaroslav, thanks for looking at this!
On 2014-12-30 14:43, Jaroslav Bachorik wrote:
While it's good to see the dead code gone I would prefer keeping the
logging code just commented out - the logging code could be useful
when investigating any future failures.
Do you mean all of it, or
On 2014-12-30 18:35, Jaroslav Bachorik wrote:
The affected files are pretty stable so we could remove *all* the
logging related methods. When a necessity arises to have a
configurable logging we would just need to re-introduce it properly.
Right, I'll leave the patch as-is when it comes to
Hi,
some classes in jvmstat/perfdata code contains debug logging code
predating the logging APIs, which
provokes some unnecessary allocation in certain applications.
Since the debug logging can't have been used for quite some time, I
propose to remove it altogether
rather than converting it
73 matches
Mail list logo
