Re: RFR: 8324241: Always record evol_method deps to avoid excessive method flushing [v5]

2024-09-12 Thread Volker Simonis
On Mon, 5 Aug 2024 00:32:40 GMT, leo liang wrote: > Hi there, we are seeing this issue when we run JFR on our services under > load, we see a large spike of CPU after JFR is triggered, which cause 500 > errors in our service. We are currently using corretto-17 in our service. > > Wondering thi

Re: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v2]

2024-07-12 Thread Volker Simonis
On Tue, 9 Jul 2024 12:17:25 GMT, Alan Bateman wrote: >> @AlanBateman would you mind having a quick look at this trivial, >> documentation-only PR and let me know if you're OK with it? >> >> Thank you and best regards, >> Volker > >> @AlanBateman would you mind having a quick look at this trivia

Integrated: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors

2024-07-12 Thread Volker Simonis
On Wed, 3 Jul 2024 16:14:31 GMT, Volker Simonis wrote: > Since Java 5 the `java.lang.instrument` package provides services that allow > Java programming language agents to instrument (i.e. modify the bytecode) of > programs running on the Java Virtual Machine. The `java.lang.i

Re: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v3]

2024-07-10 Thread Volker Simonis
On Wed, 10 Jul 2024 12:53:46 GMT, Alan Bateman wrote: >> Volker Simonis has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Addressed @AlanBateman's suggestions and updated copyright year > > src/java

Re: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v4]

2024-07-10 Thread Volker Simonis
get will be loaded unmodified > (see `ClassFileTransformer` API spec: "*throwing an exception has the same > effect as returning null*"). But unfortunately, it can also have a subtle but > at the same time much more far-reaching consequence. If the > `ClassCircularityE

Re: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v2]

2024-07-09 Thread Volker Simonis
On Tue, 9 Jul 2024 12:17:25 GMT, Alan Bateman wrote: >> @AlanBateman would you mind having a quick look at this trivial, >> documentation-only PR and let me know if you're OK with it? >> >> Thank you and best regards, >> Volker > >> @AlanBateman would you mind having a quick look at this trivia

Re: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v3]

2024-07-09 Thread Volker Simonis
get will be loaded unmodified > (see `ClassFileTransformer` API spec: "*throwing an exception has the same > effect as returning null*"). But unfortunately, it can also have a subtle but > at the same time much more far-reaching consequence. If the > `ClassCircularityE

Re: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v2]

2024-07-05 Thread Volker Simonis
On Thu, 4 Jul 2024 10:49:47 GMT, Volker Simonis wrote: >> Since Java 5 the `java.lang.instrument` package provides services that allow >> Java programming language agents to instrument (i.e. modify the bytecode) of >> programs running on the Java Virtual Machine. The `ja

Re: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v2]

2024-07-04 Thread Volker Simonis
On Thu, 4 Jul 2024 10:49:47 GMT, Volker Simonis wrote: >> Since Java 5 the `java.lang.instrument` package provides services that allow >> Java programming language agents to instrument (i.e. modify the bytecode) of >> programs running on the Java Virtual Machine. The `ja

Re: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors [v2]

2024-07-04 Thread Volker Simonis
get will be loaded unmodified > (see `ClassFileTransformer` API spec: "*throwing an exception has the same > effect as returning null*"). But unfortunately, it can also have a subtle but > at the same time much more far-reaching consequence. If the > `ClassCircularityE

Re: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors

2024-07-04 Thread Volker Simonis
On Wed, 3 Jul 2024 19:44:36 GMT, Chen Liang wrote: >> Since Java 5 the `java.lang.instrument` package provides services that allow >> Java programming language agents to instrument (i.e. modify the bytecode) of >> programs running on the Java Virtual Machine. The `java.lang.instrument` >> func

Re: RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors

2024-07-04 Thread Volker Simonis
On Thu, 4 Jul 2024 06:14:35 GMT, Thomas Stuefe wrote: >> Since Java 5 the `java.lang.instrument` package provides services that allow >> Java programming language agents to instrument (i.e. modify the bytecode) of >> programs running on the Java Virtual Machine. The `java.lang.instrument` >> f

RFR: 8335619: Add an @apiNote to j.l.i.ClassFileTransformer to warn about recursive class loading and ClassCircularityErrors

