t; [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-gap-between-host-and-gue
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
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_breakpoint_e
c
> 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 only increases
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
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
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
c
> 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 only increases
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:
>>
>> -
c
> 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 only increases
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,
>>> \
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
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
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_breakpoint_e
c
> 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 only increases
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:
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
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
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
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:
>
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
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
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
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
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
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`
>
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
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:
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
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
>
>
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
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,
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
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
> >
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
35 matches
Mail list logo
