Howto replicate failure of 8254790?

Hi all, I am trying to replicate the failure of the tier2 test mentioned in 8254790 but I am only seeing it pass under an x86 linux machine. Are there any specific architectural constraints under which this test should be run in order to make

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]

On Wed, 14 Oct 2020 14:39:40 GMT, Albert Mingkun Yang wrote: >> (1) The "0" suffix is idiomatic for this sort of thing. See, for example, >> src/java.base/share/native/libjava/ConstantPool.c. (2) I'm not sure what >> else besides an override one might wonder >> about? "Default implementation o

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v4]

> Finally returning to this review that was started in April 2020. I've > recast it as a github PR. I think the security concern raised by Gil > has been adequately answered. > https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html > https://mail.openjdk.java.net/pipermail/

Re: RFR: 8159746: (proxy) Support for default methods

On Wed, 7 Oct 2020 21:31:29 GMT, Mandy Chung wrote: >> I'm thinking a static method `InvocationHandler::invokeDefaultMethod` and no >> new method in `Proxy` class. Proxy class >> will still have the package-private methods for >> `InvocationHandler::invokeDefaultMethod` implementation to use.

Re: RFR: 8159746: (proxy) Support for default methods [v4]

> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke > the given default method on the given proxy instance. > > The implementation looks up a method handle for `invokespecial` instruction > as if called from with the proxy class as the caller, equivalent to calling > `X.supe

Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v4]

Ian, Should IllegalFormatArgumentIndexException.java provide an override of getMessage? It appears that is done in the following: https://github.com/openjdk/jdk/blob/9b07ef33b6e07afae1a8bfa034200eb3aab1f94f/src/java.base/share/classes/java/util/IllegalFormatWidthException.java https://github.co

Re: RFR: 8254192: ExtraSharedClassListFile contains extra white space at end of line [v2]

On Thu, 15 Oct 2020 01:04:25 GMT, Yumin Qi wrote: >> Hi, Please review the simple change. >> >> The removing of white spaces from end of line in ClassListParser should be >> moved to before we add lambda-form-invoker >> line to array. After made such arrangement, changed CDS.java for trimm

Re: RFR: 8254192: ExtraSharedClassListFile contains extra white space at end of line [v2]

> Hi, Please review the simple change. > > The removing of white spaces from end of line in ClassListParser should be > moved to before we add lambda-form-invoker > line to array. After made such arrangement, changed CDS.java for trimming > line code. > > Tests: local test on runtime/cds/a

Re: Howto replicate failure of 8254790?

Hi Jason, On 15/10/2020 10:42 am, Tatton, Jason wrote: Hi all, I am trying to replicate the failure of the tier2 test mentioned in 8254790 but I am only seeing it pass under an x86 linux machine. Are there any specific architectural constrai

RFR: 8254192: ExtraSharedClassListFile contains extra white space at end of line

Hi, Please review the simple change. The removing of white spaces from end of line in ClassListParser should be moved to before we add lambda-form-invoker line to array. After made such arrangement, changed CDS.java for trimming line code. Tests: local test on runtime/cds/appcds. Mach5 tie

Re: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding [v4]

On Wed, 14 Oct 2020 10:29:40 GMT, Martin Doerr wrote: > Hi Corey, > Are you thinking of a case where that produces a higher iteration count? > Sorry for the confusion. This is also fine: length = sl - sp - 12 i = length > / block_size if (i <= 0) return 0 But I > still wonder why we should use 2

Re: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v6]

My apologies. I relied on the other reviewers. I'll do an independent review in the future. Thanks, Paul On 10/14/20, 11:02 AM, "core-libs-dev on behalf of Roger Riggs" wrote: On Wed, 14 Oct 2020 15:01:42 GMT, Roger Riggs wrote: >> Due to the requirement for multiple reviewers, I

Re: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v6]

On Wed, 14 Oct 2020 17:59:53 GMT, Roger Riggs wrote: >> This integration without testing with a current merge from the master and >> has caused two build failures. >> >> JDK-8254761: Wrong intrinsic annotation used for StringLatin1.indexOfChar >> >> JDK-8254775: Microbenchmark StringIndexOfCha

Re: RFR: 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents [v10]

On Wed, 14 Oct 2020 00:25:14 GMT, Vladimir Kozlov wrote: > > > Good. Thanks for the review, Vladimir (@vnkozlov)! I'm still (stress) testing adaptations to lazy/concurrent thread stack processing for ZGC. --Richard. - PR: https://git.openjdk.java.net/jdk/pull/119

Integrated: 8223347: Integration of Vector API (Incubator)

On Fri, 25 Sep 2020 20:14:29 GMT, Paul Sandoz wrote: > This pull request is for integration of the Vector API. It was previously > reviewed under conditions when mercurial was > used for the source code control system. Review threads can be found here > (searching for issue number 8223347 in th

Re: RFR: 8251989: Hex formatting and parsing utility [v2]

On Tue, 13 Oct 2020 21:56:31 GMT, Marcono1234 wrote: >> Roger Riggs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Various code review comments, rename UpperCase and LowerCase methods to >> match Character, remove unnecessary Class na

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]

On Wed, 14 Oct 2020 04:27:34 GMT, Kim Barrett wrote: >> Finally returning to this review that was started in April 2020. I've >> recast it as a github PR. I think the security concern raised by Gil >> has been adequately answered. >> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-A

Re: RFR: 8251989: Hex formatting and parsing utility [v3]

> java.util.HexFormat utility: > > - Format and parse hexadecimal strings, with parameters for delimiter, > prefix, suffix and upper/lowercase > - Static factories and builder methods to create HexFormat copies with > modified parameters. > - Consistent naming of methods for conversion of byt

Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v4]

> The `java.util.Formatter` format specifies support for field widths, argument > indexes, or precision lengths of a field > that relate to the variadic arguments supplied to the formatter. These > numbers are specified by integers, sometimes > negative. For argument index, it's specified in the

Re: RFR: 8254161: Prevent instantiation of EnumSet subclasses through deserialization

On Mon, 12 Oct 2020 13:47:46 GMT, Chris Hegarty wrote: > TL;DR add EnumSet::readObjectNoData() > > EnumSet is an exemplar of the Serialization Proxy Pattern. As such, it > should strictly implement that pattern and demonstrate how best to > defend against inappropriate instantiation through dese

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]

On Wed, 14 Oct 2020 18:09:16 GMT, Mandy Chung wrote: >> @mlchung I have often used a `Reference` in tests - but my main usage >> there would be to call `ref.refersTo(null)` >> which works in all cases. My main concern here however is that using `T` in >> `refersTo` seems to go against the >> a

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]

On Tue, 13 Oct 2020 08:49:23 GMT, Daniel Fuchs wrote: >> @dfuch I would expect the users of `refersTo` should know the type of the >> referent to be compared, i.e. it should know >> the parameter type of a Reference object. Do you have any specific use >> case in mind that you have a `Referen

