Re: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java are not reproducable

Hi Jie, The new test looks good, thanks. About the GenerateJLIClassesPlugin change, I mentioned the alternative way to implement it.   I think you can avoid the resorting in the case when the trace config file is present.   I'd like to see the initialize method builds a sorted speciesTypes,

Re: RFR: 8226297: Dual-pivot quicksort improvements

Hi, I've created a webrev of the latest test changes that Vladimir sent me: http://cr.openjdk.java.net/~bchristi/8226297/webrev09-testUpdate/ (I also created an incremental webrev[1] along the way, in case that's helpful to anyone). I have just a few comments:

Re: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes

Hi Martin, This is going a bit OT I think ... On 24/10/2019 1:24 pm, Martin Buchholz wrote: On Tue, Oct 22, 2019 at 3:58 PM David Holmes > wrote: Perhaps one aspect of the class loading/resolution/initialization process that can lead to confusion

Re: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java are not reproducable

Hi Mandy, Updated: http://cr.openjdk.java.net/~jiefu/8232864/webrev.01/ The JLinkReproducibleTest had been extended to test the case when the default trace file is not present. If you're OK with the change, could you please sponsor it? Thanks a lot. Best regards, Jie On 2019/10/24 上午2:37,

Re: RFR: JDK-8232773: ClassLoading Debug Output for Specific Classes

On Tue, Oct 22, 2019 at 3:58 PM David Holmes wrote: > > Perhaps one aspect of the class loading/resolution/initialization > process that can lead to confusion here is that if a class fails to > execute its static initialization then it is marked as Erroneous and all > subsequent attempts to use

Re: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem leads to a CRC failure in the generated jar file

Hello Christoph, Thank you for the very detailed review. Comments inline. On 24/10/19 3:00 AM, Langer, Christoph wrote: > > For the path to the test file, you could simply do: final Path jarPath = > Paths.get("zipfs-crc-test.jar"); > The test is run in the scratch directory of jtreg, so no

Re: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem leads to a CRC failure in the generated jar file

Thank you Lance. -Jaikiran On 24/10/19 1:17 AM, Lance Andersen wrote: > Hi Jaikiran, > > I will take a look and once we are good with the review, I can sponsor it. > > Best > Lance >> On Oct 23, 2019, at 7:24 AM, Jaikiran Pai > > wrote: >> >> Can I please get a

RFR: JDK-8223323: Adjust jpackage makefiles

Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8223323 [2] http://cr.openjdk.java.net/~asemenyuk/8223323/webrev.00

RFR: JDK-8230612: Debian packaging ignores version and release in custom control file

Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8230612 [2] http://cr.openjdk.java.net/~asemenyuk/8230612/webrev.00

Re: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java are not reproducable

Thanks Mandy for your review and comments. I'll try to construct a reproducer. Thanks. On 2019/10/24 上午2:37, Mandy Chung wrote: On 10/23/19 12:16 AM, Jie Fu wrote: Hi all, JBS: https://bugs.openjdk.java.net/browse/JDK-8232864 Webrev: http://cr.openjdk.java.net/~jiefu/8232864/webrev.00/

Re: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java are not reproducable

Thanks Claes for your review and comments. On 2019/10/23 下午6:49, Claes Redestad wrote: Hi, ideally the build step to generate default_jli_trace.txt should be done independently of where the CDS feature is compiled in, but the fix looks good regardless. /Claes On 2019-10-23 09:16, Jie Fu

Re: 8205132: Remove Thread.countStackFrames()

At least a couple appear to be recently active, though I don't have current access. Maybe an IDE generates boilerplate for proxies and ignores deprecation ? is the speed of the StackWalker approach to counting frames comparable to the current native method ? On Wed, Oct 23, 2019 at 11:57 AM

RE: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem leads to a CRC failure in the generated jar file

Hi Jaikiran, thanks for proposing this patch. I just had a look and think the fix in ZipFileSystem.java is the right thing to do. As for the test: That could be simplified a bit. For the path to the test file, you could simply do: final Path jarPath = Paths.get("zipfs-crc-test.jar"); The test

Re: RFR: JDK-8229871: Improve performance of Method.copy() and leafCopy()

Hi Ogata, I finally managed to find some time to experiment with this. To measure invocation performance I created the following JMH benchmark [1]. It measures the invocation speed of instance and static methods using either: - direct invocation (bytecodes) - invocation via constant Method

Re: RFR 8231451: ZipFileInputStream::skip handling of negative values with STORED entries

On 23/10/2019 19:06, Lance Andersen wrote: On Oct 22, 2019, at 2:37 PM, Alan Bateman > wrote: I assume skip(Long.MAX_VALUE) will cause n+pos to overflow and it will skip backwards rather than to the end. That is correct.  If you prefer it to skip to the end,

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