2024-07-03 Thread Volker Simonis
Since Java 5 the `java.lang.instrument` package provides services that allow Java programming language agents to instrument (i.e. modify the bytecode) of programs running on the Java Virtual Machine. The `java.lang.instrument` functionality is based and implemented on top of the native Java Virt

Re: RFR: 8329204: Diagnostic command for zeroing unused parts of the heap [v2]

2024-03-27 Thread Volker Simonis
[1]: https://criu.org > [2]: > https://github.com/firecracker-microvm/firecracker/blob/main/docs/snapshotting/snapshot-support.md > [3]: https://man7.org/linux/man-pages/man1/fallocate.1.html > [4]: > https://fosdem.org/2024/schedule/event/fosdem-2024-3454-zeroing-and-the-semantic

RFR: 8329204: Diagnostic command for zeroing unused parts of the heap

2024-03-27 Thread Volker Simonis
Diagnostic command for zeroing unused parts of the heap I propose to add a new diagnostic command `System.zero_unused_memory` which zeros out all unused parts of the heap. The name of the command is intentionally GC/heap agnostic because in the future it might be extended to also zero unused pa

Integrated: 8324241: Always record evol_method deps to avoid excessive method flushing

2024-01-26 Thread Volker Simonis
On Sat, 20 Jan 2024 19:48:07 GMT, Volker Simonis wrote: > Currently we don't record dependencies on redefined methods (i.e. > `evol_method` dependencies) in JIT compiled methods if none of the > `can_redefine_classes`, `can_retransform_classes` or > `can_generate_breakpo

Re: RFR: 8324241: Always record evol_method deps to avoid excessive method flushing [v5]

2024-01-26 Thread Volker Simonis
Spring Petclinic > application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions > -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 > with C2) resulting in an aggregated nmethod size of around ~40bm. > Additionally recording `evol_method` dependencies

Re: RFR: 8324241: Always record evol_method deps to avoid excessive method flushing [v4]

2024-01-26 Thread Volker Simonis
On Fri, 26 Jan 2024 09:36:49 GMT, Aleksey Shipilev wrote: >> Volker Simonis has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Made the flag experimental and added an assertion to >> set_can_hotswap_or_pos

Re: RFR: 8324241: Always record evol_method deps to avoid excessive method flushing [v4]

2024-01-26 Thread Volker Simonis
On Fri, 26 Jan 2024 09:33:17 GMT, Aleksey Shipilev wrote: >> Volker Simonis has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Made the flag experimental and added an assertion to >> set_can_hotswap_or_pos

Re: RFR: 8324241: Always record evol_method deps to avoid excessive method flushing [v3]

2024-01-25 Thread Volker Simonis
On Tue, 23 Jan 2024 19:57:14 GMT, Vladimir Ivanov wrote: >> Volker Simonis has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Updated option description and assertion based on review feedback > > I support kee

Re: RFR: 8324241: Always record evol_method deps to avoid excessive method flushing [v4]

2024-01-24 Thread Volker Simonis
Spring Petclinic > application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions > -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 > with C2) resulting in an aggregated nmethod size of around ~40bm. > Additionally recording `evol_method` dependencies

Re: RFR: 8324241: Always record evol_method deps to avoid excessive method flushing [v2]

2024-01-24 Thread Volker Simonis
On Tue, 23 Jan 2024 23:36:37 GMT, Dean Long wrote: >> A good question, but after deep digging (it took me quite some time to >> figure this out myself :) I don't think that >> `can_hotswap_or_post_breakpoint`/`all_dependencies_are_recorded` can ever be >> reset. Here's how it works: >> >> - t

Re: RFR: 8324241: Always record evol_method deps to avoid excessive method flushing [v3]

2024-01-23 Thread Volker Simonis
Spring Petclinic > application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions > -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 > with C2) resulting in an aggregated nmethod size of around ~40bm. > Additionally recording `evol_method` dependencies

Re: RFR: 8324241: Always record evol_method deps to avoid excessive method flushing [v2]

