From thomas.schatzl at oracle.com Tue Jul 30 20:43:00 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 30 Jul 2019 13:43:00 -0700 Subject: Workshop proposal: CMS Removal Timeline Message-ID: Hi all, I would like to propose the following topic for the workshop: Title: CMS Removal Abstract: CMS has been deprecated for a long time now. We at Oracle as maintainers of CMS would like to go forward with actual removal of the CMS collector. Initially by suggesting to disable compilation, followed by removal of source code (the gc/cms directory) and further cleanup of the code. This includes discussion about how and when. Length: short? Biography: Thomas Schatzl has been working on GC for 10+ years and is part of the Oracle Hotspot GC team for 6 years. Thanks, Thomas From thomas.schatzl at oracle.com Tue Jul 30 20:53:19 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 30 Jul 2019 13:53:19 -0700 Subject: Workshop topic: Deprecation of Parallel GC SerialOld Message-ID: Hi all, I would like to propose the following topic for the workshop: Title: Deprecation of Parallel GC SerialOld collector Abstract: Parallel GC has a mode where it uses a single-thread Mark-Sweep algorithm for old generation collection enabled by -XX:+UseParallelGC -XX:-UseParallelOldGC (I think). This mode seems to be very little used, but poses a certain maintenance overhead for testing and when changing functionality in Parallel GC. We would like to discuss usage of this collector mode and deprecation. Length: short? Biography: Thomas Schatzl has been working on GC for 10+ years and has been part of the Oracle Hotspot GC team for 6 years. Thanks, Thomas From thomas.schatzl at oracle.com Tue Jul 30 20:55:01 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 30 Jul 2019 13:55:01 -0700 Subject: Workshop proposal: Deprecation of Parallel GC SerialOld Message-ID: <594f4a6b-eb9f-07cd-b69c-72dea0da0158@oracle.com> (Fixing subject) Hi all, I would like to propose the following topic for the workshop: Title: Deprecation of Parallel GC SerialOld collector Abstract: Parallel GC has a mode where it uses a single-thread Mark-Sweep algorithm for old generation collection enabled by -XX:+UseParallelGC -XX:-UseParallelOldGC (I think). This mode seems to be very little used, but poses a certain maintenance overhead for testing and when changing functionality in Parallel GC. We would like to discuss usage of this collector mode and deprecation. Length: short? Biography: Thomas Schatzl has been working on GC for 10+ years and has been part of the Oracle Hotspot GC team for 6 years. Thanks, Thomas From thomas.schatzl at oracle.com Tue Jul 30 21:08:14 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 30 Jul 2019 14:08:14 -0700 Subject: Workshop proposal: GC contributions sync-up Message-ID: <94a75ab1-5840-2f75-c65b-81ba9df3697e@oracle.com> Hi all, I would like to propose the following topic for the workshop: Title: GC contributions sync-up Abstract: We in the Oracle GC team would like to take the opportunity to sync up with current and potential contributors attending OCW to the GC component of the JVM. One goal is to get an overview of what is being worked on if people are interested in talking about them; another to give attendees the opportunity to propose contributions and get (initial?) feedback for them. Length: medium, depending on participation? Biography: Thomas Schatzl has been working on GC for 10+ years and is part of the Oracle Hotspot GC team for 6 years. Thanks, Thomas From stuart.marks at oracle.com Tue Jul 30 23:32:22 2019 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 30 Jul 2019 16:32:22 -0700 Subject: Workshop proposal: Using Serviceability Mechanisms from java.base Message-ID: <6d8661bc-82e5-4b6b-efa4-d9b794dea430@oracle.com> A few interesting things have happened after Java 8 regarding serviceability mechanisms. 1. System.Logger was introduced as a public API. 2. JFR was open sourced. 3. Some JFR support infrastructure was added to java.base. These are significant because they allow log messages and JFR events to be emitted from the java.base module. In the case of logging, it's possible to unify JDK system logging from java.base with application logging, by redirecting SystemLogger to the logging back-end of choice. The discussion topic is: now that these mechanisms are available, what things in in java.base should use them? We should also consider making more use of MXBeans, which are thus far underutilized. Length: long Bio: Stuart Marks is a core libraries engineer in the Oracle JDK group.