2019/10/23 12:37:56 -0700, bob.vande...@oracle.com: >> On Oct 23, 2019, at 3:07 PM, mark.reinh...@oracle.com wrote: >> ... >> >> Addendum: To keep things sane for JFR and the serviceability agent, >> I had to propagate this change through to those subsystems. >> >> Relative patch below; original

Re: RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem leads to a CRC failure in the generated jar file

Hi Jaikiran, I will take a look and once we are good with the review, I can sponsor it. Best Lance > On Oct 23, 2019, at 7:24 AM, Jaikiran Pai wrote: > > Can I please get a review and a sponsor for a potential fix for > JDK-8232879[1]? The patch is available as a webrev at [2]. > > What's

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

> On Oct 23, 2019, at 3:07 PM, mark.reinh...@oracle.com wrote: > > 2019/10/22 15:36:28 -0700, mark.reinh...@oracle.com: >> 2019/10/22 12:43:42 -0700, bob.vande...@oracle.com: On Oct 22, 2019, at 3:22 PM, mark.reinh...@oracle.com wrote: 2019/10/22 10:31:55 -0700,

Re: 14 RFR (M) 8232080: jlink plugins for vendor information and run-time options

2019/10/22 15:36:28 -0700, mark.reinh...@oracle.com: > 2019/10/22 12:43:42 -0700, bob.vande...@oracle.com: >>> On Oct 22, 2019, at 3:22 PM, mark.reinh...@oracle.com wrote: >>> 2019/10/22 10:31:55 -0700, bob.vande...@oracle.com: In arguments.cpp, could you use a new JVMFlag to declare options

Re: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java are not reproducable

On 10/23/19 12:16 AM, Jie Fu wrote: Hi all, JBS:    https://bugs.openjdk.java.net/browse/JDK-8232864 Webrev: http://cr.openjdk.java.net/~jiefu/8232864/webrev.00/ speciesTypes, invokerTypes, callSiteTypes and dmhMethods are sorted when the trace config is present (done in readTraceConfig).

Re: RFR (S) 8232168: Fix non wide char canonicalization on Windows

Hi Christoph, The changes look good. I agree that other mentioned items (the JPLIS agent usage and moving the canonicalize function into hotspot) could be done in separate RFEs. thanks, Calvin On 10/23/19 5:57 AM, Langer, Christoph wrote: Hi, I've picked up Ralf's patch and cleaned it up

Re: RFR 8231451: ZipFileInputStream::skip handling of negative values with STORED entries

> On Oct 22, 2019, at 2:37 PM, Alan Bateman wrote: > > On 22/10/2019 18:00, Lance Andersen wrote: >> >> Per your suggestion, I tweaked the patch to move to BOF when the negative >> skip value goes beyond BOF. I updated the release note as well. >> >> webrev can be found at: >>

Re: RFR: JDK-8232723: make the resource file main.wxs over-ridable

Looks good. - Alexey On 10/23/2019 1:29 PM, Andy Herrick wrote: revised test (webrev.03 [4]) as per feedback from Alexey. [4] http://cr.openjdk.java.net/~herrick/8232723/webrev.03 /Andy On 10/23/2019 9:25 AM, Andy Herrick wrote: revised to add test webrev.02 at [3] [3]

Re: RFR: JDK-8232723: make the resource file main.wxs over-ridable

revised test (webrev.03 [4]) as per feedback from Alexey. [4] http://cr.openjdk.java.net/~herrick/8232723/webrev.03 /Andy On 10/23/2019 9:25 AM, Andy Herrick wrote: revised to add test webrev.02 at [3] [3] http://cr.openjdk.java.net/~herrick/8232723/webrev.02 /Andy On 10/22/2019 2:57 PM,

Re: 8205132: Remove Thread.countStackFrames()

On 10/23/19 12:25 AM, Alan Bateman wrote: Thread::countStackFrames has been deprecated for 20+ years and has been marked for-removal since Java SE 9. I'd like to remove it for Java SE 14. It's was never a well-defined method and I've been unable to find anything that uses it. The

Re: RFR: JDK-8232186: Add verification for pkg and dmg tests

looks ok to me /ANdy On 10/22/2019 5:29 PM, Alexander Matveev wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). - Removed --mac-app-store-category. - Added Hello.java test app to support file

Re: 8205132: Remove Thread.countStackFrames()

On 23/10/2019 16:25, seth lytle wrote: With respect to "unable to find anything that uses it", a quick search of the code that I have access to shows some usage, though everything I looked at in any depth is either a test or a proxy, so there will be source code changes required. I've never

Re: 8205132: Remove Thread.countStackFrames()

With respect to "unable to find anything that uses it", a quick search of the code that I have access to shows some usage, though everything I looked at in any depth is either a test or a proxy, so there will be source code changes required. I've never thought about what the right way to handle

Re: 8205132: Remove Thread.countStackFrames()

