Sign In
Manage this list Sign In

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

hotspot-jfr-dev

Thread Start a new thread
Download
Threads by month
  • ----- 2026 -----
  • March
  • February
  • January
  • ----- 2025 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2018 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
hotspot-jfr-dev@openjdk.org

August 2025

  • 20 participants
  • 45 discussions
RFR: 8364427: JFR: Possible resource leak in Recording::getStream
by Erik Gahlin 04 Aug '25

04 Aug '25
Could I have a review of the PR that fixes resource leaks when Recording::getStream is used? Testing: tier1 + test/jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Fix whitespace - Initial Changes: https://git.openjdk.org/jdk/pull/26575/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26575&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364427 Stats: 176 lines in 2 files changed: 160 ins; 6 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/26575.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26575/head:pull/26575 PR: https://git.openjdk.org/jdk/pull/26575
3 7
0 0
RFR: 8364257: JFR: User-defined events and settings with a one-letter name cannot be configured
by Erik Gahlin 04 Aug '25

04 Aug '25
Could I have a review of the PR that fixes a bug with short event or setting names? Instead of adding a new test, I modified an existing test so that it uses an event and setting name with one letter. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/26531/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26531&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364257 Stats: 10 lines in 2 files changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/26531.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26531/head:pull/26531 PR: https://git.openjdk.org/jdk/pull/26531
2 2
0 0
Re: RFR: 8364258: ThreadGroup constant pool serialization is not normalized [v8]
by Markus Grönlund 02 Aug '25

02 Aug '25
> Greetings, > > The following change set normalizes the ThreadGroup constants being serialized to the .jfr binary file. > > It does this in two parts: > > 1. Re-inserts a scavenging scheme to remove stale (unloaded) ThreadGroups; some logic that we used to have in place, but may have been lost as part of the major refactoring around JFR Event Streaming, or even earlier. > 2. Introduces a per-epoch "is_serialized" scheme, building on top of JFR epoch generations. > > Problem manifestation is a very high number of duplicated TGs (jdk.types.ThreadGroup) as part of JFR checkpoints. > > Testing: jdk_jfr > > Thanks > Markus Markus Grönlund has updated the pull request incrementally with one additional commit since the last revision: do not attempt to serialize a null thread group ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26558/files - new: https://git.openjdk.org/jdk/pull/26558/files/d3ae953c..7738eda8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26558.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26558/head:pull/26558 PR: https://git.openjdk.org/jdk/pull/26558
2 1
0 0
Re: RFR: 8364258: ThreadGroup constant pool serialization is not normalized [v7]
by Markus Grönlund 01 Aug '25

01 Aug '25
> Greetings, > > The following change set normalizes the ThreadGroup constants being serialized to the .jfr binary file. > > It does this in two parts: > > 1. Re-inserts a scavenging scheme to remove stale (unloaded) ThreadGroups; some logic that we used to have in place, but may have been lost as part of the major refactoring around JFR Event Streaming, or even earlier. > 2. Introduces a per-epoch "is_serialized" scheme, building on top of JFR epoch generations. > > Problem manifestation is a very high number of duplicated TGs (jdk.types.ThreadGroup) as part of JFR checkpoints. > > Testing: jdk_jfr > > Thanks > Markus Markus Grönlund has updated the pull request incrementally with one additional commit since the last revision: handle no thread groups found ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26558/files - new: https://git.openjdk.org/jdk/pull/26558/files/c73a8f91..d3ae953c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26558.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26558/head:pull/26558 PR: https://git.openjdk.org/jdk/pull/26558
1 0
0 0
Re: RFR: 8364258: ThreadGroup constant pool serialization is not normalized [v6]
by Markus Grönlund 01 Aug '25

01 Aug '25
> Greetings, > > The following change set normalizes the ThreadGroup constants being serialized to the .jfr binary file. > > It does this in two parts: > > 1. Re-inserts a scavenging scheme to remove stale (unloaded) ThreadGroups; some logic that we used to have in place, but may have been lost as part of the major refactoring around JFR Event Streaming, or even earlier. > 2. Introduces a per-epoch "is_serialized" scheme, building on top of JFR epoch generations. > > Problem manifestation is a very high number of duplicated TGs (jdk.types.ThreadGroup) as part of JFR checkpoints. > > Testing: jdk_jfr > > Thanks > Markus Markus Grönlund has updated the pull request incrementally with one additional commit since the last revision: minimal window ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26558/files - new: https://git.openjdk.org/jdk/pull/26558/files/0691e4c5..c73a8f91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26558&range=04-05 Stats: 10 lines in 3 files changed: 1 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26558.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26558/head:pull/26558 PR: https://git.openjdk.org/jdk/pull/26558
2 1
0 0
  • ← Newer
  • 1
  • 2
  • 3
  • 4
  • 5
  • Older →


Terms of Use • License: GPLv2 • Privacy • Trademarks