Re: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v6]

On Wed, 14 Oct 2020 15:01:42 GMT, Roger Riggs wrote: >> Due to the requirement for multiple reviewers, I had been waiting to add my >> review of the Core-Libs files until the >> HotSpot reviewers had approved! I see only one reviewer credited in the >> commit. > > This integration without test

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v7]

On Wed, 14 Oct 2020 16:31:32 GMT, Lance Andersen wrote: > Mach5 run is clean :-) Thanks a lot Lance. Just waiting for the CSR to get approved now. - PR: https://git.openjdk.java.net/jdk/pull/520

Re: RFR: 8223347: Integration of Vector API (Incubator) [v6]

> This pull request is for integration of the Vector API. It was previously > reviewed under conditions when mercurial was > used for the source code control system. Review threads can be found here > (searching for issue number 8223347 in the > title): > https://mail.openjdk.java.net/pipermail

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v7]

On Wed, 14 Oct 2020 14:52:29 GMT, Lance Andersen wrote: >> Volker Simonis has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental >> views will show differences compared to the previous content of the PR. > > The changes look good. Thank you f

Re: RFR: 8247666: Support Lambda proxy classes in static CDS archive [v5]

On Wed, 14 Oct 2020 01:44:05 GMT, Mandy Chung wrote: >> Changes requested by iklam (Reviewer). > >> `@lambda-proxy: LambHello run ()Ljava/lang/Runnable; ()V 6 LambHello >> lambda$main$0 ()V ()V` > > Can you explain the format? `@lambda-proxy LambHello run ()Ljava/lang/Runnable; ()V REF_invoke

Re: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v2]

On Tue, 13 Oct 2020 14:48:40 GMT, Andy Herrick wrote: >> JDK-8252870: Finalize (remove "incubator" from) jpackage > > Andy Herrick has updated the pull request incrementally with one additional > commit since the last revision: > > JDK-8252870: Finalize (remove "incubator" from) jpackage >

Re: RFR: 8254775: Microbenchmark StringIndexOfChar doesn't compile

On Wed, 14 Oct 2020 15:32:13 GMT, Aleksey Shipilev wrote: >> Thanks for reviewing, @RogerRiggs - hopefully this is the last of 'em > > The benchmark is oddly written. I submitted > https://bugs.openjdk.java.net/browse/JDK-8254782 -- to let original authors > fix it up. @shipilev yeah, seems rea

Re: RFR: 8254775: Microbenchmark StringIndexOfChar doesn't compile

On Wed, 14 Oct 2020 15:23:31 GMT, Claes Redestad wrote: >> Thanks for fixing these problems. > > Thanks for reviewing, @RogerRiggs - hopefully this is the last of 'em The benchmark is oddly written. I submitted https://bugs.openjdk.java.net/browse/JDK-8254782 -- to let original authors fix it u

Integrated: 8254775: Microbenchmark StringIndexOfChar doesn't compile

On Wed, 14 Oct 2020 15:09:59 GMT, Claes Redestad wrote: > - Illegal use of a unicode codepoint > \u as a char. > - Wrong class name. > - @Benchmark methods shouldn't be static. > > Each of these breaks the build, e.g. make build-microbenchmark fails, so it > seems the micro was never tested

Re: RFR: 8254775: Microbenchmark StringIndexOfChar doesn't compile

On Wed, 14 Oct 2020 15:13:00 GMT, Roger Riggs wrote: >> - Illegal use of a unicode codepoint > \u as a char. >> - Wrong class name. >> - @Benchmark methods shouldn't be static. >> >> Each of these breaks the build, e.g. make build-microbenchmark fails, so it >> seems the micro was never tes

Re: RFR: 8254775: Microbenchmark StringIndexOfChar doesn't compile

On Wed, 14 Oct 2020 15:09:59 GMT, Claes Redestad wrote: > - Illegal use of a unicode codepoint > \u as a char. > - Wrong class name. > - @Benchmark methods shouldn't be static. > > Each of these breaks the build, e.g. make build-microbenchmark fails, so it > seems the micro was never tested

RFR: 8254775: Microbenchmark StringIndexOfChar doesn't compile

- Illegal use of a unicode codepoint > \u as a char. - Wrong class name. - @Benchmark methods shouldn't be static. Each of these breaks the build, e.g. make build-microbenchmark fails, so it seems the micro was never tested..? This patch fixes up the micro so it compiles, but makes no guaran

Re: RFR: 8223347: Integration of Vector API (Incubator) [v5]

> This pull request is for integration of the Vector API. It was previously > reviewed under conditions when mercurial was > used for the source code control system. Review threads can be found here > (searching for issue number 8223347 in the > title): > https://mail.openjdk.java.net/pipermail

Re: RFR: 8251989: Hex formatting and parsing utility [v2]

On Wed, 14 Oct 2020 13:46:59 GMT, Daniel Fuchs wrote: >> Its a bit of a space/time trade-off. And the balance point will change if >> the class is converted in the future to a >> Valhalla primitive class. At this point it looks to me like a premature >> optimization. > > OK - but just to avoid

Re: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v6]

On Wed, 14 Oct 2020 13:18:19 GMT, Roger Riggs wrote: >> Marked as reviewed by neliasso (Reviewer). > > Due to the requirement for multiple reviewers, I had been waiting to add my > review of the Core-Libs files until the > HotSpot reviewers had approved! I see only one reviewer credited in the

RFR: 8253525: Implement getInstanceSize/sizeOf intrinsics

This is fork off the SizeOf JEP, JDK-8249196. There is already the entry point in JDK that can use the intrinsic like this: `Instrumentation.getInstanceSize`. Therefore, we can implement the C1/C2 intrinsic now, hook it up to `Instrumentation`, and let the tools use that fast path today. With th

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v2]

On Mon, 12 Oct 2020 11:46:31 GMT, Volker Simonis wrote: >> I don't believe we discuss/reference the data descriptor for a Zip entry >> (outside of the PKWare Zip specification) so I >> am not sure we should reference it in the javadoc. >> Placing the sentence after "The default compression meth

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v7]

On Wed, 14 Oct 2020 10:54:30 GMT, Volker Simonis wrote: >> ### Summary >> >> Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code >> which can lead to the `ZipException "invalid >> entry compressed size"`. >> ### Motivation >> >> In general it is not safe to directly write

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]

On Wed, 14 Oct 2020 14:19:59 GMT, Kim Barrett wrote: > See, for example, src/java.base/share/native/libjava/ConstantPool.c. Got it; thank you. > I'm not sure what else besides an override one might wonder about? I don't know; maybe override is the only sensible choice. I just believe saying i

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]

On Wed, 14 Oct 2020 11:18:18 GMT, Albert Mingkun Yang wrote: >> Kim Barrett has updated the pull request incrementally with three additional >> commits since the last revision: >> >> - simplify test >> - cleanup nits from Mandy >> - use Object instead of TestObject > > src/java.base/share/cl

Re: RFR: 8238669: Long.divideUnsigned is extremely slow for certain values (Needs to be Intrinsic) [v2]

On Thu, 24 Sep 2020 15:33:01 GMT, Raffaello Giulietti wrote: >> @shipilev I agree, but that's the title chosen by the reporter of the JBS >> issue. Not sure I can edit it without >> impacting bots and tools. > > Hello > > this is a gentle reminder that this issue still needs a more formal revi

Integrated: 8254761: Wrong intrinsic annotation used for StringLatin1.indexOfChar

On Wed, 14 Oct 2020 14:04:07 GMT, Claes Redestad wrote: > Wrong intrinsic name used, causing a build breakage This pull request has now been integrated. Changeset: a6a38135 Author:Claes Redestad URL: https://git.openjdk.java.net/jdk/commit/a6a38135 Stats: 1 line in 1 file changed

Integrated: 8254761: Wrong intrinsic annotation used for StringLatin1.indexOfChar

Wrong intrinsic name used, causing a build breakage - Commit messages: - Revert accidental changes - Merge branch 'intrinsic' of https://github.com/cl4es/jdk into intrinsic - HotspotIntrinsicCandidate is now IntrinsicCandidate - Revert accidental changes Changes: https://git.open

Re: Integrated: 8254761: Wrong intrinsic annotation used for StringLatin1.indexOfChar

On Wed, 14 Oct 2020 14:06:44 GMT, Alan Bateman wrote: >> Wrong intrinsic name used, causing a build breakage > > Marked as reviewed by alanb (Reviewer). Thanks for reviewing, @AlanBateman Since builds are broken and I've verified a local build I'll go ahead and integrate without waiting for au

Re: Integrated: 8254761: Wrong intrinsic annotation used for StringLatin1.indexOfChar

On Wed, 14 Oct 2020 14:04:07 GMT, Claes Redestad wrote: > Wrong intrinsic name used, causing a build breakage Marked as reviewed by alanb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/654

Re: RFR: 8251989: Hex formatting and parsing utility [v2]

On Wed, 14 Oct 2020 09:53:23 GMT, Daniel Fuchs wrote: >> Roger Riggs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Various code review comments, rename UpperCase and LowerCase methods to >> match Character, remove unnecessary Class na

Re: RFR: 8251989: Hex formatting and parsing utility [v2]

On Wed, 14 Oct 2020 13:38:51 GMT, Roger Riggs wrote: >> src/java.net.http/share/classes/jdk/internal/net/http/common/Utils.java line >> 1116: >> >>> 1114: } >>> 1115: >>> 1116: HexFormat format = HexFormat.of().withUpperCase(); >> >> Should/can this be a static final field in t

Re: RFR: 8251989: Hex formatting and parsing utility [v2]

On Wed, 14 Oct 2020 09:28:25 GMT, Daniel Fuchs wrote: >> Roger Riggs has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Various code review comments, rename UpperCase and LowerCase methods to >> match Character, remove unnecessary Class na

Re: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v6]

On Wed, 14 Oct 2020 12:03:42 GMT, Nils Eliasson wrote: >> Jason Tatton has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Added missing copyright notices > > Marked as reviewed by neliasso (Reviewer). Due to the requirement for multiple re

Integrated: 8173585: Intrinsify StringLatin1.indexOf(char)

On Tue, 8 Sep 2020 11:59:36 GMT, Jason Tatton wrote: > This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 > byte encoded Strings). It is provided for > x86 and ARM64. The implementation is greatly inspired by the indexOf(char) > intrinsic for StringUTF16. To incorpora

Re: RFR: 8254177: (tz) Upgrade time-zone data to tzdata2020b

On Tue, 13 Oct 2020 18:43:18 GMT, Andrew John Hughes wrote: >> Thanks for the review everyone, I have added a release note to the bug. I >> will integrate the changes > > Looks like we both reached the same patch for this one independently :) > systemv was removed from tzdata some time ago and w

Re: RFR: 8173585: Intrinsify StringLatin1.indexOf(char) [v6]

On Mon, 12 Oct 2020 11:17:25 GMT, Jason Tatton wrote: >> This is an implementation of the indexOf(char) intrinsic for StringLatin1 (1 >> byte encoded Strings). It is provided for >> x86 and ARM64. The implementation is greatly inspired by the indexOf(char) >> intrinsic for StringUTF16. To inco

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]

On Wed, 14 Oct 2020 04:27:34 GMT, Kim Barrett wrote: >> Finally returning to this review that was started in April 2020. I've >> recast it as a github PR. I think the security concern raised by Gil >> has been adequately answered. >> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-A

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v7]

> ### Summary > > Work around wrong usage of `ZipOutputStream.putNextEntry()` in user code > which can lead to the `ZipException "invalid > entry compressed size"`. > ### Motivation > > In general it is not safe to directly write a ZipEntry obtained from > `ZipInputStream.getNextEntry()`, > `Zi

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v6]