On 10/23/19 3:25 AM, Alan Bateman wrote: Thread::countStackFrames has been deprecated for 20+ years and has been marked for-removal since Java SE 9. I'd like to remove it for Java SE 14. It's was never a well-defined method and I've been unable to find anything that uses it. The StackWalker

RE: RFR (S) 8232168: Fix non wide char canonicalization on Windows

Hi Alan, > I have this on my list to look at. I think we'll need to figure out a > path to separate the usages (the JPLIS agent usage is technical debt, we > should have addressed that issue a long time ago). I agree that it's a good thing to explore how the different usages of calls to

Re: RFR: JDK-8232723: make the resource file main.wxs over-ridable

revised to add test webrev.02 at [3] [3] http://cr.openjdk.java.net/~herrick/8232723/webrev.02 /Andy On 10/22/2019 2:57 PM, Alexey Semenyuk wrote: Looks good. It would be good to have a test for this change as a part of this fix or as a follow up CR. - Alexey On 10/22/2019 2:50 PM, Andy

Re: RFR (S) 8232168: Fix non wide char canonicalization on Windows

On 23/10/2019 13:57, Langer, Christoph wrote: Hi, I've picked up Ralf's patch and cleaned it up a little bit. But apart from some comment changes it should be the same as his original version. So, what happens is that the windows 'canonicalize" function will only delegate to 'wcanonicalize'

RE: RFR (S) 8232168: Fix non wide char canonicalization on Windows

Hi, I've picked up Ralf's patch and cleaned it up a little bit. But apart from some comment changes it should be the same as his original version. So, what happens is that the windows 'canonicalize" function will only delegate to 'wcanonicalize' from now on. Furthermore,

Re: 8205132: Remove Thread.countStackFrames()

Looks good Alan! I'm guessing there may be a JCK update required somewhere to go with this. Thanks, David On 23/10/2019 5:25 pm, Alan Bateman wrote: Thread::countStackFrames has been deprecated for 20+ years and has been marked for-removal since Java SE 9. I'd like to remove it for Java SE

RFR: JDK-8232879: (zipfs) Writing out data with ZipFileSystem leads to a CRC failure in the generated jar file

Can I please get a review and a sponsor for a potential fix for JDK-8232879[1]? The patch is available as a webrev at [2]. What's happening in there is that the jdk.nio.zipfs.ZipFileSystem.DeflatingEntryOutputStream is overriding the one arg write(byte b) method and calling the super.write(b) and

Re: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java are not reproducable

Hi, ideally the build step to generate default_jli_trace.txt should be done independently of where the CDS feature is compiled in, but the fix looks good regardless. /Claes On 2019-10-23 09:16, Jie Fu wrote: Hi all, JBS:    https://bugs.openjdk.java.net/browse/JDK-8232864 Webrev:

Re: 8205132: Remove Thread.countStackFrames()

> On 23 Oct 2019, at 08:25, Alan Bateman wrote: > > > Thread::countStackFrames has been deprecated for 20+ years and has been > marked for-removal since Java SE 9. I'd like to remove it for Java SE 14. > It's was never a well-defined method and I've been unable to find anything > that uses

Re: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java are not reproducable

Hi Alan, Thanks for looking at this. On 2019/10/23 下午3:57, Alan Bateman wrote: Would this test have caught this if it were run with CDS disables? Yes. This bug was found while we were debugging the CDS feature on our mips platform. I'm just wondering if we need to add more run modes.

Re: 8231602: Deprecate Thread.suspend/resume for removal

On 23/10/2019 10:15, Chris Hegarty wrote: : While orthogonal to this JIRA issue, 8231602 says: "It's time to dial this up to forRemoval=true so these methods can be removed in a future release." - Is there a planned release where these methods will be removed? If so, what is that release? TBD.

Re: RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java are not reproducable

On 23/10/2019 08:16, Jie Fu wrote: Hi all, JBS:    https://bugs.openjdk.java.net/browse/JDK-8232864 Webrev: http://cr.openjdk.java.net/~jiefu/8232864/webrev.00/ To find out how to reproduce this bug, please refer to the JBS. To keep things sorted in a deterministic order, current

8205132: Remove Thread.countStackFrames()

Thread::countStackFrames has been deprecated for 20+ years and has been marked for-removal since Java SE 9. I'd like to remove it for Java SE 14. It's was never a well-defined method and I've been unable to find anything that uses it. The StackWalker API is a much better solution for code

RFR: 8232864: Classes generated by GenerateJLIClassesPlugin.java are not reproducable

Hi all, JBS:    https://bugs.openjdk.java.net/browse/JDK-8232864 Webrev: http://cr.openjdk.java.net/~jiefu/8232864/webrev.00/ To find out how to reproduce this bug, please refer to the JBS. To keep things sorted in a deterministic order, current implementation seems to be dependent on a