2024-01-23 Thread Volker Simonis
On Mon, 22 Jan 2024 23:38:40 GMT, John R Rose wrote: >> src/hotspot/share/runtime/globals.hpp line 2014: >> >>> 2012: >>> \ >>> 2013: product(bool, AlwaysRecordEvolDependencies, true, DIAGNOSTIC, >>> \ >>

Re: RFR: 8324241: Always record evol_method deps to avoid excessive method flushing [v2]

2024-01-23 Thread Volker Simonis
On Tue, 23 Jan 2024 10:06:34 GMT, Aleksey Shipilev wrote: >> Volker Simonis has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Guard the feature with a diagnostic option and update the comments in the >> co

Re: RFR: 8324241: Always record evol_method deps to avoid excessive method flushing [v2]

2024-01-23 Thread Volker Simonis
On Tue, 23 Jan 2024 03:31:59 GMT, Dean Long wrote: >> Volker Simonis has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Guard the feature with a diagnostic option and update the comments in the >> code

Re: RFR: 8324241: Always record evol_method deps to avoid excessive method flushing

2024-01-22 Thread Volker Simonis
On Sat, 20 Jan 2024 19:48:07 GMT, Volker Simonis wrote: > Currently we don't record dependencies on redefined methods (i.e. > `evol_method` dependencies) in JIT compiled methods if none of the > `can_redefine_classes`, `can_retransform_classes` or > `can_generate_breakpo

Re: RFR: 8324241: Always record evol_method deps to avoid excessive method flushing [v2]

2024-01-22 Thread Volker Simonis
Spring Petclinic > application started with `-Xbatch -XX:+UnlockDiagnosticVMOptions > -XX:+LogCompilation` compiles about ~11500 methods (~9000 with C1 and ~2500 > with C2) resulting in an aggregated nmethod size of around ~40bm. > Additionally recording `evol_method` dependencies

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v53]

2023-12-01 Thread Volker Simonis
On Thu, 30 Nov 2023 09:46:03 GMT, Stefan Johansson wrote: >> Jonathan Joo has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Add missing include > > src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 905: > >> 903: gc_threads_do

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v37]

2023-11-02 Thread Volker Simonis
On Wed, 1 Nov 2023 23:56:25 GMT, Jonathan Joo wrote: >> 8315149: Add hsperf counters for CPU time of internal GC threads > > Jonathan Joo has updated the pull request incrementally with two additional > commits since the last revision: > > - revert gitignore change > - Attempt to fix broken t

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v32]

2023-10-26 Thread Volker Simonis
On Thu, 26 Oct 2023 12:49:21 GMT, Albert Mingkun Yang wrote: >> Jonathan Joo has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Use 64-bit atomic add for incrementing counters > > src/hotspot/share/gc/g1/g1ConcurrentMarkThread.cpp line 138:

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v32]

2023-10-26 Thread Volker Simonis
On Wed, 25 Oct 2023 20:37:46 GMT, Jonathan Joo wrote: >> 8315149: Add hsperf counters for CPU time of internal GC threads > > Jonathan Joo has updated the pull request incrementally with one additional > commit since the last revision: > > Use 64-bit atomic add for incrementing counters Than

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v27]

2023-10-25 Thread Volker Simonis
On Thu, 5 Oct 2023 03:04:39 GMT, Jonathan Joo wrote: >> Jonathan Joo has updated the pull request incrementally with one additional >> commit since the last revision: >> >> add comment and change if defined to ifdef > > Resolved comments and sanity checks pass on all builds: > https://github

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v30]

2023-10-19 Thread Volker Simonis
On Fri, 13 Oct 2023 01:38:13 GMT, Jonathan Joo wrote: >> 8315149: Add hsperf counters for CPU time of internal GC threads > > Jonathan Joo has updated the pull request incrementally with one additional > commit since the last revision: > > Add call to publish in parallel gc and update counter

Re: RFR: 8315149: Add hsperf counters for CPU time of internal GC threads [v24]

2023-09-26 Thread Volker Simonis
On Tue, 19 Sep 2023 22:48:16 GMT, Jonathan Joo wrote: >> 8315149: Add hsperf counters for CPU time of internal GC threads > > Jonathan Joo has updated the pull request incrementally with one additional > commit since the last revision: > > Fix build issues Thanks for your continued work on t

Re: Question on why sun.management MBeans are not exported?

2023-09-06 Thread Volker Simonis
On Wed, Sep 6, 2023 at 3:47 PM Alan Bateman wrote: > > On 06/09/2023 14:02, Volker Simonis wrote: > > : > > > > I wonder why "sun.management" was encapsulated in the first place? I > > understand that it is not an "officially supported" API, but

Question on why sun.management MBeans are not exported?