On Wed, 14 Oct 2020 10:48:55 GMT, Volker Simonis wrote: >> test/jdk/java/util/zip/CopyZipFile.java line 104: >> >>> 102: // all these fields set to '-1'. >>> 103: InputStream is = new FileInputStream(ZIP_FILE); >>> 104: ZipInputStream zis = new ZipInputStream(is); >> >>

Re: RFR: 8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size [v6]

On Tue, 13 Oct 2020 19:56:50 GMT, Lance Andersen wrote: >> Volker Simonis has refreshed the contents of this pull request, and previous >> commits have been removed. The incremental >> views will show differences compared to the previous content of the PR. > > test/jdk/java/util/zip/CopyZipFile.

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]

On Wed, 14 Oct 2020 04:27:34 GMT, Kim Barrett wrote: >> Finally returning to this review that was started in April 2020. I've >> recast it as a github PR. I think the security concern raised by Gil >> has been adequately answered. >> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-A

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v3]

On Thu, 8 Oct 2020 14:00:11 GMT, Roger Riggs wrote: >> Can you add a unit test in `test/jdk/java/lang/ref` that serves as a basic >> API test for this new `refersTo` API without >> depending the WhiteBox API? test/hotspot/jtreg/gc` test serves as a more >> white-boxed type and comprehensive

Re: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding [v4]

On Wed, 14 Oct 2020 02:04:42 GMT, CoreyAshford wrote: >>> Hi Corey, thanks for taking some stuff out of the “too short” path. There >>> may be a performance regression when decoding >>> many short arrays because of the stub call overhead and the usage of the >>> slower part of the Java impleme

Re: RFR: 8251989: Hex formatting and parsing utility [v2]

On Tue, 13 Oct 2020 19:51:30 GMT, Roger Riggs wrote: >> java.util.HexFormat utility: >> >> - Format and parse hexadecimal strings, with parameters for delimiter, >> prefix, suffix and upper/lowercase >> - Static factories and builder methods to create HexFormat copies with >> modified parame