2023-09-06 Thread Volker Simonis
Hi, I recently looked for an easy way to get the CPU time spent by JIT-compiler and GC threads in Java (e.g exported by IBM J9's JvmCpuMonitorMXBean [0]). An easy way to achieve this is in OpenJDK is by using the "sun.management.HotspotInternal" MBean which exports the "sun.management:type=Hotspot

Re: RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v23]

2023-05-30 Thread Volker Simonis
On Fri, 26 May 2023 16:35:32 GMT, Paul Hohensee wrote: >> The tests and all apps might thank us for keeping last known value, and not >> returning anything lower, ensuring montonicity. > > Fixed using a high water mark. A simple fix for guaranteeing monotonicity, would be to add another field (

Re: RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v11]

2023-05-15 Thread Volker Simonis
On Tue, 9 May 2023 01:23:23 GMT, David Holmes wrote: >> Paul Hohensee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Implement 32-bit linux Atomic::add() > > Also note that the current placement of the `incr_exited_allocated_bytes` > s

Re: New candidate JEP: 451: Prepare to Disallow the Dynamic Loading of Agents

2023-05-10 Thread Volker Simonis
On Mon, May 8, 2023 at 9:17 PM Mark Reinhold wrote: > > https://openjdk.org/jeps/451 > > Summary: Issue warnings when agents are loaded dynamically into a > running JVM. These warnings aim to prepare users for a future release > which disallows the dynamic loading of agents by default in ord

Re: RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v12]

2023-05-09 Thread Volker Simonis
On Tue, 9 May 2023 01:21:14 GMT, David Holmes wrote: >> Paul Hohensee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Implement 32-bit linux Atomic::add() > > src/hotspot/share/services/threadService.cpp line 224: > >> 222: >> 223: d

Re: RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v5]

2023-05-09 Thread Volker Simonis
On Tue, 9 May 2023 01:02:32 GMT, David Holmes wrote: >> If the `thread` is no longer on any ThreadsList, then it is not safe to >> access `thread`. > > @dcubed-ojdk This is the current thread acting on itself This method (i.e. `ThreadService::remove_thread()`) is called from `Threads::remove()

Re: RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM [v5]

2023-05-08 Thread Volker Simonis
On Mon, 8 May 2023 02:10:48 GMT, David Holmes wrote: >> Paul Hohensee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8304074: [JMX] Add an approximation of total bytes allocated on the Java >> heap by the JVM > > src/hotspot/share/serv

Re: RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM

2023-05-05 Thread Volker Simonis
On Fri, 5 May 2023 06:45:10 GMT, David Holmes wrote: >> Please review this addition to com.sun.management.ThreadMXBean that returns >> the total number of bytes allocated on the Java heap since JVM launch by >> both terminated and live threads. >> >> Because this PR adds a new interface method

Re: RFR: 8304074: [JMX] Add an approximation of total bytes allocated on the Java heap by the JVM

2023-05-05 Thread Volker Simonis
On Thu, 4 May 2023 19:54:57 GMT, Paul Hohensee wrote: > Please review this addition to com.sun.management.ThreadMXBean that returns > the total number of bytes allocated on the Java heap since JVM launch by both > terminated and live threads. > > Because this PR adds a new interface method, I'

Re: JEP draft: Disallow the Dynamic Loading of Agents by Default

2023-04-28 Thread Volker Simonis
On Wed, Apr 19, 2023 at 12:29 AM Ron Pressler wrote: > > Hi. > > Following last month’s email about changing the default of > EnableDynamicAgentLoading [1], we’ve now published two JEP drafts. > > The first is an informational JEP describing what integrity is and why we > need it, > and motivates

Re: [External] : Re: Disallowing the dynamic loading of agents by default

2023-03-27 Thread Volker Simonis
On Mon, Mar 27, 2023 at 12:32 PM Ron Pressler wrote: > > Hi Andrew! > > > On 24 Mar 2023, at 17:21, Andrew Dinn wrote: > > > > Hi Ron, > > > > Thank you for providing a heads up on the proposed JEP. The Red Hat Java > > team have been discussing this proposal. We have reviewed the original > >

Re: [External] : Re: Disallowing the dynamic loading of agents by default

2023-03-20 Thread Volker Simonis
Hi Ron, I'm still missing convincing technical arguments for disallowing dynamic loading of agents. If the argument is security then I can only agree with previous answers in that an attacker needs local access with the same credentials like the attacked JVM. But once he has that, all bets are of