From stuart.marks at oracle.com Fri May 1 04:02:33 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 30 Apr 2020 21:02:33 -0700 Subject: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException In-Reply-To: References: <2b1a70a8-7d0a-9d7a-b48d-69de03b07e2e@oracle.com> Message-ID: <3b4efc42-f45f-820f-44af-89c3fa28ac39@oracle.com> Hi Jay, OK, welcome! I'll sponsor this changeset for you. It's pretty simple, so I'll just paste the exported changeset below. (For complicated changesets, you'll have to ask a sponsor to host a webrev on cr.openjdk.java.net for you.) Please check the Contributed-by line in the changeset to make sure the attribution is correct. I just copied the From: line from your email, but if you want it to be different, please let me know. I'll update the bug report with a pointer to this email thread. https://bugs.openjdk.java.net/browse/JDK-6415694 Could I get a Reviewer to review this? Thanks. (I noticed that the anachronistic markup is used here instead of the preferred {@code ...} javadoc tag. However, is used all over this package, so I didn't think that changing it in just one place would be helpful.) I'll also note again that since this is merely an editorial wording change to the specification, I don't think it needs a CSR request. Thanks, s'marks # HG changeset patch # User smarks # Date 1588290431 25200 # Thu Apr 30 16:47:11 2020 -0700 # Node ID 1f5b3876d1500a2e77d6e39d079649964ba6dd26 # Parent fe6548dc92de4c875467c968ee37e7c9bbee1697 6415694: Clarification in Javadoc for java.rmi.AlreadyBoundException Reviewed-by: XXX Contributed-by: Jayashree Sk1 diff -r fe6548dc92de -r 1f5b3876d150 src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java --- a/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Thu Apr 30 15:21:15 2020 -0700 +++ b/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Thu Apr 30 16:47:11 2020 -0700 @@ -26,8 +26,8 @@ /** * An AlreadyBoundException is thrown if an attempt - * is made to bind an object in the registry to a name that already - * has an associated binding. + * is made to bind an object to a name that already + * has an associated binding in the registry. * * @since 1.1 * @author Ann Wollrath On 4/29/20 10:24 PM, Jayashree Sk1 wrote: > Thanks for the review comment Stuart. Yes, I will need a sponsor, this is my first time here in OpenJDK. > > > Regards! > Jay > > -----Stuart Marks wrote: ----- > To: Jayashree Sk1 > From: Stuart Marks > Date: 04/30/2020 09:22AM > Cc: core-libs-dev at openjdk.java.net > Subject: [EXTERNAL] Re: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException > > The change looks fine. Although this is in a normative portion of the > specification, the nature of the change is purely editorial, so I don't think it > needs a CSR. > > Do you need a sponsor? > > s'marks > > On 4/29/20 2:57 AM, Jayashree Sk1 wrote: >> Hi All, >> Please find the below changes for the issues https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D6415694&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=rA_13vli8clPM_toR46hq8FVwH3XGr8z7cUfcQoqL-k&m=OXEC-w1xTWoJUyw_sRivRwIGmkHIUc3DllMsA_N3qIk&s=iesFFcE4NSOreLmf8vwdKzcdnFgjGE_SEERICPUFef4&e= . >> It is a description change, which was already approved by the reviewer. >> >> Thanks! >> >> diff -r 59b5bd9a7168 src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java >> --- a/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Mon Mar 16 02:16:49 2020 -0400 >> +++ b/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Mon Mar 30 15:45:43 2020 +0530 >> @@ -26,8 +26,8 @@ >> >> /** >> * An AlreadyBoundException is thrown if an attempt >> - * is made to bind an object in the registry to a name that already >> - * has an associated binding. >> + * is made to bind an object to a name that already >> + * has an associated binding in the registry. >> * >> * @since 1.1 >> * @author Ann Wollrath >> > > From thomas.stuefe at gmail.com Fri May 1 06:19:34 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 1 May 2020 08:19:34 +0200 Subject: RFR [XXS] : 8244183: linker error jpackageapplauncher on Windows 32bit In-Reply-To: References: Message-ID: You have enough reviews now, but thanks for fixing this. ..Thomas On Thu, Apr 30, 2020 at 4:15 PM Baesken, Matthias wrote: > Hello, please look into this small fix for a link error we faced on > Windows 32bit. > > Currently we run into this link error : > jpackageapplauncher > > * For target > support_native_jdk.incubator.jpackage_jpackageapplauncher_BUILD_JPACKAGE_APPLAUNCHEREXE_link: > LINK : fatal error LNK1561: entry point must be defined > > looks like the wWinMain signature in > src\jdk.incubator.jpackage\windows\native\applauncher\WinLauncher.cpp > has to be adjusted. > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8244183 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8244183.0/ > > > Thanks, Matthias > From dmytro.sheyko.jdk at gmail.com Fri May 1 09:02:45 2020 From: dmytro.sheyko.jdk at gmail.com (dmytro sheyko) Date: Fri, 1 May 2020 12:02:45 +0300 Subject: Collections.synchronizedXXX() and internal mutex (aka SyncRoot) In-Reply-To: <6f88885e-fe66-5ae2-4746-74a4e959a350@oracle.com> References: <6f88885e-fe66-5ae2-4746-74a4e959a350@oracle.com> Message-ID: Thank you, I got it. I have one more a bit unrelated question. The checked, synchronized and unmodifiable wrappers in some cases store backing collection in more than one fields. Thus `UnmodifiableList` has 1. its own field `List list` and 2. `Collection c`, which it inherits from `UnmodifiableCollection`. Also `UnmodifiableNavigableSet` has even 3 duplicated fields: 1. its own `NavigableSet ns`, 2. `SortedSet ss` from `UnmodifiableSortedSet` and 3. `Collection c` from `UnmodifiableCollection`. Isn't it worth to get rid of such duplication? (at least for unmodifiable collections). This may affect serialization, but I believe it's still possible preserve serialization backward compatible, if it's necessary. Or is it done intentionally? Thank you, Dmytro On Fri, May 1, 2020 at 1:20 AM Stuart Marks wrote: > The general rule in the collections that wrappers and views don't divulge > their > backing collections. The reason is fairly obvious for things like the > checked > wrappers and unmodifiable wrappers, but it's equally important for various > view > collections like those of Lists, Sets, and Maps. If there were something > like > getSyncRoot() it could be used to break encapsulation. For example: > > Map map = Collections.synchronizedMap(...); > someMethod(map.values()); > > Currently, the caller is assured that someMethod() can only see the values > of > the map. Also, as you observe, someMethod() can't safely iterate that > collection > using an iterator or stream. If getSyncRoot() were introduced to address > that issue, > > void someMethod(Collection values) { > @SuppressWarnings("unchecked") > var map = (Map) Collections.getSyncRoot(values); > // I now have access to map's keys and can put new entries, > mwahaha! > } > > Undoubtedly there are ways we can avoid this, but the cost is designing > yet more > complicated APIs in an area where it provides little value. I think it's > pretty > unlikely that we'll do anything like this, or variants that allow the > caller to > provide an external lock at creation time, such as proposed in > JDK-4335520. > There's a pretty fundamental clash between external locking and > encapsulation, > and the platform has shifted to pursuing other approaches for concurrency. > > Legacy code that needs to iterate collection views might find some luck > replacing iterator loops with bulk methods like forEach() or removeIf(). > > s'marks > > > On 4/30/20 1:34 AM, dmytro sheyko wrote: > > Hi Stuart, > > > > In general I agree with you regarding synchronized collections. But > nevertheless > > there is a lot of legacy code that still uses synchronized wrappers. And > > sometimes synchronization is done on wrong lock object, which leads to > > relatively rare but extremely hard to reproduce and troubleshoot errors. > > Reworking whole this legacy stuff is risky. But if we had means to get > the right > > lock object for given synchronized collections, this would help us to > make the > > fixes more localized and hence safe. That's why I would like to know the > reason, > > why this has not been done earlier, and is there hope/plan this will be > done in > > near future. > > > > Thank you, > > Dmytro > > > > On Thu, Apr 30, 2020 at 6:36 AM Stuart Marks > > wrote: > > > > Hi Dmytro, > > > > Callers of an API performing explicit synchronization, along with the > > synchronized collections wrappers, have mostly fallen into disuse > since the > > introduction of the java.util.concurrent collections. > > > > Multiple threads can either interact directly on a concurrent > collection, or > > the > > developer can provide an intermediate object (not a collection) that > does > > internal locking, and that exports the right set of thread-safe APIs > to > > callers. > > I'm thus skeptical of the utility of enhancing these wrapper classes > with > > additional APIs. > > > > Do you have a use case that's difficult to handle any other way? > > > > s'marks > > > > > > > > On 4/29/20 12:58 AM, dmytro sheyko wrote: > > > Hello, > > > > > > Have you ever discussed to make field mutex in synchronized > collections > > > accessible? > > > > > > Javadoc for Collections#synchronizedSortedSet suggest to iterate > collection > > > this way: > > > > > > SortedSet s = Collections.synchronizedSortedSet(new TreeSet()); > > > SortedSet s2 = s.headSet(foo); > > > ... > > > synchronized (s) { // Note: s, not s2!!! > > > Iterator i = s2.iterator(); // Must be in the synchronized > block > > > while (i.hasNext()) > > > foo(i.next()); > > > } > > > > > > I.e. in order to iterate subset, we also need a reference to the > whole set, > > > which is not really convenient. How about to make it possible to > write: > > > > > > SortedSet s2 = s.headSet(foo); > > > ... > > > synchronized (Collections.getSyncRoot(s2)) { // Note: > > > Collections.getSyncRoot(s2) > > > Iterator i = s2.iterator(); // Must be in the synchronized > block > > > while (i.hasNext()) > > > foo(i.next()); > > > } > > > > > > Also I think it would be convenient to let to provide custom sync > root when > > > synchronized collection is created. > > > E.g. > > > > > > Object customSyncRoot = new Object(); > > > SortedSet s = Collections.synchronizedSortedSet(new TreeSet(), > > > customSyncRoot); > > > > > > What do you think about this? > > > > > > Regards, > > > Dmytro > > > > > > From maurizio.cimadamore at oracle.com Fri May 1 11:06:50 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 1 May 2020 12:06:50 +0100 Subject: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator) In-Reply-To: <7a96ec1b-cdec-1e3f-f6ca-102d7340e70a@oracle.com> References: <7a96ec1b-cdec-1e3f-f6ca-102d7340e70a@oracle.com> Message-ID: <271da482-cdbc-1d53-2ddd-efcb3a62ddff@oracle.com> Latest iteration - the follow issues were addressed: * fix a bug with alignment of native segments triggering spurious failures (contributed by Jorn) * fix javadoc and tests for access modes (contributed by Chris) * added benchmarks for Stream::findAny using segment spliterator (contributed by Peter) * addressed CSR comments Webrev: http://cr.openjdk.java.net/~mcimadamore/8243491_v3/webrev Delta webrev: http://cr.openjdk.java.net/~mcimadamore/8243491_v3/webrev_delta/ Javadoc: http://cr.openjdk.java.net/~mcimadamore/8243491_v3/javadoc Specdiff: http://cr.openjdk.java.net/~mcimadamore/8243491_v3/specdiff/overview-summary.html Cheers Maurizio On 27/04/2020 13:13, Maurizio Cimadamore wrote: > Another iteration, which addresses the following issues: > > * wrong copyright headers in certain tests > * issue with TestNative when running in debug mode caused by > mismatched malloc/os::free (contributed by Jorn) > * clarify javadoc of MemoryHandles::withStride > * improved implementation of MemoryAccessVarHandleGenerator to use > hidden classes rather than Unsafe.dAC (contributed by Mandy) > > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v2/webrev > > Delta webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v2/webrev_delta/ > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v2/javadoc > > Specdiff: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v2/specdiff/overview-summary.html > > > > Cheers > Maurizio > > > On 23/04/2020 21:33, Maurizio Cimadamore wrote: >> Hi, >> time has come for another round of foreign memory access API >> incubation (see JEP 383 [3]). This iteration aims at polishing some >> of the rough edges of the API, and adds some of the functionalities >> that developers have been asking for during this first round of >> incubation. The revised API tightens the thread-confinement >> constraints (by removing the MemorySegment::acquire method) and >> instead provides more targeted support for parallel computation via a >> segment spliterator. The API also adds a way to create a custom >> native segment; this is, essentially, an unsafe API point, very >> similar in spirit to the JNI NewDirectByteBuffer functionality [1]. >> By using this bit of API,? power-users will be able to add support, >> via MemorySegment, to *their own memory sources* (e.g. think of a >> custom allocator written in C/C++). For now, this API point is called >> off as "restricted" and a special read-only JDK property will have to >> be set on the command line for calls to this method to succeed. We >> are aware there's no precedent for something like this in the Java SE >> API - but if Project Panama is to remain true about its ultimate goal >> of replacing bits of JNI code with (low level) Java code, stuff like >> this has to be *possible*. We anticipate that, at some point, this >> property will become a true launcher flag, and that the foreign >> restricted machinery will be integrated more neatly into the module >> system. >> >> A list of the API, implementation and test changes is provided below. >> If you have any questions, or need more detailed explanations, I (and >> the rest of the Panama team) will be happy to point at existing >> discussions, and/or to provide the feedback required. >> >> Thanks >> Maurizio >> >> Webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/8243491_v1/webrev >> >> Javadoc: >> >> http://cr.openjdk.java.net/~mcimadamore/8243491_v1/javadoc >> >> Specdiff: >> >> http://cr.openjdk.java.net/~mcimadamore/8243491_v1/specdiff/overview-summary.html >> >> >> CSR: >> >> https://bugs.openjdk.java.net/browse/JDK-8243496 >> >> >> >> API changes >> =========== >> >> * MemorySegment >> ? - drop support for acquire() method - in its place now you can >> obtain a spliterator from a segment, which supports divide-and-conquer >> ? - revamped support for views - e.g. isReadOnly - now segments have >> access modes >> ? - added API to do serial confinement hand-off >> (MemorySegment::withOwnerThread) >> ? - added unsafe factory to construct a native segment out of an >> existing address; this API is "restricted" and only available if the >> program is executed using the -Dforeign.unsafe=permit flag. >> ? - the MemorySegment::mapFromPath now returns a MappedMemorySegment >> * MappedMemorySegment >> ? - small sub-interface which provides extra capabilities for mapped >> segments (load(), unload() and force()) >> * MemoryAddress >> ? - added distinction between *checked* and *unchecked* addresses; >> *unchecked* addresses do not have a segment, so they cannot be >> dereferenced >> ? - added NULL memory address (it's an unchecked address) >> ? - added factory to construct MemoryAddress from long value (result >> is also an unchecked address) >> ? - added API point to get raw address value (where possible - e.g. >> if this is not an address pointing to a heap segment) >> * MemoryLayout >> ? - Added support for layout "attributes" - e.g. store metadata >> inside MemoryLayouts >> ? - Added MemoryLayout::isPadding predicate >> ? - Added helper function to SequenceLayout to rehape/flatten >> sequence layouts (a la NDArray [4]) >> * MemoryHandles >> ? - add support for general VarHandle combinators (similar to MH >> combinators) >> ? - add a combinator to turn a long-VH into a MemoryAddress VH (the >> resulting MemoryAddress is also *unchecked* and cannot be dereferenced) >> >> Implementation changes >> ====================== >> >> * add support for VarHandle combinators (e.g. IndirectVH) >> >> The idea here is simple: a VarHandle can almost be thought of as a >> set of method handles (one for each access mode supported by the var >> handle) that are lazily linked. This gives us a relatively simple >> idea upon which to build support for custom var handle adapters: we >> could create a VarHandle by passing an existing var handle and also >> specify the set of adaptations that should be applied to the method >> handle for a given access mode in the original var handle. The result >> is a new VarHandle which might support a different carrier type and >> more, or less coordinate types. Adding this support was relatively >> easy - and it only required one low-level surgery of the lambda forms >> generated for adapted var handle (this is required so that the >> "right" var handle receiver can be used for dispatching the access >> mode call). >> >> All the new adapters in the MemoryHandles API (which are really >> defined inside VarHandles) are really just a bunch of MH adapters >> that are stitched together into a brand new VH. The only caveat is >> that, we could have a checked exception mismatch: the VarHandle API >> methods are specified not to throw any checked exception, whereas >> method handles can throw any throwable. This means that, potentially, >> calling get() on an adapted VarHandle could result in a checked >> exception being thrown; to solve this gnarly issue, we decided to >> scan all the filter functions passed to the VH combinators and look >> for direct method handles which throw checked exceptions. If such MHs >> are found (these can be deeply nested, since the MHs can be adapted >> on their own), adaptation of the target VH fails fast. >> >> >> * More ByteBuffer implementation changes >> >> Some more changes to ByteBuffer support were necessary here. First, >> we have added support for retrieval of "mapped" properties associated >> with a ByteBuffer (e.g. the file descriptor, etc.). This is crucial >> if we want to be able to turn an existing byte buffer into the "right >> kind" of memory segment. >> >> Conversely, we also have to allow creation of mapped byte buffers >> given existing parameters - which is needed when going from (mapped) >> segment to a buffer. These two pieces together allow us to go from >> segment to buffer and back w/o losing any information about the >> underlying memory mapping (which was an issue in the previous >> implementation). >> >> Lastly, to support the new MappedMemorySegment abstraction, all the >> memory mapped supporting functionalities have been moved into a >> common helper class so that MappedMemorySegmentImpl can reuse that >> (e.g. for MappedMemorySegment::force). >> >> * Rewritten memory segment hierarchy >> >> The old implementation had a monomorphic memory segment class. In >> this round we aimed at splitting the various implementation classes >> so that we have a class for heap segments (HeapMemorySegmentImpl), >> one for native segments (NativeMemorySegmentImpl) and one for memory >> mapped segments (MappedMemorySegmentImpl, which extends from >> NativeMemorySegmentImpl). Not much to see here - although one >> important point is that, by doing this, we have been able to speed up >> performances quite a bit, since now e.g. native/mapped segments are >> _guaranteed_ to have a null "base". We have also done few tricks to >> make sure that the "base" accessor for heap segment is sharply typed >> and also NPE checked, which allows C2 to speculate more and hoist. >> With these changes _all_ segment types have comparable performances >> and hoisting guarantees (unlike in the old implementation). >> >> * Add workarounds in MemoryAddressProxy, AbstractMemorySegmentImpl to >> special case "small segments" so that VM can apply bound check >> elimination >> >> This is another important piece which allows to get very good >> performances out of indexes memory access var handles; as you might >> know, the JIT compiler has troubles in optimizing loops where the >> loop variable is a long [2]. To make up for that, in this round we >> add an optimization which allows the API to detect whether a segment >> is *small* or *large*. For small segments, the API realizes that >> there's no need to perform long computation (e.g. to perform bound >> checks, or offset additions), so it falls back to integer logic, >> which in turns allows bound check elimination. >> >> * renaming of the various var handle classes to conform to "memory >> access var handle" terminology >> >> This is mostly stylistic, nothing to see here. >> >> Tests changes >> ============= >> >> In addition to the tests for the new API changes, we've also added >> some stress tests for var handle combinators - e.g. there's a flag >> that can be enabled which turns on some "dummy" var handle >> adaptations on all var handles created by the runtime. We've used >> this flag on existing tests to make sure that things work as expected. >> >> To sanity test the new memory segment spliterator, we have wired the >> new segment spliterator with the existing spliterator test harness. >> >> We have also added several micro benchmarks for the memory segment >> API (and made some changes to the build script so that native >> libraries would be handled correctly). >> >> >> [1] - >> https://docs.oracle.com/en/java/javase/14/docs/specs/jni/functions.html#newdirectbytebuffer >> [2] - https://bugs.openjdk.java.net/browse/JDK-8223051 >> [3] - https://openjdk.java.net/jeps/383 >> [4] - >> https://docs.scipy.org/doc/numpy/reference/generated/numpy.reshape.html#numpy.reshape >> >> From peter.levart at gmail.com Fri May 1 13:00:50 2020 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 1 May 2020 15:00:50 +0200 Subject: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator) In-Reply-To: <4d0bfd55-5792-7172-287f-7059e1499bcc@oracle.com> References: <2fc767e1-c4bc-65ca-230d-9f7224f4ebe8@gmail.com> <7703864a-486a-36f1-7983-14df8923b71f@oracle.com> <790dc9a2-2807-4758-9f97-d0d3a8f2dcd0@oracle.com> <7e244f2b-fb78-c399-3dc7-be699396c3ea@oracle.com> <021a1013-cabc-760f-a1e4-5b36ed26f60a@gmail.com> <4d0bfd55-5792-7172-287f-7059e1499bcc@oracle.com> Message-ID: On 4/30/20 8:10 PM, Maurizio Cimadamore wrote: > > On 30/04/2020 01:06, Peter Levart wrote: >> Think differently: what if the client succeeded in closing the >> segment, just because it did it in a time window when no thread in >> the thread pool held an open scope (this is entirely possible with >> parallel stream for example since threads periodically acquire and >> close scopes). This would have the same effect on threads in the >> thread pool - they would not be able to continue their work... What >> I'm trying to say is that this is just a mechanism to make things >> safe, not to coordinate work. If program wants to avoid trouble, it >> must carefully coordinate work of threads. > > This appear to me to be a bit of a slippery slope? Sure, if somebody > prematurely calls close() on a segment while other threads are > accessing it, it could be seen as undefined behavior (a la C > specifications ;-) ), but then, if you pull on the same string, why > even bother with confinement in the first place? If you call close() > prematurely and you get a VM crash that's on you? Luckily, I think I have fixed this shortcoming in the alternative MemoryScope: http://cr.openjdk.java.net/~plevart/jdk-dev/8243491_MemoryScope/v2/MemoryScope.java The trick is in using a 'state' with 3 values: OPEN, CLOSING, CLOSED ... The acquiring thread does the following in order: - increments the 'acquires' scalable counter (volatile write) - reads the 'state' (volatile read) and then enters a spin-loop: ??? - if state == STATE_OPEN the acquire succeeded (this is fast path); else ??? - if state == STATE_CLOSING it spin-loops re-reading 'state' in each iteration; else ??? - if state == STATE_CLOSED it increments 'releases' scalable counter and throws exception The closing thread does the following in order: - writes STATE_CLOSING to 'state' (volatile write) - sums the 'releases' scalable counter (volatile reads) - sums the 'acquires' scalable counter (volatile reads) - compares both sums and: ??? - if they don't match then it writes back STATE_OPEN to 'state' (volatile write) and throws exception; else ??? - it writes STATE_CLOSED to 'state' (volatile write) and executes cleanup action This, I think, is better, isn't it? Regards, Peter > Maurizio > > From peter.levart at gmail.com Fri May 1 14:31:39 2020 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 1 May 2020 16:31:39 +0200 Subject: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator) In-Reply-To: References: <2fc767e1-c4bc-65ca-230d-9f7224f4ebe8@gmail.com> <7703864a-486a-36f1-7983-14df8923b71f@oracle.com> <790dc9a2-2807-4758-9f97-d0d3a8f2dcd0@oracle.com> <7e244f2b-fb78-c399-3dc7-be699396c3ea@oracle.com> <021a1013-cabc-760f-a1e4-5b36ed26f60a@gmail.com> <4d0bfd55-5792-7172-287f-7059e1499bcc@oracle.com> Message-ID: Hi Maurizio, On 5/1/20 3:00 PM, Peter Levart wrote: > > > Luckily, I think I have fixed this shortcoming in the alternative > MemoryScope: > > > http://cr.openjdk.java.net/~plevart/jdk-dev/8243491_MemoryScope/v2/MemoryScope.java > > I added support for dup() (modified above file in-place) and also the last missing part: MemoryScope.GLOBAL. So WDYT? Is it ok to propose this for panama? How do I proceed? Regards, Peter From maurizio.cimadamore at oracle.com Fri May 1 14:36:57 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 1 May 2020 15:36:57 +0100 Subject: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator) In-Reply-To: References: <2fc767e1-c4bc-65ca-230d-9f7224f4ebe8@gmail.com> <7703864a-486a-36f1-7983-14df8923b71f@oracle.com> <790dc9a2-2807-4758-9f97-d0d3a8f2dcd0@oracle.com> <7e244f2b-fb78-c399-3dc7-be699396c3ea@oracle.com> <021a1013-cabc-760f-a1e4-5b36ed26f60a@gmail.com> <4d0bfd55-5792-7172-287f-7059e1499bcc@oracle.com> Message-ID: <30217bef-c680-48fe-973b-07ab52682bb6@oracle.com> Hi Peter, this does look better yes. I suspect this doesn't affect performance negatively right? (in most cases, when acquiring, state will be OPEN). Now there's dup(). I think implementing dup() on a root scope is not too hard - for the child you probably need some trick, but probably not too bad - in the sense that in a Child scope, the cleanup action is really the increment of the root exit scope. So you could have a: close(boolean doCleanup) like we do now, and avoid the cleanup on dup (which in the case of the Child will avoid the adder increment). I *believe* this should be functionally equivalent to what we have now. One question: the more I look at the code, the less I'm sure that a close vs. access race cannot occur. I'm considering this situation: * thread 1 does acquire, and find state == OPEN * thread 2 does close, set state to CLOSING, then checks if the adders match But, how can we be sure that the value we get back from the adder (e.g. acquires.sum()) is accurate and reflects the fact that thread (1) has entered already? The API doesn't seem to provide any such guarantee: " The returned value is /NOT/ an atomic snapshot; invocation in the absence of concurrent updates returns an accurate result, but concurrent updates that occur while the sum is being calculated might not be incorporated." I guess perhaps the trick is in that "while" ? E.g. there's no guarantee only if the concurrent update occurs _while_ sum() is called. Now I think this is ok - because when acquire races with close we can have two cases: 1) "state" has been set to CLOSING _before_ it is read inside acquire() 2) "state" has been set to CLOSING _after_ it is read inside acquire() In the case (1), acquire will start spinning, so nothing can harmful can really happen here. Either the read of "state" from acquire() happened when "state" is about to transition to CLOSED (in which case it will fail soon after) - or the read happened before close() had a chance to look at the counter - in which case there might be a chance that the counter will be updated concurrently (e.g. acquire() thread calls increment() while close() thread calls sum()). But there will be two outcomes here: either the adder has missed the update, in which case the segment will be close, and acquire() will fail; or the adder got the update, in which case close() will fail and acquire() will fail. In the case (2) we have an happen before edge between the "state" read performed by acquire() and the "state" write performed by close(). Which means that, by the time? we get to calling acquires.sum() we are guaranteed that the thread doing the close() will have seen the adder update from the thread doing the acquire (since the update comes _before_ the volatile read in the acquire() method). So, for this case we have that: * [acquire] acquires.increment() happens before * [acquire] state > OPEN happens before * [close] state = CLOSING happens before * [close] acquires.sum() Which, I think, proves that the thread performing the acquire cannot possibly have assumed that the scope is OPEN and also updating the adder concurrently with the call to sum() in the close thread. Maurizio On 01/05/2020 14:00, Peter Levart wrote: > > On 4/30/20 8:10 PM, Maurizio Cimadamore wrote: >> >> On 30/04/2020 01:06, Peter Levart wrote: >>> Think differently: what if the client succeeded in closing the >>> segment, just because it did it in a time window when no thread in >>> the thread pool held an open scope (this is entirely possible with >>> parallel stream for example since threads periodically acquire and >>> close scopes). This would have the same effect on threads in the >>> thread pool - they would not be able to continue their work... What >>> I'm trying to say is that this is just a mechanism to make things >>> safe, not to coordinate work. If program wants to avoid trouble, it >>> must carefully coordinate work of threads. >> >> This appear to me to be a bit of a slippery slope? Sure, if somebody >> prematurely calls close() on a segment while other threads are >> accessing it, it could be seen as undefined behavior (a la C >> specifications ;-) ), but then, if you pull on the same string, why >> even bother with confinement in the first place? If you call close() >> prematurely and you get a VM crash that's on you? > > > Luckily, I think I have fixed this shortcoming in the alternative > MemoryScope: > > > http://cr.openjdk.java.net/~plevart/jdk-dev/8243491_MemoryScope/v2/MemoryScope.java > > > > The trick is in using a 'state' with 3 values: OPEN, CLOSING, CLOSED ... > > > The acquiring thread does the following in order: > > - increments the 'acquires' scalable counter (volatile write) > > - reads the 'state' (volatile read) and then enters a spin-loop: > > ??? - if state == STATE_OPEN the acquire succeeded (this is fast > path); else > > ??? - if state == STATE_CLOSING it spin-loops re-reading 'state' in > each iteration; else > > ??? - if state == STATE_CLOSED it increments 'releases' scalable > counter and throws exception > > > The closing thread does the following in order: > > - writes STATE_CLOSING to 'state' (volatile write) > > - sums the 'releases' scalable counter (volatile reads) > > - sums the 'acquires' scalable counter (volatile reads) > > - compares both sums and: > > ??? - if they don't match then it writes back STATE_OPEN to 'state' > (volatile write) and throws exception; else > > ??? - it writes STATE_CLOSED to 'state' (volatile write) and executes > cleanup action > > > This, I think, is better, isn't it? > > > Regards, Peter > > > > > >> Maurizio >> >> From maurizio.cimadamore at oracle.com Fri May 1 14:53:42 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 1 May 2020 15:53:42 +0100 Subject: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator) In-Reply-To: References: <2fc767e1-c4bc-65ca-230d-9f7224f4ebe8@gmail.com> <7703864a-486a-36f1-7983-14df8923b71f@oracle.com> <790dc9a2-2807-4758-9f97-d0d3a8f2dcd0@oracle.com> <7e244f2b-fb78-c399-3dc7-be699396c3ea@oracle.com> <021a1013-cabc-760f-a1e4-5b36ed26f60a@gmail.com> <4d0bfd55-5792-7172-287f-7059e1499bcc@oracle.com> Message-ID: <600d8576-b32f-a6ee-df5d-effb40910c85@oracle.com> On 01/05/2020 15:31, Peter Levart wrote: > So WDYT? Is it ok to propose this for panama? How do I proceed? You can do a pull request against this branch: https://github.com/openjdk/panama-foreign/tree/foreign-memaccess Cheers Maurizio From Roger.Riggs at oracle.com Fri May 1 14:57:02 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 1 May 2020 10:57:02 -0400 Subject: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException In-Reply-To: <3b4efc42-f45f-820f-44af-89c3fa28ac39@oracle.com> References: <2b1a70a8-7d0a-9d7a-b48d-69de03b07e2e@oracle.com> <3b4efc42-f45f-820f-44af-89c3fa28ac39@oracle.com> Message-ID: <79d34810-8956-4330-5468-e1b754375034@oracle.com> +1, BTW, Stuart you are a Reviewer, no need for a 2nd. Roger On 5/1/20 12:02 AM, Stuart Marks wrote: > Hi Jay, > > OK, welcome! I'll sponsor this changeset for you. It's pretty simple, > so I'll just paste the exported changeset below. (For complicated > changesets, you'll have to ask a sponsor to host a webrev on > cr.openjdk.java.net for you.) Please check the Contributed-by line in > the changeset to make sure the attribution is correct. I just copied > the From: line from your email, but if you want it to be different, > please let me know. > > I'll update the bug report with a pointer to this email thread. > > ? https://bugs.openjdk.java.net/browse/JDK-6415694 > > Could I get a Reviewer to review this? Thanks. > > (I noticed that the anachronistic markup is used here instead > of the preferred {@code ...} javadoc tag. However, is used all > over this package, so I didn't think that changing it in just one > place would be helpful.) > > I'll also note again that since this is merely an editorial wording > change to the specification, I don't think it needs a CSR request. > > Thanks, > > s'marks > > > > > > # HG changeset patch > # User smarks > # Date 1588290431 25200 > #????? Thu Apr 30 16:47:11 2020 -0700 > # Node ID 1f5b3876d1500a2e77d6e39d079649964ba6dd26 > # Parent? fe6548dc92de4c875467c968ee37e7c9bbee1697 > 6415694: Clarification in Javadoc for java.rmi.AlreadyBoundException > Reviewed-by: XXX > Contributed-by: Jayashree Sk1 > > diff -r fe6548dc92de -r 1f5b3876d150 > src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java > --- a/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java > Thu Apr 30 15:21:15 2020 -0700 > +++ b/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java > Thu Apr 30 16:47:11 2020 -0700 > @@ -26,8 +26,8 @@ > > ?/** > ? * An AlreadyBoundException is thrown if an attempt > - * is made to bind an object in the registry to a name that already > - * has an associated binding. > + * is made to bind an object to a name that already > + * has an associated binding in the registry. > ? * > ? * @since?? 1.1 > ? * @author? Ann Wollrath > > > > > On 4/29/20 10:24 PM, Jayashree Sk1 wrote: >> Thanks for the review comment Stuart. Yes, I will need a sponsor, >> this is my first time here in OpenJDK. >> >> >> Regards! >> Jay >> ? -----Stuart Marks wrote: ----- >> To: Jayashree Sk1 >> From: Stuart Marks >> Date: 04/30/2020 09:22AM >> Cc: core-libs-dev at openjdk.java.net >> Subject: [EXTERNAL] Re: RFR: 6415694 Clarification in Javadoc for >> java.rmi.AlreadyBoundException >> >> The change looks fine. Although this is in a normative portion of the >> specification, the nature of the change is purely editorial, so I >> don't think it >> needs a CSR. >> >> Do you need a sponsor? >> >> s'marks >> >> On 4/29/20 2:57 AM, Jayashree Sk1 wrote: >>> Hi All, >>> ????????? Please find the below changes for the issues >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D6415694&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=rA_13vli8clPM_toR46hq8FVwH3XGr8z7cUfcQoqL-k&m=OXEC-w1xTWoJUyw_sRivRwIGmkHIUc3DllMsA_N3qIk&s=iesFFcE4NSOreLmf8vwdKzcdnFgjGE_SEERICPUFef4&e= >>> . >>> It is a description change, which was already approved by the reviewer. >>> >>> Thanks! >>> >>> diff -r 59b5bd9a7168 >>> src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java >>> --- a/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java >>> Mon Mar 16 02:16:49 2020 -0400 >>> +++ b/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java >>> Mon Mar 30 15:45:43 2020 +0530 >>> @@ -26,8 +26,8 @@ >>> ?? ?? /** >>> ??? * An AlreadyBoundException is thrown if an attempt >>> - * is made to bind an object in the registry to a name that already >>> - * has an associated binding. >>> + * is made to bind an object to a name that already >>> + * has an associated binding in the registry. >>> ??? * >>> ??? * @since?? 1.1 >>> ??? * @author? Ann Wollrath >>> >> >> From maurizio.cimadamore at oracle.com Fri May 1 15:00:23 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 1 May 2020 16:00:23 +0100 Subject: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator) In-Reply-To: <30217bef-c680-48fe-973b-07ab52682bb6@oracle.com> References: <2fc767e1-c4bc-65ca-230d-9f7224f4ebe8@gmail.com> <7703864a-486a-36f1-7983-14df8923b71f@oracle.com> <790dc9a2-2807-4758-9f97-d0d3a8f2dcd0@oracle.com> <7e244f2b-fb78-c399-3dc7-be699396c3ea@oracle.com> <021a1013-cabc-760f-a1e4-5b36ed26f60a@gmail.com> <4d0bfd55-5792-7172-287f-7059e1499bcc@oracle.com> <30217bef-c680-48fe-973b-07ab52682bb6@oracle.com> Message-ID: On 01/05/2020 15:36, Maurizio Cimadamore wrote: > in which case close() will fail and acquire() will fail. I meant close() will fail and segment will be acquired From kevin.rushforth at oracle.com Fri May 1 15:19:52 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 1 May 2020 08:19:52 -0700 Subject: jpackage signing fails with Mac jdk-14.0.1+7 In-Reply-To: References: Message-ID: Redirecting to core-libs-dev (with a Bcc to code-tools-dev) Code signing for macOS, along with the addition of notarization, has been improved for JDK 15. You might want to try the EA builds of JDK 15, which are available here: https://jdk.java.net/15/ -- Kevin On 5/1/2020 8:13 AM, Adam Carroll wrote: > Using JDK 14.0.1 on the Mac, jpackage fails when signing is requested. > This problem was observed using AdoptOpenJDK. I reported the problem to > that project and they suggested that I report the problem here. > > Platform: > > Mac OS Catalina v10.15.4 > > Architecture: > > x86 > > Description: > > This problem was seen using AdoptOpenJDK 14.0.1+7. > > Using the Mac signing option for jpackage ... --mac-sign ... I see the > following error (extra path information removed): > > /var/folders/rh/...../HelloFX.app: is already signed > > However, if the --mac-sign option is removed, the build works without a > problem. > > Reproducing the problem: > > I've created a minimal, single-class JavaFX application along with the > necessary scripts to reproduce the problem: > https://github.com/AdamCarroll/jdk14-jpackage-mac > > First clone the repo: > > $ git clone git at github.com:AdamCarroll/jdk14-jpackage-mac.git > > Checkout the tag: > > $ git checkout 1.0.0 > > Run the build (very fast as there's only one class): > > $ ./gradlew clean build > > Now run the jpackage command with the --mac-sign option as follows (this is > included in the file bin/create-signed-dmg.sh): > > $ jpackage \ > --type dmg \ > --module-path 'build/modules' \ > --verbose \ > --add-modules javafx.controls \ > --input 'build/libraries' \ > --dest "build/bundle" \ > --name HelloFX \ > --main-jar 'jdk14-jpackage-mac.jar' \ > --main-class 'demo.HelloFX' \ > --mac-sign > > You will now see a long error that includes the following: > > /var/folders/rh/...jdk.incubator.jpackage..../HelloFX.app: is already signed > java.io.IOException: Command [codesign, -s, Developer ID Application: Your > Name Here (XXXXXXXXXX), -vvvv, > /var/folders/rh/...jdk.incubator.jpackage.../HelloFX.app] exited with 1 code > at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.Executor.executeExpectSuccess(Executor.java:73) > at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:179) > at > jdk.incubator.jpackage/jdk.incubator.jpackage.internal.IOUtils.exec(IOUtils.java:150) > ... > > If you now run the same command but without the --mac-sign option (or > alternatively use the script bin/create-unsigned-dmg.sh), everything works > without problems. > > You can find the original issue report to the AdoptOpenJDK repository here: > https://github.com/AdoptOpenJDK/openjdk-build/issues/1718 From alexey.semenyuk at oracle.com Fri May 1 20:00:04 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 1 May 2020 16:00:04 -0400 Subject: RFR: JDK-8244220 : Compiler error in jpackage with VS2019 In-Reply-To: References: Message-ID: <1ce0bd1f-5ad2-0679-60fc-f330dcb5ad19@oracle.com> Please review fix [2] for jpackage bug [1]. Fix vs2019 compliation error. - Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8244220 [2]?http://cr.openjdk.java.net/~asemenyuk/8244220/webrev.00 From stuart.marks at oracle.com Fri May 1 20:01:53 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 1 May 2020 13:01:53 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes Message-ID: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> Hi all, I'm taking another swing at this one. I've taken a minimal approach compared to my previous proposals. Briefly, AbstractSet.removeAll switches from iterating this collection and calling contains() on its argument, to iterating the argument and calling this.contains(), if the argument collection is smaller than this collection. This attempt at optimization is incorrect, because this collection and the argument collection might have different semantics for contains(). There is a confounding performance problem, which is that if the argument is a List, contains() is generally linear, which can result in pathologically slow (O(m*n)) performance. Because of the iteration-switching above, this performance problem can appear and disappear based on the relative sizes, which is startling. The fix for the semantic problem is simply to remove the attempted optimization from AbstractSet. This comports with the specification of Collection.removeAll and Set.removeAll, which imply that contains() is called on the argument collection. This allows sets to inherit the implementation in AbstractCollection.removeAll. In addition, this ensures that removeAll is now always the complement of retainAll (as it should be), which it sometimes was not when the optimization was in place. IdentityHashMap's keySet and entrySet views were broken by this optimization, so they had to override removeAll with copies of the implementation from AbstractCollection. Since they can now inherit from AbstractCollection, these overrides have been removed. This leaves a potential performance problem with removeAll when the argument is a List. To mitigate this, HashSet.removeAll switches to iterating the argument if the argument is a List. This is safe, as both HashSet and List use the same semantics for contains() (at least, as far as I know). I've opted not to pursue size-based optimizations at this time, since they provide only incremental benefit, whereas the pathological performance problem mentioned above is the primary issue. Also, it's actually quite difficult to determine when it's safe to switch iteration. Finally, I've added performance notes to the specifications of containsAll(), removeAll(), and retainAll(), warning about potential performance problems that can occur with repeated calls to contains() made by these methods. Bug: https://bugs.openjdk.java.net/browse/JDK-6394757 Webrev: http://cr.openjdk.java.net/~smarks/reviews/6394757/webrev.2/ Previous discussions: http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007125.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058140.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058378.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060007.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060147.html Thanks, s'marks From paul.sandoz at oracle.com Fri May 1 20:36:10 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 1 May 2020 13:36:10 -0700 Subject: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests In-Reply-To: <1886691513.405349.1587389515699.JavaMail.zimbra@u-pem.fr> References: <49F81016-55DF-4E3C-940A-A8DF8C712259@oracle.com> <1886691513.405349.1587389515699.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, Thanks for the feedback. I am gonna need to go over this with John. Some comments inline. > On Apr 20, 2020, at 6:31 AM, Remi Forax wrote: > > Hi Paul, > about the API part (not the implementation), > there are location where the same concept is described with a different names which doesn't help to understand how thing work > - vector length <=> vector lane count > - vector shape <=> vector bits size > - element size <=> lane size > > "size" should never be used (VectorSpecies.elementSize() by example ) because it's never clear if it's the byte size or the bits size, using byteSize and bitsSize as used several times in the API should be used everywhere. I agree with being explicit here e.g. s/Vector.elementSize/Vector.elementBitSize and other usages. I would prefer to consistently use length in methods to refer to the lane count, it matches more closely to an array and for thinking about bounds checking. How about on Vector: /** * Returns number of vector lanes ({@code VLENGTH}), commonly referred to as the lane count. * * @return the number of vector lanes */ public abstract int length(); And then change VectorShape.laneCount to VectorShape.laneLength. ? > > Initially, having VectorSpecies and VectorShape confuse me, it's not the shape of the vector but only it's bits size, > renaming VectorShape to VectorBitsSize will help, i think. > Shape is quite a fundamental concept specified and used in the API, representing the information capacity of a vector. I think it would be misleading to refer to it only as VectorBitSize and unwieldy to change the specification accordingly. In this sense it serves as a useful abstraction to talk about vectors of the same bit size, and operations that change that size or not (such as shape-changing or shape-invariant). > You have the same values defined at several places in the API (sometimes with different names), usually it's aliases but it makes the API bigger that it should. > I think all the reference to the element type, vector byte size, vector bit size, element byte size, element byte size, vector lane count should not appear on Vector because they are accessible from Species, > and to go from a vector to the corresponding species, species() is enough. > But it also makes it less usable, esp. for length(). > You have also the same methods defined at several places, on VectorSpecies and as a static method taking a species as parameter, > all the methods of VectorSpecies that takes or return a vector/mask/shuffle should be static in vector/mask/shuffle. > It?s a little more nuanced, but I agree there is some duplication e.g. VectorSpecies.fromByteArray compared to the richer set of methods defined on [E]Vector. I think we can remove that method from VectorSpecies. Then I think we are dealing with the more ?erased/reflective? and long carrier accepting methods for general operation without appealing to E. > I think Binary and Associative should be merged to one VectorOperation, given that the difference is subtle and the whole point of this API is that if the hardware do not provide a way to reduce a binary op, it can be done in Java. Not quite true, ARM/x86 implementations do provide intrinsic implementations (leveraging a sequence of instructions) for some reduction operations e.g. min/max. I cannot recall there current state of the ARM/x86 implementations for other reductive operations but the plan is to optimize all of them at some point. Further, hardware may evolve in the future. > > I have no idea what a Conversion.rangeType() is ? > It?s the element type of the resulting output vector, Doc on VectorOperators.Operator: /** * Reports the special return type of this operator. * If this operator is a boolean, returns {@code boolean.class}. * If this operator is a {@code Conversion}, * returns its {@linkplain Conversion#rangeType range type}. * * Otherwise, the operator's return value always has * whatever type was given as an input, and this method * returns {@code Object.class} to denote that fact. * @return the special return type, or {@code Object.class} if none */ Class rangeType(); > More specially: > - VectorSpecies.loopbound() is not used in the example ? In the package-info? Yes, we should update that. > - VectorSpecies.arrayType()/genericElementType() are more for implementers than users , no ? at least arrayType should be arrayElementType. I don?t think we need to expose genericElementType in the API. I suspect arrayType may have been added before it was added to Class in 12 for the constable support. I think we can remove it. > - VectorSpecies.withLanes() => withElementType() > > - VectorMask.check* are implementer methods ? The intent is to provide abstractions so the developer can perform ?reflective" checks on vector, mask, or shuffle. > - VectorMask.equal(VectorMask) => equiv > Because it?s too close to the name ?equals?? > - VectorShuffle.check* are implementer methods ? > - VectorShuffle.vectorSpecies() => VectorShuffle.species() (as in Vector and VectorMask) Ok. > - VectorShuffle.toVector() should return a IntVector No, it returns a vector according to its species. Note the constraint that shuffle source indexes are always in the range of -VLENGTH to VLENGTH - 1. > - VectorShuffle.laneIsValid(), it seems to be an operation on Vector, not VectorShuffle. > No, its specific to shuffle for masking out exceptional indexes (those < 0). > - IntVector.max, why there is no binary version that takes a mask ? It's documented but not why it's not available. > It's to reduce the number of methods. On Vector: * This is not a full-service named operation like * {@link #add(Vector) add()}. A masked version of * this operation is not directly available * but may be obtained via the masked version of * {@code lanewise}. Subclasses define an additional * scalar-broadcast overloading of this method. > > and i'm also not a big fans of the method that returns a long instead of a vector and only works on 64 bits values. > Can you provide more details? Thanks, Paul. From stuart.marks at oracle.com Fri May 1 20:43:53 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 1 May 2020 13:43:53 -0700 Subject: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException In-Reply-To: <79d34810-8956-4330-5468-e1b754375034@oracle.com> References: <2b1a70a8-7d0a-9d7a-b48d-69de03b07e2e@oracle.com> <3b4efc42-f45f-820f-44af-89c3fa28ac39@oracle.com> <79d34810-8956-4330-5468-e1b754375034@oracle.com> Message-ID: <0d7aa064-9809-1b13-564f-d5173367645d@oracle.com> Thanks Roger. I figure I could have gotten away without an additional reviewer. :-) However, I asked for a review because I wanted someone to cross-check my decision not to file a CSR for this, despite most specification changes requiring a CSR. I also wanted to model behavior for new community members. s'marks On 5/1/20 7:57 AM, Roger Riggs wrote: > +1, > > BTW, Stuart you are a Reviewer, no need for a 2nd. > > Roger > > > On 5/1/20 12:02 AM, Stuart Marks wrote: >> Hi Jay, >> >> OK, welcome! I'll sponsor this changeset for you. It's pretty simple, so I'll >> just paste the exported changeset below. (For complicated changesets, you'll >> have to ask a sponsor to host a webrev on cr.openjdk.java.net for you.) Please >> check the Contributed-by line in the changeset to make sure the attribution is >> correct. I just copied the From: line from your email, but if you want it to >> be different, please let me know. >> >> I'll update the bug report with a pointer to this email thread. >> >> ? https://bugs.openjdk.java.net/browse/JDK-6415694 >> >> Could I get a Reviewer to review this? Thanks. >> >> (I noticed that the anachronistic markup is used here instead of the >> preferred {@code ...} javadoc tag. However, is used all over this >> package, so I didn't think that changing it in just one place would be helpful.) >> >> I'll also note again that since this is merely an editorial wording change to >> the specification, I don't think it needs a CSR request. >> >> Thanks, >> >> s'marks >> >> >> >> >> >> # HG changeset patch >> # User smarks >> # Date 1588290431 25200 >> #????? Thu Apr 30 16:47:11 2020 -0700 >> # Node ID 1f5b3876d1500a2e77d6e39d079649964ba6dd26 >> # Parent? fe6548dc92de4c875467c968ee37e7c9bbee1697 >> 6415694: Clarification in Javadoc for java.rmi.AlreadyBoundException >> Reviewed-by: XXX >> Contributed-by: Jayashree Sk1 >> >> diff -r fe6548dc92de -r 1f5b3876d150 >> src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java >> --- a/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Thu Apr >> 30 15:21:15 2020 -0700 >> +++ b/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Thu Apr >> 30 16:47:11 2020 -0700 >> @@ -26,8 +26,8 @@ >> >> ?/** >> ? * An AlreadyBoundException is thrown if an attempt >> - * is made to bind an object in the registry to a name that already >> - * has an associated binding. >> + * is made to bind an object to a name that already >> + * has an associated binding in the registry. >> ? * >> ? * @since?? 1.1 >> ? * @author? Ann Wollrath >> >> >> >> >> On 4/29/20 10:24 PM, Jayashree Sk1 wrote: >>> Thanks for the review comment Stuart. Yes, I will need a sponsor, this is my >>> first time here in OpenJDK. >>> >>> >>> Regards! >>> Jay >>> ? -----Stuart Marks wrote: ----- >>> To: Jayashree Sk1 >>> From: Stuart Marks >>> Date: 04/30/2020 09:22AM >>> Cc: core-libs-dev at openjdk.java.net >>> Subject: [EXTERNAL] Re: RFR: 6415694 Clarification in Javadoc for >>> java.rmi.AlreadyBoundException >>> >>> The change looks fine. Although this is in a normative portion of the >>> specification, the nature of the change is purely editorial, so I don't think it >>> needs a CSR. >>> >>> Do you need a sponsor? >>> >>> s'marks >>> >>> On 4/29/20 2:57 AM, Jayashree Sk1 wrote: >>>> Hi All, >>>> ????????? Please find the below changes for the issues >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D6415694&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=rA_13vli8clPM_toR46hq8FVwH3XGr8z7cUfcQoqL-k&m=OXEC-w1xTWoJUyw_sRivRwIGmkHIUc3DllMsA_N3qIk&s=iesFFcE4NSOreLmf8vwdKzcdnFgjGE_SEERICPUFef4&e= >>>> . >>>> It is a description change, which was already approved by the reviewer. >>>> >>>> Thanks! >>>> >>>> diff -r 59b5bd9a7168 >>>> src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java >>>> --- a/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Mon Mar >>>> 16 02:16:49 2020 -0400 >>>> +++ b/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Mon Mar >>>> 30 15:45:43 2020 +0530 >>>> @@ -26,8 +26,8 @@ >>>> ?? ?? /** >>>> ??? * An AlreadyBoundException is thrown if an attempt >>>> - * is made to bind an object in the registry to a name that already >>>> - * has an associated binding. >>>> + * is made to bind an object to a name that already >>>> + * has an associated binding in the registry. >>>> ??? * >>>> ??? * @since?? 1.1 >>>> ??? * @author? Ann Wollrath >>>> >>> >>> > From jorn.vernee at oracle.com Fri May 1 21:13:27 2020 From: jorn.vernee at oracle.com (Jorn Vernee) Date: Fri, 1 May 2020 23:13:27 +0200 Subject: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable In-Reply-To: References: Message-ID: <4cfb2ae9-cd5b-49a0-be99-b0d6d70486de@oracle.com> The CSR for this patch is now Approved, so it looks like this patch is ready to be sponsored. Here are the relevant links again. Bug: https://bugs.openjdk.java.net/browse/JDK-8241100 CSR: https://bugs.openjdk.java.net/browse/JDK-8241667 Patch: http://cr.openjdk.java.net/~jvernee/8241100/webrev.04/ Thanks, Jorn On 18/03/2020 15:08, Jorn Vernee wrote: > Hi, > > Can someone please sponsor this patch that makes Boolean, Character, > Byte, and Short implement Constable? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241100 > Webrev: http://cr.openjdk.java.net/~jvernee/8241100/webrev.00/ > > Having the other box types implement Constable makes them easier to > use with APIs that accept any Constable. Though I'm mostly interesting > in boolean, for which I'm currently falling back to "true" & "false" > strings, but the downside is that this also requires parsing the > string again and having to deal with random other strings. > > This patch also adds the ConstantBootstraps::convert method that is > used to facilitate the conversion from int to (short|char|byte). This > currently takes a source type explicitly. In practice, it seems that > Object can always be used as a source type for the same behavior, but > explicitly specifying source and destination types seems more robust > to me in case this behavior ever changes, or we want to expand on the > supported kinds of conversion. (for instance it is currently not > possible to convert from an int to a Long directly, or from Short to > Integer, but maybe those cases could be supported in the future as well). > > Testing: tier1-3 & downstream testing for my particular use case > > Thanks, > Jorn > From alexander.matveev at oracle.com Fri May 1 21:21:43 2020 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Fri, 1 May 2020 14:21:43 -0700 Subject: RFR: JDK-8244220 : Compiler error in jpackage with VS2019 In-Reply-To: <1ce0bd1f-5ad2-0679-60fc-f330dcb5ad19@oracle.com> References: <1ce0bd1f-5ad2-0679-60fc-f330dcb5ad19@oracle.com> Message-ID: Hi Alexey, Looks fine. Thanks, Alexander On 5/1/20 1:00 PM, Alexey Semenyuk wrote: > Please review fix [2] for jpackage bug [1]. > > Fix vs2019 compliation error. > > - Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8244220 > > [2]?http://cr.openjdk.java.net/~asemenyuk/8244220/webrev.00 > From paul.sandoz at oracle.com Fri May 1 21:25:36 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 1 May 2020 14:25:36 -0700 Subject: Sponsor Request: 8241100: Make Boolean, Character, Byte, and Short implement Constable In-Reply-To: <4cfb2ae9-cd5b-49a0-be99-b0d6d70486de@oracle.com> References: <4cfb2ae9-cd5b-49a0-be99-b0d6d70486de@oracle.com> Message-ID: I?ll push it for you, Paul. > On May 1, 2020, at 2:13 PM, Jorn Vernee wrote: > > The CSR for this patch is now Approved, so it looks like this patch is ready to be sponsored. > > Here are the relevant links again. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8241100 > CSR: https://bugs.openjdk.java.net/browse/JDK-8241667 > Patch: http://cr.openjdk.java.net/~jvernee/8241100/webrev.04/ > > Thanks, > Jorn > > On 18/03/2020 15:08, Jorn Vernee wrote: >> Hi, >> >> Can someone please sponsor this patch that makes Boolean, Character, Byte, and Short implement Constable? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8241100 >> Webrev: http://cr.openjdk.java.net/~jvernee/8241100/webrev.00/ >> >> Having the other box types implement Constable makes them easier to use with APIs that accept any Constable. Though I'm mostly interesting in boolean, for which I'm currently falling back to "true" & "false" strings, but the downside is that this also requires parsing the string again and having to deal with random other strings. >> >> This patch also adds the ConstantBootstraps::convert method that is used to facilitate the conversion from int to (short|char|byte). This currently takes a source type explicitly. In practice, it seems that Object can always be used as a source type for the same behavior, but explicitly specifying source and destination types seems more robust to me in case this behavior ever changes, or we want to expand on the supported kinds of conversion. (for instance it is currently not possible to convert from an int to a Long directly, or from Short to Integer, but maybe those cases could be supported in the future as well). >> >> Testing: tier1-3 & downstream testing for my particular use case >> >> Thanks, >> Jorn >> From philip.race at oracle.com Fri May 1 22:21:03 2020 From: philip.race at oracle.com (Philip Race) Date: Fri, 01 May 2020 15:21:03 -0700 Subject: RFR: JDK-8244220 : Compiler error in jpackage with VS2019 In-Reply-To: <1ce0bd1f-5ad2-0679-60fc-f330dcb5ad19@oracle.com> References: <1ce0bd1f-5ad2-0679-60fc-f330dcb5ad19@oracle.com> Message-ID: <5EACA0CF.9020706@oracle.com> It may be self-evident but I really like to see a RFR include an evaluation and explanation of the fix and the same in the bug report. Please do both. -phil. On 5/1/20, 1:00 PM, Alexey Semenyuk wrote: > Please review fix [2] for jpackage bug [1]. > > Fix vs2019 compliation error. > > - Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8244220 > > [2] http://cr.openjdk.java.net/~asemenyuk/8244220/webrev.00 > From stuart.marks at oracle.com Fri May 1 22:45:40 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 1 May 2020 15:45:40 -0700 Subject: Collections.synchronizedXXX() and internal mutex (aka SyncRoot) In-Reply-To: References: <6f88885e-fe66-5ae2-4746-74a4e959a350@oracle.com> Message-ID: On 5/1/20 2:02 AM, dmytro sheyko wrote: > The checked, synchronized and unmodifiable wrappers in some cases store backing > collection in more than one fields. > > Thus `UnmodifiableList` has > 1. its own field `List list` and > 2. `Collection c`, which it inherits from `UnmodifiableCollection`. > > Also `UnmodifiableNavigableSet` has even 3 duplicated fields: > 1. its own `NavigableSet ns`, > 2. `SortedSet ss` from `UnmodifiableSortedSet` and > 3. `Collection c` from `UnmodifiableCollection`. > > Isn't it worth to get rid of such duplication? (at least for unmodifiable > collections). This may affect serialization, but I believe it's still possible > preserve serialization backward compatible, if it's necessary. > Or is it done intentionally? Interesting. I went through some of the history here, in particular the core-libs-dev review threads of JDK-7129185 [1] which was the last time significant work was done on the wrappers. There was no mention of the duplicate references in any of the reviews. I suspect the wrappers introduced in this changeset (e.g., UnmodifiableNavigableSet) copied the style from existing wrappers, which also used this style. I was able to look through the old (non open source) history of the JDK, and I found that this style of having a redundant field in a wrapper subtype was introduced in JDK 1.2 in 1998 along with the original collections implementation. I suspect it was done this way for convenience. Certainly the wrapper subclasses have access to the field from the superclass. But to use it they there would have to be a cast at every call site that wanted to use a subclass method. This would certainly make the wrapper code more verbose, and it might even slow things down a bit with checkcast bytecodes and such. While trying to save space is laudable, compatibility with existing serial forms needs to be preserved. Doing this would require adding serialPersistentFields arrays and readObject() and writeObject() methods to every one of the wrapper classes. This is fairly tedious and error-prone. I'm not sure it's worth it. s'marks [1] https://bugs.openjdk.java.net/browse/JDK-7129185 From alexey.semenyuk at oracle.com Fri May 1 23:18:41 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 1 May 2020 19:18:41 -0400 Subject: RFR: JDK-8244220 : Compiler error in jpackage with VS2019 In-Reply-To: <5EACA0CF.9020706@oracle.com> References: <1ce0bd1f-5ad2-0679-60fc-f330dcb5ad19@oracle.com> <5EACA0CF.9020706@oracle.com> Message-ID: <0e8bf2de-cc64-3cd3-21ef-4fff0dd6d91d@oracle.com> Evaluation: Code snippet at memory(1871): --- ??? ~unique_ptr() noexcept { ??????? if (_Mypair._Myval2) { ??????????? _Mypair._Get_first()(_Mypair._Myval2); ??????? } ??? } --- Where '_Myval2' is of type jni::JniObjWithEnv defined in JniUtils.h. JniObjWithEnv is a struct wrapping two pointers: JNIEnv* and jobject. It requires user defined bool operator to make code in ~unique_ptr() compile. By some reason vs2017 didn't complain on missing bool operator. I've added the evaluation in the comments section of the bug report as well. - Alexey On 5/1/2020 6:21 PM, Philip Race wrote: > It may be self-evident but I really like to see a RFR include an > evaluation > and explanation of the fix and the same in the bug report. > > Please do both. > > -phil. > > On 5/1/20, 1:00 PM, Alexey Semenyuk wrote: >> Please review fix [2] for jpackage bug [1]. >> >> Fix vs2019 compliation error. >> >> - Alexey >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8244220 >> >> [2] http://cr.openjdk.java.net/~asemenyuk/8244220/webrev.00 >> From philip.race at oracle.com Fri May 1 23:31:48 2020 From: philip.race at oracle.com (Philip Race) Date: Fri, 01 May 2020 16:31:48 -0700 Subject: RFR: JDK-8244220 : Compiler error in jpackage with VS2019 In-Reply-To: <0e8bf2de-cc64-3cd3-21ef-4fff0dd6d91d@oracle.com> References: <1ce0bd1f-5ad2-0679-60fc-f330dcb5ad19@oracle.com> <5EACA0CF.9020706@oracle.com> <0e8bf2de-cc64-3cd3-21ef-4fff0dd6d91d@oracle.com> Message-ID: <5EACB164.7080805@oracle.com> OK. Approved. -phil. On 5/1/20, 4:18 PM, Alexey Semenyuk wrote: > Evaluation: > > Code snippet at memory(1871): > --- > ~unique_ptr() noexcept { > if (_Mypair._Myval2) { > _Mypair._Get_first()(_Mypair._Myval2); > } > } > --- > > Where '_Myval2' is of type jni::JniObjWithEnv defined in JniUtils.h. > > JniObjWithEnv is a struct wrapping two pointers: JNIEnv* and jobject. > It requires user defined bool operator to make code in ~unique_ptr() > compile. By some reason vs2017 didn't complain on missing bool operator. > > I've added the evaluation in the comments section of the bug report as > well. > > - Alexey > > On 5/1/2020 6:21 PM, Philip Race wrote: >> It may be self-evident but I really like to see a RFR include an >> evaluation >> and explanation of the fix and the same in the bug report. >> >> Please do both. >> >> -phil. >> >> On 5/1/20, 1:00 PM, Alexey Semenyuk wrote: >>> Please review fix [2] for jpackage bug [1]. >>> >>> Fix vs2019 compliation error. >>> >>> - Alexey >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8244220 >>> >>> [2] http://cr.openjdk.java.net/~asemenyuk/8244220/webrev.00 >>> > From vladimir.kozlov at oracle.com Sat May 2 00:31:37 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 1 May 2020 17:31:37 -0700 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes In-Reply-To: References: Message-ID: Changes seems fine. Nice work. Why it is called "vector-unstable branch"? Thanks, Vladimir K On 4/3/20 5:16 PM, Viswanathan, Sandhya wrote: > Hi, > > > Following up on review requests of API [0], Java implementation [1] and > > General Hotspot changes[3] for Vector API, here's a request for review > > of x86 backend changes required for supporting the API: > > > > JEP: https://openjdk.java.net/jeps/338 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223347 > > Webrev:http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00/ > > > > Complete implementation resides in vector-unstable branch of > > panama/dev repository [3]. > > Looking forward to your feedback. > > Best Regards, > Sandhya > > > [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html > > > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065587.html > > > > [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037798.html > > > > [3] https://openjdk.java.net/projects/panama/ > > $ hg clone http://hg.openjdk.java.net/panama/dev/ -b vector-unstable > > > > > From sandhya.viswanathan at intel.com Sat May 2 00:55:57 2020 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Sat, 2 May 2020 00:55:57 +0000 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes In-Reply-To: References: Message-ID: Hi Vladimir, Thanks a lot for the feedback. We used an old existing separate branch to share the code for review and to track changes. We didn?t know how to change the name of the branch from vector-unstable to vector-stable. Best Regards, Sandhya -----Original Message----- From: Vladimir Kozlov Sent: Friday, May 01, 2020 5:32 PM To: Viswanathan, Sandhya ; hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; hotspot-dev Subject: Re: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes Changes seems fine. Nice work. Why it is called "vector-unstable branch"? Thanks, Vladimir K On 4/3/20 5:16 PM, Viswanathan, Sandhya wrote: > Hi, > > > Following up on review requests of API [0], Java implementation [1] and > > General Hotspot changes[3] for Vector API, here's a request for review > > of x86 backend changes required for supporting the API: > > > > JEP: https://openjdk.java.net/jeps/338 > > JBS: https://bugs.openjdk.java.net/browse/JDK-8223347 > > Webrev:http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00/ > > > > Complete implementation resides in vector-unstable branch of > > panama/dev repository [3]. > > Looking forward to your feedback. > > Best Regards, > Sandhya > > > [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html > > > > [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065587.html > > > > [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037798.html > > > > [3] https://openjdk.java.net/projects/panama/ > > $ hg clone http://hg.openjdk.java.net/panama/dev/ -b vector-unstable > > > > > From vladimir.kozlov at oracle.com Sat May 2 01:05:19 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 1 May 2020 18:05:19 -0700 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes In-Reply-To: References: Message-ID: <5b4f8d0f-d355-8914-193a-3c87eccf2d34@oracle.com> On 5/1/20 5:55 PM, Viswanathan, Sandhya wrote: > Hi Vladimir, > > Thanks a lot for the feedback. > > We used an old existing separate branch to share the code for review and to track changes. > We didn?t know how to change the name of the branch from vector-unstable to vector-stable. Good to know that it does not mean that code is "unstable" ;) Katya filed today new bug [1]. Please look. Regards, Vladimir [1] https://bugs.openjdk.java.net/browse/JDK-8244269 > > Best Regards, > Sandhya > > -----Original Message----- > From: Vladimir Kozlov > Sent: Friday, May 01, 2020 5:32 PM > To: Viswanathan, Sandhya ; hotspot-compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; hotspot-dev > Subject: Re: RFR (XXL): 8223347: Integration of Vector API (Incubator): x86 backend changes > > Changes seems fine. Nice work. > > Why it is called "vector-unstable branch"? > > Thanks, > Vladimir K > > On 4/3/20 5:16 PM, Viswanathan, Sandhya wrote: >> Hi, >> >> >> Following up on review requests of API [0], Java implementation [1] and >> >> General Hotspot changes[3] for Vector API, here's a request for review >> >> of x86 backend changes required for supporting the API: >> >> >> >> JEP: https://openjdk.java.net/jeps/338 >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8223347 >> >> Webrev:http://cr.openjdk.java.net/~sviswanathan/VAPI_RFR/x86_webrev/webrev.00/ >> >> >> >> Complete implementation resides in vector-unstable branch of >> >> panama/dev repository [3]. >> >> Looking forward to your feedback. >> >> Best Regards, >> Sandhya >> >> >> [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html >> >> >> >> [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065587.html >> >> >> >> [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037798.html >> >> >> >> [3] https://openjdk.java.net/projects/panama/ >> >> $ hg clone http://hg.openjdk.java.net/panama/dev/ -b vector-unstable >> >> >> >> >> From jason_mehrens at hotmail.com Sat May 2 05:41:35 2020 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Sat, 2 May 2020 05:41:35 +0000 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> Message-ID: 1. I assume you are using "c instanceof List" instead of "!(c instanceof Set)" to correctly handle IdentitityHashMap.values()? The instanceof List seems like safe choice but it is too bad we can still fool that check by wrapping List as an unmodifiableCollection. If splitIterator().characteristics() could tell us that the collection used identity comparisons I think we would be able to determine if it was safe to swap the ordering in the general case as we could check for IDENTITY, SORTED, and comparator equality. 2. Should code applied to HashSet.removeAll also be applied to HashMap.keySet().removeAll and HashMap.entrySet().removeAll? Collections::newSetFromMap will end up having different behavior if it is not consistently applied. 3. Not to derail this thread but do think we need a new JIRA ticket to address Collections.disjoint? Seems like it has similar sins of calling size and using "!(c2 instanceof Set)" but I don't want to muddy the waters by covering any solutions to that method in this thread. Jason ________________________________________ From: core-libs-dev on behalf of Stuart Marks Sent: Friday, May 1, 2020 3:01 PM To: core-libs-dev Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes Hi all, I'm taking another swing at this one. I've taken a minimal approach compared to my previous proposals. Briefly, AbstractSet.removeAll switches from iterating this collection and calling contains() on its argument, to iterating the argument and calling this.contains(), if the argument collection is smaller than this collection. This attempt at optimization is incorrect, because this collection and the argument collection might have different semantics for contains(). There is a confounding performance problem, which is that if the argument is a List, contains() is generally linear, which can result in pathologically slow (O(m*n)) performance. Because of the iteration-switching above, this performance problem can appear and disappear based on the relative sizes, which is startling. The fix for the semantic problem is simply to remove the attempted optimization from AbstractSet. This comports with the specification of Collection.removeAll and Set.removeAll, which imply that contains() is called on the argument collection. This allows sets to inherit the implementation in AbstractCollection.removeAll. In addition, this ensures that removeAll is now always the complement of retainAll (as it should be), which it sometimes was not when the optimization was in place. IdentityHashMap's keySet and entrySet views were broken by this optimization, so they had to override removeAll with copies of the implementation from AbstractCollection. Since they can now inherit from AbstractCollection, these overrides have been removed. This leaves a potential performance problem with removeAll when the argument is a List. To mitigate this, HashSet.removeAll switches to iterating the argument if the argument is a List. This is safe, as both HashSet and List use the same semantics for contains() (at least, as far as I know). I've opted not to pursue size-based optimizations at this time, since they provide only incremental benefit, whereas the pathological performance problem mentioned above is the primary issue. Also, it's actually quite difficult to determine when it's safe to switch iteration. Finally, I've added performance notes to the specifications of containsAll(), removeAll(), and retainAll(), warning about potential performance problems that can occur with repeated calls to contains() made by these methods. Bug: https://bugs.openjdk.java.net/browse/JDK-6394757 Webrev: http://cr.openjdk.java.net/~smarks/reviews/6394757/webrev.2/ Previous discussions: http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007125.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058140.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058378.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060007.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060147.html Thanks, s'marks From peter.levart at gmail.com Sat May 2 08:45:28 2020 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 2 May 2020 10:45:28 +0200 Subject: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator) In-Reply-To: <30217bef-c680-48fe-973b-07ab52682bb6@oracle.com> References: <2fc767e1-c4bc-65ca-230d-9f7224f4ebe8@gmail.com> <7703864a-486a-36f1-7983-14df8923b71f@oracle.com> <790dc9a2-2807-4758-9f97-d0d3a8f2dcd0@oracle.com> <7e244f2b-fb78-c399-3dc7-be699396c3ea@oracle.com> <021a1013-cabc-760f-a1e4-5b36ed26f60a@gmail.com> <4d0bfd55-5792-7172-287f-7059e1499bcc@oracle.com> <30217bef-c680-48fe-973b-07ab52682bb6@oracle.com> Message-ID: <111ffdb1-131a-b163-5751-b2d4a71929c9@gmail.com> Hi Maurizio, On 5/1/20 4:36 PM, Maurizio Cimadamore wrote: > > Hi Peter, > this does look better yes. > > I suspect this doesn't affect performance negatively right? (in most > cases, when acquiring, state will be OPEN). > > Now there's dup(). I think implementing dup() on a root scope is not > too hard - for the child you probably need some trick, but probably > not too bad - in the sense that in a Child scope, the cleanup action > is really the increment of the root exit scope. So you could have a: > > close(boolean doCleanup) > > like we do now, and avoid the cleanup on dup (which in the case of the > Child will avoid the adder increment). I *believe* this should be > functionally equivalent to what we have now. > I'll look into optimizing this part. > One question: the more I look at the code, the less I'm sure that a > close vs. access race cannot occur. I'm considering this situation: > > * thread 1 does acquire, and find state == OPEN > * thread 2 does close, set state to CLOSING, then checks if the adders > match > > But, how can we be sure that the value we get back from the adder > (e.g. acquires.sum()) is accurate and reflects the fact that thread > (1) has entered already? > Because of ordering. All 4 actions are volatile reads or writes. So we can linearize them: Thread 1 does: a) increments 'acquires' b) reads OPEN from 'state' Thread 2 does: c) writes CLOSING to 'state' d) sums 'acquires' 'a' happens before 'b' happens before 'c' happens before 'd' => 'a' happens before 'd' > The API doesn't seem to provide any such guarantee: > > " The returned value is /NOT/ an atomic snapshot; invocation in the > absence of concurrent updates returns an accurate result, but > concurrent updates that occur while the sum is being calculated might > not be incorporated." > As far as the relation of action 'a' to action 'd' is concerned, those two actions are not concurrent. They are clearly 'a' happens before 'd', so in 'd' we are guaranteed to see the effects of 'a'. Surely we may also see the effects of other concurrent updates. But what those concurrent updates do is increment the 'acquires' counter (more precisely one of the counters in LongAdder). So we may see an even larger sum, never smaller (unless overflow happens, but then the sum won't be any "closer" to the sum of 'releases', only further away). What is important here is that we will not miss the update of action 'a' above. The important part is also that we 1st do a sum of 'releases' and then sum of 'acquires'. That way we will never miss an update of 'acquires' if we saw a related update of 'releases' made by same thread, because the acquiring thread 1st increments 'acquires' and then, when finished, increments 'releases'. It's all a play of action orderings. > I guess perhaps the trick is in that "while" ? E.g. there's no > guarantee only if the concurrent update occurs _while_ sum() is called. > The while loop is just an addition to prevent spurious acquire failures. It has nothing to do with "detection". > Now I think this is ok - because when acquire races with close we can > have two cases: > > 1) "state" has been set to CLOSING _before_ it is read inside acquire() > 2) "state" has been set to CLOSING _after_ it is read inside acquire() > > In the case (1), acquire will start spinning, so nothing can harmful > can really happen here. Either the read of "state" from acquire() > happened when "state" is about to transition to CLOSED (in which case > it will fail soon after) - or the read happened before close() had a > chance to look at the counter - in which case there might be a chance > that the counter will be updated concurrently (e.g. acquire() thread > calls increment() while close() thread calls sum()). But there will be > two outcomes here: either the adder has missed the update, in which > case the segment will be close, and acquire() will fail; or the adder > got the update, in which case close() will fail and acquire() will fail. > > In the case (2) we have an happen before edge between the "state" read > performed by acquire() and the "state" write performed by close(). > Which means that, by the time? we get to calling acquires.sum() we are > guaranteed that the thread doing the close() will have seen the adder > update from the thread doing the acquire (since the update comes > _before_ the volatile read in the acquire() method). So, for this case > we have that: > > * [acquire] acquires.increment() happens before > * [acquire] state > OPEN happens before > * [close] state = CLOSING happens before > * [close] acquires.sum() > > Which, I think, proves that the thread performing the acquire cannot > possibly have assumed that the scope is OPEN and also updating the > adder concurrently with the call to sum() in the close thread. > But you just showed above that acquires.increment() (by acquiring thread) happens before acquires.sum() (by closing thread) - they don't execute concurrently, so closing thread can not possibly see the sum of 'acquires' be equal to the sum of 'releases' (which has been taken just before the sum of acquires) and therefore it will transition state back to OPEN and throw exception. So close will fail and acquire will succeed. Regards, Peter > Maurizio > > On 01/05/2020 14:00, Peter Levart wrote: >> >> On 4/30/20 8:10 PM, Maurizio Cimadamore wrote: >>> >>> On 30/04/2020 01:06, Peter Levart wrote: >>>> Think differently: what if the client succeeded in closing the >>>> segment, just because it did it in a time window when no thread in >>>> the thread pool held an open scope (this is entirely possible with >>>> parallel stream for example since threads periodically acquire and >>>> close scopes). This would have the same effect on threads in the >>>> thread pool - they would not be able to continue their work... What >>>> I'm trying to say is that this is just a mechanism to make things >>>> safe, not to coordinate work. If program wants to avoid trouble, it >>>> must carefully coordinate work of threads. >>> >>> This appear to me to be a bit of a slippery slope? Sure, if somebody >>> prematurely calls close() on a segment while other threads are >>> accessing it, it could be seen as undefined behavior (a la C >>> specifications ;-) ), but then, if you pull on the same string, why >>> even bother with confinement in the first place? If you call close() >>> prematurely and you get a VM crash that's on you? >> >> >> Luckily, I think I have fixed this shortcoming in the alternative >> MemoryScope: >> >> >> http://cr.openjdk.java.net/~plevart/jdk-dev/8243491_MemoryScope/v2/MemoryScope.java >> >> >> >> The trick is in using a 'state' with 3 values: OPEN, CLOSING, CLOSED ... >> >> >> The acquiring thread does the following in order: >> >> - increments the 'acquires' scalable counter (volatile write) >> >> - reads the 'state' (volatile read) and then enters a spin-loop: >> >> ??? - if state == STATE_OPEN the acquire succeeded (this is fast >> path); else >> >> ??? - if state == STATE_CLOSING it spin-loops re-reading 'state' in >> each iteration; else >> >> ??? - if state == STATE_CLOSED it increments 'releases' scalable >> counter and throws exception >> >> >> The closing thread does the following in order: >> >> - writes STATE_CLOSING to 'state' (volatile write) >> >> - sums the 'releases' scalable counter (volatile reads) >> >> - sums the 'acquires' scalable counter (volatile reads) >> >> - compares both sums and: >> >> ??? - if they don't match then it writes back STATE_OPEN to 'state' >> (volatile write) and throws exception; else >> >> ??? - it writes STATE_CLOSED to 'state' (volatile write) and executes >> cleanup action >> >> >> This, I think, is better, isn't it? >> >> >> Regards, Peter >> >> >> >> >> >>> Maurizio >>> >>> From andy.herrick at oracle.com Sat May 2 14:23:20 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Sat, 2 May 2020 10:23:20 -0400 Subject: RFR: JDK-8244220 : Compiler error in jpackage with VS2019 In-Reply-To: <0e8bf2de-cc64-3cd3-21ef-4fff0dd6d91d@oracle.com> References: <1ce0bd1f-5ad2-0679-60fc-f330dcb5ad19@oracle.com> <5EACA0CF.9020706@oracle.com> <0e8bf2de-cc64-3cd3-21ef-4fff0dd6d91d@oracle.com> Message-ID: <4457a0b7-a1ab-0f1e-1730-1e4abcabfec3@oracle.com> looks good /Andy On 5/1/20 7:18 PM, Alexey Semenyuk wrote: > Evaluation: > > Code snippet at memory(1871): > --- > ??? ~unique_ptr() noexcept { > ??????? if (_Mypair._Myval2) { > ??????????? _Mypair._Get_first()(_Mypair._Myval2); > ??????? } > ??? } > --- > > Where '_Myval2' is of type jni::JniObjWithEnv defined in JniUtils.h. > > JniObjWithEnv is a struct wrapping two pointers: JNIEnv* and jobject. > It requires user defined bool operator to make code in ~unique_ptr() > compile. By some reason vs2017 didn't complain on missing bool operator. > > I've added the evaluation in the comments section of the bug report as > well. > > - Alexey > > On 5/1/2020 6:21 PM, Philip Race wrote: >> It may be self-evident but I really like to see a RFR include an >> evaluation >> and explanation of the fix and the same in the bug report. >> >> Please do both. >> >> -phil. >> >> On 5/1/20, 1:00 PM, Alexey Semenyuk wrote: >>> Please review fix [2] for jpackage bug [1]. >>> >>> Fix vs2019 compliation error. >>> >>> - Alexey >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8244220 >>> >>> [2] http://cr.openjdk.java.net/~asemenyuk/8244220/webrev.00 >>> > From andy.herrick at oracle.com Sat May 2 14:31:09 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Sat, 2 May 2020 10:31:09 -0400 Subject: RFR: JDK-8242865: Usability problems using mac signing in jpackage Message-ID: Please review fix at [1] for issue [2] /Andy [1] - http://cr.openjdk.java.net/~herrick/8242865/webrev.01/ [2] - https://bugs.openjdk.java.net/browse/JDK-8242865 From alexey.semenyuk at oracle.com Sat May 2 15:04:59 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Sat, 2 May 2020 11:04:59 -0400 Subject: RFR: JDK-8242865: Usability problems using mac signing in jpackage In-Reply-To: References: Message-ID: <708bbc7d-e02e-6026-d1dd-b1951241c3a3@oracle.com> Looks good! - Alexey On 5/2/2020 10:31 AM, Andy Herrick wrote: > Please review fix at [1] for issue [2] > > /Andy > > [1] - http://cr.openjdk.java.net/~herrick/8242865/webrev.01/ > > [2] - https://bugs.openjdk.java.net/browse/JDK-8242865 > From peter.levart at gmail.com Sun May 3 07:28:25 2020 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 3 May 2020 09:28:25 +0200 Subject: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator) In-Reply-To: <30217bef-c680-48fe-973b-07ab52682bb6@oracle.com> References: <2fc767e1-c4bc-65ca-230d-9f7224f4ebe8@gmail.com> <7703864a-486a-36f1-7983-14df8923b71f@oracle.com> <790dc9a2-2807-4758-9f97-d0d3a8f2dcd0@oracle.com> <7e244f2b-fb78-c399-3dc7-be699396c3ea@oracle.com> <021a1013-cabc-760f-a1e4-5b36ed26f60a@gmail.com> <4d0bfd55-5792-7172-287f-7059e1499bcc@oracle.com> <30217bef-c680-48fe-973b-07ab52682bb6@oracle.com> Message-ID: On 5/1/20 4:36 PM, Maurizio Cimadamore wrote: > > Now there's dup(). I think implementing dup() on a root scope is not > too hard - for the child you probably need some trick, but probably > not too bad - in the sense that in a Child scope, the cleanup action > is really the increment of the root exit scope. So you could have a: > > close(boolean doCleanup) > > like we do now, and avoid the cleanup on dup (which in the case of the > Child will avoid the adder increment). I *believe* this should be > functionally equivalent to what we have now. > I optimized the dup() on both root and child scopes as much as possible in last version of MemoryScope. I also added some comments about usage of methods. I'll make a PR for this version incorporated in the panama shortly: http://cr.openjdk.java.net/~plevart/jdk-dev/8243491_MemoryScope/v3/MemoryScope.java Regards, Peter From amaembo at gmail.com Sun May 3 09:36:30 2020 From: amaembo at gmail.com (Tagir Valeev) Date: Sun, 3 May 2020 16:36:30 +0700 Subject: RFR: JDK-8244288 Specialized implementations for putIfAbsent, merge, compute* methods in TreeMap derived maps Message-ID: Hello! Please review the following change: https://bugs.openjdk.java.net/browse/JDK-8244288 http://cr.openjdk.java.net/~tvaleev/webrev/8244288/r1/ We already implemented putIfAbsent, merge, computeIfAbsent, computeIfPresent, and compute for TreeMap class (see JDK-8176894). However, default implementations of these methods are still used for TreeMap derived maps, such as descendingMap(), tailMap(), headMap() and subMap(). The implementation is pretty straightforward, just a range-check+delegation for each of these methods inside the TreeMap.NavigableSubMap (+32 lines in TreeMap.java). Care should be taken to avoid throwing IAE from compute* methods if the key is outside of the range but we don't actually add the entry. This mimics the previous behavior and also consistent with other modification methods like Map.remove (we don't throw from remove if the key is out of range, simply do nothing). To cover these changes with tests, I added new TreeMap().descendingMap() to InPlaceOpsCollisions.nullValueFriendlyMaps and MapWithCollisionsProviders.makeMapsMoreTypes. This map should behave like a normal Map modulo iteration order but implementation goes through NavigableSubMap. Also, I added more adders to LockStep::randomAdder (lines 572+) to cover new methods, as well as some more throws IAE asserts around line 806. At the same time, I took the liberty to modernize this test: - Convert all the raw-types to properly parameterized (using 'var' for local vars where resulting type is long) - Convert MapFrobber and SetFrobber to interfaces, and convert all the implementations to lambdas (automatic conversion via IntelliJ IDEA + rename of conflicting parameter names) - Use for-each loop instead of indexed for loop where possible - 'elts' array was created in two places but unused afterward. I added size assert to these arrays to use it at least somehow (though probably content should be checked as well). - Use Comparator.naturalOrder() instead of manually written one in comparator() methods (should not affect the testing in any way as it's only used directly, not passed e.g. to TreeMap constructor). - Use Objects.equals inside LockStep#equal - Inverted 'if' at line 299 to avoid empty block. If the cleanup really complicates the review I can post the cleanup as a separate changeset. Though it should not be very problematic as the actual changes are quite compact (as said above, near lines 572 and 806) I also improved the previously added benchmark TreeMapUpdate to check descendingMap and tailMap cases to confirm the hypothesis that the change improves the performance of derived maps. This is indeed the case. E.g. merge test yields (comparator = false, size = 1000) for unpatched JDK: (benchmark) (mode) (prefill) Score Error Units TreeMapUpdate.merge TreeMap true 63589,075 ? 1028,065 ns/op TreeMapUpdate.merge TreeMap false 65414,367 ? 1011,442 ns/op TreeMapUpdate.merge descendingMap true 121501,618 ? 1849,108 ns/op TreeMapUpdate.merge descendingMap false 95913,212 ? 2854,063 ns/op TreeMapUpdate.merge tailMap true 126657,309 ? 4467,733 ns/op TreeMapUpdate.merge tailMap false 93448,840 ? 1359,392 ns/op As you can see, the merge on derived maps is significantly slower. After the patch is applied the results are much better: (benchmark) (mode) (prefill) Score Error Units TreeMapUpdate.merge TreeMap true 64059,189 ? 808,230 ns/op TreeMapUpdate.merge TreeMap false 65156,912 ? 1229,965 ns/op TreeMapUpdate.merge descendingMap true 69938,131 ? 1697,357 ns/op TreeMapUpdate.merge descendingMap false 67783,829 ? 263,061 ns/op TreeMapUpdate.merge tailMap true 71079,529 ? 841,738 ns/op TreeMapUpdate.merge tailMap false 68577,169 ? 1196,758 ns/op I don't think this requires a CSR, as the changed class is package-private, so it cannot be extended by clients. With best regards, Tagir Valeev. From jens.lidestrom at fripost.org Sat May 2 18:26:21 2020 From: jens.lidestrom at fripost.org (=?UTF-8?Q?Jens_Lidestr=c3=b6m?=) Date: Sat, 2 May 2020 20:26:21 +0200 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> Message-ID: <62d0e4f9-267f-6a01-f605-c6ed74a06341@fripost.org> I will chip in once more on this topic. (I did so once before [1], perhaps in a much too wordy manner.) The proposed changes in AbstractSet.removeAll will be inherited by TreeSet. A TreeSet might use a comparator as a custom equality test. Because of this it seems backwards if TreeSet.removeAll where to use the equality semantics of the argument instead of the ones of the receiver, which will be the case with the proposed changes. It seems much more intuitive and regular to instead use the equality semantics of the receiver. The same thing applies to other collections with custom equality tests. It seems to be surprising and error prone to users if TreeSet where to behave like this: var s = new TreeSet(String.CASE_INSENSITIVE_ORDER); s.addAll(Set.of("A", "B")); s.remove("a"); // Removes "A" as expected s.removeAll(List.of("b")); // Ops, doesn't remove "B"! Many other common methods use the equality semantics of the receiver: containsAll, equals, remove, contains. To let TreeSet.removeAll be inconsistent with all these methods seems worse than it being inconsistent with the less commonly used TreeSet.retainAll. The conclusion is that I think it would be better if TreeSet or AbstractSet gets an implementation of removeAll which iterates over the argument collection. Best regards, Jens Lidestr?m [1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061581.html On 2020-05-01 22:01, Stuart Marks wrote: > Hi all, > > I'm taking another swing at this one. I've taken a minimal approach > compared to my previous proposals. > > Briefly, AbstractSet.removeAll switches from iterating this collection and > calling contains() on its argument, to iterating the argument and calling > this.contains(), if the argument collection is smaller than this > collection. This attempt at optimization is incorrect, because this > collection and the argument collection might have different semantics for > contains(). > > There is a confounding performance problem, which is that if the argument > is a List, contains() is generally linear, which can result in > pathologically slow (O(m*n)) performance. Because of the > iteration-switching above, this performance problem can appear and > disappear based on the relative sizes, which is startling. > > The fix for the semantic problem is simply to remove the attempted > optimization from AbstractSet. This comports with the specification of > Collection.removeAll and Set.removeAll, which imply that contains() is > called on the argument collection. This allows sets to inherit the > implementation in AbstractCollection.removeAll. In addition, this ensures > that removeAll is now always the complement of retainAll (as it should > be), which it sometimes was not when the optimization was in place. > > IdentityHashMap's keySet and entrySet views were broken by this > optimization, so they had to override removeAll with copies of the > implementation from AbstractCollection. Since they can now inherit from > AbstractCollection, these overrides have been removed. > > This leaves a potential performance problem with removeAll when the > argument is a List. To mitigate this, HashSet.removeAll switches to > iterating the argument if the argument is a List. This is safe, as both > HashSet and List use the same semantics for contains() (at least, as far > as I know). > > I've opted not to pursue size-based optimizations at this time, since they > provide only incremental benefit, whereas the pathological performance > problem mentioned above is the primary issue. Also, it's actually quite > difficult to determine when it's safe to switch iteration. > > Finally, I've added performance notes to the specifications of > containsAll(), removeAll(), and retainAll(), warning about potential > performance problems that can occur with repeated calls to contains() made > by these methods. > > Bug: > > ??? https://bugs.openjdk.java.net/browse/JDK-6394757 > > Webrev: > > ??? http://cr.openjdk.java.net/~smarks/reviews/6394757/webrev.2/ > > Previous discussions: > > ??? > http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007125.html > > ??? > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058140.html > > ??? > http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058378.html > > > ??? http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060007.html > > ??? http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060147.html > > Thanks, > > s'marks > From vipinsharma85 at gmail.com Sun May 3 15:10:16 2020 From: vipinsharma85 at gmail.com (Vipin Sharma) Date: Sun, 3 May 2020 20:40:16 +0530 Subject: Fix for warning related to stream api call chains in java.base Message-ID: Hi All, I have fixed some warnings in java.base module, following are 3 type of code changes in this patch: ! stream().filter(...).findFirst().isPresent() replaced with stream().noneMatch(...)) stream.filter(...).findFirst().isPresent() replaced with stream.anyMatch(...) stream.collect(Collectors.joining(",")) replaced with String.join(",", stringList) This patch improves performance as well, jmh results available at https://gist.github.com/Vipin-Sharma/00f1d6da6b8e0e0bc7bec2e33bce85ed, end of gist file you can see results. Need a sponsor for this patch. Patch: --- old/src/java.base/share/classes/java/lang/invoke/MethodHandles.java 2020-05-03 19:44:09.519289354 +0530 +++ new/src/java.base/share/classes/java/lang/invoke/MethodHandles.java 2020-05-03 19:44:09.087294954 +0530 @@ -6349,7 +6349,7 @@ loopReturnType + ")"); } - if (!pred.stream().filter(Objects::nonNull).findFirst().isPresent()) { + if (pred.stream().noneMatch(Objects::nonNull)) { throw newIllegalArgumentException("no predicate found", pred); } if (pred.stream().filter(Objects::nonNull).map(MethodHandle::type).map(MethodType::returnType). --- old/src/java.base/share/classes/java/util/Locale.java 2020-05-03 19:44:10.915271183 +0530 +++ new/src/java.base/share/classes/java/util/Locale.java 2020-05-03 19:44:10.487276766 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1996, 2019, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -2250,7 +2250,7 @@ // If we have no list patterns, compose the list in a simple, // non-localized way. if (pattern == null) { - return Arrays.stream(stringList).collect(Collectors.joining(",")); + return String.join(",", stringList); } switch (stringList.length) { --- old/src/java.base/share/classes/jdk/internal/module/DefaultRoots.java 2020-05-03 19:44:11.911258115 +0530 +++ new/src/java.base/share/classes/jdk/internal/module/DefaultRoots.java 2020-05-03 19:44:11.479263786 +0530 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2017, 2018, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -74,8 +74,6 @@ private static boolean exportsAPI(ModuleDescriptor descriptor) { return descriptor.exports() .stream() - .filter(e -> !e.isQualified()) - .findAny() - .isPresent(); + .anyMatch(e -> !e.isQualified()); } } --- old/src/java.base/share/classes/sun/launcher/LauncherHelper.java 2020-05-03 19:44:12.863245549 +0530 +++ new/src/java.base/share/classes/sun/launcher/LauncherHelper.java 2020-05-03 19:44:12.427251308 +0530 @@ -1142,7 +1142,7 @@ ostream.format("uses %s%n", s); } for (Provides ps : md.provides()) { - String names = ps.providers().stream().collect(Collectors.joining(" ")); + String names = String.join(" ", ps.providers()); ostream.format("provides %s with %s%n", ps.service(), names); } @@ -1150,7 +1150,7 @@ // qualified exports for (Exports e : md.exports()) { if (e.isQualified()) { - String who = e.targets().stream().collect(Collectors.joining(" ")); + String who = String.join(" ", e.targets()); ostream.format("qualified exports %s to %s%n", e.source(), who); } } @@ -1164,7 +1164,7 @@ .collect(Collectors.joining(" ")); ostream.format("opens %s", sourceAndMods); if (opens.isQualified()) { - String who = opens.targets().stream().collect(Collectors.joining(" ")); + String who = String.join(" ", opens.targets()); ostream.format(" to %s", who); } ostream.println(); --- old/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java 2020-05-03 19:44:14.143228540 +0530 +++ new/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java 2020-05-03 19:44:13.711234292 +0530 @@ -380,7 +380,7 @@ return parse(oset); } catch (OptionException ex) { if (ex.options().isEmpty()) { - msg("jshell.err.opt.invalid", stream(args).collect(joining(", "))); + msg("jshell.err.opt.invalid", String.join(", ", args)); } else { boolean isKnown = parser.recognizedOptions().containsKey(ex.options().iterator().next()); msg(isKnown @@ -2041,16 +2041,14 @@ if (matches.length == 0) { // There are no matching sub-commands errormsg("jshell.err.arg", cmd, sub); - fluffmsg("jshell.msg.use.one.of", Arrays.stream(subs) - .collect(Collectors.joining(", ")) + fluffmsg("jshell.msg.use.one.of", String.join(", ", subs) ); return null; } if (matches.length > 1) { // More than one sub-command matches the initial characters provided errormsg("jshell.err.sub.ambiguous", cmd, sub); - fluffmsg("jshell.msg.use.one.of", Arrays.stream(matches) - .collect(Collectors.joining(", ")) + fluffmsg("jshell.msg.use.one.of", String.join(", ", matches) ); return null; } Regards, Vipin From powers.anirvan at gmail.com Sun May 3 16:03:10 2020 From: powers.anirvan at gmail.com (Anirvan Sarkar) Date: Mon, 4 May 2020 01:03:10 +0900 Subject: 8244293 : Remove outdated @apiNote in java.util.Objects Message-ID: Hi, The class level @apiNote in java.util.Objects refers to variation of static methods checkIndex(int, int), checkFromToIndex(int, int, int), and checkFromIndexSize(int, int, int), which support customization of the runtime exception, and corresponding exception detail message. But these static methods were removed from java.util.Objects as part of JDK-8155794 [1]. So the @apiNote in java.util.Objects is outdated. I have created JBS issue to remove the @apiNote [2]. Patch is attached. Can someone review and sponsor it? [1] : https://bugs.openjdk.java.net/browse/JDK-8155794 [2] : https://bugs.openjdk.java.net/browse/JDK-8244293 -- Anirvan -------------- next part -------------- A non-text attachment was scrubbed... Name: JDK-8244293.patch Type: text/x-patch Size: 2077 bytes Desc: not available URL: From mikael.vidstedt at oracle.com Mon May 4 05:12:08 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Sun, 3 May 2020 22:12:08 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) Message-ID: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> Please review this change which implements part of JEP 381: JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/corelibs/open/webrev/ JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! Background: Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. Testing: A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. Cheers, Mikael [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ From thejasvi.v.voniadka at oracle.com Mon May 4 07:26:13 2020 From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka) Date: Mon, 4 May 2020 00:26:13 -0700 (PDT) Subject: [PATCH] 8244199: [TestBug]: Update sun/management/jmxremote/bootstrap tests Message-ID: Hi, May I please find a sponsor for this patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8244199 Description: The test "test/jdk/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh" fails intermittently on a lower release. While investigating the cause for the failure, I felt the diagnostic messaging built into the test was not adequate. Some of the issues observed: 1. If the test throws a RuntimeException, the full stack trace is not displayed. 2. The test has several logging statements. However, the logging environment is not properly initialized to allow levels such as FINE when needed. 3. The logging sequence could be improved: some messages end up at stdout, and others at stderr, which makes it harder to follow the output. The patch is to improve the test in these lines. Webrev: http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.full.00 I have also used this opportunity to clean-up the test code as a whole, in lines of removal of redundant logic, formatting, coding guidelines, etc.... If the above patch looks too confusing and is hard to follow, here is a simpler version that shows only the core logic changes (I intend to submit only the full patch to be committed though): http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.simple.00 The patch has been tested on mach5, and all jmxremote tests passed. From Alan.Bateman at oracle.com Mon May 4 08:49:08 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 4 May 2020 09:49:08 +0100 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> Message-ID: On 04/05/2020 06:12, Mikael Vidstedt wrote: > Please review this change which implements part of JEP 381: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/corelibs/open/webrev/ > JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 > > > Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! > I took a pass over the changes. I agree its a bit tedious. I'm sure there will be a few follow up issues as there are opportunities for cleanup in several areas. Just a few comments/questions from a first pass. ExtendedSocketOption.SO_FLOW_SLA is the Solaris specific socket option that was terminally deprecated in 14. The patch removes the implementation but leave the API (SO_FLOW_SA and jdk.net.SocketFlow). Do you want a someone to take a follow-on issue to remove the API? ResolverConfigurationImpl.localDomain0 can be removed. The comment on mcast_join_leave in PlainDatagramSocketImpl.c has a residual reference to Solaris. JISAutoDetect - might be simpler to just initialize EUCJPName to "EUC_JP". Socket.setTrafficClass(int) swallows exceptions to workaround strange behaviour on Solaris. Tracked as JDK-8221487 so okay to leave it to that issue if you want. There is also cruft in the old plain SocketImpl that to work around eagerness to report "connection reset errors - I think we should just leave that because the old socket impl is not used by default and will be removed at some point. -Alan. From jayashreesk at in.ibm.com Mon May 4 08:50:35 2020 From: jayashreesk at in.ibm.com (Jayashree Sk1) Date: Mon, 4 May 2020 08:50:35 +0000 Subject: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException In-Reply-To: <3b4efc42-f45f-820f-44af-89c3fa28ac39@oracle.com> References: <3b4efc42-f45f-820f-44af-89c3fa28ac39@oracle.com>, <2b1a70a8-7d0a-9d7a-b48d-69de03b07e2e@oracle.com> Message-ID: Hi Stuart, Yup Contributed-by as picked from my email : jayashreesk . Will keep in mind about the complicated change-sets. Thanks Jay -----Stuart Marks wrote: ----- To: Jayashree Sk1 From: Stuart Marks Date: 05/01/2020 09:32AM Cc: core-libs-dev at openjdk.java.net Subject: [EXTERNAL] Re: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException Hi Jay, OK, welcome! I'll sponsor this changeset for you. It's pretty simple, so I'll just paste the exported changeset below. (For complicated changesets, you'll have to ask a sponsor to host a webrev on cr.openjdk.java.net for you.) Please check the Contributed-by line in the changeset to make sure the attribution is correct. I just copied the From: line from your email, but if you want it to be different, please let me know. I'll update the bug report with a pointer to this email thread. https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D6415694&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=rA_13vli8clPM_toR46hq8FVwH3XGr8z7cUfcQoqL-k&m=9YMcjPnAAEf40XGqmcEU_Uiyg_xCVlOU26-U56hEb4A&s=ueOfMpgrTsTZc7xg22AdzVskohCya_stq_WLTREzw24&e= Could I get a Reviewer to review this? Thanks. (I noticed that the anachronistic markup is used here instead of the preferred {@code ...} javadoc tag. However, is used all over this package, so I didn't think that changing it in just one place would be helpful.) I'll also note again that since this is merely an editorial wording change to the specification, I don't think it needs a CSR request. Thanks, s'marks # HG changeset patch # User smarks # Date 1588290431 25200 # Thu Apr 30 16:47:11 2020 -0700 # Node ID 1f5b3876d1500a2e77d6e39d079649964ba6dd26 # Parent fe6548dc92de4c875467c968ee37e7c9bbee1697 6415694: Clarification in Javadoc for java.rmi.AlreadyBoundException Reviewed-by: XXX Contributed-by: Jayashree Sk1 diff -r fe6548dc92de -r 1f5b3876d150 src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java --- a/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Thu Apr 30 15:21:15 2020 -0700 +++ b/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Thu Apr 30 16:47:11 2020 -0700 @@ -26,8 +26,8 @@ /** * An AlreadyBoundException is thrown if an attempt - * is made to bind an object in the registry to a name that already - * has an associated binding. + * is made to bind an object to a name that already + * has an associated binding in the registry. * * @since 1.1 * @author Ann Wollrath On 4/29/20 10:24 PM, Jayashree Sk1 wrote: > Thanks for the review comment Stuart. Yes, I will need a sponsor, this is my first time here in OpenJDK. > > > Regards! > Jay > > -----Stuart Marks wrote: ----- > To: Jayashree Sk1 > From: Stuart Marks > Date: 04/30/2020 09:22AM > Cc: core-libs-dev at openjdk.java.net > Subject: [EXTERNAL] Re: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException > > The change looks fine. Although this is in a normative portion of the > specification, the nature of the change is purely editorial, so I don't think it > needs a CSR. > > Do you need a sponsor? > > s'marks > > On 4/29/20 2:57 AM, Jayashree Sk1 wrote: >> Hi All, >> Please find the below changes for the issues https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D6415694&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=rA_13vli8clPM_toR46hq8FVwH3XGr8z7cUfcQoqL-k&m=OXEC-w1xTWoJUyw_sRivRwIGmkHIUc3DllMsA_N3qIk&s=iesFFcE4NSOreLmf8vwdKzcdnFgjGE_SEERICPUFef4&e= . >> It is a description change, which was already approved by the reviewer. >> >> Thanks! >> >> diff -r 59b5bd9a7168 src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java >> --- a/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Mon Mar 16 02:16:49 2020 -0400 >> +++ b/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Mon Mar 30 15:45:43 2020 +0530 >> @@ -26,8 +26,8 @@ >> >> /** >> * An AlreadyBoundException is thrown if an attempt >> - * is made to bind an object in the registry to a name that already >> - * has an associated binding. >> + * is made to bind an object to a name that already >> + * has an associated binding in the registry. >> * >> * @since 1.1 >> * @author Ann Wollrath >> > > From thejasvi.v.voniadka at oracle.com Mon May 4 12:35:14 2020 From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka) Date: Mon, 4 May 2020 05:35:14 -0700 (PDT) Subject: [PATCH] 8244199: [TestBug]: Update sun/management/jmxremote/bootstrap tests In-Reply-To: References: Message-ID: <1d7ad0b3-2b3a-4950-b559-929451e13283@default> Adding jmx-dev and security-dev. -----Original Message----- From: Thejasvi Voniadka Sent: Monday, May 4, 2020 12:56 PM To: core-libs-dev at openjdk.java.net Subject: [PATCH] 8244199: [TestBug]: Update sun/management/jmxremote/bootstrap tests Hi, May I please find a sponsor for this patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8244199 Description: The test "test/jdk/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh" fails intermittently on a lower release. While investigating the cause for the failure, I felt the diagnostic messaging built into the test was not adequate. Some of the issues observed: 1. If the test throws a RuntimeException, the full stack trace is not displayed. 2. The test has several logging statements. However, the logging environment is not properly initialized to allow levels such as FINE when needed. 3. The logging sequence could be improved: some messages end up at stdout, and others at stderr, which makes it harder to follow the output. The patch is to improve the test in these lines. Webrev: http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.full.00 I have also used this opportunity to clean-up the test code as a whole, in lines of removal of redundant logic, formatting, coding guidelines, etc.... If the above patch looks too confusing and is hard to follow, here is a simpler version that shows only the core logic changes (I intend to submit only the full patch to be committed though): http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.simple.00 The patch has been tested on mach5, and all jmxremote tests passed. From weijun.wang at oracle.com Mon May 4 14:22:38 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 4 May 2020 22:22:38 +0800 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> Message-ID: <1BA86CD8-2322-4D68-ADAE-D95311FEDF23@oracle.com> There are several security-related files (name.contains("security")) and they all look fine. --Max > On May 4, 2020, at 1:12 PM, Mikael Vidstedt wrote: > > > Please review this change which implements part of JEP 381: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/corelibs/open/webrev/ > JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 > > > Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! > > > Background: > > Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. > > For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. > > In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. > > > Testing: > > A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. > > Cheers, > Mikael > > [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ > From Roger.Riggs at oracle.com Mon May 4 14:59:30 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 4 May 2020 10:59:30 -0400 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> Message-ID: <513265a5-8a7d-d2b9-9cfe-adcf87cca390@oracle.com> Hi Michael, Looks good. Maybe just a future cleanup to rename files, since the "...so..." is refering to solaris. src/java.base/unix/native/libjli/java_md_solinux.h src/java.base/unix/native/libjli/java_md_solinux.h Regards, Roger On 5/4/20 4:49 AM, Alan Bateman wrote: > On 04/05/2020 06:12, Mikael Vidstedt wrote: >> Please review this change which implements part of JEP 381: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >> webrev: >> http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/corelibs/open/webrev/ >> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >> >> >> Note: When reviewing this, please be aware that this exercise was >> *extremely* mind-numbing, so I appreciate your help reviewing all the >> individual changes carefully. You may want to get that coffee cup >> filled up (or whatever keeps you awake)! >> > I took a pass over the changes. I agree its a bit tedious. I'm sure > there will be a few follow up issues as there are opportunities for > cleanup in several areas. Just a few comments/questions from a first > pass. > > ExtendedSocketOption.SO_FLOW_SLA is the Solaris specific socket option > that was terminally deprecated in 14. The patch removes the > implementation but leave the API (SO_FLOW_SA and jdk.net.SocketFlow). > Do you want a someone to take a follow-on issue to remove the API? > > ResolverConfigurationImpl.localDomain0 can be removed. > > The comment on mcast_join_leave in PlainDatagramSocketImpl.c has a > residual reference to Solaris. > > JISAutoDetect - might be simpler to just initialize EUCJPName to > "EUC_JP". > > Socket.setTrafficClass(int) swallows exceptions to workaround strange > behaviour on Solaris. Tracked as JDK-8221487 so okay to leave it to > that issue if you want. There is also cruft in the old plain > SocketImpl that to work around eagerness to report "connection reset > errors - I think we should just leave that because the old socket impl > is not used by default and will be removed at some point. > > -Alan. From alexey.semenyuk at oracle.com Mon May 4 15:20:06 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 4 May 2020 11:20:06 -0400 Subject: RFR: JDK-8244018: No error message for non-existent icon path In-Reply-To: References: Message-ID: <165ec5a4-8b35-c1cc-9efb-eeb4116fc926@oracle.com> Looks good. - Alexey On 4/29/2020 10:31 AM, Andy Herrick wrote: > Please review fix at [1] for issue [2] > > The change just adds error when specified icon is not found, and a > test for that. > > /Andy > > [1] - http://cr.openjdk.java.net/~herrick/8244018/webrev.01/ > > [2] - https://bugs.openjdk.java.net/browse/JDK-8244018 > > From paul.sandoz at oracle.com Mon May 4 16:15:51 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 4 May 2020 09:15:51 -0700 Subject: 8244293 : Remove outdated @apiNote in java.util.Objects In-Reply-To: References: Message-ID: <8DE622E2-926E-4641-86EF-1C08C32E6ADF@oracle.com> Hi, Removing all of the api note looks good, since it was really written in the context of the removed methods. I?ll sponsor. (I removed the methods but forgot to remove the note.) Paul. > On May 3, 2020, at 9:03 AM, Anirvan Sarkar wrote: > > Hi, > > The class level @apiNote in java.util.Objects refers to variation of static > methods checkIndex(int, int), checkFromToIndex(int, int, int), and > checkFromIndexSize(int, int, int), which support customization of the > runtime exception, and corresponding exception detail message. > > But these static methods were removed from java.util.Objects as part of > JDK-8155794 [1]. > So the @apiNote in java.util.Objects is outdated. > > I have created JBS issue to remove the @apiNote [2]. > Patch is attached. > > Can someone review and sponsor it? > > [1] : https://bugs.openjdk.java.net/browse/JDK-8155794 > [2] : https://bugs.openjdk.java.net/browse/JDK-8244293 > > -- > Anirvan > From naoto.sato at oracle.com Mon May 4 16:27:00 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 4 May 2020 09:27:00 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> Message-ID: <26996994-3e08-c312-c1fa-9b2ffd5b5d95@oracle.com> Hi Mikael, I took a look at i18n related files. It looks good overall. One nit in java/nio/charset/Charset/DefaultCharsetTest.java: If the test is only applicable to linux (@requires os.family == "linux" in jtreg tag after the change), the condition isLinux() is no longer needed at line 73. Naoto On 5/3/20 10:12 PM, Mikael Vidstedt wrote: > > Please review this change which implements part of JEP 381: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/corelibs/open/webrev/ > JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 > > > Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! > > > Background: > > Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. > > For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. > > In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. > > > Testing: > > A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. > > Cheers, > Mikael > > [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ > From ioi.lam at oracle.com Mon May 4 17:43:20 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 4 May 2020 10:43:20 -0700 Subject: RFR(S) 8241071 Generation of classes.jsa is not deterministic In-Reply-To: <60e5d174-8799-93da-69c9-bcc44215da04@oracle.com> References: <30172e56-e470-a1bb-b4e7-87670ad91b8d@oracle.com> <93e98a36-854d-6afb-4c8f-92a29266ebbf@oracle.com> <60e5d174-8799-93da-69c9-bcc44215da04@oracle.com> Message-ID: On 4/27/20 7:05 PM, David Holmes wrote: > On 28/04/2020 10:01 am, David Holmes wrote: >> On 28/04/2020 9:37 am, Ioi Lam wrote: >>> Hi David & Jiangli, >>> >>> Thanks for your comments. >>> >>> I thought about using a system property, but the user can also >>> specify it like >>> >>> ???? java -Djdk.xshare.dump.salt=0 MyProgram >> >> There's a way to pass properties from the VM that the user can't >> override. I'll need to lookup the details. > > It should suffice to define SystemProperty that is non-writeable and > internal (for good measure). But it seems we have introduced a bug > since Java 9 whereby a non-writeable property is actually being > overwritten! :( > > David > Hi David, I tried implementing the seed as a system property. However, ImmutableCollections.() is executed very early during JDK bootstrap (about 500-th bytecode), much earlier than when System.props is initialized (about 43689-th bytecode). So attempts to read the system property would give a NullPointerException Error occurred during initialization of VM java.lang.ExceptionInInitializerError ??? at java.util.ImmutableCollections$Set12.(java.base/ImmutableCollections.java:626) ??? at java.util.Set.of(java.base/Set.java:468) ??? at java.lang.Module.(java.base/Module.java:251) Caused by: java.lang.NullPointerException ??? at java.lang.System.getProperty(java.base/System.java:834) ??? at java.util.ImmutableCollections.(java.base/ImmutableCollections.java:80) ??? at java.util.ImmutableCollections$Set12.(java.base/ImmutableCollections.java:626) ??? at java.util.Set.of(java.base/Set.java:468) ??? at java.lang.Module.(java.base/Module.java:251) Because of this, I have to keep using the JVM_GetRandomSeedForCDSDump() native function. Thanks - Ioi >> David >> >>> This would circumvent the calculation of >>> ImmutableCollections.SALT32L for normal execution. I am not sure if >>> this is desirable, or if there's a way to prevent the user from >>> doing that. I'll see what the core lib folks suggest. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v03/ >>> >>> http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v03.delta/ >>> >>> >>> More comments below >>> >>> >>> On 4/26/20 11:20 PM, David Holmes wrote: >>>> Hi Ioi, >>>> >>>> On 27/04/2020 3:22 pm, Ioi Lam wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8241071 >>>>> http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v02/ >>>>> >>>>> >>>>> The goal is to for "java -Xshare:dump" to produce deterministic >>>>> contents in >>>>> the CDS archive that depend only on the contents of >>>>> $JAVA_HOME/lib/modules. >>>>> >>>>> Problems: >>>>> [1] Symbols in the CDS archive may have non-deterministic order >>>>> because >>>>> ???? Arena allocation is non-deterministic. >>>>> [2] The contents of the CDS shared heap region may be randomized >>>>> due to >>>>> ?? ? ImmutableCollections.SALT32L. >>>>> >>>>> Fixes: >>>>> [1] With -Xshare:dump, allocate Symbols from the class space >>>>> (64-bit only). >>>> >>>> I'm not seeing what restricts this to 64-bit only ?? >>> >>> The last version of the patch allocated using >>> MetaspaceObj::ClassType. On 64-bit+compressed classes, this will >>> allocate from the class space. >>> >>> But anyway, as Thomas commented, doing this is problematic. >>> >>>> >>>> Will changing the allocation of symbols cause any problems with the >>>> amount of "class space" we need? >>>> >>> >>> Per Thomas's comment, I moved the allocation of Symbols in a >>> separate virtual space. Please see my comments to Thomas's e-mail. >>> >>>>> ?? ? See changes in symbol.cpp for details. >>>>> [2] When running the VM with -Xshare:dump, >>>>> ImmutableCollections.SALT32L is >>>>> ???? initialized with a deterministic seed. NOTE: this affects >>>>> ONLY when the >>>>> ?? ? VM is running with the special flag -Xshare:dump to dump the >>>>> CDS archive. >>>>> ?? ? It does NOT affect normal execution of Java programs. >>>> >>>> I can't say I like adding in the VM call for this. Another >>>> alternative would be a VM defined system property. But I'll let >>>> core-libs folk make the call here. >>>> >>>>> --- >>>>> I also cleaned up the -Xlog:cds output and print out the CRC of each >>>>> CDS region, to help diagnose why two CDS archives may have >>>>> different contents. >>>> >>>> Generally seems okay. A couple of minor nits: >>>> >>>> src/hotspot/share/oops/symbol.cpp >>>> >>>> typo: adresses -> addresses >>>> >>> >>> Fixed >>> >>>> test/hotspot/jtreg/runtime/cds/DeterministicDump.java >>>> >>>> Should the test use @driver mode? >>>> >>> >>> Fixed >>> >>>> ?39 // use of SharedArchiveFile argument. >>>> >>>> s/argument/arguments/ >>>> >>>> ?40 // methods to form command line to create/use shared archive. >>>> >>>> s/line/lines/ >>>> >>>> s/shared/the shared/ >>>> >>> >>> I copied these comments from another test. They are not needed here >>> so I deleted them in the new webrev. >>> >>>> ?71 if (n0 == 0) { >>>> >>>> Shouldn't this check come before the loop at line 63? >>> >>> Fixed. >>> >>> >>> Thanks >>> - Ioi >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Thanks >>>>> - Ioi >>> From brent.christian at oracle.com Mon May 4 21:33:17 2020 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 4 May 2020 14:33:17 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> Message-ID: Hi, Looks fine to me. I have just one minor observation: src/java.base/share/native/libjli/emessages.h *** 92,102 **** #define JRE_ERROR5 "Error: Failed to start a %d-bit JVM process from a %d-bit JVM." ! #define JRE_ERROR6 "Error: Verify all necessary Java SE components have been installed.\n(Solaris SPARC 64-bit components must be installed after 32-bit components.)" #define JRE_ERROR7 "Error: Either 64-bit processes are not supported by this platform\nor the 64-bit components have not been installed." --- 91,101 ---- #define JRE_ERROR5 "Error: Failed to start a %d-bit JVM process from a %d-bit JVM." ! #define JRE_ERROR6 "Error: Verify all necessary Java SE components have been installed.\n" #define JRE_ERROR7 "Error: Either 64-bit processes are not supported by this platform\nor the 64-bit components have not been installed." The other error messages do not include a trailing newline. -Brent On 5/3/20 10:12 PM, Mikael Vidstedt wrote: > > Please review this change which implements part of JEP 381: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/corelibs/open/webrev/ > JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 > > > Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! > > > Background: > > Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. > > For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. > > In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. > > > Testing: > > A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. > > Cheers, > Mikael > > [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ > From david.holmes at oracle.com Mon May 4 22:14:38 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 5 May 2020 08:14:38 +1000 Subject: RFR(S) 8241071 Generation of classes.jsa is not deterministic In-Reply-To: References: <30172e56-e470-a1bb-b4e7-87670ad91b8d@oracle.com> <93e98a36-854d-6afb-4c8f-92a29266ebbf@oracle.com> <60e5d174-8799-93da-69c9-bcc44215da04@oracle.com> Message-ID: <1d45bb83-ff0b-0123-66f4-b67fdd4258e5@oracle.com> Hi Ioi, On 5/05/2020 3:43 am, Ioi Lam wrote: > > > On 4/27/20 7:05 PM, David Holmes wrote: >> On 28/04/2020 10:01 am, David Holmes wrote: >>> On 28/04/2020 9:37 am, Ioi Lam wrote: >>>> Hi David & Jiangli, >>>> >>>> Thanks for your comments. >>>> >>>> I thought about using a system property, but the user can also >>>> specify it like >>>> >>>> ???? java -Djdk.xshare.dump.salt=0 MyProgram >>> >>> There's a way to pass properties from the VM that the user can't >>> override. I'll need to lookup the details. >> >> It should suffice to define SystemProperty that is non-writeable and >> internal (for good measure). But it seems we have introduced a bug >> since Java 9 whereby a non-writeable property is actually being >> overwritten! :( >> >> David >> > > Hi David, > > I tried implementing the seed as a system property. However, > ImmutableCollections.() is executed very early during JDK > bootstrap (about 500-th bytecode), much earlier than when System.props > is initialized (about 43689-th bytecode). So attempts to read the system > property would give a NullPointerException > > Error occurred during initialization of VM > java.lang.ExceptionInInitializerError > ??? at > java.util.ImmutableCollections$Set12.(java.base/ImmutableCollections.java:626) > > ??? at java.util.Set.of(java.base/Set.java:468) > ??? at java.lang.Module.(java.base/Module.java:251) > Caused by: java.lang.NullPointerException > ??? at java.lang.System.getProperty(java.base/System.java:834) > ??? at > java.util.ImmutableCollections.(java.base/ImmutableCollections.java:80) > > ??? at > java.util.ImmutableCollections$Set12.(java.base/ImmutableCollections.java:626) > > ??? at java.util.Set.of(java.base/Set.java:468) > ??? at java.lang.Module.(java.base/Module.java:251) > > Because of this, I have to keep using the JVM_GetRandomSeedForCDSDump() > native function. Okay - thanks for trying the alternative. Initialization is always tricky. David > Thanks > - Ioi > >>> David >>> >>>> This would circumvent the calculation of >>>> ImmutableCollections.SALT32L for normal execution. I am not sure if >>>> this is desirable, or if there's a way to prevent the user from >>>> doing that. I'll see what the core lib folks suggest. >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v03/ >>>> >>>> http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v03.delta/ >>>> >>>> >>>> More comments below >>>> >>>> >>>> On 4/26/20 11:20 PM, David Holmes wrote: >>>>> Hi Ioi, >>>>> >>>>> On 27/04/2020 3:22 pm, Ioi Lam wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8241071 >>>>>> http://cr.openjdk.java.net/~iklam/jdk15/8241071-deterministic-cds-archive.v02/ >>>>>> >>>>>> >>>>>> The goal is to for "java -Xshare:dump" to produce deterministic >>>>>> contents in >>>>>> the CDS archive that depend only on the contents of >>>>>> $JAVA_HOME/lib/modules. >>>>>> >>>>>> Problems: >>>>>> [1] Symbols in the CDS archive may have non-deterministic order >>>>>> because >>>>>> ???? Arena allocation is non-deterministic. >>>>>> [2] The contents of the CDS shared heap region may be randomized >>>>>> due to >>>>>> ?? ? ImmutableCollections.SALT32L. >>>>>> >>>>>> Fixes: >>>>>> [1] With -Xshare:dump, allocate Symbols from the class space >>>>>> (64-bit only). >>>>> >>>>> I'm not seeing what restricts this to 64-bit only ?? >>>> >>>> The last version of the patch allocated using >>>> MetaspaceObj::ClassType. On 64-bit+compressed classes, this will >>>> allocate from the class space. >>>> >>>> But anyway, as Thomas commented, doing this is problematic. >>>> >>>>> >>>>> Will changing the allocation of symbols cause any problems with the >>>>> amount of "class space" we need? >>>>> >>>> >>>> Per Thomas's comment, I moved the allocation of Symbols in a >>>> separate virtual space. Please see my comments to Thomas's e-mail. >>>> >>>>>> ?? ? See changes in symbol.cpp for details. >>>>>> [2] When running the VM with -Xshare:dump, >>>>>> ImmutableCollections.SALT32L is >>>>>> ???? initialized with a deterministic seed. NOTE: this affects >>>>>> ONLY when the >>>>>> ?? ? VM is running with the special flag -Xshare:dump to dump the >>>>>> CDS archive. >>>>>> ?? ? It does NOT affect normal execution of Java programs. >>>>> >>>>> I can't say I like adding in the VM call for this. Another >>>>> alternative would be a VM defined system property. But I'll let >>>>> core-libs folk make the call here. >>>>> >>>>>> --- >>>>>> I also cleaned up the -Xlog:cds output and print out the CRC of each >>>>>> CDS region, to help diagnose why two CDS archives may have >>>>>> different contents. >>>>> >>>>> Generally seems okay. A couple of minor nits: >>>>> >>>>> src/hotspot/share/oops/symbol.cpp >>>>> >>>>> typo: adresses -> addresses >>>>> >>>> >>>> Fixed >>>> >>>>> test/hotspot/jtreg/runtime/cds/DeterministicDump.java >>>>> >>>>> Should the test use @driver mode? >>>>> >>>> >>>> Fixed >>>> >>>>> ?39 // use of SharedArchiveFile argument. >>>>> >>>>> s/argument/arguments/ >>>>> >>>>> ?40 // methods to form command line to create/use shared archive. >>>>> >>>>> s/line/lines/ >>>>> >>>>> s/shared/the shared/ >>>>> >>>> >>>> I copied these comments from another test. They are not needed here >>>> so I deleted them in the new webrev. >>>> >>>>> ?71 if (n0 == 0) { >>>>> >>>>> Shouldn't this check come before the loop at line 63? >>>> >>>> Fixed. >>>> >>>> >>>> Thanks >>>> - Ioi >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> Thanks >>>>>> - Ioi >>>> > From stuart.marks at oracle.com Mon May 4 23:19:15 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 4 May 2020 16:19:15 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: <62d0e4f9-267f-6a01-f605-c6ed74a06341@fripost.org> References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <62d0e4f9-267f-6a01-f605-c6ed74a06341@fripost.org> Message-ID: <9fd34999-4109-29f3-735e-4b8a51461e6f@oracle.com> Hi Jens, This is a situation where intuition can easily lead one astray. Indeed, I initially made the same assumption [1] that x.removeAll(y) should essentially call x.remove() on each element of y, as if y::forEach(x::remove). This would imply that y is iterated and that x's membership semantics would be used. However, after some further discussion, research, and analysis, I changed my mind. [2] This is somewhat counterintuitive, but there are good reasons for going the opposite direction. First, consider the specification of Collection.removeAll: Removes all of this collection's elements that are also contained in the specified collection[...]. This is somewhat oddly worded, even stilted. Why doesn't it say something simple like "removes each of the elements of the specified collection from this collection"? The answer is that they mean different things. Consider: var list = new ArrayList<>(List.of("a", "a")) list.removeAll(List.of("a")) list ==> [] The word "all" is used in two senses simultaneously here: it removes from this collection "all" occurrences of "all" the elements of the specified collection. The implication here is that *this* collection is iterated, and an element is removed if it's contained in the specified collection. That implies contains() is called on the specified collection, and that uses the specified collection's membership semantics. AbstractCollection.removeAll is implemented exactly this way. Given that Set.removeAll overrides Collection.removeAll, they should have compatible semantics to the greatest extent possible. (And yes, there are various existing violations of Liskov subsitutability in the collections framework, but changing this would introduce a new violation as well as a massive incompatibility.) You might say, the example above has duplicates in *this* collection, which turns out to be a list. But this is different, because now we're talking about sets, which can't have duplicates, so the alternative sense of removeAll doesn't matter. It still matters, because the notion of "duplicate" depends on whose membership semantics are in use. Consider: Collection list = new ArrayList<>(List.of("a", "A")) Collection hash = new HashSet<>(list) var tree = new TreeSet<>(String.CASE_INSENSITIVE_ORDER) tree.add("A") list.removeAll(tree) list ==> [] hash.removeAll(tree) hash ==> [] Even though neither the List nor the HashSet appears to have duplicates, they both do when using the TreeSet's semantics. It would be terribly inconsistent to have AbstractCollection.removeAll and AbstractSet.removeAll differ in which collection's semantics they depend upon. Finally, there is retainAll. It may be that removeAll is used more than retainAll, but their specifications and semantics are inextricably linked. Their specs are: removeAll: Removes all of this collection's elements that are also contained in the specified collection retainAll: Retains only the elements in this collection that are contained in the specified collection The specifications are inverses of each other, so the result of removeAll should be the complement of the result of retainAll, and both rely on the contains() semantics of the specified collection. ** It's perhaps unfortunate that Set.removeAll seems "backwards", but there are good reasons it's this way. It needs to stay this way in order to remain compatible with Collections.removeAll and to preserve its relationship with retainAll. s'marks [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058172.html [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058540.html On 5/2/20 11:26 AM, Jens Lidestr?m wrote: > I will chip in once more on this topic. (I did so once before [1], perhaps > in a much too wordy manner.) > > The proposed changes in AbstractSet.removeAll will be inherited by > TreeSet. A TreeSet might use a comparator as a custom equality test. > > Because of this it seems backwards if TreeSet.removeAll where to use the > equality semantics of the argument instead of the ones of the receiver, > which will be the case with the proposed changes. It seems much more > intuitive and regular to instead use the equality semantics of the receiver. > > The same thing applies to other collections with custom equality tests. > > It seems to be surprising and error prone to users if TreeSet where to > behave like this: > > var s = new TreeSet(String.CASE_INSENSITIVE_ORDER); > s.addAll(Set.of("A", "B")); > s.remove("a"); // Removes "A" as expected > s.removeAll(List.of("b")); // Ops, doesn't remove "B"! > > Many other common methods use the equality semantics of the receiver: > containsAll, equals, remove, contains. To let TreeSet.removeAll be > inconsistent with all these methods seems worse than it being inconsistent > with the less commonly used TreeSet.retainAll. > > The conclusion is that I think it would be better if TreeSet or > AbstractSet gets an implementation of removeAll which iterates over the > argument collection. > > Best regards, > Jens Lidestr?m > > [1]: > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July/061581.html > > On 2020-05-01 22:01, Stuart Marks wrote: >> Hi all, >> >> I'm taking another swing at this one. I've taken a minimal approach >> compared to my previous proposals. >> >> Briefly, AbstractSet.removeAll switches from iterating this collection and >> calling contains() on its argument, to iterating the argument and calling >> this.contains(), if the argument collection is smaller than this >> collection. This attempt at optimization is incorrect, because this >> collection and the argument collection might have different semantics for >> contains(). >> >> There is a confounding performance problem, which is that if the argument >> is a List, contains() is generally linear, which can result in >> pathologically slow (O(m*n)) performance. Because of the >> iteration-switching above, this performance problem can appear and >> disappear based on the relative sizes, which is startling. >> >> The fix for the semantic problem is simply to remove the attempted >> optimization from AbstractSet. This comports with the specification of >> Collection.removeAll and Set.removeAll, which imply that contains() is >> called on the argument collection. This allows sets to inherit the >> implementation in AbstractCollection.removeAll. In addition, this ensures >> that removeAll is now always the complement of retainAll (as it should >> be), which it sometimes was not when the optimization was in place. >> >> IdentityHashMap's keySet and entrySet views were broken by this >> optimization, so they had to override removeAll with copies of the >> implementation from AbstractCollection. Since they can now inherit from >> AbstractCollection, these overrides have been removed. >> >> This leaves a potential performance problem with removeAll when the >> argument is a List. To mitigate this, HashSet.removeAll switches to >> iterating the argument if the argument is a List. This is safe, as both >> HashSet and List use the same semantics for contains() (at least, as far >> as I know). >> >> I've opted not to pursue size-based optimizations at this time, since they >> provide only incremental benefit, whereas the pathological performance >> problem mentioned above is the primary issue. Also, it's actually quite >> difficult to determine when it's safe to switch iteration. >> >> Finally, I've added performance notes to the specifications of >> containsAll(), removeAll(), and retainAll(), warning about potential >> performance problems that can occur with repeated calls to contains() made >> by these methods. >> >> Bug: >> >> ??? https://bugs.openjdk.java.net/browse/JDK-6394757 >> >> Webrev: >> >> ??? http://cr.openjdk.java.net/~smarks/reviews/6394757/webrev.2/ >> >> Previous discussions: >> >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-July/007125.html >> >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/058140.html >> >> >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-February/058378.html >> >> >> ??? http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060007.html >> >> ??? http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060147.html >> >> Thanks, >> >> s'marks >> From stuart.marks at oracle.com Tue May 5 00:25:32 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 4 May 2020 17:25:32 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> Message-ID: <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> On 5/1/20 10:41 PM, Jason Mehrens wrote: > 1. I assume you are using "c instanceof List" instead of "!(c instanceof Set)" to correctly handle IdentitityHashMap.values()? The instanceof List seems like safe choice but it is too bad we can still fool that check by wrapping List as an unmodifiableCollection. If splitIterator().characteristics() could tell us that the collection used identity comparisons I think we would be able to determine if it was safe to swap the ordering in the general case as we could check for IDENTITY, SORTED, and comparator equality. I'm using "instance List", not for the reason of IdentityHashMap.values() specifically (though that's a good example), but mainly to try to be minimal. While I think getting the semantics right takes priority, the change does impact performance, so I want to reintroduce the performance heuristic in the safest manner possible. Checking for !Set seems dangerous, as there might be any number of Collections out there that aren't Sets and that aren't consistent with equals. Checking for instanceof List seemed like the safest and most minimal thing to do. In fact, I'm not even sure how safe List is! It's certainly possible for someone to have a List that isn't consistent with equals. Such a thing might violate the List contract, but that hasn't stopped people from implementing such things (outside the JDK). I also toyed around with various additional tests for when it would be profitable to switch iteration to the smaller collection. This could be applied to a variety of consistent-with-equals set implementations in the JDK. The benefits of swapping the iteration is more modest in these cases compared to List, however. Avoiding repeated List.contains() helps avoid quasi-quadratic (O(M*N)) performance. Swapping iteration order of sets gets us only the smaller of O(M) vs O(N), which is still linear. Also, as you noted, this heuristic is easily defeated by things like the collection wrappers. > 2. Should code applied to HashSet.removeAll also be applied to HashMap.keySet().removeAll and HashMap.entrySet().removeAll? Collections::newSetFromMap will end up having different behavior if it is not consistently applied. I think the *results* will be consistent, but the *performance* might not be consistent. But these cases could result in pathological performance if removeAll(list) is called, so I'm a bit concerned about them. If we agree that "instanceof List" is a reasonable heuristic, then I don't have any objection in principle to adding it to these locations as well. But I want to be careful about sprinkling ad hoc policies like this around the JDK. I note that the erroneous size-based optimization was copied into, and therefore needs to be removed from ConcurrentSkipListSet (JDK-8218945) and the set views of CHM (JDK-8219069). I'd more concerned about getting these cleaned up in the short term. > 3. Not to derail this thread but do think we need a new JIRA ticket to address Collections.disjoint? Seems like it has similar sins of calling size and using "!(c2 instanceof Set)" but I don't want to muddy the waters by covering any solutions to that method in this thread. Yeah I'm not sure what to do about Collections.disjoint(). Note that there are some statements in bug reports (possibly even made by me!) that assert that Collections.disjoint should be consistent with Set.removeAll. I don't think that's the case. As discussed elsewhere, removeAll() needs to be consistent about relying on the membership semantics of the argument collection. As Collections.disjoint currently stands, it has the big "Care must be exercised" disclaimer in its spec, and it goes to some length to make a bunch of tests and vary the iteration accordingly. The programmer can get a speedup using disjoint() compared to copying a set and then calling retainAll(), provided sufficient care is taken. Maybe that's an acceptable tradeoff. If you have any ideas about how disjoint()'s spec or implementation could be improved, you could file a JIRA issue, or I could file one if you sent me the info. s'marks From javalists at cbfiddle.com Tue May 5 01:44:14 2020 From: javalists at cbfiddle.com (Alan Snyder) Date: Mon, 4 May 2020 18:44:14 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> Message-ID: What problem are you trying to solve? The Collections framework explicitly does not support custom membership semantics. If you think it should, file an RFE and create a JEP. It?s not a small change and tinkering is not the way to get there. If your present concern is performance surprises, be aware that your new proposal has the same problem as the old one. Although it removes some data-dependent performance surprises, it adds a potential JDK-dependent performance surprise. The data-dependent performance issues can be detected by testing, but no amount of testing can alert a developer to the possibility that an unexpected implementation change in a future JDK might cause a big performance hit. You may have mis-remembered the performance problem that I am concerned about. It involves using removeAll to remove a relatively small number of elements from a large, hash based collection. The performance hit is the need to iterate over the entire collection and test every element regardless of the number of elements being removed. Although the performance problem may be exacerbated when the argument is a List, the problem exists for any collection that is much smaller than the target collection. Alan > On May 4, 2020, at 5:25 PM, Stuart Marks wrote: > > > > On 5/1/20 10:41 PM, Jason Mehrens wrote: >> 1. I assume you are using "c instanceof List" instead of "!(c instanceof Set)" to correctly handle IdentitityHashMap.values()? The instanceof List seems like safe choice but it is too bad we can still fool that check by wrapping List as an unmodifiableCollection. If splitIterator().characteristics() could tell us that the collection used identity comparisons I think we would be able to determine if it was safe to swap the ordering in the general case as we could check for IDENTITY, SORTED, and comparator equality. > > I'm using "instance List", not for the reason of IdentityHashMap.values() specifically (though that's a good example), but mainly to try to be minimal. While I think getting the semantics right takes priority, the change does impact performance, so I want to reintroduce the performance heuristic in the safest manner possible. Checking for !Set seems dangerous, as there might be any number of Collections out there that aren't Sets and that aren't consistent with equals. Checking for instanceof List seemed like the safest and most minimal thing to do. > > In fact, I'm not even sure how safe List is! It's certainly possible for someone to have a List that isn't consistent with equals. Such a thing might violate the List contract, but that hasn't stopped people from implementing such things (outside the JDK). > > I also toyed around with various additional tests for when it would be profitable to switch iteration to the smaller collection. This could be applied to a variety of consistent-with-equals set implementations in the JDK. The benefits of swapping the iteration is more modest in these cases compared to List, however. Avoiding repeated List.contains() helps avoid quasi-quadratic (O(M*N)) performance. Swapping iteration order of sets gets us only the smaller of O(M) vs O(N), which is still linear. > > Also, as you noted, this heuristic is easily defeated by things like the collection wrappers. > >> 2. Should code applied to HashSet.removeAll also be applied to HashMap.keySet().removeAll and HashMap.entrySet().removeAll? Collections::newSetFromMap will end up having different behavior if it is not consistently applied. > > I think the *results* will be consistent, but the *performance* might not be consistent. > > But these cases could result in pathological performance if removeAll(list) is called, so I'm a bit concerned about them. If we agree that "instanceof List" is a reasonable heuristic, then I don't have any objection in principle to adding it to these locations as well. But I want to be careful about sprinkling ad hoc policies like this around the JDK. > > I note that the erroneous size-based optimization was copied into, and therefore needs to be removed from ConcurrentSkipListSet (JDK-8218945) and the set views of CHM (JDK-8219069). I'd more concerned about getting these cleaned up in the short term. > >> 3. Not to derail this thread but do think we need a new JIRA ticket to address Collections.disjoint? Seems like it has similar sins of calling size and using "!(c2 instanceof Set)" but I don't want to muddy the waters by covering any solutions to that method in this thread. > > Yeah I'm not sure what to do about Collections.disjoint(). > > Note that there are some statements in bug reports (possibly even made by me!) that assert that Collections.disjoint should be consistent with Set.removeAll. I don't think that's the case. As discussed elsewhere, removeAll() needs to be consistent about relying on the membership semantics of the argument collection. > > As Collections.disjoint currently stands, it has the big "Care must be exercised" disclaimer in its spec, and it goes to some length to make a bunch of tests and vary the iteration accordingly. The programmer can get a speedup using disjoint() compared to copying a set and then calling retainAll(), provided sufficient care is taken. Maybe that's an acceptable tradeoff. > > If you have any ideas about how disjoint()'s spec or implementation could be improved, you could file a JIRA issue, or I could file one if you sent me the info. > > s'marks > From daniel.fuchs at oracle.com Tue May 5 12:42:37 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 5 May 2020 13:42:37 +0100 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> Message-ID: <779ec619-f61c-be8a-793d-15777e783e8e@oracle.com> Hi Mikael, I spotted another place where a residual reference to Solaris remains in a comment: src/java.base/unix/native/libnet/PlainSocketImpl.c 857 #if defined(_AIX) 858 if (errno == EINVAL) { 859 // On Solaris setsockopt will set errno to EINVAL if the socket 860 // is closed. The default error message is then confusing Otherwise I had a look at the networking related files and the changes seemed reasonable to me. best regards, -- daniel On 04/05/2020 06:12, Mikael Vidstedt wrote: > Please review this change which implements part of JEP 381: > > JBS:https://bugs.openjdk.java.net/browse/JDK-8244224 > webrev:http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/corelibs/open/webrev/ > JEP:https://bugs.openjdk.java.net/browse/JDK-8241787 > From maurizio.cimadamore at oracle.com Tue May 5 14:12:18 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 5 May 2020 15:12:18 +0100 Subject: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator) In-Reply-To: <111ffdb1-131a-b163-5751-b2d4a71929c9@gmail.com> References: <2fc767e1-c4bc-65ca-230d-9f7224f4ebe8@gmail.com> <7703864a-486a-36f1-7983-14df8923b71f@oracle.com> <790dc9a2-2807-4758-9f97-d0d3a8f2dcd0@oracle.com> <7e244f2b-fb78-c399-3dc7-be699396c3ea@oracle.com> <021a1013-cabc-760f-a1e4-5b36ed26f60a@gmail.com> <4d0bfd55-5792-7172-287f-7059e1499bcc@oracle.com> <30217bef-c680-48fe-973b-07ab52682bb6@oracle.com> <111ffdb1-131a-b163-5751-b2d4a71929c9@gmail.com> Message-ID: <3fc1a73c-0f48-be96-fd72-b94009b930f2@oracle.com> On 02/05/2020 09:45, Peter Levart wrote: > > Thread 1 does: > > a) increments 'acquires' > > b) reads OPEN from 'state' > > > Thread 2 does: > > c) writes CLOSING to 'state' > > d) sums 'acquires' > > > 'a' happens before 'b' happens before 'c' happens before 'd' => 'a' > happens before 'd' > Where did you get the "b" happens before "c" edge? I think it's more subtle then that? E.g. if thread 1 saw OPEN, _then_ you can establish an HB edge between (b) and (c). But it could also be the case that Thread 1 reads CLOSED and starts to spin - so we need also to prove that there's some HB edges in that case (which I've tried to do in my email). I think this is the actual _difficult_ case to prove (I agree that the other is just transitive property of HB) - I think I've convinced myself that we should be in the clear also for the path when Thread 1 reads CLOSING, but I found it more subtle there to prove that either one thread or the other would fail. E.g. can there be a situation where BOTH operations fail? Maurizio From powers.anirvan at gmail.com Tue May 5 15:15:44 2020 From: powers.anirvan at gmail.com (Anirvan Sarkar) Date: Wed, 6 May 2020 00:15:44 +0900 Subject: 8244293 : Remove outdated @apiNote in java.util.Objects In-Reply-To: <8DE622E2-926E-4641-86EF-1C08C32E6ADF@oracle.com> References: <8DE622E2-926E-4641-86EF-1C08C32E6ADF@oracle.com> Message-ID: Hi Paul, Thanks for sponsoring ! On Tue, 5 May 2020 at 01:16, Paul Sandoz wrote: > Hi, > > Removing all of the api note looks good, since it was really written in > the context of the removed methods. > > I?ll sponsor. (I removed the methods but forgot to remove the note.) > > Paul. > > > On May 3, 2020, at 9:03 AM, Anirvan Sarkar > wrote: > > > > Hi, > > > > The class level @apiNote in java.util.Objects refers to variation of > static > > methods checkIndex(int, int), checkFromToIndex(int, int, int), and > > checkFromIndexSize(int, int, int), which support customization of the > > runtime exception, and corresponding exception detail message. > > > > But these static methods were removed from java.util.Objects as part of > > JDK-8155794 [1]. > > So the @apiNote in java.util.Objects is outdated. > > > > I have created JBS issue to remove the @apiNote [2]. > > Patch is attached. > > > > Can someone review and sponsor it? > > > > [1] : https://bugs.openjdk.java.net/browse/JDK-8155794 > > [2] : https://bugs.openjdk.java.net/browse/JDK-8244293 > > > > -- > > Anirvan > > > > -- Anirvan From peter.levart at gmail.com Tue May 5 16:37:55 2020 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 5 May 2020 18:37:55 +0200 Subject: [15] RFR: 8244152: Remove unnecessary hash map resize in LocaleProviderAdapters In-Reply-To: References: Message-ID: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> Hi Naoto, On 4/30/20 12:18 AM, naoto.sato at oracle.com wrote: > Hello, > > Please review this small fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8244152 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ > > The hash map used there didn't have initial capacity, even though the > exact numbers are known. Well, it has to be calculated 1st (countTokens), but I guess this pays off when HashSet (the backing HashMap) does not have to be rehashed then. The expression you use: ??? Math.max((int)(tokens.countTokens() / 0.75f) + 1, 16) ...has a minimum value of 16. Why is that? 16 is just HashMap's default initialCapacity if not specified explicitly. But if you only want to store say 1 entry in the map, you can specify 2 as initialCapacity and HashMap will happily work for such case without resizing. So you could just use: ??? (int)(tokens.countTokens() / 0.75f) + 1 And even this expression is sometimes overshooting the minimal required value by 1 (when # of tokens is "exact" multiple of 0.75f, say 6). I think the following could be used to optimally pre-size the HashMap with default load factor 0.75: ??? (tokens.countTokens() * 4 + 2) / 3 Regards, Peter > > Naoto From aleksej.efimov at oracle.com Tue May 5 17:23:23 2020 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Tue, 5 May 2020 18:23:23 +0100 Subject: RFR [LDAP]: 8062947: Fix exception message to correctly represent LDAP connection failure Message-ID: <8cfc457f-ed92-535e-5798-1a6f586b02c0@oracle.com> Hi, NamingException message is not precise about the cause of LDAP connection failure, i.e. in case of LDAP connection closure the NamingException with misleading message is thrown: "LDAP response read timed out, timeout used:-1ms.": https://bugs.openjdk.java.net/browse/JDK-8062947 The following fix tries to tackle this issue: http://cr.openjdk.java.net/~aefimov/8062947/00 Also, while we're here we can remove the commented debug code blocks in Connection class LDAP regression and javax.naming JCK tests are green - no failures With Best Regards, Aleksei From naoto.sato at oracle.com Tue May 5 17:25:13 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 5 May 2020 10:25:13 -0700 Subject: [15] RFR: 8244152: Remove unnecessary hash map resize in LocaleProviderAdapters In-Reply-To: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> References: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> Message-ID: <46715fee-ae7f-d281-37c7-6189004fe621@oracle.com> Hi Peter, You are correct. Thanks. I'll remove that initial value of 16. Naoto On 5/5/20 9:37 AM, Peter Levart wrote: > Hi Naoto, > > On 4/30/20 12:18 AM, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review this small fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8244152 >> >> The proposed changeset is located at: >> >> https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ >> >> The hash map used there didn't have initial capacity, even though the >> exact numbers are known. > > > Well, it has to be calculated 1st (countTokens), but I guess this pays > off when HashSet (the backing HashMap) does not have to be rehashed then. > > The expression you use: > > ??? Math.max((int)(tokens.countTokens() / 0.75f) + 1, 16) > > ...has a minimum value of 16. Why is that? 16 is just HashMap's default > initialCapacity if not specified explicitly. But if you only want to > store say 1 entry in the map, you can specify 2 as initialCapacity and > HashMap will happily work for such case without resizing. > > > So you could just use: > > ??? (int)(tokens.countTokens() / 0.75f) + 1 > > And even this expression is sometimes overshooting the minimal required > value by 1 (when # of tokens is "exact" multiple of 0.75f, say 6). I > think the following could be used to optimally pre-size the HashMap with > default load factor 0.75: > > ??? (tokens.countTokens() * 4 + 2) / 3 > > > Regards, Peter > >> >> Naoto From peter.levart at gmail.com Tue May 5 17:50:19 2020 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 5 May 2020 19:50:19 +0200 Subject: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator) In-Reply-To: <3fc1a73c-0f48-be96-fd72-b94009b930f2@oracle.com> References: <2fc767e1-c4bc-65ca-230d-9f7224f4ebe8@gmail.com> <7703864a-486a-36f1-7983-14df8923b71f@oracle.com> <790dc9a2-2807-4758-9f97-d0d3a8f2dcd0@oracle.com> <7e244f2b-fb78-c399-3dc7-be699396c3ea@oracle.com> <021a1013-cabc-760f-a1e4-5b36ed26f60a@gmail.com> <4d0bfd55-5792-7172-287f-7059e1499bcc@oracle.com> <30217bef-c680-48fe-973b-07ab52682bb6@oracle.com> <111ffdb1-131a-b163-5751-b2d4a71929c9@gmail.com> <3fc1a73c-0f48-be96-fd72-b94009b930f2@oracle.com> Message-ID: <40780e01-930a-88c5-200d-0d7f6b8b9158@gmail.com> Hi Maurizio, On 5/5/20 4:12 PM, Maurizio Cimadamore wrote: > > On 02/05/2020 09:45, Peter Levart wrote: >> >> Thread 1 does: >> >> a) increments 'acquires' >> >> b) reads OPEN from 'state' >> >> >> Thread 2 does: >> >> c) writes CLOSING to 'state' >> >> d) sums 'acquires' >> >> >> 'a' happens before 'b' happens before 'c' happens before 'd' => 'a' >> happens before 'd' >> > Where did you get the "b" happens before "c" edge? I think it's more > subtle then that? E.g. if thread 1 saw OPEN, _then_ you can establish > an HB edge between (b) and (c). But it could also be the case that > Thread 1 reads CLOSED and starts to spin - so we need also to prove > that there's some HB edges in that case (which I've tried to do in my > email). I think this is the actual _difficult_ case to prove (I agree > that the other is just transitive property of HB) - I think I've > convinced myself that we should be in the clear also for the path when > Thread 1 reads CLOSING, but I found it more subtle there to prove that > either one thread or the other would fail. > > E.g. can there be a situation where BOTH operations fail? > > Maurizio > There is one precondition which has to be present for this to work correctly. That close() is only executed by one thread. And in case of MemoryScope, this is true, because calls to close() are pre-screened by MemorySegment which checks that close() is executed only in owner thread. So if this is true, then it follows that 'b' happens before 'c' because in 'b' we did not see the effect of 'c' and 'c' is volatile write and 'b' is volatile read. So for the case that you was asking: > One question: the more I look at the code, the less I'm sure that a > close vs. access race cannot occur. I'm considering this situation: > > * thread 1 does acquire, and find state == OPEN > * thread 2 does close, set state to CLOSING, then checks if the adders > match > > But, how can we be sure that the value we get back from the adder > (e.g. acquires.sum()) is accurate and reflects the fact that thread > (1) has entered already? > ...this is all that needs to be proven. For other cases, the proof of correctness is of course different. So you are concerned about the case where the acquiring thread reads CLOSED. This is simple, since at that point the thread would just increment the releases (to level them back with acquires) and fail with exception. If that happens than we are also sure that the closing thread did successfully close the scope, so we have this mutual exclusion covered in this case where one thread is guaranteed to succeed while the other is guaranteed to fail. The interesting case is when the acquiring thread reads CLOSING. In that case it will spin-loop, re-reading the state until it either gets reset back to OPEN or set to CLOSED. So we have 2 sub-cases how the loop ends: - it finally reads CLOSED - in this case the closing thread decided to successfully close the scope, so acquiring thread fails - if finally reads OPEN - in this case the closing thread decided that it should not close the scope so close() fails, but acquiring thread succeeds. So in both above sub-cases we have the mutual exclusion covered. Notice that for this last three cases it was not important what closing thread read from acquires.sum() and releases.sum(). So we don't have to prove anything about the ordering of those two operations. Regards, Peter From naoto.sato at oracle.com Tue May 5 18:01:55 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 5 May 2020 11:01:55 -0700 Subject: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters In-Reply-To: <46715fee-ae7f-d281-37c7-6189004fe621@oracle.com> References: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> <46715fee-ae7f-d281-37c7-6189004fe621@oracle.com> Message-ID: <71a3c4e7-4dd1-ec96-0699-830f1667b9c7@oracle.com> And here is the fix. Please review. http://cr.openjdk.java.net/~naoto/8244459/webrev.00/ Naoto On 5/5/20 10:25 AM, naoto.sato at oracle.com wrote: > Hi Peter, > > You are correct. Thanks. I'll remove that initial value of 16. > > Naoto > > On 5/5/20 9:37 AM, Peter Levart wrote: >> Hi Naoto, >> >> On 4/30/20 12:18 AM, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> Please review this small fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8244152 >>> >>> The proposed changeset is located at: >>> >>> https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ >>> >>> The hash map used there didn't have initial capacity, even though the >>> exact numbers are known. >> >> >> Well, it has to be calculated 1st (countTokens), but I guess this pays >> off when HashSet (the backing HashMap) does not have to be rehashed then. >> >> The expression you use: >> >> ???? Math.max((int)(tokens.countTokens() / 0.75f) + 1, 16) >> >> ...has a minimum value of 16. Why is that? 16 is just HashMap's >> default initialCapacity if not specified explicitly. But if you only >> want to store say 1 entry in the map, you can specify 2 as >> initialCapacity and HashMap will happily work for such case without >> resizing. >> >> >> So you could just use: >> >> ???? (int)(tokens.countTokens() / 0.75f) + 1 >> >> And even this expression is sometimes overshooting the minimal >> required value by 1 (when # of tokens is "exact" multiple of 0.75f, >> say 6). I think the following could be used to optimally pre-size the >> HashMap with default load factor 0.75: >> >> ???? (tokens.countTokens() * 4 + 2) / 3 >> >> >> Regards, Peter >> >>> >>> Naoto From huizhe.wang at oracle.com Tue May 5 18:29:13 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 5 May 2020 11:29:13 -0700 Subject: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters In-Reply-To: <71a3c4e7-4dd1-ec96-0699-830f1667b9c7@oracle.com> References: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> <46715fee-ae7f-d281-37c7-6189004fe621@oracle.com> <71a3c4e7-4dd1-ec96-0699-830f1667b9c7@oracle.com> Message-ID: <0ad39c21-a5a4-6c38-b2ba-30d278b865a6@oracle.com> Hi Naoto, It seems you've missed the parentheses in : Set tagset = new HashSet<>(tokens.countTokens() * 4 + 2 / 3); vs Set tagset = new HashSet<>((tokens.countTokens() * 4 + 2) / 3); -Joe On 5/5/2020 11:01 AM, naoto.sato at oracle.com wrote: > And here is the fix. Please review. > > http://cr.openjdk.java.net/~naoto/8244459/webrev.00/ > > Naoto > > On 5/5/20 10:25 AM, naoto.sato at oracle.com wrote: >> Hi Peter, >> >> You are correct. Thanks. I'll remove that initial value of 16. >> >> Naoto >> >> On 5/5/20 9:37 AM, Peter Levart wrote: >>> Hi Naoto, >>> >>> On 4/30/20 12:18 AM, naoto.sato at oracle.com wrote: >>>> Hello, >>>> >>>> Please review this small fix to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8244152 >>>> >>>> The proposed changeset is located at: >>>> >>>> https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ >>>> >>>> The hash map used there didn't have initial capacity, even though >>>> the exact numbers are known. >>> >>> >>> Well, it has to be calculated 1st (countTokens), but I guess this >>> pays off when HashSet (the backing HashMap) does not have to be >>> rehashed then. >>> >>> The expression you use: >>> >>> ???? Math.max((int)(tokens.countTokens() / 0.75f) + 1, 16) >>> >>> ...has a minimum value of 16. Why is that? 16 is just HashMap's >>> default initialCapacity if not specified explicitly. But if you only >>> want to store say 1 entry in the map, you can specify 2 as >>> initialCapacity and HashMap will happily work for such case without >>> resizing. >>> >>> >>> So you could just use: >>> >>> ???? (int)(tokens.countTokens() / 0.75f) + 1 >>> >>> And even this expression is sometimes overshooting the minimal >>> required value by 1 (when # of tokens is "exact" multiple of 0.75f, >>> say 6). I think the following could be used to optimally pre-size >>> the HashMap with default load factor 0.75: >>> >>> ???? (tokens.countTokens() * 4 + 2) / 3 >>> >>> >>> Regards, Peter >>> >>>> >>>> Naoto From martinrb at google.com Tue May 5 18:26:58 2020 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 May 2020 11:26:58 -0700 Subject: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters In-Reply-To: <71a3c4e7-4dd1-ec96-0699-830f1667b9c7@oracle.com> References: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> <46715fee-ae7f-d281-37c7-6189004fe621@oracle.com> <71a3c4e7-4dd1-ec96-0699-830f1667b9c7@oracle.com> Message-ID: See related: https://guava.dev/releases/23.0/api/docs/com/google/common/collect/Maps.html#newHashMapWithExpectedSize-int- On Tue, May 5, 2020 at 11:03 AM wrote: > And here is the fix. Please review. > > http://cr.openjdk.java.net/~naoto/8244459/webrev.00/ > > Naoto > > On 5/5/20 10:25 AM, naoto.sato at oracle.com wrote: > > Hi Peter, > > > > You are correct. Thanks. I'll remove that initial value of 16. > > > > Naoto > > > > On 5/5/20 9:37 AM, Peter Levart wrote: > >> Hi Naoto, > >> > >> On 4/30/20 12:18 AM, naoto.sato at oracle.com wrote: > >>> Hello, > >>> > >>> Please review this small fix to the following issue: > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8244152 > >>> > >>> The proposed changeset is located at: > >>> > >>> https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ > >>> > >>> The hash map used there didn't have initial capacity, even though the > >>> exact numbers are known. > >> > >> > >> Well, it has to be calculated 1st (countTokens), but I guess this pays > >> off when HashSet (the backing HashMap) does not have to be rehashed > then. > >> > >> The expression you use: > >> > >> Math.max((int)(tokens.countTokens() / 0.75f) + 1, 16) > >> > >> ...has a minimum value of 16. Why is that? 16 is just HashMap's > >> default initialCapacity if not specified explicitly. But if you only > >> want to store say 1 entry in the map, you can specify 2 as > >> initialCapacity and HashMap will happily work for such case without > >> resizing. > >> > >> > >> So you could just use: > >> > >> (int)(tokens.countTokens() / 0.75f) + 1 > >> > >> And even this expression is sometimes overshooting the minimal > >> required value by 1 (when # of tokens is "exact" multiple of 0.75f, > >> say 6). I think the following could be used to optimally pre-size the > >> HashMap with default load factor 0.75: > >> > >> (tokens.countTokens() * 4 + 2) / 3 > >> > >> > >> Regards, Peter > >> > >>> > >>> Naoto > From michaelkroll at mail.de Tue May 5 18:55:00 2020 From: michaelkroll at mail.de (M. Kroll) Date: Tue, 5 May 2020 20:55:00 +0200 Subject: CfD: compile-time checked immutable collections Message-ID: <0e238928-f7c8-f806-64ce-b3920a95068b@mail.de> Hey there! I am new here so first i want to introduce myself. My name is Michael and i live in germany. For a job i am a java developer with 10 years of java EE experience. At work my passion is to create long-living core tools for our projects. But now for the reason i joined openjdk and this group in particular: immutable collections. During development i sometimes stumble upon the fact that there is no simple way build an immutable object that exposes a read-only collection, and all this in a compile-time safe manner. To explain it with code, i want to have something like this: class Example { ??? private final Collection values; ??? public Example(String... args) { this.values = Arrays.asList(args); } ??? public Collection getValues() { return values; } } class Test { ??? public void test() { ??????? Collection v = new Example("a","b","c").getValues(); ??????? v.clear(); // <-- compile time error ??? } } The current approach to this is using either Collections.unmodifiableXYZ(...), which may lead to runtime exceptions. Or we use Stream as return object, but there is no simple way to pass that around and use it multiple times. I don't see Supplier as a solution to this: determining the size of the collection would need to traverse the whole stream, even if the underlying collection is an arraylist... not good. My approach to this would be to split up the Collection-Interface into a read-only and a mutating part. But before i present you my somewhat complete solution, i asked myself if you already discussed something like that. So i dived into the bug database and found 3 somewhat similar tickets: 1. https://bugs.openjdk.java.net/browse/JDK-6432147 ? ? The author wanted to introduce annotations to mark objects as immutable and on basis of this raise compile exceptions. This would need a load of annotations throughout the code and additional rules to check by the compiler. The ticket was closed as a duplicate to [2] 2. https://bugs.openjdk.java.net/browse/JDK-4211070 ??? The author wanted to introduce a new keyword 'const' to be used just like the annotation in [1]. Same problem: massive spray of the new keyword throughout the code and the need for a change in the compiler and even in the language. 3. https://bugs.openjdk.java.net/browse/JDK-5099784 ??? This is as old as JDK1.4.2 (2004) and proposes the same way i want to go: split the Collection-interface into a new parent-interface that contains all non-modifying methods and the Collection-interface itself that then only contains modifying methods. A user of the Collection-interface would see the same API as before, a user of the new parent-interface would only see read-only methods. The original author of [3] is inactive by now, the ticket itself was not discussed and is still unresolved open. I would happily try to implement this approach, but first i want to know if this is the way to go and what your thoughts are about this. Hope this is not too much text for a Call for Discussion, Michael From peter.levart at gmail.com Tue May 5 19:12:37 2020 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 5 May 2020 21:12:37 +0200 Subject: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters In-Reply-To: References: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> <46715fee-ae7f-d281-37c7-6189004fe621@oracle.com> <71a3c4e7-4dd1-ec96-0699-830f1667b9c7@oracle.com> Message-ID: Hi Martin, On 5/5/20 8:26 PM, Martin Buchholz wrote: > See related: > https://guava.dev/releases/23.0/api/docs/com/google/common/collect/Maps.html#newHashMapWithExpectedSize-int- This is basically the same calculation (or at least gives same result) as Naoto did (without the max part): Naoto: (int)(expectedSize / 0.75f) + 1 Guava: (int) ((float) expectedSize / 0.75F + 1.0F) but in case expectedSize is a multiple of 3, it gives the result which is 1 more than needed. If what is needed is also a power of 2, then twice the needed space is allocated in the HashMap backing table. Regards, Peter > > On Tue, May 5, 2020 at 11:03 AM > wrote: > > And here is the fix. Please review. > > http://cr.openjdk.java.net/~naoto/8244459/webrev.00/ > > Naoto > > On 5/5/20 10:25 AM, naoto.sato at oracle.com > wrote: > > Hi Peter, > > > > You are correct. Thanks. I'll remove that initial value of 16. > > > > Naoto > > > > On 5/5/20 9:37 AM, Peter Levart wrote: > >> Hi Naoto, > >> > >> On 4/30/20 12:18 AM, naoto.sato at oracle.com > wrote: > >>> Hello, > >>> > >>> Please review this small fix to the following issue: > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8244152 > >>> > >>> The proposed changeset is located at: > >>> > >>> https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ > >>> > >>> The hash map used there didn't have initial capacity, even > though the > >>> exact numbers are known. > >> > >> > >> Well, it has to be calculated 1st (countTokens), but I guess > this pays > >> off when HashSet (the backing HashMap) does not have to be > rehashed then. > >> > >> The expression you use: > >> > >> ???? Math.max((int)(tokens.countTokens() / 0.75f) + 1, 16) > >> > >> ...has a minimum value of 16. Why is that? 16 is just HashMap's > >> default initialCapacity if not specified explicitly. But if you > only > >> want to store say 1 entry in the map, you can specify 2 as > >> initialCapacity and HashMap will happily work for such case > without > >> resizing. > >> > >> > >> So you could just use: > >> > >> ???? (int)(tokens.countTokens() / 0.75f) + 1 > >> > >> And even this expression is sometimes overshooting the minimal > >> required value by 1 (when # of tokens is "exact" multiple of > 0.75f, > >> say 6). I think the following could be used to optimally > pre-size the > >> HashMap with default load factor 0.75: > >> > >> ???? (tokens.countTokens() * 4 + 2) / 3 > >> > >> > >> Regards, Peter > >> > >>> > >>> Naoto > From martinrb at google.com Tue May 5 19:41:31 2020 From: martinrb at google.com (Martin Buchholz) Date: Tue, 5 May 2020 12:41:31 -0700 Subject: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters In-Reply-To: References: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> <46715fee-ae7f-d281-37c7-6189004fe621@oracle.com> <71a3c4e7-4dd1-ec96-0699-830f1667b9c7@oracle.com> Message-ID: Hi Peter, Are you saying guava has a tiny bug? On Tue, May 5, 2020 at 12:12 PM Peter Levart wrote: > Hi Martin, > On 5/5/20 8:26 PM, Martin Buchholz wrote: > > See related: > > https://guava.dev/releases/23.0/api/docs/com/google/common/collect/Maps.html#newHashMapWithExpectedSize-int- > > > This is basically the same calculation (or at least gives same result) as > Naoto did (without the max part): > > Naoto: (int)(expectedSize / 0.75f) + 1 > > Guava: (int) ((float) expectedSize / 0.75F + 1.0F) > > but in case expectedSize is a multiple of 3, it gives the result which is > 1 more than needed. If what is needed is also a power of 2, then twice the > needed space is allocated in the HashMap backing table. > > > Regards, Peter > > > > On Tue, May 5, 2020 at 11:03 AM wrote: > >> And here is the fix. Please review. >> >> http://cr.openjdk.java.net/~naoto/8244459/webrev.00/ >> >> Naoto >> >> On 5/5/20 10:25 AM, naoto.sato at oracle.com wrote: >> > Hi Peter, >> > >> > You are correct. Thanks. I'll remove that initial value of 16. >> > >> > Naoto >> > >> > On 5/5/20 9:37 AM, Peter Levart wrote: >> >> Hi Naoto, >> >> >> >> On 4/30/20 12:18 AM, naoto.sato at oracle.com wrote: >> >>> Hello, >> >>> >> >>> Please review this small fix to the following issue: >> >>> >> >>> https://bugs.openjdk.java.net/browse/JDK-8244152 >> >>> >> >>> The proposed changeset is located at: >> >>> >> >>> https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ >> >>> >> >>> The hash map used there didn't have initial capacity, even though the >> >>> exact numbers are known. >> >> >> >> >> >> Well, it has to be calculated 1st (countTokens), but I guess this pays >> >> off when HashSet (the backing HashMap) does not have to be rehashed >> then. >> >> >> >> The expression you use: >> >> >> >> Math.max((int)(tokens.countTokens() / 0.75f) + 1, 16) >> >> >> >> ...has a minimum value of 16. Why is that? 16 is just HashMap's >> >> default initialCapacity if not specified explicitly. But if you only >> >> want to store say 1 entry in the map, you can specify 2 as >> >> initialCapacity and HashMap will happily work for such case without >> >> resizing. >> >> >> >> >> >> So you could just use: >> >> >> >> (int)(tokens.countTokens() / 0.75f) + 1 >> >> >> >> And even this expression is sometimes overshooting the minimal >> >> required value by 1 (when # of tokens is "exact" multiple of 0.75f, >> >> say 6). I think the following could be used to optimally pre-size the >> >> HashMap with default load factor 0.75: >> >> >> >> (tokens.countTokens() * 4 + 2) / 3 >> >> >> >> >> >> Regards, Peter >> >> >> >>> >> >>> Naoto >> > From james.laskey at oracle.com Tue May 5 19:56:03 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 5 May 2020 16:56:03 -0300 Subject: RFR: JDK-8241602 jlink does not produce reproducible jimage files Message-ID: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> This fix addresses the inconsistent ordering by jimage content by jlink from run to run. Bottom line, the implementer was using HashSet without defining hashcode/equals for the Set entry classes. webrev: http://cr.openjdk.java.net/~jlaskey/8241602/webrev-00 jbs: https://bugs.openjdk.java.net/browse/JDK-8241602 Cheers, -- Jim From peter.levart at gmail.com Tue May 5 20:01:56 2020 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 5 May 2020 22:01:56 +0200 Subject: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters In-Reply-To: References: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> <46715fee-ae7f-d281-37c7-6189004fe621@oracle.com> <71a3c4e7-4dd1-ec96-0699-830f1667b9c7@oracle.com> Message-ID: <4e994519-c6bd-a6e9-2ef8-1e8be4ef6008@gmail.com> On 5/5/20 9:41 PM, Martin Buchholz wrote: > Hi Peter, > > Are you saying guava has a tiny bug? If it was just 1 too much when expected size is a multiple of 3 then that would not be a bug, just sub-optimal calculation. And the same calculation is performed also in JDK when a copy constructor is called for example. But I investigated further and what I found could be considered a bug. Sometimes, the following expression: (int) ((float) expectedSize / 0.75f + 1.0f) ...calculates a value that is not enough (due to floating point arithmetic and conversion to int) to store the expectedSize elements into the HashMap without re-hashing. What HashMap does with initialCapacity parameter is to round it up to nearest power of 2: ??? static int tableSizeFor(int cap) { ??????? int n = -1 >>> Integer.numberOfLeadingZeros(cap - 1); ??????? return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1; ??? } then it uses this as the initial backing table size. From that table size it calculates the threshold value: ??? static int threshold(int cap) { ??????? float ft = (float) cap * 0.75f; ??????? return (cap < MAXIMUM_CAPACITY && ft < (float) MAXIMUM_CAPACITY ? ??????????????? (int) ft : Integer.MAX_VALUE); ??? } ... and uses it as the max. number of elements that a HashMap can hold before it is re-hashed. So I did the following test (comparing the effectiveness of above formula with alternative (expectedSize*4+2)/3 formula): public class HMTest { ??? static final int MAXIMUM_CAPACITY = 1 << 30; ??? static int tableSizeFor(int cap) { ??????? int n = -1 >>> Integer.numberOfLeadingZeros(cap - 1); ??????? return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1; ??? } ??? static int threshold(int cap) { ??????? float ft = (float) cap * 0.75f; ??????? return (cap < MAXIMUM_CAPACITY && ft < (float) MAXIMUM_CAPACITY ? ??????????????? (int) ft : Integer.MAX_VALUE); ??? } ??? public static void main(String[] args) { ??????? for (int expectedSize = 0; expectedSize < (Integer.MAX_VALUE - 2) / 4; expectedSize++) { ??????????? int cap1 = (int) ((float) expectedSize / 0.75f + 1.0f); ??????????? int cap2 = (expectedSize * 4 + 2) / 3; ??????????? int ts1 = tableSizeFor(cap1); ??????????? int ts2 = tableSizeFor(cap2); ??????????? int th1 = threshold(ts1); ??????????? int th2 = threshold(ts2); ??????????? if (th1 < expectedSize || th2 < expectedSize) { ??????????????? System.out.printf("%d: (%d, %d, %d)%s (%d, %d, %d)%s\n", ??????????????????????? expectedSize, ??????????????????????? cap1, ts1, th1, (th1 < expectedSize) ? "!" : " ", ??????????????????????? cap2, ts2, th2, (th2 < expectedSize) ? "!" : " " ??????????????? ); ??????????? } ??????? } ??? } } And what this prints is the following: 25165825: (33554432, 33554432, 25165824)! (33554434, 67108864, 50331648) 50331649: (67108864, 67108864, 50331648)! (67108866, 134217728, 100663296) 50331650: (67108864, 67108864, 50331648)! (67108867, 134217728, 100663296) 100663297: (134217728, 134217728, 100663296)! (134217730, 268435456, 201326592) 100663298: (134217728, 134217728, 100663296)! (134217731, 268435456, 201326592) 100663299: (134217728, 134217728, 100663296)! (134217732, 268435456, 201326592) 100663300: (134217728, 134217728, 100663296)! (134217734, 268435456, 201326592) 201326593: (268435456, 268435456, 201326592)! (268435458, 536870912, 402653184) 201326594: (268435456, 268435456, 201326592)! (268435459, 536870912, 402653184) 201326595: (268435456, 268435456, 201326592)! (268435460, 536870912, 402653184) 201326596: (268435456, 268435456, 201326592)! (268435462, 536870912, 402653184) 201326597: (268435456, 268435456, 201326592)! (268435463, 536870912, 402653184) 201326598: (268435456, 268435456, 201326592)! (268435464, 536870912, 402653184) 201326599: (268435456, 268435456, 201326592)! (268435466, 536870912, 402653184) 201326600: (268435456, 268435456, 201326592)! (268435467, 536870912, 402653184) 402653185: (536870912, 536870912, 402653184)! (536870914, 1073741824, 2147483647) 402653186: (536870912, 536870912, 402653184)! (536870915, 1073741824, 2147483647) 402653187: (536870912, 536870912, 402653184)! (536870916, 1073741824, 2147483647) 402653188: (536870912, 536870912, 402653184)! (536870918, 1073741824, 2147483647) 402653189: (536870912, 536870912, 402653184)! (536870919, 1073741824, 2147483647) 402653190: (536870912, 536870912, 402653184)! (536870920, 1073741824, 2147483647) 402653191: (536870912, 536870912, 402653184)! (536870922, 1073741824, 2147483647) 402653192: (536870912, 536870912, 402653184)! (536870923, 1073741824, 2147483647) 402653193: (536870912, 536870912, 402653184)! (536870924, 1073741824, 2147483647) 402653194: (536870912, 536870912, 402653184)! (536870926, 1073741824, 2147483647) 402653195: (536870912, 536870912, 402653184)! (536870927, 1073741824, 2147483647) 402653196: (536870912, 536870912, 402653184)! (536870928, 1073741824, 2147483647) 402653197: (536870912, 536870912, 402653184)! (536870930, 1073741824, 2147483647) 402653198: (536870912, 536870912, 402653184)! (536870931, 1073741824, 2147483647) 402653199: (536870912, 536870912, 402653184)! (536870932, 1073741824, 2147483647) 402653200: (536870912, 536870912, 402653184)! (536870934, 1073741824, 2147483647) So as you see, for expectedSize < (Integer.MAX_VALUE - 2) / 4 (where the alternative formula does not experience overflow and is enough for Naoto's case) all miscalculations are due to the JDK/Guava formula which in those cases calculates a value that is less than alternative formula's value and too small to adequately pre-size the HashMap table. Voila, we have some bugs to fix or I am doing something wrong here. Regards, Peter > > On Tue, May 5, 2020 at 12:12 PM Peter Levart > wrote: > > Hi Martin, > > On 5/5/20 8:26 PM, Martin Buchholz wrote: >> See related: >> https://guava.dev/releases/23.0/api/docs/com/google/common/collect/Maps.html#newHashMapWithExpectedSize-int- > > > This is basically the same calculation (or at least gives same > result) as Naoto did (without the max part): > > Naoto: (int)(expectedSize / 0.75f) + 1 > > Guava: (int) ((float) expectedSize / 0.75F + 1.0F) > > but in case expectedSize is a multiple of 3, it gives the result > which is 1 more than needed. If what is needed is also a power of > 2, then twice the needed space is allocated in the HashMap backing > table. > > > Regards, Peter > > >> >> On Tue, May 5, 2020 at 11:03 AM > > wrote: >> >> And here is the fix. Please review. >> >> http://cr.openjdk.java.net/~naoto/8244459/webrev.00/ >> >> Naoto >> >> On 5/5/20 10:25 AM, naoto.sato at oracle.com >> wrote: >> > Hi Peter, >> > >> > You are correct. Thanks. I'll remove that initial value of 16. >> > >> > Naoto >> > >> > On 5/5/20 9:37 AM, Peter Levart wrote: >> >> Hi Naoto, >> >> >> >> On 4/30/20 12:18 AM, naoto.sato at oracle.com >> wrote: >> >>> Hello, >> >>> >> >>> Please review this small fix to the following issue: >> >>> >> >>> https://bugs.openjdk.java.net/browse/JDK-8244152 >> >>> >> >>> The proposed changeset is located at: >> >>> >> >>> https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ >> >>> >> >>> The hash map used there didn't have initial capacity, >> even though the >> >>> exact numbers are known. >> >> >> >> >> >> Well, it has to be calculated 1st (countTokens), but I >> guess this pays >> >> off when HashSet (the backing HashMap) does not have to be >> rehashed then. >> >> >> >> The expression you use: >> >> >> >> ???? Math.max((int)(tokens.countTokens() / 0.75f) + 1, 16) >> >> >> >> ...has a minimum value of 16. Why is that? 16 is just >> HashMap's >> >> default initialCapacity if not specified explicitly. But >> if you only >> >> want to store say 1 entry in the map, you can specify 2 as >> >> initialCapacity and HashMap will happily work for such >> case without >> >> resizing. >> >> >> >> >> >> So you could just use: >> >> >> >> ???? (int)(tokens.countTokens() / 0.75f) + 1 >> >> >> >> And even this expression is sometimes overshooting the >> minimal >> >> required value by 1 (when # of tokens is "exact" multiple >> of 0.75f, >> >> say 6). I think the following could be used to optimally >> pre-size the >> >> HashMap with default load factor 0.75: >> >> >> >> ???? (tokens.countTokens() * 4 + 2) / 3 >> >> >> >> >> >> Regards, Peter >> >> >> >>> >> >>> Naoto >> From peter.levart at gmail.com Tue May 5 20:26:52 2020 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 5 May 2020 22:26:52 +0200 Subject: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters In-Reply-To: <4e994519-c6bd-a6e9-2ef8-1e8be4ef6008@gmail.com> References: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> <46715fee-ae7f-d281-37c7-6189004fe621@oracle.com> <71a3c4e7-4dd1-ec96-0699-830f1667b9c7@oracle.com> <4e994519-c6bd-a6e9-2ef8-1e8be4ef6008@gmail.com> Message-ID: There's more... Guava (and JDK in copy constructor) formula: ??? (int) ((float) expectedSize / 0.75f + 1.0f) is not the same as Naoto's formula: ??? (int) (expectedSize / 0.75f) + 1 Notice that Naoto does addition of 1 in integer arithmetic after conversion to int, while Guava/JDK does in floating point before conversion to int. If I put Naoto's formula into my test program, no undercalculations are detected. So while Naoto's formula is sub-optimal for expectedSizes that are multiples of 3, the Guava/JDK also has a bug. Regards, Peter On 5/5/20 10:01 PM, Peter Levart wrote: > > > On 5/5/20 9:41 PM, Martin Buchholz wrote: >> Hi Peter, >> >> Are you saying guava has a tiny bug? > > > If it was just 1 too much when expected size is a multiple of 3 then > that would not be a bug, just sub-optimal calculation. And the same > calculation is performed also in JDK when a copy constructor is called > for example. > > > But I investigated further and what I found could be considered a bug. > Sometimes, the following expression: > > > (int) ((float) expectedSize / 0.75f + 1.0f) > > > ...calculates a value that is not enough (due to floating point > arithmetic and conversion to int) to store the expectedSize elements > into the HashMap without re-hashing. > > > What HashMap does with initialCapacity parameter is to round it up to > nearest power of 2: > > ??? static int tableSizeFor(int cap) { > ??????? int n = -1 >>> Integer.numberOfLeadingZeros(cap - 1); > ??????? return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? > MAXIMUM_CAPACITY : n + 1; > ??? } > > then it uses this as the initial backing table size. From that table > size it calculates the threshold value: > > ??? static int threshold(int cap) { > ??????? float ft = (float) cap * 0.75f; > ??????? return (cap < MAXIMUM_CAPACITY && ft < (float) MAXIMUM_CAPACITY ? > ??????????????? (int) ft : Integer.MAX_VALUE); > ??? } > > ... and uses it as the max. number of elements that a HashMap can hold > before it is re-hashed. So I did the following test (comparing the > effectiveness of above formula with alternative (expectedSize*4+2)/3 > formula): > > > public class HMTest { > ??? static final int MAXIMUM_CAPACITY = 1 << 30; > > ??? static int tableSizeFor(int cap) { > ??????? int n = -1 >>> Integer.numberOfLeadingZeros(cap - 1); > ??????? return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? > MAXIMUM_CAPACITY : n + 1; > ??? } > > ??? static int threshold(int cap) { > ??????? float ft = (float) cap * 0.75f; > ??????? return (cap < MAXIMUM_CAPACITY && ft < (float) MAXIMUM_CAPACITY ? > ??????????????? (int) ft : Integer.MAX_VALUE); > ??? } > > ??? public static void main(String[] args) { > ??????? for (int expectedSize = 0; expectedSize < (Integer.MAX_VALUE - > 2) / 4; expectedSize++) { > ??????????? int cap1 = (int) ((float) expectedSize / 0.75f + 1.0f); > ??????????? int cap2 = (expectedSize * 4 + 2) / 3; > ??????????? int ts1 = tableSizeFor(cap1); > ??????????? int ts2 = tableSizeFor(cap2); > ??????????? int th1 = threshold(ts1); > ??????????? int th2 = threshold(ts2); > > ??????????? if (th1 < expectedSize || th2 < expectedSize) { > ??????????????? System.out.printf("%d: (%d, %d, %d)%s (%d, %d, %d)%s\n", > ??????????????????????? expectedSize, > ??????????????????????? cap1, ts1, th1, (th1 < expectedSize) ? "!" : " ", > ??????????????????????? cap2, ts2, th2, (th2 < expectedSize) ? "!" : " " > ??????????????? ); > ??????????? } > ??????? } > ??? } > } > > > And what this prints is the following: > > > 25165825: (33554432, 33554432, 25165824)! (33554434, 67108864, 50331648) > 50331649: (67108864, 67108864, 50331648)! (67108866, 134217728, > 100663296) > 50331650: (67108864, 67108864, 50331648)! (67108867, 134217728, > 100663296) > 100663297: (134217728, 134217728, 100663296)! (134217730, 268435456, > 201326592) > 100663298: (134217728, 134217728, 100663296)! (134217731, 268435456, > 201326592) > 100663299: (134217728, 134217728, 100663296)! (134217732, 268435456, > 201326592) > 100663300: (134217728, 134217728, 100663296)! (134217734, 268435456, > 201326592) > 201326593: (268435456, 268435456, 201326592)! (268435458, 536870912, > 402653184) > 201326594: (268435456, 268435456, 201326592)! (268435459, 536870912, > 402653184) > 201326595: (268435456, 268435456, 201326592)! (268435460, 536870912, > 402653184) > 201326596: (268435456, 268435456, 201326592)! (268435462, 536870912, > 402653184) > 201326597: (268435456, 268435456, 201326592)! (268435463, 536870912, > 402653184) > 201326598: (268435456, 268435456, 201326592)! (268435464, 536870912, > 402653184) > 201326599: (268435456, 268435456, 201326592)! (268435466, 536870912, > 402653184) > 201326600: (268435456, 268435456, 201326592)! (268435467, 536870912, > 402653184) > 402653185: (536870912, 536870912, 402653184)! (536870914, 1073741824, > 2147483647) > 402653186: (536870912, 536870912, 402653184)! (536870915, 1073741824, > 2147483647) > 402653187: (536870912, 536870912, 402653184)! (536870916, 1073741824, > 2147483647) > 402653188: (536870912, 536870912, 402653184)! (536870918, 1073741824, > 2147483647) > 402653189: (536870912, 536870912, 402653184)! (536870919, 1073741824, > 2147483647) > 402653190: (536870912, 536870912, 402653184)! (536870920, 1073741824, > 2147483647) > 402653191: (536870912, 536870912, 402653184)! (536870922, 1073741824, > 2147483647) > 402653192: (536870912, 536870912, 402653184)! (536870923, 1073741824, > 2147483647) > 402653193: (536870912, 536870912, 402653184)! (536870924, 1073741824, > 2147483647) > 402653194: (536870912, 536870912, 402653184)! (536870926, 1073741824, > 2147483647) > 402653195: (536870912, 536870912, 402653184)! (536870927, 1073741824, > 2147483647) > 402653196: (536870912, 536870912, 402653184)! (536870928, 1073741824, > 2147483647) > 402653197: (536870912, 536870912, 402653184)! (536870930, 1073741824, > 2147483647) > 402653198: (536870912, 536870912, 402653184)! (536870931, 1073741824, > 2147483647) > 402653199: (536870912, 536870912, 402653184)! (536870932, 1073741824, > 2147483647) > 402653200: (536870912, 536870912, 402653184)! (536870934, 1073741824, > 2147483647) > > > So as you see, for expectedSize < (Integer.MAX_VALUE - 2) / 4 (where > the alternative formula does not experience overflow and is enough for > Naoto's case) all miscalculations are due to the JDK/Guava formula > which in those cases calculates a value that is less than alternative > formula's value and too small to adequately pre-size the HashMap table. > > > Voila, we have some bugs to fix or I am doing something wrong here. > > > Regards, Peter > > >> >> On Tue, May 5, 2020 at 12:12 PM Peter Levart > > wrote: >> >> Hi Martin, >> >> On 5/5/20 8:26 PM, Martin Buchholz wrote: >>> See related: >>> https://guava.dev/releases/23.0/api/docs/com/google/common/collect/Maps.html#newHashMapWithExpectedSize-int- >> >> >> This is basically the same calculation (or at least gives same >> result) as Naoto did (without the max part): >> >> Naoto: (int)(expectedSize / 0.75f) + 1 >> >> Guava: (int) ((float) expectedSize / 0.75F + 1.0F) >> >> but in case expectedSize is a multiple of 3, it gives the result >> which is 1 more than needed. If what is needed is also a power of >> 2, then twice the needed space is allocated in the HashMap >> backing table. >> >> >> Regards, Peter >> >> >>> >>> On Tue, May 5, 2020 at 11:03 AM >> > wrote: >>> >>> And here is the fix. Please review. >>> >>> http://cr.openjdk.java.net/~naoto/8244459/webrev.00/ >>> >>> Naoto >>> >>> On 5/5/20 10:25 AM, naoto.sato at oracle.com >>> wrote: >>> > Hi Peter, >>> > >>> > You are correct. Thanks. I'll remove that initial value of 16. >>> > >>> > Naoto >>> > >>> > On 5/5/20 9:37 AM, Peter Levart wrote: >>> >> Hi Naoto, >>> >> >>> >> On 4/30/20 12:18 AM, naoto.sato at oracle.com >>> wrote: >>> >>> Hello, >>> >>> >>> >>> Please review this small fix to the following issue: >>> >>> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8244152 >>> >>> >>> >>> The proposed changeset is located at: >>> >>> >>> >>> https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ >>> >>> >>> >>> The hash map used there didn't have initial capacity, >>> even though the >>> >>> exact numbers are known. >>> >> >>> >> >>> >> Well, it has to be calculated 1st (countTokens), but I >>> guess this pays >>> >> off when HashSet (the backing HashMap) does not have to >>> be rehashed then. >>> >> >>> >> The expression you use: >>> >> >>> >> ???? Math.max((int)(tokens.countTokens() / 0.75f) + 1, 16) >>> >> >>> >> ...has a minimum value of 16. Why is that? 16 is just >>> HashMap's >>> >> default initialCapacity if not specified explicitly. But >>> if you only >>> >> want to store say 1 entry in the map, you can specify 2 as >>> >> initialCapacity and HashMap will happily work for such >>> case without >>> >> resizing. >>> >> >>> >> >>> >> So you could just use: >>> >> >>> >> ???? (int)(tokens.countTokens() / 0.75f) + 1 >>> >> >>> >> And even this expression is sometimes overshooting the >>> minimal >>> >> required value by 1 (when # of tokens is "exact" multiple >>> of 0.75f, >>> >> say 6). I think the following could be used to optimally >>> pre-size the >>> >> HashMap with default load factor 0.75: >>> >> >>> >> ???? (tokens.countTokens() * 4 + 2) / 3 >>> >> >>> >> >>> >> Regards, Peter >>> >> >>> >>> >>> >>> Naoto >>> From peter.levart at gmail.com Tue May 5 20:50:49 2020 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 5 May 2020 22:50:49 +0200 Subject: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters In-Reply-To: <0ad39c21-a5a4-6c38-b2ba-30d278b865a6@oracle.com> References: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> <46715fee-ae7f-d281-37c7-6189004fe621@oracle.com> <71a3c4e7-4dd1-ec96-0699-830f1667b9c7@oracle.com> <0ad39c21-a5a4-6c38-b2ba-30d278b865a6@oracle.com> Message-ID: <87e924eb-7960-c8f9-c490-ca6e7b90cd4b@gmail.com> On 5/5/20 8:29 PM, Joe Wang wrote: > Hi Naoto, > > It seems you've missed the parentheses in : > Set tagset = new HashSet<>(tokens.countTokens() * 4 + 2 / 3); > vs > Set tagset = new HashSet<>((tokens.countTokens() * 4 + 2) / 3); > > -Joe Just a reminder to Naoto: In all this excitement, don't loose track on those parentheses (like Dirty Harry lost track of shots fired) ;-) Regards, Peter > > On 5/5/2020 11:01 AM, naoto.sato at oracle.com wrote: >> And here is the fix. Please review. >> >> http://cr.openjdk.java.net/~naoto/8244459/webrev.00/ >> >> Naoto >> >> On 5/5/20 10:25 AM, naoto.sato at oracle.com wrote: >>> Hi Peter, >>> >>> You are correct. Thanks. I'll remove that initial value of 16. >>> >>> Naoto >>> >>> On 5/5/20 9:37 AM, Peter Levart wrote: >>>> Hi Naoto, >>>> >>>> On 4/30/20 12:18 AM, naoto.sato at oracle.com wrote: >>>>> Hello, >>>>> >>>>> Please review this small fix to the following issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8244152 >>>>> >>>>> The proposed changeset is located at: >>>>> >>>>> https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ >>>>> >>>>> The hash map used there didn't have initial capacity, even though >>>>> the exact numbers are known. >>>> >>>> >>>> Well, it has to be calculated 1st (countTokens), but I guess this >>>> pays off when HashSet (the backing HashMap) does not have to be >>>> rehashed then. >>>> >>>> The expression you use: >>>> >>>> ???? Math.max((int)(tokens.countTokens() / 0.75f) + 1, 16) >>>> >>>> ...has a minimum value of 16. Why is that? 16 is just HashMap's >>>> default initialCapacity if not specified explicitly. But if you >>>> only want to store say 1 entry in the map, you can specify 2 as >>>> initialCapacity and HashMap will happily work for such case without >>>> resizing. >>>> >>>> >>>> So you could just use: >>>> >>>> ???? (int)(tokens.countTokens() / 0.75f) + 1 >>>> >>>> And even this expression is sometimes overshooting the minimal >>>> required value by 1 (when # of tokens is "exact" multiple of 0.75f, >>>> say 6). I think the following could be used to optimally pre-size >>>> the HashMap with default load factor 0.75: >>>> >>>> ???? (tokens.countTokens() * 4 + 2) / 3 >>>> >>>> >>>> Regards, Peter >>>> >>>>> >>>>> Naoto > From naoto.sato at oracle.com Tue May 5 21:08:46 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 5 May 2020 14:08:46 -0700 Subject: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters In-Reply-To: <71a3c4e7-4dd1-ec96-0699-830f1667b9c7@oracle.com> References: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> <46715fee-ae7f-d281-37c7-6189004fe621@oracle.com> <71a3c4e7-4dd1-ec96-0699-830f1667b9c7@oracle.com> Message-ID: <5c22598c-cba4-bcb9-4c52-6994e95d4355@oracle.com> Thanks, all. I didn't see this coming! If I understand the discussion correctly, Peter's suggestion is the most optimal (Mark, your formula produces 1 for the expected size is 0, although it won't be happening in this particular case). And Joe, thank you for finding my silly mistake :-) So here is the updated webrev: http://cr.openjdk.java.net/~naoto/8244459/webrev.01/ Naoto On 5/5/20 11:01 AM, naoto.sato at oracle.com wrote: > And here is the fix. Please review. > > http://cr.openjdk.java.net/~naoto/8244459/webrev.00/ > > Naoto > > On 5/5/20 10:25 AM, naoto.sato at oracle.com wrote: >> Hi Peter, >> >> You are correct. Thanks. I'll remove that initial value of 16. >> >> Naoto >> >> On 5/5/20 9:37 AM, Peter Levart wrote: >>> Hi Naoto, >>> >>> On 4/30/20 12:18 AM, naoto.sato at oracle.com wrote: >>>> Hello, >>>> >>>> Please review this small fix to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8244152 >>>> >>>> The proposed changeset is located at: >>>> >>>> https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ >>>> >>>> The hash map used there didn't have initial capacity, even though >>>> the exact numbers are known. >>> >>> >>> Well, it has to be calculated 1st (countTokens), but I guess this >>> pays off when HashSet (the backing HashMap) does not have to be >>> rehashed then. >>> >>> The expression you use: >>> >>> ???? Math.max((int)(tokens.countTokens() / 0.75f) + 1, 16) >>> >>> ...has a minimum value of 16. Why is that? 16 is just HashMap's >>> default initialCapacity if not specified explicitly. But if you only >>> want to store say 1 entry in the map, you can specify 2 as >>> initialCapacity and HashMap will happily work for such case without >>> resizing. >>> >>> >>> So you could just use: >>> >>> ???? (int)(tokens.countTokens() / 0.75f) + 1 >>> >>> And even this expression is sometimes overshooting the minimal >>> required value by 1 (when # of tokens is "exact" multiple of 0.75f, >>> say 6). I think the following could be used to optimally pre-size the >>> HashMap with default load factor 0.75: >>> >>> ???? (tokens.countTokens() * 4 + 2) / 3 >>> >>> >>> Regards, Peter >>> >>>> >>>> Naoto From huizhe.wang at oracle.com Tue May 5 21:40:22 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 5 May 2020 14:40:22 -0700 Subject: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters In-Reply-To: <5c22598c-cba4-bcb9-4c52-6994e95d4355@oracle.com> References: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> <46715fee-ae7f-d281-37c7-6189004fe621@oracle.com> <71a3c4e7-4dd1-ec96-0699-830f1667b9c7@oracle.com> <5c22598c-cba4-bcb9-4c52-6994e95d4355@oracle.com> Message-ID: On 5/5/2020 2:08 PM, naoto.sato at oracle.com wrote: > Thanks, all. I didn't see this coming! +1, just when one might think it was just a minor tweak... ;-) > > If I understand the discussion correctly, Peter's suggestion is the > most optimal (Mark, your formula produces 1 for the expected size is > 0, although it won't be happening in this particular case). And Joe, > thank you for finding my silly mistake :-) So here is the updated webrev: > > http://cr.openjdk.java.net/~naoto/8244459/webrev.01/ +1 -Joe > > Naoto > > > On 5/5/20 11:01 AM, naoto.sato at oracle.com wrote: >> And here is the fix. Please review. >> >> http://cr.openjdk.java.net/~naoto/8244459/webrev.00/ >> >> Naoto >> >> On 5/5/20 10:25 AM, naoto.sato at oracle.com wrote: >>> Hi Peter, >>> >>> You are correct. Thanks. I'll remove that initial value of 16. >>> >>> Naoto >>> >>> On 5/5/20 9:37 AM, Peter Levart wrote: >>>> Hi Naoto, >>>> >>>> On 4/30/20 12:18 AM, naoto.sato at oracle.com wrote: >>>>> Hello, >>>>> >>>>> Please review this small fix to the following issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8244152 >>>>> >>>>> The proposed changeset is located at: >>>>> >>>>> https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ >>>>> >>>>> The hash map used there didn't have initial capacity, even though >>>>> the exact numbers are known. >>>> >>>> >>>> Well, it has to be calculated 1st (countTokens), but I guess this >>>> pays off when HashSet (the backing HashMap) does not have to be >>>> rehashed then. >>>> >>>> The expression you use: >>>> >>>> ???? Math.max((int)(tokens.countTokens() / 0.75f) + 1, 16) >>>> >>>> ...has a minimum value of 16. Why is that? 16 is just HashMap's >>>> default initialCapacity if not specified explicitly. But if you >>>> only want to store say 1 entry in the map, you can specify 2 as >>>> initialCapacity and HashMap will happily work for such case without >>>> resizing. >>>> >>>> >>>> So you could just use: >>>> >>>> ???? (int)(tokens.countTokens() / 0.75f) + 1 >>>> >>>> And even this expression is sometimes overshooting the minimal >>>> required value by 1 (when # of tokens is "exact" multiple of 0.75f, >>>> say 6). I think the following could be used to optimally pre-size >>>> the HashMap with default load factor 0.75: >>>> >>>> ???? (tokens.countTokens() * 4 + 2) / 3 >>>> >>>> >>>> Regards, Peter >>>> >>>>> >>>>> Naoto From forax at univ-mlv.fr Tue May 5 20:19:32 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 5 May 2020 22:19:32 +0200 (CEST) Subject: CfD: compile-time checked immutable collections In-Reply-To: <0e238928-f7c8-f806-64ce-b3920a95068b@mail.de> References: <0e238928-f7c8-f806-64ce-b3920a95068b@mail.de> Message-ID: <887720937.1274806.1588709972890.JavaMail.zimbra@u-pem.fr> Hallo ! This questions have been asked so many times since 1998, Josh Bloch one of the designer of the API (who will later write Effective Java) as created a FAQ around that time answering to that question: https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html Google also tried to tackle the problem https://github.com/google/guava/wiki/ImmutableCollectionsExplained https://guava.dev/releases/21.0/api/docs/com/google/common/collect/ImmutableCollection.html the section "Interfaces, not implementations" explains why you should not takes an immutable list as parameters Some of those classes have been retrofitted in recent releases of the JDK (see List/Map/Set.of and List/Map/Set.copyOf) Some IDEs can emit a warning or an error if you try calls a method that can throw UnsupportedOperationException on a map/collection you receive as return value of a call, usually it's enough to detect 99% of the bugs. regards, R?mi ----- Mail original ----- > De: "M. Kroll" > ?: "core-libs-dev" > Envoy?: Mardi 5 Mai 2020 20:55:00 > Objet: CfD: compile-time checked immutable collections > Hey there! > > I am new here so first i want to introduce myself. My name is Michael > and i live in germany. For a job i am a java developer with 10 years of > java EE experience. At work my passion is to create long-living core > tools for our projects. > > But now for the reason i joined openjdk and this group in particular: > immutable collections. > > During development i sometimes stumble upon the fact that there is no > simple way build an immutable object that exposes a read-only > collection, and all this in a compile-time safe manner. To explain it > with code, i want to have something like this: > > class Example { > ??? private final Collection values; > ??? public Example(String... args) { this.values = Arrays.asList(args); } > ??? public Collection getValues() { return values; } > } > class Test { > ??? public void test() { > ??????? Collection v = new Example("a","b","c").getValues(); > ??????? v.clear(); // <-- compile time error > ??? } > } > > The current approach to this is using either > Collections.unmodifiableXYZ(...), which may lead to runtime exceptions. > Or we use Stream as return object, but there is no simple way to pass > that around and use it multiple times. I don't see Supplier as a > solution to this: determining the size of the collection would need to > traverse the whole stream, even if the underlying collection is an > arraylist... not good. > > My approach to this would be to split up the Collection-Interface into a > read-only and a mutating part. > > But before i present you my somewhat complete solution, i asked myself > if you already discussed something like that. So i dived into the bug > database and found 3 somewhat similar tickets: > > 1. https://bugs.openjdk.java.net/browse/JDK-6432147 > ? ? The author wanted to introduce annotations to mark objects as > immutable and on basis of this raise compile exceptions. This would need > a load of annotations throughout the code and additional rules to check > by the compiler. The ticket was closed as a duplicate to [2] > 2. https://bugs.openjdk.java.net/browse/JDK-4211070 > ??? The author wanted to introduce a new keyword 'const' to be used > just like the annotation in [1]. Same problem: massive spray of the new > keyword throughout the code and the need for a change in the compiler > and even in the language. > 3. https://bugs.openjdk.java.net/browse/JDK-5099784 > ??? This is as old as JDK1.4.2 (2004) and proposes the same way i want > to go: split the Collection-interface into a new parent-interface that > contains all non-modifying methods and the Collection-interface itself > that then only contains modifying methods. A user of the > Collection-interface would see the same API as before, a user of the new > parent-interface would only see read-only methods. > > The original author of [3] is inactive by now, the ticket itself was not > discussed and is still unresolved open. > > I would happily try to implement this approach, but first i want to know > if this is the way to go and what your thoughts are about this. > > Hope this is not too much text for a Call for Discussion, > Michael From claes.redestad at oracle.com Tue May 5 22:12:33 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 6 May 2020 00:12:33 +0200 Subject: RFR: 8244413: Avoid rebinds in MethodHandle.viewAsType Message-ID: <1f48fd48-0bb9-7a14-dfa1-cf09545e56ff@oracle.com> Hi, in the current implementation MethodHandle.viewAsType eagerly rebinds when creating a view of a method type as an alternative type: MethodHandle viewAsType(MethodType newType, boolean strict) { ... MethodHandle mh = rebind(); return this.copyWith(newType, mh.form); } This prevents exposing uncrackable DMHs, ie, ones where calling Lookup.revealDirect(mh) would not produce a correct MethodHandleInfo. If we restructure this so that crackability is a property on the DMH, we can avoid the rebinds: http://cr.openjdk.java.net/~redestad/8244413/open.00/ This improves overhead slightly when calling MH.asType with a "viewable" type (one where all parameters in the new type can be assigned without transforms to parameters in the old; and return in the old can be assigned without transforms in the new). At the very least this means a small startup gain for a selection of apps. (The patch looks footprint neutral since 15, since the added boolean can slot into a padding gap created by fields in the MethodHandle base class.) Testing: tier1-3 /Claes From mandy.chung at oracle.com Tue May 5 22:23:33 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 5 May 2020 15:23:33 -0700 Subject: RFR: 8244413: Avoid rebinds in MethodHandle.viewAsType In-Reply-To: <1f48fd48-0bb9-7a14-dfa1-cf09545e56ff@oracle.com> References: <1f48fd48-0bb9-7a14-dfa1-cf09545e56ff@oracle.com> Message-ID: <34b04075-f9b3-2802-ac5a-7589199d6f57@oracle.com> On 5/5/20 3:12 PM, Claes Redestad wrote: > Hi, > > in the current implementation MethodHandle.viewAsType eagerly rebinds > when creating a view of a method type as an alternative type: > > ??? MethodHandle viewAsType(MethodType newType, boolean strict) { > ??????? ... > ??????? MethodHandle mh = rebind(); > ??????? return this.copyWith(newType, mh.form); > ??? } > > This prevents exposing uncrackable DMHs, ie, ones where calling > Lookup.revealDirect(mh) would not produce a correct MethodHandleInfo. > > If we restructure this so that crackability is a property on the DMH, we > can avoid the rebinds: > > http://cr.openjdk.java.net/~redestad/8244413/open.00/ > This looks good. Nit: one assert with paratheses and the other without.? Better to make them consistent. 163 assert viewAsTypeChecks(newType, strict); ?164 assert(this.getClass() == DirectMethodHandle.class); // must override in subclasses thanks Mandy From claes.redestad at oracle.com Tue May 5 22:34:51 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 6 May 2020 00:34:51 +0200 Subject: RFR: 8244413: Avoid rebinds in MethodHandle.viewAsType In-Reply-To: <34b04075-f9b3-2802-ac5a-7589199d6f57@oracle.com> References: <1f48fd48-0bb9-7a14-dfa1-cf09545e56ff@oracle.com> <34b04075-f9b3-2802-ac5a-7589199d6f57@oracle.com> Message-ID: <97f1284a-4007-c14c-6a91-27efd145dea8@oracle.com> Hi Mandy, On 2020-05-06 00:23, Mandy Chung wrote: > > This looks good. thanks! > > Nit: one assert with paratheses and the other without.? Better to make > them consistent. > > 163 assert viewAsTypeChecks(newType, strict); ?164 > assert(this.getClass() == DirectMethodHandle.class); // must override in > subclasses Sure, I'll add some. /Claes From stuart.marks at oracle.com Tue May 5 23:29:21 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 5 May 2020 16:29:21 -0700 Subject: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters In-Reply-To: References: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> <46715fee-ae7f-d281-37c7-6189004fe621@oracle.com> <71a3c4e7-4dd1-ec96-0699-830f1667b9c7@oracle.com> <4e994519-c6bd-a6e9-2ef8-1e8be4ef6008@gmail.com> Message-ID: <2aa09b33-19ab-b1bd-83a9-29cd178b7b65@oracle.com> Hm, interesting, good catch Peter! Very subtle. The time-honored (int) (expected / 0.75f) + 1 appears in several places around the JDK. I think most people (including me) just copy it, because it's "good enough" for most cases. I'm a little concerned about (expectedSize * 4 + 2) / 3 because that wraps around to negative starting at about 2^29. Might I suggest the following instead? (int) Math.ceil(expectedSize / 0.75) This expresses the actual intent more clearly, I think, and its results match Peter's expression for the range less than 2^29. It also saturates at Integer.MAX_VALUE instead of going negative. It does use double precision, though, as there's no float version of ceil(). At this point I think this is a small disadvantage. ** As for Naoto's changeset, I don't think it should be held up while we bikeshed this. :-) I'm ok with whatever he decides. s'marks On 5/5/20 1:26 PM, Peter Levart wrote: > There's more... > > > Guava (and JDK in copy constructor) formula: > > ??? (int) ((float) expectedSize / 0.75f + 1.0f) > > > is not the same as Naoto's formula: > > ??? (int) (expectedSize / 0.75f) + 1 > > > Notice that Naoto does addition of 1 in integer arithmetic after conversion to > int, while Guava/JDK does in floating point before conversion to int. If I put > Naoto's formula into my test program, no undercalculations are detected. > > > So while Naoto's formula is sub-optimal for expectedSizes that are multiples of > 3, the Guava/JDK also has a bug. > > > Regards, Peter > > > On 5/5/20 10:01 PM, Peter Levart wrote: >> >> >> On 5/5/20 9:41 PM, Martin Buchholz wrote: >>> Hi Peter, >>> >>> Are you saying guava has a tiny bug? >> >> >> If it was just 1 too much when expected size is a multiple of 3 then that >> would not be a bug, just sub-optimal calculation. And the same calculation is >> performed also in JDK when a copy constructor is called for example. >> >> >> But I investigated further and what I found could be considered a bug. >> Sometimes, the following expression: >> >> >> (int) ((float) expectedSize / 0.75f + 1.0f) >> >> >> ...calculates a value that is not enough (due to floating point arithmetic and >> conversion to int) to store the expectedSize elements into the HashMap without >> re-hashing. >> >> >> What HashMap does with initialCapacity parameter is to round it up to nearest >> power of 2: >> >> ??? static int tableSizeFor(int cap) { >> ??????? int n = -1 >>> Integer.numberOfLeadingZeros(cap - 1); >> ??????? return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1; >> ??? } >> >> then it uses this as the initial backing table size. From that table size it >> calculates the threshold value: >> >> ??? static int threshold(int cap) { >> ??????? float ft = (float) cap * 0.75f; >> ??????? return (cap < MAXIMUM_CAPACITY && ft < (float) MAXIMUM_CAPACITY ? >> ??????????????? (int) ft : Integer.MAX_VALUE); >> ??? } >> >> ... and uses it as the max. number of elements that a HashMap can hold before >> it is re-hashed. So I did the following test (comparing the effectiveness of >> above formula with alternative (expectedSize*4+2)/3 formula): >> >> >> public class HMTest { >> ??? static final int MAXIMUM_CAPACITY = 1 << 30; >> >> ??? static int tableSizeFor(int cap) { >> ??????? int n = -1 >>> Integer.numberOfLeadingZeros(cap - 1); >> ??????? return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? MAXIMUM_CAPACITY : n + 1; >> ??? } >> >> ??? static int threshold(int cap) { >> ??????? float ft = (float) cap * 0.75f; >> ??????? return (cap < MAXIMUM_CAPACITY && ft < (float) MAXIMUM_CAPACITY ? >> ??????????????? (int) ft : Integer.MAX_VALUE); >> ??? } >> >> ??? public static void main(String[] args) { >> ??????? for (int expectedSize = 0; expectedSize < (Integer.MAX_VALUE - 2) / 4; >> expectedSize++) { >> ??????????? int cap1 = (int) ((float) expectedSize / 0.75f + 1.0f); >> ??????????? int cap2 = (expectedSize * 4 + 2) / 3; >> ??????????? int ts1 = tableSizeFor(cap1); >> ??????????? int ts2 = tableSizeFor(cap2); >> ??????????? int th1 = threshold(ts1); >> ??????????? int th2 = threshold(ts2); >> >> ??????????? if (th1 < expectedSize || th2 < expectedSize) { >> ??????????????? System.out.printf("%d: (%d, %d, %d)%s (%d, %d, %d)%s\n", >> ??????????????????????? expectedSize, >> ??????????????????????? cap1, ts1, th1, (th1 < expectedSize) ? "!" : " ", >> ??????????????????????? cap2, ts2, th2, (th2 < expectedSize) ? "!" : " " >> ??????????????? ); >> ??????????? } >> ??????? } >> ??? } >> } >> >> >> And what this prints is the following: >> >> >> 25165825: (33554432, 33554432, 25165824)! (33554434, 67108864, 50331648) >> 50331649: (67108864, 67108864, 50331648)! (67108866, 134217728, 100663296) >> 50331650: (67108864, 67108864, 50331648)! (67108867, 134217728, 100663296) >> 100663297: (134217728, 134217728, 100663296)! (134217730, 268435456, 201326592) >> 100663298: (134217728, 134217728, 100663296)! (134217731, 268435456, 201326592) >> 100663299: (134217728, 134217728, 100663296)! (134217732, 268435456, 201326592) >> 100663300: (134217728, 134217728, 100663296)! (134217734, 268435456, 201326592) >> 201326593: (268435456, 268435456, 201326592)! (268435458, 536870912, 402653184) >> 201326594: (268435456, 268435456, 201326592)! (268435459, 536870912, 402653184) >> 201326595: (268435456, 268435456, 201326592)! (268435460, 536870912, 402653184) >> 201326596: (268435456, 268435456, 201326592)! (268435462, 536870912, 402653184) >> 201326597: (268435456, 268435456, 201326592)! (268435463, 536870912, 402653184) >> 201326598: (268435456, 268435456, 201326592)! (268435464, 536870912, 402653184) >> 201326599: (268435456, 268435456, 201326592)! (268435466, 536870912, 402653184) >> 201326600: (268435456, 268435456, 201326592)! (268435467, 536870912, 402653184) >> 402653185: (536870912, 536870912, 402653184)! (536870914, 1073741824, 2147483647) >> 402653186: (536870912, 536870912, 402653184)! (536870915, 1073741824, 2147483647) >> 402653187: (536870912, 536870912, 402653184)! (536870916, 1073741824, 2147483647) >> 402653188: (536870912, 536870912, 402653184)! (536870918, 1073741824, 2147483647) >> 402653189: (536870912, 536870912, 402653184)! (536870919, 1073741824, 2147483647) >> 402653190: (536870912, 536870912, 402653184)! (536870920, 1073741824, 2147483647) >> 402653191: (536870912, 536870912, 402653184)! (536870922, 1073741824, 2147483647) >> 402653192: (536870912, 536870912, 402653184)! (536870923, 1073741824, 2147483647) >> 402653193: (536870912, 536870912, 402653184)! (536870924, 1073741824, 2147483647) >> 402653194: (536870912, 536870912, 402653184)! (536870926, 1073741824, 2147483647) >> 402653195: (536870912, 536870912, 402653184)! (536870927, 1073741824, 2147483647) >> 402653196: (536870912, 536870912, 402653184)! (536870928, 1073741824, 2147483647) >> 402653197: (536870912, 536870912, 402653184)! (536870930, 1073741824, 2147483647) >> 402653198: (536870912, 536870912, 402653184)! (536870931, 1073741824, 2147483647) >> 402653199: (536870912, 536870912, 402653184)! (536870932, 1073741824, 2147483647) >> 402653200: (536870912, 536870912, 402653184)! (536870934, 1073741824, 2147483647) >> >> >> So as you see, for expectedSize < (Integer.MAX_VALUE - 2) / 4 (where the >> alternative formula does not experience overflow and is enough for Naoto's >> case) all miscalculations are due to the JDK/Guava formula which in those >> cases calculates a value that is less than alternative formula's value and too >> small to adequately pre-size the HashMap table. >> >> >> Voila, we have some bugs to fix or I am doing something wrong here. >> >> >> Regards, Peter >> >> >>> >>> On Tue, May 5, 2020 at 12:12 PM Peter Levart >> > wrote: >>> >>> ??? Hi Martin, >>> >>> ??? On 5/5/20 8:26 PM, Martin Buchholz wrote: >>>> ??? See related: >>>> >>>> https://guava.dev/releases/23.0/api/docs/com/google/common/collect/Maps.html#newHashMapWithExpectedSize-int- >>>> >>> >>> >>> ??? This is basically the same calculation (or at least gives same >>> ??? result) as Naoto did (without the max part): >>> >>> ??? Naoto: (int)(expectedSize / 0.75f) + 1 >>> >>> ??? Guava: (int) ((float) expectedSize / 0.75F + 1.0F) >>> >>> ??? but in case expectedSize is a multiple of 3, it gives the result >>> ??? which is 1 more than needed. If what is needed is also a power of >>> ??? 2, then twice the needed space is allocated in the HashMap >>> ??? backing table. >>> >>> >>> ??? Regards, Peter >>> >>> >>>> >>>> ??? On Tue, May 5, 2020 at 11:03 AM >>> ??? > wrote: >>>> >>>> ??????? And here is the fix. Please review. >>>> >>>> ??????? http://cr.openjdk.java.net/~naoto/8244459/webrev.00/ >>>> >>>> ??????? Naoto >>>> >>>> ??????? On 5/5/20 10:25 AM, naoto.sato at oracle.com >>>> ??????? wrote: >>>> ??????? > Hi Peter, >>>> ??????? > >>>> ??????? > You are correct. Thanks. I'll remove that initial value of 16. >>>> ??????? > >>>> ??????? > Naoto >>>> ??????? > >>>> ??????? > On 5/5/20 9:37 AM, Peter Levart wrote: >>>> ??????? >> Hi Naoto, >>>> ??????? >> >>>> ??????? >> On 4/30/20 12:18 AM, naoto.sato at oracle.com >>>> ??????? wrote: >>>> ??????? >>> Hello, >>>> ??????? >>> >>>> ??????? >>> Please review this small fix to the following issue: >>>> ??????? >>> >>>> ??????? >>> https://bugs.openjdk.java.net/browse/JDK-8244152 >>>> ??????? >>> >>>> ??????? >>> The proposed changeset is located at: >>>> ??????? >>> >>>> ??????? >>> https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ >>>> ??????? >>> >>>> ??????? >>> The hash map used there didn't have initial capacity, >>>> ??????? even though the >>>> ??????? >>> exact numbers are known. >>>> ??????? >> >>>> ??????? >> >>>> ??????? >> Well, it has to be calculated 1st (countTokens), but I >>>> ??????? guess this pays >>>> ??????? >> off when HashSet (the backing HashMap) does not have to >>>> ??????? be rehashed then. >>>> ??????? >> >>>> ??????? >> The expression you use: >>>> ??????? >> >>>> ??????? >> ???? Math.max((int)(tokens.countTokens() / 0.75f) + 1, 16) >>>> ??????? >> >>>> ??????? >> ...has a minimum value of 16. Why is that? 16 is just >>>> ??????? HashMap's >>>> ??????? >> default initialCapacity if not specified explicitly. But >>>> ??????? if you only >>>> ??????? >> want to store say 1 entry in the map, you can specify 2 as >>>> ??????? >> initialCapacity and HashMap will happily work for such >>>> ??????? case without >>>> ??????? >> resizing. >>>> ??????? >> >>>> ??????? >> >>>> ??????? >> So you could just use: >>>> ??????? >> >>>> ??????? >> ???? (int)(tokens.countTokens() / 0.75f) + 1 >>>> ??????? >> >>>> ??????? >> And even this expression is sometimes overshooting the >>>> ??????? minimal >>>> ??????? >> required value by 1 (when # of tokens is "exact" multiple >>>> ??????? of 0.75f, >>>> ??????? >> say 6). I think the following could be used to optimally >>>> ??????? pre-size the >>>> ??????? >> HashMap with default load factor 0.75: >>>> ??????? >> >>>> ??????? >> ???? (tokens.countTokens() * 4 + 2) / 3 >>>> ??????? >> >>>> ??????? >> >>>> ??????? >> Regards, Peter >>>> ??????? >> >>>> ??????? >>> >>>> ??????? >>> Naoto >>>> From naoto.sato at oracle.com Wed May 6 00:04:40 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 5 May 2020 17:04:40 -0700 Subject: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters In-Reply-To: <2aa09b33-19ab-b1bd-83a9-29cd178b7b65@oracle.com> References: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> <46715fee-ae7f-d281-37c7-6189004fe621@oracle.com> <71a3c4e7-4dd1-ec96-0699-830f1667b9c7@oracle.com> <4e994519-c6bd-a6e9-2ef8-1e8be4ef6008@gmail.com> <2aa09b33-19ab-b1bd-83a9-29cd178b7b65@oracle.com> Message-ID: <1b2e71f3-52c4-169b-c7eb-36eb165311ad@oracle.com> Hi Stuart, On 5/5/20 4:29 PM, Stuart Marks wrote: > As for Naoto's changeset, I don't think it should be held up while we > bikeshed this. :-) I'm ok with whatever he decides. I don't think the number of language tags exceed 2^29, unless languages in the whole universe are counted :-) So I would go with the current version. Naoto > > s'marks > > > > > On 5/5/20 1:26 PM, Peter Levart wrote: >> There's more... >> >> >> Guava (and JDK in copy constructor) formula: >> >> ???? (int) ((float) expectedSize / 0.75f + 1.0f) >> >> >> is not the same as Naoto's formula: >> >> ???? (int) (expectedSize / 0.75f) + 1 >> >> >> Notice that Naoto does addition of 1 in integer arithmetic after >> conversion to int, while Guava/JDK does in floating point before >> conversion to int. If I put Naoto's formula into my test program, no >> undercalculations are detected. >> >> >> So while Naoto's formula is sub-optimal for expectedSizes that are >> multiples of 3, the Guava/JDK also has a bug. >> >> >> Regards, Peter >> >> >> On 5/5/20 10:01 PM, Peter Levart wrote: >>> >>> >>> On 5/5/20 9:41 PM, Martin Buchholz wrote: >>>> Hi Peter, >>>> >>>> Are you saying guava has a tiny bug? >>> >>> >>> If it was just 1 too much when expected size is a multiple of 3 then >>> that would not be a bug, just sub-optimal calculation. And the same >>> calculation is performed also in JDK when a copy constructor is >>> called for example. >>> >>> >>> But I investigated further and what I found could be considered a >>> bug. Sometimes, the following expression: >>> >>> >>> (int) ((float) expectedSize / 0.75f + 1.0f) >>> >>> >>> ...calculates a value that is not enough (due to floating point >>> arithmetic and conversion to int) to store the expectedSize elements >>> into the HashMap without re-hashing. >>> >>> >>> What HashMap does with initialCapacity parameter is to round it up to >>> nearest power of 2: >>> >>> ??? static int tableSizeFor(int cap) { >>> ??????? int n = -1 >>> Integer.numberOfLeadingZeros(cap - 1); >>> ??????? return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? >>> MAXIMUM_CAPACITY : n + 1; >>> ??? } >>> >>> then it uses this as the initial backing table size. From that table >>> size it calculates the threshold value: >>> >>> ??? static int threshold(int cap) { >>> ??????? float ft = (float) cap * 0.75f; >>> ??????? return (cap < MAXIMUM_CAPACITY && ft < (float) >>> MAXIMUM_CAPACITY ? >>> ??????????????? (int) ft : Integer.MAX_VALUE); >>> ??? } >>> >>> ... and uses it as the max. number of elements that a HashMap can >>> hold before it is re-hashed. So I did the following test (comparing >>> the effectiveness of above formula with alternative >>> (expectedSize*4+2)/3 formula): >>> >>> >>> public class HMTest { >>> ??? static final int MAXIMUM_CAPACITY = 1 << 30; >>> >>> ??? static int tableSizeFor(int cap) { >>> ??????? int n = -1 >>> Integer.numberOfLeadingZeros(cap - 1); >>> ??????? return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? >>> MAXIMUM_CAPACITY : n + 1; >>> ??? } >>> >>> ??? static int threshold(int cap) { >>> ??????? float ft = (float) cap * 0.75f; >>> ??????? return (cap < MAXIMUM_CAPACITY && ft < (float) >>> MAXIMUM_CAPACITY ? >>> ??????????????? (int) ft : Integer.MAX_VALUE); >>> ??? } >>> >>> ??? public static void main(String[] args) { >>> ??????? for (int expectedSize = 0; expectedSize < (Integer.MAX_VALUE >>> - 2) / 4; expectedSize++) { >>> ??????????? int cap1 = (int) ((float) expectedSize / 0.75f + 1.0f); >>> ??????????? int cap2 = (expectedSize * 4 + 2) / 3; >>> ??????????? int ts1 = tableSizeFor(cap1); >>> ??????????? int ts2 = tableSizeFor(cap2); >>> ??????????? int th1 = threshold(ts1); >>> ??????????? int th2 = threshold(ts2); >>> >>> ??????????? if (th1 < expectedSize || th2 < expectedSize) { >>> ??????????????? System.out.printf("%d: (%d, %d, %d)%s (%d, %d, %d)%s\n", >>> ??????????????????????? expectedSize, >>> ??????????????????????? cap1, ts1, th1, (th1 < expectedSize) ? "!" : >>> " ", >>> ??????????????????????? cap2, ts2, th2, (th2 < expectedSize) ? "!" : " " >>> ??????????????? ); >>> ??????????? } >>> ??????? } >>> ??? } >>> } >>> >>> >>> And what this prints is the following: >>> >>> >>> 25165825: (33554432, 33554432, 25165824)! (33554434, 67108864, 50331648) >>> 50331649: (67108864, 67108864, 50331648)! (67108866, 134217728, >>> 100663296) >>> 50331650: (67108864, 67108864, 50331648)! (67108867, 134217728, >>> 100663296) >>> 100663297: (134217728, 134217728, 100663296)! (134217730, 268435456, >>> 201326592) >>> 100663298: (134217728, 134217728, 100663296)! (134217731, 268435456, >>> 201326592) >>> 100663299: (134217728, 134217728, 100663296)! (134217732, 268435456, >>> 201326592) >>> 100663300: (134217728, 134217728, 100663296)! (134217734, 268435456, >>> 201326592) >>> 201326593: (268435456, 268435456, 201326592)! (268435458, 536870912, >>> 402653184) >>> 201326594: (268435456, 268435456, 201326592)! (268435459, 536870912, >>> 402653184) >>> 201326595: (268435456, 268435456, 201326592)! (268435460, 536870912, >>> 402653184) >>> 201326596: (268435456, 268435456, 201326592)! (268435462, 536870912, >>> 402653184) >>> 201326597: (268435456, 268435456, 201326592)! (268435463, 536870912, >>> 402653184) >>> 201326598: (268435456, 268435456, 201326592)! (268435464, 536870912, >>> 402653184) >>> 201326599: (268435456, 268435456, 201326592)! (268435466, 536870912, >>> 402653184) >>> 201326600: (268435456, 268435456, 201326592)! (268435467, 536870912, >>> 402653184) >>> 402653185: (536870912, 536870912, 402653184)! (536870914, 1073741824, >>> 2147483647) >>> 402653186: (536870912, 536870912, 402653184)! (536870915, 1073741824, >>> 2147483647) >>> 402653187: (536870912, 536870912, 402653184)! (536870916, 1073741824, >>> 2147483647) >>> 402653188: (536870912, 536870912, 402653184)! (536870918, 1073741824, >>> 2147483647) >>> 402653189: (536870912, 536870912, 402653184)! (536870919, 1073741824, >>> 2147483647) >>> 402653190: (536870912, 536870912, 402653184)! (536870920, 1073741824, >>> 2147483647) >>> 402653191: (536870912, 536870912, 402653184)! (536870922, 1073741824, >>> 2147483647) >>> 402653192: (536870912, 536870912, 402653184)! (536870923, 1073741824, >>> 2147483647) >>> 402653193: (536870912, 536870912, 402653184)! (536870924, 1073741824, >>> 2147483647) >>> 402653194: (536870912, 536870912, 402653184)! (536870926, 1073741824, >>> 2147483647) >>> 402653195: (536870912, 536870912, 402653184)! (536870927, 1073741824, >>> 2147483647) >>> 402653196: (536870912, 536870912, 402653184)! (536870928, 1073741824, >>> 2147483647) >>> 402653197: (536870912, 536870912, 402653184)! (536870930, 1073741824, >>> 2147483647) >>> 402653198: (536870912, 536870912, 402653184)! (536870931, 1073741824, >>> 2147483647) >>> 402653199: (536870912, 536870912, 402653184)! (536870932, 1073741824, >>> 2147483647) >>> 402653200: (536870912, 536870912, 402653184)! (536870934, 1073741824, >>> 2147483647) >>> >>> >>> So as you see, for expectedSize < (Integer.MAX_VALUE - 2) / 4 (where >>> the alternative formula does not experience overflow and is enough >>> for Naoto's case) all miscalculations are due to the JDK/Guava >>> formula which in those cases calculates a value that is less than >>> alternative formula's value and too small to adequately pre-size the >>> HashMap table. >>> >>> >>> Voila, we have some bugs to fix or I am doing something wrong here. >>> >>> >>> Regards, Peter >>> >>> >>>> >>>> On Tue, May 5, 2020 at 12:12 PM Peter Levart >>> > wrote: >>>> >>>> ??? Hi Martin, >>>> >>>> ??? On 5/5/20 8:26 PM, Martin Buchholz wrote: >>>>> ??? See related: >>>>> https://guava.dev/releases/23.0/api/docs/com/google/common/collect/Maps.html#newHashMapWithExpectedSize-int- >>>>> >>>> >>>> >>>> ??? This is basically the same calculation (or at least gives same >>>> ??? result) as Naoto did (without the max part): >>>> >>>> ??? Naoto: (int)(expectedSize / 0.75f) + 1 >>>> >>>> ??? Guava: (int) ((float) expectedSize / 0.75F + 1.0F) >>>> >>>> ??? but in case expectedSize is a multiple of 3, it gives the result >>>> ??? which is 1 more than needed. If what is needed is also a power of >>>> ??? 2, then twice the needed space is allocated in the HashMap >>>> ??? backing table. >>>> >>>> >>>> ??? Regards, Peter >>>> >>>> >>>>> >>>>> ??? On Tue, May 5, 2020 at 11:03 AM >>>> ??? > wrote: >>>>> >>>>> ??????? And here is the fix. Please review. >>>>> >>>>> ??????? http://cr.openjdk.java.net/~naoto/8244459/webrev.00/ >>>>> >>>>> ??????? Naoto >>>>> >>>>> ??????? On 5/5/20 10:25 AM, naoto.sato at oracle.com >>>>> ??????? wrote: >>>>> ??????? > Hi Peter, >>>>> ??????? > >>>>> ??????? > You are correct. Thanks. I'll remove that initial value >>>>> of 16. >>>>> ??????? > >>>>> ??????? > Naoto >>>>> ??????? > >>>>> ??????? > On 5/5/20 9:37 AM, Peter Levart wrote: >>>>> ??????? >> Hi Naoto, >>>>> ??????? >> >>>>> ??????? >> On 4/30/20 12:18 AM, naoto.sato at oracle.com >>>>> ??????? wrote: >>>>> ??????? >>> Hello, >>>>> ??????? >>> >>>>> ??????? >>> Please review this small fix to the following issue: >>>>> ??????? >>> >>>>> ??????? >>> https://bugs.openjdk.java.net/browse/JDK-8244152 >>>>> ??????? >>> >>>>> ??????? >>> The proposed changeset is located at: >>>>> ??????? >>> >>>>> ??????? >>> https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ >>>>> ??????? >>> >>>>> ??????? >>> The hash map used there didn't have initial capacity, >>>>> ??????? even though the >>>>> ??????? >>> exact numbers are known. >>>>> ??????? >> >>>>> ??????? >> >>>>> ??????? >> Well, it has to be calculated 1st (countTokens), but I >>>>> ??????? guess this pays >>>>> ??????? >> off when HashSet (the backing HashMap) does not have to >>>>> ??????? be rehashed then. >>>>> ??????? >> >>>>> ??????? >> The expression you use: >>>>> ??????? >> >>>>> ??????? >> ???? Math.max((int)(tokens.countTokens() / 0.75f) + 1, 16) >>>>> ??????? >> >>>>> ??????? >> ...has a minimum value of 16. Why is that? 16 is just >>>>> ??????? HashMap's >>>>> ??????? >> default initialCapacity if not specified explicitly. But >>>>> ??????? if you only >>>>> ??????? >> want to store say 1 entry in the map, you can specify 2 as >>>>> ??????? >> initialCapacity and HashMap will happily work for such >>>>> ??????? case without >>>>> ??????? >> resizing. >>>>> ??????? >> >>>>> ??????? >> >>>>> ??????? >> So you could just use: >>>>> ??????? >> >>>>> ??????? >> ???? (int)(tokens.countTokens() / 0.75f) + 1 >>>>> ??????? >> >>>>> ??????? >> And even this expression is sometimes overshooting the >>>>> ??????? minimal >>>>> ??????? >> required value by 1 (when # of tokens is "exact" multiple >>>>> ??????? of 0.75f, >>>>> ??????? >> say 6). I think the following could be used to optimally >>>>> ??????? pre-size the >>>>> ??????? >> HashMap with default load factor 0.75: >>>>> ??????? >> >>>>> ??????? >> ???? (tokens.countTokens() * 4 + 2) / 3 >>>>> ??????? >> >>>>> ??????? >> >>>>> ??????? >> Regards, Peter >>>>> ??????? >> >>>>> ??????? >>> >>>>> ??????? >>> Naoto >>>>> From john.r.rose at oracle.com Wed May 6 03:01:50 2020 From: john.r.rose at oracle.com (John Rose) Date: Tue, 5 May 2020 20:01:50 -0700 Subject: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests In-Reply-To: References: <49F81016-55DF-4E3C-940A-A8DF8C712259@oracle.com> <1886691513.405349.1587389515699.JavaMail.zimbra@u-pem.fr> Message-ID: On May 1, 2020, at 1:36 PM, Paul Sandoz wrote: > > Hi Remi, > > Thanks for the feedback. I am gonna need to go over this with John. Some comments inline. > > >> On Apr 20, 2020, at 6:31 AM, Remi Forax wrote: >> >> Hi Paul, >> about the API part (not the implementation), >> there are location where the same concept is described with a different names which doesn't help to understand how thing work >> - vector length <=> vector lane count >> - vector shape <=> vector bits size >> - element size <=> lane size >> >> "size" should never be used (VectorSpecies.elementSize() by example ) because it's never clear if it's the byte size or the bits size, using byteSize and bitsSize as used several times in the API should be used everywhere. > > I agree with being explicit here e.g. s/Vector.elementSize/Vector.elementBitSize and other usages. The name ?size? follows the precedent of the API point Integer.SIZE, which is the size of an `int` in bits. Although bit-size and byte-size is an important thing to keep track of, in the case of the Vector type, it lives primarily in registers, like `int`, and only secondarily in memory (as `int[]` lives primarily in memory). When you need the size of a datum in a register, you appeal to its bit count, not its byte count. When you store in memory, then you might want its byte size but for vectors that is an edge case. So I don?t think we need bitSize, as a more explicit term for size, for vectors and their lanes. It is enough to say ?size?. > > I would prefer to consistently use length in methods to refer to the lane count, it matches more closely to an array and for thinking about bounds checking. Yes, in this way (contrary to what I just said), a Vector is like an array, and so it just has a length. It?s a small array, and it lives in a register, and it doesn?t support good random access, but it has a length like an array. > > How about on Vector: > > /** > * Returns number of vector lanes ({@code VLENGTH}), commonly referred to as the lane count. > * > * @return the number of vector lanes > */ > public abstract int length(); Yes. Although laneCount would be a runner-up for naming this API point. But a Vector is enough like an array or String that giving it a length is the least confusing choice. With documentation that says somewhere that a vector looks like a little array formed from its lanes, so its length as a vector is the count of its lanes. Also, the semi-formal symbol {@code VLENGTH} is employed throughout the javadoc, and would have to change to something even uglier like {@code VLANECOUNT} if we got rid of Vector::length. > And then change VectorShape.laneCount to VectorShape.laneLength. > > ? That sounds wrong, as if it were reporting the length of a lane somewhere. Lane-count is correct. As the javadoc explains clearly, a vector has a certain number of lanes. > > >> >> Initially, having VectorSpecies and VectorShape confuse me, it's not the shape of the vector but only it's bits size, >> renaming VectorShape to VectorBitsSize will help, i think. >> > > Shape is quite a fundamental concept specified and used in the API, representing the information capacity of a vector. > > I think it would be misleading to refer to it only as VectorBitSize and unwieldy to change the specification accordingly. In this sense it serves as a useful abstraction to talk about vectors of the same bit size, and operations that change that size or not (such as shape-changing or shape-invariant). More comments: Shape also plays a critical role in the miscibility of vectors. Two vectors can line up to perform a lane-wise operation if and only if they have the same shape. This is fundamental. If we were to make these rules more ?clever?, allowing cross-shape lanewise operations, we?d give up on our current performance levels, because the necessary dynamic checks would put sand in the gears of the optimizer. There are present and future hardware platforms, and software abstractions, for which shape is more than just ?the number of my bits?. The max-bits shape is a dynamically determined shape which is not the same as any statically determined shape. In the future, shapes may be distinguished according to whether the involved vectors have intrinsic masks or not. In the near future, we might like to take the option of making synthetic shapes, such as ?a pair of 2-lane doubles of VLENGTH=4?, which are often seen in other vector developer toolkits. > >> You have the same values defined at several places in the API (sometimes with different names), usually it's aliases but it makes the API bigger that it should. >> I think all the reference to the element type, vector byte size, vector bit size, element byte size, element byte size, vector lane count should not appear on Vector because they are accessible from Species, >> and to go from a vector to the corresponding species, species() is enough. >> > > But it also makes it less usable, esp. for length(). The following is not an obviously or universally correct principle: ?There should only be one way to do a given task.? It is surely not universally true for the Vector API. When we point out that ?API point X is a duplicate of API point Y?, we may or may not be willing to follow that up with ?so get rid of API point X since the programmer can reach for Y?. If it?s our favorite utility method X, we will defend it vigorously. If it?s one we can?t imagine using, we will suggest that it be voted off the island. Only the most pure of purists will try to prove that some API has the minimum number of points, and rest happily only when that is the case. When Remi objects to Vector::length he is perhaps being such a purist, but very few programmers like to live on such spartan foundations, in practice. So utility methods like Vector::length, Vector::broadcast, Vector::maskAll, Vector::toDoubleArray, etc. help make common coding tasks easier. The most important thing to make easy is not reducing keystrokes (code golf) but rather making code as clear as possible. SKI combinators are a minimal API for Turing computations, but even if I loved to code with them, my code would not be reviewable for correctness, and even I couldn?t debug it as well, without some ?convenience combinators? available. Likewise, for vectors, it will be so common to loop over the lanes of a vector, that adding just the tokens ?.species()? to every loop head will make those loops harder to read and prove correct. In short: Code as you like, but if you expect to review or debug it, your code had better not have much extra ?noise? in it. This motivates convenience methods. Most of those in the Vector API have been placed there because they made somebody?s job easier writing clear Vector API code. A second reason for the convenience methods, in the Vector API, is discoverability. We put add, sub, mul, div, min, max, eq, le on Vector not because that?s the only possible place for their unique instantiation, but because they are friendly signs, on the front door of the API (Vector) that it is open for business. When you noodle around with a Vector in an API, you instantly see a familiar looking set of operations. You are not overwhelmed by hyperbolic arc-cosine, and on the other hand you are not left with an room empty of everything but abstract sculptures (the architectural version of having only higher-order functions). When you explore Vector::add, you find that it does about what you think it should, and how it should. You also discover the special shed (VectorOperations) where all the other tools are kept, and observe its connection to those previously-scary abstract sculptures (the lanewise and reduction higher order methods). If the purist succeeded in putting everything in one place, the initial experience of working with Vector would be very uninformative, more like playing a role-playing exploration game than getting work done on a ?batteries included? platform. I think the above reasons are also why IntStream::sum is such a good idea. Anyway, simple stuff should be easy to read, and complicated stuff should be discoverable from simple stuff. That why we repeat ourselves, because we think it will help users. > > >> You have also the same methods defined at several places, on VectorSpecies and as a static method taking a species as parameter, >> all the methods of VectorSpecies that takes or return a vector/mask/shuffle should be static in vector/mask/shuffle. >> > > It?s a little more nuanced, but I agree there is some duplication e.g. VectorSpecies.fromByteArray compared to the richer set of methods defined on [E]Vector. I think we can remove that method from VectorSpecies. Then I think we are dealing with the more ?erased/reflective? and long carrier accepting methods for general operation without appealing to E. Yes, I?m OK with removing that; it?s more like a leftover from previous rounds. OTOH, the static factories for methods annoy me for various reasons. I hope we can eventually find a better notation. Putting methods on VectorSpecies or on Vector itself sometimes is a viable alternative, sometimes not. Vector::broadcast is a static factory in disguise, which justifies its redundant existence in terms of usability and discoverability. But to do a better job on more API points, we might have to wait for specialized generics to make better moves. I?m content to wait? > > >> I think Binary and Associative should be merged to one VectorOperation, given that the difference is subtle and the whole point of this API is that if the hardware do not provide a way to reduce a binary op, it can be done in Java. > > Not quite true, ARM/x86 implementations do provide intrinsic implementations (leveraging a sequence of instructions) for some reduction operations e.g. min/max. I cannot recall there current state of the ARM/x86 implementations for other reductive operations but the plan is to optimize all of them at some point. Further, hardware may evolve in the future. It?s also useful, in an IDE, to have a static type check on the VectorOperation token passed to a reduction operation. You don?t want to accidentally reduce by SUB or DIV, and Associative allows the type-checker to stop it. > >> >> I have no idea what a Conversion.rangeType() is ? >> > > It?s the element type of the resulting output vector, > > Doc on VectorOperators.Operator: > > /** > * Reports the special return type of this operator. > * If this operator is a boolean, returns {@code boolean.class}. > * If this operator is a {@code Conversion}, > * returns its {@linkplain Conversion#rangeType range type}. > * > * Otherwise, the operator's return value always has > * whatever type was given as an input, and this method > * returns {@code Object.class} to denote that fact. > * @return the special return type, or {@code Object.class} if none > */ > Class rangeType(); Vector operators are static operation symbols, some of which have little accessor methods to describe themselves. The range type of a conversion is like `int` in C++ `operator int()`. It?s spelled as a type, not with characters. > > >> More specially: >> - VectorSpecies.loopbound() is not used in the example ? > > In the package-info? Yes, we should update that. +1 We should also make sure it optimizes. > > >> - VectorSpecies.arrayType()/genericElementType() are more for implementers than users , no ? at least arrayType should be arrayElementType. > > I don?t think we need to expose genericElementType in the API. +1 I wish we had Class.wrapperType, Class.primitiveType also. > I suspect arrayType may have been added before it was added to Class in 12 for the constable support. I think we can remove it. Yep. Class.arrayType is a nice $0.25 payoff of long technical debt. (I wonder how much that would compound with interest over 25 years?) > >> - VectorSpecies.withLanes() => withElementType() >> >> - VectorMask.check* are implementer methods ? > > The intent is to provide abstractions so the developer can perform ?reflective" checks on vector, mask, or shuffle. Yes. Also the Vector API intentionally allows some flexibility in coding with strong typing (IntVector, etc.) and weak typing (Vector, etc.). We think we can narrow that gap with specialized generics, but for now it?s important to allow both sides to be inhabited. When bridging the gap, you need casts, and there are lots of operations in the API which help with this?make it easier to read when a transition is being made. In particular, the check methods allow an intermediate value which may have lost static type information to be re-equipped with that static type information. Maybe they will be less important in the future, but I think even in the future it will be useful to be able to assert that two vectors are of the same shape. (Remember that vector shape is always a constraint on correct mixing of vectors, so it?s something the programmer needs help with sometimes.) > > >> - VectorMask.equal(VectorMask) => equiv >> > > Because it?s too close to the name ?equals?? Should have been eq, I guess. Perhaps it?s a leftover from before we had eq/ne/le/lt/gt/ge. > > >> - VectorShuffle.check* are implementer methods ? >> - VectorShuffle.vectorSpecies() => VectorShuffle.species() (as in Vector and VectorMask) > > Ok. It?s hair-splitting, but a VectorShuffle, because it isn?t a vector, doesn?t have a species. It operates on vectors of a common species. So, while we have Vector::species, we have (at a larger conceptual distance) VectorShuffle::vectorSpecies and VectorMask::vectorSpecies. The shuffles and masks know which species of vector they apply to, but that?s ?their species? indirectly. Who was Babe Ruth?s team? His kids didn?t have the same team, but they had their father?s team, only indirectly. > > >> - VectorShuffle.toVector() should return a IntVector > > No, it returns a vector according to its species. Note the constraint that shuffle source indexes are always in the range of -VLENGTH to VLENGTH - 1. This is a sore point in the API. A VectorShuffle isn?t a vector in part because its lanes contain source indexes (lane pointers) instead of vector data. What?s the implementation type? We don?t know exactly, could be byte, could be int, could be some clever union type superimposed on the vectors being operated on. It gets worse when the vector being operated on is too long and too narrow (at the same time) for its lanes to be able to encode all the necessary values. A vector of 512 lanes each of 8 bits is out of luck in this sense. In fact, it needs 10 bits (not 9) per source index in order to represent the ?negative conjugate? (invalid) source index values, which are required for various common operations. What to do? I?m not sure, but the answer probably has to do with treating VectorShuffle::toVector as a contracting and/or expanding operation, complete with part numbers. Or it could be treated as producing an unstated companion type, which must be queried reflectively. For now we?ve papered over the problems, but the paper won?t hold forever. > > >> - VectorShuffle.laneIsValid(), it seems to be an operation on Vector, not VectorShuffle. >> > > No, its specific to shuffle for masking out exceptional indexes (those < 0). (?negative conjugates?. A term I just made up today. Not tired of it yet.) See the javadoc for what they do and how they work. In short, we always add exactly one bit to the necessary set of bits for representing a lane index. The scheme works for VLENGTH which is not a power of two. And it gives various commonly seen idioms for masking, merging, and error checking. > > >> - IntVector.max, why there is no binary version that takes a mask ? It's documented but not why it's not available. >> > > It's to reduce the number of methods. On Vector: > > * This is not a full-service named operation like > * {@link #add(Vector) add()}. A masked version of > * this operation is not directly available > * but may be obtained via the masked version of > * {@code lanewise}. Subclasses define an additional > * scalar-broadcast overloading of this method. > We should probably document ?full service?. (Briefly!) Joe Darcy also mentioned this. > >> >> and i'm also not a big fans of the method that returns a long instead of a vector and only works on 64 bits values. >> > > Can you provide more details? The API points which work with double and long, in the weakly typed API, use those types as ?top for primitive?. Any primitive will fit without loss in either a long or double (sometimes both), just as any Vector will fit in a Vector, without loss. If you just need to broadcast zero, or get back a count, then putting it into a long is a really cheap form of boxing, and easy to read and prove correct. (And the redundant API point that helps you tells you where to find the ?real stuff? that?s going on, so you can learn about it if you need to.) I think these API points might need a little more documentation, to make it clear that they are doing *nothing* more than the corresponding strongly-typed API points, plus (to make up the primitive type differences) a cheap type conversion and/or error check. (Type conversion on output, error check on input, seems to be the most useful choice here. It?s an oddly reversed occurrence of Postel?s Law.) In particular, if I ask an IntVector to sum up its lanes, I don?t expect that the long version of the result will carry any more bits of information than the strongly typed int version (which truncates overflow). HTH ? John From justin.dekeyser at gmail.com Wed May 6 05:29:22 2020 From: justin.dekeyser at gmail.com (Justin Dekeyser) Date: Wed, 6 May 2020 07:29:22 +0200 Subject: Was functional-Try already discussed? Message-ID: Hi everyone, I am new to the OpenJDK community and I'm using Java fora small decade now, first as a hobby, then in my academic studies and my PhD in maths, and now as a professional developer in IT companies. I'm quite active on forum to help people, I've helped teaching students in the university, I read a lot of posts on blogs, and so many times I'm facing people having trouble with checked exceptions. The situation in my current job makes clarifies what I mean. People usually like declaring their own exception super class as "BusinessException", then deriving it in many subclasses to describe more accurate failure reasons. The problem they face is that when they declare their class as *checked Exception*, they cannot use the mechanism of Optional and Stream, for an obvious reason. Usually they prefer Optional and Stream, so they end up by subclassing RuntimeException. I find it so sad because, when interfacing services, you often forget about declaring those unchecked exceptions, and the client is not aware of what's happening! I think you loose all the benefit of the exception mechanism in Java here for a very bad reason. In my job I finally rectified (partially, because the code base is huge) the situation by implementing a "functional" Try in the same spirit than the Optional. People are quite happy with it. I can invest more time in its development but I think this small library could help more people about turning their exception in something clean again. So maybe it could be useful for the whole community. (I already discussed it with my boss, there will be no copyright problem.) There exists similar projects around the world (in the Vavr lib for example) and Scala offers this as a basic feature, which basically means that people could appreciate the enhancement! I am wondering if the Try interface would be interesting for OpenJDK, if they have been discussions about it, and what were the decisions about such a library? In my opinion, it may be a good complement to the Optional and the Stream interfaces to allow a functional style while keeping this cool feature of checked exceptions. Best regards, Justin Dekeyser From thejasvi.v.voniadka at oracle.com Wed May 6 06:09:21 2020 From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka) Date: Tue, 5 May 2020 23:09:21 -0700 (PDT) Subject: [PATCH] 8244199: [TestBug]: Update sun/management/jmxremote/bootstrap tests In-Reply-To: <1d7ad0b3-2b3a-4950-b559-929451e13283@default> References: <1d7ad0b3-2b3a-4950-b559-929451e13283@default> Message-ID: <4f805057-4bdb-42d7-b1e7-bf658a052615@default> Hello, A quick follow-up on this request.. -----Original Message----- From: Thejasvi Voniadka Sent: Monday, May 4, 2020 12:56 PM To: core-libs-dev at openjdk.java.net Subject: [PATCH] 8244199: [TestBug]: Update sun/management/jmxremote/bootstrap tests Hi, May I please find a sponsor for this patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8244199 Description: The test "test/jdk/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh" fails intermittently on a lower release. While investigating the cause for the failure, I felt the diagnostic messaging built into the test was not adequate. Some of the issues observed: 1. If the test throws a RuntimeException, the full stack trace is not displayed. 2. The test has several logging statements. However, the logging environment is not properly initialized to allow levels such as FINE when needed. 3. The logging sequence could be improved: some messages end up at stdout, and others at stderr, which makes it harder to follow the output. The patch is to improve the test in these lines. Webrev: http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.full.00 I have also used this opportunity to clean-up the test code as a whole, in lines of removal of redundant logic, formatting, coding guidelines, etc.... If the above patch looks too confusing and is hard to follow, here is a simpler version that shows only the core logic changes (I intend to submit only the full patch to be committed though): http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.simple.00 The patch has been tested on mach5, and all jmxremote tests passed. From magnus.ihse.bursie at oracle.com Wed May 6 07:00:43 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 6 May 2020 09:00:43 +0200 Subject: RFR: JDK-8241602 jlink does not produce reproducible jimage files In-Reply-To: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> References: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> Message-ID: <91dc6628-1adf-eb76-c893-ccd1b1fd7800@oracle.com> On 2020-05-05 21:56, Jim Laskey wrote: > This fix addresses the inconsistent ordering by jimage content by jlink from run to run. Bottom line, the implementer was using HashSet without defining hashcode/equals for the Set entry classes. > > webrev: http://cr.openjdk.java.net/~jlaskey/8241602/webrev-00 Looks good to me. /Magnus > jbs: https://bugs.openjdk.java.net/browse/JDK-8241602 > > Cheers, > > -- Jim > From Alan.Bateman at oracle.com Wed May 6 07:14:22 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 May 2020 08:14:22 +0100 Subject: RFR: JDK-8241602 jlink does not produce reproducible jimage files In-Reply-To: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> References: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> Message-ID: On 05/05/2020 20:56, Jim Laskey wrote: > This fix addresses the inconsistent ordering by jimage content by jlink from run to run. Bottom line, the implementer was using HashSet without defining hashcode/equals for the Set entry classes. > > webrev: http://cr.openjdk.java.net/~jlaskey/8241602/webrev-00 > jbs: https://bugs.openjdk.java.net/browse/JDK-8241602 > DirArchive and JmodArchive look okay. They could use Objects.hash/equals but what you have is okay too. Can you re-check JarArchive as it is created with a runtime version so equals should be checking 3 fields. The existing test for reproducible builds is JLinkReproducibleTest. Adding a new test is okay too but we should at least try to keep the names consistent. A couple of suggestions for the test in the webrev: - the @modules tag needs to include java.desktop as it is needed by the test. Better still would be to change to java.se so that there are more modules in the images. - Did you mean to open jdk.tools.jlink.internal? Maybe its a leftover from a previous iteration of the test? - You can use Files.mismatch to compare the lib/modules files are identical (like JLinkReproducibleTest).? It's okay to use the jimage ImageReaderFactory to check the names tables too but I think it's more important to check that the lib/modules files are identical before probing further. -Alan From daniel.fuchs at oracle.com Wed May 6 10:35:03 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 6 May 2020 11:35:03 +0100 Subject: RFR [LDAP]: 8062947: Fix exception message to correctly represent LDAP connection failure In-Reply-To: <8cfc457f-ed92-535e-5798-1a6f586b02c0@oracle.com> References: <8cfc457f-ed92-535e-5798-1a6f586b02c0@oracle.com> Message-ID: <42053431-7ee1-3d3d-a270-942701d30582@oracle.com> Hi Aleksei, Looks good to me. best regards, -- daniel On 05/05/2020 18:23, Aleks Efimov wrote: > "LDAP response read timed out, timeout used:-1ms.": > https://bugs.openjdk.java.net/browse/JDK-8062947 > > The following fix tries to tackle this issue: > http://cr.openjdk.java.net/~aefimov/8062947/00 From james.laskey at oracle.com Wed May 6 13:42:46 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 6 May 2020 10:42:46 -0300 Subject: RFR: JDK-8241602 jlink does not produce reproducible jimage files In-Reply-To: References: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> Message-ID: <0CD37DE0-D3BA-4260-96B4-A960CBF81962@oracle.com> Thank you. Notes below. updated webrev: http://cr.openjdk.java.net/~jlaskey/8241602/webrev-00 > On May 6, 2020, at 4:14 AM, Alan Bateman wrote: > > On 05/05/2020 20:56, Jim Laskey wrote: >> This fix addresses the inconsistent ordering by jimage content by jlink from run to run. Bottom line, the implementer was using HashSet without defining hashcode/equals for the Set entry classes. >> >> webrev: http://cr.openjdk.java.net/~jlaskey/8241602/webrev-00 >> jbs: https://bugs.openjdk.java.net/browse/JDK-8241602 >> > DirArchive and JmodArchive look okay. They could use Objects.hash/equals but what you have is okay too. Can you re-check JarArchive as it is created with a runtime version so equals should be checking 3 fields. Opted to use Objects. Added version for JarArchive (not convinced needed but should be benign.) > > The existing test for reproducible builds is JLinkReproducibleTest. Adding a new test is okay too but we should at least try to keep the names consistent. A couple of suggestions for the test in the webrev: > - the @modules tag needs to include java.desktop as it is needed by the test. Better still would be to change to java.se so that there are more modules in the images. Switched to java.se, only a second slower than java.desktop . Overall better test than JLinkReproducibleTest for increased likelihood of variance. > - Did you mean to open jdk.tools.jlink.internal? Maybe its a leftover from a previous iteration of the test? Nope, Yep. > - You can use Files.mismatch to compare the lib/modules files are identical (like JLinkReproducibleTest). It's okay to use the jimage ImageReaderFactory to check the names tables too but I think it's more important to check that the lib/modules files are identical before probing further. I had it in my mind there was a timestamp in the file, but then I remembered there wasn't. Switched to Files.mismatch. Everything else is redundant. Aside: The order in the file is still somewhat scattered, based on archive and archive content. We have the a pattern based sorting plugin which we don't use and we never did any locality vs performance testing. > > -Alan From Alan.Bateman at oracle.com Wed May 6 14:05:14 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 May 2020 15:05:14 +0100 Subject: RFR: JDK-8241602 jlink does not produce reproducible jimage filesJ In-Reply-To: <0CD37DE0-D3BA-4260-96B4-A960CBF81962@oracle.com> References: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> <0CD37DE0-D3BA-4260-96B4-A960CBF81962@oracle.com> Message-ID: <8b1b7f66-ae6b-54b7-2185-74ec20ab2b07@oracle.com> On 06/05/2020 14:42, Jim Laskey wrote: > : > > Aside: The order in the file is still somewhat scattered, based on > archive and archive content. ?We have the a pattern based sorting > plugin which we don't use and we never did any locality vs performance > testing. > Not in the test but the JDK does use the order-resources plugin with the following pattern: JLINK_ORDER_RESOURCES += \ ??? /java.base/java/** \ ??? /java.base/jdk/** \ ??? /java.base/sun/** \ ??? /java.base/com/** \ ??? /jdk.localedata/** \ ??? # Anyway, I looked at webrev-01 and the jlink changes look good. The updated test doesn't use the jimage API so no need to open jdk.internal.jimage. The imports can be removed too, also RUNTIME is no longer used in this version. Have you decided on a test name? The rallying call is "reproducible builds" and I'd prefer to have "Reproducible" in the test name so its consistent with the existing test that checks for reproducible with user modules. -Alan. From james.laskey at oracle.com Wed May 6 14:45:32 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 6 May 2020 11:45:32 -0300 Subject: RFR: JDK-8241602 jlink does not produce reproducible jimage filesJ In-Reply-To: <8b1b7f66-ae6b-54b7-2185-74ec20ab2b07@oracle.com> References: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> <0CD37DE0-D3BA-4260-96B4-A960CBF81962@oracle.com> <8b1b7f66-ae6b-54b7-2185-74ec20ab2b07@oracle.com> Message-ID: <7449D5CF-5757-4E12-884A-D651A14AE523@oracle.com> http://cr.openjdk.java.net/~jlaskey/8241602/webrev-02 > On May 6, 2020, at 11:05 AM, Alan Bateman wrote: > > On 06/05/2020 14:42, Jim Laskey wrote: >> : >> >> Aside: The order in the file is still somewhat scattered, based on archive and archive content. We have the a pattern based sorting plugin which we don't use and we never did any locality vs performance testing. >> > Not in the test but the JDK does use the order-resources plugin with the following pattern: > > JLINK_ORDER_RESOURCES += \ > /java.base/java/** \ > /java.base/jdk/** \ > /java.base/sun/** \ > /java.base/com/** \ > /jdk.localedata/** \ > # > > Anyway, I looked at webrev-01 and the jlink changes look good. The updated test doesn't use the jimage API so no need to open jdk.internal.jimage. The imports can be removed too, also RUNTIME is no longer used in this version. Have you decided on a test name? The rallying call is "reproducible builds" and I'd prefer to have "Reproducible" in the test name so its consistent with the existing test that checks for reproducible with user modules. > > -Alan. > > From aleksej.efimov at oracle.com Wed May 6 14:57:02 2020 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Wed, 6 May 2020 15:57:02 +0100 Subject: RFR [LDAP]: 8062947: Fix exception message to correctly represent LDAP connection failure In-Reply-To: <42053431-7ee1-3d3d-a270-942701d30582@oracle.com> References: <8cfc457f-ed92-535e-5798-1a6f586b02c0@oracle.com> <42053431-7ee1-3d3d-a270-942701d30582@oracle.com> Message-ID: Hi Daniel, Thanks for the review ! Best, Aleksei On 06/05/2020 11:35, Daniel Fuchs wrote: > Hi Aleksei, > > Looks good to me. > > best regards, > > -- daniel > > On 05/05/2020 18:23, Aleks Efimov wrote: >> "LDAP response read timed out, timeout used:-1ms.": >> https://bugs.openjdk.java.net/browse/JDK-8062947 >> >> The following fix tries to tackle this issue: >> http://cr.openjdk.java.net/~aefimov/8062947/00 > From claes.redestad at oracle.com Wed May 6 14:59:39 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 6 May 2020 16:59:39 +0200 Subject: RFR: 8244413: Avoid rebinds in MethodHandle.viewAsType In-Reply-To: <97f1284a-4007-c14c-6a91-27efd145dea8@oracle.com> References: <1f48fd48-0bb9-7a14-dfa1-cf09545e56ff@oracle.com> <34b04075-f9b3-2802-ac5a-7589199d6f57@oracle.com> <97f1284a-4007-c14c-6a91-27efd145dea8@oracle.com> Message-ID: <80cdf4c9-3bec-0e7a-c779-909b75100050@oracle.com> On 2020-05-06 00:34, Claes Redestad wrote: > Hi Mandy, > > On 2020-05-06 00:23, Mandy Chung wrote: >> >> This looks good. > > thanks! Pushed. FTR, I took inventory of existing micros, and found a few where the effect of this change on capturing lambdas can be studied. For example: $ make build-microbenchmark $ java -jar build/linux-x64/images/test/micro/benchmarks.jar Capture.*lambda_01$ -f 1 -w 1 -r 1 As expected, no statistically significant effect after JIT: Benchmark Mode Cnt Score Error Units 15-b19 Capture0.lambda_01 avgt 5 5.444 ? 0.872 ns/op 15-b20 Capture0.lambda_01 avgt 5 5.516 ? 1.199 ns/op jdk Capture0.lambda_01 avgt 5 5.465 ? 1.101 ns/op -Xint: Benchmark Mode Cnt Score Error Units 15-b19 Capture0.lambda_01 avgt 5 616.555 ? 2.732 ns/op 15-b20 Capture0.lambda_01 avgt 5 859.594 ? 7.954 ns/op jdk Capture0.lambda_01 avgt 5 745.150 ? 1.821 ns/op -XX:TieredStopAtLevel=1: Benchmark Mode Cnt Score Error Units 15-b19 Capture0.lambda_01 avgt 5 6.312 ? 0.919 ns/op 15-b20 Capture0.lambda_01 avgt 5 105.761 ? 7.575 ns/op jdk Capture0.lambda_01 avgt 5 105.228 ? 7.175 ns/op So outside of the direct bootstrap improvement, there's a positive effect during early warmup. Sadly this patch doesn't translate into an improvement in C1. I can see a rather large regression in C1 on this specific micro in 15-b20 (which is where the Hidden Classes integration happened). /Claes From Alan.Bateman at oracle.com Wed May 6 15:12:59 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 6 May 2020 16:12:59 +0100 Subject: RFR: JDK-8241602 jlink does not produce reproducible jimage filesJ In-Reply-To: <7449D5CF-5757-4E12-884A-D651A14AE523@oracle.com> References: <0449756E-0941-4FC1-9FA6-E36B4244A34D@oracle.com> <0CD37DE0-D3BA-4260-96B4-A960CBF81962@oracle.com> <8b1b7f66-ae6b-54b7-2185-74ec20ab2b07@oracle.com> <7449D5CF-5757-4E12-884A-D651A14AE523@oracle.com> Message-ID: <122dc847-5d5b-512b-d589-31157d1ecdf9@oracle.com> On 06/05/2020 15:45, Jim Laskey wrote: > http://cr.openjdk.java.net/~jlaskey/8241602/webrev-02 This version looks okay to me. -Alan. From michaelkroll at mail.de Wed May 6 15:14:21 2020 From: michaelkroll at mail.de (Michael Kroll) Date: Wed, 06 May 2020 17:14:21 +0200 Subject: CfD: compile-time checked immutable collections In-Reply-To: <887720937.1274806.1588709972890.JavaMail.zimbra@u-pem.fr> References: <887720937.1274806.1588709972890.JavaMail.zimbra@u-pem.fr> Message-ID: <20200506151421.C8C18A054D@smtp02.mail.de> Thank you for your reply. I am not truly satisfied with this explanation (especially Josh Blochs "i am unwilling to create a few more interfaces" - sounds a bit silly if you look at all those unmodifiable-workarounds that are in place by now, even those incorporated into IDEs to warn the developer), but i'll get to that later. Nevertheless, could you please close the tickets i mentioned, commenting with the same text you sent me? I think that in the future people would benefit from finding an explanation before diving deeper into this topic on their own... or asking basic questions here. regards, Michael Am 05-May-2020 23:56:43 +0200 schrieb forax at univ-mlv.fr: Hallo ! This questions have been asked so many times since 1998, Josh Bloch one of the designer of the API (who will later write Effective Java) as created a FAQ around that time answering to that question: https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html Google also tried to tackle the problem https://github.com/google/guava/wiki/ImmutableCollectionsExplained https://guava.dev/releases/21.0/api/docs/com/google/common/collect/ImmutableCollection.html the section "Interfaces, not implementations" explains why you should not takes an immutable list as parameters Some of those classes have been retrofitted in recent releases of the JDK (see List/Map/Set.of and List/Map/Set.copyOf) Some IDEs can emit a warning or an error if you try calls a method that can throw UnsupportedOperationException on a map/collection you receive as return value of a call, usually it's enough to detect 99% of the bugs. regards, Rmi ----- Mail original ----- > De: "M. Kroll" > : "core-libs-dev" > Envoy: Mardi 5 Mai 2020 20:55:00 > Objet: CfD: compile-time checked immutable collections > Hey there! > > I am new here so first i want to introduce myself. My name is Michael > and i live in germany. For a job i am a java developer with 10 years of > java EE experience. At work my passion is to create long-living core > tools for our projects. > > But now for the reason i joined openjdk and this group in particular: > immutable collections. > > During development i sometimes stumble upon the fact that there is no > simple way build an immutable object that exposes a read-only > collection, and all this in a compile-time safe manner. To explain it > with code, i want to have something like this: > > class Example { > private final Collection values; > public Example(String... args) { this.values = Arrays.asList(args); } > public Collection getValues() { return values; } > } > class Test { > public void test() { > Collection v = new Example("a","b","c").getValues(); > v.clear(); // } > } > > The current approach to this is using either > Collections.unmodifiableXYZ(...), which may lead to runtime exceptions. > Or we use Stream as return object, but there is no simple way to pass > that around and use it multiple times. I don't see Supplier as a > solution to this: determining the size of the collection would need to > traverse the whole stream, even if the underlying collection is an > arraylist... not good. > > My approach to this would be to split up the Collection-Interface into a > read-only and a mutating part. > > But before i present you my somewhat complete solution, i asked myself > if you already discussed something like that. So i dived into the bug > database and found 3 somewhat similar tickets: > > 1. https://bugs.openjdk.java.net/browse/JDK-6432147 > The author wanted to introduce annotations to mark objects as > immutable and on basis of this raise compile exceptions. This would need > a load of annotations throughout the code and additional rules to check > by the compiler. The ticket was closed as a duplicate to [2] > 2. https://bugs.openjdk.java.net/browse/JDK-4211070 > The author wanted to introduce a new keyword 'const' to be used > just like the annotation in [1]. Same problem: massive spray of the new > keyword throughout the code and the need for a change in the compiler > and even in the language. > 3. https://bugs.openjdk.java.net/browse/JDK-5099784 > This is as old as JDK1.4.2 (2004) and proposes the same way i want > to go: split the Collection-interface into a new parent-interface that > contains all non-modifying methods and the Collection-interface itself > that then only contains modifying methods. A user of the > Collection-interface would see the same API as before, a user of the new > parent-interface would only see read-only methods. > > The original author of [3] is inactive by now, the ticket itself was not > discussed and is still unresolved open. > > I would happily try to implement this approach, but first i want to know > if this is the way to go and what your thoughts are about this. > > Hope this is not too much text for a Call for Discussion, > Michael From paul.sandoz at oracle.com Wed May 6 16:02:12 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 6 May 2020 09:02:12 -0700 (PDT) Subject: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests In-Reply-To: References: <49F81016-55DF-4E3C-940A-A8DF8C712259@oracle.com> <1886691513.405349.1587389515699.JavaMail.zimbra@u-pem.fr> Message-ID: <523F2CB3-AAA3-4343-80B9-7542652804CE@oracle.com> Hi John, Thanks. For the benefit of others, John and I had a long chat about this and Joe?s CSR comments. I have a better appreciation of your approach to the design and some of the more subjective aspects to guide developers to API points, and to make code more readable (that?s creative API design :-) ). I agree with your assessment on size, lane count, and Mask/Shuffle.vectorSpecies. Re: VectorSpecies.fromByteArray, I now see the method Vector.reinterpretShape appeals to VectorSpecies.fromByteArray for its specification. Removal would result in a less elegant specification of the behavior (making harder to understand). In that sense I think it?s worth its weight. However, I would suggest keeping in sync with a proposed change (on panama-dev) to the related load/store byte[]/ByteBuffer methods, requiring they all accept a ByteOrder. I think this does bring up the wider point you raised about where factory methods reside, and I agree about waiting for specialized generics, as that might allow us to make better moves. Paul. > On May 5, 2020, at 8:01 PM, John Rose wrote: > > On May 1, 2020, at 1:36 PM, Paul Sandoz > wrote: >> >> Hi Remi, >> >> Thanks for the feedback. I am gonna need to go over this with John. Some comments inline. >> >> >>> On Apr 20, 2020, at 6:31 AM, Remi Forax wrote: >>> >>> Hi Paul, >>> about the API part (not the implementation), >>> there are location where the same concept is described with a different names which doesn't help to understand how thing work >>> - vector length <=> vector lane count >>> - vector shape <=> vector bits size >>> - element size <=> lane size >>> >>> "size" should never be used (VectorSpecies.elementSize() by example ) because it's never clear if it's the byte size or the bits size, using byteSize and bitsSize as used several times in the API should be used everywhere. >> >> I agree with being explicit here e.g. s/Vector.elementSize/Vector.elementBitSize and other usages. > > The name ?size? follows the precedent of the API point > Integer.SIZE, which is the size of an `int` in bits. Although > bit-size and byte-size is an important thing to keep track of, > in the case of the Vector type, it lives primarily in registers, > like `int`, and only secondarily in memory (as `int[]` lives > primarily in memory). When you need the size of a datum > in a register, you appeal to its bit count, not its byte count. > > When you store in memory, then you might want its byte > size but for vectors that is an edge case. > > So I don?t think we need bitSize, as a more explicit term for > size, for vectors and their lanes. It is enough to say ?size?. > >> >> I would prefer to consistently use length in methods to refer to the lane count, it matches more closely to an array and for thinking about bounds checking. > > Yes, in this way (contrary to what I just said), a Vector is like > an array, and so it just has a length. It?s a small array, and it > lives in a register, and it doesn?t support good random access, > but it has a length like an array. > >> >> How about on Vector: >> >> /** >> * Returns number of vector lanes ({@code VLENGTH}), commonly referred to as the lane count. >> * >> * @return the number of vector lanes >> */ >> public abstract int length(); > > Yes. Although laneCount would be a runner-up for naming this API point. > But a Vector is enough like an array or String that giving it a length > is the least confusing choice. With documentation that says somewhere > that a vector looks like a little array formed from its lanes, so its length > as a vector is the count of its lanes. > > Also, the semi-formal symbol {@code VLENGTH} is employed throughout > the javadoc, and would have to change to something even uglier like > {@code VLANECOUNT} if we got rid of Vector::length. > >> And then change VectorShape.laneCount to VectorShape.laneLength. >> >> ? > > That sounds wrong, as if it were reporting the length of a lane somewhere. > > Lane-count is correct. As the javadoc explains clearly, a vector > has a certain number of lanes. > >> >> >>> >>> Initially, having VectorSpecies and VectorShape confuse me, it's not the shape of the vector but only it's bits size, >>> renaming VectorShape to VectorBitsSize will help, i think. >>> >> >> Shape is quite a fundamental concept specified and used in the API, representing the information capacity of a vector. >> >> I think it would be misleading to refer to it only as VectorBitSize and unwieldy to change the specification accordingly. In this sense it serves as a useful abstraction to talk about vectors of the same bit size, and operations that change that size or not (such as shape-changing or shape-invariant). > > More comments: > > Shape also plays a critical role in the miscibility of vectors. > Two vectors can line up to perform a lane-wise operation if > and only if they have the same shape. This is fundamental. > If we were to make these rules more ?clever?, allowing > cross-shape lanewise operations, we?d give up on our current > performance levels, because the necessary dynamic checks > would put sand in the gears of the optimizer. > > There are present and future hardware platforms, and software > abstractions, for which shape is more than just ?the number of > my bits?. The max-bits shape is a dynamically determined > shape which is not the same as any statically determined shape. > In the future, shapes may be distinguished according to whether > the involved vectors have intrinsic masks or not. In the near > future, we might like to take the option of making synthetic > shapes, such as ?a pair of 2-lane doubles of VLENGTH=4?, > which are often seen in other vector developer toolkits. > >> >>> You have the same values defined at several places in the API (sometimes with different names), usually it's aliases but it makes the API bigger that it should. >>> I think all the reference to the element type, vector byte size, vector bit size, element byte size, element byte size, vector lane count should not appear on Vector because they are accessible from Species, >>> and to go from a vector to the corresponding species, species() is enough. >>> >> >> But it also makes it less usable, esp. for length(). > > The following is not an obviously or universally correct principle: > ?There should only be one way to do a given task.? It is surely > not universally true for the Vector API. When we point out that > ?API point X is a duplicate of API point Y?, we may or may not > be willing to follow that up with ?so get rid of API point X since > the programmer can reach for Y?. If it?s our favorite utility > method X, we will defend it vigorously. If it?s one we can?t > imagine using, we will suggest that it be voted off the island. > Only the most pure of purists will try to prove that some API > has the minimum number of points, and rest happily only > when that is the case. When Remi objects to Vector::length > he is perhaps being such a purist, but very few programmers > like to live on such spartan foundations, in practice. > > So utility methods like Vector::length, Vector::broadcast, > Vector::maskAll, Vector::toDoubleArray, etc. help make > common coding tasks easier. The most important thing > to make easy is not reducing keystrokes (code golf) but > rather making code as clear as possible. SKI combinators > are a minimal API for Turing computations, but even if > I loved to code with them, my code would not be reviewable > for correctness, and even I couldn?t debug it as well, > without some ?convenience combinators? available. > Likewise, for vectors, it will be so common to loop over > the lanes of a vector, that adding just the tokens > ?.species()? to every loop head will make those loops > harder to read and prove correct. In short: Code > as you like, but if you expect to review or debug it, > your code had better not have much extra ?noise? > in it. This motivates convenience methods. Most > of those in the Vector API have been placed there > because they made somebody?s job easier writing > clear Vector API code. > > A second reason for the convenience methods, in > the Vector API, is discoverability. We put add, sub, > mul, div, min, max, eq, le on Vector not because > that?s the only possible place for their unique > instantiation, but because they are friendly signs, > on the front door of the API (Vector) that it is > open for business. When you noodle around with > a Vector in an API, you instantly see a familiar > looking set of operations. You are not overwhelmed > by hyperbolic arc-cosine, and on the other hand > you are not left with an room empty of everything > but abstract sculptures (the architectural version > of having only higher-order functions). > > When you explore Vector::add, you find that it does > about what you think it should, and how it should. > You also discover the special shed (VectorOperations) > where all the other tools are kept, and observe its > connection to those previously-scary abstract > sculptures (the lanewise and reduction higher order > methods). > > If the purist succeeded in putting everything in one > place, the initial experience of working with Vector > would be very uninformative, more like playing a > role-playing exploration game than getting work > done on a ?batteries included? platform. > > I think the above reasons are also why IntStream::sum > is such a good idea. Anyway, simple stuff should be easy to > read, and complicated stuff should be discoverable from > simple stuff. That why we repeat ourselves, because we > think it will help users. > >> >> >>> You have also the same methods defined at several places, on VectorSpecies and as a static method taking a species as parameter, >>> all the methods of VectorSpecies that takes or return a vector/mask/shuffle should be static in vector/mask/shuffle. >>> >> >> It?s a little more nuanced, but I agree there is some duplication e.g. VectorSpecies.fromByteArray compared to the richer set of methods defined on [E]Vector. I think we can remove that method from VectorSpecies. Then I think we are dealing with the more ?erased/reflective? and long carrier accepting methods for general operation without appealing to E. > > Yes, I?m OK with removing that; it?s more like a leftover from > previous rounds. > > OTOH, the static factories for methods annoy me for various > reasons. I hope we can eventually find a better notation. > Putting methods on VectorSpecies or on Vector itself sometimes > is a viable alternative, sometimes not. Vector::broadcast is > a static factory in disguise, which justifies its redundant > existence in terms of usability and discoverability. But to > do a better job on more API points, we might have to wait > for specialized generics to make better moves. I?m content > to wait? > >> >> >>> I think Binary and Associative should be merged to one VectorOperation, given that the difference is subtle and the whole point of this API is that if the hardware do not provide a way to reduce a binary op, it can be done in Java. >> >> Not quite true, ARM/x86 implementations do provide intrinsic implementations (leveraging a sequence of instructions) for some reduction operations e.g. min/max. I cannot recall there current state of the ARM/x86 implementations for other reductive operations but the plan is to optimize all of them at some point. Further, hardware may evolve in the future. > > It?s also useful, in an IDE, to have a static type check on the > VectorOperation token passed to a reduction operation. > You don?t want to accidentally reduce by SUB or DIV, > and Associative allows the type-checker to stop it. > >> >>> >>> I have no idea what a Conversion.rangeType() is ? >>> >> >> It?s the element type of the resulting output vector, >> >> Doc on VectorOperators.Operator: >> >> /** >> * Reports the special return type of this operator. >> * If this operator is a boolean, returns {@code boolean.class}. >> * If this operator is a {@code Conversion}, >> * returns its {@linkplain Conversion#rangeType range type}. >> * >> * Otherwise, the operator's return value always has >> * whatever type was given as an input, and this method >> * returns {@code Object.class} to denote that fact. >> * @return the special return type, or {@code Object.class} if none >> */ >> Class rangeType(); > > Vector operators are static operation symbols, some of which > have little accessor methods to describe themselves. The range > type of a conversion is like `int` in C++ `operator int()`. > It?s spelled as a type, not with characters. > >> >> >>> More specially: >>> - VectorSpecies.loopbound() is not used in the example ? >> >> In the package-info? Yes, we should update that. > > +1 We should also make sure it optimizes. > >> >> >>> - VectorSpecies.arrayType()/genericElementType() are more for implementers than users , no ? at least arrayType should be arrayElementType. >> >> I don?t think we need to expose genericElementType in the API. > > +1 I wish we had Class.wrapperType, Class.primitiveType also. > >> I suspect arrayType may have been added before it was added to Class in 12 for the constable support. I think we can remove it. > > Yep. Class.arrayType is a nice $0.25 payoff of long technical > debt. (I wonder how much that would compound with interest > over 25 years?) > >> >>> - VectorSpecies.withLanes() => withElementType() >>> >>> - VectorMask.check* are implementer methods ? >> >> The intent is to provide abstractions so the developer can perform ?reflective" checks on vector, mask, or shuffle. > > Yes. Also the Vector API intentionally allows some flexibility > in coding with strong typing (IntVector, etc.) and weak typing > (Vector, etc.). We think we can narrow that gap > with specialized generics, but for now it?s important to allow > both sides to be inhabited. When bridging the gap, you need > casts, and there are lots of operations in the API which help > with this?make it easier to read when a transition is being > made. In particular, the check methods allow an intermediate > value which may have lost static type information to be > re-equipped with that static type information. Maybe they > will be less important in the future, but I think even in the > future it will be useful to be able to assert that two vectors > are of the same shape. (Remember that vector shape is > always a constraint on correct mixing of vectors, so it?s > something the programmer needs help with sometimes.) > >> >> >>> - VectorMask.equal(VectorMask) => equiv >>> >> >> Because it?s too close to the name ?equals?? > > Should have been eq, I guess. Perhaps it?s a leftover from > before we had eq/ne/le/lt/gt/ge. > >> >> >>> - VectorShuffle.check* are implementer methods ? >>> - VectorShuffle.vectorSpecies() => VectorShuffle.species() (as in Vector and VectorMask) >> >> Ok. > > It?s hair-splitting, but a VectorShuffle, because it isn?t a vector, > doesn?t have a species. It operates on vectors of a common species. > So, while we have Vector::species, we have (at a larger conceptual > distance) VectorShuffle::vectorSpecies and VectorMask::vectorSpecies. > The shuffles and masks know which species of vector they apply > to, but that?s ?their species? indirectly. Who was Babe Ruth?s team? > His kids didn?t have the same team, but they had their father?s team, > only indirectly. > >> >> >>> - VectorShuffle.toVector() should return a IntVector >> >> No, it returns a vector according to its species. Note the constraint that shuffle source indexes are always in the range of -VLENGTH to VLENGTH - 1. > > This is a sore point in the API. A VectorShuffle isn?t a vector > in part because its lanes contain source indexes (lane pointers) > instead of vector data. What?s the implementation type? We > don?t know exactly, could be byte, could be int, could be some > clever union type superimposed on the vectors being operated on. > > It gets worse when the vector being operated on is too long > and too narrow (at the same time) for its lanes to be able to > encode all the necessary values. A vector of 512 lanes each > of 8 bits is out of luck in this sense. In fact, it needs 10 bits > (not 9) per source index in order to represent the ?negative > conjugate? (invalid) source index values, which are required > for various common operations. > > What to do? I?m not sure, but the answer probably has to do > with treating VectorShuffle::toVector as a contracting and/or > expanding operation, complete with part numbers. Or it could > be treated as producing an unstated companion type, which > must be queried reflectively. For now we?ve papered over > the problems, but the paper won?t hold forever. > >> >> >>> - VectorShuffle.laneIsValid(), it seems to be an operation on Vector, not VectorShuffle. >>> >> >> No, its specific to shuffle for masking out exceptional indexes (those < 0). > > (?negative conjugates?. A term I just made up today. Not tired of it yet.) > > See the javadoc for what they do and how they work. In short, > we always add exactly one bit to the necessary set of bits for > representing a lane index. The scheme works for VLENGTH > which is not a power of two. And it gives various commonly > seen idioms for masking, merging, and error checking. > >> >> >>> - IntVector.max, why there is no binary version that takes a mask ? It's documented but not why it's not available. >>> >> >> It's to reduce the number of methods. On Vector: >> >> * This is not a full-service named operation like >> * {@link #add(Vector) add()}. A masked version of >> * this operation is not directly available >> * but may be obtained via the masked version of >> * {@code lanewise}. Subclasses define an additional >> * scalar-broadcast overloading of this method. >> > > We should probably document ?full service?. (Briefly!) > Joe Darcy also mentioned this. > >> >>> >>> and i'm also not a big fans of the method that returns a long instead of a vector and only works on 64 bits values. >>> >> >> Can you provide more details? > > The API points which work with double and long, in the weakly > typed API, use those types as ?top for primitive?. Any primitive > will fit without loss in either a long or double (sometimes both), > just as any Vector will fit in a Vector, without loss. If you > just need to broadcast zero, or get back a count, then putting it > into a long is a really cheap form of boxing, and easy to read > and prove correct. (And the redundant API point that helps > you tells you where to find the ?real stuff? that?s going on, > so you can learn about it if you need to.) > > I think these API points might need a little more documentation, > to make it clear that they are doing *nothing* more than the > corresponding strongly-typed API points, plus (to make up > the primitive type differences) a cheap type conversion and/or > error check. (Type conversion on output, error check on input, > seems to be the most useful choice here. It?s an oddly reversed > occurrence of Postel?s Law.) In particular, if I ask an IntVector > to sum up its lanes, I don?t expect that the long version of the > result will carry any more bits of information than the strongly > typed int version (which truncates overflow). > > HTH > > ? John From john.r.rose at oracle.com Wed May 6 17:22:37 2020 From: john.r.rose at oracle.com (John Rose) Date: Wed, 6 May 2020 10:22:37 -0700 Subject: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests In-Reply-To: <523F2CB3-AAA3-4343-80B9-7542652804CE@oracle.com> References: <49F81016-55DF-4E3C-940A-A8DF8C712259@oracle.com> <1886691513.405349.1587389515699.JavaMail.zimbra@u-pem.fr> <523F2CB3-AAA3-4343-80B9-7542652804CE@oracle.com> Message-ID: Thanks, Paul! Talking with you about it helped me formulate my thoughts better. > On May 6, 2020, at 9:02 AM, Paul Sandoz wrote: > > Hi John, > > Thanks. For the benefit of others, John and I had a long chat about this and Joe?s CSR comments. > > I have a better appreciation of your approach to the design and some of the more subjective aspects to guide developers to API points, and to make code more readable (that?s creative API design :-) ). > > I agree with your assessment on size, lane count, and Mask/Shuffle.vectorSpecies. > > Re: VectorSpecies.fromByteArray, I now see the method Vector.reinterpretShape appeals to VectorSpecies.fromByteArray for its specification. Removal would result in a less elegant specification of the behavior (making harder to understand). In that sense I think it?s worth its weight. However, I would suggest keeping in sync with a proposed change (on panama-dev) to the related load/store byte[]/ByteBuffer methods, requiring they all accept a ByteOrder. > I think this does bring up the wider point you raised about where factory methods reside, and I agree about waiting for specialized generics, as that might allow us to make better moves. > > Paul. From andy.herrick at oracle.com Wed May 6 19:13:53 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 6 May 2020 15:13:53 -0400 Subject: RFR: JDK-8236518: There is no Native Packages WinUpgradeUUIDTest-2.0.exe after creating Native packages on win Message-ID: Please review jpackage test fix to issue [1] at [2] [1] - https://bugs.openjdk.java.net/browse/JDK-8236518 [2] - http://cr.openjdk.java.net/~herrick/8236518/webrev.01 /Andy From claes.redestad at oracle.com Wed May 6 19:50:07 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 6 May 2020 21:50:07 +0200 Subject: RFR: 8244413: Avoid rebinds in MethodHandle.viewAsType In-Reply-To: <80cdf4c9-3bec-0e7a-c779-909b75100050@oracle.com> References: <1f48fd48-0bb9-7a14-dfa1-cf09545e56ff@oracle.com> <34b04075-f9b3-2802-ac5a-7589199d6f57@oracle.com> <97f1284a-4007-c14c-6a91-27efd145dea8@oracle.com> <80cdf4c9-3bec-0e7a-c779-909b75100050@oracle.com> Message-ID: <6b93f5c6-e678-bd8d-f068-bbb974bdca84@oracle.com> On 2020-05-06 16:59, Claes Redestad wrote: > > -XX:TieredStopAtLevel=1: > ??????? Benchmark?????????? Mode? Cnt??? Score?? Error? Units > 15-b19? Capture0.lambda_01? avgt??? 5??? 6.312 ? 0.919? ns/op > 15-b20? Capture0.lambda_01? avgt??? 5? 105.761 ? 7.575? ns/op > jdk???? Capture0.lambda_01? avgt??? 5? 105.228 ? 7.175? ns/op > > So outside of the direct bootstrap improvement, there's a positive > effect during early warmup. Sadly this patch doesn't translate into an > improvement in C1. I can see a rather large regression in C1 on this > specific micro in 15-b20 (which is where the Hidden Classes integration > happened). Filed: https://bugs.openjdk.java.net/browse/JDK-8244550 Overhead is entirely in Unsafe::allocateInstance, which will be intrinsified by C2, but has ~100ns/op overhead when called from interpreter and C1 code. I've prototyped a patch to remove a few redundant VM->native transitions and gotten this overhead down to 60ns/op. /Claes From stuart.marks at oracle.com Wed May 6 20:00:54 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 6 May 2020 13:00:54 -0700 Subject: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException In-Reply-To: References: <3b4efc42-f45f-820f-44af-89c3fa28ac39@oracle.com> <2b1a70a8-7d0a-9d7a-b48d-69de03b07e2e@oracle.com> Message-ID: <5802ab85-0195-fe6c-26fc-c47fcc9ffc70@oracle.com> OK, pushed: http://hg.openjdk.java.net/jdk/jdk/rev/6b4e4ffe01ab Thanks for your contribution! s'marks On 5/4/20 1:50 AM, Jayashree Sk1 wrote: > > Hi Stuart, > > Yup Contributed-by as picked from my email : jayashreesk . > Will keep in mind about the complicated change-sets. > > > Thanks > Jay > > -----Stuart Marks wrote: ----- > To: Jayashree Sk1 > From: Stuart Marks > Date: 05/01/2020 09:32AM > Cc: core-libs-dev at openjdk.java.net > Subject: [EXTERNAL] Re: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException > > Hi Jay, > > OK, welcome! I'll sponsor this changeset for you. It's pretty simple, so I'll > just paste the exported changeset below. (For complicated changesets, you'll > have to ask a sponsor to host a webrev on cr.openjdk.java.net for you.) Please > check the Contributed-by line in the changeset to make sure the attribution is > correct. I just copied the From: line from your email, but if you want it to be > different, please let me know. > > I'll update the bug report with a pointer to this email thread. > > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D6415694&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=rA_13vli8clPM_toR46hq8FVwH3XGr8z7cUfcQoqL-k&m=9YMcjPnAAEf40XGqmcEU_Uiyg_xCVlOU26-U56hEb4A&s=ueOfMpgrTsTZc7xg22AdzVskohCya_stq_WLTREzw24&e= > > Could I get a Reviewer to review this? Thanks. > > (I noticed that the anachronistic markup is used here instead of the > preferred {@code ...} javadoc tag. However, is used all over this > package, so I didn't think that changing it in just one place would be helpful.) > > I'll also note again that since this is merely an editorial wording change to > the specification, I don't think it needs a CSR request. > > Thanks, > > s'marks > > > > > > # HG changeset patch > # User smarks > # Date 1588290431 25200 > # Thu Apr 30 16:47:11 2020 -0700 > # Node ID 1f5b3876d1500a2e77d6e39d079649964ba6dd26 > # Parent fe6548dc92de4c875467c968ee37e7c9bbee1697 > 6415694: Clarification in Javadoc for java.rmi.AlreadyBoundException > Reviewed-by: XXX > Contributed-by: Jayashree Sk1 > > diff -r fe6548dc92de -r 1f5b3876d150 > src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java > --- a/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Thu Apr 30 > 15:21:15 2020 -0700 > +++ b/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Thu Apr 30 > 16:47:11 2020 -0700 > @@ -26,8 +26,8 @@ > > /** > * An AlreadyBoundException is thrown if an attempt > - * is made to bind an object in the registry to a name that already > - * has an associated binding. > + * is made to bind an object to a name that already > + * has an associated binding in the registry. > * > * @since 1.1 > * @author Ann Wollrath > > > > > On 4/29/20 10:24 PM, Jayashree Sk1 wrote: >> Thanks for the review comment Stuart. Yes, I will need a sponsor, this is my first time here in OpenJDK. >> >> >> Regards! >> Jay >> >> -----Stuart Marks wrote: ----- >> To: Jayashree Sk1 >> From: Stuart Marks >> Date: 04/30/2020 09:22AM >> Cc: core-libs-dev at openjdk.java.net >> Subject: [EXTERNAL] Re: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException >> >> The change looks fine. Although this is in a normative portion of the >> specification, the nature of the change is purely editorial, so I don't think it >> needs a CSR. >> >> Do you need a sponsor? >> >> s'marks >> >> On 4/29/20 2:57 AM, Jayashree Sk1 wrote: >>> Hi All, >>> Please find the below changes for the issues https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D6415694&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=rA_13vli8clPM_toR46hq8FVwH3XGr8z7cUfcQoqL-k&m=OXEC-w1xTWoJUyw_sRivRwIGmkHIUc3DllMsA_N3qIk&s=iesFFcE4NSOreLmf8vwdKzcdnFgjGE_SEERICPUFef4&e= . >>> It is a description change, which was already approved by the reviewer. >>> >>> Thanks! >>> >>> diff -r 59b5bd9a7168 src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java >>> --- a/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Mon Mar 16 02:16:49 2020 -0400 >>> +++ b/src/java.rmi/share/classes/java/rmi/AlreadyBoundException.java Mon Mar 30 15:45:43 2020 +0530 >>> @@ -26,8 +26,8 @@ >>> >>> /** >>> * An AlreadyBoundException is thrown if an attempt >>> - * is made to bind an object in the registry to a name that already >>> - * has an associated binding. >>> + * is made to bind an object to a name that already >>> + * has an associated binding in the registry. >>> * >>> * @since 1.1 >>> * @author Ann Wollrath >>> >> >> > > From mandy.chung at oracle.com Wed May 6 20:11:22 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 6 May 2020 13:11:22 -0700 Subject: RFR: 8244413: Avoid rebinds in MethodHandle.viewAsType In-Reply-To: <6b93f5c6-e678-bd8d-f068-bbb974bdca84@oracle.com> References: <1f48fd48-0bb9-7a14-dfa1-cf09545e56ff@oracle.com> <34b04075-f9b3-2802-ac5a-7589199d6f57@oracle.com> <97f1284a-4007-c14c-6a91-27efd145dea8@oracle.com> <80cdf4c9-3bec-0e7a-c779-909b75100050@oracle.com> <6b93f5c6-e678-bd8d-f068-bbb974bdca84@oracle.com> Message-ID: <053f6de7-85fd-3fd2-f2bb-359a7819247d@oracle.com> On 5/6/20 12:50 PM, Claes Redestad wrote: > On 2020-05-06 16:59, Claes Redestad wrote: >> >> -XX:TieredStopAtLevel=1: >> ???????? Benchmark?????????? Mode? Cnt??? Score?? Error? Units >> 15-b19? Capture0.lambda_01? avgt??? 5??? 6.312 ? 0.919? ns/op >> 15-b20? Capture0.lambda_01? avgt??? 5? 105.761 ? 7.575? ns/op >> jdk???? Capture0.lambda_01? avgt??? 5? 105.228 ? 7.175? ns/op >> >> So outside of the direct bootstrap improvement, there's a positive >> effect during early warmup. Sadly this patch doesn't translate into an >> improvement in C1. I can see a rather large regression in C1 on this >> specific micro in 15-b20 (which is where the Hidden Classes integration >> happened). > > Filed: https://bugs.openjdk.java.net/browse/JDK-8244550 > Thanks. > Overhead is entirely in Unsafe::allocateInstance, which will be > intrinsified by C2, but has ~100ns/op overhead when called from > interpreter and C1 code. > > I've prototyped a patch to remove a few redundant VM->native transitions > and gotten this overhead down to 60ns/op. > FTR, prior to hidden classes, LMF generated a factory method to create an instance of lambda proxy via invokespecial.?? With hidden classes, it can get the constructor iva findConstructor and that causes Unsafe::allocateInstance to be called. Mandy From naoto.sato at oracle.com Wed May 6 20:44:11 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 6 May 2020 13:44:11 -0700 Subject: [15]: RFR: 8244245: localizedBy() should override localized values with default values Message-ID: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8244245 The CSR and proposed changeset are located at: https://bugs.openjdk.java.net/browse/JDK-8244246 https://cr.openjdk.java.net/~naoto/8244245/webrev.00/ This stems from the closed issue (https://bugs.openjdk.java.net/browse/JDK-8243162), and the rationale for this fix is discussed there. Naoto From stuart.marks at oracle.com Wed May 6 21:08:48 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 6 May 2020 14:08:48 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> Message-ID: On 5/4/20 6:44 PM, Alan Snyder wrote: > What problem are you trying to solve? > > The Collections framework explicitly does not support custom membership > semantics. If you think it should, file an RFE and create a JEP. It?s not a > small change and tinkering is not the way to get there. There are already three different kinds of sets in the JDK that support different membership semantics: sets derived from IdentityHashMap, ordinary sets like HashSet, and the SortedSet/NavigableSet family. Arguably the last already supports custom membership semantics, as it's possible for callers to provide their own comparators. I'm trying to fix semantic bugs in the way various collection operations handle situations with mixed membership semantics, and secondarily, to avoid pathological performance problems that have arisen. > If your present concern is performance surprises, be aware that your new > proposal has the same problem as the old one. Although it removes some > data-dependent performance surprises, it adds a potential JDK-dependent > performance surprise. The data-dependent performance issues can be detected by > testing, but no amount of testing can alert a developer to the possibility that > an unexpected implementation change in a future JDK might cause a big > performance hit. > > You may have mis-remembered the performance problem that I am concerned about. > It involves using removeAll to remove a relatively small number of elements from > a large, hash based collection. The performance hit is the need to iterate over > the entire collection and test every element regardless of the number of > elements being removed. Although the performance problem may be exacerbated when > the argument is a List, the problem exists for any collection that is much > smaller than the target collection. You're conflating two different parts of the performance issue. This is illustrated in an article that Jon Skeet posted back in 2010, [1] which is linked from JDK-6982173. Briefly, Skeet observed that a removeAll using a List of 300,000 elements could take nearly 3 minutes, whereas iterating a HashSet of 1,000,000 elements would take only 38ms. (These numbers are from 2010, and hardware is certainly different today, and these aren't rigorous benchmarks. However, an informal benchmark that shows the difference between 3 minutes and 38ms is a pretty clear demonstration of a performance problem.) Taking 3 minutes for this kind of operation is clearly pathological behavior, which is what I'm trying to address. Although it seems impossible to prevent it from ever happening, putting some special cases for handling List into places such as HashSet.removeAll would seem to cover the most of the common cases. It's true that if you're removing a small set from a large set, iterating the "wrong" set might take 38ms instead of a much smaller time (probably microseconds). This would indeed be a performance regression. (It might also be an improvement in correctness, if the sets have different membership contracts.) The fact is that there are performance regressions from one JDK release to the next. Sometimes they're introduced by accident, and we try to address these where possible. Sometimes they're introduced intentionally, as part of various tradeoffs. That's what's going on here. I'm improving the correctness of the system and avoiding pathological performance problems, while introducing a performance regression that seems modest relative to the pathological performance issue that's being mitigated. s'marks [1] https://codeblog.jonskeet.uk/2010/07/29/there-s-a-hole-in-my-abstraction-dear-liza-dear-liza/ > > ? Alan > > > > >> On May 4, 2020, at 5:25 PM, Stuart Marks > > wrote: >> >> >> >> On 5/1/20 10:41 PM, Jason Mehrens wrote: >>> 1. I assume you are using "c instanceof List" instead of "!(c instanceof >>> Set)" to correctly handle IdentitityHashMap.values()? ?The instanceof List >>> seems like safe choice but it is too bad we can still fool that check by >>> wrapping List as an unmodifiableCollection. ?If >>> splitIterator().characteristics() could tell us that the collection used >>> identity comparisons I think we would be able to determine if it was safe to >>> swap the ordering in the general case as we could check for IDENTITY, SORTED, >>> and comparator equality. >> >> I'm using "instance List", not for the reason of IdentityHashMap.values() >> specifically (though that's a good example), but mainly to try to be minimal. >> While I think getting the semantics right takes priority, the change does >> impact performance, so I want to reintroduce the performance heuristic in the >> safest manner possible. Checking for !Set seems dangerous, as there might be >> any number of Collections out there that aren't Sets and that aren't >> consistent with equals. Checking for instanceof List seemed like the safest >> and most minimal thing to do. >> >> In fact, I'm not even sure how safe List is! It's certainly possible for >> someone to have a List that isn't consistent with equals. Such a thing might >> violate the List contract, but that hasn't stopped people from implementing >> such things (outside the JDK). >> >> I also toyed around with various additional tests for when it would be >> profitable to switch iteration to the smaller collection. This could be >> applied to a variety of consistent-with-equals set implementations in the JDK. >> The benefits of swapping the iteration is more modest in these cases compared >> to List, however. Avoiding repeated List.contains() helps avoid >> quasi-quadratic (O(M*N)) performance. Swapping iteration order of sets gets us >> only the smaller of O(M) vs O(N), which is still linear. >> >> Also, as you noted, this heuristic is easily defeated by things like the >> collection wrappers. >> >>> 2. Should code applied to HashSet.removeAll also be applied to >>> HashMap.keySet().removeAll and HashMap.entrySet().removeAll? >>> ?Collections::newSetFromMap will end up having different behavior if it is >>> not consistently applied. >> >> I think the *results* will be consistent, but the *performance* might not be >> consistent. >> >> But these cases could result in pathological performance if removeAll(list) is >> called, so I'm a bit concerned about them. If we agree that "instanceof List" >> is a reasonable heuristic, then I don't have any objection in principle to >> adding it to these locations as well. But I want to be careful about >> sprinkling ad hoc policies like this around the JDK. >> >> I note that the erroneous size-based optimization was copied into, and >> therefore needs to be removed from ConcurrentSkipListSet (JDK-8218945) and the >> set views of CHM (JDK-8219069). I'd more concerned about getting these cleaned >> up in the short term. >> >>> 3. Not to derail this thread but do think we need a new JIRA ticket to >>> address Collections.disjoint? ?Seems like it has similar sins of calling size >>> and using "!(c2 instanceof Set)" but I don't want to muddy the waters by >>> covering any solutions to that method in this thread. >> >> Yeah I'm not sure what to do about Collections.disjoint(). >> >> Note that there are some statements in bug reports (possibly even made by me!) >> that assert that Collections.disjoint should be consistent with Set.removeAll. >> I don't think that's the case. As discussed elsewhere, removeAll() needs to be >> consistent about relying on the membership semantics of the argument collection. >> >> As Collections.disjoint currently stands, it has the big "Care must be >> exercised" disclaimer in its spec, and it goes to some length to make a bunch >> of tests and vary the iteration accordingly. The programmer can get a speedup >> using disjoint() compared to copying a set and then calling retainAll(), >> provided sufficient care is taken. Maybe that's an acceptable tradeoff. >> >> If you have any ideas about how disjoint()'s spec or implementation could be >> improved, you could file a JIRA issue, or I could file one if you sent me the >> info. >> >> s'marks >> > From alexander.matveev at oracle.com Wed May 6 22:05:27 2020 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Wed, 6 May 2020 15:05:27 -0700 Subject: RFR: JDK-8236518: There is no Native Packages WinUpgradeUUIDTest-2.0.exe after creating Native packages on win In-Reply-To: References: Message-ID: <8d742bba-bcfe-f441-15f3-a08678382fdb@oracle.com> Hi Andy, Looks good. Thanks, Alexander On 5/6/20 12:13 PM, Andy Herrick wrote: > Please review jpackage test fix to issue [1] at [2] > > [1] - https://bugs.openjdk.java.net/browse/JDK-8236518 > > [2] - http://cr.openjdk.java.net/~herrick/8236518/webrev.01 > > /Andy > > From scolebourne at joda.org Wed May 6 23:06:04 2020 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 7 May 2020 00:06:04 +0100 Subject: [15]: RFR: 8244245: localizedBy() should override localized values with default values In-Reply-To: References: Message-ID: +1 Stephen On Wed, 6 May 2020 at 21:50, wrote: > > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8244245 > > The CSR and proposed changeset are located at: > > https://bugs.openjdk.java.net/browse/JDK-8244246 > https://cr.openjdk.java.net/~naoto/8244245/webrev.00/ > > This stems from the closed issue > (https://bugs.openjdk.java.net/browse/JDK-8243162), and the rationale > for this fix is discussed there. > > Naoto > From alexey.semenyuk at oracle.com Wed May 6 23:31:14 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 6 May 2020 19:31:14 -0400 Subject: RFR: JDK-8236518: There is no Native Packages WinUpgradeUUIDTest-2.0.exe after creating Native packages on win In-Reply-To: References: Message-ID: <8d3d8bf0-1232-7052-2ebe-bea0b27b18bd@oracle.com> Looks good. - Alexey On 5/6/2020 3:13 PM, Andy Herrick wrote: > Please review jpackage test fix to issue [1] at [2] > > [1] - https://bugs.openjdk.java.net/browse/JDK-8236518 > > [2] - http://cr.openjdk.java.net/~herrick/8236518/webrev.01 > > /Andy > > From aleksej.efimov at oracle.com Wed May 6 23:52:46 2020 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Thu, 7 May 2020 00:52:46 +0100 Subject: RFR: 8237834: com/sun/jndi/ldap/LdapDnsProviderTest.java failing with LDAP response read timeout Message-ID: Hi, LdapDnsProviderTest test expects to have no services running on 1111 port on test machine. That could cause it to fail intermittently due to unexpected exception message thrown by LDAP client, i.e. timeout or disconnect instead of expected connection refusal. The proposed fix tries to make test more stable ('intermittent' key was still added) by running test cases with non-default port multiple times by trying to use different random port numbers ('randomness' key was added) for each run. Webrev: http://cr.openjdk.java.net/~aefimov/8237834/00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8237834 Test was not observed to fail for over 300 iterations. With Best Regards, Aleksei From javalists at cbfiddle.com Thu May 7 00:05:17 2020 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 6 May 2020 17:05:17 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> Message-ID: <4B44293C-2465-4BA7-B6F6-9AAA437760C4@cbfiddle.com> > On May 6, 2020, at 2:08 PM, Stuart Marks wrote: > > > > On 5/4/20 6:44 PM, Alan Snyder wrote: >> What problem are you trying to solve? >> The Collections framework explicitly does not support custom membership semantics. If you think it should, file an RFE and create a JEP. It?s not a small change and tinkering is not the way to get there. > > There are already three different kinds of sets in the JDK that support different membership semantics: sets derived from IdentityHashMap, ordinary sets like HashSet, and the SortedSet/NavigableSet family. Arguably the last already supports custom membership semantics, as it's possible for callers to provide their own comparators. I'm trying to fix semantic bugs in the way various collection operations handle situations with mixed membership semantics, and secondarily, to avoid pathological performance problems that have arisen. > Let me clarify. I was referring to the non-support by the framework, which restricts membership semantics: Many methods in Collections Framework interfaces are defined in terms of the equals method. For example, the specification for the contains(Object o) method says: "returns true if and only if this collection contains at least one element e such that (o==null ? e==null : o.equals(e))." This specification should not be construed to imply that invoking Collection.contains with a non-null argument o will cause o.equals(e) to be invoked for any element e. Implementations are free to implement optimizations whereby the equals invocation is avoided, for example, by first comparing the hash codes of the two elements. (The Object.hashCode() specification guarantees that two objects with unequal hash codes cannot be equal.) More generally, implementations of the various Collections Framework interfaces are free to take advantage of the specified behavior of underlying Object methods wherever the implementor deems it appropriate. Although the framework provides implementation classes that MAY be used to create nonconforming collections, these classes are called out as potentially non-conforming. For example: This class is not a general-purpose Map implementation! While this class implements the Map interface, it intentionally violates Map's general contract, which mandates the use of the equals method when comparing objects. This class is designed for use only in the rare cases wherein reference-equality semantics are required. And in many places, the implications of non-conformance are also called out: While the object returned by this method implements the Collection interface, it does not obey Collection's general contract. Like its backing map, the collection returned by this method defines element equality as reference-equality rather than object-equality. This affects the behavior of its contains, remove and containsAll methods. The phrase ?affects the behavior? is open ended. It means all bets are off. (I am glad to see these statements in the specification, but I would not assume that all possible behavioral consequences are documented.) As it is also the case that these classes CAN be used to create conforming collections, there is justification for including them in the generic type hierarchy, but such inclusion does not imply conformance for all instances of these classes. The type system is inadequate to fully distinguish conforming and non-conforming collections. My point is that (fully) supporting custom membership semantics changes a fundamental property of the original design and should be approached as a redesign. It is not a matter of fixing a series of issues one at a time, as you discover them. Calling these issues semantic bugs when there is no violation of the specification is leading you down the wrong path, in my opinion. What would (full) support for custom membership semantics look like? What restrictions would you place on the contains() method? What axioms would you specify for the generic operations? Is substitutability tossed out the window? What does it mean for an object to be a member of a set (according to contains) but not be returned by the iterator or included in the size? What should Set.copyOf() do if its argument is a non-conforming collection? etc. etc. >> If your present concern is performance surprises, be aware that your new proposal has the same problem as the old one. Although it removes some data-dependent performance surprises, it adds a potential JDK-dependent performance surprise. The data-dependent performance issues can be detected by testing, but no amount of testing can alert a developer to the possibility that an unexpected implementation change in a future JDK might cause a big performance hit. >> You may have mis-remembered the performance problem that I am concerned about. It involves using removeAll to remove a relatively small number of elements from a large, hash based collection. The performance hit is the need to iterate over the entire collection and test every element regardless of the number of elements being removed. Although the performance problem may be exacerbated when the argument is a List, the problem exists for any collection that is much smaller than the target collection. > > You're conflating two different parts of the performance issue. > > This is illustrated in an article that Jon Skeet posted back in 2010, [1] which is linked from JDK-6982173. Briefly, Skeet observed that a removeAll using a List of 300,000 elements could take nearly 3 minutes, whereas iterating a HashSet of 1,000,000 elements would take only 38ms. > > (These numbers are from 2010, and hardware is certainly different today, and these aren't rigorous benchmarks. However, an informal benchmark that shows the difference between 3 minutes and 38ms is a pretty clear demonstration of a performance problem.) > > Taking 3 minutes for this kind of operation is clearly pathological behavior, which is what I'm trying to address. Although it seems impossible to prevent it from ever happening, putting some special cases for handling List into places such as HashSet.removeAll would seem to cover the most of the common cases. > > It's true that if you're removing a small set from a large set, iterating the "wrong" set might take 38ms instead of a much smaller time (probably microseconds). This would indeed be a performance regression. (It might also be an improvement in correctness, if the sets have different membership contracts.) > > The fact is that there are performance regressions from one JDK release to the next. Sometimes they're introduced by accident, and we try to address these where possible. Sometimes they're introduced intentionally, as part of various tradeoffs. That's what's going on here. I'm improving the correctness of the system and avoiding pathological performance problems, while introducing a performance regression that seems modest relative to the pathological performance issue that's being mitigated. > > s'marks > > [1] https://codeblog.jonskeet.uk/2010/07/29/there-s-a-hole-in-my-abstraction-dear-liza-dear-liza/ > I understand that trade-offs are necessary, and if I understand correctly, the CSR process should review intentional regressions. Do you agree? Alan > > >> Alan >>> On May 4, 2020, at 5:25 PM, Stuart Marks > wrote: >>> >>> >>> >>> On 5/1/20 10:41 PM, Jason Mehrens wrote: >>>> 1. I assume you are using "c instanceof List" instead of "!(c instanceof Set)" to correctly handle IdentitityHashMap.values()? The instanceof List seems like safe choice but it is too bad we can still fool that check by wrapping List as an unmodifiableCollection. If splitIterator().characteristics() could tell us that the collection used identity comparisons I think we would be able to determine if it was safe to swap the ordering in the general case as we could check for IDENTITY, SORTED, and comparator equality. >>> >>> I'm using "instance List", not for the reason of IdentityHashMap.values() specifically (though that's a good example), but mainly to try to be minimal. While I think getting the semantics right takes priority, the change does impact performance, so I want to reintroduce the performance heuristic in the safest manner possible. Checking for !Set seems dangerous, as there might be any number of Collections out there that aren't Sets and that aren't consistent with equals. Checking for instanceof List seemed like the safest and most minimal thing to do. >>> >>> In fact, I'm not even sure how safe List is! It's certainly possible for someone to have a List that isn't consistent with equals. Such a thing might violate the List contract, but that hasn't stopped people from implementing such things (outside the JDK). >>> >>> I also toyed around with various additional tests for when it would be profitable to switch iteration to the smaller collection. This could be applied to a variety of consistent-with-equals set implementations in the JDK. The benefits of swapping the iteration is more modest in these cases compared to List, however. Avoiding repeated List.contains() helps avoid quasi-quadratic (O(M*N)) performance. Swapping iteration order of sets gets us only the smaller of O(M) vs O(N), which is still linear. >>> >>> Also, as you noted, this heuristic is easily defeated by things like the collection wrappers. >>> >>>> 2. Should code applied to HashSet.removeAll also be applied to HashMap.keySet().removeAll and HashMap.entrySet().removeAll? Collections::newSetFromMap will end up having different behavior if it is not consistently applied. >>> >>> I think the *results* will be consistent, but the *performance* might not be consistent. >>> >>> But these cases could result in pathological performance if removeAll(list) is called, so I'm a bit concerned about them. If we agree that "instanceof List" is a reasonable heuristic, then I don't have any objection in principle to adding it to these locations as well. But I want to be careful about sprinkling ad hoc policies like this around the JDK. >>> >>> I note that the erroneous size-based optimization was copied into, and therefore needs to be removed from ConcurrentSkipListSet (JDK-8218945) and the set views of CHM (JDK-8219069). I'd more concerned about getting these cleaned up in the short term. >>> >>>> 3. Not to derail this thread but do think we need a new JIRA ticket to address Collections.disjoint? Seems like it has similar sins of calling size and using "!(c2 instanceof Set)" but I don't want to muddy the waters by covering any solutions to that method in this thread. >>> >>> Yeah I'm not sure what to do about Collections.disjoint(). >>> >>> Note that there are some statements in bug reports (possibly even made by me!) that assert that Collections.disjoint should be consistent with Set.removeAll. I don't think that's the case. As discussed elsewhere, removeAll() needs to be consistent about relying on the membership semantics of the argument collection. >>> >>> As Collections.disjoint currently stands, it has the big "Care must be exercised" disclaimer in its spec, and it goes to some length to make a bunch of tests and vary the iteration accordingly. The programmer can get a speedup using disjoint() compared to copying a set and then calling retainAll(), provided sufficient care is taken. Maybe that's an acceptable tradeoff. >>> >>> If you have any ideas about how disjoint()'s spec or implementation could be improved, you could file a JIRA issue, or I could file one if you sent me the info. >>> >>> s'marks >>> > From yumin.qi at oracle.com Thu May 7 01:01:42 2020 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 6 May 2020 18:01:42 -0700 Subject: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750 Message-ID: <2fe9ee54-da65-bf68-cd0a-279a7e002f5a@oracle.com> Hi, ? Please review the fix for ? bug: https://bugs.openjdk.java.net/browse/JDK-8244495 ? webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ Tests tools/jlink/JLinkTest.javaand tools/jlink/basic/BasicTest.java failed after 8237750 pushed. The fix of 8237750 changed default behavior of loading zip library to on-demand loading. jlink (and jimage) assumes that zip library was loaded already, so call to FindEntry caused ACCESS_VIOLATION on Windows. This is a Windows specific problem. GetModuleHandle is used on the library already loaded and won't load the library if it's not loaded. ?? Tests: tier1-2 passed. ? Thanks ? Yumin From kim.barrett at oracle.com Thu May 7 01:26:42 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 6 May 2020 21:26:42 -0400 Subject: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750 In-Reply-To: <2fe9ee54-da65-bf68-cd0a-279a7e002f5a@oracle.com> References: <2fe9ee54-da65-bf68-cd0a-279a7e002f5a@oracle.com> Message-ID: <955183EB-FF98-4D31-97F0-FF77DF6A7E47@oracle.com> > On May 6, 2020, at 9:01 PM, Yumin Qi wrote: > > Hi, > Please review the fix for > bug: https://bugs.openjdk.java.net/browse/JDK-8244495 > webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ > > Tests tools/jlink/JLinkTest.javaand tools/jlink/basic/BasicTest.java failed after 8237750 pushed. The fix of 8237750 changed default behavior of loading zip library to on-demand loading. jlink (and jimage) assumes that zip library was loaded already, so call to FindEntry caused ACCESS_VIOLATION on Windows. This is a Windows specific problem. GetModuleHandle is used on the library already loaded and won't load the library if it's not loaded. > > Tests: tier1-2 passed. > > Thanks > Yumin Looks good. From mandy.chung at oracle.com Thu May 7 01:50:03 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 6 May 2020 18:50:03 -0700 Subject: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750 In-Reply-To: <2fe9ee54-da65-bf68-cd0a-279a7e002f5a@oracle.com> References: <2fe9ee54-da65-bf68-cd0a-279a7e002f5a@oracle.com> Message-ID: <8c7bba71-764e-00c4-8a99-b4ace4db05c1@oracle.com> This looks okay to me. Mandy On 5/6/20 6:01 PM, Yumin Qi wrote: > Hi, > ? Please review the fix for > ? bug: https://bugs.openjdk.java.net/browse/JDK-8244495 > ? webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ > > Tests tools/jlink/JLinkTest.javaand tools/jlink/basic/BasicTest.java > failed after 8237750 pushed. The fix of 8237750 changed default > behavior of loading zip library to on-demand loading. jlink (and > jimage) assumes that zip library was loaded already, so call to > FindEntry caused ACCESS_VIOLATION on Windows. This is a Windows > specific problem. GetModuleHandle is used on the library already > loaded and won't load the library if it's not loaded. > > ?? Tests: tier1-2 passed. > > ? Thanks > ? Yumin From david.holmes at oracle.com Thu May 7 02:00:54 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 May 2020 12:00:54 +1000 Subject: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750 In-Reply-To: <2fe9ee54-da65-bf68-cd0a-279a7e002f5a@oracle.com> References: <2fe9ee54-da65-bf68-cd0a-279a7e002f5a@oracle.com> Message-ID: Hi Yumin, On 7/05/2020 11:01 am, Yumin Qi wrote: > Hi, > ? Please review the fix for > ? bug: https://bugs.openjdk.java.net/browse/JDK-8244495 > ? webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ > > Tests tools/jlink/JLinkTest.javaand tools/jlink/basic/BasicTest.java > failed after 8237750 pushed. The fix of 8237750 changed default behavior > of loading zip library to on-demand loading. jlink (and jimage) assumes > that zip library was loaded already, so call to FindEntry caused > ACCESS_VIOLATION on Windows. This is a Windows specific problem. > GetModuleHandle is used on the library already loaded and won't load the > library if it's not loaded. Fix looks good. I was wondering why we crashed when the method already potentially returns NULL but I see: 88 ZipInflateFully = (ZipInflateFully_t) findEntry("ZIP_InflateFully"); 89 assert(ZipInflateFully != NULL && "ZIP decompressor not found."); so in product builds we assume it is non-NULL and try to call it. And unfortunately IIUC JDK tier2 tests only run on product builds - hence why we never saw a simple and obvious assertion failure in the CI. Thanks, David ----- > ?? Tests: tier1-2 passed. > > ? Thanks > ? Yumin From daniel.daugherty at oracle.com Thu May 7 02:04:22 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 May 2020 22:04:22 -0400 Subject: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750 In-Reply-To: <2fe9ee54-da65-bf68-cd0a-279a7e002f5a@oracle.com> References: <2fe9ee54-da65-bf68-cd0a-279a7e002f5a@oracle.com> Message-ID: On 5/6/20 9:01 PM, Yumin Qi wrote: > Hi, > ? Please review the fix for > ? bug: https://bugs.openjdk.java.net/browse/JDK-8244495 > ? webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ src/java.base/share/native/libjimage/imageDecompressor.cpp ??? No comments. Thumbs up. I think this qualifies as a trivial fix so you can push this fix without waiting for 24 hours. Dan > > Tests tools/jlink/JLinkTest.javaand tools/jlink/basic/BasicTest.java > failed after 8237750 pushed. The fix of 8237750 changed default > behavior of loading zip library to on-demand loading. jlink (and > jimage) assumes that zip library was loaded already, so call to > FindEntry caused ACCESS_VIOLATION on Windows. This is a Windows > specific problem. GetModuleHandle is used on the library already > loaded and won't load the library if it's not loaded. > > ?? Tests: tier1-2 passed. > > ? Thanks > ? Yumin From david.holmes at oracle.com Thu May 7 02:15:02 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 May 2020 12:15:02 +1000 Subject: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750 In-Reply-To: References: <2fe9ee54-da65-bf68-cd0a-279a7e002f5a@oracle.com> Message-ID: <231e1e6d-3cb6-87c5-a5d9-355abfb00443@oracle.com> On 7/05/2020 12:04 pm, Daniel D. Daugherty wrote: > On 5/6/20 9:01 PM, Yumin Qi wrote: >> Hi, >> ? Please review the fix for >> ? bug: https://bugs.openjdk.java.net/browse/JDK-8244495 >> ? webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ > > src/java.base/share/native/libjimage/imageDecompressor.cpp > ??? No comments. > > Thumbs up. I think this qualifies as a trivial fix so you can push > this fix without waiting for 24 hours. Especially when it already has 4 reviewers :) David > Dan > > >> >> Tests tools/jlink/JLinkTest.javaand tools/jlink/basic/BasicTest.java >> failed after 8237750 pushed. The fix of 8237750 changed default >> behavior of loading zip library to on-demand loading. jlink (and >> jimage) assumes that zip library was loaded already, so call to >> FindEntry caused ACCESS_VIOLATION on Windows. This is a Windows >> specific problem. GetModuleHandle is used on the library already >> loaded and won't load the library if it's not loaded. >> >> ?? Tests: tier1-2 passed. >> >> ? Thanks >> ? Yumin > From yumin.qi at oracle.com Thu May 7 02:33:04 2020 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 6 May 2020 19:33:04 -0700 Subject: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750 In-Reply-To: <955183EB-FF98-4D31-97F0-FF77DF6A7E47@oracle.com> References: <2fe9ee54-da65-bf68-cd0a-279a7e002f5a@oracle.com> <955183EB-FF98-4D31-97F0-FF77DF6A7E47@oracle.com> Message-ID: Thanks for review! Yumin On 5/6/20 6:26 PM, Kim Barrett wrote: >> On May 6, 2020, at 9:01 PM, Yumin Qi wrote: >> >> Hi, >> Please review the fix for >> bug: https://bugs.openjdk.java.net/browse/JDK-8244495 >> webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ >> >> Tests tools/jlink/JLinkTest.javaand tools/jlink/basic/BasicTest.java failed after 8237750 pushed. The fix of 8237750 changed default behavior of loading zip library to on-demand loading. jlink (and jimage) assumes that zip library was loaded already, so call to FindEntry caused ACCESS_VIOLATION on Windows. This is a Windows specific problem. GetModuleHandle is used on the library already loaded and won't load the library if it's not loaded. >> >> Tests: tier1-2 passed. >> >> Thanks >> Yumin > Looks good. > From yumin.qi at oracle.com Thu May 7 02:34:47 2020 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 6 May 2020 19:34:47 -0700 Subject: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750 In-Reply-To: <231e1e6d-3cb6-87c5-a5d9-355abfb00443@oracle.com> References: <2fe9ee54-da65-bf68-cd0a-279a7e002f5a@oracle.com> <231e1e6d-3cb6-87c5-a5d9-355abfb00443@oracle.com> Message-ID: <18c8ebae-f7c8-6bd2-db60-31741dfd1043@oracle.com> Thanks for review, yes, enough for a push! Yumin On 5/6/20 7:15 PM, David Holmes wrote: > On 7/05/2020 12:04 pm, Daniel D. Daugherty wrote: >> On 5/6/20 9:01 PM, Yumin Qi wrote: >>> Hi, >>> ? Please review the fix for >>> ? bug: https://bugs.openjdk.java.net/browse/JDK-8244495 >>> ? webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ >> >> src/java.base/share/native/libjimage/imageDecompressor.cpp >> ???? No comments. >> >> Thumbs up. I think this qualifies as a trivial fix so you can push >> this fix without waiting for 24 hours. > > Especially when it already has 4 reviewers :) > > David > >> Dan >> >> >>> >>> Tests tools/jlink/JLinkTest.javaand tools/jlink/basic/BasicTest.java >>> failed after 8237750 pushed. The fix of 8237750 changed default >>> behavior of loading zip library to on-demand loading. jlink (and >>> jimage) assumes that zip library was loaded already, so call to >>> FindEntry caused ACCESS_VIOLATION on Windows. This is a Windows >>> specific problem. GetModuleHandle is used on the library already >>> loaded and won't load the library if it's not loaded. >>> >>> ?? Tests: tier1-2 passed. >>> >>> ? Thanks >>> ? Yumin >> From yumin.qi at oracle.com Thu May 7 02:34:11 2020 From: yumin.qi at oracle.com (Yumin Qi) Date: Wed, 6 May 2020 19:34:11 -0700 Subject: RFR(XS): 8244495: Some jlink tests crash on Windows after JDK-8237750 In-Reply-To: <8c7bba71-764e-00c4-8a99-b4ace4db05c1@oracle.com> References: <2fe9ee54-da65-bf68-cd0a-279a7e002f5a@oracle.com> <8c7bba71-764e-00c4-8a99-b4ace4db05c1@oracle.com> Message-ID: Thanks Mandy for review! Yumin On 5/6/20 6:50 PM, Mandy Chung wrote: > This looks okay to me. > > Mandy > > On 5/6/20 6:01 PM, Yumin Qi wrote: >> Hi, >> ? Please review the fix for >> ? bug: https://bugs.openjdk.java.net/browse/JDK-8244495 >> ? webrev: http://cr.openjdk.java.net/~minqi/8244495/webrev/ >> >> Tests tools/jlink/JLinkTest.javaand tools/jlink/basic/BasicTest.java >> failed after 8237750 pushed. The fix of 8237750 changed default >> behavior of loading zip library to on-demand loading. jlink (and >> jimage) assumes that zip library was loaded already, so call to >> FindEntry caused ACCESS_VIOLATION on Windows. This is a Windows >> specific problem. GetModuleHandle is used on the library already >> loaded and won't load the library if it's not loaded. >> >> ?? Tests: tier1-2 passed. >> >> ? Thanks >> ? Yumin > From david.holmes at oracle.com Thu May 7 02:43:01 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 May 2020 12:43:01 +1000 Subject: os::javaTimeSystemUTC to call nanosecond precision OS API, so Clock.systemUTC() can give nanosecond precision UTC In-Reply-To: References: <0c697d39-0e62-ccf2-bf81-ed4110f87fda@oracle.com> <9353c814-650c-c9f9-708e-c1a4d3fdcdf8@oracle.com> <9d13d404-ccf3-153c-90ea-9dce1c530c47@oracle.com> Message-ID: <180c73a1-02e0-0a33-e086-2f59468f156f@oracle.com> Hi Mark, On 6/05/2020 1:50 am, Mark Kralj-Taylor wrote: > Hi David, > > So the issue is that while glibc 2.12 (in OEL6.4) supports > clock_gettime(CLOCK_REALTIME) it requires a runtime dependency on > librt.so, which is an optional runtime dependency, hence the dynamic > lookup you mention. The complexity of dynamic lookup makes this > enhancement unattractive. But when openjdk updates to require glibc >> =2.17 it would be trivial, because clock_gettime() was moved into the > core libc.so. It would be good to be able to remove the need to link librt. In general we try to avoid needing to track libc/glibc changes in detail, and which versions on which Linux distributions contain which libc/glibc version - and even whether they are necessarily equivalent ie. are all glibc 2.17 the same? > With glibc >= 2.17 there would still need to be a call to > clock_gettime() to see if the optional CLOCK_MONOTONIC is supported, > whereas CLOCK_REALTIME is required by the Posix spec and header docs. I would have hoped/expected that glibc 2.17 either did or did not support CLOCK_MONOTONIC without any need to do a dynamic runtime check. :( You seem to be suggesting that two Linux distributions claiming to have glibc 2.17 may have different support for CLOCK_MONOTONIC - is that really the case? > --- > This leads me to ask a different question: > > What is the openjdk process for reviewing and updating its minimum dependencies? > - When are dependencies reviewed? > - What is the mailgroup to look at? (please let me know if there is a > better place to ask this question) > > The info I found was last updated for JDK 13: > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms So there are two issues: build platforms and runtime platforms. The minimum build platform is generally determined by the Build group (build-dev at openjdk.java.net) and is generally driven by the regular toolchain upgrade process - ie if we want to support gcc X.Y and it no longer runs on SomeLinux A.B then we have to decide if it is okay drop that support and bump the minimum SomeLinux version. That may depend on the other OpenJDK members and what they need to support in their build farms etc. The wiki above should be tracking that but the build team (aka Magnus and Erik) are busy folk and it can fall behind. This is further complicated by the fact that we may use a devkit for an older OS version, but run it on a later one. For runtime platforms there is no official OpenJDK minimum supported platform as far as I am aware. Obviously given the source code + toolchain there is an implied minimum version, you just won't necessarily find it clearly documented at any given point in time - nor know when it suddenly changes. My understanding is that each OpenJDK distributor determines their own minimum supported OS versions - potentially maintaining custom patches to achieve that. Any OpenJDK change that implicitly changes those minimum versions should result in feedback that then influences whether such a change should be kept or reverted. And of course there is a difference between an officially supported OS version and one where it happens to still run okay. For example, for a long time Windows XP was not officially supported but we actively tried to not break it. > - Glibc 2.12 was released in 2010 and glibc 2.17 in 2012 > - The current openjdk LTS release is Java SE 11 in September 2018, > supported through to October 2024 (extended support to September > 2026): https://en.wikipedia.org/wiki/Java_version_history). > - Oracle Enterprise Linux 7.0 released in 2014 included glibc 2.17 > > These dates suggest an update of openjdk's glibc dependency might be due. > But I guess the driving factor is how the timelines of openjdk LTS > release support fits with those of Oracle Enterprise Linux versions. And with other OpenJDK distributors/vendors. Here's the information for the Oracle JDK 14: https://www.oracle.com/java/technologies/javase/products-doc-jdk14certconfig.html > --- > FYI some observations on my experience of building and testing openjdk. > > I installed OEL6.4, but found it very tricky to build a `real` openjdk > distribution on a current Ubuntu that would run with all features on > OEL6.4. Right that is not a supported build platform. > - The base openjdk build was easy to use, but it built a JDK with elf > dependencies based on my OS, so of course would not run on OLE6. > - The openjdk make/devkit infrastructure didn't work for me to make an > OEL6 build, after lots of attempts (including running in chroot or > docker isolation). I'm sure it works reliably, provided you have the > correct OS setup. But its not easy for an outsider to replicate that. > - The AdoptOpenJDK Docker build was super easy to use, and I liked > that it used Docker to use a reproducible and fully scripted OS build > environment. https://github.com/AdoptOpenJDK/openjdk-build > - But AdoptOpenJDK Docker build doesn't support building and using an > OEL6 devkit. AdoptOpenJDK build targets RHEL 7.4+: > https://github.com/AdoptOpenJDK/openjdk-build/wiki/%5BWIP%5D-Minimum-OS-levels Yes I think 7.4 is current minimum build platform. > openjdk's devkit infra must pre-date the rise of Docker, and fully > reproducible build environments becoming the norm. Have they become the norm? :) I don't play in that space so have no idea. But yes this all pre-dates Docker et al by a very long time. Cheers, David ----- > Maybe one day there will be time to use Docker or similar to simplify > the openjdk build, and making it easy for anyone to reproduce. > > As with using newer glibc features (glibc 2.17 vs 2.12), its likely to > be drastically simpler when openjdk is able to update dependencies to > newer OS versions. Especially if openjdk can be built on its minimum > required per-platform OS version in a (Docker) container. > > Mark > > On Tue, 14 Apr 2020 at 23:34, David Holmes wrote: >> >> Hi Mark, >> >> On 15/04/2020 3:09 am, Mark Kralj-Taylor wrote: >>> David, Daniel, >>> What is the oldest (lowest) version of Linux and glibc for openjdk 15? >> >> I'm not clear on that. >> >>> The availability of clock_gettime(CLOCK_REALTIME) on the oldest >>> Linux/glibc supported by openjdk 15 is likely to be the deciding >>> factor on if Hotspot Linux code can call >>> clock_gettime(CLOCK_REALTIME). >>> >>> doc/building.md suggests minimum Linux is Oracle Enterprise Linux 6.4 >>> (i.e. RHEL 6.4). >>> Which I think uses glibc 2.12-1.107 (based on >>> https://yum.oracle.com/repo/OracleLinux/OL6/4/base/x86_64/index_src.html). >>> Searching for glibc sources it looks like this supports >>> clock_gettime(CLOCK_REALTIME). >>> >>> The wording of Linux docs suggests that clock_gettime(CLOCK_REALTIME) >>> should be supported if the clock_gettime() API exists. But other clock >>> sources are not mandatory. So CLOCK_REALTIME should be available even >>> if CLOCK_MONOTONIC is not. >>> - See: https://linux.die.net/man/2/clock_gettime. >>> - Also "POSIX.1-2008 marks gettimeofday() as obsolete, recommending >>> the use of clock_gettime(2) instead." from: >>> https://linux.die.net/man/2/gettimeofday >>> >>> Note that Hotspot os_posix.cpp checks for non-error return from >>> clock_gettime(CLOCK_MONOTONIC) to guard setting the _clock_gettime >>> function pointer. Which was why in the patch I called clock_gettime >>> directly for Linux specific os_linux.cpp (a subset of Posix OS-s). >>> >>> Also os_linux.cpp has: >>> #ifndef SUPPORTS_CLOCK_MONOTONIC >>> #error "Build platform doesn't support clock_gettime and related functionality" >>> #endif >>> Which made me wonder if openjdk might require CLOCK_MONOTONIC - which >>> would mean clock_gettime(CLOCK_REALTIME) is supported. >> >> So we require that the build platform supports CLOCK_MONOTONIC and >> clock_gettime, but not that the runtime platform supports >> CLOCK_MONOTONIC (without which we don't/didn't need clock_gettime(). >> >> So we can switch to using clock_gettime(CLOCK_REALTIME) at build time >> with no problem. >> >> We can probably also require clock_gettime(CLOCK_REALTIME) at runtime, >> but we need to double-check that. I recall encountering a platform where >> clock_gettime was not available, but I can't recall if it was mainstream >> or on one of the other OpenJDK projects - nor do I recall exactly how >> long ago this was. Keeping the dynamic lookup of clock_gettime would be >> a conservative approach here - but we would need to make the distinction >> between the ability to use CLOCK_REALTIME and CLOCK_MONOTONIC. >> >> Or someone puts in the time and effort to establish exactly what the >> kernel and glibc dependencies are and whether we can just rely on >> everything existing on all platforms we care about. I don't have time to >> do that nor validate the results if someone else does it. >> >> Cheers, >> David >> >>> Mark >>> >>> On Tue, 14 Apr 2020 at 18:04, Mark Kralj-Taylor wrote: >>>> >>>> Daniel, >>>> Yes System.currentTimeMillis() and Clock.systemUTC() must be >>>> consistent, so should use the same OS time source (as shown by ). >>>> >>>> The patch to os_linux.cpp ensures this by calling the same Linux API: >>>> clock_gettime(CLOCK_REALTIME) for both, from: >>>> - os::javaTimeMillis() that backs System.currentTimeMillis() >>>> - os::javaTimeSystemUTC() that backs Clock.systemUTC() >>>> >>>> Looking at Linux / glibc source I think that gettimeofday() and >>>> clock_gettime(CLOCK_REALTIME) are supposed to be the same clocksource. >>>> i.e. that given by: cat >>>> /sys/devices/system/clocksource/clocksource0/current_clocksource >>>> >>>> Mark >>>> >>>> On Tue, 14 Apr 2020 at 13:29, Daniel Fuchs wrote: >>>>> >>>>> Hi, >>>>> >>>>> On 11/04/2020 00:53, David Holmes wrote: >>>>>> Update: >>>>>>> It's a holiday weekend so I can't dig into this right now but we tried >>>>>>> using a high-precision clock source for systemUTC() in the past but it >>>>>>> didn't work because systemUTC() and currentTimeMillis() have to use >>>>>>> the same time base, and currentTimeMillis() has to use gettimeofday(). >>>>>>> I thought this cross-dependency was documented somewhere but can't >>>>>>> find it right now. If gettimeofday and clock_gettime(CLOCK_REALTIME) >>>>>>> actually have the same time characteristics wrt. wall-clock time then >>>>>>> changing both as suggested may indeed work. >>>>> >>>>> Just to emphasize David's comment: System::currentTimeMillis() and >>>>> Clock::systemUTC() should use the same time source: if they don't - then >>>>> some tests will fail, and because it can be tricky to assert things >>>>> in tests, they might (and probably will) fail only intermittently. >>>>> >>>>> I'm probably the culprit here, I added those tests when I upgraded >>>>> Clock::systemUTC() to report sub millisecond granularity [1] - as was >>>>> available in the underlying clock that System::currentTimeMillis() >>>>> already used. >>>>> >>>>> However, I think I would be disturbed if System::currentTimeMillis() >>>>> and Clock::systemUTC() were using different clocks and could >>>>> report a different notion of time (by drifting away from each other). >>>>> >>>>> best regards, >>>>> >>>>> -- daniel >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8068730 From mikael.vidstedt at oracle.com Thu May 7 04:38:16 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 6 May 2020 21:38:16 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> Message-ID: <6854A858-ACA9-4572-868B-3745A2E30332@oracle.com> Alan, thank you for the review! New webrev coming. Meanwhile comments inline.. > On May 4, 2020, at 1:49 AM, Alan Bateman wrote: > > On 04/05/2020 06:12, Mikael Vidstedt wrote: >> Please review this change which implements part of JEP 381: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/corelibs/open/webrev/ >> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >> >> >> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >> > I took a pass over the changes. I agree its a bit tedious. I'm sure there will be a few follow up issues as there are opportunities for cleanup in several areas. Just a few comments/questions from a first pass. > > ExtendedSocketOption.SO_FLOW_SLA is the Solaris specific socket option that was terminally deprecated in 14. The patch removes the implementation but leave the API (SO_FLOW_SA and jdk.net.SocketFlow). Do you want a someone to take a follow-on issue to remove the API? I would very much appreciate if somebody could take that on! > ResolverConfigurationImpl.localDomain0 can be removed. Fixed. > The comment on mcast_join_leave in PlainDatagramSocketImpl.c has a residual reference to Solaris. Fixed. > JISAutoDetect - might be simpler to just initialize EUCJPName to "EUC_JP?. I was going back and forth on this one - in a way preserving the method was nicely symmetric with getSJISName(), but in the end I removed the method in favor of initializing the variable directly. > Socket.setTrafficClass(int) swallows exceptions to workaround strange behaviour on Solaris. Tracked as JDK-8221487 so okay to leave it to that issue if you want. There is also cruft in the old plain SocketImpl that to work around eagerness to report "connection reset errors - I think we should just leave that because the old socket impl is not used by default and will be removed at some point. Anything I can do to keep the complexity of this patch down is appreciated. I have *not* changed anything, let me know if you want me to do something with this. Cheers, Mikael From mikael.vidstedt at oracle.com Thu May 7 04:39:47 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 6 May 2020 21:39:47 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: <1BA86CD8-2322-4D68-ADAE-D95311FEDF23@oracle.com> References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> <1BA86CD8-2322-4D68-ADAE-D95311FEDF23@oracle.com> Message-ID: <369FDCBB-F56F-4840-8808-3E3F2CF05768@oracle.com> Thank you for reviewing, Max! Cheers, Mikael > On May 4, 2020, at 7:22 AM, Weijun Wang wrote: > > There are several security-related files (name.contains("security")) and they all look fine. > > --Max > > >> On May 4, 2020, at 1:12 PM, Mikael Vidstedt wrote: >> >> >> Please review this change which implements part of JEP 381: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/corelibs/open/webrev/ >> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >> >> >> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >> >> >> Background: >> >> Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. >> >> For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. >> >> In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. >> >> >> Testing: >> >> A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. >> >> Cheers, >> Mikael >> >> [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ >> > From mikael.vidstedt at oracle.com Thu May 7 04:44:49 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 6 May 2020 21:44:49 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> Message-ID: <3E46F5BA-F52A-417D-9B10-C2F371F9732D@oracle.com> > On May 4, 2020, at 2:33 PM, Brent Christian wrote: > > Hi, > > Looks fine to me. I have just one minor observation: > > src/java.base/share/native/libjli/emessages.h > > *** 92,102 **** > #define JRE_ERROR5 "Error: Failed to start a %d-bit JVM process from a %d-bit JVM." > ! #define JRE_ERROR6 "Error: Verify all necessary Java SE components have been installed.\n(Solaris SPARC 64-bit components must be installed after 32-bit components.)" > #define JRE_ERROR7 "Error: Either 64-bit processes are not supported by this platform\nor the 64-bit components have not been installed." > --- 91,101 ---- > #define JRE_ERROR5 "Error: Failed to start a %d-bit JVM process from a %d-bit JVM." > ! #define JRE_ERROR6 "Error: Verify all necessary Java SE components have been installed.\n" > #define JRE_ERROR7 "Error: Either 64-bit processes are not supported by this platform\nor the 64-bit components have not been installed." > > > The other error messages do not include a trailing newline. Nice catch! Fixed in the upcoming webrev. Thank you for this review - and the pre-review before it! :) Cheers, Mikael From mikael.vidstedt at oracle.com Thu May 7 04:43:56 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 6 May 2020 21:43:56 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: <26996994-3e08-c312-c1fa-9b2ffd5b5d95@oracle.com> References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> <26996994-3e08-c312-c1fa-9b2ffd5b5d95@oracle.com> Message-ID: <3E353A59-B7E2-4924-9A94-25C2C42ACA2C@oracle.com> > On May 4, 2020, at 9:27 AM, naoto.sato at oracle.com wrote: > > Hi Mikael, > > I took a look at i18n related files. It looks good overall. > > One nit in java/nio/charset/Charset/DefaultCharsetTest.java: If the test is only applicable to linux (@requires os.family == "linux" in jtreg tag after the change), the condition isLinux() is no longer needed at line 73. Good catch! Fixed in the upcoming webrev. Thank you for the review! Cheers, Mikael From mikael.vidstedt at oracle.com Thu May 7 04:45:34 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 6 May 2020 21:45:34 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: <779ec619-f61c-be8a-793d-15777e783e8e@oracle.com> References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> <779ec619-f61c-be8a-793d-15777e783e8e@oracle.com> Message-ID: > On May 5, 2020, at 5:42 AM, Daniel Fuchs wrote: > > Hi Mikael, > > I spotted another place where a residual reference to Solaris > remains in a comment: > src/java.base/unix/native/libnet/PlainSocketImpl.c > > 857 #if defined(_AIX) > 858 if (errno == EINVAL) { > 859 // On Solaris setsockopt will set errno to EINVAL if the socket > 860 // is closed. The default error message is then confusing Fixed in the upcoming webrev! > Otherwise I had a look at the networking related files and > the changes seemed reasonable to me. Thanks a lot for the review! Cheers, Mikael From mikael.vidstedt at oracle.com Thu May 7 04:43:17 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 6 May 2020 21:43:17 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: <513265a5-8a7d-d2b9-9cfe-adcf87cca390@oracle.com> References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> <513265a5-8a7d-d2b9-9cfe-adcf87cca390@oracle.com> Message-ID: I have always wondered what ?solinux? is supposed to mean - though not enough to actually ask anybody :) I?ll file a follow-up enhancement to cover renaming the files. Thank you for the review! Cheers, Mikael > On May 4, 2020, at 7:59 AM, Roger Riggs wrote: > > Hi Michael, > > Looks good. > > Maybe just a future cleanup to rename files, since the "...so..." is refering to solaris. > > src/java.base/unix/native/libjli/java_md_solinux.h > src/java.base/unix/native/libjli/java_md_solinux.h > > Regards, Roger > > > On 5/4/20 4:49 AM, Alan Bateman wrote: >> On 04/05/2020 06:12, Mikael Vidstedt wrote: >>> Please review this change which implements part of JEP 381: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 >>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/corelibs/open/webrev/ >>> JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 >>> >>> >>> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >>> >> I took a pass over the changes. I agree its a bit tedious. I'm sure there will be a few follow up issues as there are opportunities for cleanup in several areas. Just a few comments/questions from a first pass. >> >> ExtendedSocketOption.SO_FLOW_SLA is the Solaris specific socket option that was terminally deprecated in 14. The patch removes the implementation but leave the API (SO_FLOW_SA and jdk.net.SocketFlow). Do you want a someone to take a follow-on issue to remove the API? >> >> ResolverConfigurationImpl.localDomain0 can be removed. >> >> The comment on mcast_join_leave in PlainDatagramSocketImpl.c has a residual reference to Solaris. >> >> JISAutoDetect - might be simpler to just initialize EUCJPName to "EUC_JP". >> >> Socket.setTrafficClass(int) swallows exceptions to workaround strange behaviour on Solaris. Tracked as JDK-8221487 so okay to leave it to that issue if you want. There is also cruft in the old plain SocketImpl that to work around eagerness to report "connection reset errors - I think we should just leave that because the old socket impl is not used by default and will be removed at some point. >> >> -Alan. > From mikael.vidstedt at oracle.com Thu May 7 04:56:16 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 6 May 2020 21:56:16 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> Message-ID: <3A65A5FD-BA6B-41C6-BF85-27746EF3E1A0@oracle.com> New webrev addressing the feedback/comments I have received: webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/corelibs/open/webrev/ incremental: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.01/corelibs.incr/open/webrev/ I hope I caught everything. Some outstanding items: * File follow-up enhancement for the removal of SO_FLOW_SA and jdk.net.SocketFlow Would appreciate if somebody could help file this for me. * File follow-up enhancement for renaming the ?solinux? files * Get confirmation from Alan that the Socket.setTrafficClass(int) and SocketImpl stuff is good as-is Cheers, Mikael > On May 3, 2020, at 10:12 PM, Mikael Vidstedt wrote: > > > Please review this change which implements part of JEP 381: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8244224 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/corelibs/open/webrev/ > JEP: https://bugs.openjdk.java.net/browse/JDK-8241787 > > > Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! > > > Background: > > Because of the size of the total patch and wide range of areas touched, this patch is one out of in total six partial patches which together make up the necessary changes to remove the Solaris and SPARC ports. The other patches are being sent out for review to mailing lists appropriate for the respective areas the touch. An email will be sent to jdk-dev summarizing all the patches/reviews. To be clear: this patch is *not* in itself complete and stand-alone - all of the (six) patches are needed to form a complete patch. Some changes in this patch may look wrong or incomplete unless also looking at the corresponding changes in other areas. > > For convenience, I?m including a link below[1] to the full webrev, but in case you have comments on changes in other areas, outside of the files included in this thread, please provide those comments directly in the thread on the appropriate mailing list for that area if possible. > > In case it helps, the changes were effectively produced by searching for and updating any code mentioning ?solaris", ?sparc?, ?solstudio?, ?sunos?, etc. More information about the areas impacted can be found in the JEP itself. > > > Testing: > > A slightly earlier version of this change successfully passed tier1-8, as well as client tier1-2. Additional testing will be done after the first round of reviews has been completed. > > Cheers, > Mikael > > [1] http://cr.openjdk.java.net/~mikael/webrevs/8244224/webrev.00/all/open/webrev/ > From matthias.baesken at sap.com Thu May 7 05:16:09 2020 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 7 May 2020 05:16:09 +0000 Subject: RFR [XXS] : 8244183: linker error jpackageapplauncher on Windows 32bit In-Reply-To: References: Message-ID: Sorry , there was still an issue with rev. 0 , I had to adjust the signature of wmain As well to get around the link errors . http://cr.openjdk.java.net/~mbaesken/webrevs/8244183.1/ This builds on both windows 64 bit and 32 bit . Best regards, Matthias From: Thomas St?fe Sent: Freitag, 1. Mai 2020 08:20 To: Baesken, Matthias Cc: core-libs-dev ; Doerr, Martin Subject: Re: RFR [XXS] : 8244183: linker error jpackageapplauncher on Windows 32bit You have enough reviews now, but thanks for fixing this. ..Thomas On Thu, Apr 30, 2020 at 4:15 PM Baesken, Matthias > wrote: Hello, please look into this small fix for a link error we faced on Windows 32bit. Currently we run into this link error : jpackageapplauncher * For target support_native_jdk.incubator.jpackage_jpackageapplauncher_BUILD_JPACKAGE_APPLAUNCHEREXE_link: LINK : fatal error LNK1561: entry point must be defined looks like the wWinMain signature in src\jdk.incubator.jpackage\windows\native\applauncher\WinLauncher.cpp has to be adjusted. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8244183 http://cr.openjdk.java.net/~mbaesken/webrevs/8244183.0/ Thanks, Matthias From huizhe.wang at oracle.com Thu May 7 06:32:20 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 6 May 2020 23:32:20 -0700 Subject: [15]: RFR: 8244245: localizedBy() should override localized values with default values In-Reply-To: References: Message-ID: <2b681167-85d0-631f-60e2-641a28a0a0a0@oracle.com> Hi Naoto, The Javadoc states: ??? If the locale contains the "ca" (calendar), "nu" (numbering system), "rg" (region override), and/or "tz" (timezone) Unicode extensions, the chronology, numbering system and/or the zone are overridden. If you remove the two statements that check whether the specified locale contains "ca" or "nu", would you need to update the Javadoc as well? Best, Joe On 5/6/2020 1:44 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8244245 > > The CSR and proposed changeset are located at: > > https://bugs.openjdk.java.net/browse/JDK-8244246 > https://cr.openjdk.java.net/~naoto/8244245/webrev.00/ > > This stems from the closed issue > (https://bugs.openjdk.java.net/browse/JDK-8243162), and the rationale > for this fix is discussed there. > > Naoto > From Alan.Bateman at oracle.com Thu May 7 06:41:44 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 May 2020 07:41:44 +0100 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: <3A65A5FD-BA6B-41C6-BF85-27746EF3E1A0@oracle.com> References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> <3A65A5FD-BA6B-41C6-BF85-27746EF3E1A0@oracle.com> Message-ID: On 07/05/2020 05:56, Mikael Vidstedt wrote: > : > > * File follow-up enhancement for the removal of SO_FLOW_SA and jdk.net.SocketFlow I've created JDK-8244582 to track this, we should try to this in the same release as JEP 381. > : > > > * Get confirmation from Alan that the Socket.setTrafficClass(int) and SocketImpl stuff is good as-is > JDK-8221487 tracks the Socket.setTrafficClass issue. I didn't create an issue to mop up issues in the old SocketImpl as it is not used (at least not by default) since JDK 13. The intention is to completely remove the old SocketImpl implementation, don't know which release yet but it's hardly seems worth spending time doing cleanup on this code. I've no doubt there will be cleanup in many areas of the JDK code after JEP 381 is pushed. -Alan. From scolebourne at joda.org Thu May 7 08:14:25 2020 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 7 May 2020 09:14:25 +0100 Subject: [15]: RFR: 8244245: localizedBy() should override localized values with default values In-Reply-To: <2b681167-85d0-631f-60e2-641a28a0a0a0@oracle.com> References: <2b681167-85d0-631f-60e2-641a28a0a0a0@oracle.com> Message-ID: On Thu, 7 May 2020 at 07:38, Joe Wang wrote: > The Javadoc states: > If the locale contains the "ca" (calendar), "nu" (numbering > system), "rg" (region override), and/or "tz" (timezone) Unicode > extensions, the chronology, numbering system and/or the zone are overridden. > > If you remove the two statements that check whether the specified locale > contains "ca" or "nu", would you need to update the Javadoc as well? Those things are checked by the methods Chronology.of(locale) and DecimalStyle.of(locale), so although indirect, I think the Javadoc is fine. Stephen From xu.y.yin at oracle.com Thu May 7 09:24:38 2020 From: xu.y.yin at oracle.com (Chris Yin) Date: Thu, 7 May 2020 17:24:38 +0800 Subject: RFR [LDAP]: 8062947: Fix exception message to correctly represent LDAP connection failure In-Reply-To: <42053431-7ee1-3d3d-a270-942701d30582@oracle.com> References: <8cfc457f-ed92-535e-5798-1a6f586b02c0@oracle.com> <42053431-7ee1-3d3d-a270-942701d30582@oracle.com> Message-ID: <6174A2EF-94FB-4DFC-AA0A-90AF9CFA8613@oracle.com> +1 Thanks, Chris > On 6 May 2020, at 6:35 PM, Daniel Fuchs wrote: > > Hi Aleksei, > > Looks good to me. > > best regards, > > -- daniel > > On 05/05/2020 18:23, Aleks Efimov wrote: >> "LDAP response read timed out, timeout used:-1ms.": >> https://bugs.openjdk.java.net/browse/JDK-8062947 >> The following fix tries to tackle this issue: >> http://cr.openjdk.java.net/~aefimov/8062947/00 > From vyommani at gmail.com Thu May 7 10:03:23 2020 From: vyommani at gmail.com (Vyom Tiwari) Date: Thu, 7 May 2020 15:33:23 +0530 Subject: RFR [LDAP]: 8062947: Fix exception message to correctly represent LDAP connection failure In-Reply-To: <6174A2EF-94FB-4DFC-AA0A-90AF9CFA8613@oracle.com> References: <8cfc457f-ed92-535e-5798-1a6f586b02c0@oracle.com> <42053431-7ee1-3d3d-a270-942701d30582@oracle.com> <6174A2EF-94FB-4DFC-AA0A-90AF9CFA8613@oracle.com> Message-ID: LGTM as well. Vyom On Thu, May 7, 2020 at 3:01 PM Chris Yin wrote: > +1 > > Thanks, > Chris > > > On 6 May 2020, at 6:35 PM, Daniel Fuchs wrote: > > > > Hi Aleksei, > > > > Looks good to me. > > > > best regards, > > > > -- daniel > > > > On 05/05/2020 18:23, Aleks Efimov wrote: > >> "LDAP response read timed out, timeout used:-1ms.": > >> https://bugs.openjdk.java.net/browse/JDK-8062947 > >> The following fix tries to tackle this issue: > >> http://cr.openjdk.java.net/~aefimov/8062947/00 > > > > -- Thanks, Vyom From daniel.fuchs at oracle.com Thu May 7 10:10:59 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 7 May 2020 11:10:59 +0100 Subject: RFR: 8237834: com/sun/jndi/ldap/LdapDnsProviderTest.java failing with LDAP response read timeout In-Reply-To: References: Message-ID: <3580997f-4e06-6634-58f1-b61572d93d26@oracle.com> Hi Aleksei, I agree with the general idea. However, the method: 215 private static int generateUnseenPort() { 216 int port; 217 do { 218 port = 1111 + RND.nextInt(1000); 219 } while (SEEN_PORTS.contains(port)); 220 SEEN_PORTS.add(port); 221 return port; 222 } might never return - if none of the port in the range [1111, 2111] are free. Arguably, the test will have failed in timeout before that. But maybe an assertion error should be thrown if that happens. best regards, -- daniel On 07/05/2020 00:52, Aleks Efimov wrote: > Hi, > > LdapDnsProviderTest test expects to have no services running on 1111 > port on test machine. That could cause it to fail intermittently due to > unexpected exception message thrown by LDAP client, i.e. timeout or > disconnect instead of expected connection refusal. > > The proposed fix tries to make test more stable ('intermittent' key was > still added) by running test cases with non-default port multiple times > by trying to use different random port numbers ('randomness' key was > added) for each run. > > Webrev: http://cr.openjdk.java.net/~aefimov/8237834/00/index.html > > JBS: https://bugs.openjdk.java.net/browse/JDK-8237834 > > Test was not observed to fail for over 300 iterations. > > With Best Regards, > Aleksei > From info at j-kuhn.de Thu May 7 11:37:12 2020 From: info at j-kuhn.de (Johannes Kuhn) Date: Thu, 7 May 2020 13:37:12 +0200 Subject: JDK-8226810: An other case and a small change suggestion Message-ID: <2c1ff9d3-a9a6-800d-bb55-e771f22a3807@j-kuhn.de> I just saw a question on StackOverflow [1] which reports to have the same issue as in JDK-8226810 [2] - with the same stack trace. While I could not reproduce the issue, I tried to understand which code path could lead to that outcome. While doing so I did come across getEncodingInternal in java_props_md.c [3] The path when GetLocaleInfo in line 72 fails just sets the codepage to 1252. The following switch doesn't have a branch for codepage 1252, so the default branch is used. The first two elements of the char array are set to "Cp", while the rest of that char array is still uninitialized. This (partially) uninitialized array is then returned. This seems wrong. I would therefore either change codepage to 0 (resulting in a default encoding of UTF-8) or also copy the "Cp1252" to the char buffer. ---- (More when I follow this code path): In InitializeEncoding [4] this invalid encoding is then set to jnuEncoding, and fastEncoding to NO_FAST_ENCODING. A call to JNU_NewStringPlatform will then result in a call to newSizedStringJava [5], where jnuEncodingSupported is called. This calls java.nio.charset.Charset.isSupported(jnuEncoding) and caches the result - I assume it returns false. Or throws. This means new String(byte[]) is called. Here comes the puzzler: java.lang.StringCoding.decode(byte[],int,int) calls Charset.getDefaultCharset() as first action. - and does not fall back to iso-8859-1 as the comment in newSizedStringJava suggests. Charset.getDefaultCharset() then tries to read the properties - which are currently in the process to be initialized - and fails with a NullPointerException. ---- In the end, I don't know what causes the bug, or how I can replicate it. I think I did find a likely suspect. I therefore would like to propose the following patch: diff --git a/src/java.base/windows/native/libjava/java_props_md.c b/src/java.base/windows/native/libjava/java_props_md.c --- a/src/java.base/windows/native/libjava/java_props_md.c +++ b/src/java.base/windows/native/libjava/java_props_md.c @@ -73,6 +73,7 @@ ?????????????????????? LOCALE_IDEFAULTANSICODEPAGE, ?????????????????????? ret+2, 14) == 0) { ???????? codepage = 1252; +??????? strcpy(ret, "Cp1252"); ???? } else { ???????? codepage = atoi(ret+2); ???? } Because this path is not taken on my system, I can't test if this change affects anything. Tests run as before. But I still think that it is The Right Thing To Do. Maybe logging the GetLastError too - but it's very early in the VM's startup. I did consider calling GetLocaleInfo twice - with NULL as buffer and 0 as length - which returns the required size of the buffer. But that would have some implication on the startup time. I could also check GetLastError and try again with a bigger buffer - but then the question arises: Can the VM handle such a charset? Johannes [1]: https://stackoverflow.com/questions/61650372/jdk-14-0-1-error-occurred-during-initialization-of-vm-java-lang-nullpointerexcep [2]: https://bugs.openjdk.java.net/browse/JDK-8226810 [3]: https://hg.openjdk.java.net/jdk/jdk/file/d40d865753fb/src/java.base/windows/native/libjava/java_props_md.c#l64 [4]: https://hg.openjdk.java.net/jdk/jdk/file/d40d865753fb/src/java.base/share/native/libjava/jni_util.c#l773 [5]: https://hg.openjdk.java.net/jdk/jdk/file/d40d865753fb/src/java.base/share/native/libjava/jni_util.c#l661 From Alan.Bateman at oracle.com Thu May 7 12:50:57 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 7 May 2020 13:50:57 +0100 Subject: JDK-8226810: An other case and a small change suggestion In-Reply-To: <2c1ff9d3-a9a6-800d-bb55-e771f22a3807@j-kuhn.de> References: <2c1ff9d3-a9a6-800d-bb55-e771f22a3807@j-kuhn.de> Message-ID: On 07/05/2020 12:37, Johannes Kuhn wrote: > : > > In the end, I don't know what causes the bug, or how I can replicate it. > I think I did find a likely suspect. Good sleuthing. I don't what the conditions are for GetLocaleInfo to fail but it does look like that would return possibly non-terminated garbage starting with "CP" so we should at least fix that. The issue in JDK-8226810 might be something else. One of the submitters to that issue did engage and provided enough information to learn that the locale is zh_CN and also reported that it was failing for GB18030. GB18030 is not in java.base so that at least explained that report. -Alan From aleksej.efimov at oracle.com Thu May 7 13:57:33 2020 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Thu, 7 May 2020 14:57:33 +0100 Subject: RFR: 8237834: com/sun/jndi/ldap/LdapDnsProviderTest.java failing with LDAP response read timeout In-Reply-To: <3580997f-4e06-6634-58f1-b61572d93d26@oracle.com> References: <3580997f-4e06-6634-58f1-b61572d93d26@oracle.com> Message-ID: <996e514d-7e7f-8b15-92c2-229fa1a2549b@oracle.com> Hi Daniel, As a follow-up to our off-list discussion, I've updated the generateUnseenPort method: a) Added comment to be more specific about the number of times it is called b) The port range has been extended to [1111, PortConfig.getUpper()) Webrev with new version: http://cr.openjdk.java.net/~aefimov/8237834/01 With Best Regards, Aleksei On 07/05/2020 11:10, Daniel Fuchs wrote: > Hi Aleksei, > > I agree with the general idea. However, the method: > > ?215???? private static int generateUnseenPort() { > ?216???????? int port; > ?217???????? do { > ?218???????????? port = 1111 + RND.nextInt(1000); > ?219???????? } while (SEEN_PORTS.contains(port)); > ?220???????? SEEN_PORTS.add(port); > ?221???????? return port; > ?222???? } > > might never return - if none of the port in the range > [1111, 2111] are free. Arguably, the test will have > failed in timeout before that. But maybe an assertion > error should be thrown if that happens. > > best regards, > > -- daniel > > > On 07/05/2020 00:52, Aleks Efimov wrote: >> Hi, >> >> LdapDnsProviderTest test expects to have no services running on 1111 >> port on test machine. That could cause it to fail intermittently due >> to unexpected exception message thrown by LDAP client, i.e. timeout >> or disconnect instead of expected connection refusal. >> >> The proposed fix tries to make test more stable ('intermittent' key >> was still added) by running test cases with non-default port multiple >> times by trying to use different random port numbers ('randomness' >> key was added) for each run. >> >> Webrev: http://cr.openjdk.java.net/~aefimov/8237834/00/index.html >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8237834 >> >> Test was not observed to fail for over 300 iterations. >> >> With Best Regards, >> Aleksei >> > From daniel.fuchs at oracle.com Thu May 7 14:12:04 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 7 May 2020 15:12:04 +0100 Subject: RFR: 8237834: com/sun/jndi/ldap/LdapDnsProviderTest.java failing with LDAP response read timeout In-Reply-To: <996e514d-7e7f-8b15-92c2-229fa1a2549b@oracle.com> References: <3580997f-4e06-6634-58f1-b61572d93d26@oracle.com> <996e514d-7e7f-8b15-92c2-229fa1a2549b@oracle.com> Message-ID: Hi Aleksei, If that solves the issue, then LGTM! best regards, -- daniel On 07/05/2020 14:57, Aleks Efimov wrote: > Hi Daniel, > > As a follow-up to our off-list discussion, I've updated the > generateUnseenPort method: > a) Added comment to be more specific about the number of times it is called > b) The port range has been extended to [1111, PortConfig.getUpper()) > > Webrev with new version: > http://cr.openjdk.java.net/~aefimov/8237834/01 > > With Best Regards, > Aleksei > > On 07/05/2020 11:10, Daniel Fuchs wrote: >> Hi Aleksei, >> >> I agree with the general idea. However, the method: >> >> ?215???? private static int generateUnseenPort() { >> ?216???????? int port; >> ?217???????? do { >> ?218???????????? port = 1111 + RND.nextInt(1000); >> ?219???????? } while (SEEN_PORTS.contains(port)); >> ?220???????? SEEN_PORTS.add(port); >> ?221???????? return port; >> ?222???? } >> >> might never return - if none of the port in the range >> [1111, 2111] are free. Arguably, the test will have >> failed in timeout before that. But maybe an assertion >> error should be thrown if that happens. >> >> best regards, >> >> -- daniel >> >> >> On 07/05/2020 00:52, Aleks Efimov wrote: >>> Hi, >>> >>> LdapDnsProviderTest test expects to have no services running on 1111 >>> port on test machine. That could cause it to fail intermittently due >>> to unexpected exception message thrown by LDAP client, i.e. timeout >>> or disconnect instead of expected connection refusal. >>> >>> The proposed fix tries to make test more stable ('intermittent' key >>> was still added) by running test cases with non-default port multiple >>> times by trying to use different random port numbers ('randomness' >>> key was added) for each run. >>> >>> Webrev: http://cr.openjdk.java.net/~aefimov/8237834/00/index.html >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8237834 >>> >>> Test was not observed to fail for over 300 iterations. >>> >>> With Best Regards, >>> Aleksei >>> >> > From Roger.Riggs at oracle.com Thu May 7 14:43:40 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 7 May 2020 10:43:40 -0400 Subject: [15]: RFR: 8244245: localizedBy() should override localized values with default values In-Reply-To: References: Message-ID: <9edc738f-2da2-98d4-866c-3217461d3cde@oracle.com> Hi Naoto, Looks fine with a small source edit below. TestUnicodeExtension.java: Please wrap the excessively long lines; string concatination will put them together for the test. Thanks, Roger On 5/6/20 4:44 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8244245 > > The CSR and proposed changeset are located at: > > https://bugs.openjdk.java.net/browse/JDK-8244246 > https://cr.openjdk.java.net/~naoto/8244245/webrev.00/ > > This stems from the closed issue > (https://bugs.openjdk.java.net/browse/JDK-8243162), and the rationale > for this fix is discussed there. > > Naoto > From kusrinivasan at vmware.com Thu May 7 14:52:05 2020 From: kusrinivasan at vmware.com (Kumar Srinivasan) Date: Thu, 7 May 2020 14:52:05 +0000 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> <513265a5-8a7d-d2b9-9cfe-adcf87cca390@oracle.com> Message-ID: <32A4EA4A-D640-47F4-8A8A-1888BC016E14@vmware.com> Hi Mikael, I may have created solinux when the macosx port was merged and in an effort to reduce the CPP conditionals. solinux = solaris + linux ie. Vanilla unix code vs Darwin code IIRC has Objective-C, MacOSX specific thread initialization etc. I looked over the launcher related code looks ok to me. I did notice the \n endings for the messages that Brent pointed out. Best Kumar Srinivasan On May 6, 2020, at 9:43 PM, Mikael Vidstedt > wrote: I have always wondered what ?solinux? is supposed to mean - though not enough to actually ask anybody :) I?ll file a follow-up enhancement to cover renaming the files. Thank you for the review! Cheers, Mikael On May 4, 2020, at 7:59 AM, Roger Riggs > wrote: Hi Michael, Looks good. Maybe just a future cleanup to rename files, since the "...so..." is refering to solaris. src/java.base/unix/native/libjli/java_md_solinux.h src/java.base/unix/native/libjli/java_md_solinux.h Regards, Roger On 5/4/20 4:49 AM, Alan Bateman wrote: On 04/05/2020 06:12, Mikael Vidstedt wrote: Please review this change which implements part of JEP 381: JBS: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8244224&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=W5VvD1owIGoUcbcRkcwixXGPkFLjHUFof2v6cxMqchk%3D&reserved=0 webrev: https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~mikael%2Fwebrevs%2F8244224%2Fwebrev.00%2Fcorelibs%2Fopen%2Fwebrev%2F&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=tQZIjuF5cIPs%2FNqTRtY2WtmwAgwa0iv205wQ9vk0vOQ%3D&reserved=0 JEP: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8241787&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=rDvBE%2BJ2F1IIFC9fbA92rs0KZNgYPg0JZM2ynqp7mcs%3D&reserved=0 Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! I took a pass over the changes. I agree its a bit tedious. I'm sure there will be a few follow up issues as there are opportunities for cleanup in several areas. Just a few comments/questions from a first pass. ExtendedSocketOption.SO_FLOW_SLA is the Solaris specific socket option that was terminally deprecated in 14. The patch removes the implementation but leave the API (SO_FLOW_SA and jdk.net.SocketFlow). Do you want a someone to take a follow-on issue to remove the API? ResolverConfigurationImpl.localDomain0 can be removed. The comment on mcast_join_leave in PlainDatagramSocketImpl.c has a residual reference to Solaris. JISAutoDetect - might be simpler to just initialize EUCJPName to "EUC_JP". Socket.setTrafficClass(int) swallows exceptions to workaround strange behaviour on Solaris. Tracked as JDK-8221487 so okay to leave it to that issue if you want. There is also cruft in the old plain SocketImpl that to work around eagerness to report "connection reset errors - I think we should just leave that because the old socket impl is not used by default and will be removed at some point. -Alan. From sgehwolf at redhat.com Thu May 7 15:09:05 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 07 May 2020 17:09:05 +0200 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result Message-ID: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> Hi, Please review this OpenJDK 8u fix for an issue where the update version as configured via --with-update-version=XXX might overflow in internal JDK structures and thus, will get reported wrong. In particular, only 1 byte is being reserved for the update versions internally. That is, it works fine up to a configured update version of 255 (2^8 - 1). We've passed that in OpenJDK 8u with the 8u262 cycle currently in EA. Hence, we are now seeing this issue. Bug: https://bugs.openjdk.java.net/browse/JDK-8244548 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244548/02/ testing: Linux tier 1 The proposed fix is to extend the update_version field in jdk_version_info from 8 to 16 bit and to use 16 bit of the jvm_version integer in jvm_version_info. Thus, the new upper bound for update version number is 2^16-1 => 65535 which should be sufficient. I don't think OpenJDK 8u will live that long ;-) jvm_version_info.jvm_version currently holds this quadruplet: Most significant 8 bits => major version, followed by 8 bits => minor version, followed by 8 bits => micro version, followed by 8 bits => build version. Note that JVM minor version represents the update version as passed in via configure and the micro version is currently not used (always 0). See vm_version.cpp lines 100-102 where only major, minor and build number are ever been set. Knowing this, we can still preserve the same behavior after patch by defining JVM_VERSION_MICRO to 0 for any version. For jdk_version_info the fix is simpler, since the update_version is a separate field for which I've extended it to 16 bit. Andrew Brygin suggested to reduce the reserved1 field from currently 16 bit to 8 bit since we are extending update_version by 8 bits, thus making the whole structure grow. I'm not sure reducing reserved1 to 8 bits so as to not grow the structure would be necessary, but I'd be happy to do so if there is such consensus. Thoughts? Thanks, Severin From naoto.sato at oracle.com Thu May 7 16:03:43 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 7 May 2020 09:03:43 -0700 Subject: [15]: RFR: 8244245: localizedBy() should override localized values with default values In-Reply-To: <2b681167-85d0-631f-60e2-641a28a0a0a0@oracle.com> References: <2b681167-85d0-631f-60e2-641a28a0a0a0@oracle.com> Message-ID: Hi Joe, Thank you for the review. The removed check was explicitly avoiding the default chrono/number in the locale overriding the current locale values, which is exactly what this issue is trying to remove. As Stephen wrote in another email, Unicode Extensions are correctly dealt in Chronology.ofLocale()/DecimalStyle.of() methods indirectly, so I believe no doc change is warranted. Naoto On 5/6/20 11:32 PM, Joe Wang wrote: > Hi Naoto, > > The Javadoc states: > ??? If the locale contains the "ca" (calendar), "nu" (numbering > system), "rg" (region override), and/or "tz" (timezone) Unicode > extensions, the chronology, numbering system and/or the zone are > overridden. > > If you remove the two statements that check whether the specified locale > contains "ca" or "nu", would you need to update the Javadoc as well? > > Best, > Joe > > On 5/6/2020 1:44 PM, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8244245 >> >> The CSR and proposed changeset are located at: >> >> https://bugs.openjdk.java.net/browse/JDK-8244246 >> https://cr.openjdk.java.net/~naoto/8244245/webrev.00/ >> >> This stems from the closed issue >> (https://bugs.openjdk.java.net/browse/JDK-8243162), and the rationale >> for this fix is discussed there. >> >> Naoto >> > From naoto.sato at oracle.com Thu May 7 16:06:02 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 7 May 2020 09:06:02 -0700 Subject: [15]: RFR: 8244245: localizedBy() should override localized values with default values In-Reply-To: <9edc738f-2da2-98d4-866c-3217461d3cde@oracle.com> References: <9edc738f-2da2-98d4-866c-3217461d3cde@oracle.com> Message-ID: Hi Roger, Thank you for the review. Wrapped the long lines as suggested, along with some typo fixes in the comments: https://cr.openjdk.java.net/~naoto/8244245/webrev.01/ Naoto On 5/7/20 7:43 AM, Roger Riggs wrote: > Hi Naoto, > > Looks fine with a small source edit below. > > TestUnicodeExtension.java: Please wrap the excessively long lines; > string concatination will put them together for the test. > > Thanks, Roger > > > On 5/6/20 4:44 PM, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8244245 >> >> The CSR and proposed changeset are located at: >> >> https://bugs.openjdk.java.net/browse/JDK-8244246 >> https://cr.openjdk.java.net/~naoto/8244245/webrev.00/ >> >> This stems from the closed issue >> (https://bugs.openjdk.java.net/browse/JDK-8243162), and the rationale >> for this fix is discussed there. >> >> Naoto >> > From Roger.Riggs at oracle.com Thu May 7 16:07:03 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Thu, 7 May 2020 12:07:03 -0400 Subject: [15]: RFR: 8244245: localizedBy() should override localized values with default values In-Reply-To: References: <9edc738f-2da2-98d4-866c-3217461d3cde@oracle.com> Message-ID: Looks good, thanks On 5/7/20 12:06 PM, naoto.sato at oracle.com wrote: > Hi Roger, > > Thank you for the review. Wrapped the long lines as suggested, along > with some typo fixes in the comments: > > https://cr.openjdk.java.net/~naoto/8244245/webrev.01/ > > Naoto > > On 5/7/20 7:43 AM, Roger Riggs wrote: >> Hi Naoto, >> >> Looks fine with a small source edit below. >> >> TestUnicodeExtension.java: Please wrap the excessively long lines; >> string concatination will put them together for the test. >> >> Thanks, Roger >> >> >> On 5/6/20 4:44 PM, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8244245 >>> >>> The CSR and proposed changeset are located at: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8244246 >>> https://cr.openjdk.java.net/~naoto/8244245/webrev.00/ >>> >>> This stems from the closed issue >>> (https://bugs.openjdk.java.net/browse/JDK-8243162), and the >>> rationale for this fix is discussed there. >>> >>> Naoto >>> >> From huizhe.wang at oracle.com Thu May 7 16:12:54 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 7 May 2020 09:12:54 -0700 Subject: [15]: RFR: 8244245: localizedBy() should override localized values with default values In-Reply-To: References: <2b681167-85d0-631f-60e2-641a28a0a0a0@oracle.com> Message-ID: <91ff2a2f-69cc-68d2-376a-b6a1136e1bbd@oracle.com> On 5/7/2020 1:14 AM, Stephen Colebourne wrote: > On Thu, 7 May 2020 at 07:38, Joe Wang wrote: >> The Javadoc states: >> If the locale contains the "ca" (calendar), "nu" (numbering >> system), "rg" (region override), and/or "tz" (timezone) Unicode >> extensions, the chronology, numbering system and/or the zone are overridden. >> >> If you remove the two statements that check whether the specified locale >> contains "ca" or "nu", would you need to update the Javadoc as well? > Those things are checked by the methods Chronology.of(locale) and > DecimalStyle.of(locale), so although indirect, I think the Javadoc is > fine. I see.? Thanks. -Joe > Stephen From huizhe.wang at oracle.com Thu May 7 16:18:29 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 7 May 2020 09:18:29 -0700 Subject: [15]: RFR: 8244245: localizedBy() should override localized values with default values In-Reply-To: References: <2b681167-85d0-631f-60e2-641a28a0a0a0@oracle.com> Message-ID: On 5/7/2020 9:03 AM, naoto.sato at oracle.com wrote: > Hi Joe, > > Thank you for the review. The removed check was explicitly avoiding > the default chrono/number in the locale overriding the current locale > values, which is exactly what this issue is trying to remove. As > Stephen wrote in another email, Unicode Extensions are correctly dealt > in Chronology.ofLocale()/DecimalStyle.of() methods indirectly, so I > believe no doc change is warranted. Ok, thanks for the explanation. -Joe > > Naoto > > On 5/6/20 11:32 PM, Joe Wang wrote: >> Hi Naoto, >> >> The Javadoc states: >> ???? If the locale contains the "ca" (calendar), "nu" (numbering >> system), "rg" (region override), and/or "tz" (timezone) Unicode >> extensions, the chronology, numbering system and/or the zone are >> overridden. >> >> If you remove the two statements that check whether the specified >> locale contains "ca" or "nu", would you need to update the Javadoc as >> well? >> >> Best, >> Joe >> >> On 5/6/2020 1:44 PM, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8244245 >>> >>> The CSR and proposed changeset are located at: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8244246 >>> https://cr.openjdk.java.net/~naoto/8244245/webrev.00/ >>> >>> This stems from the closed issue >>> (https://bugs.openjdk.java.net/browse/JDK-8243162), and the >>> rationale for this fix is discussed there. >>> >>> Naoto >>> >> From kralj.mark at gmail.com Tue May 5 15:50:47 2020 From: kralj.mark at gmail.com (Mark Kralj-Taylor) Date: Tue, 5 May 2020 16:50:47 +0100 Subject: os::javaTimeSystemUTC to call nanosecond precision OS API, so Clock.systemUTC() can give nanosecond precision UTC In-Reply-To: <9d13d404-ccf3-153c-90ea-9dce1c530c47@oracle.com> References: <0c697d39-0e62-ccf2-bf81-ed4110f87fda@oracle.com> <9353c814-650c-c9f9-708e-c1a4d3fdcdf8@oracle.com> <9d13d404-ccf3-153c-90ea-9dce1c530c47@oracle.com> Message-ID: Hi David, So the issue is that while glibc 2.12 (in OEL6.4) supports clock_gettime(CLOCK_REALTIME) it requires a runtime dependency on librt.so, which is an optional runtime dependency, hence the dynamic lookup you mention. The complexity of dynamic lookup makes this enhancement unattractive. But when openjdk updates to require glibc >=2.17 it would be trivial, because clock_gettime() was moved into the core libc.so. With glibc >= 2.17 there would still need to be a call to clock_gettime() to see if the optional CLOCK_MONOTONIC is supported, whereas CLOCK_REALTIME is required by the Posix spec and header docs. --- This leads me to ask a different question: What is the openjdk process for reviewing and updating its minimum dependencies? - When are dependencies reviewed? - What is the mailgroup to look at? (please let me know if there is a better place to ask this question) The info I found was last updated for JDK 13: https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms - Glibc 2.12 was released in 2010 and glibc 2.17 in 2012 - The current openjdk LTS release is Java SE 11 in September 2018, supported through to October 2024 (extended support to September 2026): https://en.wikipedia.org/wiki/Java_version_history). - Oracle Enterprise Linux 7.0 released in 2014 included glibc 2.17 These dates suggest an update of openjdk's glibc dependency might be due. But I guess the driving factor is how the timelines of openjdk LTS release support fits with those of Oracle Enterprise Linux versions. --- FYI some observations on my experience of building and testing openjdk. I installed OEL6.4, but found it very tricky to build a `real` openjdk distribution on a current Ubuntu that would run with all features on OEL6.4. - The base openjdk build was easy to use, but it built a JDK with elf dependencies based on my OS, so of course would not run on OLE6. - The openjdk make/devkit infrastructure didn't work for me to make an OEL6 build, after lots of attempts (including running in chroot or docker isolation). I'm sure it works reliably, provided you have the correct OS setup. But its not easy for an outsider to replicate that. - The AdoptOpenJDK Docker build was super easy to use, and I liked that it used Docker to use a reproducible and fully scripted OS build environment. https://github.com/AdoptOpenJDK/openjdk-build - But AdoptOpenJDK Docker build doesn't support building and using an OEL6 devkit. AdoptOpenJDK build targets RHEL 7.4+: https://github.com/AdoptOpenJDK/openjdk-build/wiki/%5BWIP%5D-Minimum-OS-levels openjdk's devkit infra must pre-date the rise of Docker, and fully reproducible build environments becoming the norm. Maybe one day there will be time to use Docker or similar to simplify the openjdk build, and making it easy for anyone to reproduce. As with using newer glibc features (glibc 2.17 vs 2.12), its likely to be drastically simpler when openjdk is able to update dependencies to newer OS versions. Especially if openjdk can be built on its minimum required per-platform OS version in a (Docker) container. Mark On Tue, 14 Apr 2020 at 23:34, David Holmes wrote: > > Hi Mark, > > On 15/04/2020 3:09 am, Mark Kralj-Taylor wrote: > > David, Daniel, > > What is the oldest (lowest) version of Linux and glibc for openjdk 15? > > I'm not clear on that. > > > The availability of clock_gettime(CLOCK_REALTIME) on the oldest > > Linux/glibc supported by openjdk 15 is likely to be the deciding > > factor on if Hotspot Linux code can call > > clock_gettime(CLOCK_REALTIME). > > > > doc/building.md suggests minimum Linux is Oracle Enterprise Linux 6.4 > > (i.e. RHEL 6.4). > > Which I think uses glibc 2.12-1.107 (based on > > https://yum.oracle.com/repo/OracleLinux/OL6/4/base/x86_64/index_src.html). > > Searching for glibc sources it looks like this supports > > clock_gettime(CLOCK_REALTIME). > > > > The wording of Linux docs suggests that clock_gettime(CLOCK_REALTIME) > > should be supported if the clock_gettime() API exists. But other clock > > sources are not mandatory. So CLOCK_REALTIME should be available even > > if CLOCK_MONOTONIC is not. > > - See: https://linux.die.net/man/2/clock_gettime. > > - Also "POSIX.1-2008 marks gettimeofday() as obsolete, recommending > > the use of clock_gettime(2) instead." from: > > https://linux.die.net/man/2/gettimeofday > > > > Note that Hotspot os_posix.cpp checks for non-error return from > > clock_gettime(CLOCK_MONOTONIC) to guard setting the _clock_gettime > > function pointer. Which was why in the patch I called clock_gettime > > directly for Linux specific os_linux.cpp (a subset of Posix OS-s). > > > > Also os_linux.cpp has: > > #ifndef SUPPORTS_CLOCK_MONOTONIC > > #error "Build platform doesn't support clock_gettime and related functionality" > > #endif > > Which made me wonder if openjdk might require CLOCK_MONOTONIC - which > > would mean clock_gettime(CLOCK_REALTIME) is supported. > > So we require that the build platform supports CLOCK_MONOTONIC and > clock_gettime, but not that the runtime platform supports > CLOCK_MONOTONIC (without which we don't/didn't need clock_gettime(). > > So we can switch to using clock_gettime(CLOCK_REALTIME) at build time > with no problem. > > We can probably also require clock_gettime(CLOCK_REALTIME) at runtime, > but we need to double-check that. I recall encountering a platform where > clock_gettime was not available, but I can't recall if it was mainstream > or on one of the other OpenJDK projects - nor do I recall exactly how > long ago this was. Keeping the dynamic lookup of clock_gettime would be > a conservative approach here - but we would need to make the distinction > between the ability to use CLOCK_REALTIME and CLOCK_MONOTONIC. > > Or someone puts in the time and effort to establish exactly what the > kernel and glibc dependencies are and whether we can just rely on > everything existing on all platforms we care about. I don't have time to > do that nor validate the results if someone else does it. > > Cheers, > David > > > Mark > > > > On Tue, 14 Apr 2020 at 18:04, Mark Kralj-Taylor wrote: > >> > >> Daniel, > >> Yes System.currentTimeMillis() and Clock.systemUTC() must be > >> consistent, so should use the same OS time source (as shown by ). > >> > >> The patch to os_linux.cpp ensures this by calling the same Linux API: > >> clock_gettime(CLOCK_REALTIME) for both, from: > >> - os::javaTimeMillis() that backs System.currentTimeMillis() > >> - os::javaTimeSystemUTC() that backs Clock.systemUTC() > >> > >> Looking at Linux / glibc source I think that gettimeofday() and > >> clock_gettime(CLOCK_REALTIME) are supposed to be the same clocksource. > >> i.e. that given by: cat > >> /sys/devices/system/clocksource/clocksource0/current_clocksource > >> > >> Mark > >> > >> On Tue, 14 Apr 2020 at 13:29, Daniel Fuchs wrote: > >>> > >>> Hi, > >>> > >>> On 11/04/2020 00:53, David Holmes wrote: > >>>> Update: > >>>>> It's a holiday weekend so I can't dig into this right now but we tried > >>>>> using a high-precision clock source for systemUTC() in the past but it > >>>>> didn't work because systemUTC() and currentTimeMillis() have to use > >>>>> the same time base, and currentTimeMillis() has to use gettimeofday(). > >>>>> I thought this cross-dependency was documented somewhere but can't > >>>>> find it right now. If gettimeofday and clock_gettime(CLOCK_REALTIME) > >>>>> actually have the same time characteristics wrt. wall-clock time then > >>>>> changing both as suggested may indeed work. > >>> > >>> Just to emphasize David's comment: System::currentTimeMillis() and > >>> Clock::systemUTC() should use the same time source: if they don't - then > >>> some tests will fail, and because it can be tricky to assert things > >>> in tests, they might (and probably will) fail only intermittently. > >>> > >>> I'm probably the culprit here, I added those tests when I upgraded > >>> Clock::systemUTC() to report sub millisecond granularity [1] - as was > >>> available in the underlying clock that System::currentTimeMillis() > >>> already used. > >>> > >>> However, I think I would be disturbed if System::currentTimeMillis() > >>> and Clock::systemUTC() were using different clocks and could > >>> report a different notion of time (by drifting away from each other). > >>> > >>> best regards, > >>> > >>> -- daniel > >>> [1] https://bugs.openjdk.java.net/browse/JDK-8068730 From mark at macchiato.com Tue May 5 18:42:56 2020 From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=) Date: Tue, 5 May 2020 11:42:56 -0700 Subject: [15] RFR: 8244152: Remove unnecessary hash map resize in LocaleProviderAdapters In-Reply-To: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> References: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> Message-ID: > (int)(tokens.countTokens() / 0.75f) + 1 > (tokens.countTokens() * 4 + 2) / 3 if you want A * X / Y, rounded up, you can use (A * X - 1 ) / Y + 1 eg where X/Y = 4/3, 0 => 0 1 => 2 2 => 3 3 => 4 4 => 6 ... Mark On Tue, May 5, 2020 at 9:48 AM Peter Levart wrote: > Hi Naoto, > > On 4/30/20 12:18 AM, naoto.sato at oracle.com wrote: > > Hello, > > > > Please review this small fix to the following issue: > > > > https://bugs.openjdk.java.net/browse/JDK-8244152 > > > > The proposed changeset is located at: > > > > https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ > > > > The hash map used there didn't have initial capacity, even though the > > exact numbers are known. > > > Well, it has to be calculated 1st (countTokens), but I guess this pays > off when HashSet (the backing HashMap) does not have to be rehashed then. > > The expression you use: > > Math.max((int)(tokens.countTokens() / 0.75f) + 1, 16) > > ...has a minimum value of 16. Why is that? 16 is just HashMap's default > initialCapacity if not specified explicitly. But if you only want to > store say 1 entry in the map, you can specify 2 as initialCapacity and > HashMap will happily work for such case without resizing. > > > So you could just use: > > (int)(tokens.countTokens() / 0.75f) + 1 > > And even this expression is sometimes overshooting the minimal required > value by 1 (when # of tokens is "exact" multiple of 0.75f, say 6). I > think the following could be used to optimally pre-size the HashMap with > default load factor 0.75: > > (tokens.countTokens() * 4 + 2) / 3 > > > Regards, Peter > > > > > Naoto > From mark at macchiato.com Wed May 6 04:02:41 2020 From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=) Date: Tue, 5 May 2020 21:02:41 -0700 Subject: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters In-Reply-To: <1b2e71f3-52c4-169b-c7eb-36eb165311ad@oracle.com> References: <40815512-2925-1140-e6f7-5aa026f427c5@gmail.com> <46715fee-ae7f-d281-37c7-6189004fe621@oracle.com> <71a3c4e7-4dd1-ec96-0699-830f1667b9c7@oracle.com> <4e994519-c6bd-a6e9-2ef8-1e8be4ef6008@gmail.com> <2aa09b33-19ab-b1bd-83a9-29cd178b7b65@oracle.com> <1b2e71f3-52c4-169b-c7eb-36eb165311ad@oracle.com> Message-ID: I wouldn't worry too much about over 2^29 either. However, the number of possible valid language tags is much larger than people think, since any combination of multiple variants can occur). So even not counting the locale extensions, it is over 2^129 (my rough calculation). Mark On Tue, May 5, 2020 at 5:09 PM wrote: > Hi Stuart, > > On 5/5/20 4:29 PM, Stuart Marks wrote: > > As for Naoto's changeset, I don't think it should be held up while we > > bikeshed this. :-) I'm ok with whatever he decides. > > I don't think the number of language tags exceed 2^29, unless languages > in the whole universe are counted :-) So I would go with the current > version. > > Naoto > > > > > s'marks > > > > > > > > > > On 5/5/20 1:26 PM, Peter Levart wrote: > >> There's more... > >> > >> > >> Guava (and JDK in copy constructor) formula: > >> > >> (int) ((float) expectedSize / 0.75f + 1.0f) > >> > >> > >> is not the same as Naoto's formula: > >> > >> (int) (expectedSize / 0.75f) + 1 > >> > >> > >> Notice that Naoto does addition of 1 in integer arithmetic after > >> conversion to int, while Guava/JDK does in floating point before > >> conversion to int. If I put Naoto's formula into my test program, no > >> undercalculations are detected. > >> > >> > >> So while Naoto's formula is sub-optimal for expectedSizes that are > >> multiples of 3, the Guava/JDK also has a bug. > >> > >> > >> Regards, Peter > >> > >> > >> On 5/5/20 10:01 PM, Peter Levart wrote: > >>> > >>> > >>> On 5/5/20 9:41 PM, Martin Buchholz wrote: > >>>> Hi Peter, > >>>> > >>>> Are you saying guava has a tiny bug? > >>> > >>> > >>> If it was just 1 too much when expected size is a multiple of 3 then > >>> that would not be a bug, just sub-optimal calculation. And the same > >>> calculation is performed also in JDK when a copy constructor is > >>> called for example. > >>> > >>> > >>> But I investigated further and what I found could be considered a > >>> bug. Sometimes, the following expression: > >>> > >>> > >>> (int) ((float) expectedSize / 0.75f + 1.0f) > >>> > >>> > >>> ...calculates a value that is not enough (due to floating point > >>> arithmetic and conversion to int) to store the expectedSize elements > >>> into the HashMap without re-hashing. > >>> > >>> > >>> What HashMap does with initialCapacity parameter is to round it up to > >>> nearest power of 2: > >>> > >>> static int tableSizeFor(int cap) { > >>> int n = -1 >>> Integer.numberOfLeadingZeros(cap - 1); > >>> return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? > >>> MAXIMUM_CAPACITY : n + 1; > >>> } > >>> > >>> then it uses this as the initial backing table size. From that table > >>> size it calculates the threshold value: > >>> > >>> static int threshold(int cap) { > >>> float ft = (float) cap * 0.75f; > >>> return (cap < MAXIMUM_CAPACITY && ft < (float) > >>> MAXIMUM_CAPACITY ? > >>> (int) ft : Integer.MAX_VALUE); > >>> } > >>> > >>> ... and uses it as the max. number of elements that a HashMap can > >>> hold before it is re-hashed. So I did the following test (comparing > >>> the effectiveness of above formula with alternative > >>> (expectedSize*4+2)/3 formula): > >>> > >>> > >>> public class HMTest { > >>> static final int MAXIMUM_CAPACITY = 1 << 30; > >>> > >>> static int tableSizeFor(int cap) { > >>> int n = -1 >>> Integer.numberOfLeadingZeros(cap - 1); > >>> return (n < 0) ? 1 : (n >= MAXIMUM_CAPACITY) ? > >>> MAXIMUM_CAPACITY : n + 1; > >>> } > >>> > >>> static int threshold(int cap) { > >>> float ft = (float) cap * 0.75f; > >>> return (cap < MAXIMUM_CAPACITY && ft < (float) > >>> MAXIMUM_CAPACITY ? > >>> (int) ft : Integer.MAX_VALUE); > >>> } > >>> > >>> public static void main(String[] args) { > >>> for (int expectedSize = 0; expectedSize < (Integer.MAX_VALUE > >>> - 2) / 4; expectedSize++) { > >>> int cap1 = (int) ((float) expectedSize / 0.75f + 1.0f); > >>> int cap2 = (expectedSize * 4 + 2) / 3; > >>> int ts1 = tableSizeFor(cap1); > >>> int ts2 = tableSizeFor(cap2); > >>> int th1 = threshold(ts1); > >>> int th2 = threshold(ts2); > >>> > >>> if (th1 < expectedSize || th2 < expectedSize) { > >>> System.out.printf("%d: (%d, %d, %d)%s (%d, %d, > %d)%s\n", > >>> expectedSize, > >>> cap1, ts1, th1, (th1 < expectedSize) ? "!" : > >>> " ", > >>> cap2, ts2, th2, (th2 < expectedSize) ? "!" : " > " > >>> ); > >>> } > >>> } > >>> } > >>> } > >>> > >>> > >>> And what this prints is the following: > >>> > >>> > >>> 25165825: (33554432, 33554432, 25165824)! (33554434, 67108864, > 50331648) > >>> 50331649: (67108864, 67108864, 50331648)! (67108866, 134217728, > >>> 100663296) > >>> 50331650: (67108864, 67108864, 50331648)! (67108867, 134217728, > >>> 100663296) > >>> 100663297: (134217728, 134217728, 100663296)! (134217730, 268435456, > >>> 201326592) > >>> 100663298: (134217728, 134217728, 100663296)! (134217731, 268435456, > >>> 201326592) > >>> 100663299: (134217728, 134217728, 100663296)! (134217732, 268435456, > >>> 201326592) > >>> 100663300: (134217728, 134217728, 100663296)! (134217734, 268435456, > >>> 201326592) > >>> 201326593: (268435456, 268435456, 201326592)! (268435458, 536870912, > >>> 402653184) > >>> 201326594: (268435456, 268435456, 201326592)! (268435459, 536870912, > >>> 402653184) > >>> 201326595: (268435456, 268435456, 201326592)! (268435460, 536870912, > >>> 402653184) > >>> 201326596: (268435456, 268435456, 201326592)! (268435462, 536870912, > >>> 402653184) > >>> 201326597: (268435456, 268435456, 201326592)! (268435463, 536870912, > >>> 402653184) > >>> 201326598: (268435456, 268435456, 201326592)! (268435464, 536870912, > >>> 402653184) > >>> 201326599: (268435456, 268435456, 201326592)! (268435466, 536870912, > >>> 402653184) > >>> 201326600: (268435456, 268435456, 201326592)! (268435467, 536870912, > >>> 402653184) > >>> 402653185: (536870912, 536870912, 402653184)! (536870914, 1073741824, > >>> 2147483647) > >>> 402653186: (536870912, 536870912, 402653184)! (536870915, 1073741824, > >>> 2147483647) > >>> 402653187: (536870912, 536870912, 402653184)! (536870916, 1073741824, > >>> 2147483647) > >>> 402653188: (536870912, 536870912, 402653184)! (536870918, 1073741824, > >>> 2147483647) > >>> 402653189: (536870912, 536870912, 402653184)! (536870919, 1073741824, > >>> 2147483647) > >>> 402653190: (536870912, 536870912, 402653184)! (536870920, 1073741824, > >>> 2147483647) > >>> 402653191: (536870912, 536870912, 402653184)! (536870922, 1073741824, > >>> 2147483647) > >>> 402653192: (536870912, 536870912, 402653184)! (536870923, 1073741824, > >>> 2147483647) > >>> 402653193: (536870912, 536870912, 402653184)! (536870924, 1073741824, > >>> 2147483647) > >>> 402653194: (536870912, 536870912, 402653184)! (536870926, 1073741824, > >>> 2147483647) > >>> 402653195: (536870912, 536870912, 402653184)! (536870927, 1073741824, > >>> 2147483647) > >>> 402653196: (536870912, 536870912, 402653184)! (536870928, 1073741824, > >>> 2147483647) > >>> 402653197: (536870912, 536870912, 402653184)! (536870930, 1073741824, > >>> 2147483647) > >>> 402653198: (536870912, 536870912, 402653184)! (536870931, 1073741824, > >>> 2147483647) > >>> 402653199: (536870912, 536870912, 402653184)! (536870932, 1073741824, > >>> 2147483647) > >>> 402653200: (536870912, 536870912, 402653184)! (536870934, 1073741824, > >>> 2147483647) > >>> > >>> > >>> So as you see, for expectedSize < (Integer.MAX_VALUE - 2) / 4 (where > >>> the alternative formula does not experience overflow and is enough > >>> for Naoto's case) all miscalculations are due to the JDK/Guava > >>> formula which in those cases calculates a value that is less than > >>> alternative formula's value and too small to adequately pre-size the > >>> HashMap table. > >>> > >>> > >>> Voila, we have some bugs to fix or I am doing something wrong here. > >>> > >>> > >>> Regards, Peter > >>> > >>> > >>>> > >>>> On Tue, May 5, 2020 at 12:12 PM Peter Levart >>>> > wrote: > >>>> > >>>> Hi Martin, > >>>> > >>>> On 5/5/20 8:26 PM, Martin Buchholz wrote: > >>>>> See related: > >>>>> > https://guava.dev/releases/23.0/api/docs/com/google/common/collect/Maps.html#newHashMapWithExpectedSize-int- > >>>>> > >>>> > >>>> > >>>> This is basically the same calculation (or at least gives same > >>>> result) as Naoto did (without the max part): > >>>> > >>>> Naoto: (int)(expectedSize / 0.75f) + 1 > >>>> > >>>> Guava: (int) ((float) expectedSize / 0.75F + 1.0F) > >>>> > >>>> but in case expectedSize is a multiple of 3, it gives the result > >>>> which is 1 more than needed. If what is needed is also a power of > >>>> 2, then twice the needed space is allocated in the HashMap > >>>> backing table. > >>>> > >>>> > >>>> Regards, Peter > >>>> > >>>> > >>>>> > >>>>> On Tue, May 5, 2020 at 11:03 AM >>>>> > wrote: > >>>>> > >>>>> And here is the fix. Please review. > >>>>> > >>>>> http://cr.openjdk.java.net/~naoto/8244459/webrev.00/ > >>>>> > >>>>> Naoto > >>>>> > >>>>> On 5/5/20 10:25 AM, naoto.sato at oracle.com > >>>>> wrote: > >>>>> > Hi Peter, > >>>>> > > >>>>> > You are correct. Thanks. I'll remove that initial value > >>>>> of 16. > >>>>> > > >>>>> > Naoto > >>>>> > > >>>>> > On 5/5/20 9:37 AM, Peter Levart wrote: > >>>>> >> Hi Naoto, > >>>>> >> > >>>>> >> On 4/30/20 12:18 AM, naoto.sato at oracle.com > >>>>> wrote: > >>>>> >>> Hello, > >>>>> >>> > >>>>> >>> Please review this small fix to the following issue: > >>>>> >>> > >>>>> >>> https://bugs.openjdk.java.net/browse/JDK-8244152 > >>>>> >>> > >>>>> >>> The proposed changeset is located at: > >>>>> >>> > >>>>> >>> https://cr.openjdk.java.net/~naoto/8244152/webrev.00/ > >>>>> >>> > >>>>> >>> The hash map used there didn't have initial capacity, > >>>>> even though the > >>>>> >>> exact numbers are known. > >>>>> >> > >>>>> >> > >>>>> >> Well, it has to be calculated 1st (countTokens), but I > >>>>> guess this pays > >>>>> >> off when HashSet (the backing HashMap) does not have to > >>>>> be rehashed then. > >>>>> >> > >>>>> >> The expression you use: > >>>>> >> > >>>>> >> Math.max((int)(tokens.countTokens() / 0.75f) + 1, 16) > >>>>> >> > >>>>> >> ...has a minimum value of 16. Why is that? 16 is just > >>>>> HashMap's > >>>>> >> default initialCapacity if not specified explicitly. But > >>>>> if you only > >>>>> >> want to store say 1 entry in the map, you can specify 2 as > >>>>> >> initialCapacity and HashMap will happily work for such > >>>>> case without > >>>>> >> resizing. > >>>>> >> > >>>>> >> > >>>>> >> So you could just use: > >>>>> >> > >>>>> >> (int)(tokens.countTokens() / 0.75f) + 1 > >>>>> >> > >>>>> >> And even this expression is sometimes overshooting the > >>>>> minimal > >>>>> >> required value by 1 (when # of tokens is "exact" multiple > >>>>> of 0.75f, > >>>>> >> say 6). I think the following could be used to optimally > >>>>> pre-size the > >>>>> >> HashMap with default load factor 0.75: > >>>>> >> > >>>>> >> (tokens.countTokens() * 4 + 2) / 3 > >>>>> >> > >>>>> >> > >>>>> >> Regards, Peter > >>>>> >> > >>>>> >>> > >>>>> >>> Naoto > >>>>> > From andy.herrick at oracle.com Thu May 7 20:23:54 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 7 May 2020 16:23:54 -0400 Subject: RFR: JDK-8244620: test failure in WinUpgradeUUIDTest Message-ID: please review fix for issue [1] at [2]. /Andy [1] - https://bugs.openjdk.java.net/browse/JDK-8244620 [2] - http://cr.openjdk.java.net/~herrick/8244620/webrev.01/ From alexey.semenyuk at oracle.com Thu May 7 20:41:57 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 7 May 2020 16:41:57 -0400 Subject: RFR: JDK-8244620: test failure in WinUpgradeUUIDTest In-Reply-To: References: Message-ID: <6e3a2e93-f1cd-970b-ee05-87d236d991ea@oracle.com> Andy, Is there a plan to properly fix the failing test instead of just disabling it? - Alexey On 5/7/2020 4:23 PM, Andy Herrick wrote: > please review fix for issue [1] at [2]. > > /Andy > > [1] - https://bugs.openjdk.java.net/browse/JDK-8244620 > > [2] - http://cr.openjdk.java.net/~herrick/8244620/webrev.01/ > From philip.race at oracle.com Thu May 7 21:03:54 2020 From: philip.race at oracle.com (Philip Race) Date: Thu, 07 May 2020 14:03:54 -0700 Subject: RFR: JDK-8244620: test failure in WinUpgradeUUIDTest In-Reply-To: References: Message-ID: <5EB477BA.70202@oracle.com> What's the failure look like ? I don't see it in the bug report. -phil. On 5/7/20, 1:23 PM, Andy Herrick wrote: > please review fix for issue [1] at [2]. > > /Andy > > [1] - https://bugs.openjdk.java.net/browse/JDK-8244620 > > [2] - http://cr.openjdk.java.net/~herrick/8244620/webrev.01/ > From mikael.vidstedt at oracle.com Thu May 7 21:24:33 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 7 May 2020 14:24:33 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> <3A65A5FD-BA6B-41C6-BF85-27746EF3E1A0@oracle.com> Message-ID: > On May 6, 2020, at 11:41 PM, Alan Bateman wrote: > > On 07/05/2020 05:56, Mikael Vidstedt wrote: >> : >> >> * File follow-up enhancement for the removal of SO_FLOW_SA and jdk.net.SocketFlow > I've created JDK-8244582 to track this, we should try to this in the same release as JEP 381. Thank you! > >> : >> >> >> * Get confirmation from Alan that the Socket.setTrafficClass(int) and SocketImpl stuff is good as-is >> > JDK-8221487 tracks the Socket.setTrafficClass issue. I didn't create an issue to mop up issues in the old SocketImpl as it is not used (at least not by default) since JDK 13. The intention is to completely remove the old SocketImpl implementation, don't know which release yet but it's hardly seems worth spending time doing cleanup on this code. I've no doubt there will be cleanup in many areas of the JDK code after JEP 381 is pushed. Sounds good, thank you! Cheers, Mikael From claes.redestad at oracle.com Thu May 7 21:28:29 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 7 May 2020 23:28:29 +0200 Subject: RFR: 8244624: Improve handling of JarFile META-INF resources Message-ID: <118bd37e-ba97-bee5-e82e-e2d0dec4dc7f@oracle.com> Hi, currently during ZipFile creation, we create an int[] array of pointers to META-INF entries. These are then retrieved from three different places in JarFile. However, JarFile is only interested in some combination a few things: the existence of and name of the META-INF/MANIFEST file, the existence of and the names of various signature related files, i.e., files in META-INF that have a suffix such as .EC, .SF, .RSA and .DSA Refactoring the contract between JarFile and ZipFile means we can filter out such entries that we're not interested when opening the file, and also remove the need to create the String for each entries unless we actually want them: Bug: https://bugs.openjdk.java.net/browse/JDK-8244624 Webrev: http://cr.openjdk.java.net/~redestad/8244624/open.00/ This reduces retained footprint of Jar-/ZipFile by slimming down or removing the Source.metanames array entirely, and a significant speed-up in some cases. In the provided microbenchmark, getManifestFromJarWithManifest and getManifestFromJarWithSignatureFiles doesn't call JUZFA.getMetaInfEntryNames but still see small (~5%) speed-up decrease in allocations. getManifestFromJarWithNoManifest exercise JUZFA.getMetaInfEntryNames in the baseline, and now calls JUZFA.getManifestName. Result is a 1.25x speed-up and 30% reduction in allocations. While unrealistic (most JARs have a META-INF/MANIFEST.MF), this speed-up will translate to a few places - such as when loading classes from potentially-signed JAR files. Testing: tier1-2 Thanks! /Claes From mikael.vidstedt at oracle.com Thu May 7 21:27:28 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 7 May 2020 14:27:28 -0700 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: <32A4EA4A-D640-47F4-8A8A-1888BC016E14@vmware.com> References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> <513265a5-8a7d-d2b9-9cfe-adcf87cca390@oracle.com> <32A4EA4A-D640-47F4-8A8A-1888BC016E14@vmware.com> Message-ID: <0A8DB9F8-E535-48F1-B28A-B71257596C12@oracle.com> > On May 7, 2020, at 7:52 AM, Kumar Srinivasan wrote: > > Hi Mikael, > > I may have created solinux when the macosx port was merged and in an effort to reduce the CPP conditionals. > solinux = solaris + linux ie. Vanilla unix code vs Darwin code IIRC has Objective-C, MacOSX specific thread initialization etc. Thank you for the background - it all makes sense now! :) > I looked over the launcher related code looks ok to me. > > I did notice the \n endings for the messages that Brent pointed out. Thank you for the review! The line ending should be fixed in webrev.01. Cheers, Mikael > >> On May 6, 2020, at 9:43 PM, Mikael Vidstedt > wrote: >> >> >> I have always wondered what ?solinux? is supposed to mean - though not enough to actually ask anybody :) >> >> I?ll file a follow-up enhancement to cover renaming the files. >> >> Thank you for the review! >> >> Cheers, >> Mikael >> >>> On May 4, 2020, at 7:59 AM, Roger Riggs > wrote: >>> >>> Hi Michael, >>> >>> Looks good. >>> >>> Maybe just a future cleanup to rename files, since the "...so..." is refering to solaris. >>> >>> src/java.base/unix/native/libjli/java_md_solinux.h >>> src/java.base/unix/native/libjli/java_md_solinux.h >>> >>> Regards, Roger >>> >>> >>> On 5/4/20 4:49 AM, Alan Bateman wrote: >>>> On 04/05/2020 06:12, Mikael Vidstedt wrote: >>>>> Please review this change which implements part of JEP 381: >>>>> >>>>> JBS: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8244224&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=W5VvD1owIGoUcbcRkcwixXGPkFLjHUFof2v6cxMqchk%3D&reserved=0 >>>>> webrev: https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~mikael%2Fwebrevs%2F8244224%2Fwebrev.00%2Fcorelibs%2Fopen%2Fwebrev%2F&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=tQZIjuF5cIPs%2FNqTRtY2WtmwAgwa0iv205wQ9vk0vOQ%3D&reserved=0 >>>>> JEP: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8241787&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=rDvBE%2BJ2F1IIFC9fbA92rs0KZNgYPg0JZM2ynqp7mcs%3D&reserved=0 >>>>> >>>>> >>>>> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >>>>> >>>> I took a pass over the changes. I agree its a bit tedious. I'm sure there will be a few follow up issues as there are opportunities for cleanup in several areas. Just a few comments/questions from a first pass. >>>> >>>> ExtendedSocketOption.SO_FLOW_SLA is the Solaris specific socket option that was terminally deprecated in 14. The patch removes the implementation but leave the API (SO_FLOW_SA and jdk.net.SocketFlow). Do you want a someone to take a follow-on issue to remove the API? >>>> >>>> ResolverConfigurationImpl.localDomain0 can be removed. >>>> >>>> The comment on mcast_join_leave in PlainDatagramSocketImpl.c has a residual reference to Solaris. >>>> >>>> JISAutoDetect - might be simpler to just initialize EUCJPName to "EUC_JP". >>>> >>>> Socket.setTrafficClass(int) swallows exceptions to workaround strange behaviour on Solaris. Tracked as JDK-8221487 so okay to leave it to that issue if you want. There is also cruft in the old plain SocketImpl that to work around eagerness to report "connection reset errors - I think we should just leave that because the old socket impl is not used by default and will be removed at some point. >>>> >>>> -Alan. > From naoto.sato at oracle.com Thu May 7 21:59:12 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 7 May 2020 14:59:12 -0700 Subject: [15] RFR: 8239383: Support for Unicode 13.0 Message-ID: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8239383 Its CSR and proposed changeset are located at: https://bugs.openjdk.java.net/browse/JDK-8239504 https://cr.openjdk.java.net/~naoto/8239383/webrev.00/ This updates java.lang.Character class to support Unicode Character Database 13.0, as well as incorporating ICU4J version 67.1, which corresponds to Unicode 13.0, for upgrading java.text.BiDi/Normalizer support. Grapheme support in java.util.regex package is also upgraded to 13.0 level. Naoto From david.holmes at oracle.com Fri May 8 00:41:03 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 May 2020 10:41:03 +1000 Subject: RFR: JDK-8244618 - WinUpgradeUUIDTest.java fails after JDK-8236518 In-Reply-To: <79FCF932-0C6B-4023-A11E-6CC50CCE4264@oracle.com> References: <79FCF932-0C6B-4023-A11E-6CC50CCE4264@oracle.com> Message-ID: <03a58483-3d5a-fc92-f5a7-26142dc15ab9@oracle.com> Ship it! (though should have gone to core-libs-dev cc'd) Thanks, David On 8/05/2020 10:31 am, Jesper Wilhelmsson wrote: > Hi. > > Please review this patch to problemlist WinUpgradeUUIDTest.java that is currently failing in tier 2. Another change is in review to remove the failure but it doesn't seem likely that it will be pushed today, so in the interest of keeping tier 2 green during the non-US timezones Friday I propose to problemlist the test for now. > > Thanks, > /Jesper > > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt > +++ b/test/jdk/ProblemList.txt > @@ -903,6 +903,7 @@ > # core_tools > > tools/jlink/JLinkReproducibleTest.java 8217166 windows-all > +tools/jpackage/windows/WinUpgradeUUIDTest.java#id1 8244620 windows-all > > ############################################################################ > From jesper.wilhelmsson at oracle.com Fri May 8 00:44:42 2020 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 8 May 2020 02:44:42 +0200 Subject: RFR: JDK-8244618 - WinUpgradeUUIDTest.java fails after JDK-8236518 In-Reply-To: <03a58483-3d5a-fc92-f5a7-26142dc15ab9@oracle.com> References: <79FCF932-0C6B-4023-A11E-6CC50CCE4264@oracle.com> <03a58483-3d5a-fc92-f5a7-26142dc15ab9@oracle.com> Message-ID: <77A74D53-C5DF-4D1D-8429-334627311BB9@oracle.com> Thank you! Pushed. /Jesper > On 8 May 2020, at 02:41, David Holmes wrote: > > Ship it! > > (though should have gone to core-libs-dev cc'd) > > Thanks, > David > > On 8/05/2020 10:31 am, Jesper Wilhelmsson wrote: >> Hi. >> Please review this patch to problemlist WinUpgradeUUIDTest.java that is currently failing in tier 2. Another change is in review to remove the failure but it doesn't seem likely that it will be pushed today, so in the interest of keeping tier 2 green during the non-US timezones Friday I propose to problemlist the test for now. >> Thanks, >> /Jesper >> diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt >> +++ b/test/jdk/ProblemList.txt >> @@ -903,6 +903,7 @@ >> # core_tools >> tools/jlink/JLinkReproducibleTest.java 8217166 windows-all >> +tools/jpackage/windows/WinUpgradeUUIDTest.java#id1 8244620 windows-all >> ############################################################################ From thejasvi.v.voniadka at oracle.com Fri May 8 00:47:28 2020 From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka) Date: Thu, 7 May 2020 17:47:28 -0700 (PDT) Subject: RFR: 8244199: [TestBug]: Update sun/management/jmxremote/bootstrap tests Message-ID: <8177caa9-b705-40d9-b35e-59834cfed2d5@default> Hi, May someone please sponsor this patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8244199 Description: The test "test/jdk/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh" fails intermittently on a lower release. While investigating the cause for the failure, I felt the diagnostic messaging built into the test was not adequate. Some of the issues observed: 1. If the test throws a RuntimeException, the full stack trace is not displayed. 2. The test has several logging statements. However, the logging environment is not properly initialized to allow levels such as FINE and FINER. 3. The logging sequence could be improved: some messages end up at stdout, and others at stderr, which makes it harder to follow the output. The patch is to improve the test in these lines. Webrev: http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.full.00 I have also used this opportunity to clean-up the test code as a whole, in lines of removal of redundant logic, formatting, coding guidelines, etc.... If the above patch looks too confusing and is hard to follow, here is a simpler version that shows only the core logic changes (I intend to submit the full patch to be pushed though): http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.simple.00 The patch has been tested on mach5, and all jmxremote tests passed. From justin.dekeyser at gmail.com Fri May 8 06:25:39 2020 From: justin.dekeyser at gmail.com (Justin Dekeyser) Date: Fri, 8 May 2020 08:25:39 +0200 Subject: Was functional-Try already discussed? In-Reply-To: References: Message-ID: I realized it may still not be clear! Sorry, My dream Try would be something like this: ``` import static java.util.Try.on; import static java.util.Try.safe; private Bar convert (Foo foo) throws ConversionException { ... } Stream foos; Stream bars = foos.map(on(ConversionException.class)::of).map(safe(this::convert)).filter(Try::notInFailure).map(Try::get); ``` This is the algebra I would like to be able to write down! Basically, Try.on would return a monad of Try< . , ConversionException>, while the Try.safe method sanitizes a method: ``` @FunctionalInterface interface TryFunction { V apply(U args) throws E; } Function> safe (TryFunction f) { ... } ``` The Try could be enriched with many interpolability facilities, but its essence would be to catch the provided exception. Best regards, Justin Dekeyser On Fri, May 8, 2020 at 1:23 AM Justin Dekeyser wrote: > Dear Dmytro, > > Thank you very much for the time you have spent answering my email. > I am sorry if I was not clear in my previous sending. I will try to > elaborate. > > In my various situations, I find people that are convinced that checked > exceptions are too hard to manage, especially beacause it does not fit well > with streams and Optional. > > I think a Try class, as usually defined, may be a good utilitary class to > have in the java.utils library, in the same way Optional does. > > In my opinion, the covered feature is an enhancement, fills a gap in > functional style flow suggested by stream and optional, is business > agnostic, technology independant, figths against the anti pattern people > adopt by defining unchecked exceptions, so for all these reasons, I think > one can propose a solution as standard. > > Was the Try already discussed somewhere? What does Optional conceptually > brings, that Try could not? > > Best regards, > > Justin Dekeyser > > On Thursday, May 7, 2020, dmytro sheyko > wrote: > >> Hi Justin, >> >> This is not quite clear what exactly you are talking about. In any case >> why do you think it should be a part of OpenJDK? Can't it be just a >> separate library? >> >> Regards, >> Dmytro >> >> On Wed, May 6, 2020 at 8:31 AM Justin Dekeyser >> wrote: >> >>> Hi everyone, >>> >>> I am new to the OpenJDK community and I'm using Java fora small decade >>> now, >>> first as a hobby, then in my academic studies and my PhD in maths, and >>> now >>> as a professional developer in IT companies. I'm quite active on forum to >>> help people, I've helped teaching students in the university, I read a >>> lot >>> of posts on blogs, and so many times I'm facing people having trouble >>> with >>> checked exceptions. >>> >>> The situation in my current job makes clarifies what I mean. People >>> usually >>> like declaring their own exception super class as "BusinessException", >>> then >>> deriving it in many subclasses to describe more accurate failure reasons. >>> The problem they face is that when they declare their class as *checked >>> Exception*, they cannot use the mechanism of Optional and Stream, for an >>> obvious reason. Usually they prefer Optional and Stream, so they end up >>> by >>> subclassing RuntimeException. >>> >>> I find it so sad because, when interfacing services, you often forget >>> about >>> declaring those unchecked exceptions, and the client is not aware of >>> what's >>> happening! I think you loose all the benefit of the exception mechanism >>> in >>> Java here for a very bad reason. >>> >>> In my job I finally rectified (partially, because the code base is huge) >>> the situation by implementing a "functional" Try in the same spirit than >>> the Optional. People are quite happy with it. I can invest more time in >>> its >>> development but I think this small library could help more people about >>> turning their exception in something clean again. So maybe it could be >>> useful for the whole community. (I already discussed it with my boss, >>> there >>> will be no copyright problem.) >>> >>> There exists similar projects around the world (in the Vavr lib for >>> example) and Scala offers this as a basic feature, which basically means >>> that people could appreciate the enhancement! >>> >>> I am wondering if the Try interface would be interesting for OpenJDK, if >>> they have been discussions about it, and what were the decisions about >>> such >>> a library? In my opinion, it may be a good complement to the Optional and >>> the Stream interfaces to allow a functional style while keeping this cool >>> feature of checked exceptions. >>> >>> Best regards, >>> >>> Justin Dekeyser >>> >> From weijun.wang at oracle.com Fri May 8 07:08:52 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 8 May 2020 15:08:52 +0800 Subject: RFR: 8244624: Improve handling of JarFile META-INF resources In-Reply-To: <118bd37e-ba97-bee5-e82e-e2d0dec4dc7f@oracle.com> References: <118bd37e-ba97-bee5-e82e-e2d0dec4dc7f@oracle.com> Message-ID: JarFile.java: 734: extra new line? 930: Remove or rewrite the comment. ZipFile.java: 49: seems not used Please add links to each other between src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java::isBlockOrSF and src/java.base/share/classes/java/util/zip/ZipFile.java::isSignatureRelated. The 2nd method can also be static. I assume you cannot put ZipFile::isSignatureRelated into SignatureFileVerifier.java, right? Thanks, Max p.s. How do you run the benchmark test? Both locally and on mach5. > On May 8, 2020, at 5:28 AM, Claes Redestad wrote: > > Hi, > > currently during ZipFile creation, we create an int[] array of pointers > to META-INF entries. These are then retrieved from three different > places in JarFile. > > However, JarFile is only interested in some combination a few things: > the existence of and name of the META-INF/MANIFEST file, the existence > of and the names of various signature related files, i.e., files in > META-INF that have a suffix such as .EC, .SF, .RSA and .DSA > > Refactoring the contract between JarFile and ZipFile means we can filter > out such entries that we're not interested when opening the file, and > also remove the need to create the String for each entries unless we > actually want them: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244624 > Webrev: http://cr.openjdk.java.net/~redestad/8244624/open.00/ > > This reduces retained footprint of Jar-/ZipFile by slimming down or > removing the Source.metanames array entirely, and a significant speed-up > in some cases. > > In the provided microbenchmark, getManifestFromJarWithManifest and > getManifestFromJarWithSignatureFiles doesn't call > JUZFA.getMetaInfEntryNames but still see small (~5%) speed-up decrease > in allocations. > > getManifestFromJarWithNoManifest exercise JUZFA.getMetaInfEntryNames in > the baseline, and now calls JUZFA.getManifestName. Result is a 1.25x > speed-up and 30% reduction in allocations. While unrealistic (most JARs > have a META-INF/MANIFEST.MF), this speed-up will translate to a few > places - such as when loading classes from potentially-signed JAR files. > > Testing: tier1-2 > > Thanks! > > /Claes From magnus.ihse.bursie at oracle.com Fri May 8 08:20:40 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 8 May 2020 10:20:40 +0200 Subject: RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (core libraries) In-Reply-To: <0A8DB9F8-E535-48F1-B28A-B71257596C12@oracle.com> References: <3905A7D9-C6DB-4A5C-BBBB-A16EEA3BB7F5@oracle.com> <513265a5-8a7d-d2b9-9cfe-adcf87cca390@oracle.com> <32A4EA4A-D640-47F4-8A8A-1888BC016E14@vmware.com> <0A8DB9F8-E535-48F1-B28A-B71257596C12@oracle.com> Message-ID: <41020a42-1334-8cb8-fc4b-a42952cffa3a@oracle.com> On 2020-05-07 23:27, Mikael Vidstedt wrote: > >> On May 7, 2020, at 7:52 AM, Kumar Srinivasan wrote: >> >> Hi Mikael, >> >> I may have created solinux when the macosx port was merged and in an effort to reduce the CPP conditionals. >> solinux = solaris + linux ie. Vanilla unix code vs Darwin code IIRC has Objective-C, MacOSX specific thread initialization etc. > Thank you for the background - it all makes sense now! :) If the file is truly only used on linux, it should be moved to java.base/linux/native/libjli instead. (And be renamed.) If it's still used on other unix platforms (read: AIX) it should probably be renamed java_md_unix.h instead, and kept in place. If this change should be done in a follow-up fix or as part of JEP 381, I leave to you to decide. (edit: *actually looking at the files* ... ) Hm. The include block looks like this: #if defined(_AIX) #include "java_md_aix.h" #endif #ifdef MACOSX #include "java_md_macosx.h" #else? /* !MACOSX */ #include "java_md_solinux.h" #endif /* MACOSX */ #endif /* JAVA_MD_H */ It would probably make sense to make this a three-pronged include with separate files for aix, macosx and linux, but that will probably require stuff to migrate from java_md_solinux.h to java_md_aix.h, or at the very least, proper testing on AIX. Recommend filing follow-up issue to sort this out. /Magnus > >> I looked over the launcher related code looks ok to me. >> >> I did notice the \n endings for the messages that Brent pointed out. > Thank you for the review! The line ending should be fixed in webrev.01. > > Cheers, > Mikael > >>> On May 6, 2020, at 9:43 PM, Mikael Vidstedt > wrote: >>> >>> >>> I have always wondered what ?solinux? is supposed to mean - though not enough to actually ask anybody :) >>> >>> I?ll file a follow-up enhancement to cover renaming the files. >>> >>> Thank you for the review! >>> >>> Cheers, >>> Mikael >>> >>>> On May 4, 2020, at 7:59 AM, Roger Riggs > wrote: >>>> >>>> Hi Michael, >>>> >>>> Looks good. >>>> >>>> Maybe just a future cleanup to rename files, since the "...so..." is refering to solaris. >>>> >>>> src/java.base/unix/native/libjli/java_md_solinux.h >>>> src/java.base/unix/native/libjli/java_md_solinux.h >>>> >>>> Regards, Roger >>>> >>>> >>>> On 5/4/20 4:49 AM, Alan Bateman wrote: >>>>> On 04/05/2020 06:12, Mikael Vidstedt wrote: >>>>>> Please review this change which implements part of JEP 381: >>>>>> >>>>>> JBS: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8244224&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=W5VvD1owIGoUcbcRkcwixXGPkFLjHUFof2v6cxMqchk%3D&reserved=0 >>>>>> webrev: https://nam04.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~mikael%2Fwebrevs%2F8244224%2Fwebrev.00%2Fcorelibs%2Fopen%2Fwebrev%2F&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=tQZIjuF5cIPs%2FNqTRtY2WtmwAgwa0iv205wQ9vk0vOQ%3D&reserved=0 >>>>>> JEP: https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8241787&data=02%7C01%7Ckusrinivasan%40vmware.com%7Ce48bd44f0c484e6fd85608d7f243f1ff%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637244245954061434&sdata=rDvBE%2BJ2F1IIFC9fbA92rs0KZNgYPg0JZM2ynqp7mcs%3D&reserved=0 >>>>>> >>>>>> >>>>>> Note: When reviewing this, please be aware that this exercise was *extremely* mind-numbing, so I appreciate your help reviewing all the individual changes carefully. You may want to get that coffee cup filled up (or whatever keeps you awake)! >>>>>> >>>>> I took a pass over the changes. I agree its a bit tedious. I'm sure there will be a few follow up issues as there are opportunities for cleanup in several areas. Just a few comments/questions from a first pass. >>>>> >>>>> ExtendedSocketOption.SO_FLOW_SLA is the Solaris specific socket option that was terminally deprecated in 14. The patch removes the implementation but leave the API (SO_FLOW_SA and jdk.net.SocketFlow). Do you want a someone to take a follow-on issue to remove the API? >>>>> >>>>> ResolverConfigurationImpl.localDomain0 can be removed. >>>>> >>>>> The comment on mcast_join_leave in PlainDatagramSocketImpl.c has a residual reference to Solaris. >>>>> >>>>> JISAutoDetect - might be simpler to just initialize EUCJPName to "EUC_JP". >>>>> >>>>> Socket.setTrafficClass(int) swallows exceptions to workaround strange behaviour on Solaris. Tracked as JDK-8221487 so okay to leave it to that issue if you want. There is also cruft in the old plain SocketImpl that to work around eagerness to report "connection reset errors - I think we should just leave that because the old socket impl is not used by default and will be removed at some point. >>>>> >>>>> -Alan. From claes.redestad at oracle.com Fri May 8 10:57:25 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 8 May 2020 12:57:25 +0200 Subject: RFR: 8244624: Improve handling of JarFile META-INF resources In-Reply-To: References: <118bd37e-ba97-bee5-e82e-e2d0dec4dc7f@oracle.com> Message-ID: <86efa64d-a9a2-3942-5847-140ec4ba4692@oracle.com> Hi Max, On 2020-05-08 09:08, Weijun Wang wrote: > JarFile.java: > > 734: extra new line? Fixed > 930: Remove or rewrite the comment. Did even better: now that I find the position of the manifest during initCEN, this method should always call JUZFA.getManifest(this, false); - which is both a simplification and an optimization. > > ZipFile.java: > > 49: seems not used Fixed > > Please add links to each other between src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java::isBlockOrSF and src/java.base/share/classes/java/util/zip/ZipFile.java::isSignatureRelated. The 2nd method can also be static. > > I assume you cannot put ZipFile::isSignatureRelated into SignatureFileVerifier.java, right? Right, that wouldn't be great for either since ZipFile operates directly on UTF-8 encoded bytes for performance, while SignatureFileVerifier works on Strings. What we can do though is to add in an assert that the result of ZF::isSignatureRelated matches that of SFV::isBlockOrSF - which should ensure. I also added a note to SignatureFileVerifier::isBlockOfSF to keep these in sync: http://cr.openjdk.java.net/~redestad/8244624/open.01/ Testing: re-running tier1+2 > > Thanks, > Max > > p.s. How do you run the benchmark test? Both locally and on mach5. See doc/testing.md Basically: Configure with --with-jmh (jib does this automatically) make build-microbenchmark $JDK/bin/java -jar build/$CONF/images/test/micro/benchmarks.jar JarFileMeta Thanks! /Claes > >> On May 8, 2020, at 5:28 AM, Claes Redestad wrote: >> >> Hi, >> >> currently during ZipFile creation, we create an int[] array of pointers >> to META-INF entries. These are then retrieved from three different >> places in JarFile. >> >> However, JarFile is only interested in some combination a few things: >> the existence of and name of the META-INF/MANIFEST file, the existence >> of and the names of various signature related files, i.e., files in >> META-INF that have a suffix such as .EC, .SF, .RSA and .DSA >> >> Refactoring the contract between JarFile and ZipFile means we can filter >> out such entries that we're not interested when opening the file, and >> also remove the need to create the String for each entries unless we >> actually want them: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8244624 >> Webrev: http://cr.openjdk.java.net/~redestad/8244624/open.00/ >> >> This reduces retained footprint of Jar-/ZipFile by slimming down or >> removing the Source.metanames array entirely, and a significant speed-up >> in some cases. >> >> In the provided microbenchmark, getManifestFromJarWithManifest and >> getManifestFromJarWithSignatureFiles doesn't call >> JUZFA.getMetaInfEntryNames but still see small (~5%) speed-up decrease >> in allocations. >> >> getManifestFromJarWithNoManifest exercise JUZFA.getMetaInfEntryNames in >> the baseline, and now calls JUZFA.getManifestName. Result is a 1.25x >> speed-up and 30% reduction in allocations. While unrealistic (most JARs >> have a META-INF/MANIFEST.MF), this speed-up will translate to a few >> places - such as when loading classes from potentially-signed JAR files. >> >> Testing: tier1-2 >> >> Thanks! >> >> /Claes > From fernando.guallini at oracle.com Fri May 8 12:58:23 2020 From: fernando.guallini at oracle.com (Fernando Guallini) Date: Fri, 8 May 2020 13:58:23 +0100 Subject: RFR: JDK-8209774 - [TESTBUG]Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java Message-ID: <4F6C2290-A3AE-4A93-BE99-D057C9CEC778@oracle.com> Hi all, Please, review the following change: webrev: http://cr.openjdk.java.net/~fyuan/fernando/8209774/webrev.00/ Testbug: https://bugs.openjdk.java.net/browse/JDK-8209774 Change details: - Refactor shell test to java That test was originally created to check XERCESJ-1007 bug fix, that java.lang.AbstractMethodError is not thrown when patching JDK boot class DocumentImpl with its own. Kind regards, Fernando From daniel.fuchs at oracle.com Fri May 8 14:16:45 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 8 May 2020 15:16:45 +0100 Subject: RFR: JDK-8209774 - [TESTBUG]Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java In-Reply-To: <4F6C2290-A3AE-4A93-BE99-D057C9CEC778@oracle.com> References: <4F6C2290-A3AE-4A93-BE99-D057C9CEC778@oracle.com> Message-ID: <54095829-fd05-267f-3330-deb6a8c213b8@oracle.com> Hi Fernando, I believe that if you simply move the patched file under a directory named javax.xml, then you can get rid of all the @compile in the test. Starting from your patch: cd test/jdk/javax/xml/jaxp/common/8035437 mkdir java.xml hg move org javax.xml hg move com javax.xml then: 31 /* 32 * @test 33 * @bug 8035437 34 * @summary Tests that java.lang.AbstractMethodError is not thrown when 35 * serializing improper version of DocumentImpl class. 36 * @library /test/lib * @modules javax.xml/org.w3c.dom * javax.xml/com.sun.org.apache.xerces.internal.dom 40 * @run main/othervm --patch-module java.xml=${test.class.path} AbstractMethodErrorTest 41 */ (not 100% sure the @modules is even needed) best regards, -- daniel On 08/05/2020 13:58, Fernando Guallini wrote: > Hi all, > > Please, review the following change: > > webrev: http://cr.openjdk.java.net/~fyuan/fernando/8209774/webrev.00/ > Testbug: https://bugs.openjdk.java.net/browse/JDK-8209774 > > Change details: > - Refactor shell test to java > > That test was originally created to check XERCESJ-1007 bug fix, that java.lang.AbstractMethodError is not thrown when patching JDK boot class DocumentImpl with its own. > > Kind regards, > Fernando > From Alan.Bateman at oracle.com Fri May 8 14:40:30 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 8 May 2020 15:40:30 +0100 Subject: RFR: JDK-8209774 - [TESTBUG]Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java In-Reply-To: <54095829-fd05-267f-3330-deb6a8c213b8@oracle.com> References: <4F6C2290-A3AE-4A93-BE99-D057C9CEC778@oracle.com> <54095829-fd05-267f-3330-deb6a8c213b8@oracle.com> Message-ID: <2a03d73b-e7d9-2799-dedd-7d4f097a3309@oracle.com> On 08/05/2020 15:16, Daniel Fuchs wrote: > : > > then: > > ? 31 /* > ? 32? * @test > ? 33? * @bug 8035437 > ? 34? * @summary Tests that java.lang.AbstractMethodError is not > thrown when > ? 35? * serializing improper version of DocumentImpl class. > ? 36? * @library /test/lib > ????? * @modules javax.xml/org.w3c.dom > ????? *????????? javax.xml/com.sun.org.apache.xerces.internal.dom > ? 40? * @run main/othervm --patch-module java.xml=${test.class.path} > AbstractMethodErrorTest > ? 41? */ > > (not 100% sure the @modules is even needed) I wouldn't expect to need --patch-module here. Instead maybe it could be changed to use @compile/module=java.xml ... and jtreg should compile and run the overrides "as if" they are in the java.xml module. There are a couple of examples of this in the test suite that might help get this going. No need for javax.xml/org.w3c.dom as that package is already exported. -Alan From daniel.fuchs at oracle.com Fri May 8 14:49:38 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 8 May 2020 15:49:38 +0100 Subject: RFR: JDK-8209774 - [TESTBUG]Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java In-Reply-To: <2a03d73b-e7d9-2799-dedd-7d4f097a3309@oracle.com> References: <4F6C2290-A3AE-4A93-BE99-D057C9CEC778@oracle.com> <54095829-fd05-267f-3330-deb6a8c213b8@oracle.com> <2a03d73b-e7d9-2799-dedd-7d4f097a3309@oracle.com> Message-ID: On 08/05/2020 15:40, Alan Bateman wrote: >> ? 31 /* >> ? 32? * @test >> ? 33? * @bug 8035437 >> ? 34? * @summary Tests that java.lang.AbstractMethodError is not >> thrown when >> ? 35? * serializing improper version of DocumentImpl class. >> ? 36? * @library /test/lib >> ????? * @modules javax.xml/org.w3c.dom >> ????? *????????? javax.xml/com.sun.org.apache.xerces.internal.dom >> ? 40? * @run main/othervm --patch-module java.xml=${test.class.path} >> AbstractMethodErrorTest >> ? 41? */ >> >> (not 100% sure the @modules is even needed) > I wouldn't expect to need --patch-module here. Instead maybe it could be > changed to use @compile/module=java.xml ... and jtreg should compile and > run the overrides "as if" they are in the java.xml module. There are a > couple of examples of this in the test suite that might help get this > going. No need for javax.xml/org.w3c.dom as that package is already > exported. Right. Copy paste error. The --patch-module shouldn't be needed anywhere. Good point about @compile - the main class AbstractMethodErrorTest is not in the patched module, so the patched classes may not get compiled if you don't force their compilation. Thanks for the correction Alan! -- daniel From volker.simonis at gmail.com Fri May 8 15:36:11 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 8 May 2020 17:36:11 +0200 Subject: RFR(s): 8244659: Improve ZipFile.getInputStream Message-ID: Hi, can I please have a review for the following small enhancement which improves the speed of reading from ZipFile.getInputStream() by ~5%: http://cr.openjdk.java.net/~simonis/webrevs/2020/8244659/ https://bugs.openjdk.java.net/browse/JDK-8244659 ZipFile.getInputStream() tries to find a good size for sizing the internal buffer of the underlying InflaterInputStream. This buffer is used to read the compressed data from the associated InputStream. Unfortunately, ZipFile.getInputStream() uses CENLEN (i.e. the uncompressed size of a ZipEntry) instead of CENSIZ (i.e. the compressed size of a ZipEntry) to configure the input buffer and thus unnecessarily wastes memory, because the corresponding, compressed input data is at most CENSIZ bytes long. After fixing this and doing some benchmarks, I realized that a much bigger problem is the continuous allocation of new, temporary input buffers for each new input stream. Assuming that a zip files usually has hundreds if not thousands of ZipEntries, I think it makes sense to cache these input buffers. Fortunately, ZipFile already has a built-in mechanism for such caching which it uses for caching the Inflaters needed for each new input stream. In order to cache the buffers as well, I had to add a new , package-private constructor to InflaterInputStream. I'm not sure if it makes sense to make this new constructor public, to enable other users of InflaterInputStream to pre-allocate the buffer. If you think so, I'd be happy to do that change and open a CSR for this issue. Adding a cache for input stream buffers increases the speed of reading ZipEntries from an InputStream by roughly 5% (see benchmark results below). More importantly, it also decreases the memory consumption for each call to ZipFile.getInputStream() which can be quite significant if many ZipEntries are read from a ZipFile. One visible effect of caching the input buffers is that the manual JTreg test java/util/zip/ZipFile/TestZipFile.java, which regularly failed on my desktop with an OutOfMemoryError before, now reliably passes (this tests calls ZipFile.getInputStream() excessively). I've experimented with different buffer sizes (even with buffer sizes depending on the size of the compressed ZipEntries), but couldn't see any difference so I decided to go with a default buffer size of 65536 which already was the maximal buffer size in use before my change. I've also added a shortcut to Inflater which prevents us doing a native call down to libz's inflate() method every time we call Inflater.inflate() with "input == ZipUtils.defaultBuf" which is the default for every newly created Inflater and for Inflaters after "Inflater.reset()" has been called on them. Following some JMH benchmark results which show the time and memory used to read all bytes from a ZipEntry before and after this change. The 'size' parameter denotes the uncompressed size of the corresponding ZipEntries. In the "BEFORE" numbers, when looking at the "gc.alloc.rate.norm" values, you can see the anomaly caused by using CENLEN instead of CENSIZ in ZipFile.getInputStream(). I.e. getInputStream() chooses to big buffers because it looks at the uncompressed ZipEntry sizes which are ~ 6 times bigger than the compressed sizes. Also, the old implementation capped buffers bigger than 65536 to 8192 bytes. The memory savings for a call to getInputStream() are obviously the effect of repetadly calling getInputStream() on the same zip file (becuase only in that case, the caching of the input buffers pays of). But as I wrote before, I think it is common to have mor then a few entries in a zip file and even if not, the overhead of caching is minimal compared to the situation we had before the change. Thank you and best regards, Volker = BEFORE 8244659 = Benchmark (size) Mode Cnt Score Error Units ZipFileGetInputStream.readAllBytes 1024 avgt 3 13.577 ? 0.540 us/op ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 1024 avgt 3 1872.673 ? 0.317 B/op ZipFileGetInputStream.readAllBytes:?gc.count 1024 avgt 3 57.000 counts ZipFileGetInputStream.readAllBytes:?gc.time 1024 avgt 3 15.000 ms ZipFileGetInputStream.readAllBytes 4096 avgt 3 20.938 ? 0.577 us/op ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 4096 avgt 3 4945.793 ? 0.493 B/op ZipFileGetInputStream.readAllBytes:?gc.count 4096 avgt 3 102.000 counts ZipFileGetInputStream.readAllBytes:?gc.time 4096 avgt 3 25.000 ms ZipFileGetInputStream.readAllBytes 16384 avgt 3 51.348 ? 2.600 us/op ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 16384 avgt 3 17238.030 ? 3.183 B/op ZipFileGetInputStream.readAllBytes:?gc.count 16384 avgt 3 144.000 counts ZipFileGetInputStream.readAllBytes:?gc.time 16384 avgt 3 33.000 ms ZipFileGetInputStream.readAllBytes 65536 avgt 3 203.082 ? 7.046 us/op ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 65536 avgt 3 9035.475 ? 7.426 B/op ZipFileGetInputStream.readAllBytes:?gc.count 65536 avgt 3 18.000 counts ZipFileGetInputStream.readAllBytes:?gc.time 65536 avgt 3 5.000 ms ZipFileGetInputStream.readAllBytes 262144 avgt 3 801.928 ? 22.474 us/op ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 262144 avgt 3 9034.192 ? 0.047 B/op ZipFileGetInputStream.readAllBytes:?gc.count 262144 avgt 3 3.000 counts ZipFileGetInputStream.readAllBytes:?gc.time 262144 avgt 3 1.000 ms ZipFileGetInputStream.readAllBytes 1048576 avgt 3 3154.747 ? 57.588 us/op ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 1048576 avgt 3 9032.194 ? 0.004 B/op ZipFileGetInputStream.readAllBytes:?gc.count 1048576 avgt 3 ? 0 counts = AFTER 8244659 = Benchmark (size) Mode Cnt Score Error Units ZipFileGetInputStream.readAllBytes 1024 avgt 3 13.031 ? 0.452 us/op ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 1024 avgt 3 824.311 ? 0.027 B/op ZipFileGetInputStream.readAllBytes:?gc.count 1024 avgt 3 27.000 counts ZipFileGetInputStream.readAllBytes:?gc.time 1024 avgt 3 7.000 ms ZipFileGetInputStream.readAllBytes 4096 avgt 3 20.018 ? 0.805 us/op ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 4096 avgt 3 824.289 ? 0.722 B/op ZipFileGetInputStream.readAllBytes:?gc.count 4096 avgt 3 15.000 counts ZipFileGetInputStream.readAllBytes:?gc.time 4096 avgt 3 4.000 ms ZipFileGetInputStream.readAllBytes 16384 avgt 3 48.916 ? 1.140 us/op ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 16384 avgt 3 824.263 ? 0.008 B/op ZipFileGetInputStream.readAllBytes:?gc.count 16384 avgt 3 6.000 counts ZipFileGetInputStream.readAllBytes:?gc.time 16384 avgt 3 1.000 ms ZipFileGetInputStream.readAllBytes 65536 avgt 3 192.815 ? 4.102 us/op ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 65536 avgt 3 824.012 ? 0.001 B/op ZipFileGetInputStream.readAllBytes:?gc.count 65536 avgt 3 ? 0 counts ZipFileGetInputStream.readAllBytes 262144 avgt 3 755.713 ? 42.408 us/op ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 262144 avgt 3 824.047 ? 0.003 B/op ZipFileGetInputStream.readAllBytes:?gc.count 262144 avgt 3 ? 0 counts ZipFileGetInputStream.readAllBytes 1048576 avgt 3 2989.236 ? 8.808 us/op ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 1048576 avgt 3 824.184 ? 0.002 B/op ZipFileGetInputStream.readAllBytes:?gc.count 1048576 avgt 3 ? 0 counts From naoto.sato at oracle.com Fri May 8 16:27:23 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 8 May 2020 09:27:23 -0700 Subject: JDK-8226810: An other case and a small change suggestion In-Reply-To: References: <2c1ff9d3-a9a6-800d-bb55-e771f22a3807@j-kuhn.de> Message-ID: <625e04bf-b052-1805-772e-1a1411ef5e00@oracle.com> Ditto. Good catch! I am not sure the fix would address the issue in 8226810 (cannot confirm it either, as my Windows box is at my office where I cannot enter at the moment :-), but this definitely looks like a bug. I would change the additional line to "strcpy(ret+2, "1252");" as Cp is copied in the following switch. Naoto On 5/7/20 5:50 AM, Alan Bateman wrote: > On 07/05/2020 12:37, Johannes Kuhn wrote: >> : >> >> In the end, I don't know what causes the bug, or how I can replicate it. >> I think I did find a likely suspect. > Good sleuthing. I don't what the conditions are for GetLocaleInfo to > fail but it does look like that would return possibly non-terminated > garbage starting with "CP" so we should at least fix that. > > The issue in JDK-8226810 might be something else. One of the submitters > to that issue did engage and provided enough information to learn that > the locale is zh_CN and also reported that it was failing for GB18030. > GB18030 is not in java.base so that at least explained that report. > > -Alan From fernando.guallini at oracle.com Fri May 8 17:19:10 2020 From: fernando.guallini at oracle.com (Fernando Guallini) Date: Fri, 8 May 2020 18:19:10 +0100 Subject: RFR: JDK-8209774 - [TESTBUG]Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java In-Reply-To: References: <4F6C2290-A3AE-4A93-BE99-D057C9CEC778@oracle.com> <54095829-fd05-267f-3330-deb6a8c213b8@oracle.com> <2a03d73b-e7d9-2799-dedd-7d4f097a3309@oracle.com> Message-ID: <5BA24215-81C0-4540-B425-DD9167FBFF44@oracle.com> Hi Daniel and Alan, @compile/module=java.xml was my first try, but for the nature of this test, it didn't work. The reason is that the original shell test does the following: - Compiles it?s own version of Node and Document interfaces - Compiles DocumentImpl patching java.xml with those 2 interfaces - Executes the AbstractMethodErrorTest patching the java.xml module only with DocumentImpl patch(not including Document and Node) It does that by keeping the patches output in different folders. That?s important otherwise AbstractMethodErrorTest doesn?t compile, because it references some methods not declared in its custom interfaces, and it seems to be coded this way to reproduce the original bug. That is also the reason why I added the @clean command to remove Document and Node before running the test. But when using @compile/module=java.xml, under the hood, JTREG generates a folder named ?patches/java.xml/..? including all the compiled classes under it. Unfortunately, the temporary interfaces can?t be removed because @clean does not know how to resolve the path "/patches/java.xml/..?. To sum up, this test creates a temporary java.xml patch that needs to be ignored after compiling DocumentImpl. I am using ?patch-module because it?s more flexible than @compile/module Hope I explained myself! > On 8 May 2020, at 15:49, Daniel Fuchs wrote: > > On 08/05/2020 15:40, Alan Bateman wrote: >>> 31 /* >>> 32 * @test >>> 33 * @bug 8035437 >>> 34 * @summary Tests that java.lang.AbstractMethodError is not thrown when >>> 35 * serializing improper version of DocumentImpl class. >>> 36 * @library /test/lib >>> * @modules javax.xml/org.w3c.dom >>> * javax.xml/com.sun.org.apache.xerces.internal.dom >>> 40 * @run main/othervm --patch-module java.xml=${test.class.path} AbstractMethodErrorTest >>> 41 */ >>> >>> (not 100% sure the @modules is even needed) >> I wouldn't expect to need --patch-module here. Instead maybe it could be changed to use @compile/module=java.xml ... and jtreg should compile and run the overrides "as if" they are in the java.xml module. There are a couple of examples of this in the test suite that might help get this going. No need for javax.xml/org.w3c.dom as that package is already exported. > > Right. Copy paste error. The --patch-module shouldn't be needed > anywhere. Good point about @compile - the main class > AbstractMethodErrorTest is not in the patched module, so > the patched classes may not get compiled if you don't force > their compilation. > > Thanks for the correction Alan! > > -- daniel From daniel.fuchs at oracle.com Fri May 8 17:39:58 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 8 May 2020 18:39:58 +0100 Subject: RFR: JDK-8209774 - [TESTBUG]Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java In-Reply-To: <5BA24215-81C0-4540-B425-DD9167FBFF44@oracle.com> References: <4F6C2290-A3AE-4A93-BE99-D057C9CEC778@oracle.com> <54095829-fd05-267f-3330-deb6a8c213b8@oracle.com> <2a03d73b-e7d9-2799-dedd-7d4f097a3309@oracle.com> <5BA24215-81C0-4540-B425-DD9167FBFF44@oracle.com> Message-ID: <3e64642d-0e55-61e7-c0c7-9e0582b16691@oracle.com> Hi Fernando, Ah - I see the keypoint is the: 39 * @clean org.w3c.dom.* OK, I missed that. Then I agree - ignore my previous comments. Maybe the explanations below should be added to the test in some comment to help future maintainers (and reviewers). best regards, -- daniel On 08/05/2020 18:19, Fernando Guallini wrote: > Hi Daniel and Alan, > @compile/module=java.xml was my first try, but for the nature of this > test, it didn't work. The reason is that the original shell test does > the following: > - Compiles it?s own version of Node and Document interfaces > - Compiles DocumentImpl patching java.xml with those 2 interfaces > - Executes the AbstractMethodErrorTest patching the java.xml module > *only with DocumentImpl*?patch(not including Document and Node) > > It does that by keeping the patches output in different folders. That?s > important otherwise AbstractMethodErrorTest doesn?t compile, because it > references some methods not declared in its custom interfaces, and it > seems to be coded this way to reproduce the original bug. That is also > the reason why I added the *@clean*?command to remove Document and Node > *before* running the test. > > But when using *@compile/module=java.xml*, under the hood, JTREG > generates a folder named ?patches/java.xml/..? including all the > compiled classes under it. Unfortunately, the temporary interfaces can?t > be removed because *@clean* does not know how to resolve the path > "/patches/java.xml/..?. > > To sum up, this test creates a temporary java.xml patch that needs to be > ignored after compiling *DocumentImpl. *I am using??patch-module because > it?s more flexible than @compile/module > * > * > Hope I explained myself! > > >> On 8 May 2020, at 15:49, Daniel Fuchs > > wrote: >> >> On 08/05/2020 15:40, Alan Bateman wrote: >>>> ? 31 /* >>>> ? 32? * @test >>>> ? 33? * @bug 8035437 >>>> ? 34? * @summary Tests that java.lang.AbstractMethodError is not >>>> thrown when >>>> ? 35? * serializing improper version of DocumentImpl class. >>>> ? 36? * @library /test/lib >>>> ????? * @modules javax.xml/org.w3c.dom >>>> ????? *????????? javax.xml/com.sun.org.apache.xerces.internal.dom >>>> ? 40? * @run main/othervm --patch-module java.xml=${test.class.path} >>>> AbstractMethodErrorTest >>>> ? 41? */ >>>> >>>> (not 100% sure the @modules is even needed) >>> I wouldn't expect to need --patch-module here. Instead maybe it could >>> be changed to use @compile/module=java.xml ... and jtreg should >>> compile and run the overrides "as if" they are in the java.xml >>> module. There are a couple of examples of this in the test suite that >>> might help get this going. No need for javax.xml/org.w3c.dom as that >>> package is already exported. >> >> Right. Copy paste error. The --patch-module shouldn't be needed >> anywhere. Good point about @compile - the main class >> AbstractMethodErrorTest is not in the patched module, so >> the patched classes may not get compiled if you don't force >> their compilation. >> >> Thanks for the correction Alan! >> >> -- daniel > From fernando.guallini at oracle.com Fri May 8 17:49:57 2020 From: fernando.guallini at oracle.com (Fernando Guallini) Date: Fri, 8 May 2020 18:49:57 +0100 Subject: RFR: JDK-8209774 - [TESTBUG]Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java In-Reply-To: <3e64642d-0e55-61e7-c0c7-9e0582b16691@oracle.com> References: <4F6C2290-A3AE-4A93-BE99-D057C9CEC778@oracle.com> <54095829-fd05-267f-3330-deb6a8c213b8@oracle.com> <2a03d73b-e7d9-2799-dedd-7d4f097a3309@oracle.com> <5BA24215-81C0-4540-B425-DD9167FBFF44@oracle.com> <3e64642d-0e55-61e7-c0c7-9e0582b16691@oracle.com> Message-ID: Sure, I will add some of the explanation as a comment. Thank you Daniel! > On 8 May 2020, at 18:39, Daniel Fuchs wrote: > > Hi Fernando, > > Ah - I see the keypoint is the: > 39 * @clean org.w3c.dom.* > OK, I missed that. Then I agree - ignore my previous comments. > > Maybe the explanations below should be added to the test in some > comment to help future maintainers (and reviewers). > > best regards, > > -- daniel > > > On 08/05/2020 18:19, Fernando Guallini wrote: >> Hi Daniel and Alan, >> @compile/module=java.xml was my first try, but for the nature of this test, it didn't work. The reason is that the original shell test does the following: >> - Compiles it?s own version of Node and Document interfaces >> - Compiles DocumentImpl patching java.xml with those 2 interfaces >> - Executes the AbstractMethodErrorTest patching the java.xml module *only with DocumentImpl* patch(not including Document and Node) >> It does that by keeping the patches output in different folders. That?s important otherwise AbstractMethodErrorTest doesn?t compile, because it references some methods not declared in its custom interfaces, and it seems to be coded this way to reproduce the original bug. That is also the reason why I added the *@clean* command to remove Document and Node *before* running the test. >> But when using *@compile/module=java.xml*, under the hood, JTREG generates a folder named ?patches/java.xml/..? including all the compiled classes under it. Unfortunately, the temporary interfaces can?t be removed because *@clean* does not know how to resolve the path "/patches/java.xml/..?. >> To sum up, this test creates a temporary java.xml patch that needs to be ignored after compiling *DocumentImpl. *I am using ?patch-module because it?s more flexible than @compile/module >> * >> * >> Hope I explained myself! >>> On 8 May 2020, at 15:49, Daniel Fuchs > wrote: >>> >>> On 08/05/2020 15:40, Alan Bateman wrote: >>>>> 31 /* >>>>> 32 * @test >>>>> 33 * @bug 8035437 >>>>> 34 * @summary Tests that java.lang.AbstractMethodError is not thrown when >>>>> 35 * serializing improper version of DocumentImpl class. >>>>> 36 * @library /test/lib >>>>> * @modules javax.xml/org.w3c.dom >>>>> * javax.xml/com.sun.org.apache.xerces.internal.dom >>>>> 40 * @run main/othervm --patch-module java.xml=${test.class.path} AbstractMethodErrorTest >>>>> 41 */ >>>>> >>>>> (not 100% sure the @modules is even needed) >>>> I wouldn't expect to need --patch-module here. Instead maybe it could be changed to use @compile/module=java.xml ... and jtreg should compile and run the overrides "as if" they are in the java.xml module. There are a couple of examples of this in the test suite that might help get this going. No need for javax.xml/org.w3c.dom as that package is already exported. >>> >>> Right. Copy paste error. The --patch-module shouldn't be needed >>> anywhere. Good point about @compile - the main class >>> AbstractMethodErrorTest is not in the patched module, so >>> the patched classes may not get compiled if you don't force >>> their compilation. >>> >>> Thanks for the correction Alan! >>> >>> -- daniel > From huizhe.wang at oracle.com Fri May 8 18:05:53 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 8 May 2020 11:05:53 -0700 Subject: RFR: JDK-8209774 - [TESTBUG]Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java In-Reply-To: References: <4F6C2290-A3AE-4A93-BE99-D057C9CEC778@oracle.com> <54095829-fd05-267f-3330-deb6a8c213b8@oracle.com> <2a03d73b-e7d9-2799-dedd-7d4f097a3309@oracle.com> <5BA24215-81C0-4540-B425-DD9167FBFF44@oracle.com> <3e64642d-0e55-61e7-c0c7-9e0582b16691@oracle.com> Message-ID: <4be73c77-aac6-1bf8-19ca-b947d2fe5d2f@oracle.com> Hi Fernando, While you add the comment (about compile/run), you may want to update the original comment about the test as well as it mentioned "see run.sh" that is now gone. A minor comment on the header:? a space between the years would be good, that is "2014,2020," -> 2014, 2020, -Joe On 5/8/2020 10:49 AM, Fernando Guallini wrote: > Sure, I will add some of the explanation as a comment. Thank you Daniel! > >> On 8 May 2020, at 18:39, Daniel Fuchs wrote: >> >> Hi Fernando, >> >> Ah - I see the keypoint is the: >> 39 * @clean org.w3c.dom.* >> OK, I missed that. Then I agree - ignore my previous comments. >> >> Maybe the explanations below should be added to the test in some >> comment to help future maintainers (and reviewers). >> >> best regards, >> >> -- daniel >> >> >> On 08/05/2020 18:19, Fernando Guallini wrote: >>> Hi Daniel and Alan, >>> @compile/module=java.xml was my first try, but for the nature of this test, it didn't work. The reason is that the original shell test does the following: >>> - Compiles it?s own version of Node and Document interfaces >>> - Compiles DocumentImpl patching java.xml with those 2 interfaces >>> - Executes the AbstractMethodErrorTest patching the java.xml module *only with DocumentImpl* patch(not including Document and Node) >>> It does that by keeping the patches output in different folders. That?s important otherwise AbstractMethodErrorTest doesn?t compile, because it references some methods not declared in its custom interfaces, and it seems to be coded this way to reproduce the original bug. That is also the reason why I added the *@clean* command to remove Document and Node *before* running the test. >>> But when using *@compile/module=java.xml*, under the hood, JTREG generates a folder named ?patches/java.xml/..? including all the compiled classes under it. Unfortunately, the temporary interfaces can?t be removed because *@clean* does not know how to resolve the path "/patches/java.xml/..?. >>> To sum up, this test creates a temporary java.xml patch that needs to be ignored after compiling *DocumentImpl. *I am using ?patch-module because it?s more flexible than @compile/module >>> * >>> * >>> Hope I explained myself! >>>> On 8 May 2020, at 15:49, Daniel Fuchs > wrote: >>>> >>>> On 08/05/2020 15:40, Alan Bateman wrote: >>>>>> 31 /* >>>>>> 32 * @test >>>>>> 33 * @bug 8035437 >>>>>> 34 * @summary Tests that java.lang.AbstractMethodError is not thrown when >>>>>> 35 * serializing improper version of DocumentImpl class. >>>>>> 36 * @library /test/lib >>>>>> * @modules javax.xml/org.w3c.dom >>>>>> * javax.xml/com.sun.org.apache.xerces.internal.dom >>>>>> 40 * @run main/othervm --patch-module java.xml=${test.class.path} AbstractMethodErrorTest >>>>>> 41 */ >>>>>> >>>>>> (not 100% sure the @modules is even needed) >>>>> I wouldn't expect to need --patch-module here. Instead maybe it could be changed to use @compile/module=java.xml ... and jtreg should compile and run the overrides "as if" they are in the java.xml module. There are a couple of examples of this in the test suite that might help get this going. No need for javax.xml/org.w3c.dom as that package is already exported. >>>> Right. Copy paste error. The --patch-module shouldn't be needed >>>> anywhere. Good point about @compile - the main class >>>> AbstractMethodErrorTest is not in the patched module, so >>>> the patched classes may not get compiled if you don't force >>>> their compilation. >>>> >>>> Thanks for the correction Alan! >>>> >>>> -- daniel From brent.christian at oracle.com Fri May 8 18:04:32 2020 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 8 May 2020 11:04:32 -0700 Subject: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes In-Reply-To: <220837ff2ee9039fd466089e9a77d8000d9bab70.camel@paratix.ch> References: <44EE1961-6729-4F96-8885-439FED393A81@oracle.com> <026cd2c446b0133fb8a9ec59c4fc3032a04de3fb.camel@paratix.ch> <10485888-3ac8-c967-0131-08fe52d2694d@oracle.com> <6a4e59d2e0028d80da9655cb1f724697bd516461.camel@paratix.ch> <1d249f65-8086-4806-ef91-d7ecdfcf15bc@oracle.com> <220837ff2ee9039fd466089e9a77d8000d9bab70.camel@paratix.ch> Message-ID: Hi, Philipp. Sorry for the further delay. Just to step back a bit: The current manifest-writing behavior dates back to JDK 1.2 (at least), so compatibility is an overriding concern. It is unfortunate that multi-byte characters weren't better accounted for in the placement of line breaks from the beginning. But typically in cases like this, we would update the specification to fit the long-standing behavior, and avoid the risk of breaking applications in the wild. We can test that manifests written with your changes can be read by the JDK. But there is also manifest-reading code external to the JDK. Some examples, that would need to be investigated: jarmanifest https://pypi.org/project/jarmanifest/ Chromium https://chromium.googlesource.com/external/googleappengine/python/+/7e0ab775c587657f0f93a3134f2db99e46bb98bd/google/appengine/tools/jarfile.py Maven http://maven.apache.org/shared/maven-archiver/index.html Apache Ant https://en.wikipedia.org/wiki/JAR_(file_format)#Apache_Ant_Zip/JAR_support IDEs would be another good place to check, and maybe also consumers of JavaEE WAR / EAR files. Performance is also a consideration. JMH benchmarks would be needed to confirm that reading the new manifest is not slower, and to gauge any regression in Manifest writing performance. So that is the work that would need to be done to support this change. The question then will be if the benefit of this change (seen only outside of running code) outweighs the risk of changing behavior that has not been an issue for 20+ years. It seems unlikely that a strong enough case could be made. -Brent On 4/13/20 10:29 AM, Philipp Kunz wrote: > Hi Naoto, > You are absolutely right to raise the question. I've also thought about > this but haven't come up so far with a compellingly elegant solution, > at least not yet. > If only String.isLatin1 was public that would come in very handy. > Character or anything else I looked at cannot tell if a string is > ascii. BreakIterator supports iterating backwards so we could start at > the potential line end but that requires a start position that is a > boundary to start with and that is not obviously possible due to the > regional indicators and probably other code points requiring stateful > processing. Same with regexes and I wouldn't know how to express groups > that could count bytes. It does not even seem to be possible to guess > any number of characters to start searching for a boundary because of > the statefulness. Even the most simple approach to detect latin1 > Strings requires an encoding or a regex such as "[^\\p{ASCII}]" which > essentially is another inefficient loop. It also does not work to > encode the string into UTF-8 in a single pass because then it is not > known which grapheme boundary matches to which byte position. I also > tried to write the header names and the ": " delimiter without breaking > first but it did not seem to significantly affect performance. > UTF_8.newEncoder cannot process single surrogates, admittedly an edge > case, but required for compatibility. I added a fast path, see patch, > the best way I could think of. Did I miss a better way to tell ascii > strings from others? > What I found actually improving performance is based on the > consideration that strings are composed of primitive chars that will be > encoded into three bytes each maximum always that up to 24 characters > can be passed to writeChar72 at a time reducing the number of > writeChar72 and in turn String.getBytes invocations. The number of > characters that can be passed to writeChar72 is at most the number of > bytes remaining on the current manifest line (linePos) divided by three > but at least one. See attached patch. > Regards,Philipp > > On Mon, 2020-03-30 at 14:31 -0700, naoto.sato at oracle.com wrote: >> Hi Philipp, >> Sorry for the delay. >> On 3/25/20 11:52 AM, Philipp Kunz wrote: >>> Hi Naoto, >>> See another patch attached with Locale.ROOT for the BreakIterator. >>> I will be glad to hear of any feedback. >> >> I wonder how your change affects the performance, as it will do >> String.getBytes(UTF-8) per each character. I think this can >> definitely be improved by adding some fastpath, e.g., for ASCII. The >> usage of the BreakIterator is fine, though. >>> There is another patch [1] around dealing with manifest attributes >>> during application launch. It certainly is related to 6202130 but >>> feels like a distinct set of changes with a slightly different >>> concern. Any opinion as how to proceed with that one? >> >> I am not quite sure which patch you are referring to, but I agree >> that creating an issue would not hurt. >> Naoto >>> Regards,Philipp >>> >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-February/064720.html >>> >>> >>> On Mon, 2020-03-23 at 09:05 -0700, naoto.sato at oracle.com wrote: >>>> Hi Philipp, >>>> Right, Locale.ROOT is more appropriate here by definition, though >>>> theimplementation is the same. >>>> Naoto >>>> On 3/21/20 5:19 AM, Philipp Kunz wrote: >>>>> Hi Naoto and everyone, >>>>> There are almost as many occurrences of Locale.ROOT as >>>>> Locale.US whichmade me wonder which one is more appropriately >>>>> locale-independent andwhich is probably another topic and not >>>>> actually relevant here >>>>> becauseBreakIterator.getCharacterInstance is locale-agnostic as >>>>> far as I can tell. >>>>> See attached patch with another attempt to fix bug 6202130. >>>>> Regards,Philipp >>>>> >>>>> On Tue, 2020-03-10 at 10:45 -0700,naoto.sato at oracle.com >>>>> wrote: >>>>>> Hi Philipp, >>>>>> ..., so using BreakIterator (withLocale.US) is more preferred >>>>>> solution to me. >>>>>> Naoto > > From claes.redestad at oracle.com Fri May 8 19:05:18 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 8 May 2020 21:05:18 +0200 Subject: RFR: 8244624: Improve handling of JarFile META-INF resources In-Reply-To: <86efa64d-a9a2-3942-5847-140ec4ba4692@oracle.com> References: <118bd37e-ba97-bee5-e82e-e2d0dec4dc7f@oracle.com> <86efa64d-a9a2-3942-5847-140ec4ba4692@oracle.com> Message-ID: <96385984-862e-7d56-7107-c2d8a91b60dd@oracle.com> I updated open.01 with a reworked microbenchmark that uses JarFile.getInputStream to trigger the "maybe instantiate the JAR verifier" logic. This exercise the code being optimized in this patch better, while also being a little bit more realistic. Improvements around 1.3x-1.5x across tested jar variants, along with 20-35% allocation reductions. See the source for sampled results. Thanks! /Claes On 2020-05-08 12:57, Claes Redestad wrote: > Hi Max, > > On 2020-05-08 09:08, Weijun Wang wrote: >> JarFile.java: >> >> 734: extra new line? > > Fixed > >> 930: Remove or rewrite the comment. > > Did even better: now that I find the position of the manifest during > initCEN, this method should always call JUZFA.getManifest(this, false); > - which is both a simplification and an optimization. > >> >> ZipFile.java: >> >> 49: seems not used > > Fixed > >> >> Please add links to each other between >> src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java::isBlockOrSF >> and >> src/java.base/share/classes/java/util/zip/ZipFile.java::isSignatureRelated. >> The 2nd method can also be static. >> >> I assume you cannot put ZipFile::isSignatureRelated into >> SignatureFileVerifier.java, right? > > Right, that wouldn't be great for either since ZipFile operates directly > on UTF-8 encoded bytes for performance, while SignatureFileVerifier > works on Strings. > > What we can do though is to add in an assert that the result of > ZF::isSignatureRelated matches that of SFV::isBlockOrSF - which should > ensure. I also added a note to SignatureFileVerifier::isBlockOfSF to > keep these in sync: > > http://cr.openjdk.java.net/~redestad/8244624/open.01/ > > Testing: re-running tier1+2 > >> >> Thanks, >> Max >> >> p.s. How do you run the benchmark test? Both locally and on mach5. > > See doc/testing.md > > Basically: > Configure with --with-jmh (jib does this automatically) > make build-microbenchmark > $JDK/bin/java -jar build/$CONF/images/test/micro/benchmarks.jar JarFileMeta > > Thanks! > > /Claes >> >>> On May 8, 2020, at 5:28 AM, Claes Redestad >>> wrote: >>> >>> Hi, >>> >>> currently during ZipFile creation, we create an int[] array of pointers >>> to META-INF entries. These are then retrieved from three different >>> places in JarFile. >>> >>> However, JarFile is only interested in some combination a few things: >>> the existence of and name of the META-INF/MANIFEST file, the existence >>> of and the names of various signature related files, i.e., files in >>> META-INF that have a suffix such as .EC, .SF, .RSA and .DSA >>> >>> Refactoring the contract between JarFile and ZipFile means we can filter >>> out such entries that we're not interested when opening the file, and >>> also remove the need to create the String for each entries unless we >>> actually want them: >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8244624 >>> Webrev: http://cr.openjdk.java.net/~redestad/8244624/open.00/ >>> >>> This reduces retained footprint of Jar-/ZipFile by slimming down or >>> removing the Source.metanames array entirely, and a significant speed-up >>> in some cases. >>> >>> In the provided microbenchmark, getManifestFromJarWithManifest and >>> getManifestFromJarWithSignatureFiles doesn't call >>> JUZFA.getMetaInfEntryNames but still see small (~5%) speed-up decrease >>> in allocations. >>> >>> getManifestFromJarWithNoManifest exercise JUZFA.getMetaInfEntryNames in >>> the baseline, and now calls JUZFA.getManifestName. Result is a 1.25x >>> speed-up and 30% reduction in allocations. While unrealistic (most JARs >>> have a META-INF/MANIFEST.MF), this speed-up will translate to a few >>> places - such as when loading classes from potentially-signed JAR files. >>> >>> Testing: tier1-2 >>> >>> Thanks! >>> >>> /Claes >> From info at j-kuhn.de Fri May 8 20:37:25 2020 From: info at j-kuhn.de (Johannes Kuhn) Date: Fri, 8 May 2020 22:37:25 +0200 Subject: JDK-8226810: An other case and a small change suggestion In-Reply-To: <625e04bf-b052-1805-772e-1a1411ef5e00@oracle.com> References: <2c1ff9d3-a9a6-800d-bb55-e771f22a3807@j-kuhn.de> <625e04bf-b052-1805-772e-1a1411ef5e00@oracle.com> Message-ID: Thanks. I think strcpy(ret+2, "1252") vs. strcpy(ret, "Cp1252")? is a just matter of style. I would prefer the later, as it makes the intent clear. But not my call. Do you have any info how I can change the detected codepage there? I wrote a small C program that basically just does that part and printf it. In my limited tests (windows likes to require a restart after each configuration change) I did not find a way to influence that. An other thing to consider is if Cp65001 should be treated as UTF-8 in that function? (As said before, locale is not my expertise. Can that function with that LCSID even return 65001?) I can see how things go wrong if it returns 65001 as locale, so... could be a safe change? (I'm sure that things break if that function returns 65001.) Then there is the other part: The mismatch between the comment in jni_util.c/newSizedStringJava and the implementation on the Java side. There is no fallback to iso-8859-1. If new String(byte[]) is called before the system properties are installed, then this will lead to a NullPointerException. And there is a code path that leads to exactly that - newPlatformString is called from the initialization of the properties. [1] And if the encoding returned by the windows function is not supported, then it will call new String(byte[]) - during system property initialization. - Johannes [1]: https://hg.openjdk.java.net/jdk/jdk/file/d40d865753fb/src/java.base/share/native/libjava/System.c#l207 On 08-May-20 18:27, naoto.sato at oracle.com wrote: > Ditto. Good catch! > > I am not sure the fix would address the issue in 8226810 (cannot > confirm it either, as my Windows box is at my office where I cannot > enter at the moment :-), but this definitely looks like a bug. I would > change the additional line to "strcpy(ret+2, "1252");" as Cp is copied > in the following switch. > > Naoto > > > > On 5/7/20 5:50 AM, Alan Bateman wrote: >> On 07/05/2020 12:37, Johannes Kuhn wrote: >>> : >>> >>> In the end, I don't know what causes the bug, or how I can replicate >>> it. >>> I think I did find a likely suspect. >> Good sleuthing. I don't what the conditions are for GetLocaleInfo to >> fail but it does look like that would return possibly non-terminated >> garbage starting with "CP" so we should at least fix that. >> >> The issue in JDK-8226810 might be something else. One of the >> submitters to that issue did engage and provided enough information >> to learn that the locale is zh_CN and also reported that it was >> failing for GB18030. GB18030 is not in java.base so that at least >> explained that report. >> >> -Alan From stuart.marks at oracle.com Fri May 8 20:49:27 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 8 May 2020 13:49:27 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: <4B44293C-2465-4BA7-B6F6-9AAA437760C4@cbfiddle.com> References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> <4B44293C-2465-4BA7-B6F6-9AAA437760C4@cbfiddle.com> Message-ID: <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com> On 5/6/20 5:05 PM, Alan Snyder wrote: > Let me clarify. I was referring to the non-support by the framework, which > restricts membership semantics: > ...[specification text regarding equals()]... OK, thanks for the clarification. > Although the framework provides implementation classes that MAY be used to > create nonconforming collections, these classes are called out as potentially > non-conforming. For example: [IdentityHashMap] > *This class is /not/?a general-purpose |Map|?implementation! While this class > implements the |Map|?interface, it intentionally violates |Map's|?general > contract, which mandates the use of the |equals|?method when comparing objects. > This class is designed for use only in the rare cases wherein reference-equality > semantics are required.* > > And in many places, the implications of non-conformance are also called out: > > *While the object returned by this method implements the |Collection|?interface, > it does /not/?obey |Collection's|?general contract. Like its backing map, the > collection returned by this method defines element equality as > reference-equality rather than object-equality. This affects the behavior of its > |contains|, |remove|?and |containsAll|?methods.* > > The phrase ?affects the behavior? is open ended. It means all bets are off. No, all bets are not off. "All bets are off" isn't an unreasonable interpretation of the current wording of the specification, but in fact the specification is incredibly poorly worded and confusing. Plus there are several out-and-out bugs in the spec. It's also somewhat odd to say that some collection implementations are conforming whereas others aren't. Implementations can have bugs that render them non-conformant to a specification. In this case, though, parts of the specification contradict each other. You could pick part A of the spec and say that part B is "non-conformant" but that really doesn't make sense if you consider the totality of the specification. The fact is that the spec as a whole is self-inconsistent. I intend to fix that. > My point is that (fully) supporting custom membership semantics changes a > fundamental property of the original design and should be approached as a > redesign. It is not a matter of fixing a series of issues one at a time, as you > discover them. Calling these issues semantic bugs when there is no violation of > the specification is leading you down the wrong path, in my opinion. The issue of membership semantics is part of the original design. If you look at the history, the collections framework was added in JDK 1.2, and the JDK 1.2 specification includes both Set and SortedSet. There is the wording in the SortedSet specification that is very similar to what exists today: [edited for brevity] Note that the ordering maintained by a sorted set must be consistent with equals if the sorted set is to correctly implement the Set interface. This is so because the Set interface is defined in terms of the equals operation, but a sorted set performs all element comparisons using its compareTo (or compare) method. The behavior of a sorted set is well-defined even if its ordering is inconsistent with equals; it just fails to obey the general contract of the Set interface. The original designers (including Josh Bloch, and probably others) clearly thought about these issues enough to put that wording in the specification. I don't think they thought through the full implications of this, or at least they didn't write it down, hence the vague wording above. In addition, the issue was forgotten, and over time, bugs were introduced in the system that made things worse. For example, the "optimization" that is the root cause of the bug we are discussing (JDK-6394757) was introduced in JDK 1.3. In the comments on this bug report [1] Bloch is quoted as saying The spec clearly states that removeAll "Removes all this collection's elements that are also contained in the specified collection." So the current behavior is not just unpredictable, it's broken. It worked until 1.3, and was broken in 1.3-1.5. Sigh... (And indeed, AbstractCollection.removeAll does precisely what the Collection.removeAll spec demands) [1] https://bugs.openjdk.java.net/browse/JDK-6394757?focusedCommentId=12242803&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12242803 Another bug, a spec bug this time, was introduced later. (I haven't searched the history to find out exactly when.) The TreeSet.add() method specification says this: [2] Adds the specified element to this set if it is not already present. More formally, adds the specified element e to this set if the set contains no element e2 such that Objects.equals(e, e2). If this set already contains the element, the call leaves the set unchanged and returns false. [2] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/util/TreeSet.html#add(E) This is simply wrong, as TreeSet membership is determined by the comparison method, not by equals(). > What would (full) support for custom membership semantics look like? What > restrictions would you place on the contains() method? What axioms would you > specify for the generic operations? Is substitutability tossed out the window? > What does it mean for an object to be a member of a set (according to contains) > but not be returned by the iterator or included in the size? What should > Set.copyOf() do if its argument is a non-conforming collection? etc. etc. I think it's fair to raise all of these questions if "all bets are off" but indeed all bets are not off. I think the root of the problem is in the statement from the specification, The behavior of a sorted set is well-defined even if its ordering is inconsistent with equals; it just fails to obey the general contract of the Set interface. This statement is essentially impossible to understand without looking at the history, various bugs (such as this one), the design intent of the collections framework, etc. What it really means is the following. A SortedSet being "well-defined" answers most of your questions above. The obvious axioms all still apply. If you add an element and add() returns true, then contains() on that element should return true, and iterating the set should at some point return that element, etc. The "general contract" phrase that appears in several places doesn't mean "the totality of the Set interface" but instead it means specifically what we've been calling the "membership contract" of the set. That is, Sets contain no pair of elements e1 and e2 such that e1 $ e2. Where $ is: compare(e1, e2) == 0 for SortedSet == for sets built from IdentityHashMap equals() for Sets excluding the above Once it's clear that "general contract" really means membership contract, many things become clearer. Most bets in fact are still on. Issues arise only when there are cases where there are two sets at play, and the question of which set's membership contract is in use needs to be specified. For copy constructors, Set.copyOf, and addAll(), it's clear that elements are added according to the receiver's membership contract. Other methods require a bit more analysis: containsAll() equals() removeAll() retainAll() The containsAll() and equals() methods both use the membership contract of the receiver, not the argument. Unfortunately, the equals() specification says, Returns true if the specified object is also a set, the two sets have the same size, and every member of the specified set is contained in this set (or equivalently, every member of this set is contained in the specified set). As should be clear from this discussion, the "equivalently" clause is incorrect -- another spec bug. Finally, removeAll() and retainAll() use the membership semantics of the argument. I've discussed this elsewhere in this thread. To summarize, fixing this bug is part of a larger effort to clean up various ambiguities and bugs in the specifications, as well as bugs in implementations. The fact that I'm proceeding incrementally shouldn't be interpreted to mean that I'm fixing semantic issues one by one as I come across them. > I understand that trade-offs are necessary, and if I understand correctly, the > CSR process should review intentional regressions. Do you agree? Yes, I will definitely file a CSR for this, to include specification changes as well as the behavioral and performance tradeoffs. s'marks From naoto.sato at oracle.com Fri May 8 21:19:13 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 8 May 2020 14:19:13 -0700 Subject: JDK-8226810: An other case and a small change suggestion In-Reply-To: References: <2c1ff9d3-a9a6-800d-bb55-e771f22a3807@j-kuhn.de> <625e04bf-b052-1805-772e-1a1411ef5e00@oracle.com> Message-ID: <43dd09ed-8058-8552-b5ed-ade74acc765d@oracle.com> Hi Johannes, On 5/8/20 1:37 PM, Johannes Kuhn wrote: > Thanks. > > I think strcpy(ret+2, "1252") vs. strcpy(ret, "Cp1252")? is a just > matter of style. I would prefer the later, as it makes the intent clear. > But not my call. I thought the former was clearer, as at that point, Cp/MS/GB part is not initialized in normal cases. It follows that pattern. > > Do you have any info how I can change the detected codepage there? I > wrote a small C program that basically just does that part and printf it. > In my limited tests (windows likes to require a restart after each > configuration change) I did not find a way to influence that. Have you tried changing the Windows System Locale to Japanese? I am pretty sure the code will return MS932. > > An other thing to consider is if Cp65001 should be treated as UTF-8 in > that function? > (As said before, locale is not my expertise. Can that function with that > LCSID even return 65001?) > I can see how things go wrong if it returns 65001 as locale, so... could > be a safe change? (I'm sure that things break if that function returns > 65001.) Yes it should return UTF-8, which is not implemented. If the code page is 65001, then the following switch should put UTF-8 as the default charset. > > Then there is the other part: > The mismatch between the comment in jni_util.c/newSizedStringJava and > the implementation on the Java side. > There is no fallback to iso-8859-1. If new String(byte[]) is called > before the system properties are installed, then this will lead to a > NullPointerException. > And there is a code path that leads to exactly that - newPlatformString > is called from the initialization of the properties. [1] > And if the encoding returned by the windows function is not supported, > then it will call new String(byte[]) - during system property > initialization. I would expect there shouldn't be a mismatch, i.e., all the default system locale in Windows should return *known* default charset. Returning UTF-8 in java_props_md.c should resolve this. Naoto > > - Johannes > > [1]: > https://hg.openjdk.java.net/jdk/jdk/file/d40d865753fb/src/java.base/share/native/libjava/System.c#l207 > > On 08-May-20 18:27, naoto.sato at oracle.com wrote: >> Ditto. Good catch! >> >> I am not sure the fix would address the issue in 8226810 (cannot >> confirm it either, as my Windows box is at my office where I cannot >> enter at the moment :-), but this definitely looks like a bug. I would >> change the additional line to "strcpy(ret+2, "1252");" as Cp is copied >> in the following switch. >> >> Naoto >> >> >> >> On 5/7/20 5:50 AM, Alan Bateman wrote: >>> On 07/05/2020 12:37, Johannes Kuhn wrote: >>>> : >>>> >>>> In the end, I don't know what causes the bug, or how I can replicate >>>> it. >>>> I think I did find a likely suspect. >>> Good sleuthing. I don't what the conditions are for GetLocaleInfo to >>> fail but it does look like that would return possibly non-terminated >>> garbage starting with "CP" so we should at least fix that. >>> >>> The issue in JDK-8226810 might be something else. One of the >>> submitters to that issue did engage and provided enough information >>> to learn that the locale is zh_CN and also reported that it was >>> failing for GB18030. GB18030 is not in java.base so that at least >>> explained that report. >>> >>> -Alan > > From brent.christian at oracle.com Fri May 8 23:27:07 2020 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 8 May 2020 16:27:07 -0700 Subject: JDK-8226810: An other case and a small change suggestion In-Reply-To: References: <2c1ff9d3-a9a6-800d-bb55-e771f22a3807@j-kuhn.de> Message-ID: On 5/7/20 5:50 AM, Alan Bateman wrote: > On 07/05/2020 12:37, Johannes Kuhn wrote: >> : >> >> In the end, I don't know what causes the bug, or how I can replicate it. >> I think I did find a likely suspect. > > Good sleuthing. I don't what the conditions are for GetLocaleInfo to > fail but it does look like that would return possibly non-terminated > garbage starting with "CP" so we should at least fix that. I agree. I can file a bug and sponsor this small change. -Brent From andy.herrick at oracle.com Fri May 8 23:34:38 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 8 May 2020 19:34:38 -0400 Subject: RFR: JDK-8244620: test failure in WinUpgradeUUIDTest In-Reply-To: References: Message-ID: <119a3df2-3f1a-a6a7-b32e-48f3ead9a5af@oracle.com> Revised webrev at [3] - this fixes the test problem that was caused by the test assuming wix tools are on all systems. /Andy [3] - http://cr.openjdk.java.net/~herrick/8244620/webrev.02/ On 5/7/2020 4:23 PM, Andy Herrick wrote: > please review fix for issue [1] at [2]. > > /Andy > > [1] - https://bugs.openjdk.java.net/browse/JDK-8244620 > > [2] - http://cr.openjdk.java.net/~herrick/8244620/webrev.01/ > From jason_mehrens at hotmail.com Sat May 9 01:46:44 2020 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Sat, 9 May 2020 01:46:44 +0000 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> , <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> Message-ID: Stuart, I assume Deque/Queue would suffer the same issue as List. It would be nice to some how ensure ArrayDeque.contains is not called as far as the heuristic goes. Looks like PriorityQueue uses equals for contains but that is not to say there are not other queue implementations in the wild that do something different. The more I think about it in general, it seems like your task would be easier if you could declare: 1. AbstractCollection.removeAll should assume this.contains is O(N) and iterate over this and check contains on arg. 2. AbstractSet.removeAll should iterate over argument and assume that this.contains/remove is at least O(log (N)) and assume argument.contains is O(N). 3. Concrete implementations of removeAll know the cost of their contains method. If it is known to be O(N) then walk this otherwise walk the arg. 4. Include an example in removeAll that says if membership semantics differ between sets use: source.removeIf(e -> removals.contains(e)); or removals.forEach(e -> source.remove(e)); instead. If they don't differ then use removeAll. Given this has been around since JDK 1.3 would it be safe to assume that code that is mixing collections with different membership semantics is already working around this issue and therefore the risk is a bit lower in changing the spec? Lots of concrete implementations already override removeAll anyway. Jason ________________________________________ From: core-libs-dev on behalf of Stuart Marks Sent: Monday, May 4, 2020 7:25 PM To: Jason Mehrens Cc: core-libs-dev Subject: Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes On 5/1/20 10:41 PM, Jason Mehrens wrote: > 1. I assume you are using "c instanceof List" instead of "!(c instanceof Set)" to correctly handle IdentitityHashMap.values()? The instanceof List seems like safe choice but it is too bad we can still fool that check by wrapping List as an unmodifiableCollection. If splitIterator().characteristics() could tell us that the collection used identity comparisons I think we would be able to determine if it was safe to swap the ordering in the general case as we could check for IDENTITY, SORTED, and comparator equality. I'm using "instance List", not for the reason of IdentityHashMap.values() specifically (though that's a good example), but mainly to try to be minimal. While I think getting the semantics right takes priority, the change does impact performance, so I want to reintroduce the performance heuristic in the safest manner possible. Checking for !Set seems dangerous, as there might be any number of Collections out there that aren't Sets and that aren't consistent with equals. Checking for instanceof List seemed like the safest and most minimal thing to do. In fact, I'm not even sure how safe List is! It's certainly possible for someone to have a List that isn't consistent with equals. Such a thing might violate the List contract, but that hasn't stopped people from implementing such things (outside the JDK). I also toyed around with various additional tests for when it would be profitable to switch iteration to the smaller collection. This could be applied to a variety of consistent-with-equals set implementations in the JDK. The benefits of swapping the iteration is more modest in these cases compared to List, however. Avoiding repeated List.contains() helps avoid quasi-quadratic (O(M*N)) performance. Swapping iteration order of sets gets us only the smaller of O(M) vs O(N), which is still linear. Also, as you noted, this heuristic is easily defeated by things like the collection wrappers. > 2. Should code applied to HashSet.removeAll also be applied to HashMap.keySet().removeAll and HashMap.entrySet().removeAll? Collections::newSetFromMap will end up having different behavior if it is not consistently applied. I think the *results* will be consistent, but the *performance* might not be consistent. But these cases could result in pathological performance if removeAll(list) is called, so I'm a bit concerned about them. If we agree that "instanceof List" is a reasonable heuristic, then I don't have any objection in principle to adding it to these locations as well. But I want to be careful about sprinkling ad hoc policies like this around the JDK. I note that the erroneous size-based optimization was copied into, and therefore needs to be removed from ConcurrentSkipListSet (JDK-8218945) and the set views of CHM (JDK-8219069). I'd more concerned about getting these cleaned up in the short term. > 3. Not to derail this thread but do think we need a new JIRA ticket to address Collections.disjoint? Seems like it has similar sins of calling size and using "!(c2 instanceof Set)" but I don't want to muddy the waters by covering any solutions to that method in this thread. Yeah I'm not sure what to do about Collections.disjoint(). Note that there are some statements in bug reports (possibly even made by me!) that assert that Collections.disjoint should be consistent with Set.removeAll. I don't think that's the case. As discussed elsewhere, removeAll() needs to be consistent about relying on the membership semantics of the argument collection. As Collections.disjoint currently stands, it has the big "Care must be exercised" disclaimer in its spec, and it goes to some length to make a bunch of tests and vary the iteration accordingly. The programmer can get a speedup using disjoint() compared to copying a set and then calling retainAll(), provided sufficient care is taken. Maybe that's an acceptable tradeoff. If you have any ideas about how disjoint()'s spec or implementation could be improved, you could file a JIRA issue, or I could file one if you sent me the info. s'marks From javalists at cbfiddle.com Sat May 9 02:32:48 2020 From: javalists at cbfiddle.com (Alan Snyder) Date: Fri, 8 May 2020 19:32:48 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com> References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> <4B44293C-2465-4BA7-B6F6-9AAA437760C4@cbfiddle.com> <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com> Message-ID: I believe I can agree with you on a number of points. ? The specification is confusing. ? The problem areas involve the ?membership contract?. ? There may have been some intent initially to support multiple membership semantics (this was new to me). ? There are inconsistencies in the specification (but we may disagree on where the inconsistencies are). You say: It's also somewhat odd to say that some collection implementations are conforming whereas others aren't. Yes, it is odd, but I would say that the design is odd, and it is odd by choice. Here?s the situation: You have an abstract class or interface A and a concrete class C. The specification of class C depends upon certain parameters, such as the implementation of an abstract method or the choice of a type parameter or the choice of a constructor parameter. Some uses of C produce a specification that is consistent with the specification of A, but others produce specifications that are inconsistent with the specification of A. As the designer of A and C, you have to make a choice: ? C does not extend or implement A. This choice makes the question of conformance moot. Even if a particular instance of C conforms to the specification of A, the type system prevents it from being used as an A. (I?m ignoring the extra complexity that arises if A is an interface and someone creates a subclass of C that implements A.) ? Define C to extend or implement A. This choice allows any instance of C to be used as an A, even the ones that do not conform to the specification of A. The first choice avoids all of the problems we have been discussing, but it rules out cases that have no problems with non-conformance. Presumably on the grounds of greater utility, the designers of the Collection framework (or their successors) chose the second option for several concrete classes (the ones we have been discussing). Recognizing the issue of non-conformance, they chose to document it (often using bold type). Documentation is the best they could do given that it is not possible in general to detect improper use of non-conforming objects either at compile time or at run time. If you believe that the possibility of non-conforming instances is inherently inconsistent and inconsistency must be fixed, then the only options are to remove the inheritance link or to weaken A so that C always conforms to A. I?m not sure that either option is practical in this case. You quote the specification: The behavior of a sorted set is well-defined even if its ordering is inconsistent with equals; it just fails to obey the general contract of the Set interface. This is exactly the case above, with A=Set and C=TreeSet. (Actually, as the specification of TreeSet does not change the specifications of the basic methods in any significant way, it would more accurate to say that the TreeSet implementation does not conform to the TreeSet specification. That is certainly inconsistent, but it could be fixed by changing the specification of TreeSet, as you implied.) You say: The issue of membership semantics is part of the original design. I agree, but only to the point of identifying inconsistent membership semantics as a source of non-conformance. What is not part of the original design is allowing a broader range of membership semantics to be conformant, which I assume is what you want. Another point of disagreement involves the specification of membership, especially in the case of Set, which I believe is where the problems arise. I?m not completely sure what you are thinking, but it sounds like you believe that membership is defined by the implementation of the contains() method. I believe that is incorrect (i.e., not implied by the current specification). When I read the specification of Set, the only way I can make sense of it is that the specification of Set is defined in terms of mathematical sets. Consider the ?more formal? definition of contains(): More formally, returns true if and only if this set contains an element e such that Objects.equals(o, e). Clearly, it would make no sense to define the contains() method in terms of itself. But it does make sense to say that the current state of a Set is a mathematical set of instances such that no pair of instances returns true from e1.equals(e2). I believe that is what the specification is trying to say, however imperfectly. So, rather that *defining* set membership, the contains() method *reveals* it. Other methods also reveal set membership, such as the iterator, or compute values that depend upon set membership, such as size() and hashCode(). They are defined in terms of ?the elements of the set?, i.e., the mathematical set of instances that satisfies the equals rule. The add() method specification also depends upon set membership, and it has the interesting property that it is defined to add at most one element to the (mathematical) set of instances. The non-conforming sets are non-conforming in these basic operations: add(), size(), iterator(), as well as operations derived from those basic operations, such as hashCode(). Consider the classic example, a TreeSet of Strings that is case-insensitive. If I add one string ?hello? to an empty TreeSet, how many elements does it contain? The specification of add() says one. The size() method returns one. The iterator returns one element. But the contains() method returns true for multiple non-equal objects. Oops. In other words, a case-insensitive TreeSet does not conform to the specification of Collection or Set (or even TreeSet, but that could be fixed). What I conclude from this exercise: ? As set membership is not defined by the implementation of the contains() method, the problematic removeAll() implementation is not broken just because it does not call contains() on the argument. Using iteration, hashCode() and equals() is a valid alternative, according to the current specification of Collection and Set. ? The problems of non-conforming collections are larger than you think. It is *not* the case that all of the basic axioms still apply. ? This history of the design is not required to understand how a comparator that is inconsistent with equals() leads to non-conformance. ? If you are proposing to define set membership programmatically in terms of the implementation of the contains() method, that would be a very large change indeed. I would want to evaluate the complete solution before evaluating individual changes. In case it is not obvious, there are workarounds that any developer can use to avoid creating non-conforming collections. To create a conforming case-insensitive TreeSet of Strings, for example, define a wrapper class for Strings that implements case-insensitive equals and hashCode. To create a conforming IdentityHashMap of Strings, for example, define a wrapper class for Strings that canonicalizes them at least to the point that no two equal instances ever co-exist. Alan > On May 8, 2020, at 1:49 PM, Stuart Marks wrote: > > > > On 5/6/20 5:05 PM, Alan Snyder wrote: >> Let me clarify. I was referring to the non-support by the framework, which restricts membership semantics: >> ...[specification text regarding equals()]... > > OK, thanks for the clarification. > >> Although the framework provides implementation classes that MAY be used to create nonconforming collections, these classes are called out as potentially non-conforming. For example: > > [IdentityHashMap] > >> *This class is /not/ a general-purpose |Map| implementation! While this class implements the |Map| interface, it intentionally violates |Map's| general contract, which mandates the use of the |equals| method when comparing objects. This class is designed for use only in the rare cases wherein reference-equality semantics are required.* >> And in many places, the implications of non-conformance are also called out: >> *While the object returned by this method implements the |Collection| interface, it does /not/ obey |Collection's| general contract. Like its backing map, the collection returned by this method defines element equality as reference-equality rather than object-equality. This affects the behavior of its |contains|, |remove| and |containsAll| methods.* >> The phrase ?affects the behavior? is open ended. It means all bets are off. > > No, all bets are not off. > > "All bets are off" isn't an unreasonable interpretation of the current wording of the specification, but in fact the specification is incredibly poorly worded and confusing. Plus there are several out-and-out bugs in the spec. > > It's also somewhat odd to say that some collection implementations are conforming whereas others aren't. Implementations can have bugs that render them non-conformant to a specification. In this case, though, parts of the specification contradict each other. You could pick part A of the spec and say that part B is "non-conformant" but that really doesn't make sense if you consider the totality of the specification. The fact is that the spec as a whole is self-inconsistent. I intend to fix that. > >> My point is that (fully) supporting custom membership semantics changes a fundamental property of the original design and should be approached as a redesign. It is not a matter of fixing a series of issues one at a time, as you discover them. Calling these issues semantic bugs when there is no violation of the specification is leading you down the wrong path, in my opinion. > > The issue of membership semantics is part of the original design. > > If you look at the history, the collections framework was added in JDK 1.2, and the JDK 1.2 specification includes both Set and SortedSet. There is the wording in the SortedSet specification that is very similar to what exists today: [edited for brevity] > > Note that the ordering maintained by a sorted set must be consistent with > equals if the sorted set is to correctly implement the Set interface. > This is so because the Set interface is defined in terms of the equals > operation, but a sorted set performs all element comparisons using its > compareTo (or compare) method. The behavior of a sorted set is well-defined > even if its ordering is inconsistent with equals; it just fails to obey the > general contract of the Set interface. > > The original designers (including Josh Bloch, and probably others) clearly thought about these issues enough to put that wording in the specification. I don't think they thought through the full implications of this, or at least they didn't write it down, hence the vague wording above. > > In addition, the issue was forgotten, and over time, bugs were introduced in the system that made things worse. For example, the "optimization" that is the root cause of the bug we are discussing (JDK-6394757) was introduced in JDK 1.3. In the comments on this bug report [1] Bloch is quoted as saying > > The spec clearly states that removeAll "Removes all this collection's > elements that are also contained in the specified collection." So the > current behavior is not just unpredictable, it's broken. It worked until > 1.3, and was broken in 1.3-1.5. Sigh... > > (And indeed, AbstractCollection.removeAll does precisely what the > Collection.removeAll spec demands) > > [1] https://bugs.openjdk.java.net/browse/JDK-6394757?focusedCommentId=12242803&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12242803 > > Another bug, a spec bug this time, was introduced later. (I haven't searched the history to find out exactly when.) The TreeSet.add() method specification says this: [2] > > Adds the specified element to this set if it is not already present. More > formally, adds the specified element e to this set if the set contains no > element e2 such that Objects.equals(e, e2). If this set already contains the > element, the call leaves the set unchanged and returns false. > > [2] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/util/TreeSet.html#add(E) > > This is simply wrong, as TreeSet membership is determined by the comparison method, not by equals(). > >> What would (full) support for custom membership semantics look like? What restrictions would you place on the contains() method? What axioms would you specify for the generic operations? Is substitutability tossed out the window? What does it mean for an object to be a member of a set (according to contains) but not be returned by the iterator or included in the size? What should Set.copyOf() do if its argument is a non-conforming collection? etc. etc. > > I think it's fair to raise all of these questions if "all bets are off" but indeed all bets are not off. I think the root of the problem is in the statement from the specification, > > The behavior of a sorted set is well-defined even if its ordering is > inconsistent with equals; it just fails to obey the general contract > of the Set interface. > > This statement is essentially impossible to understand without looking at the history, various bugs (such as this one), the design intent of the collections framework, etc. What it really means is the following. > > A SortedSet being "well-defined" answers most of your questions above. The obvious axioms all still apply. If you add an element and add() returns true, then contains() on that element should return true, and iterating the set should at some point return that element, etc. > > The "general contract" phrase that appears in several places doesn't mean "the totality of the Set interface" but instead it means specifically what we've been calling the "membership contract" of the set. That is, > > Sets contain no pair of elements e1 and e2 such that e1 $ e2. > > Where $ is: > > compare(e1, e2) == 0 for SortedSet > == for sets built from IdentityHashMap > equals() for Sets excluding the above > > Once it's clear that "general contract" really means membership contract, many things become clearer. Most bets in fact are still on. Issues arise only when there are cases where there are two sets at play, and the question of which set's membership contract is in use needs to be specified. For copy constructors, Set.copyOf, and addAll(), it's clear that elements are added according to the receiver's membership contract. Other methods require a bit more analysis: > > containsAll() > equals() > removeAll() > retainAll() > > The containsAll() and equals() methods both use the membership contract of the receiver, not the argument. Unfortunately, the equals() specification says, > > Returns true if the specified object is also a set, the two sets have the > same size, and every member of the specified set is contained in this set > (or equivalently, every member of this set is contained in the specified > set). > > As should be clear from this discussion, the "equivalently" clause is incorrect -- another spec bug. > > Finally, removeAll() and retainAll() use the membership semantics of the argument. I've discussed this elsewhere in this thread. > > To summarize, fixing this bug is part of a larger effort to clean up various ambiguities and bugs in the specifications, as well as bugs in implementations. The fact that I'm proceeding incrementally shouldn't be interpreted to mean that I'm fixing semantic issues one by one as I come across them. > >> I understand that trade-offs are necessary, and if I understand correctly, the CSR process should review intentional regressions. Do you agree? > > Yes, I will definitely file a CSR for this, to include specification changes as well as the behavioral and performance tradeoffs. > > s'marks > From javalists at cbfiddle.com Sat May 9 02:40:59 2020 From: javalists at cbfiddle.com (Alan Snyder) Date: Fri, 8 May 2020 19:40:59 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> Message-ID: > On May 8, 2020, at 6:46 PM, Jason Mehrens wrote: > > Given this has been around since JDK 1.3 would it be safe to assume that code that is mixing collections with different membership semantics is already working around this issue and therefore the risk is a bit lower in changing the spec? Lots of concrete implementations already override removeAll anyway. Hi Jason, I agree that it is safe to say that existing code that is mixing collections with different membership semantics is already working around this issue, but from that I would conclude that it is hard to justify any changes that risk breaking existing code. It's the code that is not mixing membership semantics that I am concerned about breaking. The main advantage of improving the framework is reducing the size of the tarpit that developers can fall into. Alan From lance.andersen at oracle.com Sat May 9 18:27:36 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Sat, 9 May 2020 14:27:36 -0400 Subject: RFR: 8244624: Improve handling of JarFile META-INF resources In-Reply-To: <86efa64d-a9a2-3942-5847-140ec4ba4692@oracle.com> References: <118bd37e-ba97-bee5-e82e-e2d0dec4dc7f@oracle.com> <86efa64d-a9a2-3942-5847-140ec4ba4692@oracle.com> Message-ID: <86CB9FBC-722D-4A2F-ACEF-42AA63BE339B@oracle.com> Hi Claes, I think this looks good. One suggestion before you finalize and push, perhaps update the comment in ZipFile ???? // Use the "oldest ASCII trick in the book" ????? to include something that this is for lowercase comparison. It just might help others when they look at the code and do not know the trick ;-) What made me think about this was the addition of isManifestName() which also uses this means to lowercase. Best Lance > On May 8, 2020, at 6:57 AM, Claes Redestad wrote: > > Hi Max, > > On 2020-05-08 09:08, Weijun Wang wrote: >> JarFile.java: >> 734: extra new line? > > Fixed > >> 930: Remove or rewrite the comment. > > Did even better: now that I find the position of the manifest during > initCEN, this method should always call JUZFA.getManifest(this, false); > - which is both a simplification and an optimization. > >> ZipFile.java: >> 49: seems not used > > Fixed > >> Please add links to each other between src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java::isBlockOrSF and src/java.base/share/classes/java/util/zip/ZipFile.java::isSignatureRelated. The 2nd method can also be static. >> I assume you cannot put ZipFile::isSignatureRelated into SignatureFileVerifier.java, right? > > Right, that wouldn't be great for either since ZipFile operates directly > on UTF-8 encoded bytes for performance, while SignatureFileVerifier > works on Strings. > > What we can do though is to add in an assert that the result of > ZF::isSignatureRelated matches that of SFV::isBlockOrSF - which should > ensure. I also added a note to SignatureFileVerifier::isBlockOfSF to > keep these in sync: > > http://cr.openjdk.java.net/~redestad/8244624/open.01/ > > Testing: re-running tier1+2 > >> Thanks, >> Max >> p.s. How do you run the benchmark test? Both locally and on mach5. > > See doc/testing.md > > Basically: > Configure with --with-jmh (jib does this automatically) > make build-microbenchmark > $JDK/bin/java -jar build/$CONF/images/test/micro/benchmarks.jar JarFileMeta > > Thanks! > > /Claes >>> On May 8, 2020, at 5:28 AM, Claes Redestad wrote: >>> >>> Hi, >>> >>> currently during ZipFile creation, we create an int[] array of pointers >>> to META-INF entries. These are then retrieved from three different >>> places in JarFile. >>> >>> However, JarFile is only interested in some combination a few things: >>> the existence of and name of the META-INF/MANIFEST file, the existence >>> of and the names of various signature related files, i.e., files in >>> META-INF that have a suffix such as .EC, .SF, .RSA and .DSA >>> >>> Refactoring the contract between JarFile and ZipFile means we can filter >>> out such entries that we're not interested when opening the file, and >>> also remove the need to create the String for each entries unless we >>> actually want them: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8244624 >>> Webrev: http://cr.openjdk.java.net/~redestad/8244624/open.00/ >>> >>> This reduces retained footprint of Jar-/ZipFile by slimming down or >>> removing the Source.metanames array entirely, and a significant speed-up >>> in some cases. >>> >>> In the provided microbenchmark, getManifestFromJarWithManifest and >>> getManifestFromJarWithSignatureFiles doesn't call >>> JUZFA.getMetaInfEntryNames but still see small (~5%) speed-up decrease >>> in allocations. >>> >>> getManifestFromJarWithNoManifest exercise JUZFA.getMetaInfEntryNames in >>> the baseline, and now calls JUZFA.getManifestName. Result is a 1.25x >>> speed-up and 30% reduction in allocations. While unrealistic (most JARs >>> have a META-INF/MANIFEST.MF), this speed-up will translate to a few >>> places - such as when loading classes from potentially-signed JAR files. >>> >>> Testing: tier1-2 >>> >>> Thanks! >>> >>> /Claes Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From javalists at cbfiddle.com Sun May 10 02:48:04 2020 From: javalists at cbfiddle.com (Alan Snyder) Date: Sat, 9 May 2020 19:48:04 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com> References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> <4B44293C-2465-4BA7-B6F6-9AAA437760C4@cbfiddle.com> <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com> Message-ID: A small point? you might want to reconsider your analysis of Set.copyOf(), as it is a static method and there is no receiver. From info at j-kuhn.de Sun May 10 14:47:46 2020 From: info at j-kuhn.de (Johannes Kuhn) Date: Sun, 10 May 2020 16:47:46 +0200 Subject: JDK-8226810: An other case and a small change suggestion In-Reply-To: References: <2c1ff9d3-a9a6-800d-bb55-e771f22a3807@j-kuhn.de> Message-ID: On 09-May-20 1:27, Brent Christian wrote: > On 5/7/20 5:50 AM, Alan Bateman wrote: >> On 07/05/2020 12:37, Johannes Kuhn wrote: >>> : >>> >>> In the end, I don't know what causes the bug, or how I can replicate >>> it. >>> I think I did find a likely suspect. > > >> Good sleuthing. I don't what the conditions are for GetLocaleInfo to >> fail but it does look like that would return possibly non-terminated >> garbage starting with "CP" so we should at least fix that. > > I agree.? I can file a bug and sponsor this small change. > > -Brent Thank you. After the discussion with Naoto, I would like to change the one line to strcpy(ret + 2, "1252") diff --git a/src/java.base/windows/native/libjava/java_props_md.c b/src/java.base/windows/native/libjava/java_props_md.c --- a/src/java.base/windows/native/libjava/java_props_md.c +++ b/src/java.base/windows/native/libjava/java_props_md.c @@ -73,6 +73,7 @@ ?????????????????????? LOCALE_IDEFAULTANSICODEPAGE, ?????????????????????? ret+2, 14) == 0) { ???????? codepage = 1252; +??????? strcpy(ret + 2, "1252"); ???? } else { ???????? codepage = atoi(ret+2); ???? } I have already signed the OCA. This would be my first patch. Is there anything else you need? I will take a further look into GetLocaleInfo, and try to find a model that works for me (currently thinking about blackbox, can return anything from [1]), and then discussing how to handle all those cases. - Johannes [1]: https://docs.microsoft.com/en-us/windows/win32/intl/code-page-identifiers From martinrb at google.com Sun May 10 19:53:04 2020 From: martinrb at google.com (Martin Buchholz) Date: Sun, 10 May 2020 12:53:04 -0700 Subject: RFR: 8244624: Improve handling of JarFile META-INF resources In-Reply-To: <118bd37e-ba97-bee5-e82e-e2d0dec4dc7f@oracle.com> References: <118bd37e-ba97-bee5-e82e-e2d0dec4dc7f@oracle.com> Message-ID: Thanks for improving the jar/zip code. I wish I had more time to do the same. My own superficial review only adds one small suggestion: add a comment as to why isSignatureRelated never hits a negative index exception. I still like my ancient "ASCII trick" comment. On Thu, May 7, 2020 at 2:34 PM Claes Redestad wrote: > > Hi, > > currently during ZipFile creation, we create an int[] array of pointers > to META-INF entries. These are then retrieved from three different > places in JarFile. > > However, JarFile is only interested in some combination a few things: > the existence of and name of the META-INF/MANIFEST file, the existence > of and the names of various signature related files, i.e., files in > META-INF that have a suffix such as .EC, .SF, .RSA and .DSA > > Refactoring the contract between JarFile and ZipFile means we can filter > out such entries that we're not interested when opening the file, and > also remove the need to create the String for each entries unless we > actually want them: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244624 > Webrev: http://cr.openjdk.java.net/~redestad/8244624/open.00/ > > This reduces retained footprint of Jar-/ZipFile by slimming down or > removing the Source.metanames array entirely, and a significant speed-up > in some cases. > > In the provided microbenchmark, getManifestFromJarWithManifest and > getManifestFromJarWithSignatureFiles doesn't call > JUZFA.getMetaInfEntryNames but still see small (~5%) speed-up decrease > in allocations. > > getManifestFromJarWithNoManifest exercise JUZFA.getMetaInfEntryNames in > the baseline, and now calls JUZFA.getManifestName. Result is a 1.25x > speed-up and 30% reduction in allocations. While unrealistic (most JARs > have a META-INF/MANIFEST.MF), this speed-up will translate to a few > places - such as when loading classes from potentially-signed JAR files. > > Testing: tier1-2 > > Thanks! > > /Claes From claes.redestad at oracle.com Sun May 10 21:07:07 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 10 May 2020 23:07:07 +0200 Subject: RFR: 8244624: Improve handling of JarFile META-INF resources In-Reply-To: References: <118bd37e-ba97-bee5-e82e-e2d0dec4dc7f@oracle.com> Message-ID: Hi Martin, On 2020-05-10 21:53, Martin Buchholz wrote: > Thanks for improving the jar/zip code. thanks! > I wish I had more time to do the same. > My own superficial review only adds one small suggestion: > add a comment as to why isSignatureRelated never hits a negative index > exception. Yes, it's a bit subtle and deserves a comment. > I still like my ancient "ASCII trick" comment. Google "oldest ASCII trick in the book" and the first hit is an article about this trick (or well, the inverse - but it still counts!). :-) Lance only suggested we clarify what that trick is - hope you're OK with that: http://cr.openjdk.java.net/~redestad/8244624/open.02/ /Claes > > On Thu, May 7, 2020 at 2:34 PM Claes Redestad wrote: >> >> Hi, >> >> currently during ZipFile creation, we create an int[] array of pointers >> to META-INF entries. These are then retrieved from three different >> places in JarFile. >> >> However, JarFile is only interested in some combination a few things: >> the existence of and name of the META-INF/MANIFEST file, the existence >> of and the names of various signature related files, i.e., files in >> META-INF that have a suffix such as .EC, .SF, .RSA and .DSA >> >> Refactoring the contract between JarFile and ZipFile means we can filter >> out such entries that we're not interested when opening the file, and >> also remove the need to create the String for each entries unless we >> actually want them: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8244624 >> Webrev: http://cr.openjdk.java.net/~redestad/8244624/open.00/ >> >> This reduces retained footprint of Jar-/ZipFile by slimming down or >> removing the Source.metanames array entirely, and a significant speed-up >> in some cases. >> >> In the provided microbenchmark, getManifestFromJarWithManifest and >> getManifestFromJarWithSignatureFiles doesn't call >> JUZFA.getMetaInfEntryNames but still see small (~5%) speed-up decrease >> in allocations. >> >> getManifestFromJarWithNoManifest exercise JUZFA.getMetaInfEntryNames in >> the baseline, and now calls JUZFA.getManifestName. Result is a 1.25x >> speed-up and 30% reduction in allocations. While unrealistic (most JARs >> have a META-INF/MANIFEST.MF), this speed-up will translate to a few >> places - such as when loading classes from potentially-signed JAR files. >> >> Testing: tier1-2 >> >> Thanks! >> >> /Claes From martinrb at google.com Sun May 10 21:45:27 2020 From: martinrb at google.com (Martin Buchholz) Date: Sun, 10 May 2020 14:45:27 -0700 Subject: RFR: 8244624: Improve handling of JarFile META-INF resources In-Reply-To: References: <118bd37e-ba97-bee5-e82e-e2d0dec4dc7f@oracle.com> Message-ID: Looks good to me! On Sun, May 10, 2020 at 2:07 PM Claes Redestad wrote: > Hi Martin, > > On 2020-05-10 21:53, Martin Buchholz wrote: > > Thanks for improving the jar/zip code. > > thanks! > > > I wish I had more time to do the same. > > My own superficial review only adds one small suggestion: > > add a comment as to why isSignatureRelated never hits a negative index > > exception. > > Yes, it's a bit subtle and deserves a comment. > > > I still like my ancient "ASCII trick" comment. > > Google "oldest ASCII trick in the book" and the first hit is an article > about this trick (or well, the inverse - but it still counts!). :-) > > Lance only suggested we clarify what that trick is - hope you're OK with > that: > > http://cr.openjdk.java.net/~redestad/8244624/open.02/ > > /Claes > > > > > On Thu, May 7, 2020 at 2:34 PM Claes Redestad > wrote: > >> > >> Hi, > >> > >> currently during ZipFile creation, we create an int[] array of pointers > >> to META-INF entries. These are then retrieved from three different > >> places in JarFile. > >> > >> However, JarFile is only interested in some combination a few things: > >> the existence of and name of the META-INF/MANIFEST file, the existence > >> of and the names of various signature related files, i.e., files in > >> META-INF that have a suffix such as .EC, .SF, .RSA and .DSA > >> > >> Refactoring the contract between JarFile and ZipFile means we can filter > >> out such entries that we're not interested when opening the file, and > >> also remove the need to create the String for each entries unless we > >> actually want them: > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8244624 > >> Webrev: http://cr.openjdk.java.net/~redestad/8244624/open.00/ > >> > >> This reduces retained footprint of Jar-/ZipFile by slimming down or > >> removing the Source.metanames array entirely, and a significant speed-up > >> in some cases. > >> > >> In the provided microbenchmark, getManifestFromJarWithManifest and > >> getManifestFromJarWithSignatureFiles doesn't call > >> JUZFA.getMetaInfEntryNames but still see small (~5%) speed-up decrease > >> in allocations. > >> > >> getManifestFromJarWithNoManifest exercise JUZFA.getMetaInfEntryNames in > >> the baseline, and now calls JUZFA.getManifestName. Result is a 1.25x > >> speed-up and 30% reduction in allocations. While unrealistic (most JARs > >> have a META-INF/MANIFEST.MF), this speed-up will translate to a few > >> places - such as when loading classes from potentially-signed JAR files. > >> > >> Testing: tier1-2 > >> > >> Thanks! > >> > >> /Claes > From Alan.Bateman at oracle.com Mon May 11 08:59:25 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 May 2020 09:59:25 +0100 Subject: JDK-8226810: An other case and a small change suggestion In-Reply-To: References: <2c1ff9d3-a9a6-800d-bb55-e771f22a3807@j-kuhn.de> Message-ID: <023c5b7e-ba89-f37b-4da0-c2b3da558d51@oracle.com> On 10/05/2020 15:47, Johannes Kuhn wrote: > : > > After the discussion with Naoto, I would like to change the one line > to strcpy(ret + 2, "1252") > > diff --git a/src/java.base/windows/native/libjava/java_props_md.c > b/src/java.base/windows/native/libjava/java_props_md.c > --- a/src/java.base/windows/native/libjava/java_props_md.c > +++ b/src/java.base/windows/native/libjava/java_props_md.c > @@ -73,6 +73,7 @@ > ?????????????????????? LOCALE_IDEFAULTANSICODEPAGE, > ?????????????????????? ret+2, 14) == 0) { > ???????? codepage = 1252; > +??????? strcpy(ret + 2, "1252"); > ???? } else { > ???????? codepage = atoi(ret+2); > ???? } > > I have already signed the OCA. > This would be my first patch. Is there anything else you need? > > I will take a further look into GetLocaleInfo, and try to find a model > that works for me (currently thinking about blackbox, can return > anything from [1]), > and then discussing how to handle all those cases. It's not clear how conditions are necessary for GetLocaleInfo to fail but good to fix this code path. We should probably create a new issue in JIRA for this as it's not clear that it is the same issue as JDK-8226810. We've been chasing JDK-8226810 for some time but have not been able to find a system where it duplicates. The reports so far suggests is Windows Chinese but most of the people that report the issue to not respond to questions so we can't be sure. One of the reports (see my comment in the bug from June 2019) suggests the code page is 54936, useful information as GB18030 is not in java.base. Once your fix is in then I think we should try to improve the exception message rather than NPE. There may be some of these cases where it should default to UTF-8. -Alan. From Alan.Bateman at oracle.com Mon May 11 09:32:56 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 May 2020 10:32:56 +0100 Subject: RFR: JDK-8209774 - [TESTBUG]Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java In-Reply-To: <5BA24215-81C0-4540-B425-DD9167FBFF44@oracle.com> References: <4F6C2290-A3AE-4A93-BE99-D057C9CEC778@oracle.com> <54095829-fd05-267f-3330-deb6a8c213b8@oracle.com> <2a03d73b-e7d9-2799-dedd-7d4f097a3309@oracle.com> <5BA24215-81C0-4540-B425-DD9167FBFF44@oracle.com> Message-ID: On 08/05/2020 18:19, Fernando Guallini wrote: > Hi Daniel and Alan, > @compile/module=java.xml was my first try, but for the nature of this > test, it didn't work. The reason is that the original shell test does > the following: > - Compiles it?s own version of Node and Document interfaces > - Compiles DocumentImpl patching java.xml with those 2 interfaces > - Executes the AbstractMethodErrorTest patching the java.xml module > *only with DocumentImpl*?patch(not including Document and Node) > > It does that by keeping the patches output in different folders. > That?s important otherwise AbstractMethodErrorTest doesn?t compile, > because it references some methods not declared in its custom > interfaces, and it seems to be coded this way to reproduce the > original bug. That is also the reason why I added the *@clean*?command > to remove Document and Node *before* running the test. > > But when using *@compile/module=java.xml*, under the hood, JTREG > generates a folder named ?patches/java.xml/..? including all the > compiled classes under it. Unfortunately, the temporary interfaces > can?t be removed because *@clean* does not know how to resolve the > path "/patches/java.xml/..?. > > To sum up, this test creates a temporary java.xml patch that needs to > be ignored after compiling *DocumentImpl. *I am using??patch-module > because it?s more flexible than @compile/module > * > * > Hope I explained myself! This may be a question for Joe Wang but I'm curious if this need to override/upgrade W3C DOM API classes dates back to when it was an endorsed standard that could be overridden with the endorsed standards override mechanism. The @bug on the test suggests otherwise but I'm curious if it make any sense with JDK 9+. This doesn't impact the good work to replace the script of course, I'm just curious how separately compilation issue arises here. -Alan From amaembo at gmail.com Mon May 11 09:33:14 2020 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 11 May 2020 16:33:14 +0700 Subject: [PING] RFR: JDK-8244288 Specialized implementations for putIfAbsent, merge, compute* methods in TreeMap derived maps In-Reply-To: References: Message-ID: Hello! A gentle ping: please review https://bugs.openjdk.java.net/browse/JDK-8244288 http://cr.openjdk.java.net/~tvaleev/webrev/8244288/r1/ The details are listed below. With best regards, Tagir Valeev. On Sun, May 3, 2020 at 4:36 PM Tagir Valeev wrote: > > Hello! > > Please review the following change: > https://bugs.openjdk.java.net/browse/JDK-8244288 > http://cr.openjdk.java.net/~tvaleev/webrev/8244288/r1/ > > We already implemented putIfAbsent, merge, computeIfAbsent, > computeIfPresent, and compute for TreeMap class (see JDK-8176894). > However, default implementations of these methods are still used for > TreeMap derived maps, such as descendingMap(), tailMap(), headMap() > and subMap(). The implementation is pretty straightforward, just a > range-check+delegation for each of these methods inside the > TreeMap.NavigableSubMap (+32 lines in TreeMap.java). Care should be > taken to avoid throwing IAE from compute* methods if the key is > outside of the range but we don't actually add the entry. This mimics > the previous behavior and also consistent with other modification > methods like Map.remove (we don't throw from remove if the key is out > of range, simply do nothing). > > To cover these changes with tests, I added new > TreeMap().descendingMap() to > InPlaceOpsCollisions.nullValueFriendlyMaps and > MapWithCollisionsProviders.makeMapsMoreTypes. This map should behave > like a normal Map modulo iteration order but implementation goes > through NavigableSubMap. Also, I added more adders to > LockStep::randomAdder (lines 572+) to cover new methods, as well as > some more throws IAE asserts around line 806. At the same time, I took > the liberty to modernize this test: > - Convert all the raw-types to properly parameterized (using 'var' for > local vars where resulting type is long) > - Convert MapFrobber and SetFrobber to interfaces, and convert all the > implementations to lambdas (automatic conversion via IntelliJ IDEA + > rename of conflicting parameter names) > - Use for-each loop instead of indexed for loop where possible > - 'elts' array was created in two places but unused afterward. I added > size assert to these arrays to use it at least somehow (though > probably content should be checked as well). > - Use Comparator.naturalOrder() instead of manually written one in > comparator() methods (should not affect the testing in any way as it's > only used directly, not passed e.g. to TreeMap constructor). > - Use Objects.equals inside LockStep#equal > - Inverted 'if' at line 299 to avoid empty block. > If the cleanup really complicates the review I can post the cleanup as > a separate changeset. Though it should not be very problematic as the > actual changes are quite compact (as said above, near lines 572 and > 806) > > I also improved the previously added benchmark TreeMapUpdate to check > descendingMap and tailMap cases to confirm the hypothesis that the > change improves the performance of derived maps. This is indeed the > case. E.g. merge test yields (comparator = false, size = 1000) for > unpatched JDK: > > (benchmark) (mode) (prefill) Score Error Units > TreeMapUpdate.merge TreeMap true 63589,075 ? 1028,065 ns/op > TreeMapUpdate.merge TreeMap false 65414,367 ? 1011,442 ns/op > TreeMapUpdate.merge descendingMap true 121501,618 ? 1849,108 ns/op > TreeMapUpdate.merge descendingMap false 95913,212 ? 2854,063 ns/op > TreeMapUpdate.merge tailMap true 126657,309 ? 4467,733 ns/op > TreeMapUpdate.merge tailMap false 93448,840 ? 1359,392 ns/op > > As you can see, the merge on derived maps is significantly slower. > After the patch is applied the results are much better: > > (benchmark) (mode) (prefill) Score Error Units > TreeMapUpdate.merge TreeMap true 64059,189 ? 808,230 ns/op > TreeMapUpdate.merge TreeMap false 65156,912 ? 1229,965 ns/op > TreeMapUpdate.merge descendingMap true 69938,131 ? 1697,357 ns/op > TreeMapUpdate.merge descendingMap false 67783,829 ? 263,061 ns/op > TreeMapUpdate.merge tailMap true 71079,529 ? 841,738 ns/op > TreeMapUpdate.merge tailMap false 68577,169 ? 1196,758 ns/op > > I don't think this requires a CSR, as the changed class is > package-private, so it cannot be extended by clients. > > With best regards, > Tagir Valeev. From claes.redestad at oracle.com Mon May 11 09:50:44 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 11 May 2020 11:50:44 +0200 Subject: RFR: 8193066: Avoid use of capturing lambdas in JarFile Message-ID: <308e2e4b-b952-bbc9-9c0c-1483e4a476c4@oracle.com> Hi, lambdas used in the interaction between JarFile and ZipFile can be avoided by having ZipFile call a shared secret in JarFile to create a JarFileEntry when appropriate. This removes an allocation per lookup. Bug: https://bugs.openjdk.java.net/browse/JDK-8193066 Webrev: http://cr.openjdk.java.net/~redestad/8193066/open.00/ Testing: tier1-2, verified a small per-op speed-up, significantly so for negative lookups and during startup/warmup (10-20% improvements when interpreting) Thanks! /Claes From info at j-kuhn.de Mon May 11 11:10:55 2020 From: info at j-kuhn.de (Johannes Kuhn) Date: Mon, 11 May 2020 13:10:55 +0200 Subject: JDK-8226810: An other case and a small change suggestion In-Reply-To: <023c5b7e-ba89-f37b-4da0-c2b3da558d51@oracle.com> References: <2c1ff9d3-a9a6-800d-bb55-e771f22a3807@j-kuhn.de> <023c5b7e-ba89-f37b-4da0-c2b3da558d51@oracle.com> Message-ID: On 11-May-20 10:59, Alan Bateman wrote: > > > On 10/05/2020 15:47, Johannes Kuhn wrote: >> : >> >> After the discussion with Naoto, I would like to change the one line >> to strcpy(ret + 2, "1252") >> >> diff --git a/src/java.base/windows/native/libjava/java_props_md.c >> b/src/java.base/windows/native/libjava/java_props_md.c >> --- a/src/java.base/windows/native/libjava/java_props_md.c >> +++ b/src/java.base/windows/native/libjava/java_props_md.c >> @@ -73,6 +73,7 @@ >> ?????????????????????? LOCALE_IDEFAULTANSICODEPAGE, >> ?????????????????????? ret+2, 14) == 0) { >> ???????? codepage = 1252; >> +??????? strcpy(ret + 2, "1252"); >> ???? } else { >> ???????? codepage = atoi(ret+2); >> ???? } >> >> I have already signed the OCA. >> This would be my first patch. Is there anything else you need? >> >> I will take a further look into GetLocaleInfo, and try to find a >> model that works for me (currently thinking about blackbox, can >> return anything from [1]), >> and then discussing how to handle all those cases. > It's not clear how conditions are necessary for GetLocaleInfo to fail > but good to fix this code path. We should probably create a new issue > in JIRA for this as it's not clear that it is the same issue as > JDK-8226810. We've been chasing JDK-8226810 for some time but have not > been able to find a system where it duplicates. The reports so far > suggests is Windows Chinese but most of the people that report the > issue to not respond to questions so we can't be sure. One of the > reports (see my comment in the bug from June 2019) suggests the code > page is 54936, useful information as GB18030 is not in java.base. Once > your fix is in then I think we should try to improve the exception > message rather than NPE. There may be some of these cases where it > should default to UTF-8. > > -Alan. > I agree. Looking through the JDK code, the IMHO best way to create a hook for this is Charset.defaultCharset(). Instead of using GetPropertyAction, it could retrieve System.getProperties and do a null check there. This has probably the least impact on performance as this code path is only executed once. Indeed, it could (theoretically) emit a warning/debug message there with debug information and return sun.nio.cs.UTF_8.INSTANCE as fallback without setting defaultCharset. But that is a hard problem. I don't really like adding a warning to java startup, even if it would not work before just to get debug information. On the other hand, just continuing as if nothing did happen could hide further bugs. (Also, how would I get the debug info from the Java side, as properties are not yet initialized.) I wrote a small C program which just outputs the result of GetLocaleInfo(GetSystemDefaultLCID(), LOCALE_IDEFAULTANSICODEPAGE, ...). I was not able to influence that result - on my machine it's always 1252. My current understanding of codepages is basically: They are like encodings. They come in two variants (?): ANSI and non-ANSI. The ansi codepages use ANSI for bytes between 0 and 127. Each system, application or thread (wtf? see CP_THREAD_ACP) can have a different current codepage. Some windows API functions (the *A variants) use the current codepage (as returned by GetACP) to translate the string from/to unicode. GetACP returns the codepage identifier for the operating system. (No mention of thread in the doc for that, so why is there even CP_THREAD_ACP?) It's a rabbit hole. If someone knows about a way to influence the result of GetLocaleInfo(GetSystemDefaultLCID(), LOCALE_IDEFAULTANSICODEPAGE, ...), then at least reproducing the error would become possible. - Johannes From vipinmv1 at in.ibm.com Mon May 11 11:30:48 2020 From: vipinmv1 at in.ibm.com (Vipin Mv1) Date: Mon, 11 May 2020 11:30:48 +0000 Subject: RFR 6470126 java.util.jar.Attributes#containsKey fails with Strings Message-ID: Hi, Please review the fix for the following issue. https://bugs.openjdk.java.net/browse/JDK-6470126 diff -r 53568400fec3 src/java.base/share/classes/java/util/jar/Attributes.java --- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Mar 26 15:26:51 2020 +0000 +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Mon May 11 15:00:01 2020 +0530 @@ -205,7 +205,10 @@ * @return true if this Map contains the specified attribute name */ public boolean containsKey(Object name) { - return map.containsKey(name); + if(String.class.isInstance(name)) + return map.containsKey(Name.of((String)name)); + else + return map.containsKey(name); } /** Thanks & Regards Vipin Menon From claes.redestad at oracle.com Mon May 11 11:44:32 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 11 May 2020 13:44:32 +0200 Subject: RFR 6470126 java.util.jar.Attributes#containsKey fails with Strings In-Reply-To: References: Message-ID: <0091ccb2-68d7-2535-bc90-3cfa6faf3721@oracle.com> Hi Vipin, making containsKey("key") return true without also ensuring the other Map operations like get, put, .. work consistently and transparently with String keys seem like a partial fix that will subtly break operations like getOrDefault. And why not "if (name instanceof String)"? Thanks! /Claes On 2020-05-11 13:30, Vipin Mv1 wrote: > Hi, > > Please review the fix for the following issue. > > https://bugs.openjdk.java.net/browse/JDK-6470126 > > > diff -r 53568400fec3 src/java.base/share/classes/java/util/jar/Attributes.java > --- a/src/java.base/share/classes/java/util/jar/Attributes.java Thu Mar 26 15:26:51 2020 +0000 > +++ b/src/java.base/share/classes/java/util/jar/Attributes.java Mon May 11 15:00:01 2020 +0530 > @@ -205,7 +205,10 @@ > * @return true if this Map contains the specified attribute name > */ > public boolean containsKey(Object name) { > - return map.containsKey(name); > + if(String.class.isInstance(name)) > + return map.containsKey(Name.of((String)name)); > + else > + return map.containsKey(name); > } > > /** > > Thanks & Regards > Vipin Menon > From Alan.Bateman at oracle.com Mon May 11 11:54:22 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 11 May 2020 12:54:22 +0100 Subject: RFR 6470126 java.util.jar.Attributes#containsKey fails with Strings In-Reply-To: <0091ccb2-68d7-2535-bc90-3cfa6faf3721@oracle.com> References: <0091ccb2-68d7-2535-bc90-3cfa6faf3721@oracle.com> Message-ID: <0fd77f6e-777e-1390-8ca5-57e6eee350b6@oracle.com> On 11/05/2020 12:44, Claes Redestad wrote: > Hi Vipin, > > making containsKey("key") return true without also ensuring the > other Map operations like get, put, .. work consistently and > transparently with String keys seem like a partial fix that will subtly > break operations like getOrDefault. Yeah, I think this one will require going through Attributes all the consistency issues. The outcome may require a spec clarification to several methods where it's not currently clear if the input is a String or a Name. -Alan From lance.andersen at oracle.com Mon May 11 12:43:04 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 11 May 2020 08:43:04 -0400 Subject: RFR 6470126 java.util.jar.Attributes#containsKey fails with Strings In-Reply-To: <0fd77f6e-777e-1390-8ca5-57e6eee350b6@oracle.com> References: <0091ccb2-68d7-2535-bc90-3cfa6faf3721@oracle.com> <0fd77f6e-777e-1390-8ca5-57e6eee350b6@oracle.com> Message-ID: <71496538-AFD8-410A-9158-CF4C54AB3347@oracle.com> Hi Vipin, When you submit your revised patch addressing the input previously provided, please include a test case which exercises the various methods. Best Lance > On May 11, 2020, at 7:54 AM, Alan Bateman wrote: > > On 11/05/2020 12:44, Claes Redestad wrote: >> Hi Vipin, >> >> making containsKey("key") return true without also ensuring the >> other Map operations like get, put, .. work consistently and >> transparently with String keys seem like a partial fix that will subtly >> break operations like getOrDefault. > Yeah, I think this one will require going through Attributes all the consistency issues. The outcome may require a spec clarification to several methods where it's not currently clear if the input is a String or a Name. > > -Alan Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From jeffhainrocket at gmail.com Mon May 11 14:33:54 2020 From: jeffhainrocket at gmail.com (Jeff Hain) Date: Mon, 11 May 2020 16:33:54 +0200 Subject: BigInteger.squareToLen() can be wrong (when called directly) Message-ID: Hi. While trying to use BigInteger.squareToLen(x, len, z) directly (with reflection), I saw that its pure Java implementation computed wrong results when a 'z' is specified with (z.length > 2 * len). Ex.: x = {1, 2} len = 2 with z.length = 4: {0, 1, 4, 4} (as expected) with z.length = 5: {0, 1, 0, 8, 0} instead of {0, 1, 4, 4, 0} The core issue is in implMulAdd(), where 'offset' is set to "out.length-offset - 1" instead of "zlen - offset - 1" (which requires to add zlen as argument). In practice it doesn't hurt for current usages in BigInteger, since it seems to always be called with either null or a tightly sized array, and I'm not sure we can create a bug only reproducible by calling a private method directly, but I think it would be wise to defuse this behavior. The intrinsic implementation doesn't have this problem (once we can get it to kick in, with "-XX:+UseSquareToLenIntrinsic" (for pre-JDK-8154945) and a few thousand calls). No issue with multiplyToLen() either. -Jeff PS: I used to post here as jeffhain at rocketmail.com, but now it's being rejected at some point, hence the new address. From lance.andersen at oracle.com Mon May 11 16:01:48 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 11 May 2020 12:01:48 -0400 Subject: RFR: 8193066: Avoid use of capturing lambdas in JarFile In-Reply-To: <308e2e4b-b952-bbc9-9c0c-1483e4a476c4@oracle.com> References: <308e2e4b-b952-bbc9-9c0c-1483e4a476c4@oracle.com> Message-ID: <86513C2B-2C63-4F75-A554-5027DEA9DC09@oracle.com> Hi Claes, I think this looks good. Thank you for making JarFile zippier ;-) > On May 11, 2020, at 5:50 AM, Claes Redestad wrote: > > Hi, > > lambdas used in the interaction between JarFile and ZipFile can be > avoided by having ZipFile call a shared secret in JarFile to create a > JarFileEntry when appropriate. This removes an allocation per lookup. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193066 > Webrev: http://cr.openjdk.java.net/~redestad/8193066/open.00/ > > Testing: tier1-2, verified a small per-op speed-up, significantly so > for negative lookups and during startup/warmup (10-20% > improvements when interpreting) > > Thanks! > > /Claes Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Mon May 11 16:27:03 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 11 May 2020 09:27:03 -0700 Subject: RFR: JDK-8209774 - [TESTBUG]Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java In-Reply-To: References: <4F6C2290-A3AE-4A93-BE99-D057C9CEC778@oracle.com> <54095829-fd05-267f-3330-deb6a8c213b8@oracle.com> <2a03d73b-e7d9-2799-dedd-7d4f097a3309@oracle.com> <5BA24215-81C0-4540-B425-DD9167FBFF44@oracle.com> Message-ID: On 5/11/2020 2:32 AM, Alan Bateman wrote: > On 08/05/2020 18:19, Fernando Guallini wrote: >> Hi Daniel and Alan, >> @compile/module=java.xml was my first try, but for the nature of this >> test, it didn't work. The reason is that the original shell test does >> the following: >> - Compiles it?s own version of Node and Document interfaces >> - Compiles DocumentImpl patching java.xml with those 2 interfaces >> - Executes the AbstractMethodErrorTest patching the java.xml module >> *only with DocumentImpl*?patch(not including Document and Node) >> >> It does that by keeping the patches output in different folders. >> That?s important otherwise AbstractMethodErrorTest doesn?t compile, >> because it references some methods not declared in its custom >> interfaces, and it seems to be coded this way to reproduce the >> original bug. That is also the reason why I added the >> *@clean*?command to remove Document and Node *before* running the test. >> >> But when using *@compile/module=java.xml*, under the hood, JTREG >> generates a folder named ?patches/java.xml/..? including all the >> compiled classes under it. Unfortunately, the temporary interfaces >> can?t be removed because *@clean* does not know how to resolve the >> path "/patches/java.xml/..?. >> >> To sum up, this test creates a temporary java.xml patch that needs to >> be ignored after compiling *DocumentImpl. *I am using??patch-module >> because it?s more flexible than @compile/module >> * >> * >> Hope I explained myself! > This may be a question for Joe Wang but I'm curious if this need to > override/upgrade W3C DOM API classes dates back to when it was an > endorsed standard that could be overridden with the endorsed standards > override mechanism. The @bug on the test suggests otherwise but I'm > curious if it make any sense with JDK 9+. This doesn't impact the good > work to replace the script of course, I'm just curious how separately > compilation issue arises here. I agree with you, Alan, that this test is obsolete. I just haven't thought of getting rid of it. But you're right, it can be removed instead. -Joe > > -Alan > From claes.redestad at oracle.com Mon May 11 16:37:14 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 11 May 2020 18:37:14 +0200 Subject: RFR: 8193066: Avoid use of capturing lambdas in JarFile In-Reply-To: <86513C2B-2C63-4F75-A554-5027DEA9DC09@oracle.com> References: <308e2e4b-b952-bbc9-9c0c-1483e4a476c4@oracle.com> <86513C2B-2C63-4F75-A554-5027DEA9DC09@oracle.com> Message-ID: <53d11883-4de1-6bf5-c595-c4cbdce2dd59@oracle.com> Hi Lance, thank you for reviewing! /Claes On 2020-05-11 18:01, Lance Andersen wrote: > Hi Claes, > > I think this looks good. ?Thank you for making JarFile zippier ;-) > >> On May 11, 2020, at 5:50 AM, Claes Redestad > > wrote: >> >> Hi, >> >> lambdas used in the interaction between JarFile and ZipFile can be >> avoided by having ZipFile call a shared secret in JarFile to create a >> JarFileEntry when appropriate. This removes an allocation per lookup. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8193066 >> Webrev: http://cr.openjdk.java.net/~redestad/8193066/open.00/ >> >> Testing: tier1-2, verified a small per-op speed-up, significantly so >> ????????for negative lookups and during startup/warmup (10-20% >> ????????improvements when interpreting) >> >> Thanks! >> >> /Claes > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From philip.race at oracle.com Mon May 11 17:52:28 2020 From: philip.race at oracle.com (Philip Race) Date: Mon, 11 May 2020 10:52:28 -0700 Subject: RFR: JDK-8244620: test failure in WinUpgradeUUIDTest In-Reply-To: <119a3df2-3f1a-a6a7-b32e-48f3ead9a5af@oracle.com> References: <119a3df2-3f1a-a6a7-b32e-48f3ead9a5af@oracle.com> Message-ID: <5EB990DC.6060708@oracle.com> +1 -phil. On 5/8/20, 4:34 PM, Andy Herrick wrote: > Revised webrev at [3] - this fixes the test problem that was caused by > the test assuming wix tools are on all systems. > > /Andy > > [3] - http://cr.openjdk.java.net/~herrick/8244620/webrev.02/ > > On 5/7/2020 4:23 PM, Andy Herrick wrote: >> please review fix for issue [1] at [2]. >> >> /Andy >> >> [1] - https://bugs.openjdk.java.net/browse/JDK-8244620 >> >> [2] - http://cr.openjdk.java.net/~herrick/8244620/webrev.01/ >> From martinrb at google.com Mon May 11 17:54:53 2020 From: martinrb at google.com (Martin Buchholz) Date: Mon, 11 May 2020 10:54:53 -0700 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> Message-ID: On Thu, May 7, 2020 at 8:18 AM Severin Gehwolf wrote: > Thus, the new upper bound for update > version number is 2^16-1 => 65535 which should be sufficient. I don't > think OpenJDK 8u will live that long ;-) Everyone expected 256 to be sufficient for update release numbering, before the gaps in the numbering scheme were introduced! I don't know how we ended up with 2 mod 10. From alexey.semenyuk at oracle.com Mon May 11 18:44:16 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 11 May 2020 14:44:16 -0400 Subject: RFR: JDK-8244620: test failure in WinUpgradeUUIDTest In-Reply-To: <119a3df2-3f1a-a6a7-b32e-48f3ead9a5af@oracle.com> References: <119a3df2-3f1a-a6a7-b32e-48f3ead9a5af@oracle.com> Message-ID: <0b233f2f-5f2b-e78b-b91e-5c38b5a98265@oracle.com> Looks good. - Alexey On 5/8/2020 7:34 PM, Andy Herrick wrote: > Revised webrev at [3] - this fixes the test problem that was caused by > the test assuming wix tools are on all systems. > > /Andy > > [3] - http://cr.openjdk.java.net/~herrick/8244620/webrev.02/ > > On 5/7/2020 4:23 PM, Andy Herrick wrote: >> please review fix for issue [1] at [2]. >> >> /Andy >> >> [1] - https://bugs.openjdk.java.net/browse/JDK-8244620 >> >> [2] - http://cr.openjdk.java.net/~herrick/8244620/webrev.01/ >> From james.laskey at oracle.com Mon May 11 19:38:34 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 11 May 2020 16:38:34 -0300 Subject: RFR: (CSR) JDK-8236688 Clarify String::stripIndent javadoc when string ends with line terminator Message-ID: Sponsoring for Andrew Leonard. Please review the following CSR. Hopefully this clarifies user's misunderstanding when a line seems to disappear when the string ends with a line terminator. CSR: https://bugs.openjdk.java.net/browse/JDK-8236688 JBS: https://bugs.openjdk.java.net/browse/JDK-8230800 Thank you. Cheers, -- Jim From lance.andersen at oracle.com Mon May 11 20:26:58 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 11 May 2020 16:26:58 -0400 Subject: RFR(s): 8244659: Improve ZipFile.getInputStream In-Reply-To: References: Message-ID: <931E83DC-CB7C-4E25-A54D-7C4B9CCFF39A@oracle.com> Hi Volker, Could you update your patch now that Claes?s changes are back as I think that would make it easier to review Thank you! > On May 8, 2020, at 11:36 AM, Volker Simonis wrote: > > Hi, > > can I please have a review for the following small enhancement which > improves the speed of reading from ZipFile.getInputStream() by ~5%: > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8244659/ > https://bugs.openjdk.java.net/browse/JDK-8244659 > > ZipFile.getInputStream() tries to find a good size for sizing the internal > buffer of the underlying InflaterInputStream. This buffer is used to read > the compressed data from the associated InputStream. Unfortunately, > ZipFile.getInputStream() uses CENLEN (i.e. the uncompressed size of a > ZipEntry) instead of CENSIZ (i.e. the compressed size of a ZipEntry) to > configure the input buffer and thus unnecessarily wastes memory, because > the corresponding, compressed input data is at most CENSIZ bytes long. > > After fixing this and doing some benchmarks, I realized that a much bigger > problem is the continuous allocation of new, temporary input buffers for > each new input stream. Assuming that a zip files usually has hundreds if > not thousands of ZipEntries, I think it makes sense to cache these input > buffers. Fortunately, ZipFile already has a built-in mechanism for such > caching which it uses for caching the Inflaters needed for each new input > stream. In order to cache the buffers as well, I had to add a new , > package-private constructor to InflaterInputStream. I'm not sure if it > makes sense to make this new constructor public, to enable other users of > InflaterInputStream to pre-allocate the buffer. If you think so, I'd be > happy to do that change and open a CSR for this issue. > > Adding a cache for input stream buffers increases the speed of reading > ZipEntries from an InputStream by roughly 5% (see benchmark results below). > More importantly, it also decreases the memory consumption for each call to > ZipFile.getInputStream() which can be quite significant if many ZipEntries > are read from a ZipFile. One visible effect of caching the input buffers is > that the manual JTreg test java/util/zip/ZipFile/TestZipFile.java, which > regularly failed on my desktop with an OutOfMemoryError before, now > reliably passes (this tests calls ZipFile.getInputStream() excessively). > > I've experimented with different buffer sizes (even with buffer sizes > depending on the size of the compressed ZipEntries), but couldn't see any > difference so I decided to go with a default buffer size of 65536 which > already was the maximal buffer size in use before my change. > > I've also added a shortcut to Inflater which prevents us doing a native > call down to libz's inflate() method every time we call Inflater.inflate() > with "input == ZipUtils.defaultBuf" which is the default for every newly > created Inflater and for Inflaters after "Inflater.reset()" has been called > on them. > > Following some JMH benchmark results which show the time and memory used to > read all bytes from a ZipEntry before and after this change. The 'size' > parameter denotes the uncompressed size of the corresponding ZipEntries. > > In the "BEFORE" numbers, when looking at the "gc.alloc.rate.norm" values, > you can see the anomaly caused by using CENLEN instead of CENSIZ in > ZipFile.getInputStream(). I.e. getInputStream() chooses to big buffers > because it looks at the uncompressed ZipEntry sizes which are ~ 6 times > bigger than the compressed sizes. Also, the old implementation capped > buffers bigger than 65536 to 8192 bytes. > > The memory savings for a call to getInputStream() are obviously the effect > of repetadly calling getInputStream() on the same zip file (becuase only in > that case, the caching of the input buffers pays of). But as I wrote > before, I think it is common to have mor then a few entries in a zip file > and even if not, the overhead of caching is minimal compared to the > situation we had before the change. > > Thank you and best regards, > Volker > > = BEFORE 8244659 = > Benchmark (size) > Mode Cnt Score Error Units > ZipFileGetInputStream.readAllBytes 1024 > avgt 3 13.577 ? 0.540 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 1024 > avgt 3 1872.673 ? 0.317 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 1024 > avgt 3 57.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 1024 > avgt 3 15.000 ms > ZipFileGetInputStream.readAllBytes 4096 > avgt 3 20.938 ? 0.577 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 4096 > avgt 3 4945.793 ? 0.493 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 4096 > avgt 3 102.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 4096 > avgt 3 25.000 ms > ZipFileGetInputStream.readAllBytes 16384 > avgt 3 51.348 ? 2.600 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 16384 > avgt 3 17238.030 ? 3.183 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 16384 > avgt 3 144.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 16384 > avgt 3 33.000 ms > ZipFileGetInputStream.readAllBytes 65536 > avgt 3 203.082 ? 7.046 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 65536 > avgt 3 9035.475 ? 7.426 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 65536 > avgt 3 18.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 65536 > avgt 3 5.000 ms > ZipFileGetInputStream.readAllBytes 262144 > avgt 3 801.928 ? 22.474 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 262144 > avgt 3 9034.192 ? 0.047 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 262144 > avgt 3 3.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 262144 > avgt 3 1.000 ms > ZipFileGetInputStream.readAllBytes 1048576 > avgt 3 3154.747 ? 57.588 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 1048576 > avgt 3 9032.194 ? 0.004 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 1048576 > avgt 3 ? 0 counts > > = AFTER 8244659 = > Benchmark (size) > Mode Cnt Score Error Units > ZipFileGetInputStream.readAllBytes 1024 > avgt 3 13.031 ? 0.452 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 1024 > avgt 3 824.311 ? 0.027 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 1024 > avgt 3 27.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 1024 > avgt 3 7.000 ms > ZipFileGetInputStream.readAllBytes 4096 > avgt 3 20.018 ? 0.805 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 4096 > avgt 3 824.289 ? 0.722 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 4096 > avgt 3 15.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 4096 > avgt 3 4.000 ms > ZipFileGetInputStream.readAllBytes 16384 > avgt 3 48.916 ? 1.140 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 16384 > avgt 3 824.263 ? 0.008 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 16384 > avgt 3 6.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 16384 > avgt 3 1.000 ms > ZipFileGetInputStream.readAllBytes 65536 > avgt 3 192.815 ? 4.102 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 65536 > avgt 3 824.012 ? 0.001 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 65536 > avgt 3 ? 0 counts > ZipFileGetInputStream.readAllBytes 262144 > avgt 3 755.713 ? 42.408 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 262144 > avgt 3 824.047 ? 0.003 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 262144 > avgt 3 ? 0 counts > ZipFileGetInputStream.readAllBytes 1048576 > avgt 3 2989.236 ? 8.808 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 1048576 > avgt 3 824.184 ? 0.002 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 1048576 > avgt 3 ? 0 counts Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From brent.christian at oracle.com Mon May 11 20:29:20 2020 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 11 May 2020 13:29:20 -0700 Subject: RFR: 8244624: Improve handling of JarFile META-INF resources In-Reply-To: References: <118bd37e-ba97-bee5-e82e-e2d0dec4dc7f@oracle.com> Message-ID: <2cf5c528-a877-cc4a-0e66-7bab4fce2264@oracle.com> Looks good, Claes. Just one small question: src/java.base/share/classes/java/util/jar/JarFile.java 759 } catch (IOException | IllegalArgumentException ex) { Why the addition of IllegalArgumentException ? -Brent On 5/10/20 2:07 PM, Claes Redestad wrote: > Hi Martin, > > On 2020-05-10 21:53, Martin Buchholz wrote: >> Thanks for improving the jar/zip code. > > thanks! > >> I wish I had more time to do the same. >> My own superficial review only adds one small suggestion: >> add a comment as to why isSignatureRelated never hits a negative index >> exception. > > Yes, it's a bit subtle and deserves a comment. > >> I still like my ancient "ASCII trick" comment. > > Google "oldest ASCII trick in the book" and the first hit is an article > about this trick (or well, the inverse - but it still counts!). :-) > > Lance only suggested we clarify what that trick is - hope you're OK with > that: > > http://cr.openjdk.java.net/~redestad/8244624/open.02/ > > /Claes > >> >> On Thu, May 7, 2020 at 2:34 PM Claes Redestad >> wrote: >>> >>> Hi, >>> >>> currently during ZipFile creation, we create an int[] array of pointers >>> to META-INF entries. These are then retrieved from three different >>> places in JarFile. >>> >>> However, JarFile is only interested in some combination a few things: >>> the existence of and name of the META-INF/MANIFEST file, the existence >>> of and the names of various signature related files, i.e., files in >>> META-INF that have a suffix such as .EC, .SF, .RSA and .DSA >>> >>> Refactoring the contract between JarFile and ZipFile means we can filter >>> out such entries that we're not interested when opening the file, and >>> also remove the need to create the String for each entries unless we >>> actually want them: >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8244624 >>> Webrev: http://cr.openjdk.java.net/~redestad/8244624/open.00/ >>> >>> This reduces retained footprint of Jar-/ZipFile by slimming down or >>> removing the Source.metanames array entirely, and a significant speed-up >>> in some cases. >>> >>> In the provided microbenchmark, getManifestFromJarWithManifest and >>> getManifestFromJarWithSignatureFiles doesn't call >>> JUZFA.getMetaInfEntryNames but still see small (~5%) speed-up decrease >>> in allocations. >>> >>> getManifestFromJarWithNoManifest exercise JUZFA.getMetaInfEntryNames in >>> the baseline, and now calls JUZFA.getManifestName. Result is a 1.25x >>> speed-up and 30% reduction in allocations. While unrealistic (most JARs >>> have a META-INF/MANIFEST.MF), this speed-up will translate to a few >>> places - such as when loading classes from potentially-signed JAR files. >>> >>> Testing: tier1-2 >>> >>> Thanks! >>> >>> /Claes From brent.christian at oracle.com Mon May 11 23:36:09 2020 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 11 May 2020 16:36:09 -0700 Subject: RFR: 8244767 - Potential non-terminated string in getEncodingInternal() on Windows Message-ID: <070bbf5d-092c-b648-bf44-a0dcf3037428@oracle.com> Hi, Please review this small fix in Windows native code: Bug: https://bugs.openjdk.java.net/browse/JDK-8244767 Webrev: http://cr.openjdk.java.net/~bchristi/8244767/webrev-00/ As reported on this thread[1], the getEncodingInternal() function has a potential unterminated string in the case that the GetLocaleInfo() Windows function fails. In this case, the default switch() case will write "Cp" to the beginning of the 'ret' buffer, but the rest of the buffer remains uninitialized and unterminated. The fix is to strcpy() the default codepage into 'ret'. Thanks to Johannes Kuhn for uncovering this issue and submitting the fix. An automated build and test run is in progress. -Brent 1. http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066310.html From alexey.semenyuk at oracle.com Mon May 11 23:36:53 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 11 May 2020 19:36:53 -0400 Subject: RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302 In-Reply-To: <1ce0bd1f-5ad2-0679-60fc-f330dcb5ad19@oracle.com> References: <1ce0bd1f-5ad2-0679-60fc-f330dcb5ad19@oracle.com> Message-ID: <21c3ac81-80d4-72bd-7c99-002d4b941d7f@oracle.com> Please review fix [2] for jpackage bug [1]. Fix failure to load jli.dll from app launcher. The fix is to append path to directory with jli.dll to PATH env variable and load jli.dll with altered value of PATH if the first attempt to load jli.dll without altering PATH fails. - Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8244634 [2]?http://cr.openjdk.java.net/~asemenyuk/8244634/webrev.00 From brent.christian at oracle.com Mon May 11 23:40:30 2020 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 11 May 2020 16:40:30 -0700 Subject: JDK-8226810: An other case and a small change suggestion In-Reply-To: References: <2c1ff9d3-a9a6-800d-bb55-e771f22a3807@j-kuhn.de> Message-ID: <70dd217d-3be8-c547-c209-438f39b46609@oracle.com> FYI, I've filed a new issue[1] for this fix, and requested a code review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066384.html I don't believe I need anything else, Johannes. Thank you! -Brent 1. https://bugs.openjdk.java.net/browse/JDK-8244767 On 5/10/20 7:47 AM, Johannes Kuhn wrote: > On 09-May-20 1:27, Brent Christian wrote: >> On 5/7/20 5:50 AM, Alan Bateman wrote: >>> On 07/05/2020 12:37, Johannes Kuhn wrote: >>>> : >>>> >>>> In the end, I don't know what causes the bug, or how I can replicate >>>> it. >>>> I think I did find a likely suspect. >> > >>> Good sleuthing. I don't what the conditions are for GetLocaleInfo to >>> fail but it does look like that would return possibly non-terminated >>> garbage starting with "CP" so we should at least fix that. >> >> I agree.? I can file a bug and sponsor this small change. >> >> -Brent > Thank you. > > After the discussion with Naoto, I would like to change the one line to > strcpy(ret + 2, "1252") > > diff --git a/src/java.base/windows/native/libjava/java_props_md.c > b/src/java.base/windows/native/libjava/java_props_md.c > --- a/src/java.base/windows/native/libjava/java_props_md.c > +++ b/src/java.base/windows/native/libjava/java_props_md.c > @@ -73,6 +73,7 @@ > ?????????????????????? LOCALE_IDEFAULTANSICODEPAGE, > ?????????????????????? ret+2, 14) == 0) { > ???????? codepage = 1252; > +??????? strcpy(ret + 2, "1252"); > ???? } else { > ???????? codepage = atoi(ret+2); > ???? } > > I have already signed the OCA. > This would be my first patch. Is there anything else you need? > > I will take a further look into GetLocaleInfo, and try to find a model > that works for me (currently thinking about blackbox, can return > anything from [1]), > and then discussing how to handle all those cases. > > - Johannes > > [1]: > https://docs.microsoft.com/en-us/windows/win32/intl/code-page-identifiers From brian.burkhalter at oracle.com Tue May 12 00:25:11 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 11 May 2020 17:25:11 -0700 Subject: RFR: 8244767 - Potential non-terminated string in getEncodingInternal() on Windows In-Reply-To: <070bbf5d-092c-b648-bf44-a0dcf3037428@oracle.com> References: <070bbf5d-092c-b648-bf44-a0dcf3037428@oracle.com> Message-ID: <3AA7D013-DDD8-4CE7-B462-D0D15AD65858@oracle.com> Hi Brent, It looks OK to me. Brian > On May 11, 2020, at 4:36 PM, Brent Christian wrote: > > Please review this small fix in Windows native code: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244767 > Webrev: http://cr.openjdk.java.net/~bchristi/8244767/webrev-00/ > > As reported on this thread[1], the getEncodingInternal() function has a potential unterminated string in the case that the GetLocaleInfo() Windows function fails. In this case, the default switch() case will write "Cp" to the beginning of the 'ret' buffer, but the rest of the buffer remains uninitialized and unterminated. > > The fix is to strcpy() the default codepage into 'ret'. From naoto.sato at oracle.com Tue May 12 00:26:55 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 11 May 2020 17:26:55 -0700 Subject: RFR: 8244767 - Potential non-terminated string in getEncodingInternal() on Windows In-Reply-To: <3AA7D013-DDD8-4CE7-B462-D0D15AD65858@oracle.com> References: <070bbf5d-092c-b648-bf44-a0dcf3037428@oracle.com> <3AA7D013-DDD8-4CE7-B462-D0D15AD65858@oracle.com> Message-ID: +1 Naoto On 5/11/20 5:25 PM, Brian Burkhalter wrote: > Hi Brent, > > It looks OK to me. > > Brian > >> On May 11, 2020, at 4:36 PM, Brent Christian wrote: >> >> Please review this small fix in Windows native code: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8244767 >> Webrev: http://cr.openjdk.java.net/~bchristi/8244767/webrev-00/ >> >> As reported on this thread[1], the getEncodingInternal() function has a potential unterminated string in the case that the GetLocaleInfo() Windows function fails. In this case, the default switch() case will write "Cp" to the beginning of the 'ret' buffer, but the rest of the buffer remains uninitialized and unterminated. >> >> The fix is to strcpy() the default codepage into 'ret'. > From alexander.matveev at oracle.com Tue May 12 01:37:23 2020 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Mon, 11 May 2020 18:37:23 -0700 Subject: RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302 In-Reply-To: <21c3ac81-80d4-72bd-7c99-002d4b941d7f@oracle.com> References: <1ce0bd1f-5ad2-0679-60fc-f330dcb5ad19@oracle.com> <21c3ac81-80d4-72bd-7c99-002d4b941d7f@oracle.com> Message-ID: Hi Alexey, Updating PATH does not look like good solution to me. Did you try to load jli.dll by specifying full path to jli.dll when calling LoadLibary? If it does not work, then for AddDllDirectory() did you used LoadLibrary() or LoadLibraryEx() with LOAD_LIBRARY_SEARCH_USER_DIRS? According to doc you need to use LoadLibraryEx() with flag when using AddDllDirectory(). Thanks, Alexander On 5/11/2020 4:36 PM, Alexey Semenyuk wrote: > Please review fix [2] for jpackage bug [1]. > > Fix failure to load jli.dll from app launcher. The fix is to append > path to directory with jli.dll to PATH env variable and load jli.dll > with altered value of PATH if the first attempt to load jli.dll > without altering PATH fails. > > - Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8244634 > > [2]?http://cr.openjdk.java.net/~asemenyuk/8244634/webrev.00 > From thejasvi.v.voniadka at oracle.com Tue May 12 02:18:27 2020 From: thejasvi.v.voniadka at oracle.com (Thejasvi Voniadka) Date: Mon, 11 May 2020 19:18:27 -0700 (PDT) Subject: RFR: 8244199: [TestBug]: Update sun/management/jmxremote/bootstrap tests In-Reply-To: <8177caa9-b705-40d9-b35e-59834cfed2d5@default> References: <8177caa9-b705-40d9-b35e-59834cfed2d5@default> Message-ID: <5ff0d35a-1a19-4a30-9c59-d7f9d29aba28@default> Ping.. -----Original Message----- From: Thejasvi Voniadka Sent: Friday, May 8, 2020 6:17 AM To: core-libs-dev at openjdk.java.net; jmx-dev at openjdk.java.net; security-dev at openjdk.java.net Subject: RFR: 8244199: [TestBug]: Update sun/management/jmxremote/bootstrap tests Hi, May someone please sponsor this patch? Bug: https://bugs.openjdk.java.net/browse/JDK-8244199 Description: The test "test/jdk/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh" fails intermittently on a lower release. While investigating the cause for the failure, I felt the diagnostic messaging built into the test was not adequate. Some of the issues observed: 1. If the test throws a RuntimeException, the full stack trace is not displayed. 2. The test has several logging statements. However, the logging environment is not properly initialized to allow levels such as FINE and FINER. 3. The logging sequence could be improved: some messages end up at stdout, and others at stderr, which makes it harder to follow the output. The patch is to improve the test in these lines. Webrev: http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.full.00 I have also used this opportunity to clean-up the test code as a whole, in lines of removal of redundant logic, formatting, coding guidelines, etc.... If the above patch looks too confusing and is hard to follow, here is a simpler version that shows only the core logic changes (I intend to submit the full patch to be pushed though): http://cr.openjdk.java.net/~tvoniadka/reviews/8244199/webrev.simple.00 The patch has been tested on mach5, and all jmxremote tests passed. From fernando.guallini at oracle.com Tue May 12 10:46:19 2020 From: fernando.guallini at oracle.com (Fernando Guallini) Date: Tue, 12 May 2020 11:46:19 +0100 Subject: RFR: JDK-8209774 - [TESTBUG]Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java In-Reply-To: References: <4F6C2290-A3AE-4A93-BE99-D057C9CEC778@oracle.com> <54095829-fd05-267f-3330-deb6a8c213b8@oracle.com> <2a03d73b-e7d9-2799-dedd-7d4f097a3309@oracle.com> <5BA24215-81C0-4540-B425-DD9167FBFF44@oracle.com> Message-ID: <6755096D-7F8C-4F06-B5DD-65B849C5AC55@oracle.com> Thanks for your comments. Below you can find a new web rev version that includes a test description in a comment: http://cr.openjdk.java.net/~fyuan/fernando/8209774/webrev.01/ I will also create a JBS ticket to revisit this test and remove it if obsolete, if that is fine with you. -Fernando > On 11 May 2020, at 17:27, Joe Wang wrote: > > > > On 5/11/2020 2:32 AM, Alan Bateman wrote: >> On 08/05/2020 18:19, Fernando Guallini wrote: >>> Hi Daniel and Alan, >>> @compile/module=java.xml was my first try, but for the nature of this test, it didn't work. The reason is that the original shell test does the following: >>> - Compiles it?s own version of Node and Document interfaces >>> - Compiles DocumentImpl patching java.xml with those 2 interfaces >>> - Executes the AbstractMethodErrorTest patching the java.xml module *only with DocumentImpl* patch(not including Document and Node) >>> >>> It does that by keeping the patches output in different folders. That?s important otherwise AbstractMethodErrorTest doesn?t compile, because it references some methods not declared in its custom interfaces, and it seems to be coded this way to reproduce the original bug. That is also the reason why I added the *@clean* command to remove Document and Node *before* running the test. >>> >>> But when using *@compile/module=java.xml*, under the hood, JTREG generates a folder named ?patches/java.xml/..? including all the compiled classes under it. Unfortunately, the temporary interfaces can?t be removed because *@clean* does not know how to resolve the path "/patches/java.xml/..?. >>> >>> To sum up, this test creates a temporary java.xml patch that needs to be ignored after compiling *DocumentImpl. *I am using ?patch-module because it?s more flexible than @compile/module >>> * >>> * >>> Hope I explained myself! >> This may be a question for Joe Wang but I'm curious if this need to override/upgrade W3C DOM API classes dates back to when it was an endorsed standard that could be overridden with the endorsed standards override mechanism. The @bug on the test suggests otherwise but I'm curious if it make any sense with JDK 9+. This doesn't impact the good work to replace the script of course, I'm just curious how separately compilation issue arises here. > > I agree with you, Alan, that this test is obsolete. I just haven't thought of getting rid of it. But you're right, it can be removed instead. > > -Joe > >> >> -Alan >> > From andy.herrick at oracle.com Tue May 12 12:22:13 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 12 May 2020 08:22:13 -0400 Subject: RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302 In-Reply-To: References: <1ce0bd1f-5ad2-0679-60fc-f330dcb5ad19@oracle.com> <21c3ac81-80d4-72bd-7c99-002d4b941d7f@oracle.com> Message-ID: <0a7a2d81-1b19-aa60-888e-d9ba62af397a@oracle.com> Is the problem that by removing the copy of the microsoft dlls from the applications bin directory, then on machines that do not have all of these dll's already in the PATH (usually in C:\windows\system32) they can no longer be found ? I don't like manually manipulating the PATH env variable either, but if so I don't see what else can be done short of putting the app exe in the bin dir of the runtime. /Andy On 5/11/2020 9:37 PM, Alexander Matveev wrote: > Hi Alexey, > > Updating PATH does not look like good solution to me. Did you try to > load jli.dll by specifying full path to jli.dll when calling > LoadLibary? If it does not work, then for AddDllDirectory() did you > used LoadLibrary() or LoadLibraryEx() with > LOAD_LIBRARY_SEARCH_USER_DIRS? According to doc you need to use > LoadLibraryEx() with flag when using AddDllDirectory(). > > Thanks, > Alexander > > On 5/11/2020 4:36 PM, Alexey Semenyuk wrote: >> Please review fix [2] for jpackage bug [1]. >> >> Fix failure to load jli.dll from app launcher. The fix is to append >> path to directory with jli.dll to PATH env variable and load jli.dll >> with altered value of PATH if the first attempt to load jli.dll >> without altering PATH fails. >> >> - Alexey >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8244634 >> >> [2]?http://cr.openjdk.java.net/~asemenyuk/8244634/webrev.00 >> > From kevin.rushforth at oracle.com Tue May 12 12:31:07 2020 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 12 May 2020 05:31:07 -0700 Subject: RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302 In-Reply-To: <0a7a2d81-1b19-aa60-888e-d9ba62af397a@oracle.com> References: <1ce0bd1f-5ad2-0679-60fc-f330dcb5ad19@oracle.com> <21c3ac81-80d4-72bd-7c99-002d4b941d7f@oracle.com> <0a7a2d81-1b19-aa60-888e-d9ba62af397a@oracle.com> Message-ID: <124e8330-8af2-a85f-550c-419036f78b29@oracle.com> Is there a way you can link the launcher (e.g., something similar to RPATH on Unix systems) to look in the right place relative to the launcher? Otherwise, the solution with adding to the PATH seems OK to me. -- Kevin On 5/12/2020 5:22 AM, Andy Herrick wrote: > Is the problem that by removing the copy of the microsoft dlls from > the applications bin directory, then on machines that do not have all > of these dll's already in the PATH (usually in C:\windows\system32) > they can no longer be found ? > > I don't like manually manipulating the PATH env variable either, but > if so I don't see what else can be done short of putting the app exe > in the bin dir of the runtime. > > /Andy > > > On 5/11/2020 9:37 PM, Alexander Matveev wrote: >> Hi Alexey, >> >> Updating PATH does not look like good solution to me. Did you try to >> load jli.dll by specifying full path to jli.dll when calling >> LoadLibary? If it does not work, then for AddDllDirectory() did you >> used LoadLibrary() or LoadLibraryEx() with >> LOAD_LIBRARY_SEARCH_USER_DIRS? According to doc you need to use >> LoadLibraryEx() with flag when using AddDllDirectory(). >> >> Thanks, >> Alexander >> >> On 5/11/2020 4:36 PM, Alexey Semenyuk wrote: >>> Please review fix [2] for jpackage bug [1]. >>> >>> Fix failure to load jli.dll from app launcher. The fix is to append >>> path to directory with jli.dll to PATH env variable and load jli.dll >>> with altered value of PATH if the first attempt to load jli.dll >>> without altering PATH fails. >>> >>> - Alexey >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8244634 >>> >>> [2]?http://cr.openjdk.java.net/~asemenyuk/8244634/webrev.00 >>> >> From volker.simonis at gmail.com Tue May 12 12:55:54 2020 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 12 May 2020 14:55:54 +0200 Subject: RFR(s): 8244659: Improve ZipFile.getInputStream In-Reply-To: <931E83DC-CB7C-4E25-A54D-7C4B9CCFF39A@oracle.com> References: <931E83DC-CB7C-4E25-A54D-7C4B9CCFF39A@oracle.com> Message-ID: Sure, here it is: http://cr.openjdk.java.net/~simonis/webrevs/2020/8244659.01/ Fortunately, it still applies cleanly :) It also passed the zip-related JTreg tests and submit repo. On Mon, May 11, 2020 at 10:27 PM Lance Andersen wrote: > Hi Volker, > > Could you update your patch now that Claes?s changes are back as I think > that would make it easier to review > > Thank you! > > On May 8, 2020, at 11:36 AM, Volker Simonis > wrote: > > Hi, > > can I please have a review for the following small enhancement which > improves the speed of reading from ZipFile.getInputStream() by ~5%: > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8244659/ > https://bugs.openjdk.java.net/browse/JDK-8244659 > > ZipFile.getInputStream() tries to find a good size for sizing the internal > buffer of the underlying InflaterInputStream. This buffer is used to read > the compressed data from the associated InputStream. Unfortunately, > ZipFile.getInputStream() uses CENLEN (i.e. the uncompressed size of a > ZipEntry) instead of CENSIZ (i.e. the compressed size of a ZipEntry) to > configure the input buffer and thus unnecessarily wastes memory, because > the corresponding, compressed input data is at most CENSIZ bytes long. > > After fixing this and doing some benchmarks, I realized that a much bigger > problem is the continuous allocation of new, temporary input buffers for > each new input stream. Assuming that a zip files usually has hundreds if > not thousands of ZipEntries, I think it makes sense to cache these input > buffers. Fortunately, ZipFile already has a built-in mechanism for such > caching which it uses for caching the Inflaters needed for each new input > stream. In order to cache the buffers as well, I had to add a new , > package-private constructor to InflaterInputStream. I'm not sure if it > makes sense to make this new constructor public, to enable other users of > InflaterInputStream to pre-allocate the buffer. If you think so, I'd be > happy to do that change and open a CSR for this issue. > > Adding a cache for input stream buffers increases the speed of reading > ZipEntries from an InputStream by roughly 5% (see benchmark results below). > More importantly, it also decreases the memory consumption for each call to > ZipFile.getInputStream() which can be quite significant if many ZipEntries > are read from a ZipFile. One visible effect of caching the input buffers is > that the manual JTreg test java/util/zip/ZipFile/TestZipFile.java, which > regularly failed on my desktop with an OutOfMemoryError before, now > reliably passes (this tests calls ZipFile.getInputStream() excessively). > > I've experimented with different buffer sizes (even with buffer sizes > depending on the size of the compressed ZipEntries), but couldn't see any > difference so I decided to go with a default buffer size of 65536 which > already was the maximal buffer size in use before my change. > > I've also added a shortcut to Inflater which prevents us doing a native > call down to libz's inflate() method every time we call Inflater.inflate() > with "input == ZipUtils.defaultBuf" which is the default for every newly > created Inflater and for Inflaters after "Inflater.reset()" has been called > on them. > > Following some JMH benchmark results which show the time and memory used to > read all bytes from a ZipEntry before and after this change. The 'size' > parameter denotes the uncompressed size of the corresponding ZipEntries. > > In the "BEFORE" numbers, when looking at the "gc.alloc.rate.norm" values, > you can see the anomaly caused by using CENLEN instead of CENSIZ in > ZipFile.getInputStream(). I.e. getInputStream() chooses to big buffers > because it looks at the uncompressed ZipEntry sizes which are ~ 6 times > bigger than the compressed sizes. Also, the old implementation capped > buffers bigger than 65536 to 8192 bytes. > > The memory savings for a call to getInputStream() are obviously the effect > of repetadly calling getInputStream() on the same zip file (becuase only in > that case, the caching of the input buffers pays of). But as I wrote > before, I think it is common to have mor then a few entries in a zip file > and even if not, the overhead of caching is minimal compared to the > situation we had before the change. > > Thank you and best regards, > Volker > > = BEFORE 8244659 = > Benchmark (size) > Mode Cnt Score Error Units > ZipFileGetInputStream.readAllBytes 1024 > avgt 3 13.577 ? 0.540 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 1024 > avgt 3 1872.673 ? 0.317 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 1024 > avgt 3 57.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 1024 > avgt 3 15.000 ms > ZipFileGetInputStream.readAllBytes 4096 > avgt 3 20.938 ? 0.577 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 4096 > avgt 3 4945.793 ? 0.493 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 4096 > avgt 3 102.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 4096 > avgt 3 25.000 ms > ZipFileGetInputStream.readAllBytes 16384 > avgt 3 51.348 ? 2.600 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 16384 > avgt 3 17238.030 ? 3.183 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 16384 > avgt 3 144.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 16384 > avgt 3 33.000 ms > ZipFileGetInputStream.readAllBytes 65536 > avgt 3 203.082 ? 7.046 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 65536 > avgt 3 9035.475 ? 7.426 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 65536 > avgt 3 18.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 65536 > avgt 3 5.000 ms > ZipFileGetInputStream.readAllBytes 262144 > avgt 3 801.928 ? 22.474 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 262144 > avgt 3 9034.192 ? 0.047 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 262144 > avgt 3 3.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 262144 > avgt 3 1.000 ms > ZipFileGetInputStream.readAllBytes 1048576 > avgt 3 3154.747 ? 57.588 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 1048576 > avgt 3 9032.194 ? 0.004 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 1048576 > avgt 3 ? 0 counts > > = AFTER 8244659 = > Benchmark (size) > Mode Cnt Score Error Units > ZipFileGetInputStream.readAllBytes 1024 > avgt 3 13.031 ? 0.452 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 1024 > avgt 3 824.311 ? 0.027 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 1024 > avgt 3 27.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 1024 > avgt 3 7.000 ms > ZipFileGetInputStream.readAllBytes 4096 > avgt 3 20.018 ? 0.805 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 4096 > avgt 3 824.289 ? 0.722 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 4096 > avgt 3 15.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 4096 > avgt 3 4.000 ms > ZipFileGetInputStream.readAllBytes 16384 > avgt 3 48.916 ? 1.140 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 16384 > avgt 3 824.263 ? 0.008 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 16384 > avgt 3 6.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 16384 > avgt 3 1.000 ms > ZipFileGetInputStream.readAllBytes 65536 > avgt 3 192.815 ? 4.102 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 65536 > avgt 3 824.012 ? 0.001 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 65536 > avgt 3 ? 0 counts > ZipFileGetInputStream.readAllBytes 262144 > avgt 3 755.713 ? 42.408 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 262144 > avgt 3 824.047 ? 0.003 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 262144 > avgt 3 ? 0 counts > ZipFileGetInputStream.readAllBytes 1048576 > avgt 3 2989.236 ? 8.808 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 1048576 > avgt 3 824.184 ? 0.002 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 1048576 > avgt 3 ? 0 counts > > > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > From aph at redhat.com Tue May 12 13:07:17 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 May 2020 14:07:17 +0100 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> Message-ID: <808419e3-316b-381d-f636-606aadff39b6@redhat.com> On 5/7/20 4:09 PM, Severin Gehwolf wrote: > jvm_version_info.jvm_version currently holds this quadruplet: > > Most significant 8 bits => major version, followed by 8 bits => minor > version, followed by 8 bits => micro version, followed by 8 bits => > build version. Note that JVM minor version represents the update > version as passed in via configure and the micro version is currently > not used (always 0). See vm_version.cpp lines 100-102 where only major, > minor and build number are ever been set. Knowing this, we can still > preserve the same behavior after patch by defining JVM_VERSION_MICRO to > 0 for any version. This is tricky. JVM_GetVersionInfo is a function exported by libjvm.so, and the version is simply encoded as unsigned int Abstract_VM_Version::jvm_version() { return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) | ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) | (Abstract_VM_Version::vm_build_number() & 0xFF); } I guess we could argue that this is for JVM-JDK internal use only, and no-one else cares. Or we could encode it in a different way such that at least we have a jvm_version that is monotonically increasing, perhaps by (ab)using the lower 8 bits of the version, the vm_build_number. But I guess I'm being paranoid, and no tools are going to care about minor versions anyway,even if they do call JVM_GetVersionInfo. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From claes.redestad at oracle.com Tue May 12 13:41:34 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 12 May 2020 15:41:34 +0200 Subject: RFR(s): 8244659: Improve ZipFile.getInputStream In-Reply-To: References: Message-ID: <0746f629-1083-18d4-2f4f-5fb8f7c236a9@oracle.com> Hi Volker, I think this look like a nice improvement! One high-level concern I have with the design is that this will add and retain (at least) one 64k buffer to each Jar-/ZipFile we've read a stream from. We routinely see apps reading classes from 100s of jar files on their class path, so this could add noticeable overhead to the baseline retained memory usage of such applications. Have you considered other strategies such as making the cache global? Since a (the?) common usage pattern is likely a single thread repeatedly reading resources from a series of jar files, contention on such a global cache is likely going to be very low, while likely reducing the total number of buffers we have to allocate and retain to single-digit numbers. I don't insist on a re-design, but it shouldn't be hard to prototype and run some numbers on it. Minor random comments: Since you're not assigning null to bufferCache anywhere, this field could be final and the null-check in releaseBuffer removed. Pre-existing, but I wonder if there's a good reason to assign null to the inflaterCache in the run() method. Seems like trying to do the GCs job.. It could probably be removed, the field made final and the null check removed in the same way. On 2020-05-08 17:36, Volker Simonis wrote: > Hi, > > can I please have a review for the following small enhancement which > improves the speed of reading from ZipFile.getInputStream() by ~5%: > > http://cr.openjdk.java.net/~simonis/webrevs/2020/8244659/ > https://bugs.openjdk.java.net/browse/JDK-8244659 > > ZipFile.getInputStream() tries to find a good size for sizing the internal > buffer of the underlying InflaterInputStream. This buffer is used to read > the compressed data from the associated InputStream. Unfortunately, > ZipFile.getInputStream() uses CENLEN (i.e. the uncompressed size of a > ZipEntry) instead of CENSIZ (i.e. the compressed size of a ZipEntry) to > configure the input buffer and thus unnecessarily wastes memory, because > the corresponding, compressed input data is at most CENSIZ bytes long. > > After fixing this and doing some benchmarks, I realized that a much bigger > problem is the continuous allocation of new, temporary input buffers for > each new input stream. Assuming that a zip files usually has hundreds if > not thousands of ZipEntries, I think it makes sense to cache these input > buffers. Fortunately, ZipFile already has a built-in mechanism for such > caching which it uses for caching the Inflaters needed for each new input > stream. In order to cache the buffers as well, I had to add a new , > package-private constructor to InflaterInputStream. I'm not sure if it > makes sense to make this new constructor public, to enable other users of > InflaterInputStream to pre-allocate the buffer. If you think so, I'd be > happy to do that change and open a CSR for this issue. This could be interesting for some non-ZipFile use cases such as reading gzipped content from network streams - but I think considering making it public should be done separately - along with some use case to motivate it - and not hold back this RFE. Thanks! /Claes > > Adding a cache for input stream buffers increases the speed of reading > ZipEntries from an InputStream by roughly 5% (see benchmark results below). > More importantly, it also decreases the memory consumption for each call to > ZipFile.getInputStream() which can be quite significant if many ZipEntries > are read from a ZipFile. One visible effect of caching the input buffers is > that the manual JTreg test java/util/zip/ZipFile/TestZipFile.java, which > regularly failed on my desktop with an OutOfMemoryError before, now > reliably passes (this tests calls ZipFile.getInputStream() excessively). > > I've experimented with different buffer sizes (even with buffer sizes > depending on the size of the compressed ZipEntries), but couldn't see any > difference so I decided to go with a default buffer size of 65536 which > already was the maximal buffer size in use before my change. > > I've also added a shortcut to Inflater which prevents us doing a native > call down to libz's inflate() method every time we call Inflater.inflate() > with "input == ZipUtils.defaultBuf" which is the default for every newly > created Inflater and for Inflaters after "Inflater.reset()" has been called > on them. > > Following some JMH benchmark results which show the time and memory used to > read all bytes from a ZipEntry before and after this change. The 'size' > parameter denotes the uncompressed size of the corresponding ZipEntries. > > In the "BEFORE" numbers, when looking at the "gc.alloc.rate.norm" values, > you can see the anomaly caused by using CENLEN instead of CENSIZ in > ZipFile.getInputStream(). I.e. getInputStream() chooses to big buffers > because it looks at the uncompressed ZipEntry sizes which are ~ 6 times > bigger than the compressed sizes. Also, the old implementation capped > buffers bigger than 65536 to 8192 bytes. > > The memory savings for a call to getInputStream() are obviously the effect > of repetadly calling getInputStream() on the same zip file (becuase only in > that case, the caching of the input buffers pays of). But as I wrote > before, I think it is common to have mor then a few entries in a zip file > and even if not, the overhead of caching is minimal compared to the > situation we had before the change. > > Thank you and best regards, > Volker > > = BEFORE 8244659 = > Benchmark (size) > Mode Cnt Score Error Units > ZipFileGetInputStream.readAllBytes 1024 > avgt 3 13.577 ? 0.540 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 1024 > avgt 3 1872.673 ? 0.317 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 1024 > avgt 3 57.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 1024 > avgt 3 15.000 ms > ZipFileGetInputStream.readAllBytes 4096 > avgt 3 20.938 ? 0.577 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 4096 > avgt 3 4945.793 ? 0.493 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 4096 > avgt 3 102.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 4096 > avgt 3 25.000 ms > ZipFileGetInputStream.readAllBytes 16384 > avgt 3 51.348 ? 2.600 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 16384 > avgt 3 17238.030 ? 3.183 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 16384 > avgt 3 144.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 16384 > avgt 3 33.000 ms > ZipFileGetInputStream.readAllBytes 65536 > avgt 3 203.082 ? 7.046 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 65536 > avgt 3 9035.475 ? 7.426 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 65536 > avgt 3 18.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 65536 > avgt 3 5.000 ms > ZipFileGetInputStream.readAllBytes 262144 > avgt 3 801.928 ? 22.474 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 262144 > avgt 3 9034.192 ? 0.047 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 262144 > avgt 3 3.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 262144 > avgt 3 1.000 ms > ZipFileGetInputStream.readAllBytes 1048576 > avgt 3 3154.747 ? 57.588 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 1048576 > avgt 3 9032.194 ? 0.004 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 1048576 > avgt 3 ? 0 counts > > = AFTER 8244659 = > Benchmark (size) > Mode Cnt Score Error Units > ZipFileGetInputStream.readAllBytes 1024 > avgt 3 13.031 ? 0.452 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 1024 > avgt 3 824.311 ? 0.027 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 1024 > avgt 3 27.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 1024 > avgt 3 7.000 ms > ZipFileGetInputStream.readAllBytes 4096 > avgt 3 20.018 ? 0.805 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 4096 > avgt 3 824.289 ? 0.722 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 4096 > avgt 3 15.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 4096 > avgt 3 4.000 ms > ZipFileGetInputStream.readAllBytes 16384 > avgt 3 48.916 ? 1.140 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 16384 > avgt 3 824.263 ? 0.008 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 16384 > avgt 3 6.000 counts > ZipFileGetInputStream.readAllBytes:?gc.time 16384 > avgt 3 1.000 ms > ZipFileGetInputStream.readAllBytes 65536 > avgt 3 192.815 ? 4.102 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 65536 > avgt 3 824.012 ? 0.001 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 65536 > avgt 3 ? 0 counts > ZipFileGetInputStream.readAllBytes 262144 > avgt 3 755.713 ? 42.408 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 262144 > avgt 3 824.047 ? 0.003 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 262144 > avgt 3 ? 0 counts > ZipFileGetInputStream.readAllBytes 1048576 > avgt 3 2989.236 ? 8.808 us/op > ZipFileGetInputStream.readAllBytes:?gc.alloc.rate.norm 1048576 > avgt 3 824.184 ? 0.002 B/op > ZipFileGetInputStream.readAllBytes:?gc.count 1048576 > avgt 3 ? 0 counts > From andy.herrick at oracle.com Tue May 12 13:56:36 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 12 May 2020 09:56:36 -0400 Subject: RFR: JDK-8244758,: DMG bundler ignores --install-dir option. Message-ID: Please review jpackage fix for issue [1] at [2]. The change allows the specified --install-dir (instead of always /Applications) to be suggested for drag target of a DMG image. [1] - https://bugs.openjdk.java.net/browse/JDK-8244758 [2] - http://cr.openjdk.java.net/~herrick/8244758 /Andy From swpalmer at gmail.com Tue May 12 14:07:34 2020 From: swpalmer at gmail.com (Scott Palmer) Date: Tue, 12 May 2020 10:07:34 -0400 Subject: RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302 In-Reply-To: <124e8330-8af2-a85f-550c-419036f78b29@oracle.com> References: <124e8330-8af2-a85f-550c-419036f78b29@oracle.com> Message-ID: <94E28C00-E066-42CF-B330-E27915C34954@gmail.com> I think that sorry if things is usually handled in an ?Application Manifest? on Windows https://docs.microsoft.com/en-us/windows/win32/sbscs/application-manifests Scott > On May 12, 2020, at 8:33 AM, Kevin Rushforth wrote: > > ?Is there a way you can link the launcher (e.g., something similar to RPATH on Unix systems) to look in the right place relative to the launcher? Otherwise, the solution with adding to the PATH seems OK to me. > > -- Kevin > > >> On 5/12/2020 5:22 AM, Andy Herrick wrote: >> Is the problem that by removing the copy of the microsoft dlls from the applications bin directory, then on machines that do not have all of these dll's already in the PATH (usually in C:\windows\system32) they can no longer be found ? >> >> I don't like manually manipulating the PATH env variable either, but if so I don't see what else can be done short of putting the app exe in the bin dir of the runtime. >> >> /Andy >> >> >>> On 5/11/2020 9:37 PM, Alexander Matveev wrote: >>> Hi Alexey, >>> >>> Updating PATH does not look like good solution to me. Did you try to load jli.dll by specifying full path to jli.dll when calling LoadLibary? If it does not work, then for AddDllDirectory() did you used LoadLibrary() or LoadLibraryEx() with LOAD_LIBRARY_SEARCH_USER_DIRS? According to doc you need to use LoadLibraryEx() with flag when using AddDllDirectory(). >>> >>> Thanks, >>> Alexander >>> >>> On 5/11/2020 4:36 PM, Alexey Semenyuk wrote: >>>> Please review fix [2] for jpackage bug [1]. >>>> >>>> Fix failure to load jli.dll from app launcher. The fix is to append path to directory with jli.dll to PATH env variable and load jli.dll with altered value of PATH if the first attempt to load jli.dll without altering PATH fails. >>>> >>>> - Alexey >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8244634 >>>> >>>> [2] http://cr.openjdk.java.net/~asemenyuk/8244634/webrev.00 >>>> >>> > From martinrb at google.com Tue May 12 14:07:30 2020 From: martinrb at google.com (Martin Buchholz) Date: Tue, 12 May 2020 07:07:30 -0700 Subject: RFR(s): 8244659: Improve ZipFile.getInputStream In-Reply-To: <0746f629-1083-18d4-2f4f-5fb8f7c236a9@oracle.com> References: <0746f629-1083-18d4-2f4f-5fb8f7c236a9@oracle.com> Message-ID: On Tue, May 12, 2020 at 6:42 AM Claes Redestad wrote: > Hi Volker, > > I think this look like a nice improvement! > > One high-level concern I have with the design is that this will add and > retain (at least) one 64k buffer to each Jar-/ZipFile we've read a > stream from. We routinely see apps reading classes from 100s of jar > files on their class path, so this could add noticeable overhead to the > baseline retained memory usage of such applications. > At Google, it's common to run java applications with 10,000 small jar files on the classpath. Making the "quiescent cost" of each ZipFile object as small as possible is important. OTOH we currently retain the byte[] of the zip file central directory indefinitely. > > Have you considered other strategies such as making the cache global? > Since a (the?) common usage pattern is likely a single thread repeatedly > reading resources from a series of jar files, contention on such a > global cache is likely going to be very low, while likely reducing the > total number of buffers we have to allocate and retain to single-digit > numbers. I don't insist on a re-design, but it shouldn't be hard to > prototype and run some numbers on it. > Java resource management is still hard! From sgehwolf at redhat.com Tue May 12 14:14:45 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 12 May 2020 16:14:45 +0200 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: <808419e3-316b-381d-f636-606aadff39b6@redhat.com> References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> <808419e3-316b-381d-f636-606aadff39b6@redhat.com> Message-ID: <15a2fa41f80935d8c7d3893aad7d080c1f67aa2a.camel@redhat.com> Hi Andrew, Thanks for looking at this. On Tue, 2020-05-12 at 14:07 +0100, Andrew Haley wrote: > On 5/7/20 4:09 PM, Severin Gehwolf wrote: > > jvm_version_info.jvm_version currently holds this quadruplet: > > > > Most significant 8 bits => major version, followed by 8 bits => minor > > version, followed by 8 bits => micro version, followed by 8 bits => > > build version. Note that JVM minor version represents the update > > version as passed in via configure and the micro version is currently > > not used (always 0). See vm_version.cpp lines 100-102 where only major, > > minor and build number are ever been set. Knowing this, we can still > > preserve the same behavior after patch by defining JVM_VERSION_MICRO to > > 0 for any version. > > This is tricky. JVM_GetVersionInfo is a function exported by > libjvm.so, and the version is simply encoded as > > unsigned int Abstract_VM_Version::jvm_version() { > return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) | > ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) | > (Abstract_VM_Version::vm_build_number() & 0xFF); > } > > I guess we could argue that this is for JVM-JDK internal use only, and > no-one else cares. > > Or we could encode it in a different way such that at least we have a > jvm_version that is monotonically increasing, perhaps by (ab)using the > lower 8 bits of the version, the vm_build_number. But I guess I'm > being paranoid, and no tools are going to care about minor versions > anyway,even if they do call JVM_GetVersionInfo. Yes, this is indeed tricky. The trouble is that Abstract_VM_Version::vm_build_number() actually holds the configured JDK build number, we can't really use it. It's already being used. (gdb) 99 100 _vm_major_version = atoi(vm_major_ver); 101 _vm_minor_version = atoi(vm_minor_ver); 102 _vm_build_number = atoi(vm_build_num); 103 104 os::free(vm_version); 105 _initialized = true; 106 } 107 108 #if defined(_LP64) (gdb) p _vm_build_number $1 = 2 The only bits which seem unused are bits 8 through 16 of this unsigned int. So even if JVM_GetVersionInfo *is* being used somewhere in the wild, it *should* continue to work. Hence, the proposal to now also use those unused bits for the minor version. Thoughts? Thanks, Severin From alexey.semenyuk at oracle.com Tue May 12 14:33:37 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 12 May 2020 10:33:37 -0400 Subject: RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302 In-Reply-To: <124e8330-8af2-a85f-550c-419036f78b29@oracle.com> References: <1ce0bd1f-5ad2-0679-60fc-f330dcb5ad19@oracle.com> <21c3ac81-80d4-72bd-7c99-002d4b941d7f@oracle.com> <0a7a2d81-1b19-aa60-888e-d9ba62af397a@oracle.com> <124e8330-8af2-a85f-550c-419036f78b29@oracle.com> Message-ID: <36f107c2-16f5-0fd5-eefa-656d86aea6b4@oracle.com> > Is the problem that by removing the copy of the microsoft dlls from the applications bin directory, then on machines that do not have all of these dll's already in the PATH (usually in C:\windows\system32) they can no longer be found ? Yes. > Is there a way you can link the launcher (e.g., something similar to RPATH on Unix systems) to look in the right place relative to the launcher? The problem with failure to load jli.dll from the app launcher is that the system fails to load dependent dlls for jli.dll (MSVC run-time libs) from the directory with jli.dll even though the full path to jli.dll is specified in LoadLibrary() call. Launcher itself is statically linked with MSVC run-time libs. It it not an issue. > Did you try to load jli.dll by specifying full path to jli.dll when calling LoadLibary? Yes. Launcher loads jli.dll with the full path specified. The problem why LoadLibrary() fails to load it from the full path is that depending on OS/DLL loading settings LoadLibrary() would or would NOT look for dependent dlls in the directory where jli.dll is located. The tricky part about AddDllDirectory() is that it would work for LoadLibraryEx() with LOAD_LIBRARY_SEARCH_USER_DIRS only. Is this how Windows implicitly loads MSVC run-time libs before it completes explicit request to load jli.dll from the app launcher? I don't know. PATH env variable will be altered only in case the first attempt to load jli.dll fails. Value of PATH can be restored after jli.dll is loaded. This piece of code can be added to the patch. I'll also give another try to AddDllDirectory() with LoadLibraryEx() call. - Alexey On 5/12/2020 8:31 AM, Kevin Rushforth wrote: > Is there a way you can link the launcher (e.g., something similar to > RPATH on Unix systems) to look in the right place relative to the > launcher? Otherwise, the solution with adding to the PATH seems OK to me. > > -- Kevin > > > On 5/12/2020 5:22 AM, Andy Herrick wrote: >> Is the problem that by removing the copy of the microsoft dlls from >> the applications bin directory, then on machines that do not have all >> of these dll's already in the PATH (usually in C:\windows\system32) >> they can no longer be found ? >> >> I don't like manually manipulating the PATH env variable either, but >> if so I don't see what else can be done short of putting the app exe >> in the bin dir of the runtime. >> >> /Andy >> >> >> On 5/11/2020 9:37 PM, Alexander Matveev wrote: >>> Hi Alexey, >>> >>> Updating PATH does not look like good solution to me. Did you try to >>> load jli.dll by specifying full path to jli.dll when calling >>> LoadLibary? If it does not work, then for AddDllDirectory() did you >>> used LoadLibrary() or LoadLibraryEx() with >>> LOAD_LIBRARY_SEARCH_USER_DIRS? According to doc you need to use >>> LoadLibraryEx() with flag when using AddDllDirectory(). >>> >>> Thanks, >>> Alexander >>> >>> On 5/11/2020 4:36 PM, Alexey Semenyuk wrote: >>>> Please review fix [2] for jpackage bug [1]. >>>> >>>> Fix failure to load jli.dll from app launcher. The fix is to append >>>> path to directory with jli.dll to PATH env variable and load >>>> jli.dll with altered value of PATH if the first attempt to load >>>> jli.dll without altering PATH fails. >>>> >>>> - Alexey >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8244634 >>>> >>>> [2]?http://cr.openjdk.java.net/~asemenyuk/8244634/webrev.00 >>>> >>> > From claes.redestad at oracle.com Tue May 12 14:42:14 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 12 May 2020 16:42:14 +0200 Subject: RFR(s): 8244659: Improve ZipFile.getInputStream In-Reply-To: References: <0746f629-1083-18d4-2f4f-5fb8f7c236a9@oracle.com> Message-ID: <154bece7-ab54-df4e-7b8f-479c692dbe51@oracle.com> On 2020-05-12 16:07, Martin Buchholz wrote: > > > On Tue, May 12, 2020 at 6:42 AM Claes Redestad > > wrote: > > Hi Volker, > > I think this look like a nice improvement! > > One high-level concern I have with the design is that this will add and > retain (at least) one 64k buffer to each Jar-/ZipFile we've read a > stream from. We routinely see apps reading classes from 100s of jar > files on their class path, so this could add noticeable overhead to the > baseline retained memory usage of such applications. > > > At Google, it's common to run java applications with 10,000 small jar > files on the classpath. Ouch! That could mean a 600Mb+ footprint increase. Not very nice. > Making the "quiescent cost" of each ZipFile object as small as possible > is important. > OTOH we currently retain the byte[] of the zip file central directory > indefinitely. Striking the right trade-off is hard - and footprint has often gotten the shortest stick. > > > Have you considered other strategies such as making the cache global? > Since a (the?) common usage pattern is likely a single thread repeatedly > reading resources from a series of jar files, contention on such a > global cache is likely going to be very low, while likely reducing the > total number of buffers we have to allocate and retain to single-digit > numbers. I don't insist on a re-design, but it shouldn't be hard to > prototype and run some numbers on it. > > > Java resource management is still hard! ... but fun?! /Claes From alexey.semenyuk at oracle.com Tue May 12 14:46:09 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 12 May 2020 10:46:09 -0400 Subject: RFR: JDK-8244758,: DMG bundler ignores --install-dir option. In-Reply-To: References: Message-ID: <39e8b416-4adc-4012-ee53-408c469db622@oracle.com> Looks good. - Alexey On 5/12/2020 9:56 AM, Andy Herrick wrote: > Please review jpackage fix for issue [1] at [2]. > > The change allows the specified --install-dir (instead of always > /Applications) to be suggested for drag target of a DMG image. > > [1] - https://bugs.openjdk.java.net/browse/JDK-8244758 > > [2] - http://cr.openjdk.java.net/~herrick/8244758 > > /Andy > From alexey.semenyuk at oracle.com Tue May 12 15:42:01 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 12 May 2020 11:42:01 -0400 Subject: RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302 In-Reply-To: <36f107c2-16f5-0fd5-eefa-656d86aea6b4@oracle.com> References: <1ce0bd1f-5ad2-0679-60fc-f330dcb5ad19@oracle.com> <21c3ac81-80d4-72bd-7c99-002d4b941d7f@oracle.com> <0a7a2d81-1b19-aa60-888e-d9ba62af397a@oracle.com> <124e8330-8af2-a85f-550c-419036f78b29@oracle.com> <36f107c2-16f5-0fd5-eefa-656d86aea6b4@oracle.com> Message-ID: <2cdf6c1b-89b2-c860-50af-b9c252431eee@oracle.com> Changed the patch to try AddDllDirectory() first and alter PATH as the last resort. Webrev at [1] Log output: --- $ env JPACKAGE_DEBUG=true ./JTwork/scratch/output/test/test.exe [TRACE] applauncher.cpp:217: Entering AppLauncher::launch [TRACE] applauncher.cpp:100: Launcher config file path: "C:\Users\test\8244634\jdk-15_b22\JTwork\scratch\output\test\app\test.cfg" [TRACE] winlauncher.cpp:70: Entering `anonymous-namespace'::loadDllWithAddDllDirectory [TRACE] winlauncher.cpp:86: AddDllDirectory(C:\Users\test\8244634\jdk-15_b22\JTwork\scratch\output\test\runtime\bin): OK [TRACE] winlauncher.cpp:94: LoadLibraryEx(C:\Users\test\8244634\jdk-15_b22\JTwork\scratch\output\test\runtime\bin\jli.dll, LOAD_LIBRARY_SEARCH_DEFAULT_DIRS): 00007FFBED200000 [TRACE] winlauncher.cpp:0: Exiting `anonymous-namespace'::loadDllWithAddDllDirectory (entered at winlauncher.cpp:70) [TRACE] jvmlauncher.cpp:177: JVM library: "C:\Users\test\8244634\jdk-15_b22\JTwork\scratch\output\test\runtime\bin\jli.dll" hello: Environment supports a display jpackage test application args.length: 0 -Dparam1=Some Param 1 -Dparam2=Some "Param" 2 -Dparam3=Some "Param" with " 3 hello: Output file: [appOutput.txt] [TRACE] applauncher.cpp:0: Exiting AppLauncher::launch (entered at applauncher.cpp:217) --- AddDllDirectory/LoadLibraryEx works. However not with LOAD_LIBRARY_SEARCH_USER_DIRS flag, but with wider LOAD_LIBRARY_SEARCH_DEFAULT_DIRS. Should we keep the code that would alter PATH in case AddDllDirectory() doesn't work? [1] http://cr.openjdk.java.net/~asemenyuk/8244634/webrev.01 - Alexey On 5/12/2020 10:33 AM, Alexey Semenyuk wrote: > > Is the problem that by removing the copy of the microsoft dlls from > the applications bin directory, then on machines that do not have all > of these dll's already in the PATH (usually in C:\windows\system32) > they can no longer be found ? > Yes. > > > Is there a way you can link the launcher (e.g., something similar to > RPATH on Unix systems) to look in the right place relative to the > launcher? > The problem with failure to load jli.dll from the app launcher is that > the system fails to load dependent dlls for jli.dll (MSVC run-time > libs) from the directory with jli.dll even though the full path to > jli.dll is specified in LoadLibrary() call. Launcher itself is > statically linked with MSVC run-time libs. It it not an issue. > > > Did you try to load jli.dll by specifying full path to jli.dll when > calling LoadLibary? > Yes. Launcher loads jli.dll with the full path specified. The problem > why LoadLibrary() fails to load it from the full path is that > depending on OS/DLL loading settings LoadLibrary() would or would NOT > look for dependent dlls in the directory where jli.dll is located. > The tricky part about AddDllDirectory() is that it would work for > LoadLibraryEx() with LOAD_LIBRARY_SEARCH_USER_DIRS only. Is this how > Windows implicitly loads MSVC run-time libs before it completes > explicit request to load jli.dll from the app launcher? I don't know. > > PATH env variable will be altered only in case the first attempt to > load jli.dll fails. Value of PATH can be restored after jli.dll is > loaded. This piece of code can be added to the patch. I'll also give > another try to AddDllDirectory() with LoadLibraryEx() call. > > - Alexey > > On 5/12/2020 8:31 AM, Kevin Rushforth wrote: >> Is there a way you can link the launcher (e.g., something similar to >> RPATH on Unix systems) to look in the right place relative to the >> launcher? Otherwise, the solution with adding to the PATH seems OK to >> me. >> >> -- Kevin >> >> >> On 5/12/2020 5:22 AM, Andy Herrick wrote: >>> Is the problem that by removing the copy of the microsoft dlls from >>> the applications bin directory, then on machines that do not have >>> all of these dll's already in the PATH (usually in >>> C:\windows\system32) they can no longer be found ? >>> >>> I don't like manually manipulating the PATH env variable either, but >>> if so I don't see what else can be done short of putting the app exe >>> in the bin dir of the runtime. >>> >>> /Andy >>> >>> >>> On 5/11/2020 9:37 PM, Alexander Matveev wrote: >>>> Hi Alexey, >>>> >>>> Updating PATH does not look like good solution to me. Did you try >>>> to load jli.dll by specifying full path to jli.dll when calling >>>> LoadLibary? If it does not work, then for AddDllDirectory() did you >>>> used LoadLibrary() or LoadLibraryEx() with >>>> LOAD_LIBRARY_SEARCH_USER_DIRS? According to doc you need to use >>>> LoadLibraryEx() with flag when using AddDllDirectory(). >>>> >>>> Thanks, >>>> Alexander >>>> >>>> On 5/11/2020 4:36 PM, Alexey Semenyuk wrote: >>>>> Please review fix [2] for jpackage bug [1]. >>>>> >>>>> Fix failure to load jli.dll from app launcher. The fix is to >>>>> append path to directory with jli.dll to PATH env variable and >>>>> load jli.dll with altered value of PATH if the first attempt to >>>>> load jli.dll without altering PATH fails. >>>>> >>>>> - Alexey >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8244634 >>>>> >>>>> [2]?http://cr.openjdk.java.net/~asemenyuk/8244634/webrev.00 >>>>> >>>> >> > From javalists at cbfiddle.com Tue May 12 16:27:56 2020 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 12 May 2020 09:27:56 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com> References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> <4B44293C-2465-4BA7-B6F6-9AAA437760C4@cbfiddle.com> <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com> Message-ID: <8138A696-AE6D-49D4-9A9B-4E4C23DC65A4@cbfiddle.com> > On May 8, 2020, at 1:49 PM, Stuart Marks wrote: > > The containsAll() and equals() methods both use the membership contract of the receiver, not the argument. Unfortunately, the equals() specification says, > > Returns true if the specified object is also a set, the two sets have the > same size, and every member of the specified set is contained in this set > (or equivalently, every member of this set is contained in the specified > set). > > As should be clear from this discussion, the "equivalently" clause is incorrect -- another spec bug. Changing Set.equals() in this way would make Set inconsistent with Object. Do you really think that is a good idea? Comparator cc = (a, b) -> a.compareToIgnoreCase(b); Set s1 = new HashSet<>(); Set s2 = new TreeSet<>(cc); s1.add("hello"); s2.add("Hello"); s1.equals(s2) -> false s2.equals(s1) -> true s1.hashCode() == s2.hashCode() -> false From jason_mehrens at hotmail.com Tue May 12 18:13:22 2020 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 12 May 2020 18:13:22 +0000 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: <8138A696-AE6D-49D4-9A9B-4E4C23DC65A4@cbfiddle.com> References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> <4B44293C-2465-4BA7-B6F6-9AAA437760C4@cbfiddle.com> <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com>, <8138A696-AE6D-49D4-9A9B-4E4C23DC65A4@cbfiddle.com> Message-ID: HashSet/TreeSet could do what ConcurrentHashMap/ConcurrentSkipListSet do by using the "this contains that and that contains this" logic. Comparator cc = String.CASE_INSENSITIVE_ORDER; Set s1 = new ConcurrentHashMap().keySet(""); Set s2 = new ConcurrentSkipListSet<>(cc); s1.add("hello"); s2.add("Hello"); System.out.println(s1.equals(s2)); System.out.println(s2.equals(s1)); System.out.println(s1.hashCode() == s2.hashCode()); === false false false ________________________________________ From: core-libs-dev on behalf of Alan Snyder Sent: Tuesday, May 12, 2020 11:27 AM To: Stuart Marks Cc: core-libs-dev Subject: Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes > On May 8, 2020, at 1:49 PM, Stuart Marks wrote: > > The containsAll() and equals() methods both use the membership contract of the receiver, not the argument. Unfortunately, the equals() specification says, > > Returns true if the specified object is also a set, the two sets have the > same size, and every member of the specified set is contained in this set > (or equivalently, every member of this set is contained in the specified > set). > > As should be clear from this discussion, the "equivalently" clause is incorrect -- another spec bug. Changing Set.equals() in this way would make Set inconsistent with Object. Do you really think that is a good idea? Comparator cc = (a, b) -> a.compareToIgnoreCase(b); Set s1 = new HashSet<>(); Set s2 = new TreeSet<>(cc); s1.add("hello"); s2.add("Hello"); s1.equals(s2) -> false s2.equals(s1) -> true s1.hashCode() == s2.hashCode() -> false From brent.christian at oracle.com Tue May 12 18:24:00 2020 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 12 May 2020 11:24:00 -0700 Subject: RFR: 8244767 - Potential non-terminated string in getEncodingInternal() on Windows In-Reply-To: References: <070bbf5d-092c-b648-bf44-a0dcf3037428@oracle.com> <3AA7D013-DDD8-4CE7-B462-D0D15AD65858@oracle.com> Message-ID: Thanks - change is pushed. -B On 5/11/20 5:26 PM, naoto.sato at oracle.com wrote: > +1 > > Naoto > > On 5/11/20 5:25 PM, Brian Burkhalter wrote: >> Hi Brent, >> >> It looks OK to me. >> >> Brian >> >>> On May 11, 2020, at 4:36 PM, Brent Christian >>> wrote: >>> >>> Please review this small fix in Windows native code: >>> >>> ?? Bug: https://bugs.openjdk.java.net/browse/JDK-8244767 >>> >>> Webrev: http://cr.openjdk.java.net/~bchristi/8244767/webrev-00/ >>> >>> >>> As reported on this thread[1], the getEncodingInternal() function has >>> a potential unterminated string in the case that the GetLocaleInfo() >>> Windows function fails.? In this case, the default switch() case will >>> write "Cp" to the beginning of the 'ret' buffer, but the rest of the >>> buffer remains uninitialized and unterminated. >>> >>> The fix is to strcpy() the default codepage into 'ret'. >> From bob.vandette at oracle.com Tue May 12 18:46:41 2020 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 12 May 2020 14:46:41 -0400 Subject: RFR: 8244853 - The static build of libextnet is missing the JNI_OnLoad_extnet function Message-ID: BUG: https://bugs.openjdk.java.net/browse/JDK-8244853 Please review this simple fix for JDK 15 which adds the required JNI_OnLoad_extnet function to the libextnet.a static library when it is built. the JDK 15 make static-libs-image target currently builds this static library but it is not spec compliant and causes the GraalVM native-image utility to fail generating executables due to the lack of the OnLoad symbol. CHANGE: diff --git a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c --- a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c +++ b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c @@ -34,6 +34,11 @@ #include "jdk_net_LinuxSocketOptions.h" /* + * Declare library specific JNI_Onload entry if static build + */ +DEF_STATIC_JNI_OnLoad + +/* * Class: jdk_net_LinuxSocketOptions * Method: setQuickAck * Signature: (II)V diff --git a/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c b/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c --- a/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c +++ b/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c @@ -32,6 +32,11 @@ #include #include "jni_util.h" +/* + * Declare library specific JNI_Onload entry if static build + */ +DEF_STATIC_JNI_OnLoad + static jint socketOptionSupported(jint sockopt) { jint one = 1; jint rv, s; diff --git a/src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c b/src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c --- a/src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c +++ b/src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c @@ -32,6 +32,11 @@ static int initialized = 0; /* + * Declare library specific JNI_Onload entry if static build + */ +DEF_STATIC_JNI_OnLoad + +/* * Class: jdk_net_SolarisSocketOptions * Method: init * Signature: ()V From Alan.Bateman at oracle.com Tue May 12 18:57:01 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 12 May 2020 19:57:01 +0100 Subject: RFR: 8244853 - The static build of libextnet is missing the JNI_OnLoad_extnet function In-Reply-To: References: Message-ID: <0a69f26b-34f6-6b57-1b7c-571cdd2f3f1e@oracle.com> Looks okay to me. On 12/05/2020 19:46, Bob Vandette wrote: > BUG: > > https://bugs.openjdk.java.net/browse/JDK-8244853 > > Please review this simple fix for JDK 15 which adds the required JNI_OnLoad_extnet function to the libextnet.a > static library when it is built. > > the JDK 15 make static-libs-image target currently builds this static library but it is not spec compliant and > causes the GraalVM native-image utility to fail generating executables due to the lack of the OnLoad symbol. > > > CHANGE: > > diff --git a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c > --- a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c > +++ b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c > @@ -34,6 +34,11 @@ > #include "jdk_net_LinuxSocketOptions.h" > > /* > + * Declare library specific JNI_Onload entry if static build > + */ > +DEF_STATIC_JNI_OnLoad > + > +/* > * Class: jdk_net_LinuxSocketOptions > * Method: setQuickAck > * Signature: (II)V > diff --git a/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c b/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c > --- a/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c > +++ b/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c > @@ -32,6 +32,11 @@ > #include > #include "jni_util.h" > > +/* > + * Declare library specific JNI_Onload entry if static build > + */ > +DEF_STATIC_JNI_OnLoad > + > static jint socketOptionSupported(jint sockopt) { > jint one = 1; > jint rv, s; > diff --git a/src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c b/src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c > --- a/src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c > +++ b/src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c > @@ -32,6 +32,11 @@ > static int initialized = 0; > > /* > + * Declare library specific JNI_Onload entry if static build > + */ > +DEF_STATIC_JNI_OnLoad > + > +/* > * Class: jdk_net_SolarisSocketOptions > * Method: init > * Signature: ()V From brent.christian at oracle.com Tue May 12 19:04:24 2020 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 12 May 2020 12:04:24 -0700 (PDT) Subject: RFR: 8244855 : Remove unused "getParent" function from Windows jni_util_md.c Message-ID: <8fb5e19d-a7cb-d965-e2fa-0d9a3fb107b4@oracle.com> Hi, Please review this change to remove the unused "getParent()" function from jni_util_md.c on Windows. https://bugs.openjdk.java.net/browse/JDK-8244855 Automated build+test job is in progress. The diff is as follows: diff -r ee4bd700b772 src/java.base/windows/native/libjava/jni_util_md.c --- a/src/java.base/windows/native/libjava/jni_util_md.c Tue May 12 11:20:34 2020 -0700 +++ b/src/java.base/windows/native/libjava/jni_util_md.c Tue May 12 12:00:39 2020 -0700 @@ -31,17 +31,6 @@ #include "jni.h" #include "jni_util.h" -static void getParent(const TCHAR *path, TCHAR *dest) { - char* lastSlash = max(strrchr(path, '\\'), strrchr(path, '/')); - if (lastSlash == NULL) { - *dest = 0; - return; - } - if (path != dest) - strcpy(dest, path); - *lastSlash = 0; -} - void* getProcessHandle() { return (void*)GetModuleHandle(NULL); } Thanks, -Brent From lance.andersen at oracle.com Tue May 12 19:12:25 2020 From: lance.andersen at oracle.com (Lance @ Oracle) Date: Tue, 12 May 2020 15:12:25 -0400 Subject: RFR: 8244855 : Remove unused "getParent" function from Windows jni_util_md.c In-Reply-To: <8fb5e19d-a7cb-d965-e2fa-0d9a3fb107b4@oracle.com> References: <8fb5e19d-a7cb-d965-e2fa-0d9a3fb107b4@oracle.com> Message-ID: +1 Best, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Sent from my iPad > On May 12, 2020, at 3:05 PM, Brent Christian wrote: > > ?Hi, > > Please review this change to remove the unused "getParent()" function from jni_util_md.c on Windows. > > https://bugs.openjdk.java.net/browse/JDK-8244855 > > Automated build+test job is in progress. > The diff is as follows: > > diff -r ee4bd700b772 src/java.base/windows/native/libjava/jni_util_md.c > --- a/src/java.base/windows/native/libjava/jni_util_md.c Tue May 12 11:20:34 2020 -0700 > +++ b/src/java.base/windows/native/libjava/jni_util_md.c Tue May 12 12:00:39 2020 -0700 > @@ -31,17 +31,6 @@ > #include "jni.h" > #include "jni_util.h" > > -static void getParent(const TCHAR *path, TCHAR *dest) { > - char* lastSlash = max(strrchr(path, '\\'), strrchr(path, '/')); > - if (lastSlash == NULL) { > - *dest = 0; > - return; > - } > - if (path != dest) > - strcpy(dest, path); > - *lastSlash = 0; > -} > - > void* getProcessHandle() { > return (void*)GetModuleHandle(NULL); > } > > Thanks, > -Brent From naoto.sato at oracle.com Tue May 12 19:17:53 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 12 May 2020 12:17:53 -0700 Subject: RFR: 8244855 : Remove unused "getParent" function from Windows jni_util_md.c In-Reply-To: References: <8fb5e19d-a7cb-d965-e2fa-0d9a3fb107b4@oracle.com> Message-ID: <499aac76-c8d6-055d-24a3-fa5f981a7ab5@oracle.com> Looks good, with the change to copyright year to "2020." Naoto On 5/12/20 12:12 PM, Lance @ Oracle wrote: > +1 > > Best, > Lance > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > Sent from my iPad > >> On May 12, 2020, at 3:05 PM, Brent Christian wrote: >> >> ?Hi, >> >> Please review this change to remove the unused "getParent()" function from jni_util_md.c on Windows. >> >> https://bugs.openjdk.java.net/browse/JDK-8244855 >> >> Automated build+test job is in progress. >> The diff is as follows: >> >> diff -r ee4bd700b772 src/java.base/windows/native/libjava/jni_util_md.c >> --- a/src/java.base/windows/native/libjava/jni_util_md.c Tue May 12 11:20:34 2020 -0700 >> +++ b/src/java.base/windows/native/libjava/jni_util_md.c Tue May 12 12:00:39 2020 -0700 >> @@ -31,17 +31,6 @@ >> #include "jni.h" >> #include "jni_util.h" >> >> -static void getParent(const TCHAR *path, TCHAR *dest) { >> - char* lastSlash = max(strrchr(path, '\\'), strrchr(path, '/')); >> - if (lastSlash == NULL) { >> - *dest = 0; >> - return; >> - } >> - if (path != dest) >> - strcpy(dest, path); >> - *lastSlash = 0; >> -} >> - >> void* getProcessHandle() { >> return (void*)GetModuleHandle(NULL); >> } >> >> Thanks, >> -Brent From stuart.marks at oracle.com Tue May 12 20:34:18 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 12 May 2020 13:34:18 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> Message-ID: <7a9e679f-c697-9a59-2cf9-2eba76b215d3@oracle.com> On 5/8/20 6:46 PM, Jason Mehrens wrote: > I assume Deque/Queue would suffer the same issue as List. It would be nice to some how ensure ArrayDeque.contains is not called as far as the heuristic goes. Looks like PriorityQueue uses equals for contains but that is not to say there are not other queue implementations in the wild that do something different. The difficulty here is how far to take the heuristic. The goal here is not to guarantee that behavior can never be O(M*N) but to catch what seem to be the most common cases. I think the most common case is where the argument is a List, but there are lots of possibilities that we'd inevitably miss. > The more I think about it in general, it seems like your task would be easier if you could declare: > 1. AbstractCollection.removeAll should assume this.contains is O(N) and iterate over this and check contains on arg. > 2. AbstractSet.removeAll should iterate over argument and assume that this.contains/remove is at least O(log (N)) and assume argument.contains is O(N). > 3. Concrete implementations of removeAll know the cost of their contains method. If it is known to be O(N) then walk this otherwise walk the arg. > 4. Include an example in removeAll that says if membership semantics differ between sets use: source.removeIf(e -> removals.contains(e)); or removals.forEach(e -> source.remove(e)); instead. If they don't differ then use removeAll. This sort of makes sense from a performance standpoint, but it doesn't address the semantic issues I raised in my reply the other day to Jens Lidestr?m. Specifically, we don't want Set.removeAll or AbstractSet.removeAll to disagree with Collection.removeAll and AbstractCollection.removeAll. We also want removeAll() to be the complement of retainAll(). > Given this has been around since JDK 1.3 would it be safe to assume that code that is mixing collections with different membership semantics is already working around this issue and therefore the risk is a bit lower in changing the spec? Lots of concrete implementations already override removeAll anyway. I'm not sure that's true. People keep running into either the performance problem or the semantic problem. Sometimes people live with bugs for a long time and can't figure it out. "Yeah, removeAll sometimes gives this weird result. I don't know why. Maybe I just don't understand Java." s'marks From brent.christian at oracle.com Tue May 12 21:17:02 2020 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 12 May 2020 14:17:02 -0700 Subject: RFR: 8244855 : Remove unused "getParent" function from Windows jni_util_md.c In-Reply-To: <499aac76-c8d6-055d-24a3-fa5f981a7ab5@oracle.com> References: <8fb5e19d-a7cb-d965-e2fa-0d9a3fb107b4@oracle.com> <499aac76-c8d6-055d-24a3-fa5f981a7ab5@oracle.com> Message-ID: Ah, thanks. I meant to check that, then it slipped my mind. -Brent On 5/12/20 12:17 PM, naoto.sato at oracle.com wrote: > Looks good, with the change to copyright year to "2020." > > Naoto > > On 5/12/20 12:12 PM, Lance @ Oracle wrote: >> +1 >> >> Best, >> Lance >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> Sent from my iPad >> >>> On May 12, 2020, at 3:05 PM, Brent Christian >>> wrote: >>> >>> ?Hi, >>> >>> Please review this change to remove the unused "getParent()" function >>> from jni_util_md.c on Windows. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8244855 >>> >>> Automated build+test job is in progress. >>> The diff is as follows: >>> >>> diff -r ee4bd700b772 src/java.base/windows/native/libjava/jni_util_md.c >>> --- a/src/java.base/windows/native/libjava/jni_util_md.c??? Tue May >>> 12 11:20:34 2020 -0700 >>> +++ b/src/java.base/windows/native/libjava/jni_util_md.c??? Tue May >>> 12 12:00:39 2020 -0700 >>> @@ -31,17 +31,6 @@ >>> #include "jni.h" >>> #include "jni_util.h" >>> >>> -static void getParent(const TCHAR *path, TCHAR *dest) { >>> -??? char* lastSlash = max(strrchr(path, '\\'), strrchr(path, '/')); >>> -??? if (lastSlash == NULL) { >>> -??????? *dest = 0; >>> -??????? return; >>> -??? } >>> -??? if (path != dest) >>> -??????? strcpy(dest, path); >>> -??? *lastSlash = 0; >>> -} >>> - >>> void* getProcessHandle() { >>> ???? return (void*)GetModuleHandle(NULL); >>> } >>> >>> Thanks, >>> -Brent From stuart.marks at oracle.com Tue May 12 21:28:09 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 12 May 2020 14:28:09 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: <8138A696-AE6D-49D4-9A9B-4E4C23DC65A4@cbfiddle.com> References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> <4B44293C-2465-4BA7-B6F6-9AAA437760C4@cbfiddle.com> <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com> <8138A696-AE6D-49D4-9A9B-4E4C23DC65A4@cbfiddle.com> Message-ID: <6ac64550-4107-bc62-ad4d-9f19dc1751a3@oracle.com> > You say: > > The issue of membership semantics is part of the original design. > > I agree, but only to the point of identifying inconsistent membership semantics as a source of non-conformance. What is not part of the original design is allowing a broader range of membership semantics to be conformant, which I assume is what you want. I'm not using the concept of "conformance" so that's unrelated to what I want. > Another point of disagreement involves the specification of membership, especially in the case of Set, which I believe is where the problems arise. > > I?m not completely sure what you are thinking, but it sounds like you believe that membership is defined by the implementation of the contains() method. I believe that is incorrect (i.e., not implied by the current specification). No, I don't believe that membership is defined by the implementation of contains(). I'm not sure where that came from; it might be misapprehension or miscommunication. > Consider the ?more formal? definition of contains(): > > More formally, returns true if and only if this set contains an element e such that Objects.equals(o, e). > > Clearly, it would make no sense to define the contains() method in terms of itself. But it does make sense to say that the current state of a Set is a mathematical set of instances such that no pair of instances returns true from e1.equals(e2). I believe that is what the specification is trying to say, however imperfectly. Yes, this much makes sense. Note that this embodies the membership contract of typical equals-based sets. Unfortunately, other sets (such as SortedSet) make some statements that imply that membership is determined by the comparator, they don't make any statments about how this affects contains(). The specification for SortedSet.contains(o) should say, Returns true if and only if this set contains an element e such that compare(o, e) == 0. That it doesn't is yet another spec bug. > Consider the classic example, a TreeSet of Strings that is case-insensitive. If I add one string ?hello? to an empty TreeSet, how many elements does it contain? The specification of add() says one. The size() method returns one. The iterator returns one element. But the contains() method returns true for multiple non-equal objects. Oops. The reason this seems wrong is that you're calling contains() on two "non-equal" objects, but your statement's use of "non-equal" means you're using a different notion of equivalence from that used by the TreeSet. Since the TreeSet from your example uses case-insensitivity, those multiple "non-equal" objects on which you're calling contains() are in fact equivalent, so the result makes sense. > What I conclude from this exercise: Does this mean you're close to conclusing this argument? :-) I'll call out just one of your conclusions, since the other seem to be based on an incorrect assumption that I believe that the membership semantics are defined by the implementation of the contains() method, or that I'm proposing to do so. That conclusion is: > The problems of non-conforming collections are larger than you think. It is *not* the case that all of the basic axioms still apply. Well I don't know how you know how large I think the problem is, but I'll agree it's pretty large. It's certainly much larger than the changeset that is currently under review. Regarding the basic axioms, I'll return to some wording from SortedSet: The behavior of a sorted set is well-defined even if its ordering is inconsistent with equals; it just fails to obey the general contract of the Set interface. The "well-defined" clause means that the basic axioms apply. However, I'll admit that the current wording of the spec does not support this! I'm assuming that there will be future changes to SortedSet et. al. that strengthen its notion of membership contract differing from other sets, and further that its add(), contains(), remove(), etc. methods all need to be adjusted to use this different membership contract. Sorry if this wasn't clear. I know I've said this elsewhere, but possibly not on this thread or its predecessors. s'marks From stuart.marks at oracle.com Tue May 12 21:30:10 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 12 May 2020 14:30:10 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> <4B44293C-2465-4BA7-B6F6-9AAA437760C4@cbfiddle.com> <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com> Message-ID: On 5/9/20 7:48 PM, Alan Snyder wrote: > A small point? you might want to reconsider your analysis of Set.copyOf(), as it is a static method and there is no receiver. Of course there is no receiver. For static factory methods, and for constructors, I meant the newly created instance is the one whose membership contract is used. s'marks From stuart.marks at oracle.com Tue May 12 21:37:42 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 12 May 2020 14:37:42 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: <8138A696-AE6D-49D4-9A9B-4E4C23DC65A4@cbfiddle.com> References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> <4B44293C-2465-4BA7-B6F6-9AAA437760C4@cbfiddle.com> <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com> <8138A696-AE6D-49D4-9A9B-4E4C23DC65A4@cbfiddle.com> Message-ID: <80b39d46-2108-c97a-d4fc-aca5a9a402af@oracle.com> >> The containsAll() and equals() methods both use the membership contract of the >> receiver, not the argument. Unfortunately, the equals() specification says, >> >> ???Returns true if the specified object is also a set, the two sets have the >> ???same size, and every member of the specified set is contained in this set >> ???(or equivalently, every member of this set is contained in the specified >> ???set). >> >> As should be clear from this discussion, the "equivalently" clause is >> incorrect -- another spec bug. > > Changing Set.equals() in this way would make Set inconsistent with Object. > Do you really think that is a good idea? [example of asymmetry of equals] Your example illustrates that the "equivalently" clause is incorrect. I prefer specifications to have fewer incorrect statements. s'marks From alexander.matveev at oracle.com Tue May 12 22:22:34 2020 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 12 May 2020 15:22:34 -0700 Subject: RFR: JDK-8244758,: DMG bundler ignores --install-dir option. In-Reply-To: References: Message-ID: Hi Andy, Looks good. Thanks, Alexander On 5/12/2020 6:56 AM, Andy Herrick wrote: > Please review jpackage fix for issue [1] at [2]. > > The change allows the specified --install-dir (instead of always > /Applications) to be suggested for drag target of a DMG image. > > [1] - https://bugs.openjdk.java.net/browse/JDK-8244758 > > [2] - http://cr.openjdk.java.net/~herrick/8244758 > > /Andy > From alexander.matveev at oracle.com Tue May 12 22:55:44 2020 From: alexander.matveev at oracle.com (Alexander Matveev) Date: Tue, 12 May 2020 15:55:44 -0700 Subject: RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302 In-Reply-To: <2cdf6c1b-89b2-c860-50af-b9c252431eee@oracle.com> References: <1ce0bd1f-5ad2-0679-60fc-f330dcb5ad19@oracle.com> <21c3ac81-80d4-72bd-7c99-002d4b941d7f@oracle.com> <0a7a2d81-1b19-aa60-888e-d9ba62af397a@oracle.com> <124e8330-8af2-a85f-550c-419036f78b29@oracle.com> <36f107c2-16f5-0fd5-eefa-656d86aea6b4@oracle.com> <2cdf6c1b-89b2-c860-50af-b9c252431eee@oracle.com> Message-ID: <32b74bb6-c130-753a-b348-c60c019e8f39@oracle.com> Hi Alexey, Looks good. I do not see any issues with keeping code which alters PATH. I think it might be better to keep it, just in case. Thanks, Alexander On 5/12/2020 8:42 AM, Alexey Semenyuk wrote: > Changed the patch to try AddDllDirectory() first and alter PATH as the > last resort. Webrev at [1] > > Log output: > --- > $ env JPACKAGE_DEBUG=true ./JTwork/scratch/output/test/test.exe > [TRACE] applauncher.cpp:217: Entering AppLauncher::launch > [TRACE] applauncher.cpp:100: Launcher config file path: > "C:\Users\test\8244634\jdk-15_b22\JTwork\scratch\output\test\app\test.cfg" > [TRACE] winlauncher.cpp:70: Entering > `anonymous-namespace'::loadDllWithAddDllDirectory > [TRACE] winlauncher.cpp:86: > AddDllDirectory(C:\Users\test\8244634\jdk-15_b22\JTwork\scratch\output\test\runtime\bin): > OK > [TRACE] winlauncher.cpp:94: > LoadLibraryEx(C:\Users\test\8244634\jdk-15_b22\JTwork\scratch\output\test\runtime\bin\jli.dll, > LOAD_LIBRARY_SEARCH_DEFAULT_DIRS): 00007FFBED200000 > [TRACE] winlauncher.cpp:0: Exiting > `anonymous-namespace'::loadDllWithAddDllDirectory (entered at > winlauncher.cpp:70) > [TRACE] jvmlauncher.cpp:177: JVM library: > "C:\Users\test\8244634\jdk-15_b22\JTwork\scratch\output\test\runtime\bin\jli.dll" > hello: Environment supports a display > jpackage test application > args.length: 0 > -Dparam1=Some Param 1 > -Dparam2=Some "Param" 2 > -Dparam3=Some "Param" with " 3 > hello: Output file: [appOutput.txt] > [TRACE] applauncher.cpp:0: Exiting AppLauncher::launch (entered at > applauncher.cpp:217) > --- > > AddDllDirectory/LoadLibraryEx works. However not with > LOAD_LIBRARY_SEARCH_USER_DIRS flag, but with wider > LOAD_LIBRARY_SEARCH_DEFAULT_DIRS. > Should we keep the code that would alter PATH in case > AddDllDirectory() doesn't work? > > [1] http://cr.openjdk.java.net/~asemenyuk/8244634/webrev.01 > > - Alexey > > On 5/12/2020 10:33 AM, Alexey Semenyuk wrote: >> > Is the problem that by removing the copy of the microsoft dlls from >> the applications bin directory, then on machines that do not have all >> of these dll's already in the PATH (usually in C:\windows\system32) >> they can no longer be found ? >> Yes. >> >> > Is there a way you can link the launcher (e.g., something similar >> to RPATH on Unix systems) to look in the right place relative to the >> launcher? >> The problem with failure to load jli.dll from the app launcher is >> that the system fails to load dependent dlls for jli.dll (MSVC >> run-time libs) from the directory with jli.dll even though the full >> path to jli.dll is specified in LoadLibrary() call. Launcher itself >> is statically linked with MSVC run-time libs. It it not an issue. >> >> > Did you try to load jli.dll by specifying full path to jli.dll when >> calling LoadLibary? >> Yes. Launcher loads jli.dll with the full path specified. The problem >> why LoadLibrary() fails to load it from the full path is that >> depending on OS/DLL loading settings LoadLibrary() would or would NOT >> look for dependent dlls in the directory where jli.dll is located. >> The tricky part about AddDllDirectory() is that it would work for >> LoadLibraryEx() with LOAD_LIBRARY_SEARCH_USER_DIRS only. Is this how >> Windows implicitly loads MSVC run-time libs before it completes >> explicit request to load jli.dll from the app launcher? I don't know. >> >> PATH env variable will be altered only in case the first attempt to >> load jli.dll fails. Value of PATH can be restored after jli.dll is >> loaded. This piece of code can be added to the patch. I'll also give >> another try to AddDllDirectory() with LoadLibraryEx() call. >> >> - Alexey >> >> On 5/12/2020 8:31 AM, Kevin Rushforth wrote: >>> Is there a way you can link the launcher (e.g., something similar to >>> RPATH on Unix systems) to look in the right place relative to the >>> launcher? Otherwise, the solution with adding to the PATH seems OK >>> to me. >>> >>> -- Kevin >>> >>> >>> On 5/12/2020 5:22 AM, Andy Herrick wrote: >>>> Is the problem that by removing the copy of the microsoft dlls from >>>> the applications bin directory, then on machines that do not have >>>> all of these dll's already in the PATH (usually in >>>> C:\windows\system32) they can no longer be found ? >>>> >>>> I don't like manually manipulating the PATH env variable either, >>>> but if so I don't see what else can be done short of putting the >>>> app exe in the bin dir of the runtime. >>>> >>>> /Andy >>>> >>>> >>>> On 5/11/2020 9:37 PM, Alexander Matveev wrote: >>>>> Hi Alexey, >>>>> >>>>> Updating PATH does not look like good solution to me. Did you try >>>>> to load jli.dll by specifying full path to jli.dll when calling >>>>> LoadLibary? If it does not work, then for AddDllDirectory() did >>>>> you used LoadLibrary() or LoadLibraryEx() with >>>>> LOAD_LIBRARY_SEARCH_USER_DIRS? According to doc you need to use >>>>> LoadLibraryEx() with flag when using AddDllDirectory(). >>>>> >>>>> Thanks, >>>>> Alexander >>>>> >>>>> On 5/11/2020 4:36 PM, Alexey Semenyuk wrote: >>>>>> Please review fix [2] for jpackage bug [1]. >>>>>> >>>>>> Fix failure to load jli.dll from app launcher. The fix is to >>>>>> append path to directory with jli.dll to PATH env variable and >>>>>> load jli.dll with altered value of PATH if the first attempt to >>>>>> load jli.dll without altering PATH fails. >>>>>> >>>>>> - Alexey >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8244634 >>>>>> >>>>>> [2]?http://cr.openjdk.java.net/~asemenyuk/8244634/webrev.00 >>>>>> >>>>> >>> >> > From javalists at cbfiddle.com Tue May 12 22:58:20 2020 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 12 May 2020 15:58:20 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> <4B44293C-2465-4BA7-B6F6-9AAA437760C4@cbfiddle.com> <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com> Message-ID: <49A851FE-B935-4864-AD2A-FEDE9B3B6147@cbfiddle.com> But what kind of instance should be created by Set.copyOf? > On May 12, 2020, at 2:30 PM, Stuart Marks wrote: > > > > On 5/9/20 7:48 PM, Alan Snyder wrote: >> A small point? you might want to reconsider your analysis of Set.copyOf(), as it is a static method and there is no receiver. > > Of course there is no receiver. For static factory methods, and for constructors, I meant the newly created instance is the one whose membership contract is used. > > s'marks > From javalists at cbfiddle.com Tue May 12 23:03:46 2020 From: javalists at cbfiddle.com (Alan Snyder) Date: Tue, 12 May 2020 16:03:46 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: <80b39d46-2108-c97a-d4fc-aca5a9a402af@oracle.com> References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> <4B44293C-2465-4BA7-B6F6-9AAA437760C4@cbfiddle.com> <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com> <8138A696-AE6D-49D4-9A9B-4E4C23DC65A4@cbfiddle.com> <80b39d46-2108-c97a-d4fc-aca5a9a402af@oracle.com> Message-ID: <0B435FAE-D7E1-4CCF-90EA-6E1EA5979347@cbfiddle.com> You must have misunderstood. Even so, a snarky answer is uncalled for. The specification of Object.equals() is violated by the example, but that outcome would be *required* by your version of the specification of Set.equals(). Do you really think that the specification of Object.equals() is unimportant? Lots of code relies on it. > On May 12, 2020, at 2:37 PM, Stuart Marks wrote: > > > >>> The containsAll() and equals() methods both use the membership contract of the receiver, not the argument. Unfortunately, the equals() specification says, >>> >>> Returns true if the specified object is also a set, the two sets have the >>> same size, and every member of the specified set is contained in this set >>> (or equivalently, every member of this set is contained in the specified >>> set). >>> >>> As should be clear from this discussion, the "equivalently" clause is incorrect -- another spec bug. >> Changing Set.equals() in this way would make Set inconsistent with Object. >> Do you really think that is a good idea? > > [example of asymmetry of equals] > > Your example illustrates that the "equivalently" clause is incorrect. I prefer specifications to have fewer incorrect statements. > > s'marks > From andy.herrick at oracle.com Tue May 12 23:09:13 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 12 May 2020 19:09:13 -0400 Subject: RFR: JDK-8244634:, LoadLibraryW failed from tools/jpackage tests after JDK-8242302 In-Reply-To: <2cdf6c1b-89b2-c860-50af-b9c252431eee@oracle.com> References: <1ce0bd1f-5ad2-0679-60fc-f330dcb5ad19@oracle.com> <21c3ac81-80d4-72bd-7c99-002d4b941d7f@oracle.com> <0a7a2d81-1b19-aa60-888e-d9ba62af397a@oracle.com> <124e8330-8af2-a85f-550c-419036f78b29@oracle.com> <36f107c2-16f5-0fd5-eefa-656d86aea6b4@oracle.com> <2cdf6c1b-89b2-c860-50af-b9c252431eee@oracle.com> Message-ID: <0da1f747-b7c3-4922-4468-4bb9288126ff@oracle.com> OK - looks good. /Andy On 5/12/2020 11:42 AM, Alexey Semenyuk wrote: > Changed the patch to try AddDllDirectory() first and alter PATH as the > last resort. Webrev at [1] > > Log output: > --- > $ env JPACKAGE_DEBUG=true ./JTwork/scratch/output/test/test.exe > [TRACE] applauncher.cpp:217: Entering AppLauncher::launch > [TRACE] applauncher.cpp:100: Launcher config file path: > "C:\Users\test\8244634\jdk-15_b22\JTwork\scratch\output\test\app\test.cfg" > [TRACE] winlauncher.cpp:70: Entering > `anonymous-namespace'::loadDllWithAddDllDirectory > [TRACE] winlauncher.cpp:86: > AddDllDirectory(C:\Users\test\8244634\jdk-15_b22\JTwork\scratch\output\test\runtime\bin): > OK > [TRACE] winlauncher.cpp:94: > LoadLibraryEx(C:\Users\test\8244634\jdk-15_b22\JTwork\scratch\output\test\runtime\bin\jli.dll, > LOAD_LIBRARY_SEARCH_DEFAULT_DIRS): 00007FFBED200000 > [TRACE] winlauncher.cpp:0: Exiting > `anonymous-namespace'::loadDllWithAddDllDirectory (entered at > winlauncher.cpp:70) > [TRACE] jvmlauncher.cpp:177: JVM library: > "C:\Users\test\8244634\jdk-15_b22\JTwork\scratch\output\test\runtime\bin\jli.dll" > hello: Environment supports a display > jpackage test application > args.length: 0 > -Dparam1=Some Param 1 > -Dparam2=Some "Param" 2 > -Dparam3=Some "Param" with " 3 > hello: Output file: [appOutput.txt] > [TRACE] applauncher.cpp:0: Exiting AppLauncher::launch (entered at > applauncher.cpp:217) > --- > > AddDllDirectory/LoadLibraryEx works. However not with > LOAD_LIBRARY_SEARCH_USER_DIRS flag, but with wider > LOAD_LIBRARY_SEARCH_DEFAULT_DIRS. > Should we keep the code that would alter PATH in case > AddDllDirectory() doesn't work? > > [1] http://cr.openjdk.java.net/~asemenyuk/8244634/webrev.01 > > - Alexey > > On 5/12/2020 10:33 AM, Alexey Semenyuk wrote: >> > Is the problem that by removing the copy of the microsoft dlls from >> the applications bin directory, then on machines that do not have all >> of these dll's already in the PATH (usually in C:\windows\system32) >> they can no longer be found ? >> Yes. >> >> > Is there a way you can link the launcher (e.g., something similar >> to RPATH on Unix systems) to look in the right place relative to the >> launcher? >> The problem with failure to load jli.dll from the app launcher is >> that the system fails to load dependent dlls for jli.dll (MSVC >> run-time libs) from the directory with jli.dll even though the full >> path to jli.dll is specified in LoadLibrary() call. Launcher itself >> is statically linked with MSVC run-time libs. It it not an issue. >> >> > Did you try to load jli.dll by specifying full path to jli.dll when >> calling LoadLibary? >> Yes. Launcher loads jli.dll with the full path specified. The problem >> why LoadLibrary() fails to load it from the full path is that >> depending on OS/DLL loading settings LoadLibrary() would or would NOT >> look for dependent dlls in the directory where jli.dll is located. >> The tricky part about AddDllDirectory() is that it would work for >> LoadLibraryEx() with LOAD_LIBRARY_SEARCH_USER_DIRS only. Is this how >> Windows implicitly loads MSVC run-time libs before it completes >> explicit request to load jli.dll from the app launcher? I don't know. >> >> PATH env variable will be altered only in case the first attempt to >> load jli.dll fails. Value of PATH can be restored after jli.dll is >> loaded. This piece of code can be added to the patch. I'll also give >> another try to AddDllDirectory() with LoadLibraryEx() call. >> >> - Alexey >> >> On 5/12/2020 8:31 AM, Kevin Rushforth wrote: >>> Is there a way you can link the launcher (e.g., something similar to >>> RPATH on Unix systems) to look in the right place relative to the >>> launcher? Otherwise, the solution with adding to the PATH seems OK >>> to me. >>> >>> -- Kevin >>> >>> >>> On 5/12/2020 5:22 AM, Andy Herrick wrote: >>>> Is the problem that by removing the copy of the microsoft dlls from >>>> the applications bin directory, then on machines that do not have >>>> all of these dll's already in the PATH (usually in >>>> C:\windows\system32) they can no longer be found ? >>>> >>>> I don't like manually manipulating the PATH env variable either, >>>> but if so I don't see what else can be done short of putting the >>>> app exe in the bin dir of the runtime. >>>> >>>> /Andy >>>> >>>> >>>> On 5/11/2020 9:37 PM, Alexander Matveev wrote: >>>>> Hi Alexey, >>>>> >>>>> Updating PATH does not look like good solution to me. Did you try >>>>> to load jli.dll by specifying full path to jli.dll when calling >>>>> LoadLibary? If it does not work, then for AddDllDirectory() did >>>>> you used LoadLibrary() or LoadLibraryEx() with >>>>> LOAD_LIBRARY_SEARCH_USER_DIRS? According to doc you need to use >>>>> LoadLibraryEx() with flag when using AddDllDirectory(). >>>>> >>>>> Thanks, >>>>> Alexander >>>>> >>>>> On 5/11/2020 4:36 PM, Alexey Semenyuk wrote: >>>>>> Please review fix [2] for jpackage bug [1]. >>>>>> >>>>>> Fix failure to load jli.dll from app launcher. The fix is to >>>>>> append path to directory with jli.dll to PATH env variable and >>>>>> load jli.dll with altered value of PATH if the first attempt to >>>>>> load jli.dll without altering PATH fails. >>>>>> >>>>>> - Alexey >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8244634 >>>>>> >>>>>> [2]?http://cr.openjdk.java.net/~asemenyuk/8244634/webrev.00 >>>>>> >>>>> >>> >> > From maurizio.cimadamore at oracle.com Wed May 13 12:12:00 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 13 May 2020 13:12:00 +0100 Subject: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator) In-Reply-To: <271da482-cdbc-1d53-2ddd-efcb3a62ddff@oracle.com> References: <7a96ec1b-cdec-1e3f-f6ca-102d7340e70a@oracle.com> <271da482-cdbc-1d53-2ddd-efcb3a62ddff@oracle.com> Message-ID: <543817be-92d5-d6b1-d8e5-88f6fd3f3346@oracle.com> Another iteration which addresses the latest CSR comments (the CSR has now been approved): * make MemorySegment::withAccessModes/hasAccessMode throw IllegalArgumentException in cases where the provided mask is invalid (this required a test tweak) * sprinkled a couple of references to the JLS in the package javadoc, as per CSR suggestions * Fixed the ParallelSum::findAny_bulk benchmarks, which were (erroneously) not testing all the elements in the segment Webrev: http://cr.openjdk.java.net/~mcimadamore/8243491_v4/webrev Delta webrev: http://cr.openjdk.java.net/~mcimadamore/8243491_v4/webrev_delta/ Cheers Maurizio On 01/05/2020 12:06, Maurizio Cimadamore wrote: > Latest iteration - the follow issues were addressed: > > * fix a bug with alignment of native segments triggering spurious > failures (contributed by Jorn) > * fix javadoc and tests for access modes (contributed by Chris) > * added benchmarks for Stream::findAny using segment spliterator > (contributed by Peter) > * addressed CSR comments > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v3/webrev > > Delta webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v3/webrev_delta/ > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v3/javadoc > > Specdiff: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v3/specdiff/overview-summary.html > > > > Cheers > Maurizio > > On 27/04/2020 13:13, Maurizio Cimadamore wrote: >> Another iteration, which addresses the following issues: >> >> * wrong copyright headers in certain tests >> * issue with TestNative when running in debug mode caused by >> mismatched malloc/os::free (contributed by Jorn) >> * clarify javadoc of MemoryHandles::withStride >> * improved implementation of MemoryAccessVarHandleGenerator to use >> hidden classes rather than Unsafe.dAC (contributed by Mandy) >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/8243491_v2/webrev >> >> Delta webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/8243491_v2/webrev_delta/ >> >> Javadoc: >> >> http://cr.openjdk.java.net/~mcimadamore/8243491_v2/javadoc >> >> Specdiff: >> >> http://cr.openjdk.java.net/~mcimadamore/8243491_v2/specdiff/overview-summary.html >> >> >> >> Cheers >> Maurizio >> >> >> On 23/04/2020 21:33, Maurizio Cimadamore wrote: >>> Hi, >>> time has come for another round of foreign memory access API >>> incubation (see JEP 383 [3]). This iteration aims at polishing some >>> of the rough edges of the API, and adds some of the functionalities >>> that developers have been asking for during this first round of >>> incubation. The revised API tightens the thread-confinement >>> constraints (by removing the MemorySegment::acquire method) and >>> instead provides more targeted support for parallel computation via >>> a segment spliterator. The API also adds a way to create a custom >>> native segment; this is, essentially, an unsafe API point, very >>> similar in spirit to the JNI NewDirectByteBuffer functionality [1]. >>> By using this bit of API,? power-users will be able to add support, >>> via MemorySegment, to *their own memory sources* (e.g. think of a >>> custom allocator written in C/C++). For now, this API point is >>> called off as "restricted" and a special read-only JDK property will >>> have to be set on the command line for calls to this method to >>> succeed. We are aware there's no precedent for something like this >>> in the Java SE API - but if Project Panama is to remain true about >>> its ultimate goal of replacing bits of JNI code with (low level) >>> Java code, stuff like this has to be *possible*. We anticipate that, >>> at some point, this property will become a true launcher flag, and >>> that the foreign restricted machinery will be integrated more neatly >>> into the module system. >>> >>> A list of the API, implementation and test changes is provided >>> below. If you have any questions, or need more detailed >>> explanations, I (and the rest of the Panama team) will be happy to >>> point at existing discussions, and/or to provide the feedback required. >>> >>> Thanks >>> Maurizio >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~mcimadamore/8243491_v1/webrev >>> >>> Javadoc: >>> >>> http://cr.openjdk.java.net/~mcimadamore/8243491_v1/javadoc >>> >>> Specdiff: >>> >>> http://cr.openjdk.java.net/~mcimadamore/8243491_v1/specdiff/overview-summary.html >>> >>> >>> CSR: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8243496 >>> >>> >>> >>> API changes >>> =========== >>> >>> * MemorySegment >>> ? - drop support for acquire() method - in its place now you can >>> obtain a spliterator from a segment, which supports divide-and-conquer >>> ? - revamped support for views - e.g. isReadOnly - now segments have >>> access modes >>> ? - added API to do serial confinement hand-off >>> (MemorySegment::withOwnerThread) >>> ? - added unsafe factory to construct a native segment out of an >>> existing address; this API is "restricted" and only available if the >>> program is executed using the -Dforeign.unsafe=permit flag. >>> ? - the MemorySegment::mapFromPath now returns a MappedMemorySegment >>> * MappedMemorySegment >>> ? - small sub-interface which provides extra capabilities for mapped >>> segments (load(), unload() and force()) >>> * MemoryAddress >>> ? - added distinction between *checked* and *unchecked* addresses; >>> *unchecked* addresses do not have a segment, so they cannot be >>> dereferenced >>> ? - added NULL memory address (it's an unchecked address) >>> ? - added factory to construct MemoryAddress from long value (result >>> is also an unchecked address) >>> ? - added API point to get raw address value (where possible - e.g. >>> if this is not an address pointing to a heap segment) >>> * MemoryLayout >>> ? - Added support for layout "attributes" - e.g. store metadata >>> inside MemoryLayouts >>> ? - Added MemoryLayout::isPadding predicate >>> ? - Added helper function to SequenceLayout to rehape/flatten >>> sequence layouts (a la NDArray [4]) >>> * MemoryHandles >>> ? - add support for general VarHandle combinators (similar to MH >>> combinators) >>> ? - add a combinator to turn a long-VH into a MemoryAddress VH (the >>> resulting MemoryAddress is also *unchecked* and cannot be dereferenced) >>> >>> Implementation changes >>> ====================== >>> >>> * add support for VarHandle combinators (e.g. IndirectVH) >>> >>> The idea here is simple: a VarHandle can almost be thought of as a >>> set of method handles (one for each access mode supported by the var >>> handle) that are lazily linked. This gives us a relatively simple >>> idea upon which to build support for custom var handle adapters: we >>> could create a VarHandle by passing an existing var handle and also >>> specify the set of adaptations that should be applied to the method >>> handle for a given access mode in the original var handle. The >>> result is a new VarHandle which might support a different carrier >>> type and more, or less coordinate types. Adding this support was >>> relatively easy - and it only required one low-level surgery of the >>> lambda forms generated for adapted var handle (this is required so >>> that the "right" var handle receiver can be used for dispatching the >>> access mode call). >>> >>> All the new adapters in the MemoryHandles API (which are really >>> defined inside VarHandles) are really just a bunch of MH adapters >>> that are stitched together into a brand new VH. The only caveat is >>> that, we could have a checked exception mismatch: the VarHandle API >>> methods are specified not to throw any checked exception, whereas >>> method handles can throw any throwable. This means that, >>> potentially, calling get() on an adapted VarHandle could result in a >>> checked exception being thrown; to solve this gnarly issue, we >>> decided to scan all the filter functions passed to the VH >>> combinators and look for direct method handles which throw checked >>> exceptions. If such MHs are found (these can be deeply nested, since >>> the MHs can be adapted on their own), adaptation of the target VH >>> fails fast. >>> >>> >>> * More ByteBuffer implementation changes >>> >>> Some more changes to ByteBuffer support were necessary here. First, >>> we have added support for retrieval of "mapped" properties >>> associated with a ByteBuffer (e.g. the file descriptor, etc.). This >>> is crucial if we want to be able to turn an existing byte buffer >>> into the "right kind" of memory segment. >>> >>> Conversely, we also have to allow creation of mapped byte buffers >>> given existing parameters - which is needed when going from (mapped) >>> segment to a buffer. These two pieces together allow us to go from >>> segment to buffer and back w/o losing any information about the >>> underlying memory mapping (which was an issue in the previous >>> implementation). >>> >>> Lastly, to support the new MappedMemorySegment abstraction, all the >>> memory mapped supporting functionalities have been moved into a >>> common helper class so that MappedMemorySegmentImpl can reuse that >>> (e.g. for MappedMemorySegment::force). >>> >>> * Rewritten memory segment hierarchy >>> >>> The old implementation had a monomorphic memory segment class. In >>> this round we aimed at splitting the various implementation classes >>> so that we have a class for heap segments (HeapMemorySegmentImpl), >>> one for native segments (NativeMemorySegmentImpl) and one for memory >>> mapped segments (MappedMemorySegmentImpl, which extends from >>> NativeMemorySegmentImpl). Not much to see here - although one >>> important point is that, by doing this, we have been able to speed >>> up performances quite a bit, since now e.g. native/mapped segments >>> are _guaranteed_ to have a null "base". We have also done few tricks >>> to make sure that the "base" accessor for heap segment is sharply >>> typed and also NPE checked, which allows C2 to speculate more and >>> hoist. With these changes _all_ segment types have comparable >>> performances and hoisting guarantees (unlike in the old >>> implementation). >>> >>> * Add workarounds in MemoryAddressProxy, AbstractMemorySegmentImpl >>> to special case "small segments" so that VM can apply bound check >>> elimination >>> >>> This is another important piece which allows to get very good >>> performances out of indexes memory access var handles; as you might >>> know, the JIT compiler has troubles in optimizing loops where the >>> loop variable is a long [2]. To make up for that, in this round we >>> add an optimization which allows the API to detect whether a segment >>> is *small* or *large*. For small segments, the API realizes that >>> there's no need to perform long computation (e.g. to perform bound >>> checks, or offset additions), so it falls back to integer logic, >>> which in turns allows bound check elimination. >>> >>> * renaming of the various var handle classes to conform to "memory >>> access var handle" terminology >>> >>> This is mostly stylistic, nothing to see here. >>> >>> Tests changes >>> ============= >>> >>> In addition to the tests for the new API changes, we've also added >>> some stress tests for var handle combinators - e.g. there's a flag >>> that can be enabled which turns on some "dummy" var handle >>> adaptations on all var handles created by the runtime. We've used >>> this flag on existing tests to make sure that things work as expected. >>> >>> To sanity test the new memory segment spliterator, we have wired the >>> new segment spliterator with the existing spliterator test harness. >>> >>> We have also added several micro benchmarks for the memory segment >>> API (and made some changes to the build script so that native >>> libraries would be handled correctly). >>> >>> >>> [1] - >>> https://docs.oracle.com/en/java/javase/14/docs/specs/jni/functions.html#newdirectbytebuffer >>> [2] - https://bugs.openjdk.java.net/browse/JDK-8223051 >>> [3] - https://openjdk.java.net/jeps/383 >>> [4] - >>> https://docs.scipy.org/doc/numpy/reference/generated/numpy.reshape.html#numpy.reshape >>> >>> From chris.hegarty at oracle.com Wed May 13 13:59:53 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 13 May 2020 14:59:53 +0100 Subject: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator) In-Reply-To: <543817be-92d5-d6b1-d8e5-88f6fd3f3346@oracle.com> References: <7a96ec1b-cdec-1e3f-f6ca-102d7340e70a@oracle.com> <271da482-cdbc-1d53-2ddd-efcb3a62ddff@oracle.com> <543817be-92d5-d6b1-d8e5-88f6fd3f3346@oracle.com> Message-ID: <3E1DC24F-581E-473D-82AD-E17A94CA09AF@oracle.com> > On 13 May 2020, at 13:12, Maurizio Cimadamore wrote: > > Another iteration which addresses the latest CSR comments (the CSR has now been approved): > > * make MemorySegment::withAccessModes/hasAccessMode throw IllegalArgumentException in cases where the provided mask is invalid (this required a test tweak) > * sprinkled a couple of references to the JLS in the package javadoc, as per CSR suggestions > * Fixed the ParallelSum::findAny_bulk benchmarks, which were (erroneously) not testing all the elements in the segment > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v4/webrev > > Delta webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v4/webrev_delta/ > This latest version looks good to me. Reviewed. -Chris. From andy.herrick at oracle.com Wed May 13 14:11:56 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 13 May 2020 10:11:56 -0400 Subject: RFR: JDK-8244576: [macos] Volume icon deleted by osascript for background image Message-ID: Please review jpackage fix for issue [1] at [2]. [1] - https://bugs.openjdk.java.net/browse/JDK-8244576 [2] - http://cr.openjdk.java.net/~herrick/8244576/webrev.01/ /Andy From alexey.semenyuk at oracle.com Wed May 13 14:48:51 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Wed, 13 May 2020 10:48:51 -0400 Subject: RFR: JDK-8244576: [macos] Volume icon deleted by osascript for background image In-Reply-To: References: Message-ID: <03d70055-244c-81bc-5993-cecf10c40517@oracle.com> Looks good. - Alexey On 5/13/2020 10:11 AM, Andy Herrick wrote: > Please review jpackage fix for issue [1] at [2]. > > [1] - https://bugs.openjdk.java.net/browse/JDK-8244576 > > [2] - http://cr.openjdk.java.net/~herrick/8244576/webrev.01/ > > /Andy > From sgehwolf at redhat.com Wed May 13 14:59:42 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 13 May 2020 16:59:42 +0200 Subject: [8u] RFR: [JDK 8u] JapanEraNameCompatTest fails Message-ID: Hi, Could somebody please review this fix for the failing JapanEraNameCompatTest.java test (part of tier1)? The reason why it's failing is that there are missing locale data for no and sr_Latn which are exercised by the test. The original backport of JDK-8219781 didn't include those as the changed sections in the JDK 11 patch didn't exist in 8u. Those extra sections got introduced with JDK-8008577 or JDK- 8145136. This patch adds locale data for locales left out in the JDK-8219781 8u backport, except for JavaTimeSupplementary_in.java. That file doesn't exist at all in 8u, hence I've left that out. Missing locale info has been retrieved from JDK-8008577 and JDK-8145136 both of which aren't suitable to get backported to 8u. Bug: https://bugs.openjdk.java.net/browse/JDK-8244843 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244843/01/webrev/ Testing: tier1. One less test failure, namely JapanEraNameCompatTest, no longer fails. Thoughts? Thanks, Severin From gnu.andrew at redhat.com Wed May 13 15:11:02 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 May 2020 16:11:02 +0100 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: <15a2fa41f80935d8c7d3893aad7d080c1f67aa2a.camel@redhat.com> References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> <808419e3-316b-381d-f636-606aadff39b6@redhat.com> <15a2fa41f80935d8c7d3893aad7d080c1f67aa2a.camel@redhat.com> Message-ID: On 12/05/2020 15:14, Severin Gehwolf wrote: > Hi Andrew, > > Thanks for looking at this. > > On Tue, 2020-05-12 at 14:07 +0100, Andrew Haley wrote: >> On 5/7/20 4:09 PM, Severin Gehwolf wrote: >>> jvm_version_info.jvm_version currently holds this quadruplet: >>> >>> Most significant 8 bits => major version, followed by 8 bits => minor >>> version, followed by 8 bits => micro version, followed by 8 bits => >>> build version. Note that JVM minor version represents the update >>> version as passed in via configure and the micro version is currently >>> not used (always 0). See vm_version.cpp lines 100-102 where only major, >>> minor and build number are ever been set. Knowing this, we can still >>> preserve the same behavior after patch by defining JVM_VERSION_MICRO to >>> 0 for any version. >> >> This is tricky. JVM_GetVersionInfo is a function exported by >> libjvm.so, and the version is simply encoded as >> >> unsigned int Abstract_VM_Version::jvm_version() { >> return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) | >> ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) | >> (Abstract_VM_Version::vm_build_number() & 0xFF); >> } >> >> I guess we could argue that this is for JVM-JDK internal use only, and >> no-one else cares. >> >> Or we could encode it in a different way such that at least we have a >> jvm_version that is monotonically increasing, perhaps by (ab)using the >> lower 8 bits of the version, the vm_build_number. But I guess I'm >> being paranoid, and no tools are going to care about minor versions >> anyway,even if they do call JVM_GetVersionInfo. > > Yes, this is indeed tricky. The trouble is that > Abstract_VM_Version::vm_build_number() actually holds the configured > JDK build number, we can't really use it. It's already being used. > > (gdb) > 99 > 100 _vm_major_version = atoi(vm_major_ver); > 101 _vm_minor_version = atoi(vm_minor_ver); > 102 _vm_build_number = atoi(vm_build_num); > 103 > 104 os::free(vm_version); > 105 _initialized = true; > 106 } > 107 > 108 #if defined(_LP64) > (gdb) p _vm_build_number > $1 = 2 > > The only bits which seem unused are bits 8 through 16 of this unsigned > int. So even if JVM_GetVersionInfo *is* being used somewhere in the > wild, it *should* continue to work. Hence, the proposal to now also use > those unused bits for the minor version. > > Thoughts? > > Thanks, > Severin > The April release of OpenJDK 7u has the values: Major version: 24, minor version: 5, micro version: 0, build number: 2 when it should be 24.261-b02. So we already have a situation that could be potentially be misinterpreted as an old JDK version, 7u5 b02, using the current interpretation of the structure. 8u will see similar issues if we make no change in this cycle. As the micro version appears to have always been zero, it seems pretty safe to just hard-code this value and instead use all 16 bits of the interpreted value for the micro version. In terms of backwards compatibility, if a micro version greater than zero is read using the old method, this will be an indicator that it needs to be re-interpreted as a 16-bit value. The current value for 7 is 402980866 (0001 1000 0000 0101 0000 0000 0000 0010) which thus gets interpreted as above. The new method encodes the same version numbers as 402720002 (0001 1000 0000 0001 0000 0101 0000 0010) which can be read back as major 24, minor 261, micro 0 and build 2 using the updated decoding. If the old decoding is used, we get major 24, minor 1, micro 5 and build 2. As micro is usually set to zero, updated code should be able to use this to instead use the new interpretation, while, in the worst case, stale code will get a unique, if incorrect, version. As 7u releases are oddly numbered and increment in tens, we won't hit a case where the second byte (the old micro version) is zero. With 8u, this will happen where the update version is a multiple of 256 (e.g. 8u512, 8u1792, ...) Regarding the contract of this API, it is generally used only for interactions between the JVM and the class library. jvm.h is not included in the JDK image. Attempts to follow the API when CACAO & JamVM were still trying to work with OpenJDK suggest it has been unstable even across update releases [0] [1]. [0] https://icedtea.classpath.org/hg/icedtea7/rev/810d698ffdfb [1] https://icedtea.classpath.org/hg/icedtea7/rev/139f2a8f085d -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From claes.redestad at oracle.com Wed May 13 15:44:58 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 13 May 2020 17:44:58 +0200 Subject: RFR: 8244936: Reduce JNI overhead of accessing FileDescriptor Message-ID: Hi, compilers can't see though and optimize away the repeated GetObjectField calls in places such as in the io_util_md.h GET_FD macro: #define GET_FD(this, fid) \ (*env)->GetObjectField(env, (this), (fid)) == NULL ? \ -1 : (*env)->GetIntField(env, (*env)->GetObjectField(env, (this), (fid)), IO_fd_fdID) This can be avoided if we turn the macros into functions which call GetObjectField only once: FD getFD(JNIEnv *env, jobject this, jfieldID fid) { jobject fd = (*env)->GetObjectField(env, this, fid); if (fd == NULL) { return -1; } return (*env)->GetIntField(env, fd, IO_fd_fdID); } The similarly affected SET_FD is only used in one place, so I removed that macro and applied the equivalent optimization at the call-site. Webrev: http://cr.openjdk.java.net/~redestad/8244936/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8244936 This shows an improvement on the existing RandomAccessRead.test micro: Before: Benchmark (fileSize) Mode Cnt Score Error Units RandomAccessRead.test 1000000 avgt 25 0.832 ? 0.001 us/op After: Benchmark (fileSize) Mode Cnt Score Error Units RandomAccessRead.test 1000000 avgt 25 0.771 ? 0.005 us/op ~60ns/op overhead reduction - or ~30ns per native call (the micro calls RAF::seek followed by RAF::read). Since it's an improvement to the constant call overhead, relative gain diminishes for larger operations, e.g., reading a 512b buffer sees only ~2% improvement, while already on a 8kb read the improvement is more or less the noise. I added a read-into-buffer variant of the micro that demonstrates. Still, constant overhead is constant overhead, and operations that only read a few bytes is common enough, for example when opening zip files, so there's a fair chance for a positive effect in various places. As a bonus this refactoring shrinks libjava by a few Kb. Testing: tier1-2 Thanks! /Claes From naoto.sato at oracle.com Wed May 13 15:50:23 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 13 May 2020 08:50:23 -0700 Subject: [15] RFR: 8239383: Support for Unicode 13.0 In-Reply-To: References: Message-ID: <102402fa-02c1-fba1-5d48-a6fa76188b87@oracle.com> Ping. Naoto On 5/7/20 2:59 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8239383 > > Its CSR and proposed changeset are located at: > > https://bugs.openjdk.java.net/browse/JDK-8239504 > https://cr.openjdk.java.net/~naoto/8239383/webrev.00/ > > This updates java.lang.Character class to support Unicode Character > Database 13.0, as well as incorporating ICU4J version 67.1, which > corresponds to Unicode 13.0, for upgrading java.text.BiDi/Normalizer > support. Grapheme support in java.util.regex package is also upgraded to > 13.0 level. > > Naoto From gnu.andrew at redhat.com Wed May 13 16:37:00 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 May 2020 17:37:00 +0100 Subject: [8u] RFR: [JDK 8u] JapanEraNameCompatTest fails In-Reply-To: References: Message-ID: On 13/05/2020 15:59, Severin Gehwolf wrote: > Hi, > > Could somebody please review this fix for the failing > JapanEraNameCompatTest.java test (part of tier1)? The reason why it's > failing is that there are missing locale data for no and sr_Latn which > are exercised by the test. The original backport of JDK-8219781 didn't > include those as the changed sections in the JDK 11 patch didn't exist > in 8u. Those extra sections got introduced with JDK-8008577 or JDK- > 8145136. This also includes the JDK-8219781 changes for these locales. I think it's worth mentioning all three bug IDs in the summary text so they appear in a keyword search. Changes for these locales look ok to me. > > This patch adds locale data for locales left out in the JDK-8219781 8u > backport, except for JavaTimeSupplementary_in.java. That file doesn't > exist at all in 8u, hence I've left that out. This doesn't make sense to me. The in locale is present in sun/text/resources, but the only one without JavaTimeSupplementary_*: $ for locales in $(find jdk/src/share/classes/sun/text/resources/ -maxdepth 1 -mindepth 1 -type d) > do > locale=$(basename ${locales}) > echo ${locale}; ls ${locales}/JavaTimeSupplementary_${locale}* > done pt jdk/src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt.java jdk/src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt_PT.java ro jdk/src/share/classes/sun/text/resources/ro/JavaTimeSupplementary_ro.java hr jdk/src/share/classes/sun/text/resources/hr/JavaTimeSupplementary_hr.java es jdk/src/share/classes/sun/text/resources/es/JavaTimeSupplementary_es.java de jdk/src/share/classes/sun/text/resources/de/JavaTimeSupplementary_de.java in ls: cannot access 'jdk/src/share/classes/sun/text/resources/in/JavaTimeSupplementary_in*': No such file or directory tr jdk/src/share/classes/sun/text/resources/tr/JavaTimeSupplementary_tr.java sk jdk/src/share/classes/sun/text/resources/sk/JavaTimeSupplementary_sk.java mk jdk/src/share/classes/sun/text/resources/mk/JavaTimeSupplementary_mk.java ca jdk/src/share/classes/sun/text/resources/ca/JavaTimeSupplementary_ca.java iw jdk/src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw_IL.java jdk/src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw.java is jdk/src/share/classes/sun/text/resources/is/JavaTimeSupplementary_is.java lv jdk/src/share/classes/sun/text/resources/lv/JavaTimeSupplementary_lv.java sq jdk/src/share/classes/sun/text/resources/sq/JavaTimeSupplementary_sq.java vi jdk/src/share/classes/sun/text/resources/vi/JavaTimeSupplementary_vi.java hu jdk/src/share/classes/sun/text/resources/hu/JavaTimeSupplementary_hu.java ms jdk/src/share/classes/sun/text/resources/ms/JavaTimeSupplementary_ms.java no jdk/src/share/classes/sun/text/resources/no/JavaTimeSupplementary_no.java et jdk/src/share/classes/sun/text/resources/et/JavaTimeSupplementary_et.java da jdk/src/share/classes/sun/text/resources/da/JavaTimeSupplementary_da.java sr jdk/src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr.java jdk/src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr_Latn.java th jdk/src/share/classes/sun/text/resources/th/JavaTimeSupplementary_th.java it jdk/src/share/classes/sun/text/resources/it/JavaTimeSupplementary_it.java bg jdk/src/share/classes/sun/text/resources/bg/JavaTimeSupplementary_bg.java lt jdk/src/share/classes/sun/text/resources/lt/JavaTimeSupplementary_lt.java el jdk/src/share/classes/sun/text/resources/el/JavaTimeSupplementary_el.java pl jdk/src/share/classes/sun/text/resources/pl/JavaTimeSupplementary_pl.java ja jdk/src/share/classes/sun/text/resources/ja/JavaTimeSupplementary_ja.java ru jdk/src/share/classes/sun/text/resources/ru/JavaTimeSupplementary_ru.java be jdk/src/share/classes/sun/text/resources/be/JavaTimeSupplementary_be.java fi jdk/src/share/classes/sun/text/resources/fi/JavaTimeSupplementary_fi.java cs jdk/src/share/classes/sun/text/resources/cs/JavaTimeSupplementary_cs.java hi jdk/src/share/classes/sun/text/resources/hi/JavaTimeSupplementary_hi_IN.java en jdk/src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_GB.java jdk/src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en.java jdk/src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_SG.java sv jdk/src/share/classes/sun/text/resources/sv/JavaTimeSupplementary_sv.java ga jdk/src/share/classes/sun/text/resources/ga/JavaTimeSupplementary_ga.java fr jdk/src/share/classes/sun/text/resources/fr/JavaTimeSupplementary_fr.java zh jdk/src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh.java jdk/src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh_TW.java uk jdk/src/share/classes/sun/text/resources/uk/JavaTimeSupplementary_uk.java nl jdk/src/share/classes/sun/text/resources/nl/JavaTimeSupplementary_nl.java ko jdk/src/share/classes/sun/text/resources/ko/JavaTimeSupplementary_ko.java ar jdk/src/share/classes/sun/text/resources/ar/JavaTimeSupplementary_ar.java mt jdk/src/share/classes/sun/text/resources/mt/JavaTimeSupplementary_mt.java sl jdk/src/share/classes/sun/text/resources/sl/JavaTimeSupplementary_sl.java The file is introduced in JDK-8145136. Why not just take it from there and update with the changes in JDK-8219781? The test passes for this locale (as it does for nl, which is updated in this patch) because the values are the same as for the base locale (English). but there are other translations in that file which are missing in 8u. > > Missing locale info has been retrieved from JDK-8008577 and JDK-8145136 > both of which aren't suitable to get backported to 8u. Agreed. The problem with these changesets is they attempt to do everything in bulk. It's a problem I've seen with such changes before. We don't want to backport the CLDR update, but the updates to legacy locale data should be ok. We did used to get locale data updates with most CPUs. I haven't seen those since we switched to the current update system, which is a little worrying. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244843 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244843/01/webrev/ > > Testing: tier1. One less test failure, namely JapanEraNameCompatTest, > no longer fails. > > Thoughts? > I guess the number of people hitting the lack of a Serbian translation of a Japanese era name in the Latin character set was small, but it's good to have this fixed. Thanks for looking into it. > Thanks, > Severin > -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From christoph.dreis at freenet.de Wed May 13 17:32:17 2020 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Wed, 13 May 2020 19:32:17 +0200 Subject: Avoid getting hashCode of keys for empty ConcurrentHashMap Message-ID: <90ABA4F1-C990-413D-B96E-763D4C297A47@freenet.de> Hi, forgive me if this is not the correct list. I get confused where things about java.util.concurrent should be posted. I found an optimization opportunity in ConcurrentHashMap that seems relatively straight-forward. When ConcurrentHashMap.get() is called on an empty map, the key's hashCode() method is still called while it doesn't seem necessary to do so. With the attached patch I see the following results: Patched Benchmark Mode Cnt Score Error Units Benchmark.test avgt 10 2,713 ? 0,290 ns/op Benchmark.test:?gc.alloc.rate avgt 10 ? 10?? MB/sec Benchmark.test:?gc.alloc.rate.norm avgt 10 ? 10?? B/op MyBenchmark.test:?gc.count avgt 10 ? 0 counts Before patch Benchmark Mode Cnt Score Error Units Benchmark.test avgt 10 3,759 ? 0,442 ns/op Benchmark.test:?gc.alloc.rate avgt 10 ? 10?? MB/sec Benchmark.test:?gc.alloc.rate.norm avgt 10 ? 10?? B/op Benchmark.test:?gc.count avgt 10 ? 0 counts For completeness reasons, here is the benchmark I used: @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class MyBenchmark { @State(Scope.Benchmark) public static class ThreadState { private Map map = new ConcurrentHashMap<>(); private TestKey key = new TestKey(Collections.singleton("test")); } @Benchmark public String test(ThreadState threadState) { return threadState.map.get(threadState.key); } } Where TestKey is the following: public class TestKey { private final Set params; public TestKey(Set params) { this.params = params; } @Override public int hashCode() { return this.params.hashCode(); } } This usually happens if the map is not populated yet - which is also the case for some JDK internal usages. But I've also seen cases where the map stays empty during runtime[1]. If you think, this is worthwhile I'd appreciate if this patch could be sponsored. Cheers, Christoph [1] https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/main/java/org/springframework/core/SimpleAliasRegistry.java#L49 ========= PATCH ========== --- a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java Wed May 13 16:18:16 2020 +0200 +++ b/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java Wed May 13 19:15:46 2020 +0200 @@ -932,10 +932,9 @@ * @throws NullPointerException if the specified key is null */ public V get(Object key) { - Node[] tab; Node e, p; int n, eh; K ek; - int h = spread(key.hashCode()); + Node[] tab; Node e, p; int h, n, eh; K ek; if ((tab = table) != null && (n = tab.length) > 0 && - (e = tabAt(tab, (n - 1) & h)) != null) { + (e = tabAt(tab, (n - 1) & (h = spread(key.hashCode())))) != null) { if ((eh = e.hash) == h) { if ((ek = e.key) == key || (ek != null && key.equals(ek))) return e.val; From Roger.Riggs at oracle.com Wed May 13 17:47:44 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 13 May 2020 13:47:44 -0400 Subject: [15] RFR: 8239383: Support for Unicode 13.0 In-Reply-To: References: Message-ID: <09d82c1a-1614-23d2-c725-3341bfe42c8a@oracle.com> Hi Naoto, Looks fine. Lots of small changes but mostly in the Unicode reference files. Thanks, Roger On 5/7/20 5:59 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8239383 > > Its CSR and proposed changeset are located at: > > https://bugs.openjdk.java.net/browse/JDK-8239504 > https://cr.openjdk.java.net/~naoto/8239383/webrev.00/ > > This updates java.lang.Character class to support Unicode Character > Database 13.0, as well as incorporating ICU4J version 67.1, which > corresponds to Unicode 13.0, for upgrading java.text.BiDi/Normalizer > support. Grapheme support in java.util.regex package is also upgraded > to 13.0 level. > > Naoto From Roger.Riggs at oracle.com Wed May 13 17:55:58 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 13 May 2020 13:55:58 -0400 Subject: RFR: 8244936: Reduce JNI overhead of accessing FileDescriptor In-Reply-To: References: Message-ID: <5b065fa1-28a8-f400-676d-995b1a495a5f@oracle.com> Hi Claes, Looks fine. Straightfoward since the offiset is already cached for other operations. Thanks, Roger On 5/13/20 11:44 AM, Claes Redestad wrote: > Hi, > > compilers can't see though and optimize away the repeated GetObjectField > calls in places such as in the io_util_md.h GET_FD macro: > > #define GET_FD(this, fid) \ > ??? (*env)->GetObjectField(env, (this), (fid)) == NULL ? \ > ??????? -1 : (*env)->GetIntField(env, (*env)->GetObjectField(env, > (this), (fid)), IO_fd_fdID) > > This can be avoided if we turn the macros into functions which call > GetObjectField only once: > > FD getFD(JNIEnv *env, jobject this, jfieldID fid) { > ? jobject fd = (*env)->GetObjectField(env, this, fid); > ? if (fd == NULL) { > ??? return -1; > ? } > ? return (*env)->GetIntField(env, fd, IO_fd_fdID); > } > > The similarly affected SET_FD is only used in one place, so I removed > that macro and applied the equivalent optimization at the call-site. > > Webrev: http://cr.openjdk.java.net/~redestad/8244936/open.00/ > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8244936 > > This shows an improvement on the existing RandomAccessRead.test micro: > > Before: > Benchmark??????????????? (fileSize)? Mode? Cnt? Score?? Error Units > RandomAccessRead.test?????? 1000000? avgt?? 25? 0.832 ? 0.001 us/op > > After: > Benchmark??????????????? (fileSize)? Mode? Cnt? Score?? Error Units > RandomAccessRead.test?????? 1000000? avgt?? 25? 0.771 ? 0.005 us/op > > ~60ns/op overhead reduction - or ~30ns per native call (the micro calls > RAF::seek followed by RAF::read). > > Since it's an improvement to the constant call overhead, relative gain > diminishes for larger operations, e.g., reading a 512b buffer sees only > ~2% improvement, while already on a 8kb read the improvement is more or > less the noise. I added a read-into-buffer variant of the micro that > demonstrates. > > Still, constant overhead is constant overhead, and operations that only > read a few bytes is common enough, for example when opening zip files, > so there's a fair chance for a positive effect in various places. As a > bonus this refactoring shrinks libjava by a few Kb. > > Testing: tier1-2 > > Thanks! > > /Claes From martinrb at google.com Wed May 13 17:59:08 2020 From: martinrb at google.com (Martin Buchholz) Date: Wed, 13 May 2020 10:59:08 -0700 Subject: Avoid getting hashCode of keys for empty ConcurrentHashMap In-Reply-To: <90ABA4F1-C990-413D-B96E-763D4C297A47@freenet.de> References: <90ABA4F1-C990-413D-B96E-763D4C297A47@freenet.de> Message-ID: Thanks! I filed https://bugs.openjdk.java.net/browse/JDK-8244960 Looks like a good change. (But we are more time-limited than usual these days) On Wed, May 13, 2020 at 10:35 AM Christoph Dreis wrote: > > Hi, > > forgive me if this is not the correct list. I get confused where things about java.util.concurrent should be posted. > > I found an optimization opportunity in ConcurrentHashMap that seems relatively straight-forward. > > When ConcurrentHashMap.get() is called on an empty map, the key's hashCode() method is still called while it doesn't seem necessary to do so. > > With the attached patch I see the following results: > > Patched > Benchmark Mode Cnt Score Error Units > Benchmark.test avgt 10 2,713 ? 0,290 ns/op > Benchmark.test:?gc.alloc.rate avgt 10 ? 10?? MB/sec > Benchmark.test:?gc.alloc.rate.norm avgt 10 ? 10?? B/op > MyBenchmark.test:?gc.count avgt 10 ? 0 counts > > Before patch > Benchmark Mode Cnt Score Error Units > Benchmark.test avgt 10 3,759 ? 0,442 ns/op > Benchmark.test:?gc.alloc.rate avgt 10 ? 10?? MB/sec > Benchmark.test:?gc.alloc.rate.norm avgt 10 ? 10?? B/op > Benchmark.test:?gc.count avgt 10 ? 0 counts > > For completeness reasons, here is the benchmark I used: > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class MyBenchmark { > > @State(Scope.Benchmark) > public static class ThreadState { > > private Map map = new ConcurrentHashMap<>(); > private TestKey key = new TestKey(Collections.singleton("test")); > > } > > @Benchmark > public String test(ThreadState threadState) { > return threadState.map.get(threadState.key); > } > > } > > Where TestKey is the following: > > public class TestKey { > > private final Set params; > > public TestKey(Set params) { > this.params = params; > } > > @Override > public int hashCode() { > return this.params.hashCode(); > } > > } > > This usually happens if the map is not populated yet - which is also the case for some JDK internal usages. But I've also seen cases where the map stays empty during runtime[1]. > > If you think, this is worthwhile I'd appreciate if this patch could be sponsored. > > Cheers, > Christoph > > [1] https://github.com/spring-projects/spring-framework/blob/master/spring-core/src/main/java/org/springframework/core/SimpleAliasRegistry.java#L49 > > > ========= PATCH ========== > > --- a/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java Wed May 13 16:18:16 2020 +0200 > +++ b/src/java.base/share/classes/java/util/concurrent/ConcurrentHashMap.java Wed May 13 19:15:46 2020 +0200 > @@ -932,10 +932,9 @@ > * @throws NullPointerException if the specified key is null > */ > public V get(Object key) { > - Node[] tab; Node e, p; int n, eh; K ek; > - int h = spread(key.hashCode()); > + Node[] tab; Node e, p; int h, n, eh; K ek; > if ((tab = table) != null && (n = tab.length) > 0 && > - (e = tabAt(tab, (n - 1) & h)) != null) { > + (e = tabAt(tab, (n - 1) & (h = spread(key.hashCode())))) != null) { > if ((eh = e.hash) == h) { > if ((ek = e.key) == key || (ek != null && key.equals(ek))) > return e.val; > > From claes.redestad at oracle.com Wed May 13 18:12:52 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 13 May 2020 20:12:52 +0200 Subject: RFR: 8244936: Reduce JNI overhead of accessing FileDescriptor In-Reply-To: <5b065fa1-28a8-f400-676d-995b1a495a5f@oracle.com> References: <5b065fa1-28a8-f400-676d-995b1a495a5f@oracle.com> Message-ID: <5b770149-327f-6c60-ef92-16ea8f4d71ea@oracle.com> Hi Roger, On 2020-05-13 19:55, Roger Riggs wrote: > Hi Claes, > > Looks fine. thank you for reviewing! /Claes > Straightfoward since the offiset is already cached for other operations. > > Thanks, Roger From Alan.Bateman at oracle.com Wed May 13 18:31:36 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 13 May 2020 19:31:36 +0100 Subject: RFR: 8244936: Reduce JNI overhead of accessing FileDescriptor In-Reply-To: References: Message-ID: <38970d5b-7dbd-211f-de8c-9b09037a0a84@oracle.com> On 13/05/2020 16:44, Claes Redestad wrote: > Hi, > > compilers can't see though and optimize away the repeated GetObjectField > calls in places such as in the io_util_md.h GET_FD macro: > > #define GET_FD(this, fid) \ > ??? (*env)->GetObjectField(env, (this), (fid)) == NULL ? \ > ??????? -1 : (*env)->GetIntField(env, (*env)->GetObjectField(env, > (this), (fid)), IO_fd_fdID) > > This can be avoided if we turn the macros into functions which call > GetObjectField only once: > > FD getFD(JNIEnv *env, jobject this, jfieldID fid) { > ? jobject fd = (*env)->GetObjectField(env, this, fid); > ? if (fd == NULL) { > ??? return -1; > ? } > ? return (*env)->GetIntField(env, fd, IO_fd_fdID); > } > > The similarly affected SET_FD is only used in one place, so I removed > that macro and applied the equivalent optimization at the call-site. The Windows implementation returns a HANDLE rather than an int fd so there is a bit inconsistency when compared to the network code. This pre-dates your change and technical debt that will need attention some time. Your changes look good. -Alan From claes.redestad at oracle.com Wed May 13 18:35:53 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 13 May 2020 20:35:53 +0200 Subject: RFR: 8244936: Reduce JNI overhead of accessing FileDescriptor In-Reply-To: <38970d5b-7dbd-211f-de8c-9b09037a0a84@oracle.com> References: <38970d5b-7dbd-211f-de8c-9b09037a0a84@oracle.com> Message-ID: <7f510c36-0e3b-9239-e546-23a26dbee5b4@oracle.com> On 2020-05-13 20:31, Alan Bateman wrote: > On 13/05/2020 16:44, Claes Redestad wrote: >> Hi, >> >> compilers can't see though and optimize away the repeated GetObjectField >> calls in places such as in the io_util_md.h GET_FD macro: >> >> #define GET_FD(this, fid) \ >> ??? (*env)->GetObjectField(env, (this), (fid)) == NULL ? \ >> ??????? -1 : (*env)->GetIntField(env, (*env)->GetObjectField(env, >> (this), (fid)), IO_fd_fdID) >> >> This can be avoided if we turn the macros into functions which call >> GetObjectField only once: >> >> FD getFD(JNIEnv *env, jobject this, jfieldID fid) { >> ? jobject fd = (*env)->GetObjectField(env, this, fid); >> ? if (fd == NULL) { >> ??? return -1; >> ? } >> ? return (*env)->GetIntField(env, fd, IO_fd_fdID); >> } >> >> The similarly affected SET_FD is only used in one place, so I removed >> that macro and applied the equivalent optimization at the call-site. > The Windows implementation returns a HANDLE rather than an int fd so > there is a bit inconsistency when compared to the network code. This > pre-dates your change and technical debt that will need attention some > time. Your changes look good. Right, FD is defined as jlong on Windows, int elsewhere. Since it's used from shared code renaming it to HANDLE on Windows variant wouldn't work - rather we'd need some type name that would capture the duality (FD_OR_HANDLE?) Thanks for the review! /Claes From sgehwolf at redhat.com Wed May 13 19:26:19 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 13 May 2020 21:26:19 +0200 Subject: [8u] RFR: [JDK 8u] JapanEraNameCompatTest fails In-Reply-To: References: Message-ID: <12b4fdfab95f458c396b7e0b64770907adb19a1a.camel@redhat.com> Hi Andrew, Thanks for looking at this. On Wed, 2020-05-13 at 17:37 +0100, Andrew Hughes wrote: > On 13/05/2020 15:59, Severin Gehwolf wrote: > > Hi, > > > > Could somebody please review this fix for the failing > > JapanEraNameCompatTest.java test (part of tier1)? The reason why it's > > failing is that there are missing locale data for no and sr_Latn which > > are exercised by the test. The original backport of JDK-8219781 didn't > > include those as the changed sections in the JDK 11 patch didn't exist > > in 8u. Those extra sections got introduced with JDK-8008577 or JDK- > > 8145136. > > This also includes the JDK-8219781 changes for these locales. I think > it's worth mentioning all three bug IDs in the summary text so they > appear in a keyword search. OK, done. > Changes for these locales look ok to me. > > > This patch adds locale data for locales left out in the JDK-8219781 8u > > backport, except for JavaTimeSupplementary_in.java. That file doesn't > > exist at all in 8u, hence I've left that out. > > This doesn't make sense to me. The in locale is present in > sun/text/resources, but the only one without JavaTimeSupplementary_*: Sorry for not being clear. I meant that there is no JavaTimeSupplementary_in.java in 8u (prior this patch). > $ for locales in $(find jdk/src/share/classes/sun/text/resources/ > -maxdepth 1 -mindepth 1 -type d) > > do > > locale=$(basename ${locales}) > > echo ${locale}; ls ${locales}/JavaTimeSupplementary_${locale}* > > done > pt > jdk/src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt.java > jdk/src/share/classes/sun/text/resources/pt/JavaTimeSupplementary_pt_PT.java > ro > jdk/src/share/classes/sun/text/resources/ro/JavaTimeSupplementary_ro.java > hr > jdk/src/share/classes/sun/text/resources/hr/JavaTimeSupplementary_hr.java > es > jdk/src/share/classes/sun/text/resources/es/JavaTimeSupplementary_es.java > de > jdk/src/share/classes/sun/text/resources/de/JavaTimeSupplementary_de.java > in > ls: cannot access > 'jdk/src/share/classes/sun/text/resources/in/JavaTimeSupplementary_in*': > No such file or directory > tr > jdk/src/share/classes/sun/text/resources/tr/JavaTimeSupplementary_tr.java > sk > jdk/src/share/classes/sun/text/resources/sk/JavaTimeSupplementary_sk.java > mk > jdk/src/share/classes/sun/text/resources/mk/JavaTimeSupplementary_mk.java > ca > jdk/src/share/classes/sun/text/resources/ca/JavaTimeSupplementary_ca.java > iw > jdk/src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw_IL.java > jdk/src/share/classes/sun/text/resources/iw/JavaTimeSupplementary_iw.java > is > jdk/src/share/classes/sun/text/resources/is/JavaTimeSupplementary_is.java > lv > jdk/src/share/classes/sun/text/resources/lv/JavaTimeSupplementary_lv.java > sq > jdk/src/share/classes/sun/text/resources/sq/JavaTimeSupplementary_sq.java > vi > jdk/src/share/classes/sun/text/resources/vi/JavaTimeSupplementary_vi.java > hu > jdk/src/share/classes/sun/text/resources/hu/JavaTimeSupplementary_hu.java > ms > jdk/src/share/classes/sun/text/resources/ms/JavaTimeSupplementary_ms.java > no > jdk/src/share/classes/sun/text/resources/no/JavaTimeSupplementary_no.java > et > jdk/src/share/classes/sun/text/resources/et/JavaTimeSupplementary_et.java > da > jdk/src/share/classes/sun/text/resources/da/JavaTimeSupplementary_da.java > sr > jdk/src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr.java > jdk/src/share/classes/sun/text/resources/sr/JavaTimeSupplementary_sr_Latn.java > th > jdk/src/share/classes/sun/text/resources/th/JavaTimeSupplementary_th.java > it > jdk/src/share/classes/sun/text/resources/it/JavaTimeSupplementary_it.java > bg > jdk/src/share/classes/sun/text/resources/bg/JavaTimeSupplementary_bg.java > lt > jdk/src/share/classes/sun/text/resources/lt/JavaTimeSupplementary_lt.java > el > jdk/src/share/classes/sun/text/resources/el/JavaTimeSupplementary_el.java > pl > jdk/src/share/classes/sun/text/resources/pl/JavaTimeSupplementary_pl.java > ja > jdk/src/share/classes/sun/text/resources/ja/JavaTimeSupplementary_ja.java > ru > jdk/src/share/classes/sun/text/resources/ru/JavaTimeSupplementary_ru.java > be > jdk/src/share/classes/sun/text/resources/be/JavaTimeSupplementary_be.java > fi > jdk/src/share/classes/sun/text/resources/fi/JavaTimeSupplementary_fi.java > cs > jdk/src/share/classes/sun/text/resources/cs/JavaTimeSupplementary_cs.java > hi > jdk/src/share/classes/sun/text/resources/hi/JavaTimeSupplementary_hi_IN.java > en > jdk/src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_GB.java > jdk/src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en.java > jdk/src/share/classes/sun/text/resources/en/JavaTimeSupplementary_en_SG.java > sv > jdk/src/share/classes/sun/text/resources/sv/JavaTimeSupplementary_sv.java > ga > jdk/src/share/classes/sun/text/resources/ga/JavaTimeSupplementary_ga.java > fr > jdk/src/share/classes/sun/text/resources/fr/JavaTimeSupplementary_fr.java > zh > jdk/src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh.java > jdk/src/share/classes/sun/text/resources/zh/JavaTimeSupplementary_zh_TW.java > uk > jdk/src/share/classes/sun/text/resources/uk/JavaTimeSupplementary_uk.java > nl > jdk/src/share/classes/sun/text/resources/nl/JavaTimeSupplementary_nl.java > ko > jdk/src/share/classes/sun/text/resources/ko/JavaTimeSupplementary_ko.java > ar > jdk/src/share/classes/sun/text/resources/ar/JavaTimeSupplementary_ar.java > mt > jdk/src/share/classes/sun/text/resources/mt/JavaTimeSupplementary_mt.java > sl > jdk/src/share/classes/sun/text/resources/sl/JavaTimeSupplementary_sl.java > > The file is introduced in JDK-8145136. Why not just take it from there > and update with the changes in JDK-8219781? Sure. Done now: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244843/02/webrev/ > The test passes for this locale (as it does for nl, which is updated in > this patch) because the values are the same as for the base locale > (English). but there are other translations in that file which are > missing in 8u. > > > Missing locale info has been retrieved from JDK-8008577 and JDK-8145136 > > both of which aren't suitable to get backported to 8u. > > Agreed. > > The problem with these changesets is they attempt to do everything in > bulk. It's a problem I've seen with such changes before. We don't want > to backport the CLDR update, but the updates to legacy locale data > should be ok. How does the updated webrev above look to you? > We did used to get locale data updates with most CPUs. I haven't seen > those since we switched to the current update system, which is a little > worrying. Good point. Thanks, Severin > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244843 > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244843/01/webrev/ > > > > Testing: tier1. One less test failure, namely JapanEraNameCompatTest, > > no longer fails. > > > > Thoughts? > > > > I guess the number of people hitting the lack of a Serbian translation > of a Japanese era name in the Latin character set was small, but it's > good to have this fixed. Thanks for looking into it. > > > Thanks, > > Severin > > From harold.seigel at oracle.com Wed May 13 21:09:12 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 13 May 2020 17:09:12 -0400 Subject: RFR: JDK-8225056 VM support for sealed classes Message-ID: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> Hi, Please review this patch for JVM and Core-libs support for the JEP 360 Sealed Classes preview feature.? Code changes include the following: * Processing of the new PermittedSubclasses attribute to enforce that a class or interface, whose super is a sealed class or interface, must be listed in the super's PermittedSubclasses attribute. * Disallow redefinition of a sealed class or interface if its redefinition would change its PermittedSubclasses attribute. * Support API's to determine if a class or interface is sealed and, if it's sealed, return a list of its permitted subclasses. * asm support for the PermittedSubclasses attribute Open Webrev: http://cr.openjdk.java.net/~vromero/8225056/webrev.00/index.html JBS bug: https://bugs.openjdk.java.net/browse/JDK-8225056 Java Language Spec changes: http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html JVM Spec changes: http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jvms.html JEP 360: https://bugs.openjdk.java.net/browse/JDK-8227043 JVM CSR: https://bugs.openjdk.java.net/browse/JDK-8242578 Changes to javac and other language tools will be reviewed separately. Thanks, Harold From alexander.matveev at oracle.com Wed May 13 21:19:55 2020 From: alexander.matveev at oracle.com (alexander.matveev at oracle.com) Date: Wed, 13 May 2020 14:19:55 -0700 Subject: RFR: JDK-8244576: [macos] Volume icon deleted by osascript for background image In-Reply-To: References: Message-ID: <72139aa2-268c-6442-914c-f42eb5075bbc@oracle.com> Hi Andy, Looks good. Thanks, Alexander On 5/13/20 7:11 AM, Andy Herrick wrote: > Please review jpackage fix for issue [1] at [2]. > > [1] - https://bugs.openjdk.java.net/browse/JDK-8244576 > > [2] - http://cr.openjdk.java.net/~herrick/8244576/webrev.01/ > > /Andy > From huizhe.wang at oracle.com Wed May 13 21:58:06 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 13 May 2020 14:58:06 -0700 Subject: [15] RFR: 8239383: Support for Unicode 13.0 In-Reply-To: <09d82c1a-1614-23d2-c725-3341bfe42c8a@oracle.com> References: <09d82c1a-1614-23d2-c725-3341bfe42c8a@oracle.com> Message-ID: +1 They are from the reference files, but it's interesting to note the ranges in Blocks.txt (that Character.java follows) for Tangut Supplement (18D00..18D8F) and CJK Unified Ideographs Extension G (30000..3134F) are slightly different from those in the online pdf files (http://www.unicode.org/charts/PDF/Unicode-13.0/), where Tangut Supplement showed "Range: 18D00?18D08" and CJK Unified Ideographs Extension G "Range: 30000?3134A". Best, Joe On 5/13/2020 10:47 AM, Roger Riggs wrote: > Hi Naoto, > > Looks fine. > Lots of small changes but mostly in the Unicode reference files. > > Thanks, Roger > > > On 5/7/20 5:59 PM, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8239383 >> >> Its CSR and proposed changeset are located at: >> >> https://bugs.openjdk.java.net/browse/JDK-8239504 >> https://cr.openjdk.java.net/~naoto/8239383/webrev.00/ >> >> This updates java.lang.Character class to support Unicode Character >> Database 13.0, as well as incorporating ICU4J version 67.1, which >> corresponds to Unicode 13.0, for upgrading java.text.BiDi/Normalizer >> support. Grapheme support in java.util.regex package is also upgraded >> to 13.0 level. >> >> Naoto > From brent.christian at oracle.com Wed May 13 22:21:48 2020 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 13 May 2020 15:21:48 -0700 Subject: RFR: (CSR) JDK-8236688 Clarify String::stripIndent javadoc when string ends with line terminator In-Reply-To: References: Message-ID: Hi, Jim I have a few comments on the new wording (hopefully my understanding is correct): ! *

  • If the block ends with a LF{@code "\n"} or CR{@code "\r"} character, ! * then this implies the block closes in column 0 of the next line, and thus ! * implies an indent of 0.

    • I feel like the opening wording could be improved. I presume this applies to, for instance, both the "\n" construct (\005C \006e) as well as LF character (\u000A). Maybe something like: "If the block ends with a line break (LF, "\n", CR, "\r"),..." Is it worth an example (or description) of what a block ending with a line break looks like? e.g. this is the end of the block. """ Also, it seems worth calling out here (or maybe later) that an indent of 0 means no leading white space is removed. Or maybe rework the ending phrase a bit: "..., then this implies the block closes in column 0 of the next line. In this case the indent is 0, and no leading incidental white space is removed. Thanks, -Brent On 5/11/20 12:38 PM, Jim Laskey wrote: > Sponsoring for Andrew Leonard. Please review the following CSR. Hopefully this clarifies user's misunderstanding when a line seems to disappear when the string ends with a line terminator. > > > CSR: https://bugs.openjdk.java.net/browse/JDK-8236688 > JBS: https://bugs.openjdk.java.net/browse/JDK-8230800 > > Thank you. > > Cheers, > > -- Jim > From naoto.sato at oracle.com Wed May 13 22:24:58 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 13 May 2020 15:24:58 -0700 Subject: [15] RFR: 8239383: Support for Unicode 13.0 In-Reply-To: References: <09d82c1a-1614-23d2-c725-3341bfe42c8a@oracle.com> Message-ID: <661bfd05-a7ad-2492-11b3-255056b18404@oracle.com> Thanks for the review, Joe! On 5/13/20 2:58 PM, Joe Wang wrote: > +1 > > They are from the reference files, but it's interesting to note the > ranges in Blocks.txt (that Character.java follows) for Tangut Supplement > (18D00..18D8F) and CJK Unified Ideographs Extension G (30000..3134F) are > slightly different from those in the online pdf files > (http://www.unicode.org/charts/PDF/Unicode-13.0/), where Tangut > Supplement showed "Range: 18D00?18D08" and CJK Unified Ideographs > Extension G "Range: 30000?3134A". IIUC, the chart in the PDF are the ranges of newly added characters in 13.0, so the range should be within the corresponding block, but not necessarily equal to the block range itself. Naoto > > Best, > Joe > > On 5/13/2020 10:47 AM, Roger Riggs wrote: >> Hi Naoto, >> >> Looks fine. >> Lots of small changes but mostly in the Unicode reference files. >> >> Thanks, Roger >> >> >> On 5/7/20 5:59 PM, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8239383 >>> >>> Its CSR and proposed changeset are located at: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8239504 >>> https://cr.openjdk.java.net/~naoto/8239383/webrev.00/ >>> >>> This updates java.lang.Character class to support Unicode Character >>> Database 13.0, as well as incorporating ICU4J version 67.1, which >>> corresponds to Unicode 13.0, for upgrading java.text.BiDi/Normalizer >>> support. Grapheme support in java.util.regex package is also upgraded >>> to 13.0 level. >>> >>> Naoto >> > From huizhe.wang at oracle.com Wed May 13 22:26:35 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 13 May 2020 15:26:35 -0700 Subject: [15] RFR: 8239383: Support for Unicode 13.0 In-Reply-To: <661bfd05-a7ad-2492-11b3-255056b18404@oracle.com> References: <09d82c1a-1614-23d2-c725-3341bfe42c8a@oracle.com> <661bfd05-a7ad-2492-11b3-255056b18404@oracle.com> Message-ID: On 5/13/2020 3:24 PM, naoto.sato at oracle.com wrote: > Thanks for the review, Joe! > > On 5/13/20 2:58 PM, Joe Wang wrote: >> +1 >> >> They are from the reference files, but it's interesting to note the >> ranges in Blocks.txt (that Character.java follows) for Tangut >> Supplement (18D00..18D8F) and CJK Unified Ideographs Extension G >> (30000..3134F) are slightly different from those in the online pdf >> files (http://www.unicode.org/charts/PDF/Unicode-13.0/), where Tangut >> Supplement showed "Range: 18D00?18D08" and CJK Unified Ideographs >> Extension G "Range: 30000?3134A". > > IIUC, the chart in the PDF are the ranges of newly added characters in > 13.0, so the range should be within the corresponding block, but not > necessarily equal to the block range itself. That makes sense. -Joe > > Naoto > >> >> Best, >> Joe >> >> On 5/13/2020 10:47 AM, Roger Riggs wrote: >>> Hi Naoto, >>> >>> Looks fine. >>> Lots of small changes but mostly in the Unicode reference files. >>> >>> Thanks, Roger >>> >>> >>> On 5/7/20 5:59 PM, naoto.sato at oracle.com wrote: >>>> Hello, >>>> >>>> Please review the fix to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8239383 >>>> >>>> Its CSR and proposed changeset are located at: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8239504 >>>> https://cr.openjdk.java.net/~naoto/8239383/webrev.00/ >>>> >>>> This updates java.lang.Character class to support Unicode Character >>>> Database 13.0, as well as incorporating ICU4J version 67.1, which >>>> corresponds to Unicode 13.0, for upgrading >>>> java.text.BiDi/Normalizer support. Grapheme support in >>>> java.util.regex package is also upgraded to 13.0 level. >>>> >>>> Naoto >>> >> From nick.gasson at arm.com Thu May 14 08:18:19 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Thu, 14 May 2020 16:18:19 +0800 Subject: RFR(XS): 8244981: jpackage error due to missing final newline in Debian control file Message-ID: <85pnb76ib8.fsf@arm.com> Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8244981 Webrev: http://cr.openjdk.java.net/~ngasson/8244981/webrev.0/ Several jpackage jtreg tests fail on Debian/Ubuntu with this error: Running [fakeroot, dpkg-deb, --verbose, -b, <..snip..>] dpkg-deb: error: parsing file '/tmp/<..snip..>/images/DEBIAN/control' near line 9 package 'appcategorytest': end of file during value of field 'Installed-Size' (missing final newline) dpkg-deb requires each field in the control file to be terminated with a newline. This patch adds a trailing newline to all resource files, but I think that shouldn't cause a problem. Tested with jdk/tools/jpackage jtreg tests. -- Thanks, Nick From daniel.fuchs at oracle.com Thu May 14 09:14:09 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 14 May 2020 10:14:09 +0100 Subject: RFR: JDK-8209774 - [TESTBUG]Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java In-Reply-To: <6755096D-7F8C-4F06-B5DD-65B849C5AC55@oracle.com> References: <4F6C2290-A3AE-4A93-BE99-D057C9CEC778@oracle.com> <54095829-fd05-267f-3330-deb6a8c213b8@oracle.com> <2a03d73b-e7d9-2799-dedd-7d4f097a3309@oracle.com> <5BA24215-81C0-4540-B425-DD9167FBFF44@oracle.com> <6755096D-7F8C-4F06-B5DD-65B849C5AC55@oracle.com> Message-ID: Hi Fernando, That looks good to me. best regards, -- daniel On 12/05/2020 11:46, Fernando Guallini wrote: > Thanks for your comments. > Below you can find a new web rev version that includes a test description in a comment: > http://cr.openjdk.java.net/~fyuan/fernando/8209774/webrev.01/ > > I will also create a JBS ticket to revisit this test and remove it if obsolete, if that is fine with you. > > -Fernando From james.laskey at oracle.com Thu May 14 12:26:12 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 14 May 2020 09:26:12 -0300 Subject: RFR: (CSR) JDK-8236688 Clarify String::stripIndent javadoc when string ends with line terminator In-Reply-To: References: Message-ID: Brent, Are you looking at the text by Andrew in the bug? I reworked the in the CSR. Cheers, -- Jim > On May 13, 2020, at 7:21 PM, Brent Christian wrote: > > Hi, Jim > > I have a few comments on the new wording (hopefully my understanding is correct): > > ! *

  • If the block ends with a LF{@code "\n"} or CR{@code "\r"} character, > ! * then this implies the block closes in column 0 of the next line, and thus > ! * implies an indent of 0.

    • > > > I feel like the opening wording could be improved. I presume this applies to, for instance, both the "\n" construct (\005C \006e) as well as LF character (\u000A). Maybe something like: > > "If the block ends with a line break (LF, "\n", CR, "\r"),..." > > > Is it worth an example (or description) of what a block ending with a line break looks like? e.g. > > this is the end of the block. > """ > > > Also, it seems worth calling out here (or maybe later) that an indent of 0 means no leading white space is removed. Or maybe rework the ending phrase a bit: > > "..., then this implies the block closes in column 0 of the next line. In this case the indent is 0, and no leading incidental white space is removed. > > Thanks, > -Brent > > On 5/11/20 12:38 PM, Jim Laskey wrote: >> Sponsoring for Andrew Leonard. Please review the following CSR. Hopefully this clarifies user's misunderstanding when a line seems to disappear when the string ends with a line terminator. >> CSR: https://bugs.openjdk.java.net/browse/JDK-8236688 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8230800 >> Thank you. >> Cheers, >> -- Jim From adinn at redhat.com Thu May 14 13:09:47 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 14 May 2020 14:09:47 +0100 Subject: RFR: 8244853 - The static build of libextnet is missing the JNI_OnLoad_extnet function In-Reply-To: <0a69f26b-34f6-6b57-1b7c-571cdd2f3f1e@oracle.com> References: <0a69f26b-34f6-6b57-1b7c-571cdd2f3f1e@oracle.com> Message-ID: <1475410f-7d21-3c6a-f698-5ebf977ac96d@redhat.com> Hi Alan, On 12/05/2020 19:57, Alan Bateman wrote: > Looks okay to me. I am glad to hear that and also to see this fixed quickly (thanks Bob for posting the patch). I'd like to see it backported to jdk11u (via jdk14u, of course) if possible in order to allow stock jdk14u/11u to be used to build GraalVM native images. I was unaware that this was a spec requirement for static libs. Can you point me at any discussion that explains why this is required and what the function might be expected to do? or even tell me when it was added to the spec? The macro appears to implement an empty function. Is there any expectation/requirement that it could/should do something more than that? I am also wondering if this is the only such omission or if other libs might require a corresponding JNI_OnLoad_extnet_xxx function. regards, Andrew Dinn ----------- > On 12/05/2020 19:46, Bob Vandette wrote: >> BUG: >> >> https://bugs.openjdk.java.net/browse/JDK-8244853 >> >> Please review this simple fix for JDK 15 which adds the required >> JNI_OnLoad_extnet function to the libextnet.a >> static library when it is built. >> >> the JDK 15 make static-libs-image target currently builds this static >> library but it is not spec compliant and >> causes the GraalVM native-image utility to fail generating executables >> due to the lack of the OnLoad symbol. >> >> >> CHANGE: >> >> diff --git a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c >> b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c >> --- a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c >> +++ b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c >> @@ -34,6 +34,11 @@ >> ? #include "jdk_net_LinuxSocketOptions.h" >> ? ? /* >> + * Declare library specific JNI_Onload entry if static build >> + */ >> +DEF_STATIC_JNI_OnLoad >> + >> +/* >> ?? * Class:???? jdk_net_LinuxSocketOptions >> ?? * Method:??? setQuickAck >> ?? * Signature: (II)V >> diff --git a/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c >> b/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c >> --- a/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c >> +++ b/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c >> @@ -32,6 +32,11 @@ >> ? #include >> ? #include "jni_util.h" >> ? +/* >> + * Declare library specific JNI_Onload entry if static build >> + */ >> +DEF_STATIC_JNI_OnLoad >> + >> ? static jint socketOptionSupported(jint sockopt) { >> ????? jint one = 1; >> ????? jint rv, s; >> diff --git >> a/src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c >> b/src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c >> --- a/src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c >> +++ b/src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c >> @@ -32,6 +32,11 @@ >> ? static int initialized = 0; >> ? ? /* >> + * Declare library specific JNI_Onload entry if static build >> + */ >> +DEF_STATIC_JNI_OnLoad >> + >> +/* >> ?? * Class:???? jdk_net_SolarisSocketOptions >> ?? * Method:??? init >> ?? * Signature: ()V > -- regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From bob.vandette at oracle.com Thu May 14 13:32:17 2020 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 14 May 2020 09:32:17 -0400 Subject: RFR: 8244853 - The static build of libextnet is missing the JNI_OnLoad_extnet function In-Reply-To: <1475410f-7d21-3c6a-f698-5ebf977ac96d@redhat.com> References: <0a69f26b-34f6-6b57-1b7c-571cdd2f3f1e@oracle.com> <1475410f-7d21-3c6a-f698-5ebf977ac96d@redhat.com> Message-ID: <3C5247E2-2C50-4535-B319-CF34AC6866EC@oracle.com> > On May 14, 2020, at 9:09 AM, Andrew Dinn wrote: > > Hi Alan, > > On 12/05/2020 19:57, Alan Bateman wrote: >> Looks okay to me. > > I am glad to hear that and also to see this fixed quickly (thanks Bob > for posting the patch). I'd like to see it backported to jdk11u (via > jdk14u, of course) if possible in order to allow stock jdk14u/11u to be > used to build GraalVM native images. > > I was unaware that this was a spec requirement for static libs. Can you > point me at any discussion that explains why this is required and what > the function might be expected to do? or even tell me when it was added > to the spec? The macro appears to implement an empty function. Is there > any expectation/requirement that it could/should do something more than > that? The static library support was added in JDK 8 under JEP 178 (https://openjdk.java.net/jeps/178 ) and integrated under https://bugs.openjdk.java.net/browse/JDK-8046168 . The macros that were added to jni_util.h are not part of the specification and were added for the JDK build to use. There are two forms of the macros. DEF_JNI_OnLoad is used when the onload function runs initialization logic and DEF_STATIC_JNI_OnLoad that adds an empty function only when building the library statically. Both macros append the library name when building static forms of each library. > > I am also wondering if this is the only such omission or if other libs > might require a corresponding JNI_OnLoad_extnet_xxx function. All JDK native libraries should have this support but I supposed it?s possible that new libraries have been added since JDK 8 that are missing the DEF_STATIC_JNI_OnLoad. I did a quick scan of the sources when implementing this fix and did not see any bare JNI_OnLoad functions. Bob. > > regards, > > > Andrew Dinn > ----------- > >> On 12/05/2020 19:46, Bob Vandette wrote: >>> BUG: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8244853 >>> >>> Please review this simple fix for JDK 15 which adds the required >>> JNI_OnLoad_extnet function to the libextnet.a >>> static library when it is built. >>> >>> the JDK 15 make static-libs-image target currently builds this static >>> library but it is not spec compliant and >>> causes the GraalVM native-image utility to fail generating executables >>> due to the lack of the OnLoad symbol. >>> >>> >>> CHANGE: >>> >>> diff --git a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c >>> b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c >>> --- a/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c >>> +++ b/src/jdk.net/linux/native/libextnet/LinuxSocketOptions.c >>> @@ -34,6 +34,11 @@ >>> #include "jdk_net_LinuxSocketOptions.h" >>> /* >>> + * Declare library specific JNI_Onload entry if static build >>> + */ >>> +DEF_STATIC_JNI_OnLoad >>> + >>> +/* >>> * Class: jdk_net_LinuxSocketOptions >>> * Method: setQuickAck >>> * Signature: (II)V >>> diff --git a/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c >>> b/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c >>> --- a/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c >>> +++ b/src/jdk.net/macosx/native/libextnet/MacOSXSocketOptions.c >>> @@ -32,6 +32,11 @@ >>> #include >>> #include "jni_util.h" >>> +/* >>> + * Declare library specific JNI_Onload entry if static build >>> + */ >>> +DEF_STATIC_JNI_OnLoad >>> + >>> static jint socketOptionSupported(jint sockopt) { >>> jint one = 1; >>> jint rv, s; >>> diff --git >>> a/src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c >>> b/src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c >>> --- a/src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c >>> +++ b/src/jdk.net/solaris/native/libextnet/SolarisSocketOptions.c >>> @@ -32,6 +32,11 @@ >>> static int initialized = 0; >>> /* >>> + * Declare library specific JNI_Onload entry if static build >>> + */ >>> +DEF_STATIC_JNI_OnLoad >>> + >>> +/* >>> * Class: jdk_net_SolarisSocketOptions >>> * Method: init >>> * Signature: ()V >> > > -- > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From javalists at cbfiddle.com Thu May 14 13:39:18 2020 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 14 May 2020 06:39:18 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> <4B44293C-2465-4BA7-B6F6-9AAA437760C4@cbfiddle.com> <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com> <8138A696-AE6D-49D4-9A9B-4E4C23DC65A4@cbfiddle.com> Message-ID: <83FBA525-902A-4F61-901D-E5E123ED85EB@cbfiddle.com> > HashSet/TreeSet could do what ConcurrentHashMap/ConcurrentSkipListSet do by using the "this contains that and that contains this" logic. Yes, at the cost of yet another performance regression. But how about this problem: Comparator cc = String.CASE_INSENSITIVE_ORDER; Set s1 = new TreeSet<>(cc); Set s2 = new TreeSet<>(cc); s1.add("hello"); s2.add("Hello"); s1.equals(s2) -> true s2.equals(s1) -> true s1.hashCode() == s2.hashCode() -> false From Alan.Bateman at oracle.com Thu May 14 13:40:07 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 14 May 2020 14:40:07 +0100 Subject: RFR: 8244853 - The static build of libextnet is missing the JNI_OnLoad_extnet function In-Reply-To: <1475410f-7d21-3c6a-f698-5ebf977ac96d@redhat.com> References: <0a69f26b-34f6-6b57-1b7c-571cdd2f3f1e@oracle.com> <1475410f-7d21-3c6a-f698-5ebf977ac96d@redhat.com> Message-ID: <1f3c5785-e435-47e7-f52f-509f2d475439@oracle.com> On 14/05/2020 14:09, Andrew Dinn wrote: > : > I was unaware that this was a spec requirement for static libs. Can you > point me at any discussion that explains why this is required and what > the function might be expected to do? or even tell me when it was added > to the spec? The macro appears to implement an empty function. Is there > any expectation/requirement that it could/should do something more than > that? > I see Bob's mail with a link to the JEP. You might also be looking for the "Support for Statically Linked Libraries" section of the JNI spec [1] that came from that JEP. -Alan [1] https://docs.oracle.com/en/java/javase/14/docs/specs/jni/invocation.html#support-for-statically-linked-libraries From info at j-kuhn.de Thu May 14 14:24:45 2020 From: info at j-kuhn.de (Johannes Kuhn) Date: Thu, 14 May 2020 16:24:45 +0200 Subject: Mismatch between spec and implementation of DataInputStream.readFully(byte[], int, int) Message-ID: <91007068-7280-7d35-b1f2-65253f90b969@j-kuhn.de> Found a small mismatch between the specification of DataInputStream.readFully(byte[] b, int off, int len) and its implementation. In particular, it doesn't throw an IndexOutOfBoundsException if offset is negative and len is 0. Reproducer below. I suggest changing the specification of this method to allow that behavior. This change should also affect DataInput, where care has to be taken that both behaviors are legal. - Johannes import java.io.ByteArrayInputStream; import java.io.DataInputStream; import java.io.IOException; public class DISBug { ??? public static void main(String[] args) throws IOException { ??????? try (var bais = new ByteArrayInputStream(new byte[0]); ??????????????? var dis = new DataInputStream(bais)) { ??????????? // From the spec: ??????????? // throws IndexOutOfBoundsException - if off is negative, len is negative, or len is greater than b.length - off. ??????????? byte[] b = new byte[0]; ??????????? int off = -1; // This is not valid ??????????? int len = 0; ??????????? dis.readFully(b, off, len); ??????????? throw new AssertionError("readFully did not throw"); ??????? } catch (IndexOutOfBoundsException expected) { ??????????? // Ignore, this exception is expected ??????? } ??? } } From claes.redestad at oracle.com Thu May 14 14:39:45 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 14 May 2020 16:39:45 +0200 Subject: RFR: 8245024: Simplify and eagerly initialize StringConcatFactory Message-ID: <368adada-9002-8f22-0a64-fd9a6f81cd26@oracle.com> Hi, JDK-8155090 added some measures to StringConcatFactory to prevent certain bootstrapping issues. I think we should consider eagerly initializing the StringConcatFactory base class during bootstrap instead. Doing so will add a tiny bit of class loading overhead to bootstrap (which of course will be amortized on first use of SCF) but still this would also be a good opportunity to clean up a little. One straightforward means to do so is to move the CACHE, DUMPER and CACHE_ENABLE fields to BytecodeStringBuilderStrategy, since it's the only place where they are used (the MethodHandle based strategies don't manually spin classes and rely on LF sharing to de-duplicate shared components). Webrev: http://cr.openjdk.java.net/~redestad/8245024/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8245024 This reduces initialization overhead and simplifices bootstraps for the default case, while still passing relevant test cases such as test/jdk /java/lang/String/concat/WithSecurityManager.java for all strategies. Testing: tier1-2 Thanks! /Claes From james.laskey at oracle.com Thu May 14 15:05:03 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Thu, 14 May 2020 12:05:03 -0300 Subject: RFR: 8245024: Simplify and eagerly initialize StringConcatFactory In-Reply-To: <368adada-9002-8f22-0a64-fd9a6f81cd26@oracle.com> References: <368adada-9002-8f22-0a64-fd9a6f81cd26@oracle.com> Message-ID: <9F9AF3F7-7440-4841-B67A-68C291CC88FC@oracle.com> Will this have an effect on JDK-8218173 ? > On May 14, 2020, at 11:39 AM, Claes Redestad wrote: > > Hi, > > JDK-8155090 added some measures to StringConcatFactory to prevent > certain bootstrapping issues. I think we should consider eagerly > initializing the StringConcatFactory base class during bootstrap > instead. > > Doing so will add a tiny bit of class loading overhead to bootstrap > (which of course will be amortized on first use of SCF) but still this > would also be a good opportunity to clean up a little. > > One straightforward means to do so is to move the CACHE, DUMPER and > CACHE_ENABLE fields to BytecodeStringBuilderStrategy, since it's the > only place where they are used (the MethodHandle based strategies don't > manually spin classes and rely on LF sharing to de-duplicate shared > components). > > Webrev: http://cr.openjdk.java.net/~redestad/8245024/open.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8245024 > > This reduces initialization overhead and simplifices bootstraps for the > default case, while still passing relevant test cases such as test/jdk > /java/lang/String/concat/WithSecurityManager.java for all strategies. > > Testing: tier1-2 > > Thanks! > > /Claes From claes.redestad at oracle.com Thu May 14 15:22:03 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 14 May 2020 17:22:03 +0200 Subject: RFR: 8245024: Simplify and eagerly initialize StringConcatFactory In-Reply-To: <9F9AF3F7-7440-4841-B67A-68C291CC88FC@oracle.com> References: <368adada-9002-8f22-0a64-fd9a6f81cd26@oracle.com> <9F9AF3F7-7440-4841-B67A-68C291CC88FC@oracle.com> Message-ID: On 2020-05-14 17:05, Jim Laskey wrote: > Will this have an effect on JDK-8218173 > ?? Interesting that you ask, since this cleanup was extracted from an attempted fix for 8218173. _Potentially_ this helps. But it won't fix it. Ensuring SCF.class is initialized reduces risk that we'll hit certain OOMEs when going into the BSM in a constrained environment, but doesn't eliminate the corner case in 8218173 entirely. Initializing the strategy up front might solve more of the issues in 8218173, but it's a slippery slope and it'd regress startup (likely adds ~5ms to startup due the MH lookups). As I was looking at an eager initialization I ran into weird bootstrapping issues, too, so I've backed away from trying to solve 8218173. /Claes > >> On May 14, 2020, at 11:39 AM, Claes Redestad >> > wrote: >> >> Hi, >> >> JDK-8155090 added some measures to StringConcatFactory to prevent >> certain bootstrapping issues. I think we should consider eagerly >> initializing the StringConcatFactory base class during bootstrap >> instead. >> >> Doing so will add a tiny bit of class loading overhead to bootstrap >> (which of course will be amortized on first use of SCF) but still this >> would also be a good opportunity to clean up a little. >> >> One straightforward means to do so is to move the CACHE, DUMPER and >> CACHE_ENABLE fields to BytecodeStringBuilderStrategy, since it's the >> only place where they are used (the MethodHandle based strategies don't >> manually spin classes and rely on LF sharing to de-duplicate shared >> components). >> >> Webrev: http://cr.openjdk.java.net/~redestad/8245024/open.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8245024 >> >> This reduces initialization overhead and simplifices bootstraps for the >> default case, while still passing relevant test cases such as test/jdk >> /java/lang/String/concat/WithSecurityManager.java for all strategies. >> >> Testing: tier1-2 >> >> Thanks! >> >> /Claes > From brian.burkhalter at oracle.com Thu May 14 15:25:48 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 14 May 2020 08:25:48 -0700 Subject: Mismatch between spec and implementation of DataInputStream.readFully(byte[], int, int) In-Reply-To: <91007068-7280-7d35-b1f2-65253f90b969@j-kuhn.de> References: <91007068-7280-7d35-b1f2-65253f90b969@j-kuhn.de> Message-ID: <6D6042C3-E9B4-478E-84A8-9E4FA823FFC9@oracle.com> Hi Johannes, > On May 14, 2020, at 7:24 AM, Johannes Kuhn wrote: > > Found a small mismatch between the specification of DataInputStream.readFully(byte[] b, int off, int len) and its implementation. > > In particular, it doesn't throw an IndexOutOfBoundsException if offset is negative and len is 0. It looks like you are correct. Objects.checkFromIndexSize() should ideally be used here [1]. > Reproducer below. > > I suggest changing the specification of this method to allow that behavior. The usual practice for longstanding API discrepancies is to change the spec to match the behavior. > This change should also affect DataInput, where care has to be taken that both behaviors are legal. I?ll file an issue. Thanks, Brian [1] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/util/Objects.html#checkFromIndexSize(int,int,int) From paul.sandoz at oracle.com Thu May 14 15:28:54 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 14 May 2020 08:28:54 -0700 Subject: RFR: 8245024: Simplify and eagerly initialize StringConcatFactory In-Reply-To: <368adada-9002-8f22-0a64-fd9a6f81cd26@oracle.com> References: <368adada-9002-8f22-0a64-fd9a6f81cd26@oracle.com> Message-ID: <6BE19064-CA9E-4599-BC51-C9B2784C1BCD@oracle.com> Looks good. ? Separately, not for this issue, the code changes you made impact what is mostly unused code. I don?t recall us ever changing the default strategy, nor I am aware of others changing it via a system property (except for our tests), are you? At the time when we introduced this feature we were not sure what might play out, now the dust has settled and we are more informed shall we consider removing the code for the other non-default strategies, thereby reducing the maintenance burden? Paul. > On May 14, 2020, at 7:39 AM, Claes Redestad wrote: > > Hi, > > JDK-8155090 added some measures to StringConcatFactory to prevent > certain bootstrapping issues. I think we should consider eagerly > initializing the StringConcatFactory base class during bootstrap > instead. > > Doing so will add a tiny bit of class loading overhead to bootstrap > (which of course will be amortized on first use of SCF) but still this > would also be a good opportunity to clean up a little. > > One straightforward means to do so is to move the CACHE, DUMPER and > CACHE_ENABLE fields to BytecodeStringBuilderStrategy, since it's the > only place where they are used (the MethodHandle based strategies don't > manually spin classes and rely on LF sharing to de-duplicate shared > components). > > Webrev: http://cr.openjdk.java.net/~redestad/8245024/open.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8245024 > > This reduces initialization overhead and simplifices bootstraps for the > default case, while still passing relevant test cases such as test/jdk > /java/lang/String/concat/WithSecurityManager.java for all strategies. > > Testing: tier1-2 > > Thanks! > > /Claes From brian.burkhalter at oracle.com Thu May 14 15:34:08 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 14 May 2020 08:34:08 -0700 Subject: Mismatch between spec and implementation of DataInputStream.readFully(byte[], int, int) In-Reply-To: <6D6042C3-E9B4-478E-84A8-9E4FA823FFC9@oracle.com> References: <91007068-7280-7d35-b1f2-65253f90b969@j-kuhn.de> <6D6042C3-E9B4-478E-84A8-9E4FA823FFC9@oracle.com> Message-ID: <6D11EDCB-0B4C-4EAC-81C5-CFB64A1CE649@oracle.com> > On May 14, 2020, at 8:25 AM, Brian Burkhalter wrote: > >> This change should also affect DataInput, where care has to be taken that both behaviors are legal. > > I?ll file an issue. Filed: https://bugs.openjdk.java.net/browse/JDK-8245036 Thanks, Brian From brian.burkhalter at oracle.com Thu May 14 16:01:51 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 14 May 2020 09:01:51 -0700 Subject: BigInteger.squareToLen() can be wrong (when called directly) In-Reply-To: References: Message-ID: Hi Jeff, I filed https://bugs.openjdk.java.net/browse/JDK-8245038 to track this. Thanks, Brian > On May 11, 2020, at 7:33 AM, Jeff Hain wrote: > > While trying to use BigInteger.squareToLen(x, len, z) directly > (with reflection), I saw that its pure Java implementation > computed wrong results when a 'z' is specified with > (z.length > 2 * len). > Ex.: > x = {1, 2} > len = 2 > with z.length = 4: {0, 1, 4, 4} (as expected) > with z.length = 5: {0, 1, 0, 8, 0} instead of {0, 1, 4, 4, 0} From javalists at cbfiddle.com Thu May 14 16:08:00 2020 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 14 May 2020 09:08:00 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: <6ac64550-4107-bc62-ad4d-9f19dc1751a3@oracle.com> References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> <4B44293C-2465-4BA7-B6F6-9AAA437760C4@cbfiddle.com> <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com> <8138A696-AE6D-49D4-9A9B-4E4C23DC65A4@cbfiddle.com> <6ac64550-4107-bc62-ad4d-9f19dc1751a3@oracle.com> Message-ID: <04EF21C5-0CD7-41B5-955D-8F0699058B8D@cbfiddle.com> You have said: I'm trying to fix semantic bugs in the way various collection operations handle situations with mixed membership semantics I believe this statement is misleading and is at the root of our apparently irreconcilable differences. Many if not most of the problematic examples of mixed membership semantics involve an argument declared to be a Set or a Collection. In the current framework, the Set and Collection interfaces prescribe a single membership semantics. As the specification of SortedSet clearly states: Note that the ordering maintained by a sorted set (whether or not an explicit comparator is provided) must be consistent with equals if the sorted set is to correctly implement the Set interface. It is not the responsibility of a specification to define the behavior of a method when it operates on an incorrectly implemented argument, and where there is no specification of behavior, there can be no semantic bug. I am not saying this to be pedantic or to disparage your concerns. The concerns are valid, but your statement suggests that they can be resolved by a series of bug fixes, which I believe would be a high risk strategy. The proper way to address these concerns is to consider them all to be part of a redesign of the framework, one in which Set and Collection explicitly define a range of possible membership semantics and specify the intended behavior of all methods in all combinations of membership semantics. (Do not take this as an endorsement of such a project. I consider it to have a high risk to value ratio, and if it were up to me, I would not fund it.) In the meantime, you might identify changes that make certain methods more forgiving when faced with non-conforming instances of Set or Collection. This is not inherently a bad thing, but as the change is not fixing a bug, the risk of behavior/performance regressions must be very low. Alan From claes.redestad at oracle.com Thu May 14 16:23:40 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 14 May 2020 18:23:40 +0200 Subject: RFR: 8245024: Simplify and eagerly initialize StringConcatFactory In-Reply-To: <6BE19064-CA9E-4599-BC51-C9B2784C1BCD@oracle.com> References: <368adada-9002-8f22-0a64-fd9a6f81cd26@oracle.com> <6BE19064-CA9E-4599-BC51-C9B2784C1BCD@oracle.com> Message-ID: On 2020-05-14 17:28, Paul Sandoz wrote: > Looks good. Thanks! > > ? > > Separately, not for this issue, the code changes you made impact what is mostly unused code. I don?t recall us ever changing the default strategy, nor I am aware of others changing it via a system property (except for our tests), are you? > > At the time when we introduced this feature we were not sure what might play out, now the dust has settled and we are more informed shall we consider removing the code for the other non-default strategies, thereby reducing the maintenance burden? It has been argued the alternative strategies might have a role to play as a fallback if the default strategy ever fails. So far we've not seen any reports to that effect, and the default strategy has been optimized substantially since inception, while alternatives have stayed more or less the same since 9 (barring some adjustment to work with hidden classes recently). I think a more effective fallback in face of any issues would be to desugar ISC call-sites to classic StringBuilder chains at link-time[1], like one would do at (javac) compile-time with -XDconcat=inline. But yeah, another issue. /Claes [1] "easy" to do with jlink, slightly tricker - but possible? - to do so as a linking step when loading the class into the VM > > Paul. > >> On May 14, 2020, at 7:39 AM, Claes Redestad wrote: >> >> Hi, >> >> JDK-8155090 added some measures to StringConcatFactory to prevent >> certain bootstrapping issues. I think we should consider eagerly >> initializing the StringConcatFactory base class during bootstrap >> instead. >> >> Doing so will add a tiny bit of class loading overhead to bootstrap >> (which of course will be amortized on first use of SCF) but still this >> would also be a good opportunity to clean up a little. >> >> One straightforward means to do so is to move the CACHE, DUMPER and >> CACHE_ENABLE fields to BytecodeStringBuilderStrategy, since it's the >> only place where they are used (the MethodHandle based strategies don't >> manually spin classes and rely on LF sharing to de-duplicate shared >> components). >> >> Webrev: http://cr.openjdk.java.net/~redestad/8245024/open.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8245024 >> >> This reduces initialization overhead and simplifices bootstraps for the >> default case, while still passing relevant test cases such as test/jdk >> /java/lang/String/concat/WithSecurityManager.java for all strategies. >> >> Testing: tier1-2 >> >> Thanks! >> >> /Claes > From huizhe.wang at oracle.com Thu May 14 16:28:36 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 14 May 2020 09:28:36 -0700 Subject: RFR: JDK-8209774 - [TESTBUG]Refactor shell test javax/xml/jaxp/common/8035437/run.sh to java In-Reply-To: References: <4F6C2290-A3AE-4A93-BE99-D057C9CEC778@oracle.com> <54095829-fd05-267f-3330-deb6a8c213b8@oracle.com> <2a03d73b-e7d9-2799-dedd-7d4f097a3309@oracle.com> <5BA24215-81C0-4540-B425-DD9167FBFF44@oracle.com> <6755096D-7F8C-4F06-B5DD-65B849C5AC55@oracle.com> Message-ID: <25122b69-fd60-cf0d-27d8-445cbff16d45@oracle.com> +1 Joe On 5/14/2020 2:14 AM, Daniel Fuchs wrote: > Hi Fernando, > > That looks good to me. > > best regards, > > -- daniel > > On 12/05/2020 11:46, Fernando Guallini wrote: >> Thanks for your comments. >> Below you can find a new web rev version that includes a test >> description in a comment: >> http://cr.openjdk.java.net/~fyuan/fernando/8209774/webrev.01/ >> >> >> I will also create a JBS ticket to revisit this test and remove it if >> obsolete, if that is fine with you. >> >> -Fernando From alexey.semenyuk at oracle.com Thu May 14 19:39:36 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 14 May 2020 15:39:36 -0400 Subject: RFR(XS): 8244981: jpackage error due to missing final newline in Debian control file In-Reply-To: <85pnb76ib8.fsf@arm.com> References: <85pnb76ib8.fsf@arm.com> Message-ID: <075df90c-1044-f7df-6bdc-8481913dca57@oracle.com> Looks good. - Alexey On 5/14/2020 4:18 AM, Nick Gasson wrote: > Hi, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8244981 > Webrev: http://cr.openjdk.java.net/~ngasson/8244981/webrev.0/ > > Several jpackage jtreg tests fail on Debian/Ubuntu with this error: > > Running [fakeroot, dpkg-deb, --verbose, -b, <..snip..>] > dpkg-deb: error: parsing file '/tmp/<..snip..>/images/DEBIAN/control' near line 9 package 'appcategorytest': > end of file during value of field 'Installed-Size' (missing final newline) > > dpkg-deb requires each field in the control file to be terminated with a > newline. This patch adds a trailing newline to all resource files, but I > think that shouldn't cause a problem. > > Tested with jdk/tools/jpackage jtreg tests. > > -- > Thanks, > Nick From mandy.chung at oracle.com Thu May 14 20:12:50 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 May 2020 13:12:50 -0700 Subject: RFR JDK-8244961: MethodHandles::privateLookupIn throws NPE when called during initPhase2 Message-ID: MethodHandles::privateLookupIn should prepare for being called during early startup when the module of java.base classes are not yet assigned.? This bug is uncovered by panama prototype converting NIO to use memory access API. The fix is very simple and move the call to Module::isNamed only if the caller module and target module are different: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8244961/webrev.00/ Mandy From mandy.chung at oracle.com Thu May 14 20:39:06 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 May 2020 13:39:06 -0700 Subject: RFR: 8245024: Simplify and eagerly initialize StringConcatFactory In-Reply-To: <368adada-9002-8f22-0a64-fd9a6f81cd26@oracle.com> References: <368adada-9002-8f22-0a64-fd9a6f81cd26@oracle.com> Message-ID: Hi Claes, Is the bootstrapping issue contributed by Class::getDeclaredConstructors call in InnerClassLambdaMetafactory::buildCallSite? I wonder how much performance gain compared to using Lookup::findConstructor for non-capturing lambda case.?? If LMF uses Lookup::findConstructor, it does not perform any security permission check since it's a full privileged lookup and address JDK-8155659 lambda bootstrapping issue with security manager.?? Is it easy to measure the performance difference? Mandy On 5/14/20 7:39 AM, Claes Redestad wrote: > Hi, > > JDK-8155090 added some measures to StringConcatFactory to prevent > certain bootstrapping issues. I think we should consider eagerly > initializing the StringConcatFactory base class during bootstrap > instead. > > Doing so will add a tiny bit of class loading overhead to bootstrap > (which of course will be amortized on first use of SCF) but still this > would also be a good opportunity to clean up a little. > > One straightforward means to do so is to move the CACHE, DUMPER and > CACHE_ENABLE fields to BytecodeStringBuilderStrategy, since it's the > only place where they are used (the MethodHandle based strategies don't > manually spin classes and rely on LF sharing to de-duplicate shared > components). > > Webrev: http://cr.openjdk.java.net/~redestad/8245024/open.00/ > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8245024 > > This reduces initialization overhead and simplifices bootstraps for the > default case, while still passing relevant test cases such as test/jdk > /java/lang/String/concat/WithSecurityManager.java for all strategies. > > Testing: tier1-2 > > Thanks! > > /Claes From chris.hegarty at oracle.com Thu May 14 20:52:14 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 14 May 2020 21:52:14 +0100 Subject: RFR JDK-8244961: MethodHandles::privateLookupIn throws NPE when called during initPhase2 In-Reply-To: References: Message-ID: Hi Mandy, > On 14 May 2020, at 21:12, Mandy Chung wrote: > > MethodHandles::privateLookupIn should prepare for being called during early startup when the module of java.base classes are not yet assigned. This bug is uncovered by panama prototype converting NIO to use memory access API. > > The fix is very simple and move the call to Module::isNamed only if the caller module and target module are different: > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8244961/webrev.00/ LGTM. In this case both the caller and target modules are, well.. , null (at this point of initialization). So your change should avoid tripping up on this and resulting in a NPE. I am surprised that nothing else has run into this before, but the code executed this early on is somewhat limited. -Chris. From claes.redestad at oracle.com Thu May 14 21:27:48 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 14 May 2020 23:27:48 +0200 Subject: RFR: 8245024: Simplify and eagerly initialize StringConcatFactory In-Reply-To: References: <368adada-9002-8f22-0a64-fd9a6f81cd26@oracle.com> Message-ID: <53809660-145d-3169-3e09-bf7a9e43724d@oracle.com> Hi Mandy, I haven't looked at JDK-8155659 in years - and lambda bootstrap has been simplified a lot since. Maybe there's a way to pre-initializate a few classes to avoid the issues similarly now. It's not been a priority to fix since it isn't a regression in behavior like JDK-8155090 was - "just" a behavioral gotcha. Doesn't mean it shouldn't be fixed, if possible. Regardless, SCF doesn't use the InnerClassLambdaMetafactory, so the bootstrapping circularity issue at hand here is unrelated. If you remove the initialization in System.java and run the test, you'll get a stacktrace like this: java.lang.BootstrapMethodError: bootstrap method initialization exception at WithSecurityManager$1.checkPermission(WithSecurityManager.java:59) at java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:747) at java.base/java.io.File.exists(File.java:818) at java.base/jdk.internal.loader.URLClassPath$FileLoader.getResource(URLClassPath.java:1239) at java.base/jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:317) at java.base/jdk.internal.loader.BuiltinClassLoader$4.run(BuiltinClassLoader.java:733) at java.base/jdk.internal.loader.BuiltinClassLoader$4.run(BuiltinClassLoader.java:731) at java.base/java.security.AccessController.doPrivileged(AccessController.java:312) at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:744) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:646) at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:604) at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:168) at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520) at com.sun.javatest.regtest.agent.MainWrapper.handleTestException(MainWrapper.java:94) at com.sun.javatest.regtest.agent.MainWrapper.access$000(MainWrapper.java:38) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:136) at java.base/java.lang.Thread.run(Thread.java:832) /Claes On 2020-05-14 22:39, Mandy Chung wrote: > Hi Claes, > > Is the bootstrapping issue contributed by Class::getDeclaredConstructors > call in InnerClassLambdaMetafactory::buildCallSite? > > I wonder how much performance gain compared to using > Lookup::findConstructor for non-capturing lambda case.?? If LMF uses > Lookup::findConstructor, it does not perform any security permission > check since it's a full privileged lookup and address JDK-8155659 lambda > bootstrapping issue with security manager.?? Is it easy to measure the > performance difference? > > Mandy > > On 5/14/20 7:39 AM, Claes Redestad wrote: >> Hi, >> >> JDK-8155090 added some measures to StringConcatFactory to prevent >> certain bootstrapping issues. I think we should consider eagerly >> initializing the StringConcatFactory base class during bootstrap >> instead. >> >> Doing so will add a tiny bit of class loading overhead to bootstrap >> (which of course will be amortized on first use of SCF) but still this >> would also be a good opportunity to clean up a little. >> >> One straightforward means to do so is to move the CACHE, DUMPER and >> CACHE_ENABLE fields to BytecodeStringBuilderStrategy, since it's the >> only place where they are used (the MethodHandle based strategies don't >> manually spin classes and rely on LF sharing to de-duplicate shared >> components). >> >> Webrev: http://cr.openjdk.java.net/~redestad/8245024/open.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8245024 >> >> This reduces initialization overhead and simplifices bootstraps for the >> default case, while still passing relevant test cases such as test/jdk >> /java/lang/String/concat/WithSecurityManager.java for all strategies. >> >> Testing: tier1-2 >> >> Thanks! >> >> /Claes > From brent.christian at oracle.com Thu May 14 21:45:14 2020 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 14 May 2020 14:45:14 -0700 Subject: RFR: (CSR) JDK-8236688 Clarify String::stripIndent javadoc when string ends with line terminator In-Reply-To: References: Message-ID: <9d67520b-5b23-2dcb-78ec-f2f933f8117a@oracle.com> On 5/14/20 5:26 AM, Jim Laskey wrote: > > Are you looking at the text by Andrew in the bug? It would seem so. I found the prettyprint markup in the CSR distracting, so I was looking at my own javadoc build, but used the older diff. I've rebuilt using the diff in the CSR. I have a few minor suggestions: * I would expect a colon, rather than a period, when "...as follows" precedes a bulleted list. * The wording of the third bullet point is good, though I find I preferred the numeral 0 to the word "zero". * The passage at the end of the @apiNote: "...ignore the last line if the last line contains no characters (ends with a line terminator.)" is potentially confusing in that a line terminator is a character in and of itself. Perhaps it could be reworked a little - something like: * "...ignore the last line if the last line contains only a line terminator." ? or * "...ignore the last line if the last line is empty (contains only a line terminator)." or something along those lines. Thanks, -Brent >> On May 13, 2020, at 7:21 PM, Brent Christian wrote: >> >> Hi, Jim >> >> I have a few comments on the new wording (hopefully my understanding is correct): >> >> ! *

  • If the block ends with a LF{@code "\n"} or CR{@code "\r"} character, >> ! * then this implies the block closes in column 0 of the next line, and thus >> ! * implies an indent of 0.

    • >> >> >> I feel like the opening wording could be improved. I presume this applies to, for instance, both the "\n" construct (\005C \006e) as well as LF character (\u000A). Maybe something like: >> >> "If the block ends with a line break (LF, "\n", CR, "\r"),..." >> >> >> Is it worth an example (or description) of what a block ending with a line break looks like? e.g. >> >> this is the end of the block. >> """ >> >> >> Also, it seems worth calling out here (or maybe later) that an indent of 0 means no leading white space is removed. Or maybe rework the ending phrase a bit: >> >> "..., then this implies the block closes in column 0 of the next line. In this case the indent is 0, and no leading incidental white space is removed. >> >> Thanks, >> -Brent >> >> On 5/11/20 12:38 PM, Jim Laskey wrote: >>> Sponsoring for Andrew Leonard. Please review the following CSR. Hopefully this clarifies user's misunderstanding when a line seems to disappear when the string ends with a line terminator. >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236688 >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8230800 >>> Thank you. >>> Cheers, >>> -- Jim > From mandy.chung at oracle.com Thu May 14 21:58:06 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 May 2020 14:58:06 -0700 Subject: RFR JDK-8244961: MethodHandles::privateLookupIn throws NPE when called during initPhase2 In-Reply-To: References: Message-ID: On 5/14/20 1:52 PM, Chris Hegarty wrote: > Hi Mandy, > >> On 14 May 2020, at 21:12, Mandy Chung wrote: >> >> MethodHandles::privateLookupIn should prepare for being called during early startup when the module of java.base classes are not yet assigned. This bug is uncovered by panama prototype converting NIO to use memory access API. >> >> The fix is very simple and move the call to Module::isNamed only if the caller module and target module are different: >> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8244961/webrev.00/ > LGTM. Thanks. > > In this case both the caller and target modules are, well.. , null (at this point of initialization). So your change should avoid tripping up on this and resulting in a NPE. I am surprised that nothing else has run into this before, but the code executed this early on is somewhat limited. JDK 9 jigsaw cleaned up various bootstrapping issues that enables early startup to use lambdas. ? This is very early during VM initialization and those code path may still be pre-JDK 9 code and not surprised that it does not use VarHandle/MethodHandle yet until this panama change. Mandy From mandy.chung at oracle.com Thu May 14 23:19:24 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 14 May 2020 16:19:24 -0700 Subject: RFR: 8245024: Simplify and eagerly initialize StringConcatFactory In-Reply-To: <53809660-145d-3169-3e09-bf7a9e43724d@oracle.com> References: <368adada-9002-8f22-0a64-fd9a6f81cd26@oracle.com> <53809660-145d-3169-3e09-bf7a9e43724d@oracle.com> Message-ID: <93a25977-1fe6-6b48-80f3-3b79e981075e@oracle.com> Ah, it's unrelated to JDK-8155659. The change looks okay.? Minor: it might worth adding the getClassName method in BSBS class. I also agree with Paul that we should examine if it's time to remove the non-default strategies if they are mostly unused. Mandy On 5/14/20 2:27 PM, Claes Redestad wrote: > Hi Mandy, > > I haven't looked at JDK-8155659 in years - and lambda bootstrap has been > simplified a lot since. Maybe there's a way to pre-initializate a few > classes to avoid the issues similarly now. It's not been a priority > to fix since it isn't a regression in behavior like JDK-8155090 was - > "just" a behavioral gotcha. Doesn't mean it shouldn't be fixed, if > possible. > > Regardless, SCF doesn't use the InnerClassLambdaMetafactory, so the > bootstrapping circularity issue at hand here is unrelated. > > If you remove the initialization in System.java and run the test, you'll > get a stacktrace like this: > > java.lang.BootstrapMethodError: bootstrap method initialization exception > ????at WithSecurityManager$1.checkPermission(WithSecurityManager.java:59) > ????at > java.base/java.lang.SecurityManager.checkRead(SecurityManager.java:747) > ????at java.base/java.io.File.exists(File.java:818) > ????at > java.base/jdk.internal.loader.URLClassPath$FileLoader.getResource(URLClassPath.java:1239) > ????at > java.base/jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:317) > ????at > java.base/jdk.internal.loader.BuiltinClassLoader$4.run(BuiltinClassLoader.java:733) > ????at > java.base/jdk.internal.loader.BuiltinClassLoader$4.run(BuiltinClassLoader.java:731) > ????at > java.base/java.security.AccessController.doPrivileged(AccessController.java:312) > ????at > java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:744) > ????at > java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:646) > ????at > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:604) > ????at > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:168) > ????at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520) > ????at > com.sun.javatest.regtest.agent.MainWrapper.handleTestException(MainWrapper.java:94) > ????at > com.sun.javatest.regtest.agent.MainWrapper.access$000(MainWrapper.java:38) > ????at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:136) > ????at java.base/java.lang.Thread.run(Thread.java:832) > > /Claes > > On 2020-05-14 22:39, Mandy Chung wrote: >> Hi Claes, >> >> Is the bootstrapping issue contributed by >> Class::getDeclaredConstructors call in >> InnerClassLambdaMetafactory::buildCallSite? >> >> I wonder how much performance gain compared to using >> Lookup::findConstructor for non-capturing lambda case.?? If LMF uses >> Lookup::findConstructor, it does not perform any security permission >> check since it's a full privileged lookup and address JDK-8155659 >> lambda bootstrapping issue with security manager. Is it easy to >> measure the performance difference? >> >> Mandy >> >> On 5/14/20 7:39 AM, Claes Redestad wrote: >>> Hi, >>> >>> JDK-8155090 added some measures to StringConcatFactory to prevent >>> certain bootstrapping issues. I think we should consider eagerly >>> initializing the StringConcatFactory base class during bootstrap >>> instead. >>> >>> Doing so will add a tiny bit of class loading overhead to bootstrap >>> (which of course will be amortized on first use of SCF) but still this >>> would also be a good opportunity to clean up a little. >>> >>> One straightforward means to do so is to move the CACHE, DUMPER and >>> CACHE_ENABLE fields to BytecodeStringBuilderStrategy, since it's the >>> only place where they are used (the MethodHandle based strategies don't >>> manually spin classes and rely on LF sharing to de-duplicate shared >>> components). >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8245024/open.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8245024 >>> >>> This reduces initialization overhead and simplifices bootstraps for the >>> default case, while still passing relevant test cases such as test/jdk >>> /java/lang/String/concat/WithSecurityManager.java for all strategies. >>> >>> Testing: tier1-2 >>> >>> Thanks! >>> >>> /Claes >> From jason_mehrens at hotmail.com Fri May 15 01:06:07 2020 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Fri, 15 May 2020 01:06:07 +0000 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: <7a9e679f-c697-9a59-2cf9-2eba76b215d3@oracle.com> References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> , <7a9e679f-c697-9a59-2cf9-2eba76b215d3@oracle.com> Message-ID: I think you have it covered. Thanks for the feedback it for sure helped me understand the approach. So on a lighthearted note I did figure out a way (tongue in cheek) to test if Collection::contains is expensive. You could even figure out if the membership semantics of each collection are the same without even creating new APIs. Anyway, don't take this example seriously and enjoy! @Deprecated public static boolean removeAllTester(Collection dis, Collection c) { Objects.requireNonNull(c); boolean modified = false; class Ref { int count; Ref() { } public boolean equals(Object o) { count++; return super.equals(o); } public int hashCode() { count++; return super.hashCode(); } } boolean expensiveContains; try { Ref test = new Ref(); c.contains(test); //Identity == zero and greater than 10 is a poor bin length //Obviously this fails if the collection::contains performs 'e.equals(o)' expensiveContains = test.count >= 10; } catch (RuntimeException usesCompare) { expensiveContains = false; } if (expensiveContains) { for (Object e : c) modified |= dis.remove(e); } else { for (Iterator i = dis.iterator(); i.hasNext(); ) { if (c.contains(i.next())) { i.remove(); modified = true; } } } return modified; } public static void main(String[] args) { int sourceSize = 300000; int removalsSize = 300000; Set source = new HashSet(); Collection removals = new ArrayList(); for (int i = 0; i < sourceSize; i++) source.add(i); for (int i = 1; i <= removalsSize; i++) removals.add(-i); long start = System.currentTimeMillis(); boolean modified; //modified = source.removeAll(removals); modified = removeAllTester(source, removals); //removals.forEach(e -> source.remove(e)); //source.removeIf(e -> removals.contains(e)); long end = System.currentTimeMillis(); System.out.println("Time taken: " + (end - start) + "ms " + modified); } Jason ________________________________________ From: Stuart Marks Sent: Tuesday, May 12, 2020 3:34 PM To: Jason Mehrens Cc: core-libs-dev Subject: Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes On 5/8/20 6:46 PM, Jason Mehrens wrote: > I assume Deque/Queue would suffer the same issue as List. It would be nice to some how ensure ArrayDeque.contains is not called as far as the heuristic goes. Looks like PriorityQueue uses equals for contains but that is not to say there are not other queue implementations in the wild that do something different. The difficulty here is how far to take the heuristic. The goal here is not to guarantee that behavior can never be O(M*N) but to catch what seem to be the most common cases. I think the most common case is where the argument is a List, but there are lots of possibilities that we'd inevitably miss. > The more I think about it in general, it seems like your task would be easier if you could declare: > 1. AbstractCollection.removeAll should assume this.contains is O(N) and iterate over this and check contains on arg. > 2. AbstractSet.removeAll should iterate over argument and assume that this.contains/remove is at least O(log (N)) and assume argument.contains is O(N). > 3. Concrete implementations of removeAll know the cost of their contains method. If it is known to be O(N) then walk this otherwise walk the arg. > 4. Include an example in removeAll that says if membership semantics differ between sets use: source.removeIf(e -> removals.contains(e)); or removals.forEach(e -> source.remove(e)); instead. If they don't differ then use removeAll. This sort of makes sense from a performance standpoint, but it doesn't address the semantic issues I raised in my reply the other day to Jens Lidestr?m. Specifically, we don't want Set.removeAll or AbstractSet.removeAll to disagree with Collection.removeAll and AbstractCollection.removeAll. We also want removeAll() to be the complement of retainAll(). > Given this has been around since JDK 1.3 would it be safe to assume that code that is mixing collections with different membership semantics is already working around this issue and therefore the risk is a bit lower in changing the spec? Lots of concrete implementations already override removeAll anyway. I'm not sure that's true. People keep running into either the performance problem or the semantic problem. Sometimes people live with bugs for a long time and can't figure it out. "Yeah, removeAll sometimes gives this weird result. I don't know why. Maybe I just don't understand Java." s'marks From gnu.andrew at redhat.com Fri May 15 05:53:49 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 15 May 2020 06:53:49 +0100 Subject: [8u] RFR: [JDK 8u] JapanEraNameCompatTest fails In-Reply-To: <12b4fdfab95f458c396b7e0b64770907adb19a1a.camel@redhat.com> References: <12b4fdfab95f458c396b7e0b64770907adb19a1a.camel@redhat.com> Message-ID: On 13/05/2020 20:26, Severin Gehwolf wrote: > Hi Andrew, > > Thanks for looking at this. > No problem. Thanks for taking it on. > On Wed, 2020-05-13 at 17:37 +0100, Andrew Hughes wrote: >> On 13/05/2020 15:59, Severin Gehwolf wrote: >>> Hi, >>> >>> Could somebody please review this fix for the failing >>> JapanEraNameCompatTest.java test (part of tier1)? The reason why it's >>> failing is that there are missing locale data for no and sr_Latn which >>> are exercised by the test. The original backport of JDK-8219781 didn't >>> include those as the changed sections in the JDK 11 patch didn't exist >>> in 8u. Those extra sections got introduced with JDK-8008577 or JDK- >>> 8145136. >> >> This also includes the JDK-8219781 changes for these locales. I think >> it's worth mentioning all three bug IDs in the summary text so they >> appear in a keyword search. > > OK, done. I was thinking more along the lines: Summary: Backports hr, lt, in, nl, no, sr_Latn & sv changes from 8008577, 8145136 & 8219781 Do we want this to appear as a backport bug of those issues? > >> Changes for these locales look ok to me. >> >>> This patch adds locale data for locales left out in the JDK-8219781 8u >>> backport, except for JavaTimeSupplementary_in.java. That file doesn't >>> exist at all in 8u, hence I've left that out. >> >> This doesn't make sense to me. The in locale is present in >> sun/text/resources, but the only one without JavaTimeSupplementary_*: > > Sorry for not being clear. I meant that there is no > JavaTimeSupplementary_in.java in 8u (prior this patch). Yeah, I got that. I just didn't understand why you didn't just add the file. snip... > > Sure. Done now: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244843/02/webrev/ > ... > > How does the updated webrev above look to you? > Only issue with the patch itself is java.time.japanese.short.Eras is missing the new Reiwa era. I guess this is because 11u has JDK-8159943, which refactors these files so they share blocks where possible, before JDK-8219781. Thus, there is only one block to change in 11u, but it's a shared block which is then used from both java.time.japanese.short.Eras & java.time.japanese.long.Eras Looking at JDK-8219781 again, it is huge, but I don't think it actually changes much of the existing locales, just refactors them and adds some missing ones. I'm pondering whether a backport is worthwhile to avoid the duplication issue in future (without the LocaleData.java code changes). I guess it depends how likely it is we'll see more changes to locale data. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From Alan.Bateman at oracle.com Fri May 15 07:00:49 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 15 May 2020 08:00:49 +0100 Subject: RFR JDK-8244961: MethodHandles::privateLookupIn throws NPE when called during initPhase2 In-Reply-To: References: Message-ID: <97f25ce5-bc9f-ca62-94d9-330cea356d5b@oracle.com> On 14/05/2020 21:12, Mandy Chung wrote: > MethodHandles::privateLookupIn should prepare for being called during > early startup when the module of java.base classes are not yet > assigned.? This bug is uncovered by panama prototype converting NIO to > use memory access API. > > The fix is very simple and move the call to Module::isNamed only if > the caller module and target module are different: > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8244961/webrev.00/ I think this is a bug I left in JDK 9, sorry about that. In general there should be very little code executed before the loaded classes are patched to in java.base. The exception is with exploded where a lot of library code gets executed when find the (exploded) module modules. The change looks good. -Alan From vipinmv1 at in.ibm.com Fri May 15 07:26:11 2020 From: vipinmv1 at in.ibm.com (Vipin Mv1) Date: Fri, 15 May 2020 07:26:11 +0000 Subject: RFR 6470126 java.util.jar.Attributes#containsKey fails with Strings In-Reply-To: References: Message-ID: Hi, Thanks for the review comments. I will work on the same and get back with the same soon. Thanks & Regards Vipin MV From nick.gasson at arm.com Fri May 15 07:36:58 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Fri, 15 May 2020 15:36:58 +0800 Subject: RFR(XS): 8244981: jpackage error due to missing final newline in Debian control file In-Reply-To: <075df90c-1044-f7df-6bdc-8481913dca57@oracle.com> References: <85pnb76ib8.fsf@arm.com> <075df90c-1044-f7df-6bdc-8481913dca57@oracle.com> Message-ID: <85eerl3azp.fsf@arm.com> On 05/15/20 03:39 am, Alexey Semenyuk wrote: > Looks good. > > - Alexey Thanks Alexey. Can I get another reviewer to look at it before pushing? Nick >> Hi, >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8244981 >> Webrev: http://cr.openjdk.java.net/~ngasson/8244981/webrev.0/ >> >> Several jpackage jtreg tests fail on Debian/Ubuntu with this error: >> >> Running [fakeroot, dpkg-deb, --verbose, -b, <..snip..>] >> dpkg-deb: error: parsing file '/tmp/<..snip..>/images/DEBIAN/control' near line 9 package 'appcategorytest': >> end of file during value of field 'Installed-Size' (missing final newline) >> >> dpkg-deb requires each field in the control file to be terminated with a >> newline. This patch adds a trailing newline to all resource files, but I >> think that shouldn't cause a problem. >> >> Tested with jdk/tools/jpackage jtreg tests. >> >> -- >> Thanks, >> Nick From sgehwolf at redhat.com Fri May 15 08:45:03 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 May 2020 10:45:03 +0200 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> <808419e3-316b-381d-f636-606aadff39b6@redhat.com> <15a2fa41f80935d8c7d3893aad7d080c1f67aa2a.camel@redhat.com> Message-ID: <74e4d10641c8b6acca8ada68459a767f98e23585.camel@redhat.com> Hi, On Wed, 2020-05-13 at 16:11 +0100, Andrew Hughes wrote: > On 12/05/2020 15:14, Severin Gehwolf wrote: > > Hi Andrew, > > > > Thanks for looking at this. > > > > On Tue, 2020-05-12 at 14:07 +0100, Andrew Haley wrote: > > > On 5/7/20 4:09 PM, Severin Gehwolf wrote: > > > > jvm_version_info.jvm_version currently holds this quadruplet: > > > > > > > > Most significant 8 bits => major version, followed by 8 bits => minor > > > > version, followed by 8 bits => micro version, followed by 8 bits => > > > > build version. Note that JVM minor version represents the update > > > > version as passed in via configure and the micro version is currently > > > > not used (always 0). See vm_version.cpp lines 100-102 where only major, > > > > minor and build number are ever been set. Knowing this, we can still > > > > preserve the same behavior after patch by defining JVM_VERSION_MICRO to > > > > 0 for any version. > > > > > > This is tricky. JVM_GetVersionInfo is a function exported by > > > libjvm.so, and the version is simply encoded as > > > > > > unsigned int Abstract_VM_Version::jvm_version() { > > > return ((Abstract_VM_Version::vm_major_version() & 0xFF) << 24) | > > > ((Abstract_VM_Version::vm_minor_version() & 0xFF) << 16) | > > > (Abstract_VM_Version::vm_build_number() & 0xFF); > > > } > > > > > > I guess we could argue that this is for JVM-JDK internal use only, and > > > no-one else cares. > > > > > > Or we could encode it in a different way such that at least we have a > > > jvm_version that is monotonically increasing, perhaps by (ab)using the > > > lower 8 bits of the version, the vm_build_number. But I guess I'm > > > being paranoid, and no tools are going to care about minor versions > > > anyway,even if they do call JVM_GetVersionInfo. > > > > Yes, this is indeed tricky. The trouble is that > > Abstract_VM_Version::vm_build_number() actually holds the configured > > JDK build number, we can't really use it. It's already being used. > > > > (gdb) > > 99 > > 100 _vm_major_version = atoi(vm_major_ver); > > 101 _vm_minor_version = atoi(vm_minor_ver); > > 102 _vm_build_number = atoi(vm_build_num); > > 103 > > 104 os::free(vm_version); > > 105 _initialized = true; > > 106 } > > 107 > > 108 #if defined(_LP64) > > (gdb) p _vm_build_number > > $1 = 2 > > > > The only bits which seem unused are bits 8 through 16 of this unsigned > > int. So even if JVM_GetVersionInfo *is* being used somewhere in the > > wild, it *should* continue to work. Hence, the proposal to now also use > > those unused bits for the minor version. > > > > Thoughts? > > > > Thanks, > > Severin > > > > The April release of OpenJDK 7u has the values: > > Major version: 24, minor version: 5, micro version: 0, build number: 2 > > when it should be 24.261-b02. So we already have a situation that could > be potentially be misinterpreted as an old JDK version, 7u5 b02, using > the current interpretation of the structure. 8u will see similar issues > if we make no change in this cycle. Yes. I believe we need to get this fixed. The earlier in the 262 update cycle the better. > As the micro version appears to have always been zero, it seems pretty > safe to just hard-code this value and instead use all 16 bits of the > interpreted value for the micro version. In terms of backwards > compatibility, if a micro version greater than zero is read using the > old method, this will be an indicator that it needs to be > re-interpreted as a 16-bit value. As Andrew Hughes mentioned below, the only way to see the difference post-patch would be for somebody to use old jvm.h defines *and* use a supposedly a JDK private API (JVM_GetVersionInfo). It is an exported symbol, but as Andrew Hughes pointed out, for JDK <=> hotspot communication. On the other hand, the chance of somebody using forbidden (access restricted), yet available API via sun.misc.Version is more likely. Of which the following are broken (see my latest comment on the bug[1]): sun.misc.Version.jvmMinorVersion() sun.misc.Version.jdkUpdateVersion() Post patch the above are fixed, but somebody using JVM_GetVersionInfo directly with old jvm.h macros would get for 8u262-b03 (pseudo code): #define JVM_VERSION_MAJOR(version) ((version & 0xFF000000) >> 24) #define JVM_VERSION_MINOR(version) ((version & 0x00FF0000) >> 16) #define JVM_VERSION_MICRO(version) ((version & 0x0000FF00) >> 8) #define JVM_VERSION_BUILD(version) ((version & 0x000000FF)) jvm_version_info info; [ call JVM_GetVersionInfo, etc. ] JVM_VERSION_MAJOR(info.jvm_version) // => 25 JVM_VERSION_MINOR(info.jvm_version) // => 1 JVM_VERSION_MICRO(info.jvm_version) // => 6 JVM_VERSION_BUILD(info.jvm_version) // => 3 So, minor, micro would be wrong. Question is what's more likely in use today in the wild? JVM_GetVersionInfo or sun.misc.Version. > The current value for 7 is 402980866 > (0001 1000 0000 0101 0000 0000 0000 0010) > which thus gets interpreted as above. > > The new method encodes the same version numbers as 402720002 > (0001 1000 0000 0001 0000 0101 0000 0010) > > which can be read back as major 24, minor 261, micro 0 and build 2 using > the updated decoding. > > If the old decoding is used, we get major 24, minor 1, micro 5 and build > 2. As micro is usually set to zero, updated code should be able to use > this to instead use the new interpretation, while, in the worst case, > stale code will get a unique, if incorrect, version. Yes. So, Andrew Haley, what's the verdict on this one? There is a risk, yes. Not fixing the bug seems riskier, though. Thoughts? Thanks, Severin [1] https://bugs.openjdk.java.net/browse/JDK-8244548?focusedCommentId=14338519&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14338519 From sgehwolf at redhat.com Fri May 15 09:22:59 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 May 2020 11:22:59 +0200 Subject: [8u] RFR: 8244843: [JDK 8u] JapanEraNameCompatTest fails In-Reply-To: References: <12b4fdfab95f458c396b7e0b64770907adb19a1a.camel@redhat.com> Message-ID: <3037e70f07846eda25fdf67e3b022e4ce30fb458.camel@redhat.com> Hi Andrew, Sigh, I only now realized that the bug number was missing the subject. Fixed now. On Fri, 2020-05-15 at 06:53 +0100, Andrew Hughes wrote: > On 13/05/2020 20:26, Severin Gehwolf wrote: > > Hi Andrew, > > > > Thanks for looking at this. > > > > No problem. Thanks for taking it on. > > > On Wed, 2020-05-13 at 17:37 +0100, Andrew Hughes wrote: > > > On 13/05/2020 15:59, Severin Gehwolf wrote: > > > > Hi, > > > > > > > > Could somebody please review this fix for the failing > > > > JapanEraNameCompatTest.java test (part of tier1)? The reason why it's > > > > failing is that there are missing locale data for no and sr_Latn which > > > > are exercised by the test. The original backport of JDK-8219781 didn't > > > > include those as the changed sections in the JDK 11 patch didn't exist > > > > in 8u. Those extra sections got introduced with JDK-8008577 or JDK- > > > > 8145136. > > > > > > This also includes the JDK-8219781 changes for these locales. I think > > > it's worth mentioning all three bug IDs in the summary text so they > > > appear in a keyword search. > > > > OK, done. > > I was thinking more along the lines: > > Summary: Backports hr, lt, in, nl, no, sr_Latn & sv changes from > 8008577, 8145136 & 8219781 Sure. Changed that. > Do we want this to appear as a backport bug of those issues? > > > > Changes for these locales look ok to me. > > > > > > > This patch adds locale data for locales left out in the JDK-8219781 8u > > > > backport, except for JavaTimeSupplementary_in.java. That file doesn't > > > > exist at all in 8u, hence I've left that out. > > > > > > This doesn't make sense to me. The in locale is present in > > > sun/text/resources, but the only one without JavaTimeSupplementary_*: > > > > Sorry for not being clear. I meant that there is no > > JavaTimeSupplementary_in.java in 8u (prior this patch). > > Yeah, I got that. I just didn't understand why you didn't just add the file. > > snip... > > > Sure. Done now: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244843/02/webrev/ > > > ... > > How does the updated webrev above look to you? > > > > Only issue with the patch itself is java.time.japanese.short.Eras is > missing the new Reiwa era. I guess this is because 11u has JDK-8159943, > which refactors these files so they share blocks where possible, before > JDK-8219781. Thus, there is only one block to change in 11u, but it's a > shared block which is then used from both java.time.japanese.short.Eras > & java.time.japanese.long.Eras Should be fixed in 03 here. Thanks for the catch: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244843/03/webrev/ Thoughts? Thanks, Severin From claes.redestad at oracle.com Fri May 15 10:54:36 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 15 May 2020 12:54:36 +0200 Subject: RFR: 8245094: Reduce overhead of initializing the default StringConcatFactory strategy Message-ID: Hi, by adding a bridge method in JavaLangAcces to call into the StringConcatHelper.initialCoder - which is done only once during initialization - we can reduce bootstrap overhead of SCF by a few million instructions - ~0.5ms on wall clock measures. Webrev: http://cr.openjdk.java.net/~redestad/8245094/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8245094 Testing: tier1 Thanks! /Claes From andy.herrick at oracle.com Fri May 15 11:43:16 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 15 May 2020 07:43:16 -0400 Subject: RFR(XS): 8244981: jpackage error due to missing final newline in Debian control file In-Reply-To: <85eerl3azp.fsf@arm.com> References: <85pnb76ib8.fsf@arm.com> <075df90c-1044-f7df-6bdc-8481913dca57@oracle.com> <85eerl3azp.fsf@arm.com> Message-ID: Yes - sorry - thought I had replied. looks good. /Andy On 5/15/2020 3:36 AM, Nick Gasson wrote: > On 05/15/20 03:39 am, Alexey Semenyuk wrote: >> Looks good. >> >> - Alexey > Thanks Alexey. Can I get another reviewer to look at it before pushing? > > > Nick > >>> Hi, >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8244981 >>> Webrev: http://cr.openjdk.java.net/~ngasson/8244981/webrev.0/ >>> >>> Several jpackage jtreg tests fail on Debian/Ubuntu with this error: >>> >>> Running [fakeroot, dpkg-deb, --verbose, -b, <..snip..>] >>> dpkg-deb: error: parsing file '/tmp/<..snip..>/images/DEBIAN/control' near line 9 package 'appcategorytest': >>> end of file during value of field 'Installed-Size' (missing final newline) >>> >>> dpkg-deb requires each field in the control file to be terminated with a >>> newline. This patch adds a trailing newline to all resource files, but I >>> think that shouldn't cause a problem. >>> >>> Tested with jdk/tools/jpackage jtreg tests. >>> >>> -- >>> Thanks, >>> Nick From james.laskey at oracle.com Fri May 15 11:53:31 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Fri, 15 May 2020 08:53:31 -0300 Subject: RFR: 8245094: Reduce overhead of initializing the default StringConcatFactory strategy In-Reply-To: References: Message-ID: <11763D14-25A4-4415-922F-EC4E064C0F47@oracle.com> +1 > On May 15, 2020, at 7:54 AM, Claes Redestad wrote: > > Hi, > > by adding a bridge method in JavaLangAcces to call into the > StringConcatHelper.initialCoder - which is done only once during > initialization - we can reduce bootstrap overhead of SCF by a few > million instructions - ~0.5ms on wall clock measures. > > Webrev: http://cr.openjdk.java.net/~redestad/8245094/open.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8245094 > > Testing: tier1 > > Thanks! > > /Claes From pavel.rappo at oracle.com Fri May 15 12:35:29 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 15 May 2020 13:35:29 +0100 Subject: RFR [15] 8245111: Update doc comments for improved processing by the Standard Doclet Message-ID: <2CDB5F27-0767-4393-B8AA-F4917A1ED060@oracle.com> Hello, Please review this trivial change for https://bugs.openjdk.java.net/browse/JDK-8245111: http://cr.openjdk.java.net/~prappo/8245111/webrev.00/ In addition to fixing the main issue, this includes a blanket change from "followed with" to "followed by" as the latter seemed idiomatic to me. -Pavel From aph at redhat.com Fri May 15 13:29:26 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 15 May 2020 14:29:26 +0100 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: <74e4d10641c8b6acca8ada68459a767f98e23585.camel@redhat.com> References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> <808419e3-316b-381d-f636-606aadff39b6@redhat.com> <15a2fa41f80935d8c7d3893aad7d080c1f67aa2a.camel@redhat.com> <74e4d10641c8b6acca8ada68459a767f98e23585.camel@redhat.com> Message-ID: On 5/15/20 9:45 AM, Severin Gehwolf wrote: > So, Andrew Haley, what's the verdict on this one? There is a risk, yes. > Not fixing the bug seems riskier, though. Thoughts? Thanks for the detailed explanation. I think we have to keep sun.misc.Version working correctly but sacrifice binary consistency in JVM_GetVersionInfo. As long as stuff such as AOT compilation and class data sharing keep working I think we're OK. It's not great, but it's an almost-inevitable consequence of using a one-byte field for the minor version and bumping releases by 10. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From daniel.fuchs at oracle.com Fri May 15 14:00:00 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 15 May 2020 15:00:00 +0100 Subject: RFR [15] 8245111: Update doc comments for improved processing by the Standard Doclet In-Reply-To: <2CDB5F27-0767-4393-B8AA-F4917A1ED060@oracle.com> References: <2CDB5F27-0767-4393-B8AA-F4917A1ED060@oracle.com> Message-ID: Hi Pavel, This looks good to me - but English is not my native language ;-) cheers, -- daniel On 15/05/2020 13:35, Pavel Rappo wrote: > Hello, > > Please review this trivial change for https://bugs.openjdk.java.net/browse/JDK-8245111: > > http://cr.openjdk.java.net/~prappo/8245111/webrev.00/ > > In addition to fixing the main issue, this includes a blanket change from "followed with" to "followed by" as the latter seemed idiomatic to me. > > -Pavel > From sgehwolf at redhat.com Fri May 15 14:24:18 2020 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 May 2020 16:24:18 +0200 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> <808419e3-316b-381d-f636-606aadff39b6@redhat.com> <15a2fa41f80935d8c7d3893aad7d080c1f67aa2a.camel@redhat.com> <74e4d10641c8b6acca8ada68459a767f98e23585.camel@redhat.com> Message-ID: <6e023f46cec38601e6cd15356f971ab5d6cd99e2.camel@redhat.com> On Fri, 2020-05-15 at 14:29 +0100, Andrew Haley wrote: > On 5/15/20 9:45 AM, Severin Gehwolf wrote: > > So, Andrew Haley, what's the verdict on this one? There is a risk, yes. > > Not fixing the bug seems riskier, though. Thoughts? > > Thanks for the detailed explanation. > > I think we have to keep sun.misc.Version working correctly but > sacrifice binary consistency in JVM_GetVersionInfo. As long as stuff > such as AOT compilation and class data sharing keep working I think > we're OK. It's not great, but it's an almost-inevitable consequence of > using a one-byte field for the minor version and bumping releases by > 10. Agreed. Thanks for the review. I've requested 8u approval for this bug. Cheers, Severin From huizhe.wang at oracle.com Fri May 15 15:46:25 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 15 May 2020 08:46:25 -0700 Subject: RFR [15] 8245111: Update doc comments for improved processing by the Standard Doclet In-Reply-To: References: <2CDB5F27-0767-4393-B8AA-F4917A1ED060@oracle.com> Message-ID: +1 Cheers, Joe On 5/15/2020 7:00 AM, Daniel Fuchs wrote: > Hi Pavel, > > This looks good to me - but English is not my native language ;-) > > cheers, > > -- daniel > > On 15/05/2020 13:35, Pavel Rappo wrote: >> Hello, >> >> Please review this trivial change for >> https://bugs.openjdk.java.net/browse/JDK-8245111: >> >> ?? http://cr.openjdk.java.net/~prappo/8245111/webrev.00/ >> >> In addition to fixing the main issue, this includes a blanket change >> from "followed with" to "followed by" as the latter seemed idiomatic >> to me. >> >> -Pavel >> > From Roger.Riggs at oracle.com Fri May 15 15:53:11 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 15 May 2020 11:53:11 -0400 Subject: RFR [15] 8245111: Update doc comments for improved processing by the Standard Doclet In-Reply-To: References: <2CDB5F27-0767-4393-B8AA-F4917A1ED060@oracle.com> Message-ID: <0762a9b9-ce83-7a44-e7f4-57388d3f60b0@oracle.com> Hi Pavel, No problem with the "with" -> "by" changes. javax/naming/NameNotFoundException.java: 55 ? "initialized" -> "are initialized" java/util/jar/Attributes.java:594 ? The period was in the correct place. ? The second sentence is a separate comment about the use (non-use). ?"used for the extension mechanism that is no longer supported." Would read better as: "This name is obsolete, the extension mechanism is no longer supported." $.02, Roger On 5/15/20 10:00 AM, Daniel Fuchs wrote: > Hi Pavel, > > This looks good to me - but English is not my native language ;-) > > cheers, > > -- daniel > > On 15/05/2020 13:35, Pavel Rappo wrote: >> Hello, >> >> Please review this trivial change for >> https://bugs.openjdk.java.net/browse/JDK-8245111: >> >> ?? http://cr.openjdk.java.net/~prappo/8245111/webrev.00/ >> >> In addition to fixing the main issue, this includes a blanket change >> from "followed with" to "followed by" as the latter seemed idiomatic >> to me. >> >> -Pavel >> > From andy.herrick at oracle.com Fri May 15 15:55:44 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 15 May 2020 11:55:44 -0400 Subject: RFR: JDK-823797: ,Package type for runtime image on macosx Message-ID: <9ec5b3b7-c424-058f-e55b-ee809a1b5ce6@oracle.com> Please review fix for issue [1] at [2]. The change enables packaging runtime images as a dmg on MacOS. [1] - https://bugs.openjdk.java.net/browse/JDK-8237971 [2] - http://cr.openjdk.java.net/~herrick/8237971/webrev.01/ /Andy From claes.redestad at oracle.com Fri May 15 15:57:14 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 15 May 2020 17:57:14 +0200 Subject: RFR: 8245094: Reduce overhead of initializing the default StringConcatFactory strategy In-Reply-To: <11763D14-25A4-4415-922F-EC4E064C0F47@oracle.com> References: <11763D14-25A4-4415-922F-EC4E064C0F47@oracle.com> Message-ID: <641cff1f-e851-d5b9-337c-21fef0f3a7cf@oracle.com> On 2020-05-15 13:53, Jim Laskey wrote: > +1 Thanks, Jim! /Claes > > >> On May 15, 2020, at 7:54 AM, Claes Redestad wrote: >> >> Hi, >> >> by adding a bridge method in JavaLangAcces to call into the >> StringConcatHelper.initialCoder - which is done only once during >> initialization - we can reduce bootstrap overhead of SCF by a few >> million instructions - ~0.5ms on wall clock measures. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8245094/open.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8245094 >> >> Testing: tier1 >> >> Thanks! >> >> /Claes > From pavel.rappo at oracle.com Fri May 15 15:59:37 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 15 May 2020 16:59:37 +0100 Subject: RFR [15] 8245111: Update doc comments for improved processing by the Standard Doclet In-Reply-To: <0762a9b9-ce83-7a44-e7f4-57388d3f60b0@oracle.com> References: <2CDB5F27-0767-4393-B8AA-F4917A1ED060@oracle.com> <0762a9b9-ce83-7a44-e7f4-57388d3f60b0@oracle.com> Message-ID: <4D032107-4C3B-4617-B36A-161749ED6AD9@oracle.com> > On 15 May 2020, at 16:53, Roger Riggs wrote: > > Hi Pavel, > > No problem with the "with" -> "by" changes. > > javax/naming/NameNotFoundException.java: 55 > "initialized" -> "are initialized" > > java/util/jar/Attributes.java:594 > The period was in the correct place. > The second sentence is a separate comment about the use (non-use). I considered that initially, but then saw how it was used on the adjacent field: /** * {@code Name} object for {@code Extension-List} manifest attribute * used for the extension mechanism that is no longer supported. */ public static final Name EXTENSION_LIST; Would you suggest making a similar fix here? > "used for the extension mechanism that is no longer supported." > > Would read better as: > "This name is obsolete, the extension mechanism is no longer supported." > > $.02, Roger > > > On 5/15/20 10:00 AM, Daniel Fuchs wrote: >> Hi Pavel, >> >> This looks good to me - but English is not my native language ;-) >> >> cheers, >> >> -- daniel >> >> On 15/05/2020 13:35, Pavel Rappo wrote: >>> Hello, >>> >>> Please review this trivial change for https://bugs.openjdk.java.net/browse/JDK-8245111: >>> >>> http://cr.openjdk.java.net/~prappo/8245111/webrev.00/ >>> >>> In addition to fixing the main issue, this includes a blanket change from "followed with" to "followed by" as the latter seemed idiomatic to me. >>> >>> -Pavel >>> >> > From paul.sandoz at oracle.com Fri May 15 16:00:42 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 15 May 2020 09:00:42 -0700 Subject: RFR: 8245094: Reduce overhead of initializing the default StringConcatFactory strategy In-Reply-To: References: Message-ID: <0F321953-5413-47EF-8D7C-7BDB91365606@oracle.com> +1 Paul. > On May 15, 2020, at 3:54 AM, Claes Redestad wrote: > > Hi, > > by adding a bridge method in JavaLangAcces to call into the > StringConcatHelper.initialCoder - which is done only once during > initialization - we can reduce bootstrap overhead of SCF by a few > million instructions - ~0.5ms on wall clock measures. > > Webrev: http://cr.openjdk.java.net/~redestad/8245094/open.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8245094 > > Testing: tier1 > > Thanks! > > /Claes From paul.sandoz at oracle.com Fri May 15 16:03:57 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 15 May 2020 09:03:57 -0700 Subject: RFR JDK-8244961: MethodHandles::privateLookupIn throws NPE when called during initPhase2 In-Reply-To: References: Message-ID: <23E8825E-47D2-4AA8-821B-4E3BC83474F4@oracle.com> +1 Paul. > On May 14, 2020, at 1:12 PM, Mandy Chung wrote: > > MethodHandles::privateLookupIn should prepare for being called during early startup when the module of java.base classes are not yet assigned. This bug is uncovered by panama prototype converting NIO to use memory access API. > > The fix is very simple and move the call to Module::isNamed only if the caller module and target module are different: > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8244961/webrev.00/ > > Mandy From claes.redestad at oracle.com Fri May 15 16:08:52 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 15 May 2020 18:08:52 +0200 Subject: RFR: 8245094: Reduce overhead of initializing the default StringConcatFactory strategy In-Reply-To: <0F321953-5413-47EF-8D7C-7BDB91365606@oracle.com> References: <0F321953-5413-47EF-8D7C-7BDB91365606@oracle.com> Message-ID: <9828b655-5984-adf2-c2e2-4f5a2531e2ce@oracle.com> Thanks, Paul! /Claes On 2020-05-15 18:00, Paul Sandoz wrote: > +1 > > Paul. > >> On May 15, 2020, at 3:54 AM, Claes Redestad wrote: >> >> Hi, >> >> by adding a bridge method in JavaLangAcces to call into the >> StringConcatHelper.initialCoder - which is done only once during >> initialization - we can reduce bootstrap overhead of SCF by a few >> million instructions - ~0.5ms on wall clock measures. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8245094/open.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8245094 >> >> Testing: tier1 >> >> Thanks! >> >> /Claes > From Roger.Riggs at oracle.com Fri May 15 16:34:20 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 15 May 2020 12:34:20 -0400 Subject: RFR [15] 8245111: Update doc comments for improved processing by the Standard Doclet In-Reply-To: <4D032107-4C3B-4617-B36A-161749ED6AD9@oracle.com> References: <2CDB5F27-0767-4393-B8AA-F4917A1ED060@oracle.com> <0762a9b9-ce83-7a44-e7f4-57388d3f60b0@oracle.com> <4D032107-4C3B-4617-B36A-161749ED6AD9@oracle.com> Message-ID: Hi Pavel, Yes, I think that would be an improvement. But its a slippery slope beyond what you originally observed and wanted to fix. Thanks, Roger On 5/15/20 11:59 AM, Pavel Rappo wrote: >> On 15 May 2020, at 16:53, Roger Riggs wrote: >> >> Hi Pavel, >> >> No problem with the "with" -> "by" changes. >> >> javax/naming/NameNotFoundException.java: 55 >> "initialized" -> "are initialized" >> >> java/util/jar/Attributes.java:594 >> The period was in the correct place. >> The second sentence is a separate comment about the use (non-use). > I considered that initially, but then saw how it was used on the adjacent field: > > /** > * {@code Name} object for {@code Extension-List} manifest attribute > * used for the extension mechanism that is no longer supported. > */ > public static final Name EXTENSION_LIST; > > Would you suggest making a similar fix here? > >> "used for the extension mechanism that is no longer supported." >> >> Would read better as: >> "This name is obsolete, the extension mechanism is no longer supported." >> >> $.02, Roger >> >> >> On 5/15/20 10:00 AM, Daniel Fuchs wrote: >>> Hi Pavel, >>> >>> This looks good to me - but English is not my native language ;-) >>> >>> cheers, >>> >>> -- daniel >>> >>> On 15/05/2020 13:35, Pavel Rappo wrote: >>>> Hello, >>>> >>>> Please review this trivial change for https://bugs.openjdk.java.net/browse/JDK-8245111: >>>> >>>> http://cr.openjdk.java.net/~prappo/8245111/webrev.00/ >>>> >>>> In addition to fixing the main issue, this includes a blanket change from "followed with" to "followed by" as the latter seemed idiomatic to me. >>>> >>>> -Pavel >>>> From pavel.rappo at oracle.com Fri May 15 16:47:41 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 15 May 2020 17:47:41 +0100 Subject: RFR [15] 8245111: Update doc comments for improved processing by the Standard Doclet In-Reply-To: References: <2CDB5F27-0767-4393-B8AA-F4917A1ED060@oracle.com> <0762a9b9-ce83-7a44-e7f4-57388d3f60b0@oracle.com> <4D032107-4C3B-4617-B36A-161749ED6AD9@oracle.com> Message-ID: Roger, I think I will not do that even though it might be an improvement. If you look closely, the "attribute used for" pattern carpet-bombs that file. I guess if we are making this change you suggest, this should be done in a separate changeset. You are absolutely right saying that it's a slippery slope. So, unless you have arguments that outweigh the argument of consistency, I'd shelve your suggestion until better time. Thanks for your review! -Pavel > On 15 May 2020, at 17:34, Roger Riggs wrote: > > Hi Pavel, > > Yes, I think that would be an improvement. > But its a slippery slope beyond what you originally observed and wanted to fix. > > Thanks, Roger > > > On 5/15/20 11:59 AM, Pavel Rappo wrote: >>> On 15 May 2020, at 16:53, Roger Riggs wrote: >>> >>> Hi Pavel, >>> >>> No problem with the "with" -> "by" changes. >>> >>> javax/naming/NameNotFoundException.java: 55 >>> "initialized" -> "are initialized" >>> >>> java/util/jar/Attributes.java:594 >>> The period was in the correct place. >>> The second sentence is a separate comment about the use (non-use). >> I considered that initially, but then saw how it was used on the adjacent field: >> >> /** >> * {@code Name} object for {@code Extension-List} manifest attribute >> * used for the extension mechanism that is no longer supported. >> */ >> public static final Name EXTENSION_LIST; >> >> Would you suggest making a similar fix here? >> >>> "used for the extension mechanism that is no longer supported." >>> >>> Would read better as: >>> "This name is obsolete, the extension mechanism is no longer supported." >>> >>> $.02, Roger >>> >>> >>> On 5/15/20 10:00 AM, Daniel Fuchs wrote: >>>> Hi Pavel, >>>> >>>> This looks good to me - but English is not my native language ;-) >>>> >>>> cheers, >>>> >>>> -- daniel >>>> >>>> On 15/05/2020 13:35, Pavel Rappo wrote: >>>>> Hello, >>>>> >>>>> Please review this trivial change for https://bugs.openjdk.java.net/browse/JDK-8245111: >>>>> >>>>> http://cr.openjdk.java.net/~prappo/8245111/webrev.00/ >>>>> >>>>> In addition to fixing the main issue, this includes a blanket change from "followed with" to "followed by" as the latter seemed idiomatic to me. >>>>> >>>>> -Pavel >>>>> > From Roger.Riggs at oracle.com Fri May 15 17:05:18 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 15 May 2020 13:05:18 -0400 Subject: RFR [15] 8245111: Update doc comments for improved processing by the Standard Doclet In-Reply-To: References: <2CDB5F27-0767-4393-B8AA-F4917A1ED060@oracle.com> <0762a9b9-ce83-7a44-e7f4-57388d3f60b0@oracle.com> <4D032107-4C3B-4617-B36A-161749ED6AD9@oracle.com> Message-ID: <6e8c1ce3-b26e-b9f5-13fc-83fdc3abde56@oracle.com> Hi Pavel, +1 No problem, local consistency is more important. Roger On 5/15/20 12:47 PM, Pavel Rappo wrote: > Roger, I think I will not do that even though it might be an improvement. > > If you look closely, the "attribute used for" pattern carpet-bombs that file. I guess if we are making this change you suggest, this should be done in a separate changeset. You are absolutely right saying that it's a slippery slope. So, unless you have arguments that outweigh the argument of consistency, I'd shelve your suggestion until better time. > > Thanks for your review! > > -Pavel > >> On 15 May 2020, at 17:34, Roger Riggs wrote: >> >> Hi Pavel, >> >> Yes, I think that would be an improvement. >> But its a slippery slope beyond what you originally observed and wanted to fix. >> >> Thanks, Roger >> >> >> On 5/15/20 11:59 AM, Pavel Rappo wrote: >>>> On 15 May 2020, at 16:53, Roger Riggs wrote: >>>> >>>> Hi Pavel, >>>> >>>> No problem with the "with" -> "by" changes. >>>> >>>> javax/naming/NameNotFoundException.java: 55 >>>> "initialized" -> "are initialized" >>>> >>>> java/util/jar/Attributes.java:594 >>>> The period was in the correct place. >>>> The second sentence is a separate comment about the use (non-use). >>> I considered that initially, but then saw how it was used on the adjacent field: >>> >>> /** >>> * {@code Name} object for {@code Extension-List} manifest attribute >>> * used for the extension mechanism that is no longer supported. >>> */ >>> public static final Name EXTENSION_LIST; >>> >>> Would you suggest making a similar fix here? >>> >>>> "used for the extension mechanism that is no longer supported." >>>> >>>> Would read better as: >>>> "This name is obsolete, the extension mechanism is no longer supported." >>>> >>>> $.02, Roger >>>> >>>> >>>> On 5/15/20 10:00 AM, Daniel Fuchs wrote: >>>>> Hi Pavel, >>>>> >>>>> This looks good to me - but English is not my native language ;-) >>>>> >>>>> cheers, >>>>> >>>>> -- daniel >>>>> >>>>> On 15/05/2020 13:35, Pavel Rappo wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this trivial change for https://bugs.openjdk.java.net/browse/JDK-8245111: >>>>>> >>>>>> http://cr.openjdk.java.net/~prappo/8245111/webrev.00/ >>>>>> >>>>>> In addition to fixing the main issue, this includes a blanket change from "followed with" to "followed by" as the latter seemed idiomatic to me. >>>>>> >>>>>> -Pavel >>>>>> From lance.andersen at oracle.com Fri May 15 17:11:09 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 15 May 2020 13:11:09 -0400 Subject: RFR [15] 8245111: Update doc comments for improved processing by the Standard Doclet In-Reply-To: References: <2CDB5F27-0767-4393-B8AA-F4917A1ED060@oracle.com> <0762a9b9-ce83-7a44-e7f4-57388d3f60b0@oracle.com> <4D032107-4C3B-4617-B36A-161749ED6AD9@oracle.com> Message-ID: Hi Pavel > On May 15, 2020, at 12:34 PM, Roger Riggs wrote: > > Hi Pavel, > > Yes, I think that would be an improvement. > But its a slippery slope beyond what you originally observed and wanted to fix. I understand why you want to fix this. When you look at the rest of the field descriptions, that will now show as the only field without a period in the description. Not sure what the best answer is. The rest is fine, this is the only puzzler :-) Best Lance > > Thanks, Roger > > > On 5/15/20 11:59 AM, Pavel Rappo wrote: >>> On 15 May 2020, at 16:53, Roger Riggs wrote: >>> >>> Hi Pavel, >>> >>> No problem with the "with" -> "by" changes. >>> >>> javax/naming/NameNotFoundException.java: 55 >>> "initialized" -> "are initialized" >>> >>> java/util/jar/Attributes.java:594 >>> The period was in the correct place. >>> The second sentence is a separate comment about the use (non-use). >> I considered that initially, but then saw how it was used on the adjacent field: >> >> /** >> * {@code Name} object for {@code Extension-List} manifest attribute >> * used for the extension mechanism that is no longer supported. >> */ >> public static final Name EXTENSION_LIST; >> >> Would you suggest making a similar fix here? >> >>> "used for the extension mechanism that is no longer supported." >>> >>> Would read better as: >>> "This name is obsolete, the extension mechanism is no longer supported." >>> >>> $.02, Roger >>> >>> >>> On 5/15/20 10:00 AM, Daniel Fuchs wrote: >>>> Hi Pavel, >>>> >>>> This looks good to me - but English is not my native language ;-) >>>> >>>> cheers, >>>> >>>> -- daniel >>>> >>>> On 15/05/2020 13:35, Pavel Rappo wrote: >>>>> Hello, >>>>> >>>>> Please review this trivial change for https://bugs.openjdk.java.net/browse/JDK-8245111: >>>>> >>>>> http://cr.openjdk.java.net/~prappo/8245111/webrev.00/ >>>>> >>>>> In addition to fixing the main issue, this includes a blanket change from "followed with" to "followed by" as the latter seemed idiomatic to me. >>>>> >>>>> -Pavel >>>>> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Fri May 15 17:54:29 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 15 May 2020 10:54:29 -0700 Subject: RFR [15] 8244342: Compilation warnings about unexpected serialization related method signatures. Message-ID: <1e7b9a0a-869e-acb0-5d70-062da677611f@oracle.com> Hi, Please review a fix for the compilation warnings. Thanks Roger for the detailed instructions! If you could verify the fix with the work-in-progress processor, that would be great too. Regular build and test passed. https://bugs.openjdk.java.net/browse/JDK-8244342 http://cr.openjdk.java.net/~joehw/jdk15/8244342/webrev/ Thanks, Joe From lance.andersen at oracle.com Fri May 15 18:35:56 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 15 May 2020 14:35:56 -0400 Subject: RFR [15] 8244342: Compilation warnings about unexpected serialization related method signatures. In-Reply-To: <1e7b9a0a-869e-acb0-5d70-062da677611f@oracle.com> References: <1e7b9a0a-869e-acb0-5d70-062da677611f@oracle.com> Message-ID: Looks ok joe > On May 15, 2020, at 1:54 PM, Joe Wang wrote: > > Hi, > > Please review a fix for the compilation warnings. Thanks Roger for the detailed instructions! If you could verify the fix with the work-in-progress processor, that would be great too. Regular build and test passed. > > https://bugs.openjdk.java.net/browse/JDK-8244342 > http://cr.openjdk.java.net/~joehw/jdk15/8244342/webrev/ > > Thanks, > Joe Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From naoto.sato at oracle.com Fri May 15 18:39:12 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 15 May 2020 11:39:12 -0700 Subject: RFR [15] 8244342: Compilation warnings about unexpected serialization related method signatures. In-Reply-To: References: <1e7b9a0a-869e-acb0-5d70-062da677611f@oracle.com> Message-ID: <5ebd7cad-8e56-b747-1b66-55b0c1b5276b@oracle.com> +1 Naoto On 5/15/20 11:35 AM, Lance Andersen wrote: > Looks ok joe > >> On May 15, 2020, at 1:54 PM, Joe Wang wrote: >> >> Hi, >> >> Please review a fix for the compilation warnings. Thanks Roger for the detailed instructions! If you could verify the fix with the work-in-progress processor, that would be great too. Regular build and test passed. >> >> https://bugs.openjdk.java.net/browse/JDK-8244342 >> http://cr.openjdk.java.net/~joehw/jdk15/8244342/webrev/ >> >> Thanks, >> Joe > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From alexey.semenyuk at oracle.com Fri May 15 19:11:17 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 15 May 2020 15:11:17 -0400 Subject: RFR: JDK-823797: ,Package type for runtime image on macosx In-Reply-To: <9ec5b3b7-c424-058f-e55b-ee809a1b5ce6@oracle.com> References: <9ec5b3b7-c424-058f-e55b-ee809a1b5ce6@oracle.com> Message-ID: <6d5d9535-e0d0-4932-ddae-009f55253816@oracle.com> Looks good. - Alexey On 5/15/2020 11:55 AM, Andy Herrick wrote: > Please review fix for issue [1] at [2]. > > The change enables packaging runtime images as a dmg on MacOS. > > [1] - https://bugs.openjdk.java.net/browse/JDK-8237971 > > [2] - http://cr.openjdk.java.net/~herrick/8237971/webrev.01/ > > /Andy > From alexander.matveev at oracle.com Fri May 15 22:42:55 2020 From: alexander.matveev at oracle.com (alexander.matveev at oracle.com) Date: Fri, 15 May 2020 15:42:55 -0700 Subject: RFR: JDK-823797: ,Package type for runtime image on macosx In-Reply-To: <9ec5b3b7-c424-058f-e55b-ee809a1b5ce6@oracle.com> References: <9ec5b3b7-c424-058f-e55b-ee809a1b5ce6@oracle.com> Message-ID: <9eaf811b-b2b7-15cb-1468-1c028ca4b350@oracle.com> Hi Andy, Looks good. Thanks, Alexander On 5/15/20 8:55 AM, Andy Herrick wrote: > Please review fix for issue [1] at [2]. > > The change enables packaging runtime images as a dmg on MacOS. > > [1] - https://bugs.openjdk.java.net/browse/JDK-8237971 > > [2] - http://cr.openjdk.java.net/~herrick/8237971/webrev.01/ > > /Andy > From philipp.kunz at paratix.ch Sun May 17 09:53:50 2020 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Sun, 17 May 2020 11:53:50 +0200 Subject: RFR: JDK-8243454 - Redundant code for executable jar file manifests except SplashScreen-Image In-Reply-To: <866cb01ce33c1468f78b43ac51cbeb7b28d38125.camel@paratix.ch> References: <866cb01ce33c1468f78b43ac51cbeb7b28d38125.camel@paratix.ch> Message-ID: <01fb33ccad1252e45d103503062075f8f33a6387.camel@paratix.ch> Hi, Essentially the same patch as last time [1] but this time with a bug number [2].The patch does not include the updated UnicodeTest.jar which I created with ../jtreg-5.0-b01/bin/jtreg -va -nr -jdk:build/linux-x86_64-server- release/images/jdk/ -Xshare:off test/jdk/tools/launcher/UnicodeTest.javacp JTwork/scratch/UnicodeTest.jar test/jdk/tools/launcher/ Regards,Philipp [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-January/064190.html[2 ] https://bugs.openjdk.java.net/browse/JDK-8243454 On Sat, 2020-01-04 at 11:00 +0100, Philipp Kunz wrote: > Hi, > When I tried to improve Unicode support in JAR manifests in [1], > independent of what will happen with that, I found that there are not > only Manifest and Attributes classes parsing manifests but also some > c code which parses "SplashScreen-Image" attribute and also used to > parse some other attributes such as "Main-Class" and others. > There already are tests for splash screen images but those existing > ones work with the "-splash" command line option and not with the > "SplashScreen-Image" manifest attribute. I found "SplashScreen-Image" > manifest attribute not yet covered with a test and extended the > existing UnicodeTest accordingly, see attached patch which confirmed > that the "SplashScreen-Image" manifest attribute already fully > supports Unicode. > Support for "JRE-Version" manifest attribute and "-jre-restrict- > search" and "-jre-no-restrict-search" command line attributes has > already been removed earlier already and the relevant lines of code > determining the main class from the manifest when launching have > already been moved to or near LauncherHelper::getMainClassFromJar in > earlier versions, apparently leaving them with no use any longer in > java.c, java.h, manifest_info.h, and parse_manifest.c, I figure. > Hence, I propose to remove those parts as in the attached patch. > This leaves manifest_info.h and parse_manifest.c with "SplashScreen- > Image" as the only attribute parsed there. Certainly it would be a > different change but anyway it might be worth a consideration to move > the code opening the splash screen image to LauncherHelper or a > similar appropriate place in Java which would allow to remove quite a > number of some lines of c code, provided it could be acceptable to > show the splash screen image slightly later. > There is no existing related bug and I didn't find a new one. It > would be nice to have "SplashScreen-Image" manifest attribute covered > with a test and there is some potential for cleaning up unused code > which certainly is not urgent at all and I would not know how > desirable this really is. Also I'm not sure whether it's better or > not to add SPLASHSCREEN_IMAGE to Attributes.Name.KNOWN_NAMES. > Any opinion about to how to proceed with this, if at all or would > someone sponsor this patch? > Regards,Philipp > > [1] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-December/064149.html > -------------- next part -------------- A non-text attachment was scrubbed... Name: 20200517-splashscreenimageunicodetestwithoutunicodetestjar.patch Type: text/x-patch Size: 24288 bytes Desc: not available URL: From lance.andersen at oracle.com Sun May 17 13:30:56 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Sun, 17 May 2020 09:30:56 -0400 Subject: RFR: JDK-8243454 - Redundant code for executable jar file manifests except SplashScreen-Image In-Reply-To: <01fb33ccad1252e45d103503062075f8f33a6387.camel@paratix.ch> References: <866cb01ce33c1468f78b43ac51cbeb7b28d38125.camel@paratix.ch> <01fb33ccad1252e45d103503062075f8f33a6387.camel@paratix.ch> Message-ID: Hi Philipp, I have not looked at this in detail yet, but the changes you are proposing would require a CSR and probably an update to the JAR specification I am not sure of the history as to why this was done, perhaps others might know. I think this would be good to know as part of considering this change/ Best, Lance > On May 17, 2020, at 5:53 AM, Philipp Kunz wrote: > > Hi, > Essentially the same patch as last time [1] but this time with a bug > number [2].The patch does not include the updated UnicodeTest.jar which > I created with > ../jtreg-5.0-b01/bin/jtreg -va -nr -jdk:build/linux-x86_64-server- > release/images/jdk/ -Xshare:off > test/jdk/tools/launcher/UnicodeTest.javacp > JTwork/scratch/UnicodeTest.jar test/jdk/tools/launcher/ > Regards,Philipp > [1] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-January/064190.html[2 > ] https://bugs.openjdk.java.net/browse/JDK-8243454 > > On Sat, 2020-01-04 at 11:00 +0100, Philipp Kunz wrote: >> Hi, >> When I tried to improve Unicode support in JAR manifests in [1], >> independent of what will happen with that, I found that there are not >> only Manifest and Attributes classes parsing manifests but also some >> c code which parses "SplashScreen-Image" attribute and also used to >> parse some other attributes such as "Main-Class" and others. >> There already are tests for splash screen images but those existing >> ones work with the "-splash" command line option and not with the >> "SplashScreen-Image" manifest attribute. I found "SplashScreen-Image" >> manifest attribute not yet covered with a test and extended the >> existing UnicodeTest accordingly, see attached patch which confirmed >> that the "SplashScreen-Image" manifest attribute already fully >> supports Unicode. >> Support for "JRE-Version" manifest attribute and "-jre-restrict- >> search" and "-jre-no-restrict-search" command line attributes has >> already been removed earlier already and the relevant lines of code >> determining the main class from the manifest when launching have >> already been moved to or near LauncherHelper::getMainClassFromJar in >> earlier versions, apparently leaving them with no use any longer in >> java.c, java.h, manifest_info.h, and parse_manifest.c, I figure. >> Hence, I propose to remove those parts as in the attached patch. >> This leaves manifest_info.h and parse_manifest.c with "SplashScreen- >> Image" as the only attribute parsed there. Certainly it would be a >> different change but anyway it might be worth a consideration to move >> the code opening the splash screen image to LauncherHelper or a >> similar appropriate place in Java which would allow to remove quite a >> number of some lines of c code, provided it could be acceptable to >> show the splash screen image slightly later. >> There is no existing related bug and I didn't find a new one. It >> would be nice to have "SplashScreen-Image" manifest attribute covered >> with a test and there is some potential for cleaning up unused code >> which certainly is not urgent at all and I would not know how >> desirable this really is. Also I'm not sure whether it's better or >> not to add SPLASHSCREEN_IMAGE to Attributes.Name.KNOWN_NAMES. >> Any opinion about to how to proceed with this, if at all or would >> someone sponsor this patch? >> Regards,Philipp >> >> [1] >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-December/064149.html >> > <20200517-splashscreenimageunicodetestwithoutunicodetestjar.patch> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From gnu.andrew at redhat.com Sun May 17 18:22:19 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sun, 17 May 2020 19:22:19 +0100 Subject: [8u] RFR(S): 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result In-Reply-To: References: <17f5dc4d7bc7d405acfd2c49642a97c1fc22689a.camel@redhat.com> <808419e3-316b-381d-f636-606aadff39b6@redhat.com> <15a2fa41f80935d8c7d3893aad7d080c1f67aa2a.camel@redhat.com> <74e4d10641c8b6acca8ada68459a767f98e23585.camel@redhat.com> Message-ID: <38d5c8bb-5be7-af41-786a-5621a118f8fd@redhat.com> On 15/05/2020 14:29, Andrew Haley wrote: > On 5/15/20 9:45 AM, Severin Gehwolf wrote: >> So, Andrew Haley, what's the verdict on this one? There is a risk, yes. >> Not fixing the bug seems riskier, though. Thoughts? > > Thanks for the detailed explanation. > > I think we have to keep sun.misc.Version working correctly but > sacrifice binary consistency in JVM_GetVersionInfo. As long as stuff > such as AOT compilation and class data sharing keep working I think > we're OK. It's not great, but it's an almost-inevitable consequence of > using a one-byte field for the minor version and bumping releases by > 10. > I see little to no risk in changing this. Anyone using 7u261 or later, or 8u262 or later, is going to get an overflowed minor JVM version and an overflowed upgrade JDK version even if we do nothing at all. What we can do is attempt to fix things in a way that doesn't change the size of the structure, just the interpretation of its contents, as proposed here. Calling code that adapts to the modified version will then be able to get the correct values. Code that doesn't will be just as broken as if we'd made no change. Arguably, even that case will be a little better, as with a non-zero micro value, the incorrect version will at least be distinct from older versions. This is for 7u & 8u, which don't have AOT compilation, so that shouldn't be an issue. I'll be approving this for 8u. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From peter.levart at gmail.com Mon May 18 08:48:49 2020 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 18 May 2020 10:48:49 +0200 Subject: RFR: 8244936: Reduce JNI overhead of accessing FileDescriptor In-Reply-To: References: Message-ID: <8c3e43a9-ab3e-3c0a-8d78-2bd33de661fb@gmail.com> Hi Claes, One step further would be to eliminate access to FileDescriptor.fd/handle from native hot paths altogether and pass the fd/handle to native methods from java: http://cr.openjdk.java.net/~plevart/jdk-dev/8244936_dont_access_FileDescriptor/webrev.01/ This has similar incremental effect on the RandomAccessRead.test micro as your patch had: before: Benchmark??????????????????? (buffer)? (fileSize)?? Mode? Cnt Score??? Error?? Units RandomAccessRead.test??????????? 8192???? 1000000? thrpt??? 5 809.538 ? 11.658? ops/ms after: Benchmark??????????????????? (buffer)? (fileSize)?? Mode? Cnt Score??? Error?? Units RandomAccessRead.test??????????? 8192???? 1000000? thrpt??? 5 861.619 ? 12.307? ops/ms All jdk_io tests pass on Linux but I don't have a Windows machine at hand. So WDYT? Regards, Peter On 5/13/20 5:44 PM, Claes Redestad wrote: > Hi, > > compilers can't see though and optimize away the repeated GetObjectField > calls in places such as in the io_util_md.h GET_FD macro: > > #define GET_FD(this, fid) \ > ??? (*env)->GetObjectField(env, (this), (fid)) == NULL ? \ > ??????? -1 : (*env)->GetIntField(env, (*env)->GetObjectField(env, > (this), (fid)), IO_fd_fdID) > > This can be avoided if we turn the macros into functions which call > GetObjectField only once: > > FD getFD(JNIEnv *env, jobject this, jfieldID fid) { > ? jobject fd = (*env)->GetObjectField(env, this, fid); > ? if (fd == NULL) { > ??? return -1; > ? } > ? return (*env)->GetIntField(env, fd, IO_fd_fdID); > } > > The similarly affected SET_FD is only used in one place, so I removed > that macro and applied the equivalent optimization at the call-site. > > Webrev: http://cr.openjdk.java.net/~redestad/8244936/open.00/ > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8244936 > > This shows an improvement on the existing RandomAccessRead.test micro: > > Before: > Benchmark??????????????? (fileSize)? Mode? Cnt? Score?? Error Units > RandomAccessRead.test?????? 1000000? avgt?? 25? 0.832 ? 0.001 us/op > > After: > Benchmark??????????????? (fileSize)? Mode? Cnt? Score?? Error Units > RandomAccessRead.test?????? 1000000? avgt?? 25? 0.771 ? 0.005 us/op > > ~60ns/op overhead reduction - or ~30ns per native call (the micro calls > RAF::seek followed by RAF::read). > > Since it's an improvement to the constant call overhead, relative gain > diminishes for larger operations, e.g., reading a 512b buffer sees only > ~2% improvement, while already on a 8kb read the improvement is more or > less the noise. I added a read-into-buffer variant of the micro that > demonstrates. > > Still, constant overhead is constant overhead, and operations that only > read a few bytes is common enough, for example when opening zip files, > so there's a fair chance for a positive effect in various places. As a > bonus this refactoring shrinks libjava by a few Kb. > > Testing: tier1-2 > > Thanks! > > /Claes From Alan.Bateman at oracle.com Mon May 18 08:52:40 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 May 2020 09:52:40 +0100 Subject: RFR: 8244936: Reduce JNI overhead of accessing FileDescriptor In-Reply-To: <8c3e43a9-ab3e-3c0a-8d78-2bd33de661fb@gmail.com> References: <8c3e43a9-ab3e-3c0a-8d78-2bd33de661fb@gmail.com> Message-ID: <354abe60-90df-5345-e424-d8a9fe39f65e@oracle.com> On 18/05/2020 09:48, Peter Levart wrote: > Hi Claes, > > > One step further would be to eliminate access to > FileDescriptor.fd/handle from native hot paths altogether and pass the > fd/handle to native methods from java: I was chatting with Claes about this last week and the concern with doing this is that it creates problems for async close because it increases the window where the native code is using a "raw" file descriptor. -Alan From peter.levart at gmail.com Mon May 18 08:59:20 2020 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 18 May 2020 10:59:20 +0200 Subject: RFR: 8244936: Reduce JNI overhead of accessing FileDescriptor In-Reply-To: <354abe60-90df-5345-e424-d8a9fe39f65e@oracle.com> References: <8c3e43a9-ab3e-3c0a-8d78-2bd33de661fb@gmail.com> <354abe60-90df-5345-e424-d8a9fe39f65e@oracle.com> Message-ID: <472fd418-b940-4c52-4067-98040a4c525d@gmail.com> On 5/18/20 10:52 AM, Alan Bateman wrote: > On 18/05/2020 09:48, Peter Levart wrote: >> Hi Claes, >> >> >> One step further would be to eliminate access to >> FileDescriptor.fd/handle from native hot paths altogether and pass >> the fd/handle to native methods from java: > I was chatting with Claes about this last week and the concern with > doing this is that it creates problems for async close because it > increases the window where the native code is using a "raw" file > descriptor. Please elaborate. Do you have an example of such use case? Are there any existing races possible? Peter > > -Alan From Alan.Bateman at oracle.com Mon May 18 09:11:21 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 18 May 2020 10:11:21 +0100 Subject: RFR: 8244936: Reduce JNI overhead of accessing FileDescriptor In-Reply-To: <472fd418-b940-4c52-4067-98040a4c525d@gmail.com> References: <8c3e43a9-ab3e-3c0a-8d78-2bd33de661fb@gmail.com> <354abe60-90df-5345-e424-d8a9fe39f65e@oracle.com> <472fd418-b940-4c52-4067-98040a4c525d@gmail.com> Message-ID: <640ecc51-2467-b3ac-4852-c4e15b4db082@oracle.com> On 18/05/2020 09:59, Peter Levart wrote: > : > > Please elaborate. Do you have an example of such use case? Are there > any existing races possible? Everywhere that closes a file descriptor needs to coordinate the closing with threads that may be accessing that file descriptor, otherwise you risk doing I/O on file descriptors that have been recycled. This has always been problematic for the legacy java.io classes, so the concern is that increasing the window where you are using the "raw" file descriptor will make it worse. -Alan. From claes.redestad at oracle.com Mon May 18 10:04:29 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 18 May 2020 12:04:29 +0200 Subject: RFR: 8244936: Reduce JNI overhead of accessing FileDescriptor In-Reply-To: <640ecc51-2467-b3ac-4852-c4e15b4db082@oracle.com> References: <8c3e43a9-ab3e-3c0a-8d78-2bd33de661fb@gmail.com> <354abe60-90df-5345-e424-d8a9fe39f65e@oracle.com> <472fd418-b940-4c52-4067-98040a4c525d@gmail.com> <640ecc51-2467-b3ac-4852-c4e15b4db082@oracle.com> Message-ID: On 2020-05-18 11:11, Alan Bateman wrote: > On 18/05/2020 09:59, Peter Levart wrote: >> : >> >> Please elaborate. Do you have an example of such use case? Are there >> any existing races possible? > Everywhere that closes a file descriptor needs to coordinate the closing > with threads that may be accessing that file descriptor, otherwise you > risk doing I/O on file descriptors that have been recycled. This has > always been problematic for the legacy java.io classes, so the concern > is that increasing the window where you are using the "raw" file > descriptor will make it worse. The pushed fix gets half the potential gain while possibly narrowing the window, so seemed like an obvious and quick win for speed without hurting reliability. Getting to the other half of the potential gain would of course be great, but proving it is (or can be made) safe might be a challenge. Alan has asked me not to pursue this right now since there's a lot of history to dig up here, and much of it might not be available in the open. /Claes From peter.levart at gmail.com Mon May 18 10:18:25 2020 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 18 May 2020 12:18:25 +0200 Subject: RFR: 8244936: Reduce JNI overhead of accessing FileDescriptor In-Reply-To: <640ecc51-2467-b3ac-4852-c4e15b4db082@oracle.com> References: <8c3e43a9-ab3e-3c0a-8d78-2bd33de661fb@gmail.com> <354abe60-90df-5345-e424-d8a9fe39f65e@oracle.com> <472fd418-b940-4c52-4067-98040a4c525d@gmail.com> <640ecc51-2467-b3ac-4852-c4e15b4db082@oracle.com> Message-ID: On 5/18/20 11:11 AM, Alan Bateman wrote: > On 18/05/2020 09:59, Peter Levart wrote: >> : >> >> Please elaborate. Do you have an example of such use case? Are there >> any existing races possible? > Everywhere that closes a file descriptor needs to coordinate the > closing with threads that may be accessing that file descriptor, > otherwise you risk doing I/O on file descriptors that have been > recycled. This has always been problematic for the legacy java.io > classes, so the concern is that increasing the window where you are > using the "raw" file descriptor will make it worse. > > -Alan. Ah, that. So the concern is that the operation performed would be performed on the wrong file because the fd/handle would be recycled. So here you assume that transition from java to native code takes considerably more time than the part of GetIntField JNI API call between reading the field value and completing the call? Or is the transition to native code equipped with some sort of implicit memory barrier so that reading the filed from native code makes it more recent? If that last is the case then perhaps such memory barrier could be issued in java code too... Regards, Peter From Roger.Riggs at oracle.com Mon May 18 13:58:31 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 18 May 2020 09:58:31 -0400 Subject: RFR [15] 8244342: Compilation warnings about unexpected serialization related method signatures. In-Reply-To: <5ebd7cad-8e56-b747-1b66-55b0c1b5276b@oracle.com> References: <1e7b9a0a-869e-acb0-5d70-062da677611f@oracle.com> <5ebd7cad-8e56-b747-1b66-55b0c1b5276b@oracle.com> Message-ID: <61430c43-e865-6240-d9fe-9c93dca4d693@oracle.com> Hi Joe, Looks good, thanks for the cleanup. Roger On 5/15/20 2:39 PM, naoto.sato at oracle.com wrote: > +1 > > Naoto > > On 5/15/20 11:35 AM, Lance Andersen wrote: >> Looks ok joe >> >>> On May 15, 2020, at 1:54 PM, Joe Wang wrote: >>> >>> Hi, >>> >>> Please review a fix for the compilation warnings. Thanks Roger for >>> the detailed instructions! If you could verify the fix with the >>> work-in-progress processor, that would be great too. Regular build >>> and test passed. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8244342 >>> http://cr.openjdk.java.net/~joehw/jdk15/8244342/webrev/ >>> >>> Thanks, >>> Joe >> >> >> >> >> Lance >> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> From macanaoire at hotmail.com Mon May 18 17:21:34 2020 From: macanaoire at hotmail.com (mark sheppard) Date: Mon, 18 May 2020 17:21:34 +0000 Subject: RFR [15] 8244342: Compilation warnings about unexpected serialization related method signatures. In-Reply-To: <1e7b9a0a-869e-acb0-5d70-062da677611f@oracle.com> References: <1e7b9a0a-869e-acb0-5d70-062da677611f@oracle.com> Message-ID: Hi Joe, do your changes warrant a java doc change for readObject in each LocPathIterator PredicatedNodeTest, and UnionPathIterator ? regards Mark ________________________________ From: core-libs-dev on behalf of Joe Wang Sent: Friday 15 May 2020 17:54 To: core-libs-dev at openjdk.java.net Subject: RFR [15] 8244342: Compilation warnings about unexpected serialization related method signatures. Hi, Please review a fix for the compilation warnings. Thanks Roger for the detailed instructions! If you could verify the fix with the work-in-progress processor, that would be great too. Regular build and test passed. https://bugs.openjdk.java.net/browse/JDK-8244342 http://cr.openjdk.java.net/~joehw/jdk15/8244342/webrev/ Thanks, Joe From paul.sandoz at oracle.com Mon May 18 19:13:59 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 18 May 2020 12:13:59 -0700 Subject: Update Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests In-Reply-To: <49F81016-55DF-4E3C-940A-A8DF8C712259@oracle.com> References: <49F81016-55DF-4E3C-940A-A8DF8C712259@oracle.com> Message-ID: <9D074341-7234-4D9F-8E99-0E73F5BB5407@oracle.com> HI, Here?s an update of the API and implementation webrevs based on (mostly) API feedback. We have removed the performance tests to make the review easier (those will be dealt with separately to integration as a follow on task). I think over the past year and recently via the CSR the API has had significant review. Reviews focusing on the Java implementation and tests would be greatly appreciated. It?s worth reiterating that the implementation and tests are quite formulaic, there is a lot of code that is generated from templates, so it's possible to focus on the template + subset (e.g. byte, long, float, and sizes of say 256, max). Notable changes from the prior webrev are: - Removal of the fromValues methods to construct a vector from a varargs array. Feedback indicated this was a misleading way to obtain a vector. - Unification of byte array and ByteBuffer load/store method signatures and unification of the implementations with more tests (including out-of-bounds tests for all the kinds of loads/stores). Paul. -- Latest javadoc http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/docs-2020-05-15-88a83f7238d8/api/jdk.incubator.vector/jdk/incubator/vector/package-summary.html Latest specdiff http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/specdiff-jdk-2020-05-15-88a83f7238d8/overview-summary.html Incremental specdiff http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/specdiff-2020-05-11-38dd763d023e-2020-05-15-88a83f7238d8/overview-summary.html Latest implementation webrev http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev-2020-05-16-default-2020-05-15-88a83f7238d8/webrev/ Incremental Implementation webrev http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev-2020-05-11-38dd763d023e-2020-05-15-88a83f7238d8/webrev/ Latest test webrev http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev-2020-05-16-default-2020-05-15-88a83f7238d8/webrev/ Incremental test webrev http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev-2020-05-11-38dd763d023e-2020-05-15-88a83f7238d8/webrev/ > On Apr 1, 2020, at 3:46 PM, Paul Sandoz wrote: > > Hi, > > A prior email sent out a request for review of the Vector API in preparation for JEP 338: Vector API (Incubator) [1] to be proposed for target: > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html > > This email expands the review of the API to the Java implementation and Java tests: > > http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev/webrev/ > > http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev/webrev/ > > (Further emails will sent for review of general HotSpot changes CPU architecture specific HotSpot changes, x64 and aarch64, and performance tests. For an early peek see the links in the description of JDK-8223347.) > > ? > > The Vector API provides > > - the public Vector class with vector operations common to all supported primitive types > > - public primitive specializations, such as IntVector, with common operations associated with the primitive type > > - internal concrete specializations for the vector size, such as Int256Vector, for a vector holding 8 ints. > > Operations generally defer to one of approximately 20 vector intrinsics. Some operations may be composed of other operations. > > Explicit casts are performed by vector operations to ensure vectors arguments are of the required shape (bit size) and element type. > > A vector intrinsic is an internal low-level vector operation. The last argument to the intrinsic is fall back behavior in Java, implementing the scalar operation over the number of elements held by the vector. Thus, If the intrinsic is not supported in C2 for the other arguments then the Java implementation is executed (the Java implementation is always executed when running in the interpreter or for C1). > > The public primitive specializations and the internal concrete implementations are generated from SSP template files, X-Vector.java.template and X-VectorBits.java.template respectively. > > Overall the implementation approach is quite formulaic and rather repetitive. Once you grok the pattern It should be easier to review if a little laborious. > > Unit tests are auto-generated by composing templates for each operation into an SSP template file which is then used to generate unit test files for each concrete vector class. The tests are quite extensive and have found many a HotSpot issue in development across a wide range of platforms. > > Paul. > > [1] https://bugs.openjdk.java.net/browse/JDK-8201271 > From huizhe.wang at oracle.com Mon May 18 19:36:10 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 18 May 2020 12:36:10 -0700 Subject: RFR [15] 8244342: Compilation warnings about unexpected serialization related method signatures. In-Reply-To: References: <1e7b9a0a-869e-acb0-5d70-062da677611f@oracle.com> Message-ID: <12616163-bd28-c723-b567-c959ab862a23@oracle.com> Thanks Mark! I missed that, and I was also 20 min too fast on the checkin :-) Here's a catch-up patch, pls review: http://cr.openjdk.java.net/~joehw/jdk15/8245231/webrev/ -Joe On 5/18/2020 10:21 AM, mark sheppard wrote: > Hi Joe, > ? ?do your changes warrant a java doc change for readObject > in each LocPathIterator PredicatedNodeTest, and UnionPathIterator ? > > regards > Mark > > ------------------------------------------------------------------------ > *From:* core-libs-dev on > behalf of Joe Wang > *Sent:* Friday 15 May 2020 17:54 > *To:* core-libs-dev at openjdk.java.net > *Subject:* RFR [15] 8244342: Compilation warnings about unexpected > serialization related method signatures. > Hi, > > Please review a fix for the compilation warnings. Thanks Roger for the > detailed instructions! If you could verify the fix with the > work-in-progress processor, that would be great too. Regular build and > test passed. > > https://bugs.openjdk.java.net/browse/JDK-8244342 > http://cr.openjdk.java.net/~joehw/jdk15/8244342/webrev/ > > Thanks, > Joe From claes.redestad at oracle.com Mon May 18 20:48:53 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 18 May 2020 22:48:53 +0200 Subject: RFR: 8215401: Add isEmpty default method to CharSequence Message-ID: <73809ad1-e317-ade2-7fec-f356f38d005c@oracle.com> Hi, let's add an isEmpty default method to CharSequence! Webrev: http://cr.openjdk.java.net/~redestad/8215401/open.00/ RFE: https://bugs.openjdk.java.net/browse/JDK-8215401 CSR: https://bugs.openjdk.java.net/browse/JDK-8215402 Testing: tier1-3 /Claes From macanaoire at hotmail.com Mon May 18 20:49:44 2020 From: macanaoire at hotmail.com (mark sheppard) Date: Mon, 18 May 2020 20:49:44 +0000 Subject: RFR [15] 8244342: Compilation warnings about unexpected serialization related method signatures. In-Reply-To: <12616163-bd28-c723-b567-c959ab862a23@oracle.com> References: <1e7b9a0a-869e-acb0-5d70-062da677611f@oracle.com> , <12616163-bd28-c723-b567-c959ab862a23@oracle.com> Message-ID: Hi Joe, all good I think. ?? regards Mark ________________________________ From: Joe Wang Sent: Monday 18 May 2020 19:36 To: mark sheppard ; core-libs-dev at openjdk.java.net Cc: Mark Sheppard Subject: Re: RFR [15] 8244342: Compilation warnings about unexpected serialization related method signatures. Thanks Mark! I missed that, and I was also 20 min too fast on the checkin :-) Here's a catch-up patch, pls review: http://cr.openjdk.java.net/~joehw/jdk15/8245231/webrev/ -Joe On 5/18/2020 10:21 AM, mark sheppard wrote: Hi Joe, do your changes warrant a java doc change for readObject in each LocPathIterator PredicatedNodeTest, and UnionPathIterator ? regards Mark ________________________________ From: core-libs-dev on behalf of Joe Wang Sent: Friday 15 May 2020 17:54 To: core-libs-dev at openjdk.java.net Subject: RFR [15] 8244342: Compilation warnings about unexpected serialization related method signatures. Hi, Please review a fix for the compilation warnings. Thanks Roger for the detailed instructions! If you could verify the fix with the work-in-progress processor, that would be great too. Regular build and test passed. https://bugs.openjdk.java.net/browse/JDK-8244342 http://cr.openjdk.java.net/~joehw/jdk15/8244342/webrev/ Thanks, Joe From huizhe.wang at oracle.com Mon May 18 20:53:47 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 18 May 2020 13:53:47 -0700 Subject: RFR [15] 8244342: Compilation warnings about unexpected serialization related method signatures. In-Reply-To: References: <1e7b9a0a-869e-acb0-5d70-062da677611f@oracle.com> <12616163-bd28-c723-b567-c959ab862a23@oracle.com> Message-ID: <0b5aa875-7133-94e8-e4d0-a4276c893e7f@oracle.com> Thanks Mark. -Joe On 5/18/2020 1:49 PM, mark sheppard wrote: > Hi Joe, > > all good I think. ?? > > regards > Mark > > ------------------------------------------------------------------------ > *From:* Joe Wang > *Sent:* Monday 18 May 2020 19:36 > *To:* mark sheppard ; > core-libs-dev at openjdk.java.net > *Cc:* Mark Sheppard > *Subject:* Re: RFR [15] 8244342: Compilation warnings about unexpected > serialization related method signatures. > Thanks Mark! I missed that, and I was also 20 min too fast on the > checkin :-) > > Here's a catch-up patch, pls review: > http://cr.openjdk.java.net/~joehw/jdk15/8245231/webrev/ > > -Joe > > On 5/18/2020 10:21 AM, mark sheppard wrote: >> Hi Joe, >> ? ?do your changes warrant a java doc change for readObject >> in each LocPathIterator PredicatedNodeTest, and UnionPathIterator ? >> >> regards >> Mark >> >> ------------------------------------------------------------------------ >> *From:* core-libs-dev >> on behalf of Joe Wang >> >> *Sent:* Friday 15 May 2020 17:54 >> *To:* core-libs-dev at openjdk.java.net >> >> >> *Subject:* RFR [15] 8244342: Compilation warnings about unexpected >> serialization related method signatures. >> Hi, >> >> Please review a fix for the compilation warnings. Thanks Roger for the >> detailed instructions! If you could verify the fix with the >> work-in-progress processor, that would be great too. Regular build and >> test passed. >> >> https://bugs.openjdk.java.net/browse/JDK-8244342 >> http://cr.openjdk.java.net/~joehw/jdk15/8244342/webrev/ >> >> Thanks, >> Joe > From philipp.kunz at paratix.ch Mon May 18 21:42:43 2020 From: philipp.kunz at paratix.ch (Philipp Kunz) Date: Mon, 18 May 2020 23:42:43 +0200 Subject: 6202130: Need to handle UTF-8 values and break up lines longer than 72 bytes In-Reply-To: References: <44EE1961-6729-4F96-8885-439FED393A81@oracle.com> <026cd2c446b0133fb8a9ec59c4fc3032a04de3fb.camel@paratix.ch> <10485888-3ac8-c967-0131-08fe52d2694d@oracle.com> <6a4e59d2e0028d80da9655cb1f724697bd516461.camel@paratix.ch> <1d249f65-8086-4806-ef91-d7ecdfcf15bc@oracle.com> <220837ff2ee9039fd466089e9a77d8000d9bab70.camel@paratix.ch> Message-ID: Hi Brent, Thank you very much indeed for your serious answer. Still a lot of work left but to start with I randomly picked Ant and found it suffers a bug. See attached bunch of files to reproduce. The bug does not occur with my proposed patch. One reason for this bug to occur is cutting and concatenating binary portions of manifests as strings which don't properly align with Unicode character boundaries which just does not work and my patch avoids. If I may share an opinion I'd prefer to avoid manifests which are not also valid UTF-8 in the first place. Regards,Philipp On Fri, 2020-05-08 at 11:04 -0700, Brent Christian wrote: > Hi, Philipp. Sorry for the further delay. > Just to step back a bit: > The current manifest-writing behavior dates back to JDK 1.2 (at > least), so compatibility is an overriding concern. It is unfortunate > that multi-byte characters weren't better accounted for in the > placement of line breaks from the beginning. > But typically in cases like this, we would update the specification > to fit the long-standing behavior, and avoid the risk of breaking > applications in the wild. > We can test that manifests written with your changes can be read by > the JDK. But there is also manifest-reading code external to the > JDK. Some examples, that would need to be investigated: > jarmanifesthttps://pypi.org/project/jarmanifest/ > > Chromium > https://chromium.googlesource.com/external/googleappengine/python/+/7e0ab775c587657f0f93a3134f2db99e46bb98bd/google/appengine/tools/jarfile.py > > Mavenhttp://maven.apache.org/shared/maven-archiver/index.html > > Apache Ant > https://en.wikipedia.org/wiki/JAR_(file_format)#Apache_Ant_Zip/JAR_support > > IDEs would be another good place to check, and maybe also consumers > of JavaEE WAR / EAR files. > > Performance is also a consideration. JMH benchmarks would be needed > to confirm that reading the new manifest is not slower, and to gauge > any regression in Manifest writing performance. > > So that is the work that would need to be done to support this > change. > The question then will be if the benefit of this change (seen only > outside of running code) outweighs the risk of changing behavior that > has not been an issue for 20+ years. It seems unlikely that a strong > enough case could be made. > -Brent > On 4/13/20 10:29 AM, Philipp Kunz wrote: > > Hi Naoto,You are absolutely right to raise the question. I've also > > thought aboutthis but haven't come up so far with a compellingly > > elegant solution,at least not yet.If only String.isLatin1 was > > public that would come in very handy.Character or anything else I > > looked at cannot tell if a string isascii. BreakIterator supports > > iterating backwards so we could start atthe potential line end but > > that requires a start position that is aboundary to start with and > > that is not obviously possible due to theregional indicators and > > probably other code points requiring statefulprocessing. Same with > > regexes and I wouldn't know how to express groupsthat could count > > bytes. It does not even seem to be possible to guessany number of > > characters to start searching for a boundary because ofthe > > statefulness. Even the most simple approach to detect latin1Strings > > requires an encoding or a regex such as "[^\\p{ASCII}]" > > whichessentially is another inefficient loop. It also does not work > > toencode the string into UTF-8 in a single pass because then it is > > notknown which grapheme boundary matches to which byte position. I > > alsotried to write the header names and the ": " delimiter without > > breakingfirst but it did not seem to significantly affect > > performance.UTF_8.newEncoder cannot process single surrogates, > > admittedly an edgecase, but required for compatibility. I added a > > fast path, see patch,the best way I could think of. Did I miss a > > better way to tell asciistrings from others?What I found actually > > improving performance is based on theconsideration that strings are > > composed of primitive chars that will beencoded into three bytes > > each maximum always that up to 24 characterscan be passed to > > writeChar72 at a time reducing the number ofwriteChar72 and in turn > > String.getBytes invocations. The number ofcharacters that can be > > passed to writeChar72 is at most the number ofbytes remaining on > > the current manifest line (linePos) divided by threebut at least > > one. See attached patch.Regards,Philipp > > On Mon, 2020-03-30 at 14:31 -0700, naoto.sato at oracle.com wrote: > > > Hi Philipp,Sorry for the delay.On 3/25/20 11:52 AM, Philipp Kunz > > > wrote: > > > > Hi Naoto,See another patch attached with Locale.ROOT for the > > > > BreakIterator.I will be glad to hear of any feedback. > > > > > > I wonder how your change affects the performance, as it will > > > doString.getBytes(UTF-8) per each character. I think this > > > candefinitely be improved by adding some fastpath, e.g., for > > > ASCII. Theusage of the BreakIterator is fine, though. > > > > There is another patch [1] around dealing with manifest > > > > attributesduring application launch. It certainly is related to > > > > 6202130 butfeels like a distinct set of changes with a slightly > > > > differentconcern. Any opinion as how to proceed with that one? > > > > > > I am not quite sure which patch you are referring to, but I > > > agreethat creating an issue would not hurt.Naoto > > > > Regards,Philipp > > > > > > > > [1] > > > > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-February/064720.html > > > > > > > > > > > > On Mon, 2020-03-23 at 09:05 -0700, naoto.sato at oracle.com wrote: > > > > > Hi Philipp,Right, Locale.ROOT is more appropriate here by > > > > > definition, thoughtheimplementation is the same.NaotoOn > > > > > 3/21/20 5:19 AM, Philipp Kunz wrote: > > > > > > Hi Naoto and everyone,There are almost as many occurrences > > > > > > of Locale.ROOT asLocale.US whichmade me wonder which one is > > > > > > more appropriatelylocale-independent andwhich is probably > > > > > > another topic and notactually relevant > > > > > > herebecauseBreakIterator.getCharacterInstance is locale- > > > > > > agnostic asfar as I can tell.See attached patch with > > > > > > another attempt to fix bug 6202130.Regards,Philipp > > > > > > On Tue, 2020-03-10 at 10:45 -0700,naoto.sato at oracle.com > > > > > > wrote: > > > > > > > Hi Philipp,..., so using BreakIterator (withLocale.US) is > > > > > > > more preferredsolution to me.Naoto From huizhe.wang at oracle.com Mon May 18 22:04:29 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 18 May 2020 15:04:29 -0700 Subject: RFR [15] 8245231 Javadoc for the readObject methods needs to be updated (8244342 followup) In-Reply-To: <0b5aa875-7133-94e8-e4d0-a4276c893e7f@oracle.com> References: <1e7b9a0a-869e-acb0-5d70-062da677611f@oracle.com> <12616163-bd28-c723-b567-c959ab862a23@oracle.com> <0b5aa875-7133-94e8-e4d0-a4276c893e7f@oracle.com> Message-ID: <31b52dbe-8c00-0b89-f18e-bc5efd7dc57c@oracle.com> As it appears, I was missing a comma in the header as well (see https://bugs.openjdk.java.net/browse/JDK-8245238) The webrev is updated with the comma added (to PredicatedNodeTest.java) http://cr.openjdk.java.net/~joehw/jdk15/8245231/webrev/ Thanks, Joe On 5/18/2020 1:53 PM, Joe Wang wrote: > Thanks Mark. > > -Joe > > On 5/18/2020 1:49 PM, mark sheppard wrote: >> Hi Joe, >> >> all good I think. ?? >> >> regards >> Mark >> >> ------------------------------------------------------------------------ >> *From:* Joe Wang >> *Sent:* Monday 18 May 2020 19:36 >> *To:* mark sheppard ; >> core-libs-dev at openjdk.java.net >> *Cc:* Mark Sheppard >> *Subject:* Re: RFR [15] 8244342: Compilation warnings about >> unexpected serialization related method signatures. >> Thanks Mark! I missed that, and I was also 20 min too fast on the >> checkin :-) >> >> Here's a catch-up patch, pls review: >> http://cr.openjdk.java.net/~joehw/jdk15/8245231/webrev/ >> >> -Joe >> >> On 5/18/2020 10:21 AM, mark sheppard wrote: >>> Hi Joe, >>> ? ?do your changes warrant a java doc change for readObject >>> in each LocPathIterator PredicatedNodeTest, and UnionPathIterator ? >>> >>> regards >>> Mark >>> >>> ------------------------------------------------------------------------ >>> >>> *From:* core-libs-dev >>> on behalf of Joe >>> Wang >>> *Sent:* Friday 15 May 2020 17:54 >>> *To:* core-libs-dev at openjdk.java.net >>> >>> >>> >>> *Subject:* RFR [15] 8244342: Compilation warnings about unexpected >>> serialization related method signatures. >>> Hi, >>> >>> Please review a fix for the compilation warnings. Thanks Roger for the >>> detailed instructions! If you could verify the fix with the >>> work-in-progress processor, that would be great too. Regular build and >>> test passed. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8244342 >>> http://cr.openjdk.java.net/~joehw/jdk15/8244342/webrev/ >>> >>> Thanks, >>> Joe >> > From lance.andersen at oracle.com Mon May 18 22:06:08 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 18 May 2020 18:06:08 -0400 Subject: RFR [15] 8245231 Javadoc for the readObject methods needs to be updated (8244342 followup) In-Reply-To: <31b52dbe-8c00-0b89-f18e-bc5efd7dc57c@oracle.com> References: <1e7b9a0a-869e-acb0-5d70-062da677611f@oracle.com> <12616163-bd28-c723-b567-c959ab862a23@oracle.com> <0b5aa875-7133-94e8-e4d0-a4276c893e7f@oracle.com> <31b52dbe-8c00-0b89-f18e-bc5efd7dc57c@oracle.com> Message-ID: <96EC93EA-E5F8-4C0D-A48D-70A222FB7A72@oracle.com> looks good Joe > On May 18, 2020, at 6:04 PM, Joe Wang wrote: > > As it appears, I was missing a comma in the header as well (see https://bugs.openjdk.java.net/browse/JDK-8245238) > > The webrev is updated with the comma added (to PredicatedNodeTest.java) > http://cr.openjdk.java.net/~joehw/jdk15/8245231/webrev/ > > Thanks, > Joe > > On 5/18/2020 1:53 PM, Joe Wang wrote: >> Thanks Mark. >> >> -Joe >> >> On 5/18/2020 1:49 PM, mark sheppard wrote: >>> Hi Joe, >>> >>> all good I think. ?? >>> >>> regards >>> Mark >>> >>> ------------------------------------------------------------------------ >>> *From:* Joe Wang >>> *Sent:* Monday 18 May 2020 19:36 >>> *To:* mark sheppard ; core-libs-dev at openjdk.java.net >>> *Cc:* Mark Sheppard >>> *Subject:* Re: RFR [15] 8244342: Compilation warnings about unexpected serialization related method signatures. >>> Thanks Mark! I missed that, and I was also 20 min too fast on the checkin :-) >>> >>> Here's a catch-up patch, pls review: >>> http://cr.openjdk.java.net/~joehw/jdk15/8245231/webrev/ >>> >>> -Joe >>> >>> On 5/18/2020 10:21 AM, mark sheppard wrote: >>>> Hi Joe, >>>> do your changes warrant a java doc change for readObject >>>> in each LocPathIterator PredicatedNodeTest, and UnionPathIterator ? >>>> >>>> regards >>>> Mark >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* core-libs-dev on behalf of Joe Wang >>>> *Sent:* Friday 15 May 2020 17:54 >>>> *To:* core-libs-dev at openjdk.java.net >>>> *Subject:* RFR [15] 8244342: Compilation warnings about unexpected serialization related method signatures. >>>> Hi, >>>> >>>> Please review a fix for the compilation warnings. Thanks Roger for the >>>> detailed instructions! If you could verify the fix with the >>>> work-in-progress processor, that would be great too. Regular build and >>>> test passed. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8244342 >>>> http://cr.openjdk.java.net/~joehw/jdk15/8244342/webrev/ >>>> >>>> Thanks, >>>> Joe >>> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Roger.Riggs at oracle.com Mon May 18 22:29:06 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Mon, 18 May 2020 18:29:06 -0400 Subject: RFR: 8215401: Add isEmpty default method to CharSequence In-Reply-To: <73809ad1-e317-ade2-7fec-f356f38d005c@oracle.com> References: <73809ad1-e317-ade2-7fec-f356f38d005c@oracle.com> Message-ID: Hi Claes, Though it does not look like it could be any simpler, there should probably be a test. Checking consistency with the existing implementations of CharSequence.length() and a custom subtype. Thanks, Roger On 5/18/20 4:48 PM, Claes Redestad wrote: > Hi, > > let's add an isEmpty default method to CharSequence! > > Webrev: http://cr.openjdk.java.net/~redestad/8215401/open.00/ > RFE:??? https://bugs.openjdk.java.net/browse/JDK-8215401 > CSR:??? https://bugs.openjdk.java.net/browse/JDK-8215402 > > Testing: tier1-3 > > /Claes From vicente.romero at oracle.com Mon May 18 22:42:34 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 18 May 2020 18:42:34 -0400 Subject: RFR: JDK-8227046: compiler implementation for sealed classes, JDK-8227047: Javadoc for sealed types and JDK-8227044: javax.lang.model for sealed classes Message-ID: <3bd27bea-b8a3-88a2-5536-ea9610749ce4@oracle.com> Hi, Please review this patch for the compiler, javadoc and javax.lang.model support for the JEP 360 Sealed Classes (Preview). The changes are provided at [1], which implements the latest JLS for sealed types [2]. The patch also include the needed changes to javadoc and javax.lang.model to support sealed types. The CSR witht the changes in the javax.lang.model spec is at [3]. The sealed types JEP is accessible at [4]. There is an ongoing review for the VM and core-libs code of sealed types [5] and that code hasn't been included in this webrev, Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8227046/webrev.00/ [2] http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html [3] https://bugs.openjdk.java.net/browse/JDK-8244367 [4] https://openjdk.java.net/jeps/360 [5] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066440.html From jonathan.gibbons at oracle.com Tue May 19 00:31:47 2020 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 18 May 2020 17:31:47 -0700 Subject: RFR: 8215401: Add isEmpty default method to CharSequence In-Reply-To: <73809ad1-e317-ade2-7fec-f356f38d005c@oracle.com> References: <73809ad1-e317-ade2-7fec-f356f38d005c@oracle.com> Message-ID: You might want to check the /generated/ API docs. It doesn't look like the first {@link} will do what you might be expecting. -- Jon On 5/18/20 1:48 PM, Claes Redestad wrote: > Hi, > > let's add an isEmpty default method to CharSequence! > > Webrev: http://cr.openjdk.java.net/~redestad/8215401/open.00/ > RFE:??? https://bugs.openjdk.java.net/browse/JDK-8215401 > CSR:??? https://bugs.openjdk.java.net/browse/JDK-8215402 > > Testing: tier1-3 > > /Claes From david.holmes at oracle.com Tue May 19 05:26:38 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 May 2020 15:26:38 +1000 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> Message-ID: Hi Harold, Adding serviceability-dev for the serviceability related changes. Nit: "VM support for sealed classes" This RFR covers the VM, core-libs, serviceability and even some langtools tests. AFAICS only the javac changes are not included here so when and where will they be reviewed and under what bug id? Ideally there will be a single JBS issue for "Implementation of JEP 360: Sealed types". It's okay to break up the RFRs across different areas, but it should be done under one bug id. Overall this looks good. I've looked at all files and mainly have some style nits in various places. But there are some more significant items below. On 14/05/2020 7:09 am, Harold Seigel wrote: > Hi, > > Please review this patch for JVM and Core-libs support for the JEP 360 > Sealed Classes preview feature.? Code changes include the following: > > ?* Processing of the new PermittedSubclasses attribute to enforce that > ?? a class or interface, whose super is a sealed class or interface, > ?? must be listed in the super's PermittedSubclasses attribute. > ?* Disallow redefinition of a sealed class or interface if its > ?? redefinition would change its PermittedSubclasses attribute. > ?* Support API's to determine if a class or interface is sealed and, if > ?? it's sealed, return a list of its permitted subclasses. > ?* asm support for the PermittedSubclasses attribute I assume Remi is providing the upstream support in ASM? :) But also see below ... > > Open Webrev: > http://cr.openjdk.java.net/~vromero/8225056/webrev.00/index.html make/data/jdwp/jdwp.spec There needs to be a sub-task and associated CSR request for this JDWP spec update. I couldn't see this covered anywhere. --- src/hotspot/share/classfile/classFileParser.cpp 3215 u2 ClassFileParser::parse_classfile_permitted_subclasses_attribute(const ClassFileStream* const cfs, 3216 const u1* const permitted_subclasses_attribute_start, 3217 TRAPS) { Indention on L3216/17 needs fixing after the copy'n'edit. 3515 return _major_version == JVM_CLASSFILE_MAJOR_VERSION && 3516 _minor_version == JAVA_PREVIEW_MINOR_VERSION && 3517 Arguments::enable_preview(); Too much indentation on L3516/17 3790 // Check for PermittedSubclasses tag That comment (copied from my nestmates code :) is in the wrong place. It needs to be before 3788 if (tag == vmSymbols::tag_permitted_subclasses()) { Minor nit: I would suggest checking parsed_permitted_subclasses_attribute before checking ACC_FINAL. 3876 if (parsed_permitted_subclasses_attribute) { 3877 const u2 num_of_subclasses = parse_classfile_permitted_subclasses_attribute( 3878 cfs, 3879 permitted_subclasses_attribute_start, 3880 CHECK); Although it looks odd the preceding, similarly shaped, sections all indent to the same absolute position. Can you make L3878/78/80 match please. 3882 guarantee_property( 3883 permitted_subclasses_attribute_length == 3884 sizeof(num_of_subclasses) + sizeof(u2) * num_of_subclasses, 3885 "Wrong PermittedSubclasses attribute length in class file %s", CHECK); Nits: please reformat as: 3882 guarantee_property( 3883 permitted_subclasses_attribute_length == sizeof(num_of_subclasses) + sizeof(u2) * num_of_subclasses, 3885 "Wrong PermittedSubclasses attribute length in class file %s", CHECK); It would also look slightly better if you shortened the name of the num_of_subclasses variable. --- src/hotspot/share/classfile/classFileParser.hpp + u2 parse_classfile_permitted_subclasses_attribute(const ClassFileStream* const cfs, + const u1* const permitted_subclasses_attribute_start, + TRAPS); Please fix indentation after copy'n'edit. --- src/hotspot/share/oops/instanceKlass.cpp 247 if (classloader1 != classloader2) { I'm not clear what rule this is verifying. The same module check follows this one. The rule is that the subclass must be accessible to the superclass implying: 1. same named module (regardless of class access modifiers); or 2. (implicitly in un-named module) same package if subclass not public; or 3. public subclass Having the same classloader implies same package, but that alone doesn't address 2 or 3. So this doesn't conform to proposed JVMS rules. 264 if (_constants->tag_at(cp_index).is_klass()) { 265 Klass* k2 = _constants->klass_at(cp_index, CHECK_false); You've copied this code from the nestmember checks but your changes don't quite make sense to me. If we have already checked is_klass() then klass_at() cannot lead to any exceptions. 272 if (name == k->name()) { 273 log_trace(class, sealed)("- Found it at permitted_subclasses[%d] => cp[%d]", i, cp_index); 274 return true; I was wondering why you don't resolve the cp entry when you find the name matches, as we do for nest members, but realized that unlike the nest membership check, which can happen many times for a given class, this permitted subclass check can only happen once per class. As you don't actually resolve here, and given that the earlier check cannot throw exceptions, it follows that the entire method never results in any exceptions and so callers should not be using the CHECK macro. --- src/hotspot/share/oops/method.cpp I don't understand how knowing the class is sealed allows you to infer that a non-final method is actually final ?? --- src/hotspot/share/prims/jvm.cpp It would be simpler (and cheaper) if the Java side of this ensures it doesn't call into the VM with an array or primitive class. --- src/hotspot/share/prims/jvmti.xml The JVM TI spec changes also need to be covered by a CSR request. --- src/hotspot/share/prims/jvmtiRedefineClasses.cpp We should file a RFE to refactor the logic that checks that an attribute consisting of a list of classes has not changed. :) Aside: I spotted a bug in the nest member code (missing NULL check!) thanks to your change :) --- src/java.base/share/classes/java/lang/Class.java There needs to be a CSR request for these changes. + * Returns an array containing {@code ClassDesc} objects representing all the + * permitted subclasses of this {@linkplain Class} if it is sealed. Returns an empty array if this + * {@linkplain Class} is not sealed. should add "or this class represents an array or primitive type" (using the standard wording for such cases). + * @throws IllegalArgumentException if a class descriptor is not in the correct format IllegalArgumentException is not an appropriate exception to use as this method takes no arguments. If the class descriptor is not valid and it comes from the VM then I think we have a problem with how the VM validates class descriptors. Any IAE from ClassDesc.of should be caught and converted to a more suitable exception type - preferably InternalError if the VM should always return valid strings. + public ClassDesc[] getPermittedSubclasses() { As mentioned for jvm.cpp this Java code should do the isArray() and isPrimitive() check before calling the VM. + String[] descriptors = getPermittedSubclasses0(); Nit: what you get from the VM are not descriptors, just name strings in internal form. This wouldn't really matter except it then looks strange to call ClassDesc.of(...) instead of ClassDesc.ofDescriptor(...). + if (descriptors == null The VM never returns null. + return getPermittedSubclasses().length != 0; It's grossly inefficient to create the ClassDesc array and then throw it away IMO. The result should be cached either in a field of Class or in the ReflectionData of the class. --- src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java ! // - The offset of the PermittedSubclasses attribute, or 0 int permittedSubtypesOffset = 0; Obviously ASM already has some prelim support for sealed classes, but now that the attribute has been renamed that should also flow through to the ASM code ie the variable, not just the comment. Ditto for ClassWriter.java and its fields. --- src/java.base/share/native/libjava/Class.c {"isRecord0", "()Z", (void *)&JVM_IsRecord}, + {"getPermittedSubclasses0", "()[" STR, (void *)&JVM_GetPermittedSubclasses}, please align (void --- src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java There needs to be a CSR for these changes too. --- test/langtools/tools/javac/processing/model/TestSourceVersion.java ! // Assume "record" and "sealed" will be restricted keywords. ! "record", "sealed"); What about the non-sealed keyword defined in the JEP? --- In the tests you don't need to explicitly include sun.hotspot.WhiteBox$WhiteBoxPermission on the ClassFileInstaller invocation. (previous RFE's have been removing existing occurrences after the CFI was fixed to handle it internally). Please ensure all new tests have an @bug 8225056 (or whatever the actual JBS issue will be) All test classes (and thus files) should be named in camel-case i.e. C1 not c1, C2 not c2, SuperClass not superClass etc. test/hotspot/jtreg/runtime/modules/sealedP1/superClass.jcod test/hotspot/jtreg/runtime/sealedClasses/Pkg/sealedInterface.jcod Please add comments clarifying why these must be jcod files. --- That's it from me. Thanks, David ----- > JBS bug: https://bugs.openjdk.java.net/browse/JDK-8225056 > > Java Language Spec changes: > http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html > > > JVM Spec changes: > http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jvms.html > > > JEP 360: https://bugs.openjdk.java.net/browse/JDK-8227043 > > JVM CSR: https://bugs.openjdk.java.net/browse/JDK-8242578 > > Changes to javac and other language tools will be reviewed separately. > > Thanks, Harold > > From forax at univ-mlv.fr Tue May 19 08:41:54 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 19 May 2020 10:41:54 +0200 (CEST) Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> Message-ID: <1968935181.766173.1589877714107.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "David Holmes" > ?: "Harold David Seigel" , "hotspot-runtime-dev" , > "amber-dev" , "core-libs-dev" , "serviceability-dev" > > Envoy?: Mardi 19 Mai 2020 07:26:38 > Objet: Re: RFR: JDK-8225056 VM support for sealed classes > Hi Harold, > > Adding serviceability-dev for the serviceability related changes. > > Nit: "VM support for sealed classes" > > This RFR covers the VM, core-libs, serviceability and even some > langtools tests. AFAICS only the javac changes are not included here so > when and where will they be reviewed and under what bug id? Ideally > there will be a single JBS issue for "Implementation of JEP 360: Sealed > types". It's okay to break up the RFRs across different areas, but it > should be done under one bug id. > > Overall this looks good. I've looked at all files and mainly have some > style nits in various places. But there are some more significant items > below. > > On 14/05/2020 7:09 am, Harold Seigel wrote: >> Hi, >> >> Please review this patch for JVM and Core-libs support for the JEP 360 >> Sealed Classes preview feature.? Code changes include the following: >> >> ?* Processing of the new PermittedSubclasses attribute to enforce that >> ?? a class or interface, whose super is a sealed class or interface, >> ?? must be listed in the super's PermittedSubclasses attribute. >> ?* Disallow redefinition of a sealed class or interface if its >> ?? redefinition would change its PermittedSubclasses attribute. >> ?* Support API's to determine if a class or interface is sealed and, if >> ?? it's sealed, return a list of its permitted subclasses. >> ?* asm support for the PermittedSubclasses attribute > > I assume Remi is providing the upstream support in ASM? :) But also see > below ... Currently the version of ASM used JDK already supports sealed classes but with the attribute named PermittedSubtypes instead of PermittedSubclasses. This patch renames the attribute which is the right thing to do. Then when JDK 15 will be released, we will release ASM 9 with full support of PermittedSubclasses, with the right method names, docs, etc, that will be then integrated in JDK 16. So with my ASM hat, the changes to the 3 ASM classes are good. R?mi From claes.redestad at oracle.com Tue May 19 10:36:12 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 19 May 2020 12:36:12 +0200 Subject: RFR: 8215401: Add isEmpty default method to CharSequence In-Reply-To: References: <73809ad1-e317-ade2-7fec-f356f38d005c@oracle.com> Message-ID: <600f4e7e-1fec-8a46-e1c5-3e94d0728a60@oracle.com> Good eye - I believe I intended this to be a {@code} block. Updated in- place. /Claes On 2020-05-19 02:31, Jonathan Gibbons wrote: > You might want to check the /generated/ API docs. It doesn't look like > the first {@link} will do what you might be expecting. > > -- Jon > > On 5/18/20 1:48 PM, Claes Redestad wrote: >> Hi, >> >> let's add an isEmpty default method to CharSequence! >> >> Webrev: http://cr.openjdk.java.net/~redestad/8215401/open.00/ >> RFE:??? https://bugs.openjdk.java.net/browse/JDK-8215401 >> CSR:??? https://bugs.openjdk.java.net/browse/JDK-8215402 >> >> Testing: tier1-3 >> >> /Claes From claes.redestad at oracle.com Tue May 19 10:37:18 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 19 May 2020 12:37:18 +0200 Subject: RFR: 8215401: Add isEmpty default method to CharSequence In-Reply-To: References: <73809ad1-e317-ade2-7fec-f356f38d005c@oracle.com> Message-ID: <9765e3e1-5841-e93e-77b1-2030b894e660@oracle.com> Hi Roger, sure, added Emptiness.java with a few sanity tests. /Claes On 2020-05-19 00:29, Roger Riggs wrote: > Hi Claes, > > Though it does not look like it could be any simpler, there should > probably be a test. > Checking consistency with the existing implementations of > CharSequence.length() > and a custom subtype. > > Thanks, Roger > > > On 5/18/20 4:48 PM, Claes Redestad wrote: >> Hi, >> >> let's add an isEmpty default method to CharSequence! >> >> Webrev: http://cr.openjdk.java.net/~redestad/8215401/open.00/ >> RFE:??? https://bugs.openjdk.java.net/browse/JDK-8215401 >> CSR:??? https://bugs.openjdk.java.net/browse/JDK-8215402 >> >> Testing: tier1-3 >> >> /Claes > From Yang.Zhang at arm.com Tue May 19 10:55:09 2020 From: Yang.Zhang at arm.com (Yang Zhang) Date: Tue, 19 May 2020 10:55:09 +0000 Subject: RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes Message-ID: Hi, Following up on review requests of API [0], Java implementation and test [1], General Hotspot changes[2] for Vector API and x86 backend changes [3]. Here's a request for review of AArch64 backend changes required for supporting the Vector API: JEP: https://openjdk.java.net/jeps/338 JBS: https://bugs.openjdk.java.net/browse/JDK-8223347 Webrev: http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.01/ Complete implementation resides in vector-unstable branch of panama/dev repository [4]. Looking forward to your feedback. Best Regards, Yang [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065587.html [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037798.html [3] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037801.html [4] https://openjdk.java.net/projects/panama/ $ hg clone http://hg.openjdk.java.net/panama/dev/ -b vector-unstable From christoph.dreis at freenet.de Tue May 19 12:22:42 2020 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Tue, 19 May 2020 14:22:42 +0200 Subject: Optimize (Linked-)HashMap lookup when backing array is null Message-ID: <311BBE19-C22B-4BA4-B9EE-267B6811841E@freenet.de> Hi, similar to JDK-8244960[1] that I reported last week, I noticed that HashMap & LinkedHashMap could benefit from a similar improvement. I used the following benchmark again to validate the results: @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class MyBenchmark { @State(Scope.Benchmark) public static class ThreadState { private Map map = new HashMap<>(); private TestKey key = new TestKey(Collections.singleton("test")); /* public ThreadState() { this.map.put(key, "test"); } */ } @Benchmark public String test(ThreadState threadState) { return threadState.map.get(threadState.key); } } Where TestKey is the following: public class TestKey { private final Set params; public TestKey(Set params) { this.params = params; } @Override public int hashCode() { return this.params.hashCode(); } } Applying the (hopefully) attached patch I see the following results: Patched Benchmark Mode Cnt Score Error Units MyBenchmark.test avgt 10 2,717 ? 0,247 ns/op MyBenchmark.test:?gc.alloc.rate avgt 10 ? 10?? MB/sec MyBenchmark.test:?gc.alloc.rate.norm avgt 10 ? 10?? B/op MyBenchmark.test:?gc.count avgt 10 ? 0 counts Old Benchmark Mode Cnt Score Error Units MyBenchmark.test avgt 10 3,713 ? 0,091 ns/op MyBenchmark.test:?gc.alloc.rate avgt 10 ? 10?? MB/sec MyBenchmark.test:?gc.alloc.rate.norm avgt 10 ? 10?? B/op MyBenchmark.test:?gc.count avgt 10 ? 0 counts The case when the map is already filled didn't seem to show any regression. Unfortunately, there is the caveat of potentially executing the hash() method twice in computeIfPresent if the remapping function returns null and the node is removed. I don't know if this case is really common (or more common than an empty map), but I should mention it for completeness reasons. One common case for the above scenario is the following: I noticed that in a typical Spring-Boot app Manifest.getTrustedAttributes or Manifest.getEntries() is actually empty. Since this is used during class loading it is executed relatively frequent. I could imagine other use-cases where this might be benefitial for startup scenarios. In case you think this is worthwhile, I would highly appreciate a sponsoring of the attached patch. Cheers, Christoph [1] https://bugs.openjdk.java.net/browse/JDK-8244960 -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hashmap-patch.txt URL: From jan.lahoda at oracle.com Tue May 19 12:44:34 2020 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 19 May 2020 14:44:34 +0200 Subject: RFR: JDK-8227046: compiler implementation for sealed classes, JDK-8227047: Javadoc for sealed types and JDK-8227044: javax.lang.model for sealed classes In-Reply-To: <3bd27bea-b8a3-88a2-5536-ea9610749ce4@oracle.com> References: <3bd27bea-b8a3-88a2-5536-ea9610749ce4@oracle.com> Message-ID: Hi Vicente, javac changes look overall OK to me. A few comments: -the handling of non-sealed in JavacParser is fairly good, even though I wonder if handling it in the tokenizer would not be better. If I read the specification correctly, "non-sealed" is specified as a keyword, so the tokenizer would seem like a proper place to recognize it (when preview is enabled, etc.). So, I think this: class NonSealed { { int non = 0; int sealed = 0; int c = non-sealed; } } should not compile, but it does. In any case, not sure if there are tests for broken/strange non-sealed, like "non -sealed", "non/**/-sealed", "non\u002Dsealed". Also, the checks for 'non', '-', 'sealed' tokens is duplicated twice, it would be nicer to have this slightly complex code only once. -parsing of permitted classes allows parameterized types, while it, I guess, should not. I.e. it appears javac compiles this without producing compile-time errors: public sealed class Sealed1 permits I { } final class I extends Sealed1 {} -in ClassReader: new AttributeReader(names.PermittedSubclasses, V58, CLASS_ATTRIBUTE) that should use V59? -I appreciate the error recovery for using "sealed/non-sealed" for local classes, but I wonder if there's something we could do when "sealed" is used without --enable-preview (for local and non-local classes/interfaces). Maybe if "sealed" is followed by another modifier, '@', 'class' or 'interface', we can produce a better errors? (But we can work on that later.) -regarding TypeElement#getPermittedSubclasses: it currently returns List; I wonder if returning List would be better? -not sure if I prefer the "invalid permits clause" errors like: --- DuplicateTypeInPermits.java:30: error: invalid permits clause sealed class Sealed permits Sub, Sub {} ^ (must not contain duplicates: Sub) --- something like: --- DuplicateTypeInPermits.java:30: error: repeated permitted type sealed class Sealed permits Sub, Sub {} ^ --- might work as well. -nit: ClassTree#getPermitsClause() could use List.of(), instead of Collections.emptyList(); Thanks, Jan On 19. 05. 20 0:42, Vicente Romero wrote: > Hi, > > Please review this patch for the compiler, javadoc and javax.lang.model > support for the JEP 360 Sealed Classes (Preview). The changes are > provided at [1], which implements the latest JLS for sealed types [2]. > The patch also include the needed changes to javadoc and > javax.lang.model to support sealed types. The CSR witht the changes in > the javax.lang.model spec is at [3]. The sealed types JEP is accessible > at [4]. There is an ongoing review for the VM and core-libs code of > sealed types [5] and that code hasn't been included in this webrev, > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8227046/webrev.00/ > [2] > http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html > > [3] https://bugs.openjdk.java.net/browse/JDK-8244367 > [4] https://openjdk.java.net/jeps/360 > [5] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066440.html From claes.redestad at oracle.com Tue May 19 12:47:38 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 19 May 2020 14:47:38 +0200 Subject: Optimize (Linked-)HashMap lookup when backing array is null In-Reply-To: <311BBE19-C22B-4BA4-B9EE-267B6811841E@freenet.de> References: <311BBE19-C22B-4BA4-B9EE-267B6811841E@freenet.de> Message-ID: Hi Christoph, unlike CHM, HashMap and LinkedHashMap have constant-time size/isEmpty accessors - could this be used to simplify your patch? It's easy to get heavily biased results in microbenchmarks when all you do is repeatedly calling down one path. That is, JIT might speculatively assume all HashMaps are empty or non-empty if all you do is call a method on only empty or non-empty maps respectively. So I'd like to see some analysis on microbenchmark that uses a mix of such maps in the same @Benchmark /Claes On 2020-05-19 14:22, Christoph Dreis wrote: > Hi, > > similar to JDK-8244960[1] that I reported last week, I noticed that HashMap & LinkedHashMap could benefit from a similar improvement. > > I used the following benchmark again to validate the results: > > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class MyBenchmark { > > @State(Scope.Benchmark) > public static class ThreadState { > > private Map map = new HashMap<>(); > private TestKey key = new TestKey(Collections.singleton("test")); > > /* > public ThreadState() { > this.map.put(key, "test"); > } > */ > } > > @Benchmark > public String test(ThreadState threadState) { > return threadState.map.get(threadState.key); > } > > } > > Where TestKey is the following: > > public class TestKey { > > private final Set params; > > public TestKey(Set params) { > this.params = params; > } > > @Override > public int hashCode() { > return this.params.hashCode(); > } > > } > > Applying the (hopefully) attached patch I see the following results: > > Patched > Benchmark Mode Cnt Score Error Units > MyBenchmark.test avgt 10 2,717 ? 0,247 ns/op > MyBenchmark.test:?gc.alloc.rate avgt 10 ? 10?? MB/sec > MyBenchmark.test:?gc.alloc.rate.norm avgt 10 ? 10?? B/op > MyBenchmark.test:?gc.count avgt 10 ? 0 counts > > Old > Benchmark Mode Cnt Score Error Units > MyBenchmark.test avgt 10 3,713 ? 0,091 ns/op > MyBenchmark.test:?gc.alloc.rate avgt 10 ? 10?? MB/sec > MyBenchmark.test:?gc.alloc.rate.norm avgt 10 ? 10?? B/op > MyBenchmark.test:?gc.count avgt 10 ? 0 counts > > The case when the map is already filled didn't seem to show any regression. > > Unfortunately, there is the caveat of potentially executing the hash() method twice in computeIfPresent if the remapping function returns null and the node is removed. I don't know if this case is really common (or more common than an empty map), but I should mention it for completeness reasons. > > One common case for the above scenario is the following: I noticed that in a typical Spring-Boot app Manifest.getTrustedAttributes or Manifest.getEntries() is actually empty. Since this is used during class loading it is executed relatively frequent. I could imagine other use-cases where this might be benefitial for startup scenarios. > > In case you think this is worthwhile, I would highly appreciate a sponsoring of the attached patch. > > Cheers, > Christoph > > > [1] https://bugs.openjdk.java.net/browse/JDK-8244960 > > From gavin.bierman at oracle.com Tue May 19 12:48:37 2020 From: gavin.bierman at oracle.com (Gavin Bierman) Date: Tue, 19 May 2020 13:48:37 +0100 Subject: RFR: JDK-8227046: compiler implementation for sealed classes, JDK-8227047: Javadoc for sealed types and JDK-8227044: javax.lang.model for sealed classes In-Reply-To: References: <3bd27bea-b8a3-88a2-5536-ea9610749ce4@oracle.com> Message-ID: <00819242-4AC8-43EA-8E1C-49EF47421627@oracle.com> > On 19 May 2020, at 13:44, Jan Lahoda wrote: > > Hi Vicente, > > javac changes look overall OK to me. > > A few comments: > -the handling of non-sealed in JavacParser is fairly good, even though I wonder if handling it in the tokenizer would not be better. If I read the specification correctly, "non-sealed" is specified as a keyword, so the tokenizer would seem like a proper place to recognize it (when preview is enabled, etc.). So, I think this: > class NonSealed { > { > int non = 0; > int sealed = 0; > int c = non-sealed; > } > } > > should not compile, but it does. In any case, not sure if there are tests for broken/strange non-sealed, like "non -sealed", "non/**/-sealed", "non\u002Dsealed". That?s actually a bug in the spec (to be filed). I believe now the intent is to treat non-sealed as a contextual keyword, which is what the compiler does. Gavin From christoph.dreis at freenet.de Tue May 19 13:15:06 2020 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Tue, 19 May 2020 15:15:06 +0200 Subject: Optimize (Linked-)HashMap lookup when backing array is null In-Reply-To: References: <311BBE19-C22B-4BA4-B9EE-267B6811841E@freenet.de> Message-ID: Hi Claes, > unlike CHM, HashMap and LinkedHashMap have constant-time size/isEmpty > accessors - could this be used to simplify your patch? I was wondering about that during implementation, but simply took the path I already chose for the CHM. > So I'd like to see some analysis on microbenchmark that uses a mix of such maps in the same I see the following results when I introduce a counter and have it look like that: @Benchmark public String test(ThreadState threadState) { if (threadState.counter++ % 2 == 0) { return threadState.emptyMap.get(threadState.key); } return threadState.map.get(threadState.key); } Old Benchmark Mode Cnt Score Error Units MyBenchmark.test avgt 10 4,916 ? 0,106 ns/op MyBenchmark.test:?gc.alloc.rate avgt 10 ? 10?? MB/sec MyBenchmark.test:?gc.alloc.rate.norm avgt 10 ? 10?? B/op MyBenchmark.test:?gc.count avgt 10 ? 0 counts New patched MyBenchmark.test avgt 10 4,493 ? 0,169 ns/op MyBenchmark.test:?gc.alloc.rate avgt 10 ? 10?? MB/sec MyBenchmark.test:?gc.alloc.rate.norm avgt 10 ? 10?? B/op MyBenchmark.test:?gc.count avgt 10 ? 0 counts Was that what you had in mind? Cheers, Christoph ?Am 19.05.20, 14:47 schrieb "Claes Redestad" : Hi Christoph, unlike CHM, HashMap and LinkedHashMap have constant-time size/isEmpty accessors - could this be used to simplify your patch? It's easy to get heavily biased results in microbenchmarks when all you do is repeatedly calling down one path. That is, JIT might speculatively assume all HashMaps are empty or non-empty if all you do is call a method on only empty or non-empty maps respectively. So I'd like to see some analysis on microbenchmark that uses a mix of such maps in the same @Benchmark /Claes On 2020-05-19 14:22, Christoph Dreis wrote: > Hi, > > similar to JDK-8244960[1] that I reported last week, I noticed that HashMap & LinkedHashMap could benefit from a similar improvement. > > I used the following benchmark again to validate the results: > > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class MyBenchmark { > > @State(Scope.Benchmark) > public static class ThreadState { > > private Map map = new HashMap<>(); > private TestKey key = new TestKey(Collections.singleton("test")); > > /* > public ThreadState() { > this.map.put(key, "test"); > } > */ > } > > @Benchmark > public String test(ThreadState threadState) { > return threadState.map.get(threadState.key); > } > > } > > Where TestKey is the following: > > public class TestKey { > > private final Set params; > > public TestKey(Set params) { > this.params = params; > } > > @Override > public int hashCode() { > return this.params.hashCode(); > } > > } > > Applying the (hopefully) attached patch I see the following results: > > Patched > Benchmark Mode Cnt Score Error Units > MyBenchmark.test avgt 10 2,717 ? 0,247 ns/op > MyBenchmark.test:?gc.alloc.rate avgt 10 ? 10?? MB/sec > MyBenchmark.test:?gc.alloc.rate.norm avgt 10 ? 10?? B/op > MyBenchmark.test:?gc.count avgt 10 ? 0 counts > > Old > Benchmark Mode Cnt Score Error Units > MyBenchmark.test avgt 10 3,713 ? 0,091 ns/op > MyBenchmark.test:?gc.alloc.rate avgt 10 ? 10?? MB/sec > MyBenchmark.test:?gc.alloc.rate.norm avgt 10 ? 10?? B/op > MyBenchmark.test:?gc.count avgt 10 ? 0 counts > > The case when the map is already filled didn't seem to show any regression. > > Unfortunately, there is the caveat of potentially executing the hash() method twice in computeIfPresent if the remapping function returns null and the node is removed. I don't know if this case is really common (or more common than an empty map), but I should mention it for completeness reasons. > > One common case for the above scenario is the following: I noticed that in a typical Spring-Boot app Manifest.getTrustedAttributes or Manifest.getEntries() is actually empty. Since this is used during class loading it is executed relatively frequent. I could imagine other use-cases where this might be benefitial for startup scenarios. > > In case you think this is worthwhile, I would highly appreciate a sponsoring of the attached patch. > > Cheers, > Christoph > > > [1] https://bugs.openjdk.java.net/browse/JDK-8244960 > > From claes.redestad at oracle.com Tue May 19 13:31:42 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 19 May 2020 15:31:42 +0200 Subject: Optimize (Linked-)HashMap lookup when backing array is null In-Reply-To: References: <311BBE19-C22B-4BA4-B9EE-267B6811841E@freenet.de> Message-ID: <39881274-1311-c67d-b7a5-9e6ab07e812a@oracle.com> Hi, On 2020-05-19 15:15, Christoph Dreis wrote: > Hi Claes, > >> unlike CHM, HashMap and LinkedHashMap have constant-time size/isEmpty >> accessors - could this be used to simplify your patch? > > I was wondering about that during implementation, but simply took the path I already chose for the CHM. I think we should try to keep any changes here as simple as possible. > >> So I'd like to see some analysis on microbenchmark that uses a mix of such maps in the same > > I see the following results when I introduce a counter and have it look like that: > > @Benchmark > public String test(ThreadState threadState) { > if (threadState.counter++ % 2 == 0) { > return threadState.emptyMap.get(threadState.key); > } > return threadState.map.get(threadState.key); > } > > Old > Benchmark Mode Cnt Score Error Units > MyBenchmark.test avgt 10 4,916 ? 0,106 ns/op > MyBenchmark.test:?gc.alloc.rate avgt 10 ? 10?? MB/sec > MyBenchmark.test:?gc.alloc.rate.norm avgt 10 ? 10?? B/op > MyBenchmark.test:?gc.count avgt 10 ? 0 counts > > New patched > MyBenchmark.test avgt 10 4,493 ? 0,169 ns/op > MyBenchmark.test:?gc.alloc.rate avgt 10 ? 10?? MB/sec > MyBenchmark.test:?gc.alloc.rate.norm avgt 10 ? 10?? B/op > MyBenchmark.test:?gc.count avgt 10 ? 0 counts > > Was that what you had in mind? Something like that, yes. Thanks! /Claes > > Cheers, > Christoph > > ?Am 19.05.20, 14:47 schrieb "Claes Redestad" : > > Hi Christoph, > > unlike CHM, HashMap and LinkedHashMap have constant-time size/isEmpty > accessors - could this be used to simplify your patch? > > It's easy to get heavily biased results in microbenchmarks when all you > do is repeatedly calling down one path. That is, JIT might speculatively > assume all HashMaps are empty or non-empty if all you do is call a > method on only empty or non-empty maps respectively. So I'd like to see > some analysis on microbenchmark that uses a mix of such maps in the same > @Benchmark > > /Claes > > On 2020-05-19 14:22, Christoph Dreis wrote: > > Hi, > > > > similar to JDK-8244960[1] that I reported last week, I noticed that HashMap & LinkedHashMap could benefit from a similar improvement. > > > > I used the following benchmark again to validate the results: > > > > > > @BenchmarkMode(Mode.AverageTime) > > @OutputTimeUnit(TimeUnit.NANOSECONDS) > > public class MyBenchmark { > > > > @State(Scope.Benchmark) > > public static class ThreadState { > > > > private Map map = new HashMap<>(); > > private TestKey key = new TestKey(Collections.singleton("test")); > > > > /* > > public ThreadState() { > > this.map.put(key, "test"); > > } > > */ > > } > > > > @Benchmark > > public String test(ThreadState threadState) { > > return threadState.map.get(threadState.key); > > } > > > > } > > > > Where TestKey is the following: > > > > public class TestKey { > > > > private final Set params; > > > > public TestKey(Set params) { > > this.params = params; > > } > > > > @Override > > public int hashCode() { > > return this.params.hashCode(); > > } > > > > } > > > > Applying the (hopefully) attached patch I see the following results: > > > > Patched > > Benchmark Mode Cnt Score Error Units > > MyBenchmark.test avgt 10 2,717 ? 0,247 ns/op > > MyBenchmark.test:?gc.alloc.rate avgt 10 ? 10?? MB/sec > > MyBenchmark.test:?gc.alloc.rate.norm avgt 10 ? 10?? B/op > > MyBenchmark.test:?gc.count avgt 10 ? 0 counts > > > > Old > > Benchmark Mode Cnt Score Error Units > > MyBenchmark.test avgt 10 3,713 ? 0,091 ns/op > > MyBenchmark.test:?gc.alloc.rate avgt 10 ? 10?? MB/sec > > MyBenchmark.test:?gc.alloc.rate.norm avgt 10 ? 10?? B/op > > MyBenchmark.test:?gc.count avgt 10 ? 0 counts > > > > The case when the map is already filled didn't seem to show any regression. > > > > Unfortunately, there is the caveat of potentially executing the hash() method twice in computeIfPresent if the remapping function returns null and the node is removed. I don't know if this case is really common (or more common than an empty map), but I should mention it for completeness reasons. > > > > One common case for the above scenario is the following: I noticed that in a typical Spring-Boot app Manifest.getTrustedAttributes or Manifest.getEntries() is actually empty. Since this is used during class loading it is executed relatively frequent. I could imagine other use-cases where this might be benefitial for startup scenarios. > > > > In case you think this is worthwhile, I would highly appreciate a sponsoring of the attached patch. > > > > Cheers, > > Christoph > > > > > > [1] https://bugs.openjdk.java.net/browse/JDK-8244960 > > > > > > From claes.redestad at oracle.com Tue May 19 13:59:38 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 19 May 2020 15:59:38 +0200 Subject: RFR: 8218173: exception during StringConcatFactory clinit breaks string concat with no fallback Message-ID: Hi, while hard to reproduce, it's possible to break the StringConcatFactory if trying to bootstrap a concatenation when the VM is in such a state that any allocation will throw an OOME By eagerly initializing the default strategy classes during bootstrap, while lazily initializing any method handles it uses in a way that allows retries later if that fail, we should minimize the risk of this, while ensuring we can recuperate. This loads and initializes a few more classes eagerly on bootstrap, but the initial startup cost of that sits well below 0.1ms (amortized on first concat bootstrap), which seems a reasonable cost for increased stability in constrained environments. I've not attempted a fix for the non-default strategies. Our intent is to remove these alternative strategies. Bug: https://bugs.openjdk.java.net/browse/JDK-8218173 Webrev: http://cr.openjdk.java.net/~redestad/8218173/open.00/ Testing: tier1-3 This might also resolve https://bugs.openjdk.java.net/browse/JDK-8218176 - so I included the removal of TestStressG1Humongous from ProblemList- graal.txt. I've run it a few times locally and in our CI without issue, but we probably need to enable it for while to determine if the intermittent issue is gone for good (or if we just move the issue somewhere else). Thanks! /Claes From james.laskey at oracle.com Tue May 19 14:05:48 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 19 May 2020 11:05:48 -0300 Subject: RFR: 8218173: exception during StringConcatFactory clinit breaks string concat with no fallback In-Reply-To: References: Message-ID: +1 > On May 19, 2020, at 10:59 AM, Claes Redestad wrote: > > Hi, > > while hard to reproduce, it's possible to break the StringConcatFactory > if trying to bootstrap a concatenation when the VM is in such a state > that any allocation will throw an OOME > > By eagerly initializing the default strategy classes during bootstrap, > while lazily initializing any method handles it uses in a way that > allows retries later if that fail, we should minimize the risk of this, > while ensuring we can recuperate. > > This loads and initializes a few more classes eagerly on bootstrap, but > the initial startup cost of that sits well below 0.1ms (amortized on > first concat bootstrap), which seems a reasonable cost for increased > stability in constrained environments. > > I've not attempted a fix for the non-default strategies. Our intent is > to remove these alternative strategies. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218173 > Webrev: http://cr.openjdk.java.net/~redestad/8218173/open.00/ > > Testing: tier1-3 > > This might also resolve https://bugs.openjdk.java.net/browse/JDK-8218176 > - so I included the removal of TestStressG1Humongous from ProblemList- > graal.txt. I've run it a few times locally and in our CI without issue, > but we probably need to enable it for while to determine if the > intermittent issue is gone for good (or if we just move the issue > somewhere else). > > Thanks! > > /Claes From claes.redestad at oracle.com Tue May 19 14:08:11 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 19 May 2020 16:08:11 +0200 Subject: RFR: 8218173: exception during StringConcatFactory clinit breaks string concat with no fallback In-Reply-To: References: Message-ID: <70f298af-cd65-f0b8-cc71-dd11c692781a@oracle.com> Thanks for reviewing, Jim! /Claes On 2020-05-19 16:05, Jim Laskey wrote: > +1 > > >> On May 19, 2020, at 10:59 AM, Claes Redestad wrote: >> >> Hi, >> >> while hard to reproduce, it's possible to break the StringConcatFactory >> if trying to bootstrap a concatenation when the VM is in such a state >> that any allocation will throw an OOME >> >> By eagerly initializing the default strategy classes during bootstrap, >> while lazily initializing any method handles it uses in a way that >> allows retries later if that fail, we should minimize the risk of this, >> while ensuring we can recuperate. >> >> This loads and initializes a few more classes eagerly on bootstrap, but >> the initial startup cost of that sits well below 0.1ms (amortized on >> first concat bootstrap), which seems a reasonable cost for increased >> stability in constrained environments. >> >> I've not attempted a fix for the non-default strategies. Our intent is >> to remove these alternative strategies. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8218173 >> Webrev: http://cr.openjdk.java.net/~redestad/8218173/open.00/ >> >> Testing: tier1-3 >> >> This might also resolve https://bugs.openjdk.java.net/browse/JDK-8218176 >> - so I included the removal of TestStressG1Humongous from ProblemList- >> graal.txt. I've run it a few times locally and in our CI without issue, >> but we probably need to enable it for while to determine if the >> intermittent issue is gone for good (or if we just move the issue >> somewhere else). >> >> Thanks! >> >> /Claes > From paul.sandoz at oracle.com Tue May 19 15:22:21 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 19 May 2020 08:22:21 -0700 Subject: RFR: 8218173: exception during StringConcatFactory clinit breaks string concat with no fallback In-Reply-To: References: Message-ID: <2F79B1DE-99DE-446E-82E4-15FD88073354@oracle.com> +1 Originally I thought this was a lost cause or too much effort given the edge case, but your prior fix and Peter?s nudging to ?lazy? static values made it more viable. I agree with not changing the other strategies. Let's remove ?em. Paul. > On May 19, 2020, at 6:59 AM, Claes Redestad wrote: > > Hi, > > while hard to reproduce, it's possible to break the StringConcatFactory > if trying to bootstrap a concatenation when the VM is in such a state > that any allocation will throw an OOME > > By eagerly initializing the default strategy classes during bootstrap, > while lazily initializing any method handles it uses in a way that > allows retries later if that fail, we should minimize the risk of this, > while ensuring we can recuperate. > > This loads and initializes a few more classes eagerly on bootstrap, but > the initial startup cost of that sits well below 0.1ms (amortized on > first concat bootstrap), which seems a reasonable cost for increased > stability in constrained environments. > > I've not attempted a fix for the non-default strategies. Our intent is > to remove these alternative strategies. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8218173 > Webrev: http://cr.openjdk.java.net/~redestad/8218173/open.00/ > > Testing: tier1-3 > > This might also resolve https://bugs.openjdk.java.net/browse/JDK-8218176 > - so I included the removal of TestStressG1Humongous from ProblemList- > graal.txt. I've run it a few times locally and in our CI without issue, > but we probably need to enable it for while to determine if the > intermittent issue is gone for good (or if we just move the issue > somewhere else). > > Thanks! > > /Claes From claes.redestad at oracle.com Tue May 19 15:33:17 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 19 May 2020 17:33:17 +0200 Subject: RFR: 8218173: exception during StringConcatFactory clinit breaks string concat with no fallback In-Reply-To: <2F79B1DE-99DE-446E-82E4-15FD88073354@oracle.com> References: <2F79B1DE-99DE-446E-82E4-15FD88073354@oracle.com> Message-ID: <9e062c17-e5ed-e36d-4a32-b03f6838b5ca@oracle.com> On 2020-05-19 17:22, Paul Sandoz wrote: > +1 Thanks! > > Originally I thought this was a lost cause or too much effort given the edge case, but your prior fix and Peter?s nudging to ?lazy? static values made it more viable. Yeah, I had written it off as a lost cause too until Peter nudged me back on track. /Claes > > I agree with not changing the other strategies. Let's remove ?em. > > Paul. > >> On May 19, 2020, at 6:59 AM, Claes Redestad wrote: >> >> Hi, >> >> while hard to reproduce, it's possible to break the StringConcatFactory >> if trying to bootstrap a concatenation when the VM is in such a state >> that any allocation will throw an OOME >> >> By eagerly initializing the default strategy classes during bootstrap, >> while lazily initializing any method handles it uses in a way that >> allows retries later if that fail, we should minimize the risk of this, >> while ensuring we can recuperate. >> >> This loads and initializes a few more classes eagerly on bootstrap, but >> the initial startup cost of that sits well below 0.1ms (amortized on >> first concat bootstrap), which seems a reasonable cost for increased >> stability in constrained environments. >> >> I've not attempted a fix for the non-default strategies. Our intent is >> to remove these alternative strategies. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8218173 >> Webrev: http://cr.openjdk.java.net/~redestad/8218173/open.00/ >> >> Testing: tier1-3 >> >> This might also resolve https://bugs.openjdk.java.net/browse/JDK-8218176 >> - so I included the removal of TestStressG1Humongous from ProblemList- >> graal.txt. I've run it a few times locally and in our CI without issue, >> but we probably need to enable it for while to determine if the >> intermittent issue is gone for good (or if we just move the issue >> somewhere else). >> >> Thanks! >> >> /Claes > From serguei.spitsyn at oracle.com Tue May 19 15:53:54 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 May 2020 08:53:54 -0700 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> Message-ID: Hi Harold, The Serviceability part including the tests looks good to me. I can file a JVMTI enhancement on the jvmtiRedefineClasses.cpp refactoring if you are okay with it. Thanks, Serguei On 5/18/20 22:26, David Holmes wrote: > Hi Harold, > > Adding serviceability-dev for the serviceability related changes. > > Nit: "VM support for sealed classes" > > This RFR covers the VM, core-libs, serviceability and even some > langtools tests. AFAICS only the javac changes are not included here > so when and where will they be reviewed and under what bug id? Ideally > there will be a single JBS issue for "Implementation of JEP 360: > Sealed types". It's okay to break up the RFRs across different areas, > but it should be done under one bug id. > > Overall this looks good. I've looked at all files and mainly have some > style nits in various places. But there are some more significant > items below. > > On 14/05/2020 7:09 am, Harold Seigel wrote: >> Hi, >> >> Please review this patch for JVM and Core-libs support for the JEP >> 360 Sealed Classes preview feature.? Code changes include the following: >> >> ??* Processing of the new PermittedSubclasses attribute to enforce that >> ??? a class or interface, whose super is a sealed class or interface, >> ??? must be listed in the super's PermittedSubclasses attribute. >> ??* Disallow redefinition of a sealed class or interface if its >> ??? redefinition would change its PermittedSubclasses attribute. >> ??* Support API's to determine if a class or interface is sealed and, if >> ??? it's sealed, return a list of its permitted subclasses. >> ??* asm support for the PermittedSubclasses attribute > > I assume Remi is providing the upstream support in ASM? :) But also > see below ... > >> >> Open Webrev: >> http://cr.openjdk.java.net/~vromero/8225056/webrev.00/index.html > > make/data/jdwp/jdwp.spec > > There needs to be a sub-task and associated CSR request for this JDWP > spec update. I couldn't see this covered anywhere. > > --- > > src/hotspot/share/classfile/classFileParser.cpp > > 3215 u2 > ClassFileParser::parse_classfile_permitted_subclasses_attribute(const > ClassFileStream* const cfs, > 3216 const u1* const permitted_subclasses_attribute_start, > 3217 TRAPS) { > > Indention on L3216/17 needs fixing after the copy'n'edit. > > 3515?? return _major_version == JVM_CLASSFILE_MAJOR_VERSION && > 3516????????????? _minor_version == JAVA_PREVIEW_MINOR_VERSION && > 3517????????????? Arguments::enable_preview(); > > Too much indentation on L3516/17 > > 3790???????????????? // Check for PermittedSubclasses tag > > That comment (copied from my nestmates code :) is in the wrong place. > It needs to be before > > 3788???????????? if (tag == vmSymbols::tag_permitted_subclasses()) { > > > Minor nit: I would suggest checking > parsed_permitted_subclasses_attribute before checking ACC_FINAL. > > 3876?? if (parsed_permitted_subclasses_attribute) { > 3877???? const u2 num_of_subclasses = > parse_classfile_permitted_subclasses_attribute( > 3878??????????????????????????????????? cfs, > 3879 permitted_subclasses_attribute_start, > 3880??????????????????????????????????? CHECK); > > Although it looks odd the preceding, similarly shaped, sections all > indent to the same absolute position. Can you make L3878/78/80 match > please. > > 3882?????? guarantee_property( > 3883???????? permitted_subclasses_attribute_length == > 3884?????????? sizeof(num_of_subclasses) + sizeof(u2) * > num_of_subclasses, > 3885???????? "Wrong PermittedSubclasses attribute length in class file > %s", CHECK); > > Nits: please reformat as: > > 3882?????? guarantee_property( > 3883???????? permitted_subclasses_attribute_length == > sizeof(num_of_subclasses) + sizeof(u2) * num_of_subclasses, > 3885???????? "Wrong PermittedSubclasses attribute length in class file > %s", CHECK); > > It would also look slightly better if you shortened the name of the > num_of_subclasses variable. > > --- > > src/hotspot/share/classfile/classFileParser.hpp > > +?? u2 parse_classfile_permitted_subclasses_attribute(const > ClassFileStream* const cfs, > +???????????????????????????????????????????? const u1* const > permitted_subclasses_attribute_start, > +???????????????????????????????????????????? TRAPS); > > Please fix indentation after copy'n'edit. > > --- > > src/hotspot/share/oops/instanceKlass.cpp > > ?247?? if (classloader1 != classloader2) { > > I'm not clear what rule this is verifying. The same module check > follows this one. The rule is that the subclass must be accessible to > the superclass implying: > 1. same named module (regardless of class access modifiers); or > 2. (implicitly in un-named module) same package if subclass not > public; or > 3. public subclass > > Having the same classloader implies same package, but that alone > doesn't address 2 or 3. So this doesn't conform to proposed JVMS rules. > > > ?264???? if (_constants->tag_at(cp_index).is_klass()) { > ?265?????? Klass* k2 = _constants->klass_at(cp_index, CHECK_false); > > You've copied this code from the nestmember checks but your changes > don't quite make sense to me. If we have already checked is_klass() > then klass_at() cannot lead to any exceptions. > > ?272?????? if (name == k->name()) { > ?273???????? log_trace(class, sealed)("- Found it at > permitted_subclasses[%d] => cp[%d]", i, cp_index); > ?274???????? return true; > > I was wondering why you don't resolve the cp entry when you find the > name matches, as we do for nest members, but realized that unlike the > nest membership check, which can happen many times for a given class, > this permitted subclass check can only happen once per class. As you > don't actually resolve here, and given that the earlier check cannot > throw exceptions, it follows that the entire method never results in > any exceptions and so callers should not be using the CHECK macro. > > --- > > src/hotspot/share/oops/method.cpp > > I don't understand how knowing the class is sealed allows you to infer > that a non-final method is actually final ?? > > --- > > ?src/hotspot/share/prims/jvm.cpp > > It would be simpler (and cheaper) if the Java side of this ensures it > doesn't call into the VM with an array or primitive class. > > --- > > ?src/hotspot/share/prims/jvmti.xml > > The JVM TI spec changes also need to be covered by a CSR request. > > --- > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp > > We should file a RFE to refactor the logic that checks that an > attribute consisting of a list of classes has not changed. :) > > Aside: I spotted a bug in the nest member code (missing NULL check!) > thanks to your change :) > > --- > > src/java.base/share/classes/java/lang/Class.java > > There needs to be a CSR request for these changes. > > +????? * Returns an array containing {@code ClassDesc} objects > representing all the > +????? * permitted subclasses of this {@linkplain Class} if it is > sealed. Returns an empty array if this > +????? * {@linkplain Class} is not sealed. > > should add "or this class represents an array or primitive type" > (using the standard wording for such cases). > > +????? * @throws IllegalArgumentException if a class descriptor is not > in the correct format > > IllegalArgumentException is not an appropriate exception to use as > this method takes no arguments. If the class descriptor is not valid > and it comes from the VM then I think we have a problem with how the > VM validates class descriptors. Any IAE from ClassDesc.of should be > caught and converted to a more suitable exception type - preferably > InternalError if the VM should always return valid strings. > > +???? public ClassDesc[] getPermittedSubclasses() { > > As mentioned for jvm.cpp this Java code should do the isArray() and > isPrimitive() check before calling the VM. > > +???????? String[] descriptors = getPermittedSubclasses0(); > > Nit: what you get from the VM are not descriptors, just name strings > in internal form. This wouldn't really matter except it then looks > strange to call ClassDesc.of(...) instead of ClassDesc.ofDescriptor(...). > > +???????? if (descriptors == null > > The VM never returns null. > > +???????? return getPermittedSubclasses().length != 0; > > It's grossly inefficient to create the ClassDesc array and then throw > it away IMO. The result should be cached either in a field of Class or > in the ReflectionData of the class. > > --- > > src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java > > > !???????? // - The offset of the PermittedSubclasses attribute, or 0 > ????????? int permittedSubtypesOffset = 0; > > Obviously ASM already has some prelim support for sealed classes, but > now that the attribute has been renamed that should also flow through > to the ASM code ie the variable, not just the comment. > > Ditto for ClassWriter.java and its fields. > > --- > > src/java.base/share/native/libjava/Class.c > > ????? {"isRecord0",??????????? "()Z",???????? (void *)&JVM_IsRecord}, > +???? {"getPermittedSubclasses0", "()[" STR,??? (void > *)&JVM_GetPermittedSubclasses}, > > please align (void > > --- > > src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java > > src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > > There needs to be a CSR for these changes too. > > --- > > test/langtools/tools/javac/processing/model/TestSourceVersion.java > > !??????????????????? // Assume "record" and "sealed" will be > restricted keywords. > !??????????????????? "record", "sealed"); > > What about the non-sealed keyword defined in the JEP? > > --- > > In the tests you don't need to explicitly include > sun.hotspot.WhiteBox$WhiteBoxPermission on the ClassFileInstaller > invocation. (previous RFE's have been removing existing occurrences > after the CFI was fixed to handle it internally). > > Please ensure all new tests have an @bug 8225056 (or whatever the > actual JBS issue will be) > > All test classes (and thus files) should be named in camel-case i.e. > C1 not c1, C2 not c2, SuperClass not superClass etc. > > > test/hotspot/jtreg/runtime/modules/sealedP1/superClass.jcod > test/hotspot/jtreg/runtime/sealedClasses/Pkg/sealedInterface.jcod > > Please add comments clarifying why these must be jcod files. > > --- > > That's it from me. > > Thanks, > David > ----- > > > >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8225056 >> >> Java Language Spec changes: >> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html >> >> >> JVM Spec changes: >> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jvms.html >> >> >> JEP 360: https://bugs.openjdk.java.net/browse/JDK-8227043 >> >> JVM CSR: https://bugs.openjdk.java.net/browse/JDK-8242578 >> >> Changes to javac and other language tools will be reviewed separately. >> >> Thanks, Harold >> >> From harold.seigel at oracle.com Tue May 19 16:46:21 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Tue, 19 May 2020 12:46:21 -0400 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> Message-ID: I think that's a good idea. Thanks, Harold On 5/19/2020 11:49 AM, serguei.spitsyn at oracle.com wrote: > Hi Harold and David, > > Just one comment. > We could save on the CSR's for: > ? make/data/jdwp/jdwp.spec > || src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > || > src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java > > As we discussed with David, it could make sense to remove duplication > in the Serviceability class redefinition and retransformation specs. > I'd suggest something like this webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/redef-spec-dedup.1/ > > If the direction looks okay then I could file RFE+CSR (and post an RFR). > > Thanks, > Serguei > > > On 5/18/20 22:26, David Holmes wrote: >> Hi Harold, >> >> Adding serviceability-dev for the serviceability related changes. >> >> Nit: "VM support for sealed classes" >> >> This RFR covers the VM, core-libs, serviceability and even some >> langtools tests. AFAICS only the javac changes are not included here >> so when and where will they be reviewed and under what bug id? >> Ideally there will be a single JBS issue for "Implementation of JEP >> 360: Sealed types". It's okay to break up the RFRs across different >> areas, but it should be done under one bug id. >> >> Overall this looks good. I've looked at all files and mainly have >> some style nits in various places. But there are some more >> significant items below. >> >> On 14/05/2020 7:09 am, Harold Seigel wrote: >>> Hi, >>> >>> Please review this patch for JVM and Core-libs support for the JEP >>> 360 Sealed Classes preview feature.? Code changes include the >>> following: >>> >>> ??* Processing of the new PermittedSubclasses attribute to enforce that >>> ??? a class or interface, whose super is a sealed class or interface, >>> ??? must be listed in the super's PermittedSubclasses attribute. >>> ??* Disallow redefinition of a sealed class or interface if its >>> ??? redefinition would change its PermittedSubclasses attribute. >>> ??* Support API's to determine if a class or interface is sealed >>> and, if >>> ??? it's sealed, return a list of its permitted subclasses. >>> ??* asm support for the PermittedSubclasses attribute >> >> I assume Remi is providing the upstream support in ASM? :) But also >> see below ... >> >>> >>> Open Webrev: >>> http://cr.openjdk.java.net/~vromero/8225056/webrev.00/index.html >> >> make/data/jdwp/jdwp.spec >> >> There needs to be a sub-task and associated CSR request for this JDWP >> spec update. I couldn't see this covered anywhere. >> >> --- >> >> src/hotspot/share/classfile/classFileParser.cpp >> >> 3215 u2 >> ClassFileParser::parse_classfile_permitted_subclasses_attribute(const >> ClassFileStream* const cfs, >> 3216 const u1* const permitted_subclasses_attribute_start, >> 3217 TRAPS) { >> >> Indention on L3216/17 needs fixing after the copy'n'edit. >> >> 3515?? return _major_version == JVM_CLASSFILE_MAJOR_VERSION && >> 3516????????????? _minor_version == JAVA_PREVIEW_MINOR_VERSION && >> 3517????????????? Arguments::enable_preview(); >> >> Too much indentation on L3516/17 >> >> 3790???????????????? // Check for PermittedSubclasses tag >> >> That comment (copied from my nestmates code :) is in the wrong place. >> It needs to be before >> >> 3788???????????? if (tag == vmSymbols::tag_permitted_subclasses()) { >> >> >> Minor nit: I would suggest checking >> parsed_permitted_subclasses_attribute before checking ACC_FINAL. >> >> 3876?? if (parsed_permitted_subclasses_attribute) { >> 3877???? const u2 num_of_subclasses = >> parse_classfile_permitted_subclasses_attribute( >> 3878??????????????????????????????????? cfs, >> 3879 permitted_subclasses_attribute_start, >> 3880??????????????????????????????????? CHECK); >> >> Although it looks odd the preceding, similarly shaped, sections all >> indent to the same absolute position. Can you make L3878/78/80 match >> please. >> >> 3882?????? guarantee_property( >> 3883???????? permitted_subclasses_attribute_length == >> 3884?????????? sizeof(num_of_subclasses) + sizeof(u2) * >> num_of_subclasses, >> 3885???????? "Wrong PermittedSubclasses attribute length in class >> file %s", CHECK); >> >> Nits: please reformat as: >> >> 3882?????? guarantee_property( >> 3883???????? permitted_subclasses_attribute_length == >> sizeof(num_of_subclasses) + sizeof(u2) * num_of_subclasses, >> 3885???????? "Wrong PermittedSubclasses attribute length in class >> file %s", CHECK); >> >> It would also look slightly better if you shortened the name of the >> num_of_subclasses variable. >> >> --- >> >> src/hotspot/share/classfile/classFileParser.hpp >> >> +?? u2 parse_classfile_permitted_subclasses_attribute(const >> ClassFileStream* const cfs, >> +???????????????????????????????????????????? const u1* const >> permitted_subclasses_attribute_start, >> +???????????????????????????????????????????? TRAPS); >> >> Please fix indentation after copy'n'edit. >> >> --- >> >> src/hotspot/share/oops/instanceKlass.cpp >> >> ?247?? if (classloader1 != classloader2) { >> >> I'm not clear what rule this is verifying. The same module check >> follows this one. The rule is that the subclass must be accessible to >> the superclass implying: >> 1. same named module (regardless of class access modifiers); or >> 2. (implicitly in un-named module) same package if subclass not >> public; or >> 3. public subclass >> >> Having the same classloader implies same package, but that alone >> doesn't address 2 or 3. So this doesn't conform to proposed JVMS rules. >> >> >> ?264???? if (_constants->tag_at(cp_index).is_klass()) { >> ?265?????? Klass* k2 = _constants->klass_at(cp_index, CHECK_false); >> >> You've copied this code from the nestmember checks but your changes >> don't quite make sense to me. If we have already checked is_klass() >> then klass_at() cannot lead to any exceptions. >> >> ?272?????? if (name == k->name()) { >> ?273???????? log_trace(class, sealed)("- Found it at >> permitted_subclasses[%d] => cp[%d]", i, cp_index); >> ?274???????? return true; >> >> I was wondering why you don't resolve the cp entry when you find the >> name matches, as we do for nest members, but realized that unlike the >> nest membership check, which can happen many times for a given class, >> this permitted subclass check can only happen once per class. As you >> don't actually resolve here, and given that the earlier check cannot >> throw exceptions, it follows that the entire method never results in >> any exceptions and so callers should not be using the CHECK macro. >> >> --- >> >> src/hotspot/share/oops/method.cpp >> >> I don't understand how knowing the class is sealed allows you to >> infer that a non-final method is actually final ?? >> >> --- >> >> ?src/hotspot/share/prims/jvm.cpp >> >> It would be simpler (and cheaper) if the Java side of this ensures it >> doesn't call into the VM with an array or primitive class. >> >> --- >> >> ?src/hotspot/share/prims/jvmti.xml >> >> The JVM TI spec changes also need to be covered by a CSR request. >> >> --- >> >> src/hotspot/share/prims/jvmtiRedefineClasses.cpp >> >> We should file a RFE to refactor the logic that checks that an >> attribute consisting of a list of classes has not changed. :) >> >> Aside: I spotted a bug in the nest member code (missing NULL check!) >> thanks to your change :) >> >> --- >> >> src/java.base/share/classes/java/lang/Class.java >> >> There needs to be a CSR request for these changes. >> >> +????? * Returns an array containing {@code ClassDesc} objects >> representing all the >> +????? * permitted subclasses of this {@linkplain Class} if it is >> sealed. Returns an empty array if this >> +????? * {@linkplain Class} is not sealed. >> >> should add "or this class represents an array or primitive type" >> (using the standard wording for such cases). >> >> +????? * @throws IllegalArgumentException if a class descriptor is >> not in the correct format >> >> IllegalArgumentException is not an appropriate exception to use as >> this method takes no arguments. If the class descriptor is not valid >> and it comes from the VM then I think we have a problem with how the >> VM validates class descriptors. Any IAE from ClassDesc.of should be >> caught and converted to a more suitable exception type - preferably >> InternalError if the VM should always return valid strings. >> >> +???? public ClassDesc[] getPermittedSubclasses() { >> >> As mentioned for jvm.cpp this Java code should do the isArray() and >> isPrimitive() check before calling the VM. >> >> +???????? String[] descriptors = getPermittedSubclasses0(); >> >> Nit: what you get from the VM are not descriptors, just name strings >> in internal form. This wouldn't really matter except it then looks >> strange to call ClassDesc.of(...) instead of >> ClassDesc.ofDescriptor(...). >> >> +???????? if (descriptors == null >> >> The VM never returns null. >> >> +???????? return getPermittedSubclasses().length != 0; >> >> It's grossly inefficient to create the ClassDesc array and then throw >> it away IMO. The result should be cached either in a field of Class >> or in the ReflectionData of the class. >> >> --- >> >> src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java >> >> >> !???????? // - The offset of the PermittedSubclasses attribute, or 0 >> ????????? int permittedSubtypesOffset = 0; >> >> Obviously ASM already has some prelim support for sealed classes, but >> now that the attribute has been renamed that should also flow through >> to the ASM code ie the variable, not just the comment. >> >> Ditto for ClassWriter.java and its fields. >> >> --- >> >> src/java.base/share/native/libjava/Class.c >> >> ????? {"isRecord0",??????????? "()Z",???????? (void *)&JVM_IsRecord}, >> +???? {"getPermittedSubclasses0", "()[" STR,??? (void >> *)&JVM_GetPermittedSubclasses}, >> >> please align (void >> >> --- >> >> src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java >> >> src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java >> >> There needs to be a CSR for these changes too. >> >> --- >> >> test/langtools/tools/javac/processing/model/TestSourceVersion.java >> >> !??????????????????? // Assume "record" and "sealed" will be >> restricted keywords. >> !??????????????????? "record", "sealed"); >> >> What about the non-sealed keyword defined in the JEP? >> >> --- >> >> In the tests you don't need to explicitly include >> sun.hotspot.WhiteBox$WhiteBoxPermission on the ClassFileInstaller >> invocation. (previous RFE's have been removing existing occurrences >> after the CFI was fixed to handle it internally). >> >> Please ensure all new tests have an @bug 8225056 (or whatever the >> actual JBS issue will be) >> >> All test classes (and thus files) should be named in camel-case i.e. >> C1 not c1, C2 not c2, SuperClass not superClass etc. >> >> >> test/hotspot/jtreg/runtime/modules/sealedP1/superClass.jcod >> test/hotspot/jtreg/runtime/sealedClasses/Pkg/sealedInterface.jcod >> >> Please add comments clarifying why these must be jcod files. >> >> --- >> >> That's it from me. >> >> Thanks, >> David >> ----- >> >> >> >>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8225056 >>> >>> Java Language Spec changes: >>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html >>> >>> >>> JVM Spec changes: >>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jvms.html >>> >>> >>> JEP 360: https://bugs.openjdk.java.net/browse/JDK-8227043 >>> >>> JVM CSR: https://bugs.openjdk.java.net/browse/JDK-8242578 >>> >>> Changes to javac and other language tools will be reviewed separately. >>> >>> Thanks, Harold >>> >>> > From harold.seigel at oracle.com Tue May 19 16:46:45 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Tue, 19 May 2020 12:46:45 -0400 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> Message-ID: That sounds good! Thanks, Harold On 5/19/2020 11:53 AM, serguei.spitsyn at oracle.com wrote: > Hi Harold, > > The Serviceability part including the tests looks good to me. > I can file a JVMTI enhancement on the jvmtiRedefineClasses.cpp > refactoring if you are okay with it. > > Thanks, > Serguei > > > On 5/18/20 22:26, David Holmes wrote: >> Hi Harold, >> >> Adding serviceability-dev for the serviceability related changes. >> >> Nit: "VM support for sealed classes" >> >> This RFR covers the VM, core-libs, serviceability and even some >> langtools tests. AFAICS only the javac changes are not included here >> so when and where will they be reviewed and under what bug id? >> Ideally there will be a single JBS issue for "Implementation of JEP >> 360: Sealed types". It's okay to break up the RFRs across different >> areas, but it should be done under one bug id. >> >> Overall this looks good. I've looked at all files and mainly have >> some style nits in various places. But there are some more >> significant items below. >> >> On 14/05/2020 7:09 am, Harold Seigel wrote: >>> Hi, >>> >>> Please review this patch for JVM and Core-libs support for the JEP >>> 360 Sealed Classes preview feature.? Code changes include the >>> following: >>> >>> ??* Processing of the new PermittedSubclasses attribute to enforce that >>> ??? a class or interface, whose super is a sealed class or interface, >>> ??? must be listed in the super's PermittedSubclasses attribute. >>> ??* Disallow redefinition of a sealed class or interface if its >>> ??? redefinition would change its PermittedSubclasses attribute. >>> ??* Support API's to determine if a class or interface is sealed >>> and, if >>> ??? it's sealed, return a list of its permitted subclasses. >>> ??* asm support for the PermittedSubclasses attribute >> >> I assume Remi is providing the upstream support in ASM? :) But also >> see below ... >> >>> >>> Open Webrev: >>> http://cr.openjdk.java.net/~vromero/8225056/webrev.00/index.html >> >> make/data/jdwp/jdwp.spec >> >> There needs to be a sub-task and associated CSR request for this JDWP >> spec update. I couldn't see this covered anywhere. >> >> --- >> >> src/hotspot/share/classfile/classFileParser.cpp >> >> 3215 u2 >> ClassFileParser::parse_classfile_permitted_subclasses_attribute(const >> ClassFileStream* const cfs, >> 3216 const u1* const permitted_subclasses_attribute_start, >> 3217 TRAPS) { >> >> Indention on L3216/17 needs fixing after the copy'n'edit. >> >> 3515?? return _major_version == JVM_CLASSFILE_MAJOR_VERSION && >> 3516????????????? _minor_version == JAVA_PREVIEW_MINOR_VERSION && >> 3517????????????? Arguments::enable_preview(); >> >> Too much indentation on L3516/17 >> >> 3790???????????????? // Check for PermittedSubclasses tag >> >> That comment (copied from my nestmates code :) is in the wrong place. >> It needs to be before >> >> 3788???????????? if (tag == vmSymbols::tag_permitted_subclasses()) { >> >> >> Minor nit: I would suggest checking >> parsed_permitted_subclasses_attribute before checking ACC_FINAL. >> >> 3876?? if (parsed_permitted_subclasses_attribute) { >> 3877???? const u2 num_of_subclasses = >> parse_classfile_permitted_subclasses_attribute( >> 3878??????????????????????????????????? cfs, >> 3879 permitted_subclasses_attribute_start, >> 3880??????????????????????????????????? CHECK); >> >> Although it looks odd the preceding, similarly shaped, sections all >> indent to the same absolute position. Can you make L3878/78/80 match >> please. >> >> 3882?????? guarantee_property( >> 3883???????? permitted_subclasses_attribute_length == >> 3884?????????? sizeof(num_of_subclasses) + sizeof(u2) * >> num_of_subclasses, >> 3885???????? "Wrong PermittedSubclasses attribute length in class >> file %s", CHECK); >> >> Nits: please reformat as: >> >> 3882?????? guarantee_property( >> 3883???????? permitted_subclasses_attribute_length == >> sizeof(num_of_subclasses) + sizeof(u2) * num_of_subclasses, >> 3885???????? "Wrong PermittedSubclasses attribute length in class >> file %s", CHECK); >> >> It would also look slightly better if you shortened the name of the >> num_of_subclasses variable. >> >> --- >> >> src/hotspot/share/classfile/classFileParser.hpp >> >> +?? u2 parse_classfile_permitted_subclasses_attribute(const >> ClassFileStream* const cfs, >> +???????????????????????????????????????????? const u1* const >> permitted_subclasses_attribute_start, >> +???????????????????????????????????????????? TRAPS); >> >> Please fix indentation after copy'n'edit. >> >> --- >> >> src/hotspot/share/oops/instanceKlass.cpp >> >> ?247?? if (classloader1 != classloader2) { >> >> I'm not clear what rule this is verifying. The same module check >> follows this one. The rule is that the subclass must be accessible to >> the superclass implying: >> 1. same named module (regardless of class access modifiers); or >> 2. (implicitly in un-named module) same package if subclass not >> public; or >> 3. public subclass >> >> Having the same classloader implies same package, but that alone >> doesn't address 2 or 3. So this doesn't conform to proposed JVMS rules. >> >> >> ?264???? if (_constants->tag_at(cp_index).is_klass()) { >> ?265?????? Klass* k2 = _constants->klass_at(cp_index, CHECK_false); >> >> You've copied this code from the nestmember checks but your changes >> don't quite make sense to me. If we have already checked is_klass() >> then klass_at() cannot lead to any exceptions. >> >> ?272?????? if (name == k->name()) { >> ?273???????? log_trace(class, sealed)("- Found it at >> permitted_subclasses[%d] => cp[%d]", i, cp_index); >> ?274???????? return true; >> >> I was wondering why you don't resolve the cp entry when you find the >> name matches, as we do for nest members, but realized that unlike the >> nest membership check, which can happen many times for a given class, >> this permitted subclass check can only happen once per class. As you >> don't actually resolve here, and given that the earlier check cannot >> throw exceptions, it follows that the entire method never results in >> any exceptions and so callers should not be using the CHECK macro. >> >> --- >> >> src/hotspot/share/oops/method.cpp >> >> I don't understand how knowing the class is sealed allows you to >> infer that a non-final method is actually final ?? >> >> --- >> >> ?src/hotspot/share/prims/jvm.cpp >> >> It would be simpler (and cheaper) if the Java side of this ensures it >> doesn't call into the VM with an array or primitive class. >> >> --- >> >> ?src/hotspot/share/prims/jvmti.xml >> >> The JVM TI spec changes also need to be covered by a CSR request. >> >> --- >> >> src/hotspot/share/prims/jvmtiRedefineClasses.cpp >> >> We should file a RFE to refactor the logic that checks that an >> attribute consisting of a list of classes has not changed. :) >> >> Aside: I spotted a bug in the nest member code (missing NULL check!) >> thanks to your change :) >> >> --- >> >> src/java.base/share/classes/java/lang/Class.java >> >> There needs to be a CSR request for these changes. >> >> +????? * Returns an array containing {@code ClassDesc} objects >> representing all the >> +????? * permitted subclasses of this {@linkplain Class} if it is >> sealed. Returns an empty array if this >> +????? * {@linkplain Class} is not sealed. >> >> should add "or this class represents an array or primitive type" >> (using the standard wording for such cases). >> >> +????? * @throws IllegalArgumentException if a class descriptor is >> not in the correct format >> >> IllegalArgumentException is not an appropriate exception to use as >> this method takes no arguments. If the class descriptor is not valid >> and it comes from the VM then I think we have a problem with how the >> VM validates class descriptors. Any IAE from ClassDesc.of should be >> caught and converted to a more suitable exception type - preferably >> InternalError if the VM should always return valid strings. >> >> +???? public ClassDesc[] getPermittedSubclasses() { >> >> As mentioned for jvm.cpp this Java code should do the isArray() and >> isPrimitive() check before calling the VM. >> >> +???????? String[] descriptors = getPermittedSubclasses0(); >> >> Nit: what you get from the VM are not descriptors, just name strings >> in internal form. This wouldn't really matter except it then looks >> strange to call ClassDesc.of(...) instead of >> ClassDesc.ofDescriptor(...). >> >> +???????? if (descriptors == null >> >> The VM never returns null. >> >> +???????? return getPermittedSubclasses().length != 0; >> >> It's grossly inefficient to create the ClassDesc array and then throw >> it away IMO. The result should be cached either in a field of Class >> or in the ReflectionData of the class. >> >> --- >> >> src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java >> >> >> !???????? // - The offset of the PermittedSubclasses attribute, or 0 >> ????????? int permittedSubtypesOffset = 0; >> >> Obviously ASM already has some prelim support for sealed classes, but >> now that the attribute has been renamed that should also flow through >> to the ASM code ie the variable, not just the comment. >> >> Ditto for ClassWriter.java and its fields. >> >> --- >> >> src/java.base/share/native/libjava/Class.c >> >> ????? {"isRecord0",??????????? "()Z",???????? (void *)&JVM_IsRecord}, >> +???? {"getPermittedSubclasses0", "()[" STR,??? (void >> *)&JVM_GetPermittedSubclasses}, >> >> please align (void >> >> --- >> >> src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java >> >> src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java >> >> There needs to be a CSR for these changes too. >> >> --- >> >> test/langtools/tools/javac/processing/model/TestSourceVersion.java >> >> !??????????????????? // Assume "record" and "sealed" will be >> restricted keywords. >> !??????????????????? "record", "sealed"); >> >> What about the non-sealed keyword defined in the JEP? >> >> --- >> >> In the tests you don't need to explicitly include >> sun.hotspot.WhiteBox$WhiteBoxPermission on the ClassFileInstaller >> invocation. (previous RFE's have been removing existing occurrences >> after the CFI was fixed to handle it internally). >> >> Please ensure all new tests have an @bug 8225056 (or whatever the >> actual JBS issue will be) >> >> All test classes (and thus files) should be named in camel-case i.e. >> C1 not c1, C2 not c2, SuperClass not superClass etc. >> >> >> test/hotspot/jtreg/runtime/modules/sealedP1/superClass.jcod >> test/hotspot/jtreg/runtime/sealedClasses/Pkg/sealedInterface.jcod >> >> Please add comments clarifying why these must be jcod files. >> >> --- >> >> That's it from me. >> >> Thanks, >> David >> ----- >> >> >> >>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8225056 >>> >>> Java Language Spec changes: >>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html >>> >>> >>> JVM Spec changes: >>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jvms.html >>> >>> >>> JEP 360: https://bugs.openjdk.java.net/browse/JDK-8227043 >>> >>> JVM CSR: https://bugs.openjdk.java.net/browse/JDK-8242578 >>> >>> Changes to javac and other language tools will be reviewed separately. >>> >>> Thanks, Harold >>> >>> > From Roger.Riggs at oracle.com Tue May 19 16:56:48 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 19 May 2020 12:56:48 -0400 Subject: RFR: 8215401: Add isEmpty default method to CharSequence In-Reply-To: <9765e3e1-5841-e93e-77b1-2030b894e660@oracle.com> References: <73809ad1-e317-ade2-7fec-f356f38d005c@oracle.com> <9765e3e1-5841-e93e-77b1-2030b894e660@oracle.com> Message-ID: <3dae63a5-3f2c-1e3f-d023-bd640db34591@oracle.com> Hi Claes, Looks good, Thanks for the test. p.s.? I probably would have used a data provider for the CS cases but its not significant. On 5/19/20 6:37 AM, Claes Redestad wrote: > Hi Roger, > > sure, added Emptiness.java with a few sanity tests. > > /Claes > > On 2020-05-19 00:29, Roger Riggs wrote: >> Hi Claes, >> >> Though it does not look like it could be any simpler, there should >> probably be a test. >> Checking consistency with the existing implementations of >> CharSequence.length() >> and a custom subtype. >> >> Thanks, Roger >> >> >> On 5/18/20 4:48 PM, Claes Redestad wrote: >>> Hi, >>> >>> let's add an isEmpty default method to CharSequence! >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8215401/open.00/ >>> RFE:??? https://bugs.openjdk.java.net/browse/JDK-8215401 >>> CSR:??? https://bugs.openjdk.java.net/browse/JDK-8215402 >>> >>> Testing: tier1-3 >>> >>> /Claes >> From christoph.dreis at freenet.de Tue May 19 17:50:13 2020 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Tue, 19 May 2020 19:50:13 +0200 Subject: Optimize (Linked-)HashMap lookup when backing array is null In-Reply-To: <39881274-1311-c67d-b7a5-9e6ab07e812a@oracle.com> References: <311BBE19-C22B-4BA4-B9EE-267B6811841E@freenet.de> <39881274-1311-c67d-b7a5-9e6ab07e812a@oracle.com> Message-ID: <3850FBEC-DE36-4405-81DE-27DC5CB79EE5@freenet.de> Hi Claes, On 2020-05-19 15:15, Christoph Dreis wrote: >> Hi Claes, >> >>> unlike CHM, HashMap and LinkedHashMap have constant-time size/isEmpty >>> accessors - could this be used to simplify your patch? >> >> I was wondering about that during implementation, but simply took the path I already chose for the CHM. > I think we should try to keep any changes here as simple as possible. Please find an alternative solution attached that does isEmpty() checks for get() and containsKey() calls. With the provided solution and the combined (empty & non-empty maps) benchmarks, I get the following results: MyBenchmarkNew.test avgt 10 4,479 ? 0,061 ns/op MyBenchmarkOld.test avgt 10 4,877 ? 0,054 ns/op I should note that I see a slightly higher average timing with a filled map with the isEmpty() version: MyBenchmarkNew.test avgt 10 5,465 ? 0,354 ns/op MyBenchmarkOld.test avgt 10 5,315 ? 0,187 ns/op Isolated benchmarks on just an empty map show the following results (for completeness reasons): MyBenchmarkNew.test avgt 10 2,785 ? 0,191 ns/op MyBenchmarkOld.test avgt 10 3,785 ? 0,436 ns/op I can somewhat explain the higher average timing on a filled map with this solution: It actually does "more" work by checking for the size, while the previous solution shifted only existing work to a place where it's actually needed. I would probably go for the first version although it is a bit more complicated and has the computeIfPresent caveat, because it doesn't slow down the common Map.get() case when the map is actually filled. Let me know what you think. Cheers, Christoph -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pre-isempty-hashmap.txt URL: From serguei.spitsyn at oracle.com Tue May 19 18:09:30 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 May 2020 11:09:30 -0700 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> Message-ID: <9e330d14-a3b5-0017-fc7f-8fcb403a8f39@oracle.com> On 5/19/20 09:46, Harold Seigel wrote: > That sounds good! > > Thanks, Harold > > On 5/19/2020 11:53 AM, serguei.spitsyn at oracle.com wrote: >> Hi Harold, >> >> The Serviceability part including the tests looks good to me. >> I can file a JVMTI enhancement on the jvmtiRedefineClasses.cpp >> refactoring if you are okay with it. Filed enhancement and assigned to myself: ? https://bugs.openjdk.java.net/browse/JDK-8245321 ??? refactor the redefine check that an attribute consisting of a list of classes has not changed Thanks, Serguei >> >> Thanks, >> Serguei >> >> >> On 5/18/20 22:26, David Holmes wrote: >>> Hi Harold, >>> >>> Adding serviceability-dev for the serviceability related changes. >>> >>> Nit: "VM support for sealed classes" >>> >>> This RFR covers the VM, core-libs, serviceability and even some >>> langtools tests. AFAICS only the javac changes are not included here >>> so when and where will they be reviewed and under what bug id? >>> Ideally there will be a single JBS issue for "Implementation of JEP >>> 360: Sealed types". It's okay to break up the RFRs across different >>> areas, but it should be done under one bug id. >>> >>> Overall this looks good. I've looked at all files and mainly have >>> some style nits in various places. But there are some more >>> significant items below. >>> >>> On 14/05/2020 7:09 am, Harold Seigel wrote: >>>> Hi, >>>> >>>> Please review this patch for JVM and Core-libs support for the JEP >>>> 360 Sealed Classes preview feature.? Code changes include the >>>> following: >>>> >>>> ??* Processing of the new PermittedSubclasses attribute to enforce >>>> that >>>> ??? a class or interface, whose super is a sealed class or interface, >>>> ??? must be listed in the super's PermittedSubclasses attribute. >>>> ??* Disallow redefinition of a sealed class or interface if its >>>> ??? redefinition would change its PermittedSubclasses attribute. >>>> ??* Support API's to determine if a class or interface is sealed >>>> and, if >>>> ??? it's sealed, return a list of its permitted subclasses. >>>> ??* asm support for the PermittedSubclasses attribute >>> >>> I assume Remi is providing the upstream support in ASM? :) But also >>> see below ... >>> >>>> >>>> Open Webrev: >>>> http://cr.openjdk.java.net/~vromero/8225056/webrev.00/index.html >>> >>> make/data/jdwp/jdwp.spec >>> >>> There needs to be a sub-task and associated CSR request for this >>> JDWP spec update. I couldn't see this covered anywhere. >>> >>> --- >>> >>> src/hotspot/share/classfile/classFileParser.cpp >>> >>> 3215 u2 >>> ClassFileParser::parse_classfile_permitted_subclasses_attribute(const >>> ClassFileStream* const cfs, >>> 3216 const u1* const permitted_subclasses_attribute_start, >>> 3217 TRAPS) { >>> >>> Indention on L3216/17 needs fixing after the copy'n'edit. >>> >>> 3515?? return _major_version == JVM_CLASSFILE_MAJOR_VERSION && >>> 3516????????????? _minor_version == JAVA_PREVIEW_MINOR_VERSION && >>> 3517????????????? Arguments::enable_preview(); >>> >>> Too much indentation on L3516/17 >>> >>> 3790???????????????? // Check for PermittedSubclasses tag >>> >>> That comment (copied from my nestmates code :) is in the wrong >>> place. It needs to be before >>> >>> 3788???????????? if (tag == vmSymbols::tag_permitted_subclasses()) { >>> >>> >>> Minor nit: I would suggest checking >>> parsed_permitted_subclasses_attribute before checking ACC_FINAL. >>> >>> 3876?? if (parsed_permitted_subclasses_attribute) { >>> 3877???? const u2 num_of_subclasses = >>> parse_classfile_permitted_subclasses_attribute( >>> 3878??????????????????????????????????? cfs, >>> 3879 permitted_subclasses_attribute_start, >>> 3880??????????????????????????????????? CHECK); >>> >>> Although it looks odd the preceding, similarly shaped, sections all >>> indent to the same absolute position. Can you make L3878/78/80 match >>> please. >>> >>> 3882?????? guarantee_property( >>> 3883???????? permitted_subclasses_attribute_length == >>> 3884?????????? sizeof(num_of_subclasses) + sizeof(u2) * >>> num_of_subclasses, >>> 3885???????? "Wrong PermittedSubclasses attribute length in class >>> file %s", CHECK); >>> >>> Nits: please reformat as: >>> >>> 3882?????? guarantee_property( >>> 3883???????? permitted_subclasses_attribute_length == >>> sizeof(num_of_subclasses) + sizeof(u2) * num_of_subclasses, >>> 3885???????? "Wrong PermittedSubclasses attribute length in class >>> file %s", CHECK); >>> >>> It would also look slightly better if you shortened the name of the >>> num_of_subclasses variable. >>> >>> --- >>> >>> src/hotspot/share/classfile/classFileParser.hpp >>> >>> +?? u2 parse_classfile_permitted_subclasses_attribute(const >>> ClassFileStream* const cfs, >>> +???????????????????????????????????????????? const u1* const >>> permitted_subclasses_attribute_start, >>> +???????????????????????????????????????????? TRAPS); >>> >>> Please fix indentation after copy'n'edit. >>> >>> --- >>> >>> src/hotspot/share/oops/instanceKlass.cpp >>> >>> ?247?? if (classloader1 != classloader2) { >>> >>> I'm not clear what rule this is verifying. The same module check >>> follows this one. The rule is that the subclass must be accessible >>> to the superclass implying: >>> 1. same named module (regardless of class access modifiers); or >>> 2. (implicitly in un-named module) same package if subclass not >>> public; or >>> 3. public subclass >>> >>> Having the same classloader implies same package, but that alone >>> doesn't address 2 or 3. So this doesn't conform to proposed JVMS rules. >>> >>> >>> ?264???? if (_constants->tag_at(cp_index).is_klass()) { >>> ?265?????? Klass* k2 = _constants->klass_at(cp_index, CHECK_false); >>> >>> You've copied this code from the nestmember checks but your changes >>> don't quite make sense to me. If we have already checked is_klass() >>> then klass_at() cannot lead to any exceptions. >>> >>> ?272?????? if (name == k->name()) { >>> ?273???????? log_trace(class, sealed)("- Found it at >>> permitted_subclasses[%d] => cp[%d]", i, cp_index); >>> ?274???????? return true; >>> >>> I was wondering why you don't resolve the cp entry when you find the >>> name matches, as we do for nest members, but realized that unlike >>> the nest membership check, which can happen many times for a given >>> class, this permitted subclass check can only happen once per class. >>> As you don't actually resolve here, and given that the earlier check >>> cannot throw exceptions, it follows that the entire method never >>> results in any exceptions and so callers should not be using the >>> CHECK macro. >>> >>> --- >>> >>> src/hotspot/share/oops/method.cpp >>> >>> I don't understand how knowing the class is sealed allows you to >>> infer that a non-final method is actually final ?? >>> >>> --- >>> >>> ?src/hotspot/share/prims/jvm.cpp >>> >>> It would be simpler (and cheaper) if the Java side of this ensures >>> it doesn't call into the VM with an array or primitive class. >>> >>> --- >>> >>> ?src/hotspot/share/prims/jvmti.xml >>> >>> The JVM TI spec changes also need to be covered by a CSR request. >>> >>> --- >>> >>> src/hotspot/share/prims/jvmtiRedefineClasses.cpp >>> >>> We should file a RFE to refactor the logic that checks that an >>> attribute consisting of a list of classes has not changed. :) >>> >>> Aside: I spotted a bug in the nest member code (missing NULL check!) >>> thanks to your change :) >>> >>> --- >>> >>> src/java.base/share/classes/java/lang/Class.java >>> >>> There needs to be a CSR request for these changes. >>> >>> +????? * Returns an array containing {@code ClassDesc} objects >>> representing all the >>> +????? * permitted subclasses of this {@linkplain Class} if it is >>> sealed. Returns an empty array if this >>> +????? * {@linkplain Class} is not sealed. >>> >>> should add "or this class represents an array or primitive type" >>> (using the standard wording for such cases). >>> >>> +????? * @throws IllegalArgumentException if a class descriptor is >>> not in the correct format >>> >>> IllegalArgumentException is not an appropriate exception to use as >>> this method takes no arguments. If the class descriptor is not valid >>> and it comes from the VM then I think we have a problem with how the >>> VM validates class descriptors. Any IAE from ClassDesc.of should be >>> caught and converted to a more suitable exception type - preferably >>> InternalError if the VM should always return valid strings. >>> >>> +???? public ClassDesc[] getPermittedSubclasses() { >>> >>> As mentioned for jvm.cpp this Java code should do the isArray() and >>> isPrimitive() check before calling the VM. >>> >>> +???????? String[] descriptors = getPermittedSubclasses0(); >>> >>> Nit: what you get from the VM are not descriptors, just name strings >>> in internal form. This wouldn't really matter except it then looks >>> strange to call ClassDesc.of(...) instead of >>> ClassDesc.ofDescriptor(...). >>> >>> +???????? if (descriptors == null >>> >>> The VM never returns null. >>> >>> +???????? return getPermittedSubclasses().length != 0; >>> >>> It's grossly inefficient to create the ClassDesc array and then >>> throw it away IMO. The result should be cached either in a field of >>> Class or in the ReflectionData of the class. >>> >>> --- >>> >>> src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java >>> >>> >>> !???????? // - The offset of the PermittedSubclasses attribute, or 0 >>> ????????? int permittedSubtypesOffset = 0; >>> >>> Obviously ASM already has some prelim support for sealed classes, >>> but now that the attribute has been renamed that should also flow >>> through to the ASM code ie the variable, not just the comment. >>> >>> Ditto for ClassWriter.java and its fields. >>> >>> --- >>> >>> src/java.base/share/native/libjava/Class.c >>> >>> ????? {"isRecord0",??????????? "()Z",???????? (void *)&JVM_IsRecord}, >>> +???? {"getPermittedSubclasses0", "()[" STR,??? (void >>> *)&JVM_GetPermittedSubclasses}, >>> >>> please align (void >>> >>> --- >>> >>> src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java >>> >>> src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java >>> >>> There needs to be a CSR for these changes too. >>> >>> --- >>> >>> test/langtools/tools/javac/processing/model/TestSourceVersion.java >>> >>> !??????????????????? // Assume "record" and "sealed" will be >>> restricted keywords. >>> !??????????????????? "record", "sealed"); >>> >>> What about the non-sealed keyword defined in the JEP? >>> >>> --- >>> >>> In the tests you don't need to explicitly include >>> sun.hotspot.WhiteBox$WhiteBoxPermission on the ClassFileInstaller >>> invocation. (previous RFE's have been removing existing occurrences >>> after the CFI was fixed to handle it internally). >>> >>> Please ensure all new tests have an @bug 8225056 (or whatever the >>> actual JBS issue will be) >>> >>> All test classes (and thus files) should be named in camel-case i.e. >>> C1 not c1, C2 not c2, SuperClass not superClass etc. >>> >>> >>> test/hotspot/jtreg/runtime/modules/sealedP1/superClass.jcod >>> test/hotspot/jtreg/runtime/sealedClasses/Pkg/sealedInterface.jcod >>> >>> Please add comments clarifying why these must be jcod files. >>> >>> --- >>> >>> That's it from me. >>> >>> Thanks, >>> David >>> ----- >>> >>> >>> >>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8225056 >>>> >>>> Java Language Spec changes: >>>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html >>>> >>>> >>>> JVM Spec changes: >>>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jvms.html >>>> >>>> >>>> JEP 360: https://bugs.openjdk.java.net/browse/JDK-8227043 >>>> >>>> JVM CSR: https://bugs.openjdk.java.net/browse/JDK-8242578 >>>> >>>> Changes to javac and other language tools will be reviewed separately. >>>> >>>> Thanks, Harold >>>> >>>> >> From jason_mehrens at hotmail.com Tue May 19 18:24:15 2020 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 19 May 2020 18:24:15 +0000 Subject: RFR: 8215401: Add isEmpty default method to CharSequence In-Reply-To: <9765e3e1-5841-e93e-77b1-2030b894e660@oracle.com> References: <73809ad1-e317-ade2-7fec-f356f38d005c@oracle.com> , <9765e3e1-5841-e93e-77b1-2030b894e660@oracle.com> Message-ID: Claes, I would think CharBuffer would require some testing in your test cases too. Also it looks like some of the CharSequence methods in CharBuffer are declared final. Not sure what is appropriate here as far as CharBuffer::isEmpty modifiers are concerned. Jason ________________________________________ From: core-libs-dev on behalf of Claes Redestad Sent: Tuesday, May 19, 2020 5:37 AM To: Roger Riggs; core-libs-dev at openjdk.java.net Subject: Re: RFR: 8215401: Add isEmpty default method to CharSequence Hi Roger, sure, added Emptiness.java with a few sanity tests. /Claes On 2020-05-19 00:29, Roger Riggs wrote: > Hi Claes, > > Though it does not look like it could be any simpler, there should > probably be a test. > Checking consistency with the existing implementations of > CharSequence.length() > and a custom subtype. > > Thanks, Roger > > > On 5/18/20 4:48 PM, Claes Redestad wrote: >> Hi, >> >> let's add an isEmpty default method to CharSequence! >> >> Webrev: http://cr.openjdk.java.net/~redestad/8215401/open.00/ >> RFE: https://bugs.openjdk.java.net/browse/JDK-8215401 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8215402 >> >> Testing: tier1-3 >> >> /Claes > From vipinsharma85 at gmail.com Tue May 19 18:51:33 2020 From: vipinsharma85 at gmail.com (Vipin Sharma) Date: Wed, 20 May 2020 00:21:33 +0530 Subject: Fix for warning related to stream api call chains in java.base In-Reply-To: References: Message-ID: <36DF7BDE-0D6C-410F-887E-B0C22B34818F@gmail.com> Hi All, Forgot to mention these are IDE warnings I am trying to fix, need a sponsor for this. Regards, Vipin > On May 3, 2020, at 8:40 PM, Vipin Sharma wrote: > > Hi All, > > I have fixed some warnings in java.base module, following are 3 type of code changes in this patch: > > ! stream().filter(...).findFirst().isPresent() replaced with stream().noneMatch(...)) > stream.filter(...).findFirst().isPresent() replaced with stream.anyMatch(...) > stream.collect(Collectors.joining(",")) replaced with String.join(",", stringList) > > This patch improves performance as well, jmh results available at https://gist.github.com/Vipin-Sharma/00f1d6da6b8e0e0bc7bec2e33bce85ed , end of gist file you can see results. Need a sponsor for this patch. > > Patch: > > --- old/src/java.base/share/classes/java/lang/invoke/MethodHandles.java 2020-05-03 19:44:09.519289354 +0530 > +++ new/src/java.base/share/classes/java/lang/invoke/MethodHandles.java 2020-05-03 19:44:09.087294954 +0530 > @@ -6349,7 +6349,7 @@ > loopReturnType + ")"); > } > > - if (!pred.stream().filter(Objects::nonNull).findFirst().isPresent()) { > + if (pred.stream().noneMatch(Objects::nonNull)) { > throw newIllegalArgumentException("no predicate found", pred); > } > if (pred.stream().filter(Objects::nonNull).map(MethodHandle::type).map(MethodType::returnType). > --- old/src/java.base/share/classes/java/util/Locale.java 2020-05-03 19:44:10.915271183 +0530 > +++ new/src/java.base/share/classes/java/util/Locale.java 2020-05-03 19:44:10.487276766 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1996, 2019, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 1996, 2020, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -2250,7 +2250,7 @@ > // If we have no list patterns, compose the list in a simple, > // non-localized way. > if (pattern == null) { > - return Arrays.stream(stringList).collect(Collectors.joining(",")); > + return String.join(",", stringList); > } > > switch (stringList.length) { > --- old/src/java.base/share/classes/jdk/internal/module/DefaultRoots.java 2020-05-03 19:44:11.911258115 +0530 > +++ new/src/java.base/share/classes/jdk/internal/module/DefaultRoots.java 2020-05-03 19:44:11.479263786 +0530 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2017, 2018, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2017, 2020, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -74,8 +74,6 @@ > private static boolean exportsAPI(ModuleDescriptor descriptor) { > return descriptor.exports() > .stream() > - .filter(e -> !e.isQualified()) > - .findAny() > - .isPresent(); > + .anyMatch(e -> !e.isQualified()); > } > } > --- old/src/java.base/share/classes/sun/launcher/LauncherHelper.java 2020-05-03 19:44:12.863245549 +0530 > +++ new/src/java.base/share/classes/sun/launcher/LauncherHelper.java 2020-05-03 19:44:12.427251308 +0530 > @@ -1142,7 +1142,7 @@ > ostream.format("uses %s%n", s); > } > for (Provides ps : md.provides()) { > - String names = ps.providers().stream().collect(Collectors.joining(" ")); > + String names = String.join(" ", ps.providers()); > ostream.format("provides %s with %s%n", ps.service(), names); > > } > @@ -1150,7 +1150,7 @@ > // qualified exports > for (Exports e : md.exports()) { > if (e.isQualified()) { > - String who = e.targets().stream().collect(Collectors.joining(" ")); > + String who = String.join(" ", e.targets()); > ostream.format("qualified exports %s to %s%n", e.source(), who); > } > } > @@ -1164,7 +1164,7 @@ > .collect(Collectors.joining(" ")); > ostream.format("opens %s", sourceAndMods); > if (opens.isQualified()) { > - String who = opens.targets().stream().collect(Collectors.joining(" ")); > + String who = String.join(" ", opens.targets()); > ostream.format(" to %s", who); > } > ostream.println(); > --- old/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java 2020-05-03 19:44:14.143228540 +0530 > +++ new/src/jdk.jshell/share/classes/jdk/internal/jshell/tool/JShellTool.java 2020-05-03 19:44:13.711234292 +0530 > @@ -380,7 +380,7 @@ > return parse(oset); > } catch (OptionException ex) { > if (ex.options().isEmpty()) { > - msg("jshell.err.opt.invalid", stream(args).collect(joining(", "))); > + msg("jshell.err.opt.invalid", String.join(", ", args)); > } else { > boolean isKnown = parser.recognizedOptions().containsKey(ex.options().iterator().next()); > msg(isKnown > @@ -2041,16 +2041,14 @@ > if (matches.length == 0) { > // There are no matching sub-commands > errormsg("jshell.err.arg", cmd, sub); > - fluffmsg("jshell.msg.use.one.of", Arrays.stream(subs) > - .collect(Collectors.joining(", ")) > + fluffmsg("jshell.msg.use.one.of", String.join(", ", subs) > ); > return null; > } > if (matches.length > 1) { > // More than one sub-command matches the initial characters provided > errormsg("jshell.err.sub.ambiguous", cmd, sub); > - fluffmsg("jshell.msg.use.one.of", Arrays.stream(matches) > - .collect(Collectors.joining(", ")) > + fluffmsg("jshell.msg.use.one.of", String.join(", ", matches) > ); > return null; > } > > > Regards, > Vipin From claes.redestad at oracle.com Tue May 19 19:21:19 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 19 May 2020 21:21:19 +0200 Subject: Optimize (Linked-)HashMap lookup when backing array is null In-Reply-To: <3850FBEC-DE36-4405-81DE-27DC5CB79EE5@freenet.de> References: <311BBE19-C22B-4BA4-B9EE-267B6811841E@freenet.de> <39881274-1311-c67d-b7a5-9e6ab07e812a@oracle.com> <3850FBEC-DE36-4405-81DE-27DC5CB79EE5@freenet.de> Message-ID: Thanks for producing the simpler variant and getting some comparative runs done. On 2020-05-19 19:50, Christoph Dreis wrote: > I would probably go for the first version although it is a bit more complicated and has the computeIfPresent caveat, because it doesn't slow down the common Map.get() case when the map is actually filled. It is a bit of step up in complexity, but getting the win without adding a branch to Map.get() _is_ a nice property. > > Let me know what you think. If core libs maintainers are fine with the added complexity of your original patch, I think it looks ok. /Claes From claes.redestad at oracle.com Tue May 19 19:35:06 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 19 May 2020 21:35:06 +0200 Subject: RFR: 8215401: Add isEmpty default method to CharSequence In-Reply-To: References: <73809ad1-e317-ade2-7fec-f356f38d005c@oracle.com> <9765e3e1-5841-e93e-77b1-2030b894e660@oracle.com> Message-ID: <2b4030b6-29d9-a1af-e96d-1da3ce260711@oracle.com> Hi Jason, I guess overriding and marking the CharBuffer method final for consistency wouldn't hurt. Except I probably need to pass this through another CSR review. Also added test cases for char[] and String-based CharBuffers: http://cr.openjdk.java.net/~redestad/8215401/open.01/ /Claes On 2020-05-19 20:24, Jason Mehrens wrote: > Claes, > > I would think CharBuffer would require some testing in your test cases too. Also it looks like some of the CharSequence methods in CharBuffer are declared final. Not sure what is appropriate here as far as CharBuffer::isEmpty modifiers are concerned. > > Jason > > ________________________________________ > From: core-libs-dev on behalf of Claes Redestad > Sent: Tuesday, May 19, 2020 5:37 AM > To: Roger Riggs; core-libs-dev at openjdk.java.net > Subject: Re: RFR: 8215401: Add isEmpty default method to CharSequence > > Hi Roger, > > sure, added Emptiness.java with a few sanity tests. > > /Claes > > On 2020-05-19 00:29, Roger Riggs wrote: >> Hi Claes, >> >> Though it does not look like it could be any simpler, there should >> probably be a test. >> Checking consistency with the existing implementations of >> CharSequence.length() >> and a custom subtype. >> >> Thanks, Roger >> >> >> On 5/18/20 4:48 PM, Claes Redestad wrote: >>> Hi, >>> >>> let's add an isEmpty default method to CharSequence! >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8215401/open.00/ >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8215401 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8215402 >>> >>> Testing: tier1-3 >>> >>> /Claes >> From Roger.Riggs at oracle.com Tue May 19 19:48:26 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 19 May 2020 15:48:26 -0400 Subject: Optimize (Linked-)HashMap lookup when backing array is null In-Reply-To: References: <311BBE19-C22B-4BA4-B9EE-267B6811841E@freenet.de> <39881274-1311-c67d-b7a5-9e6ab07e812a@oracle.com> <3850FBEC-DE36-4405-81DE-27DC5CB79EE5@freenet.de> Message-ID: <1f0e873b-0ba9-1bcc-847e-1d8dabea689c@oracle.com> Hi, How does the performance degrade when the computation of the hash is non-trivial. For example, with an array as a key or an object with fields that are objects? The original code made a point of computing the hash only once. ??, Roger On 5/19/20 3:21 PM, Claes Redestad wrote: > Thanks for producing the simpler variant and getting some comparative > runs done. > > On 2020-05-19 19:50, Christoph Dreis wrote: >> I would probably go for the first version although it is a bit more >> complicated and has the computeIfPresent caveat, because it doesn't >> slow down the common Map.get() case when the map is actually filled. > > It is a bit of step up in complexity, but getting the win without adding > a branch to Map.get() _is_ a nice property. > >> >> Let me know what you think. > > If core libs maintainers are fine with the added complexity of your > original patch, I think it looks ok. > > /Claes From christoph.dreis at freenet.de Tue May 19 19:56:46 2020 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Tue, 19 May 2020 21:56:46 +0200 Subject: Optimize (Linked-)HashMap lookup when backing array is null In-Reply-To: <1f0e873b-0ba9-1bcc-847e-1d8dabea689c@oracle.com> References: <311BBE19-C22B-4BA4-B9EE-267B6811841E@freenet.de> <39881274-1311-c67d-b7a5-9e6ab07e812a@oracle.com> <3850FBEC-DE36-4405-81DE-27DC5CB79EE5@freenet.de> <1f0e873b-0ba9-1bcc-847e-1d8dabea689c@oracle.com> Message-ID: <55194386-F651-4A0D-B0EF-9EB9B4553C24@freenet.de> Hi Roger, > How does the performance degrade when the computation of the hash > is non-trivial. For example, with an array as a key or an object with > fields that are objects? > The original code made a point of computing the hash only once. HashMap.get() and HashMap.containsKey() etc. would still calculate it only once. Only computeIfPresent would degrade. Did you mean that? Cheers, Christoph On 5/19/20 3:21 PM, Claes Redestad wrote: >> Thanks for producing the simpler variant and getting some comparative >> runs done. >> >> On 2020-05-19 19:50, Christoph Dreis wrote: >>> I would probably go for the first version although it is a bit more >>> complicated and has the computeIfPresent caveat, because it doesn't >>> slow down the common Map.get() case when the map is actually filled. >> >> It is a bit of step up in complexity, but getting the win without adding >> a branch to Map.get() _is_ a nice property. >> >>> >>> Let me know what you think. >> >> If core libs maintainers are fine with the added complexity of your >> original patch, I think it looks ok. >> >> /Claes From james.laskey at oracle.com Tue May 19 20:00:22 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Tue, 19 May 2020 17:00:22 -0300 Subject: RFR (CSR) JDK-8245399 Remove addition preview adornment from String::formatted Message-ID: <4D744464-3018-48E2-BF9B-3D089EB4AD75@oracle.com> Please review this change to remove the preview heading from the javadoc of String::formatted. This also updates the @since to 15. Thank you. Cheers, -- Jim csr: https://bugs.openjdk.java.net/browse/JDK-8245399 jbs: https://bugs.openjdk.java.net/browse/JDK-8245398 From Roger.Riggs at oracle.com Tue May 19 20:21:16 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 19 May 2020 16:21:16 -0400 Subject: Optimize (Linked-)HashMap lookup when backing array is null In-Reply-To: <55194386-F651-4A0D-B0EF-9EB9B4553C24@freenet.de> References: <311BBE19-C22B-4BA4-B9EE-267B6811841E@freenet.de> <39881274-1311-c67d-b7a5-9e6ab07e812a@oracle.com> <3850FBEC-DE36-4405-81DE-27DC5CB79EE5@freenet.de> <1f0e873b-0ba9-1bcc-847e-1d8dabea689c@oracle.com> <55194386-F651-4A0D-B0EF-9EB9B4553C24@freenet.de> Message-ID: <899c7670-cba9-1128-dc2c-d4468613a0be@oracle.com> Hi, Right, its only in the case of removing the node because the new value was null. Besides being infrequent, that should not be a problem. Thanks, Roger On 5/19/20 3:56 PM, Christoph Dreis wrote: > Hi Roger, > >> How does the performance degrade when the computation of the hash >> is non-trivial. For example, with an array as a key or an object with >> fields that are objects? >> The original code made a point of computing the hash only once. > HashMap.get() and HashMap.containsKey() etc. would still calculate it only once. > Only computeIfPresent would degrade. Did you mean that? > > Cheers, > Christoph > > On 5/19/20 3:21 PM, Claes Redestad wrote: >>> Thanks for producing the simpler variant and getting some comparative >>> runs done. >>> >>> On 2020-05-19 19:50, Christoph Dreis wrote: >>>> I would probably go for the first version although it is a bit more >>>> complicated and has the computeIfPresent caveat, because it doesn't >>>> slow down the common Map.get() case when the map is actually filled. >>> It is a bit of step up in complexity, but getting the win without adding >>> a branch to Map.get() _is_ a nice property. >>> >>>> Let me know what you think. >>> If core libs maintainers are fine with the added complexity of your >>> original patch, I think it looks ok. >>> >>> /Claes > > From paul.sandoz at oracle.com Tue May 19 20:41:33 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 19 May 2020 13:41:33 -0700 Subject: RFR (CSR) JDK-8245399 Remove addition preview adornment from String::formatted In-Reply-To: <4D744464-3018-48E2-BF9B-3D089EB4AD75@oracle.com> References: <4D744464-3018-48E2-BF9B-3D089EB4AD75@oracle.com> Message-ID: <1E86CE6E-5AD7-4E98-8162-4D9530F1BA77@oracle.com> +1 Paul. > On May 19, 2020, at 1:00 PM, Jim Laskey wrote: > > Please review this change to remove the preview heading from the javadoc of String::formatted. This also updates the @since to 15. > > Thank you. > > Cheers, > > -- Jim > > > csr: https://bugs.openjdk.java.net/browse/JDK-8245399 > jbs: https://bugs.openjdk.java.net/browse/JDK-8245398 > > From james.laskey at oracle.com Tue May 19 20:42:19 2020 From: james.laskey at oracle.com (James Laskey) Date: Tue, 19 May 2020 17:42:19 -0300 Subject: RFR (CSR) JDK-8245399 Remove addition preview adornment from String::formatted In-Reply-To: <1E86CE6E-5AD7-4E98-8162-4D9530F1BA77@oracle.com> References: <1E86CE6E-5AD7-4E98-8162-4D9530F1BA77@oracle.com> Message-ID: <99CBCAED-A562-42E1-8F97-C3184F1B2E2A@oracle.com> Thank you Paul. ?? > On May 19, 2020, at 5:41 PM, Paul Sandoz wrote: > > ?+1 > Paul. > >> On May 19, 2020, at 1:00 PM, Jim Laskey wrote: >> >> Please review this change to remove the preview heading from the javadoc of String::formatted. This also updates the @since to 15. >> >> Thank you. >> >> Cheers, >> >> -- Jim >> >> >> csr: https://bugs.openjdk.java.net/browse/JDK-8245399 >> jbs: https://bugs.openjdk.java.net/browse/JDK-8245398 >> >> > From paul.sandoz at oracle.com Tue May 19 22:25:27 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 19 May 2020 15:25:27 -0700 Subject: Update Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests In-Reply-To: <9D074341-7234-4D9F-8E99-0E73F5BB5407@oracle.com> References: <49F81016-55DF-4E3C-940A-A8DF8C712259@oracle.com> <9D074341-7234-4D9F-8E99-0E73F5BB5407@oracle.com> Message-ID: I just realized that the vector tests have not been included in any JDK test category e.g. tier1. Ordinarily I would expect the tests to be added to tier1 since the tests exercise intrinsics. However, those intrinsics are only enabled with the Vector API module so we could place in another tier to potentially reduce the cost of testing. Advice very much appreciate on which tier the tests should belong to. Paul. > On May 18, 2020, at 12:13 PM, Paul Sandoz wrote: > > HI, > > Here?s an update of the API and implementation webrevs based on (mostly) API feedback. We have removed the performance tests to make the review easier (those will be dealt with separately to integration as a follow on task). > > I think over the past year and recently via the CSR the API has had significant review. Reviews focusing on the Java implementation and tests would be greatly appreciated. > > It?s worth reiterating that the implementation and tests are quite formulaic, there is a lot of code that is generated from templates, so it's possible to focus on the template + subset (e.g. byte, long, float, and sizes of say 256, max). > > Notable changes from the prior webrev are: > > - Removal of the fromValues methods to construct a vector from a varargs array. Feedback indicated this was a misleading way to obtain a vector. > > - Unification of byte array and ByteBuffer load/store method signatures and unification of the implementations with more tests (including out-of-bounds tests for all the kinds of loads/stores). > > Paul. > > -- > > Latest javadoc > http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/docs-2020-05-15-88a83f7238d8/api/jdk.incubator.vector/jdk/incubator/vector/package-summary.html > > Latest specdiff > http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/specdiff-jdk-2020-05-15-88a83f7238d8/overview-summary.html > > Incremental specdiff > http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/specdiff-2020-05-11-38dd763d023e-2020-05-15-88a83f7238d8/overview-summary.html > > > Latest implementation webrev > http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev-2020-05-16-default-2020-05-15-88a83f7238d8/webrev/ > > Incremental Implementation webrev > http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev-2020-05-11-38dd763d023e-2020-05-15-88a83f7238d8/webrev/ > > Latest test webrev > http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev-2020-05-16-default-2020-05-15-88a83f7238d8/webrev/ > > Incremental test webrev > http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev-2020-05-11-38dd763d023e-2020-05-15-88a83f7238d8/webrev/ > > >> On Apr 1, 2020, at 3:46 PM, Paul Sandoz wrote: >> >> Hi, >> >> A prior email sent out a request for review of the Vector API in preparation for JEP 338: Vector API (Incubator) [1] to be proposed for target: >> >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html >> >> This email expands the review of the API to the Java implementation and Java tests: >> >> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev/webrev/ >> >> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev/webrev/ >> >> (Further emails will sent for review of general HotSpot changes CPU architecture specific HotSpot changes, x64 and aarch64, and performance tests. For an early peek see the links in the description of JDK-8223347.) >> >> ? >> >> The Vector API provides >> >> - the public Vector class with vector operations common to all supported primitive types >> >> - public primitive specializations, such as IntVector, with common operations associated with the primitive type >> >> - internal concrete specializations for the vector size, such as Int256Vector, for a vector holding 8 ints. >> >> Operations generally defer to one of approximately 20 vector intrinsics. Some operations may be composed of other operations. >> >> Explicit casts are performed by vector operations to ensure vectors arguments are of the required shape (bit size) and element type. >> >> A vector intrinsic is an internal low-level vector operation. The last argument to the intrinsic is fall back behavior in Java, implementing the scalar operation over the number of elements held by the vector. Thus, If the intrinsic is not supported in C2 for the other arguments then the Java implementation is executed (the Java implementation is always executed when running in the interpreter or for C1). >> >> The public primitive specializations and the internal concrete implementations are generated from SSP template files, X-Vector.java.template and X-VectorBits.java.template respectively. >> >> Overall the implementation approach is quite formulaic and rather repetitive. Once you grok the pattern It should be easier to review if a little laborious. >> >> Unit tests are auto-generated by composing templates for each operation into an SSP template file which is then used to generate unit test files for each concrete vector class. The tests are quite extensive and have found many a HotSpot issue in development across a wide range of platforms. >> >> Paul. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8201271 >> > From ekaterina.pavlova at oracle.com Wed May 20 00:06:28 2020 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Tue, 19 May 2020 17:06:28 -0700 Subject: Update Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests In-Reply-To: References: <49F81016-55DF-4E3C-940A-A8DF8C712259@oracle.com> <9D074341-7234-4D9F-8E99-0E73F5BB5407@oracle.com> Message-ID: <5bf2b471-36c0-f28b-b7c9-06ff5fded10c@oracle.com> As I wrote to openjdk alias tier3 seems to be more reasonable tier for incubating feature tests. Once the tests will be integrated we will also need to add these tests into hs-comp tiers to be tested with additional compiler flags (like -Xcomp). -katya On 5/19/20 3:25 PM, Paul Sandoz wrote: > I just realized that the vector tests have not been included in any JDK test category e.g. tier1. > > Ordinarily I would expect the tests to be added to tier1 since the tests exercise intrinsics. However, those intrinsics are only enabled with the Vector API module so we could place in another tier to potentially reduce the cost of testing. > > Advice very much appreciate on which tier the tests should belong to. > > Paul. > >> On May 18, 2020, at 12:13 PM, Paul Sandoz wrote: >> >> HI, >> >> Here?s an update of the API and implementation webrevs based on (mostly) API feedback. We have removed the performance tests to make the review easier (those will be dealt with separately to integration as a follow on task). >> >> I think over the past year and recently via the CSR the API has had significant review. Reviews focusing on the Java implementation and tests would be greatly appreciated. >> >> It?s worth reiterating that the implementation and tests are quite formulaic, there is a lot of code that is generated from templates, so it's possible to focus on the template + subset (e.g. byte, long, float, and sizes of say 256, max). >> >> Notable changes from the prior webrev are: >> >> - Removal of the fromValues methods to construct a vector from a varargs array. Feedback indicated this was a misleading way to obtain a vector. >> >> - Unification of byte array and ByteBuffer load/store method signatures and unification of the implementations with more tests (including out-of-bounds tests for all the kinds of loads/stores). >> >> Paul. >> >> -- >> >> Latest javadoc >> http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/docs-2020-05-15-88a83f7238d8/api/jdk.incubator.vector/jdk/incubator/vector/package-summary.html >> >> Latest specdiff >> http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/specdiff-jdk-2020-05-15-88a83f7238d8/overview-summary.html >> >> Incremental specdiff >> http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/specdiff-2020-05-11-38dd763d023e-2020-05-15-88a83f7238d8/overview-summary.html >> >> >> Latest implementation webrev >> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev-2020-05-16-default-2020-05-15-88a83f7238d8/webrev/ >> >> Incremental Implementation webrev >> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev-2020-05-11-38dd763d023e-2020-05-15-88a83f7238d8/webrev/ >> >> Latest test webrev >> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev-2020-05-16-default-2020-05-15-88a83f7238d8/webrev/ >> >> Incremental test webrev >> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev-2020-05-11-38dd763d023e-2020-05-15-88a83f7238d8/webrev/ >> >> >>> On Apr 1, 2020, at 3:46 PM, Paul Sandoz wrote: >>> >>> Hi, >>> >>> A prior email sent out a request for review of the Vector API in preparation for JEP 338: Vector API (Incubator) [1] to be proposed for target: >>> >>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html >>> >>> This email expands the review of the API to the Java implementation and Java tests: >>> >>> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev/webrev/ >>> >>> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev/webrev/ >>> >>> (Further emails will sent for review of general HotSpot changes CPU architecture specific HotSpot changes, x64 and aarch64, and performance tests. For an early peek see the links in the description of JDK-8223347.) >>> >>> ? >>> >>> The Vector API provides >>> >>> - the public Vector class with vector operations common to all supported primitive types >>> >>> - public primitive specializations, such as IntVector, with common operations associated with the primitive type >>> >>> - internal concrete specializations for the vector size, such as Int256Vector, for a vector holding 8 ints. >>> >>> Operations generally defer to one of approximately 20 vector intrinsics. Some operations may be composed of other operations. >>> >>> Explicit casts are performed by vector operations to ensure vectors arguments are of the required shape (bit size) and element type. >>> >>> A vector intrinsic is an internal low-level vector operation. The last argument to the intrinsic is fall back behavior in Java, implementing the scalar operation over the number of elements held by the vector. Thus, If the intrinsic is not supported in C2 for the other arguments then the Java implementation is executed (the Java implementation is always executed when running in the interpreter or for C1). >>> >>> The public primitive specializations and the internal concrete implementations are generated from SSP template files, X-Vector.java.template and X-VectorBits.java.template respectively. >>> >>> Overall the implementation approach is quite formulaic and rather repetitive. Once you grok the pattern It should be easier to review if a little laborious. >>> >>> Unit tests are auto-generated by composing templates for each operation into an SSP template file which is then used to generate unit test files for each concrete vector class. The tests are quite extensive and have found many a HotSpot issue in development across a wide range of platforms. >>> >>> Paul. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8201271 >>> >> > From david.holmes at oracle.com Wed May 20 02:31:03 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 May 2020 12:31:03 +1000 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> Message-ID: <991bd925-f418-a605-6450-fd11db8dd7c0@oracle.com> Hi Serguei, On 20/05/2020 1:49 am, serguei.spitsyn at oracle.com wrote: > Hi Harold and David, > > Just one comment. > We could save on the CSR's for: > ? make/data/jdwp/jdwp.spec > || src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > || > src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java Just to be clear, you don't need a CSR request per change but each change must be covered by some CSR request. > As we discussed with David, it could make sense to remove duplication in > the Serviceability class redefinition and retransformation specs. > I'd suggest something like this webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/redef-spec-dedup.1/ > > If the direction looks okay then I could file RFE+CSR (and post an RFR). I like the idea of keeping one list referred to by the other specs! Thanks, David ----- > Thanks, > Serguei > > > On 5/18/20 22:26, David Holmes wrote: >> Hi Harold, >> >> Adding serviceability-dev for the serviceability related changes. >> >> Nit: "VM support for sealed classes" >> >> This RFR covers the VM, core-libs, serviceability and even some >> langtools tests. AFAICS only the javac changes are not included here >> so when and where will they be reviewed and under what bug id? Ideally >> there will be a single JBS issue for "Implementation of JEP 360: >> Sealed types". It's okay to break up the RFRs across different areas, >> but it should be done under one bug id. >> >> Overall this looks good. I've looked at all files and mainly have some >> style nits in various places. But there are some more significant >> items below. >> >> On 14/05/2020 7:09 am, Harold Seigel wrote: >>> Hi, >>> >>> Please review this patch for JVM and Core-libs support for the JEP >>> 360 Sealed Classes preview feature.? Code changes include the following: >>> >>> ??* Processing of the new PermittedSubclasses attribute to enforce that >>> ??? a class or interface, whose super is a sealed class or interface, >>> ??? must be listed in the super's PermittedSubclasses attribute. >>> ??* Disallow redefinition of a sealed class or interface if its >>> ??? redefinition would change its PermittedSubclasses attribute. >>> ??* Support API's to determine if a class or interface is sealed and, if >>> ??? it's sealed, return a list of its permitted subclasses. >>> ??* asm support for the PermittedSubclasses attribute >> >> I assume Remi is providing the upstream support in ASM? :) But also >> see below ... >> >>> >>> Open Webrev: >>> http://cr.openjdk.java.net/~vromero/8225056/webrev.00/index.html >> >> make/data/jdwp/jdwp.spec >> >> There needs to be a sub-task and associated CSR request for this JDWP >> spec update. I couldn't see this covered anywhere. >> >> --- >> >> src/hotspot/share/classfile/classFileParser.cpp >> >> 3215 u2 >> ClassFileParser::parse_classfile_permitted_subclasses_attribute(const >> ClassFileStream* const cfs, >> 3216 const u1* const permitted_subclasses_attribute_start, >> 3217 TRAPS) { >> >> Indention on L3216/17 needs fixing after the copy'n'edit. >> >> 3515?? return _major_version == JVM_CLASSFILE_MAJOR_VERSION && >> 3516????????????? _minor_version == JAVA_PREVIEW_MINOR_VERSION && >> 3517????????????? Arguments::enable_preview(); >> >> Too much indentation on L3516/17 >> >> 3790???????????????? // Check for PermittedSubclasses tag >> >> That comment (copied from my nestmates code :) is in the wrong place. >> It needs to be before >> >> 3788???????????? if (tag == vmSymbols::tag_permitted_subclasses()) { >> >> >> Minor nit: I would suggest checking >> parsed_permitted_subclasses_attribute before checking ACC_FINAL. >> >> 3876?? if (parsed_permitted_subclasses_attribute) { >> 3877???? const u2 num_of_subclasses = >> parse_classfile_permitted_subclasses_attribute( >> 3878??????????????????????????????????? cfs, >> 3879 permitted_subclasses_attribute_start, >> 3880??????????????????????????????????? CHECK); >> >> Although it looks odd the preceding, similarly shaped, sections all >> indent to the same absolute position. Can you make L3878/78/80 match >> please. >> >> 3882?????? guarantee_property( >> 3883???????? permitted_subclasses_attribute_length == >> 3884?????????? sizeof(num_of_subclasses) + sizeof(u2) * >> num_of_subclasses, >> 3885???????? "Wrong PermittedSubclasses attribute length in class file >> %s", CHECK); >> >> Nits: please reformat as: >> >> 3882?????? guarantee_property( >> 3883???????? permitted_subclasses_attribute_length == >> sizeof(num_of_subclasses) + sizeof(u2) * num_of_subclasses, >> 3885???????? "Wrong PermittedSubclasses attribute length in class file >> %s", CHECK); >> >> It would also look slightly better if you shortened the name of the >> num_of_subclasses variable. >> >> --- >> >> src/hotspot/share/classfile/classFileParser.hpp >> >> +?? u2 parse_classfile_permitted_subclasses_attribute(const >> ClassFileStream* const cfs, >> +???????????????????????????????????????????? const u1* const >> permitted_subclasses_attribute_start, >> +???????????????????????????????????????????? TRAPS); >> >> Please fix indentation after copy'n'edit. >> >> --- >> >> src/hotspot/share/oops/instanceKlass.cpp >> >> ?247?? if (classloader1 != classloader2) { >> >> I'm not clear what rule this is verifying. The same module check >> follows this one. The rule is that the subclass must be accessible to >> the superclass implying: >> 1. same named module (regardless of class access modifiers); or >> 2. (implicitly in un-named module) same package if subclass not >> public; or >> 3. public subclass >> >> Having the same classloader implies same package, but that alone >> doesn't address 2 or 3. So this doesn't conform to proposed JVMS rules. >> >> >> ?264???? if (_constants->tag_at(cp_index).is_klass()) { >> ?265?????? Klass* k2 = _constants->klass_at(cp_index, CHECK_false); >> >> You've copied this code from the nestmember checks but your changes >> don't quite make sense to me. If we have already checked is_klass() >> then klass_at() cannot lead to any exceptions. >> >> ?272?????? if (name == k->name()) { >> ?273???????? log_trace(class, sealed)("- Found it at >> permitted_subclasses[%d] => cp[%d]", i, cp_index); >> ?274???????? return true; >> >> I was wondering why you don't resolve the cp entry when you find the >> name matches, as we do for nest members, but realized that unlike the >> nest membership check, which can happen many times for a given class, >> this permitted subclass check can only happen once per class. As you >> don't actually resolve here, and given that the earlier check cannot >> throw exceptions, it follows that the entire method never results in >> any exceptions and so callers should not be using the CHECK macro. >> >> --- >> >> src/hotspot/share/oops/method.cpp >> >> I don't understand how knowing the class is sealed allows you to infer >> that a non-final method is actually final ?? >> >> --- >> >> ?src/hotspot/share/prims/jvm.cpp >> >> It would be simpler (and cheaper) if the Java side of this ensures it >> doesn't call into the VM with an array or primitive class. >> >> --- >> >> ?src/hotspot/share/prims/jvmti.xml >> >> The JVM TI spec changes also need to be covered by a CSR request. >> >> --- >> >> src/hotspot/share/prims/jvmtiRedefineClasses.cpp >> >> We should file a RFE to refactor the logic that checks that an >> attribute consisting of a list of classes has not changed. :) >> >> Aside: I spotted a bug in the nest member code (missing NULL check!) >> thanks to your change :) >> >> --- >> >> src/java.base/share/classes/java/lang/Class.java >> >> There needs to be a CSR request for these changes. >> >> +????? * Returns an array containing {@code ClassDesc} objects >> representing all the >> +????? * permitted subclasses of this {@linkplain Class} if it is >> sealed. Returns an empty array if this >> +????? * {@linkplain Class} is not sealed. >> >> should add "or this class represents an array or primitive type" >> (using the standard wording for such cases). >> >> +????? * @throws IllegalArgumentException if a class descriptor is not >> in the correct format >> >> IllegalArgumentException is not an appropriate exception to use as >> this method takes no arguments. If the class descriptor is not valid >> and it comes from the VM then I think we have a problem with how the >> VM validates class descriptors. Any IAE from ClassDesc.of should be >> caught and converted to a more suitable exception type - preferably >> InternalError if the VM should always return valid strings. >> >> +???? public ClassDesc[] getPermittedSubclasses() { >> >> As mentioned for jvm.cpp this Java code should do the isArray() and >> isPrimitive() check before calling the VM. >> >> +???????? String[] descriptors = getPermittedSubclasses0(); >> >> Nit: what you get from the VM are not descriptors, just name strings >> in internal form. This wouldn't really matter except it then looks >> strange to call ClassDesc.of(...) instead of ClassDesc.ofDescriptor(...). >> >> +???????? if (descriptors == null >> >> The VM never returns null. >> >> +???????? return getPermittedSubclasses().length != 0; >> >> It's grossly inefficient to create the ClassDesc array and then throw >> it away IMO. The result should be cached either in a field of Class or >> in the ReflectionData of the class. >> >> --- >> >> src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java >> >> >> !???????? // - The offset of the PermittedSubclasses attribute, or 0 >> ????????? int permittedSubtypesOffset = 0; >> >> Obviously ASM already has some prelim support for sealed classes, but >> now that the attribute has been renamed that should also flow through >> to the ASM code ie the variable, not just the comment. >> >> Ditto for ClassWriter.java and its fields. >> >> --- >> >> src/java.base/share/native/libjava/Class.c >> >> ????? {"isRecord0",??????????? "()Z",???????? (void *)&JVM_IsRecord}, >> +???? {"getPermittedSubclasses0", "()[" STR,??? (void >> *)&JVM_GetPermittedSubclasses}, >> >> please align (void >> >> --- >> >> src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java >> >> src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java >> >> There needs to be a CSR for these changes too. >> >> --- >> >> test/langtools/tools/javac/processing/model/TestSourceVersion.java >> >> !??????????????????? // Assume "record" and "sealed" will be >> restricted keywords. >> !??????????????????? "record", "sealed"); >> >> What about the non-sealed keyword defined in the JEP? >> >> --- >> >> In the tests you don't need to explicitly include >> sun.hotspot.WhiteBox$WhiteBoxPermission on the ClassFileInstaller >> invocation. (previous RFE's have been removing existing occurrences >> after the CFI was fixed to handle it internally). >> >> Please ensure all new tests have an @bug 8225056 (or whatever the >> actual JBS issue will be) >> >> All test classes (and thus files) should be named in camel-case i.e. >> C1 not c1, C2 not c2, SuperClass not superClass etc. >> >> >> test/hotspot/jtreg/runtime/modules/sealedP1/superClass.jcod >> test/hotspot/jtreg/runtime/sealedClasses/Pkg/sealedInterface.jcod >> >> Please add comments clarifying why these must be jcod files. >> >> --- >> >> That's it from me. >> >> Thanks, >> David >> ----- >> >> >> >>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8225056 >>> >>> Java Language Spec changes: >>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html >>> >>> >>> JVM Spec changes: >>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jvms.html >>> >>> >>> JEP 360: https://bugs.openjdk.java.net/browse/JDK-8227043 >>> >>> JVM CSR: https://bugs.openjdk.java.net/browse/JDK-8242578 >>> >>> Changes to javac and other language tools will be reviewed separately. >>> >>> Thanks, Harold >>> >>> > From serguei.spitsyn at oracle.com Wed May 20 04:05:19 2020 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 19 May 2020 21:05:19 -0700 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: <991bd925-f418-a605-6450-fd11db8dd7c0@oracle.com> References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> <991bd925-f418-a605-6450-fd11db8dd7c0@oracle.com> Message-ID: <8005c048-24cd-81f2-4358-7d71ab362ef2@oracle.com> Hi David, On 5/19/20 19:31, David Holmes wrote: > Hi Serguei, > > On 20/05/2020 1:49 am, serguei.spitsyn at oracle.com wrote: >> Hi Harold and David, >> >> Just one comment. >> We could save on the CSR's for: >> ?? make/data/jdwp/jdwp.spec >> || src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java >> || >> src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java > > Just to be clear, you don't need a CSR request per change but each > change must be covered by some CSR request. Oh, right. I was confused by your comments against each change. >> As we discussed with David, it could make sense to remove duplication >> in the Serviceability class redefinition and retransformation specs. >> I'd suggest something like this webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2020/redef-spec-dedup.1/ >> >> If the direction looks okay then I could file RFE+CSR (and post an RFR). > > I like the idea of keeping one list referred to by the other specs! Thanks, I've started this. Probably, it is better to wait until this fix is pushed. Thanks, Serguei > Thanks, > David > ----- > >> Thanks, >> Serguei >> >> >> On 5/18/20 22:26, David Holmes wrote: >>> Hi Harold, >>> >>> Adding serviceability-dev for the serviceability related changes. >>> >>> Nit: "VM support for sealed classes" >>> >>> This RFR covers the VM, core-libs, serviceability and even some >>> langtools tests. AFAICS only the javac changes are not included here >>> so when and where will they be reviewed and under what bug id? >>> Ideally there will be a single JBS issue for "Implementation of JEP >>> 360: Sealed types". It's okay to break up the RFRs across different >>> areas, but it should be done under one bug id. >>> >>> Overall this looks good. I've looked at all files and mainly have >>> some style nits in various places. But there are some more >>> significant items below. >>> >>> On 14/05/2020 7:09 am, Harold Seigel wrote: >>>> Hi, >>>> >>>> Please review this patch for JVM and Core-libs support for the JEP >>>> 360 Sealed Classes preview feature.? Code changes include the >>>> following: >>>> >>>> ??* Processing of the new PermittedSubclasses attribute to enforce >>>> that >>>> ??? a class or interface, whose super is a sealed class or interface, >>>> ??? must be listed in the super's PermittedSubclasses attribute. >>>> ??* Disallow redefinition of a sealed class or interface if its >>>> ??? redefinition would change its PermittedSubclasses attribute. >>>> ??* Support API's to determine if a class or interface is sealed >>>> and, if >>>> ??? it's sealed, return a list of its permitted subclasses. >>>> ??* asm support for the PermittedSubclasses attribute >>> >>> I assume Remi is providing the upstream support in ASM? :) But also >>> see below ... >>> >>>> >>>> Open Webrev: >>>> http://cr.openjdk.java.net/~vromero/8225056/webrev.00/index.html >>> >>> make/data/jdwp/jdwp.spec >>> >>> There needs to be a sub-task and associated CSR request for this >>> JDWP spec update. I couldn't see this covered anywhere. >>> >>> --- >>> >>> src/hotspot/share/classfile/classFileParser.cpp >>> >>> 3215 u2 >>> ClassFileParser::parse_classfile_permitted_subclasses_attribute(const >>> ClassFileStream* const cfs, >>> 3216 const u1* const permitted_subclasses_attribute_start, >>> 3217 TRAPS) { >>> >>> Indention on L3216/17 needs fixing after the copy'n'edit. >>> >>> 3515?? return _major_version == JVM_CLASSFILE_MAJOR_VERSION && >>> 3516????????????? _minor_version == JAVA_PREVIEW_MINOR_VERSION && >>> 3517????????????? Arguments::enable_preview(); >>> >>> Too much indentation on L3516/17 >>> >>> 3790???????????????? // Check for PermittedSubclasses tag >>> >>> That comment (copied from my nestmates code :) is in the wrong >>> place. It needs to be before >>> >>> 3788???????????? if (tag == vmSymbols::tag_permitted_subclasses()) { >>> >>> >>> Minor nit: I would suggest checking >>> parsed_permitted_subclasses_attribute before checking ACC_FINAL. >>> >>> 3876?? if (parsed_permitted_subclasses_attribute) { >>> 3877???? const u2 num_of_subclasses = >>> parse_classfile_permitted_subclasses_attribute( >>> 3878??????????????????????????????????? cfs, >>> 3879 permitted_subclasses_attribute_start, >>> 3880??????????????????????????????????? CHECK); >>> >>> Although it looks odd the preceding, similarly shaped, sections all >>> indent to the same absolute position. Can you make L3878/78/80 match >>> please. >>> >>> 3882?????? guarantee_property( >>> 3883???????? permitted_subclasses_attribute_length == >>> 3884?????????? sizeof(num_of_subclasses) + sizeof(u2) * >>> num_of_subclasses, >>> 3885???????? "Wrong PermittedSubclasses attribute length in class >>> file %s", CHECK); >>> >>> Nits: please reformat as: >>> >>> 3882?????? guarantee_property( >>> 3883???????? permitted_subclasses_attribute_length == >>> sizeof(num_of_subclasses) + sizeof(u2) * num_of_subclasses, >>> 3885???????? "Wrong PermittedSubclasses attribute length in class >>> file %s", CHECK); >>> >>> It would also look slightly better if you shortened the name of the >>> num_of_subclasses variable. >>> >>> --- >>> >>> src/hotspot/share/classfile/classFileParser.hpp >>> >>> +?? u2 parse_classfile_permitted_subclasses_attribute(const >>> ClassFileStream* const cfs, >>> +???????????????????????????????????????????? const u1* const >>> permitted_subclasses_attribute_start, >>> +???????????????????????????????????????????? TRAPS); >>> >>> Please fix indentation after copy'n'edit. >>> >>> --- >>> >>> src/hotspot/share/oops/instanceKlass.cpp >>> >>> ?247?? if (classloader1 != classloader2) { >>> >>> I'm not clear what rule this is verifying. The same module check >>> follows this one. The rule is that the subclass must be accessible >>> to the superclass implying: >>> 1. same named module (regardless of class access modifiers); or >>> 2. (implicitly in un-named module) same package if subclass not >>> public; or >>> 3. public subclass >>> >>> Having the same classloader implies same package, but that alone >>> doesn't address 2 or 3. So this doesn't conform to proposed JVMS rules. >>> >>> >>> ?264???? if (_constants->tag_at(cp_index).is_klass()) { >>> ?265?????? Klass* k2 = _constants->klass_at(cp_index, CHECK_false); >>> >>> You've copied this code from the nestmember checks but your changes >>> don't quite make sense to me. If we have already checked is_klass() >>> then klass_at() cannot lead to any exceptions. >>> >>> ?272?????? if (name == k->name()) { >>> ?273???????? log_trace(class, sealed)("- Found it at >>> permitted_subclasses[%d] => cp[%d]", i, cp_index); >>> ?274???????? return true; >>> >>> I was wondering why you don't resolve the cp entry when you find the >>> name matches, as we do for nest members, but realized that unlike >>> the nest membership check, which can happen many times for a given >>> class, this permitted subclass check can only happen once per class. >>> As you don't actually resolve here, and given that the earlier check >>> cannot throw exceptions, it follows that the entire method never >>> results in any exceptions and so callers should not be using the >>> CHECK macro. >>> >>> --- >>> >>> src/hotspot/share/oops/method.cpp >>> >>> I don't understand how knowing the class is sealed allows you to >>> infer that a non-final method is actually final ?? >>> >>> --- >>> >>> ?src/hotspot/share/prims/jvm.cpp >>> >>> It would be simpler (and cheaper) if the Java side of this ensures >>> it doesn't call into the VM with an array or primitive class. >>> >>> --- >>> >>> ?src/hotspot/share/prims/jvmti.xml >>> >>> The JVM TI spec changes also need to be covered by a CSR request. >>> >>> --- >>> >>> src/hotspot/share/prims/jvmtiRedefineClasses.cpp >>> >>> We should file a RFE to refactor the logic that checks that an >>> attribute consisting of a list of classes has not changed. :) >>> >>> Aside: I spotted a bug in the nest member code (missing NULL check!) >>> thanks to your change :) >>> >>> --- >>> >>> src/java.base/share/classes/java/lang/Class.java >>> >>> There needs to be a CSR request for these changes. >>> >>> +????? * Returns an array containing {@code ClassDesc} objects >>> representing all the >>> +????? * permitted subclasses of this {@linkplain Class} if it is >>> sealed. Returns an empty array if this >>> +????? * {@linkplain Class} is not sealed. >>> >>> should add "or this class represents an array or primitive type" >>> (using the standard wording for such cases). >>> >>> +????? * @throws IllegalArgumentException if a class descriptor is >>> not in the correct format >>> >>> IllegalArgumentException is not an appropriate exception to use as >>> this method takes no arguments. If the class descriptor is not valid >>> and it comes from the VM then I think we have a problem with how the >>> VM validates class descriptors. Any IAE from ClassDesc.of should be >>> caught and converted to a more suitable exception type - preferably >>> InternalError if the VM should always return valid strings. >>> >>> +???? public ClassDesc[] getPermittedSubclasses() { >>> >>> As mentioned for jvm.cpp this Java code should do the isArray() and >>> isPrimitive() check before calling the VM. >>> >>> +???????? String[] descriptors = getPermittedSubclasses0(); >>> >>> Nit: what you get from the VM are not descriptors, just name strings >>> in internal form. This wouldn't really matter except it then looks >>> strange to call ClassDesc.of(...) instead of >>> ClassDesc.ofDescriptor(...). >>> >>> +???????? if (descriptors == null >>> >>> The VM never returns null. >>> >>> +???????? return getPermittedSubclasses().length != 0; >>> >>> It's grossly inefficient to create the ClassDesc array and then >>> throw it away IMO. The result should be cached either in a field of >>> Class or in the ReflectionData of the class. >>> >>> --- >>> >>> src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java >>> >>> >>> !???????? // - The offset of the PermittedSubclasses attribute, or 0 >>> ????????? int permittedSubtypesOffset = 0; >>> >>> Obviously ASM already has some prelim support for sealed classes, >>> but now that the attribute has been renamed that should also flow >>> through to the ASM code ie the variable, not just the comment. >>> >>> Ditto for ClassWriter.java and its fields. >>> >>> --- >>> >>> src/java.base/share/native/libjava/Class.c >>> >>> ????? {"isRecord0",??????????? "()Z",???????? (void *)&JVM_IsRecord}, >>> +???? {"getPermittedSubclasses0", "()[" STR,??? (void >>> *)&JVM_GetPermittedSubclasses}, >>> >>> please align (void >>> >>> --- >>> >>> src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java >>> >>> src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java >>> >>> There needs to be a CSR for these changes too. >>> >>> --- >>> >>> test/langtools/tools/javac/processing/model/TestSourceVersion.java >>> >>> !??????????????????? // Assume "record" and "sealed" will be >>> restricted keywords. >>> !??????????????????? "record", "sealed"); >>> >>> What about the non-sealed keyword defined in the JEP? >>> >>> --- >>> >>> In the tests you don't need to explicitly include >>> sun.hotspot.WhiteBox$WhiteBoxPermission on the ClassFileInstaller >>> invocation. (previous RFE's have been removing existing occurrences >>> after the CFI was fixed to handle it internally). >>> >>> Please ensure all new tests have an @bug 8225056 (or whatever the >>> actual JBS issue will be) >>> >>> All test classes (and thus files) should be named in camel-case i.e. >>> C1 not c1, C2 not c2, SuperClass not superClass etc. >>> >>> >>> test/hotspot/jtreg/runtime/modules/sealedP1/superClass.jcod >>> test/hotspot/jtreg/runtime/sealedClasses/Pkg/sealedInterface.jcod >>> >>> Please add comments clarifying why these must be jcod files. >>> >>> --- >>> >>> That's it from me. >>> >>> Thanks, >>> David >>> ----- >>> >>> >>> >>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8225056 >>>> >>>> Java Language Spec changes: >>>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html >>>> >>>> >>>> JVM Spec changes: >>>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jvms.html >>>> >>>> >>>> JEP 360: https://bugs.openjdk.java.net/browse/JDK-8227043 >>>> >>>> JVM CSR: https://bugs.openjdk.java.net/browse/JDK-8242578 >>>> >>>> Changes to javac and other language tools will be reviewed separately. >>>> >>>> Thanks, Harold >>>> >>>> >> From james.laskey at oracle.com Wed May 20 11:54:55 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 20 May 2020 08:54:55 -0300 Subject: RFR (CSR) JDK-8245399 Remove addition preview adornment from String::formatted In-Reply-To: <4D744464-3018-48E2-BF9B-3D089EB4AD75@oracle.com> References: <4D744464-3018-48E2-BF9B-3D089EB4AD75@oracle.com> Message-ID: <7BFBA125-77EB-44A9-8086-7BE3CEF28293@oracle.com> All call for aid response to a comment on the CSR from Joe. > I suggesting having some explicit statement about the line count in addition to the number of line terminators. That is the crux of the skirting around. Line count can mean two things depending on whether lines are interpreted as a) character sequences separated by line terminators (\r, \n) or b) character sequences terminated by line terminators. If we state one thing a) then a developer will state, no it's b). It all depends on what the developer does next. Generally, core libraries (String::split, String::lines, String::stripIndent) interpret lines using a) with the option of having a final line terminator which then kind of looks like b). String::lines tries to make this clear, "stream of lines extracted from this string, separated by line terminators.", but you can still have the optional final line terminator (as does String::split("\\R")). Files::lines and BufferedReader::lines side-step the issue all together (assumptions left to the user.) Any wordsmything assistance would be appreciated, -- Jim > On May 19, 2020, at 5:00 PM, Jim Laskey wrote: > > Please review this change to remove the preview heading from the javadoc of String::formatted. This also updates the @since to 15. > > Thank you. > > Cheers, > > -- Jim > > > csr: https://bugs.openjdk.java.net/browse/JDK-8245399 > jbs: https://bugs.openjdk.java.net/browse/JDK-8245398 > > From maurizio.cimadamore at oracle.com Wed May 20 14:01:59 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 20 May 2020 15:01:59 +0100 Subject: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator) In-Reply-To: <543817be-92d5-d6b1-d8e5-88f6fd3f3346@oracle.com> References: <7a96ec1b-cdec-1e3f-f6ca-102d7340e70a@oracle.com> <271da482-cdbc-1d53-2ddd-efcb3a62ddff@oracle.com> <543817be-92d5-d6b1-d8e5-88f6fd3f3346@oracle.com> Message-ID: <9beb2729-4ab8-deda-fc92-b4550fdfbb4e@oracle.com> Another very small iteration which fixes a gap in the javadoc specification for MemorySegment::toArray (thanks Chris!) Webrev: http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev Delta webrev: http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev_delta/ Cheers Maurizio On 13/05/2020 13:12, Maurizio Cimadamore wrote: > Another iteration which addresses the latest CSR comments (the CSR has > now been approved): > > * make MemorySegment::withAccessModes/hasAccessMode throw > IllegalArgumentException in cases where the provided mask is invalid > (this required a test tweak) > * sprinkled a couple of references to the JLS in the package javadoc, > as per CSR suggestions > * Fixed the ParallelSum::findAny_bulk benchmarks, which were > (erroneously) not testing all the elements in the segment > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v4/webrev > > Delta webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v4/webrev_delta/ > > > Cheers > Maurizio > > On 01/05/2020 12:06, Maurizio Cimadamore wrote: >> Latest iteration - the follow issues were addressed: >> >> * fix a bug with alignment of native segments triggering spurious >> failures (contributed by Jorn) >> * fix javadoc and tests for access modes (contributed by Chris) >> * added benchmarks for Stream::findAny using segment spliterator >> (contributed by Peter) >> * addressed CSR comments >> >> Webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/8243491_v3/webrev >> >> Delta webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/8243491_v3/webrev_delta/ >> >> Javadoc: >> >> http://cr.openjdk.java.net/~mcimadamore/8243491_v3/javadoc >> >> Specdiff: >> >> http://cr.openjdk.java.net/~mcimadamore/8243491_v3/specdiff/overview-summary.html >> >> >> >> Cheers >> Maurizio >> >> On 27/04/2020 13:13, Maurizio Cimadamore wrote: >>> Another iteration, which addresses the following issues: >>> >>> * wrong copyright headers in certain tests >>> * issue with TestNative when running in debug mode caused by >>> mismatched malloc/os::free (contributed by Jorn) >>> * clarify javadoc of MemoryHandles::withStride >>> * improved implementation of MemoryAccessVarHandleGenerator to use >>> hidden classes rather than Unsafe.dAC (contributed by Mandy) >>> >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~mcimadamore/8243491_v2/webrev >>> >>> Delta webrev: >>> >>> http://cr.openjdk.java.net/~mcimadamore/8243491_v2/webrev_delta/ >>> >>> Javadoc: >>> >>> http://cr.openjdk.java.net/~mcimadamore/8243491_v2/javadoc >>> >>> Specdiff: >>> >>> http://cr.openjdk.java.net/~mcimadamore/8243491_v2/specdiff/overview-summary.html >>> >>> >>> >>> Cheers >>> Maurizio >>> >>> >>> On 23/04/2020 21:33, Maurizio Cimadamore wrote: >>>> Hi, >>>> time has come for another round of foreign memory access API >>>> incubation (see JEP 383 [3]). This iteration aims at polishing some >>>> of the rough edges of the API, and adds some of the functionalities >>>> that developers have been asking for during this first round of >>>> incubation. The revised API tightens the thread-confinement >>>> constraints (by removing the MemorySegment::acquire method) and >>>> instead provides more targeted support for parallel computation via >>>> a segment spliterator. The API also adds a way to create a custom >>>> native segment; this is, essentially, an unsafe API point, very >>>> similar in spirit to the JNI NewDirectByteBuffer functionality [1]. >>>> By using this bit of API,? power-users will be able to add support, >>>> via MemorySegment, to *their own memory sources* (e.g. think of a >>>> custom allocator written in C/C++). For now, this API point is >>>> called off as "restricted" and a special read-only JDK property >>>> will have to be set on the command line for calls to this method to >>>> succeed. We are aware there's no precedent for something like this >>>> in the Java SE API - but if Project Panama is to remain true about >>>> its ultimate goal of replacing bits of JNI code with (low level) >>>> Java code, stuff like this has to be *possible*. We anticipate >>>> that, at some point, this property will become a true launcher >>>> flag, and that the foreign restricted machinery will be integrated >>>> more neatly into the module system. >>>> >>>> A list of the API, implementation and test changes is provided >>>> below. If you have any questions, or need more detailed >>>> explanations, I (and the rest of the Panama team) will be happy to >>>> point at existing discussions, and/or to provide the feedback >>>> required. >>>> >>>> Thanks >>>> Maurizio >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/8243491_v1/webrev >>>> >>>> Javadoc: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/8243491_v1/javadoc >>>> >>>> Specdiff: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/8243491_v1/specdiff/overview-summary.html >>>> >>>> >>>> CSR: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8243496 >>>> >>>> >>>> >>>> API changes >>>> =========== >>>> >>>> * MemorySegment >>>> ? - drop support for acquire() method - in its place now you can >>>> obtain a spliterator from a segment, which supports divide-and-conquer >>>> ? - revamped support for views - e.g. isReadOnly - now segments >>>> have access modes >>>> ? - added API to do serial confinement hand-off >>>> (MemorySegment::withOwnerThread) >>>> ? - added unsafe factory to construct a native segment out of an >>>> existing address; this API is "restricted" and only available if >>>> the program is executed using the -Dforeign.unsafe=permit flag. >>>> ? - the MemorySegment::mapFromPath now returns a MappedMemorySegment >>>> * MappedMemorySegment >>>> ? - small sub-interface which provides extra capabilities for >>>> mapped segments (load(), unload() and force()) >>>> * MemoryAddress >>>> ? - added distinction between *checked* and *unchecked* addresses; >>>> *unchecked* addresses do not have a segment, so they cannot be >>>> dereferenced >>>> ? - added NULL memory address (it's an unchecked address) >>>> ? - added factory to construct MemoryAddress from long value >>>> (result is also an unchecked address) >>>> ? - added API point to get raw address value (where possible - e.g. >>>> if this is not an address pointing to a heap segment) >>>> * MemoryLayout >>>> ? - Added support for layout "attributes" - e.g. store metadata >>>> inside MemoryLayouts >>>> ? - Added MemoryLayout::isPadding predicate >>>> ? - Added helper function to SequenceLayout to rehape/flatten >>>> sequence layouts (a la NDArray [4]) >>>> * MemoryHandles >>>> ? - add support for general VarHandle combinators (similar to MH >>>> combinators) >>>> ? - add a combinator to turn a long-VH into a MemoryAddress VH (the >>>> resulting MemoryAddress is also *unchecked* and cannot be >>>> dereferenced) >>>> >>>> Implementation changes >>>> ====================== >>>> >>>> * add support for VarHandle combinators (e.g. IndirectVH) >>>> >>>> The idea here is simple: a VarHandle can almost be thought of as a >>>> set of method handles (one for each access mode supported by the >>>> var handle) that are lazily linked. This gives us a relatively >>>> simple idea upon which to build support for custom var handle >>>> adapters: we could create a VarHandle by passing an existing var >>>> handle and also specify the set of adaptations that should be >>>> applied to the method handle for a given access mode in the >>>> original var handle. The result is a new VarHandle which might >>>> support a different carrier type and more, or less coordinate >>>> types. Adding this support was relatively easy - and it only >>>> required one low-level surgery of the lambda forms generated for >>>> adapted var handle (this is required so that the "right" var handle >>>> receiver can be used for dispatching the access mode call). >>>> >>>> All the new adapters in the MemoryHandles API (which are really >>>> defined inside VarHandles) are really just a bunch of MH adapters >>>> that are stitched together into a brand new VH. The only caveat is >>>> that, we could have a checked exception mismatch: the VarHandle API >>>> methods are specified not to throw any checked exception, whereas >>>> method handles can throw any throwable. This means that, >>>> potentially, calling get() on an adapted VarHandle could result in >>>> a checked exception being thrown; to solve this gnarly issue, we >>>> decided to scan all the filter functions passed to the VH >>>> combinators and look for direct method handles which throw checked >>>> exceptions. If such MHs are found (these can be deeply nested, >>>> since the MHs can be adapted on their own), adaptation of the >>>> target VH fails fast. >>>> >>>> >>>> * More ByteBuffer implementation changes >>>> >>>> Some more changes to ByteBuffer support were necessary here. First, >>>> we have added support for retrieval of "mapped" properties >>>> associated with a ByteBuffer (e.g. the file descriptor, etc.). This >>>> is crucial if we want to be able to turn an existing byte buffer >>>> into the "right kind" of memory segment. >>>> >>>> Conversely, we also have to allow creation of mapped byte buffers >>>> given existing parameters - which is needed when going from >>>> (mapped) segment to a buffer. These two pieces together allow us to >>>> go from segment to buffer and back w/o losing any information about >>>> the underlying memory mapping (which was an issue in the previous >>>> implementation). >>>> >>>> Lastly, to support the new MappedMemorySegment abstraction, all the >>>> memory mapped supporting functionalities have been moved into a >>>> common helper class so that MappedMemorySegmentImpl can reuse that >>>> (e.g. for MappedMemorySegment::force). >>>> >>>> * Rewritten memory segment hierarchy >>>> >>>> The old implementation had a monomorphic memory segment class. In >>>> this round we aimed at splitting the various implementation classes >>>> so that we have a class for heap segments (HeapMemorySegmentImpl), >>>> one for native segments (NativeMemorySegmentImpl) and one for >>>> memory mapped segments (MappedMemorySegmentImpl, which extends from >>>> NativeMemorySegmentImpl). Not much to see here - although one >>>> important point is that, by doing this, we have been able to speed >>>> up performances quite a bit, since now e.g. native/mapped segments >>>> are _guaranteed_ to have a null "base". We have also done few >>>> tricks to make sure that the "base" accessor for heap segment is >>>> sharply typed and also NPE checked, which allows C2 to speculate >>>> more and hoist. With these changes _all_ segment types have >>>> comparable performances and hoisting guarantees (unlike in the old >>>> implementation). >>>> >>>> * Add workarounds in MemoryAddressProxy, AbstractMemorySegmentImpl >>>> to special case "small segments" so that VM can apply bound check >>>> elimination >>>> >>>> This is another important piece which allows to get very good >>>> performances out of indexes memory access var handles; as you might >>>> know, the JIT compiler has troubles in optimizing loops where the >>>> loop variable is a long [2]. To make up for that, in this round we >>>> add an optimization which allows the API to detect whether a >>>> segment is *small* or *large*. For small segments, the API realizes >>>> that there's no need to perform long computation (e.g. to perform >>>> bound checks, or offset additions), so it falls back to integer >>>> logic, which in turns allows bound check elimination. >>>> >>>> * renaming of the various var handle classes to conform to "memory >>>> access var handle" terminology >>>> >>>> This is mostly stylistic, nothing to see here. >>>> >>>> Tests changes >>>> ============= >>>> >>>> In addition to the tests for the new API changes, we've also added >>>> some stress tests for var handle combinators - e.g. there's a flag >>>> that can be enabled which turns on some "dummy" var handle >>>> adaptations on all var handles created by the runtime. We've used >>>> this flag on existing tests to make sure that things work as expected. >>>> >>>> To sanity test the new memory segment spliterator, we have wired >>>> the new segment spliterator with the existing spliterator test >>>> harness. >>>> >>>> We have also added several micro benchmarks for the memory segment >>>> API (and made some changes to the build script so that native >>>> libraries would be handled correctly). >>>> >>>> >>>> [1] - >>>> https://docs.oracle.com/en/java/javase/14/docs/specs/jni/functions.html#newdirectbytebuffer >>>> [2] - https://bugs.openjdk.java.net/browse/JDK-8223051 >>>> [3] - https://openjdk.java.net/jeps/383 >>>> [4] - >>>> https://docs.scipy.org/doc/numpy/reference/generated/numpy.reshape.html#numpy.reshape >>>> >>>> From Alan.Bateman at oracle.com Wed May 20 14:10:19 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 20 May 2020 15:10:19 +0100 Subject: RFR: 8215401: Add isEmpty default method to CharSequence In-Reply-To: <2b4030b6-29d9-a1af-e96d-1da3ce260711@oracle.com> References: <73809ad1-e317-ade2-7fec-f356f38d005c@oracle.com> <9765e3e1-5841-e93e-77b1-2030b894e660@oracle.com> <2b4030b6-29d9-a1af-e96d-1da3ce260711@oracle.com> Message-ID: <910d6b79-e002-9519-ad54-e31f72fd14d3@oracle.com> On 19/05/2020 20:35, Claes Redestad wrote: > Hi Jason, > > I guess overriding and marking the CharBuffer method final for > consistency wouldn't hurt. Except I probably need to pass this through > another CSR review. > > Also added test cases for char[] and String-based CharBuffers: > > http://cr.openjdk.java.net/~redestad/8215401/open.01/ Yes, CharBuffer sometimes needs attention default methods are added to CharSequence. In this case it shouldn't need anything but overriding the javadoc is okay (just missing @since 15). For the test then you could expand it to test the views of heap and direct buffers (asCharBuffer). -Alan From james.laskey at oracle.com Wed May 20 14:38:56 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Wed, 20 May 2020 11:38:56 -0300 Subject: RFR (CSR) JDK-8245399 Remove addition preview adornment from String::formatted In-Reply-To: <7BFBA125-77EB-44A9-8086-7BE3CEF28293@oracle.com> References: <4D744464-3018-48E2-BF9B-3D089EB4AD75@oracle.com> <7BFBA125-77EB-44A9-8086-7BE3CEF28293@oracle.com> Message-ID: <841340BE-0B8B-4051-95BF-A8709634B259@oracle.com> Disregard. I have two bugs against String.java and overlapped the email. > On May 20, 2020, at 8:54 AM, Jim Laskey wrote: > > All call for aid response to a comment on the CSR from Joe. > >> I suggesting having some explicit statement about the line count in addition to the number of line terminators. > > > That is the crux of the skirting around. Line count can mean two things depending on whether lines are interpreted as a) character sequences separated by line terminators (\r, \n) or b) character sequences terminated by line terminators. If we state one thing a) then a developer will state, no it's b). It all depends on what the developer does next. > > Generally, core libraries (String::split, String::lines, String::stripIndent) interpret lines using a) with the option of having a final line terminator which then kind of looks like b). String::lines tries to make this clear, "stream of lines extracted from this string, separated by line terminators.", but you can still have the optional final line terminator (as does String::split("\\R")). > > Files::lines and BufferedReader::lines side-step the issue all together (assumptions left to the user.) Any wordsmything assistance would be appreciated, > > -- Jim > > > > >> On May 19, 2020, at 5:00 PM, Jim Laskey wrote: >> >> Please review this change to remove the preview heading from the javadoc of String::formatted. This also updates the @since to 15. >> >> Thank you. >> >> Cheers, >> >> -- Jim >> >> >> csr: https://bugs.openjdk.java.net/browse/JDK-8245399 >> jbs: https://bugs.openjdk.java.net/browse/JDK-8245398 >> >> > From claes.redestad at oracle.com Wed May 20 15:21:24 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 20 May 2020 17:21:24 +0200 Subject: RFR: 8215401: Add isEmpty default method to CharSequence In-Reply-To: <910d6b79-e002-9519-ad54-e31f72fd14d3@oracle.com> References: <73809ad1-e317-ade2-7fec-f356f38d005c@oracle.com> <9765e3e1-5841-e93e-77b1-2030b894e660@oracle.com> <2b4030b6-29d9-a1af-e96d-1da3ce260711@oracle.com> <910d6b79-e002-9519-ad54-e31f72fd14d3@oracle.com> Message-ID: <926afde9-bcfa-41ee-7177-c1cc596d626a@oracle.com> On 2020-05-20 16:10, Alan Bateman wrote: > > > On 19/05/2020 20:35, Claes Redestad wrote: >> Hi Jason, >> >> I guess overriding and marking the CharBuffer method final for >> consistency wouldn't hurt. Except I probably need to pass this through >> another CSR review. >> >> Also added test cases for char[] and String-based CharBuffers: >> >> http://cr.openjdk.java.net/~redestad/8215401/open.01/ > > Yes, CharBuffer sometimes needs attention default methods are added to > CharSequence. In this case it shouldn't need anything but overriding the > javadoc is okay (just missing @since 15). Ok - I'll also update and resubmit the CSR with the edits and additions that came up during review here. > For the test then you could expand it to test the views of heap and > direct buffers (asCharBuffer). How about this: http://cr.openjdk.java.net/~redestad/8215401/open.02/ /Claes From vicente.romero at oracle.com Wed May 20 15:40:54 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Wed, 20 May 2020 11:40:54 -0400 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> Message-ID: Hi David, > src/java.base/share/classes/java/lang/Class.java > > There needs to be a CSR request for these changes. yes there is one already: https://bugs.openjdk.java.net/browse/JDK-8244556 > > +????? * Returns an array containing {@code ClassDesc} objects > representing all the > +????? * permitted subclasses of this {@linkplain Class} if it is > sealed. Returns an empty array if this > +????? * {@linkplain Class} is not sealed. > > should add "or this class represents an array or primitive type" > (using the standard wording for such cases). well given that array and primitive classes are not sealed classes I think we are already covered by the method's spec. > > +????? * @throws IllegalArgumentException if a class descriptor is not > in the correct format > > IllegalArgumentException is not an appropriate exception to use as > this method takes no arguments. If the class descriptor is not valid > and it comes from the VM then I think we have a problem with how the > VM validates class descriptors. Any IAE from ClassDesc.of should be > caught and converted to a more suitable exception type - preferably > InternalError if the VM should always return valid strings. we agree with you here, this will be fixed in the next review iteration. > > +???? public ClassDesc[] getPermittedSubclasses() { > > As mentioned for jvm.cpp this Java code should do the isArray() and > isPrimitive() check before calling the VM. agreed. > Thanks, Vicente From paul.sandoz at oracle.com Wed May 20 15:45:57 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 20 May 2020 08:45:57 -0700 Subject: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator) In-Reply-To: <9beb2729-4ab8-deda-fc92-b4550fdfbb4e@oracle.com> References: <7a96ec1b-cdec-1e3f-f6ca-102d7340e70a@oracle.com> <271da482-cdbc-1d53-2ddd-efcb3a62ddff@oracle.com> <543817be-92d5-d6b1-d8e5-88f6fd3f3346@oracle.com> <9beb2729-4ab8-deda-fc92-b4550fdfbb4e@oracle.com> Message-ID: <611EB787-F7AE-4F8A-841E-7B249AC9C04A@oracle.com> +1 Paul. > On May 20, 2020, at 7:01 AM, Maurizio Cimadamore wrote: > > Another very small iteration which fixes a gap in the javadoc specification for MemorySegment::toArray (thanks Chris!) > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev > > Delta webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev_delta/ > > > Cheers > Maurizio From mandy.chung at oracle.com Wed May 20 17:05:09 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 20 May 2020 10:05:09 -0700 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> Message-ID: <8a20c6da-24a6-de3e-c672-d57f57dc6319@oracle.com> Hi Vicente, On 5/20/20 8:40 AM, Vicente Romero wrote: > Hi David, > >> src/java.base/share/classes/java/lang/Class.java >> >> There needs to be a CSR request for these changes. > > yes there is one already: > https://bugs.openjdk.java.net/browse/JDK-8244556 Adding to David's comment w.r.t. @throws IAE: The Class::getXXX APIs returns `Class` or `Class[]` if the result is about type(s).? This new `getPermittedSubclasses` returns `ClassDesc[]`.?? I wonder if this should be renamed to `permittedSubclasses` to follow the convention of the new APIs added to support descriptors e.g. `describeConstable` Nit: {@linkplain Class} should be {@code Class} Mandy From naoto.sato at oracle.com Wed May 20 17:29:48 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 20 May 2020 10:29:48 -0700 Subject: [15] RFR: 8245241: Incorrect locale provider preference is not logged Message-ID: <4ab22033-8eda-e96b-3898-0525a43e29fd@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8245241 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8245241/webrev.00/ Incorrect user-provided provider preference is supposed to be logged. However it is not so because it is using PlatformLogger(SurrogateLogger) which uses the default logging level. I changed it to use j.l.System's logger and bumped it to INFO level (it should notify the user by default). By taking this opportunity, I did some clean-up in locale provider adapter's logging related code as well. Naoto From paul.sandoz at oracle.com Wed May 20 17:29:50 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 20 May 2020 10:29:50 -0700 Subject: Update Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests In-Reply-To: <5bf2b471-36c0-f28b-b7c9-06ff5fded10c@oracle.com> References: <49F81016-55DF-4E3C-940A-A8DF8C712259@oracle.com> <9D074341-7234-4D9F-8E99-0E73F5BB5407@oracle.com> <5bf2b471-36c0-f28b-b7c9-06ff5fded10c@oracle.com> Message-ID: <6EB0C8F6-EB7F-4CBA-BDE1-4CE4F978D624@oracle.com> Thanks, tier3 it is! I am curious about how those tests can be co-opted for HS tiers. Can you share details on the panama-dev thread? Paul. diff -r a606409980d6 test/jdk/TEST.groups --- a/test/jdk/TEST.groups Fri May 15 17:23:27 2020 -0700 +++ b/test/jdk/TEST.groups Wed May 20 10:28:34 2020 -0700 @@ -72,6 +72,7 @@ tier3 = \ :build \ + :jdk_vector :jdk_rmi \ :jdk_beans \ :jdk_imageio \ @@ -338,6 +339,9 @@ jdk_foreign = \ java/foreign +jdk_vector = \ + jdk/incubator/vector + ############################# # > On May 19, 2020, at 5:06 PM, Ekaterina Pavlova wrote: > > As I wrote to openjdk alias tier3 seems to be more reasonable tier for incubating feature tests. > > Once the tests will be integrated we will also need to add these tests into hs-comp tiers to be tested with > additional compiler flags (like -Xcomp). > > -katya > > > On 5/19/20 3:25 PM, Paul Sandoz wrote: >> I just realized that the vector tests have not been included in any JDK test category e.g. tier1. >> Ordinarily I would expect the tests to be added to tier1 since the tests exercise intrinsics. However, those intrinsics are only enabled with the Vector API module so we could place in another tier to potentially reduce the cost of testing. >> Advice very much appreciate on which tier the tests should belong to. >> Paul. >>> On May 18, 2020, at 12:13 PM, Paul Sandoz wrote: >>> >>> HI, >>> >>> Here?s an update of the API and implementation webrevs based on (mostly) API feedback. We have removed the performance tests to make the review easier (those will be dealt with separately to integration as a follow on task). >>> >>> I think over the past year and recently via the CSR the API has had significant review. Reviews focusing on the Java implementation and tests would be greatly appreciated. >>> >>> It?s worth reiterating that the implementation and tests are quite formulaic, there is a lot of code that is generated from templates, so it's possible to focus on the template + subset (e.g. byte, long, float, and sizes of say 256, max). >>> >>> Notable changes from the prior webrev are: >>> >>> - Removal of the fromValues methods to construct a vector from a varargs array. Feedback indicated this was a misleading way to obtain a vector. >>> >>> - Unification of byte array and ByteBuffer load/store method signatures and unification of the implementations with more tests (including out-of-bounds tests for all the kinds of loads/stores). >>> >>> Paul. >>> >>> -- >>> >>> Latest javadoc >>> http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/docs-2020-05-15-88a83f7238d8/api/jdk.incubator.vector/jdk/incubator/vector/package-summary.html >>> >>> Latest specdiff >>> http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/specdiff-jdk-2020-05-15-88a83f7238d8/overview-summary.html >>> >>> Incremental specdiff >>> http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/specdiff-2020-05-11-38dd763d023e-2020-05-15-88a83f7238d8/overview-summary.html >>> >>> >>> Latest implementation webrev >>> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev-2020-05-16-default-2020-05-15-88a83f7238d8/webrev/ >>> >>> Incremental Implementation webrev >>> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev-2020-05-11-38dd763d023e-2020-05-15-88a83f7238d8/webrev/ >>> >>> Latest test webrev >>> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev-2020-05-16-default-2020-05-15-88a83f7238d8/webrev/ >>> >>> Incremental test webrev >>> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev-2020-05-11-38dd763d023e-2020-05-15-88a83f7238d8/webrev/ >>> >>> >>>> On Apr 1, 2020, at 3:46 PM, Paul Sandoz wrote: >>>> >>>> Hi, >>>> >>>> A prior email sent out a request for review of the Vector API in preparation for JEP 338: Vector API (Incubator) [1] to be proposed for target: >>>> >>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html >>>> >>>> This email expands the review of the API to the Java implementation and Java tests: >>>> >>>> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev/webrev/ >>>> >>>> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev/webrev/ >>>> >>>> (Further emails will sent for review of general HotSpot changes CPU architecture specific HotSpot changes, x64 and aarch64, and performance tests. For an early peek see the links in the description of JDK-8223347.) >>>> >>>> ? >>>> >>>> The Vector API provides >>>> >>>> - the public Vector class with vector operations common to all supported primitive types >>>> >>>> - public primitive specializations, such as IntVector, with common operations associated with the primitive type >>>> >>>> - internal concrete specializations for the vector size, such as Int256Vector, for a vector holding 8 ints. >>>> >>>> Operations generally defer to one of approximately 20 vector intrinsics. Some operations may be composed of other operations. >>>> >>>> Explicit casts are performed by vector operations to ensure vectors arguments are of the required shape (bit size) and element type. >>>> >>>> A vector intrinsic is an internal low-level vector operation. The last argument to the intrinsic is fall back behavior in Java, implementing the scalar operation over the number of elements held by the vector. Thus, If the intrinsic is not supported in C2 for the other arguments then the Java implementation is executed (the Java implementation is always executed when running in the interpreter or for C1). >>>> >>>> The public primitive specializations and the internal concrete implementations are generated from SSP template files, X-Vector.java.template and X-VectorBits.java.template respectively. >>>> >>>> Overall the implementation approach is quite formulaic and rather repetitive. Once you grok the pattern It should be easier to review if a little laborious. >>>> >>>> Unit tests are auto-generated by composing templates for each operation into an SSP template file which is then used to generate unit test files for each concrete vector class. The tests are quite extensive and have found many a HotSpot issue in development across a wide range of platforms. >>>> >>>> Paul. >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8201271 >>>> >>> > From chris.hegarty at oracle.com Wed May 20 17:42:36 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 20 May 2020 18:42:36 +0100 Subject: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator) In-Reply-To: <9beb2729-4ab8-deda-fc92-b4550fdfbb4e@oracle.com> References: <7a96ec1b-cdec-1e3f-f6ca-102d7340e70a@oracle.com> <271da482-cdbc-1d53-2ddd-efcb3a62ddff@oracle.com> <543817be-92d5-d6b1-d8e5-88f6fd3f3346@oracle.com> <9beb2729-4ab8-deda-fc92-b4550fdfbb4e@oracle.com> Message-ID: > On 20 May 2020, at 15:01, Maurizio Cimadamore wrote: > > Another very small iteration which fixes a gap in the javadoc specification for MemorySegment::toArray (thanks Chris!) > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev > > Delta webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev_delta/ Still LGTM. -Chris. From jason_mehrens at hotmail.com Wed May 20 18:23:16 2020 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Wed, 20 May 2020 18:23:16 +0000 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: <83FBA525-902A-4F61-901D-E5E123ED85EB@cbfiddle.com> References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> <4B44293C-2465-4BA7-B6F6-9AAA437760C4@cbfiddle.com> <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com> <8138A696-AE6D-49D4-9A9B-4E4C23DC65A4@cbfiddle.com> , <83FBA525-902A-4F61-901D-E5E123ED85EB@cbfiddle.com> Message-ID: Alan, This contains that and that contains this at least avoids calling size which could be expensive or ephemeral at the AbstractSet level. Using the iterators you can at least do a final check to see there are no more elements to walk. Biasing towards ordering could pay off for things like naturally ordered SortedSet to SortedSet, LinkedHashSet, or CopyOnWriteArraySet. Computing the hash during equals is about the best I can come up with: public class SetEquals { public static void main(String[] args) { Comparator cc = String.CASE_INSENSITIVE_ORDER; Set s1 = new TreeSet<>(cc); Set s2 = new TreeSet<>(cc); s1.add("hello"); s2.add("Hello"); System.out.println(equals(s1, s2)); System.out.println(equals(s2, s1)); System.out.println(s1.hashCode() == s2.hashCode()); } private static boolean equals(Set s1, Set s2) { if (s2 == null) { return false; } if (s1 == s2) { return true; } int s1h = 0; int s2h = 0; Iterator e1 = s1.iterator(); Iterator e2 = s2.iterator(); if (s1 instanceof SortedSet && s2 instanceof SortedSet && isSameOrder((SortedSet) s1, (SortedSet) s2)) { //TODO: raw type warnings. Comparator cmp = ((SortedSet) s1).comparator(); if (cmp == null) { cmp = Comparator.naturalOrder(); } while (e1.hasNext() && e2.hasNext()) { Object o1 = e1.next(); Object o2 = e2.next(); try { if (cmp.compare(o1, o2) != 0 && (!s1.contains(o2) || !s2.contains(o1))) { return false; } } catch (ClassCastException cce) { return false; } s1h += Objects.hashCode(o1); s2h += Objects.hashCode(o2); //Iteration order should be the same. if (s1h != s2h) { return false; } } } else { while (e1.hasNext() && e2.hasNext()) { Object o1 = e1.next(); Object o2 = e2.next(); try { if (!Objects.equals(o1, o2) && (!s1.contains(o2) || !s2.contains(o1))) { return false; } } catch (ClassCastException cce) { return false; } s1h += Objects.hashCode(o1); s2h += Objects.hashCode(o2); } } return s1h == s2h && !e1.hasNext() && !e2.hasNext(); } private static boolean isSameOrder(SortedSet s1, SortedSet s2) { //null matches natural ordering or unwrap to find a singleton. //Avoid calling equals on comparator. return Collections.reverseOrder(s1.comparator()) == Collections.reverseOrder(s2.comparator()); } } Jason ________________________________________ From: Alan Snyder Sent: Thursday, May 14, 2020 8:39 AM To: Jason Mehrens Cc: core-libs-dev Subject: Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes > HashSet/TreeSet could do what ConcurrentHashMap/ConcurrentSkipListSet do by using the "this contains that and that contains this" logic. Yes, at the cost of yet another performance regression. But how about this problem: Comparator cc = String.CASE_INSENSITIVE_ORDER; Set s1 = new TreeSet<>(cc); Set s2 = new TreeSet<>(cc); s1.add("hello"); s2.add("Hello"); s1.equals(s2) -> true s2.equals(s1) -> true s1.hashCode() == s2.hashCode() -> false From javalists at cbfiddle.com Wed May 20 18:53:01 2020 From: javalists at cbfiddle.com (Alan Snyder) Date: Wed, 20 May 2020 11:53:01 -0700 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> <4B44293C-2465-4BA7-B6F6-9AAA437760C4@cbfiddle.com> <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com> <8138A696-AE6D-49D4-9A9B-4E4C23DC65A4@cbfiddle.com> <83FBA525-902A-4F61-901D-E5E123ED85EB@cbfiddle.com> Message-ID: <90121B6A-D222-46A8-ADEF-984C45DB81C9@cbfiddle.com> Do you believe that Set.equals() should behave this way on SortedSets? > On May 20, 2020, at 11:23 AM, Jason Mehrens wrote: > > public class SetEquals { > > public static void main(String[] args) { > Comparator cc = String.CASE_INSENSITIVE_ORDER; > Set s1 = new TreeSet<>(cc); > Set s2 = new TreeSet<>(cc); > s1.add("hello"); > s2.add("Hello"); > System.out.println(equals(s1, s2)); > System.out.println(equals(s2, s1)); > System.out.println(s1.hashCode() == s2.hashCode()); > } > > private static boolean equals(Set s1, Set s2) { > if (s2 == null) { > return false; > } > > if (s1 == s2) { > return true; > } > > int s1h = 0; > int s2h = 0; > Iterator e1 = s1.iterator(); > Iterator e2 = s2.iterator(); > > if (s1 instanceof SortedSet && s2 instanceof SortedSet > && isSameOrder((SortedSet) s1, (SortedSet) s2)) { > //TODO: raw type warnings. > Comparator cmp = ((SortedSet) s1).comparator(); > if (cmp == null) { > cmp = Comparator.naturalOrder(); > } > while (e1.hasNext() && e2.hasNext()) { > Object o1 = e1.next(); > Object o2 = e2.next(); > > try { > if (cmp.compare(o1, o2) != 0 > && (!s1.contains(o2) || !s2.contains(o1))) { > return false; > } > } catch (ClassCastException cce) { > return false; > } > > s1h += Objects.hashCode(o1); > s2h += Objects.hashCode(o2); > > //Iteration order should be the same. > if (s1h != s2h) { > return false; > } > } > } else { > while (e1.hasNext() && e2.hasNext()) { > Object o1 = e1.next(); > Object o2 = e2.next(); > > try { > if (!Objects.equals(o1, o2) > && (!s1.contains(o2) || !s2.contains(o1))) { > return false; > } > } catch (ClassCastException cce) { > return false; > } > > s1h += Objects.hashCode(o1); > s2h += Objects.hashCode(o2); > } > } > return s1h == s2h && !e1.hasNext() && !e2.hasNext(); > } > > private static boolean isSameOrder(SortedSet s1, SortedSet s2) { > //null matches natural ordering or unwrap to find a singleton. > //Avoid calling equals on comparator. > return Collections.reverseOrder(s1.comparator()) > == Collections.reverseOrder(s2.comparator()); > } > } From claes.redestad at oracle.com Wed May 20 19:11:31 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 20 May 2020 21:11:31 +0200 Subject: Optimize (Linked-)HashMap lookup when backing array is null In-Reply-To: <899c7670-cba9-1128-dc2c-d4468613a0be@oracle.com> References: <311BBE19-C22B-4BA4-B9EE-267B6811841E@freenet.de> <39881274-1311-c67d-b7a5-9e6ab07e812a@oracle.com> <3850FBEC-DE36-4405-81DE-27DC5CB79EE5@freenet.de> <1f0e873b-0ba9-1bcc-847e-1d8dabea689c@oracle.com> <55194386-F651-4A0D-B0EF-9EB9B4553C24@freenet.de> <899c7670-cba9-1128-dc2c-d4468613a0be@oracle.com> Message-ID: Hi, seems acceptable to me, too. I'd be happy to sponsor this, but just starting a long weekend here so might not have time before start of next week. /Claes On 2020-05-19 22:21, Roger Riggs wrote: > Hi, > > Right, its only in the case of removing the node because the new value > was null. > Besides being infrequent, that should not be a problem. > > Thanks, Roger > > > On 5/19/20 3:56 PM, Christoph Dreis wrote: >> Hi Roger, >> >>> How does the performance degrade when the computation of the hash >>> is non-trivial. For example, with an array as a key or an object with >>> fields that are objects? >>> The original code made a point of computing the hash only once. >> HashMap.get() and HashMap.containsKey() etc. would still calculate it >> only once. >> Only computeIfPresent would degrade. Did you mean that? >> >> Cheers, >> Christoph >> >> On 5/19/20 3:21 PM, Claes Redestad wrote: >>>> Thanks for producing the simpler variant and getting some comparative >>>> runs done. >>>> >>>> On 2020-05-19 19:50, Christoph Dreis wrote: >>>>> I would probably go for the first version although it is a bit more >>>>> complicated and has the computeIfPresent caveat, because it doesn't >>>>> slow down the common Map.get() case when the map is actually filled. >>>> It is a bit of step up in complexity, but getting the win without >>>> adding >>>> a branch to Map.get() _is_ a nice property. >>>> >>>>> Let me know what you think. >>>> If core libs maintainers are fine with the added complexity of your >>>> original patch, I think it looks ok. >>>> >>>> /Claes >> >> > From martinrb at google.com Wed May 20 19:26:33 2020 From: martinrb at google.com (Martin Buchholz) Date: Wed, 20 May 2020 12:26:33 -0700 Subject: Optimize (Linked-)HashMap lookup when backing array is null In-Reply-To: References: <311BBE19-C22B-4BA4-B9EE-267B6811841E@freenet.de> <39881274-1311-c67d-b7a5-9e6ab07e812a@oracle.com> <3850FBEC-DE36-4405-81DE-27DC5CB79EE5@freenet.de> <1f0e873b-0ba9-1bcc-847e-1d8dabea689c@oracle.com> <55194386-F651-4A0D-B0EF-9EB9B4553C24@freenet.de> <899c7670-cba9-1128-dc2c-d4468613a0be@oracle.com> Message-ID: No strong opinion either way, but ... Generally we try to avoid special case code just for performance. The value depends on how rare lookups on empty maps are; I don't have a good intuition on that. On Wed, May 20, 2020 at 12:11 PM Claes Redestad wrote: > > Hi, > > seems acceptable to me, too. > > I'd be happy to sponsor this, but just starting a long weekend here so > might not have time before start of next week. > > /Claes > > On 2020-05-19 22:21, Roger Riggs wrote: > > Hi, > > > > Right, its only in the case of removing the node because the new value > > was null. > > Besides being infrequent, that should not be a problem. > > > > Thanks, Roger > > > > > > On 5/19/20 3:56 PM, Christoph Dreis wrote: > >> Hi Roger, > >> > >>> How does the performance degrade when the computation of the hash > >>> is non-trivial. For example, with an array as a key or an object with > >>> fields that are objects? > >>> The original code made a point of computing the hash only once. > >> HashMap.get() and HashMap.containsKey() etc. would still calculate it > >> only once. > >> Only computeIfPresent would degrade. Did you mean that? > >> > >> Cheers, > >> Christoph > >> > >> On 5/19/20 3:21 PM, Claes Redestad wrote: > >>>> Thanks for producing the simpler variant and getting some comparative > >>>> runs done. > >>>> > >>>> On 2020-05-19 19:50, Christoph Dreis wrote: > >>>>> I would probably go for the first version although it is a bit more > >>>>> complicated and has the computeIfPresent caveat, because it doesn't > >>>>> slow down the common Map.get() case when the map is actually filled. > >>>> It is a bit of step up in complexity, but getting the win without > >>>> adding > >>>> a branch to Map.get() _is_ a nice property. > >>>> > >>>>> Let me know what you think. > >>>> If core libs maintainers are fine with the added complexity of your > >>>> original patch, I think it looks ok. > >>>> > >>>> /Claes > >> > >> > > From claes.redestad at oracle.com Wed May 20 19:42:45 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 20 May 2020 21:42:45 +0200 Subject: Optimize (Linked-)HashMap lookup when backing array is null In-Reply-To: References: <311BBE19-C22B-4BA4-B9EE-267B6811841E@freenet.de> <39881274-1311-c67d-b7a5-9e6ab07e812a@oracle.com> <3850FBEC-DE36-4405-81DE-27DC5CB79EE5@freenet.de> <1f0e873b-0ba9-1bcc-847e-1d8dabea689c@oracle.com> <55194386-F651-4A0D-B0EF-9EB9B4553C24@freenet.de> <899c7670-cba9-1128-dc2c-d4468613a0be@oracle.com> Message-ID: I don't have a good intuition either, but this optimization feels like a natural companion to the optimization to not allocate backing arrays for empty maps in the first place - which seems to be a rather common occurrence[1]. And since we'll not call hashCode() when the map is empty, the gain might be more significant for classes that have a non- caching hashCode function. /Claes [1] https://bugs.openjdk.java.net/browse/JDK-7143928 On 2020-05-20 21:26, Martin Buchholz wrote: > No strong opinion either way, but ... > Generally we try to avoid special case code just for performance. > The value depends on how rare lookups on empty maps are; I don't have > a good intuition on that. > > On Wed, May 20, 2020 at 12:11 PM Claes Redestad > wrote: >> >> Hi, >> >> seems acceptable to me, too. >> >> I'd be happy to sponsor this, but just starting a long weekend here so >> might not have time before start of next week. >> >> /Claes >> >> On 2020-05-19 22:21, Roger Riggs wrote: >>> Hi, >>> >>> Right, its only in the case of removing the node because the new value >>> was null. >>> Besides being infrequent, that should not be a problem. >>> >>> Thanks, Roger >>> >>> >>> On 5/19/20 3:56 PM, Christoph Dreis wrote: >>>> Hi Roger, >>>> >>>>> How does the performance degrade when the computation of the hash >>>>> is non-trivial. For example, with an array as a key or an object with >>>>> fields that are objects? >>>>> The original code made a point of computing the hash only once. >>>> HashMap.get() and HashMap.containsKey() etc. would still calculate it >>>> only once. >>>> Only computeIfPresent would degrade. Did you mean that? >>>> >>>> Cheers, >>>> Christoph >>>> >>>> On 5/19/20 3:21 PM, Claes Redestad wrote: >>>>>> Thanks for producing the simpler variant and getting some comparative >>>>>> runs done. >>>>>> >>>>>> On 2020-05-19 19:50, Christoph Dreis wrote: >>>>>>> I would probably go for the first version although it is a bit more >>>>>>> complicated and has the computeIfPresent caveat, because it doesn't >>>>>>> slow down the common Map.get() case when the map is actually filled. >>>>>> It is a bit of step up in complexity, but getting the win without >>>>>> adding >>>>>> a branch to Map.get() _is_ a nice property. >>>>>> >>>>>>> Let me know what you think. >>>>>> If core libs maintainers are fine with the added complexity of your >>>>>> original patch, I think it looks ok. >>>>>> >>>>>> /Claes >>>> >>>> >>> From harold.seigel at oracle.com Wed May 20 19:43:17 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 20 May 2020 15:43:17 -0400 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: <1968935181.766173.1589877714107.JavaMail.zimbra@u-pem.fr> References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> <1968935181.766173.1589877714107.JavaMail.zimbra@u-pem.fr> Message-ID: <6006e5bf-c642-a3bd-ddbb-df6ca401f564@oracle.com> Hi Remi, Thank you for reviewing the ASM changes. Harold On 5/19/2020 4:41 AM, Remi Forax wrote: > > ----- Mail original ----- >> De: "David Holmes" >> ?: "Harold David Seigel" , "hotspot-runtime-dev" , >> "amber-dev" , "core-libs-dev" , "serviceability-dev" >> >> Envoy?: Mardi 19 Mai 2020 07:26:38 >> Objet: Re: RFR: JDK-8225056 VM support for sealed classes >> Hi Harold, >> >> Adding serviceability-dev for the serviceability related changes. >> >> Nit: "VM support for sealed classes" >> >> This RFR covers the VM, core-libs, serviceability and even some >> langtools tests. AFAICS only the javac changes are not included here so >> when and where will they be reviewed and under what bug id? Ideally >> there will be a single JBS issue for "Implementation of JEP 360: Sealed >> types". It's okay to break up the RFRs across different areas, but it >> should be done under one bug id. >> >> Overall this looks good. I've looked at all files and mainly have some >> style nits in various places. But there are some more significant items >> below. >> >> On 14/05/2020 7:09 am, Harold Seigel wrote: >>> Hi, >>> >>> Please review this patch for JVM and Core-libs support for the JEP 360 >>> Sealed Classes preview feature.? Code changes include the following: >>> >>> ?* Processing of the new PermittedSubclasses attribute to enforce that >>> ?? a class or interface, whose super is a sealed class or interface, >>> ?? must be listed in the super's PermittedSubclasses attribute. >>> ?* Disallow redefinition of a sealed class or interface if its >>> ?? redefinition would change its PermittedSubclasses attribute. >>> ?* Support API's to determine if a class or interface is sealed and, if >>> ?? it's sealed, return a list of its permitted subclasses. >>> ?* asm support for the PermittedSubclasses attribute >> I assume Remi is providing the upstream support in ASM? :) But also see >> below ... > > Currently the version of ASM used JDK already supports sealed classes but with the attribute named PermittedSubtypes instead of PermittedSubclasses. > This patch renames the attribute which is the right thing to do. > Then when JDK 15 will be released, we will release ASM 9 with full support of PermittedSubclasses, with the right method names, docs, etc, that will be then integrated in JDK 16. > > So with my ASM hat, the changes to the 3 ASM classes are good. > > R?mi From jason_mehrens at hotmail.com Wed May 20 20:21:34 2020 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Wed, 20 May 2020 20:21:34 +0000 Subject: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes In-Reply-To: <90121B6A-D222-46A8-ADEF-984C45DB81C9@cbfiddle.com> References: <6ac899fc-abad-89cd-88e0-2ef3ffdba952@oracle.com> <8c02f6a1-4951-9104-283c-d8d3289d45db@oracle.com> <4B44293C-2465-4BA7-B6F6-9AAA437760C4@cbfiddle.com> <944eed3e-666c-fe00-8dae-1171eade1eea@oracle.com> <8138A696-AE6D-49D4-9A9B-4E4C23DC65A4@cbfiddle.com> <83FBA525-902A-4F61-901D-E5E123ED85EB@cbfiddle.com> , <90121B6A-D222-46A8-ADEF-984C45DB81C9@cbfiddle.com> Message-ID: Biasing towards ordering is covered in https://bugs.openjdk.java.net/browse/JDK-8181146 (read the markmail thread link in the ticket) and some of those changes worked there way into http://hg.openjdk.java.net/jdk/jdk14/file/6c954123ee8d/src/java.base/share/classes/java/util/concurrent/ConcurrentSkipListMap.java#l1708 and http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/concurrent/ConcurrentSkipListMap.java?r1=1.176&r2=1.177 I think there is some merit in even biasing toward ordering for non-sorted sets/maps to avoid expensive contains calls. Any change we apply to equals we can usually apply a similar idea to containsAll. I'm not sure about computing the hash code during equals. It is not ideal but seems to solve the case you raised. I doubt it passes the compatibility bar for behavior or performance. Jason ________________________________________ From: Alan Snyder Sent: Wednesday, May 20, 2020 1:53 PM To: Jason Mehrens Cc: core-libs-dev Subject: Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes Do you believe that Set.equals() should behave this way on SortedSets? On May 20, 2020, at 11:23 AM, Jason Mehrens > wrote: public class SetEquals { public static void main(String[] args) { Comparator cc = String.CASE_INSENSITIVE_ORDER; Set s1 = new TreeSet<>(cc); Set s2 = new TreeSet<>(cc); s1.add("hello"); s2.add("Hello"); System.out.println(equals(s1, s2)); System.out.println(equals(s2, s1)); System.out.println(s1.hashCode() == s2.hashCode()); } private static boolean equals(Set s1, Set s2) { if (s2 == null) { return false; } if (s1 == s2) { return true; } int s1h = 0; int s2h = 0; Iterator e1 = s1.iterator(); Iterator e2 = s2.iterator(); if (s1 instanceof SortedSet && s2 instanceof SortedSet && isSameOrder((SortedSet) s1, (SortedSet) s2)) { //TODO: raw type warnings. Comparator cmp = ((SortedSet) s1).comparator(); if (cmp == null) { cmp = Comparator.naturalOrder(); } while (e1.hasNext() && e2.hasNext()) { Object o1 = e1.next(); Object o2 = e2.next(); try { if (cmp.compare(o1, o2) != 0 && (!s1.contains(o2) || !s2.contains(o1))) { return false; } } catch (ClassCastException cce) { return false; } s1h += Objects.hashCode(o1); s2h += Objects.hashCode(o2); //Iteration order should be the same. if (s1h != s2h) { return false; } } } else { while (e1.hasNext() && e2.hasNext()) { Object o1 = e1.next(); Object o2 = e2.next(); try { if (!Objects.equals(o1, o2) && (!s1.contains(o2) || !s2.contains(o1))) { return false; } } catch (ClassCastException cce) { return false; } s1h += Objects.hashCode(o1); s2h += Objects.hashCode(o2); } } return s1h == s2h && !e1.hasNext() && !e2.hasNext(); } private static boolean isSameOrder(SortedSet s1, SortedSet s2) { //null matches natural ordering or unwrap to find a singleton. //Avoid calling equals on comparator. return Collections.reverseOrder(s1.comparator()) == Collections.reverseOrder(s2.comparator()); } } From jeffhainrocket at gmail.com Wed May 20 20:55:07 2020 From: jeffhainrocket at gmail.com (Jeff Hain) Date: Wed, 20 May 2020 22:55:07 +0200 Subject: BigInteger.squareToLen() can be wrong (when called directly) In-Reply-To: References: Message-ID: Hi. >I filed https://bugs.openjdk.java.net/browse/JDK-8245038 to track this. Can't seem to comment the bug so I post here. >>The core issue is in implMulAdd(), where 'offset' is set to >>"out.length-offset - 1" >>instead of >>"zlen - offset - 1" There is another place that needs a fix for pure Java squareToLen() to always work properly, it's in addOne(), where 'offset' is set to "a.length-1-mlen-offset" instead of "zlen-1-mlen-offset" I found a new test cases that allows to check both corrections: x = [1, -2] len = 2 (i.e. zlen = 4) z.length = 5 z = [0, 1, -2, 0, 0] (no correction) z = [0, 1, -6, 4, 0] (only correction 1) z = [0, 3, -4, 0, 0] (only correction 2) z = [0, 3, -8, 4, 0] (expected value) I don't think there is a third place to correct: this kind of thing is only done in these two places, and I now checked this code through millions of random magnitudes/values. -Jeff From naoto.sato at oracle.com Wed May 20 21:31:39 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 20 May 2020 14:31:39 -0700 Subject: [15] RFR: 8239480: Support for CLDR version 37 Message-ID: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8239480 The proposed changeset, and the release note draft are located at: https://cr.openjdk.java.net/~naoto/8239480/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8243581 This updates the CLDR locale data to version 37. Although the changeset is huge, this mainly consists of the locale data and licenses changes. Other than those, only one test case was updated (IncludeLocalesPluginTest.java) due to the locale data change. Naoto From ekaterina.pavlova at oracle.com Wed May 20 22:55:13 2020 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Wed, 20 May 2020 15:55:13 -0700 Subject: Update Re: RFR JDK-8223347 Integration of Vector API (Incubator): Java API, implementation, and tests In-Reply-To: <6EB0C8F6-EB7F-4CBA-BDE1-4CE4F978D624@oracle.com> References: <49F81016-55DF-4E3C-940A-A8DF8C712259@oracle.com> <9D074341-7234-4D9F-8E99-0E73F5BB5407@oracle.com> <5bf2b471-36c0-f28b-b7c9-06ff5fded10c@oracle.com> <6EB0C8F6-EB7F-4CBA-BDE1-4CE4F978D624@oracle.com> Message-ID: On 5/20/20 10:29 AM, Paul Sandoz wrote: > Thanks, tier3 it is! Great, now Vector API tests could be automatically run with default HS flags as part of tier3 testing in mach5. > I am curious about how those tests can be co-opted for HS tiers. Can you share details on the panama-dev thread? I would suggest just to add open/test/jdk/jdk/incubator/vector tests into corresponding HS compiler testing tiers (mach5 tasks) which do run tests with -Xcomp and other compiler flags. I can take care of this once Vector API is integrated. -katya > Paul. > > diff -r a606409980d6 test/jdk/TEST.groups > --- a/test/jdk/TEST.groups Fri May 15 17:23:27 2020 -0700 > +++ b/test/jdk/TEST.groups Wed May 20 10:28:34 2020 -0700 > @@ -72,6 +72,7 @@ > > tier3 = \ > :build \ > + :jdk_vector > :jdk_rmi \ > :jdk_beans \ > :jdk_imageio \ > @@ -338,6 +339,9 @@ > jdk_foreign = \ > java/foreign > > +jdk_vector = \ > + jdk/incubator/vector > + > ############################# > > # > > >> On May 19, 2020, at 5:06 PM, Ekaterina Pavlova wrote: >> >> As I wrote to openjdk alias tier3 seems to be more reasonable tier for incubating feature tests. >> >> Once the tests will be integrated we will also need to add these tests into hs-comp tiers to be tested with >> additional compiler flags (like -Xcomp). >> >> -katya >> >> >> On 5/19/20 3:25 PM, Paul Sandoz wrote: >>> I just realized that the vector tests have not been included in any JDK test category e.g. tier1. >>> Ordinarily I would expect the tests to be added to tier1 since the tests exercise intrinsics. However, those intrinsics are only enabled with the Vector API module so we could place in another tier to potentially reduce the cost of testing. >>> Advice very much appreciate on which tier the tests should belong to. >>> Paul. >>>> On May 18, 2020, at 12:13 PM, Paul Sandoz wrote: >>>> >>>> HI, >>>> >>>> Here?s an update of the API and implementation webrevs based on (mostly) API feedback. We have removed the performance tests to make the review easier (those will be dealt with separately to integration as a follow on task). >>>> >>>> I think over the past year and recently via the CSR the API has had significant review. Reviews focusing on the Java implementation and tests would be greatly appreciated. >>>> >>>> It?s worth reiterating that the implementation and tests are quite formulaic, there is a lot of code that is generated from templates, so it's possible to focus on the template + subset (e.g. byte, long, float, and sizes of say 256, max). >>>> >>>> Notable changes from the prior webrev are: >>>> >>>> - Removal of the fromValues methods to construct a vector from a varargs array. Feedback indicated this was a misleading way to obtain a vector. >>>> >>>> - Unification of byte array and ByteBuffer load/store method signatures and unification of the implementations with more tests (including out-of-bounds tests for all the kinds of loads/stores). >>>> >>>> Paul. >>>> >>>> -- >>>> >>>> Latest javadoc >>>> http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/docs-2020-05-15-88a83f7238d8/api/jdk.incubator.vector/jdk/incubator/vector/package-summary.html >>>> >>>> Latest specdiff >>>> http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/specdiff-jdk-2020-05-15-88a83f7238d8/overview-summary.html >>>> >>>> Incremental specdiff >>>> http://cr.openjdk.java.net/~psandoz/panama/vector-api-review/specdiff-2020-05-11-38dd763d023e-2020-05-15-88a83f7238d8/overview-summary.html >>>> >>>> >>>> Latest implementation webrev >>>> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev-2020-05-16-default-2020-05-15-88a83f7238d8/webrev/ >>>> >>>> Incremental Implementation webrev >>>> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev-2020-05-11-38dd763d023e-2020-05-15-88a83f7238d8/webrev/ >>>> >>>> Latest test webrev >>>> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev-2020-05-16-default-2020-05-15-88a83f7238d8/webrev/ >>>> >>>> Incremental test webrev >>>> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev-2020-05-11-38dd763d023e-2020-05-15-88a83f7238d8/webrev/ >>>> >>>> >>>>> On Apr 1, 2020, at 3:46 PM, Paul Sandoz wrote: >>>>> >>>>> Hi, >>>>> >>>>> A prior email sent out a request for review of the Vector API in preparation for JEP 338: Vector API (Incubator) [1] to be proposed for target: >>>>> >>>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html >>>>> >>>>> This email expands the review of the API to the Java implementation and Java tests: >>>>> >>>>> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_src_webrev/webrev/ >>>>> >>>>> http://cr.openjdk.java.net/~psandoz/panama/JDK-8223347-vector-api-integration-java/jdk_test_webrev/webrev/ >>>>> >>>>> (Further emails will sent for review of general HotSpot changes CPU architecture specific HotSpot changes, x64 and aarch64, and performance tests. For an early peek see the links in the description of JDK-8223347.) >>>>> >>>>> ? >>>>> >>>>> The Vector API provides >>>>> >>>>> - the public Vector class with vector operations common to all supported primitive types >>>>> >>>>> - public primitive specializations, such as IntVector, with common operations associated with the primitive type >>>>> >>>>> - internal concrete specializations for the vector size, such as Int256Vector, for a vector holding 8 ints. >>>>> >>>>> Operations generally defer to one of approximately 20 vector intrinsics. Some operations may be composed of other operations. >>>>> >>>>> Explicit casts are performed by vector operations to ensure vectors arguments are of the required shape (bit size) and element type. >>>>> >>>>> A vector intrinsic is an internal low-level vector operation. The last argument to the intrinsic is fall back behavior in Java, implementing the scalar operation over the number of elements held by the vector. Thus, If the intrinsic is not supported in C2 for the other arguments then the Java implementation is executed (the Java implementation is always executed when running in the interpreter or for C1). >>>>> >>>>> The public primitive specializations and the internal concrete implementations are generated from SSP template files, X-Vector.java.template and X-VectorBits.java.template respectively. >>>>> >>>>> Overall the implementation approach is quite formulaic and rather repetitive. Once you grok the pattern It should be easier to review if a little laborious. >>>>> >>>>> Unit tests are auto-generated by composing templates for each operation into an SSP template file which is then used to generate unit test files for each concrete vector class. The tests are quite extensive and have found many a HotSpot issue in development across a wide range of platforms. >>>>> >>>>> Paul. >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8201271 >>>>> >>>> >> > From huizhe.wang at oracle.com Wed May 20 23:10:13 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 20 May 2020 16:10:13 -0700 Subject: [15] RFR: 8245241: Incorrect locale provider preference is not logged In-Reply-To: <4ab22033-8eda-e96b-3898-0525a43e29fd@oracle.com> References: <4ab22033-8eda-e96b-3898-0525a43e29fd@oracle.com> Message-ID: Hi Naoto, I don't seem to see the DateFormat class or the getDateInstance methods specify how errors may be handled (or logged). Is that stated somewhere else?? In other cases, I see that you've changed it to throw ServiceConfigurationError, that looks to me may be better than a log as a configuration error? (or specifying wrong provider) sounds to me more severe than info. Of the three HostLocaleProviderAdapterImpl, the one for unix is deleted, is there a specific reason? Best, Joe On 5/20/2020 10:29 AM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8245241 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8245241/webrev.00/ > > Incorrect user-provided provider preference is supposed to be logged. > However it is not so because it is using > PlatformLogger(SurrogateLogger) which uses the default logging level. > I changed it to use j.l.System's logger and bumped it to INFO level > (it should notify the user by default). By taking this opportunity, I > did some clean-up in locale provider adapter's logging related code as > well. > > Naoto From david.holmes at oracle.com Wed May 20 23:44:39 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 May 2020 09:44:39 +1000 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> Message-ID: <3b83b315-538f-b643-c45a-3d3070e27b00@oracle.com> Hi Vicente, On 21/05/2020 1:40 am, Vicente Romero wrote: > Hi David, > >> src/java.base/share/classes/java/lang/Class.java >> >> There needs to be a CSR request for these changes. > > yes there is one already: https://bugs.openjdk.java.net/browse/JDK-8244556 >> >> +????? * Returns an array containing {@code ClassDesc} objects >> representing all the >> +????? * permitted subclasses of this {@linkplain Class} if it is >> sealed. Returns an empty array if this >> +????? * {@linkplain Class} is not sealed. >> >> should add "or this class represents an array or primitive type" >> (using the standard wording for such cases). > > well given that array and primitive classes are not sealed classes I > think we are already covered by the method's spec. Yes, now I've seen the JLS updates, this is more clear to me. Thanks, David ----- >> >> +????? * @throws IllegalArgumentException if a class descriptor is not >> in the correct format >> >> IllegalArgumentException is not an appropriate exception to use as >> this method takes no arguments. If the class descriptor is not valid >> and it comes from the VM then I think we have a problem with how the >> VM validates class descriptors. Any IAE from ClassDesc.of should be >> caught and converted to a more suitable exception type - preferably >> InternalError if the VM should always return valid strings. > > we agree with you here, this will be fixed in the next review iteration. > >> >> +???? public ClassDesc[] getPermittedSubclasses() { >> >> As mentioned for jvm.cpp this Java code should do the isArray() and >> isPrimitive() check before calling the VM. > > agreed. > >> > Thanks, > Vicente From naoto.sato at oracle.com Wed May 20 23:49:55 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 20 May 2020 16:49:55 -0700 Subject: [15] RFR: 8245241: Incorrect locale provider preference is not logged In-Reply-To: References: <4ab22033-8eda-e96b-3898-0525a43e29fd@oracle.com> Message-ID: <72d71433-1c05-1c10-bd08-8e7b28384dfd@oracle.com> Hi Joe, thanks for the review. On 5/20/20 4:10 PM, Joe Wang wrote: > Hi Naoto, > > I don't seem to see the DateFormat class or the getDateInstance methods > specify how errors may be handled (or logged). Is that stated somewhere > else? Description of the system property "java.locale.providers" is in the class description of java.util.spi.LocaleServiceProvider class, in which the possible provider names can only be CLDR/COMPAT/SPI/HOST/JRE. So possible error with this system property is user's typo of the provider names. Although the behavior is not described, wrong names have been simply ignored at runtime. The problem here is that user cannot tell that he's done typo, and this fix is exactly to address it. >? In other cases, I see that you've changed it to throw > ServiceConfigurationError, that looks to me may be better than a log as > a configuration error? (or specifying wrong provider) sounds to me more > severe than info. Those exceptions will never happen in normal situation, since those locations are loading SPI/HostLocaleProviderAdapter class(es) that are the JDK classes (classes/methods are known to exist). On the other hand, I kept exception handlers in LocaleProviderAdapter to generate Level.INFO log, as this is for the user's typo of the provider names (explained above). Again this should be ignored and replaced/continue with proper default behavior, and letting user know the typo. If this were throwing SCError, it would break compatibility. > > Of the three HostLocaleProviderAdapterImpl, the one for unix is deleted, > is there a specific reason? Because it is simply not necessary (empty class). It was meant to be implemented later, but the host provider on Unixes has never been requested. Probably because OS date/time/number settings in Unixes are less important to Java clients. HTH, Naoto > > Best, > Joe > > On 5/20/2020 10:29 AM, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8245241 >> >> The proposed changeset is located at: >> >> https://cr.openjdk.java.net/~naoto/8245241/webrev.00/ >> >> Incorrect user-provided provider preference is supposed to be logged. >> However it is not so because it is using >> PlatformLogger(SurrogateLogger) which uses the default logging level. >> I changed it to use j.l.System's logger and bumped it to INFO level >> (it should notify the user by default). By taking this opportunity, I >> did some clean-up in locale provider adapter's logging related code as >> well. >> >> Naoto > From huizhe.wang at oracle.com Thu May 21 01:09:20 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 20 May 2020 18:09:20 -0700 Subject: [15] RFR: 8245241: Incorrect locale provider preference is not logged In-Reply-To: <72d71433-1c05-1c10-bd08-8e7b28384dfd@oracle.com> References: <4ab22033-8eda-e96b-3898-0525a43e29fd@oracle.com> <72d71433-1c05-1c10-bd08-8e7b28384dfd@oracle.com> Message-ID: Hi Naoto, Thanks for the explanation. I agree on the needs for maintaining backward compatibility.? The patch looks good me then. Best, Joe On 5/20/2020 4:49 PM, naoto.sato at oracle.com wrote: > Hi Joe, thanks for the review. > > On 5/20/20 4:10 PM, Joe Wang wrote: >> Hi Naoto, >> >> I don't seem to see the DateFormat class or the getDateInstance >> methods specify how errors may be handled (or logged). Is that stated >> somewhere else? > > Description of the system property "java.locale.providers" is in the > class description of java.util.spi.LocaleServiceProvider class, in > which the possible provider names can only be > CLDR/COMPAT/SPI/HOST/JRE. So possible error with this system property > is user's typo of the provider names. Although the behavior is not > described, wrong names have been simply ignored at runtime. The > problem here is that user cannot tell that he's done typo, and this > fix is exactly to address it. > >> ? In other cases, I see that you've changed it to throw >> ServiceConfigurationError, that looks to me may be better than a log >> as a configuration error? (or specifying wrong provider) sounds to me >> more severe than info. > > Those exceptions will never happen in normal situation, since those > locations are loading SPI/HostLocaleProviderAdapter class(es) that are > the JDK classes (classes/methods are known to exist). > On the other hand, I kept exception handlers in LocaleProviderAdapter > to generate Level.INFO log, as this is for the user's typo of the > provider names (explained above). Again this should be ignored and > replaced/continue with proper default behavior, and letting user know > the typo. If this were throwing SCError, it would break compatibility. > >> >> Of the three HostLocaleProviderAdapterImpl, the one for unix is >> deleted, is there a specific reason? > > Because it is simply not necessary (empty class). It was meant to be > implemented later, but the host provider on Unixes has never been > requested. Probably because OS date/time/number settings in Unixes are > less important to Java clients. > > HTH, > Naoto > >> >> Best, >> Joe >> >> On 5/20/2020 10:29 AM, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8245241 >>> >>> The proposed changeset is located at: >>> >>> https://cr.openjdk.java.net/~naoto/8245241/webrev.00/ >>> >>> Incorrect user-provided provider preference is supposed to be >>> logged. However it is not so because it is using >>> PlatformLogger(SurrogateLogger) which uses the default logging >>> level. I changed it to use j.l.System's logger and bumped it to INFO >>> level (it should notify the user by default). By taking this >>> opportunity, I did some clean-up in locale provider adapter's >>> logging related code as well. >>> >>> Naoto >> From huizhe.wang at oracle.com Thu May 21 01:51:38 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 20 May 2020 18:51:38 -0700 Subject: [15] RFR: 8239480: Support for CLDR version 37 In-Reply-To: References: Message-ID: <60df81f9-0b16-9739-6817-55bfefef76a3@oracle.com> Looks good to me. A minor comment: in the license files, Terms of Use lost its original format (e.g. headings and numbering), lines are also super long. But I think we've seen them in the previous update, it's up to you whether you'd want to reformat them. Either way, no need to regenerate the huge webrev :-) Best, Joe On 5/20/2020 2:31 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8239480 > > The proposed changeset, and the release note draft are located at: > > https://cr.openjdk.java.net/~naoto/8239480/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8243581 > > This updates the CLDR locale data to version 37. Although the > changeset is huge, this mainly consists of the locale data and > licenses changes. Other than those, only one test case was updated > (IncludeLocalesPluginTest.java) due to the locale data change. > > Naoto From naoto.sato at oracle.com Thu May 21 02:06:03 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 20 May 2020 19:06:03 -0700 Subject: [15] RFR: 8239480: Support for CLDR version 37 In-Reply-To: <60df81f9-0b16-9739-6817-55bfefef76a3@oracle.com> References: <60df81f9-0b16-9739-6817-55bfefef76a3@oracle.com> Message-ID: Hi Joe, thanks again! The license file "unicode-license.txt" is actually included in the version 37 artifact: https://github.com/unicode-org/cldr/blob/release-37/unicode-license.txt The changeset uses the file as is, so I believe it is OK. Naoto On 5/20/20 6:51 PM, Joe Wang wrote: > Looks good to me. > > A minor comment: in the license files, Terms of Use lost its original > format (e.g. headings and > numbering), lines are also super long. But I think we've seen them in > the previous update, it's up to you whether you'd want to reformat them. > Either way, no need to regenerate the huge webrev :-) > > Best, > Joe > > On 5/20/2020 2:31 PM, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8239480 >> >> The proposed changeset, and the release note draft are located at: >> >> https://cr.openjdk.java.net/~naoto/8239480/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8243581 >> >> This updates the CLDR locale data to version 37. Although the >> changeset is huge, this mainly consists of the locale data and >> licenses changes. Other than those, only one test case was updated >> (IncludeLocalesPluginTest.java) due to the locale data change. >> >> Naoto > From huizhe.wang at oracle.com Thu May 21 05:56:19 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 20 May 2020 22:56:19 -0700 Subject: [15] RFR: 8239480: Support for CLDR version 37 In-Reply-To: References: <60df81f9-0b16-9739-6817-55bfefef76a3@oracle.com> Message-ID: <1e195b3d-fa14-ed44-52d8-1d4695527bb0@oracle.com> On 5/20/2020 7:06 PM, naoto.sato at oracle.com wrote: > Hi Joe, thanks again! No problem. > > The license file "unicode-license.txt" is actually included in the > version 37 artifact: > > https://github.com/unicode-org/cldr/blob/release-37/unicode-license.txt > > The changeset uses the file as is, so I believe it is OK. I meant the md files that include the license text with the additional "Terms of Use", starting from line 55. That looks like a copy of this: https://www.unicode.org/copyright.html, but headings and numbering were lost. Plus, without html format, some of the lines stretched very long . But again, the format of the md files might not be that important. Your call. -Joe > > Naoto > > On 5/20/20 6:51 PM, Joe Wang wrote: >> Looks good to me. >> >> A minor comment: in the license files, Terms of Use lost its original >> format (e.g. headings and >> numbering), lines are also super long. But I think we've seen them in >> the previous update, it's up to you whether you'd want to reformat >> them. Either way, no need to regenerate the huge webrev :-) >> >> Best, >> Joe >> >> On 5/20/2020 2:31 PM, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8239480 >>> >>> The proposed changeset, and the release note draft are located at: >>> >>> https://cr.openjdk.java.net/~naoto/8239480/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8243581 >>> >>> This updates the CLDR locale data to version 37. Although the >>> changeset is huge, this mainly consists of the locale data and >>> licenses changes. Other than those, only one test case was updated >>> (IncludeLocalesPluginTest.java) due to the locale data change. >>> >>> Naoto >> From alexey at azul.com Thu May 21 07:35:07 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Thu, 21 May 2020 07:35:07 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos Message-ID: Hello, Could you please review the following patch: JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding (based on the TLS server certificate). The channel binding data is calculated as following : ? The client calculates a hash of the TLS server certificate. The hash algorithm is selected on the base of the certificate signature algorithm. Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based ? The channel binding information is the same as defined in rfc4121 [1] with small corrections: ? initiator and acceptor addresses should be set to NULL ? initiator and acceptor address types should be zero. It contradicts to the ?Using Channel Bindings in GSS-API? document [2] that say that the address type should be set to GSS_C_AF_NULLADDR=0xFF, instead of GSS_C_AF_UNSPEC=0x00. This patch introduces changes in the LDAP, SASL and JGSS modules to generate channel binding data automatically if requested by an application. This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. The patch introduces new environment property ?com.sun.jndi.ldap.tls.cbtype? that indicates Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. Right now "tls-server-end-point" Channel Binding type is supported only. The client extracts server certificate from the underlying TLS connection and creates Channel Binding data for JGSS/Kerberos authentication if application indicates com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. Client application should also specify existing "com.sun.jndi.ldap.connect.timeout? property to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 [2] - https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html Initial discussion of this issue is available at security-dev list: https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html From alexander.matveev at oracle.com Thu May 21 08:16:21 2020 From: alexander.matveev at oracle.com (alexander.matveev at oracle.com) Date: Thu, 21 May 2020 01:16:21 -0700 Subject: RFR: 8237908: [TESTBUG] [macos] Add support to jtreg helpers to unpack pkg packages Message-ID: <6b49a035-62f0-abda-8627-08937dee0666@oracle.com> Please review the jpackage fix for bug [1] at [2]. - Added support for unpacking pkg. [1] https://bugs.openjdk.java.net/browse/JDK-8237908 [2] http://cr.openjdk.java.net/~almatvee/8237908/webrev.00/ Thanks, Alexander From Alan.Bateman at oracle.com Thu May 21 10:35:57 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 May 2020 11:35:57 +0100 Subject: RFR: 8215401: Add isEmpty default method to CharSequence In-Reply-To: <926afde9-bcfa-41ee-7177-c1cc596d626a@oracle.com> References: <73809ad1-e317-ade2-7fec-f356f38d005c@oracle.com> <9765e3e1-5841-e93e-77b1-2030b894e660@oracle.com> <2b4030b6-29d9-a1af-e96d-1da3ce260711@oracle.com> <910d6b79-e002-9519-ad54-e31f72fd14d3@oracle.com> <926afde9-bcfa-41ee-7177-c1cc596d626a@oracle.com> Message-ID: On 20/05/2020 16:21, Claes Redestad wrote: > > Ok - I'll also update and resubmit the CSR with the edits and additions > that came up during review here. > >> For the test then you could expand it to test the views of heap and >> direct buffers (asCharBuffer). > > How about this: > > http://cr.openjdk.java.net/~redestad/8215401/open.02/ Looks good. -Alan. From daniel.fuchs at oracle.com Thu May 21 10:42:52 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 21 May 2020 11:42:52 +0100 Subject: [15] RFR: 8245241: Incorrect locale provider preference is not logged In-Reply-To: <4ab22033-8eda-e96b-3898-0525a43e29fd@oracle.com> References: <4ab22033-8eda-e96b-3898-0525a43e29fd@oracle.com> Message-ID: <7f4db42f-1873-3d08-2537-b20279c74ab0@oracle.com> Hi Naoto, Logging uses: ZonedDateTime zdt = ZonedDateTime.ofInstant( record.getInstant(), ZoneId.systemDefault()); and then String.format("%1$tb %1$td, %1$tY %1$tl:%1$tM:%1$tS %1$Tp %2$s%n%4$s: %5$s%6$s%n", ...) to format the date. If the locale provider can't be loaded, is that going to cause problem, when logging is invoked to log the info/warning? In particular: java.base/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java 197 getLogger(LocaleProviderAdapter.class.getCanonicalName()) 198 .log(Logger.Level.INFO, e); 199 adapterInstances.putIfAbsent(type, NONEXISTENT_ADAPTER); 200 if (defaultLocaleProviderAdapter == type) { 201 defaultLocaleProviderAdapter = Type.FALLBACK; 202 } Maybe logging should only be invoked *after* lines 199-202? Same potential issue in src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java lines 367-372 best regards, -- daniel On 20/05/2020 18:29, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8245241 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8245241/webrev.00/ > > Incorrect user-provided provider preference is supposed to be logged. > However it is not so because it is using PlatformLogger(SurrogateLogger) > which uses the default logging level. I changed it to use j.l.System's > logger and bumped it to INFO level (it should notify the user by > default). By taking this opportunity, I did some clean-up in locale > provider adapter's logging related code as well. > > Naoto From claes.redestad at oracle.com Thu May 21 10:48:37 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 21 May 2020 12:48:37 +0200 Subject: RFR: 8215401: Add isEmpty default method to CharSequence In-Reply-To: References: <73809ad1-e317-ade2-7fec-f356f38d005c@oracle.com> <9765e3e1-5841-e93e-77b1-2030b894e660@oracle.com> <2b4030b6-29d9-a1af-e96d-1da3ce260711@oracle.com> <910d6b79-e002-9519-ad54-e31f72fd14d3@oracle.com> <926afde9-bcfa-41ee-7177-c1cc596d626a@oracle.com> Message-ID: On 2020-05-21 12:35, Alan Bateman wrote: > On 20/05/2020 16:21, Claes Redestad wrote: >> >> Ok - I'll also update and resubmit the CSR with the edits and additions >> that came up during review here. >> >>> For the test then you could expand it to test the views of heap and >>> direct buffers (asCharBuffer). >> >> How about this: >> >> http://cr.openjdk.java.net/~redestad/8215401/open.02/ > Looks good. Thanks, Alan! /Claes From maurizio.cimadamore at oracle.com Thu May 21 12:14:08 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 21 May 2020 13:14:08 +0100 Subject: RFR: JDK-8227046: compiler implementation for sealed classes, JDK-8227047: Javadoc for sealed types and JDK-8227044: javax.lang.model for sealed classes In-Reply-To: <3bd27bea-b8a3-88a2-5536-ea9610749ce4@oracle.com> References: <3bd27bea-b8a3-88a2-5536-ea9610749ce4@oracle.com> Message-ID: <11f8828c-607e-e844-1ac6-5977a40c9a77@oracle.com> Hi Vicente, looks very good. Some comments below. * the parser logic is clever in its use of position to apply context-dependent keyword detection; as Jan says, perhaps just share the code so that the position checks are not repeated. * I found one very edge-case quirk in the context-dependent logic; not sure how we wanna address: class Foo { ??? sealed m() {} } This fails with: Error: invalid method declaration; return type required As javac parses non-sealed as a modifier, and then expects a type. I think this is probably reasonable, but it's not as context-dependent as it could be I guess. * This case: class Bar { } sealed @interface Foo permits Bar Fails as expected, but only because Bar doesn't extends Foo. I believe we'd like to ban sealed on annotations more eagerly. Same for non-sealed. For enums and records (which are non-extensible) the compiler does the right thing and tells me that I can't just use sealed/non-sealed there. * The recovery logic in case preview features aren't enabled leaves something to be desired. For instance, if I compile this w/o --enable-preview: ?record Foo() {} I get a very sensible error: records are a preview feature and are disabled by default. ??? (use --enable-preview to enable records) However, if I compiler this w/o --enable-preview: sealed class Foo {} I get this: error: class, interface, or enum expected (no mention of preview features) It gets worse if I also specify a `permits`. * As Jan mentioned, type parameters on permitted types should be banned, not silently cleared in TypeEnter * Overall the type enter logic seems robust - I've tried several examples swapping superclass/subclass - using references to nested classes in supertype declaration, and it all works. Well done. * The error for lambda expressions leaves to be desired: sealed interface Action { ?void doAction(); } class Test { ? Action a = () -> { }; } Foo.java:6: error: class is not allowed to extend sealed class: Action ? Action a = () -> { }; ???????????? ^ I think a dedicated error here would be useful. * the same check is not applied to method references: class Test { ? Action a2 = Test::m; //no error ? static void m() { } } More generally, if a functional interface cannot be sealed, I think it would be better to inject the check in the functional interface check (e.g. Types::findDescriptorInternal) so that you won't need any extra code in Attr. This would also be more in spirit with the spec, where the non-sealedness check is defined in 9.8, not in section 15. * Pulling more on that string, the @FunctionalInterface annotation can be placed on a sealed interface and no error is issued * On ClassWriter - isn't calling adjustFlags() enough? That will truncate the long flags into an int - I think Flags.SEALED is bigger than that? // error messages * DuplicateTypesInPermits I suggest: test/langtools/tools/javac/diags/examples/DuplicateTypeInPermits.java:30: error: invalid permits clause sealed class Sealed permits Sub, Sub {} ??????????????????????????? ^ ? (repeated type: Sub) [this is consistent with the error we issues in other places - e.g. when you implements same interface twice] * NonSealedWithNoSealedSuper test/langtools/tools/javac/diags/examples/NonSealedWithNoSealedSuper.java:31: error: non-sealed modifier not allowed here non-sealed class Sub extends C {} ?????????? ^ ? (class must have a sealed superclasses) I suggest to replace the details message with something like this: (class C does not have any sealed supertypes) [since I expect this message to be applicable also for superinterfaces] * PermitsCantListDeclaringClass test/langtools/tools/javac/diags/examples/PermitsCantListDeclaringClass.java:30: error: invalid permits clause sealed class C permits C {} ?????????????????????? ^ ? (must not include the declaring class: C) Here I recommend something like: (illegal self-reference in permits clause) * PermitsCantListSuperType test/langtools/tools/javac/diags/examples/PermitsCantListSuperType.java:32: error: invalid permits clause sealed class C implements I permits I {} ??????????????????????????????????? ^ ? (must not include a supertype: I) I suggest: (illegal reference to supertype I) * PermitsInNoSealedClass test/langtools/tools/javac/diags/examples/PermitsInNoSealedClass.java:30: error: invalid permits clause class C permits Sub {} ??????? ^ ? (class must be sealed) This is good, but I noted that if you change the test to use an interface, the message still says "class" - the kindname should be used here. * SealedMustHaveSubtypes test/langtools/tools/javac/diags/examples/SealedMustHaveSubtypes.java:29: error: sealed class must have subclasses sealed class Sealed {} ?????? ^ I think this message reflects one of the main issues with the general type vs. class dichotomy. A subclass, in JLS lingo is e.g. `B` where `B extends A`. Interfaces do not play in the mix - they are not considered subclasses. The word subtypes could be more general - but again, it is a bit imprecise, since we're talking about declarations here, not types. I'll defer this conundrum to our spec gurus :-) Cheers Maurizio On 18/05/2020 23:42, Vicente Romero wrote: > Hi, > > Please review this patch for the compiler, javadoc and > javax.lang.model support for the JEP 360 Sealed Classes (Preview). The > changes are provided at [1], which implements the latest JLS for > sealed types [2]. The patch also include the needed changes to javadoc > and javax.lang.model to support sealed types. The CSR witht the > changes in the javax.lang.model spec is at [3]. The sealed types JEP > is accessible at [4]. There is an ongoing review for the VM and > core-libs code of sealed types [5] and that code hasn't been included > in this webrev, > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8227046/webrev.00/ > [2] > http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html > > [3] https://bugs.openjdk.java.net/browse/JDK-8244367 > [4] https://openjdk.java.net/jeps/360 > [5] > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066440.html From harold.seigel at oracle.com Thu May 21 18:33:07 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Thu, 21 May 2020 14:33:07 -0400 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> Message-ID: Hi David, Thanks for looking at this!? Please review this new webrev: http://cr.openjdk.java.net/~hseigel/webrev.01/webrev/ This webrev contains the following significant changes: 1. The format/indentation issues in classFileParser.cpp were fixed. 2. Unneeded checks in InstanceKlass::has_as_permitted_subclass() were removed and the TRAPS parameter was removed. 3. The changes to klassVtable.* and method.* were reverted. Those changes were from when sealed classes were marked as final, and are no longer valid. 4. Method getPermittedSubclasses() in Class.java was renamed to permittedSubclasses() and its implementation was changed. 5. Variables and methods for 'asm' were renamed from 'permittedSubtypes' to 'permittedSubclasses'. 6. Classes for sealed classes tests were changed to start with capital letters. 7. Changes to langtools tests were removed from this webrev. They are covered by the javac webrev (JDK-8244556). 8. The CSR's for JVMTI, JDWP, and JDI are in progress. Please also see comments inline. On 5/19/2020 1:26 AM, David Holmes wrote: > Hi Harold, > > Adding serviceability-dev for the serviceability related changes. > > Nit: "VM support for sealed classes" > > This RFR covers the VM, core-libs, serviceability and even some > langtools tests. AFAICS only the javac changes are not included here > so when and where will they be reviewed and under what bug id? Ideally > there will be a single JBS issue for "Implementation of JEP 360: > Sealed types". It's okay to break up the RFRs across different areas, > but it should be done under one bug id. The javac changes are being reviewed as bug JDK-8227406.? We understand the need to do the reviews under one bug. > > Overall this looks good. I've looked at all files and mainly have some > style nits in various places. But there are some more significant > items below. > > On 14/05/2020 7:09 am, Harold Seigel wrote: >> Hi, >> >> Please review this patch for JVM and Core-libs support for the JEP >> 360 Sealed Classes preview feature.? Code changes include the following: >> >> ??* Processing of the new PermittedSubclasses attribute to enforce that >> ??? a class or interface, whose super is a sealed class or interface, >> ??? must be listed in the super's PermittedSubclasses attribute. >> ??* Disallow redefinition of a sealed class or interface if its >> ??? redefinition would change its PermittedSubclasses attribute. >> ??* Support API's to determine if a class or interface is sealed and, if >> ??? it's sealed, return a list of its permitted subclasses. >> ??* asm support for the PermittedSubclasses attribute > > I assume Remi is providing the upstream support in ASM? :) But also > see below ... > >> >> Open Webrev: >> http://cr.openjdk.java.net/~vromero/8225056/webrev.00/index.html > > make/data/jdwp/jdwp.spec > > There needs to be a sub-task and associated CSR request for this JDWP > spec update. I couldn't see this covered anywhere. > > --- > > src/hotspot/share/classfile/classFileParser.cpp > > 3215 u2 > ClassFileParser::parse_classfile_permitted_subclasses_attribute(const > ClassFileStream* const cfs, > 3216 const u1* const permitted_subclasses_attribute_start, > 3217 TRAPS) { > > Indention on L3216/17 needs fixing after the copy'n'edit. > > 3515?? return _major_version == JVM_CLASSFILE_MAJOR_VERSION && > 3516????????????? _minor_version == JAVA_PREVIEW_MINOR_VERSION && > 3517????????????? Arguments::enable_preview(); > > Too much indentation on L3516/17 > > 3790???????????????? // Check for PermittedSubclasses tag > > That comment (copied from my nestmates code :) is in the wrong place. > It needs to be before > > 3788???????????? if (tag == vmSymbols::tag_permitted_subclasses()) { > > > Minor nit: I would suggest checking > parsed_permitted_subclasses_attribute before checking ACC_FINAL. > > 3876?? if (parsed_permitted_subclasses_attribute) { > 3877???? const u2 num_of_subclasses = > parse_classfile_permitted_subclasses_attribute( > 3878??????????????????????????????????? cfs, > 3879 permitted_subclasses_attribute_start, > 3880??????????????????????????????????? CHECK); > > Although it looks odd the preceding, similarly shaped, sections all > indent to the same absolute position. Can you make L3878/78/80 match > please. > > 3882?????? guarantee_property( > 3883???????? permitted_subclasses_attribute_length == > 3884?????????? sizeof(num_of_subclasses) + sizeof(u2) * > num_of_subclasses, > 3885???????? "Wrong PermittedSubclasses attribute length in class file > %s", CHECK); > > Nits: please reformat as: > > 3882?????? guarantee_property( > 3883???????? permitted_subclasses_attribute_length == > sizeof(num_of_subclasses) + sizeof(u2) * num_of_subclasses, > 3885???????? "Wrong PermittedSubclasses attribute length in class file > %s", CHECK); > > It would also look slightly better if you shortened the name of the > num_of_subclasses variable. All of the above classFileParser.cpp changes were done. > > --- > > src/hotspot/share/classfile/classFileParser.hpp > > +?? u2 parse_classfile_permitted_subclasses_attribute(const > ClassFileStream* const cfs, > +???????????????????????????????????????????? const u1* const > permitted_subclasses_attribute_start, > +???????????????????????????????????????????? TRAPS); > > Please fix indentation after copy'n'edit. Done. > > --- > > src/hotspot/share/oops/instanceKlass.cpp > > ?247?? if (classloader1 != classloader2) { > > I'm not clear what rule this is verifying. The same module check > follows this one. The rule is that the subclass must be accessible to > the superclass implying: > 1. same named module (regardless of class access modifiers); or > 2. (implicitly in un-named module) same package if subclass not > public; or > 3. public subclass > > Having the same classloader implies same package, but that alone > doesn't address 2 or 3. So this doesn't conform to proposed JVMS rules. This was discussed as part of the CSR and hopefully clarified. > > > > ?264???? if (_constants->tag_at(cp_index).is_klass()) { > ?265?????? Klass* k2 = _constants->klass_at(cp_index, CHECK_false); > > You've copied this code from the nestmember checks but your changes > don't quite make sense to me. If we have already checked is_klass() > then klass_at() cannot lead to any exceptions. > > ?272?????? if (name == k->name()) { > ?273???????? log_trace(class, sealed)("- Found it at > permitted_subclasses[%d] => cp[%d]", i, cp_index); > ?274???????? return true; > > I was wondering why you don't resolve the cp entry when you find the > name matches, as we do for nest members, but realized that unlike the > nest membership check, which can happen many times for a given class, > this permitted subclass check can only happen once per class. As you > don't actually resolve here, and given that the earlier check cannot > throw exceptions, it follows that the entire method never results in > any exceptions and so callers should not be using the CHECK macro. The comparison of class loaders was removed because checking that the two classes are in the same module ensures that they have the same class loader. The traps parameter was removed.? The CHECK macro was replaced with THREAD. > > --- > > src/hotspot/share/oops/method.cpp > > I don't understand how knowing the class is sealed allows you to infer > that a non-final method is actually final ?? This change was removed.? See item #3 at the beginning of this email. > > --- > > ?src/hotspot/share/prims/jvm.cpp > > It would be simpler (and cheaper) if the Java side of this ensures it > doesn't call into the VM with an array or primitive class. Done. > > --- > > ?src/hotspot/share/prims/jvmti.xml > > The JVM TI spec changes also need to be covered by a CSR request. > > --- > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp > > We should file a RFE to refactor the logic that checks that an > attribute consisting of a list of classes has not changed. :) Serguei filed the RFE. > > Aside: I spotted a bug in the nest member code (missing NULL check!) > thanks to your change :) > > --- > > src/java.base/share/classes/java/lang/Class.java > > There needs to be a CSR request for these changes. The CSR is JDK-8244556. > > +????? * Returns an array containing {@code ClassDesc} objects > representing all the > +????? * permitted subclasses of this {@linkplain Class} if it is > sealed. Returns an empty array if this > +????? * {@linkplain Class} is not sealed. > > should add "or this class represents an array or primitive type" > (using the standard wording for such cases). Discussed off-line and was decided that this text isn't needed. > > +????? * @throws IllegalArgumentException if a class descriptor is not > in the correct format > > IllegalArgumentException is not an appropriate exception to use as > this method takes no arguments. If the class descriptor is not valid > and it comes from the VM then I think we have a problem with how the > VM validates class descriptors. Any IAE from ClassDesc.of should be > caught and converted to a more suitable exception type - preferably > InternalError if the VM should always return valid strings. Done. > > +???? public ClassDesc[] getPermittedSubclasses() { > > As mentioned for jvm.cpp this Java code should do the isArray() and > isPrimitive() check before calling the VM. Done. > > +???????? String[] descriptors = getPermittedSubclasses0(); > > Nit: what you get from the VM are not descriptors, just name strings > in internal form. This wouldn't really matter except it then looks > strange to call ClassDesc.of(...) instead of ClassDesc.ofDescriptor(...). We tried using ClassDesc.ofDescriptor() but encountered problems. The variable 'descriptors' was renamed 'subclassNames'. > > +???????? if (descriptors == null > > The VM never returns null. The check was removed. > > +???????? return getPermittedSubclasses().length != 0; > > It's grossly inefficient to create the ClassDesc array and then throw > it away IMO. The result should be cached either in a field of Class or > in the ReflectionData of the class. Done. > > --- > > src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java > > > !???????? // - The offset of the PermittedSubclasses attribute, or 0 > ????????? int permittedSubtypesOffset = 0; > > Obviously ASM already has some prelim support for sealed classes, but > now that the attribute has been renamed that should also flow through > to the ASM code ie the variable, not just the comment. > > Ditto for ClassWriter.java and its fields. Done. > > --- > > src/java.base/share/native/libjava/Class.c > > ????? {"isRecord0",??????????? "()Z",???????? (void *)&JVM_IsRecord}, > +???? {"getPermittedSubclasses0", "()[" STR,??? (void > *)&JVM_GetPermittedSubclasses}, > > please align (void > Done. > --- > > src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java > > src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java > > There needs to be a CSR for these changes too. > > --- > > test/langtools/tools/javac/processing/model/TestSourceVersion.java > > !??????????????????? // Assume "record" and "sealed" will be > restricted keywords. > !??????????????????? "record", "sealed"); > > What about the non-sealed keyword defined in the JEP? 'non-sealed' is a keyword but not a restricted keyword.? So, it should not be in the list. > > --- > > In the tests you don't need to explicitly include > sun.hotspot.WhiteBox$WhiteBoxPermission on the ClassFileInstaller > invocation. (previous RFE's have been removing existing occurrences > after the CFI was fixed to handle it internally). Done. > > Please ensure all new tests have an @bug 8225056 (or whatever the > actual JBS issue will be) Done. > > All test classes (and thus files) should be named in camel-case i.e. > C1 not c1, C2 not c2, SuperClass not superClass etc. Done. > > > test/hotspot/jtreg/runtime/modules/sealedP1/superClass.jcod > test/hotspot/jtreg/runtime/sealedClasses/Pkg/sealedInterface.jcod > > Please add comments clarifying why these must be jcod files. Done. Thanks!? Harold > > --- > > That's it from me. > > Thanks, > David > ----- > > > >> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8225056 >> >> Java Language Spec changes: >> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html >> >> >> JVM Spec changes: >> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jvms.html >> >> >> JEP 360: https://bugs.openjdk.java.net/browse/JDK-8227043 >> >> JVM CSR: https://bugs.openjdk.java.net/browse/JDK-8242578 >> >> Changes to javac and other language tools will be reviewed separately. >> >> Thanks, Harold >> >> From harold.seigel at oracle.com Thu May 21 18:43:17 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Thu, 21 May 2020 14:43:17 -0400 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: <8a20c6da-24a6-de3e-c672-d57f57dc6319@oracle.com> References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> <8a20c6da-24a6-de3e-c672-d57f57dc6319@oracle.com> Message-ID: <976f4813-879a-3354-43ea-84f37d6b3d4a@oracle.com> Hi Mandy, Thanks for the suggestions.? They have been incorporated in the revised webrev. http://cr.openjdk.java.net/~hseigel/webrev.01/webrev/ Harold On 5/20/2020 1:05 PM, Mandy Chung wrote: > Hi Vicente, > > On 5/20/20 8:40 AM, Vicente Romero wrote: >> Hi David, >> >>> src/java.base/share/classes/java/lang/Class.java >>> >>> There needs to be a CSR request for these changes. >> >> yes there is one already: >> https://bugs.openjdk.java.net/browse/JDK-8244556 > > Adding to David's comment w.r.t. @throws IAE: > > The Class::getXXX APIs returns `Class` or `Class[]` if the result is > about type(s).? This new `getPermittedSubclasses` returns > `ClassDesc[]`.?? I wonder if this should be renamed to > `permittedSubclasses` to follow the convention of the new APIs added > to support descriptors e.g. `describeConstable` > > Nit: {@linkplain Class} should be {@code Class} > > Mandy From andy.herrick at oracle.com Thu May 21 18:55:29 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Thu, 21 May 2020 14:55:29 -0400 Subject: RFR: 8237908: [TESTBUG] [macos] Add support to jtreg helpers to unpack pkg packages In-Reply-To: <6b49a035-62f0-abda-8627-08937dee0666@oracle.com> References: <6b49a035-62f0-abda-8627-08937dee0666@oracle.com> Message-ID: <42475956-aa41-5a78-aa2b-1f6be011efcd@oracle.com> looks good. /Andy On 5/21/2020 4:16 AM, alexander.matveev at oracle.com wrote: > Please review the jpackage fix for bug [1] at [2]. > > - Added support for unpacking pkg. > > [1] https://bugs.openjdk.java.net/browse/JDK-8237908 > > [2] http://cr.openjdk.java.net/~almatvee/8237908/webrev.00/ > > Thanks, > Alexander From naoto.sato at oracle.com Thu May 21 19:00:42 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 21 May 2020 12:00:42 -0700 Subject: [15] RFR: 8245241: Incorrect locale provider preference is not logged In-Reply-To: <7f4db42f-1873-3d08-2537-b20279c74ab0@oracle.com> References: <4ab22033-8eda-e96b-3898-0525a43e29fd@oracle.com> <7f4db42f-1873-3d08-2537-b20279c74ab0@oracle.com> Message-ID: <2714c058-ba41-2f26-52fa-f2b5b8eef382@oracle.com> Hi Daniel, Thank you for your review! On 5/21/20 3:42 AM, Daniel Fuchs wrote: > Hi Naoto, > > Logging uses: > > ZonedDateTime zdt = ZonedDateTime.ofInstant( > ??????????????? record.getInstant(), ZoneId.systemDefault()); > > and then > > String.format("%1$tb %1$td, %1$tY %1$tl:%1$tM:%1$tS %1$Tp %2$s%n%4$s: > %5$s%6$s%n", ...) > > to format the date. > > If the locale provider can't be loaded, is that going to cause problem, > when logging is invoked to log the info/warning? > > In particular: > java.base/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java > > ?197 getLogger(LocaleProviderAdapter.class.getCanonicalName()) > ?198???????????????????????????? .log(Logger.Level.INFO, e); > ?199???????????????????? adapterInstances.putIfAbsent(type, > NONEXISTENT_ADAPTER); > ?200???????????????????? if (defaultLocaleProviderAdapter == type) { > ?201???????????????????????? defaultLocaleProviderAdapter = Type.FALLBACK; > ?202???????????????????? } > > Maybe logging should only be invoked *after* lines 199-202? In fact, this piece of code should not happen as those adapter classes are all JDK provided classes. I replaced the above code with ServiceConfigurationError, like other similar locations (e.g, HostLocaleProviderAdapter - line 64-65). Updated the webrev: http://cr.openjdk.java.net/~naoto/8245241/webrev.01/ > > Same potential issue in > src/java.base/share/classes/sun/util/locale/provider/LocaleServiceProviderPool.java > > > lines 367-372 This should be fine, as LocaleProviderAdapter should properly have been initialized at this point. Naoto > > best regards, > > -- daniel > > On 20/05/2020 18:29, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8245241 >> >> The proposed changeset is located at: >> >> https://cr.openjdk.java.net/~naoto/8245241/webrev.00/ >> >> Incorrect user-provided provider preference is supposed to be logged. >> However it is not so because it is using >> PlatformLogger(SurrogateLogger) which uses the default logging level. >> I changed it to use j.l.System's logger and bumped it to INFO level >> (it should notify the user by default). By taking this opportunity, I >> did some clean-up in locale provider adapter's logging related code as >> well. >> >> Naoto > From daniel.fuchs at oracle.com Thu May 21 20:00:16 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 21 May 2020 21:00:16 +0100 Subject: [15] RFR: 8245241: Incorrect locale provider preference is not logged In-Reply-To: <2714c058-ba41-2f26-52fa-f2b5b8eef382@oracle.com> References: <4ab22033-8eda-e96b-3898-0525a43e29fd@oracle.com> <7f4db42f-1873-3d08-2537-b20279c74ab0@oracle.com> <2714c058-ba41-2f26-52fa-f2b5b8eef382@oracle.com> Message-ID: Hi Naoto, On 21/05/2020 20:00, naoto.sato at oracle.com wrote: > In fact, this piece of code should not happen as those adapter classes > are all JDK provided classes. I replaced the above code with > ServiceConfigurationError, like other similar locations (e.g, > HostLocaleProviderAdapter - line 64-65). Updated the webrev: > > http://cr.openjdk.java.net/~naoto/8245241/webrev.01/ > That addresses my concern. Thanks! best regards, -- daniel From mark.reinhold at oracle.com Thu May 21 21:27:25 2020 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 21 May 2020 14:27:25 -0700 (PDT) Subject: New candidate JEP: 385: Deprecate RMI Activation for Removal Message-ID: <20200521212725.F35A8351D2C@eggemoggin.niobe.net> https://openjdk.java.net/jeps/385 - Mark From alexey.semenyuk at oracle.com Fri May 22 00:28:05 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Thu, 21 May 2020 20:28:05 -0400 Subject: RFR: 8237908: [TESTBUG] [macos] Add support to jtreg helpers to unpack pkg packages In-Reply-To: <42475956-aa41-5a78-aa2b-1f6be011efcd@oracle.com> References: <6b49a035-62f0-abda-8627-08937dee0666@oracle.com> <42475956-aa41-5a78-aa2b-1f6be011efcd@oracle.com> Message-ID: Looks good. - Alexey On 5/21/2020 2:55 PM, Andy Herrick wrote: > looks good. > > /Andy > > On 5/21/2020 4:16 AM, alexander.matveev at oracle.com wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> - Added support for unpacking pkg. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8237908 >> >> [2] http://cr.openjdk.java.net/~almatvee/8237908/webrev.00/ >> >> Thanks, >> Alexander From mikael.vidstedt at oracle.com Fri May 22 03:28:30 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 21 May 2020 20:28:30 -0700 Subject: RFR(S): 8245600: Clean up libjli Message-ID: <91AE4C99-F36E-41F3-BF13-174DAB40EC92@oracle.com> Please review this change which cleans up the libjli related files a bit: JBS: https://bugs.openjdk.java.net/browse/JDK-8245600 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8245600/webrev.00/open/webrev/ Background: During the review of JDK-8244224 it was noticed that the java_md_solinux* files should be renamed and/or cleaned up. After a quick look I noticed that some relatively straightforward cleanup was possible that removed some obvious duplication. Details: * Replace CounterGet and Counter2Micros with a single TimeGetNowMicros. Unify the macosx and unix implementations and put the (only) implementation in java_md_common.c. * Remove the unused user_dir definition (dead code since https://bugs.openjdk.java.net/browse/JDK-8058407) * Move the only remaining code - the environ definition and two #includes - from java_md_{solinux,macosx}.h to the unix java_md.h header file * Rename java_md_solinux.c to java_md.c (which also matches the name of the file on windows) Testing: Tier1 Cheers, Mikael From david.holmes at oracle.com Fri May 22 04:07:19 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 May 2020 14:07:19 +1000 Subject: RFR(S): 8245600: Clean up libjli In-Reply-To: <91AE4C99-F36E-41F3-BF13-174DAB40EC92@oracle.com> References: <91AE4C99-F36E-41F3-BF13-174DAB40EC92@oracle.com> Message-ID: Hi Mikael, Cleanup looks good to me. Bikeshed: TimeGetNowMicros -> GetTimeMicros or CurrentTimeMicros ? Thanks, David On 22/05/2020 1:28 pm, Mikael Vidstedt wrote: > > Please review this change which cleans up the libjli related files a bit: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8245600 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8245600/webrev.00/open/webrev/ > > Background: > > During the review of JDK-8244224 it was noticed that the java_md_solinux* files should be renamed and/or cleaned up. After a quick look I noticed that some relatively straightforward cleanup was possible that removed some obvious duplication. > > Details: > > * Replace CounterGet and Counter2Micros with a single TimeGetNowMicros. Unify the macosx and unix implementations and put the (only) implementation in java_md_common.c. > * Remove the unused user_dir definition (dead code since https://bugs.openjdk.java.net/browse/JDK-8058407) > * Move the only remaining code - the environ definition and two #includes - from java_md_{solinux,macosx}.h to the unix java_md.h header file > * Rename java_md_solinux.c to java_md.c (which also matches the name of the file on windows) > > Testing: > > Tier1 > > Cheers, > Mikael > From daniel.fuchs at oracle.com Fri May 22 09:33:01 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 22 May 2020 10:33:01 +0100 Subject: 8239013: java.util.logging.Logger catalog cache keeps strong references to ResourceBundles Message-ID: <03661db5-39e5-09f6-7cf5-82e7dfb823ac@oracle.com> Hi, Please find below a fix for: 8239013: java.util.logging.Logger catalog cache keeps strong references to ResourceBundles https://bugs.openjdk.java.net/browse/JDK-8239013 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8239013/webrev.00/ java.util.logging.Logger has a `catalog` variable that acts as a cache and holds a reference to the last resource bundle that was loaded by the logger. This fix replaces the strong reference with a weak reference, allowing the cached object to be garbage collected even in cases where a strong reference to the logger remains. best regards, -- daniel From claes.redestad at oracle.com Fri May 22 09:33:00 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 22 May 2020 11:33:00 +0200 Subject: RFR: 8245619: Remove unused methods in UnixNativeDispatcher Message-ID: <50837179-2579-acd0-7fa8-30e76fcecf6d@oracle.com> Hi, this patch removes four orphaned methods from UnixNativeDispatcher that are no longer used after the Solaris removal: Webrev: http://cr.openjdk.java.net/~redestad/8245619/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8245619 Testing: tier1 Thanks! /Claes From Alan.Bateman at oracle.com Fri May 22 09:36:08 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 May 2020 10:36:08 +0100 Subject: RFR: 8245619: Remove unused methods in UnixNativeDispatcher In-Reply-To: <50837179-2579-acd0-7fa8-30e76fcecf6d@oracle.com> References: <50837179-2579-acd0-7fa8-30e76fcecf6d@oracle.com> Message-ID: <085211a6-a86b-e71a-0d9e-642666a91ce0@oracle.com> On 22/05/2020 10:33, Claes Redestad wrote: > Hi, > > this patch removes four orphaned methods from UnixNativeDispatcher that > are no longer used after the Solaris removal: > > Webrev: http://cr.openjdk.java.net/~redestad/8245619/open.00/ > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8245619 Looks good, I suspect there will many follow on changes to cleanup after the removal of the Solaris port. -Alan From claes.redestad at oracle.com Fri May 22 09:39:47 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 22 May 2020 11:39:47 +0200 Subject: RFR: 8245619: Remove unused methods in UnixNativeDispatcher In-Reply-To: <085211a6-a86b-e71a-0d9e-642666a91ce0@oracle.com> References: <50837179-2579-acd0-7fa8-30e76fcecf6d@oracle.com> <085211a6-a86b-e71a-0d9e-642666a91ce0@oracle.com> Message-ID: <09851f91-3dbd-8eda-76d4-851372170e7e@oracle.com> On 2020-05-22 11:36, Alan Bateman wrote: > On 22/05/2020 10:33, Claes Redestad wrote: >> Hi, >> >> this patch removes four orphaned methods from UnixNativeDispatcher that >> are no longer used after the Solaris removal: >> >> Webrev: http://cr.openjdk.java.net/~redestad/8245619/open.00/ >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8245619 > Looks good, I suspect there will many follow on changes to cleanup after > the removal of the Solaris port. > > -Alan Thanks! /Claes From claes.redestad at oracle.com Fri May 22 09:52:47 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 22 May 2020 11:52:47 +0200 Subject: RFR: 8245455: Remove alternative StringConcatFactory strategies Message-ID: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> Hi, this patch removes the alternative, undocumented strategies from StringConcatFactory. The default strategy has been optimized and stabilized since inception in JDK 9, while the alternative strategies have been falling behind both in terms of performance and stability - while adding maintenance cost. The removal allows some simplifications to the code that will reduce per callsite bootstrap overhead, and reduce what we need to load eagerly during bootstrap. I've also applied the pattern from JDK-8218173 to the remaining Stringifier method handles, which further improve robustness of bootstrapping under an OOME condition. Webrev: http://cr.openjdk.java.net/~redestad/8245455/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8245455 Testing: tier1-3 Thanks! /Claes From Alan.Bateman at oracle.com Fri May 22 11:27:24 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 22 May 2020 12:27:24 +0100 Subject: RFR(S): 8245600: Clean up libjli In-Reply-To: <91AE4C99-F36E-41F3-BF13-174DAB40EC92@oracle.com> References: <91AE4C99-F36E-41F3-BF13-174DAB40EC92@oracle.com> Message-ID: <1b17af60-92ed-9ce1-8ede-350fb976b5e3@oracle.com> On 22/05/2020 04:28, Mikael Vidstedt wrote: > Please review this change which cleans up the libjli related files a bit: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8245600 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8245600/webrev.00/open/webrev/ > Looks good, don't have a strong opinion on the function name but if I were doing this when I'd probably got for something like CurrentTimeMicros. Minor nit is that the JLI_TraceLauncher usages in java.c probably don't need to be across two lines now. -Alan. From shade at redhat.com Fri May 22 11:43:15 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 22 May 2020 13:43:15 +0200 Subject: RFR: 8245455: Remove alternative StringConcatFactory strategies In-Reply-To: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> References: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> Message-ID: <68fdbafb-e3be-4ada-2b93-6a87a1862ed2@redhat.com> On 5/22/20 11:52 AM, Claes Redestad wrote: > Webrev: http://cr.openjdk.java.net/~redestad/8245455/open.00/ The experience with dealing with string concat bugs tells me we better leave at least one strategy as the fallback. It does not have to be very optimized, but it needs to be definitely correct. BC_SB seems to fit the bill here. -- Thanks, -Aleksey From claes.redestad at oracle.com Fri May 22 11:53:33 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 22 May 2020 13:53:33 +0200 Subject: RFR: 8245455: Remove alternative StringConcatFactory strategies In-Reply-To: <68fdbafb-e3be-4ada-2b93-6a87a1862ed2@redhat.com> References: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> <68fdbafb-e3be-4ada-2b93-6a87a1862ed2@redhat.com> Message-ID: <2c3d074d-7a4f-ea8c-0201-fa4d32f5b9f1@oracle.com> On 2020-05-22 13:43, Aleksey Shipilev wrote: > On 5/22/20 11:52 AM, Claes Redestad wrote: >> Webrev: http://cr.openjdk.java.net/~redestad/8245455/open.00/ > > The experience with dealing with string concat bugs tells me we better leave at least one strategy > as the fallback. It does not have to be very optimized, but it needs to be definitely correct. BC_SB > seems to fit the bill here. > Do you have any example of a case when one of the fallbacks was used to work around any issues? We've heard of no such case. BC_SB has a rather intricate dependency on ASM, and recent stabilization work done to the default strategy will need to be duplicated. If we were to keep a fallback (which I don't think we actually need), I'd prefer keeping either MH_SB_SIZED or MH_SB_SIZED_EXACT. /Claes From shade at redhat.com Fri May 22 11:56:45 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 22 May 2020 13:56:45 +0200 Subject: RFR: 8245455: Remove alternative StringConcatFactory strategies In-Reply-To: <2c3d074d-7a4f-ea8c-0201-fa4d32f5b9f1@oracle.com> References: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> <68fdbafb-e3be-4ada-2b93-6a87a1862ed2@redhat.com> <2c3d074d-7a4f-ea8c-0201-fa4d32f5b9f1@oracle.com> Message-ID: On 5/22/20 1:53 PM, Claes Redestad wrote: > Do you have any example of a case when one of the fallbacks was used to > work around any issues? We've heard of no such case. For example, the bug in j.l.invoke caused semantic bug in String concat: https://bugs.openjdk.java.net/browse/JDK-8200118 https://bugs.openjdk.java.net/browse/JDK-8194554 > BC_SB has a rather intricate dependency on ASM, and recent stabilization > work done to the default strategy will need to be duplicated. If we were > to keep a fallback (which I don't think we actually need), I'd prefer > keeping either MH_SB_SIZED or MH_SB_SIZED_EXACT. See above. I believe we better have the fallback that does not enter the meat of j.l.invoke at all. -- Thanks, -Aleksey From claes.redestad at oracle.com Fri May 22 12:16:25 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 22 May 2020 14:16:25 +0200 Subject: RFR: 8245455: Remove alternative StringConcatFactory strategies In-Reply-To: References: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> <68fdbafb-e3be-4ada-2b93-6a87a1862ed2@redhat.com> <2c3d074d-7a4f-ea8c-0201-fa4d32f5b9f1@oracle.com> Message-ID: <61f1f7dc-4499-1dd0-1179-c7acacda4173@oracle.com> On 2020-05-22 13:56, Aleksey Shipilev wrote: > On 5/22/20 1:53 PM, Claes Redestad wrote: >> Do you have any example of a case when one of the fallbacks was used to >> work around any issues? We've heard of no such case. > > For example, the bug in j.l.invoke caused semantic bug in String concat: > https://bugs.openjdk.java.net/browse/JDK-8200118 > https://bugs.openjdk.java.net/browse/JDK-8194554 Good correctness fixes, both to underlying j.l.invoke machinery and the default strategy. What I'm asking for is whether there exist any operational issues that means users have to use any of the fallback strategies in the wild on JDK 11/14 today. That would be a good argument to keep maintaining the code, but I've not heard of such a case. For testing and verifying the correctness of dynamic concat callsites we have the javac fallback to emit SB chains (-XDstringConcat=inline) - maintaining another fallback strategy is duplication of effort and a source of potential bugs in its own right. /Claes > >> BC_SB has a rather intricate dependency on ASM, and recent stabilization >> work done to the default strategy will need to be duplicated. If we were >> to keep a fallback (which I don't think we actually need), I'd prefer >> keeping either MH_SB_SIZED or MH_SB_SIZED_EXACT. > > See above. I believe we better have the fallback that does not enter the meat of j.l.invoke at all. > From shade at redhat.com Fri May 22 12:40:11 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 22 May 2020 14:40:11 +0200 Subject: RFR: 8245455: Remove alternative StringConcatFactory strategies In-Reply-To: <61f1f7dc-4499-1dd0-1179-c7acacda4173@oracle.com> References: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> <68fdbafb-e3be-4ada-2b93-6a87a1862ed2@redhat.com> <2c3d074d-7a4f-ea8c-0201-fa4d32f5b9f1@oracle.com> <61f1f7dc-4499-1dd0-1179-c7acacda4173@oracle.com> Message-ID: <84f61a39-ab78-87ff-12d0-6499f4c5f00f@redhat.com> On 5/22/20 2:16 PM, Claes Redestad wrote: > What I'm asking for is whether there exist any operational issues that > means users have to use any of the fallback strategies in the wild on > JDK 11/14 today. That would be a good argument to keep maintaining the > code, but I've not heard of such a case. Well, I myself thought there are "no operational issues" with string concat too for years after it was in. Until at least two major bugs (one is this filter-order issue, and other is "+=" issue) were discovered. This makes me extremely averse of sticking with a single strategy. And I think you should be averse too! We know that good JVMs have runtime killswitch options to be used when something goes wrong. The killswitch might be removed after we are definitely sure most users migrated to the common path, and after that happens, no issues were reported for a while. As it stands right now, the migration from 8 is far, far, far from over, and so I would not discount the possibility new issues come up during that migration. Having no fallback means issue in MH_* string concat strategy would be a showstopper. Having a very simple fallback strategy today is a responsible thing to do, even if it makes maintenance harder. I understand the maintainability argument, and I think that removing most strategies strikes the balance between maintainability and the width of the reliability safety net. Let's just not remove all-but-one-we-hope-is-right. > For testing and verifying the correctness of dynamic concat callsites we > have the javac fallback to emit SB chains (-XDstringConcat=inline) - > maintaining another fallback strategy is duplication of effort and a > source of potential bugs in its own right. -XDstringConcat is the compilation time killswitch, it is not the same. I don't think we would ask users to recompile the JARs they got from Maven Central to deploy the workaround. Runtime option that enables a fallback strategy is what is needed for field deployment when things go very wrong. -- Thanks, -Aleksey From aph at redhat.com Fri May 22 13:00:58 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 May 2020 14:00:58 +0100 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: References: Message-ID: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> On 5/19/20 11:55 AM, Yang Zhang wrote: > Following up on review requests of API [0], Java implementation and > test [1], General Hotspot changes[2] for Vector API and x86 backend > changes [3]. Here's a request for review of AArch64 backend changes > required for supporting the Vector API: > > JEP: https://openjdk.java.net/jeps/338 > JBS: https://bugs.openjdk.java.net/browse/JDK-8223347 > Webrev: http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.01/ > > Complete implementation resides in vector-unstable branch of panama/dev > repository [4]. This looks great, and it's very impressive. Unfortunately, there are few of us sufficiently knowledgeable about Panama to review it in the detail that perhaps it deserves. I'm happy with it. However, we need tests for the new assembly instructions, so please add some to aarch64_asmtest.py and update macroassemler.cpp. Also, aarch64.ad is getting to be far too large, and perhaps all the vector stuff should be moved into a new file. Thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Roger.Riggs at oracle.com Fri May 22 13:24:02 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Fri, 22 May 2020 09:24:02 -0400 Subject: [15] RFR: 8239480: Support for CLDR version 37 In-Reply-To: References: Message-ID: Looks fine. On 5/20/20 5:31 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8239480 > > The proposed changeset, and the release note draft are located at: > > https://cr.openjdk.java.net/~naoto/8239480/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8243581 > > This updates the CLDR locale data to version 37. Although the > changeset is huge, this mainly consists of the locale data and > licenses changes. Other than those, only one test case was updated > (IncludeLocalesPluginTest.java) due to the locale data change. > > Naoto From lance.andersen at oracle.com Fri May 22 13:24:33 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 22 May 2020 09:24:33 -0400 Subject: 8239013: java.util.logging.Logger catalog cache keeps strong references to ResourceBundles In-Reply-To: <03661db5-39e5-09f6-7cf5-82e7dfb823ac@oracle.com> References: <03661db5-39e5-09f6-7cf5-82e7dfb823ac@oracle.com> Message-ID: <2A27F39A-B0E4-4B2A-9828-2EB830DE6C66@oracle.com> Hi Daniel, This looks good to me :-) Best Lance > On May 22, 2020, at 5:33 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > > 8239013: java.util.logging.Logger catalog cache keeps strong > references to ResourceBundles > https://bugs.openjdk.java.net/browse/JDK-8239013 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8239013/webrev.00/ > > java.util.logging.Logger has a `catalog` variable that acts > as a cache and holds a reference to the last resource bundle > that was loaded by the logger. > > This fix replaces the strong reference with a weak reference, > allowing the cached object to be garbage collected even in > cases where a strong reference to the logger remains. > > > best regards, > > -- daniel Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From claes.redestad at oracle.com Fri May 22 13:55:49 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 22 May 2020 15:55:49 +0200 Subject: RFR: 8245455: Remove alternative StringConcatFactory strategies In-Reply-To: <84f61a39-ab78-87ff-12d0-6499f4c5f00f@redhat.com> References: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> <68fdbafb-e3be-4ada-2b93-6a87a1862ed2@redhat.com> <2c3d074d-7a4f-ea8c-0201-fa4d32f5b9f1@oracle.com> <61f1f7dc-4499-1dd0-1179-c7acacda4173@oracle.com> <84f61a39-ab78-87ff-12d0-6499f4c5f00f@redhat.com> Message-ID: <3381f1e5-dd7f-6d7b-2b60-1dc7daa6ca7a@oracle.com> On 2020-05-22 14:40, Aleksey Shipilev wrote: > On 5/22/20 2:16 PM, Claes Redestad wrote: >> What I'm asking for is whether there exist any operational issues that >> means users have to use any of the fallback strategies in the wild on >> JDK 11/14 today. That would be a good argument to keep maintaining the >> code, but I've not heard of such a case. > > Well, I myself thought there are "no operational issues" with string concat too for years after it > was in. Until at least two major bugs (one is this filter-order issue, and other is "+=" issue) were > discovered. This makes me extremely averse of sticking with a single strategy. And I think you > should be averse too! There are no guarantees any particular fallback is not going to break in similar ways or - more likely - bit rot and break sooner. Seeing how all but the default strategy sees rather superficial testing in practice, I think you are exaggerating the value they provide as a safety net against future unknowns. Fixing some bootstrap robustness issues of late has me convinced that maintaining and verifying the fallback strategies is not worth our while. See e.g. https://bugs.openjdk.java.net/browse/JDK-8218173 - fixing this for the fallback strategies might be straightforward (or not), but to then verify it's actually fixed would require we add runs with $chosen_fallback_strategy to our entire testing for weeks. So no, I'm not particularly worried about reducing this down to a single strategy here and now. We should of course keep investing in SCF to ensure it's as robust, performant and well-tested as can be. And of course promptly fix any bugs that we discover. > > We know that good JVMs have runtime killswitch options to be used when something goes wrong. The > killswitch might be removed after we are definitely sure most users migrated to the common path, and > after that happens, no issues were reported for a while. As it stands right now, the migration from > 8 is far, far, far from over, and so I would not discount the possibility new issues come up during > that migration. > > Having no fallback means issue in MH_* string concat strategy would be a showstopper. Having a very > simple fallback strategy today is a responsible thing to do, even if it makes maintenance harder. I > understand the maintainability argument, and I think that removing most strategies strikes the > balance between maintainability and the width of the reliability safety net. > > Let's just not remove all-but-one-we-hope-is-right. > >> For testing and verifying the correctness of dynamic concat callsites we >> have the javac fallback to emit SB chains (-XDstringConcat=inline) - >> maintaining another fallback strategy is duplication of effort and a >> source of potential bugs in its own right. > > -XDstringConcat is the compilation time killswitch, it is not the same. I don't think we would ask > users to recompile the JARs they got from Maven Central to deploy the workaround. Runtime option > that enables a fallback strategy is what is needed for field deployment when things go very wrong. > I only suggested recompiling with -XDstringConcat=inline as a way to verify and test behavior. /Claes From james.laskey at oracle.com Fri May 22 14:00:39 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Fri, 22 May 2020 11:00:39 -0300 Subject: RFR: 8245455: Remove alternative StringConcatFactory strategies In-Reply-To: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> References: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> Message-ID: LGTM. > On May 22, 2020, at 6:52 AM, Claes Redestad wrote: > > Hi, > > this patch removes the alternative, undocumented strategies from > StringConcatFactory. > > The default strategy has been optimized and stabilized since inception in JDK 9, while the alternative strategies have been falling behind > both in terms of performance and stability - while adding maintenance > cost. > > The removal allows some simplifications to the code that will reduce > per callsite bootstrap overhead, and reduce what we need to load eagerly > during bootstrap. I've also applied the pattern from JDK-8218173 to > the remaining Stringifier method handles, which further improve > robustness of bootstrapping under an OOME condition. > > Webrev: http://cr.openjdk.java.net/~redestad/8245455/open.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8245455 > > Testing: tier1-3 > > Thanks! > > /Claes From lois.foltan at oracle.com Fri May 22 15:07:06 2020 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 22 May 2020 11:07:06 -0400 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> Message-ID: On 5/21/2020 2:33 PM, Harold Seigel wrote: > Hi David, > > Thanks for looking at this!? Please review this new webrev: > > ?? http://cr.openjdk.java.net/~hseigel/webrev.01/webrev/ Hi Harold, I think this webrev looks good!? A couple of minor comments: - oops/instanceKlass.cpp: ? line #236, do you need a ResourceMark here? I noticed there is one above at line #229 for the log_trace call that uses external_name(). - prims/jvmtiRedefineClasses.cpp: ? line #878, I think you need a ResourceMark for this method as well if you invoke the external_name for the log_trace calls and for NEW_RESOURCE_ARRAY_RETURN_NULL()? Tests look good. Thanks, Lois > > This webrev contains the following significant changes: > > 1. The format/indentation issues in classFileParser.cpp were fixed. > 2. Unneeded checks in InstanceKlass::has_as_permitted_subclass() were > ?? removed and the TRAPS parameter was removed. > 3. The changes to klassVtable.* and method.* were reverted. Those > ?? changes were from when sealed classes were marked as final, and are > ?? no longer valid. > 4. Method getPermittedSubclasses() in Class.java was renamed to > ?? permittedSubclasses() and its implementation was changed. > 5. Variables and methods for 'asm' were renamed from > ?? 'permittedSubtypes' to 'permittedSubclasses'. > 6. Classes for sealed classes tests were changed to start with capital > ?? letters. > 7. Changes to langtools tests were removed from this webrev. They are > ?? covered by the javac webrev (JDK-8244556). > 8. The CSR's for JVMTI, JDWP, and JDI are in progress. > > Please also see comments inline. > > > On 5/19/2020 1:26 AM, David Holmes wrote: >> Hi Harold, >> >> Adding serviceability-dev for the serviceability related changes. >> >> Nit: "VM support for sealed classes" >> >> This RFR covers the VM, core-libs, serviceability and even some >> langtools tests. AFAICS only the javac changes are not included here >> so when and where will they be reviewed and under what bug id? >> Ideally there will be a single JBS issue for "Implementation of JEP >> 360: Sealed types". It's okay to break up the RFRs across different >> areas, but it should be done under one bug id. > The javac changes are being reviewed as bug JDK-8227406.? We > understand the need to do the reviews under one bug. >> >> Overall this looks good. I've looked at all files and mainly have >> some style nits in various places. But there are some more >> significant items below. >> >> On 14/05/2020 7:09 am, Harold Seigel wrote: >>> Hi, >>> >>> Please review this patch for JVM and Core-libs support for the JEP >>> 360 Sealed Classes preview feature.? Code changes include the >>> following: >>> >>> ??* Processing of the new PermittedSubclasses attribute to enforce that >>> ??? a class or interface, whose super is a sealed class or interface, >>> ??? must be listed in the super's PermittedSubclasses attribute. >>> ??* Disallow redefinition of a sealed class or interface if its >>> ??? redefinition would change its PermittedSubclasses attribute. >>> ??* Support API's to determine if a class or interface is sealed >>> and, if >>> ??? it's sealed, return a list of its permitted subclasses. >>> ??* asm support for the PermittedSubclasses attribute >> >> I assume Remi is providing the upstream support in ASM? :) But also >> see below ... >> >>> >>> Open Webrev: >>> http://cr.openjdk.java.net/~vromero/8225056/webrev.00/index.html >> >> make/data/jdwp/jdwp.spec >> >> There needs to be a sub-task and associated CSR request for this JDWP >> spec update. I couldn't see this covered anywhere. >> >> --- >> >> src/hotspot/share/classfile/classFileParser.cpp >> >> 3215 u2 >> ClassFileParser::parse_classfile_permitted_subclasses_attribute(const >> ClassFileStream* const cfs, >> 3216 const u1* const permitted_subclasses_attribute_start, >> 3217 TRAPS) { >> >> Indention on L3216/17 needs fixing after the copy'n'edit. >> >> 3515?? return _major_version == JVM_CLASSFILE_MAJOR_VERSION && >> 3516????????????? _minor_version == JAVA_PREVIEW_MINOR_VERSION && >> 3517????????????? Arguments::enable_preview(); >> >> Too much indentation on L3516/17 >> >> 3790???????????????? // Check for PermittedSubclasses tag >> >> That comment (copied from my nestmates code :) is in the wrong place. >> It needs to be before >> >> 3788???????????? if (tag == vmSymbols::tag_permitted_subclasses()) { >> >> >> Minor nit: I would suggest checking >> parsed_permitted_subclasses_attribute before checking ACC_FINAL. >> >> 3876?? if (parsed_permitted_subclasses_attribute) { >> 3877???? const u2 num_of_subclasses = >> parse_classfile_permitted_subclasses_attribute( >> 3878??????????????????????????????????? cfs, >> 3879 permitted_subclasses_attribute_start, >> 3880??????????????????????????????????? CHECK); >> >> Although it looks odd the preceding, similarly shaped, sections all >> indent to the same absolute position. Can you make L3878/78/80 match >> please. >> >> 3882?????? guarantee_property( >> 3883???????? permitted_subclasses_attribute_length == >> 3884?????????? sizeof(num_of_subclasses) + sizeof(u2) * >> num_of_subclasses, >> 3885???????? "Wrong PermittedSubclasses attribute length in class >> file %s", CHECK); >> >> Nits: please reformat as: >> >> 3882?????? guarantee_property( >> 3883???????? permitted_subclasses_attribute_length == >> sizeof(num_of_subclasses) + sizeof(u2) * num_of_subclasses, >> 3885???????? "Wrong PermittedSubclasses attribute length in class >> file %s", CHECK); >> >> It would also look slightly better if you shortened the name of the >> num_of_subclasses variable. > All of the above classFileParser.cpp changes were done. >> >> --- >> >> src/hotspot/share/classfile/classFileParser.hpp >> >> +?? u2 parse_classfile_permitted_subclasses_attribute(const >> ClassFileStream* const cfs, >> +???????????????????????????????????????????? const u1* const >> permitted_subclasses_attribute_start, >> +???????????????????????????????????????????? TRAPS); >> >> Please fix indentation after copy'n'edit. > Done. >> >> --- >> >> src/hotspot/share/oops/instanceKlass.cpp >> >> ?247?? if (classloader1 != classloader2) { >> >> I'm not clear what rule this is verifying. The same module check >> follows this one. The rule is that the subclass must be accessible to >> the superclass implying: >> 1. same named module (regardless of class access modifiers); or >> 2. (implicitly in un-named module) same package if subclass not >> public; or >> 3. public subclass >> >> Having the same classloader implies same package, but that alone >> doesn't address 2 or 3. So this doesn't conform to proposed JVMS rules. > This was discussed as part of the CSR and hopefully clarified. >> >> >> >> ?264???? if (_constants->tag_at(cp_index).is_klass()) { >> ?265?????? Klass* k2 = _constants->klass_at(cp_index, CHECK_false); >> >> You've copied this code from the nestmember checks but your changes >> don't quite make sense to me. If we have already checked is_klass() >> then klass_at() cannot lead to any exceptions. >> >> ?272?????? if (name == k->name()) { >> ?273???????? log_trace(class, sealed)("- Found it at >> permitted_subclasses[%d] => cp[%d]", i, cp_index); >> ?274???????? return true; >> >> I was wondering why you don't resolve the cp entry when you find the >> name matches, as we do for nest members, but realized that unlike the >> nest membership check, which can happen many times for a given class, >> this permitted subclass check can only happen once per class. As you >> don't actually resolve here, and given that the earlier check cannot >> throw exceptions, it follows that the entire method never results in >> any exceptions and so callers should not be using the CHECK macro. > > The comparison of class loaders was removed because checking that the > two classes are in the same module ensures that they have the same > class loader. > > The traps parameter was removed.? The CHECK macro was replaced with > THREAD. > >> >> --- >> >> src/hotspot/share/oops/method.cpp >> >> I don't understand how knowing the class is sealed allows you to >> infer that a non-final method is actually final ?? > This change was removed.? See item #3 at the beginning of this email. >> >> --- >> >> ?src/hotspot/share/prims/jvm.cpp >> >> It would be simpler (and cheaper) if the Java side of this ensures it >> doesn't call into the VM with an array or primitive class. > Done. >> >> --- >> >> ?src/hotspot/share/prims/jvmti.xml >> >> The JVM TI spec changes also need to be covered by a CSR request. >> >> --- >> >> src/hotspot/share/prims/jvmtiRedefineClasses.cpp >> >> We should file a RFE to refactor the logic that checks that an >> attribute consisting of a list of classes has not changed. :) > Serguei filed the RFE. >> >> Aside: I spotted a bug in the nest member code (missing NULL check!) >> thanks to your change :) >> >> --- >> >> src/java.base/share/classes/java/lang/Class.java >> >> There needs to be a CSR request for these changes. > The CSR is JDK-8244556. >> >> +????? * Returns an array containing {@code ClassDesc} objects >> representing all the >> +????? * permitted subclasses of this {@linkplain Class} if it is >> sealed. Returns an empty array if this >> +????? * {@linkplain Class} is not sealed. >> >> should add "or this class represents an array or primitive type" >> (using the standard wording for such cases). > Discussed off-line and was decided that this text isn't needed. >> >> +????? * @throws IllegalArgumentException if a class descriptor is >> not in the correct format >> >> IllegalArgumentException is not an appropriate exception to use as >> this method takes no arguments. If the class descriptor is not valid >> and it comes from the VM then I think we have a problem with how the >> VM validates class descriptors. Any IAE from ClassDesc.of should be >> caught and converted to a more suitable exception type - preferably >> InternalError if the VM should always return valid strings. > Done. >> >> +???? public ClassDesc[] getPermittedSubclasses() { >> >> As mentioned for jvm.cpp this Java code should do the isArray() and >> isPrimitive() check before calling the VM. > Done. >> >> +???????? String[] descriptors = getPermittedSubclasses0(); >> >> Nit: what you get from the VM are not descriptors, just name strings >> in internal form. This wouldn't really matter except it then looks >> strange to call ClassDesc.of(...) instead of >> ClassDesc.ofDescriptor(...). > We tried using ClassDesc.ofDescriptor() but encountered problems. The > variable 'descriptors' was renamed 'subclassNames'. >> >> +???????? if (descriptors == null >> >> The VM never returns null. > The check was removed. >> >> +???????? return getPermittedSubclasses().length != 0; >> >> It's grossly inefficient to create the ClassDesc array and then throw >> it away IMO. The result should be cached either in a field of Class >> or in the ReflectionData of the class. > Done. >> >> --- >> >> src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java >> >> >> !???????? // - The offset of the PermittedSubclasses attribute, or 0 >> ????????? int permittedSubtypesOffset = 0; >> >> Obviously ASM already has some prelim support for sealed classes, but >> now that the attribute has been renamed that should also flow through >> to the ASM code ie the variable, not just the comment. >> >> Ditto for ClassWriter.java and its fields. > Done. >> >> --- >> >> src/java.base/share/native/libjava/Class.c >> >> ????? {"isRecord0",??????????? "()Z",???????? (void *)&JVM_IsRecord}, >> +???? {"getPermittedSubclasses0", "()[" STR,??? (void >> *)&JVM_GetPermittedSubclasses}, >> >> please align (void >> > Done. >> --- >> >> src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java >> >> src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java >> >> There needs to be a CSR for these changes too. >> >> --- >> >> test/langtools/tools/javac/processing/model/TestSourceVersion.java >> >> !??????????????????? // Assume "record" and "sealed" will be >> restricted keywords. >> !??????????????????? "record", "sealed"); >> >> What about the non-sealed keyword defined in the JEP? > 'non-sealed' is a keyword but not a restricted keyword.? So, it should > not be in the list. >> >> --- >> >> In the tests you don't need to explicitly include >> sun.hotspot.WhiteBox$WhiteBoxPermission on the ClassFileInstaller >> invocation. (previous RFE's have been removing existing occurrences >> after the CFI was fixed to handle it internally). > Done. >> >> Please ensure all new tests have an @bug 8225056 (or whatever the >> actual JBS issue will be) > Done. >> >> All test classes (and thus files) should be named in camel-case i.e. >> C1 not c1, C2 not c2, SuperClass not superClass etc. > Done. >> >> >> test/hotspot/jtreg/runtime/modules/sealedP1/superClass.jcod >> test/hotspot/jtreg/runtime/sealedClasses/Pkg/sealedInterface.jcod >> >> Please add comments clarifying why these must be jcod files. > > Done. > > Thanks!? Harold > >> >> --- >> >> That's it from me. >> >> Thanks, >> David >> ----- >> >> >> >>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8225056 >>> >>> Java Language Spec changes: >>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html >>> >>> >>> JVM Spec changes: >>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jvms.html >>> >>> >>> JEP 360: https://bugs.openjdk.java.net/browse/JDK-8227043 >>> >>> JVM CSR: https://bugs.openjdk.java.net/browse/JDK-8242578 >>> >>> Changes to javac and other language tools will be reviewed separately. >>> >>> Thanks, Harold >>> >>> From harold.seigel at oracle.com Fri May 22 15:20:23 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Fri, 22 May 2020 11:20:23 -0400 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> Message-ID: Thanks Lois! I'll add the two ResourceMarks before the changes get pushed. Harold On 5/22/2020 11:07 AM, Lois Foltan wrote: > On 5/21/2020 2:33 PM, Harold Seigel wrote: >> Hi David, >> >> Thanks for looking at this!? Please review this new webrev: >> >> ?? http://cr.openjdk.java.net/~hseigel/webrev.01/webrev/ > > Hi Harold, > > I think this webrev looks good!? A couple of minor comments: > > - oops/instanceKlass.cpp: > ? line #236, do you need a ResourceMark here? I noticed there is one > above at line #229 for the log_trace call that uses external_name(). > > - prims/jvmtiRedefineClasses.cpp: > ? line #878, I think you need a ResourceMark for this method as well > if you invoke the external_name for the log_trace calls and for > NEW_RESOURCE_ARRAY_RETURN_NULL()? > > Tests look good. > > Thanks, > Lois > >> >> This webrev contains the following significant changes: >> >> 1. The format/indentation issues in classFileParser.cpp were fixed. >> 2. Unneeded checks in InstanceKlass::has_as_permitted_subclass() were >> ?? removed and the TRAPS parameter was removed. >> 3. The changes to klassVtable.* and method.* were reverted. Those >> ?? changes were from when sealed classes were marked as final, and are >> ?? no longer valid. >> 4. Method getPermittedSubclasses() in Class.java was renamed to >> ?? permittedSubclasses() and its implementation was changed. >> 5. Variables and methods for 'asm' were renamed from >> ?? 'permittedSubtypes' to 'permittedSubclasses'. >> 6. Classes for sealed classes tests were changed to start with capital >> ?? letters. >> 7. Changes to langtools tests were removed from this webrev. They are >> ?? covered by the javac webrev (JDK-8244556). >> 8. The CSR's for JVMTI, JDWP, and JDI are in progress. >> >> Please also see comments inline. >> >> >> On 5/19/2020 1:26 AM, David Holmes wrote: >>> Hi Harold, >>> >>> Adding serviceability-dev for the serviceability related changes. >>> >>> Nit: "VM support for sealed classes" >>> >>> This RFR covers the VM, core-libs, serviceability and even some >>> langtools tests. AFAICS only the javac changes are not included here >>> so when and where will they be reviewed and under what bug id? >>> Ideally there will be a single JBS issue for "Implementation of JEP >>> 360: Sealed types". It's okay to break up the RFRs across different >>> areas, but it should be done under one bug id. >> The javac changes are being reviewed as bug JDK-8227406.? We >> understand the need to do the reviews under one bug. >>> >>> Overall this looks good. I've looked at all files and mainly have >>> some style nits in various places. But there are some more >>> significant items below. >>> >>> On 14/05/2020 7:09 am, Harold Seigel wrote: >>>> Hi, >>>> >>>> Please review this patch for JVM and Core-libs support for the JEP >>>> 360 Sealed Classes preview feature.? Code changes include the >>>> following: >>>> >>>> ??* Processing of the new PermittedSubclasses attribute to enforce >>>> that >>>> ??? a class or interface, whose super is a sealed class or interface, >>>> ??? must be listed in the super's PermittedSubclasses attribute. >>>> ??* Disallow redefinition of a sealed class or interface if its >>>> ??? redefinition would change its PermittedSubclasses attribute. >>>> ??* Support API's to determine if a class or interface is sealed >>>> and, if >>>> ??? it's sealed, return a list of its permitted subclasses. >>>> ??* asm support for the PermittedSubclasses attribute >>> >>> I assume Remi is providing the upstream support in ASM? :) But also >>> see below ... >>> >>>> >>>> Open Webrev: >>>> http://cr.openjdk.java.net/~vromero/8225056/webrev.00/index.html >>> >>> make/data/jdwp/jdwp.spec >>> >>> There needs to be a sub-task and associated CSR request for this >>> JDWP spec update. I couldn't see this covered anywhere. >>> >>> --- >>> >>> src/hotspot/share/classfile/classFileParser.cpp >>> >>> 3215 u2 >>> ClassFileParser::parse_classfile_permitted_subclasses_attribute(const >>> ClassFileStream* const cfs, >>> 3216 const u1* const permitted_subclasses_attribute_start, >>> 3217 TRAPS) { >>> >>> Indention on L3216/17 needs fixing after the copy'n'edit. >>> >>> 3515?? return _major_version == JVM_CLASSFILE_MAJOR_VERSION && >>> 3516????????????? _minor_version == JAVA_PREVIEW_MINOR_VERSION && >>> 3517????????????? Arguments::enable_preview(); >>> >>> Too much indentation on L3516/17 >>> >>> 3790???????????????? // Check for PermittedSubclasses tag >>> >>> That comment (copied from my nestmates code :) is in the wrong >>> place. It needs to be before >>> >>> 3788???????????? if (tag == vmSymbols::tag_permitted_subclasses()) { >>> >>> >>> Minor nit: I would suggest checking >>> parsed_permitted_subclasses_attribute before checking ACC_FINAL. >>> >>> 3876?? if (parsed_permitted_subclasses_attribute) { >>> 3877???? const u2 num_of_subclasses = >>> parse_classfile_permitted_subclasses_attribute( >>> 3878??????????????????????????????????? cfs, >>> 3879 permitted_subclasses_attribute_start, >>> 3880??????????????????????????????????? CHECK); >>> >>> Although it looks odd the preceding, similarly shaped, sections all >>> indent to the same absolute position. Can you make L3878/78/80 match >>> please. >>> >>> 3882?????? guarantee_property( >>> 3883???????? permitted_subclasses_attribute_length == >>> 3884?????????? sizeof(num_of_subclasses) + sizeof(u2) * >>> num_of_subclasses, >>> 3885???????? "Wrong PermittedSubclasses attribute length in class >>> file %s", CHECK); >>> >>> Nits: please reformat as: >>> >>> 3882?????? guarantee_property( >>> 3883???????? permitted_subclasses_attribute_length == >>> sizeof(num_of_subclasses) + sizeof(u2) * num_of_subclasses, >>> 3885???????? "Wrong PermittedSubclasses attribute length in class >>> file %s", CHECK); >>> >>> It would also look slightly better if you shortened the name of the >>> num_of_subclasses variable. >> All of the above classFileParser.cpp changes were done. >>> >>> --- >>> >>> src/hotspot/share/classfile/classFileParser.hpp >>> >>> +?? u2 parse_classfile_permitted_subclasses_attribute(const >>> ClassFileStream* const cfs, >>> +???????????????????????????????????????????? const u1* const >>> permitted_subclasses_attribute_start, >>> +???????????????????????????????????????????? TRAPS); >>> >>> Please fix indentation after copy'n'edit. >> Done. >>> >>> --- >>> >>> src/hotspot/share/oops/instanceKlass.cpp >>> >>> ?247?? if (classloader1 != classloader2) { >>> >>> I'm not clear what rule this is verifying. The same module check >>> follows this one. The rule is that the subclass must be accessible >>> to the superclass implying: >>> 1. same named module (regardless of class access modifiers); or >>> 2. (implicitly in un-named module) same package if subclass not >>> public; or >>> 3. public subclass >>> >>> Having the same classloader implies same package, but that alone >>> doesn't address 2 or 3. So this doesn't conform to proposed JVMS rules. >> This was discussed as part of the CSR and hopefully clarified. >>> >>> >>> >>> ?264???? if (_constants->tag_at(cp_index).is_klass()) { >>> ?265?????? Klass* k2 = _constants->klass_at(cp_index, CHECK_false); >>> >>> You've copied this code from the nestmember checks but your changes >>> don't quite make sense to me. If we have already checked is_klass() >>> then klass_at() cannot lead to any exceptions. >>> >>> ?272?????? if (name == k->name()) { >>> ?273???????? log_trace(class, sealed)("- Found it at >>> permitted_subclasses[%d] => cp[%d]", i, cp_index); >>> ?274???????? return true; >>> >>> I was wondering why you don't resolve the cp entry when you find the >>> name matches, as we do for nest members, but realized that unlike >>> the nest membership check, which can happen many times for a given >>> class, this permitted subclass check can only happen once per class. >>> As you don't actually resolve here, and given that the earlier check >>> cannot throw exceptions, it follows that the entire method never >>> results in any exceptions and so callers should not be using the >>> CHECK macro. >> >> The comparison of class loaders was removed because checking that the >> two classes are in the same module ensures that they have the same >> class loader. >> >> The traps parameter was removed.? The CHECK macro was replaced with >> THREAD. >> >>> >>> --- >>> >>> src/hotspot/share/oops/method.cpp >>> >>> I don't understand how knowing the class is sealed allows you to >>> infer that a non-final method is actually final ?? >> This change was removed.? See item #3 at the beginning of this email. >>> >>> --- >>> >>> ?src/hotspot/share/prims/jvm.cpp >>> >>> It would be simpler (and cheaper) if the Java side of this ensures >>> it doesn't call into the VM with an array or primitive class. >> Done. >>> >>> --- >>> >>> ?src/hotspot/share/prims/jvmti.xml >>> >>> The JVM TI spec changes also need to be covered by a CSR request. >>> >>> --- >>> >>> src/hotspot/share/prims/jvmtiRedefineClasses.cpp >>> >>> We should file a RFE to refactor the logic that checks that an >>> attribute consisting of a list of classes has not changed. :) >> Serguei filed the RFE. >>> >>> Aside: I spotted a bug in the nest member code (missing NULL check!) >>> thanks to your change :) >>> >>> --- >>> >>> src/java.base/share/classes/java/lang/Class.java >>> >>> There needs to be a CSR request for these changes. >> The CSR is JDK-8244556. >>> >>> +????? * Returns an array containing {@code ClassDesc} objects >>> representing all the >>> +????? * permitted subclasses of this {@linkplain Class} if it is >>> sealed. Returns an empty array if this >>> +????? * {@linkplain Class} is not sealed. >>> >>> should add "or this class represents an array or primitive type" >>> (using the standard wording for such cases). >> Discussed off-line and was decided that this text isn't needed. >>> >>> +????? * @throws IllegalArgumentException if a class descriptor is >>> not in the correct format >>> >>> IllegalArgumentException is not an appropriate exception to use as >>> this method takes no arguments. If the class descriptor is not valid >>> and it comes from the VM then I think we have a problem with how the >>> VM validates class descriptors. Any IAE from ClassDesc.of should be >>> caught and converted to a more suitable exception type - preferably >>> InternalError if the VM should always return valid strings. >> Done. >>> >>> +???? public ClassDesc[] getPermittedSubclasses() { >>> >>> As mentioned for jvm.cpp this Java code should do the isArray() and >>> isPrimitive() check before calling the VM. >> Done. >>> >>> +???????? String[] descriptors = getPermittedSubclasses0(); >>> >>> Nit: what you get from the VM are not descriptors, just name strings >>> in internal form. This wouldn't really matter except it then looks >>> strange to call ClassDesc.of(...) instead of >>> ClassDesc.ofDescriptor(...). >> We tried using ClassDesc.ofDescriptor() but encountered problems. The >> variable 'descriptors' was renamed 'subclassNames'. >>> >>> +???????? if (descriptors == null >>> >>> The VM never returns null. >> The check was removed. >>> >>> +???????? return getPermittedSubclasses().length != 0; >>> >>> It's grossly inefficient to create the ClassDesc array and then >>> throw it away IMO. The result should be cached either in a field of >>> Class or in the ReflectionData of the class. >> Done. >>> >>> --- >>> >>> src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java >>> >>> >>> !???????? // - The offset of the PermittedSubclasses attribute, or 0 >>> ????????? int permittedSubtypesOffset = 0; >>> >>> Obviously ASM already has some prelim support for sealed classes, >>> but now that the attribute has been renamed that should also flow >>> through to the ASM code ie the variable, not just the comment. >>> >>> Ditto for ClassWriter.java and its fields. >> Done. >>> >>> --- >>> >>> src/java.base/share/native/libjava/Class.c >>> >>> ????? {"isRecord0",??????????? "()Z",???????? (void *)&JVM_IsRecord}, >>> +???? {"getPermittedSubclasses0", "()[" STR,??? (void >>> *)&JVM_GetPermittedSubclasses}, >>> >>> please align (void >>> >> Done. >>> --- >>> >>> src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java >>> >>> src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java >>> >>> There needs to be a CSR for these changes too. >>> >>> --- >>> >>> test/langtools/tools/javac/processing/model/TestSourceVersion.java >>> >>> !??????????????????? // Assume "record" and "sealed" will be >>> restricted keywords. >>> !??????????????????? "record", "sealed"); >>> >>> What about the non-sealed keyword defined in the JEP? >> 'non-sealed' is a keyword but not a restricted keyword.? So, it >> should not be in the list. >>> >>> --- >>> >>> In the tests you don't need to explicitly include >>> sun.hotspot.WhiteBox$WhiteBoxPermission on the ClassFileInstaller >>> invocation. (previous RFE's have been removing existing occurrences >>> after the CFI was fixed to handle it internally). >> Done. >>> >>> Please ensure all new tests have an @bug 8225056 (or whatever the >>> actual JBS issue will be) >> Done. >>> >>> All test classes (and thus files) should be named in camel-case i.e. >>> C1 not c1, C2 not c2, SuperClass not superClass etc. >> Done. >>> >>> >>> test/hotspot/jtreg/runtime/modules/sealedP1/superClass.jcod >>> test/hotspot/jtreg/runtime/sealedClasses/Pkg/sealedInterface.jcod >>> >>> Please add comments clarifying why these must be jcod files. >> >> Done. >> >> Thanks!? Harold >> >>> >>> --- >>> >>> That's it from me. >>> >>> Thanks, >>> David >>> ----- >>> >>> >>> >>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8225056 >>>> >>>> Java Language Spec changes: >>>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html >>>> >>>> >>>> JVM Spec changes: >>>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jvms.html >>>> >>>> >>>> JEP 360: https://bugs.openjdk.java.net/browse/JDK-8227043 >>>> >>>> JVM CSR: https://bugs.openjdk.java.net/browse/JDK-8242578 >>>> >>>> Changes to javac and other language tools will be reviewed separately. >>>> >>>> Thanks, Harold >>>> >>>> > From paul.sandoz at oracle.com Fri May 22 16:12:03 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 22 May 2020 09:12:03 -0700 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> Message-ID: <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> HI Andrew, Thanks for looking. I am not terribly familiar with the AArch64 code, but I would note the Vector API comes with a bunch of unit tests should exercise the code gen, just not as directly as I presume you would like. To what extent do you feel we can follow up with additional issues and fix them after the initial integration? Paul. > On May 22, 2020, at 6:00 AM, Andrew Haley wrote: > > On 5/19/20 11:55 AM, Yang Zhang wrote: >> Following up on review requests of API [0], Java implementation and >> test [1], General Hotspot changes[2] for Vector API and x86 backend >> changes [3]. Here's a request for review of AArch64 backend changes >> required for supporting the Vector API: >> >> JEP: https://openjdk.java.net/jeps/338 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8223347 >> Webrev: http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.01/ >> >> Complete implementation resides in vector-unstable branch of panama/dev >> repository [4]. > > This looks great, and it's very impressive. Unfortunately, there are few > of us sufficiently knowledgeable about Panama to review it in the detail > that perhaps it deserves. I'm happy with it. > > However, we need tests for the new assembly instructions, so please add some > to aarch64_asmtest.py and update macroassemler.cpp. > > Also, aarch64.ad is getting to be far too large, and perhaps all the vector > stuff should be moved into a new file. Thanks. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From paul.sandoz at oracle.com Fri May 22 17:28:39 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 22 May 2020 10:28:39 -0700 Subject: RFR: 8245455: Remove alternative StringConcatFactory strategies In-Reply-To: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> References: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> Message-ID: Hi, I support the removal of all the other strategies to simplify SCF and make it more maintainable. Having one or more strategies to fall back on (with an undocumented flag) was I think right thing to do when initially introducing the feature. Over time, the default strategy has become more and more robust where as the others have languished due to their lack of exposure and development focus, decreasing my confidence they would not introduce different issues if enabled. It?s a judgement call but I think maturation of this feature has tipped in favor of the simplification provided by Claes?s patch. Paul. > On May 22, 2020, at 2:52 AM, Claes Redestad wrote: > > Hi, > > this patch removes the alternative, undocumented strategies from > StringConcatFactory. > > The default strategy has been optimized and stabilized since inception in JDK 9, while the alternative strategies have been falling behind > both in terms of performance and stability - while adding maintenance > cost. > > The removal allows some simplifications to the code that will reduce > per callsite bootstrap overhead, and reduce what we need to load eagerly > during bootstrap. I've also applied the pattern from JDK-8218173 to > the remaining Stringifier method handles, which further improve > robustness of bootstrapping under an OOME condition. > > Webrev: http://cr.openjdk.java.net/~redestad/8245455/open.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8245455 > > Testing: tier1-3 > > Thanks! > > /Claes From aph at redhat.com Fri May 22 17:40:12 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 May 2020 18:40:12 +0100 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> Message-ID: <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> On 5/22/20 5:12 PM, Paul Sandoz wrote: > I am not terribly familiar with the AArch64 code, but I would note > the Vector API comes with a bunch of unit tests should exercise the > code gen, just not as directly as I presume you would like. Yes, you've understood me: direct is what I want. The assembler tests are intended to make sure we generate exactly the right instructions, rather than having something painfully hard to debug later on. When a patch adds a lot of instructions to the assembler, that IMO is the right time to test that they generate correctly-encoded instructions. But yes, that can go into a follow-up patch, as long as it gets done fairly shortly. > To what extent do you feel we can follow up with additional issues > and fix them after the initial integration? We can do that. Note that after this patch, aarch64.ad is 21762 lines long. I know we don't have any hard-and-fast rule about this, but I'd rather it didn't get forgotten. Maybe I should do that one myself, but I guess I'd rather avoid the problem of version skew between the Panama repo and mainline. That'd make merging rather grim. Yang, against which repo is this webrev intended to be applied? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From forax at univ-mlv.fr Fri May 22 17:59:26 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 22 May 2020 19:59:26 +0200 (CEST) Subject: RFR: 8245455: Remove alternative StringConcatFactory strategies In-Reply-To: References: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> Message-ID: <1870710773.577955.1590170366341.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > ?: "Claes Redestad" > Cc: "core-libs-dev" > Envoy?: Vendredi 22 Mai 2020 19:28:39 > Objet: Re: RFR: 8245455: Remove alternative StringConcatFactory strategies > Hi, > > I support the removal of all the other strategies to simplify SCF and make it > more maintainable. > > Having one or more strategies to fall back on (with an undocumented flag) was I > think right thing to do when initially introducing the feature. Over time, the > default strategy has become more and more robust where as the others have > languished due to their lack of exposure and development focus, decreasing my > confidence they would not introduce different issues if enabled. > > It?s a judgement call but I think maturation of this feature has tipped in favor > of the simplification provided by Claes?s patch. I agree with Claes and Paul, an indy + its metafactory is like a new opcode in the bytecode, the VM doesn't maintain several implementations of a bytecode. > > Paul. R?mi > > >> On May 22, 2020, at 2:52 AM, Claes Redestad wrote: >> >> Hi, >> >> this patch removes the alternative, undocumented strategies from >> StringConcatFactory. >> >> The default strategy has been optimized and stabilized since inception in JDK 9, >> while the alternative strategies have been falling behind >> both in terms of performance and stability - while adding maintenance >> cost. >> >> The removal allows some simplifications to the code that will reduce >> per callsite bootstrap overhead, and reduce what we need to load eagerly >> during bootstrap. I've also applied the pattern from JDK-8218173 to >> the remaining Stringifier method handles, which further improve >> robustness of bootstrapping under an OOME condition. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8245455/open.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8245455 >> >> Testing: tier1-3 >> >> Thanks! >> > > /Claes From paul.sandoz at oracle.com Fri May 22 18:01:01 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 22 May 2020 11:01:01 -0700 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> Message-ID: <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> > On May 22, 2020, at 10:40 AM, Andrew Haley wrote: > > On 5/22/20 5:12 PM, Paul Sandoz wrote: > >> I am not terribly familiar with the AArch64 code, but I would note >> the Vector API comes with a bunch of unit tests should exercise the >> code gen, just not as directly as I presume you would like. > > Yes, you've understood me: direct is what I want. The assembler tests > are intended to make sure we generate exactly the right instructions, > rather than having something painfully hard to debug later on. When a > patch adds a lot of instructions to the assembler, that IMO is the > right time to test that they generate correctly-encoded > instructions. But yes, that can go into a follow-up patch, as long as > it gets done fairly shortly. Ok. > >> To what extent do you feel we can follow up with additional issues >> and fix them after the initial integration? > > We can do that. Note that after this patch, aarch64.ad is 21762 lines > long. I know we don't have any hard-and-fast rule about this, but I'd > rather it didn't get forgotten. We have made changes similar in spirit to the x64 ad file (reducing in size at least), so I think it reasonable request before integration to reduce the cognitive and maintenance burden. (FWIW I don?t know to what extent some functionality is utilized by the auto vectorizer and whether that impacts its location or not.) > Maybe I should do that one myself, but > I guess I'd rather avoid the problem of version skew between the > Panama repo and mainline. That'd make merging rather grim. > > Yang, against which repo is this webrev intended to be applied? > I cannot speak for Yang but we have been generating webrevs from the Panama dev repo, branch vector-unstable (unfortunate name I know!) and doing: hg diff -r default Where the default is regularly, but manually, pulled from jdk/jdk. More specifically: - code is generally pushed to the vectorIntrinsics branch - on a manual but regular basis vectorIntrinsics is synced up to jdk/jdk (via the default branch). - on a manual but regular basis vector-unstable is synced with vectorIntrinsics - occasionally there are fixes pushed directly to vector-unstable for the purposes of integration (e.g. removal of the perf test or the x64 SVML stubs). Hth, Paul. From vicente.romero at oracle.com Fri May 22 18:25:12 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Fri, 22 May 2020 14:25:12 -0400 Subject: RFR: JDK-8227046: compiler implementation for sealed classes, JDK-8227047: Javadoc for sealed types and JDK-8227044: javax.lang.model for sealed classes In-Reply-To: <11f8828c-607e-e844-1ac6-5977a40c9a77@oracle.com> References: <3bd27bea-b8a3-88a2-5536-ea9610749ce4@oracle.com> <11f8828c-607e-e844-1ac6-5977a40c9a77@oracle.com> Message-ID: Hi, Thanks Jan and Maurizio for the reviews. I have created another iteration that I hope addresses all of the comments. I recognize that dealing with `sealed`, `non-sealed` is the most complicated part as there is no guide right now from the spec. So I have tried to make them contextual keywords, for some informal definition of the concept, I think that with more success for the `sealed` case. So going in more detail this iteration includes: ?- ClassTree::getPermitsClause now returns `List.of()` ?- Types::findDescriptorInternal has been modified to fail on sealed interfaces ?- several error messages have been updated as suggested, on this front given that when a class list the same interface twice in the implements clause, the second occurrence is the one flagged, I did the same for repeated names in the permits clause ?- modifications in ClassReader and ClassWriter as suggested ?- JavacParser, the bulk of the changes are concentrated here, as mentioned above the goal has been to try to implement the contextual keyword thing and also give a nice error message in several corner case situations detected in the reviews ?- more tests were added Thanks, Vicente On 5/21/20 8:14 AM, Maurizio Cimadamore wrote: > Hi Vicente, > looks very good. Some comments below. > > * the parser logic is clever in its use of position to apply > context-dependent keyword detection; as Jan says, perhaps just share > the code so that the position checks are not repeated. > > * I found one very edge-case quirk in the context-dependent logic; not > sure how we wanna address: > > class Foo { > ??? sealed m() {} > } > > This fails with: > > Error: invalid method declaration; return type required > > As javac parses non-sealed as a modifier, and then expects a type. I > think this is probably reasonable, but it's not as context-dependent > as it could be I guess. > > * This case: > > class Bar { } > sealed @interface Foo permits Bar > > Fails as expected, but only because Bar doesn't extends Foo. I believe > we'd like to ban sealed on annotations more eagerly. Same for > non-sealed. For enums and records (which are non-extensible) the > compiler does the right thing and tells me that I can't just use > sealed/non-sealed there. > > * The recovery logic in case preview features aren't enabled leaves > something to be desired. For instance, if I compile this w/o > --enable-preview: > > ?record Foo() {} > > I get a very sensible error: > > records are a preview feature and are disabled by default. > ??? (use --enable-preview to enable records) > > However, if I compiler this w/o --enable-preview: > > sealed class Foo {} > > I get this: > > error: class, interface, or enum expected > > (no mention of preview features) > > It gets worse if I also specify a `permits`. > > * As Jan mentioned, type parameters on permitted types should be > banned, not silently cleared in TypeEnter > > * Overall the type enter logic seems robust - I've tried several > examples swapping superclass/subclass - using references to nested > classes in supertype declaration, and it all works. Well done. > > * The error for lambda expressions leaves to be desired: > > sealed interface Action { > ?void doAction(); > } > > class Test { > ? Action a = () -> { }; > } > > Foo.java:6: error: class is not allowed to extend sealed class: Action > ? Action a = () -> { }; > ???????????? ^ > > I think a dedicated error here would be useful. > > > * the same check is not applied to method references: > > > class Test { > > ? Action a2 = Test::m; //no error > > ? static void m() { } > } > > More generally, if a functional interface cannot be sealed, I think it > would be better to inject the check in the functional interface check > (e.g. Types::findDescriptorInternal) so that you won't need any extra > code in Attr. This would also be more in spirit with the spec, where > the non-sealedness check is defined in 9.8, not in section 15. > > * Pulling more on that string, the @FunctionalInterface annotation can > be placed on a sealed interface and no error is issued > > * On ClassWriter - isn't calling adjustFlags() enough? That will > truncate the long flags into an int - I think Flags.SEALED is bigger > than that? > > > // error messages > > * DuplicateTypesInPermits > > I suggest: > > test/langtools/tools/javac/diags/examples/DuplicateTypeInPermits.java:30: > error: invalid permits clause > sealed class Sealed permits Sub, Sub {} > ??????????????????????????? ^ > ? (repeated type: Sub) > > [this is consistent with the error we issues in other places - e.g. > when you implements same interface twice] > > * NonSealedWithNoSealedSuper > > test/langtools/tools/javac/diags/examples/NonSealedWithNoSealedSuper.java:31: > error: non-sealed modifier not allowed here > non-sealed class Sub extends C {} > ?????????? ^ > ? (class must have a sealed superclasses) > > I suggest to replace the details message with something like this: > > (class C does not have any sealed supertypes) > > [since I expect this message to be applicable also for superinterfaces] > > * PermitsCantListDeclaringClass > > test/langtools/tools/javac/diags/examples/PermitsCantListDeclaringClass.java:30: > error: invalid permits clause > sealed class C permits C {} > ?????????????????????? ^ > ? (must not include the declaring class: C) > > Here I recommend something like: > > (illegal self-reference in permits clause) > > * PermitsCantListSuperType > > test/langtools/tools/javac/diags/examples/PermitsCantListSuperType.java:32: > error: invalid permits clause > sealed class C implements I permits I {} > ??????????????????????????????????? ^ > ? (must not include a supertype: I) > > I suggest: > > (illegal reference to supertype I) > > * PermitsInNoSealedClass > > test/langtools/tools/javac/diags/examples/PermitsInNoSealedClass.java:30: > error: invalid permits clause > class C permits Sub {} > ??????? ^ > ? (class must be sealed) > > This is good, but I noted that if you change the test to use an > interface, the message still says "class" - the kindname should be > used here. > > * SealedMustHaveSubtypes > > test/langtools/tools/javac/diags/examples/SealedMustHaveSubtypes.java:29: > error: sealed class must have subclasses > sealed class Sealed {} > ?????? ^ > > I think this message reflects one of the main issues with the general > type vs. class dichotomy. A subclass, in JLS lingo is e.g. `B` where > `B extends A`. Interfaces do not play in the mix - they are not > considered subclasses. The word subtypes could be more general - but > again, it is a bit imprecise, since we're talking about declarations > here, not types. I'll defer this conundrum to our spec gurus :-) > > > Cheers > Maurizio > > > > On 18/05/2020 23:42, Vicente Romero wrote: >> Hi, >> >> Please review this patch for the compiler, javadoc and >> javax.lang.model support for the JEP 360 Sealed Classes (Preview). >> The changes are provided at [1], which implements the latest JLS for >> sealed types [2]. The patch also include the needed changes to >> javadoc and javax.lang.model to support sealed types. The CSR witht >> the changes in the javax.lang.model spec is at [3]. The sealed types >> JEP is accessible at [4]. There is an ongoing review for the VM and >> core-libs code of sealed types [5] and that code hasn't been included >> in this webrev, >> >> Thanks, >> Vicente >> >> [1] http://cr.openjdk.java.net/~vromero/8227046/webrev.00/ >> [2] >> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html >> >> [3] https://bugs.openjdk.java.net/browse/JDK-8244367 >> [4] https://openjdk.java.net/jeps/360 >> [5] >> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066440.html From mandy.chung at oracle.com Fri May 22 18:35:30 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 22 May 2020 11:35:30 -0700 Subject: RFR: 8245455: Remove alternative StringConcatFactory strategies In-Reply-To: References: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> Message-ID: Hi Claes, The change looks good. I also support the removal of all non-default strategies.? The default strategy has been baked for long enough time and shown solid (the issues in j.l.invoke quoted already were 2 years old). Mandy On 5/22/20 10:28 AM, Paul Sandoz wrote: > Hi, > > I support the removal of all the other strategies to simplify SCF and make it more maintainable. > > Having one or more strategies to fall back on (with an undocumented flag) was I think right thing to do when initially introducing the feature. Over time, the default strategy has become more and more robust where as the others have languished due to their lack of exposure and development focus, decreasing my confidence they would not introduce different issues if enabled. > > It?s a judgement call but I think maturation of this feature has tipped in favor of the simplification provided by Claes?s patch. > > Paul. > > >> On May 22, 2020, at 2:52 AM, Claes Redestad wrote: >> >> Hi, >> >> this patch removes the alternative, undocumented strategies from >> StringConcatFactory. >> >> The default strategy has been optimized and stabilized since inception in JDK 9, while the alternative strategies have been falling behind >> both in terms of performance and stability - while adding maintenance >> cost. >> >> The removal allows some simplifications to the code that will reduce >> per callsite bootstrap overhead, and reduce what we need to load eagerly >> during bootstrap. I've also applied the pattern from JDK-8218173 to >> the remaining Stringifier method handles, which further improve >> robustness of bootstrapping under an OOME condition. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8245455/open.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8245455 >> >> Testing: tier1-3 >> >> Thanks! >> >> /Claes From claes.redestad at oracle.com Fri May 22 18:46:59 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 22 May 2020 20:46:59 +0200 Subject: RFR: 8245455: Remove alternative StringConcatFactory strategies In-Reply-To: References: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> Message-ID: Jim, Paul, R?mi, Mandy, thank you all for your reviewing and supporting the suggested approach. /Claes On 2020-05-22 20:35, Mandy Chung wrote: > Hi Claes, > > The change looks good. > > I also support the removal of all non-default strategies.? The default > strategy has been baked for long enough time and shown solid (the issues > in j.l.invoke quoted already were 2 years old). > > Mandy > > On 5/22/20 10:28 AM, Paul Sandoz wrote: >> Hi, >> >> I support the removal of all the other strategies to simplify SCF and make it more maintainable. >> >> Having one or more strategies to fall back on (with an undocumented flag) was I think right thing to do when initially introducing the feature. Over time, the default strategy has become more and more robust where as the others have languished due to their lack of exposure and development focus, decreasing my confidence they would not introduce different issues if enabled. >> >> It?s a judgement call but I think maturation of this feature has tipped in favor of the simplification provided by Claes?s patch. >> >> Paul. >> >> >>> On May 22, 2020, at 2:52 AM, Claes Redestad wrote: >>> >>> Hi, >>> >>> this patch removes the alternative, undocumented strategies from >>> StringConcatFactory. >>> >>> The default strategy has been optimized and stabilized since inception in JDK 9, while the alternative strategies have been falling behind >>> both in terms of performance and stability - while adding maintenance >>> cost. >>> >>> The removal allows some simplifications to the code that will reduce >>> per callsite bootstrap overhead, and reduce what we need to load eagerly >>> during bootstrap. I've also applied the pattern from JDK-8218173 to >>> the remaining Stringifier method handles, which further improve >>> robustness of bootstrapping under an OOME condition. >>> >>> Webrev:http://cr.openjdk.java.net/~redestad/8245455/open.00/ >>> Bug:https://bugs.openjdk.java.net/browse/JDK-8245455 >>> >>> Testing: tier1-3 >>> >>> Thanks! >>> >>> /Claes > From mandy.chung at oracle.com Fri May 22 18:51:05 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 22 May 2020 11:51:05 -0700 Subject: 8239013: java.util.logging.Logger catalog cache keeps strong references to ResourceBundles In-Reply-To: <03661db5-39e5-09f6-7cf5-82e7dfb823ac@oracle.com> References: <03661db5-39e5-09f6-7cf5-82e7dfb823ac@oracle.com> Message-ID: Hi Daniel, This looks good.? Surprisingly no one reports this long standing bug. thanks Mandy On 5/22/20 2:33 AM, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > > 8239013: java.util.logging.Logger catalog cache keeps strong > ???????? references to ResourceBundles > https://bugs.openjdk.java.net/browse/JDK-8239013 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8239013/webrev.00/ > > java.util.logging.Logger has a `catalog` variable that acts > as a cache and holds a reference to the last resource bundle > that was loaded by the logger. > > This fix replaces the strong reference with a weak reference, > allowing the cached object to be garbage collected even in > cases where a strong reference to the logger remains. > > > best regards, > > -- daniel From naoto.sato at oracle.com Fri May 22 20:40:23 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 22 May 2020 13:40:23 -0700 Subject: 8239013: java.util.logging.Logger catalog cache keeps strong references to ResourceBundles In-Reply-To: <03661db5-39e5-09f6-7cf5-82e7dfb823ac@oracle.com> References: <03661db5-39e5-09f6-7cf5-82e7dfb823ac@oracle.com> Message-ID: Looks good to me. Naoto On 5/22/20 2:33 AM, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > > 8239013: java.util.logging.Logger catalog cache keeps strong > ???????? references to ResourceBundles > https://bugs.openjdk.java.net/browse/JDK-8239013 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8239013/webrev.00/ > > java.util.logging.Logger has a `catalog` variable that acts > as a cache and holds a reference to the last resource bundle > that was loaded by the logger. > > This fix replaces the strong reference with a weak reference, > allowing the cached object to be garbage collected even in > cases where a strong reference to the logger remains. > > > best regards, > > -- daniel From shade at redhat.com Fri May 22 21:31:42 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 22 May 2020 23:31:42 +0200 Subject: RFR: 8245455: Remove alternative StringConcatFactory strategies In-Reply-To: <3381f1e5-dd7f-6d7b-2b60-1dc7daa6ca7a@oracle.com> References: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> <68fdbafb-e3be-4ada-2b93-6a87a1862ed2@redhat.com> <2c3d074d-7a4f-ea8c-0201-fa4d32f5b9f1@oracle.com> <61f1f7dc-4499-1dd0-1179-c7acacda4173@oracle.com> <84f61a39-ab78-87ff-12d0-6499f4c5f00f@redhat.com> <3381f1e5-dd7f-6d7b-2b60-1dc7daa6ca7a@oracle.com> Message-ID: On 5/22/20 3:55 PM, Claes Redestad wrote: > There are no guarantees any particular fallback is not going to break in > similar ways or - more likely - bit rot and break sooner. Seeing how all > but the default strategy sees rather superficial testing in practice, I > think you are exaggerating the value they provide as a safety net > against future unknowns. See below: > Fixing some bootstrap robustness issues of late has me convinced that > maintaining and verifying the fallback strategies is not worth our > while. See e.g. https://bugs.openjdk.java.net/browse/JDK-8218173 - > fixing this for the fallback strategies might be straightforward (or > not), but to then verify it's actually fixed would require we add runs > with $chosen_fallback_strategy to our entire testing for weeks. The purpose of fallback strategy is to carry users until the fix for default strategy propagates. Therefore, I believe fallback strategy does not need to fix JDK-8218173. The same way we do not thoroughly test JVM with changed values of diagnostic flags and instead hoping that switching the flag in the field would be robust enough to dissect/workaround the bug until the proper fix arrives. The same way as with diagnostic flags, fallback strategy is tested with simple unit tests, so we know it is not badly broken. > So no, I'm not particularly worried about reducing this down to a single > strategy here and now. We should of course keep investing in SCF to > ensure it's as robust, performant and well-tested as can be. And of > course promptly fix any bugs that we discover. This is a noble goal. My point is that in pursuing that goal in the one of the most widely deployed pieces of software in the world, we also need to consider what happens when that pursuit fails. Fallback strategy carries users until "promptly" happens, which might take days, weeks, months. I believe not providing a fallback strategy at this time is a mistake. It would be a good time to drop fallback strategy somewhere after target=11 becomes as ubiquitous as target=8 today. That time is not now. You can consider this my non-binding dissenting opinion on the issue, if you need formal consensus to move forward. -- Thanks, -Aleksey From alexander.matveev at oracle.com Fri May 22 23:33:54 2020 From: alexander.matveev at oracle.com (alexander.matveev at oracle.com) Date: Fri, 22 May 2020 16:33:54 -0700 Subject: RFR: 8242786: [macos] tools/jpackage/share/IconTest.java fails: ABORT trying to dequeue work Message-ID: Please review the jpackage fix for bug [1] at [2]. - Detach fails sometimes due to disk image being busy. Not sure what keeps disk image busy. Probably antivirus or something else. Within short period of time disk image can be detach. So, fix is just re-try detach if it did not work right away. With proposed fix I was not able to reproduce this issue again. [1] https://bugs.openjdk.java.net/browse/JDK-8242786 [2] http://cr.openjdk.java.net/~almatvee/8242786/webrev.00/ Thanks, Alexander From christoph.dreis at freenet.de Sat May 23 07:53:59 2020 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Sat, 23 May 2020 09:53:59 +0200 Subject: Avoid allocations in Executable.getAllGenericParameterTypes Message-ID: Hi, I was looking through the code and found a relatively straight-forward optimization in Executable.getAllGenericParameterTypes (attached below). The idea is to simply move some code around to avoid unnecessary allocations from getParameters() or array initializations when working with generics and no "real" parameter data is available. I used the following benchmark: @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class MyBenchmark { @State(Scope.Benchmark) public static class ThreadState { private Parameter parameter; public ThreadState() { try { this.parameter = Test1.class.getDeclaredConstructor(Set.class).getParameters()[0]; } catch (NoSuchMethodException e) { // Do nothing } } } @Benchmark public AnnotatedType test(ThreadState threadState) { return threadState.parameter.getAnnotatedType(); } } public class Test1 { public Test1(Set names) {} } With the attached patch and the benchmark above I get the following results. Old Benchmark Mode Cnt Score Error Units MyBenchmark.test avgt 10 358,103 ? 58,098 ns/op MyBenchmark.test:?gc.alloc.rate.norm avgt 10 248,021 ? 0,003 B/op Patched MyBenchmark.test avgt 10 309,133 ? 6,319 ns/op MyBenchmark.test:?gc.alloc.rate.norm avgt 10 200,016 ? 0,001 B/op I don't think the particular method is called super often, but it seems to be used in ByteBuddy & JUnit as far as I can see. In case you think this is worthwhile, I would appreciate it if someone can sponsor this patch. Cheers, Christoph ========= PATCH ========== --- a/src/java.base/share/classes/java/lang/reflect/Executable.java Wed May 13 16:18:16 2020 +0200 +++ b/src/java.base/share/classes/java/lang/reflect/Executable.java Sat May 23 08:31:23 2020 +0200 @@ -307,12 +307,12 @@ final boolean realParamData = hasRealParameterData(); final Type[] genericParamTypes = getGenericParameterTypes(); final Type[] nonGenericParamTypes = getParameterTypes(); - final Type[] out = new Type[nonGenericParamTypes.length]; - final Parameter[] params = getParameters(); - int fromidx = 0; // If we have real parameter data, then we use the // synthetic and mandate flags to our advantage. if (realParamData) { + final Type[] out = new Type[nonGenericParamTypes.length]; + final Parameter[] params = getParameters(); + int fromidx = 0; for (int i = 0; i < out.length; i++) { final Parameter param = params[i]; if (param.isSynthetic() || param.isImplicit()) { @@ -325,6 +325,7 @@ fromidx++; } } + return out; } else { // Otherwise, use the non-generic parameter data. // Without method parameter reflection data, we have @@ -334,7 +335,6 @@ return genericParamTypes.length == nonGenericParamTypes.length ? genericParamTypes : nonGenericParamTypes; } - return out; } From aph at redhat.com Sat May 23 09:16:07 2020 From: aph at redhat.com (Andrew Haley) Date: Sat, 23 May 2020 10:16:07 +0100 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> Message-ID: <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> On 5/22/20 7:01 PM, Paul Sandoz wrote: > We have made changes similar in spirit to the x64 ad file (reducing in size at least), so I think it reasonable request before integration to reduce the cognitive and maintenance burden. So here's a question: can the changes to the AArch64 back end be made to mainline now? Or is there a problem in that the C2 patterns being used don't exist? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Sat May 23 10:48:11 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Sat, 23 May 2020 11:48:11 +0100 Subject: [8u] RFR: 8244843: [JDK 8u] JapanEraNameCompatTest fails In-Reply-To: <3037e70f07846eda25fdf67e3b022e4ce30fb458.camel@redhat.com> References: <12b4fdfab95f458c396b7e0b64770907adb19a1a.camel@redhat.com> <3037e70f07846eda25fdf67e3b022e4ce30fb458.camel@redhat.com> Message-ID: <04a578a7-4577-924f-4dc1-8741e3bddb8e@redhat.com> On 15/05/2020 10:22, Severin Gehwolf wrote: > Hi Andrew, > > Sigh, I only now realized that the bug number was missing the > subject. Fixed now. > snip... >>> >> >> Only issue with the patch itself is java.time.japanese.short.Eras is >> missing the new Reiwa era. I guess this is because 11u has JDK-8159943, >> which refactors these files so they share blocks where possible, before >> JDK-8219781. Thus, there is only one block to change in 11u, but it's a >> shared block which is then used from both java.time.japanese.short.Eras >> & java.time.japanese.long.Eras > > Should be fixed in 03 here. Thanks for the catch: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8244843/03/webrev/ > > Thoughts? > > Thanks, > Severin > I thought I replied to this about a week ago, but I can find no trace of doing so :/ Anyway, this version looks fine. Please flag with jdk8u-fix-request and let's get it fixed. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From david.holmes at oracle.com Sat May 23 13:18:15 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 23 May 2020 23:18:15 +1000 Subject: RFR: 8245455: Remove alternative StringConcatFactory strategies In-Reply-To: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> References: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> Message-ID: <31833fcf-7222-efae-b513-576973c6c8e2@oracle.com> Hi Claes, You are removing a property so this needs a CSR request. Thanks, David On 22/05/2020 7:52 pm, Claes Redestad wrote: > Hi, > > this patch removes the alternative, undocumented strategies from > StringConcatFactory. > > The default strategy has been optimized and stabilized since inception > in JDK 9, while the alternative strategies have been falling behind > both in terms of performance and stability - while adding maintenance > cost. > > The removal allows some simplifications to the code that will reduce > per callsite bootstrap overhead, and reduce what we need to load eagerly > during bootstrap. I've also applied the pattern from JDK-8218173 to > the remaining Stringifier method handles, which further improve > robustness of bootstrapping under an OOME condition. > > Webrev: http://cr.openjdk.java.net/~redestad/8245455/open.00/ > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8245455 > > Testing: tier1-3 > > Thanks! > > /Claes From claes.redestad at oracle.com Sat May 23 17:41:08 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 23 May 2020 19:41:08 +0200 Subject: Avoid allocations in Executable.getAllGenericParameterTypes In-Reply-To: References: Message-ID: <40b1b0ee-e41d-28db-48e0-b6d8b4c1d47d@oracle.com> Hi Christoph, I agree this might not be called super often, but the refactoring is straightforward and I think it clarifies the intent of the code, so seems like a reasonable enhancement to make. I've already volunteered to sponsor another patch of yours, so I might as well pick this up too and test them together. /Claes On 2020-05-23 09:53, Christoph Dreis wrote: > Hi, > > I was looking through the code and found a relatively straight-forward optimization in Executable.getAllGenericParameterTypes (attached below). > The idea is to simply move some code around to avoid unnecessary allocations from getParameters() or array initializations when working with generics and no "real" parameter data is available. > > I used the following benchmark: > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class MyBenchmark { > > @State(Scope.Benchmark) > public static class ThreadState { > > private Parameter parameter; > > public ThreadState() { > try { > this.parameter = Test1.class.getDeclaredConstructor(Set.class).getParameters()[0]; > } catch (NoSuchMethodException e) { > // Do nothing > } > } > > } > > @Benchmark > public AnnotatedType test(ThreadState threadState) { > return threadState.parameter.getAnnotatedType(); > } > > } > > public class Test1 { > public Test1(Set names) {} > } > > With the attached patch and the benchmark above I get the following results. > > Old > Benchmark Mode Cnt Score Error Units > MyBenchmark.test avgt 10 358,103 ? 58,098 ns/op > MyBenchmark.test:?gc.alloc.rate.norm avgt 10 248,021 ? 0,003 B/op > > Patched > MyBenchmark.test avgt 10 309,133 ? 6,319 ns/op > MyBenchmark.test:?gc.alloc.rate.norm avgt 10 200,016 ? 0,001 B/op > > > I don't think the particular method is called super often, but it seems to be used in ByteBuddy & JUnit as far as I can see. > In case you think this is worthwhile, I would appreciate it if someone can sponsor this patch. > > Cheers, > Christoph > > ========= PATCH ========== > --- a/src/java.base/share/classes/java/lang/reflect/Executable.java Wed May 13 16:18:16 2020 +0200 > +++ b/src/java.base/share/classes/java/lang/reflect/Executable.java Sat May 23 08:31:23 2020 +0200 > @@ -307,12 +307,12 @@ > final boolean realParamData = hasRealParameterData(); > final Type[] genericParamTypes = getGenericParameterTypes(); > final Type[] nonGenericParamTypes = getParameterTypes(); > - final Type[] out = new Type[nonGenericParamTypes.length]; > - final Parameter[] params = getParameters(); > - int fromidx = 0; > // If we have real parameter data, then we use the > // synthetic and mandate flags to our advantage. > if (realParamData) { > + final Type[] out = new Type[nonGenericParamTypes.length]; > + final Parameter[] params = getParameters(); > + int fromidx = 0; > for (int i = 0; i < out.length; i++) { > final Parameter param = params[i]; > if (param.isSynthetic() || param.isImplicit()) { > @@ -325,6 +325,7 @@ > fromidx++; > } > } > + return out; > } else { > // Otherwise, use the non-generic parameter data. > // Without method parameter reflection data, we have > @@ -334,7 +335,6 @@ > return genericParamTypes.length == nonGenericParamTypes.length ? > genericParamTypes : nonGenericParamTypes; > } > - return out; > } > > From openjdk at icemanx.nl Sat May 23 19:13:16 2020 From: openjdk at icemanx.nl (Rob Spoor) Date: Sat, 23 May 2020 21:13:16 +0200 Subject: [BUG] java.util.Properties.entrySet() does not override java.lang.Object methods since Java 9 Message-ID: Hi, I was working on upgrading a library of mine from Java 8 to 11, and I noticed my unit tests started failing. Some investigation showed that in Java 9, java.util.Properties was rewritten to no longer rely on the fact that it extends Hashtable. One of the changes was to use a private static class called EntrySet. However, while this class implements most methods from java.util.Set, it's actually missing two: equals and hashCode. As a result it does not adhere to the general contract of java.util.Set. It's also missing a toString implementation, thereby inheriting its String representation from java.lang.Object. I've checked the source code up to Java 14, and even the Mercurial repository, and this issue still exists. I think this could be solved as simply as by having this private EntrySet class extend AbstractSet, or otherwise delegate its methods to its entrySet field. The latter is probably preferred, as it matches the implementation of the same methods of the java.util.Properties class itself. Rob From openjdk at icemanx.nl Sat May 23 19:22:44 2020 From: openjdk at icemanx.nl (Rob Spoor) Date: Sat, 23 May 2020 21:22:44 +0200 Subject: [BUG] java.util.Properties.entrySet() does not override java.lang.Object methods since Java 9 In-Reply-To: References: Message-ID: <0148aedd-cae9-e1dc-5acb-41091efdb776@icemanx.nl> On 23/05/2020 21:13, Rob Spoor wrote: > Hi, > > I was working on upgrading a library of mine from Java 8 to 11, and I > noticed my unit tests started failing. Some investigation showed that in > Java 9, java.util.Properties was rewritten to no longer rely on the fact > that it extends Hashtable. One of the changes was to use a private > static class called EntrySet. However, while this class implements most > methods from java.util.Set, it's actually missing two: equals and > hashCode. As a result it does not adhere to the general contract of > java.util.Set. It's also missing a toString implementation, thereby > inheriting its String representation from java.lang.Object. I've checked > the source code up to Java 14, and even the Mercurial repository, and > this issue still exists. > > I think this could be solved as simply as by having this private > EntrySet class extend AbstractSet, or otherwise delegate its methods to > its entrySet field. The latter is probably preferred, as it matches the > implementation of the same methods of the java.util.Properties class > itself. > > Rob I've also noticed that keySet() and values() may behave differently if you add an entry with the keySet() as key or values() as value. While before that would have printed "(this Collection)", it will now cause a StackOverflowError because the key set or values collection no longer contains itself (which is the keySet() or values() from the backing ConcurrentHashMap), but a synchronized wrapper. While this is a rare corner case (nobody in their right mind would add anything but Strings to a java.util.Properties object), it is probably an unintended side effect of the rewrite of java.util.Properties. From mandy.chung at oracle.com Sat May 23 21:19:40 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Sat, 23 May 2020 14:19:40 -0700 Subject: RFR: 8245455: Remove alternative StringConcatFactory strategies In-Reply-To: <31833fcf-7222-efae-b513-576973c6c8e2@oracle.com> References: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> <31833fcf-7222-efae-b513-576973c6c8e2@oracle.com> Message-ID: Has that system property ever documented in CSR???? It's not in CSR for JEP 280 [1].?? Maybe other CSR? Mandy [1] https://bugs.openjdk.java.net/browse/CCC-8085796 On 5/23/20 6:18 AM, David Holmes wrote: > Hi Claes, > > You are removing a property so this needs a CSR request. > > Thanks, > David > > On 22/05/2020 7:52 pm, Claes Redestad wrote: >> Hi, >> >> this patch removes the alternative, undocumented strategies from >> StringConcatFactory. >> >> The default strategy has been optimized and stabilized since >> inception in JDK 9, while the alternative strategies have been >> falling behind >> both in terms of performance and stability - while adding maintenance >> cost. >> >> The removal allows some simplifications to the code that will reduce >> per callsite bootstrap overhead, and reduce what we need to load eagerly >> during bootstrap. I've also applied the pattern from JDK-8218173 to >> the remaining Stringifier method handles, which further improve >> robustness of bootstrapping under an OOME condition. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8245455/open.00/ >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8245455 >> >> Testing: tier1-3 >> >> Thanks! >> >> /Claes From andy.herrick at oracle.com Sun May 24 21:53:29 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Sun, 24 May 2020 17:53:29 -0400 Subject: RFR: 8242786: [macos] tools/jpackage/share/IconTest.java fails: ABORT trying to dequeue work In-Reply-To: References: Message-ID: <37a07ed3-5520-2d17-7a0f-5c4a959279e7@oracle.com> looks good /Andy On 5/22/2020 7:33 PM, alexander.matveev at oracle.com wrote: > Please review the jpackage fix for bug [1] at [2]. > > - Detach fails sometimes due to disk image being busy. Not sure what > keeps disk image busy. Probably antivirus or something else. Within > short period of time disk image can be detach. So, fix is just re-try > detach if it did not work right away. With proposed fix I was not able > to reproduce this issue again. > > [1] https://bugs.openjdk.java.net/browse/JDK-8242786 > > [2] http://cr.openjdk.java.net/~almatvee/8242786/webrev.00/ > > Thanks, > Alexander From david.holmes at oracle.com Sun May 24 21:56:51 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 May 2020 07:56:51 +1000 Subject: RFR: 8245455: Remove alternative StringConcatFactory strategies In-Reply-To: References: <33e37c51-cc22-a90f-4946-4451f2918d8b@oracle.com> <31833fcf-7222-efae-b513-576973c6c8e2@oracle.com> Message-ID: After some offlist discussion it seems this is an undocumented property (not unlike a VM diagnostic option) and does not require a CSR request to remove. David On 24/05/2020 7:19 am, Mandy Chung wrote: > Has that system property ever documented in CSR???? It's not in CSR for > JEP 280 [1].?? Maybe other CSR? > > Mandy > [1] https://bugs.openjdk.java.net/browse/CCC-8085796 > > On 5/23/20 6:18 AM, David Holmes wrote: >> Hi Claes, >> >> You are removing a property so this needs a CSR request. >> >> Thanks, >> David >> >> On 22/05/2020 7:52 pm, Claes Redestad wrote: >>> Hi, >>> >>> this patch removes the alternative, undocumented strategies from >>> StringConcatFactory. >>> >>> The default strategy has been optimized and stabilized since >>> inception in JDK 9, while the alternative strategies have been >>> falling behind >>> both in terms of performance and stability - while adding maintenance >>> cost. >>> >>> The removal allows some simplifications to the code that will reduce >>> per callsite bootstrap overhead, and reduce what we need to load eagerly >>> during bootstrap. I've also applied the pattern from JDK-8218173 to >>> the remaining Stringifier method handles, which further improve >>> robustness of bootstrapping under an OOME condition. >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8245455/open.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8245455 >>> >>> Testing: tier1-3 >>> >>> Thanks! >>> >>> /Claes > From david.holmes at oracle.com Mon May 25 02:28:33 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 25 May 2020 12:28:33 +1000 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> Message-ID: <9d7da8af-cda3-693d-1ea1-1db5069fea97@oracle.com> Hi Harold, On 22/05/2020 4:33 am, Harold Seigel wrote: > Hi David, > > Thanks for looking at this!? Please review this new webrev: > > http://cr.openjdk.java.net/~hseigel/webrev.01/webrev/ I'll list all relevant commens here rather than interspersing below so that it is easier to track. Mostly nits below, other than the is_permitted_subclass check in the VM, and the use of ReflectionData in java.lang.Class. -- src/hotspot/share/classfile/classFileParser.cpp + bool ClassFileParser::supports_sealed_types() { + return _major_version == JVM_CLASSFILE_MAJOR_VERSION && + _minor_version == JAVA_PREVIEW_MINOR_VERSION && + Arguments::enable_preview(); + } Nowe there is too little indentation - the subclauses of the conjunction expression should align[1] + bool ClassFileParser::supports_sealed_types() { + return _major_version == JVM_CLASSFILE_MAJOR_VERSION && + _minor_version == JAVA_PREVIEW_MINOR_VERSION && + Arguments::enable_preview(); + } 3791 if (parsed_permitted_subclasses_attribute) { 3792 classfile_parse_error("Multiple PermittedSubclasses attributes in class file %s", CHECK); 3793 // Classes marked ACC_FINAL cannot have a PermittedSubclasses attribute. 3794 } else if (_access_flags.is_final()) { 3795 classfile_parse_error("PermittedSubclasses attribute in final class file %s", CHECK); 3796 } else { 3797 parsed_permitted_subclasses_attribute = true; 3798 } The indent of the comment at L3793 is wrong, and its placement is awkward because it relates to the next condition. But we don't have to use if-else here as any parse error results in immediate return due to the CHECK macro. So the above can be reformatted as: 3791 if (parsed_permitted_subclasses_attribute) { 3792 classfile_parse_error("Multiple PermittedSubclasses attributes in class file %s", CHECK); 3793 } 3794 // Classes marked ACC_FINAL cannot have a PermittedSubclasses attribute. 3795 if (_access_flags.is_final()) { 3796 classfile_parse_error("PermittedSubclasses attribute in final class file %s", CHECK); 3797 } 3798 parsed_permitted_subclasses_attribute = true; --- src/hotspot/share/oops/instanceKlass.cpp The logic in InstanceKlass::has_as_permitted_subclass still does not implement the rules specified in the JVMS. It only implements a "same module" check, whereas the JVMS specifies an accessibility requirement as well. 730 bool InstanceKlass::is_sealed() const { 731 return _permitted_subclasses != NULL && 732 _permitted_subclasses != Universe::the_empty_short_array() && 733 _permitted_subclasses->length() > 0; 734 } Please align subclauses. --- src/hotspot/share/prims/jvm.cpp 2159 objArrayHandle result (THREAD, r); Please remove space after "result". As we will always create and return an arry, if you reverse these two statements: 2156 if (length != 0) { 2157 objArrayOop r = oopFactory::new_objArray(SystemDictionary::String_klass(), 2158 length, CHECK_NULL); and these two: 2169 return (jobjectArray)JNIHandles::make_local(THREAD, result()); 2170 } then you can delete 2172 // if it gets to here return an empty array, cases will be: the class is primitive, or an array, or just not sealed 2173 objArrayOop result = oopFactory::new_objArray(SystemDictionary::String_klass(), 0, CHECK_NULL); 2174 return (jobjectArray)JNIHandles::make_local(env, result); The comment there is no longer accurate anyway. --- src/hotspot/share/prims/jvmtiRedefineClasses.cpp 857 static jvmtiError check_permitted_subclasses_attribute(InstanceKlass* the_class, 858 InstanceKlass* scratch_class) { Please align. --- src/hotspot/share/prims/jvmtiRedefineClasses.cpp 2007 if (permitted_subclasses != NULL) { permitted_subclasses cannot be NULL. I initially thought the bug was in the nest_members version of this code, but they both have the same properties: the member is initialized to NULL when the InstanceKlass is constructed, and set to either the proper array or the empty_array() when classfile parsing is complete. So redefinition cannot encounter a NULL value here. --- src/java.base/share/classes/java/lang/Class.java The use of ReflectionData is not correctly implemented. The ReflectionData instance is not constant but can be replaced when class redefinition operates. So you cannot do this: if (rd.permittedSubclasses != null) { return rd.permittedSubclasses; } because you may be returning the permittedSubclasses field of a different Reflectiondata instance. You need to read the field once into a local and thereafter use it. Similarly with: rd.permittedSubclasses = new ClassDesc[0]; return rd.permittedSubclasses; you need to do: temp = new ClassDesc[0]; rd.permittedSubclasses = temp; return temp; I'm wondering now whether using Reflectiondata as the cache for this is actually the best way to cache it? Aside: The JEP should explicitly point out that because the sealed/non-sealed modifiers are not represented in the classfile directly, they are also not exposed via the java.lang.reflect.Modifier API. --- That's it form me. Thanks, David [1] https://wiki.openjdk.java.net/display/HotSpot/StyleGuide "Use good taste to break lines and align corresponding tokens on adjacent lines." > This webrev contains the following significant changes: > > 1. The format/indentation issues in classFileParser.cpp were fixed. > 2. Unneeded checks in InstanceKlass::has_as_permitted_subclass() were > removed and the TRAPS parameter was removed. > 3. The changes to klassVtable.* and method.* were reverted. Those > changes were from when sealed classes were marked as final, and are > no longer valid. > 4. Method getPermittedSubclasses() in Class.java was renamed to > permittedSubclasses() and its implementation was changed. > 5. Variables and methods for 'asm' were renamed from > 'permittedSubtypes' to 'permittedSubclasses'. > 6. Classes for sealed classes tests were changed to start with capital > letters. > 7. Changes to langtools tests were removed from this webrev. They are > covered by the javac webrev (JDK-8244556). > 8. The CSR's for JVMTI, JDWP, and JDI are in progress. > > Please also see comments inline. > > > On 5/19/2020 1:26 AM, David Holmes wrote: >> Hi Harold, >> >> Adding serviceability-dev for the serviceability related changes. >> >> Nit: "VM support for sealed classes" >> >> This RFR covers the VM, core-libs, serviceability and even some >> langtools tests. AFAICS only the javac changes are not included here >> so when and where will they be reviewed and under what bug id? Ideally >> there will be a single JBS issue for "Implementation of JEP 360: >> Sealed types". It's okay to break up the RFRs across different areas, >> but it should be done under one bug id. > The javac changes are being reviewed as bug JDK-8227406.? We understand > the need to do the reviews under one bug. >> >> Overall this looks good. I've looked at all files and mainly have some >> style nits in various places. But there are some more significant >> items below. >> >> On 14/05/2020 7:09 am, Harold Seigel wrote: >>> Hi, >>> >>> Please review this patch for JVM and Core-libs support for the JEP >>> 360 Sealed Classes preview feature.? Code changes include the following: >>> >>> ??* Processing of the new PermittedSubclasses attribute to enforce that >>> ??? a class or interface, whose super is a sealed class or interface, >>> ??? must be listed in the super's PermittedSubclasses attribute. >>> ??* Disallow redefinition of a sealed class or interface if its >>> ??? redefinition would change its PermittedSubclasses attribute. >>> ??* Support API's to determine if a class or interface is sealed and, if >>> ??? it's sealed, return a list of its permitted subclasses. >>> ??* asm support for the PermittedSubclasses attribute >> >> I assume Remi is providing the upstream support in ASM? :) But also >> see below ... >> >>> >>> Open Webrev: >>> http://cr.openjdk.java.net/~vromero/8225056/webrev.00/index.html >> >> make/data/jdwp/jdwp.spec >> >> There needs to be a sub-task and associated CSR request for this JDWP >> spec update. I couldn't see this covered anywhere. >> >> --- >> >> src/hotspot/share/classfile/classFileParser.cpp >> >> 3215 u2 >> ClassFileParser::parse_classfile_permitted_subclasses_attribute(const >> ClassFileStream* const cfs, >> 3216 const u1* const permitted_subclasses_attribute_start, >> 3217 TRAPS) { >> >> Indention on L3216/17 needs fixing after the copy'n'edit. >> >> 3515?? return _major_version == JVM_CLASSFILE_MAJOR_VERSION && >> 3516????????????? _minor_version == JAVA_PREVIEW_MINOR_VERSION && >> 3517????????????? Arguments::enable_preview(); >> >> Too much indentation on L3516/17 >> >> 3790???????????????? // Check for PermittedSubclasses tag >> >> That comment (copied from my nestmates code :) is in the wrong place. >> It needs to be before >> >> 3788???????????? if (tag == vmSymbols::tag_permitted_subclasses()) { >> >> >> Minor nit: I would suggest checking >> parsed_permitted_subclasses_attribute before checking ACC_FINAL. >> >> 3876?? if (parsed_permitted_subclasses_attribute) { >> 3877???? const u2 num_of_subclasses = >> parse_classfile_permitted_subclasses_attribute( >> 3878??????????????????????????????????? cfs, >> 3879 permitted_subclasses_attribute_start, >> 3880??????????????????????????????????? CHECK); >> >> Although it looks odd the preceding, similarly shaped, sections all >> indent to the same absolute position. Can you make L3878/78/80 match >> please. >> >> 3882?????? guarantee_property( >> 3883???????? permitted_subclasses_attribute_length == >> 3884?????????? sizeof(num_of_subclasses) + sizeof(u2) * >> num_of_subclasses, >> 3885???????? "Wrong PermittedSubclasses attribute length in class file >> %s", CHECK); >> >> Nits: please reformat as: >> >> 3882?????? guarantee_property( >> 3883???????? permitted_subclasses_attribute_length == >> sizeof(num_of_subclasses) + sizeof(u2) * num_of_subclasses, >> 3885???????? "Wrong PermittedSubclasses attribute length in class file >> %s", CHECK); >> >> It would also look slightly better if you shortened the name of the >> num_of_subclasses variable. > All of the above classFileParser.cpp changes were done. >> >> --- >> >> src/hotspot/share/classfile/classFileParser.hpp >> >> +?? u2 parse_classfile_permitted_subclasses_attribute(const >> ClassFileStream* const cfs, >> +???????????????????????????????????????????? const u1* const >> permitted_subclasses_attribute_start, >> +???????????????????????????????????????????? TRAPS); >> >> Please fix indentation after copy'n'edit. > Done. >> >> --- >> >> src/hotspot/share/oops/instanceKlass.cpp >> >> ?247?? if (classloader1 != classloader2) { >> >> I'm not clear what rule this is verifying. The same module check >> follows this one. The rule is that the subclass must be accessible to >> the superclass implying: >> 1. same named module (regardless of class access modifiers); or >> 2. (implicitly in un-named module) same package if subclass not >> public; or >> 3. public subclass >> >> Having the same classloader implies same package, but that alone >> doesn't address 2 or 3. So this doesn't conform to proposed JVMS rules. > This was discussed as part of the CSR and hopefully clarified. >> >> >> >> ?264???? if (_constants->tag_at(cp_index).is_klass()) { >> ?265?????? Klass* k2 = _constants->klass_at(cp_index, CHECK_false); >> >> You've copied this code from the nestmember checks but your changes >> don't quite make sense to me. If we have already checked is_klass() >> then klass_at() cannot lead to any exceptions. >> >> ?272?????? if (name == k->name()) { >> ?273???????? log_trace(class, sealed)("- Found it at >> permitted_subclasses[%d] => cp[%d]", i, cp_index); >> ?274???????? return true; >> >> I was wondering why you don't resolve the cp entry when you find the >> name matches, as we do for nest members, but realized that unlike the >> nest membership check, which can happen many times for a given class, >> this permitted subclass check can only happen once per class. As you >> don't actually resolve here, and given that the earlier check cannot >> throw exceptions, it follows that the entire method never results in >> any exceptions and so callers should not be using the CHECK macro. > > The comparison of class loaders was removed because checking that the > two classes are in the same module ensures that they have the same class > loader. > > The traps parameter was removed.? The CHECK macro was replaced with THREAD. > >> >> --- >> >> src/hotspot/share/oops/method.cpp >> >> I don't understand how knowing the class is sealed allows you to infer >> that a non-final method is actually final ?? > This change was removed.? See item #3 at the beginning of this email. >> >> --- >> >> ?src/hotspot/share/prims/jvm.cpp >> >> It would be simpler (and cheaper) if the Java side of this ensures it >> doesn't call into the VM with an array or primitive class. > Done. >> >> --- >> >> ?src/hotspot/share/prims/jvmti.xml >> >> The JVM TI spec changes also need to be covered by a CSR request. >> >> --- >> >> src/hotspot/share/prims/jvmtiRedefineClasses.cpp >> >> We should file a RFE to refactor the logic that checks that an >> attribute consisting of a list of classes has not changed. :) > Serguei filed the RFE. >> >> Aside: I spotted a bug in the nest member code (missing NULL check!) >> thanks to your change :) >> >> --- >> >> src/java.base/share/classes/java/lang/Class.java >> >> There needs to be a CSR request for these changes. > The CSR is JDK-8244556. >> >> +????? * Returns an array containing {@code ClassDesc} objects >> representing all the >> +????? * permitted subclasses of this {@linkplain Class} if it is >> sealed. Returns an empty array if this >> +????? * {@linkplain Class} is not sealed. >> >> should add "or this class represents an array or primitive type" >> (using the standard wording for such cases). > Discussed off-line and was decided that this text isn't needed. >> >> +????? * @throws IllegalArgumentException if a class descriptor is not >> in the correct format >> >> IllegalArgumentException is not an appropriate exception to use as >> this method takes no arguments. If the class descriptor is not valid >> and it comes from the VM then I think we have a problem with how the >> VM validates class descriptors. Any IAE from ClassDesc.of should be >> caught and converted to a more suitable exception type - preferably >> InternalError if the VM should always return valid strings. > Done. >> >> +???? public ClassDesc[] getPermittedSubclasses() { >> >> As mentioned for jvm.cpp this Java code should do the isArray() and >> isPrimitive() check before calling the VM. > Done. >> >> +???????? String[] descriptors = getPermittedSubclasses0(); >> >> Nit: what you get from the VM are not descriptors, just name strings >> in internal form. This wouldn't really matter except it then looks >> strange to call ClassDesc.of(...) instead of ClassDesc.ofDescriptor(...). > We tried using ClassDesc.ofDescriptor() but encountered problems. The > variable 'descriptors' was renamed 'subclassNames'. >> >> +???????? if (descriptors == null >> >> The VM never returns null. > The check was removed. >> >> +???????? return getPermittedSubclasses().length != 0; >> >> It's grossly inefficient to create the ClassDesc array and then throw >> it away IMO. The result should be cached either in a field of Class or >> in the ReflectionData of the class. > Done. >> >> --- >> >> src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java >> >> >> !???????? // - The offset of the PermittedSubclasses attribute, or 0 >> ????????? int permittedSubtypesOffset = 0; >> >> Obviously ASM already has some prelim support for sealed classes, but >> now that the attribute has been renamed that should also flow through >> to the ASM code ie the variable, not just the comment. >> >> Ditto for ClassWriter.java and its fields. > Done. >> >> --- >> >> src/java.base/share/native/libjava/Class.c >> >> ????? {"isRecord0",??????????? "()Z",???????? (void *)&JVM_IsRecord}, >> +???? {"getPermittedSubclasses0", "()[" STR,??? (void >> *)&JVM_GetPermittedSubclasses}, >> >> please align (void >> > Done. >> --- >> >> src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java >> >> src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java >> >> There needs to be a CSR for these changes too. >> >> --- >> >> test/langtools/tools/javac/processing/model/TestSourceVersion.java >> >> !??????????????????? // Assume "record" and "sealed" will be >> restricted keywords. >> !??????????????????? "record", "sealed"); >> >> What about the non-sealed keyword defined in the JEP? > 'non-sealed' is a keyword but not a restricted keyword.? So, it should > not be in the list. >> >> --- >> >> In the tests you don't need to explicitly include >> sun.hotspot.WhiteBox$WhiteBoxPermission on the ClassFileInstaller >> invocation. (previous RFE's have been removing existing occurrences >> after the CFI was fixed to handle it internally). > Done. >> >> Please ensure all new tests have an @bug 8225056 (or whatever the >> actual JBS issue will be) > Done. >> >> All test classes (and thus files) should be named in camel-case i.e. >> C1 not c1, C2 not c2, SuperClass not superClass etc. > Done. >> >> >> test/hotspot/jtreg/runtime/modules/sealedP1/superClass.jcod >> test/hotspot/jtreg/runtime/sealedClasses/Pkg/sealedInterface.jcod >> >> Please add comments clarifying why these must be jcod files. > > Done. > > Thanks!? Harold > >> >> --- >> >> That's it from me. >> >> Thanks, >> David >> ----- >> >> >> >>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8225056 >>> >>> Java Language Spec changes: >>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html >>> >>> >>> JVM Spec changes: >>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jvms.html >>> >>> >>> JEP 360: https://bugs.openjdk.java.net/browse/JDK-8227043 >>> >>> JVM CSR: https://bugs.openjdk.java.net/browse/JDK-8242578 >>> >>> Changes to javac and other language tools will be reviewed separately. >>> >>> Thanks, Harold >>> >>> From Roger.Riggs at oracle.com Mon May 25 02:33:54 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Sun, 24 May 2020 22:33:54 -0400 Subject: [BUG] java.util.Properties.entrySet() does not override java.lang.Object methods since Java 9 In-Reply-To: References: Message-ID: <59c48be4-9c4c-f64e-bfc4-41b5fec96b4d@oracle.com> Hi Rob, Thanks for the report, an issues has been created: https://bugs.openjdk.java.net/browse/JDK-8245694 Regards, Roger On 5/23/20 3:13 PM, Rob Spoor wrote: > Hi, > > I was working on upgrading a library of mine from Java 8 to 11, and I > noticed my unit tests started failing. Some investigation showed that > in Java 9, java.util.Properties was rewritten to no longer rely on the > fact that it extends Hashtable. One of the changes was to use a > private static class called EntrySet. However, while this class > implements most methods from java.util.Set, it's actually missing two: > equals and hashCode. As a result it does not adhere to the general > contract of java.util.Set. It's also missing a toString > implementation, thereby inheriting its String representation from > java.lang.Object. I've checked the source code up to Java 14, and even > the Mercurial repository, and this issue still exists. > > I think this could be solved as simply as by having this private > EntrySet class extend AbstractSet, or otherwise delegate its methods > to its entrySet field. The latter is probably preferred, as it matches > the implementation of the same methods of the java.util.Properties > class itself. > > Rob From Yang.Zhang at arm.com Mon May 25 08:26:45 2020 From: Yang.Zhang at arm.com (Yang Zhang) Date: Mon, 25 May 2020 08:26:45 +0000 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> Message-ID: Hi Andrew Please check the following. >> We have made changes similar in spirit to the x64 ad file (reducing in size at least), so I think it reasonable request before integration to reduce the cognitive and maintenance burden. > So here's a question: can the changes to the AArch64 back end be made to mainline now? Or is there a problem in that the C2 patterns being used don't exist? X86 ad file has been refactored to reduce code size in a series of JBSs [1]. I also investigated how to make similar changes to AArch64 ad file in Aug 2019. In summary, these changes wouldn't have a great impact on AArch64. If making similar changes to AArch64, about ~200kb (1% of total code size) will be reduced [2]. So I don't think we need to make these changes to AArch64 for now. To reduce maintenance burden, I agree that all the vector stuff should be moved into a new file, just like AArch64 SVE has done [3]. All the SVE instructions are generated by m4 file and placed in aarch64_sve.ad. For newly added NEON instructions in Vector API, they are all generated by m4 file. In jdk master, what we need to do is that writing m4 file for existing vector instructions and placed them to a new file aarch64_neon.ad. If no question, I will do it right away. [1] https://bugs.openjdk.java.net/browse/JDK-8230015 [2] The data came from: I implement an example (merging vaddB/S/I/F) in AArch64 platform. The code size reduction in libjvm.so is ~15kb. If all the vector instructions are merged, the estimated size reduction would be ~200kb. The code size from vector support in AArch64 backend is ~450kb (2% of total size). Original libjvm.so is 20770256, while libjvm.so without vector support is 20317328. Based on the idea of generic vector operands, half of vector stuff can be removed. So the estimated size reduction is also ~200kb. [3] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-March/037628.html Regards Yang -----Original Message----- From: Andrew Haley Sent: Saturday, May 23, 2020 5:16 PM To: Paul Sandoz Cc: Yang Zhang ; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; nd Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes On 5/22/20 7:01 PM, Paul Sandoz wrote: > We have made changes similar in spirit to the x64 ad file (reducing in size at least), so I think it reasonable request before integration to reduce the cognitive and maintenance burden. So here's a question: can the changes to the AArch64 back end be made to mainline now? Or is there a problem in that the C2 patterns being used don't exist? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From maurizio.cimadamore at oracle.com Mon May 25 09:58:52 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 25 May 2020 10:58:52 +0100 Subject: RFR 8243491: Implementation of Foreign-Memory Access API (Second Incubator) In-Reply-To: <9beb2729-4ab8-deda-fc92-b4550fdfbb4e@oracle.com> References: <7a96ec1b-cdec-1e3f-f6ca-102d7340e70a@oracle.com> <271da482-cdbc-1d53-2ddd-efcb3a62ddff@oracle.com> <543817be-92d5-d6b1-d8e5-88f6fd3f3346@oracle.com> <9beb2729-4ab8-deda-fc92-b4550fdfbb4e@oracle.com> Message-ID: <4dd9bf13-63e2-8d65-7c45-8fb8a4ce42e6@oracle.com> I've just integrated this - thanks to all the contributors and reviewers for the help! Cheers Maurizio On 20/05/2020 15:01, Maurizio Cimadamore wrote: > Another very small iteration which fixes a gap in the javadoc > specification for MemorySegment::toArray (thanks Chris!) > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev > > Delta webrev: > > http://cr.openjdk.java.net/~mcimadamore/8243491_v5/webrev_delta/ > > > Cheers > Maurizio > > On 13/05/2020 13:12, Maurizio Cimadamore wrote: >> Another iteration which addresses the latest CSR comments (the CSR >> has now been approved): >> >> * make MemorySegment::withAccessModes/hasAccessMode throw >> IllegalArgumentException in cases where the provided mask is invalid >> (this required a test tweak) >> * sprinkled a couple of references to the JLS in the package javadoc, >> as per CSR suggestions >> * Fixed the ParallelSum::findAny_bulk benchmarks, which were >> (erroneously) not testing all the elements in the segment >> >> Webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/8243491_v4/webrev >> >> Delta webrev: >> >> http://cr.openjdk.java.net/~mcimadamore/8243491_v4/webrev_delta/ >> >> >> Cheers >> Maurizio >> >> On 01/05/2020 12:06, Maurizio Cimadamore wrote: >>> Latest iteration - the follow issues were addressed: >>> >>> * fix a bug with alignment of native segments triggering spurious >>> failures (contributed by Jorn) >>> * fix javadoc and tests for access modes (contributed by Chris) >>> * added benchmarks for Stream::findAny using segment spliterator >>> (contributed by Peter) >>> * addressed CSR comments >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~mcimadamore/8243491_v3/webrev >>> >>> Delta webrev: >>> >>> http://cr.openjdk.java.net/~mcimadamore/8243491_v3/webrev_delta/ >>> >>> Javadoc: >>> >>> http://cr.openjdk.java.net/~mcimadamore/8243491_v3/javadoc >>> >>> Specdiff: >>> >>> http://cr.openjdk.java.net/~mcimadamore/8243491_v3/specdiff/overview-summary.html >>> >>> >>> >>> Cheers >>> Maurizio >>> >>> On 27/04/2020 13:13, Maurizio Cimadamore wrote: >>>> Another iteration, which addresses the following issues: >>>> >>>> * wrong copyright headers in certain tests >>>> * issue with TestNative when running in debug mode caused by >>>> mismatched malloc/os::free (contributed by Jorn) >>>> * clarify javadoc of MemoryHandles::withStride >>>> * improved implementation of MemoryAccessVarHandleGenerator to use >>>> hidden classes rather than Unsafe.dAC (contributed by Mandy) >>>> >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/8243491_v2/webrev >>>> >>>> Delta webrev: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/8243491_v2/webrev_delta/ >>>> >>>> Javadoc: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/8243491_v2/javadoc >>>> >>>> Specdiff: >>>> >>>> http://cr.openjdk.java.net/~mcimadamore/8243491_v2/specdiff/overview-summary.html >>>> >>>> >>>> >>>> Cheers >>>> Maurizio >>>> >>>> >>>> On 23/04/2020 21:33, Maurizio Cimadamore wrote: >>>>> Hi, >>>>> time has come for another round of foreign memory access API >>>>> incubation (see JEP 383 [3]). This iteration aims at polishing >>>>> some of the rough edges of the API, and adds some of the >>>>> functionalities that developers have been asking for during this >>>>> first round of incubation. The revised API tightens the >>>>> thread-confinement constraints (by removing the >>>>> MemorySegment::acquire method) and instead provides more targeted >>>>> support for parallel computation via a segment spliterator. The >>>>> API also adds a way to create a custom native segment; this is, >>>>> essentially, an unsafe API point, very similar in spirit to the >>>>> JNI NewDirectByteBuffer functionality [1]. By using this bit of >>>>> API,? power-users will be able to add support, via MemorySegment, >>>>> to *their own memory sources* (e.g. think of a custom allocator >>>>> written in C/C++). For now, this API point is called off as >>>>> "restricted" and a special read-only JDK property will have to be >>>>> set on the command line for calls to this method to succeed. We >>>>> are aware there's no precedent for something like this in the Java >>>>> SE API - but if Project Panama is to remain true about its >>>>> ultimate goal of replacing bits of JNI code with (low level) Java >>>>> code, stuff like this has to be *possible*. We anticipate that, at >>>>> some point, this property will become a true launcher flag, and >>>>> that the foreign restricted machinery will be integrated more >>>>> neatly into the module system. >>>>> >>>>> A list of the API, implementation and test changes is provided >>>>> below. If you have any questions, or need more detailed >>>>> explanations, I (and the rest of the Panama team) will be happy to >>>>> point at existing discussions, and/or to provide the feedback >>>>> required. >>>>> >>>>> Thanks >>>>> Maurizio >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~mcimadamore/8243491_v1/webrev >>>>> >>>>> Javadoc: >>>>> >>>>> http://cr.openjdk.java.net/~mcimadamore/8243491_v1/javadoc >>>>> >>>>> Specdiff: >>>>> >>>>> http://cr.openjdk.java.net/~mcimadamore/8243491_v1/specdiff/overview-summary.html >>>>> >>>>> >>>>> CSR: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8243496 >>>>> >>>>> >>>>> >>>>> API changes >>>>> =========== >>>>> >>>>> * MemorySegment >>>>> ? - drop support for acquire() method - in its place now you can >>>>> obtain a spliterator from a segment, which supports >>>>> divide-and-conquer >>>>> ? - revamped support for views - e.g. isReadOnly - now segments >>>>> have access modes >>>>> ? - added API to do serial confinement hand-off >>>>> (MemorySegment::withOwnerThread) >>>>> ? - added unsafe factory to construct a native segment out of an >>>>> existing address; this API is "restricted" and only available if >>>>> the program is executed using the -Dforeign.unsafe=permit flag. >>>>> ? - the MemorySegment::mapFromPath now returns a MappedMemorySegment >>>>> * MappedMemorySegment >>>>> ? - small sub-interface which provides extra capabilities for >>>>> mapped segments (load(), unload() and force()) >>>>> * MemoryAddress >>>>> ? - added distinction between *checked* and *unchecked* addresses; >>>>> *unchecked* addresses do not have a segment, so they cannot be >>>>> dereferenced >>>>> ? - added NULL memory address (it's an unchecked address) >>>>> ? - added factory to construct MemoryAddress from long value >>>>> (result is also an unchecked address) >>>>> ? - added API point to get raw address value (where possible - >>>>> e.g. if this is not an address pointing to a heap segment) >>>>> * MemoryLayout >>>>> ? - Added support for layout "attributes" - e.g. store metadata >>>>> inside MemoryLayouts >>>>> ? - Added MemoryLayout::isPadding predicate >>>>> ? - Added helper function to SequenceLayout to rehape/flatten >>>>> sequence layouts (a la NDArray [4]) >>>>> * MemoryHandles >>>>> ? - add support for general VarHandle combinators (similar to MH >>>>> combinators) >>>>> ? - add a combinator to turn a long-VH into a MemoryAddress VH >>>>> (the resulting MemoryAddress is also *unchecked* and cannot be >>>>> dereferenced) >>>>> >>>>> Implementation changes >>>>> ====================== >>>>> >>>>> * add support for VarHandle combinators (e.g. IndirectVH) >>>>> >>>>> The idea here is simple: a VarHandle can almost be thought of as a >>>>> set of method handles (one for each access mode supported by the >>>>> var handle) that are lazily linked. This gives us a relatively >>>>> simple idea upon which to build support for custom var handle >>>>> adapters: we could create a VarHandle by passing an existing var >>>>> handle and also specify the set of adaptations that should be >>>>> applied to the method handle for a given access mode in the >>>>> original var handle. The result is a new VarHandle which might >>>>> support a different carrier type and more, or less coordinate >>>>> types. Adding this support was relatively easy - and it only >>>>> required one low-level surgery of the lambda forms generated for >>>>> adapted var handle (this is required so that the "right" var >>>>> handle receiver can be used for dispatching the access mode call). >>>>> >>>>> All the new adapters in the MemoryHandles API (which are really >>>>> defined inside VarHandles) are really just a bunch of MH adapters >>>>> that are stitched together into a brand new VH. The only caveat is >>>>> that, we could have a checked exception mismatch: the VarHandle >>>>> API methods are specified not to throw any checked exception, >>>>> whereas method handles can throw any throwable. This means that, >>>>> potentially, calling get() on an adapted VarHandle could result in >>>>> a checked exception being thrown; to solve this gnarly issue, we >>>>> decided to scan all the filter functions passed to the VH >>>>> combinators and look for direct method handles which throw checked >>>>> exceptions. If such MHs are found (these can be deeply nested, >>>>> since the MHs can be adapted on their own), adaptation of the >>>>> target VH fails fast. >>>>> >>>>> >>>>> * More ByteBuffer implementation changes >>>>> >>>>> Some more changes to ByteBuffer support were necessary here. >>>>> First, we have added support for retrieval of "mapped" properties >>>>> associated with a ByteBuffer (e.g. the file descriptor, etc.). >>>>> This is crucial if we want to be able to turn an existing byte >>>>> buffer into the "right kind" of memory segment. >>>>> >>>>> Conversely, we also have to allow creation of mapped byte buffers >>>>> given existing parameters - which is needed when going from >>>>> (mapped) segment to a buffer. These two pieces together allow us >>>>> to go from segment to buffer and back w/o losing any information >>>>> about the underlying memory mapping (which was an issue in the >>>>> previous implementation). >>>>> >>>>> Lastly, to support the new MappedMemorySegment abstraction, all >>>>> the memory mapped supporting functionalities have been moved into >>>>> a common helper class so that MappedMemorySegmentImpl can reuse >>>>> that (e.g. for MappedMemorySegment::force). >>>>> >>>>> * Rewritten memory segment hierarchy >>>>> >>>>> The old implementation had a monomorphic memory segment class. In >>>>> this round we aimed at splitting the various implementation >>>>> classes so that we have a class for heap segments >>>>> (HeapMemorySegmentImpl), one for native segments >>>>> (NativeMemorySegmentImpl) and one for memory mapped segments >>>>> (MappedMemorySegmentImpl, which extends from >>>>> NativeMemorySegmentImpl). Not much to see here - although one >>>>> important point is that, by doing this, we have been able to speed >>>>> up performances quite a bit, since now e.g. native/mapped segments >>>>> are _guaranteed_ to have a null "base". We have also done few >>>>> tricks to make sure that the "base" accessor for heap segment is >>>>> sharply typed and also NPE checked, which allows C2 to speculate >>>>> more and hoist. With these changes _all_ segment types have >>>>> comparable performances and hoisting guarantees (unlike in the old >>>>> implementation). >>>>> >>>>> * Add workarounds in MemoryAddressProxy, AbstractMemorySegmentImpl >>>>> to special case "small segments" so that VM can apply bound check >>>>> elimination >>>>> >>>>> This is another important piece which allows to get very good >>>>> performances out of indexes memory access var handles; as you >>>>> might know, the JIT compiler has troubles in optimizing loops >>>>> where the loop variable is a long [2]. To make up for that, in >>>>> this round we add an optimization which allows the API to detect >>>>> whether a segment is *small* or *large*. For small segments, the >>>>> API realizes that there's no need to perform long computation >>>>> (e.g. to perform bound checks, or offset additions), so it falls >>>>> back to integer logic, which in turns allows bound check elimination. >>>>> >>>>> * renaming of the various var handle classes to conform to "memory >>>>> access var handle" terminology >>>>> >>>>> This is mostly stylistic, nothing to see here. >>>>> >>>>> Tests changes >>>>> ============= >>>>> >>>>> In addition to the tests for the new API changes, we've also added >>>>> some stress tests for var handle combinators - e.g. there's a flag >>>>> that can be enabled which turns on some "dummy" var handle >>>>> adaptations on all var handles created by the runtime. We've used >>>>> this flag on existing tests to make sure that things work as >>>>> expected. >>>>> >>>>> To sanity test the new memory segment spliterator, we have wired >>>>> the new segment spliterator with the existing spliterator test >>>>> harness. >>>>> >>>>> We have also added several micro benchmarks for the memory segment >>>>> API (and made some changes to the build script so that native >>>>> libraries would be handled correctly). >>>>> >>>>> >>>>> [1] - >>>>> https://docs.oracle.com/en/java/javase/14/docs/specs/jni/functions.html#newdirectbytebuffer >>>>> [2] - https://bugs.openjdk.java.net/browse/JDK-8223051 >>>>> [3] - https://openjdk.java.net/jeps/383 >>>>> [4] - >>>>> https://docs.scipy.org/doc/numpy/reference/generated/numpy.reshape.html#numpy.reshape >>>>> >>>>> From claes.redestad at oracle.com Mon May 25 10:02:31 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 25 May 2020 12:02:31 +0200 Subject: RFR: 8245677: Optimize lookups in empty HashMap Message-ID: Hi, sponsoring this patch from Christoph Dreis. By pushing down the hash calculation we can optimize lookups in empty HashMaps (also helps LinkedHashMap). Bug: https://bugs.openjdk.java.net/browse/JDK-8245677 Webrev: http://cr.openjdk.java.net/~redestad/8245677/open.00/ Testing: tier1+2 Original report: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066530.html /Claes From claes.redestad at oracle.com Mon May 25 10:03:46 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 25 May 2020 12:03:46 +0200 Subject: RFR: 8245678: Avoid allocations in Executable.getAllGenericParameterTypes Message-ID: <2f2d4ac1-a353-3e0f-8796-d204ba2fe703@oracle.com> Hi, sponsoring this patch from Christoph Dreis. Refactor Executable.getAllGenericParameterTypes to avoid allocations in some cases. Bug: https://bugs.openjdk.java.net/browse/JDK-8245678 Webrev: http://cr.openjdk.java.net/~redestad/8245678/open.00/ Testing: tier1+2 Original report: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066634.html /Claes From maurizio.cimadamore at oracle.com Mon May 25 10:37:52 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 25 May 2020 11:37:52 +0100 Subject: RFR: JDK-8227046: compiler implementation for sealed classes, JDK-8227047: Javadoc for sealed types and JDK-8227044: javax.lang.model for sealed classes In-Reply-To: References: <3bd27bea-b8a3-88a2-5536-ea9610749ce4@oracle.com> <11f8828c-607e-e844-1ac6-5977a40c9a77@oracle.com> Message-ID: Hi, changes look good, but the parser changes do not convince me. Now that the logic is more clearly defined, I see some issues e.g. there seems to be a tight coupling by where "sealed" or "non-sealed" is, and the fact that the following token must be e.g. "class". This is unlike other modifiers which can in fact appear in any configuation. I believe that you can break the current logic by adding an extra annotation between the "sealed" token and the "class" token e.g. sealed @foo class Bar { } But maybe the quick fix would be to add MONKEY_AT to the set of expected tokens after sealed/non-sealed. Maurizio On 22/05/2020 19:25, Vicente Romero wrote: > Hi, > > Thanks Jan and Maurizio for the reviews. I have created another > iteration that I hope addresses all of the comments. I recognize that > dealing with `sealed`, `non-sealed` is the most complicated part as > there is no guide right now from the spec. So I have tried to make > them contextual keywords, for some informal definition of the concept, > I think that with more success for the `sealed` case. So going in more > detail this iteration includes: > > ?- ClassTree::getPermitsClause now returns `List.of()` > ?- Types::findDescriptorInternal has been modified to fail on sealed > interfaces > ?- several error messages have been updated as suggested, on this > front given that when a class list the same interface twice in the > implements clause, the second occurrence is the one flagged, I did the > same for repeated names in the permits clause > ?- modifications in ClassReader and ClassWriter as suggested > ?- JavacParser, the bulk of the changes are concentrated here, as > mentioned above the goal has been to try to implement the contextual > keyword thing and also give a nice error message in several corner > case situations detected in the reviews > ?- more tests were added > > Thanks, > Vicente > > On 5/21/20 8:14 AM, Maurizio Cimadamore wrote: >> Hi Vicente, >> looks very good. Some comments below. >> >> * the parser logic is clever in its use of position to apply >> context-dependent keyword detection; as Jan says, perhaps just share >> the code so that the position checks are not repeated. >> >> * I found one very edge-case quirk in the context-dependent logic; >> not sure how we wanna address: >> >> class Foo { >> ??? sealed m() {} >> } >> >> This fails with: >> >> Error: invalid method declaration; return type required >> >> As javac parses non-sealed as a modifier, and then expects a type. I >> think this is probably reasonable, but it's not as context-dependent >> as it could be I guess. >> >> * This case: >> >> class Bar { } >> sealed @interface Foo permits Bar >> >> Fails as expected, but only because Bar doesn't extends Foo. I >> believe we'd like to ban sealed on annotations more eagerly. Same for >> non-sealed. For enums and records (which are non-extensible) the >> compiler does the right thing and tells me that I can't just use >> sealed/non-sealed there. >> >> * The recovery logic in case preview features aren't enabled leaves >> something to be desired. For instance, if I compile this w/o >> --enable-preview: >> >> ?record Foo() {} >> >> I get a very sensible error: >> >> records are a preview feature and are disabled by default. >> ??? (use --enable-preview to enable records) >> >> However, if I compiler this w/o --enable-preview: >> >> sealed class Foo {} >> >> I get this: >> >> error: class, interface, or enum expected >> >> (no mention of preview features) >> >> It gets worse if I also specify a `permits`. >> >> * As Jan mentioned, type parameters on permitted types should be >> banned, not silently cleared in TypeEnter >> >> * Overall the type enter logic seems robust - I've tried several >> examples swapping superclass/subclass - using references to nested >> classes in supertype declaration, and it all works. Well done. >> >> * The error for lambda expressions leaves to be desired: >> >> sealed interface Action { >> ?void doAction(); >> } >> >> class Test { >> ? Action a = () -> { }; >> } >> >> Foo.java:6: error: class is not allowed to extend sealed class: Action >> ? Action a = () -> { }; >> ???????????? ^ >> >> I think a dedicated error here would be useful. >> >> >> * the same check is not applied to method references: >> >> >> class Test { >> >> ? Action a2 = Test::m; //no error >> >> ? static void m() { } >> } >> >> More generally, if a functional interface cannot be sealed, I think >> it would be better to inject the check in the functional interface >> check (e.g. Types::findDescriptorInternal) so that you won't need any >> extra code in Attr. This would also be more in spirit with the spec, >> where the non-sealedness check is defined in 9.8, not in section 15. >> >> * Pulling more on that string, the @FunctionalInterface annotation >> can be placed on a sealed interface and no error is issued >> >> * On ClassWriter - isn't calling adjustFlags() enough? That will >> truncate the long flags into an int - I think Flags.SEALED is bigger >> than that? >> >> >> // error messages >> >> * DuplicateTypesInPermits >> >> I suggest: >> >> test/langtools/tools/javac/diags/examples/DuplicateTypeInPermits.java:30: >> error: invalid permits clause >> sealed class Sealed permits Sub, Sub {} >> ??????????????????????????? ^ >> ? (repeated type: Sub) >> >> [this is consistent with the error we issues in other places - e.g. >> when you implements same interface twice] >> >> * NonSealedWithNoSealedSuper >> >> test/langtools/tools/javac/diags/examples/NonSealedWithNoSealedSuper.java:31: >> error: non-sealed modifier not allowed here >> non-sealed class Sub extends C {} >> ?????????? ^ >> ? (class must have a sealed superclasses) >> >> I suggest to replace the details message with something like this: >> >> (class C does not have any sealed supertypes) >> >> [since I expect this message to be applicable also for superinterfaces] >> >> * PermitsCantListDeclaringClass >> >> test/langtools/tools/javac/diags/examples/PermitsCantListDeclaringClass.java:30: >> error: invalid permits clause >> sealed class C permits C {} >> ?????????????????????? ^ >> ? (must not include the declaring class: C) >> >> Here I recommend something like: >> >> (illegal self-reference in permits clause) >> >> * PermitsCantListSuperType >> >> test/langtools/tools/javac/diags/examples/PermitsCantListSuperType.java:32: >> error: invalid permits clause >> sealed class C implements I permits I {} >> ??????????????????????????????????? ^ >> ? (must not include a supertype: I) >> >> I suggest: >> >> (illegal reference to supertype I) >> >> * PermitsInNoSealedClass >> >> test/langtools/tools/javac/diags/examples/PermitsInNoSealedClass.java:30: >> error: invalid permits clause >> class C permits Sub {} >> ??????? ^ >> ? (class must be sealed) >> >> This is good, but I noted that if you change the test to use an >> interface, the message still says "class" - the kindname should be >> used here. >> >> * SealedMustHaveSubtypes >> >> test/langtools/tools/javac/diags/examples/SealedMustHaveSubtypes.java:29: >> error: sealed class must have subclasses >> sealed class Sealed {} >> ?????? ^ >> >> I think this message reflects one of the main issues with the general >> type vs. class dichotomy. A subclass, in JLS lingo is e.g. `B` where >> `B extends A`. Interfaces do not play in the mix - they are not >> considered subclasses. The word subtypes could be more general - but >> again, it is a bit imprecise, since we're talking about declarations >> here, not types. I'll defer this conundrum to our spec gurus :-) >> >> >> Cheers >> Maurizio >> >> >> >> On 18/05/2020 23:42, Vicente Romero wrote: >>> Hi, >>> >>> Please review this patch for the compiler, javadoc and >>> javax.lang.model support for the JEP 360 Sealed Classes (Preview). >>> The changes are provided at [1], which implements the latest JLS for >>> sealed types [2]. The patch also include the needed changes to >>> javadoc and javax.lang.model to support sealed types. The CSR witht >>> the changes in the javax.lang.model spec is at [3]. The sealed types >>> JEP is accessible at [4]. There is an ongoing review for the VM and >>> core-libs code of sealed types [5] and that code hasn't been >>> included in this webrev, >>> >>> Thanks, >>> Vicente >>> >>> [1] http://cr.openjdk.java.net/~vromero/8227046/webrev.00/ >>> [2] >>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html >>> >>> [3] https://bugs.openjdk.java.net/browse/JDK-8244367 >>> [4] https://openjdk.java.net/jeps/360 >>> [5] >>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066440.html > From james.laskey at oracle.com Mon May 25 12:12:12 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 25 May 2020 09:12:12 -0300 Subject: RFR: 8245677: Optimize lookups in empty HashMap In-Reply-To: References: Message-ID: <62166198-221B-47FB-B528-26166F808D84@oracle.com> +1 (Copyright date) > On May 25, 2020, at 7:02 AM, Claes Redestad wrote: > > Hi, > > sponsoring this patch from Christoph Dreis. > > By pushing down the hash calculation we can optimize lookups > in empty HashMaps (also helps LinkedHashMap). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8245677 > Webrev: http://cr.openjdk.java.net/~redestad/8245677/open.00/ > > Testing: tier1+2 > > Original report: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066530.html > > /Claes From james.laskey at oracle.com Mon May 25 12:13:10 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Mon, 25 May 2020 09:13:10 -0300 Subject: RFR: 8245678: Avoid allocations in Executable.getAllGenericParameterTypes In-Reply-To: <2f2d4ac1-a353-3e0f-8796-d204ba2fe703@oracle.com> References: <2f2d4ac1-a353-3e0f-8796-d204ba2fe703@oracle.com> Message-ID: <32044239-1386-49BA-8196-B1953FF22D93@oracle.com> +1 > On May 25, 2020, at 7:03 AM, Claes Redestad wrote: > > Hi, > > sponsoring this patch from Christoph Dreis. > > Refactor Executable.getAllGenericParameterTypes to avoid allocations > in some cases. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8245678 > Webrev: http://cr.openjdk.java.net/~redestad/8245678/open.00/ > > Testing: tier1+2 > > Original report: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066634.html > > /Claes From claes.redestad at oracle.com Mon May 25 12:14:58 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 25 May 2020 14:14:58 +0200 Subject: RFR: 8245677: Optimize lookups in empty HashMap In-Reply-To: <62166198-221B-47FB-B528-26166F808D84@oracle.com> References: <62166198-221B-47FB-B528-26166F808D84@oracle.com> Message-ID: <0f5e5ebb-69ca-6683-d725-4c4e1b640a9b@oracle.com> Thanks for reviewing, Jim! /Claes On 2020-05-25 14:12, Jim Laskey wrote: > +1 > > (Copyright date) > >> On May 25, 2020, at 7:02 AM, Claes Redestad wrote: >> >> Hi, >> >> sponsoring this patch from Christoph Dreis. >> >> By pushing down the hash calculation we can optimize lookups >> in empty HashMaps (also helps LinkedHashMap). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8245677 >> Webrev: http://cr.openjdk.java.net/~redestad/8245677/open.00/ >> >> Testing: tier1+2 >> >> Original report: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066530.html >> >> /Claes > From claes.redestad at oracle.com Mon May 25 12:15:19 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 25 May 2020 14:15:19 +0200 Subject: RFR: 8245678: Avoid allocations in Executable.getAllGenericParameterTypes In-Reply-To: <32044239-1386-49BA-8196-B1953FF22D93@oracle.com> References: <2f2d4ac1-a353-3e0f-8796-d204ba2fe703@oracle.com> <32044239-1386-49BA-8196-B1953FF22D93@oracle.com> Message-ID: <4fc6f9cd-2e91-6e43-39a6-5aa01afa7f40@oracle.com> Thanks for reviewing, Jim! /Claes On 2020-05-25 14:13, Jim Laskey wrote: > +1 > > >> On May 25, 2020, at 7:03 AM, Claes Redestad wrote: >> >> Hi, >> >> sponsoring this patch from Christoph Dreis. >> >> Refactor Executable.getAllGenericParameterTypes to avoid allocations >> in some cases. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8245678 >> Webrev: http://cr.openjdk.java.net/~redestad/8245678/open.00/ >> >> Testing: tier1+2 >> >> Original report: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066634.html >> >> /Claes > From shade at redhat.com Mon May 25 12:38:07 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 May 2020 14:38:07 +0200 Subject: RFR (XS) 8245722: 32-bit build failures after JDK-8243491 Message-ID: <493e7732-cdd1-d649-6f49-fde7bbff17c2@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8245722 This is similar to JDK-8236634, and fix takes the same form: diff -r d52c2e540934 test/jdk/java/foreign/libNativeAccess.c --- a/test/jdk/java/foreign/libNativeAccess.c Mon May 25 12:03:30 2020 +0200 +++ b/test/jdk/java/foreign/libNativeAccess.c Mon May 25 14:25:49 2020 +0200 @@ -116,12 +116,12 @@ return (*env)->GetDirectBufferCapacity(env, buf); } JNIEXPORT jlong JNICALL Java_TestNative_allocate(JNIEnv *env, jclass cls, jint size) { - return (jlong)malloc(size); + return (jlong)(uintptr_t)malloc(size); } JNIEXPORT void JNICALL Java_TestNative_free(JNIEnv *env, jclass cls, jlong ptr) { - free((void*) ptr); + free((void*)(uintptr_t)ptr); } Testing: {x86_32, x86_64} builds, jdk-submit (running) -- Thanks, -Aleksey From shade at redhat.com Mon May 25 14:08:10 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 May 2020 16:08:10 +0200 Subject: RFR (XS) 8245722: 32-bit build failures after JDK-8243491 In-Reply-To: <493e7732-cdd1-d649-6f49-fde7bbff17c2@redhat.com> References: <493e7732-cdd1-d649-6f49-fde7bbff17c2@redhat.com> Message-ID: On 5/25/20 2:38 PM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8245722 > > This is similar to JDK-8236634, and fix takes the same form: > > diff -r d52c2e540934 test/jdk/java/foreign/libNativeAccess.c > --- a/test/jdk/java/foreign/libNativeAccess.c Mon May 25 12:03:30 2020 +0200 > +++ b/test/jdk/java/foreign/libNativeAccess.c Mon May 25 14:25:49 2020 +0200 > @@ -116,12 +116,12 @@ > return (*env)->GetDirectBufferCapacity(env, buf); > } > > JNIEXPORT jlong JNICALL > Java_TestNative_allocate(JNIEnv *env, jclass cls, jint size) { > - return (jlong)malloc(size); > + return (jlong)(uintptr_t)malloc(size); > } > > JNIEXPORT void JNICALL > Java_TestNative_free(JNIEnv *env, jclass cls, jlong ptr) { > - free((void*) ptr); > + free((void*)(uintptr_t)ptr); > } > > Testing: {x86_32, x86_64} builds, jdk-submit (running) jdk-submit run is clean. -- Thanks, -Aleksey From thomas.stuefe at gmail.com Mon May 25 14:13:09 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 25 May 2020 16:13:09 +0200 Subject: RFR (XS) 8245722: 32-bit build failures after JDK-8243491 In-Reply-To: References: <493e7732-cdd1-d649-6f49-fde7bbff17c2@redhat.com> Message-ID: Seems fine and trivial. ..Thomas On Mon 25. May 2020 at 16:09, Aleksey Shipilev wrote: > On 5/25/20 2:38 PM, Aleksey Shipilev wrote: > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8245722 > > > > This is similar to JDK-8236634, and fix takes the same form: > > > > diff -r d52c2e540934 test/jdk/java/foreign/libNativeAccess.c > > --- a/test/jdk/java/foreign/libNativeAccess.c Mon May 25 12:03:30 2020 > +0200 > > +++ b/test/jdk/java/foreign/libNativeAccess.c Mon May 25 14:25:49 2020 > +0200 > > @@ -116,12 +116,12 @@ > > return (*env)->GetDirectBufferCapacity(env, buf); > > } > > > > JNIEXPORT jlong JNICALL > > Java_TestNative_allocate(JNIEnv *env, jclass cls, jint size) { > > - return (jlong)malloc(size); > > + return (jlong)(uintptr_t)malloc(size); > > } > > > > JNIEXPORT void JNICALL > > Java_TestNative_free(JNIEnv *env, jclass cls, jlong ptr) { > > - free((void*) ptr); > > + free((void*)(uintptr_t)ptr); > > } > > > > Testing: {x86_32, x86_64} builds, jdk-submit (running) > > jdk-submit run is clean. > > -- > Thanks, > -Aleksey > > From alexey.semenyuk at oracle.com Mon May 25 15:14:11 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Mon, 25 May 2020 11:14:11 -0400 Subject: RFR: 8242786: [macos] tools/jpackage/share/IconTest.java fails: ABORT trying to dequeue work In-Reply-To: <37a07ed3-5520-2d17-7a0f-5c4a959279e7@oracle.com> References: <37a07ed3-5520-2d17-7a0f-5c4a959279e7@oracle.com> Message-ID: <4a38202d-4e38-359b-f8a2-a107beafa2f0@oracle.com> Looks good. - Alexey On 5/24/2020 5:53 PM, Andy Herrick wrote: > looks good > > /Andy > > On 5/22/2020 7:33 PM, alexander.matveev at oracle.com wrote: >> Please review the jpackage fix for bug [1] at [2]. >> >> - Detach fails sometimes due to disk image being busy. Not sure what >> keeps disk image busy. Probably antivirus or something else. Within >> short period of time disk image can be detach. So, fix is just re-try >> detach if it did not work right away. With proposed fix I was not >> able to reproduce this issue again. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8242786 >> >> [2] http://cr.openjdk.java.net/~almatvee/8242786/webrev.00/ >> >> Thanks, >> Alexander From alexey at azul.com Mon May 25 15:33:33 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Mon, 25 May 2020 15:33:33 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> Message-ID: <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> Hello Michael, Thomas, Thank you a lot for review and suggestions. I?ve fixed most of the issues except of fundamental one I need more time to evaluate suggested usage of UnspecEmptyInetAddress subtype. Updated webrev is available at: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v1/ Also, please see my comments below. Regards Alexey > On 24 May 2020, at 02:38, Michael Osipov <1983-01-06 at gmx.net> wrote: > > Am 2020-05-21 um 09:35 schrieb Alexey Bakhtin: >> Hello, >> >> Could you please review the following patch: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 >> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ > > Let's go through your changes statically: > > * The JIRA issue title has a typo Thank you. Fixed in Jira > * The word "cannot" is incorrectly spelled throughout all exception messages Fixed from ?can not? to ?cannot" > >> + if (cbTypeProp.equals(TlsChannelBindingType.TLS_UNIQUE.getName())) { >> + throw new UnsupportedOperationException("LdapCtx: " + >> + TlsChannelBindingType.TLS_UNIQUE.getName() + " type is not supported"); > > > "LdapCtx: " is redundant because the stacktrace will contain the class > name already. A better message would be: "Channel binding type '%s' is > not supported". Not just the plain value. Exception message is corrected > >> + } else if (cbTypeProp.equals(TlsChannelBindingType.TLS_SERVER_END_POINT.getName())) { >> + if (connectTimeout == -1) >> + throw new IllegalArgumentException(CHANNEL_BINDING_TYPE + " property requires " + >> + CONNECT_TIMEOUT + " property is set."); > > * Same here with the message Not sure, What?s wrong with the message ? > * The IAE is wrong because passed value is correct, but leads to an > invalid state because connection timeout is -1. You need an > IllegalStateException here. Thank you. You are right again. Changed to IllegalStateException > > Stupid question: how can one create a GSS security context when the TLS > security context has not been established yet? This logic already existed here. It could be a reason for it and I don?t want change it without strong purpose. The only changes here is to prevent double setting of channel binding data. > >> --- old/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java 2020-05-18 19:39:46.000000000 +0300 >> +++ new/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java 2020-05-18 19:39:46.000000000 +0300 >> @@ -531,9 +531,12 @@ >> public void setChannelBinding(ChannelBinding channelBindings) >> throws GSSException { >> >> - if (mechCtxt == null) >> + if (mechCtxt == null) { >> + if (this.channelBindings != null) { >> + throw new GSSException(GSSException.BAD_BINDINGS); >> + } >> this.channelBindings = channelBindings; >> - >> + } >> } > > I don't understand the purpose of this hunk. Is this safeguard to set > bindings only once? > >> private static final int CHANNEL_BINDING_AF_INET = 2; >> private static final int CHANNEL_BINDING_AF_INET6 = 24; >> private static final int CHANNEL_BINDING_AF_NULL_ADDR = 255; >> + private static final int CHANNEL_BINDING_AF_UNSPEC = 0; > > This should sort from 0 to 255 and not at the end. OK. Moved to the top. > >> private int getAddrType(InetAddress addr) { >> - int addressType = CHANNEL_BINDING_AF_NULL_ADDR; >> + int addressType = CHANNEL_BINDING_AF_UNSPEC; > >> // initialize addrtype in CB first >> - cb->initiator_addrtype = GSS_C_AF_NULLADDR; >> - cb->acceptor_addrtype = GSS_C_AF_NULLADDR; >> + cb->initiator_addrtype = GSS_C_AF_UNSPEC; >> + cb->acceptor_addrtype = GSS_C_AF_UNSPEC; > > This looks wrong to me -- as you already mentioned -- this violates RFC > 2744, section 3.11, last sentence: >> or omit addressing information, specifying >> GSS_C_AF_NULLADDR as the address-types. > >> /* release initiator address */ >> - if (cb->initiator_addrtype != GSS_C_AF_NULLADDR) { >> + if (cb->initiator_addrtype != GSS_C_AF_NULLADDR && >> + cb->initiator_addrtype != GSS_C_AF_UNSPEC) { >> resetGSSBuffer(&(cb->initiator_address)); >> } >> /* release acceptor address */ >> - if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR) { >> + if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR && >> + cb->acceptor_addrtype != GSS_C_AF_UNSPEC) { >> resetGSSBuffer(&(cb->acceptor_address)); >> } > > Unspecified does not mean that it is null. > >> + final byte[] prefix = (TlsChannelBindingType.TLS_SERVER_END_POINT.getName() + ":").getBytes(); >> + byte[] cbData = Arrays.copyOf(prefix, >> + prefix.length + tlsCB.getData().length ); >> + System.arraycopy(tlsCB.getData(), 0, cbData, prefix.length, tlsCB.getData().length); > > Since you are calling "tlsCB.getData()" multiple times, this should go > into a variable. Temporary variable is added > > >> + secCtx.setChannelBinding(new > ChannelBinding(null, null, cbData)); > > Why not use new ChannelBinding(cbData)? Right. updated > >> + String hashAlg = serverCertificate.getSigAlgName(). >> + replace("SHA", "SHA-").toUpperCase(); >> + int ind = hashAlg.indexOf("WITH"); >> + if (ind > 0) { >> + hashAlg = hashAlg.substring(0, ind); >> + if (hashAlg.equals("MD5") || hashAlg.equals("SHA-1")) { >> + hashAlg = "SHA-256"; >> + } > > I have several problems with that, some might be hypothetical: > > * toUpperCase() should be qualified with Locale.ROOT or Locate.ENGLISH As you mentioned below AlgorithmId.getName() uses nameTable to return algorithm name. Looking at implementation I do not think it is realistic to get name in the non-English locale. I do not think it should be fixed > * Looking at https://tools.ietf.org/html/rfc5280#section-4.1.1.2, then > at sun.security.x509.AlgorithmId.getName() it uses nameTable to > translate OIDs to readible names. > > With indexOf("WITH") you are implying that the cert's sig alg may not > use a cryptographic function, but this would mean that if the OID is > 1.3.14.3.2.26 you'd turn "SHA-X" into "SHA--X" according to nameTable, > wouldn't you? > I also don't know how realistic "PBEWith..." is. > > This likely needs more thought or I am missing something. > I do not think it is realistic scenario to have certificate signature algorithm without crypto function. indexOf(?WITH?) just used to find end out hash algorithm name. > * Exception messages are inconsistent. Sometimes "TLS channel binding", > sometimes just "channel binding". To avoid misunderstandings it should > always read "TLS channel binding..". > Messages are updated. > Generally, I have two fundemental issues: > * How do you know that address type must be UNSPEC and not NULLADDR? > Trial and error? I did not find any strict specification about TLS Channel Binding format in Windows server. So, it was a lot of experiments, reading related forums and docs. One of the doc, that turns me to try UNSPEC type is the following: https://docs.microsoft.com/en-us/archive/blogs/openspecification/ntlm-and-channel-binding-hash-aka-extended-protection-for-authentication > * Changing the default address type against the RFC will break every > installation using channel bindings relying on it with cross GSS-API > implementations. I do not like this conflict between UNSPEC and NULLADDR types too, but I do not know How to better solve it. The usage of UnspecEmptyInetAddress subtype is not quite clear to me yet. Who set this value and will it change org.ietf.jgss.ChannelBinding public api ? As I understand, Implementation cannot decide (without pplication request), What channel binding type is enabled on the server. > > There must be another way to solve this. A system property would also be > problematic because if you have a product which connects to MS and > non-MS backends at the same time, channel bindings would be broken again. > > What about introducing a UnspecEmptyInetAddress() which gives the proper > AF type, but #getAddress() would return null? This should satisfy the > requirements, InitialToken as well as the RFC. this of course needs to > be properly passed to native providers too. GssKrb5Client would also > need to know that this channel binding is explicitly for Active > Directory and not some other, spec-compliant, SASL peer (property on > LdapCtx?) > > One could easily use this for custom code with a SSLServerSocket paired > with Java SASL or in C, OpenSSL and Cyrus SASL. > > Michael > > PS: Yes, I am a nitpicker. From raffaello.giulietti at gmail.com Mon May 25 15:46:00 2020 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 25 May 2020 17:46:00 +0200 Subject: REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results Message-ID: <15fdab50-21d3-44b1-2d06-a8bc6ed7fa46@gmail.com> Hi, afaik, review of [1] (webrev in [2]) didn't progress in the meantime. I'm very well aware that a full review requires some time (see [3] for my estimates), depending on your familiarity in working out the maths in [4] (*no* numerics, *no* floating-point arithmetic, promised!). Yet, the associated CSR [5] can be reviewed independently of the proposed algorithm and implementation. It is in "finalized" status since 2019-06-03 and requires a last push to be "approved" (15-30 minutes of concentrated work). The CSR strives to be a rigorous spec that leaves no leeway for ambiguities in the outcomes. Would be nice if it could make it for Rampdown 1 of JDK 15 (2020-06-11). Greetings Raffaello ---- [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065291.html [2] http://cr.openjdk.java.net/~bpb/4511638/webrev.04/ [3] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/066160.html [4] https://drive.google.com/open?id=1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN [5] https://bugs.openjdk.java.net/browse/JDK-8202555 From raffaello.giulietti at gmail.com Mon May 25 16:24:08 2020 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Mon, 25 May 2020 18:24:08 +0200 Subject: contributing to JDK-8171407: Port fdlibm to Java, part 2 Message-ID: <72b9f763-2647-b59a-9b42-22eca48d7706@gmail.com> Hi, [1] enumerates 14 StrictMath native functions that still need a Java porting from the original C code. As of changeset b84f122ea855 all of them are still native, so I wonder if it makes sense to contribute or if they have already been ported and on the launch pad for integration. Let me know. Greetings Raffaello ---- [1] https://bugs.openjdk.java.net/browse/JDK-8171407 From shade at redhat.com Mon May 25 16:51:23 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 May 2020 18:51:23 +0200 Subject: RFR (XS) 8245722: 32-bit build failures after JDK-8243491 In-Reply-To: References: <493e7732-cdd1-d649-6f49-fde7bbff17c2@redhat.com> Message-ID: <1435303e-91b2-b1a4-1986-b8f5c08b1bff@redhat.com> Thanks! Maurizio, want to ack this too? -Aleksey On 5/25/20 4:13 PM, Thomas St?fe wrote: > Seems fine and trivial. > > ..Thomas? > > On Mon 25. May 2020 at 16:09, Aleksey Shipilev > wrote: > > On 5/25/20 2:38 PM, Aleksey Shipilev wrote: > > Bug: > >? ?https://bugs.openjdk.java.net/browse/JDK-8245722 > > > > This is similar to JDK-8236634, and fix takes the same form: > > > > diff -r d52c2e540934 test/jdk/java/foreign/libNativeAccess.c > > --- a/test/jdk/java/foreign/libNativeAccess.c? ?Mon May 25 12:03:30 2020 +0200 > > +++ b/test/jdk/java/foreign/libNativeAccess.c? ?Mon May 25 14:25:49 2020 +0200 > > @@ -116,12 +116,12 @@ > >? ? ? return (*env)->GetDirectBufferCapacity(env, buf); > >? } > > > >? JNIEXPORT jlong JNICALL > >? Java_TestNative_allocate(JNIEnv *env, jclass cls, jint size) { > > -? ? return (jlong)malloc(size); > > +? ? return (jlong)(uintptr_t)malloc(size); > >? } > > > >? JNIEXPORT void JNICALL > >? Java_TestNative_free(JNIEnv *env, jclass cls, jlong ptr) { > > -? ? free((void*) ptr); > > +? ? free((void*)(uintptr_t)ptr); > >? } > > > > Testing: {x86_32, x86_64} builds, jdk-submit (running) > > jdk-submit run is clean. -- Thanks, -Aleksey From claes.redestad at oracle.com Mon May 25 20:23:23 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 25 May 2020 22:23:23 +0200 Subject: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers Message-ID: <3ee129e4-d0f3-96e9-9239-52194cb9e09c@oracle.com> Hi, let's improve the StringConcatFactory a bit! - prependers where both prefix and suffix is null are common in typical expressions; caching these specifically is profitable - current prepender argument ordering is unfortunate: String prefix, , String suffix. This means we have to do two back-to-back insertArguments rather than one if they were grouped together - add a bridge to the String mix function in StringConcatHelper to avoid method handle invokes in the bootstrap path. Webrev: http://cr.openjdk.java.net/~redestad/8245756/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8245756 All together I see a substantial improvement on a number of concatenation bootstrap tests. On one stress test[1] I get these numbers before: 4,257,229,918 instructions # 1.10 insn per cycle ( +- 0.84% ) 847,230,764 branches # 504.826 M/sec ( +- 0.87% ) 34,600,787 branch-misses # 4.08% of all branches ( +- 0.91% ) 0.319545331 seconds time elapsed ( +- 1.18% ) And after: 3,692,867,129 instructions # 1.10 insn per cycle ( +- 0.73% ) 734,054,515 branches # 498.753 M/sec ( +- 0.74% ) 30,699,692 branch-misses # 4.18% of all branches ( +- 0.75% ) 0.295842958 seconds time elapsed ( +- 1.10% ) So ~13% reduction on this test. Testing: tier1+2 Thanks! /Claes [1] http://cr.openjdk.java.net/~redestad/scratch/erase_scf_types.00/ObjStringCombos.java From forax at univ-mlv.fr Mon May 25 20:53:39 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 25 May 2020 22:53:39 +0200 (CEST) Subject: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers In-Reply-To: <3ee129e4-d0f3-96e9-9239-52194cb9e09c@oracle.com> References: <3ee129e4-d0f3-96e9-9239-52194cb9e09c@oracle.com> Message-ID: <1168727666.821877.1590440019689.JavaMail.zimbra@u-pem.fr> Hi Claes, do you have evaluated the improvement (1) in separation of the others ? (2) or (3) are clearly improvement but (1) is a trade of because you are adding a second lookup into another table and make prepender() less likely to be inlined. R?mi ----- Mail original ----- > De: "Claes Redestad" > ?: "core-libs-dev" > Envoy?: Lundi 25 Mai 2020 22:23:23 > Objet: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers > Hi, > > let's improve the StringConcatFactory a bit! > > - prependers where both prefix and suffix is null are common in typical > expressions; caching these specifically is profitable > > - current prepender argument ordering is unfortunate: String prefix, > , String suffix. This means we have to do two back-to-back > insertArguments rather than one if they were grouped together > > - add a bridge to the String mix function in StringConcatHelper to avoid > method handle invokes in the bootstrap path. > > Webrev: http://cr.openjdk.java.net/~redestad/8245756/open.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8245756 > > All together I see a substantial improvement on a number of > concatenation bootstrap tests. On one stress test[1] I get these numbers > before: > > 4,257,229,918 instructions # 1.10 insn per cycle ( +- 0.84% ) > 847,230,764 branches # 504.826 M/sec ( +- 0.87% ) > 34,600,787 branch-misses # 4.08% of all branches ( +- 0.91% ) > 0.319545331 seconds time elapsed ( +- 1.18% ) > > And after: > > 3,692,867,129 instructions # 1.10 insn per cycle ( +- 0.73% ) > 734,054,515 branches # 498.753 M/sec ( +- 0.74% ) > 30,699,692 branch-misses # 4.18% of all branches ( +- 0.75% ) > 0.295842958 seconds time elapsed ( +- 1.10% ) > > So ~13% reduction on this test. > > Testing: tier1+2 > > Thanks! > > /Claes > > [1] > http://cr.openjdk.java.net/~redestad/scratch/erase_scf_types.00/ObjStringCombos.java From claes.redestad at oracle.com Mon May 25 21:13:27 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 25 May 2020 23:13:27 +0200 Subject: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers In-Reply-To: <1168727666.821877.1590440019689.JavaMail.zimbra@u-pem.fr> References: <3ee129e4-d0f3-96e9-9239-52194cb9e09c@oracle.com> <1168727666.821877.1590440019689.JavaMail.zimbra@u-pem.fr> Message-ID: <6e9a8f0a-309c-09c9-c5f4-d47bdcd9c710@oracle.com> Hi R?mi, in isolation (1) was the bigger win on most of my tests. I can split the three improvements apart, if you prefer. Not sure in which sense you mean inlining? Few of the methods in the bootstrap code are likely hot enough to see inlining by a JIT - and the resulting MHs should be identical, just not constructed over and over again. /Claes On 2020-05-25 22:53, Remi Forax wrote: > Hi Claes, > do you have evaluated the improvement (1) in separation of the others ? > > (2) or (3) are clearly improvement but (1) is a trade of because you are adding a second lookup into another table and make prepender() less likely to be inlined. > > R?mi > > ----- Mail original ----- >> De: "Claes Redestad" >> ?: "core-libs-dev" >> Envoy?: Lundi 25 Mai 2020 22:23:23 >> Objet: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers > >> Hi, >> >> let's improve the StringConcatFactory a bit! >> >> - prependers where both prefix and suffix is null are common in typical >> expressions; caching these specifically is profitable >> >> - current prepender argument ordering is unfortunate: String prefix, >> , String suffix. This means we have to do two back-to-back >> insertArguments rather than one if they were grouped together >> >> - add a bridge to the String mix function in StringConcatHelper to avoid >> method handle invokes in the bootstrap path. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8245756/open.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8245756 >> >> All together I see a substantial improvement on a number of >> concatenation bootstrap tests. On one stress test[1] I get these numbers >> before: >> >> 4,257,229,918 instructions # 1.10 insn per cycle ( +- 0.84% ) >> 847,230,764 branches # 504.826 M/sec ( +- 0.87% ) >> 34,600,787 branch-misses # 4.08% of all branches ( +- 0.91% ) >> 0.319545331 seconds time elapsed ( +- 1.18% ) >> >> And after: >> >> 3,692,867,129 instructions # 1.10 insn per cycle ( +- 0.73% ) >> 734,054,515 branches # 498.753 M/sec ( +- 0.74% ) >> 30,699,692 branch-misses # 4.18% of all branches ( +- 0.75% ) >> 0.295842958 seconds time elapsed ( +- 1.10% ) >> >> So ~13% reduction on this test. >> >> Testing: tier1+2 >> >> Thanks! >> >> /Claes >> >> [1] >> http://cr.openjdk.java.net/~redestad/scratch/erase_scf_types.00/ObjStringCombos.java From christoph.dreis at freenet.de Mon May 25 21:13:48 2020 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Mon, 25 May 2020 23:13:48 +0200 Subject: Possible optimization in StringLatin1.regionMatchesCI Message-ID: Hi, I've recently looked through the StringLatin1 code - specifically regionMatchesCI. I think I have an optimization, but would need someone with more domain knowledge to verify if I'm missing nothing. Currently, the code does a conversion to uppercase and if that doesn't match it does an additional comparison of the lowercase characters. What's confusing to me is that there are actually both upper- and lowercase checks needed, but that might be explained by the comment in the UTF-16 version about the Georgian alphabet. Assuming that the additional lowercase check is needed, I was wondering if this must be on the uppercase variant. Wouldn't it be faster on the character itself to avoid potentially converting a lowercase character to an uppercase character and back? I think code is actually better explaining what I'm suggesting: --- a/src/java.base/share/classes/java/lang/StringLatin1.java Wed May 13 16:18:16 2020 +0200 +++ b/src/java.base/share/classes/java/lang/StringLatin1.java Mon May 25 22:59:13 2020 +0200 @@ -396,7 +396,7 @@ if (u1 == u2) { continue; } - if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) { + if (Character.toLowerCase(c1) == Character.toLowerCase(c2)) { continue; } return false; And indeed the newer version seems to be faster if I use the following benchmark: @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class MyBenchmark { @State(Scope.Benchmark) public static class ThreadState { private String test1 = "test"; private String test2 = "best"; } @Benchmark public boolean test(ThreadState threadState) { return threadState.test1.equalsIgnoreCase(threadState.test2); } } Benchmark Mode Cnt Score Error Units MyBenchmark.testOld avgt 10 8,843 ? 0,274 ns/op MyBenchmark.testPatched avgt 10 7,067 ? 0,177 ns/op Does this make sense? Do I miss something here? I would appreciate if someone can either explain the shortcomings of the solution above or - in case there aren't any - can maybe sponsor it. Cheers, Christoph From martinrb at google.com Mon May 25 22:18:56 2020 From: martinrb at google.com (Martin Buchholz) Date: Mon, 25 May 2020 15:18:56 -0700 Subject: Possible optimization in StringLatin1.regionMatchesCI In-Reply-To: References: Message-ID: Not a review, but: Compare with the variant of this code in StringUTF16. StringLatin1 only ever needs to support the first 256 chars in Unicode which can never change, unlike StringUTF16, Do all the String tests still pass if you simplify the code? Should CharacterDataLatin1 have a method to compare two characters case-insensitively? Be careful with Latin Small Letter sharp S On Mon, May 25, 2020 at 2:16 PM Christoph Dreis wrote: > > Hi, > > I've recently looked through the StringLatin1 code - specifically regionMatchesCI. > > I think I have an optimization, but would need someone with more domain knowledge to verify if I'm missing nothing. > > Currently, the code does a conversion to uppercase and if that doesn't match it does an additional comparison of the lowercase characters. > What's confusing to me is that there are actually both upper- and lowercase checks needed, but that might be explained by the comment in the UTF-16 version about the Georgian alphabet. > > Assuming that the additional lowercase check is needed, I was wondering if this must be on the uppercase variant. Wouldn't it be faster on the character itself to avoid potentially converting a lowercase character to an uppercase character and back? > > I think code is actually better explaining what I'm suggesting: > > --- a/src/java.base/share/classes/java/lang/StringLatin1.java Wed May 13 16:18:16 2020 +0200 > +++ b/src/java.base/share/classes/java/lang/StringLatin1.java Mon May 25 22:59:13 2020 +0200 > @@ -396,7 +396,7 @@ > if (u1 == u2) { > continue; > } > - if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) { > + if (Character.toLowerCase(c1) == Character.toLowerCase(c2)) { > continue; > } > return false; > > > And indeed the newer version seems to be faster if I use the following benchmark: > > @BenchmarkMode(Mode.AverageTime) > @OutputTimeUnit(TimeUnit.NANOSECONDS) > public class MyBenchmark { > > @State(Scope.Benchmark) > public static class ThreadState { > private String test1 = "test"; > private String test2 = "best"; > } > > @Benchmark > public boolean test(ThreadState threadState) { > return threadState.test1.equalsIgnoreCase(threadState.test2); > } > > } > > Benchmark Mode Cnt Score Error Units > MyBenchmark.testOld avgt 10 8,843 ? 0,274 ns/op > MyBenchmark.testPatched avgt 10 7,067 ? 0,177 ns/op > > Does this make sense? Do I miss something here? I would appreciate if someone can either explain the shortcomings of the solution above or - in case there aren't any - can maybe sponsor it. > > Cheers, > Christoph > > From forax at univ-mlv.fr Mon May 25 22:48:32 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 26 May 2020 00:48:32 +0200 (CEST) Subject: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers In-Reply-To: <6e9a8f0a-309c-09c9-c5f4-d47bdcd9c710@oracle.com> References: <3ee129e4-d0f3-96e9-9239-52194cb9e09c@oracle.com> <1168727666.821877.1590440019689.JavaMail.zimbra@u-pem.fr> <6e9a8f0a-309c-09c9-c5f4-d47bdcd9c710@oracle.com> Message-ID: <2035955824.845126.1590446912642.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Claes Redestad" > ?: "Remi Forax" > Cc: "core-libs-dev" > Envoy?: Lundi 25 Mai 2020 23:13:27 > Objet: Re: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers > Hi R?mi, > > in isolation (1) was the bigger win on most of my tests. I can split the > three improvements apart, if you prefer. no, i trust you, > > Not sure in which sense you mean inlining? Few of the methods in the > bootstrap code are likely hot enough to see inlining by a JIT - and the > resulting MHs should be identical, just not constructed over and over > again. I'm wondering if the code without the null tests was not simple enough to be inlined by c1, the MH creations tends to do a lot of checks that can be removed even by c1. > > /Claes R?mi > > On 2020-05-25 22:53, Remi Forax wrote: >> Hi Claes, >> do you have evaluated the improvement (1) in separation of the others ? >> >> (2) or (3) are clearly improvement but (1) is a trade of because you are adding >> a second lookup into another table and make prepender() less likely to be >> inlined. >> >> R?mi >> >> ----- Mail original ----- >>> De: "Claes Redestad" >>> ?: "core-libs-dev" >>> Envoy?: Lundi 25 Mai 2020 22:23:23 >>> Objet: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers >> >>> Hi, >>> >>> let's improve the StringConcatFactory a bit! >>> >>> - prependers where both prefix and suffix is null are common in typical >>> expressions; caching these specifically is profitable >>> >>> - current prepender argument ordering is unfortunate: String prefix, >>> , String suffix. This means we have to do two back-to-back >>> insertArguments rather than one if they were grouped together >>> >>> - add a bridge to the String mix function in StringConcatHelper to avoid >>> method handle invokes in the bootstrap path. >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8245756/open.00/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8245756 >>> >>> All together I see a substantial improvement on a number of >>> concatenation bootstrap tests. On one stress test[1] I get these numbers >>> before: >>> >>> 4,257,229,918 instructions # 1.10 insn per cycle ( +- 0.84% ) >>> 847,230,764 branches # 504.826 M/sec ( +- 0.87% ) >>> 34,600,787 branch-misses # 4.08% of all branches ( +- 0.91% ) >>> 0.319545331 seconds time elapsed ( +- 1.18% ) >>> >>> And after: >>> >>> 3,692,867,129 instructions # 1.10 insn per cycle ( +- 0.73% ) >>> 734,054,515 branches # 498.753 M/sec ( +- 0.74% ) >>> 30,699,692 branch-misses # 4.18% of all branches ( +- 0.75% ) >>> 0.295842958 seconds time elapsed ( +- 1.10% ) >>> >>> So ~13% reduction on this test. >>> >>> Testing: tier1+2 >>> >>> Thanks! >>> >>> /Claes >>> >>> [1] > >> http://cr.openjdk.java.net/~redestad/scratch/erase_scf_types.00/ObjStringCombos.java From vicente.romero at oracle.com Tue May 26 04:14:33 2020 From: vicente.romero at oracle.com (Vicente Romero) Date: Mon, 25 May 2020 21:14:33 -0700 (PDT) Subject: RFR: JDK-8227046: compiler implementation for sealed classes, JDK-8227047: Javadoc for sealed types and JDK-8227044: javax.lang.model for sealed classes In-Reply-To: References: <3bd27bea-b8a3-88a2-5536-ea9610749ce4@oracle.com> <11f8828c-607e-e844-1ac6-5977a40c9a77@oracle.com> Message-ID: Hi Maurizio, Right good catch I forgot to add the MONKEY_AT to the list of expected tokens. I have fixed that. I have published another iteration at [1]. Apart from the MONKEY_AT issue addressed at the parser this iteration also: ?- adds another error key to compiler.properties, this new key is oriented to show a more explicit error message when an interface with no `non-sealed` or `sealed` modifier extends a sealed interface. A class in this position can also be `final` but this is not possible for interfaces. ?- changes to PrintingProcessor and to test/langtools/tools/javac/processing/model/element/TestSealed.java suggested by Joe in this thread ?- adds a new subtest at SealedCompilationTests testing the sealed and non-sealed modifiers being followed by different modifiers or annotations ?- modified a subtest also at SealedCompilationTests, testPrinting, that was failing on Windows Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8227046/webrev.03.delta/ On 5/25/20 6:37 AM, Maurizio Cimadamore wrote: > Hi, > changes look good, but the parser changes do not convince me. Now that > the logic is more clearly defined, I see some issues e.g. there seems > to be a tight coupling by where "sealed" or "non-sealed" is, and the > fact that the following token must be e.g. "class". This is unlike > other modifiers which can in fact appear in any configuation. > > I believe that you can break the current logic by adding an extra > annotation between the "sealed" token and the "class" token e.g. > > sealed @foo class Bar { } > > But maybe the quick fix would be to add MONKEY_AT to the set of > expected tokens after sealed/non-sealed. > > Maurizio > > > On 22/05/2020 19:25, Vicente Romero wrote: >> Hi, >> >> Thanks Jan and Maurizio for the reviews. I have created another >> iteration that I hope addresses all of the comments. I recognize that >> dealing with `sealed`, `non-sealed` is the most complicated part as >> there is no guide right now from the spec. So I have tried to make >> them contextual keywords, for some informal definition of the >> concept, I think that with more success for the `sealed` case. So >> going in more detail this iteration includes: >> >> ?- ClassTree::getPermitsClause now returns `List.of()` >> ?- Types::findDescriptorInternal has been modified to fail on sealed >> interfaces >> ?- several error messages have been updated as suggested, on this >> front given that when a class list the same interface twice in the >> implements clause, the second occurrence is the one flagged, I did >> the same for repeated names in the permits clause >> ?- modifications in ClassReader and ClassWriter as suggested >> ?- JavacParser, the bulk of the changes are concentrated here, as >> mentioned above the goal has been to try to implement the contextual >> keyword thing and also give a nice error message in several corner >> case situations detected in the reviews >> ?- more tests were added >> >> Thanks, >> Vicente >> >> On 5/21/20 8:14 AM, Maurizio Cimadamore wrote: >>> Hi Vicente, >>> looks very good. Some comments below. >>> >>> * the parser logic is clever in its use of position to apply >>> context-dependent keyword detection; as Jan says, perhaps just share >>> the code so that the position checks are not repeated. >>> >>> * I found one very edge-case quirk in the context-dependent logic; >>> not sure how we wanna address: >>> >>> class Foo { >>> ??? sealed m() {} >>> } >>> >>> This fails with: >>> >>> Error: invalid method declaration; return type required >>> >>> As javac parses non-sealed as a modifier, and then expects a type. I >>> think this is probably reasonable, but it's not as context-dependent >>> as it could be I guess. >>> >>> * This case: >>> >>> class Bar { } >>> sealed @interface Foo permits Bar >>> >>> Fails as expected, but only because Bar doesn't extends Foo. I >>> believe we'd like to ban sealed on annotations more eagerly. Same >>> for non-sealed. For enums and records (which are non-extensible) the >>> compiler does the right thing and tells me that I can't just use >>> sealed/non-sealed there. >>> >>> * The recovery logic in case preview features aren't enabled leaves >>> something to be desired. For instance, if I compile this w/o >>> --enable-preview: >>> >>> ?record Foo() {} >>> >>> I get a very sensible error: >>> >>> records are a preview feature and are disabled by default. >>> ??? (use --enable-preview to enable records) >>> >>> However, if I compiler this w/o --enable-preview: >>> >>> sealed class Foo {} >>> >>> I get this: >>> >>> error: class, interface, or enum expected >>> >>> (no mention of preview features) >>> >>> It gets worse if I also specify a `permits`. >>> >>> * As Jan mentioned, type parameters on permitted types should be >>> banned, not silently cleared in TypeEnter >>> >>> * Overall the type enter logic seems robust - I've tried several >>> examples swapping superclass/subclass - using references to nested >>> classes in supertype declaration, and it all works. Well done. >>> >>> * The error for lambda expressions leaves to be desired: >>> >>> sealed interface Action { >>> ?void doAction(); >>> } >>> >>> class Test { >>> ? Action a = () -> { }; >>> } >>> >>> Foo.java:6: error: class is not allowed to extend sealed class: Action >>> ? Action a = () -> { }; >>> ???????????? ^ >>> >>> I think a dedicated error here would be useful. >>> >>> >>> * the same check is not applied to method references: >>> >>> >>> class Test { >>> >>> ? Action a2 = Test::m; //no error >>> >>> ? static void m() { } >>> } >>> >>> More generally, if a functional interface cannot be sealed, I think >>> it would be better to inject the check in the functional interface >>> check (e.g. Types::findDescriptorInternal) so that you won't need >>> any extra code in Attr. This would also be more in spirit with the >>> spec, where the non-sealedness check is defined in 9.8, not in >>> section 15. >>> >>> * Pulling more on that string, the @FunctionalInterface annotation >>> can be placed on a sealed interface and no error is issued >>> >>> * On ClassWriter - isn't calling adjustFlags() enough? That will >>> truncate the long flags into an int - I think Flags.SEALED is bigger >>> than that? >>> >>> >>> // error messages >>> >>> * DuplicateTypesInPermits >>> >>> I suggest: >>> >>> test/langtools/tools/javac/diags/examples/DuplicateTypeInPermits.java:30: >>> error: invalid permits clause >>> sealed class Sealed permits Sub, Sub {} >>> ??????????????????????????? ^ >>> ? (repeated type: Sub) >>> >>> [this is consistent with the error we issues in other places - e.g. >>> when you implements same interface twice] >>> >>> * NonSealedWithNoSealedSuper >>> >>> test/langtools/tools/javac/diags/examples/NonSealedWithNoSealedSuper.java:31: >>> error: non-sealed modifier not allowed here >>> non-sealed class Sub extends C {} >>> ?????????? ^ >>> ? (class must have a sealed superclasses) >>> >>> I suggest to replace the details message with something like this: >>> >>> (class C does not have any sealed supertypes) >>> >>> [since I expect this message to be applicable also for superinterfaces] >>> >>> * PermitsCantListDeclaringClass >>> >>> test/langtools/tools/javac/diags/examples/PermitsCantListDeclaringClass.java:30: >>> error: invalid permits clause >>> sealed class C permits C {} >>> ?????????????????????? ^ >>> ? (must not include the declaring class: C) >>> >>> Here I recommend something like: >>> >>> (illegal self-reference in permits clause) >>> >>> * PermitsCantListSuperType >>> >>> test/langtools/tools/javac/diags/examples/PermitsCantListSuperType.java:32: >>> error: invalid permits clause >>> sealed class C implements I permits I {} >>> ??????????????????????????????????? ^ >>> ? (must not include a supertype: I) >>> >>> I suggest: >>> >>> (illegal reference to supertype I) >>> >>> * PermitsInNoSealedClass >>> >>> test/langtools/tools/javac/diags/examples/PermitsInNoSealedClass.java:30: >>> error: invalid permits clause >>> class C permits Sub {} >>> ??????? ^ >>> ? (class must be sealed) >>> >>> This is good, but I noted that if you change the test to use an >>> interface, the message still says "class" - the kindname should be >>> used here. >>> >>> * SealedMustHaveSubtypes >>> >>> test/langtools/tools/javac/diags/examples/SealedMustHaveSubtypes.java:29: >>> error: sealed class must have subclasses >>> sealed class Sealed {} >>> ?????? ^ >>> >>> I think this message reflects one of the main issues with the >>> general type vs. class dichotomy. A subclass, in JLS lingo is e.g. >>> `B` where `B extends A`. Interfaces do not play in the mix - they >>> are not considered subclasses. The word subtypes could be more >>> general - but again, it is a bit imprecise, since we're talking >>> about declarations here, not types. I'll defer this conundrum to our >>> spec gurus :-) >>> >>> >>> Cheers >>> Maurizio >>> >>> >>> >>> On 18/05/2020 23:42, Vicente Romero wrote: >>>> Hi, >>>> >>>> Please review this patch for the compiler, javadoc and >>>> javax.lang.model support for the JEP 360 Sealed Classes (Preview). >>>> The changes are provided at [1], which implements the latest JLS >>>> for sealed types [2]. The patch also include the needed changes to >>>> javadoc and javax.lang.model to support sealed types. The CSR witht >>>> the changes in the javax.lang.model spec is at [3]. The sealed >>>> types JEP is accessible at [4]. There is an ongoing review for the >>>> VM and core-libs code of sealed types [5] and that code hasn't been >>>> included in this webrev, >>>> >>>> Thanks, >>>> Vicente >>>> >>>> [1] http://cr.openjdk.java.net/~vromero/8227046/webrev.00/ >>>> [2] >>>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html >>>> >>>> [3] https://bugs.openjdk.java.net/browse/JDK-8244367 >>>> [4] https://openjdk.java.net/jeps/360 >>>> [5] >>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066440.html >> From david.holmes at oracle.com Tue May 26 04:59:02 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 May 2020 14:59:02 +1000 Subject: RFR(S) 8242504: Enhance the system clock to nanosecond precision Message-ID: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8242504 webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ This work was contributed by Mark Kralj-Taylor: https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html On the hotspot side we change the Linux implementations of javaTimeMillis() and javaTimeSystemUTC() so that they use clock_gettime(CLOCK_REALTIME) instead of gettimeofday(). In keeping with our conditional use of this API I added a new guard os::Posix::supports_clock_gettime() and refined the existing supports_monotonic_clock() so that we can still use CLOCK_REALTIME if CLOCK_MONOTONIC does not exist. In the future (hopefully very near future) we will simply assume these APIs always exist. On the core-libs side the existing test: test/jdk/java/time/test/java/time/TestClock_System.java is adjusted to track the precision in more detail. Finally Mark has added instantNowAsEpochNanos() to the benchmark previously known as test/micro/org/openjdk/bench/java/lang/Systems.java which I've renamed to SystemTime.java as Mark suggested. I agree having these three functions measured together makes sense. Testing: - test/jdk/java/time/test/java/time/TestClock_System.java - test/micro/org/openjdk/bench/java/lang/SystemTime.java - Tiers 1-3 Thanks, David From shade at redhat.com Tue May 26 07:29:33 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 26 May 2020 09:29:33 +0200 Subject: RFR (XS) 8245722: 32-bit build failures after JDK-8243491 In-Reply-To: <1435303e-91b2-b1a4-1986-b8f5c08b1bff@redhat.com> References: <493e7732-cdd1-d649-6f49-fde7bbff17c2@redhat.com> <1435303e-91b2-b1a4-1986-b8f5c08b1bff@redhat.com> Message-ID: <62c65ad9-dbdc-9ba5-817c-a1dc7785a515@redhat.com> On 5/25/20 6:51 PM, Aleksey Shipilev wrote: > Thanks! > > Maurizio, want to ack this too? Nevermind, I pushed with Thomas' review and triviality rule. -- Thanks, -Aleksey From scolebourne at joda.org Tue May 26 08:14:32 2020 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 26 May 2020 09:14:32 +0100 Subject: RFR(S) 8242504: Enhance the system clock to nanosecond precision In-Reply-To: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> References: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> Message-ID: AFAICT a nanosecond clock is fine from a java.time.* API perspective. Stephen On Tue, 26 May 2020 at 06:01, David Holmes wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8242504 > webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ > > This work was contributed by Mark Kralj-Taylor: > > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html > > On the hotspot side we change the Linux implementations of > javaTimeMillis() and javaTimeSystemUTC() so that they use > clock_gettime(CLOCK_REALTIME) instead of gettimeofday(). In keeping with > our conditional use of this API I added a new guard > > os::Posix::supports_clock_gettime() > > and refined the existing supports_monotonic_clock() so that we can still > use CLOCK_REALTIME if CLOCK_MONOTONIC does not exist. In the future > (hopefully very near future) we will simply assume these APIs always exist. > > On the core-libs side the existing test: > > test/jdk/java/time/test/java/time/TestClock_System.java > > is adjusted to track the precision in more detail. > > Finally Mark has added instantNowAsEpochNanos() to the benchmark > previously known as > > test/micro/org/openjdk/bench/java/lang/Systems.java > > which I've renamed to SystemTime.java as Mark suggested. I agree having > these three functions measured together makes sense. > > Testing: > - test/jdk/java/time/test/java/time/TestClock_System.java > - test/micro/org/openjdk/bench/java/lang/SystemTime.java > - Tiers 1-3 > > Thanks, > David From aph at redhat.com Tue May 26 08:25:02 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 May 2020 09:25:02 +0100 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> Message-ID: <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> On 25/05/2020 09:26, Yang Zhang wrote: > In jdk master, what we need to do is that writing m4 file for existing > vector instructions and placed them to a new file aarch64_neon.ad. > If no question, I will do it right away. I'm not entirely sure that such a change is necessary now. In particular, reorganizing the existing vector instructions is IMO excessive, but I admit that it might be an improvement. But to my earlier question. please: can the new instructions be moved into jdk head first, and then merged into the Panama branch, or not? It'd help if this was possible. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vyommani at gmail.com Tue May 26 08:44:09 2020 From: vyommani at gmail.com (Vyom Tiwari) Date: Tue, 26 May 2020 14:14:09 +0530 Subject: RFR(S) 8242504: Enhance the system clock to nanosecond precision In-Reply-To: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> References: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> Message-ID: Hi David, we can remove the redundant local variable(jlong result) from if block as follows. return jlong(ts.tv_sec) * MILLIUNITS + jlong(ts.tv_nsec) / NANOUNITS_PER_MILLIUNIT; Vyom On Tue, May 26, 2020 at 10:29 AM David Holmes wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8242504 > webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ > > This work was contributed by Mark Kralj-Taylor: > > > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html > > On the hotspot side we change the Linux implementations of > javaTimeMillis() and javaTimeSystemUTC() so that they use > clock_gettime(CLOCK_REALTIME) instead of gettimeofday(). In keeping with > our conditional use of this API I added a new guard > > os::Posix::supports_clock_gettime() > > and refined the existing supports_monotonic_clock() so that we can still > use CLOCK_REALTIME if CLOCK_MONOTONIC does not exist. In the future > (hopefully very near future) we will simply assume these APIs always exist. > > On the core-libs side the existing test: > > test/jdk/java/time/test/java/time/TestClock_System.java > > is adjusted to track the precision in more detail. > > Finally Mark has added instantNowAsEpochNanos() to the benchmark > previously known as > > test/micro/org/openjdk/bench/java/lang/Systems.java > > which I've renamed to SystemTime.java as Mark suggested. I agree having > these three functions measured together makes sense. > > Testing: > - test/jdk/java/time/test/java/time/TestClock_System.java > - test/micro/org/openjdk/bench/java/lang/SystemTime.java > - Tiers 1-3 > > Thanks, > David > -- Thanks, Vyom From christoph.dreis at freenet.de Tue May 26 11:04:33 2020 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Tue, 26 May 2020 13:04:33 +0200 Subject: Possible optimization in StringLatin1.regionMatchesCI In-Reply-To: References: Message-ID: Hi Martin, ?> Not a review, but: > Compare with the variant of this code in StringUTF16. > StringLatin1 only ever needs to support the first 256 chars in Unicode Does it really? That makes me wonder even more about the additional lowercase check. > which can never change, unlike StringUTF16, What do you mean by "can never change"? > Do all the String tests still pass if you simplify the code? You mean if I remove the additional lowercasing completely!? --- a/src/java.base/share/classes/java/lang/StringLatin1.java Tue May 26 09:25:23 2020 +0200 +++ b/src/java.base/share/classes/java/lang/StringLatin1.java Tue May 26 13:01:14 2020 +0200 @@ -396,9 +396,6 @@ if (u1 == u2) { continue; } - if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) { - continue; - } return false; } return true; Tier1 seems to pass still (apart from some tests that don't seem to like my German setup - also without the change) > Should CharacterDataLatin1 have a method to compare two characters > case-insensitively? What do you mean by that? It needs to keep at least one check for the regionMatchesCI method. > Be careful with Latin Small Letter sharp S That seems to stay 223 regardless of uppercasing or lowercasing it. I'm afraid your answer raised more question marks than it actually solved. ;-) Cheers, Christoph >On Mon, May 25, 2020 at 2:16 PM Christoph Dreis > wrote: >> >> Hi, >> >> I've recently looked through the StringLatin1 code - specifically regionMatchesCI. >> >> I think I have an optimization, but would need someone with more domain knowledge to verify if I'm missing nothing. >> >> Currently, the code does a conversion to uppercase and if that doesn't match it does an additional comparison of the lowercase characters. >> What's confusing to me is that there are actually both upper- and lowercase checks needed, but that might be explained by the comment in the UTF-16 version about the Georgian alphabet. >> >> Assuming that the additional lowercase check is needed, I was wondering if this must be on the uppercase variant. Wouldn't it be faster on the character itself to avoid potentially converting a lowercase character to an uppercase character and back? >> >> I think code is actually better explaining what I'm suggesting: >> >> --- a/src/java.base/share/classes/java/lang/StringLatin1.java Wed May 13 16:18:16 2020 +0200 >> +++ b/src/java.base/share/classes/java/lang/StringLatin1.java Mon May 25 22:59:13 2020 +0200 >> @@ -396,7 +396,7 @@ >> if (u1 == u2) { >> continue; >> } >> - if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) { >> + if (Character.toLowerCase(c1) == Character.toLowerCase(c2)) { >> continue; >> } >> return false; >> >> >> And indeed the newer version seems to be faster if I use the following benchmark: >> >> @BenchmarkMode(Mode.AverageTime) >> @OutputTimeUnit(TimeUnit.NANOSECONDS) >> public class MyBenchmark { >> >> @State(Scope.Benchmark) >> public static class ThreadState { >> private String test1 = "test"; >> private String test2 = "best"; >> } >> >> @Benchmark >> public boolean test(ThreadState threadState) { >> return threadState.test1.equalsIgnoreCase(threadState.test2); >> } >> >> } >> >> Benchmark Mode Cnt Score Error Units >> MyBenchmark.testOld avgt 10 8,843 ? 0,274 ns/op >> MyBenchmark.testPatched avgt 10 7,067 ? 0,177 ns/op >> >> Does this make sense? Do I miss something here? I would appreciate if someone can either explain the shortcomings of the solution above or - in case there aren't any - can maybe sponsor it. >> >> Cheers, >> Christoph >> >> From andy.herrick at oracle.com Tue May 26 12:08:49 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 26 May 2020 08:08:49 -0400 Subject: RFR: JDK-8245202: Convert existing jpackage tests to newer form. Message-ID: <3127aec6-d764-d7f7-6cba-026d51734611@oracle.com> Please review the fix to issue [1] at [2]. The change removes all the old form helper tests and converts the 6 remaining tests that used the old helpers into 4 new tests using the new helpers. [1] - https://bugs.openjdk.java.net/browse/JDK-8245202 [2] - http://cr.openjdk.java.net/~herrick/8245202/webrev.01/ /Andy From alexey at azul.com Tue May 26 13:23:24 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 26 May 2020 13:23:24 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: <2F27D9CD-A15C-4946-976D-C522C39FB126@azul.com> Hi Michael, Thomas, Unfortunately we can not fix address type issue with the UnspecEmptyInetAddress subclass. We can not create subclass of InetAddress without changing public API. We can try similar approach but create subclass of ChannelBinding class instead. It is not so elegant like UnspecEmptyInetAddress approach but it could help to distinguish between TLS channel binding and Channel Bindings set by application. Later we can remove this workaround In case we prove that UNSPEC type should be used in all types of Channel Bindings. Updated webrev : http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v2/ Regards Alexey > On 26 May 2020, at 06:04, Thomas Maslen wrote: > > On Mon, May 25, 2020 at 3:15 AM Michael Osipov <1983-01-06 at gmx.net> wrote: > [...] > So I read the discussions. RFC 2744 shall not be changed, people > admitted that the spec of SASL GS2 mechs is wrong and should be changed, > but this has not happened yet. It remained at UNSPEC all the years. > > So we have several issues here: > * GSS-API C bindings and SASL requests are two distinct RFCs which > require/mandate differnt things. > * The change in JGSS in unrelated to this patch because GSS-API knows > nothing about SASL and its fauly spec. > > Since we are doing LDAP over SASL here and RFC 5801 requires to be > UNSPEC (0) the SASL TlsChannelBinding class must take that into account. > Unfortunately, JGSS implies with the args of the ChannelBinding the type > fo the adress. So will change my opinion a bit: > > No property for AD/non-AD is necessary, but handling of UNSPEC is > required. JGSS shall remain at NULLADDR. The subtype > UnspecEmptyInetAddress should be at least evaluated. > > Michael > > No. This isn't just about RFC 5801. As Alexey Bakhtin observed, this also applies to channel bindings for HTTP Negotiate Authentication (loosely aka "SPNEGO"), not only for NTLM (which probably isn't at issue here) but also for Kerberos -- that's where I first encountered this, working on a proprietary Java Kerberos implementation. > > More generally, if you want channel bindings to interoperate in the GSSAPI Kerberos Mechanism for any protocol -- SASL GS2, HTTP Negotiate Authentication, or anything else -- ignore the fact that RFC 2744 specifies 255 for the "no address" case and do what everyone actually does: use zero. > > Here is a test from MIT Kerberos that (implicitly) uses zero: https://github.com/krb5/krb5/blob/master/src/tests/gssapi/t_bindings.c > > And here is one from Heimdal: https://github.com/heimdal/heimdal/blob/5057d04f6a47f05f1ed7c617458722104d4c17dc/lib/gssapi/test_context.c From david.holmes at oracle.com Tue May 26 13:25:39 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 May 2020 23:25:39 +1000 Subject: RFR(S) 8242504: Enhance the system clock to nanosecond precision In-Reply-To: References: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> Message-ID: On 26/05/2020 6:14 pm, Stephen Colebourne wrote: > AFAICT a nanosecond clock is fine from a java.time.* API perspective. Thanks Stephen. Is this a review or just a nod of approval? :) Cheers, David ----- > Stephen > > On Tue, 26 May 2020 at 06:01, David Holmes wrote: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8242504 >> webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ >> >> This work was contributed by Mark Kralj-Taylor: >> >> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html >> >> On the hotspot side we change the Linux implementations of >> javaTimeMillis() and javaTimeSystemUTC() so that they use >> clock_gettime(CLOCK_REALTIME) instead of gettimeofday(). In keeping with >> our conditional use of this API I added a new guard >> >> os::Posix::supports_clock_gettime() >> >> and refined the existing supports_monotonic_clock() so that we can still >> use CLOCK_REALTIME if CLOCK_MONOTONIC does not exist. In the future >> (hopefully very near future) we will simply assume these APIs always exist. >> >> On the core-libs side the existing test: >> >> test/jdk/java/time/test/java/time/TestClock_System.java >> >> is adjusted to track the precision in more detail. >> >> Finally Mark has added instantNowAsEpochNanos() to the benchmark >> previously known as >> >> test/micro/org/openjdk/bench/java/lang/Systems.java >> >> which I've renamed to SystemTime.java as Mark suggested. I agree having >> these three functions measured together makes sense. >> >> Testing: >> - test/jdk/java/time/test/java/time/TestClock_System.java >> - test/micro/org/openjdk/bench/java/lang/SystemTime.java >> - Tiers 1-3 >> >> Thanks, >> David From david.holmes at oracle.com Tue May 26 13:27:47 2020 From: david.holmes at oracle.com (David Holmes) Date: Tue, 26 May 2020 23:27:47 +1000 Subject: RFR(S) 8242504: Enhance the system clock to nanosecond precision In-Reply-To: References: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> Message-ID: <3cf4a7ca-f357-11b8-2c1c-6cd40d33ee19@oracle.com> Hi Vyom, Thanks for looking at this. On 26/05/2020 6:44 pm, Vyom Tiwari wrote: > Hi David, > > we can remove the redundant local variable(jlong result) from if block > as follows. > > return jlong(ts.tv_sec) * MILLIUNITS + jlong(ts.tv_nsec) / NANOUNITS_PER_MILLIUNIT; Sure. I copied the code from os::javaTimeNanos. IIRC I introduced the local to allow adding a printf before the return when debugging the conversion :) I should have removed it again. Thanks, David > Vyom > > > On Tue, May 26, 2020 at 10:29 AM David Holmes > wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8242504 > webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ > > This work was contributed by Mark Kralj-Taylor: > > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html > > On the hotspot side we change the Linux implementations of > javaTimeMillis() and javaTimeSystemUTC() so that they use > clock_gettime(CLOCK_REALTIME) instead of gettimeofday(). In keeping > with > our conditional use of this API I added a new guard > > os::Posix::supports_clock_gettime() > > and refined the existing supports_monotonic_clock() so that we can > still > use CLOCK_REALTIME if CLOCK_MONOTONIC does not exist. In the future > (hopefully very near future) we will simply assume these APIs always > exist. > > On the core-libs side the existing test: > > test/jdk/java/time/test/java/time/TestClock_System.java > > is adjusted to track the precision in more detail. > > Finally Mark has added instantNowAsEpochNanos() to the benchmark > previously known as > > test/micro/org/openjdk/bench/java/lang/Systems.java > > which I've renamed to SystemTime.java as Mark suggested. I agree having > these three functions measured together makes sense. > > Testing: > ? ?- test/jdk/java/time/test/java/time/TestClock_System.java > ? ?- test/micro/org/openjdk/bench/java/lang/SystemTime.java > ? ?- Tiers 1-3 > > Thanks, > David > > > > -- > Thanks, > Vyom From scolebourne at joda.org Tue May 26 13:35:12 2020 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 26 May 2020 14:35:12 +0100 Subject: RFR(S) 8242504: Enhance the system clock to nanosecond precision In-Reply-To: References: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> Message-ID: I'm not an official OpenJDK reviewer, nor would I be confident reviewing the native code here. Stephen On Tue, 26 May 2020 at 14:28, David Holmes wrote: > > On 26/05/2020 6:14 pm, Stephen Colebourne wrote: > > AFAICT a nanosecond clock is fine from a java.time.* API perspective. > > Thanks Stephen. Is this a review or just a nod of approval? :) > > Cheers, > David > ----- > > > Stephen > > > > On Tue, 26 May 2020 at 06:01, David Holmes wrote: > >> > >> bug: https://bugs.openjdk.java.net/browse/JDK-8242504 > >> webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ > >> > >> This work was contributed by Mark Kralj-Taylor: > >> > >> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html > >> > >> On the hotspot side we change the Linux implementations of > >> javaTimeMillis() and javaTimeSystemUTC() so that they use > >> clock_gettime(CLOCK_REALTIME) instead of gettimeofday(). In keeping with > >> our conditional use of this API I added a new guard > >> > >> os::Posix::supports_clock_gettime() > >> > >> and refined the existing supports_monotonic_clock() so that we can still > >> use CLOCK_REALTIME if CLOCK_MONOTONIC does not exist. In the future > >> (hopefully very near future) we will simply assume these APIs always exist. > >> > >> On the core-libs side the existing test: > >> > >> test/jdk/java/time/test/java/time/TestClock_System.java > >> > >> is adjusted to track the precision in more detail. > >> > >> Finally Mark has added instantNowAsEpochNanos() to the benchmark > >> previously known as > >> > >> test/micro/org/openjdk/bench/java/lang/Systems.java > >> > >> which I've renamed to SystemTime.java as Mark suggested. I agree having > >> these three functions measured together makes sense. > >> > >> Testing: > >> - test/jdk/java/time/test/java/time/TestClock_System.java > >> - test/micro/org/openjdk/bench/java/lang/SystemTime.java > >> - Tiers 1-3 > >> > >> Thanks, > >> David From daniel.fuchs at oracle.com Tue May 26 14:14:49 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 26 May 2020 15:14:49 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> Message-ID: Hi Alexey, This is not a review. A few high level comments however: For that kind of change that introduce a new environment property you will need to file a CSR, and probably provide some release notes as well. Your changes seem to trigger new IllegalStateException and UnsupportedOperationExceptions which are undocumented. I believe they should be replaced by NamingException which is documented at the public API level. Also it would be good to have a test that validates that the proposed changes works as expected. I will not comment on the security libs changes - I'm clearly out of my depth there. It's a bit distasteful that the LdapCtxt/LdapClient have to have knowledge of channel binding and extract the certificates from the SSLSocket to pass them to the lower layer. Ideally this should rather be handled by the SASL layers? best regards, -- daniel On 25/05/2020 16:33, Alexey Bakhtin wrote: > Updated webrev is available at:http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v1/ From Roger.Riggs at oracle.com Tue May 26 14:28:23 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 26 May 2020 10:28:23 -0400 Subject: RFR(S) 8242504: Enhance the system clock to nanosecond precision In-Reply-To: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> References: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> Message-ID: <194797a0-450b-7fd7-a436-c6d3b49f4ba2@oracle.com> Looks good. Thanks to Mark and you for the improvement and testing. On 5/26/20 12:59 AM, David Holmes wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8242504 > webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ > > This work was contributed by Mark Kralj-Taylor: > > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html > > > On the hotspot side we change the Linux implementations of > javaTimeMillis() and javaTimeSystemUTC() so that they use > clock_gettime(CLOCK_REALTIME) instead of gettimeofday(). In keeping > with our conditional use of this API I added a new guard > > os::Posix::supports_clock_gettime() > > and refined the existing supports_monotonic_clock() so that we can > still use CLOCK_REALTIME if CLOCK_MONOTONIC does not exist. In the > future (hopefully very near future) we will simply assume these APIs > always exist. > > On the core-libs side the existing test: > > test/jdk/java/time/test/java/time/TestClock_System.java > > is adjusted to track the precision in more detail. > > Finally Mark has added instantNowAsEpochNanos() to the benchmark > previously known as > > test/micro/org/openjdk/bench/java/lang/Systems.java > > which I've renamed to SystemTime.java as Mark suggested. I agree > having these three functions measured together makes sense. > > Testing: > ? - test/jdk/java/time/test/java/time/TestClock_System.java > ? - test/micro/org/openjdk/bench/java/lang/SystemTime.java > ? - Tiers 1-3 > > Thanks, > David From Roger.Riggs at oracle.com Tue May 26 14:32:53 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Tue, 26 May 2020 10:32:53 -0400 Subject: RFR: 8245677: Optimize lookups in empty HashMap In-Reply-To: <62166198-221B-47FB-B528-26166F808D84@oracle.com> References: <62166198-221B-47FB-B528-26166F808D84@oracle.com> Message-ID: +1, Looks fine. Should the benchmark be included? Thanks, Roger On 5/25/20 8:12 AM, Jim Laskey wrote: > +1 > > (Copyright date) > >> On May 25, 2020, at 7:02 AM, Claes Redestad wrote: >> >> Hi, >> >> sponsoring this patch from Christoph Dreis. >> >> By pushing down the hash calculation we can optimize lookups >> in empty HashMaps (also helps LinkedHashMap). >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8245677 >> Webrev: http://cr.openjdk.java.net/~redestad/8245677/open.00/ >> >> Testing: tier1+2 >> >> Original report: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066530.html >> >> /Claes From claes.redestad at oracle.com Tue May 26 14:44:57 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 26 May 2020 16:44:57 +0200 Subject: RFR: 8245677: Optimize lookups in empty HashMap In-Reply-To: References: <62166198-221B-47FB-B528-26166F808D84@oracle.com> Message-ID: <8f41c0ee-9762-48f9-a6cf-bff289e9741b@oracle.com> Hi Roger, thank you for reviewing. I felt adding the micro wouldn't add much, since HashMap is such a common occurrence in various benchmarks already. /Claes On 2020-05-26 16:32, Roger Riggs wrote: > +1, > > Looks fine. > > Should the benchmark be included? > > Thanks, Roger > > > On 5/25/20 8:12 AM, Jim Laskey wrote: >> +1 >> >> (Copyright date) >> >>> On May 25, 2020, at 7:02 AM, Claes Redestad >>> wrote: >>> >>> Hi, >>> >>> sponsoring this patch from Christoph Dreis. >>> >>> By pushing down the hash calculation we can optimize lookups >>> in empty HashMaps (also helps LinkedHashMap). >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8245677 >>> Webrev: http://cr.openjdk.java.net/~redestad/8245677/open.00/ >>> >>> Testing: tier1+2 >>> >>> Original report: >>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066530.html >>> >>> >>> /Claes > From maurizio.cimadamore at oracle.com Tue May 26 14:48:48 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 26 May 2020 15:48:48 +0100 Subject: RFR: JDK-8227046: compiler implementation for sealed classes, JDK-8227047: Javadoc for sealed types and JDK-8227044: javax.lang.model for sealed classes In-Reply-To: References: <3bd27bea-b8a3-88a2-5536-ea9610749ce4@oracle.com> <11f8828c-607e-e844-1ac6-5977a40c9a77@oracle.com> Message-ID: <255648e6-8aa3-d09f-cff6-98af5b5509e3@oracle.com> Looks good. For the diagnostic, longer term it would be nice to generalize those: # 0: token, 1: token 2168 compiler.err.expected2=\ 2169 {0} or {1} expected 2170 2171 # 0: token, 1: token, 2: token 2172 compiler.err.expected3=\ 2173 {0}, {1}, or {2} expected 2174 2175 # 0: token, 1: token, 2: token, 3: string 2176 compiler.err.expected4=\ 2177 {0}, {1}, {2}, or {3} expected 2178 To work on more argument kinds (since you need the same thing). I would at leas attempt to follow the same text as in the other diagnostics - I don't see "one of:" being used anywhere else in compiler.properties. Maurizio On 26/05/2020 05:14, Vicente Romero wrote: > Hi Maurizio, > > Right good catch I forgot to add the MONKEY_AT to the list of expected > tokens. I have fixed that. I have published another iteration at [1]. > Apart from the MONKEY_AT issue addressed at the parser this iteration > also: > > ?- adds another error key to compiler.properties, this new key is > oriented to show a more explicit error message when an interface with > no `non-sealed` or `sealed` modifier extends a sealed interface. A > class in this position can also be `final` but this is not possible > for interfaces. > ?- changes to PrintingProcessor and to > test/langtools/tools/javac/processing/model/element/TestSealed.java > suggested by Joe in this thread > ?- adds a new subtest at SealedCompilationTests testing the sealed and > non-sealed modifiers being followed by different modifiers or annotations > ?- modified a subtest also at SealedCompilationTests, testPrinting, > that was failing on Windows > > Thanks, > Vicente > > [1] http://cr.openjdk.java.net/~vromero/8227046/webrev.03.delta/ > > On 5/25/20 6:37 AM, Maurizio Cimadamore wrote: >> Hi, >> changes look good, but the parser changes do not convince me. Now >> that the logic is more clearly defined, I see some issues e.g. there >> seems to be a tight coupling by where "sealed" or "non-sealed" is, >> and the fact that the following token must be e.g. "class". This is >> unlike other modifiers which can in fact appear in any configuation. >> >> I believe that you can break the current logic by adding an extra >> annotation between the "sealed" token and the "class" token e.g. >> >> sealed @foo class Bar { } >> >> But maybe the quick fix would be to add MONKEY_AT to the set of >> expected tokens after sealed/non-sealed. >> >> Maurizio >> >> >> On 22/05/2020 19:25, Vicente Romero wrote: >>> Hi, >>> >>> Thanks Jan and Maurizio for the reviews. I have created another >>> iteration that I hope addresses all of the comments. I recognize >>> that dealing with `sealed`, `non-sealed` is the most complicated >>> part as there is no guide right now from the spec. So I have tried >>> to make them contextual keywords, for some informal definition of >>> the concept, I think that with more success for the `sealed` case. >>> So going in more detail this iteration includes: >>> >>> ?- ClassTree::getPermitsClause now returns `List.of()` >>> ?- Types::findDescriptorInternal has been modified to fail on sealed >>> interfaces >>> ?- several error messages have been updated as suggested, on this >>> front given that when a class list the same interface twice in the >>> implements clause, the second occurrence is the one flagged, I did >>> the same for repeated names in the permits clause >>> ?- modifications in ClassReader and ClassWriter as suggested >>> ?- JavacParser, the bulk of the changes are concentrated here, as >>> mentioned above the goal has been to try to implement the contextual >>> keyword thing and also give a nice error message in several corner >>> case situations detected in the reviews >>> ?- more tests were added >>> >>> Thanks, >>> Vicente >>> >>> On 5/21/20 8:14 AM, Maurizio Cimadamore wrote: >>>> Hi Vicente, >>>> looks very good. Some comments below. >>>> >>>> * the parser logic is clever in its use of position to apply >>>> context-dependent keyword detection; as Jan says, perhaps just >>>> share the code so that the position checks are not repeated. >>>> >>>> * I found one very edge-case quirk in the context-dependent logic; >>>> not sure how we wanna address: >>>> >>>> class Foo { >>>> ??? sealed m() {} >>>> } >>>> >>>> This fails with: >>>> >>>> Error: invalid method declaration; return type required >>>> >>>> As javac parses non-sealed as a modifier, and then expects a type. >>>> I think this is probably reasonable, but it's not as >>>> context-dependent as it could be I guess. >>>> >>>> * This case: >>>> >>>> class Bar { } >>>> sealed @interface Foo permits Bar >>>> >>>> Fails as expected, but only because Bar doesn't extends Foo. I >>>> believe we'd like to ban sealed on annotations more eagerly. Same >>>> for non-sealed. For enums and records (which are non-extensible) >>>> the compiler does the right thing and tells me that I can't just >>>> use sealed/non-sealed there. >>>> >>>> * The recovery logic in case preview features aren't enabled leaves >>>> something to be desired. For instance, if I compile this w/o >>>> --enable-preview: >>>> >>>> ?record Foo() {} >>>> >>>> I get a very sensible error: >>>> >>>> records are a preview feature and are disabled by default. >>>> ??? (use --enable-preview to enable records) >>>> >>>> However, if I compiler this w/o --enable-preview: >>>> >>>> sealed class Foo {} >>>> >>>> I get this: >>>> >>>> error: class, interface, or enum expected >>>> >>>> (no mention of preview features) >>>> >>>> It gets worse if I also specify a `permits`. >>>> >>>> * As Jan mentioned, type parameters on permitted types should be >>>> banned, not silently cleared in TypeEnter >>>> >>>> * Overall the type enter logic seems robust - I've tried several >>>> examples swapping superclass/subclass - using references to nested >>>> classes in supertype declaration, and it all works. Well done. >>>> >>>> * The error for lambda expressions leaves to be desired: >>>> >>>> sealed interface Action { >>>> ?void doAction(); >>>> } >>>> >>>> class Test { >>>> ? Action a = () -> { }; >>>> } >>>> >>>> Foo.java:6: error: class is not allowed to extend sealed class: Action >>>> ? Action a = () -> { }; >>>> ???????????? ^ >>>> >>>> I think a dedicated error here would be useful. >>>> >>>> >>>> * the same check is not applied to method references: >>>> >>>> >>>> class Test { >>>> >>>> ? Action a2 = Test::m; //no error >>>> >>>> ? static void m() { } >>>> } >>>> >>>> More generally, if a functional interface cannot be sealed, I think >>>> it would be better to inject the check in the functional interface >>>> check (e.g. Types::findDescriptorInternal) so that you won't need >>>> any extra code in Attr. This would also be more in spirit with the >>>> spec, where the non-sealedness check is defined in 9.8, not in >>>> section 15. >>>> >>>> * Pulling more on that string, the @FunctionalInterface annotation >>>> can be placed on a sealed interface and no error is issued >>>> >>>> * On ClassWriter - isn't calling adjustFlags() enough? That will >>>> truncate the long flags into an int - I think Flags.SEALED is >>>> bigger than that? >>>> >>>> >>>> // error messages >>>> >>>> * DuplicateTypesInPermits >>>> >>>> I suggest: >>>> >>>> test/langtools/tools/javac/diags/examples/DuplicateTypeInPermits.java:30: >>>> error: invalid permits clause >>>> sealed class Sealed permits Sub, Sub {} >>>> ??????????????????????????? ^ >>>> ? (repeated type: Sub) >>>> >>>> [this is consistent with the error we issues in other places - e.g. >>>> when you implements same interface twice] >>>> >>>> * NonSealedWithNoSealedSuper >>>> >>>> test/langtools/tools/javac/diags/examples/NonSealedWithNoSealedSuper.java:31: >>>> error: non-sealed modifier not allowed here >>>> non-sealed class Sub extends C {} >>>> ?????????? ^ >>>> ? (class must have a sealed superclasses) >>>> >>>> I suggest to replace the details message with something like this: >>>> >>>> (class C does not have any sealed supertypes) >>>> >>>> [since I expect this message to be applicable also for >>>> superinterfaces] >>>> >>>> * PermitsCantListDeclaringClass >>>> >>>> test/langtools/tools/javac/diags/examples/PermitsCantListDeclaringClass.java:30: >>>> error: invalid permits clause >>>> sealed class C permits C {} >>>> ?????????????????????? ^ >>>> ? (must not include the declaring class: C) >>>> >>>> Here I recommend something like: >>>> >>>> (illegal self-reference in permits clause) >>>> >>>> * PermitsCantListSuperType >>>> >>>> test/langtools/tools/javac/diags/examples/PermitsCantListSuperType.java:32: >>>> error: invalid permits clause >>>> sealed class C implements I permits I {} >>>> ??????????????????????????????????? ^ >>>> ? (must not include a supertype: I) >>>> >>>> I suggest: >>>> >>>> (illegal reference to supertype I) >>>> >>>> * PermitsInNoSealedClass >>>> >>>> test/langtools/tools/javac/diags/examples/PermitsInNoSealedClass.java:30: >>>> error: invalid permits clause >>>> class C permits Sub {} >>>> ??????? ^ >>>> ? (class must be sealed) >>>> >>>> This is good, but I noted that if you change the test to use an >>>> interface, the message still says "class" - the kindname should be >>>> used here. >>>> >>>> * SealedMustHaveSubtypes >>>> >>>> test/langtools/tools/javac/diags/examples/SealedMustHaveSubtypes.java:29: >>>> error: sealed class must have subclasses >>>> sealed class Sealed {} >>>> ?????? ^ >>>> >>>> I think this message reflects one of the main issues with the >>>> general type vs. class dichotomy. A subclass, in JLS lingo is e.g. >>>> `B` where `B extends A`. Interfaces do not play in the mix - they >>>> are not considered subclasses. The word subtypes could be more >>>> general - but again, it is a bit imprecise, since we're talking >>>> about declarations here, not types. I'll defer this conundrum to >>>> our spec gurus :-) >>>> >>>> >>>> Cheers >>>> Maurizio >>>> >>>> >>>> >>>> On 18/05/2020 23:42, Vicente Romero wrote: >>>>> Hi, >>>>> >>>>> Please review this patch for the compiler, javadoc and >>>>> javax.lang.model support for the JEP 360 Sealed Classes (Preview). >>>>> The changes are provided at [1], which implements the latest JLS >>>>> for sealed types [2]. The patch also include the needed changes to >>>>> javadoc and javax.lang.model to support sealed types. The CSR >>>>> witht the changes in the javax.lang.model spec is at [3]. The >>>>> sealed types JEP is accessible at [4]. There is an ongoing review >>>>> for the VM and core-libs code of sealed types [5] and that code >>>>> hasn't been included in this webrev, >>>>> >>>>> Thanks, >>>>> Vicente >>>>> >>>>> [1] http://cr.openjdk.java.net/~vromero/8227046/webrev.00/ >>>>> [2] >>>>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html >>>>> >>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8244367 >>>>> [4] https://openjdk.java.net/jeps/360 >>>>> [5] >>>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066440.html >>> > From weijun.wang at oracle.com Tue May 26 14:50:22 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 26 May 2020 22:50:22 +0800 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> I have a question on GssKrb5Client.java: Do you think it's a good idea to let the SASL mechanism understand what TLS binding is? Instead of passing the whole TlsChannelBinding object through a SASL property, is it possible to only pass the actual cbData? After all, the name "com.sun.security.sasl.channelbinding" suggests it's just a general ChannelBinding which is independent with any application level info. From my reading of the code change, it looks like this cbData can be calculated on the LDAP side. Thanks, Max > On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: > > Hello, > > Could you please review the following patch: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 > Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ > > The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding > (based on the TLS server certificate). The channel binding data is calculated as following : > ? The client calculates a hash of the TLS server certificate. > The hash algorithm is selected on the base of the certificate signature algorithm. > Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based > ? The channel binding information is the same as defined in rfc4121 [1] with small corrections: > ? initiator and acceptor addresses should be set to NULL > ? initiator and acceptor address types should be zero. > It contradicts to the ?Using Channel Bindings in GSS-API? document [2] that say that > the address type should be set to GSS_C_AF_NULLADDR=0xFF, > instead of GSS_C_AF_UNSPEC=0x00. > > This patch introduces changes in the LDAP, SASL and JGSS modules > to generate channel binding data automatically if requested by an application. > This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes > initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. > The patch introduces new environment property ?com.sun.jndi.ldap.tls.cbtype? that indicates > Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. > Right now "tls-server-end-point" Channel Binding type is supported only. > The client extracts server certificate from the underlying TLS connection and creates > Channel Binding data for JGSS/Kerberos authentication if application indicates > com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. > Client application should also specify existing "com.sun.jndi.ldap.connect.timeout? property > to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. > > [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 > > [2] - > https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html > > Initial discussion of this issue is available at security-dev list: > https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html > https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html > https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html > https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html From aleksej.efimov at oracle.com Tue May 26 14:55:05 2020 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Tue, 26 May 2020 15:55:05 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> Message-ID: <9a0a7b9f-64ff-d6d2-4afe-671cf7774a6b@oracle.com> Hi Alexey, I agree with all Daniel's comments. Few thoughts about moving the implementation down to SASL layers: Will it be possible to make this new code specific only for JGSS/Kerberos authentication mechanism? Maybe investigate moving all the new code to GssKrb5Client SASL client implementation (GssKrb5Client class, "GSSAPI" authentication mechanism name): - That may require to store the server certificate extracted from SSLSocket into new context environment property - The code that processes and checks the String value of channel binding type value could also be moved to GssKrb5Client or to TlsChannelBinding - Add TlsChannelBinding factory method that creates an object from the server certificate and the string value of the environment property could also be useful here All of that will allow us to keep the fix specific to "JGSS/Kerberos" area and will keep LdapCtx/LdapClient code changes minimal and clear of "JGSS/Kerberos" details Best Regards, Aleksei On 26/05/2020 15:14, Daniel Fuchs wrote: > Hi Alexey, > > This is not a review. A few high level comments however: > > For that kind of change that introduce a new environment > property you will need to file a CSR, and probably provide > some release notes as well. > > Your changes seem to trigger new IllegalStateException and > UnsupportedOperationExceptions which are undocumented. > I believe they should be replaced by NamingException which > is documented at the public API level. > > Also it would be good to have a test that validates that > the proposed changes works as expected. > > I will not comment on the security libs changes - I'm clearly > out of my depth there. It's a bit distasteful that the > LdapCtxt/LdapClient have to have knowledge of channel binding > and extract the certificates from the SSLSocket to pass them to > the lower layer. Ideally this should rather be handled by the > SASL layers? > > best regards, > > -- daniel > > > On 25/05/2020 16:33, Alexey Bakhtin wrote: >> Updated webrev is available >> at:http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v1/ > From daniel.fuchs at oracle.com Tue May 26 15:35:44 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 26 May 2020 16:35:44 +0100 Subject: RFR(S) 8242504: Enhance the system clock to nanosecond precision In-Reply-To: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> References: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> Message-ID: <98d49d71-73a7-30f3-bab8-1a80e7ca78e9@oracle.com> Hi David, This is not a review for the posix code. Your webrev looks good to me and corresponds to what I expected to see. I understand that not all operating systems / platforms are expected to have the nano second precision, so your test probably can't go much beyond what is currently being tested. Last time I upgraded the system clock to micro second precision [1] I had to write a CSR and release notes. That was the first time the clock went beyond millisecond precision however - and my expectation is that your proposed change should no longer require a CSR as potential nanosecond precision should now be covered by the spec. I had to modify a few other places as well (see [1]) - where precision greater than 1ms was not expected, but these modifications should cover your current changes too, so I don't think anything more is required. Some --test-repeat might be in order to verify things are stable but I don't expect any issue there :-) LGTM. best regards, -- daniel [1] https://bugs.openjdk.java.net/browse/JDK-8068730 On 26/05/2020 05:59, David Holmes wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8242504 > webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ > > This work was contributed by Mark Kralj-Taylor: > > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html > > > On the hotspot side we change the Linux implementations of > javaTimeMillis() and javaTimeSystemUTC() so that they use > clock_gettime(CLOCK_REALTIME) instead of gettimeofday(). In keeping with > our conditional use of this API I added a new guard > > os::Posix::supports_clock_gettime() > > and refined the existing supports_monotonic_clock() so that we can still > use CLOCK_REALTIME if CLOCK_MONOTONIC does not exist. In the future > (hopefully very near future) we will simply assume these APIs always exist. > > On the core-libs side the existing test: > > test/jdk/java/time/test/java/time/TestClock_System.java > > is adjusted to track the precision in more detail. > > Finally Mark has added instantNowAsEpochNanos() to the benchmark > previously known as > > test/micro/org/openjdk/bench/java/lang/Systems.java > > which I've renamed to SystemTime.java as Mark suggested. I agree having > these three functions measured together makes sense. > > Testing: > ? - test/jdk/java/time/test/java/time/TestClock_System.java > ? - test/micro/org/openjdk/bench/java/lang/SystemTime.java > ? - Tiers 1-3 > > Thanks, > David From claes.redestad at oracle.com Tue May 26 16:20:36 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 26 May 2020 18:20:36 +0200 Subject: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers In-Reply-To: <2035955824.845126.1590446912642.JavaMail.zimbra@u-pem.fr> References: <3ee129e4-d0f3-96e9-9239-52194cb9e09c@oracle.com> <1168727666.821877.1590440019689.JavaMail.zimbra@u-pem.fr> <6e9a8f0a-309c-09c9-c5f4-d47bdcd9c710@oracle.com> <2035955824.845126.1590446912642.JavaMail.zimbra@u-pem.fr> Message-ID: <1709ce91-9dc5-263b-3508-79afce2c5af9@oracle.com> On 2020-05-26 00:48, forax at univ-mlv.fr wrote: >> Not sure in which sense you mean inlining? Few of the methods in the >> bootstrap code are likely hot enough to see inlining by a JIT - and the >> resulting MHs should be identical, just not constructed over and over >> again. > I'm wondering if the code without the null tests was not simple enough to be inlined by c1, > the MH creations tends to do a lot of checks that can be removed even by c1. > Time spent in prepender() does not seem to be a significant contributor to bootstrap overhead - time spent in MHs.insertArguments is, though. One thing that falls out naturally from this is that prefix can only be non-null on the first prepender: "foo" + a + "bar" + b ... will bind both "foo" and "bar" to the a-prepender, then b and subsequent prependers will never see a prefix constant since it will be bound in as a suffix of the preceding argument. Thus it makes sense to either provide a caching mechanism for prependers whose prefix arguments are pre-bound to null: http://cr.openjdk.java.net/~redestad/8245756/open.01 We might be able to special-case the first prepender so that we can remove the prefix argument from prependers in general, which might make the final MH a bit smaller and easier for the JIT to optimize. Testing: tier1+2 /Claes From martinrb at google.com Tue May 26 16:27:55 2020 From: martinrb at google.com (Martin Buchholz) Date: Tue, 26 May 2020 09:27:55 -0700 Subject: Possible optimization in StringLatin1.regionMatchesCI In-Reply-To: References: Message-ID: On Tue, May 26, 2020 at 4:07 AM Christoph Dreis wrote: > > Hi Martin, > > ?> Not a review, but: > > Compare with the variant of this code in StringUTF16. > > StringLatin1 only ever needs to support the first 256 chars in Unicode > > Does it really? That makes me wonder even more about the additional lowercase check. > > > which can never change, unlike StringUTF16, > > What do you mean by "can never change"? When we discover sentient life on Titan, their script needs to get added to Unicode. But the first 256 chars are already fully allocated; the Titans will be given empty space elsewhere. Hopefully Unicode won't be clogged by a million emojis at that point. There's a real fear of eszett capitalization changing. After centuries of debate the German Sprachbund will finally decide to (wisely!) abolish eszett, but Liechtenstein will be the only holdout insisting that eszett be capitalized to https://en.wikipedia.org/wiki/Capital_%E1%BA%9E Fortunately the code we are reviewing here is Locale-independent, and so is hopefully immune to the future politics of Liechtenstein. From alexey at azul.com Tue May 26 16:27:58 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 26 May 2020 16:27:58 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <9a0a7b9f-64ff-d6d2-4afe-671cf7774a6b@oracle.com> References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> <9a0a7b9f-64ff-d6d2-4afe-671cf7774a6b@oracle.com> Message-ID: Hello Aleks, Daniel, Thank you for your comments. I don?t like that the code is split into several modules too. The reason of doing it is I can not get TLS server certificate from the JGSS/Kerberos code. The only place Where I can fetch it is LdapClient. If I understand your idea correctly, I can extract TLS server certificate in the LdapClient and put it into internal environment property as byte array without mention about Channel Binding. It will be done for every LDAPS connection. In case of ?com.sun.security.sasl.channelbinding=tls-server-end-point? property specified, GssKrb5Client extracts certificate from the internal environment property and use it to create TLS Channel Binding. In this case almost all Channel Binding code could be moved to GssKrb5Client. LdapClient still changed but not mention about Channel Binding. Changes in the LdapCtx could be omitted. Regards Alexey > On 26 May 2020, at 17:55, Aleks Efimov wrote: > > Hi Alexey, > > I agree with all Daniel's comments. > > Few thoughts about moving the implementation down to SASL layers: > Will it be possible to make this new code specific only for JGSS/Kerberos authentication mechanism? > Maybe investigate moving all the new code to GssKrb5Client SASL client implementation (GssKrb5Client class, "GSSAPI" authentication mechanism name): > - That may require to store the server certificate extracted from SSLSocket into new context environment property > - The code that processes and checks the String value of channel binding type value could also be moved to GssKrb5Client or to TlsChannelBinding > - Add TlsChannelBinding factory method that creates an object from the server certificate and the string value of the environment property could also be useful here > > All of that will allow us to keep the fix specific to "JGSS/Kerberos" area and will keep LdapCtx/LdapClient code changes minimal and clear of "JGSS/Kerberos" details > > Best Regards, > Aleksei > > On 26/05/2020 15:14, Daniel Fuchs wrote: >> Hi Alexey, >> >> This is not a review. A few high level comments however: >> >> For that kind of change that introduce a new environment >> property you will need to file a CSR, and probably provide >> some release notes as well. >> >> Your changes seem to trigger new IllegalStateException and >> UnsupportedOperationExceptions which are undocumented. >> I believe they should be replaced by NamingException which >> is documented at the public API level. >> >> Also it would be good to have a test that validates that >> the proposed changes works as expected. >> >> I will not comment on the security libs changes - I'm clearly >> out of my depth there. It's a bit distasteful that the >> LdapCtxt/LdapClient have to have knowledge of channel binding >> and extract the certificates from the SSLSocket to pass them to >> the lower layer. Ideally this should rather be handled by the >> SASL layers? >> >> best regards, >> >> -- daniel >> >> >> On 25/05/2020 16:33, Alexey Bakhtin wrote: >>> Updated webrev is available at:http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v1/ >> From mikael.vidstedt at oracle.com Tue May 26 17:24:55 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 26 May 2020 10:24:55 -0700 Subject: RFR(S): 8245600: Clean up libjli In-Reply-To: <1b17af60-92ed-9ce1-8ede-350fb976b5e3@oracle.com> References: <91AE4C99-F36E-41F3-BF13-174DAB40EC92@oracle.com> <1b17af60-92ed-9ce1-8ede-350fb976b5e3@oracle.com> Message-ID: > On May 22, 2020, at 4:27 AM, Alan Bateman wrote: > > > > On 22/05/2020 04:28, Mikael Vidstedt wrote: >> Please review this change which cleans up the libjli related files a bit: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8245600 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8245600/webrev.00/open/webrev/ >> > Looks good, don't have a strong opinion on the function name but if I were doing this when I'd probably got for something like CurrentTimeMicros. I liked it so much I changed it. > Minor nit is that the JLI_TraceLauncher usages in java.c probably don't need to be across two lines now. Fixed. I made the changes and pushed the change. Here?s the final webrev for completeness: http://cr.openjdk.java.net/~mikael/webrevs/8245600/webrev.01/open/webrev/ Cheers, Mikael From alexey at azul.com Tue May 26 17:46:11 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Tue, 26 May 2020 17:46:11 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> Message-ID: <457AF539-498D-43FF-89BA-B567AE930D99@azul.com> Hello Max, Thank you review. If I understand correctly tls-server-end-point channel binding data is a hash of server certificate. Different SASL protocols could send cbData differently, with different prefix format. This is a reason I create TLSChannelBinding class and calculate hash from the LdapClient and add ?tls-server-end-point:? prefix in the JGSS/Kerberos. Alexey > On 26 May 2020, at 17:50, Weijun Wang wrote: > > I have a question on GssKrb5Client.java: > > Do you think it's a good idea to let the SASL mechanism understand what TLS binding is? Instead of passing the whole TlsChannelBinding object through a SASL property, is it possible to only pass the actual cbData? After all, the name "com.sun.security.sasl.channelbinding" suggests it's just a general ChannelBinding which is independent with any application level info. > > From my reading of the code change, it looks like this cbData can be calculated on the LDAP side. > > Thanks, > Max > >> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: >> >> Hello, >> >> Could you please review the following patch: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 >> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ >> >> The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding >> (based on the TLS server certificate). The channel binding data is calculated as following : >> ? The client calculates a hash of the TLS server certificate. >> The hash algorithm is selected on the base of the certificate signature algorithm. >> Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based >> ? The channel binding information is the same as defined in rfc4121 [1] with small corrections: >> ? initiator and acceptor addresses should be set to NULL >> ? initiator and acceptor address types should be zero. >> It contradicts to the ?Using Channel Bindings in GSS-API? document [2] that say that >> the address type should be set to GSS_C_AF_NULLADDR=0xFF, >> instead of GSS_C_AF_UNSPEC=0x00. >> >> This patch introduces changes in the LDAP, SASL and JGSS modules >> to generate channel binding data automatically if requested by an application. >> This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes >> initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. >> The patch introduces new environment property ?com.sun.jndi.ldap.tls.cbtype? that indicates >> Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. >> Right now "tls-server-end-point" Channel Binding type is supported only. >> The client extracts server certificate from the underlying TLS connection and creates >> Channel Binding data for JGSS/Kerberos authentication if application indicates >> com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. >> Client application should also specify existing "com.sun.jndi.ldap.connect.timeout? property >> to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. >> >> [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 >> >> [2] - >> https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html >> >> Initial discussion of this issue is available at security-dev list: >> https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html From ecki at zusammenkunft.net Tue May 26 17:53:12 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Tue, 26 May 2020 17:53:12 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <457AF539-498D-43FF-89BA-B567AE930D99@azul.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com>, <457AF539-498D-43FF-89BA-B567AE930D99@azul.com> Message-ID: Not completely sure about which of the involved apIs have what possible extensions. Maybe we can somehow make two mechanisms one which is the compatible default and one would be the rfc compliant method. Then SASL can be configured and use different mechanism names with a new propert? That would help jgss for the other mechanisms for channel bindings (cbt) as well. Not sure how jgss and JSSE will talk to each other.. via SASL? -- http://bernd.eckenfels.net ________________________________ Von: core-libs-dev im Auftrag von Alexey Bakhtin Gesendet: Tuesday, May 26, 2020 7:46:11 PM An: Weijun Wang Cc: security-dev at openjdk.java.net ; core-libs-dev at openjdk.java.net ; Michael Osipov Betreff: Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos Hello Max, Thank you review. If I understand correctly tls-server-end-point channel binding data is a hash of server certificate. Different SASL protocols could send cbData differently, with different prefix format. This is a reason I create TLSChannelBinding class and calculate hash from the LdapClient and add ?tls-server-end-point:? prefix in the JGSS/Kerberos. Alexey > On 26 May 2020, at 17:50, Weijun Wang wrote: > > I have a question on GssKrb5Client.java: > > Do you think it's a good idea to let the SASL mechanism understand what TLS binding is? Instead of passing the whole TlsChannelBinding object through a SASL property, is it possible to only pass the actual cbData? After all, the name "com.sun.security.sasl.channelbinding" suggests it's just a general ChannelBinding which is independent with any application level info. > > From my reading of the code change, it looks like this cbData can be calculated on the LDAP side. > > Thanks, > Max > >> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: >> >> Hello, >> >> Could you please review the following patch: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 >> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ >> >> The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding >> (based on the TLS server certificate). The channel binding data is calculated as following : >> ? The client calculates a hash of the TLS server certificate. >> The hash algorithm is selected on the base of the certificate signature algorithm. >> Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based >> ? The channel binding information is the same as defined in rfc4121 [1] with small corrections: >> ? initiator and acceptor addresses should be set to NULL >> ? initiator and acceptor address types should be zero. >> It contradicts to the ?Using Channel Bindings in GSS-API? document [2] that say that >> the address type should be set to GSS_C_AF_NULLADDR=0xFF, >> instead of GSS_C_AF_UNSPEC=0x00. >> >> This patch introduces changes in the LDAP, SASL and JGSS modules >> to generate channel binding data automatically if requested by an application. >> This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes >> initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. >> The patch introduces new environment property ?com.sun.jndi.ldap.tls.cbtype? that indicates >> Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. >> Right now "tls-server-end-point" Channel Binding type is supported only. >> The client extracts server certificate from the underlying TLS connection and creates >> Channel Binding data for JGSS/Kerberos authentication if application indicates >> com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. >> Client application should also specify existing "com.sun.jndi.ldap.connect.timeout? property >> to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. >> >> [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 >> >> [2] - >> https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html >> >> Initial discussion of this issue is available at security-dev list: >> https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html >> https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html From paul.sandoz at oracle.com Tue May 26 18:02:01 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 26 May 2020 11:02:01 -0700 Subject: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers In-Reply-To: <1709ce91-9dc5-263b-3508-79afce2c5af9@oracle.com> References: <3ee129e4-d0f3-96e9-9239-52194cb9e09c@oracle.com> <1168727666.821877.1590440019689.JavaMail.zimbra@u-pem.fr> <6e9a8f0a-309c-09c9-c5f4-d47bdcd9c710@oracle.com> <2035955824.845126.1590446912642.JavaMail.zimbra@u-pem.fr> <1709ce91-9dc5-263b-3508-79afce2c5af9@oracle.com> Message-ID: <5D4E5018-B60B-4ABB-81C5-7BBD9D321A51@oracle.com> I prefer the first revision from a simplicity perspective. Are there any measurable benefits in the subsequent revision? It requires some careful reading, where the logic in the prepender is duplicated in the layering of the computeIfAbsent functions. Which, if needed, is fine. Are the existing test sufficient to cover these cases? You referenced ObjStringCombos and I wondering if that makes sense as a combo stress test? Paul. > On May 26, 2020, at 9:20 AM, Claes Redestad wrote: > > On 2020-05-26 00:48, forax at univ-mlv.fr wrote: >>> Not sure in which sense you mean inlining? Few of the methods in the >>> bootstrap code are likely hot enough to see inlining by a JIT - and the >>> resulting MHs should be identical, just not constructed over and over >>> again. >> I'm wondering if the code without the null tests was not simple enough to be inlined by c1, >> the MH creations tends to do a lot of checks that can be removed even by c1. > > Time spent in prepender() does not seem to be a significant contributor > to bootstrap overhead - time spent in MHs.insertArguments is, though. > > One thing that falls out naturally from this is that prefix can only be > non-null on the first prepender: "foo" + a + "bar" + b ... will bind > both "foo" and "bar" to the a-prepender, then b and subsequent > prependers will never see a prefix constant since it will be bound in > as a suffix of the preceding argument. Thus it makes sense to either > provide a caching mechanism for prependers whose prefix arguments are > pre-bound to null: > > http://cr.openjdk.java.net/~redestad/8245756/open.01 > > We might be able to special-case the first prepender so that we can > remove the prefix argument from prependers in general, which might make > the final MH a bit smaller and easier for the JIT to optimize. > > Testing: tier1+2 > > /Claes From claes.redestad at oracle.com Tue May 26 18:31:51 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 26 May 2020 20:31:51 +0200 Subject: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers In-Reply-To: <5D4E5018-B60B-4ABB-81C5-7BBD9D321A51@oracle.com> References: <3ee129e4-d0f3-96e9-9239-52194cb9e09c@oracle.com> <1168727666.821877.1590440019689.JavaMail.zimbra@u-pem.fr> <6e9a8f0a-309c-09c9-c5f4-d47bdcd9c710@oracle.com> <2035955824.845126.1590446912642.JavaMail.zimbra@u-pem.fr> <1709ce91-9dc5-263b-3508-79afce2c5af9@oracle.com> <5D4E5018-B60B-4ABB-81C5-7BBD9D321A51@oracle.com> Message-ID: On 2020-05-26 20:02, Paul Sandoz wrote: > I prefer the first revision from a simplicity perspective. > > Are there any measurable benefits in the subsequent revision? It requires some careful reading, where the logic in the prepender is duplicated in the layering of the computeIfAbsent functions. Which, if needed, is fine. Right, it depends on test. On the ObjStringCombos test there's no real gain - on a case where there are more interleaving constants it should have more of an effect. I'll go ahead with the first version and we can think through if there are ways to simplify this for a follow-up, maybe along with a fix to remove prefix constants altogether. (the trick is to bind in the constants without binding more things directly into the main MH combinator tree - the complex prependers reduced the possible tree shapes a lot) > > Are the existing test sufficient to cover these cases? You referenced ObjStringCombos and I wondering if that makes sense as a combo stress test? Adding more stress tests that test all combinations at more arities would be good. My bootstrap tests as written are a bit poor since I don't do any verification apart from checking that they don't crash. I'll file a standalone RFE to improve the coverage. /Claes > > Paul. > >> On May 26, 2020, at 9:20 AM, Claes Redestad wrote: >> >> On 2020-05-26 00:48, forax at univ-mlv.fr wrote: >>>> Not sure in which sense you mean inlining? Few of the methods in the >>>> bootstrap code are likely hot enough to see inlining by a JIT - and the >>>> resulting MHs should be identical, just not constructed over and over >>>> again. >>> I'm wondering if the code without the null tests was not simple enough to be inlined by c1, >>> the MH creations tends to do a lot of checks that can be removed even by c1. >> >> Time spent in prepender() does not seem to be a significant contributor >> to bootstrap overhead - time spent in MHs.insertArguments is, though. >> >> One thing that falls out naturally from this is that prefix can only be >> non-null on the first prepender: "foo" + a + "bar" + b ... will bind >> both "foo" and "bar" to the a-prepender, then b and subsequent >> prependers will never see a prefix constant since it will be bound in >> as a suffix of the preceding argument. Thus it makes sense to either >> provide a caching mechanism for prependers whose prefix arguments are >> pre-bound to null: >> >> http://cr.openjdk.java.net/~redestad/8245756/open.01 >> >> We might be able to special-case the first prepender so that we can >> remove the prefix argument from prependers in general, which might make >> the final MH a bit smaller and easier for the JIT to optimize. >> >> Testing: tier1+2 >> >> /Claes > From forax at univ-mlv.fr Tue May 26 18:56:24 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Tue, 26 May 2020 20:56:24 +0200 (CEST) Subject: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers In-Reply-To: References: <3ee129e4-d0f3-96e9-9239-52194cb9e09c@oracle.com> <1168727666.821877.1590440019689.JavaMail.zimbra@u-pem.fr> <6e9a8f0a-309c-09c9-c5f4-d47bdcd9c710@oracle.com> <2035955824.845126.1590446912642.JavaMail.zimbra@u-pem.fr> <1709ce91-9dc5-263b-3508-79afce2c5af9@oracle.com> <5D4E5018-B60B-4ABB-81C5-7BBD9D321A51@oracle.com> Message-ID: <301145461.1539523.1590519384469.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Claes Redestad" > ?: "Paul Sandoz" > Cc: "Remi Forax" , "core-libs-dev" > Envoy?: Mardi 26 Mai 2020 20:31:51 > Objet: Re: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers > On 2020-05-26 20:02, Paul Sandoz wrote: >> I prefer the first revision from a simplicity perspective. >> >> Are there any measurable benefits in the subsequent revision? It requires some >> careful reading, where the logic in the prepender is duplicated in the layering >> of the computeIfAbsent functions. Which, if needed, is fine. > > Right, it depends on test. On the ObjStringCombos test there's no > real gain - on a case where there are more interleaving constants > it should have more of an effect. > > I'll go ahead with the first version and we can think through if there > are ways to simplify this for a follow-up, maybe along with a fix to > remove prefix constants altogether. (the trick is to bind in the > constants without binding more things directly into the main MH > combinator tree - the complex prependers reduced the possible tree > shapes a lot) I should have shut my big mouth, i agree that the first patch is actually better. > >> >> Are the existing test sufficient to cover these cases? You referenced >> ObjStringCombos and I wondering if that makes sense as a combo stress test? > > Adding more stress tests that test all combinations at more arities > would be good. My bootstrap tests as written are a bit poor since I > don't do any verification apart from checking that they don't crash. > I'll file a standalone RFE to improve the coverage. > > /Claes R?mi > >> >> Paul. >> >>> On May 26, 2020, at 9:20 AM, Claes Redestad wrote: >>> >>> On 2020-05-26 00:48, forax at univ-mlv.fr wrote: >>>>> Not sure in which sense you mean inlining? Few of the methods in the >>>>> bootstrap code are likely hot enough to see inlining by a JIT - and the >>>>> resulting MHs should be identical, just not constructed over and over >>>>> again. >>>> I'm wondering if the code without the null tests was not simple enough to be >>>> inlined by c1, >>>> the MH creations tends to do a lot of checks that can be removed even by c1. >>> >>> Time spent in prepender() does not seem to be a significant contributor >>> to bootstrap overhead - time spent in MHs.insertArguments is, though. >>> >>> One thing that falls out naturally from this is that prefix can only be >>> non-null on the first prepender: "foo" + a + "bar" + b ... will bind >>> both "foo" and "bar" to the a-prepender, then b and subsequent >>> prependers will never see a prefix constant since it will be bound in >>> as a suffix of the preceding argument. Thus it makes sense to either >>> provide a caching mechanism for prependers whose prefix arguments are >>> pre-bound to null: >>> >>> http://cr.openjdk.java.net/~redestad/8245756/open.01 >>> >>> We might be able to special-case the first prepender so that we can >>> remove the prefix argument from prependers in general, which might make >>> the final MH a bit smaller and easier for the JIT to optimize. >>> >>> Testing: tier1+2 >>> >>> /Claes From alexey.semenyuk at oracle.com Tue May 26 19:26:58 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 26 May 2020 15:26:58 -0400 Subject: RFR: JDK-8245831: Unify code parsing version strings on Mac and Windows In-Reply-To: <21c3ac81-80d4-72bd-7c99-002d4b941d7f@oracle.com> References: <21c3ac81-80d4-72bd-7c99-002d4b941d7f@oracle.com> Message-ID: <8a3f9c48-9561-3a4a-7e07-53a9ebbc1539@oracle.com> Please review fix [2] for jpackage bug [1]. Get rid of duplicated code parsing version strings. Move the code parsing version strings to dedicated classes with unit test coverage. Also remove Mac specific identifier setting in app's config file from the shared code. - Alexey [1] https://bugs.openjdk.java.net/browse/JDK-8245831 [2]?http://cr.openjdk.java.net/~asemenyuk/8245831/webrev.00 From stuart.marks at oracle.com Tue May 26 19:35:47 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 26 May 2020 12:35:47 -0700 Subject: RFR 15 (S): 8245068: Implement Deprecation of RMI Activation Message-ID: Hi all, Here's the implementation of the recently-posted JEP 385, deprecation of RMI Activation for removal. I'm listing this as S ("small") since conceptually it's fairly small, though there are rather a large number of files changed. Essentially the changes are: - java.rmi.activation package spec: add deprecation warning - java.rmi module spec: link to activation package spec - java.rmi.activation public classes and interfaces: deprecate - various other files: suppress warnings - Activation.java: have the rmid tool emit a deprecation warning - rmid.properties: localized warning message Webrev: http://cr.openjdk.java.net/~smarks/reviews/8245068/webrev.0/ Bug ID: https://bugs.openjdk.java.net/browse/JDK-8245068 JEP: http://openjdk.java.net/jeps/385 Thanks, s'marks From valerie.peng at oracle.com Tue May 26 20:37:07 2020 From: valerie.peng at oracle.com (Valerie Peng) Date: Tue, 26 May 2020 13:37:07 -0700 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> Message-ID: I am also concerned about the changes in GSSLibStub.c about the default value being GSS_C_AF_UNSPECinstead of GSS_C_AF_NULLADDR (line 194-195). Can you try and see if Window works with GSS_C_AF_NULLADDR? If yes, I'd prefer to not changing the default value for addresstype for the same reason which Michael has already stated. Thanks, Valerie On 5/25/2020 8:33 AM, Alexey Bakhtin wrote: > Hello Michael, Thomas, > > Thank you a lot for review and suggestions. > I?ve fixed most of the issues except of fundamental one > I need more time to evaluate suggested usage of UnspecEmptyInetAddress subtype. > > Updated webrev is available at: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v1/ > > Also, please see my comments below. > > Regards > Alexey > >> On 24 May 2020, at 02:38, Michael Osipov <1983-01-06 at gmx.net> wrote: >> >> Am 2020-05-21 um 09:35 schrieb Alexey Bakhtin: >>> Hello, >>> >>> Could you please review the following patch: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 >>> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ >> Let's go through your changes statically: >> >> * The JIRA issue title has a typo > Thank you. Fixed in Jira >> * The word "cannot" is incorrectly spelled throughout all exception messages > Fixed from ?can not? to ?cannot" >>> + if (cbTypeProp.equals(TlsChannelBindingType.TLS_UNIQUE.getName())) { >>> + throw new UnsupportedOperationException("LdapCtx: " + >>> + TlsChannelBindingType.TLS_UNIQUE.getName() + " type is not supported"); >> >> "LdapCtx: " is redundant because the stacktrace will contain the class >> name already. A better message would be: "Channel binding type '%s' is >> not supported". Not just the plain value. > Exception message is corrected >>> + } else if (cbTypeProp.equals(TlsChannelBindingType.TLS_SERVER_END_POINT.getName())) { >>> + if (connectTimeout == -1) >>> + throw new IllegalArgumentException(CHANNEL_BINDING_TYPE + " property requires " + >>> + CONNECT_TIMEOUT + " property is set."); >> * Same here with the message > Not sure, What?s wrong with the message ? >> * The IAE is wrong because passed value is correct, but leads to an >> invalid state because connection timeout is -1. You need an >> IllegalStateException here. > Thank you. You are right again. Changed to IllegalStateException >> Stupid question: how can one create a GSS security context when the TLS >> security context has not been established yet? > This logic already existed here. It could be a reason for it and I don?t want change it without strong purpose. > The only changes here is to prevent double setting of channel binding data. > >>> --- old/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java 2020-05-18 19:39:46.000000000 +0300 >>> +++ new/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java 2020-05-18 19:39:46.000000000 +0300 >>> @@ -531,9 +531,12 @@ >>> public void setChannelBinding(ChannelBinding channelBindings) >>> throws GSSException { >>> >>> - if (mechCtxt == null) >>> + if (mechCtxt == null) { >>> + if (this.channelBindings != null) { >>> + throw new GSSException(GSSException.BAD_BINDINGS); >>> + } >>> this.channelBindings = channelBindings; >>> - >>> + } >>> } >> I don't understand the purpose of this hunk. Is this safeguard to set >> bindings only once? >> >>> private static final int CHANNEL_BINDING_AF_INET = 2; >>> private static final int CHANNEL_BINDING_AF_INET6 = 24; >>> private static final int CHANNEL_BINDING_AF_NULL_ADDR = 255; >>> + private static final int CHANNEL_BINDING_AF_UNSPEC = 0; >> This should sort from 0 to 255 and not at the end. > OK. Moved to the top. > >>> private int getAddrType(InetAddress addr) { >>> - int addressType = CHANNEL_BINDING_AF_NULL_ADDR; >>> + int addressType = CHANNEL_BINDING_AF_UNSPEC; >>> // initialize addrtype in CB first >>> - cb->initiator_addrtype = GSS_C_AF_NULLADDR; >>> - cb->acceptor_addrtype = GSS_C_AF_NULLADDR; >>> + cb->initiator_addrtype = GSS_C_AF_UNSPEC; >>> + cb->acceptor_addrtype = GSS_C_AF_UNSPEC; >> This looks wrong to me -- as you already mentioned -- this violates RFC >> 2744, section 3.11, last sentence: >>> or omit addressing information, specifying >>> GSS_C_AF_NULLADDR as the address-types. >>> /* release initiator address */ >>> - if (cb->initiator_addrtype != GSS_C_AF_NULLADDR) { >>> + if (cb->initiator_addrtype != GSS_C_AF_NULLADDR && >>> + cb->initiator_addrtype != GSS_C_AF_UNSPEC) { >>> resetGSSBuffer(&(cb->initiator_address)); >>> } >>> /* release acceptor address */ >>> - if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR) { >>> + if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR && >>> + cb->acceptor_addrtype != GSS_C_AF_UNSPEC) { >>> resetGSSBuffer(&(cb->acceptor_address)); >>> } >> Unspecified does not mean that it is null. >> >>> + final byte[] prefix = (TlsChannelBindingType.TLS_SERVER_END_POINT.getName() + ":").getBytes(); >>> + byte[] cbData = Arrays.copyOf(prefix, >>> + prefix.length + tlsCB.getData().length ); >>> + System.arraycopy(tlsCB.getData(), 0, cbData, prefix.length, tlsCB.getData().length); >> Since you are calling "tlsCB.getData()" multiple times, this should go >> into a variable. > Temporary variable is added > >> >>> + secCtx.setChannelBinding(new >> ChannelBinding(null, null, cbData)); >> >> Why not use new ChannelBinding(cbData)? > Right. updated > >>> + String hashAlg = serverCertificate.getSigAlgName(). >>> + replace("SHA", "SHA-").toUpperCase(); >>> + int ind = hashAlg.indexOf("WITH"); >>> + if (ind > 0) { >>> + hashAlg = hashAlg.substring(0, ind); >>> + if (hashAlg.equals("MD5") || hashAlg.equals("SHA-1")) { >>> + hashAlg = "SHA-256"; >>> + } >> I have several problems with that, some might be hypothetical: >> >> * toUpperCase() should be qualified with Locale.ROOT or Locate.ENGLISH > As you mentioned below AlgorithmId.getName() uses nameTable to return algorithm name. > Looking at implementation I do not think it is realistic to get name in the non-English locale. > I do not think it should be fixed > >> * Looking at https://tools.ietf.org/html/rfc5280#section-4.1.1.2, then >> at sun.security.x509.AlgorithmId.getName() it uses nameTable to >> translate OIDs to readible names. >> >> With indexOf("WITH") you are implying that the cert's sig alg may not >> use a cryptographic function, but this would mean that if the OID is >> 1.3.14.3.2.26 you'd turn "SHA-X" into "SHA--X" according to nameTable, >> wouldn't you? >> I also don't know how realistic "PBEWith..." is. >> >> This likely needs more thought or I am missing something. >> > I do not think it is realistic scenario to have certificate signature algorithm without crypto function. > indexOf(?WITH?) just used to find end out hash algorithm name. > >> * Exception messages are inconsistent. Sometimes "TLS channel binding", >> sometimes just "channel binding". To avoid misunderstandings it should >> always read "TLS channel binding..". >> > Messages are updated. > >> Generally, I have two fundemental issues: >> * How do you know that address type must be UNSPEC and not NULLADDR? >> Trial and error? > I did not find any strict specification about TLS Channel Binding format in Windows server. > So, it was a lot of experiments, reading related forums and docs. > One of the doc, that turns me to try UNSPEC type is the following: > https://docs.microsoft.com/en-us/archive/blogs/openspecification/ntlm-and-channel-binding-hash-aka-extended-protection-for-authentication > >> * Changing the default address type against the RFC will break every >> installation using channel bindings relying on it with cross GSS-API >> implementations. > I do not like this conflict between UNSPEC and NULLADDR types too, but I do not know How to better solve it. > The usage of UnspecEmptyInetAddress subtype is not quite clear to me yet. Who set this value and will it change org.ietf.jgss.ChannelBinding public api ? As I understand, Implementation cannot decide (without pplication request), What channel binding type is enabled on the server. > >> There must be another way to solve this. A system property would also be >> problematic because if you have a product which connects to MS and >> non-MS backends at the same time, channel bindings would be broken again. >> >> What about introducing a UnspecEmptyInetAddress() which gives the proper >> AF type, but #getAddress() would return null? This should satisfy the >> requirements, InitialToken as well as the RFC. this of course needs to >> be properly passed to native providers too. GssKrb5Client would also >> need to know that this channel binding is explicitly for Active >> Directory and not some other, spec-compliant, SASL peer (property on >> LdapCtx?) >> >> One could easily use this for custom code with a SSLServerSocket paired >> with Java SASL or in C, OpenSSL and Cyrus SASL. >> >> Michael >> >> PS: Yes, I am a nitpicker. From andy.herrick at oracle.com Tue May 26 20:43:45 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Tue, 26 May 2020 16:43:45 -0400 Subject: RFR: JDK-8245202: Convert existing jpackage tests to newer form. In-Reply-To: <3127aec6-d764-d7f7-6cba-026d51734611@oracle.com> References: <3127aec6-d764-d7f7-6cba-026d51734611@oracle.com> Message-ID: <04a3031e-9631-e2c8-b8a6-8029f62044fd@oracle.com> revised at [3] to combine JavaOptionsTest and JavaOptionsModular tests [3] - http://cr.openjdk.java.net/~herrick/8245202/webrev.02/ /Andy On 5/26/2020 8:08 AM, Andy Herrick wrote: > Please review the fix to issue [1] at [2]. > > The change removes all the old form helper tests and converts the 6 > remaining tests that used the old helpers into 4 new tests using the > new helpers. > > [1] - https://bugs.openjdk.java.net/browse/JDK-8245202 > > [2] - http://cr.openjdk.java.net/~herrick/8245202/webrev.01/ > > /Andy > From 1983-01-06 at gmx.net Sat May 23 23:38:06 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Sun, 24 May 2020 01:38:06 +0200 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> Am 2020-05-21 um 09:35 schrieb Alexey Bakhtin: > Hello, > > Could you please review the following patch: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 > Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ Let's go through your changes statically: * The JIRA issue title has a typo * The word "cannot" is incorrectly spelled throughout all exception messages > + if (cbTypeProp.equals(TlsChannelBindingType.TLS_UNIQUE.getName())) { > + throw new UnsupportedOperationException("LdapCtx: " + > + TlsChannelBindingType.TLS_UNIQUE.getName() + " type is not supported"); "LdapCtx: " is redundant because the stacktrace will contain the class name already. A better message would be: "Channel binding type '%s' is not supported". Not just the plain value. > + } else if (cbTypeProp.equals(TlsChannelBindingType.TLS_SERVER_END_POINT.getName())) { > + if (connectTimeout == -1) > + throw new IllegalArgumentException(CHANNEL_BINDING_TYPE + " property requires " + > + CONNECT_TIMEOUT + " property is set."); * Same here with the message * The IAE is wrong because passed value is correct, but leads to an invalid state because connection timeout is -1. You need an IllegalStateException here. Stupid question: how can one create a GSS security context when the TLS security context has not been established yet? > --- old/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java 2020-05-18 19:39:46.000000000 +0300 > +++ new/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java 2020-05-18 19:39:46.000000000 +0300 > @@ -531,9 +531,12 @@ > public void setChannelBinding(ChannelBinding channelBindings) > throws GSSException { > > - if (mechCtxt == null) > + if (mechCtxt == null) { > + if (this.channelBindings != null) { > + throw new GSSException(GSSException.BAD_BINDINGS); > + } > this.channelBindings = channelBindings; > - > + } > } I don't understand the purpose of this hunk. Is this safeguard to set bindings only once? > private static final int CHANNEL_BINDING_AF_INET = 2; > private static final int CHANNEL_BINDING_AF_INET6 = 24; > private static final int CHANNEL_BINDING_AF_NULL_ADDR = 255; > + private static final int CHANNEL_BINDING_AF_UNSPEC = 0; This should sort from 0 to 255 and not at the end. > private int getAddrType(InetAddress addr) { > - int addressType = CHANNEL_BINDING_AF_NULL_ADDR; > + int addressType = CHANNEL_BINDING_AF_UNSPEC; > // initialize addrtype in CB first > - cb->initiator_addrtype = GSS_C_AF_NULLADDR; > - cb->acceptor_addrtype = GSS_C_AF_NULLADDR; > + cb->initiator_addrtype = GSS_C_AF_UNSPEC; > + cb->acceptor_addrtype = GSS_C_AF_UNSPEC; This looks wrong to me -- as you already mentioned -- this violates RFC 2744, section 3.11, last sentence: > or omit addressing information, specifying > GSS_C_AF_NULLADDR as the address-types. > /* release initiator address */ > - if (cb->initiator_addrtype != GSS_C_AF_NULLADDR) { > + if (cb->initiator_addrtype != GSS_C_AF_NULLADDR && > + cb->initiator_addrtype != GSS_C_AF_UNSPEC) { > resetGSSBuffer(&(cb->initiator_address)); > } > /* release acceptor address */ > - if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR) { > + if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR && > + cb->acceptor_addrtype != GSS_C_AF_UNSPEC) { > resetGSSBuffer(&(cb->acceptor_address)); > } Unspecified does not mean that it is null. > + final byte[] prefix = (TlsChannelBindingType.TLS_SERVER_END_POINT.getName() + ":").getBytes(); > + byte[] cbData = Arrays.copyOf(prefix, > + prefix.length + tlsCB.getData().length ); > + System.arraycopy(tlsCB.getData(), 0, cbData, prefix.length, tlsCB.getData().length); Since you are calling "tlsCB.getData()" multiple times, this should go into a variable. > + secCtx.setChannelBinding(new ChannelBinding(null, null, cbData)); Why not use new ChannelBinding(cbData)? > + String hashAlg = serverCertificate.getSigAlgName(). > + replace("SHA", "SHA-").toUpperCase(); > + int ind = hashAlg.indexOf("WITH"); > + if (ind > 0) { > + hashAlg = hashAlg.substring(0, ind); > + if (hashAlg.equals("MD5") || hashAlg.equals("SHA-1")) { > + hashAlg = "SHA-256"; > + } I have several problems with that, some might be hypothetical: * toUpperCase() should be qualified with Locale.ROOT or Locate.ENGLISH * Looking at https://tools.ietf.org/html/rfc5280#section-4.1.1.2, then at sun.security.x509.AlgorithmId.getName() it uses nameTable to translate OIDs to readible names. With indexOf("WITH") you are implying that the cert's sig alg may not use a cryptographic function, but this would mean that if the OID is 1.3.14.3.2.26 you'd turn "SHA-X" into "SHA--X" according to nameTable, wouldn't you? I also don't know how realistic "PBEWith..." is. This likely needs more thought or I am missing something. * Exception messages are inconsistent. Sometimes "TLS channel binding", sometimes just "channel binding". To avoid misunderstandings it should always read "TLS channel binding..". Generally, I have two fundemental issues: * How do you know that address type must be UNSPEC and not NULLADDR? Trial and error? * Changing the default address type against the RFC will break every installation using channel bindings relying on it with cross GSS-API implementations. There must be another way to solve this. A system property would also be problematic because if you have a product which connects to MS and non-MS backends at the same time, channel bindings would be broken again. What about introducing a UnspecEmptyInetAddress() which gives the proper AF type, but #getAddress() would return null? This should satisfy the requirements, InitialToken as well as the RFC. this of course needs to be properly passed to native providers too. GssKrb5Client would also need to know that this channel binding is explicitly for Active Directory and not some other, spec-compliant, SASL peer (property on LdapCtx?) One could easily use this for custom code with a SSLServerSocket paired with Java SASL or in C, OpenSSL and Cyrus SASL. Michael PS: Yes, I am a nitpicker. From 1983-01-06 at gmx.net Sun May 24 09:00:36 2020 From: 1983-01-06 at gmx.net (Michael Osipov) Date: Sun, 24 May 2020 11:00:36 +0200 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> Message-ID: <6118c0df-30c2-0b2c-a67f-3a74bddc839d@gmx.net> Am 2020-05-24 um 01:38 schrieb Michael Osipov: > Am 2020-05-21 um 09:35 schrieb Alexey Bakhtin: > ... > What about introducing a UnspecEmptyInetAddress() which gives the proper > AF type, but #getAddress() would return null? This should satisfy the > requirements, InitialToken as well as the RFC. this of course needs to > be properly passed to native providers too. GssKrb5Client would also > need to know that this channel binding is explicitly for Active > Directory and not some other, spec-compliant, SASL peer (property on > LdapCtx?) Giving this more thought. I believe you have also found a bug in InitialToken#getAddrType(InetAddress). It would return CHANNEL_BINDING_AF_NULL_ADDR if addr is neither Inet6 nor Inet6, but is not null which is wrong. But this is just a hypothetical case. M From kralj.mark at gmail.com Tue May 26 16:15:33 2020 From: kralj.mark at gmail.com (Mark Kralj-Taylor) Date: Tue, 26 May 2020 17:15:33 +0100 Subject: RFR(S) 8242504: Enhance the system clock to nanosecond precision In-Reply-To: <98d49d71-73a7-30f3-bab8-1a80e7ca78e9@oracle.com> References: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> <98d49d71-73a7-30f3-bab8-1a80e7ca78e9@oracle.com> Message-ID: David, Thanks for taking this enhancement, and making it work on the older glibc (pre 2.17) Linux platforms currently supported by openjdk. I like that it is a small change to split the JVM startup check on availability of Posix clock_gettime/getres() APIs and then if additionally CLOCK_MONOTONIC is supported. On Daniel's comment on the spec. Yes the nice part of this is that the JavaDoc on Clock.systemUTC() is worded to allow higher clock resolution than system.currentTimeMillis(). Please let me know if I can help any more on this. Mark On Tue, 26 May 2020 at 16:35, Daniel Fuchs wrote: > Hi David, > > This is not a review for the posix code. > > Your webrev looks good to me and corresponds to what I expected > to see. I understand that not all operating systems / platforms > are expected to have the nano second precision, so your test > probably can't go much beyond what is currently being tested. > > Last time I upgraded the system clock to micro second precision [1] > I had to write a CSR and release notes. That was the first time > the clock went beyond millisecond precision however - and my > expectation is that your proposed change should no longer > require a CSR as potential nanosecond precision should > now be covered by the spec. > > I had to modify a few other places as well (see [1]) - where precision > greater than 1ms was not expected, but these modifications > should cover your current changes too, so I don't think anything > more is required. Some --test-repeat might be in order > to verify things are stable but I don't expect any issue there :-) > > LGTM. > > best regards, > > -- daniel > > [1] https://bugs.openjdk.java.net/browse/JDK-8068730 > > On 26/05/2020 05:59, David Holmes wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8242504 > > webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ > > > > This work was contributed by Mark Kralj-Taylor: > > > > > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html > > > > > > On the hotspot side we change the Linux implementations of > > javaTimeMillis() and javaTimeSystemUTC() so that they use > > clock_gettime(CLOCK_REALTIME) instead of gettimeofday(). In keeping with > > our conditional use of this API I added a new guard > > > > os::Posix::supports_clock_gettime() > > > > and refined the existing supports_monotonic_clock() so that we can still > > use CLOCK_REALTIME if CLOCK_MONOTONIC does not exist. In the future > > (hopefully very near future) we will simply assume these APIs always > exist. > > > > On the core-libs side the existing test: > > > > test/jdk/java/time/test/java/time/TestClock_System.java > > > > is adjusted to track the precision in more detail. > > > > Finally Mark has added instantNowAsEpochNanos() to the benchmark > > previously known as > > > > test/micro/org/openjdk/bench/java/lang/Systems.java > > > > which I've renamed to SystemTime.java as Mark suggested. I agree having > > these three functions measured together makes sense. > > > > Testing: > > - test/jdk/java/time/test/java/time/TestClock_System.java > > - test/micro/org/openjdk/bench/java/lang/SystemTime.java > > - Tiers 1-3 > > > > Thanks, > > David > > From mandy.chung at oracle.com Tue May 26 21:46:12 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 26 May 2020 14:46:12 -0700 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version Message-ID: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> Lookup::defineHiddenClass currently throws IAE by ASM if the given bytes are of unsupported class file version.? The implementation should catch and throw UnsupportedClassVersionError instead. webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.00/ This patch also includes a spec clarification of @throws IAE if the the bytes has ACC_MODULE flag set to fix JDK-8245596. thanks Mandy From claes.redestad at oracle.com Tue May 26 21:49:16 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 26 May 2020 23:49:16 +0200 Subject: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers In-Reply-To: <301145461.1539523.1590519384469.JavaMail.zimbra@u-pem.fr> References: <3ee129e4-d0f3-96e9-9239-52194cb9e09c@oracle.com> <1168727666.821877.1590440019689.JavaMail.zimbra@u-pem.fr> <6e9a8f0a-309c-09c9-c5f4-d47bdcd9c710@oracle.com> <2035955824.845126.1590446912642.JavaMail.zimbra@u-pem.fr> <1709ce91-9dc5-263b-3508-79afce2c5af9@oracle.com> <5D4E5018-B60B-4ABB-81C5-7BBD9D321A51@oracle.com> <301145461.1539523.1590519384469.JavaMail.zimbra@u-pem.fr> Message-ID: <0d29c4bd-e162-32cb-cf50-ad1d720281f5@oracle.com> On 2020-05-26 20:56, forax at univ-mlv.fr wrote: > ----- Mail original ----- >> De: "Claes Redestad" >> ?: "Paul Sandoz" >> Cc: "Remi Forax" , "core-libs-dev" >> Envoy?: Mardi 26 Mai 2020 20:31:51 >> Objet: Re: RFR: 8245756: Reduce bootstrap cost of StringConcatFactory prependers > >> On 2020-05-26 20:02, Paul Sandoz wrote: >>> I prefer the first revision from a simplicity perspective. >>> >>> Are there any measurable benefits in the subsequent revision? It requires some >>> careful reading, where the logic in the prepender is duplicated in the layering >>> of the computeIfAbsent functions. Which, if needed, is fine. >> >> Right, it depends on test. On the ObjStringCombos test there's no >> real gain - on a case where there are more interleaving constants >> it should have more of an effect. >> >> I'll go ahead with the first version and we can think through if there >> are ways to simplify this for a follow-up, maybe along with a fix to >> remove prefix constants altogether. (the trick is to bind in the >> constants without binding more things directly into the main MH >> combinator tree - the complex prependers reduced the possible tree >> shapes a lot) > > I should have shut my big mouth, > i agree that the first patch is actually better. > Ok, I'll go ahead and push that version. /Claes >> >>> >>> Are the existing test sufficient to cover these cases? You referenced >>> ObjStringCombos and I wondering if that makes sense as a combo stress test? >> >> Adding more stress tests that test all combinations at more arities >> would be good. My bootstrap tests as written are a bit poor since I >> don't do any verification apart from checking that they don't crash. >> I'll file a standalone RFE to improve the coverage. >> >> /Claes > > R?mi > >> >>> >>> Paul. >>> >>>> On May 26, 2020, at 9:20 AM, Claes Redestad wrote: >>>> >>>> On 2020-05-26 00:48, forax at univ-mlv.fr wrote: >>>>>> Not sure in which sense you mean inlining? Few of the methods in the >>>>>> bootstrap code are likely hot enough to see inlining by a JIT - and the >>>>>> resulting MHs should be identical, just not constructed over and over >>>>>> again. >>>>> I'm wondering if the code without the null tests was not simple enough to be >>>>> inlined by c1, >>>>> the MH creations tends to do a lot of checks that can be removed even by c1. >>>> >>>> Time spent in prepender() does not seem to be a significant contributor >>>> to bootstrap overhead - time spent in MHs.insertArguments is, though. >>>> >>>> One thing that falls out naturally from this is that prefix can only be >>>> non-null on the first prepender: "foo" + a + "bar" + b ... will bind >>>> both "foo" and "bar" to the a-prepender, then b and subsequent >>>> prependers will never see a prefix constant since it will be bound in >>>> as a suffix of the preceding argument. Thus it makes sense to either >>>> provide a caching mechanism for prependers whose prefix arguments are >>>> pre-bound to null: >>>> >>>> http://cr.openjdk.java.net/~redestad/8245756/open.01 >>>> >>>> We might be able to special-case the first prepender so that we can >>>> remove the prefix argument from prependers in general, which might make >>>> the final MH a bit smaller and easier for the JIT to optimize. >>>> >>>> Testing: tier1+2 >>>> >>>> /Claes From alexey.semenyuk at oracle.com Tue May 26 21:53:47 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Tue, 26 May 2020 17:53:47 -0400 Subject: RFR: JDK-8245202: Convert existing jpackage tests to newer form. In-Reply-To: <04a3031e-9631-e2c8-b8a6-8029f62044fd@oracle.com> References: <3127aec6-d764-d7f7-6cba-026d51734611@oracle.com> <04a3031e-9631-e2c8-b8a6-8029f62044fd@oracle.com> Message-ID: <9bcfcb1c-8c79-a86e-430e-5ad5c475bdc5@oracle.com> Looks good. - Alexey On 5/26/2020 4:43 PM, Andy Herrick wrote: > revised at [3] to combine JavaOptionsTest and JavaOptionsModular tests > > [3] - http://cr.openjdk.java.net/~herrick/8245202/webrev.02/ > > /Andy > > On 5/26/2020 8:08 AM, Andy Herrick wrote: >> Please review the fix to issue [1] at [2]. >> >> The change removes all the old form helper tests and converts the 6 >> remaining tests that used the old helpers into 4 new tests using the >> new helpers. >> >> [1] - https://bugs.openjdk.java.net/browse/JDK-8245202 >> >> [2] - http://cr.openjdk.java.net/~herrick/8245202/webrev.01/ >> >> /Andy >> From claes.redestad at oracle.com Tue May 26 22:03:10 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 27 May 2020 00:03:10 +0200 Subject: Possible optimization in StringLatin1.regionMatchesCI In-Reply-To: References: Message-ID: <8257a192-e586-31b3-7716-69a6eb84a727@oracle.com> So to try and clarify: if (Character.toLowerCase(u1) == Character.toLowerCase(u2)) ... can never happen today in the context of the StringLatin1 version of regionMatchesCI (I did a quick check), and a test that exhaustively tests this property holds should ensure any future unicode updates doesn't trip us (unlikely -- but not theoretically impossible). I think we can go ahead with this. /Claes On 2020-05-26 18:27, Martin Buchholz wrote: > On Tue, May 26, 2020 at 4:07 AM Christoph Dreis > wrote: >> >> Hi Martin, >> >> ?> Not a review, but: >>> Compare with the variant of this code in StringUTF16. >>> StringLatin1 only ever needs to support the first 256 chars in Unicode >> >> Does it really? That makes me wonder even more about the additional lowercase check. >> >>> which can never change, unlike StringUTF16, >> >> What do you mean by "can never change"? > > When we discover sentient life on Titan, their script needs to get > added to Unicode. But the first 256 chars are already fully > allocated; the Titans will be given empty space elsewhere. Hopefully > Unicode won't be clogged by a million emojis at that point. > > There's a real fear of eszett capitalization changing. After centuries > of debate the German Sprachbund will finally decide to (wisely!) > abolish eszett, but Liechtenstein will be the only holdout insisting > that eszett be capitalized to > https://en.wikipedia.org/wiki/Capital_%E1%BA%9E > > Fortunately the code we are reviewing here is Locale-independent, and > so is hopefully immune to the future politics of Liechtenstein. > From alexander.matveev at oracle.com Tue May 26 22:42:30 2020 From: alexander.matveev at oracle.com (alexander.matveev at oracle.com) Date: Tue, 26 May 2020 15:42:30 -0700 Subject: RFR: JDK-8245202: Convert existing jpackage tests to newer form. In-Reply-To: <04a3031e-9631-e2c8-b8a6-8029f62044fd@oracle.com> References: <3127aec6-d764-d7f7-6cba-026d51734611@oracle.com> <04a3031e-9631-e2c8-b8a6-8029f62044fd@oracle.com> Message-ID: <238441ca-2bb8-09ad-f690-c10a68572a61@oracle.com> Looks good. Thanks, Alexander On 5/26/20 1:43 PM, Andy Herrick wrote: > revised at [3] to combine JavaOptionsTest and JavaOptionsModular tests > > [3] - http://cr.openjdk.java.net/~herrick/8245202/webrev.02/ > > /Andy > > On 5/26/2020 8:08 AM, Andy Herrick wrote: >> Please review the fix to issue [1] at [2]. >> >> The change removes all the old form helper tests and converts the 6 >> remaining tests that used the old helpers into 4 new tests using the >> new helpers. >> >> [1] - https://bugs.openjdk.java.net/browse/JDK-8245202 >> >> [2] - http://cr.openjdk.java.net/~herrick/8245202/webrev.01/ >> >> /Andy >> From alexander.matveev at oracle.com Wed May 27 01:34:37 2020 From: alexander.matveev at oracle.com (alexander.matveev at oracle.com) Date: Tue, 26 May 2020 18:34:37 -0700 Subject: RFR: JDK-8245831: Unify code parsing version strings on Mac and Windows In-Reply-To: <8a3f9c48-9561-3a4a-7e07-53a9ebbc1539@oracle.com> References: <21c3ac81-80d4-72bd-7c99-002d4b941d7f@oracle.com> <8a3f9c48-9561-3a4a-7e07-53a9ebbc1539@oracle.com> Message-ID: Hi Alexey, Looks good. Thanks, Alexander On 5/26/20 12:26 PM, Alexey Semenyuk wrote: > Please review fix [2] for jpackage bug [1]. > > Get rid of duplicated code parsing version strings. Move the code > parsing version strings to dedicated classes with unit test coverage. > Also remove Mac specific identifier setting in app's config file from > the shared code. > > - Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8245831 > > [2]?http://cr.openjdk.java.net/~asemenyuk/8245831/webrev.00 > From Yang.Zhang at arm.com Wed May 27 02:59:11 2020 From: Yang.Zhang at arm.com (Yang Zhang) Date: Wed, 27 May 2020 02:59:11 +0000 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> Message-ID: > But to my earlier question. please: can the new instructions be moved into jdk head first, and then merged into the Panama branch, or not? The new instructions can be classified as: 1. Instructions that can be matched with NEON instructions directly. MulVB and SqrtVF have been merged into jdk master already. The patch of AbsV is in review [1]. 2. Instructions that Jdk master has middle end support for, but they cannot be matched with NEON instructions directly. Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new instructions can be moved into jdk master first, but for auto-vectorization, the performance might not get improved. May I have a new patch for these? 3. Panama/Vector API specific instructions Such as Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. These instructions cannot be moved into jdk master first because there isn't middle-end support. Regards Yang [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-May/008861.html -----Original Message----- From: Andrew Haley Sent: Tuesday, May 26, 2020 4:25 PM To: Yang Zhang ; Paul Sandoz Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; nd Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes On 25/05/2020 09:26, Yang Zhang wrote: > In jdk master, what we need to do is that writing m4 file for existing > vector instructions and placed them to a new file aarch64_neon.ad. > If no question, I will do it right away. I'm not entirely sure that such a change is necessary now. In particular, reorganizing the existing vector instructions is IMO excessive, but I admit that it might be an improvement. But to my earlier question. please: can the new instructions be moved into jdk head first, and then merged into the Panama branch, or not? It'd help if this was possible. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From weijun.wang at oracle.com Wed May 27 03:31:43 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 27 May 2020 11:31:43 +0800 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <457AF539-498D-43FF-89BA-B567AE930D99@azul.com> References: <9B4D357B-43E7-4AE3-AE5C-48432309AE24@oracle.com> <457AF539-498D-43FF-89BA-B567AE930D99@azul.com> Message-ID: <35E1389C-302B-4D91-B7E9-13DBB6921179@oracle.com> > On May 27, 2020, at 1:46 AM, Alexey Bakhtin wrote: > > Hello Max, > > Thank you review. > If I understand correctly tls-server-end-point channel binding data is a hash of server certificate. Different SASL protocols could send cbData differently, with different prefix format. Not sure if I understand, what do "Different SASL protocols" mean? Here LdapClient is the application and therefore the "protocol". Are you worried that another SASL mechanism might choose a different prefix? I really find the TLS word in a SASL mechanism strange. It belongs to a different layer. --Max > This is a reason I create TLSChannelBinding class and calculate hash from the LdapClient and add ?tls-server-end-point:? prefix in the JGSS/Kerberos. > > Alexey > >> On 26 May 2020, at 17:50, Weijun Wang wrote: >> >> I have a question on GssKrb5Client.java: >> >> Do you think it's a good idea to let the SASL mechanism understand what TLS binding is? Instead of passing the whole TlsChannelBinding object through a SASL property, is it possible to only pass the actual cbData? After all, the name "com.sun.security.sasl.channelbinding" suggests it's just a general ChannelBinding which is independent with any application level info. >> >> From my reading of the code change, it looks like this cbData can be calculated on the LDAP side. >> >> Thanks, >> Max >> >>> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: >>> >>> Hello, >>> >>> Could you please review the following patch: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8245527 >>> Webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ >>> >>> The Windows LDAP server with LdapEnforceChannelBinding=2 uses the tls-server-end-point channel binding >>> (based on the TLS server certificate). The channel binding data is calculated as following : >>> ? The client calculates a hash of the TLS server certificate. >>> The hash algorithm is selected on the base of the certificate signature algorithm. >>> Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 based >>> ? The channel binding information is the same as defined in rfc4121 [1] with small corrections: >>> ? initiator and acceptor addresses should be set to NULL >>> ? initiator and acceptor address types should be zero. >>> It contradicts to the ?Using Channel Bindings in GSS-API? document [2] that say that >>> the address type should be set to GSS_C_AF_NULLADDR=0xFF, >>> instead of GSS_C_AF_UNSPEC=0x00. >>> >>> This patch introduces changes in the LDAP, SASL and JGSS modules >>> to generate channel binding data automatically if requested by an application. >>> This patch reuses existing org.ietf.jgss.ChannelBinding class implementation but changes >>> initial unspecified address type from CHANNEL_BINDING_AF_NULL_ADDR to CHANNEL_BINDING_AF_UNSPEC. >>> The patch introduces new environment property ?com.sun.jndi.ldap.tls.cbtype? that indicates >>> Channel Binding type that should be used in the LDAPS connection over JGSS/Kerberos. >>> Right now "tls-server-end-point" Channel Binding type is supported only. >>> The client extracts server certificate from the underlying TLS connection and creates >>> Channel Binding data for JGSS/Kerberos authentication if application indicates >>> com.sun.jndi.ldap.tls.cbtype=tls-server-end-point property. >>> Client application should also specify existing "com.sun.jndi.ldap.connect.timeout? property >>> to force and wait TLS handshake completion before JGSS/Kerberos authentication data is generated. >>> >>> [1] - https://tools.ietf.org/html/rfc4121#section-4.1.1.2 >>> >>> [2] - >>> https://docs.oracle.com/cd/E19120-01/open.solaris/819-2145/overview-52/index.html >>> >>> Initial discussion of this issue is available at security-dev list: >>> https://mail.openjdk.java.net/pipermail/security-dev/2019-December/021052.html >>> https://mail.openjdk.java.net/pipermail/security-dev/2020-January/021140.html >>> https://mail.openjdk.java.net/pipermail/security-dev/2020-February/021278.html >>> https://mail.openjdk.java.net/pipermail/security-dev/2020-May/021864.html > From david.holmes at oracle.com Wed May 27 07:24:34 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 May 2020 17:24:34 +1000 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> Message-ID: <8e788353-ced2-f74f-3407-ea4e4d1f1fb3@oracle.com> Hi Mandy, On 27/05/2020 7:46 am, Mandy Chung wrote: > Lookup::defineHiddenClass currently throws IAE by ASM if the given bytes > are of unsupported class file version.? The implementation should catch > and throw UnsupportedClassVersionError instead. > > webrev: > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.00/ What happened to the check: if ((reader.getAccess() & Opcodes.ACC_MODULE) != 0) { ? 2036 if (msg.startsWith("Unsupported class file major version")) { Is that too strict - what if the issue is with the minor version? In general having to parse the ASM exception seems fragile. This code: if (msg.startsWith("Unsupported class file major version")) { UnsupportedClassVersionError ucve = new UnsupportedClassVersionError(msg); ucve.initCause(e); throw ucve; } else { ClassFormatError cfe = new ClassFormatError(); cfe.initCause(e); throw cfe; } could be simplified to: ClassFormatError cfe; if (msg.startsWith("Unsupported class file major version")) { cfe = new UnsupportedClassVersionError(msg); } else { cfe = new ClassFormatError(); } cfe.initCause(e); throw cfe; > This patch also includes a spec clarification of @throws IAE if the > the bytes has ACC_MODULE flag set to fix JDK-8245596. Until I saw what the code did the old versus new text did not seem like a clarification. Might I suggest augmenting rather than replacing the existing text: @throws IllegalArgumentException if {@code bytes} is not a class or interface (the ACC_MODULE flag is set in the value of the {@code access_flags} item) or Note: 1927 * in the value of the {@coode access_flags} item or Typo: coode Also should same change be made to defineHiddenClassWithClassData docs. Thanks, David ----- > thanks > Mandy From david.holmes at oracle.com Wed May 27 07:28:06 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 May 2020 17:28:06 +1000 Subject: RFR(S) 8242504: Enhance the system clock to nanosecond precision In-Reply-To: <194797a0-450b-7fd7-a436-c6d3b49f4ba2@oracle.com> References: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> <194797a0-450b-7fd7-a436-c6d3b49f4ba2@oracle.com> Message-ID: <5c4ae475-fe54-5a19-fb9e-a1e70d9e948b@oracle.com> Thanks Roger! David On 27/05/2020 12:28 am, Roger Riggs wrote: > Looks good. > > Thanks to Mark and you for the improvement and testing. > > > > On 5/26/20 12:59 AM, David Holmes wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8242504 >> webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ >> >> This work was contributed by Mark Kralj-Taylor: >> >> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html >> >> >> On the hotspot side we change the Linux implementations of >> javaTimeMillis() and javaTimeSystemUTC() so that they use >> clock_gettime(CLOCK_REALTIME) instead of gettimeofday(). In keeping >> with our conditional use of this API I added a new guard >> >> os::Posix::supports_clock_gettime() >> >> and refined the existing supports_monotonic_clock() so that we can >> still use CLOCK_REALTIME if CLOCK_MONOTONIC does not exist. In the >> future (hopefully very near future) we will simply assume these APIs >> always exist. >> >> On the core-libs side the existing test: >> >> test/jdk/java/time/test/java/time/TestClock_System.java >> >> is adjusted to track the precision in more detail. >> >> Finally Mark has added instantNowAsEpochNanos() to the benchmark >> previously known as >> >> test/micro/org/openjdk/bench/java/lang/Systems.java >> >> which I've renamed to SystemTime.java as Mark suggested. I agree >> having these three functions measured together makes sense. >> >> Testing: >> ? - test/jdk/java/time/test/java/time/TestClock_System.java >> ? - test/micro/org/openjdk/bench/java/lang/SystemTime.java >> ? - Tiers 1-3 >> >> Thanks, >> David > From david.holmes at oracle.com Wed May 27 07:33:18 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 May 2020 17:33:18 +1000 Subject: RFR(S) 8242504: Enhance the system clock to nanosecond precision In-Reply-To: <98d49d71-73a7-30f3-bab8-1a80e7ca78e9@oracle.com> References: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> <98d49d71-73a7-30f3-bab8-1a80e7ca78e9@oracle.com> Message-ID: Hi Daniel, Thanks for the review on the API side, and for the detailed consideration of any potential spec issues - of which they are none I'm glad to say. Cheers, David On 27/05/2020 1:35 am, Daniel Fuchs wrote: > Hi David, > > This is not a review for the posix code. > > Your webrev looks good to me and corresponds to what I expected > to see. I understand that not all operating systems / platforms > are expected to have the nano second precision, so your test > probably can't go much beyond what is currently being tested. > > Last time I upgraded the system clock to micro second precision [1] > I had to write a CSR and release notes. That was the first time > the clock went beyond millisecond precision however - and my > expectation is that your proposed change should no longer > require a CSR as potential nanosecond precision should > now be covered by the spec. > > I had to modify a few other places as well (see [1]) - where precision > greater than 1ms was not expected, but these modifications > should cover your current changes too, so I don't think anything > more is required. Some --test-repeat might be in order > to verify things are stable but I don't expect any issue there :-) > > LGTM. > > best regards, > > -- daniel > > [1] https://bugs.openjdk.java.net/browse/JDK-8068730 > > On 26/05/2020 05:59, David Holmes wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8242504 >> webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ >> >> This work was contributed by Mark Kralj-Taylor: >> >> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html >> >> >> On the hotspot side we change the Linux implementations of >> javaTimeMillis() and javaTimeSystemUTC() so that they use >> clock_gettime(CLOCK_REALTIME) instead of gettimeofday(). In keeping >> with our conditional use of this API I added a new guard >> >> os::Posix::supports_clock_gettime() >> >> and refined the existing supports_monotonic_clock() so that we can >> still use CLOCK_REALTIME if CLOCK_MONOTONIC does not exist. In the >> future (hopefully very near future) we will simply assume these APIs >> always exist. >> >> On the core-libs side the existing test: >> >> test/jdk/java/time/test/java/time/TestClock_System.java >> >> is adjusted to track the precision in more detail. >> >> Finally Mark has added instantNowAsEpochNanos() to the benchmark >> previously known as >> >> test/micro/org/openjdk/bench/java/lang/Systems.java >> >> which I've renamed to SystemTime.java as Mark suggested. I agree >> having these three functions measured together makes sense. >> >> Testing: >> ?? - test/jdk/java/time/test/java/time/TestClock_System.java >> ?? - test/micro/org/openjdk/bench/java/lang/SystemTime.java >> ?? - Tiers 1-3 >> >> Thanks, >> David > From david.holmes at oracle.com Wed May 27 07:36:59 2020 From: david.holmes at oracle.com (David Holmes) Date: Wed, 27 May 2020 17:36:59 +1000 Subject: RFR(S) 8242504: Enhance the system clock to nanosecond precision In-Reply-To: References: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> <98d49d71-73a7-30f3-bab8-1a80e7ca78e9@oracle.com> Message-ID: Hi Mark, On 27/05/2020 2:15 am, Mark Kralj-Taylor wrote: > David, > Thanks for taking this enhancement, and making it work on the older > glibc (pre 2.17) Linux platforms currently supported by openjdk. > > I like that it is a small change to split the JVM startup check on > availability of Posix clock_gettime/getres() APIs and then if > additionally CLOCK_MONOTONIC is supported. Glad to hear it. I had originally also envisaged something more complex so the simplicity here is appealing. Hopefully for 16 (or else 17) we can get rid of all the legacy support. > On Daniel's comment on the spec. Yes the nice part of this is that the > JavaDoc on Clock.systemUTC() is worded to allow higher clock resolution > than system.currentTimeMillis(). > > Please let me know if I can help any more on this. I think we are set. Your very detailed write-up and the changes to the test and benchmark were a great assist. You've set a very high bar on your first OpenJDK contribution. :) Now I just need someone from hotspot-runtime to sign-off on the VM side. Cheers, David > Mark > > On Tue, 26 May 2020 at 16:35, Daniel Fuchs > wrote: > > Hi David, > > This is not a review for the posix code. > > Your webrev looks good to me and corresponds to what I expected > to see. I understand that not all operating systems / platforms > are expected to have the nano second precision, so your test > probably can't go much beyond what is currently being tested. > > Last time I upgraded the system clock to micro second precision [1] > I had to write a CSR and release notes. That was the first time > the clock went beyond millisecond precision however - and my > expectation is that your proposed change should no longer > require a CSR as potential nanosecond precision should > now be covered by the spec. > > I had to modify a few other places as well (see [1]) - where precision > greater than 1ms was not expected, but these modifications > should cover your current changes too, so I don't think anything > more is required. Some --test-repeat might be in order > to verify things are stable but I don't expect any issue there :-) > > LGTM. > > best regards, > > -- daniel > > [1] https://bugs.openjdk.java.net/browse/JDK-8068730 > > On 26/05/2020 05:59, David Holmes wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8242504 > > webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ > > > > This work was contributed by Mark Kralj-Taylor: > > > > > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html > > > > > > > On the hotspot side we change the Linux implementations of > > javaTimeMillis() and javaTimeSystemUTC() so that they use > > clock_gettime(CLOCK_REALTIME) instead of gettimeofday(). In > keeping with > > our conditional use of this API I added a new guard > > > > os::Posix::supports_clock_gettime() > > > > and refined the existing supports_monotonic_clock() so that we > can still > > use CLOCK_REALTIME if CLOCK_MONOTONIC does not exist. In the future > > (hopefully very near future) we will simply assume these APIs > always exist. > > > > On the core-libs side the existing test: > > > > test/jdk/java/time/test/java/time/TestClock_System.java > > > > is adjusted to track the precision in more detail. > > > > Finally Mark has added instantNowAsEpochNanos() to the benchmark > > previously known as > > > > test/micro/org/openjdk/bench/java/lang/Systems.java > > > > which I've renamed to SystemTime.java as Mark suggested. I agree > having > > these three functions measured together makes sense. > > > > Testing: > >? ? - test/jdk/java/time/test/java/time/TestClock_System.java > >? ? - test/micro/org/openjdk/bench/java/lang/SystemTime.java > >? ? - Tiers 1-3 > > > > Thanks, > > David > From alexey at azul.com Wed May 27 09:42:20 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 27 May 2020 09:42:20 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> Message-ID: <6BFC2C5A-4654-4EBB-B561-A13E72775573@azul.com> Hello Valerie, Unfortunately, Windows LDAP server with LdapEnforceChannelBinding=2 does not accept GSS_C_AF_NULLADDR address type. This is exact reason of these changes. I?ve tried to fix inconsistency of address type value in the latest webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v2/ This fix allows to set GSS_C_AF_UNSPEC address type for the tls-server-end-point channel binding only Regards Alexey > On 26 May 2020, at 23:37, Valerie Peng wrote: > > I am also concerned about the changes in GSSLibStub.c about the default value being GSS_C_AF_UNSPEC instead of GSS_C_AF_NULLADDR (line 194-195). > > Can you try and see if Window works with GSS_C_AF_NULLADDR? If yes, I'd prefer to not changing the default value for addresstype for the same reason which Michael has already stated. > > Thanks, > Valerie > > > On 5/25/2020 8:33 AM, Alexey Bakhtin wrote: >> Hello Michael, Thomas, >> >> Thank you a lot for review and suggestions. >> I?ve fixed most of the issues except of fundamental one >> I need more time to evaluate suggested usage of UnspecEmptyInetAddress subtype. >> >> Updated webrev is available at: >> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v1/ >> >> >> Also, please see my comments below. >> >> Regards >> Alexey >> >> >>> On 24 May 2020, at 02:38, Michael Osipov <1983-01-06 at gmx.net> >>> wrote: >>> >>> Am 2020-05-21 um 09:35 schrieb Alexey Bakhtin: >>> >>>> Hello, >>>> >>>> Could you please review the following patch: >>>> >>>> JBS: >>>> https://bugs.openjdk.java.net/browse/JDK-8245527 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v0/ >>> Let's go through your changes statically: >>> >>> * The JIRA issue title has a typo >>> >> Thank you. Fixed in Jira >> >>> * The word "cannot" is incorrectly spelled throughout all exception messages >>> >> Fixed from ?can not? to ?cannot" >> >>>> + if (cbTypeProp.equals(TlsChannelBindingType.TLS_UNIQUE.getName())) { >>>> + throw new UnsupportedOperationException("LdapCtx: " + >>>> + TlsChannelBindingType.TLS_UNIQUE.getName() + " type is not supported"); >>>> >>> >>> "LdapCtx: " is redundant because the stacktrace will contain the class >>> name already. A better message would be: "Channel binding type '%s' is >>> not supported". Not just the plain value. >>> >> Exception message is corrected >> >>>> + } else if (cbTypeProp.equals(TlsChannelBindingType.TLS_SERVER_END_POINT.getName())) { >>>> + if (connectTimeout == -1) >>>> + throw new IllegalArgumentException(CHANNEL_BINDING_TYPE + " property requires " + >>>> + CONNECT_TIMEOUT + " property is set."); >>>> >>> * Same here with the message >>> >> Not sure, What?s wrong with the message ? >> >>> * The IAE is wrong because passed value is correct, but leads to an >>> invalid state because connection timeout is -1. You need an >>> IllegalStateException here. >>> >> Thank you. You are right again. Changed to IllegalStateException >> >>> Stupid question: how can one create a GSS security context when the TLS >>> security context has not been established yet? >>> >> This logic already existed here. It could be a reason for it and I don?t want change it without strong purpose. >> The only changes here is to prevent double setting of channel binding data. >> >> >>>> --- old/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java 2020-05-18 19:39:46.000000000 +0300 >>>> +++ new/src/java.security.jgss/share/classes/sun/security/jgss/GSSContextImpl.java 2020-05-18 19:39:46.000000000 +0300 >>>> @@ -531,9 +531,12 @@ >>>> public void setChannelBinding(ChannelBinding channelBindings) >>>> throws GSSException { >>>> >>>> - if (mechCtxt == null) >>>> + if (mechCtxt == null) { >>>> + if (this.channelBindings != null) { >>>> + throw new GSSException(GSSException.BAD_BINDINGS); >>>> + } >>>> this.channelBindings = channelBindings; >>>> - >>>> + } >>>> } >>>> >>> I don't understand the purpose of this hunk. Is this safeguard to set >>> bindings only once? >>> >>> >>>> private static final int CHANNEL_BINDING_AF_INET = 2; >>>> private static final int CHANNEL_BINDING_AF_INET6 = 24; >>>> private static final int CHANNEL_BINDING_AF_NULL_ADDR = 255; >>>> + private static final int CHANNEL_BINDING_AF_UNSPEC = 0; >>>> >>> This should sort from 0 to 255 and not at the end. >>> >> OK. Moved to the top. >> >> >>>> private int getAddrType(InetAddress addr) { >>>> - int addressType = CHANNEL_BINDING_AF_NULL_ADDR; >>>> + int addressType = CHANNEL_BINDING_AF_UNSPEC; >>>> >>>> // initialize addrtype in CB first >>>> - cb->initiator_addrtype = GSS_C_AF_NULLADDR; >>>> - cb->acceptor_addrtype = GSS_C_AF_NULLADDR; >>>> + cb->initiator_addrtype = GSS_C_AF_UNSPEC; >>>> + cb->acceptor_addrtype = GSS_C_AF_UNSPEC; >>>> >>> This looks wrong to me -- as you already mentioned -- this violates RFC >>> 2744, section 3.11, last sentence: >>> >>>> or omit addressing information, specifying >>>> GSS_C_AF_NULLADDR as the address-types. >>>> >>>> /* release initiator address */ >>>> - if (cb->initiator_addrtype != GSS_C_AF_NULLADDR) { >>>> + if (cb->initiator_addrtype != GSS_C_AF_NULLADDR && >>>> + cb->initiator_addrtype != GSS_C_AF_UNSPEC) { >>>> resetGSSBuffer(&(cb->initiator_address)); >>>> } >>>> /* release acceptor address */ >>>> - if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR) { >>>> + if (cb->acceptor_addrtype != GSS_C_AF_NULLADDR && >>>> + cb->acceptor_addrtype != GSS_C_AF_UNSPEC) { >>>> resetGSSBuffer(&(cb->acceptor_address)); >>>> } >>>> >>> Unspecified does not mean that it is null. >>> >>> >>>> + final byte[] prefix = (TlsChannelBindingType.TLS_SERVER_END_POINT.getName() + ":").getBytes(); >>>> + byte[] cbData = Arrays.copyOf(prefix, >>>> + prefix.length + tlsCB.getData().length ); >>>> + System.arraycopy(tlsCB.getData(), 0, cbData, prefix.length, tlsCB.getData().length); >>>> >>> Since you are calling "tlsCB.getData()" multiple times, this should go >>> into a variable. >>> >> Temporary variable is added >> >> >>> >>>> + secCtx.setChannelBinding(new >>>> >>> ChannelBinding(null, null, cbData)); >>> >>> Why not use new ChannelBinding(cbData)? >>> >> Right. updated >> >> >>>> + String hashAlg = serverCertificate.getSigAlgName(). >>>> + replace("SHA", "SHA-").toUpperCase(); >>>> + int ind = hashAlg.indexOf("WITH"); >>>> + if (ind > 0) { >>>> + hashAlg = hashAlg.substring(0, ind); >>>> + if (hashAlg.equals("MD5") || hashAlg.equals("SHA-1")) { >>>> + hashAlg = "SHA-256"; >>>> + } >>>> >>> I have several problems with that, some might be hypothetical: >>> >>> * toUpperCase() should be qualified with Locale.ROOT or Locate.ENGLISH >>> >> As you mentioned below AlgorithmId.getName() uses nameTable to return algorithm name. >> Looking at implementation I do not think it is realistic to get name in the non-English locale. >> I do not think it should be fixed >> >> >>> * Looking at https://tools.ietf.org/html/rfc5280#section-4.1.1.2 >>> , then >>> at sun.security.x509.AlgorithmId.getName() it uses nameTable to >>> translate OIDs to readible names. >>> >>> With indexOf("WITH") you are implying that the cert's sig alg may not >>> use a cryptographic function, but this would mean that if the OID is >>> 1.3.14.3.2.26 you'd turn "SHA-X" into "SHA--X" according to nameTable, >>> wouldn't you? >>> I also don't know how realistic "PBEWith..." is. >>> >>> This likely needs more thought or I am missing something. >>> >>> >> I do not think it is realistic scenario to have certificate signature algorithm without crypto function. >> indexOf(?WITH?) just used to find end out hash algorithm name. >> >> >>> * Exception messages are inconsistent. Sometimes "TLS channel binding", >>> sometimes just "channel binding". To avoid misunderstandings it should >>> always read "TLS channel binding..". >>> >>> >> Messages are updated. >> >> >>> Generally, I have two fundemental issues: >>> * How do you know that address type must be UNSPEC and not NULLADDR? >>> Trial and error? >>> >> I did not find any strict specification about TLS Channel Binding format in Windows server. >> So, it was a lot of experiments, reading related forums and docs. >> One of the doc, that turns me to try UNSPEC type is the following: >> >> https://docs.microsoft.com/en-us/archive/blogs/openspecification/ntlm-and-channel-binding-hash-aka-extended-protection-for-authentication >> >> >> >>> * Changing the default address type against the RFC will break every >>> installation using channel bindings relying on it with cross GSS-API >>> implementations. >>> >> I do not like this conflict between UNSPEC and NULLADDR types too, but I do not know How to better solve it. >> The usage of UnspecEmptyInetAddress subtype is not quite clear to me yet. Who set this value and will it change org.ietf.jgss.ChannelBinding public api ? As I understand, Implementation cannot decide (without pplication request), What channel binding type is enabled on the server. >> >> >>> There must be another way to solve this. A system property would also be >>> problematic because if you have a product which connects to MS and >>> non-MS backends at the same time, channel bindings would be broken again. >>> >>> What about introducing a UnspecEmptyInetAddress() which gives the proper >>> AF type, but #getAddress() would return null? This should satisfy the >>> requirements, InitialToken as well as the RFC. this of course needs to >>> be properly passed to native providers too. GssKrb5Client would also >>> need to know that this channel binding is explicitly for Active >>> Directory and not some other, spec-compliant, SASL peer (property on >>> LdapCtx?) >>> >>> One could easily use this for custom code with a SSLServerSocket paired >>> with Java SASL or in C, OpenSSL and Cyrus SASL. >>> >>> Michael >>> >>> PS: Yes, I am a nitpicker. >>> From ecki at zusammenkunft.net Wed May 27 10:12:14 2020 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Wed, 27 May 2020 10:12:14 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <6BFC2C5A-4654-4EBB-B561-A13E72775573@azul.com> References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> , <6BFC2C5A-4654-4EBB-B561-A13E72775573@azul.com> Message-ID: LdapCtxt: 2568 /** 2569 * Sets the read timeout value 2570 */ 2571 private void setChannelBindingType(String cbTypeProp) { Not sure if that javadoc is the right one? And I also wonder if enforcing the timeout is needed, and if yes if it should be documented why. Was not obvious to me, what about having two type names (TlsChannelBindingType.TLS_SERVER_END_POINT and TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT?) This could be configured as a SASL property and it would add the benefit that you don't need the instance specific if in the gssstub native code if you instead have two different types values? Gruss Bernd ________________________________ Von: security-dev im Auftrag von Alexey Bakhtin Gesendet: Mittwoch, Mai 27, 2020 11:43 AM An: Valerie Peng Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Thomas Maslen Betreff: Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos Hello Valerie, Unfortunately, Windows LDAP server with LdapEnforceChannelBinding=2 does not accept GSS_C_AF_NULLADDR address type. This is exact reason of these changes. I ve tried to fix inconsistency of address type value in the latest webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v2/ From weijun.wang at oracle.com Wed May 27 10:25:15 2020 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 27 May 2020 18:25:15 +0800 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: Message-ID: <9ACE8592-2978-45AE-8556-5097199D0CC4@oracle.com> > On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: > > The hash algorithm is selected on the base of the certificate signature algorithm. > Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 According to https://www.rfc-editor.org/rfc/rfc5929#section-4.1, this is the right approach. I'm just curious if you have seen newer signature algorithms like RSASSA-PSS and EdDSA used in reality, since the latest TLS spec already defined ciphersuites around them. Thanks, Max From alexey at azul.com Wed May 27 10:48:13 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 27 May 2020 10:48:13 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> <6BFC2C5A-4654-4EBB-B561-A13E72775573@azul.com> Message-ID: <7688E973-70CF-4B1A-B232-E2B3F981D086@azul.com> Hello Bernd, > On 27 May 2020, at 13:12, Bernd Eckenfels wrote: > > LdapCtxt: > 2568 /** > 2569 * Sets the read timeout value > 2570 */ > 2571 private void setChannelBindingType(String cbTypeProp) { Thank you. This is misprint. Should be ?Sets the channel binding type? About timeout - Yes. It is required. Otherwise, LdapClient does not wait for TLS handshake completion and we can not get TLS server certificate before Channel Binding data is populated. Actually, we can force to wait for handshake completion but what timeout should be set in this case. As mentioned by Danial, information about new property and timeout should be documented in the release notes. For the TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT type name, I do not think it is good approach. If you think different servers could accept different address types for the same Channel Binding type, It would be better to introduce separate boolean compatibility property like ?com.sun.security.sasl.addrtype.compat?. In this case it would be applied not only for tls-server-end-point but for any provided Channel Bindings > > Not sure if that javadoc is the right one? And I also wonder if enforcing the timeout is needed, and if yes if it should be documented why. Was not obvious to me, > > what about having two type names (TlsChannelBindingType.TLS_SERVER_END_POINT and TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT?) > > This could be configured as a SASL property and it would add the benefit that you don't need the instance specific if in the gssstub native code if you instead have two different types values? > > Gruss > Bernd > > Von: security-dev im Auftrag von Alexey Bakhtin > Gesendet: Mittwoch, Mai 27, 2020 11:43 AM > An: Valerie Peng > Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Thomas Maslen > Betreff: Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos > > Hello Valerie, Unfortunately, Windows LDAP server with LdapEnforceChannelBinding=2 does not accept GSS_C_AF_NULLADDR address type. This is exact reason of these changes. I ve tried to fix inconsistency of address type value in the latest webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v2/ From lance.andersen at oracle.com Wed May 27 11:56:15 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 27 May 2020 07:56:15 -0400 Subject: RFR 15 (S): 8245068: Implement Deprecation of RMI Activation In-Reply-To: References: Message-ID: <68E6452C-D8CF-46E1-91A8-7660C963FBD4@oracle.com> Hi Stuart, I think this looks good. I will add myself as a reviewer for the CSR. I would probably create an issue for the release note and create a draft I believe I was asked for that when I was going through my CSR review for removal of the Java EE modules and CORBA. Best Lance > On May 26, 2020, at 3:35 PM, Stuart Marks wrote: > > Hi all, > > Here's the implementation of the recently-posted JEP 385, deprecation of RMI Activation for removal. > > I'm listing this as S ("small") since conceptually it's fairly small, though there are rather a large number of files changed. Essentially the changes are: > > - java.rmi.activation package spec: add deprecation warning > - java.rmi module spec: link to activation package spec > - java.rmi.activation public classes and interfaces: deprecate > - various other files: suppress warnings > - Activation.java: have the rmid tool emit a deprecation warning > - rmid.properties: localized warning message > > Webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8245068/webrev.0/ > > Bug ID: > > https://bugs.openjdk.java.net/browse/JDK-8245068 > > JEP: > > http://openjdk.java.net/jeps/385 > > Thanks, > > s'marks Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From claes.redestad at oracle.com Wed May 27 12:54:47 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 27 May 2020 14:54:47 +0200 Subject: RFR: 8245959: Extend String concat testing to account for folded constants Message-ID: <7ebf5712-a1ea-2eb5-a354-95f79004a507@oracle.com> Hi, Since JDK-8222852 the default String concat strategy aggressively folds string constants into prepender method handles, which means an expression like foo + bar and one like "x" + foo + "y" + bar + "z" will have similar shape, but take slightly different paths through generated code. This patch extends the ImplicitStringConcatShapes test to add more shape variants with surrounding String constants, which should improve coverage and put a bit more stress on the implementation strategy. The changes of interest are in ImplicitStringConcatShapesTestGen - since that's what is used to generate ImplicitStringConcatShapes Bug: https://bugs.openjdk.java.net/browse/JDK-8245959 Webrev: http://cr.openjdk.java.net/~redestad/8245959/open.00/ Testing: tier1 Thanks! /Claes From aleksej.efimov at oracle.com Wed May 27 13:13:14 2020 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Wed, 27 May 2020 14:13:14 +0100 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <7688E973-70CF-4B1A-B232-E2B3F981D086@azul.com> References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> <6BFC2C5A-4654-4EBB-B561-A13E72775573@azul.com> <7688E973-70CF-4B1A-B232-E2B3F981D086@azul.com> Message-ID: Hi Alexey, I have question about timeouts: LdapCtx has 2 timeout properties: connectTimeout and readTimeout. First one is for controlling the Socket::connect timeout (Connection::createSocket), another - for reading out the replies (Connection::readReply). Both of them have default values set to '-1' which means that the LDAP stack would not set any timeouts for connect and/or reading operations. Could you, please, share the failures you're observing with no connect timeout set? Best, Aleksei On 27/05/2020 11:48, Alexey Bakhtin wrote: > Hello Bernd, > >> On 27 May 2020, at 13:12, Bernd Eckenfels wrote: >> >> LdapCtxt: >> 2568 /** >> 2569 * Sets the read timeout value >> 2570 */ >> 2571 private void setChannelBindingType(String cbTypeProp) { > > Thank you. This is misprint. Should be ?Sets the channel binding type? > About timeout - Yes. It is required. Otherwise, LdapClient does not wait for TLS handshake completion and we can not get TLS server certificate before Channel Binding data is populated. > Actually, we can force to wait for handshake completion but what timeout should be set in this case. > As mentioned by Danial, information about new property and timeout should be documented in the release notes. > For the TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT type name, I do not think it is good approach. If you think different servers could accept different address types for the same Channel Binding type, It would be better to introduce separate boolean compatibility property like ?com.sun.security.sasl.addrtype.compat?. In this case it would be applied not only for tls-server-end-point but for any provided Channel Bindings > > >> Not sure if that javadoc is the right one? And I also wonder if enforcing the timeout is needed, and if yes if it should be documented why. Was not obvious to me, >> >> what about having two type names (TlsChannelBindingType.TLS_SERVER_END_POINT and TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT?) >> >> This could be configured as a SASL property and it would add the benefit that you don't need the instance specific if in the gssstub native code if you instead have two different types values? >> >> Gruss >> Bernd >> >> Von: security-dev im Auftrag von Alexey Bakhtin >> Gesendet: Mittwoch, Mai 27, 2020 11:43 AM >> An: Valerie Peng >> Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Thomas Maslen >> Betreff: Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos >> >> Hello Valerie, Unfortunately, Windows LDAP server with LdapEnforceChannelBinding=2 does not accept GSS_C_AF_NULLADDR address type. This is exact reason of these changes. I ve tried to fix inconsistency of address type value in the latest webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v2/ From Roger.Riggs at oracle.com Wed May 27 13:34:32 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 27 May 2020 09:34:32 -0400 Subject: RFR 15 (S): 8245068: Implement Deprecation of RMI Activation In-Reply-To: <68E6452C-D8CF-46E1-91A8-7660C963FBD4@oracle.com> References: <68E6452C-D8CF-46E1-91A8-7660C963FBD4@oracle.com> Message-ID: <3eb57f2a-44ec-ca8c-1449-8d5fafccf7c9@oracle.com> Hi Stuart, Looks good. rmid.properties: 134;? avoid breaking "have\n been" in to separate lines. I would break after the ",". module-info.java: 35:? "version" -> "release" for consistency across the messages. package-info.java: 41:? "version" -> "release" and "it may" -> "may" to be consistent with the wording in other updates. Does this also need a CSR?? (There is one, 8245068, but its all boilerplate). Thanks, Roger On 5/27/20 7:56 AM, Lance Andersen wrote: > Hi Stuart, > > I think this looks good. I will add myself as a reviewer for the CSR. > > I would probably create an issue for the release note and create a draft I believe I was asked for that when I was going through my CSR review for removal of the Java EE modules and CORBA. > > Best > Lance > >> On May 26, 2020, at 3:35 PM, Stuart Marks wrote: >> >> Hi all, >> >> Here's the implementation of the recently-posted JEP 385, deprecation of RMI Activation for removal. >> >> I'm listing this as S ("small") since conceptually it's fairly small, though there are rather a large number of files changed. Essentially the changes are: >> >> - java.rmi.activation package spec: add deprecation warning >> - java.rmi module spec: link to activation package spec >> - java.rmi.activation public classes and interfaces: deprecate >> - various other files: suppress warnings >> - Activation.java: have the rmid tool emit a deprecation warning >> - rmid.properties: localized warning message >> >> Webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/8245068/webrev.0/ >> >> Bug ID: >> >> https://bugs.openjdk.java.net/browse/JDK-8245068 >> >> JEP: >> >> http://openjdk.java.net/jeps/385 >> >> Thanks, >> >> s'marks > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From andy.herrick at oracle.com Wed May 27 14:05:57 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Wed, 27 May 2020 10:05:57 -0400 Subject: RFR: JDK-8245831: Unify code parsing version strings on Mac and Windows In-Reply-To: <8a3f9c48-9561-3a4a-7e07-53a9ebbc1539@oracle.com> References: <21c3ac81-80d4-72bd-7c99-002d4b941d7f@oracle.com> <8a3f9c48-9561-3a4a-7e07-53a9ebbc1539@oracle.com> Message-ID: <59f57b54-dc8c-3cc6-9662-4540aedf541a@oracle.com> looks good curious why app.identifier was added to cfg file.? I don't see it used anywhere. /Andy On 5/26/2020 3:26 PM, Alexey Semenyuk wrote: > Please review fix [2] for jpackage bug [1]. > > Get rid of duplicated code parsing version strings. Move the code > parsing version strings to dedicated classes with unit test coverage. > Also remove Mac specific identifier setting in app's config file from > the shared code. > > - Alexey > > [1] https://bugs.openjdk.java.net/browse/JDK-8245831 > > [2]?http://cr.openjdk.java.net/~asemenyuk/8245831/webrev.00 > From alexey at azul.com Wed May 27 14:14:43 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 27 May 2020 14:14:43 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: <9ACE8592-2978-45AE-8556-5097199D0CC4@oracle.com> References: <9ACE8592-2978-45AE-8556-5097199D0CC4@oracle.com> Message-ID: <2B5DEFB0-6D19-412E-B1D7-B7984D87F7B0@azul.com> Hi Max, You are right, It is possible that algorithm name is not confirm With format. As soon as RFC5929 does not specify this situation I would suggest to use ?SHA-256? hash instead of throwing SaslException exception. Regards Alexey > On 27 May 2020, at 13:25, Weijun Wang wrote: > > > >> On May 21, 2020, at 3:35 PM, Alexey Bakhtin wrote: >> >> The hash algorithm is selected on the base of the certificate signature algorithm. >> Also, the client should use SHA-256 algorithm, in case of the certificate signature algorithm is SHA1 or MD5 > > According to https://www.rfc-editor.org/rfc/rfc5929#section-4.1, this is the right approach. I'm just curious if you have seen newer signature algorithms like RSASSA-PSS and EdDSA used in reality, since the latest TLS spec already defined ciphersuites around them. > > Thanks, > Max From claes.redestad at oracle.com Wed May 27 14:25:33 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 27 May 2020 16:25:33 +0200 Subject: RFR: 8245969: Simplify String concat constant folding Message-ID: <6d0e8f07-baf7-40b5-4e97-4c124364b56e@oracle.com> Hi, please review this patch to StringConcatFactory which (I think) simplifies the folding of constants around arguments by folding any suffix constant into the newArray combinator instead. This simplifies the code in all prependers and in the general flow of the bootstrap code, at the cost of some added complexity around newArray and the new newArrayPrepend combinator. Slightly improves bootstrap and footprint overheads by not having to bind as many arguments to the prependers. Bug: https://bugs.openjdk.java.net/browse/JDK-8245969 Webrev: http://cr.openjdk.java.net/~redestad/8245969/open.00 Testing: tier1+2 Thanks! /Claes From alexey at azul.com Wed May 27 14:57:08 2020 From: alexey at azul.com (Alexey Bakhtin) Date: Wed, 27 May 2020 14:57:08 +0000 Subject: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos In-Reply-To: References: <6071db4a-2b28-2994-cc96-8c119f09ff74@gmx.net> <90F01C9D-9756-4BFB-97EE-7354050F1AF3@azul.com> <6BFC2C5A-4654-4EBB-B561-A13E72775573@azul.com> <7688E973-70CF-4B1A-B232-E2B3F981D086@azul.com> Message-ID: <2037375D-FBEB-491F-803F-F813D9ECB741@azul.com> Hello Aleks, I mean ?com.sun.jndi.ldap.connect.timeout? property. The positive value forces to start TLS handshake and wait for it completion during the connectTimeout milliseconds: Connection.java >> if (connectTimeout > 0) { >> int socketTimeout = sslSocket.getSoTimeout(); >> sslSocket.setSoTimeout(connectTimeout); // reuse full timeout value >> sslSocket.startHandshake(); >> sslSocket.setSoTimeout(socketTimeout); >> } Without this property handshake is started later asynchronously. As result >> certs = ssock.getSession().getPeerCertificates(); in the LdapClient.java could return SSLPeerUnverifiedException(). This exception will be wrapped to NamingException and thrown to application. This is not usually happens but I saw it on the slow connection Alexey > On 27 May 2020, at 16:13, Aleks Efimov wrote: > > Hi Alexey, > > I have question about timeouts: > LdapCtx has 2 timeout properties: connectTimeout and readTimeout. > First one is for controlling the Socket::connect timeout (Connection::createSocket), another - for reading out the replies (Connection::readReply). > Both of them have default values set to '-1' which means that the LDAP stack would not set any timeouts for connect and/or reading operations. > > Could you, please, share the failures you're observing with no connect timeout set? > > Best, > Aleksei > > On 27/05/2020 11:48, Alexey Bakhtin wrote: >> Hello Bernd, >> >>> On 27 May 2020, at 13:12, Bernd Eckenfels wrote: >>> >>> LdapCtxt: >>> 2568 /** >>> 2569 * Sets the read timeout value >>> 2570 */ >>> 2571 private void setChannelBindingType(String cbTypeProp) { >> >> Thank you. This is misprint. Should be ?Sets the channel binding type? >> About timeout - Yes. It is required. Otherwise, LdapClient does not wait for TLS handshake completion and we can not get TLS server certificate before Channel Binding data is populated. >> Actually, we can force to wait for handshake completion but what timeout should be set in this case. >> As mentioned by Danial, information about new property and timeout should be documented in the release notes. >> For the TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT type name, I do not think it is good approach. If you think different servers could accept different address types for the same Channel Binding type, It would be better to introduce separate boolean compatibility property like ?com.sun.security.sasl.addrtype.compat?. In this case it would be applied not only for tls-server-end-point but for any provided Channel Bindings >> >> >>> Not sure if that javadoc is the right one? And I also wonder if enforcing the timeout is needed, and if yes if it should be documented why. Was not obvious to me, >>> >>> what about having two type names (TlsChannelBindingType.TLS_SERVER_END_POINT and TlsChannelBindingType.TLS_SERVER_END_POINT_COMPAT?) >>> >>> This could be configured as a SASL property and it would add the benefit that you don't need the instance specific if in the gssstub native code if you instead have two different types values? >>> >>> Gruss >>> Bernd >>> >>> Von: security-dev im Auftrag von Alexey Bakhtin >>> Gesendet: Mittwoch, Mai 27, 2020 11:43 AM >>> An: Valerie Peng >>> Cc: security-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Thomas Maslen >>> Betreff: Re: RFR: 8245527: LDAP Cnannel Binding support for Java GSS/Kerberos >>> >>> Hello Valerie, Unfortunately, Windows LDAP server with LdapEnforceChannelBinding=2 does not accept GSS_C_AF_NULLADDR address type. This is exact reason of these changes. I ve tried to fix inconsistency of address type value in the latest webrev: http://cr.openjdk.java.net/~abakhtin/8245527/webrev.v2/ From daniel.daugherty at oracle.com Wed May 27 15:09:39 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 27 May 2020 11:09:39 -0400 Subject: RFR(S) 8242504: Enhance the system clock to nanosecond precision In-Reply-To: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> References: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> Message-ID: <708adca8-5a88-e592-19c4-48f26c87b79e@oracle.com> On 5/26/20 12:59 AM, David Holmes wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8242504 > webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ src/hotspot/os/posix/os_posix.hpp ??? No comments. src/hotspot/os/posix/os_posix.inline.hpp ??? No comments. src/hotspot/os/posix/os_posix.cpp ??? old L1686: #ifdef NEEDS_LIBRT ??? old L1687?????? // Close librt if there is no monotonic clock. ??? old L1688?????? if (handle != RTLD_DEFAULT) { ??? old L1689???????? dlclose(handle); ??? old L1690?????? } ??? old L1691 #endif ??????? I don't see any explanation in the bug or in the CR invite ??????? about why this code is deleted when this preceding code ??????? remains: ??????? L1658: ? // For older linux we need librt, for other OS we can find ??????? L1659: ? // this function in regular libc. ??????? L1660: #ifdef NEEDS_LIBRT ??????? L1661: ? // We do dlopen's in this particular order due to bug in linux ??????? L1662: ? // dynamic loader (see 6348968) leading to crash on exit. ??????? L1663: ? handle = dlopen("librt.so.1", RTLD_LAZY); ??????? L1664: ? if (handle == NULL) { ??????? L1665: ??? handle = dlopen("librt.so", RTLD_LAZY); ??????? L1666: ? } ??????? L1667: #endif src/hotspot/os/linux/os_linux.cpp ??? old L1382: ? return jlong(time.tv_sec) * 1000? + jlong(time.tv_usec / 1000); ??? new L1390: ??? return jlong(time.tv_sec) * MILLIUNITS? + ??? new L1391: ?????????? jlong(time.tv_usec) / (MICROUNITS / MILLIUNITS); ??? old L1390: ? nanos = jlong(time.tv_usec) * 1000; ??? new L1407: ??? nanos = jlong(time.tv_usec) * (NANOUNITS / MICROUNITS); ??????? Thanks for replacing the literal 1000s in the old code. test/jdk/java/time/test/java/time/TestClock_System.java ??? L207: ?????????????????????????????? + " millisecond precision: "+countBetterThanMillisPrecision+"/"+1000); ??? L209:? ????????????????????????????? + " microsecond precision: "+countBetterThanMicrosPrecision+"/"+1000); ?????? nit - need spaces around some of the '+' operators. test/micro/org/openjdk/bench/java/lang/SystemTime.java test/micro/org/openjdk/bench/java/lang/Systems.java ??? No comments. My only "concern" is the deletion of closing the librt handle. If you have a good explanation for that, then I'm good with this patch. Dan > > This work was contributed by Mark Kralj-Taylor: > > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html > > > On the hotspot side we change the Linux implementations of > javaTimeMillis() and javaTimeSystemUTC() so that they use > clock_gettime(CLOCK_REALTIME) instead of gettimeofday(). In keeping > with our conditional use of this API I added a new guard > > os::Posix::supports_clock_gettime() > > and refined the existing supports_monotonic_clock() so that we can > still use CLOCK_REALTIME if CLOCK_MONOTONIC does not exist. In the > future (hopefully very near future) we will simply assume these APIs > always exist. > > On the core-libs side the existing test: > > test/jdk/java/time/test/java/time/TestClock_System.java > > is adjusted to track the precision in more detail. > > Finally Mark has added instantNowAsEpochNanos() to the benchmark > previously known as > > test/micro/org/openjdk/bench/java/lang/Systems.java > > which I've renamed to SystemTime.java as Mark suggested. I agree > having these three functions measured together makes sense. > > Testing: > ? - test/jdk/java/time/test/java/time/TestClock_System.java > ? - test/micro/org/openjdk/bench/java/lang/SystemTime.java > ? - Tiers 1-3 > > Thanks, > David From forax at univ-mlv.fr Wed May 27 15:12:56 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 27 May 2020 17:12:56 +0200 (CEST) Subject: RFR: 8245969: Simplify String concat constant folding In-Reply-To: <6d0e8f07-baf7-40b5-4e97-4c124364b56e@oracle.com> References: <6d0e8f07-baf7-40b5-4e97-4c124364b56e@oracle.com> Message-ID: <319948699.2064050.1590592376987.JavaMail.zimbra@u-pem.fr> Hi Claes, so instead of having a prefix and a suffix, there is only a prefix, a suffix being seen as a prefix for the next iteration and if at the end instead of just allocating an array, you allocate an array and stuff it with the last prefix. Are you sure having a suffix at the end is uncommon enough so you use @Stable instead of final for NEW_ARRAY_SUFFIX ? The name of the MH, NEW_ARRAY_SUFFIX, and the name of the method are different "newArrayPrepend", they should be identical, and i think the method should be called "newArrayWithSuffix". I think i would prefer to have only one call to MethodHandles.foldArgumentsWithCombiner, with a variable combiner being either newArray() or newArrayWithSuffix(constant). And constant = constant == null ? constantValue : constant + constantValue; should be constant = constant == null ? constantValue : constant.concat(constantValue); to avoid to create an intermediary StringBuilder (or worst if we are able to solve the boostraping issue of indy and try to use the StringConcatFactory inside itself). I wonder if the code inside newArrayPrepend() can not be simplified given that we know that the suffix will be at the end of the array ? regards, R?mi ----- Mail original ----- > De: "Claes Redestad" > ?: "core-libs-dev" > Envoy?: Mercredi 27 Mai 2020 16:25:33 > Objet: RFR: 8245969: Simplify String concat constant folding > Hi, > > please review this patch to StringConcatFactory which (I think) > simplifies the folding of constants around arguments by folding any > suffix constant into the newArray combinator instead. > > This simplifies the code in all prependers and in the general flow of > the bootstrap code, at the cost of some added complexity around newArray > and the new newArrayPrepend combinator. Slightly improves bootstrap and > footprint overheads by not having to bind as many arguments to the > prependers. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8245969 > Webrev: http://cr.openjdk.java.net/~redestad/8245969/open.00 > > Testing: tier1+2 > > Thanks! > > /Claes From claes.redestad at oracle.com Wed May 27 15:50:19 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 27 May 2020 17:50:19 +0200 Subject: RFR: 8245969: Simplify String concat constant folding In-Reply-To: <319948699.2064050.1590592376987.JavaMail.zimbra@u-pem.fr> References: <6d0e8f07-baf7-40b5-4e97-4c124364b56e@oracle.com> <319948699.2064050.1590592376987.JavaMail.zimbra@u-pem.fr> Message-ID: <3ef8aba5-4d42-09c6-1e70-549ee1139fd9@oracle.com> Hi R?mi, thanks for looking at this. On 2020-05-27 17:12, Remi Forax wrote: > Hi Claes, > so instead of having a prefix and a suffix, there is only a prefix, a suffix being seen as a prefix for the next iteration > and if at the end instead of just allocating an array, you allocate an array and stuff it with the last prefix. Right, a constant will be either a prefix to an argument, or folded in as a suffix on the newArray combinator. Previously, only the first argument prepender could see a non-null prefix, so we were binding in a lot of null values. > > Are you sure having a suffix at the end is uncommon enough so you use @Stable instead of final for NEW_ARRAY_SUFFIX ? The pattern to use @Stable rather than initializing to a final comes from a recent bootstrap stability improvement, see https://bugs.openjdk.java.net/browse/JDK-8218173 This doesn't matter much for bootstrap costs, and AFAICT not at all for the performance of the final MH. > > The name of the MH, NEW_ARRAY_SUFFIX, and the name of the method are different "newArrayPrepend", they should be identical, and i think the method should be called "newArrayWithSuffix". Sure! > > I think i would prefer to have only one call to MethodHandles.foldArgumentsWithCombiner, with a variable combiner being either newArray() or newArrayWithSuffix(constant). Sure! > > And > constant = constant == null ? constantValue : constant + constantValue; > should be > constant = constant == null ? constantValue : constant.concat(constantValue); > to avoid to create an intermediary StringBuilder (or worst if we are able to solve the boostraping issue of indy and try to use the StringConcatFactory inside itself). Not sure I agree. Sure, .concat(..) would remove a StringBuilder, but that's a rather small micro-opt (back to back constants should be rather uncommon). W.r.t. avoiding bootstrapping issues there are several of other string concatenations elsewhere already, so we wouldn't win anything unless we eliminate them all. > > I wonder if the code inside newArrayPrepend() can not be simplified given that we know that the suffix will be at the end of the array ? Not by much, but we could inline part of prepend(long, byte[], String) to avoid a call. http://cr.openjdk.java.net/~redestad/8245969/open.01 OK? /Claes > > regards, > R?mi > > ----- Mail original ----- >> De: "Claes Redestad" >> ?: "core-libs-dev" >> Envoy?: Mercredi 27 Mai 2020 16:25:33 >> Objet: RFR: 8245969: Simplify String concat constant folding > >> Hi, >> >> please review this patch to StringConcatFactory which (I think) >> simplifies the folding of constants around arguments by folding any >> suffix constant into the newArray combinator instead. >> >> This simplifies the code in all prependers and in the general flow of >> the bootstrap code, at the cost of some added complexity around newArray >> and the new newArrayPrepend combinator. Slightly improves bootstrap and >> footprint overheads by not having to bind as many arguments to the >> prependers. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8245969 >> Webrev: http://cr.openjdk.java.net/~redestad/8245969/open.00 >> >> Testing: tier1+2 >> >> Thanks! >> >> /Claes From Alan.Bateman at oracle.com Wed May 27 16:16:33 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 27 May 2020 17:16:33 +0100 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> Message-ID: <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> On 26/05/2020 22:46, Mandy Chung wrote: > Lookup::defineHiddenClass currently throws IAE by ASM if the given > bytes are of unsupported class file version.? The implementation > should catch and throw UnsupportedClassVersionError instead. > > webrev: > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.00/ > > This patch also includes a spec clarification of @throws IAE if the > the bytes has ACC_MODULE flag set to fix JDK-8245596. R?mi - has there ever been any discussion in ASM about throwing more specific exceptions? Only asking to see if we could avoid needing to depend on the exception message here. -Alan From igor.ignatyev at oracle.com Wed May 27 17:25:01 2020 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 27 May 2020 10:25:01 -0700 Subject: RFR(S/T) : 8245874 : requires.extraPropDefns.vmOpts doesn't need -Xbootclasspath/a:bootClasses Message-ID: http://cr.openjdk.java.net/~iignatyev//8245874/webrev.00 > 8 lines changed: 2 ins; 0 del; 6 mod; Hi all, could you please review this small and trivial cleanup in TEST.ROOT files of test/jdk/ and test/hotspot/jtreg test suites? from JBS: > to make sure that classes listed in `requires.extraPropDefns.bootlibs` are in BCP, jtreg automatically adds corresponding `-Xbootclasspath/a:` to the options list, so `requires.extraPropDefns.vmOpts` doesn't have to have `-Xbootclasspath/a:bootClasses` the patch - removes -Xbootclasspath/a:bootClasses from requires.extraPropDefns.vmOpts - moves jdk.test.lib.Platform and Container classes from requires.extraPropDefns.bootlibs to requires.extraPropDefns.libs as there is no need for them to be in BCP JBS: https://bugs.openjdk.java.net/browse/JDK-8245874 testing: tier1 webrev: http://cr.openjdk.java.net/~iignatyev//8245874/webrev.00 Thanks, -- Igor From forax at univ-mlv.fr Wed May 27 17:39:42 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 27 May 2020 19:39:42 +0200 (CEST) Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> Message-ID: <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> Hi Alan, We (the ASM team) recommend to our users to check the byte 6 (and perhaps 7) instead of relying on ASM throwing an exception, because you may update the version of ASM but not the visitors your are using in your code. It's less brittle than catching the IAE thrown by ASM. R?mi ----- Mail original ----- > De: "Alan Bateman" > ?: "mandy chung" , "core-libs-dev" , "Remi Forax" > > Envoy?: Mercredi 27 Mai 2020 18:16:33 > Objet: Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are > of an unsupported major or minor version > On 26/05/2020 22:46, Mandy Chung wrote: >> Lookup::defineHiddenClass currently throws IAE by ASM if the given >> bytes are of unsupported class file version.? The implementation >> should catch and throw UnsupportedClassVersionError instead. >> >> webrev: >> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.00/ >> >> This patch also includes a spec clarification of @throws IAE if the >> the bytes has ACC_MODULE flag set to fix JDK-8245596. > R?mi - has there ever been any discussion in ASM about throwing more > specific exceptions? Only asking to see if we could avoid needing to > depend on the exception message here. > > -Alan From mandy.chung at oracle.com Wed May 27 17:57:32 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 27 May 2020 10:57:32 -0700 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> Message-ID: <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> I'm reconsidering this fix along with JDK-8245061 that may require to do its own checking (a similar issue w.r.t. ASM validation but in this case the constant pool entry of `this_class` item is not validated). thanks Mandy On 5/27/20 10:39 AM, forax at univ-mlv.fr wrote: > Hi Alan, > We (the ASM team) recommend to our users to check the byte 6 (and perhaps 7) instead of relying on ASM throwing an exception, > because you may update the version of ASM but not the visitors your are using in your code. > > It's less brittle than catching the IAE thrown by ASM. > > R?mi > > ----- Mail original ----- >> De: "Alan Bateman" >> ?: "mandy chung" , "core-libs-dev" , "Remi Forax" >> >> Envoy?: Mercredi 27 Mai 2020 18:16:33 >> Objet: Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are >> of an unsupported major or minor version >> On 26/05/2020 22:46, Mandy Chung wrote: >>> Lookup::defineHiddenClass currently throws IAE by ASM if the given >>> bytes are of unsupported class file version.? The implementation >>> should catch and throw UnsupportedClassVersionError instead. >>> >>> webrev: >>> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.00/ >>> >>> This patch also includes a spec clarification of @throws IAE if the >>> the bytes has ACC_MODULE flag set to fix JDK-8245596. >> R?mi - has there ever been any discussion in ASM about throwing more >> specific exceptions? Only asking to see if we could avoid needing to >> depend on the exception message here. >> >> -Alan From raffaello.giulietti at gmail.com Wed May 27 18:02:31 2020 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Wed, 27 May 2020 20:02:31 +0200 Subject: contributing to JDK-8171407: Port fdlibm to Java, part 2 In-Reply-To: <72b9f763-2647-b59a-9b42-22eca48d7706@gmail.com> References: <72b9f763-2647-b59a-9b42-22eca48d7706@gmail.com> Message-ID: Hi, not sure if the lack of replies means that my previous post has been overlooked? Greetings Raffaello On 2020-05-25 18:24, Raffaello Giulietti wrote: > Hi, > > [1] enumerates 14 StrictMath native functions that still need a Java > porting from the original C code. > > As of changeset b84f122ea855 all of them are still native, so I wonder > if it makes sense to contribute or if they have already been ported and > on the launch pad for integration. > > Let me know. > > > Greetings > Raffaello > > ---- > > [1] https://bugs.openjdk.java.net/browse/JDK-8171407 From paul.sandoz at oracle.com Wed May 27 19:20:05 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 27 May 2020 12:20:05 -0700 Subject: RFR: 8245959: Extend String concat testing to account for folded constants In-Reply-To: <7ebf5712-a1ea-2eb5-a354-95f79004a507@oracle.com> References: <7ebf5712-a1ea-2eb5-a354-95f79004a507@oracle.com> Message-ID: Looks good. Paul. > On May 27, 2020, at 5:54 AM, Claes Redestad wrote: > > Hi, > > Since JDK-8222852 the default String concat strategy aggressively folds > string constants into prepender method handles, which means an > expression like foo + bar and one like "x" + foo + "y" + bar + "z" will > have similar shape, but take slightly different paths through generated > code. > > This patch extends the ImplicitStringConcatShapes test to add more > shape variants with surrounding String constants, which should improve > coverage and put a bit more stress on the implementation strategy. > > The changes of interest are in ImplicitStringConcatShapesTestGen - > since that's what is used to generate ImplicitStringConcatShapes > > Bug: https://bugs.openjdk.java.net/browse/JDK-8245959 > Webrev: http://cr.openjdk.java.net/~redestad/8245959/open.00/ > > Testing: tier1 > > Thanks! > > /Claes From claes.redestad at oracle.com Wed May 27 19:20:36 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 27 May 2020 21:20:36 +0200 Subject: RFR: 8245959: Extend String concat testing to account for folded constants In-Reply-To: References: <7ebf5712-a1ea-2eb5-a354-95f79004a507@oracle.com> Message-ID: Thanks, Paul! /Claes On 2020-05-27 21:20, Paul Sandoz wrote: > Looks good. > > Paul. > >> On May 27, 2020, at 5:54 AM, Claes Redestad wrote: >> >> Hi, >> >> Since JDK-8222852 the default String concat strategy aggressively folds >> string constants into prepender method handles, which means an >> expression like foo + bar and one like "x" + foo + "y" + bar + "z" will >> have similar shape, but take slightly different paths through generated >> code. >> >> This patch extends the ImplicitStringConcatShapes test to add more >> shape variants with surrounding String constants, which should improve >> coverage and put a bit more stress on the implementation strategy. >> >> The changes of interest are in ImplicitStringConcatShapesTestGen - >> since that's what is used to generate ImplicitStringConcatShapes >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8245959 >> Webrev: http://cr.openjdk.java.net/~redestad/8245959/open.00/ >> >> Testing: tier1 >> >> Thanks! >> >> /Claes > From stuart.marks at oracle.com Wed May 27 19:30:04 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 27 May 2020 12:30:04 -0700 Subject: RFR 15 (S): 8245068: Implement Deprecation of RMI Activation In-Reply-To: <3eb57f2a-44ec-ca8c-1449-8d5fafccf7c9@oracle.com> References: <68E6452C-D8CF-46E1-91A8-7660C963FBD4@oracle.com> <3eb57f2a-44ec-ca8c-1449-8d5fafccf7c9@oracle.com> Message-ID: On 5/27/20 6:34 AM, Roger Riggs wrote: > rmid.properties: 134;? avoid breaking "have\n been" in to separate lines. > I would break after the ",". Line break adjusted. > module-info.java: 35:? "version" -> "release" for consistency across the messages. > > package-info.java: 41:? "version" -> "release" and "it may" -> "may" to be > consistent > with the wording in other updates. I switched to "version" everywhere since it's consistent with the wording added by javadoc for deprecated elements. For example, https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/Compiler.html > Does this also need a CSR?? (There is one, 8245068, but its all boilerplate). Yes, I'll work on the CSR next. Thanks, s'marks From stuart.marks at oracle.com Wed May 27 19:31:46 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 27 May 2020 12:31:46 -0700 Subject: RFR 15 (S): 8245068: Implement Deprecation of RMI Activation In-Reply-To: <68E6452C-D8CF-46E1-91A8-7660C963FBD4@oracle.com> References: <68E6452C-D8CF-46E1-91A8-7660C963FBD4@oracle.com> Message-ID: <8b939f13-ecd9-6483-779d-e1c735aa5393@oracle.com> Hi Lance, thanks for taking a look at this. On 5/27/20 4:56 AM, Lance Andersen wrote: > I think this looks good. ?I will add myself as a reviewer for the CSR. > > I would probably create an issue for the release note and create a draft I > believe I was asked for that when I was going through my CSR review for removal > of the Java EE modules and CORBA. I'll let you know when the CSR is ready for review. I'll start work on the release note too, good idea. s'marks From forax at univ-mlv.fr Wed May 27 19:34:54 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Wed, 27 May 2020 21:34:54 +0200 (CEST) Subject: RFR: 8245969: Simplify String concat constant folding In-Reply-To: <3ef8aba5-4d42-09c6-1e70-549ee1139fd9@oracle.com> References: <6d0e8f07-baf7-40b5-4e97-4c124364b56e@oracle.com> <319948699.2064050.1590592376987.JavaMail.zimbra@u-pem.fr> <3ef8aba5-4d42-09c6-1e70-549ee1139fd9@oracle.com> Message-ID: <1500543200.2175547.1590608094623.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Claes Redestad" > ?: "Remi Forax" > Cc: "core-libs-dev" > Envoy?: Mercredi 27 Mai 2020 17:50:19 > Objet: Re: RFR: 8245969: Simplify String concat constant folding > Hi R?mi, > > thanks for looking at this. > > On 2020-05-27 17:12, Remi Forax wrote: >> Hi Claes, >> so instead of having a prefix and a suffix, there is only a prefix, a suffix >> being seen as a prefix for the next iteration >> and if at the end instead of just allocating an array, you allocate an array and >> stuff it with the last prefix. > > Right, a constant will be either a prefix to an argument, or folded in > as a suffix on the newArray combinator. Previously, only the first > argument prepender could see a non-null prefix, so we were binding in > a lot of null values. > >> >> Are you sure having a suffix at the end is uncommon enough so you use @Stable >> instead of final for NEW_ARRAY_SUFFIX ? > > The pattern to use @Stable rather than initializing to a final comes > from a recent bootstrap stability improvement, see > https://bugs.openjdk.java.net/browse/JDK-8218173 > > This doesn't matter much for bootstrap costs, and AFAICT not at all for > the performance of the final MH. > >> >> The name of the MH, NEW_ARRAY_SUFFIX, and the name of the method are different >> "newArrayPrepend", they should be identical, and i think the method should be >> called "newArrayWithSuffix". > > Sure! > >> >> I think i would prefer to have only one call to >> MethodHandles.foldArgumentsWithCombiner, with a variable combiner being either >> newArray() or newArrayWithSuffix(constant). > > Sure! > >> >> And >> constant = constant == null ? constantValue : constant + constantValue; >> should be >> constant = constant == null ? constantValue : constant.concat(constantValue); >> to avoid to create an intermediary StringBuilder (or worst if we are able to >> solve the boostraping issue of indy and try to use the StringConcatFactory >> inside itself). > > Not sure I agree. Sure, .concat(..) would remove a StringBuilder, but > that's a rather small micro-opt (back to back constants should be rather > uncommon). > > W.r.t. avoiding bootstrapping issues there are several of other string > concatenations elsewhere already, so we wouldn't win anything unless > we eliminate them all. or one at a time :) But, as you said, this can be done later if we are able to bootstrap the indy/condy impl earlier. > >> >> I wonder if the code inside newArrayPrepend() can not be simplified given that >> we know that the suffix will be at the end of the array ? > > Not by much, but we could inline part of prepend(long, byte[], String) > to avoid a call. > > http://cr.openjdk.java.net/~redestad/8245969/open.01 > > OK? Ok ! > > /Claes R?mi > >> >> regards, >> R?mi >> >> ----- Mail original ----- >>> De: "Claes Redestad" >>> ?: "core-libs-dev" >>> Envoy?: Mercredi 27 Mai 2020 16:25:33 >>> Objet: RFR: 8245969: Simplify String concat constant folding >> >>> Hi, >>> >>> please review this patch to StringConcatFactory which (I think) >>> simplifies the folding of constants around arguments by folding any >>> suffix constant into the newArray combinator instead. >>> >>> This simplifies the code in all prependers and in the general flow of >>> the bootstrap code, at the cost of some added complexity around newArray >>> and the new newArrayPrepend combinator. Slightly improves bootstrap and >>> footprint overheads by not having to bind as many arguments to the >>> prependers. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8245969 >>> Webrev: http://cr.openjdk.java.net/~redestad/8245969/open.00 >>> >>> Testing: tier1+2 >>> >>> Thanks! >>> > >> /Claes From paul.sandoz at oracle.com Wed May 27 20:00:58 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 27 May 2020 13:00:58 -0700 Subject: RFR: 8245969: Simplify String concat constant folding In-Reply-To: <3ef8aba5-4d42-09c6-1e70-549ee1139fd9@oracle.com> References: <6d0e8f07-baf7-40b5-4e97-4c124364b56e@oracle.com> <319948699.2064050.1590592376987.JavaMail.zimbra@u-pem.fr> <3ef8aba5-4d42-09c6-1e70-549ee1139fd9@oracle.com> Message-ID: <81D91430-90A7-4069-92BE-D64CEB56A270@oracle.com> That?s rather elegant. Nicely done. Paul. > On May 27, 2020, at 8:50 AM, Claes Redestad wrote: > > Hi R?mi, > > thanks for looking at this. > > On 2020-05-27 17:12, Remi Forax wrote: >> Hi Claes, >> so instead of having a prefix and a suffix, there is only a prefix, a suffix being seen as a prefix for the next iteration >> and if at the end instead of just allocating an array, you allocate an array and stuff it with the last prefix. > > Right, a constant will be either a prefix to an argument, or folded in > as a suffix on the newArray combinator. Previously, only the first > argument prepender could see a non-null prefix, so we were binding in > a lot of null values. > >> Are you sure having a suffix at the end is uncommon enough so you use @Stable instead of final for NEW_ARRAY_SUFFIX ? > > The pattern to use @Stable rather than initializing to a final comes > from a recent bootstrap stability improvement, see > https://bugs.openjdk.java.net/browse/JDK-8218173 > > This doesn't matter much for bootstrap costs, and AFAICT not at all for > the performance of the final MH. > >> The name of the MH, NEW_ARRAY_SUFFIX, and the name of the method are different "newArrayPrepend", they should be identical, and i think the method should be called "newArrayWithSuffix". > > Sure! > >> I think i would prefer to have only one call to MethodHandles.foldArgumentsWithCombiner, with a variable combiner being either newArray() or newArrayWithSuffix(constant). > > Sure! > >> And >> constant = constant == null ? constantValue : constant + constantValue; >> should be >> constant = constant == null ? constantValue : constant.concat(constantValue); >> to avoid to create an intermediary StringBuilder (or worst if we are able to solve the boostraping issue of indy and try to use the StringConcatFactory inside itself). > > Not sure I agree. Sure, .concat(..) would remove a StringBuilder, but > that's a rather small micro-opt (back to back constants should be rather > uncommon). > > W.r.t. avoiding bootstrapping issues there are several of other string > concatenations elsewhere already, so we wouldn't win anything unless > we eliminate them all. > >> I wonder if the code inside newArrayPrepend() can not be simplified given that we know that the suffix will be at the end of the array ? > > Not by much, but we could inline part of prepend(long, byte[], String) > to avoid a call. > > http://cr.openjdk.java.net/~redestad/8245969/open.01 > > OK? > > /Claes > >> regards, >> R?mi >> ----- Mail original ----- >>> De: "Claes Redestad" >>> ?: "core-libs-dev" >>> Envoy?: Mercredi 27 Mai 2020 16:25:33 >>> Objet: RFR: 8245969: Simplify String concat constant folding >>> Hi, >>> >>> please review this patch to StringConcatFactory which (I think) >>> simplifies the folding of constants around arguments by folding any >>> suffix constant into the newArray combinator instead. >>> >>> This simplifies the code in all prependers and in the general flow of >>> the bootstrap code, at the cost of some added complexity around newArray >>> and the new newArrayPrepend combinator. Slightly improves bootstrap and >>> footprint overheads by not having to bind as many arguments to the >>> prependers. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8245969 >>> Webrev: http://cr.openjdk.java.net/~redestad/8245969/open.00 >>> >>> Testing: tier1+2 >>> >>> Thanks! >>> >>> /Claes From claes.redestad at oracle.com Wed May 27 20:25:30 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 27 May 2020 22:25:30 +0200 Subject: RFR: 8245969: Simplify String concat constant folding In-Reply-To: <1500543200.2175547.1590608094623.JavaMail.zimbra@u-pem.fr> References: <6d0e8f07-baf7-40b5-4e97-4c124364b56e@oracle.com> <319948699.2064050.1590592376987.JavaMail.zimbra@u-pem.fr> <3ef8aba5-4d42-09c6-1e70-549ee1139fd9@oracle.com> <1500543200.2175547.1590608094623.JavaMail.zimbra@u-pem.fr> Message-ID: <02dd0a3e-27da-a93c-fcc1-a9733cca3878@oracle.com> On 2020-05-27 21:34, forax at univ-mlv.fr wrote: >> http://cr.openjdk.java.net/~redestad/8245969/open.01 >> >> OK? > Ok ! > Thanks, R?mi! /Claes From claes.redestad at oracle.com Wed May 27 20:25:42 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 27 May 2020 22:25:42 +0200 Subject: RFR: 8245969: Simplify String concat constant folding In-Reply-To: <81D91430-90A7-4069-92BE-D64CEB56A270@oracle.com> References: <6d0e8f07-baf7-40b5-4e97-4c124364b56e@oracle.com> <319948699.2064050.1590592376987.JavaMail.zimbra@u-pem.fr> <3ef8aba5-4d42-09c6-1e70-549ee1139fd9@oracle.com> <81D91430-90A7-4069-92BE-D64CEB56A270@oracle.com> Message-ID: <5e7086b8-ebbf-f5b0-1006-e7c5a125b9fd@oracle.com> On 2020-05-27 22:00, Paul Sandoz wrote: > That?s rather elegant. Nicely done. > > Paul. Thanks, Paul! /Claes From harold.seigel at oracle.com Wed May 27 20:35:47 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 27 May 2020 13:35:47 -0700 (PDT) Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: <9d7da8af-cda3-693d-1ea1-1db5069fea97@oracle.com> References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> <9d7da8af-cda3-693d-1ea1-1db5069fea97@oracle.com> Message-ID: <9b32addd-d576-268e-61ab-0ac4921d22f5@oracle.com> Hi David, Please review this updated webrev: Incremental webrev: http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.incr.2/ full webrev: http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.2/webrev/ It includes the following changes: * Indentation and simplification changes as suggested below * If a class is not a valid permitted subclass of its sealed super then an IncompatibleClassChangeError exception is thrown (as specified in the JVM Spec) instead of VerifyError. * Added a check that a non-public subclass must be in the same package as its sealed super.? And added appropriate testing. * Method Class.permittedSubtypes() was changed. See also inline comments. On 5/24/2020 10:28 PM, David Holmes wrote: > Hi Harold, > > On 22/05/2020 4:33 am, Harold Seigel wrote: >> Hi David, >> >> Thanks for looking at this!? Please review this new webrev: >> >> ??? http://cr.openjdk.java.net/~hseigel/webrev.01/webrev/ > > I'll list all relevant commens here rather than interspersing below so > that it is easier to track. Mostly nits below, other than the > is_permitted_subclass check in the VM, and the use of ReflectionData > in java.lang.Class. > > -- > > src/hotspot/share/classfile/classFileParser.cpp > > + bool ClassFileParser::supports_sealed_types() { > +?? return _major_version == JVM_CLASSFILE_MAJOR_VERSION && > +???? _minor_version == JAVA_PREVIEW_MINOR_VERSION && > +???? Arguments::enable_preview(); > + } > > Nowe there is too little indentation - the subclauses of the > conjunction expression should align[1] > > + bool ClassFileParser::supports_sealed_types() { > +?? return _major_version == JVM_CLASSFILE_MAJOR_VERSION && > +????????? _minor_version == JAVA_PREVIEW_MINOR_VERSION && > +????????? Arguments::enable_preview(); > + } Fixed. Along with indentation of supports_records(). > > 3791???????????????? if (parsed_permitted_subclasses_attribute) { > 3792?????????????????? classfile_parse_error("Multiple > PermittedSubclasses attributes in class file %s", CHECK); > 3793???????????????? // Classes marked ACC_FINAL cannot have a > PermittedSubclasses attribute. > 3794???????????????? } else if (_access_flags.is_final()) { > 3795?????????????????? classfile_parse_error("PermittedSubclasses > attribute in final class file %s", CHECK); > 3796???????????????? } else { > 3797?????????????????? parsed_permitted_subclasses_attribute = true; > 3798???????????????? } > > The indent of the comment at L3793 is wrong, and its placement is > awkward because it relates to the next condition. But we don't have to > use if-else here as any parse error results in immediate return due to > the CHECK macro. So the above can be reformatted as: > > 3791???????????????? if (parsed_permitted_subclasses_attribute) { > 3792?????????????????? classfile_parse_error("Multiple > PermittedSubclasses attributes in class file %s", CHECK); > 3793???????????????? } > 3794???????????????? // Classes marked ACC_FINAL cannot have a > PermittedSubclasses attribute. > 3795???????????????? if (_access_flags.is_final()) { > 3796?????????????????? classfile_parse_error("PermittedSubclasses > attribute in final class file %s", CHECK); > 3797???????????????? } > 3798???????????????? parsed_permitted_subclasses_attribute = true; Done. > > --- > > src/hotspot/share/oops/instanceKlass.cpp > > The logic in InstanceKlass::has_as_permitted_subclass still does not > implement the rules specified in the JVMS. It only implements a "same > module" check, whereas the JVMS specifies an accessibility requirement > as well. Done. > > ?730 bool InstanceKlass::is_sealed() const { > ?731?? return _permitted_subclasses != NULL && > ?732???????? _permitted_subclasses != > Universe::the_empty_short_array() && > ?733???????? _permitted_subclasses->length() > 0; > ?734 } > > Please align subclauses. Done. > > --- > > src/hotspot/share/prims/jvm.cpp > > 2159?????? objArrayHandle result (THREAD, r); > > Please remove space after "result". Done. > > As we will always create and return an arry, if you reverse these two > statements: > > 2156???? if (length != 0) { > 2157?????? objArrayOop r = > oopFactory::new_objArray(SystemDictionary::String_klass(), > 2158??????????????????????????????????????????????? length, CHECK_NULL); > > and these two: > > 2169?????? return (jobjectArray)JNIHandles::make_local(THREAD, result()); > 2170???? } > > then you can delete > > 2172?? // if it gets to here return an empty array, cases will be: the > class is primitive, or an array, or just not sealed > 2173?? objArrayOop result = > oopFactory::new_objArray(SystemDictionary::String_klass(), 0, > CHECK_NULL); > 2174?? return (jobjectArray)JNIHandles::make_local(env, result); > > The comment there is no longer accurate anyway. Done. > > --- > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp > > 857 static jvmtiError > check_permitted_subclasses_attribute(InstanceKlass* the_class, > 858 InstanceKlass* scratch_class) { > > Please align. Done. > > --- > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp > > 2007?? if (permitted_subclasses != NULL) { > > permitted_subclasses cannot be NULL. I initially thought the bug was > in the nest_members version of this code, but they both have the same > properties: the member is initialized to NULL when the InstanceKlass > is constructed, and set to either the proper array or the > empty_array() when classfile parsing is complete. So redefinition > cannot encounter a NULL value here. Changed the 'if' statement to an assert. > > --- > > src/java.base/share/classes/java/lang/Class.java > > The use of ReflectionData is not correctly implemented. The > ReflectionData instance is not constant but can be replaced when class > redefinition operates. So you cannot do this: > > if (rd.permittedSubclasses != null) { > ??? return rd.permittedSubclasses; > } > > because you may be returning the permittedSubclasses field of a > different Reflectiondata instance. You need to read the field once > into a local and thereafter use it. Similarly with: > > rd.permittedSubclasses = new ClassDesc[0]; > return rd.permittedSubclasses; > > you need to do: > > temp = new ClassDesc[0]; > rd.permittedSubclasses = temp; > return temp; Done. > > I'm wondering now whether using Reflectiondata as the cache for this > is actually the best way to cache it? Perhaps Reflectiondata could be used now and an RFE could be filed to look at this more closely? Thanks, Harold > > Aside: The JEP should explicitly point out that because the > sealed/non-sealed modifiers are not represented in the classfile > directly, they are also not exposed via the java.lang.reflect.Modifier > API. > > --- > > That's it form me. > > Thanks, > David > > [1] https://wiki.openjdk.java.net/display/HotSpot/StyleGuide > "Use good taste to break lines and align corresponding tokens on > adjacent lines." > >> This webrev contains the following significant changes: >> >> ?1. The format/indentation issues in classFileParser.cpp were fixed. >> ?2. Unneeded checks in InstanceKlass::has_as_permitted_subclass() were >> ??? removed and the TRAPS parameter was removed. >> ?3. The changes to klassVtable.* and method.* were reverted. Those >> ??? changes were from when sealed classes were marked as final, and are >> ??? no longer valid. >> ?4. Method getPermittedSubclasses() in Class.java was renamed to >> ??? permittedSubclasses() and its implementation was changed. >> ?5. Variables and methods for 'asm' were renamed from >> ??? 'permittedSubtypes' to 'permittedSubclasses'. >> ?6. Classes for sealed classes tests were changed to start with capital >> ??? letters. >> ?7. Changes to langtools tests were removed from this webrev. They are >> ??? covered by the javac webrev (JDK-8244556). >> ?8. The CSR's for JVMTI, JDWP, and JDI are in progress. >> >> Please also see comments inline. >> >> >> On 5/19/2020 1:26 AM, David Holmes wrote: >>> Hi Harold, >>> >>> Adding serviceability-dev for the serviceability related changes. >>> >>> Nit: "VM support for sealed classes" >>> >>> This RFR covers the VM, core-libs, serviceability and even some >>> langtools tests. AFAICS only the javac changes are not included here >>> so when and where will they be reviewed and under what bug id? >>> Ideally there will be a single JBS issue for "Implementation of JEP >>> 360: Sealed types". It's okay to break up the RFRs across different >>> areas, but it should be done under one bug id. >> The javac changes are being reviewed as bug JDK-8227406.? We >> understand the need to do the reviews under one bug. >>> >>> Overall this looks good. I've looked at all files and mainly have >>> some style nits in various places. But there are some more >>> significant items below. >>> >>> On 14/05/2020 7:09 am, Harold Seigel wrote: >>>> Hi, >>>> >>>> Please review this patch for JVM and Core-libs support for the JEP >>>> 360 Sealed Classes preview feature.? Code changes include the >>>> following: >>>> >>>> ??* Processing of the new PermittedSubclasses attribute to enforce >>>> that >>>> ??? a class or interface, whose super is a sealed class or interface, >>>> ??? must be listed in the super's PermittedSubclasses attribute. >>>> ??* Disallow redefinition of a sealed class or interface if its >>>> ??? redefinition would change its PermittedSubclasses attribute. >>>> ??* Support API's to determine if a class or interface is sealed >>>> and, if >>>> ??? it's sealed, return a list of its permitted subclasses. >>>> ??* asm support for the PermittedSubclasses attribute >>> >>> I assume Remi is providing the upstream support in ASM? :) But also >>> see below ... >>> >>>> >>>> Open Webrev: >>>> http://cr.openjdk.java.net/~vromero/8225056/webrev.00/index.html >>> >>> make/data/jdwp/jdwp.spec >>> >>> There needs to be a sub-task and associated CSR request for this >>> JDWP spec update. I couldn't see this covered anywhere. >>> >>> --- >>> >>> src/hotspot/share/classfile/classFileParser.cpp >>> >>> 3215 u2 >>> ClassFileParser::parse_classfile_permitted_subclasses_attribute(const >>> ClassFileStream* const cfs, >>> 3216 const u1* const permitted_subclasses_attribute_start, >>> 3217 TRAPS) { >>> >>> Indention on L3216/17 needs fixing after the copy'n'edit. >>> >>> 3515?? return _major_version == JVM_CLASSFILE_MAJOR_VERSION && >>> 3516????????????? _minor_version == JAVA_PREVIEW_MINOR_VERSION && >>> 3517????????????? Arguments::enable_preview(); >>> >>> Too much indentation on L3516/17 >>> >>> 3790???????????????? // Check for PermittedSubclasses tag >>> >>> That comment (copied from my nestmates code :) is in the wrong >>> place. It needs to be before >>> >>> 3788???????????? if (tag == vmSymbols::tag_permitted_subclasses()) { >>> >>> >>> Minor nit: I would suggest checking >>> parsed_permitted_subclasses_attribute before checking ACC_FINAL. >>> >>> 3876?? if (parsed_permitted_subclasses_attribute) { >>> 3877???? const u2 num_of_subclasses = >>> parse_classfile_permitted_subclasses_attribute( >>> 3878??????????????????????????????????? cfs, >>> 3879 permitted_subclasses_attribute_start, >>> 3880??????????????????????????????????? CHECK); >>> >>> Although it looks odd the preceding, similarly shaped, sections all >>> indent to the same absolute position. Can you make L3878/78/80 match >>> please. >>> >>> 3882?????? guarantee_property( >>> 3883???????? permitted_subclasses_attribute_length == >>> 3884?????????? sizeof(num_of_subclasses) + sizeof(u2) * >>> num_of_subclasses, >>> 3885???????? "Wrong PermittedSubclasses attribute length in class >>> file %s", CHECK); >>> >>> Nits: please reformat as: >>> >>> 3882?????? guarantee_property( >>> 3883???????? permitted_subclasses_attribute_length == >>> sizeof(num_of_subclasses) + sizeof(u2) * num_of_subclasses, >>> 3885???????? "Wrong PermittedSubclasses attribute length in class >>> file %s", CHECK); >>> >>> It would also look slightly better if you shortened the name of the >>> num_of_subclasses variable. >> All of the above classFileParser.cpp changes were done. >>> >>> --- >>> >>> src/hotspot/share/classfile/classFileParser.hpp >>> >>> +?? u2 parse_classfile_permitted_subclasses_attribute(const >>> ClassFileStream* const cfs, >>> +???????????????????????????????????????????? const u1* const >>> permitted_subclasses_attribute_start, >>> +???????????????????????????????????????????? TRAPS); >>> >>> Please fix indentation after copy'n'edit. >> Done. >>> >>> --- >>> >>> src/hotspot/share/oops/instanceKlass.cpp >>> >>> ?247?? if (classloader1 != classloader2) { >>> >>> I'm not clear what rule this is verifying. The same module check >>> follows this one. The rule is that the subclass must be accessible >>> to the superclass implying: >>> 1. same named module (regardless of class access modifiers); or >>> 2. (implicitly in un-named module) same package if subclass not >>> public; or >>> 3. public subclass >>> >>> Having the same classloader implies same package, but that alone >>> doesn't address 2 or 3. So this doesn't conform to proposed JVMS rules. >> This was discussed as part of the CSR and hopefully clarified. >>> >>> >>> >>> ?264???? if (_constants->tag_at(cp_index).is_klass()) { >>> ?265?????? Klass* k2 = _constants->klass_at(cp_index, CHECK_false); >>> >>> You've copied this code from the nestmember checks but your changes >>> don't quite make sense to me. If we have already checked is_klass() >>> then klass_at() cannot lead to any exceptions. >>> >>> ?272?????? if (name == k->name()) { >>> ?273???????? log_trace(class, sealed)("- Found it at >>> permitted_subclasses[%d] => cp[%d]", i, cp_index); >>> ?274???????? return true; >>> >>> I was wondering why you don't resolve the cp entry when you find the >>> name matches, as we do for nest members, but realized that unlike >>> the nest membership check, which can happen many times for a given >>> class, this permitted subclass check can only happen once per class. >>> As you don't actually resolve here, and given that the earlier check >>> cannot throw exceptions, it follows that the entire method never >>> results in any exceptions and so callers should not be using the >>> CHECK macro. >> >> The comparison of class loaders was removed because checking that the >> two classes are in the same module ensures that they have the same >> class loader. >> >> The traps parameter was removed.? The CHECK macro was replaced with >> THREAD. >> >>> >>> --- >>> >>> src/hotspot/share/oops/method.cpp >>> >>> I don't understand how knowing the class is sealed allows you to >>> infer that a non-final method is actually final ?? >> This change was removed.? See item #3 at the beginning of this email. >>> >>> --- >>> >>> ?src/hotspot/share/prims/jvm.cpp >>> >>> It would be simpler (and cheaper) if the Java side of this ensures >>> it doesn't call into the VM with an array or primitive class. >> Done. >>> >>> --- >>> >>> ?src/hotspot/share/prims/jvmti.xml >>> >>> The JVM TI spec changes also need to be covered by a CSR request. >>> >>> --- >>> >>> src/hotspot/share/prims/jvmtiRedefineClasses.cpp >>> >>> We should file a RFE to refactor the logic that checks that an >>> attribute consisting of a list of classes has not changed. :) >> Serguei filed the RFE. >>> >>> Aside: I spotted a bug in the nest member code (missing NULL check!) >>> thanks to your change :) >>> >>> --- >>> >>> src/java.base/share/classes/java/lang/Class.java >>> >>> There needs to be a CSR request for these changes. >> The CSR is JDK-8244556. >>> >>> +????? * Returns an array containing {@code ClassDesc} objects >>> representing all the >>> +????? * permitted subclasses of this {@linkplain Class} if it is >>> sealed. Returns an empty array if this >>> +????? * {@linkplain Class} is not sealed. >>> >>> should add "or this class represents an array or primitive type" >>> (using the standard wording for such cases). >> Discussed off-line and was decided that this text isn't needed. >>> >>> +????? * @throws IllegalArgumentException if a class descriptor is >>> not in the correct format >>> >>> IllegalArgumentException is not an appropriate exception to use as >>> this method takes no arguments. If the class descriptor is not valid >>> and it comes from the VM then I think we have a problem with how the >>> VM validates class descriptors. Any IAE from ClassDesc.of should be >>> caught and converted to a more suitable exception type - preferably >>> InternalError if the VM should always return valid strings. >> Done. >>> >>> +???? public ClassDesc[] getPermittedSubclasses() { >>> >>> As mentioned for jvm.cpp this Java code should do the isArray() and >>> isPrimitive() check before calling the VM. >> Done. >>> >>> +???????? String[] descriptors = getPermittedSubclasses0(); >>> >>> Nit: what you get from the VM are not descriptors, just name strings >>> in internal form. This wouldn't really matter except it then looks >>> strange to call ClassDesc.of(...) instead of >>> ClassDesc.ofDescriptor(...). >> We tried using ClassDesc.ofDescriptor() but encountered problems. The >> variable 'descriptors' was renamed 'subclassNames'. >>> >>> +???????? if (descriptors == null >>> >>> The VM never returns null. >> The check was removed. >>> >>> +???????? return getPermittedSubclasses().length != 0; >>> >>> It's grossly inefficient to create the ClassDesc array and then >>> throw it away IMO. The result should be cached either in a field of >>> Class or in the ReflectionData of the class. >> Done. >>> >>> --- >>> >>> src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java >>> >>> >>> !???????? // - The offset of the PermittedSubclasses attribute, or 0 >>> ????????? int permittedSubtypesOffset = 0; >>> >>> Obviously ASM already has some prelim support for sealed classes, >>> but now that the attribute has been renamed that should also flow >>> through to the ASM code ie the variable, not just the comment. >>> >>> Ditto for ClassWriter.java and its fields. >> Done. >>> >>> --- >>> >>> src/java.base/share/native/libjava/Class.c >>> >>> ????? {"isRecord0",??????????? "()Z",???????? (void *)&JVM_IsRecord}, >>> +???? {"getPermittedSubclasses0", "()[" STR,??? (void >>> *)&JVM_GetPermittedSubclasses}, >>> >>> please align (void >>> >> Done. >>> --- >>> >>> src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java >>> >>> src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java >>> >>> There needs to be a CSR for these changes too. >>> >>> --- >>> >>> test/langtools/tools/javac/processing/model/TestSourceVersion.java >>> >>> !??????????????????? // Assume "record" and "sealed" will be >>> restricted keywords. >>> !??????????????????? "record", "sealed"); >>> >>> What about the non-sealed keyword defined in the JEP? >> 'non-sealed' is a keyword but not a restricted keyword.? So, it >> should not be in the list. >>> >>> --- >>> >>> In the tests you don't need to explicitly include >>> sun.hotspot.WhiteBox$WhiteBoxPermission on the ClassFileInstaller >>> invocation. (previous RFE's have been removing existing occurrences >>> after the CFI was fixed to handle it internally). >> Done. >>> >>> Please ensure all new tests have an @bug 8225056 (or whatever the >>> actual JBS issue will be) >> Done. >>> >>> All test classes (and thus files) should be named in camel-case i.e. >>> C1 not c1, C2 not c2, SuperClass not superClass etc. >> Done. >>> >>> >>> test/hotspot/jtreg/runtime/modules/sealedP1/superClass.jcod >>> test/hotspot/jtreg/runtime/sealedClasses/Pkg/sealedInterface.jcod >>> >>> Please add comments clarifying why these must be jcod files. >> >> Done. >> >> Thanks!? Harold >> >>> >>> --- >>> >>> That's it from me. >>> >>> Thanks, >>> David >>> ----- >>> >>> >>> >>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8225056 >>>> >>>> Java Language Spec changes: >>>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html >>>> >>>> >>>> JVM Spec changes: >>>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jvms.html >>>> >>>> >>>> JEP 360: https://bugs.openjdk.java.net/browse/JDK-8227043 >>>> >>>> JVM CSR: https://bugs.openjdk.java.net/browse/JDK-8242578 >>>> >>>> Changes to javac and other language tools will be reviewed separately. >>>> >>>> Thanks, Harold >>>> >>>> From joe.darcy at oracle.com Wed May 27 21:44:34 2020 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 27 May 2020 14:44:34 -0700 Subject: contributing to JDK-8171407: Port fdlibm to Java, part 2 In-Reply-To: <72b9f763-2647-b59a-9b42-22eca48d7706@gmail.com> References: <72b9f763-2647-b59a-9b42-22eca48d7706@gmail.com> Message-ID: <22cbf997-0b1b-9cd2-602d-271bdc9875ae@oracle.com> Hi Raffaello, Finishing the fdlibm port remains on my to-do list. Given the review investment needed, I would not find it helpful for someone else to contribute a port. Thanks, -Joe On 5/25/2020 9:24 AM, Raffaello Giulietti wrote: > Hi, > > [1] enumerates 14 StrictMath native functions that still need a Java > porting from the original C code. > > As of changeset b84f122ea855 all of them are still native, so I wonder > if it makes sense to contribute or if they have already been ported > and on the launch pad for integration. > > Let me know. > > > Greetings > Raffaello > > ---- > > [1] https://bugs.openjdk.java.net/browse/JDK-8171407 From david.holmes at oracle.com Thu May 28 02:08:08 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 May 2020 12:08:08 +1000 Subject: RFR(S) 8242504: Enhance the system clock to nanosecond precision In-Reply-To: <708adca8-5a88-e592-19c4-48f26c87b79e@oracle.com> References: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> <708adca8-5a88-e592-19c4-48f26c87b79e@oracle.com> Message-ID: Hi Dan, Thanks for taking a look. On 28/05/2020 1:09 am, Daniel D. Daugherty wrote: > On 5/26/20 12:59 AM, David Holmes wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8242504 >> webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ > > src/hotspot/os/posix/os_posix.hpp > ??? No comments. > > src/hotspot/os/posix/os_posix.inline.hpp > ??? No comments. > > src/hotspot/os/posix/os_posix.cpp > ??? old L1686: #ifdef NEEDS_LIBRT > ??? old L1687?????? // Close librt if there is no monotonic clock. > ??? old L1688?????? if (handle != RTLD_DEFAULT) { > ??? old L1689???????? dlclose(handle); > ??? old L1690?????? } > ??? old L1691 #endif > ??????? I don't see any explanation in the bug or in the CR invite > ??????? about why this code is deleted when this preceding code > ??????? remains: > > ??????? L1658: ? // For older linux we need librt, for other OS we can > find > ??????? L1659: ? // this function in regular libc. > ??????? L1660: #ifdef NEEDS_LIBRT > ??????? L1661: ? // We do dlopen's in this particular order due to bug > in linux > ??????? L1662: ? // dynamic loader (see 6348968) leading to crash on exit. > ??????? L1663: ? handle = dlopen("librt.so.1", RTLD_LAZY); > ??????? L1664: ? if (handle == NULL) { > ??????? L1665: ??? handle = dlopen("librt.so", RTLD_LAZY); > ??????? L1666: ? } > ??????? L1667: #endif Sorry I should have mentioned this. In the existing code if we don't have CLOCK_MONOTONIC support we will never use the dynamic handles to clock_gettime and so we can close librt again (if we loaded it for clock_gettime). With the new code we will always use clock_gettime so we can't unload librt (if we needed it for clock_gettime) just because there is no CLOCK_MONOTONIC. The existing code (and thus the new code) is technically missing something here: 1675 if (clock_getres_func != NULL && clock_gettime_func != NULL) { ... 1693 } There could be an else clause that closes librt if it was loaded. But the reality is that these functions are present in librt so we should never reach such an else clause. Closing the handle to librt is a minor "good citizen" act. This will all be moot in the not too distant future when we rely on these functions being in libc on all platforms. > src/hotspot/os/linux/os_linux.cpp > ??? old L1382: ? return jlong(time.tv_sec) * 1000? + jlong(time.tv_usec > / 1000); > ??? new L1390: ??? return jlong(time.tv_sec) * MILLIUNITS? + > ??? new L1391: ?????????? jlong(time.tv_usec) / (MICROUNITS / MILLIUNITS); > > ??? old L1390: ? nanos = jlong(time.tv_usec) * 1000; > ??? new L1407: ??? nanos = jlong(time.tv_usec) * (NANOUNITS / MICROUNITS); > ??????? Thanks for replacing the literal 1000s in the old code. > > test/jdk/java/time/test/java/time/TestClock_System.java > ??? L207: ?????????????????????????????? + " millisecond precision: > "+countBetterThanMillisPrecision+"/"+1000); > ??? L209:? ????????????????????????????? + " microsecond precision: > "+countBetterThanMicrosPrecision+"/"+1000); > ?????? nit - need spaces around some of the '+' operators. Fixed. > test/micro/org/openjdk/bench/java/lang/SystemTime.java > test/micro/org/openjdk/bench/java/lang/Systems.java > ??? No comments. > > My only "concern" is the deletion of closing the librt handle. > If you have a good explanation for that, then I'm good with this patch. Thanks again. I'll wait for your thumbs up on the explanation. David ----- > Dan > > > >> >> This work was contributed by Mark Kralj-Taylor: >> >> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html >> >> >> On the hotspot side we change the Linux implementations of >> javaTimeMillis() and javaTimeSystemUTC() so that they use >> clock_gettime(CLOCK_REALTIME) instead of gettimeofday(). In keeping >> with our conditional use of this API I added a new guard >> >> os::Posix::supports_clock_gettime() >> >> and refined the existing supports_monotonic_clock() so that we can >> still use CLOCK_REALTIME if CLOCK_MONOTONIC does not exist. In the >> future (hopefully very near future) we will simply assume these APIs >> always exist. >> >> On the core-libs side the existing test: >> >> test/jdk/java/time/test/java/time/TestClock_System.java >> >> is adjusted to track the precision in more detail. >> >> Finally Mark has added instantNowAsEpochNanos() to the benchmark >> previously known as >> >> test/micro/org/openjdk/bench/java/lang/Systems.java >> >> which I've renamed to SystemTime.java as Mark suggested. I agree >> having these three functions measured together makes sense. >> >> Testing: >> ? - test/jdk/java/time/test/java/time/TestClock_System.java >> ? - test/micro/org/openjdk/bench/java/lang/SystemTime.java >> ? - Tiers 1-3 >> >> Thanks, >> David > From daniel.daugherty at oracle.com Thu May 28 02:52:17 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 27 May 2020 22:52:17 -0400 Subject: RFR(S) 8242504: Enhance the system clock to nanosecond precision In-Reply-To: References: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> <708adca8-5a88-e592-19c4-48f26c87b79e@oracle.com> Message-ID: > I'll wait for your thumbs up on the explanation. I'm good with the explanation. Thanks! Dan On 5/27/20 10:08 PM, David Holmes wrote: > Hi Dan, > > Thanks for taking a look. > > On 28/05/2020 1:09 am, Daniel D. Daugherty wrote: >> On 5/26/20 12:59 AM, David Holmes wrote: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8242504 >>> webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ >> >> src/hotspot/os/posix/os_posix.hpp >> ???? No comments. >> >> src/hotspot/os/posix/os_posix.inline.hpp >> ???? No comments. >> >> src/hotspot/os/posix/os_posix.cpp >> ???? old L1686: #ifdef NEEDS_LIBRT >> ???? old L1687?????? // Close librt if there is no monotonic clock. >> ???? old L1688?????? if (handle != RTLD_DEFAULT) { >> ???? old L1689???????? dlclose(handle); >> ???? old L1690?????? } >> ???? old L1691 #endif >> ???????? I don't see any explanation in the bug or in the CR invite >> ???????? about why this code is deleted when this preceding code >> ???????? remains: >> >> ???????? L1658: ? // For older linux we need librt, for other OS we >> can find >> ???????? L1659: ? // this function in regular libc. >> ???????? L1660: #ifdef NEEDS_LIBRT >> ???????? L1661: ? // We do dlopen's in this particular order due to >> bug in linux >> ???????? L1662: ? // dynamic loader (see 6348968) leading to crash on >> exit. >> ???????? L1663: ? handle = dlopen("librt.so.1", RTLD_LAZY); >> ???????? L1664: ? if (handle == NULL) { >> ???????? L1665: ??? handle = dlopen("librt.so", RTLD_LAZY); >> ???????? L1666: ? } >> ???????? L1667: #endif > > Sorry I should have mentioned this. In the existing code if we don't > have CLOCK_MONOTONIC support we will never use the dynamic handles to > clock_gettime and so we can close librt again (if we loaded it for > clock_gettime). > > With the new code we will always use clock_gettime so we can't unload > librt (if we needed it for clock_gettime) just because there is no > CLOCK_MONOTONIC. > > The existing code (and thus the new code) is technically missing > something here: > > 1675?? if (clock_getres_func != NULL && clock_gettime_func != NULL) { > ... > 1693?? } > > There could be an else clause that closes librt if it was loaded. But > the reality is that these functions are present in librt so we should > never reach such an else clause. Closing the handle to librt is a > minor "good citizen" act. This will all be moot in the not too distant > future when we rely on these functions being in libc on all platforms. > >> src/hotspot/os/linux/os_linux.cpp >> ???? old L1382: ? return jlong(time.tv_sec) * 1000? + >> jlong(time.tv_usec / 1000); >> ???? new L1390: ??? return jlong(time.tv_sec) * MILLIUNITS? + >> ???? new L1391: ?????????? jlong(time.tv_usec) / (MICROUNITS / >> MILLIUNITS); >> >> ???? old L1390: ? nanos = jlong(time.tv_usec) * 1000; >> ???? new L1407: ??? nanos = jlong(time.tv_usec) * (NANOUNITS / >> MICROUNITS); >> ???????? Thanks for replacing the literal 1000s in the old code. >> >> test/jdk/java/time/test/java/time/TestClock_System.java >> ???? L207: ?????????????????????????????? + " millisecond precision: >> "+countBetterThanMillisPrecision+"/"+1000); >> ???? L209:? ????????????????????????????? + " microsecond precision: >> "+countBetterThanMicrosPrecision+"/"+1000); >> ??????? nit - need spaces around some of the '+' operators. > > Fixed. > >> test/micro/org/openjdk/bench/java/lang/SystemTime.java >> test/micro/org/openjdk/bench/java/lang/Systems.java >> ???? No comments. >> >> My only "concern" is the deletion of closing the librt handle. >> If you have a good explanation for that, then I'm good with this patch. > > Thanks again. I'll wait for your thumbs up on the explanation. > > David > ----- > >> Dan >> >> >> >>> >>> This work was contributed by Mark Kralj-Taylor: >>> >>> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html >>> >>> >>> On the hotspot side we change the Linux implementations of >>> javaTimeMillis() and javaTimeSystemUTC() so that they use >>> clock_gettime(CLOCK_REALTIME) instead of gettimeofday(). In keeping >>> with our conditional use of this API I added a new guard >>> >>> os::Posix::supports_clock_gettime() >>> >>> and refined the existing supports_monotonic_clock() so that we can >>> still use CLOCK_REALTIME if CLOCK_MONOTONIC does not exist. In the >>> future (hopefully very near future) we will simply assume these APIs >>> always exist. >>> >>> On the core-libs side the existing test: >>> >>> test/jdk/java/time/test/java/time/TestClock_System.java >>> >>> is adjusted to track the precision in more detail. >>> >>> Finally Mark has added instantNowAsEpochNanos() to the benchmark >>> previously known as >>> >>> test/micro/org/openjdk/bench/java/lang/Systems.java >>> >>> which I've renamed to SystemTime.java as Mark suggested. I agree >>> having these three functions measured together makes sense. >>> >>> Testing: >>> ? - test/jdk/java/time/test/java/time/TestClock_System.java >>> ? - test/micro/org/openjdk/bench/java/lang/SystemTime.java >>> ? - Tiers 1-3 >>> >>> Thanks, >>> David >> From mandy.chung at oracle.com Thu May 28 04:13:33 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 27 May 2020 21:13:33 -0700 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> Message-ID: <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> Updated webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.01/ I modify this patch to check the class file version and throws CFE if unsupported before creating ClassReader.? This also fixes JDK-8245061 that it reads the value of `this_class` as a constant (as ASM will throw an exception if it's not a constant) and also ensures that `this_class` is a CONSTANT_Class_info by checking the descriptor string from Type. Mandy On 5/27/20 10:57 AM, Mandy Chung wrote: > I'm reconsidering this fix along with JDK-8245061 that may require to > do its own checking (a similar issue w.r.t. ASM validation but in this > case the constant pool entry of `this_class` item is not validated). > > thanks > Mandy > > On 5/27/20 10:39 AM, forax at univ-mlv.fr wrote: >> Hi Alan, >> We (the ASM team) recommend to our users to check the byte 6 (and >> perhaps 7) instead of relying on ASM throwing an exception, >> because you may update the version of ASM but not the visitors your >> are using in your code. >> >> It's less brittle than catching the IAE thrown by ASM. >> >> R?mi >> >> ----- Mail original ----- >>> De: "Alan Bateman" >>> ?: "mandy chung" , "core-libs-dev" >>> , "Remi Forax" >>> >>> Envoy?: Mercredi 27 Mai 2020 18:16:33 >>> Objet: Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw >>> UnsupportedClassVersionError if the given bytes are >>> of an unsupported major or minor version >>> On 26/05/2020 22:46, Mandy Chung wrote: >>>> Lookup::defineHiddenClass currently throws IAE by ASM if the given >>>> bytes are of unsupported class file version.? The implementation >>>> should catch and throw UnsupportedClassVersionError instead. >>>> >>>> webrev: >>>> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.00/ >>>> >>>> This patch also includes a spec clarification of @throws IAE if the >>>> the bytes has ACC_MODULE flag set to fix JDK-8245596. >>> R?mi - has there ever been any discussion in ASM about throwing more >>> specific exceptions? Only asking to see if we could avoid needing to >>> depend on the exception message here. >>> >>> -Alan > From mandy.chung at oracle.com Thu May 28 04:18:37 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 27 May 2020 21:18:37 -0700 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <8e788353-ced2-f74f-3407-ea4e4d1f1fb3@oracle.com> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <8e788353-ced2-f74f-3407-ea4e4d1f1fb3@oracle.com> Message-ID: On 5/27/20 12:24 AM, David Holmes wrote: > Hi Mandy, > > On 27/05/2020 7:46 am, Mandy Chung wrote: >> Lookup::defineHiddenClass currently throws IAE by ASM if the given >> bytes are of unsupported class file version.? The implementation >> should catch and throw UnsupportedClassVersionError instead. >> >> webrev: >> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.00/ > > What happened to the check: > > if ((reader.getAccess() & Opcodes.ACC_MODULE) != 0) { > > ? > Thanks for catching.? It was unintentionally taken out. > 2036 if (msg.startsWith("Unsupported class file major version")) { > > Is that too strict - what if the issue is with the minor version? In > general having to parse the ASM exception seems fragile. > I have revised this patch to check the version explicitly. > >> This patch also includes a spec clarification of @throws IAE if the >> the bytes has ACC_MODULE flag set to fix JDK-8245596. > > Until I saw what the code did the old versus new text did not seem > like a clarification. Might I suggest augmenting rather than replacing > the existing text: > > @throws IllegalArgumentException if {@code bytes} is not a class or > interface (the ACC_MODULE flag is set in the value of the {@code > access_flags} item) or > This is good.? I include this suggestion in the updated webrev.01 (see my other reply); > > Note: > > 1927????????? * in the value of the {@coode access_flags} item or > > Typo: coode > > Also should same change be made to defineHiddenClassWithClassData docs. Yes, it should.? Fixed. thanks Mandy From sundararajan.athijegannathan at oracle.com Thu May 28 06:14:19 2020 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 28 May 2020 11:44:19 +0530 Subject: RFR 8246034: Remove java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js and java.base/share/classes/jdk/internal/jrtfs/jrtls.js Message-ID: <31dc2ed7-91b9-9fce-f0b2-6724da5cacdd@oracle.com> Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8246034 Webrev: http://cr.openjdk.java.net/~sundar/8246034/webrev.00/ Thanks -Sundar From james.laskey at oracle.com Thu May 28 06:43:47 2020 From: james.laskey at oracle.com (James Laskey) Date: Thu, 28 May 2020 03:43:47 -0300 Subject: RFR 8246034: Remove java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js and java.base/share/classes/jdk/internal/jrtfs/jrtls.js In-Reply-To: <31dc2ed7-91b9-9fce-f0b2-6724da5cacdd@oracle.com> References: <31dc2ed7-91b9-9fce-f0b2-6724da5cacdd@oracle.com> Message-ID: <43B3B1B8-4448-4D98-8445-F11B491D3A29@oracle.com> +1 ?? > On May 28, 2020, at 3:16 AM, sundararajan.athijegannathan at oracle.com wrote: > > ?Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8246034 > > Webrev: http://cr.openjdk.java.net/~sundar/8246034/webrev.00/ > > Thanks > > -Sundar > From david.holmes at oracle.com Thu May 28 06:51:47 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 May 2020 16:51:47 +1000 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: <9b32addd-d576-268e-61ab-0ac4921d22f5@oracle.com> References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> <9d7da8af-cda3-693d-1ea1-1db5069fea97@oracle.com> <9b32addd-d576-268e-61ab-0ac4921d22f5@oracle.com> Message-ID: Hi Harold, On 28/05/2020 6:35 am, Harold Seigel wrote: > Hi David, > > Please review this updated webrev: > > Incremental webrev: > http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.incr.2/ Changes look good - thanks! One minor comment: src/hotspot/share/prims/jvm.cpp 2159 if (length != 0) { 2160 for (int i = 0; i < length; i++) { The if statement is not needed as the loop will be skipped if length is 0. On testing: test/hotspot/jtreg/runtime/modules/SealedModuleTest.java test/hotspot/jtreg/runtime/sealedClasses/SealedUnnamedModuleTest.java test/hotspot/jtreg/runtime/sealedClasses/SealedUnnamedModuleIntfTest.java You don't seem to have coverage of the full test matrix. For the combination of "same module or not" x "same package or not" x "public or not", there should be 8 test cases: 3 failures and 5 successes. Then you also have "listed in permits clause" versus "not listed in permits clause". Then you have all that for classes and interfaces. --- On the question of whether to use ReflectionData or not that is really question for the core-libs folk to decide. Thanks, David ----- > full webrev: > http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.2/webrev/ > > It includes the following changes: > > * Indentation and simplification changes as suggested below > * If a class is not a valid permitted subclass of its sealed super > then an IncompatibleClassChangeError exception is thrown (as > specified in the JVM Spec) instead of VerifyError. > * Added a check that a non-public subclass must be in the same package > as its sealed super.? And added appropriate testing. > * Method Class.permittedSubtypes() was changed. > > See also inline comments. > > > On 5/24/2020 10:28 PM, David Holmes wrote: >> Hi Harold, >> >> On 22/05/2020 4:33 am, Harold Seigel wrote: >>> Hi David, >>> >>> Thanks for looking at this!? Please review this new webrev: >>> >>> http://cr.openjdk.java.net/~hseigel/webrev.01/webrev/ >> >> I'll list all relevant commens here rather than interspersing below so >> that it is easier to track. Mostly nits below, other than the >> is_permitted_subclass check in the VM, and the use of ReflectionData >> in java.lang.Class. >> >> -- >> >> src/hotspot/share/classfile/classFileParser.cpp >> >> + bool ClassFileParser::supports_sealed_types() { >> +?? return _major_version == JVM_CLASSFILE_MAJOR_VERSION && >> +???? _minor_version == JAVA_PREVIEW_MINOR_VERSION && >> +???? Arguments::enable_preview(); >> + } >> >> Nowe there is too little indentation - the subclauses of the >> conjunction expression should align[1] >> >> + bool ClassFileParser::supports_sealed_types() { >> +?? return _major_version == JVM_CLASSFILE_MAJOR_VERSION && >> +????????? _minor_version == JAVA_PREVIEW_MINOR_VERSION && >> +????????? Arguments::enable_preview(); >> + } > Fixed. Along with indentation of supports_records(). >> >> 3791???????????????? if (parsed_permitted_subclasses_attribute) { >> 3792?????????????????? classfile_parse_error("Multiple >> PermittedSubclasses attributes in class file %s", CHECK); >> 3793???????????????? // Classes marked ACC_FINAL cannot have a >> PermittedSubclasses attribute. >> 3794???????????????? } else if (_access_flags.is_final()) { >> 3795?????????????????? classfile_parse_error("PermittedSubclasses >> attribute in final class file %s", CHECK); >> 3796???????????????? } else { >> 3797?????????????????? parsed_permitted_subclasses_attribute = true; >> 3798???????????????? } >> >> The indent of the comment at L3793 is wrong, and its placement is >> awkward because it relates to the next condition. But we don't have to >> use if-else here as any parse error results in immediate return due to >> the CHECK macro. So the above can be reformatted as: >> >> 3791???????????????? if (parsed_permitted_subclasses_attribute) { >> 3792?????????????????? classfile_parse_error("Multiple >> PermittedSubclasses attributes in class file %s", CHECK); >> 3793???????????????? } >> 3794???????????????? // Classes marked ACC_FINAL cannot have a >> PermittedSubclasses attribute. >> 3795???????????????? if (_access_flags.is_final()) { >> 3796?????????????????? classfile_parse_error("PermittedSubclasses >> attribute in final class file %s", CHECK); >> 3797???????????????? } >> 3798???????????????? parsed_permitted_subclasses_attribute = true; > Done. >> >> --- >> >> src/hotspot/share/oops/instanceKlass.cpp >> >> The logic in InstanceKlass::has_as_permitted_subclass still does not >> implement the rules specified in the JVMS. It only implements a "same >> module" check, whereas the JVMS specifies an accessibility requirement >> as well. > Done. >> >> ?730 bool InstanceKlass::is_sealed() const { >> ?731?? return _permitted_subclasses != NULL && >> ?732???????? _permitted_subclasses != >> Universe::the_empty_short_array() && >> ?733???????? _permitted_subclasses->length() > 0; >> ?734 } >> >> Please align subclauses. > Done. >> >> --- >> >> src/hotspot/share/prims/jvm.cpp >> >> 2159?????? objArrayHandle result (THREAD, r); >> >> Please remove space after "result". > Done. >> >> As we will always create and return an arry, if you reverse these two >> statements: >> >> 2156???? if (length != 0) { >> 2157?????? objArrayOop r = >> oopFactory::new_objArray(SystemDictionary::String_klass(), >> 2158??????????????????????????????????????????????? length, CHECK_NULL); >> >> and these two: >> >> 2169?????? return (jobjectArray)JNIHandles::make_local(THREAD, result()); >> 2170???? } >> >> then you can delete >> >> 2172?? // if it gets to here return an empty array, cases will be: the >> class is primitive, or an array, or just not sealed >> 2173?? objArrayOop result = >> oopFactory::new_objArray(SystemDictionary::String_klass(), 0, >> CHECK_NULL); >> 2174?? return (jobjectArray)JNIHandles::make_local(env, result); >> >> The comment there is no longer accurate anyway. > Done. >> >> --- >> >> src/hotspot/share/prims/jvmtiRedefineClasses.cpp >> >> 857 static jvmtiError >> check_permitted_subclasses_attribute(InstanceKlass* the_class, >> 858 InstanceKlass* scratch_class) { >> >> Please align. > Done. >> >> --- >> >> src/hotspot/share/prims/jvmtiRedefineClasses.cpp >> >> 2007?? if (permitted_subclasses != NULL) { >> >> permitted_subclasses cannot be NULL. I initially thought the bug was >> in the nest_members version of this code, but they both have the same >> properties: the member is initialized to NULL when the InstanceKlass >> is constructed, and set to either the proper array or the >> empty_array() when classfile parsing is complete. So redefinition >> cannot encounter a NULL value here. > Changed the 'if' statement to an assert. >> >> --- >> >> src/java.base/share/classes/java/lang/Class.java >> >> The use of ReflectionData is not correctly implemented. The >> ReflectionData instance is not constant but can be replaced when class >> redefinition operates. So you cannot do this: >> >> if (rd.permittedSubclasses != null) { >> ??? return rd.permittedSubclasses; >> } >> >> because you may be returning the permittedSubclasses field of a >> different Reflectiondata instance. You need to read the field once >> into a local and thereafter use it. Similarly with: >> >> rd.permittedSubclasses = new ClassDesc[0]; >> return rd.permittedSubclasses; >> >> you need to do: >> >> temp = new ClassDesc[0]; >> rd.permittedSubclasses = temp; >> return temp; > Done. >> >> I'm wondering now whether using Reflectiondata as the cache for this >> is actually the best way to cache it? > > Perhaps Reflectiondata could be used now and an RFE could be filed to > look at this more closely? > > Thanks, Harold > >> >> Aside: The JEP should explicitly point out that because the >> sealed/non-sealed modifiers are not represented in the classfile >> directly, they are also not exposed via the java.lang.reflect.Modifier >> API. >> >> --- >> >> That's it form me. >> >> Thanks, >> David >> >> [1] https://wiki.openjdk.java.net/display/HotSpot/StyleGuide >> "Use good taste to break lines and align corresponding tokens on >> adjacent lines." >> >>> This webrev contains the following significant changes: >>> >>> ?1. The format/indentation issues in classFileParser.cpp were fixed. >>> ?2. Unneeded checks in InstanceKlass::has_as_permitted_subclass() were >>> ??? removed and the TRAPS parameter was removed. >>> ?3. The changes to klassVtable.* and method.* were reverted. Those >>> ??? changes were from when sealed classes were marked as final, and are >>> ??? no longer valid. >>> ?4. Method getPermittedSubclasses() in Class.java was renamed to >>> ??? permittedSubclasses() and its implementation was changed. >>> ?5. Variables and methods for 'asm' were renamed from >>> ??? 'permittedSubtypes' to 'permittedSubclasses'. >>> ?6. Classes for sealed classes tests were changed to start with capital >>> ??? letters. >>> ?7. Changes to langtools tests were removed from this webrev. They are >>> ??? covered by the javac webrev (JDK-8244556). >>> ?8. The CSR's for JVMTI, JDWP, and JDI are in progress. >>> >>> Please also see comments inline. >>> >>> >>> On 5/19/2020 1:26 AM, David Holmes wrote: >>>> Hi Harold, >>>> >>>> Adding serviceability-dev for the serviceability related changes. >>>> >>>> Nit: "VM support for sealed classes" >>>> >>>> This RFR covers the VM, core-libs, serviceability and even some >>>> langtools tests. AFAICS only the javac changes are not included here >>>> so when and where will they be reviewed and under what bug id? >>>> Ideally there will be a single JBS issue for "Implementation of JEP >>>> 360: Sealed types". It's okay to break up the RFRs across different >>>> areas, but it should be done under one bug id. >>> The javac changes are being reviewed as bug JDK-8227406.? We >>> understand the need to do the reviews under one bug. >>>> >>>> Overall this looks good. I've looked at all files and mainly have >>>> some style nits in various places. But there are some more >>>> significant items below. >>>> >>>> On 14/05/2020 7:09 am, Harold Seigel wrote: >>>>> Hi, >>>>> >>>>> Please review this patch for JVM and Core-libs support for the JEP >>>>> 360 Sealed Classes preview feature.? Code changes include the >>>>> following: >>>>> >>>>> ??* Processing of the new PermittedSubclasses attribute to enforce >>>>> that >>>>> ??? a class or interface, whose super is a sealed class or interface, >>>>> ??? must be listed in the super's PermittedSubclasses attribute. >>>>> ??* Disallow redefinition of a sealed class or interface if its >>>>> ??? redefinition would change its PermittedSubclasses attribute. >>>>> ??* Support API's to determine if a class or interface is sealed >>>>> and, if >>>>> ??? it's sealed, return a list of its permitted subclasses. >>>>> ??* asm support for the PermittedSubclasses attribute >>>> >>>> I assume Remi is providing the upstream support in ASM? :) But also >>>> see below ... >>>> >>>>> >>>>> Open Webrev: >>>>> http://cr.openjdk.java.net/~vromero/8225056/webrev.00/index.html >>>> >>>> make/data/jdwp/jdwp.spec >>>> >>>> There needs to be a sub-task and associated CSR request for this >>>> JDWP spec update. I couldn't see this covered anywhere. >>>> >>>> --- >>>> >>>> src/hotspot/share/classfile/classFileParser.cpp >>>> >>>> 3215 u2 >>>> ClassFileParser::parse_classfile_permitted_subclasses_attribute(const ClassFileStream* >>>> const cfs, >>>> 3216 const u1* const permitted_subclasses_attribute_start, >>>> 3217 TRAPS) { >>>> >>>> Indention on L3216/17 needs fixing after the copy'n'edit. >>>> >>>> 3515?? return _major_version == JVM_CLASSFILE_MAJOR_VERSION && >>>> 3516????????????? _minor_version == JAVA_PREVIEW_MINOR_VERSION && >>>> 3517????????????? Arguments::enable_preview(); >>>> >>>> Too much indentation on L3516/17 >>>> >>>> 3790???????????????? // Check for PermittedSubclasses tag >>>> >>>> That comment (copied from my nestmates code :) is in the wrong >>>> place. It needs to be before >>>> >>>> 3788???????????? if (tag == vmSymbols::tag_permitted_subclasses()) { >>>> >>>> >>>> Minor nit: I would suggest checking >>>> parsed_permitted_subclasses_attribute before checking ACC_FINAL. >>>> >>>> 3876?? if (parsed_permitted_subclasses_attribute) { >>>> 3877???? const u2 num_of_subclasses = >>>> parse_classfile_permitted_subclasses_attribute( >>>> 3878??????????????????????????????????? cfs, >>>> 3879 permitted_subclasses_attribute_start, >>>> 3880??????????????????????????????????? CHECK); >>>> >>>> Although it looks odd the preceding, similarly shaped, sections all >>>> indent to the same absolute position. Can you make L3878/78/80 match >>>> please. >>>> >>>> 3882?????? guarantee_property( >>>> 3883???????? permitted_subclasses_attribute_length == >>>> 3884?????????? sizeof(num_of_subclasses) + sizeof(u2) * >>>> num_of_subclasses, >>>> 3885???????? "Wrong PermittedSubclasses attribute length in class >>>> file %s", CHECK); >>>> >>>> Nits: please reformat as: >>>> >>>> 3882?????? guarantee_property( >>>> 3883???????? permitted_subclasses_attribute_length == >>>> sizeof(num_of_subclasses) + sizeof(u2) * num_of_subclasses, >>>> 3885???????? "Wrong PermittedSubclasses attribute length in class >>>> file %s", CHECK); >>>> >>>> It would also look slightly better if you shortened the name of the >>>> num_of_subclasses variable. >>> All of the above classFileParser.cpp changes were done. >>>> >>>> --- >>>> >>>> src/hotspot/share/classfile/classFileParser.hpp >>>> >>>> +?? u2 parse_classfile_permitted_subclasses_attribute(const >>>> ClassFileStream* const cfs, >>>> +???????????????????????????????????????????? const u1* const >>>> permitted_subclasses_attribute_start, >>>> +???????????????????????????????????????????? TRAPS); >>>> >>>> Please fix indentation after copy'n'edit. >>> Done. >>>> >>>> --- >>>> >>>> src/hotspot/share/oops/instanceKlass.cpp >>>> >>>> ?247?? if (classloader1 != classloader2) { >>>> >>>> I'm not clear what rule this is verifying. The same module check >>>> follows this one. The rule is that the subclass must be accessible >>>> to the superclass implying: >>>> 1. same named module (regardless of class access modifiers); or >>>> 2. (implicitly in un-named module) same package if subclass not >>>> public; or >>>> 3. public subclass >>>> >>>> Having the same classloader implies same package, but that alone >>>> doesn't address 2 or 3. So this doesn't conform to proposed JVMS rules. >>> This was discussed as part of the CSR and hopefully clarified. >>>> >>>> >>>> >>>> ?264???? if (_constants->tag_at(cp_index).is_klass()) { >>>> ?265?????? Klass* k2 = _constants->klass_at(cp_index, CHECK_false); >>>> >>>> You've copied this code from the nestmember checks but your changes >>>> don't quite make sense to me. If we have already checked is_klass() >>>> then klass_at() cannot lead to any exceptions. >>>> >>>> ?272?????? if (name == k->name()) { >>>> ?273???????? log_trace(class, sealed)("- Found it at >>>> permitted_subclasses[%d] => cp[%d]", i, cp_index); >>>> ?274???????? return true; >>>> >>>> I was wondering why you don't resolve the cp entry when you find the >>>> name matches, as we do for nest members, but realized that unlike >>>> the nest membership check, which can happen many times for a given >>>> class, this permitted subclass check can only happen once per class. >>>> As you don't actually resolve here, and given that the earlier check >>>> cannot throw exceptions, it follows that the entire method never >>>> results in any exceptions and so callers should not be using the >>>> CHECK macro. >>> >>> The comparison of class loaders was removed because checking that the >>> two classes are in the same module ensures that they have the same >>> class loader. >>> >>> The traps parameter was removed.? The CHECK macro was replaced with >>> THREAD. >>> >>>> >>>> --- >>>> >>>> src/hotspot/share/oops/method.cpp >>>> >>>> I don't understand how knowing the class is sealed allows you to >>>> infer that a non-final method is actually final ?? >>> This change was removed.? See item #3 at the beginning of this email. >>>> >>>> --- >>>> >>>> ?src/hotspot/share/prims/jvm.cpp >>>> >>>> It would be simpler (and cheaper) if the Java side of this ensures >>>> it doesn't call into the VM with an array or primitive class. >>> Done. >>>> >>>> --- >>>> >>>> ?src/hotspot/share/prims/jvmti.xml >>>> >>>> The JVM TI spec changes also need to be covered by a CSR request. >>>> >>>> --- >>>> >>>> src/hotspot/share/prims/jvmtiRedefineClasses.cpp >>>> >>>> We should file a RFE to refactor the logic that checks that an >>>> attribute consisting of a list of classes has not changed. :) >>> Serguei filed the RFE. >>>> >>>> Aside: I spotted a bug in the nest member code (missing NULL check!) >>>> thanks to your change :) >>>> >>>> --- >>>> >>>> src/java.base/share/classes/java/lang/Class.java >>>> >>>> There needs to be a CSR request for these changes. >>> The CSR is JDK-8244556. >>>> >>>> +????? * Returns an array containing {@code ClassDesc} objects >>>> representing all the >>>> +????? * permitted subclasses of this {@linkplain Class} if it is >>>> sealed. Returns an empty array if this >>>> +????? * {@linkplain Class} is not sealed. >>>> >>>> should add "or this class represents an array or primitive type" >>>> (using the standard wording for such cases). >>> Discussed off-line and was decided that this text isn't needed. >>>> >>>> +????? * @throws IllegalArgumentException if a class descriptor is >>>> not in the correct format >>>> >>>> IllegalArgumentException is not an appropriate exception to use as >>>> this method takes no arguments. If the class descriptor is not valid >>>> and it comes from the VM then I think we have a problem with how the >>>> VM validates class descriptors. Any IAE from ClassDesc.of should be >>>> caught and converted to a more suitable exception type - preferably >>>> InternalError if the VM should always return valid strings. >>> Done. >>>> >>>> +???? public ClassDesc[] getPermittedSubclasses() { >>>> >>>> As mentioned for jvm.cpp this Java code should do the isArray() and >>>> isPrimitive() check before calling the VM. >>> Done. >>>> >>>> +???????? String[] descriptors = getPermittedSubclasses0(); >>>> >>>> Nit: what you get from the VM are not descriptors, just name strings >>>> in internal form. This wouldn't really matter except it then looks >>>> strange to call ClassDesc.of(...) instead of >>>> ClassDesc.ofDescriptor(...). >>> We tried using ClassDesc.ofDescriptor() but encountered problems. The >>> variable 'descriptors' was renamed 'subclassNames'. >>>> >>>> +???????? if (descriptors == null >>>> >>>> The VM never returns null. >>> The check was removed. >>>> >>>> +???????? return getPermittedSubclasses().length != 0; >>>> >>>> It's grossly inefficient to create the ClassDesc array and then >>>> throw it away IMO. The result should be cached either in a field of >>>> Class or in the ReflectionData of the class. >>> Done. >>>> >>>> --- >>>> >>>> src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java >>>> >>>> >>>> !???????? // - The offset of the PermittedSubclasses attribute, or 0 >>>> ????????? int permittedSubtypesOffset = 0; >>>> >>>> Obviously ASM already has some prelim support for sealed classes, >>>> but now that the attribute has been renamed that should also flow >>>> through to the ASM code ie the variable, not just the comment. >>>> >>>> Ditto for ClassWriter.java and its fields. >>> Done. >>>> >>>> --- >>>> >>>> src/java.base/share/native/libjava/Class.c >>>> >>>> ????? {"isRecord0",??????????? "()Z",???????? (void *)&JVM_IsRecord}, >>>> +???? {"getPermittedSubclasses0", "()[" STR,??? (void >>>> *)&JVM_GetPermittedSubclasses}, >>>> >>>> please align (void >>>> >>> Done. >>>> --- >>>> >>>> src/java.instrument/share/classes/java/lang/instrument/Instrumentation.java >>>> >>>> src/jdk.jdi/share/classes/com/sun/jdi/VirtualMachine.java >>>> >>>> There needs to be a CSR for these changes too. >>>> >>>> --- >>>> >>>> test/langtools/tools/javac/processing/model/TestSourceVersion.java >>>> >>>> !??????????????????? // Assume "record" and "sealed" will be >>>> restricted keywords. >>>> !??????????????????? "record", "sealed"); >>>> >>>> What about the non-sealed keyword defined in the JEP? >>> 'non-sealed' is a keyword but not a restricted keyword.? So, it >>> should not be in the list. >>>> >>>> --- >>>> >>>> In the tests you don't need to explicitly include >>>> sun.hotspot.WhiteBox$WhiteBoxPermission on the ClassFileInstaller >>>> invocation. (previous RFE's have been removing existing occurrences >>>> after the CFI was fixed to handle it internally). >>> Done. >>>> >>>> Please ensure all new tests have an @bug 8225056 (or whatever the >>>> actual JBS issue will be) >>> Done. >>>> >>>> All test classes (and thus files) should be named in camel-case i.e. >>>> C1 not c1, C2 not c2, SuperClass not superClass etc. >>> Done. >>>> >>>> >>>> test/hotspot/jtreg/runtime/modules/sealedP1/superClass.jcod >>>> test/hotspot/jtreg/runtime/sealedClasses/Pkg/sealedInterface.jcod >>>> >>>> Please add comments clarifying why these must be jcod files. >>> >>> Done. >>> >>> Thanks!? Harold >>> >>>> >>>> --- >>>> >>>> That's it from me. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> >>>> >>>>> JBS bug: https://bugs.openjdk.java.net/browse/JDK-8225056 >>>>> >>>>> Java Language Spec changes: >>>>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jls.html >>>>> >>>>> >>>>> JVM Spec changes: >>>>> http://cr.openjdk.java.net/~gbierman/jep360/jep360-20200513/specs/sealed-classes-jvms.html >>>>> >>>>> >>>>> JEP 360: https://bugs.openjdk.java.net/browse/JDK-8227043 >>>>> >>>>> JVM CSR: https://bugs.openjdk.java.net/browse/JDK-8242578 >>>>> >>>>> Changes to javac and other language tools will be reviewed separately. >>>>> >>>>> Thanks, Harold >>>>> >>>>> From Alan.Bateman at oracle.com Thu May 28 06:58:49 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 May 2020 07:58:49 +0100 Subject: RFR 8246034: Remove java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js and java.base/share/classes/jdk/internal/jrtfs/jrtls.js In-Reply-To: <31dc2ed7-91b9-9fce-f0b2-6724da5cacdd@oracle.com> References: <31dc2ed7-91b9-9fce-f0b2-6724da5cacdd@oracle.com> Message-ID: On 28/05/2020 07:14, sundararajan.athijegannathan at oracle.com wrote: > Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8246034 > > Webrev: http://cr.openjdk.java.net/~sundar/8246034/webrev.00/ Have you checked if there are any make file configured to copy .js files? Otherwise looks good. -Alan From sundararajan.athijegannathan at oracle.com Thu May 28 07:05:45 2020 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Thu, 28 May 2020 12:35:45 +0530 Subject: RFR 8246034: Remove java.base/share/classes/jdk/internal/jrtfs/jrtfsviewer.js and java.base/share/classes/jdk/internal/jrtfs/jrtls.js In-Reply-To: References: <31dc2ed7-91b9-9fce-f0b2-6724da5cacdd@oracle.com> Message-ID: Yes, checked. No config file refers to these .js files. -Sundar On 28/05/20 12:28 pm, Alan Bateman wrote: > On 28/05/2020 07:14, sundararajan.athijegannathan at oracle.com wrote: >> Please review. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8246034 >> >> Webrev: http://cr.openjdk.java.net/~sundar/8246034/webrev.00/ > Have you checked if there are any make file configured to copy .js > files? Otherwise looks good. > > -Alan From david.holmes at oracle.com Thu May 28 07:44:37 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 May 2020 17:44:37 +1000 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> Message-ID: <2f2218dd-de42-bfd4-974a-76ef3d840882@oracle.com> Hi Mandy, On 28/05/2020 2:13 pm, Mandy Chung wrote: > Updated webrev: > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.01/ > > I modify this patch to check the class file version and throws CFE if > unsupported before creating ClassReader.? This also fixes JDK-8245061 > that it reads the value of `this_class` as a constant (as ASM will throw > an exception if it's not a constant) and also ensures that `this_class` > is a CONSTANT_Class_info by checking the descriptor string from Type. I couldn't quite follow all the details so just a couple of comments: src/java.base/share/classes/jdk/internal/misc/VM.java + public static boolean isSupportedClassFileVersion(int major, int minor) { + if (major < 45 || major > classFileMajorVersion) return false; + if (major < 56) return minor == 0; + return minor == 0 || minor == PREVIEW_MINOR_VERSION; + } that is only a partial validity test for preview versions - the major version must match the current version as well. + s = props.get("java.class.version"); + int index = s.indexOf('.'); + try { + classFileMajorVersion = Integer.valueOf(s.substring(0, index)); + classFileMinorVersion = Integer.valueOf(s.substring(index+1, s.length())); + } catch (NumberFormatException e) { + throw new InternalError(e); + } Can you not access java.lang.VersionProps to get the version info? Cheers, David > Mandy > > On 5/27/20 10:57 AM, Mandy Chung wrote: >> I'm reconsidering this fix along with JDK-8245061 that may require to >> do its own checking (a similar issue w.r.t. ASM validation but in this >> case the constant pool entry of `this_class` item is not validated). >> >> thanks >> Mandy >> >> On 5/27/20 10:39 AM, forax at univ-mlv.fr wrote: >>> Hi Alan, >>> We (the ASM team) recommend to our users to check the byte 6 (and >>> perhaps 7) instead of relying on ASM throwing an exception, >>> because you may update the version of ASM but not the visitors your >>> are using in your code. >>> >>> It's less brittle than catching the IAE thrown by ASM. >>> >>> R?mi >>> >>> ----- Mail original ----- >>>> De: "Alan Bateman" >>>> ?: "mandy chung" , "core-libs-dev" >>>> , "Remi Forax" >>>> >>>> Envoy?: Mercredi 27 Mai 2020 18:16:33 >>>> Objet: Re: RFR: JDK-8245432: Lookup::defineHiddenClass should throw >>>> UnsupportedClassVersionError if the given bytes are >>>> of an unsupported major or minor version >>>> On 26/05/2020 22:46, Mandy Chung wrote: >>>>> Lookup::defineHiddenClass currently throws IAE by ASM if the given >>>>> bytes are of unsupported class file version.? The implementation >>>>> should catch and throw UnsupportedClassVersionError instead. >>>>> >>>>> webrev: >>>>> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.00/ >>>>> >>>>> This patch also includes a spec clarification of @throws IAE if the >>>>> the bytes has ACC_MODULE flag set to fix JDK-8245596. >>>> R?mi - has there ever been any discussion in ASM about throwing more >>>> specific exceptions? Only asking to see if we could avoid needing to >>>> depend on the exception message here. >>>> >>>> -Alan >> > From david.holmes at oracle.com Thu May 28 07:47:11 2020 From: david.holmes at oracle.com (David Holmes) Date: Thu, 28 May 2020 17:47:11 +1000 Subject: RFR(S) 8242504: Enhance the system clock to nanosecond precision In-Reply-To: References: <1c910629-fd04-b978-1e21-fda2e4709863@oracle.com> <708adca8-5a88-e592-19c4-48f26c87b79e@oracle.com> Message-ID: <582de926-7ca1-3409-0a7b-32f231f9e166@oracle.com> Thanks Dan! David On 28/05/2020 12:52 pm, Daniel D. Daugherty wrote: >> I'll wait for your thumbs up on the explanation. > > I'm good with the explanation. Thanks! > > Dan > > > On 5/27/20 10:08 PM, David Holmes wrote: >> Hi Dan, >> >> Thanks for taking a look. >> >> On 28/05/2020 1:09 am, Daniel D. Daugherty wrote: >>> On 5/26/20 12:59 AM, David Holmes wrote: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8242504 >>>> webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/ >>> >>> src/hotspot/os/posix/os_posix.hpp >>> ???? No comments. >>> >>> src/hotspot/os/posix/os_posix.inline.hpp >>> ???? No comments. >>> >>> src/hotspot/os/posix/os_posix.cpp >>> ???? old L1686: #ifdef NEEDS_LIBRT >>> ???? old L1687?????? // Close librt if there is no monotonic clock. >>> ???? old L1688?????? if (handle != RTLD_DEFAULT) { >>> ???? old L1689???????? dlclose(handle); >>> ???? old L1690?????? } >>> ???? old L1691 #endif >>> ???????? I don't see any explanation in the bug or in the CR invite >>> ???????? about why this code is deleted when this preceding code >>> ???????? remains: >>> >>> ???????? L1658: ? // For older linux we need librt, for other OS we >>> can find >>> ???????? L1659: ? // this function in regular libc. >>> ???????? L1660: #ifdef NEEDS_LIBRT >>> ???????? L1661: ? // We do dlopen's in this particular order due to >>> bug in linux >>> ???????? L1662: ? // dynamic loader (see 6348968) leading to crash on >>> exit. >>> ???????? L1663: ? handle = dlopen("librt.so.1", RTLD_LAZY); >>> ???????? L1664: ? if (handle == NULL) { >>> ???????? L1665: ??? handle = dlopen("librt.so", RTLD_LAZY); >>> ???????? L1666: ? } >>> ???????? L1667: #endif >> >> Sorry I should have mentioned this. In the existing code if we don't >> have CLOCK_MONOTONIC support we will never use the dynamic handles to >> clock_gettime and so we can close librt again (if we loaded it for >> clock_gettime). >> >> With the new code we will always use clock_gettime so we can't unload >> librt (if we needed it for clock_gettime) just because there is no >> CLOCK_MONOTONIC. >> >> The existing code (and thus the new code) is technically missing >> something here: >> >> 1675?? if (clock_getres_func != NULL && clock_gettime_func != NULL) { >> ... >> 1693?? } >> >> There could be an else clause that closes librt if it was loaded. But >> the reality is that these functions are present in librt so we should >> never reach such an else clause. Closing the handle to librt is a >> minor "good citizen" act. This will all be moot in the not too distant >> future when we rely on these functions being in libc on all platforms. >> >>> src/hotspot/os/linux/os_linux.cpp >>> ???? old L1382: ? return jlong(time.tv_sec) * 1000? + >>> jlong(time.tv_usec / 1000); >>> ???? new L1390: ??? return jlong(time.tv_sec) * MILLIUNITS? + >>> ???? new L1391: ?????????? jlong(time.tv_usec) / (MICROUNITS / >>> MILLIUNITS); >>> >>> ???? old L1390: ? nanos = jlong(time.tv_usec) * 1000; >>> ???? new L1407: ??? nanos = jlong(time.tv_usec) * (NANOUNITS / >>> MICROUNITS); >>> ???????? Thanks for replacing the literal 1000s in the old code. >>> >>> test/jdk/java/time/test/java/time/TestClock_System.java >>> ???? L207: ?????????????????????????????? + " millisecond precision: >>> "+countBetterThanMillisPrecision+"/"+1000); >>> ???? L209:? ????????????????????????????? + " microsecond precision: >>> "+countBetterThanMicrosPrecision+"/"+1000); >>> ??????? nit - need spaces around some of the '+' operators. >> >> Fixed. >> >>> test/micro/org/openjdk/bench/java/lang/SystemTime.java >>> test/micro/org/openjdk/bench/java/lang/Systems.java >>> ???? No comments. >>> >>> My only "concern" is the deletion of closing the librt handle. >>> If you have a good explanation for that, then I'm good with this patch. >> >> Thanks again. I'll wait for your thumbs up on the explanation. >> >> David >> ----- >> >>> Dan >>> >>> >>> >>>> >>>> This work was contributed by Mark Kralj-Taylor: >>>> >>>> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html >>>> >>>> >>>> On the hotspot side we change the Linux implementations of >>>> javaTimeMillis() and javaTimeSystemUTC() so that they use >>>> clock_gettime(CLOCK_REALTIME) instead of gettimeofday(). In keeping >>>> with our conditional use of this API I added a new guard >>>> >>>> os::Posix::supports_clock_gettime() >>>> >>>> and refined the existing supports_monotonic_clock() so that we can >>>> still use CLOCK_REALTIME if CLOCK_MONOTONIC does not exist. In the >>>> future (hopefully very near future) we will simply assume these APIs >>>> always exist. >>>> >>>> On the core-libs side the existing test: >>>> >>>> test/jdk/java/time/test/java/time/TestClock_System.java >>>> >>>> is adjusted to track the precision in more detail. >>>> >>>> Finally Mark has added instantNowAsEpochNanos() to the benchmark >>>> previously known as >>>> >>>> test/micro/org/openjdk/bench/java/lang/Systems.java >>>> >>>> which I've renamed to SystemTime.java as Mark suggested. I agree >>>> having these three functions measured together makes sense. >>>> >>>> Testing: >>>> ? - test/jdk/java/time/test/java/time/TestClock_System.java >>>> ? - test/micro/org/openjdk/bench/java/lang/SystemTime.java >>>> ? - Tiers 1-3 >>>> >>>> Thanks, >>>> David >>> > From raffaello.giulietti at gmail.com Thu May 28 07:56:04 2020 From: raffaello.giulietti at gmail.com (Raffaello Giulietti) Date: Thu, 28 May 2020 09:56:04 +0200 Subject: contributing to JDK-8171407: Port fdlibm to Java, part 2 In-Reply-To: <22cbf997-0b1b-9cd2-602d-271bdc9875ae@oracle.com> References: <72b9f763-2647-b59a-9b42-22eca48d7706@gmail.com> <22cbf997-0b1b-9cd2-602d-271bdc9875ae@oracle.com> Message-ID: <751670fe-4e3e-aed7-326d-6616fe381696@gmail.com> Hi Joe, I kind of understand your point of being more at ease with the porting itself than with the review. However, wouldn't a review be needed anyway, regardless how knowledgeable the porter might be? That is, even if an expert like yourself does the port, somebody else would still have to invest time to do the review, I guess, so the overall combined effort would be almost the same. At least, that's my understanding on how development in the OpenJDK works. Anyway, although I'm not formally a reviewer, just a contributor, I'll be glad to review your code on an informal basis if you need an additional opinion. Greetings Raffaello On 2020-05-27 23:44, Joe Darcy wrote: > Hi Raffaello, > > Finishing the fdlibm port remains on my to-do list. Given the review > investment needed, I would not find it helpful for someone else to > contribute a port. > > Thanks, > > -Joe > > On 5/25/2020 9:24 AM, Raffaello Giulietti wrote: >> Hi, >> >> [1] enumerates 14 StrictMath native functions that still need a Java >> porting from the original C code. >> >> As of changeset b84f122ea855 all of them are still native, so I wonder >> if it makes sense to contribute or if they have already been ported >> and on the launch pad for integration. >> >> Let me know. >> >> >> Greetings >> Raffaello >> >> ---- >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8171407 From daniel.fuchs at oracle.com Thu May 28 08:50:35 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 28 May 2020 09:50:35 +0100 Subject: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space" Message-ID: Hi, Please find an almost trivial fix for: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space" https://bugs.openjdk.java.net/browse/JDK-8245867 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.00/ My new test for JDK-8239013 has been observed failing intermittently in OutOfMemory. The test needs to trigger the clearing of SoftReferences, and does so by eating up heap memory in order to trigger a GC that will clear them. The issue is that the test didn't release the memory when it no longer needed it, which caused trouble for the test harness when it tried to clean up after the test. The fix is to use SoftReference to retain the eaten-up memory (instead of strong references) so that it can be reclaimed at the time the full GC that clear soft references is triggered, and also to release the heap memory as soon as it is no longer needed. best regards, -- daniel From lance.andersen at oracle.com Thu May 28 10:48:43 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 28 May 2020 06:48:43 -0400 Subject: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space" In-Reply-To: References: Message-ID: Hi Daniel, The change looks reasonable. Thank you for addressing so quickly. Best Lance > On May 28, 2020, at 4:50 AM, Daniel Fuchs wrote: > > Hi, > > Please find an almost trivial fix for: > > 8245867: Logger/bundleLeak/BundleTest.java fails due > to "OutOfMemoryError: Java heap space" > https://bugs.openjdk.java.net/browse/JDK-8245867 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.00/ > > My new test for JDK-8239013 has been observed failing > intermittently in OutOfMemory. The test needs to trigger > the clearing of SoftReferences, and does so by eating > up heap memory in order to trigger a GC that will > clear them. > The issue is that the test didn't release the memory > when it no longer needed it, which caused trouble for > the test harness when it tried to clean up after the > test. > > The fix is to use SoftReference to retain the eaten-up > memory (instead of strong references) so that it can > be reclaimed at the time the full GC that clear soft > references is triggered, and also to release the heap > memory as soon as it is no longer needed. > > best regards, > > -- daniel Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From maurizio.cimadamore at oracle.com Thu May 28 11:20:14 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 May 2020 12:20:14 +0100 Subject: RFR 8246050: Improve scalability of MemoryScope Message-ID: Hi, during the review of [1] it emerged that the implementation of the memory scope abstraction (which is used to keep track of temporal scope of a memory segment) does not scale well in situations where there is a lot of contention on the acquire() method due to many threads working simultaneously on different chunks of the segment. Peter has proposed an alternate implementation [2] which, instead of using CAS, it cleverly uses LongAdders. While that implementation worked correctly, we managed to simplify it further, by realizing that what we needed here was an instance of a read-write lock: a thread that acquires a segment does a "read", while a thread closing a segment does a "write". By using optimistic reads with a StampedLock we were able to gain back scalability and maintain the code relatively readable. Webrev: http://cr.openjdk.java.net/~mcimadamore/8246050/webrev/ Cheers Maurizio [1] - https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/066136.html [2] - https://git.openjdk.java.net/panama-foreign/pull/142 From Alan.Bateman at oracle.com Thu May 28 13:55:33 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 May 2020 14:55:33 +0100 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> Message-ID: <8625b4fe-6035-9096-a94d-64b0705a6595@oracle.com> On 28/05/2020 05:13, Mandy Chung wrote: > Updated webrev: > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.01/ > > I modify this patch to check the class file version and throws CFE if > unsupported before creating ClassReader.? This also fixes JDK-8245061 > that it reads the value of `this_class` as a constant (as ASM will > throw an exception if it's not a constant) and also ensures that > `this_class` is a CONSTANT_Class_info by checking the descriptor > string from Type. I don't want to complicate this further but the --enable-preview handling in the VM doesn't seem to expose an internal property that allows code in the libraries know if preview feature are enabled or not. I was assuming that isSupportedClassFileVersion would need to check that. Will readUnsignedShort throw AIOBE if the offset is beyond the length? Also are you sure about "& 0xCAFEBABE", I assumed it would just check the magic number is equal to that. -Alan. From mandy.chung at oracle.com Thu May 28 17:25:22 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 28 May 2020 10:25:22 -0700 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <8625b4fe-6035-9096-a94d-64b0705a6595@oracle.com> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> <8625b4fe-6035-9096-a94d-64b0705a6595@oracle.com> Message-ID: <96d7b8b0-e6a2-fb2d-3786-3953c48ee72a@oracle.com> On 5/28/20 6:55 AM, Alan Bateman wrote: > On 28/05/2020 05:13, Mandy Chung wrote: >> Updated webrev: >> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.01/ >> >> I modify this patch to check the class file version and throws CFE if >> unsupported before creating ClassReader.? This also fixes JDK-8245061 >> that it reads the value of `this_class` as a constant (as ASM will >> throw an exception if it's not a constant) and also ensures that >> `this_class` is a CONSTANT_Class_info by checking the descriptor >> string from Type. > I don't want to complicate this further but the --enable-preview > handling in the VM doesn't seem to expose an internal property that > allows code in the libraries know if preview feature are enabled or > not. I was assuming that isSupportedClassFileVersion would need to > check that. > The runtime will ensure if --enable-preview is set if a class file with minor is loaded.?? I will prefer to keep VM::isSupportedClassFileVersion to validate the given major/minor version.? At runtime, it will fail when such class file is loaded if preview is not enabled. I'll add a comment to describe that. > Will readUnsignedShort throw AIOBE if the offset is beyond the length? Good catch.? I add the check to throw CFE. +??????????? private static int readUnsignedShort(byte[] bytes, int offset) { +??????????????? if (offset >= bytes.length) { +??????????????????? throw new ClassFormatError("Invalid ClassFile structure"); +??????????????? } +??????????????? return ((bytes[offset] & 0xFF) << 8) | (bytes[offset + 1] & 0xFF); +??????????? } > Also are you sure about "& 0xCAFEBABE", I assumed it would just check > the magic number is equal to that. It should check ==.? Fixed. thanks Mandy From mandy.chung at oracle.com Thu May 28 17:28:24 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 28 May 2020 10:28:24 -0700 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <2f2218dd-de42-bfd4-974a-76ef3d840882@oracle.com> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> <2f2218dd-de42-bfd4-974a-76ef3d840882@oracle.com> Message-ID: <8f53afb4-d11d-ae62-756f-8093726e098d@oracle.com> On 5/28/20 12:44 AM, David Holmes wrote: > Hi Mandy, > > On 28/05/2020 2:13 pm, Mandy Chung wrote: >> Updated webrev: >> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.01/ >> >> I modify this patch to check the class file version and throws CFE if >> unsupported before creating ClassReader.? This also fixes JDK-8245061 >> that it reads the value of `this_class` as a constant (as ASM will >> throw an exception if it's not a constant) and also ensures that >> `this_class` is a CONSTANT_Class_info by checking the descriptor >> string from Type. > > I couldn't quite follow all the details so just a couple of comments: > > ?src/java.base/share/classes/jdk/internal/misc/VM.java > > +???? public static boolean isSupportedClassFileVersion(int major, int > minor) { > +???????? if (major < 45 || major > classFileMajorVersion) return false; > +???????? if (major < 56) return minor == 0; > +???????? return minor == 0 || minor == PREVIEW_MINOR_VERSION; > +???? } > > that is only a partial validity test for preview versions - the major > version must match the current version as well. This is to validate the given version.? The runtime will check if preview feature is enabled when such class file is loaded.?? I will make a comment to make it clear. > > +???????? s = props.get("java.class.version"); > +???????? int index = s.indexOf('.'); > +???????? try { > +???????????? classFileMajorVersion = Integer.valueOf(s.substring(0, > index)); > +???????????? classFileMinorVersion = > Integer.valueOf(s.substring(index+1, s.length())); > +???????? } catch (NumberFormatException e) { > +???????????? throw new InternalError(e); > +???????? } > > Can you not access java.lang.VersionProps to get the version info? > VersionProps is package-private. Mandy > Cheers, > David > >> Mandy >> >> On 5/27/20 10:57 AM, Mandy Chung wrote: >>> I'm reconsidering this fix along with JDK-8245061 that may require >>> to do its own checking (a similar issue w.r.t. ASM validation but in >>> this case the constant pool entry of `this_class` item is not >>> validated). >>> >>> thanks >>> Mandy >>> >>> On 5/27/20 10:39 AM, forax at univ-mlv.fr wrote: >>>> Hi Alan, >>>> We (the ASM team) recommend to our users to check the byte 6 (and >>>> perhaps 7) instead of relying on ASM throwing an exception, >>>> because you may update the version of ASM but not the visitors your >>>> are using in your code. >>>> >>>> It's less brittle than catching the IAE thrown by ASM. >>>> >>>> R?mi >>>> >>>> ----- Mail original ----- >>>>> De: "Alan Bateman" >>>>> ?: "mandy chung" , "core-libs-dev" >>>>> , "Remi Forax" >>>>> >>>>> Envoy?: Mercredi 27 Mai 2020 18:16:33 >>>>> Objet: Re: RFR: JDK-8245432: Lookup::defineHiddenClass should >>>>> throw UnsupportedClassVersionError if the given bytes are >>>>> of an unsupported major or minor version >>>>> On 26/05/2020 22:46, Mandy Chung wrote: >>>>>> Lookup::defineHiddenClass currently throws IAE by ASM if the given >>>>>> bytes are of unsupported class file version.? The implementation >>>>>> should catch and throw UnsupportedClassVersionError instead. >>>>>> >>>>>> webrev: >>>>>> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.00/ >>>>>> >>>>>> This patch also includes a spec clarification of @throws IAE if the >>>>>> the bytes has ACC_MODULE flag set to fix JDK-8245596. >>>>> R?mi - has there ever been any discussion in ASM about throwing more >>>>> specific exceptions? Only asking to see if we could avoid needing to >>>>> depend on the exception message here. >>>>> >>>>> -Alan >>> >> From stuart.marks at oracle.com Thu May 28 17:34:02 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 28 May 2020 10:34:02 -0700 Subject: RFR 15 (S): 8245068: Implement Deprecation of RMI Activation In-Reply-To: References: Message-ID: <74cc5f47-0012-fae4-9498-1c878ae3f95a@oracle.com> I've updated the webrev a little bit in response to previous comments: http://cr.openjdk.java.net/~smarks/reviews/8245068/webrev.1/ I've also drafted a CSR request and a release note. Please review: CSR: https://bugs.openjdk.java.net/browse/JDK-8245860 Release Note: https://bugs.openjdk.java.net/browse/JDK-8246021 Thanks, s'marks On 5/26/20 12:35 PM, Stuart Marks wrote: > Hi all, > > Here's the implementation of the recently-posted JEP 385, deprecation of RMI > Activation for removal. > > I'm listing this as S ("small") since conceptually it's fairly small, though > there are rather a large number of files changed. Essentially the changes are: > > ?- java.rmi.activation package spec: add deprecation warning > ?- java.rmi module spec: link to activation package spec > ?- java.rmi.activation public classes and interfaces: deprecate > ?- various other files: suppress warnings > ?- Activation.java: have the rmid tool emit a deprecation warning > ?- rmid.properties: localized warning message > > Webrev: > > ??? http://cr.openjdk.java.net/~smarks/reviews/8245068/webrev.0/ > > Bug ID: > > ??? https://bugs.openjdk.java.net/browse/JDK-8245068 > > JEP: > > ??? http://openjdk.java.net/jeps/385 > > Thanks, > > s'marks From paul.sandoz at oracle.com Thu May 28 17:56:33 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 28 May 2020 10:56:33 -0700 Subject: RFR 8246050: Improve scalability of MemoryScope In-Reply-To: References: Message-ID: +1 (previously reviewed on the panama-dev list) It?s very pleasing to see this get simplified through some good collaboration. StampedLock is quite powerful, and likely an under utilized resource. Paul. > On May 28, 2020, at 4:20 AM, Maurizio Cimadamore wrote: > > Hi, > during the review of [1] it emerged that the implementation of the memory scope abstraction (which is used to keep track of temporal scope of a memory segment) does not scale well in situations where there is a lot of contention on the acquire() method due to many threads working simultaneously on different chunks of the segment. > > Peter has proposed an alternate implementation [2] which, instead of using CAS, it cleverly uses LongAdders. > > While that implementation worked correctly, we managed to simplify it further, by realizing that what we needed here was an instance of a read-write lock: a thread that acquires a segment does a "read", while a thread closing a segment does a "write". By using optimistic reads with a StampedLock we were able to gain back scalability and maintain the code relatively readable. > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8246050/webrev/ > > Cheers > Maurizio > > [1] - https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/066136.html > [2] - https://git.openjdk.java.net/panama-foreign/pull/142 > From martinrb at google.com Thu May 28 17:59:09 2020 From: martinrb at google.com (Martin Buchholz) Date: Thu, 28 May 2020 10:59:09 -0700 Subject: RFR 8246050: Improve scalability of MemoryScope In-Reply-To: References: Message-ID: StampedLock iis a sharp knife, hard to use well, but an excellent tool for low-level performance work. On Thu, May 28, 2020 at 10:56 AM Paul Sandoz wrote: > > +1 (previously reviewed on the panama-dev list) > > It?s very pleasing to see this get simplified through some good collaboration. StampedLock is quite powerful, and likely an under utilized resource. > > Paul. > > > On May 28, 2020, at 4:20 AM, Maurizio Cimadamore wrote: > > > > Hi, > > during the review of [1] it emerged that the implementation of the memory scope abstraction (which is used to keep track of temporal scope of a memory segment) does not scale well in situations where there is a lot of contention on the acquire() method due to many threads working simultaneously on different chunks of the segment. > > > > Peter has proposed an alternate implementation [2] which, instead of using CAS, it cleverly uses LongAdders. > > > > While that implementation worked correctly, we managed to simplify it further, by realizing that what we needed here was an instance of a read-write lock: a thread that acquires a segment does a "read", while a thread closing a segment does a "write". By using optimistic reads with a StampedLock we were able to gain back scalability and maintain the code relatively readable. > > > > Webrev: > > > > http://cr.openjdk.java.net/~mcimadamore/8246050/webrev/ > > > > Cheers > > Maurizio > > > > [1] - https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/066136.html > > [2] - https://git.openjdk.java.net/panama-foreign/pull/142 > > > From Alan.Bateman at oracle.com Thu May 28 18:11:29 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 28 May 2020 19:11:29 +0100 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <96d7b8b0-e6a2-fb2d-3786-3953c48ee72a@oracle.com> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> <8625b4fe-6035-9096-a94d-64b0705a6595@oracle.com> <96d7b8b0-e6a2-fb2d-3786-3953c48ee72a@oracle.com> Message-ID: On 28/05/2020 18:25, Mandy Chung wrote: > : > > The runtime will ensure if --enable-preview is set if a class file > with minor is loaded.?? I will prefer to keep > VM::isSupportedClassFileVersion to validate the given major/minor > version.? At runtime, it will fail when such class file is loaded if > preview is not enabled. > > I'll add a comment to describe that. > >> Will readUnsignedShort throw AIOBE if the offset is beyond the length? > > Good catch.? I add the check to throw CFE. > +??????????? private static int readUnsignedShort(byte[] bytes, int > offset) { > +??????????????? if (offset >= bytes.length) { > +??????????????????? throw new ClassFormatError("Invalid ClassFile > structure"); > +??????????????? } > +??????????????? return ((bytes[offset] & 0xFF) << 8) | (bytes[offset > + 1] & 0xFF); > +??????????? } > >> Also are you sure about "& 0xCAFEBABE", I assumed it would just check >> the magic number is equal to that. > > It should check ==.? Fixed. Thanks, this is okay with me. -Alan. From lance.andersen at oracle.com Thu May 28 19:13:12 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 28 May 2020 15:13:12 -0400 Subject: RFR 15 (S): 8245068: Implement Deprecation of RMI Activation In-Reply-To: <74cc5f47-0012-fae4-9498-1c878ae3f95a@oracle.com> References: <74cc5f47-0012-fae4-9498-1c878ae3f95a@oracle.com> Message-ID: <48A7CC6C-648C-41B1-8BBF-A23DBB002AE0@oracle.com> Hi Stuart I think your changes read fine. > On May 28, 2020, at 1:34 PM, Stuart Marks wrote: > > I've updated the webrev a little bit in response to previous comments: > > http://cr.openjdk.java.net/~smarks/reviews/8245068/webrev.1/ Thinking about: --------- @deprecated The RMI Activation mechanism has been deprecated, and it may + * be removed from a future version. ???? Perhaps it might be a bit clearer to say ?? from a future Java SE version?? I realize that is different from what is at: https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/Compiler.html , but I thought it makes it clearer as to what ?version? is referring to. Though that being said, and now looking back at what I did for the CORBA and Java EE module removal, I used the same wording as you are proposing, so all good? :-) > > I've also drafted a CSR request and a release note. Please review: > > CSR: > > https://bugs.openjdk.java.net/browse/JDK-8245860 I think the CSR is fine. I might suggest adding a comment to justify ?low? for the compatibility impact for the JCK folks. I added myself as a reviewer. > > Release Note: > > https://bugs.openjdk.java.net/browse/JDK-8246021 Looks fine. Best, Lance > > Thanks, > > s'marks > > > On 5/26/20 12:35 PM, Stuart Marks wrote: >> Hi all, >> Here's the implementation of the recently-posted JEP 385, deprecation of RMI Activation for removal. >> I'm listing this as S ("small") since conceptually it's fairly small, though there are rather a large number of files changed. Essentially the changes are: >> - java.rmi.activation package spec: add deprecation warning >> - java.rmi module spec: link to activation package spec >> - java.rmi.activation public classes and interfaces: deprecate >> - various other files: suppress warnings >> - Activation.java: have the rmid tool emit a deprecation warning >> - rmid.properties: localized warning message >> Webrev: >> http://cr.openjdk.java.net/~smarks/reviews/8245068/webrev.0/ >> Bug ID: >> https://bugs.openjdk.java.net/browse/JDK-8245068 >> JEP: >> http://openjdk.java.net/jeps/385 >> Thanks, >> s'marks Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From stuart.marks at oracle.com Thu May 28 20:05:33 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 28 May 2020 13:05:33 -0700 Subject: RFR 15 (S): 8245068: Implement Deprecation of RMI Activation In-Reply-To: <48A7CC6C-648C-41B1-8BBF-A23DBB002AE0@oracle.com> References: <74cc5f47-0012-fae4-9498-1c878ae3f95a@oracle.com> <48A7CC6C-648C-41B1-8BBF-A23DBB002AE0@oracle.com> Message-ID: <8f9701a9-f5dd-0137-aa76-09dd42a91e6d@oracle.com> On 5/28/20 12:13 PM, Lance Andersen wrote: > Thinking about: > > --------- > @deprecated The RMI Activation mechanism has been deprecated, and it may > + * be removed from a future version. > ???? > > Perhaps it might be a bit clearer to say ?? from a future Java SE version?? ?I > realize that is different from what is at: > https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/Compiler.html, > but I thought it makes it clearer as to what ?version? is referring to. > > Though that being said, ?and now looking back at what I did for the CORBA and > Java EE module removal, I used the same wording as you are proposing, ?so all > good? :-) Yeah, it does seem like it's missing a noun, doesn't it? Using "Java SE" could work, but I note that Mark R edited the JEP 385 text and changed the places where I had written "Java SE" to "the Java Platform", so I think I'll run with that wording. Thanks for reviewing the CSR and the release note. s'marks > >> >> I've also drafted a CSR request and a release note. Please review: >> >> CSR: >> >> https://bugs.openjdk.java.net/browse/JDK-8245860 > > I think the CSR is fine. ?I might suggest adding a comment to justify ?low? > for the compatibility impact for the JCK folks. > > I added myself as a reviewer. >> >> Release Note: >> >> https://bugs.openjdk.java.net/browse/JDK-8246021 > > Looks fine. > > Best, > > ?Lance >> >> Thanks, >> >> s'marks >> >> >> On 5/26/20 12:35 PM, Stuart Marks wrote: >>> Hi all, >>> Here's the implementation of the recently-posted JEP 385, deprecation of RMI >>> Activation for removal. >>> I'm listing this as S ("small") since conceptually it's fairly small, though >>> there are rather a large number of files changed. Essentially the changes are: >>> ?- java.rmi.activation package spec: add deprecation warning >>> ?- java.rmi module spec: link to activation package spec >>> ?- java.rmi.activation public classes and interfaces: deprecate >>> ?- various other files: suppress warnings >>> ?- Activation.java: have the rmid tool emit a deprecation warning >>> ?- rmid.properties: localized warning message >>> Webrev: >>> http://cr.openjdk.java.net/~smarks/reviews/8245068/webrev.0/ >>> Bug ID: >>> https://bugs.openjdk.java.net/browse/JDK-8245068 >>> JEP: >>> http://openjdk.java.net/jeps/385 >>> Thanks, >>> s'marks > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From mandy.chung at oracle.com Thu May 28 21:12:42 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 28 May 2020 14:12:42 -0700 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: <9b32addd-d576-268e-61ab-0ac4921d22f5@oracle.com> References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> <9d7da8af-cda3-693d-1ea1-1db5069fea97@oracle.com> <9b32addd-d576-268e-61ab-0ac4921d22f5@oracle.com> Message-ID: <151289f6-820c-08d1-c2f9-85b18d1bcaf5@oracle.com> Hi Harold, On 5/27/20 1:35 PM, Harold Seigel wrote: > > Incremental webrev: > http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.incr.2/ > > full webrev: > http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.2/webrev/ > Class.java 4406 ReflectionData rd = reflectionData(); 4407 ClassDesc[] tmp = rd.permittedSubclasses; 4408 if (tmp != null) { 4409 return tmp; 4410 } 4411 4412 if (isArray() || isPrimitive()) { 4413 rd.permittedSubclasses = new ClassDesc[0]; 4414 return rd.permittedSubclasses; 4415 } This causes an array class or primitive type to create a ReflectionData.?? It should first check if this is non-sealed class and returns a constant empty array. In fact, ReflectionData caches the derived names and reflected members for performance and also they may be invalidated when the class is redefined.?? It might be okay to add ReflectionData::permittedSubclasses while `PermittedSubclasses` attribute can't be redefined and getting this attribute is not performance sensitive.?? For example, the result of `getNestMembers` is not cached in ReflectionData.? It may be better not to add it in ReflectionData for modifiable and performance-sensitive data. 4421 tmp = new ClassDesc[subclassNames.length]; 4422 int i = 0; 4423 for (String subclassName : subclassNames) { 4424 try { 4425 tmp[i++] = ClassDesc.of(subclassName.replace('/', '.')); 4426 } catch (IllegalArgumentException iae) { 4427 throw new InternalError("Invalid type in permitted subclasses information: " + subclassName, iae); 4428 } 4429 } Nit: rename tmp to some other name e.g. descs I read the JVMS but it isn't clear to me that the VM will validate the names in `PermittedSubclasses`attribute are valid class descriptors.?? I see ConstantPool::is_klass_or_reference check but can't find where it validates the name is a valid class descriptor - can you point me there??? (otherwise, maybe define it to be unspecified?) W.r.t. the APIs. I don't want to delay this review.? I see that you renamed the method to new API style as I brought up.? OTOH,? I expect more discussion is needed. Below is a recent comment from John on this topic [1] > One comment, really for the future, regarding the shape of the Java > API here: It uses Optional and omits the "get" prefix on accessors. > This is the New Style, as opposed to the Classic Style using null (for > "empty" results) and a "get" prefix ("getComponentType") to get a > related type. We may choose to to use the New Style for new reflection > API points, and if so let's not choose N different New Styles, but one > New Style. Personally I like removing "get"; I accept Optional instead > of null; and I also suggest that arrays (if any) be replaced by > (immutable) Lists in the New Style There are a few existing Class APIs that use the new API style: Class arrayClass(); Optional describeConstable(); String descriptorString(); This will set up a precedence of the new API style in this class. Should this new permittedSubclasses method return a List instead of an array?? It's okay with me if you prefer to revert back to the old API style and follow this up after integration. 4442 * Returns true if this {@linkplain Class} is sealed. 4443 * 4444 * @return returns true if this class is sealed NIt: {@code true} instead of true -? consistent with the style this class uses (in most methods) test/jdk/java/lang/reflect/sealed_classes/SealedClassesReflectionTest.java Nit: s/sealed_classes/sealedClasses/ - the test directory/file naming convention use camel case or java variable name convention. Thanks [1] https://github.com/openjdk/valhalla/pull/53#issuecomment-633116043 From maurizio.cimadamore at oracle.com Thu May 28 21:25:02 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 28 May 2020 22:25:02 +0100 Subject: RFR 8246095: Tweaks to memory access API Message-ID: <21b8eeff-7c72-7c89-b200-050fc0096414@oracle.com> Hi, this followup change includes a number of tweaks that have been added to the memory access API while we were in the process of integrating it. Most of them have been contributed by Chris (thanks!), and are all listed in great details in the CSR below: https://bugs.openjdk.java.net/browse/JDK-8246096 Implementation-wise it should be all relatively straightforward - apart for the bit of surgery on lambda forms which was required to add a new kind of lambda forms to 'collect' return values. For now this method handle adaptation is package private, and can only be used by MemoryHandles::filterValues - but, if people find it useful, we might consider adding it to the MethodHandle standard combinator toolbox. Cheers Maurizio Webrev: http://cr.openjdk.java.net/~mcimadamore/8246095_v1/webrev/ Javadoc: http://cr.openjdk.java.net/~mcimadamore/8246095_v1/javadoc/jdk/incubator/foreign/package-summary.html Specdiff: http://cr.openjdk.java.net/~mcimadamore/8246095_v1/specdiff/overview-summary.html From harold.seigel at oracle.com Thu May 28 22:31:46 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Thu, 28 May 2020 18:31:46 -0400 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: <151289f6-820c-08d1-c2f9-85b18d1bcaf5@oracle.com> References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> <9d7da8af-cda3-693d-1ea1-1db5069fea97@oracle.com> <9b32addd-d576-268e-61ab-0ac4921d22f5@oracle.com> <151289f6-820c-08d1-c2f9-85b18d1bcaf5@oracle.com> Message-ID: <009c50f3-80ba-1195-04e9-6d7296454db6@oracle.com> Hi Mandy, The entries in the PermittedSubclasses attribute are constant pool ConstantClass_info entries.? These names get validated by the VM in this code in ClassFileParser::parse_constant_pool(): ? for (index = 1; index < length; index++) { ??? const jbyte tag = cp->tag_at(index).value(); ??? switch (tag) { ????? case JVM_CONSTANT_UnresolvedClass: { ??????? const Symbol* const class_name = cp->klass_name_at(index); ??????? // check the name, even if _cp_patches will overwrite it *verify_legal_class_name(class_name, CHECK);* ??????? break; ????? } Thanks, Harold On 5/28/2020 5:12 PM, Mandy Chung wrote: > I read the JVMS but it isn't clear to me that the VM will validate the > names in `PermittedSubclasses`attribute are valid class descriptors.?? > I see ConstantPool::is_klass_or_reference check but can't find where > it validates the name is a valid class descriptor - can you point me > there??? (otherwise, maybe define it to be unspecified?) > From mandy.chung at oracle.com Thu May 28 23:29:26 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 28 May 2020 16:29:26 -0700 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: <009c50f3-80ba-1195-04e9-6d7296454db6@oracle.com> References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> <9d7da8af-cda3-693d-1ea1-1db5069fea97@oracle.com> <9b32addd-d576-268e-61ab-0ac4921d22f5@oracle.com> <151289f6-820c-08d1-c2f9-85b18d1bcaf5@oracle.com> <009c50f3-80ba-1195-04e9-6d7296454db6@oracle.com> Message-ID: <5bf21391-fa1f-13e0-a368-4938b0757b26@oracle.com> Thanks for confirming it. Mandy On 5/28/20 3:31 PM, Harold Seigel wrote: > > Hi Mandy, > > The entries in the PermittedSubclasses attribute are constant pool > ConstantClass_info entries.? These names get validated by the VM in > this code in ClassFileParser::parse_constant_pool(): > > ? for (index = 1; index < length; index++) { > ??? const jbyte tag = cp->tag_at(index).value(); > ??? switch (tag) { > ????? case JVM_CONSTANT_UnresolvedClass: { > ??????? const Symbol* const class_name = cp->klass_name_at(index); > ??????? // check the name, even if _cp_patches will overwrite it > *verify_legal_class_name(class_name, CHECK);* > ??????? break; > ????? } > > Thanks, Harold > > > On 5/28/2020 5:12 PM, Mandy Chung wrote: >> I read the JVMS but it isn't clear to me that the VM will validate >> the names in `PermittedSubclasses`attribute are valid class >> descriptors.?? I see ConstantPool::is_klass_or_reference check but >> can't find where it validates the name is a valid class descriptor - >> can you point me there??? (otherwise, maybe define it to be unspecified?) >> From info at j-kuhn.de Thu May 28 23:35:45 2020 From: info at j-kuhn.de (Johannes Kuhn) Date: Fri, 29 May 2020 01:35:45 +0200 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <96d7b8b0-e6a2-fb2d-3786-3953c48ee72a@oracle.com> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> <8625b4fe-6035-9096-a94d-64b0705a6595@oracle.com> <96d7b8b0-e6a2-fb2d-3786-3953c48ee72a@oracle.com> Message-ID: Hi, just noticed a small thing: The magic is 4 bytes, but readUnsignedShort reads two bytes. - Johannes On 28-May-20 19:25, Mandy Chung wrote: > > > On 5/28/20 6:55 AM, Alan Bateman wrote: >> On 28/05/2020 05:13, Mandy Chung wrote: >>> Updated webrev: >>> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.01/ >>> >>> I modify this patch to check the class file version and throws CFE >>> if unsupported before creating ClassReader.? This also fixes >>> JDK-8245061 that it reads the value of `this_class` as a constant >>> (as ASM will throw an exception if it's not a constant) and also >>> ensures that `this_class` is a CONSTANT_Class_info by checking the >>> descriptor string from Type. >> I don't want to complicate this further but the --enable-preview >> handling in the VM doesn't seem to expose an internal property that >> allows code in the libraries know if preview feature are enabled or >> not. I was assuming that isSupportedClassFileVersion would need to >> check that. >> > > The runtime will ensure if --enable-preview is set if a class file > with minor is loaded.?? I will prefer to keep > VM::isSupportedClassFileVersion to validate the given major/minor > version.? At runtime, it will fail when such class file is loaded if > preview is not enabled. > > I'll add a comment to describe that. > >> Will readUnsignedShort throw AIOBE if the offset is beyond the length? > > Good catch.? I add the check to throw CFE. > +??????????? private static int readUnsignedShort(byte[] bytes, int > offset) { > +??????????????? if (offset >= bytes.length) { > +??????????????????? throw new ClassFormatError("Invalid ClassFile > structure"); > +??????????????? } > +??????????????? return ((bytes[offset] & 0xFF) << 8) | (bytes[offset > + 1] & 0xFF); > +??????????? } > >> Also are you sure about "& 0xCAFEBABE", I assumed it would just check >> the magic number is equal to that. > > It should check ==.? Fixed. > > thanks > Mandy From david.holmes at oracle.com Thu May 28 23:36:25 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 29 May 2020 09:36:25 +1000 Subject: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space" In-Reply-To: References: Message-ID: Hi Daniel, This caught my eye ... On 28/05/2020 6:50 pm, Daniel Fuchs wrote: > Hi, > > Please find an almost trivial fix for: > > 8245867: Logger/bundleLeak/BundleTest.java fails due > ???????? to "OutOfMemoryError: Java heap space" > https://bugs.openjdk.java.net/browse/JDK-8245867 > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.00/ > > My new test for JDK-8239013 has been observed failing > intermittently in OutOfMemory. The test needs to trigger > the clearing of SoftReferences, and does so by eating > up heap memory in order to trigger a GC that will > clear them. This seems to be assuming that the GC will clear all SoftReferences when it needs to clear any SoftReference. I don't think that is at all guaranteed. In theory your memory eating loop could be satisfied by clearing only the SoftReference added in the previous iteration of the loop. I would have expected the fix here to be simply to clear memory ie: } catch (OutOfMemoryError oome) { stop = true; memory = null; System.gc(); } Cheers, David > The issue is that the test didn't release the memory > when it no longer needed it, which caused trouble for > the test harness when it tried to clean up after the > test. > > The fix is to use SoftReference to retain the eaten-up > memory (instead of strong references) so that it can > be reclaimed at the time the full GC that clear soft > references is triggered, and also to release the heap > memory as soon as it is no longer needed. > > best regards, > > -- daniel From david.holmes at oracle.com Fri May 29 00:30:18 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 29 May 2020 10:30:18 +1000 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: <151289f6-820c-08d1-c2f9-85b18d1bcaf5@oracle.com> References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> <9d7da8af-cda3-693d-1ea1-1db5069fea97@oracle.com> <9b32addd-d576-268e-61ab-0ac4921d22f5@oracle.com> <151289f6-820c-08d1-c2f9-85b18d1bcaf5@oracle.com> Message-ID: <0749bff1-02ac-841e-4bd7-4a511a90be9d@oracle.com> Hi Harold, Sorry Mandy's comment raised a couple of issues ... On 29/05/2020 7:12 am, Mandy Chung wrote: > Hi Harold, > > On 5/27/20 1:35 PM, Harold Seigel wrote: >> >> Incremental webrev: >> http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.incr.2/ >> >> full webrev: >> http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.2/webrev/ >> > Class.java > > 4406 ReflectionData rd = reflectionData(); > 4407 ClassDesc[] tmp = rd.permittedSubclasses; > 4408 if (tmp != null) { > 4409 return tmp; > 4410 } > 4411 > 4412 if (isArray() || isPrimitive()) { > 4413 rd.permittedSubclasses = new ClassDesc[0]; > 4414 return rd.permittedSubclasses; > 4415 } > > This causes an array class or primitive type to create a > ReflectionData.?? It should first check if this is non-sealed class > and returns a constant empty array. It can't check if this is a non-sealed class as the isSealed() check calls the above code! But for arrays and primitives which can't be sealed we should just do: 4412 if (isArray() || isPrimitive()) { 4413 return new ClassDesc[0]; 4414 } But this then made me realize that we need to be creating defensive copies of the returned arrays, as happens with other APIs that use ReflectionData. Backing up a bit I complained that: public boolean isSealed() { return permittedSubclasses().length != 0; } is a very inefficient way to answer the question as to whether a class is sealed, so I suggested that the result of permittedSubclasses() be cached. Caching is not without its own issues as we are discovering, and when you add in defensive copies this seems to be trading one inefficiency for another. For nestmates we don't cache getNestMembers() because we don;t think it will be called often - it is there to complete the introspection API of Class rather than being anticipated as used in a regular programmatic sense. I expect the same is true for permittedSubclasses(). Do we expect isSealed() to be used often or is it too just there for completeness? If just for completeness then perhaps a VM query would be a better compromise on the efficiency front? Otherwise I can accept the current implementation of isSealed(), and a non-caching permittedClasses() for this initial implementation of sealed classes. If efficiency turns out to be a problem for isSealed() then we can revisit it then. Thanks, David > In fact, ReflectionData caches the derived names and reflected members > for performance and also they may be invalidated when the class is > redefined.?? It might be okay to add > ReflectionData::permittedSubclasses while `PermittedSubclasses` > attribute can't be redefined and getting this attribute is not > performance sensitive.?? For example, the result of `getNestMembers` > is not cached in ReflectionData.? It may be better not to add it in > ReflectionData for modifiable and performance-sensitive data. > > > 4421 tmp = new ClassDesc[subclassNames.length]; > 4422 int i = 0; > 4423 for (String subclassName : subclassNames) { > 4424 try { > 4425 tmp[i++] = ClassDesc.of(subclassName.replace('/', '.')); > 4426 } catch (IllegalArgumentException iae) { > 4427 throw new InternalError("Invalid type in permitted subclasses > information: " + subclassName, iae); > 4428 } > 4429 } > Nit: rename tmp to some other name e.g. descs > > I read the JVMS but it isn't clear to me that the VM will validate the > names in `PermittedSubclasses`attribute are valid class descriptors.?? > I see ConstantPool::is_klass_or_reference check but can't find where > it validates the name is a valid class descriptor - can you point me > there??? (otherwise, maybe define it to be unspecified?) > > > W.r.t. the APIs. I don't want to delay this review.? I see that you > renamed the method to new API style as I brought up.? OTOH,? I expect > more discussion is needed. Below is a recent comment from John on this > topic [1] > >> One comment, really for the future, regarding the shape of the Java >> API here: It uses Optional and omits the "get" prefix on accessors. >> This is the New Style, as opposed to the Classic Style using null >> (for "empty" results) and a "get" prefix ("getComponentType") to get >> a related type. We may choose to to use the New Style for new >> reflection API points, and if so let's not choose N different New >> Styles, but one New Style. Personally I like removing "get"; I accept >> Optional instead of null; and I also suggest that arrays (if any) be >> replaced by (immutable) Lists in the New Style > > There are a few existing Class APIs that use the new API style: > Class arrayClass(); > Optional describeConstable(); > String descriptorString(); > > This will set up a precedence of the new API style in this class. > Should this new permittedSubclasses method return a List instead of an > array?? It's okay with me if you prefer to revert back to the old API > style and follow this up after integration. > > 4442 * Returns true if this {@linkplain Class} is sealed. > 4443 * > 4444 * @return returns true if this class is sealed > > NIt: {@code true} instead of true -? consistent with the style this > class uses (in most methods) > > test/jdk/java/lang/reflect/sealed_classes/SealedClassesReflectionTest.java > > Nit: s/sealed_classes/sealedClasses/ > - the test directory/file naming convention use camel case or java > variable name convention. > > Thanks > [1] https://github.com/openjdk/valhalla/pull/53#issuecomment-633116043 From david.holmes at oracle.com Fri May 29 00:44:06 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 29 May 2020 10:44:06 +1000 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <8f53afb4-d11d-ae62-756f-8093726e098d@oracle.com> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> <2f2218dd-de42-bfd4-974a-76ef3d840882@oracle.com> <8f53afb4-d11d-ae62-756f-8093726e098d@oracle.com> Message-ID: <7f82b76b-d9ed-2ccd-5fd1-8a5e68cb0a52@oracle.com> Hi Mandy, On 29/05/2020 3:28 am, Mandy Chung wrote: > > > On 5/28/20 12:44 AM, David Holmes wrote: >> Hi Mandy, >> >> On 28/05/2020 2:13 pm, Mandy Chung wrote: >>> Updated webrev: >>> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.01/ >>> >>> I modify this patch to check the class file version and throws CFE if >>> unsupported before creating ClassReader.? This also fixes JDK-8245061 >>> that it reads the value of `this_class` as a constant (as ASM will >>> throw an exception if it's not a constant) and also ensures that >>> `this_class` is a CONSTANT_Class_info by checking the descriptor >>> string from Type. >> >> I couldn't quite follow all the details so just a couple of comments: >> >> ?src/java.base/share/classes/jdk/internal/misc/VM.java >> >> +???? public static boolean isSupportedClassFileVersion(int major, int >> minor) { >> +???????? if (major < 45 || major > classFileMajorVersion) return false; >> +???????? if (major < 56) return minor == 0; >> +???????? return minor == 0 || minor == PREVIEW_MINOR_VERSION; >> +???? } >> >> that is only a partial validity test for preview versions - the major >> version must match the current version as well. > > This is to validate the given version.? The runtime will check if > preview feature is enabled when such class file is loaded.?? I will make > a comment to make it clear. Okay but I thought the intent here was to pre-validate the version information so that when these bytes get passed to ASM you don't have to worry about the IAE that will be thrown by ASM if there is actually a problem. Maybe the only real solution here is for ASM to be more specific with the exceptions it throws. :( >> >> +???????? s = props.get("java.class.version"); >> +???????? int index = s.indexOf('.'); >> +???????? try { >> +???????????? classFileMajorVersion = Integer.valueOf(s.substring(0, >> index)); >> +???????????? classFileMinorVersion = >> Integer.valueOf(s.substring(index+1, s.length())); >> +???????? } catch (NumberFormatException e) { >> +???????????? throw new InternalError(e); >> +???????? } >> >> Can you not access java.lang.VersionProps to get the version info? >> > VersionProps is package-private. Sure but we provide that kind of cross-package access all the time. We also have JAVA_MAX_SUPPORTED_VERSION in the ModuleInfo class. Seems messy to add yet a third place where we need to determine what the current major version number is. That aside isn't the minor version, as set in java.class.version guaranteed to be zero? David ----- > Mandy >> Cheers, >> David >> >>> Mandy >>> >>> On 5/27/20 10:57 AM, Mandy Chung wrote: >>>> I'm reconsidering this fix along with JDK-8245061 that may require >>>> to do its own checking (a similar issue w.r.t. ASM validation but in >>>> this case the constant pool entry of `this_class` item is not >>>> validated). >>>> >>>> thanks >>>> Mandy >>>> >>>> On 5/27/20 10:39 AM, forax at univ-mlv.fr wrote: >>>>> Hi Alan, >>>>> We (the ASM team) recommend to our users to check the byte 6 (and >>>>> perhaps 7) instead of relying on ASM throwing an exception, >>>>> because you may update the version of ASM but not the visitors your >>>>> are using in your code. >>>>> >>>>> It's less brittle than catching the IAE thrown by ASM. >>>>> >>>>> R?mi >>>>> >>>>> ----- Mail original ----- >>>>>> De: "Alan Bateman" >>>>>> ?: "mandy chung" , "core-libs-dev" >>>>>> , "Remi Forax" >>>>>> >>>>>> Envoy?: Mercredi 27 Mai 2020 18:16:33 >>>>>> Objet: Re: RFR: JDK-8245432: Lookup::defineHiddenClass should >>>>>> throw UnsupportedClassVersionError if the given bytes are >>>>>> of an unsupported major or minor version >>>>>> On 26/05/2020 22:46, Mandy Chung wrote: >>>>>>> Lookup::defineHiddenClass currently throws IAE by ASM if the given >>>>>>> bytes are of unsupported class file version.? The implementation >>>>>>> should catch and throw UnsupportedClassVersionError instead. >>>>>>> >>>>>>> webrev: >>>>>>> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.00/ >>>>>>> >>>>>>> This patch also includes a spec clarification of @throws IAE if the >>>>>>> the bytes has ACC_MODULE flag set to fix JDK-8245596. >>>>>> R?mi - has there ever been any discussion in ASM about throwing more >>>>>> specific exceptions? Only asking to see if we could avoid needing to >>>>>> depend on the exception message here. >>>>>> >>>>>> -Alan >>>> >>> > From mandy.chung at oracle.com Fri May 29 03:52:11 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 28 May 2020 20:52:11 -0700 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <7f82b76b-d9ed-2ccd-5fd1-8a5e68cb0a52@oracle.com> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> <2f2218dd-de42-bfd4-974a-76ef3d840882@oracle.com> <8f53afb4-d11d-ae62-756f-8093726e098d@oracle.com> <7f82b76b-d9ed-2ccd-5fd1-8a5e68cb0a52@oracle.com> Message-ID: <2eda234f-045d-1145-40ae-cf2b0b7cd5c5@oracle.com> On 5/28/20 5:44 PM, David Holmes wrote: >> >> This is to validate the given version.? The runtime will check if >> preview feature is enabled when such class file is loaded. I will >> make a comment to make it clear. > > Okay but I thought the intent here was to pre-validate the version > information so that when these bytes get passed to ASM you don't have > to worry about the IAE that will be thrown by ASM if there is actually > a problem. Yes it is.? ASM does not check if preview features are enabled or not neither.? When a class file depending preview features is passed to VM, the VM will throw an exception if preview features are not enabled. > > Maybe the only real solution here is for ASM to be more specific with > the exceptions it throws. :( > This was discussed. https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066734.html > > Sure but we provide that kind of cross-package access all the time. We > also have JAVA_MAX_SUPPORTED_VERSION in the ModuleInfo class. Seems > messy to add yet a third place where we need to determine what the > current major version number is. > Ah, that's another place.? I think it's better to add VM::isSupportedModuleDescriptorVersion and remove these constants. > That aside isn't the minor version, as set in java.class.version > guaranteed to be zero? > This is set at build time.?? The minor version is zero for the current versioning scheme. Mandy > David > ----- > >> Mandy >>> Cheers, >>> David >>> >>>> Mandy >>>> >>>> On 5/27/20 10:57 AM, Mandy Chung wrote: >>>>> I'm reconsidering this fix along with JDK-8245061 that may require >>>>> to do its own checking (a similar issue w.r.t. ASM validation but >>>>> in this case the constant pool entry of `this_class` item is not >>>>> validated). >>>>> >>>>> thanks >>>>> Mandy >>>>> >>>>> On 5/27/20 10:39 AM, forax at univ-mlv.fr wrote: >>>>>> Hi Alan, >>>>>> We (the ASM team) recommend to our users to check the byte 6 (and >>>>>> perhaps 7) instead of relying on ASM throwing an exception, >>>>>> because you may update the version of ASM but not the visitors >>>>>> your are using in your code. >>>>>> >>>>>> It's less brittle than catching the IAE thrown by ASM. >>>>>> >>>>>> R?mi >>>>>> >>>>>> ----- Mail original ----- >>>>>>> De: "Alan Bateman" >>>>>>> ?: "mandy chung" , "core-libs-dev" >>>>>>> , "Remi Forax" >>>>>>> >>>>>>> Envoy?: Mercredi 27 Mai 2020 18:16:33 >>>>>>> Objet: Re: RFR: JDK-8245432: Lookup::defineHiddenClass should >>>>>>> throw UnsupportedClassVersionError if the given bytes are >>>>>>> of an unsupported major or minor version >>>>>>> On 26/05/2020 22:46, Mandy Chung wrote: >>>>>>>> Lookup::defineHiddenClass currently throws IAE by ASM if the given >>>>>>>> bytes are of unsupported class file version.? The implementation >>>>>>>> should catch and throw UnsupportedClassVersionError instead. >>>>>>>> >>>>>>>> webrev: >>>>>>>> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> This patch also includes a spec clarification of @throws IAE if >>>>>>>> the >>>>>>>> the bytes has ACC_MODULE flag set to fix JDK-8245596. >>>>>>> R?mi - has there ever been any discussion in ASM about throwing >>>>>>> more >>>>>>> specific exceptions? Only asking to see if we could avoid >>>>>>> needing to >>>>>>> depend on the exception message here. >>>>>>> >>>>>>> -Alan >>>>> >>>> >> From david.holmes at oracle.com Fri May 29 04:18:12 2020 From: david.holmes at oracle.com (David Holmes) Date: Fri, 29 May 2020 14:18:12 +1000 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <2eda234f-045d-1145-40ae-cf2b0b7cd5c5@oracle.com> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> <2f2218dd-de42-bfd4-974a-76ef3d840882@oracle.com> <8f53afb4-d11d-ae62-756f-8093726e098d@oracle.com> <7f82b76b-d9ed-2ccd-5fd1-8a5e68cb0a52@oracle.com> <2eda234f-045d-1145-40ae-cf2b0b7cd5c5@oracle.com> Message-ID: On 29/05/2020 1:52 pm, Mandy Chung wrote: > On 5/28/20 5:44 PM, David Holmes wrote: >>> >>> This is to validate the given version.? The runtime will check if >>> preview feature is enabled when such class file is loaded. I will >>> make a comment to make it clear. >> >> Okay but I thought the intent here was to pre-validate the version >> information so that when these bytes get passed to ASM you don't have >> to worry about the IAE that will be thrown by ASM if there is actually >> a problem. > > Yes it is.? ASM does not check if preview features are enabled or not > neither.? When a class file depending preview features is passed to VM, > the VM will throw an exception if preview features are not enabled. Yes but will that VM exception propagate as-is, or will ASM catch it and turn it into IAE? If the latter then your original problem still exists. >> Maybe the only real solution here is for ASM to be more specific with >> the exceptions it throws. :( >> > > This was discussed. > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066734.html Sure that is why you made the current change. But if ASM catches the VM exceptions and adapts them then your problem is not solved by pre-inspecting the major/minor version, unless you can implement a full validity check. Otherwise the only place this can be properly fixed is in ASM. >> Sure but we provide that kind of cross-package access all the time. We >> also have JAVA_MAX_SUPPORTED_VERSION in the ModuleInfo class. Seems >> messy to add yet a third place where we need to determine what the >> current major version number is. >> > > Ah, that's another place.? I think it's better to add > VM::isSupportedModuleDescriptorVersion and remove these constants. > >> That aside isn't the minor version, as set in java.class.version >> guaranteed to be zero? >> > This is set at build time.?? The minor version is zero for the current > versioning scheme. So you are allowing for someone arbitrarily setting DEFAULT_VERSION_CLASSFILE_MINOR in make/autoconf/version-numbers? I guess it doesn't hurt to be flexible, but seems unlikely anyone would want to mess with that. If this were VM code I'd just assert the minor version is 0, but Java assertions are much more heavyweight. Thanks, David > Mandy > >> David >> ----- >> >>> Mandy >>>> Cheers, >>>> David >>>> >>>>> Mandy >>>>> >>>>> On 5/27/20 10:57 AM, Mandy Chung wrote: >>>>>> I'm reconsidering this fix along with JDK-8245061 that may require >>>>>> to do its own checking (a similar issue w.r.t. ASM validation but >>>>>> in this case the constant pool entry of `this_class` item is not >>>>>> validated). >>>>>> >>>>>> thanks >>>>>> Mandy >>>>>> >>>>>> On 5/27/20 10:39 AM, forax at univ-mlv.fr wrote: >>>>>>> Hi Alan, >>>>>>> We (the ASM team) recommend to our users to check the byte 6 (and >>>>>>> perhaps 7) instead of relying on ASM throwing an exception, >>>>>>> because you may update the version of ASM but not the visitors >>>>>>> your are using in your code. >>>>>>> >>>>>>> It's less brittle than catching the IAE thrown by ASM. >>>>>>> >>>>>>> R?mi >>>>>>> >>>>>>> ----- Mail original ----- >>>>>>>> De: "Alan Bateman" >>>>>>>> ?: "mandy chung" , "core-libs-dev" >>>>>>>> , "Remi Forax" >>>>>>>> >>>>>>>> Envoy?: Mercredi 27 Mai 2020 18:16:33 >>>>>>>> Objet: Re: RFR: JDK-8245432: Lookup::defineHiddenClass should >>>>>>>> throw UnsupportedClassVersionError if the given bytes are >>>>>>>> of an unsupported major or minor version >>>>>>>> On 26/05/2020 22:46, Mandy Chung wrote: >>>>>>>>> Lookup::defineHiddenClass currently throws IAE by ASM if the given >>>>>>>>> bytes are of unsupported class file version.? The implementation >>>>>>>>> should catch and throw UnsupportedClassVersionError instead. >>>>>>>>> >>>>>>>>> webrev: >>>>>>>>> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.00/ >>>>>>>>> >>>>>>>>> >>>>>>>>> This patch also includes a spec clarification of @throws IAE if >>>>>>>>> the >>>>>>>>> the bytes has ACC_MODULE flag set to fix JDK-8245596. >>>>>>>> R?mi - has there ever been any discussion in ASM about throwing >>>>>>>> more >>>>>>>> specific exceptions? Only asking to see if we could avoid >>>>>>>> needing to >>>>>>>> depend on the exception message here. >>>>>>>> >>>>>>>> -Alan >>>>>> >>>>> >>> > From daniel.fuchs at oracle.com Fri May 29 09:01:35 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 29 May 2020 10:01:35 +0100 Subject: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space" In-Reply-To: References: Message-ID: <8657dfbc-4584-e8a4-ff14-b1056adcecff@oracle.com> Hi David, Thanks for the feedback! On 29/05/2020 00:36, David Holmes wrote: > This seems to be assuming that the GC will clear all SoftReferences when > it needs to clear any SoftReference. I don't think that is at all > guaranteed. In theory your memory eating loop could be satisfied by > clearing only the SoftReference added in the previous iteration of the > loop. I was wondering about that. > I would have expected the fix here to be simply to clear memory ie: > > } catch (OutOfMemoryError oome) { > ? stop = true; > ? memory = null; > ? System.gc(); > } Do you think this would be more reliable? It was my first thought as well - and that was the first thing I tested, and it seemed to work as well. If you think it's a better solution I can revert to that. My rationale for using SoftReference is that they then could be cleared any time by the GC, and possibly avoid unexpected OOME elsewhere in the test machinery. best regards, -- daniel From conor.cleary at oracle.com Fri May 29 09:04:51 2020 From: conor.cleary at oracle.com (Conor Cleary) Date: Fri, 29 May 2020 10:04:51 +0100 Subject: RFR(xs): 8245970: IntStream.html#reduce doc should not mention average Message-ID: Hi, The method-level documentation of Intstream::reduce(int, IntBinaryOperator) mentions the average function as a case of reduction even though the function cannot be used with the reduce method. This might cause confusion, this fix therefore removes the mention of the average function from the @apiNote. bug: https://bugs.openjdk.java.net/browse/JDK-8245970 webrev: http://cr.openjdk.java.net/~jboes/ccleary/webrevs/8242281/webrev.00/ Regards, Conor From conor.cleary at oracle.com Fri May 29 09:37:11 2020 From: conor.cleary at oracle.com (Conor Cleary) Date: Fri, 29 May 2020 10:37:11 +0100 Subject: RFR[8245658]: 'Arrays.java has two occurrences of bad unicode constants in Javadoc.' Message-ID: <57a312a6-be3c-035e-adec-92f8d1ca8b50@oracle.com> Hi, Could someone please review my webrev for JDK-8245658 'Arrays.java has two occurrences of bad unicode constants in Javadoc.'? In Arrays.java Javadoc, there were two instances of bad Unicode formatting where the null character constant was incorrectly specified with '\u000' (another zero is required). This fix displays the correct Unicode constants in the Javadoc so that outputted docs display '\u0000'. bug: https://bugs.openjdk.java.net/browse/JDK-8245658 webrev: http://cr.openjdk.java.net/~pconcannon/ccleary/8245658/webrevs/webrev.01/ Regards, Conor From james.laskey at oracle.com Fri May 29 09:54:19 2020 From: james.laskey at oracle.com (James Laskey) Date: Fri, 29 May 2020 06:54:19 -0300 Subject: RFR[8245658]: 'Arrays.java has two occurrences of bad unicode constants in Javadoc.' In-Reply-To: <57a312a6-be3c-035e-adec-92f8d1ca8b50@oracle.com> References: <57a312a6-be3c-035e-adec-92f8d1ca8b50@oracle.com> Message-ID: +1 ?? > On May 29, 2020, at 6:37 AM, Conor Cleary wrote: > > ?Hi, > > Could someone please review my webrev for JDK-8245658 'Arrays.java has two occurrences of bad unicode constants in Javadoc.'? > > In Arrays.java Javadoc, there were two instances of bad Unicode formatting where the null character constant was incorrectly specified with '\u000' (another zero is required). This fix displays the correct Unicode constants in the Javadoc so that outputted docs display '\u0000'. > > bug: https://bugs.openjdk.java.net/browse/JDK-8245658 > webrev: http://cr.openjdk.java.net/~pconcannon/ccleary/8245658/webrevs/webrev.01/ > > > Regards, > Conor > From lance.andersen at oracle.com Fri May 29 10:25:28 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 29 May 2020 06:25:28 -0400 Subject: RFR[8245658]: 'Arrays.java has two occurrences of bad unicode constants in Javadoc.' In-Reply-To: <57a312a6-be3c-035e-adec-92f8d1ca8b50@oracle.com> References: <57a312a6-be3c-035e-adec-92f8d1ca8b50@oracle.com> Message-ID: <9D52BDA5-A29D-4E4F-8D4F-B626797EFB4A@oracle.com> looks fine Connor > On May 29, 2020, at 5:37 AM, Conor Cleary wrote: > > Hi, > > Could someone please review my webrev for JDK-8245658 'Arrays.java has two occurrences of bad unicode constants in Javadoc.'? > > In Arrays.java Javadoc, there were two instances of bad Unicode formatting where the null character constant was incorrectly specified with '\u000' (another zero is required). This fix displays the correct Unicode constants in the Javadoc so that outputted docs display '\u0000'. > > bug: https://bugs.openjdk.java.net/browse/JDK-8245658 > webrev: http://cr.openjdk.java.net/~pconcannon/ccleary/8245658/webrevs/webrev.01/ > > > Regards, > Conor > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Fri May 29 10:27:30 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 29 May 2020 06:27:30 -0400 Subject: RFR[8245658]: 'Arrays.java has two occurrences of bad unicode constants in Javadoc.' In-Reply-To: <9D52BDA5-A29D-4E4F-8D4F-B626797EFB4A@oracle.com> References: <57a312a6-be3c-035e-adec-92f8d1ca8b50@oracle.com> <9D52BDA5-A29D-4E4F-8D4F-B626797EFB4A@oracle.com> Message-ID: <29FEF43C-CD62-4EC9-BE06-6C8486165354@oracle.com> Hi Connor, You will want to add the label noreg-doc to the issue before you push for fix Best Lance > On May 29, 2020, at 6:25 AM, Lance Andersen wrote: > > looks fine Connor > >> On May 29, 2020, at 5:37 AM, Conor Cleary wrote: >> >> Hi, >> >> Could someone please review my webrev for JDK-8245658 'Arrays.java has two occurrences of bad unicode constants in Javadoc.'? >> >> In Arrays.java Javadoc, there were two instances of bad Unicode formatting where the null character constant was incorrectly specified with '\u000' (another zero is required). This fix displays the correct Unicode constants in the Javadoc so that outputted docs display '\u0000'. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8245658 >> webrev: http://cr.openjdk.java.net/~pconcannon/ccleary/8245658/webrevs/webrev.01/ >> >> >> Regards, >> Conor >> > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Fri May 29 10:38:11 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 29 May 2020 06:38:11 -0400 Subject: RFR(xs): 8245970: IntStream.html#reduce doc should not mention average In-Reply-To: References: Message-ID: Hi Conor, I believe you want to reference https://bugs.openjdk.java.net/browse/JDK-8242281 as the issue below ,https://bugs.openjdk.java.net/browse/JDK-8245970, is the CSR that was withdrawn. Please add the label noreg-doc prior to finalizing your fix. The change looks fine otherwise. Best Lance > On May 29, 2020, at 5:04 AM, Conor Cleary wrote: > > Hi, > > The method-level documentation of Intstream::reduce(int, IntBinaryOperator) mentions the average function as a case of reduction even though the function cannot be used with the reduce method. This might cause confusion, this fix therefore removes the mention of the average function from the @apiNote. > > bug: https://bugs.openjdk.java.net/browse/JDK-8245970 > webrev: http://cr.openjdk.java.net/~jboes/ccleary/webrevs/8242281/webrev.00/ > > Regards, > Conor > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From pavel.rappo at oracle.com Fri May 29 10:38:49 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 29 May 2020 11:38:49 +0100 Subject: RFR[8245658]: 'Arrays.java has two occurrences of bad unicode constants in Javadoc.' In-Reply-To: <57a312a6-be3c-035e-adec-92f8d1ca8b50@oracle.com> References: <57a312a6-be3c-035e-adec-92f8d1ca8b50@oracle.com> Message-ID: <610EB080-6C79-46E8-ADBB-E3C6C906F125@oracle.com> There were two issues with this sequence in the resulting HTML pages. The first one, which you mentioned and fixed, was a missing zero. The second one, which you fixed but didn't mention, was an extra slash symbol. Looks good to me. P.S. There seem to be more cases where authors assumed the contents of the {@code} inline tags are not in any way interpreted. While this is certainly true for HTML entities and special symbols, it doesn't eliminate translation of \uxxxx sequences performed by the compiler. -Pavel > On 29 May 2020, at 10:37, Conor Cleary wrote: > > Hi, > > Could someone please review my webrev for JDK-8245658 'Arrays.java has two occurrences of bad unicode constants in Javadoc.'? > > In Arrays.java Javadoc, there were two instances of bad Unicode formatting where the null character constant was incorrectly specified with '\u000' (another zero is required). This fix displays the correct Unicode constants in the Javadoc so that outputted docs display '\u0000'. > > bug: https://bugs.openjdk.java.net/browse/JDK-8245658 > webrev: http://cr.openjdk.java.net/~pconcannon/ccleary/8245658/webrevs/webrev.01/ > > > Regards, > Conor > From james.laskey at oracle.com Fri May 29 10:45:59 2020 From: james.laskey at oracle.com (James Laskey) Date: Fri, 29 May 2020 07:45:59 -0300 Subject: RFR(xs): 8245970: IntStream.html#reduce doc should not mention average In-Reply-To: References: Message-ID: +1 ?? > On May 29, 2020, at 6:05 AM, Conor Cleary wrote: > > ?Hi, > > The method-level documentation of Intstream::reduce(int, IntBinaryOperator) mentions the average function as a case of reduction even though the function cannot be used with the reduce method. This might cause confusion, this fix therefore removes the mention of the average function from the @apiNote. > > bug: https://bugs.openjdk.java.net/browse/JDK-8245970 > webrev: http://cr.openjdk.java.net/~jboes/ccleary/webrevs/8242281/webrev.00/ > > Regards, > Conor > From maurizio.cimadamore at oracle.com Fri May 29 11:21:38 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 29 May 2020 12:21:38 +0100 Subject: RFR 8246040: java/foreign/TestAddressHandle fails on big endian platforms Message-ID: <28366e15-930b-d205-6f67-e1e144140ba7@oracle.com> Hi, following integration of second iteration of foreign memory access API, one of the new tests started acting up on big endian platforms (thanks to Thomas St?fe for catching this!). Here's a fix: http://cr.openjdk.java.net/~mcimadamore/8246040_v1/webrev/ Cheers Maurizio From chris.hegarty at oracle.com Fri May 29 11:31:22 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 29 May 2020 12:31:22 +0100 Subject: RFR 8246040: java/foreign/TestAddressHandle fails on big endian platforms In-Reply-To: <28366e15-930b-d205-6f67-e1e144140ba7@oracle.com> References: <28366e15-930b-d205-6f67-e1e144140ba7@oracle.com> Message-ID: > On 29 May 2020, at 12:21, Maurizio Cimadamore wrote: > ... > > http://cr.openjdk.java.net/~mcimadamore/8246040_v1/webrev/ > LGTM. -Chris. From sundararajan.athijegannathan at oracle.com Fri May 29 12:56:40 2020 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Fri, 29 May 2020 18:26:40 +0530 Subject: RFR 8246040: java/foreign/TestAddressHandle fails on big endian platforms In-Reply-To: <28366e15-930b-d205-6f67-e1e144140ba7@oracle.com> References: <28366e15-930b-d205-6f67-e1e144140ba7@oracle.com> Message-ID: Looks good to me. -Sundar On 29/05/20 4:51 pm, Maurizio Cimadamore wrote: > Hi, > following integration of second iteration of foreign memory access > API, one of the new tests started acting up on big endian platforms > (thanks to Thomas St?fe for catching this!). > > Here's a fix: > > http://cr.openjdk.java.net/~mcimadamore/8246040_v1/webrev/ > > Cheers > Maurizio > From daniel.fuchs at oracle.com Fri May 29 13:06:13 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 29 May 2020 14:06:13 +0100 Subject: RFR[8245658]: 'Arrays.java has two occurrences of bad unicode constants in Javadoc.' In-Reply-To: <57a312a6-be3c-035e-adec-92f8d1ca8b50@oracle.com> References: <57a312a6-be3c-035e-adec-92f8d1ca8b50@oracle.com> Message-ID: Looks good to me Conor! best regards, -- daniel On 29/05/2020 10:37, Conor Cleary wrote: > Hi, > > Could someone please review my webrev for JDK-8245658 'Arrays.java has > two occurrences of bad unicode constants in Javadoc.'? > > In Arrays.java Javadoc, there were two instances of bad Unicode > formatting where the null character constant was incorrectly specified > with '\u000' (another zero is required). This fix displays the correct > Unicode constants in the Javadoc so that outputted docs display '\u0000'. > > bug: https://bugs.openjdk.java.net/browse/JDK-8245658 > webrev: > http://cr.openjdk.java.net/~pconcannon/ccleary/8245658/webrevs/webrev.01/ > > > Regards, > Conor > From daniel.fuchs at oracle.com Fri May 29 13:14:24 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 29 May 2020 14:14:24 +0100 Subject: RFR(xs): 8242281: IntStream.html#reduce doc should not mention average In-Reply-To: References: Message-ID: <628db0fc-c489-a78b-fae3-44855d421eb1@oracle.com> Hi, You should also remove the @see #average() tag. I see this was already proposed in the CSR. When you push make sure to push with 8242281 (which is the bug id) and not with 8245970 - which is the CSR id. I have corrected the subject to help archeological search of the mail archive. best regards, -- daniel On 29/05/2020 10:04, Conor Cleary wrote: > Hi, > > The method-level documentation of Intstream::reduce(int, > IntBinaryOperator) mentions the average function as a case of reduction > even though the function cannot be used with the reduce method. This > might cause confusion, this fix therefore removes the mention of the > average function from the @apiNote. > > bug: https://bugs.openjdk.java.net/browse/JDK-8245970 > webrev: > http://cr.openjdk.java.net/~jboes/ccleary/webrevs/8242281/webrev.00/ > > Regards, > Conor > From pavel.rappo at oracle.com Fri May 29 13:27:21 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Fri, 29 May 2020 14:27:21 +0100 Subject: RFR(xs): 8242281: IntStream.html#reduce doc should not mention average In-Reply-To: <628db0fc-c489-a78b-fae3-44855d421eb1@oracle.com> References: <628db0fc-c489-a78b-fae3-44855d421eb1@oracle.com> Message-ID: Daniel, have you considered that comment from Paul Sandoz to that CSR? > IMHO removing the @see is not necessary in this respect, it's useful to point to related reduction methods. https://bugs.openjdk.java.net/browse/JDK-8245970?focusedCommentId=14341561&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14341561 > On 29 May 2020, at 14:14, Daniel Fuchs wrote: > > Hi, > > You should also remove the @see #average() tag. > I see this was already proposed in the CSR. > > When you push make sure to push with 8242281 (which is the bug id) > and not with 8245970 - which is the CSR id. I have corrected > the subject to help archeological search of the mail archive. > > best regards, > > -- daniel > > > On 29/05/2020 10:04, Conor Cleary wrote: >> Hi, >> The method-level documentation of Intstream::reduce(int, IntBinaryOperator) mentions the average function as a case of reduction even though the function cannot be used with the reduce method. This might cause confusion, this fix therefore removes the mention of the average function from the @apiNote. >> bug: https://bugs.openjdk.java.net/browse/JDK-8245970 >> webrev: http://cr.openjdk.java.net/~jboes/ccleary/webrevs/8242281/webrev.00/ >> Regards, >> Conor > From daniel.fuchs at oracle.com Fri May 29 13:31:50 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 29 May 2020 14:31:50 +0100 Subject: RFR(xs): 8242281: IntStream.html#reduce doc should not mention average In-Reply-To: References: <628db0fc-c489-a78b-fae3-44855d421eb1@oracle.com> Message-ID: <77e57ac7-a6cf-6181-3e86-527a0e02392e@oracle.com> Oh! Thanks for pointing that Pavel. I should read comments fully ;-) I hadn't noticed that the CSR was withdrawn - I saw it was closed and thought it had been Approved. Well - keep the @see then! best regards, -- daniel On 29/05/2020 14:27, Pavel Rappo wrote: > Daniel, have you considered that comment from Paul Sandoz to that CSR? > >> IMHO removing the @see is not necessary in this respect, it's useful to point to related reduction methods. > https://bugs.openjdk.java.net/browse/JDK-8245970?focusedCommentId=14341561&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14341561 > From andy.herrick at oracle.com Fri May 29 14:36:30 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 29 May 2020 10:36:30 -0400 Subject: RFR: JDK-8246010: AdditionalLaunchersTest is not enabled, and fails. Message-ID: <1d333406-e903-e5b0-c247-609293cc8322@oracle.com> Please review jpackage fix at [1] to issue [2] /Andy [1] http://cr.openjdk.java.net/~herrick/8246010/webrev.01/ [2] https://bugs.openjdk.java.net/browse/JDK-8246010 From claes.redestad at oracle.com Fri May 29 15:05:19 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 29 May 2020 17:05:19 +0200 Subject: RFR: 8246152: Improve String concat bootstrapping Message-ID: <81b395c2-9235-47d7-56b6-42ef8a56963c@oracle.com> Hi, a few small simplifications and optimizations to StringConcatFactory: - refactor makeConcat/makeConcatWithArguments methods to remove the generateRecipe argument - fold back-to-back constants into one when parsing recipe, which allows the prepender logic to be simplified - do input checking in the parse pass - get rid of the Recipe and RecipeElement classes by representing the parsed recipe as a list of Strings which are either null (argument slot) or not (constant) - eagerly rebind on setup of those method handles that we'll always transform (transforming will call rebind() anyway which will now be a no-op) - simplify filtering logic by picking up the erased type, so that we can do c == Object.class rather than !c.isPrimitive Also adding a microbenchmark I used to step by step verify the fixes having a real and measurable effect[1], while verifying a few percent improvement on a few existing startup tests[2]. Bug: https://bugs.openjdk.java.net/browse/JDK-8246152 Webrev: http://cr.openjdk.java.net/~redestad/8246152/open.00/ Testing: tier1 Thanks! /Claes [1] java -jar build/linux-x64/images/test/micro/benchmarks.jar StringConcatFactoryBootstraps -f 2 -w 5 -r 5 -prof gc -jvmArgs=-Xmx1g Before: Benchmark Mode Cnt Score Error Units StringConcatFactoryBootstraps.makeConcatWithConstants avgt 10 3046.855 ? 62.981 ns/op StringConcatFactoryBootstraps.makeConcatWithConstants:?gc.alloc.rate.norm avgt 10 4596.214 ? 121.121 B/op After: Benchmark Mode Cnt Score Error Units StringConcatFactoryBootstraps.makeConcatWithConstants avgt 10 2764.634 ? 56.244 ns/op StringConcatFactoryBootstraps.makeConcatWithConstants:?gc.alloc.rate.norm avgt 10 4136.187 ? 0.013 B/op [2] http://cr.openjdk.java.net/~redestad/scratch/erase_scf_types.00/ObjStringCombos.java Before: 3,661,949,568 instructions # 1.09 insn per cycle ( +- 1.04% ) 728,280,499 branches # 492.540 M/sec ( +- 1.06% ) 30,496,964 branch-misses # 4.19% of all branches ( +- 0.93% ) 0.301502707 seconds time elapsed ( +- 1.04% ) After: 3,485,679,714 instructions # 1.09 insn per cycle ( +- 0.90% ) 692,247,529 branches # 491.822 M/sec ( +- 0.92% ) 28,939,534 branch-misses # 4.18% of all branches ( +- 0.90% ) 0.291642667 seconds time elapsed ( +- 0.93% ) From daniel.fuchs at oracle.com Fri May 29 15:39:34 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 29 May 2020 16:39:34 +0100 Subject: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space" In-Reply-To: References: Message-ID: <4c4726bb-dd7e-95a6-8191-b85ef2f3afd1@oracle.com> Hi, I have updated the webrev as suggested by David: http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.01 Unless I hear any objection I'll push that new version if the tests come back successful. best regards, -- daniel (tier1 and 2 passed, tier5 still running) On 29/05/2020 00:36, David Holmes wrote: >> webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.00/ > > I would have expected the fix here to be simply to clear memory ie: > > } catch (OutOfMemoryError oome) { > ? stop = true; > ? memory = null; > ? System.gc(); > } > > Cheers, > David From daniel.daugherty at oracle.com Fri May 29 15:45:08 2020 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 29 May 2020 11:45:08 -0400 Subject: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space" In-Reply-To: <4c4726bb-dd7e-95a6-8191-b85ef2f3afd1@oracle.com> References: <4c4726bb-dd7e-95a6-8191-b85ef2f3afd1@oracle.com> Message-ID: <15d6a9f0-ae7a-72b5-7aef-a404e089d10a@oracle.com> On 5/29/20 11:39 AM, Daniel Fuchs wrote: > Hi, > > I have updated the webrev as suggested by David: > > http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.01 test/jdk/java/util/logging/Logger/bundleLeak/BundleTest.java ??? No comments. Thumbs up. Dan > > Unless I hear any objection I'll push that new version if the > tests come back successful. > > best regards, > > -- daniel > > (tier1 and 2 passed, tier5 still running) > > On 29/05/2020 00:36, David Holmes wrote: >>> webrev: >>> http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.00/ >> >> I would have expected the fix here to be simply to clear memory ie: >> >> } catch (OutOfMemoryError oome) { >> ?? stop = true; >> ?? memory = null; >> ?? System.gc(); >> } >> >> Cheers, >> David From forax at univ-mlv.fr Fri May 29 15:51:18 2020 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 29 May 2020 17:51:18 +0200 (CEST) Subject: RFR: 8246152: Improve String concat bootstrapping In-Reply-To: <81b395c2-9235-47d7-56b6-42ef8a56963c@oracle.com> References: <81b395c2-9235-47d7-56b6-42ef8a56963c@oracle.com> Message-ID: <969465010.1363610.1590767478429.JavaMail.zimbra@u-pem.fr> Hi Claes, For the code below the comment "Mock the recipe to reuse the concat generator code", i believe you can use String.repeat() that was introduced recently. The code that parse the the receipe can be in its own method to make the code more readable, this method returns the list and use the StringBuilder internally. In generateMHInlineCopy, element.get(0) and element.get(1) should be stored in local variables after "elements.size() == 2" will make the code more readable In simpleConcat(), should use a local variable 'mh', like the newString or newArrayWithSuffix Can you explain me, what rebind is exactly ? R?mi ----- Mail original ----- > De: "Claes Redestad" > ?: "core-libs-dev" > Envoy?: Vendredi 29 Mai 2020 17:05:19 > Objet: RFR: 8246152: Improve String concat bootstrapping > Hi, > > a few small simplifications and optimizations to StringConcatFactory: > > - refactor makeConcat/makeConcatWithArguments methods to remove the > generateRecipe argument > - fold back-to-back constants into one when parsing recipe, which > allows the prepender logic to be simplified > - do input checking in the parse pass > - get rid of the Recipe and RecipeElement classes by representing the > parsed recipe as a list of Strings which are either null (argument slot) > or not (constant) > - eagerly rebind on setup of those method handles that we'll always > transform (transforming will call rebind() anyway which will now be a no-op) > - simplify filtering logic by picking up the erased type, so that we can > do c == Object.class rather than !c.isPrimitive > > Also adding a microbenchmark I used to step by step verify the fixes > having a real and measurable effect[1], while verifying a few percent > improvement on a few existing startup tests[2]. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8246152 > Webrev: http://cr.openjdk.java.net/~redestad/8246152/open.00/ > > Testing: tier1 > > Thanks! > > /Claes > > [1] > java -jar build/linux-x64/images/test/micro/benchmarks.jar > StringConcatFactoryBootstraps -f 2 -w 5 -r 5 -prof gc -jvmArgs=-Xmx1g > > Before: > Benchmark Mode Cnt Score Error Units > StringConcatFactoryBootstraps.makeConcatWithConstants avgt 10 3046.855 ? > 62.981 ns/op > StringConcatFactoryBootstraps.makeConcatWithConstants:?gc.alloc.rate.norm > avgt 10 4596.214 ? 121.121 B/op > > After: > Benchmark Mode Cnt Score Error Units > StringConcatFactoryBootstraps.makeConcatWithConstants avgt 10 2764.634 ? > 56.244 ns/op > StringConcatFactoryBootstraps.makeConcatWithConstants:?gc.alloc.rate.norm > avgt 10 4136.187 ? 0.013 B/op > > [2] > http://cr.openjdk.java.net/~redestad/scratch/erase_scf_types.00/ObjStringCombos.java > > Before: > 3,661,949,568 instructions # 1.09 insn per > cycle ( +- 1.04% ) > 728,280,499 branches # 492.540 M/sec > ( +- 1.06% ) > 30,496,964 branch-misses # 4.19% of all > branches ( +- 0.93% ) > > 0.301502707 seconds time elapsed > ( +- 1.04% ) > > After: > 3,485,679,714 instructions # 1.09 insn per > cycle ( +- 0.90% ) > 692,247,529 branches # 491.822 M/sec > ( +- 0.92% ) > 28,939,534 branch-misses # 4.18% of all > branches ( +- 0.90% ) > > 0.291642667 seconds time elapsed > ( +- 0.93% ) From lance.andersen at oracle.com Fri May 29 15:53:12 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 29 May 2020 11:53:12 -0400 Subject: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space" In-Reply-To: <4c4726bb-dd7e-95a6-8191-b85ef2f3afd1@oracle.com> References: <4c4726bb-dd7e-95a6-8191-b85ef2f3afd1@oracle.com> Message-ID: <6E7A573B-07AB-4994-B1E9-2FF3FEA77070@oracle.com> Hi Daniel, Do you still need the SoftReference import given you are no longer using it with memory.add()? Best Lance > On May 29, 2020, at 11:39 AM, Daniel Fuchs wrote: > > Hi, > > I have updated the webrev as suggested by David: > > http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.01 > > Unless I hear any objection I'll push that new version if the > tests come back successful. > > best regards, > > -- daniel > > (tier1 and 2 passed, tier5 still running) > > On 29/05/2020 00:36, David Holmes wrote: >>> webrev: >>> http://cr.openjdk.java.net/~dfuchs/webrev_8245867/webrev.00/ >> I would have expected the fix here to be simply to clear memory ie: >> } catch (OutOfMemoryError oome) { >> stop = true; >> memory = null; >> System.gc(); >> } >> Cheers, >> David Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From claes.redestad at oracle.com Fri May 29 16:10:40 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 29 May 2020 18:10:40 +0200 Subject: RFR: 8246152: Improve String concat bootstrapping In-Reply-To: <969465010.1363610.1590767478429.JavaMail.zimbra@u-pem.fr> References: <81b395c2-9235-47d7-56b6-42ef8a56963c@oracle.com> <969465010.1363610.1590767478429.JavaMail.zimbra@u-pem.fr> Message-ID: Hi, will deal with your suggestions soon, separately. :-) On 2020-05-29 17:51, Remi Forax wrote: > > Can you explain me, what rebind is exactly ? > MH.rebind() wraps any kind of MH as a BoundMethodHandle, which is necessary to subject it to transforms. /** Require this method handle to be a BMH, or else replace it with a "wrapper" BMH. * Many transforms are implemented only for BMHs. * @return a behaviorally equivalent BMH */ abstract BoundMethodHandle rebind(); On the DMHs we lookup rebind() will return a very simple BMH, which will return itself on the rebind() that will happen when doing transforms, e.g. in insertArguments (don't mind the "makeReinvoker": complex BMHs create chains from one another so that each partial expression doesn't grow too unwieldy): @Override BoundMethodHandle rebind() { if (!tooComplex()) { return this; } return makeReinvoker(this); } For those cases where we're caching a MH that will always be used in a transform - like most of the things we use when building up the MH tree in SCF - doing the rebind() pre-emptively means we move an allocating rebind from the common path to the once-per-MH setup step, while the subsequent rebinds will be trivial and non-allocating. Hope this makes sense! /Claes From paul.sandoz at oracle.com Fri May 29 16:13:33 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 29 May 2020 09:13:33 -0700 Subject: RFR(xs): 8245970: IntStream.html#reduce doc should not mention average In-Reply-To: References: Message-ID: +1 Paul. > On May 29, 2020, at 2:04 AM, Conor Cleary wrote: > > Hi, > > The method-level documentation of Intstream::reduce(int, IntBinaryOperator) mentions the average function as a case of reduction even though the function cannot be used with the reduce method. This might cause confusion, this fix therefore removes the mention of the average function from the @apiNote. > > bug: https://bugs.openjdk.java.net/browse/JDK-8245970 > webrev: http://cr.openjdk.java.net/~jboes/ccleary/webrevs/8242281/webrev.00/ > > Regards, > Conor > From forax at univ-mlv.fr Fri May 29 16:20:02 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 29 May 2020 18:20:02 +0200 (CEST) Subject: RFR: 8246152: Improve String concat bootstrapping In-Reply-To: References: <81b395c2-9235-47d7-56b6-42ef8a56963c@oracle.com> <969465010.1363610.1590767478429.JavaMail.zimbra@u-pem.fr> Message-ID: <1538193937.1376635.1590769202536.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Claes Redestad" > ?: "Remi Forax" > Cc: "core-libs-dev" > Envoy?: Vendredi 29 Mai 2020 18:10:40 > Objet: Re: RFR: 8246152: Improve String concat bootstrapping > Hi, > > will deal with your suggestions soon, separately. :-) > > On 2020-05-29 17:51, Remi Forax wrote: >> >> Can you explain me, what rebind is exactly ? >> > > MH.rebind() wraps any kind of MH as a BoundMethodHandle, which > is necessary to subject it to transforms. > > /** Require this method handle to be a BMH, or else replace it with > a "wrapper" BMH. > * Many transforms are implemented only for BMHs. > * @return a behaviorally equivalent BMH > */ > abstract BoundMethodHandle rebind(); > > On the DMHs we lookup rebind() will return a very simple BMH, which will > return itself on the rebind() that will happen when doing transforms, > e.g. in insertArguments (don't mind the "makeReinvoker": complex BMHs > create chains from one another so that each partial expression doesn't > grow too unwieldy): > > @Override > BoundMethodHandle rebind() { > if (!tooComplex()) { > return this; > } > return makeReinvoker(this); > } > > For those cases where we're caching a MH that will always be used in a > transform - like most of the things we use when building up the MH tree > in SCF - doing the rebind() pre-emptively means we move an allocating > rebind from the common path to the once-per-MH setup step, while the > subsequent rebinds will be trivial and non-allocating. > > Hope this makes sense! yes, thanks. > > /Claes R?mi From claes.redestad at oracle.com Fri May 29 16:47:03 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 29 May 2020 18:47:03 +0200 Subject: RFR: 8246152: Improve String concat bootstrapping In-Reply-To: <969465010.1363610.1590767478429.JavaMail.zimbra@u-pem.fr> References: <81b395c2-9235-47d7-56b6-42ef8a56963c@oracle.com> <969465010.1363610.1590767478429.JavaMail.zimbra@u-pem.fr> Message-ID: <0521bb87-3251-c2e2-6c3d-639b8ecc08b8@oracle.com> Hi R?mi, thanks for looking at this and suggesting some improvements! On 2020-05-29 17:51, Remi Forax wrote: > Hi Claes, > For the code below the comment "Mock the recipe to reuse the concat generator code", > i believe you can use String.repeat() that was introduced recently. Sure, > > The code that parse the the receipe can be in its own method to make the code more readable, > this method returns the list and use the StringBuilder internally. sure, > > In generateMHInlineCopy, > element.get(0) and element.get(1) should be stored in local variables after "elements.size() == 2" > will make the code more readable sure, > > In simpleConcat(), > should use a local variable 'mh', like the newString or newArrayWithSuffix yes! http://cr.openjdk.java.net/~redestad/8246152/open.01/ Re-running tier1 /Claes From chris.hegarty at oracle.com Fri May 29 17:00:26 2020 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 29 May 2020 18:00:26 +0100 Subject: RFR 8246095: Tweaks to memory access API In-Reply-To: <21b8eeff-7c72-7c89-b200-050fc0096414@oracle.com> References: <21b8eeff-7c72-7c89-b200-050fc0096414@oracle.com> Message-ID: > On 28 May 2020, at 22:25, Maurizio Cimadamore wrote: > > Hi, > this followup change includes a number of tweaks that have been added to the memory access API while we were in the process of integrating it. Most of them have been contributed by Chris (thanks!), and are all listed in great details in the CSR below: > > https://bugs.openjdk.java.net/browse/JDK-8246096 > > Implementation-wise it should be all relatively straightforward - apart for the bit of surgery on lambda forms which was required to add a new kind of lambda forms to 'collect' return values. For now this method handle adaptation is package private, and can only be used by MemoryHandles::filterValues - but, if people find it useful, we might consider adding it to the MethodHandle standard combinator toolbox. > > Cheers > Maurizio > > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8246095_v1/webrev/ I added myself as reviewer on the CSR. The code looks good to me. Thanks for taking the time to include these API tweaks in JDK 15. -Chris. From bob.vandette at oracle.com Fri May 29 17:07:53 2020 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 29 May 2020 13:07:53 -0400 Subject: RFR: 8245832 - JDK build make-static-libs should build all JDK libraries Message-ID: Please review this change that alters the make target ?make-static-libs? to produce static libraries for ALL native libraries in the JDK. Prior to this fix we only built a small select list. Note: I had to change the functions JAWT_GetAWT for all platforms to match the prototype which used _JNI_IMPORT_OR_EXPORT_ in order to avoid compilation failures due to mismatch of types. RFE: https://bugs.openjdk.java.net/browse/JDK-8245832 WEBREV: http://cr.openjdk.java.net/~bobv/8245832/webrev.00 Bob. From fernando.guallini at oracle.com Fri May 29 17:12:37 2020 From: fernando.guallini at oracle.com (Fernando Guallini) Date: Fri, 29 May 2020 18:12:37 +0100 Subject: RFR: JDK-8222241 - Example in ServiceLoader API docs should have one provides directive Message-ID: <08E8734E-D070-4595-A8EE-9DC355962349@oracle.com> Hi, in the ServiceLoader API docs, the given example specifying the service providers for a particular service should be comma-separated instead of using two separate ?provides? directives, that would result in a compilation error. Web rev: http://cr.openjdk.java.net/~pconcannon/fguallin/8222241/webrevs/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8222241 Thanks, Fernando From erik.joelsson at oracle.com Fri May 29 17:16:46 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 29 May 2020 10:16:46 -0700 Subject: RFR: 8245832 - JDK build make-static-libs should build all JDK libraries In-Reply-To: References: Message-ID: Looks good. /Erik On 2020-05-29 10:07, Bob Vandette wrote: > Please review this change that alters the make target ?make-static-libs? to produce static > libraries for ALL native libraries in the JDK. Prior to this fix we only built a small select list. > > Note: I had to change the functions JAWT_GetAWT for all platforms to match the prototype which > used _JNI_IMPORT_OR_EXPORT_ in order to avoid compilation failures due to mismatch > of types. > > RFE: > https://bugs.openjdk.java.net/browse/JDK-8245832 > > WEBREV: > http://cr.openjdk.java.net/~bobv/8245832/webrev.00 > > Bob. > From daniel.fuchs at oracle.com Fri May 29 17:18:30 2020 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 29 May 2020 18:18:30 +0100 Subject: 8245867: Logger/bundleLeak/BundleTest.java fails due to "OutOfMemoryError: Java heap space" In-Reply-To: <6E7A573B-07AB-4994-B1E9-2FF3FEA77070@oracle.com> References: <4c4726bb-dd7e-95a6-8191-b85ef2f3afd1@oracle.com> <6E7A573B-07AB-4994-B1E9-2FF3FEA77070@oracle.com> Message-ID: <3dce8acf-41fc-1bfa-9ccf-1c3f0e33ae12@oracle.com> On 29/05/2020 16:53, Lance Andersen wrote: > Hi Daniel, > > Do you still need the SoftReference import given you are no longer using > it with memory.add()? No - I removed it. cheers, -- daniel > > Best > Lance From forax at univ-mlv.fr Fri May 29 17:32:09 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 29 May 2020 19:32:09 +0200 (CEST) Subject: RFR: 8246152: Improve String concat bootstrapping In-Reply-To: <0521bb87-3251-c2e2-6c3d-639b8ecc08b8@oracle.com> References: <81b395c2-9235-47d7-56b6-42ef8a56963c@oracle.com> <969465010.1363610.1590767478429.JavaMail.zimbra@u-pem.fr> <0521bb87-3251-c2e2-6c3d-639b8ecc08b8@oracle.com> Message-ID: <54248071.1399088.1590773529717.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Claes Redestad" > ?: "Remi Forax" > Cc: "core-libs-dev" > Envoy?: Vendredi 29 Mai 2020 18:47:03 > Objet: Re: RFR: 8246152: Improve String concat bootstrapping > Hi R?mi, > > thanks for looking at this and suggesting some improvements! > > On 2020-05-29 17:51, Remi Forax wrote: >> Hi Claes, >> For the code below the comment "Mock the recipe to reuse the concat generator >> code", >> i believe you can use String.repeat() that was introduced recently. > > Sure, > >> >> The code that parse the the receipe can be in its own method to make the code >> more readable, >> this method returns the list and use the StringBuilder internally. > > sure, > >> >> In generateMHInlineCopy, >> element.get(0) and element.get(1) should be stored in local variables after >> "elements.size() == 2" >> will make the code more readable > > sure, > >> >> In simpleConcat(), >> should use a local variable 'mh', like the newString or newArrayWithSuffix > > yes! > > http://cr.openjdk.java.net/~redestad/8246152/open.01/ I don't think you need to check MAX_INDY_CONCAT_ARG_SLOTS anymore, given that now indy is based on invokeWithArguments instead of invoke. And i think you should keep the null checks of constants upfront to not change the semantics (you are allowing constant not referenced by a recipe to be null). The catch should be: catch (Error | RuntimeException e) { if you want the StringConcatException to be propagated all the other changes looks good. > > Re-running tier1 > > /Claes R?mi From Alan.Bateman at oracle.com Fri May 29 18:00:38 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 May 2020 19:00:38 +0100 Subject: RFR: JDK-8222241 - Example in ServiceLoader API docs should have one provides directive In-Reply-To: <08E8734E-D070-4595-A8EE-9DC355962349@oracle.com> References: <08E8734E-D070-4595-A8EE-9DC355962349@oracle.com> Message-ID: <1f33370f-a762-8259-ff61-a464a0f338be@oracle.com> On 29/05/2020 18:12, Fernando Guallini wrote: > Hi, > in the ServiceLoader API docs, the given example specifying the service providers for a particular service should be comma-separated instead of using two separate ?provides? directives, that would result in a compilation error. > > Web rev: http://cr.openjdk.java.net/~pconcannon/fguallin/8222241/webrevs/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222241 > Yes, it should be one `provides` directive. Can you intend the second class name to make the code fragment a bit more readable in the generated javadoc? -Alan From alexey.semenyuk at oracle.com Fri May 29 18:06:42 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 29 May 2020 14:06:42 -0400 Subject: RFR: JDK-8245831: Unify code parsing version strings on Mac and Windows In-Reply-To: <59f57b54-dc8c-3cc6-9662-4540aedf541a@oracle.com> References: <21c3ac81-80d4-72bd-7c99-002d4b941d7f@oracle.com> <8a3f9c48-9561-3a4a-7e07-53a9ebbc1539@oracle.com> <59f57b54-dc8c-3cc6-9662-4540aedf541a@oracle.com> Message-ID: <60fce5de-539b-fce1-308b-09d3d07b613b@oracle.com> On 5/27/2020 10:05 AM, Andy Herrick wrote: > looks good > > curious why app.identifier was added to cfg file.? I don't see it used > anywhere. Right. That is why I removed it. Thank you for the review! - Alexey > > /Andy > > On 5/26/2020 3:26 PM, Alexey Semenyuk wrote: >> Please review fix [2] for jpackage bug [1]. >> >> Get rid of duplicated code parsing version strings. Move the code >> parsing version strings to dedicated classes with unit test coverage. >> Also remove Mac specific identifier setting in app's config file from >> the shared code. >> >> - Alexey >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8245831 >> >> [2]?http://cr.openjdk.java.net/~asemenyuk/8245831/webrev.00 >> From Alan.Bateman at oracle.com Fri May 29 18:29:12 2020 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 29 May 2020 19:29:12 +0100 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <2eda234f-045d-1145-40ae-cf2b0b7cd5c5@oracle.com> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> <2f2218dd-de42-bfd4-974a-76ef3d840882@oracle.com> <8f53afb4-d11d-ae62-756f-8093726e098d@oracle.com> <7f82b76b-d9ed-2ccd-5fd1-8a5e68cb0a52@oracle.com> <2eda234f-045d-1145-40ae-cf2b0b7cd5c5@oracle.com> Message-ID: <2001d65c-9e3d-72c7-da79-d41aedc76c67@oracle.com> On 29/05/2020 04:52, Mandy Chung wrote: > > > On 5/28/20 5:44 PM, David Holmes wrote: >>> >>> This is to validate the given version.? The runtime will check if >>> preview feature is enabled when such class file is loaded.?? I will >>> make a comment to make it clear. >> >> Okay but I thought the intent here was to pre-validate the version >> information so that when these bytes get passed to ASM you don't have >> to worry about the IAE that will be thrown by ASM if there is >> actually a problem. > > Yes it is.? ASM does not check if preview features are enabled or not > neither.? When a class file depending preview features is passed to > VM, the VM will throw an exception if preview features are not enabled. >> >> Maybe the only real solution here is for ASM to be more specific with >> the exceptions it throws. :( >> > > This was discussed. > https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-May/066734.html > >> >> Sure but we provide that kind of cross-package access all the time. >> We also have JAVA_MAX_SUPPORTED_VERSION in the ModuleInfo class. >> Seems messy to add yet a third place where we need to determine what >> the current major version number is. >> > > Ah, that's another place.? I think it's better to add > VM::isSupportedModuleDescriptorVersion and remove these constants. > >> That aside isn't the minor version, as set in java.class.version >> guaranteed to be zero? >> > This is set at build time.?? The minor version is zero for the current > versioning scheme. I went through webrev.02 and the only issue is the magic is read as a u2 when it should be u4, otherwise looks good. -Alan From claes.redestad at oracle.com Fri May 29 18:45:26 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 29 May 2020 20:45:26 +0200 Subject: RFR: 8246152: Improve String concat bootstrapping In-Reply-To: <54248071.1399088.1590773529717.JavaMail.zimbra@u-pem.fr> References: <81b395c2-9235-47d7-56b6-42ef8a56963c@oracle.com> <969465010.1363610.1590767478429.JavaMail.zimbra@u-pem.fr> <0521bb87-3251-c2e2-6c3d-639b8ecc08b8@oracle.com> <54248071.1399088.1590773529717.JavaMail.zimbra@u-pem.fr> Message-ID: <7fba53bc-479d-3e1b-90f8-f364ee22a0a3@oracle.com> On 2020-05-29 19:32, forax at univ-mlv.fr wrote: > ----- Mail original ----- >> De: "Claes Redestad" >> ?: "Remi Forax" >> Cc: "core-libs-dev" >> Envoy?: Vendredi 29 Mai 2020 18:47:03 >> Objet: Re: RFR: 8246152: Improve String concat bootstrapping > >> Hi R?mi, >> >> thanks for looking at this and suggesting some improvements! >> >> On 2020-05-29 17:51, Remi Forax wrote: >>> Hi Claes, >>> For the code below the comment "Mock the recipe to reuse the concat generator >>> code", >>> i believe you can use String.repeat() that was introduced recently. >> >> Sure, >> >>> >>> The code that parse the the receipe can be in its own method to make the code >>> more readable, >>> this method returns the list and use the StringBuilder internally. >> >> sure, >> >>> >>> In generateMHInlineCopy, >>> element.get(0) and element.get(1) should be stored in local variables after >>> "elements.size() == 2" >>> will make the code more readable >> >> sure, >> >>> >>> In simpleConcat(), >>> should use a local variable 'mh', like the newString or newArrayWithSuffix >> >> yes! >> >> http://cr.openjdk.java.net/~redestad/8246152/open.01/ > > > I don't think you need to check MAX_INDY_CONCAT_ARG_SLOTS anymore, given that now indy is based on invokeWithArguments instead of invoke. Not sure what's changed, but let's leave this outside the scope of this RFE? > > And i think you should keep the null checks of constants upfront to not change the semantics (you are allowing constant not referenced by a recipe to be null). If anyone provides more constants than we use (including null values) we'll fail the cCount != constants.length check later and throw a StringConcatException anyway. So no real, semantic difference apart from a change in what the exception message will say, which I think is OK, no? > > The catch should be: > catch (Error | RuntimeException e) { > if you want the StringConcatException to be propagated StringConcatException is a regular Exception and is not thrown from generateMHInlineCopy. > > all the other changes looks good. Thanks! /Claes > >> >> Re-running tier1 >> >> /Claes > > R?mi > From paul.sandoz at oracle.com Fri May 29 19:15:12 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 29 May 2020 12:15:12 -0700 Subject: RFR 8246095: Tweaks to memory access API In-Reply-To: <21b8eeff-7c72-7c89-b200-050fc0096414@oracle.com> References: <21b8eeff-7c72-7c89-b200-050fc0096414@oracle.com> Message-ID: <749FEDA0-0E62-4E8A-BF2B-30F300DE83E6@oracle.com> +1 (reviewed on panama-dev) Paul. > On May 28, 2020, at 2:25 PM, Maurizio Cimadamore wrote: > > Hi, > this followup change includes a number of tweaks that have been added to the memory access API while we were in the process of integrating it. Most of them have been contributed by Chris (thanks!), and are all listed in great details in the CSR below: > > https://bugs.openjdk.java.net/browse/JDK-8246096 > > Implementation-wise it should be all relatively straightforward - apart for the bit of surgery on lambda forms which was required to add a new kind of lambda forms to 'collect' return values. For now this method handle adaptation is package private, and can only be used by MemoryHandles::filterValues - but, if people find it useful, we might consider adding it to the MethodHandle standard combinator toolbox. > > Cheers > Maurizio > > > Webrev: > > http://cr.openjdk.java.net/~mcimadamore/8246095_v1/webrev/ > > Javadoc: > > http://cr.openjdk.java.net/~mcimadamore/8246095_v1/javadoc/jdk/incubator/foreign/package-summary.html > > Specdiff: > > http://cr.openjdk.java.net/~mcimadamore/8246095_v1/specdiff/overview-summary.html > From forax at univ-mlv.fr Fri May 29 19:18:44 2020 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 29 May 2020 21:18:44 +0200 (CEST) Subject: RFR: 8246152: Improve String concat bootstrapping In-Reply-To: <7fba53bc-479d-3e1b-90f8-f364ee22a0a3@oracle.com> References: <81b395c2-9235-47d7-56b6-42ef8a56963c@oracle.com> <969465010.1363610.1590767478429.JavaMail.zimbra@u-pem.fr> <0521bb87-3251-c2e2-6c3d-639b8ecc08b8@oracle.com> <54248071.1399088.1590773529717.JavaMail.zimbra@u-pem.fr> <7fba53bc-479d-3e1b-90f8-f364ee22a0a3@oracle.com> Message-ID: <1078240106.1416341.1590779924766.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Claes Redestad" > ?: "Remi Forax" > Cc: "core-libs-dev" > Envoy?: Vendredi 29 Mai 2020 20:45:26 > Objet: Re: RFR: 8246152: Improve String concat bootstrapping > On 2020-05-29 19:32, forax at univ-mlv.fr wrote: >> ----- Mail original ----- >>> De: "Claes Redestad" >>> ?: "Remi Forax" >>> Cc: "core-libs-dev" >>> Envoy?: Vendredi 29 Mai 2020 18:47:03 >>> Objet: Re: RFR: 8246152: Improve String concat bootstrapping >> >>> Hi R?mi, >>> >>> thanks for looking at this and suggesting some improvements! >>> >>> On 2020-05-29 17:51, Remi Forax wrote: >>>> Hi Claes, >>>> For the code below the comment "Mock the recipe to reuse the concat generator >>>> code", >>>> i believe you can use String.repeat() that was introduced recently. >>> >>> Sure, >>> >>>> >>>> The code that parse the the receipe can be in its own method to make the code >>>> more readable, >>>> this method returns the list and use the StringBuilder internally. >>> >>> sure, >>> >>>> >>>> In generateMHInlineCopy, >>>> element.get(0) and element.get(1) should be stored in local variables after >>>> "elements.size() == 2" >>>> will make the code more readable >>> >>> sure, >>> >>>> >>>> In simpleConcat(), >>>> should use a local variable 'mh', like the newString or newArrayWithSuffix >>> >>> yes! >>> >>> http://cr.openjdk.java.net/~redestad/8246152/open.01/ >> >> >> I don't think you need to check MAX_INDY_CONCAT_ARG_SLOTS anymore, given that >> now indy is based on invokeWithArguments instead of invoke. > > Not sure what's changed, but let's leave this outside the scope of this > RFE? This is https://bugs.openjdk.java.net/browse/JDK-8186469 Agree that it can be changed later. > >> >> And i think you should keep the null checks of constants upfront to not change >> the semantics (you are allowing constant not referenced by a recipe to be >> null). > > If anyone provides more constants than we use (including null values) > we'll fail the cCount != constants.length check later and throw a > StringConcatException anyway. So no real, semantic difference apart from > a change in what the exception message will say, which I think is OK, > no? > >> >> The catch should be: >> catch (Error | RuntimeException e) { >> if you want the StringConcatException to be propagated > > StringConcatException is a regular Exception and is not thrown from > generateMHInlineCopy. in that case, you should fix the comment ? > >> >> all the other changes looks good. > > Thanks! > > /Claes R?mi > >> >>> >>> Re-running tier1 >>> >>> /Claes >> >> R?mi From mandy.chung at oracle.com Fri May 29 19:23:22 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 29 May 2020 12:23:22 -0700 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> <8625b4fe-6035-9096-a94d-64b0705a6595@oracle.com> <96d7b8b0-e6a2-fb2d-3786-3953c48ee72a@oracle.com> Message-ID: It's fixed.? Thanks Mandy On 5/28/20 4:35 PM, Johannes Kuhn wrote: > Hi, > > just noticed a small thing: > The magic is 4 bytes, but readUnsignedShort reads two bytes. > > - Johannes > > On 28-May-20 19:25, Mandy Chung wrote: >> >> >> On 5/28/20 6:55 AM, Alan Bateman wrote: >>> On 28/05/2020 05:13, Mandy Chung wrote: >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.01/ >>>> >>>> I modify this patch to check the class file version and throws CFE >>>> if unsupported before creating ClassReader.? This also fixes >>>> JDK-8245061 that it reads the value of `this_class` as a constant >>>> (as ASM will throw an exception if it's not a constant) and also >>>> ensures that `this_class` is a CONSTANT_Class_info by checking the >>>> descriptor string from Type. >>> I don't want to complicate this further but the --enable-preview >>> handling in the VM doesn't seem to expose an internal property that >>> allows code in the libraries know if preview feature are enabled or >>> not. I was assuming that isSupportedClassFileVersion would need to >>> check that. >>> >> >> The runtime will ensure if --enable-preview is set if a class file >> with minor is loaded.?? I will prefer to keep >> VM::isSupportedClassFileVersion to validate the given major/minor >> version.? At runtime, it will fail when such class file is loaded if >> preview is not enabled. >> >> I'll add a comment to describe that. >> >>> Will readUnsignedShort throw AIOBE if the offset is beyond the length? >> >> Good catch.? I add the check to throw CFE. >> +??????????? private static int readUnsignedShort(byte[] bytes, int >> offset) { >> +??????????????? if (offset >= bytes.length) { >> +??????????????????? throw new ClassFormatError("Invalid ClassFile >> structure"); >> +??????????????? } >> +??????????????? return ((bytes[offset] & 0xFF) << 8) | (bytes[offset >> + 1] & 0xFF); >> +??????????? } >> >>> Also are you sure about "& 0xCAFEBABE", I assumed it would just >>> check the magic number is equal to that. >> >> It should check ==.? Fixed. >> >> thanks >> Mandy > > From mandy.chung at oracle.com Fri May 29 19:25:32 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 29 May 2020 12:25:32 -0700 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <2001d65c-9e3d-72c7-da79-d41aedc76c67@oracle.com> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> <2f2218dd-de42-bfd4-974a-76ef3d840882@oracle.com> <8f53afb4-d11d-ae62-756f-8093726e098d@oracle.com> <7f82b76b-d9ed-2ccd-5fd1-8a5e68cb0a52@oracle.com> <2eda234f-045d-1145-40ae-cf2b0b7cd5c5@oracle.com> <2001d65c-9e3d-72c7-da79-d41aedc76c67@oracle.com> Message-ID: On 5/29/20 11:29 AM, Alan Bateman wrote: > I went through webrev.02 and the only issue is the magic is read as a > u2 when it should be u4, otherwise looks good. > Thanks.? Updated in place: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.02/index.html Mandy From claes.redestad at oracle.com Fri May 29 19:55:58 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 29 May 2020 21:55:58 +0200 Subject: RFR: 8246152: Improve String concat bootstrapping In-Reply-To: <1078240106.1416341.1590779924766.JavaMail.zimbra@u-pem.fr> References: <81b395c2-9235-47d7-56b6-42ef8a56963c@oracle.com> <969465010.1363610.1590767478429.JavaMail.zimbra@u-pem.fr> <0521bb87-3251-c2e2-6c3d-639b8ecc08b8@oracle.com> <54248071.1399088.1590773529717.JavaMail.zimbra@u-pem.fr> <7fba53bc-479d-3e1b-90f8-f364ee22a0a3@oracle.com> <1078240106.1416341.1590779924766.JavaMail.zimbra@u-pem.fr> Message-ID: On 2020-05-29 21:18, forax at univ-mlv.fr wrote: > > > ----- Mail original ----- >> De: "Claes Redestad" >> ?: "Remi Forax" >> Cc: "core-libs-dev" >> Envoy?: Vendredi 29 Mai 2020 20:45:26 >> Objet: Re: RFR: 8246152: Improve String concat bootstrapping > >> On 2020-05-29 19:32, forax at univ-mlv.fr wrote: >>> ----- Mail original ----- >>>> De: "Claes Redestad" >>>> ?: "Remi Forax" >>>> Cc: "core-libs-dev" >>>> Envoy?: Vendredi 29 Mai 2020 18:47:03 >>>> Objet: Re: RFR: 8246152: Improve String concat bootstrapping >>> >>>> Hi R?mi, >>>> >>>> thanks for looking at this and suggesting some improvements! >>>> >>>> On 2020-05-29 17:51, Remi Forax wrote: >>>>> Hi Claes, >>>>> For the code below the comment "Mock the recipe to reuse the concat generator >>>>> code", >>>>> i believe you can use String.repeat() that was introduced recently. >>>> >>>> Sure, >>>> >>>>> >>>>> The code that parse the the receipe can be in its own method to make the code >>>>> more readable, >>>>> this method returns the list and use the StringBuilder internally. >>>> >>>> sure, >>>> >>>>> >>>>> In generateMHInlineCopy, >>>>> element.get(0) and element.get(1) should be stored in local variables after >>>>> "elements.size() == 2" >>>>> will make the code more readable >>>> >>>> sure, >>>> >>>>> >>>>> In simpleConcat(), >>>>> should use a local variable 'mh', like the newString or newArrayWithSuffix >>>> >>>> yes! >>>> >>>> http://cr.openjdk.java.net/~redestad/8246152/open.01/ >>> >>> >>> I don't think you need to check MAX_INDY_CONCAT_ARG_SLOTS anymore, given that >>> now indy is based on invokeWithArguments instead of invoke. >> >> Not sure what's changed, but let's leave this outside the scope of this >> RFE? > > This is https://bugs.openjdk.java.net/browse/JDK-8186469 > Agree that it can be changed later. > >> >>> >>> And i think you should keep the null checks of constants upfront to not change >>> the semantics (you are allowing constant not referenced by a recipe to be >>> null). >> >> If anyone provides more constants than we use (including null values) >> we'll fail the cCount != constants.length check later and throw a >> StringConcatException anyway. So no real, semantic difference apart from >> a change in what the exception message will say, which I think is OK, >> no? Taking a longer look at it, there seems we weren't testing for all invariants w.r.t. mismatched number of constants. Added a few tests, and fixed an issue where providing too few constants would have thrown an AIOOBE instead of a SCE with my previous patch. >> >>> >>> The catch should be: >>> catch (Error | RuntimeException e) { >>> if you want the StringConcatException to be propagated >> >> StringConcatException is a regular Exception and is not thrown from >> generateMHInlineCopy. > > in that case, you should fix the comment ? Yes, good catch! Updated in-place. /Claes > >> >>> >>> all the other changes looks good. >> >> Thanks! >> >> /Claes > > > R?mi > >> >>> >>>> >>>> Re-running tier1 >>>> >>>> /Claes >>> >>> R?mi From paul.sandoz at oracle.com Fri May 29 19:57:49 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 29 May 2020 12:57:49 -0700 Subject: RFR: 8246152: Improve String concat bootstrapping In-Reply-To: <0521bb87-3251-c2e2-6c3d-639b8ecc08b8@oracle.com> References: <81b395c2-9235-47d7-56b6-42ef8a56963c@oracle.com> <969465010.1363610.1590767478429.JavaMail.zimbra@u-pem.fr> <0521bb87-3251-c2e2-6c3d-639b8ecc08b8@oracle.com> Message-ID: <2D79876C-FB53-4798-AFBC-C15210EDF255@oracle.com> This looks good. 204 String recipe = "\u0001".repeat(concatType.parameterCount()); IIUC, that?s a rather convoluted way of creating a List from: Collections.nCopies(concatType.parameterCount(). (String) null); Perhaps it makes sense to double down on the List representation with an internal method accepting that, which the public methods call? Paul. > On May 29, 2020, at 9:47 AM, Claes Redestad wrote: > > Hi R?mi, > > thanks for looking at this and suggesting some improvements! > > On 2020-05-29 17:51, Remi Forax wrote: >> Hi Claes, >> For the code below the comment "Mock the recipe to reuse the concat generator code", >> i believe you can use String.repeat() that was introduced recently. > > Sure, > >> The code that parse the the receipe can be in its own method to make the code more readable, >> this method returns the list and use the StringBuilder internally. > > sure, > >> In generateMHInlineCopy, >> element.get(0) and element.get(1) should be stored in local variables after "elements.size() == 2" >> will make the code more readable > > sure, > >> In simpleConcat(), >> should use a local variable 'mh', like the newString or newArrayWithSuffix > > yes! > > http://cr.openjdk.java.net/~redestad/8246152/open.01/ > > Re-running tier1 > > /Claes From mandy.chung at oracle.com Fri May 29 20:03:35 2020 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 29 May 2020 13:03:35 -0700 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> <2f2218dd-de42-bfd4-974a-76ef3d840882@oracle.com> <8f53afb4-d11d-ae62-756f-8093726e098d@oracle.com> <7f82b76b-d9ed-2ccd-5fd1-8a5e68cb0a52@oracle.com> <2eda234f-045d-1145-40ae-cf2b0b7cd5c5@oracle.com> Message-ID: <7c910287-fb2d-766e-8dd4-bc3e66edb9a9@oracle.com> On 5/28/20 9:18 PM, David Holmes wrote: > On 29/05/2020 1:52 pm, Mandy Chung wrote: >> On 5/28/20 5:44 PM, David Holmes wrote: >>>> >>>> This is to validate the given version.? The runtime will check if >>>> preview feature is enabled when such class file is loaded. I will >>>> make a comment to make it clear. >>> >>> Okay but I thought the intent here was to pre-validate the version >>> information so that when these bytes get passed to ASM you don't >>> have to worry about the IAE that will be thrown by ASM if there is >>> actually a problem. >> >> Yes it is.? ASM does not check if preview features are enabled or not >> neither.? When a class file depending preview features is passed to >> VM, the VM will throw an exception if preview features are not enabled. > > Yes but will that VM exception propagate as-is, or will ASM catch it > and turn it into IAE? If the latter then your original problem still > exists. > I think you may be confused with the code path.? ASM is used only to extract the class name from the bytes.? Once it verifies the class file version and name in the bytes, the next step is to pass the name and bytes to the VM to create the class where it checks if preview features are used and enabled.? If VM will throw an exception, it just gets propagated to the user (no ASM frame on the stack at that point).? See the new PreviewHiddenClass test. Updated webrev: http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.02/index.html This patch has a behavioral change to `Lookup::defineClass` if the bytes is not a class or interface. Lookup::defineClass does not specify what exception to throw if the given bytes has ACC_MODULE flag set in the access_flags item. The current implementation throws NoClassDefFoundError (which is the behavior specified in JVMS 5.3.5). I propose Lookup::defineClass to specify and throw IllegalArgumentException if the bytes has ACC_MODULE flag set in its access_flags item to be consistent with Lookup::defineHiddenClass. CSR: https://bugs.openjdk.java.net/browse/JDK-8246108 Mandy From hongsy2006 at gmail.com Fri May 29 09:49:33 2020 From: hongsy2006 at gmail.com (Hong Shao Yang) Date: Fri, 29 May 2020 17:49:33 +0800 Subject: [PATCH] Typo in java.util.regex.Pattern Message-ID: Hi! I found a typo which has been long undetected in the documentation. In case you think this is worthwhile, I would appreciate it if someone can sponsor this patch. Cheers, Shao Yang ========= PATCH ========== diff --git a/src/java.base/share/classes/java/util/regex/Pattern.java b/src/java.base/share/classes/java/util/regex/Pattern.java index 0d7d0738965..82325d04f25 100644 --- a/src/java.base/share/classes/java/util/regex/Pattern.java +++ b/src/java.base/share/classes/java/util/regex/Pattern.java @@ -760,7 +760,7 @@ import jdk.internal.util.ArraysSupport; * *

    For a more precise description of the behavior of regular expression * constructs, please see - * Mastering Regular Expressions, 3nd Edition, Jeffrey E. F. Friedl, + * Mastering Regular Expressions, 3rd Edition, Jeffrey E. F. Friedl, * O'Reilly and Associates, 2006. *

    * From maurizio.cimadamore at oracle.com Fri May 29 21:28:18 2020 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 29 May 2020 22:28:18 +0100 Subject: RFR 8246095: Tweaks to memory access API In-Reply-To: References: <21b8eeff-7c72-7c89-b200-050fc0096414@oracle.com> Message-ID: <5a50ef67-4667-dab8-7cb2-4e76338da4cf@oracle.com> > I added myself as reviewer on the CSR. Thanks > > The code looks good to me. > > Thanks for taking the time to include these API tweaks in JDK 15. Well, thank _you_ for contributing these great additions! Cheers Maurizio > > -Chris. From calvin.cheung at oracle.com Fri May 29 21:29:58 2020 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 29 May 2020 14:29:58 -0700 Subject: RFR(XL) 8198698: Support Lambda proxy classes in dynamic CDS archive Message-ID: <7da8b0f7-1027-d033-c1b5-7deb9d1d6c09@oracle.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8198698 webrev: http://cr.openjdk.java.net/~ccheung/jdk15/8198698/webrev.00/ There's a high level design doc in the attachment[1] of the RFE. Passed tiers 1 - 4 tests (including the new tests). thanks, Calvin [1] https://bugs.openjdk.java.net/secure/attachment/88446/archive_lambda_proxy.txt From claes.redestad at oracle.com Fri May 29 22:03:17 2020 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 30 May 2020 00:03:17 +0200 Subject: RFR: 8246152: Improve String concat bootstrapping In-Reply-To: <2D79876C-FB53-4798-AFBC-C15210EDF255@oracle.com> References: <81b395c2-9235-47d7-56b6-42ef8a56963c@oracle.com> <969465010.1363610.1590767478429.JavaMail.zimbra@u-pem.fr> <0521bb87-3251-c2e2-6c3d-639b8ecc08b8@oracle.com> <2D79876C-FB53-4798-AFBC-C15210EDF255@oracle.com> Message-ID: <5fb989df-5176-806b-3ab8-9c69f17a378b@oracle.com> Hi Paul, On 2020-05-29 21:57, Paul Sandoz wrote: > This looks good. Thanks for reviewing! > > 204 String recipe = "\u0001".repeat(concatType.parameterCount()); > > IIUC, that?s a rather convoluted way of creating a List from: > > Collections.nCopies(concatType.parameterCount(). (String) null); > > Perhaps it makes sense to double down on the List representation with an internal method accepting that, which the public methods call? My concern is that makeConcat is unlikely to be used in practice, so micro-optimizing it at the expense of the default BSM seem like a bad call. As discussed offline I'll add a short inline comment to this effect: // This bootstrap method is unlikely to be used in practice, // avoid optimizing it at the expense of makeConcatWithConstants Thanks! /Claes > > Paul. > >> On May 29, 2020, at 9:47 AM, Claes Redestad wrote: >> >> Hi R?mi, >> >> thanks for looking at this and suggesting some improvements! >> >> On 2020-05-29 17:51, Remi Forax wrote: >>> Hi Claes, >>> For the code below the comment "Mock the recipe to reuse the concat generator code", >>> i believe you can use String.repeat() that was introduced recently. >> >> Sure, >> >>> The code that parse the the receipe can be in its own method to make the code more readable, >>> this method returns the list and use the StringBuilder internally. >> >> sure, >> >>> In generateMHInlineCopy, >>> element.get(0) and element.get(1) should be stored in local variables after "elements.size() == 2" >>> will make the code more readable >> >> sure, >> >>> In simpleConcat(), >>> should use a local variable 'mh', like the newString or newArrayWithSuffix >> >> yes! >> >> http://cr.openjdk.java.net/~redestad/8246152/open.01/ >> >> Re-running tier1 >> >> /Claes > From alexander.matveev at oracle.com Fri May 29 23:00:31 2020 From: alexander.matveev at oracle.com (alexander.matveev at oracle.com) Date: Fri, 29 May 2020 16:00:31 -0700 Subject: RFR: JDK-8246010: AdditionalLaunchersTest is not enabled, and fails. In-Reply-To: <1d333406-e903-e5b0-c247-609293cc8322@oracle.com> References: <1d333406-e903-e5b0-c247-609293cc8322@oracle.com> Message-ID: Hi Andy, Why we need error.lock-resource? Also, I do not like 194 limit obtained by testing, since once new files are introduced in runtime this value might not work anymore. Can we check on actual file paths to make sure they have valid length? Thanks, Alexander On 5/29/20 7:36 AM, Andy Herrick wrote: > Please review jpackage fix at [1] to issue [2] > > /Andy > > [1] http://cr.openjdk.java.net/~herrick/8246010/webrev.01/ > > [2] https://bugs.openjdk.java.net/browse/JDK-8246010 > From andy.herrick at oracle.com Fri May 29 23:12:26 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 29 May 2020 19:12:26 -0400 Subject: RFR: JDK-8246010: AdditionalLaunchersTest is not enabled, and fails. In-Reply-To: References: <1d333406-e903-e5b0-c247-609293cc8322@oracle.com> Message-ID: <2c32ab4d-e434-2e0e-b615-f4338dba2d56@oracle.com> On 5/29/20 7:00 PM, alexander.matveev at oracle.com wrote: > Hi Andy, > > Why we need error.lock-resource? because resource was used , but never defined. > > Also, I do not like 194 limit obtained by testing, since once new > files are introduced in runtime this value might not work anymore. Can > we check on actual file paths to make sure they have valid length? I don't like it either, but otherwise we need to test length every time we create a path, and the check needs to be platform dependent. /Andy > > Thanks, > Alexander > > On 5/29/20 7:36 AM, Andy Herrick wrote: >> Please review jpackage fix at [1] to issue [2] >> >> /Andy >> >> [1] http://cr.openjdk.java.net/~herrick/8246010/webrev.01/ >> >> [2] https://bugs.openjdk.java.net/browse/JDK-8246010 >> > From alexey.semenyuk at oracle.com Fri May 29 23:16:31 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Fri, 29 May 2020 19:16:31 -0400 Subject: RFR: JDK-8246010: AdditionalLaunchersTest is not enabled, and fails. In-Reply-To: <2c32ab4d-e434-2e0e-b615-f4338dba2d56@oracle.com> References: <1d333406-e903-e5b0-c247-609293cc8322@oracle.com> <2c32ab4d-e434-2e0e-b615-f4338dba2d56@oracle.com> Message-ID: Andy, The check is added to WindowsAppImageBuilder.java which means it will be done for app image bundling too. However the problem is with msi bundling only as far as I understood from your explanation. Did you try fix suggested at [1]? [1] https://stackoverflow.com/questions/15431210/wix-relative-path-ends-up-being-too-long - Alexey On 5/29/2020 7:12 PM, Andy Herrick wrote: > > On 5/29/20 7:00 PM, alexander.matveev at oracle.com wrote: >> Hi Andy, >> >> Why we need error.lock-resource? > because resource was used , but never defined. >> >> Also, I do not like 194 limit obtained by testing, since once new >> files are introduced in runtime this value might not work anymore. >> Can we check on actual file paths to make sure they have valid length? > > I don't like it either, but otherwise we need to test length every > time we create a path, and the check needs to be platform dependent. > > /Andy > >> >> Thanks, >> Alexander >> >> On 5/29/20 7:36 AM, Andy Herrick wrote: >>> Please review jpackage fix at [1] to issue [2] >>> >>> /Andy >>> >>> [1] http://cr.openjdk.java.net/~herrick/8246010/webrev.01/ >>> >>> [2] https://bugs.openjdk.java.net/browse/JDK-8246010 >>> >> From info at j-kuhn.de Fri May 29 23:31:25 2020 From: info at j-kuhn.de (Johannes Kuhn) Date: Sat, 30 May 2020 01:31:25 +0200 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> <8625b4fe-6035-9096-a94d-64b0705a6595@oracle.com> <96d7b8b0-e6a2-fb2d-3786-3953c48ee72a@oracle.com> Message-ID: <9d0642dc-ea62-5a08-c257-0bf82dc2b48c@j-kuhn.de> Thanks. Noted that readInt can read outside of the byte array when it is shorter than 4 bytes, throwing an ArrayIndexOutOfBoundsException. Same applies for readUnsignedShort. Test cases for malformedClassFiles: new byte[3], new byte[] {0xCA, 0xFE, 0xBA, 0xBE, 0x00} - Johannes On 29-May-20 21:23, Mandy Chung wrote: > It's fixed.? Thanks > Mandy > > On 5/28/20 4:35 PM, Johannes Kuhn wrote: >> Hi, >> >> just noticed a small thing: >> The magic is 4 bytes, but readUnsignedShort reads two bytes. >> >> - Johannes >> >> On 28-May-20 19:25, Mandy Chung wrote: >>> >>> >>> On 5/28/20 6:55 AM, Alan Bateman wrote: >>>> On 28/05/2020 05:13, Mandy Chung wrote: >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.01/ >>>>> >>>>> I modify this patch to check the class file version and throws CFE >>>>> if unsupported before creating ClassReader. This also fixes >>>>> JDK-8245061 that it reads the value of `this_class` as a constant >>>>> (as ASM will throw an exception if it's not a constant) and also >>>>> ensures that `this_class` is a CONSTANT_Class_info by checking the >>>>> descriptor string from Type. >>>> I don't want to complicate this further but the --enable-preview >>>> handling in the VM doesn't seem to expose an internal property that >>>> allows code in the libraries know if preview feature are enabled or >>>> not. I was assuming that isSupportedClassFileVersion would need to >>>> check that. >>>> >>> >>> The runtime will ensure if --enable-preview is set if a class file >>> with minor is loaded.?? I will prefer to keep >>> VM::isSupportedClassFileVersion to validate the given major/minor >>> version.? At runtime, it will fail when such class file is loaded if >>> preview is not enabled. >>> >>> I'll add a comment to describe that. >>> >>>> Will readUnsignedShort throw AIOBE if the offset is beyond the length? >>> >>> Good catch.? I add the check to throw CFE. >>> +??????????? private static int readUnsignedShort(byte[] bytes, int >>> offset) { >>> +??????????????? if (offset >= bytes.length) { >>> +??????????????????? throw new ClassFormatError("Invalid ClassFile >>> structure"); >>> +??????????????? } >>> +??????????????? return ((bytes[offset] & 0xFF) << 8) | >>> (bytes[offset + 1] & 0xFF); >>> +??????????? } >>> >>>> Also are you sure about "& 0xCAFEBABE", I assumed it would just >>>> check the magic number is equal to that. >>> >>> It should check ==.? Fixed. >>> >>> thanks >>> Mandy >> >> > From andy.herrick at oracle.com Fri May 29 23:38:55 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Fri, 29 May 2020 19:38:55 -0400 Subject: RFR: JDK-8246010: AdditionalLaunchersTest is not enabled, and fails. In-Reply-To: References: <1d333406-e903-e5b0-c247-609293cc8322@oracle.com> <2c32ab4d-e434-2e0e-b615-f4338dba2d56@oracle.com> Message-ID: <0cc1a351-c23c-7d7c-be81-77cbdf317d66@oracle.com> On 5/29/20 7:16 PM, Alexey Semenyuk wrote: > Andy, > > The check is added to WindowsAppImageBuilder.java which means it will > be done for app image bundling too. However the problem is with msi > bundling only as far as I understood from your explanation. > Did you try fix suggested at [1]? Yes - should add more comments in the bug report. The problem exists for app-image bundle as well, from within ExecutableRebrander. /Z > > [1] > https://stackoverflow.com/questions/15431210/wix-relative-path-ends-up-being-too-long > > - Alexey > > On 5/29/2020 7:12 PM, Andy Herrick wrote: >> >> On 5/29/20 7:00 PM, alexander.matveev at oracle.com wrote: >>> Hi Andy, >>> >>> Why we need error.lock-resource? >> because resource was used , but never defined. >>> >>> Also, I do not like 194 limit obtained by testing, since once new >>> files are introduced in runtime this value might not work anymore. >>> Can we check on actual file paths to make sure they have valid length? >> >> I don't like it either, but otherwise we need to test length every >> time we create a path, and the check needs to be platform dependent. >> >> /Andy >> >>> >>> Thanks, >>> Alexander >>> >>> On 5/29/20 7:36 AM, Andy Herrick wrote: >>>> Please review jpackage fix at [1] to issue [2] >>>> >>>> /Andy >>>> >>>> [1] http://cr.openjdk.java.net/~herrick/8246010/webrev.01/ >>>> >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8246010 >>>> >>> > From alexander.matveev at oracle.com Fri May 29 23:39:06 2020 From: alexander.matveev at oracle.com (alexander.matveev at oracle.com) Date: Fri, 29 May 2020 16:39:06 -0700 Subject: RFR: 8232841: [TESTBUG] [macos] SigningPackageTest fails when untrusted certificates exist on machine Message-ID: <1d1ab383-61ff-c573-8846-80c801f977b2@oracle.com> Please review the jpackage fix for bug [1] at [2]. - I was not able to reproduce this issue. Not sure why this command returns non zero code in some cases. It still returns output which we need, so fixed by ignoring exit code, since we will scan output for presence of certificate anyway. [1] https://bugs.openjdk.java.net/browse/JDK-8232841 [2] http://cr.openjdk.java.net/~almatvee/8232841/webrev.00/ Thanks, Alexander From brian.burkhalter at oracle.com Sat May 30 02:01:22 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 29 May 2020 19:01:22 -0700 Subject: 8246183: Scanner/ScanTest.java fails due to SIGSEGV in StubRoutines::jshort_disjoint_arraycopy Message-ID: <0698ACC3-AD70-44EB-B513-987314528A0B@oracle.com> Please review this fix [1] for [2]. It in effect just backs out the recent fix for [3]. I?ll investigate the root cause next week. Thanks, Brian [1] http://cr.openjdk.java.net/~bpb/8246183/webrev.00/ [2] https://bugs.openjdk.java.net/browse/JDK-8246183 [3] https://bugs.openjdk.java.net/browse/JDK-8245121 From mikael.vidstedt at oracle.com Sat May 30 02:04:27 2020 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 29 May 2020 19:04:27 -0700 Subject: 8246183: Scanner/ScanTest.java fails due to SIGSEGV in StubRoutines::jshort_disjoint_arraycopy In-Reply-To: <0698ACC3-AD70-44EB-B513-987314528A0B@oracle.com> References: <0698ACC3-AD70-44EB-B513-987314528A0B@oracle.com> Message-ID: Looks good, thanks for fixing! Cheers, Mikael > On May 29, 2020, at 7:01 PM, Brian Burkhalter wrote: > > ?Please review this fix [1] for [2]. It in effect just backs out the recent fix for [3]. I?ll investigate the root cause next week. > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/8246183/webrev.00/ > [2] https://bugs.openjdk.java.net/browse/JDK-8246183 > [3] https://bugs.openjdk.java.net/browse/JDK-8245121 From stuart.marks at oracle.com Sat May 30 02:10:57 2020 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 29 May 2020 19:10:57 -0700 Subject: 8246183: Scanner/ScanTest.java fails due to SIGSEGV in StubRoutines::jshort_disjoint_arraycopy In-Reply-To: <0698ACC3-AD70-44EB-B513-987314528A0B@oracle.com> References: <0698ACC3-AD70-44EB-B513-987314528A0B@oracle.com> Message-ID: OK, looks good. Thanks for jumping on this quickly. s'marks On 5/29/20 7:01 PM, Brian Burkhalter wrote: > Please review this fix [1] for [2]. It in effect just backs out the recent fix for [3]. I?ll investigate the root cause next week. > > Thanks, > > Brian > > [1] http://cr.openjdk.java.net/~bpb/8246183/webrev.00/ > [2] https://bugs.openjdk.java.net/browse/JDK-8246183 > [3] https://bugs.openjdk.java.net/browse/JDK-8245121 > From brian.burkhalter at oracle.com Sat May 30 02:12:41 2020 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 29 May 2020 19:12:41 -0700 Subject: 8246183: Scanner/ScanTest.java fails due to SIGSEGV in StubRoutines::jshort_disjoint_arraycopy In-Reply-To: References: <0698ACC3-AD70-44EB-B513-987314528A0B@oracle.com> Message-ID: Thanks. Pushed. Brian > On May 29, 2020, at 7:10 PM, Stuart Marks wrote: > > OK, looks good. Thanks for jumping on this quickly. > > s'marks > > On 5/29/20 7:01 PM, Brian Burkhalter wrote: >> Please review this fix [1] for [2]. It in effect just backs out the recent fix for [3]. I?ll investigate the root cause next week. >> Thanks, >> Brian >> [1] http://cr.openjdk.java.net/~bpb/8246183/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8246183 >> [3] https://bugs.openjdk.java.net/browse/JDK-8245121 From james.laskey at oracle.com Sat May 30 02:17:39 2020 From: james.laskey at oracle.com (James Laskey) Date: Fri, 29 May 2020 23:17:39 -0300 Subject: 8246183: Scanner/ScanTest.java fails due to SIGSEGV in StubRoutines::jshort_disjoint_arraycopy In-Reply-To: References: Message-ID: <4ECB789E-EBB1-4F2A-9734-21401C06BDCF@oracle.com> You may not have intended this comment. s/offset/scale/ 49 50 // Cached array base offset 51 private static final long ARRAY_INDEX_SCALE = UNSAFE.arrayIndexScale($type$[].class); ?? > On May 29, 2020, at 11:05 PM, Mikael Vidstedt wrote: > > ? > Looks good, thanks for fixing! > > Cheers, > Mikael > >> On May 29, 2020, at 7:01 PM, Brian Burkhalter wrote: >> >> ?Please review this fix [1] for [2]. It in effect just backs out the recent fix for [3]. I?ll investigate the root cause next week. >> >> Thanks, >> >> Brian >> >> [1] http://cr.openjdk.java.net/~bpb/8246183/webrev.00/ >> [2] https://bugs.openjdk.java.net/browse/JDK-8246183 >> [3] https://bugs.openjdk.java.net/browse/JDK-8245121 > From james.laskey at oracle.com Sat May 30 02:20:58 2020 From: james.laskey at oracle.com (James Laskey) Date: Fri, 29 May 2020 23:20:58 -0300 Subject: 8246183: Scanner/ScanTest.java fails due to SIGSEGV in StubRoutines::jshort_disjoint_arraycopy In-Reply-To: <4ECB789E-EBB1-4F2A-9734-21401C06BDCF@oracle.com> References: <4ECB789E-EBB1-4F2A-9734-21401C06BDCF@oracle.com> Message-ID: Missed that it was a backout. ?? > On May 29, 2020, at 11:18 PM, James Laskey wrote: > > ?You may not have intended this comment. s/offset/scale/ > 49 > 50 // Cached array base offset > 51 private static final long ARRAY_INDEX_SCALE = UNSAFE.arrayIndexScale($type$[].class); > > > ?? > >> On May 29, 2020, at 11:05 PM, Mikael Vidstedt wrote: >> >> ? >> Looks good, thanks for fixing! >> >> Cheers, >> Mikael >> >>>> On May 29, 2020, at 7:01 PM, Brian Burkhalter wrote: >>> >>> ?Please review this fix [1] for [2]. It in effect just backs out the recent fix for [3]. I?ll investigate the root cause next week. >>> >>> Thanks, >>> >>> Brian >>> >>> [1] http://cr.openjdk.java.net/~bpb/8246183/webrev.00/ >>> [2] https://bugs.openjdk.java.net/browse/JDK-8246183 >>> [3] https://bugs.openjdk.java.net/browse/JDK-8245121 >> From hongsy2006 at gmail.com Sat May 30 02:24:33 2020 From: hongsy2006 at gmail.com (Hong Shao Yang) Date: Sat, 30 May 2020 10:24:33 +0800 Subject: [PATCH] Typo in java.util.regex.Pattern Message-ID: Hi! I found a typo which has been long undetected in the documentation. In case you think this is worthwhile, I would appreciate it if someone can sponsor this patch. Cheers, Shao Yang ========= PATCH ========== diff --git a/src/java.base/share/classes/java/util/regex/Pattern.java b/src/java.base/share/classes/java/util/regex/Pattern.java index 0d7d0738965..82325d04f25 100644 --- a/src/java.base/share/classes/java/util/regex/Pattern.java +++ b/src/java.base/share/classes/java/util/regex/Pattern.java @@ -760,7 +760,7 @@ import jdk.internal.util.ArraysSupport; * *

    For a more precise description of the behavior of regular expression * constructs, please see - * Mastering Regular Expressions, 3nd Edition, Jeffrey E. F. Friedl, + * Mastering Regular Expressions, 3rd Edition, Jeffrey E. F. Friedl, * O'Reilly and Associates, 2006. *

    * From Lance.Andersen at oracle.com Sat May 30 11:02:09 2020 From: Lance.Andersen at oracle.com (Lance Andersen) Date: Sat, 30 May 2020 07:02:09 -0400 Subject: [PATCH] Typo in java.util.regex.Pattern In-Reply-To: References: Message-ID: <0714E2ED-0229-4C11-BF8B-A1C702474376@oracle.com> I can sponsor this for you Best Lance -- Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com Sent from my iPhone > On May 29, 2020, at 10:25 PM, Hong Shao Yang wrote: > > ?Hi! > > I found a typo which has been long undetected in the documentation. > > In case you think this is worthwhile, I would appreciate it if someone > can sponsor this patch. > > Cheers, > Shao Yang > > ========= PATCH ========== > > diff --git a/src/java.base/share/classes/java/util/regex/Pattern.java > b/src/java.base/share/classes/java/util/regex/Pattern.java > index 0d7d0738965..82325d04f25 100644 > --- a/src/java.base/share/classes/java/util/regex/Pattern.java > +++ b/src/java.base/share/classes/java/util/regex/Pattern.java > @@ -760,7 +760,7 @@ import jdk.internal.util.ArraysSupport; > * > *

    For a more precise description of the behavior of regular expression > * constructs, please see > - * Mastering Regular Expressions, 3nd Edition, Jeffrey E. F. Friedl, > + * Mastering Regular Expressions, 3rd Edition, Jeffrey E. F. Friedl, > * O'Reilly and Associates, 2006. > *

    > * From pavel.rappo at oracle.com Sat May 30 11:08:09 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Sat, 30 May 2020 12:08:09 +0100 Subject: [PATCH] Typo in java.util.regex.Pattern In-Reply-To: References: Message-ID: <8C7B6227-20BB-4753-9680-6C453199A499@oracle.com> Looks good. I can see that Lance has offered to sponsor that for you. (I was writing this message when I saw his reply.) I researched history a bit. That happened as one might guess quite trivially in November 2006: 2c2 < * @(#)Pattern.java 1.124 06/11/09 --- > * @(#)Pattern.java 1.125 06/11/14 583,585c583,585 < * constructs, please see < * Mastering Regular Expressions, 2nd Edition, Jeffrey E. F. Friedl, < * O'Reilly and Associates, 2002. --- > * constructs, please see > * Mastering Regular Expressions, 3nd Edition, Jeffrey E. F. Friedl, > * O'Reilly and Associates, 2006. 594c594 < * @version 1.124, 06/11/09 --- > * @version 1.125, 06/11/14 -Pavel > On 30 May 2020, at 03:24, Hong Shao Yang wrote: > > Hi! > > I found a typo which has been long undetected in the documentation. > > In case you think this is worthwhile, I would appreciate it if someone > can sponsor this patch. > > Cheers, > Shao Yang > > ========= PATCH ========== > > diff --git a/src/java.base/share/classes/java/util/regex/Pattern.java > b/src/java.base/share/classes/java/util/regex/Pattern.java > index 0d7d0738965..82325d04f25 100644 > --- a/src/java.base/share/classes/java/util/regex/Pattern.java > +++ b/src/java.base/share/classes/java/util/regex/Pattern.java > @@ -760,7 +760,7 @@ import jdk.internal.util.ArraysSupport; > * > *

    For a more precise description of the behavior of regular expression > * constructs, please see > - * Mastering Regular Expressions, 3nd Edition, Jeffrey E. F. Friedl, > + * Mastering Regular Expressions, 3rd Edition, Jeffrey E. F. Friedl, > * O'Reilly and Associates, 2006. > *

    > * From david.holmes at oracle.com Sat May 30 13:30:14 2020 From: david.holmes at oracle.com (David Holmes) Date: Sat, 30 May 2020 23:30:14 +1000 Subject: RFR: JDK-8245432: Lookup::defineHiddenClass should throw UnsupportedClassVersionError if the given bytes are of an unsupported major or minor version In-Reply-To: <7c910287-fb2d-766e-8dd4-bc3e66edb9a9@oracle.com> References: <176af0b0-cce9-9286-0b06-9455c0f8cea4@oracle.com> <50b420bf-a53e-06d1-43f3-d5bdac804e7d@oracle.com> <700459437.2144177.1590601182749.JavaMail.zimbra@u-pem.fr> <543b4fc8-dcbb-b8c8-4111-f200885921cd@oracle.com> <46328704-3f68-9643-71b7-d7cdc7088af3@oracle.com> <2f2218dd-de42-bfd4-974a-76ef3d840882@oracle.com> <8f53afb4-d11d-ae62-756f-8093726e098d@oracle.com> <7f82b76b-d9ed-2ccd-5fd1-8a5e68cb0a52@oracle.com> <2eda234f-045d-1145-40ae-cf2b0b7cd5c5@oracle.com> <7c910287-fb2d-766e-8dd4-bc3e66edb9a9@oracle.com> Message-ID: On 30/05/2020 6:03 am, Mandy Chung wrote: > > > On 5/28/20 9:18 PM, David Holmes wrote: >> On 29/05/2020 1:52 pm, Mandy Chung wrote: >>> On 5/28/20 5:44 PM, David Holmes wrote: >>>>> >>>>> This is to validate the given version.? The runtime will check if >>>>> preview feature is enabled when such class file is loaded. I will >>>>> make a comment to make it clear. >>>> >>>> Okay but I thought the intent here was to pre-validate the version >>>> information so that when these bytes get passed to ASM you don't >>>> have to worry about the IAE that will be thrown by ASM if there is >>>> actually a problem. >>> >>> Yes it is.? ASM does not check if preview features are enabled or not >>> neither.? When a class file depending preview features is passed to >>> VM, the VM will throw an exception if preview features are not enabled. >> >> Yes but will that VM exception propagate as-is, or will ASM catch it >> and turn it into IAE? If the latter then your original problem still >> exists. >> > > I think you may be confused with the code path.? ASM is used only to > extract the class name from the bytes.? Once it verifies the class file > version and name in the bytes, the next step is to pass the name and > bytes to the VM to create the class where it checks if preview features > are used and enabled.? If VM will throw an exception, it just gets > propagated to the user (no ASM frame on the stack at that point).? See > the new PreviewHiddenClass test. I see. That wasn't clear to me. I thought ASM was doing something that would trigger the VM checks. Thanks, David ----- > Updated webrev: > http://cr.openjdk.java.net/~mchung/jdk15/webrevs/8245432/webrev.02/index.html > > This patch has a behavioral change to `Lookup::defineClass` if the bytes > is not a class or interface. > > Lookup::defineClass does not specify what exception to throw if the > given bytes has ACC_MODULE flag set in the access_flags item. The > current implementation throws NoClassDefFoundError (which is the > behavior specified in JVMS 5.3.5). > > I propose Lookup::defineClass to specify and throw > IllegalArgumentException if the bytes has ACC_MODULE flag set in its > access_flags item to be consistent with Lookup::defineHiddenClass. > > CSR: https://bugs.openjdk.java.net/browse/JDK-8246108 > > Mandy > From james.laskey at oracle.com Sat May 30 14:29:58 2020 From: james.laskey at oracle.com (Jim Laskey) Date: Sat, 30 May 2020 11:29:58 -0300 Subject: Sometimes constraints are questionable Message-ID: <4A5AC9D1-AEB7-47E3-9E25-BF74FE01F3B0@oracle.com> I'm working through https://bugs.openjdk.java.net/browse/JDK-8230744 Several classes throw OutOfMemoryError without message . I'm wondering why hugeCapacity in src/jdk.zipfs/share/classes/jdk/nio/zipfs/ByteArrayChannel.java is defined as /** * The maximum size of array to allocate. * Some VMs reserve some header words in an array. * Attempts to allocate larger arrays may result in * OutOfMemoryError: Requested array size exceeds VM limit */ private static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8; /** * Increases the capacity to ensure that it can hold at least the * number of elements specified by the minimum capacity argument. * * @param minCapacity the desired minimum capacity */ private void grow(int minCapacity) { // overflow-conscious code int oldCapacity = buf.length; int newCapacity = oldCapacity << 1; if (newCapacity - minCapacity < 0) newCapacity = minCapacity; if (newCapacity - MAX_ARRAY_SIZE > 0) newCapacity = hugeCapacity(minCapacity); buf = Arrays.copyOf(buf, newCapacity); } private static int hugeCapacity(int minCapacity) { if (minCapacity < 0) // overflow throw new OutOfMemoryError(); return (minCapacity > MAX_ARRAY_SIZE) ? Integer.MAX_VALUE : MAX_ARRAY_SIZE; } It just seems that it's pushing the inevitable off to Arrays.copyOf. Shouldn't it be: private static int hugeCapacity(int minCapacity) { if (minCapacity < 0 || minCapacity > MAX_ARRAY_SIZE) { throw new OutOfMemoryError("ByteArrayChannel exceeds maximum size: " + MAX_ARRAY_SIZE); } return MAX_ARRAY_SIZE; } Real question: is there some hidden purpose behind this kind of logic? Cheers, -- Jim From martinrb at google.com Sat May 30 15:30:02 2020 From: martinrb at google.com (Martin Buchholz) Date: Sat, 30 May 2020 08:30:02 -0700 Subject: Sometimes constraints are questionable In-Reply-To: <4A5AC9D1-AEB7-47E3-9E25-BF74FE01F3B0@oracle.com> References: <4A5AC9D1-AEB7-47E3-9E25-BF74FE01F3B0@oracle.com> Message-ID: I wrote an earlier version of this grow logic, and then it was transplanted into other classes. We strongly suspect that the VM will throw OOME when we try to allocate an array beyond MAX_ARRAY_SIZE, so are reluctant to do so, but we also consider the VM behavior a bug that may eventually get fixed (or is already a non-issue with a different VM). We are trying for good behavior with both sorts of VM. On Sat, May 30, 2020 at 7:32 AM Jim Laskey wrote: > > I'm working through https://bugs.openjdk.java.net/browse/JDK-8230744 Several classes throw OutOfMemoryError without message . > > I'm wondering why hugeCapacity in src/jdk.zipfs/share/classes/jdk/nio/zipfs/ByteArrayChannel.java is defined as > > /** > * The maximum size of array to allocate. > * Some VMs reserve some header words in an array. > * Attempts to allocate larger arrays may result in > * OutOfMemoryError: Requested array size exceeds VM limit > */ > private static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8; > > /** > * Increases the capacity to ensure that it can hold at least the > * number of elements specified by the minimum capacity argument. > * > * @param minCapacity the desired minimum capacity > */ > private void grow(int minCapacity) { > // overflow-conscious code > int oldCapacity = buf.length; > int newCapacity = oldCapacity << 1; > if (newCapacity - minCapacity < 0) > newCapacity = minCapacity; > if (newCapacity - MAX_ARRAY_SIZE > 0) > newCapacity = hugeCapacity(minCapacity); > buf = Arrays.copyOf(buf, newCapacity); > } > > private static int hugeCapacity(int minCapacity) { > if (minCapacity < 0) // overflow > throw new OutOfMemoryError(); > return (minCapacity > MAX_ARRAY_SIZE) ? > Integer.MAX_VALUE : > MAX_ARRAY_SIZE; > } > > It just seems that it's pushing the inevitable off to Arrays.copyOf. Shouldn't it be: > > private static int hugeCapacity(int minCapacity) { > if (minCapacity < 0 || minCapacity > MAX_ARRAY_SIZE) { > throw > new OutOfMemoryError("ByteArrayChannel exceeds maximum size: " + > MAX_ARRAY_SIZE); > } > > return MAX_ARRAY_SIZE; > } > > Real question: is there some hidden purpose behind this kind of logic? > > > Cheers, > > -- Jim > > From james.laskey at oracle.com Sat May 30 16:51:04 2020 From: james.laskey at oracle.com (James Laskey) Date: Sat, 30 May 2020 13:51:04 -0300 Subject: Sometimes constraints are questionable In-Reply-To: References: Message-ID: <73D74164-4E0B-47FA-8081-4EC676AAB9F2@oracle.com> Understood. Just trying to balance correctness with providing meaningful exceptions. I suppose another approach is to let it all go deep and catch the error on the way back and provide the detail then. Not likely win any fans. ?? > On May 30, 2020, at 12:30 PM, Martin Buchholz wrote: > > ?I wrote an earlier version of this grow logic, and then it was > transplanted into other classes. > > We strongly suspect that the VM will throw OOME when we try to > allocate an array beyond MAX_ARRAY_SIZE, so are reluctant to do so, > but we also consider the VM behavior a bug that may eventually get > fixed (or is already a non-issue with a different VM). We are trying > for good behavior with both sorts of VM. > >> On Sat, May 30, 2020 at 7:32 AM Jim Laskey wrote: >> >> I'm working through https://bugs.openjdk.java.net/browse/JDK-8230744 Several classes throw OutOfMemoryError without message . >> >> I'm wondering why hugeCapacity in src/jdk.zipfs/share/classes/jdk/nio/zipfs/ByteArrayChannel.java is defined as >> >> /** >> * The maximum size of array to allocate. >> * Some VMs reserve some header words in an array. >> * Attempts to allocate larger arrays may result in >> * OutOfMemoryError: Requested array size exceeds VM limit >> */ >> private static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8; >> >> /** >> * Increases the capacity to ensure that it can hold at least the >> * number of elements specified by the minimum capacity argument. >> * >> * @param minCapacity the desired minimum capacity >> */ >> private void grow(int minCapacity) { >> // overflow-conscious code >> int oldCapacity = buf.length; >> int newCapacity = oldCapacity << 1; >> if (newCapacity - minCapacity < 0) >> newCapacity = minCapacity; >> if (newCapacity - MAX_ARRAY_SIZE > 0) >> newCapacity = hugeCapacity(minCapacity); >> buf = Arrays.copyOf(buf, newCapacity); >> } >> >> private static int hugeCapacity(int minCapacity) { >> if (minCapacity < 0) // overflow >> throw new OutOfMemoryError(); >> return (minCapacity > MAX_ARRAY_SIZE) ? >> Integer.MAX_VALUE : >> MAX_ARRAY_SIZE; >> } >> >> It just seems that it's pushing the inevitable off to Arrays.copyOf. Shouldn't it be: >> >> private static int hugeCapacity(int minCapacity) { >> if (minCapacity < 0 || minCapacity > MAX_ARRAY_SIZE) { >> throw >> new OutOfMemoryError("ByteArrayChannel exceeds maximum size: " + >> MAX_ARRAY_SIZE); >> } >> >> return MAX_ARRAY_SIZE; >> } >> >> Real question: is there some hidden purpose behind this kind of logic? >> >> >> Cheers, >> >> -- Jim >> >> From martinrb at google.com Sat May 30 17:08:28 2020 From: martinrb at google.com (Martin Buchholz) Date: Sat, 30 May 2020 10:08:28 -0700 Subject: Sometimes constraints are questionable In-Reply-To: <73D74164-4E0B-47FA-8081-4EC676AAB9F2@oracle.com> References: <73D74164-4E0B-47FA-8081-4EC676AAB9F2@oracle.com> Message-ID: On Sat, May 30, 2020 at 9:53 AM James Laskey wrote: > Understood. Just trying to balance correctness with providing meaningful > exceptions. > The VM should be providing meaningful exceptions. We might get OOME for any int array size. For attempts to allocate more than Integer.MAX_VALUE elements, there is no way the grow code can do that, so throwing then seems reasonable. Generic grow code can't know why it was asked to allocate an impossibly large amount; reworking the grow handling might be good, but few will appreciate the effort. (testing is a particular challenge) > > I suppose another approach is to let it all go deep and catch the error on > the way back and provide the detail then. Not likely win any fans. > > ?? > > > On May 30, 2020, at 12:30 PM, Martin Buchholz > wrote: > > > > ?I wrote an earlier version of this grow logic, and then it was > > transplanted into other classes. > > > > We strongly suspect that the VM will throw OOME when we try to > > allocate an array beyond MAX_ARRAY_SIZE, so are reluctant to do so, > > but we also consider the VM behavior a bug that may eventually get > > fixed (or is already a non-issue with a different VM). We are trying > > for good behavior with both sorts of VM. > > > >> On Sat, May 30, 2020 at 7:32 AM Jim Laskey > wrote: > >> > >> I'm working through https://bugs.openjdk.java.net/browse/JDK-8230744 < > https://bugs.openjdk.java.net/browse/JDK-8230744> Several classes throw > OutOfMemoryError without message . > >> > >> I'm wondering why hugeCapacity in > src/jdk.zipfs/share/classes/jdk/nio/zipfs/ByteArrayChannel.java is defined > as > >> > >> /** > >> * The maximum size of array to allocate. > >> * Some VMs reserve some header words in an array. > >> * Attempts to allocate larger arrays may result in > >> * OutOfMemoryError: Requested array size exceeds VM limit > >> */ > >> private static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8; > >> > >> /** > >> * Increases the capacity to ensure that it can hold at least the > >> * number of elements specified by the minimum capacity argument. > >> * > >> * @param minCapacity the desired minimum capacity > >> */ > >> private void grow(int minCapacity) { > >> // overflow-conscious code > >> int oldCapacity = buf.length; > >> int newCapacity = oldCapacity << 1; > >> if (newCapacity - minCapacity < 0) > >> newCapacity = minCapacity; > >> if (newCapacity - MAX_ARRAY_SIZE > 0) > >> newCapacity = hugeCapacity(minCapacity); > >> buf = Arrays.copyOf(buf, newCapacity); > >> } > >> > >> private static int hugeCapacity(int minCapacity) { > >> if (minCapacity < 0) // overflow > >> throw new OutOfMemoryError(); > >> return (minCapacity > MAX_ARRAY_SIZE) ? > >> Integer.MAX_VALUE : > >> MAX_ARRAY_SIZE; > >> } > >> > >> It just seems that it's pushing the inevitable off to Arrays.copyOf. > Shouldn't it be: > >> > >> private static int hugeCapacity(int minCapacity) { > >> if (minCapacity < 0 || minCapacity > MAX_ARRAY_SIZE) { > >> throw > >> new OutOfMemoryError("ByteArrayChannel exceeds maximum > size: " + > >> MAX_ARRAY_SIZE); > >> } > >> > >> return MAX_ARRAY_SIZE; > >> } > >> > >> Real question: is there some hidden purpose behind this kind of logic? > >> > >> > >> Cheers, > >> > >> -- Jim > >> > >> > > From Roger.Riggs at oracle.com Sat May 30 17:50:15 2020 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Sat, 30 May 2020 13:50:15 -0400 Subject: Sometimes constraints are questionable In-Reply-To: <73D74164-4E0B-47FA-8081-4EC676AAB9F2@oracle.com> References: <73D74164-4E0B-47FA-8081-4EC676AAB9F2@oracle.com> Message-ID: <0850e82b-e21f-492f-ea10-00bb760717bc@oracle.com> Hi Jim, This kind of code exists in other places too, trying to balance preferred grow sizes with necessary ones and implementation limits.? The rationale and design has been raised several times.? That last time it resulting in consolidating similar code into jdk.internalutil.ArraysUppport.newLength(). If you have any reason to touch that code at all you can probably replace all that code with a call to newLength(). Regards, Roger On 5/30/20 12:51 PM, James Laskey wrote: > Understood. Just trying to balance correctness with providing meaningful exceptions. > > I suppose another approach is to let it all go deep and catch the error on the way back and provide the detail then. Not likely win any fans. > > ?? > >> On May 30, 2020, at 12:30 PM, Martin Buchholz wrote: >> >> ?I wrote an earlier version of this grow logic, and then it was >> transplanted into other classes. >> >> We strongly suspect that the VM will throw OOME when we try to >> allocate an array beyond MAX_ARRAY_SIZE, so are reluctant to do so, >> but we also consider the VM behavior a bug that may eventually get >> fixed (or is already a non-issue with a different VM). We are trying >> for good behavior with both sorts of VM. >> >>> On Sat, May 30, 2020 at 7:32 AM Jim Laskey wrote: >>> >>> I'm working through https://bugs.openjdk.java.net/browse/JDK-8230744 Several classes throw OutOfMemoryError without message . >>> >>> I'm wondering why hugeCapacity in src/jdk.zipfs/share/classes/jdk/nio/zipfs/ByteArrayChannel.java is defined as >>> >>> /** >>> * The maximum size of array to allocate. >>> * Some VMs reserve some header words in an array. >>> * Attempts to allocate larger arrays may result in >>> * OutOfMemoryError: Requested array size exceeds VM limit >>> */ >>> private static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8; >>> >>> /** >>> * Increases the capacity to ensure that it can hold at least the >>> * number of elements specified by the minimum capacity argument. >>> * >>> * @param minCapacity the desired minimum capacity >>> */ >>> private void grow(int minCapacity) { >>> // overflow-conscious code >>> int oldCapacity = buf.length; >>> int newCapacity = oldCapacity << 1; >>> if (newCapacity - minCapacity < 0) >>> newCapacity = minCapacity; >>> if (newCapacity - MAX_ARRAY_SIZE > 0) >>> newCapacity = hugeCapacity(minCapacity); >>> buf = Arrays.copyOf(buf, newCapacity); >>> } >>> >>> private static int hugeCapacity(int minCapacity) { >>> if (minCapacity < 0) // overflow >>> throw new OutOfMemoryError(); >>> return (minCapacity > MAX_ARRAY_SIZE) ? >>> Integer.MAX_VALUE : >>> MAX_ARRAY_SIZE; >>> } >>> >>> It just seems that it's pushing the inevitable off to Arrays.copyOf. Shouldn't it be: >>> >>> private static int hugeCapacity(int minCapacity) { >>> if (minCapacity < 0 || minCapacity > MAX_ARRAY_SIZE) { >>> throw >>> new OutOfMemoryError("ByteArrayChannel exceeds maximum size: " + >>> MAX_ARRAY_SIZE); >>> } >>> >>> return MAX_ARRAY_SIZE; >>> } >>> >>> Real question: is there some hidden purpose behind this kind of logic? >>> >>> >>> Cheers, >>> >>> -- Jim >>> >>> From fw at deneb.enyo.de Sat May 30 18:11:10 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 30 May 2020 20:11:10 +0200 Subject: Sometimes constraints are questionable In-Reply-To: (Martin Buchholz's message of "Sat, 30 May 2020 08:30:02 -0700") References: <4A5AC9D1-AEB7-47E3-9E25-BF74FE01F3B0@oracle.com> Message-ID: <87ftbh5m4h.fsf@mid.deneb.enyo.de> * Martin Buchholz: > I wrote an earlier version of this grow logic, and then it was > transplanted into other classes. > > We strongly suspect that the VM will throw OOME when we try to > allocate an array beyond MAX_ARRAY_SIZE, so are reluctant to do so, > but we also consider the VM behavior a bug that may eventually get > fixed (or is already a non-issue with a different VM). We are trying > for good behavior with both sorts of VM. I still don't think this explains the present code. However, I wouldn't be surprised if there have been early bugs where the VM would produce a corrupt array instead of failing the allocation. But these bugs will have been fixed by now. C++ has a subclass of std::bad_alloc for certain allocations that exceed implementation limits (std::bad_array_new_length). Since memory is rarely tight when this happens, it allows providing better diagnostics. From naoto.sato at oracle.com Sat May 30 18:13:32 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Sat, 30 May 2020 11:13:32 -0700 Subject: [PATCH] Typo in java.util.regex.Pattern In-Reply-To: <0714E2ED-0229-4C11-BF8B-A1C702474376@oracle.com> References: <0714E2ED-0229-4C11-BF8B-A1C702474376@oracle.com> Message-ID: <6d649f2d-a3ab-8980-bc60-497819fb4f28@oracle.com> Just noticed that the release year of the 3rd ed. should also be changed to 2009 in the next line. Naoto On 5/30/20 4:02 AM, Lance Andersen wrote: > I can sponsor this for you > > Best > Lance > > -- > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > Sent from my iPhone > >> On May 29, 2020, at 10:25 PM, Hong Shao Yang wrote: >> >> ?Hi! >> >> I found a typo which has been long undetected in the documentation. >> >> In case you think this is worthwhile, I would appreciate it if someone >> can sponsor this patch. >> >> Cheers, >> Shao Yang >> >> ========= PATCH ========== >> >> diff --git a/src/java.base/share/classes/java/util/regex/Pattern.java >> b/src/java.base/share/classes/java/util/regex/Pattern.java >> index 0d7d0738965..82325d04f25 100644 >> --- a/src/java.base/share/classes/java/util/regex/Pattern.java >> +++ b/src/java.base/share/classes/java/util/regex/Pattern.java >> @@ -760,7 +760,7 @@ import jdk.internal.util.ArraysSupport; >> * >> *

    For a more precise description of the behavior of regular expression >> * constructs, please see >> - * Mastering Regular Expressions, 3nd Edition, Jeffrey E. F. Friedl, >> + * Mastering Regular Expressions, 3rd Edition, Jeffrey E. F. Friedl, >> * O'Reilly and Associates, 2006. >> *

    >> * From lance.andersen at oracle.com Sat May 30 18:30:59 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Sat, 30 May 2020 14:30:59 -0400 Subject: [PATCH] Typo in java.util.regex.Pattern In-Reply-To: <6d649f2d-a3ab-8980-bc60-497819fb4f28@oracle.com> References: <0714E2ED-0229-4C11-BF8B-A1C702474376@oracle.com> <6d649f2d-a3ab-8980-bc60-497819fb4f28@oracle.com> Message-ID: <7C8C8AED-D33B-4C65-8297-9F22580410A5@oracle.com> Thank you Naoto, I am building now with both changes and will send a final diff out later along with the bug number! Best Lance > On May 30, 2020, at 2:13 PM, naoto.sato at oracle.com wrote: > > Just noticed that the release year of the 3rd ed. should also be changed to 2009 in the next line. > > Naoto > > On 5/30/20 4:02 AM, Lance Andersen wrote: >> I can sponsor this for you >> Best >> Lance >> -- >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> Sent from my iPhone >>> On May 29, 2020, at 10:25 PM, Hong Shao Yang wrote: >>> >>> ?Hi! >>> >>> I found a typo which has been long undetected in the documentation. >>> >>> In case you think this is worthwhile, I would appreciate it if someone >>> can sponsor this patch. >>> >>> Cheers, >>> Shao Yang >>> >>> ========= PATCH ========== >>> >>> diff --git a/src/java.base/share/classes/java/util/regex/Pattern.java >>> b/src/java.base/share/classes/java/util/regex/Pattern.java >>> index 0d7d0738965..82325d04f25 100644 >>> --- a/src/java.base/share/classes/java/util/regex/Pattern.java >>> +++ b/src/java.base/share/classes/java/util/regex/Pattern.java >>> @@ -760,7 +760,7 @@ import jdk.internal.util.ArraysSupport; >>> * >>> *

    For a more precise description of the behavior of regular expression >>> * constructs, please see >>> - * Mastering Regular Expressions, 3nd Edition, Jeffrey E. F. Friedl, >>> + * Mastering Regular Expressions, 3rd Edition, Jeffrey E. F. Friedl, >>> * O'Reilly and Associates, 2006. >>> *

    >>> * Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From liyu.italy at gmail.com Sat May 30 18:31:16 2020 From: liyu.italy at gmail.com (Lisa Li) Date: Sun, 31 May 2020 02:31:16 +0800 Subject: [PATCH] 8245694 : java.util.Properties.entrySet() does not override java.lang.Object methods Message-ID: Hi, Please help review the fix for JDK-8245694 . And this is my very first patch submission. I know it's not perfect. *BUG DESCRIPTION*: JDK-8245694 : java.util.Properties.entrySet() does not override java.lang.Object methods since java 9. *PROPOSED FIX*: Add delegating overrides for equals(), hashCode(), and toString(). *PATCH*: # HG changeset patch # User yuli # Date 1590841711 -28800 # Sat May 30 20:28:31 2020 +0800 # Node ID 7dc946e5b5863291fa070bfdbdce48aefbe87b7b # Parent 8e28aae5068069e853673148e4d3f44cb50350a7 8245694: java.util.Properties.entrySet() does not override Object methods Summary: Add missing override methods Contributed-by: Yu Li diff --git a/src/java.base/share/classes/java/util/Properties.java b/src/java.base/share/classes/java/util/Properties.java --- a/src/java.base/share/classes/java/util/Properties.java +++ b/src/java.base/share/classes/java/util/Properties.java @@ -1414,6 +1414,21 @@ return entrySet.retainAll(c); } + @Override + public boolean equals(Object o) { + return entrySet.equals(o); + } + + @Override + public int hashCode() { + return entrySet.hashCode(); + } + + @Override + public String toString() { + return entrySet.toString(); + } + @Override public Iterator> iterator() { return entrySet.iterator(); diff --git a/test/jdk/java/util/Properties/PropertiesEntrySetTest.java b/test/jdk/java/util/Properties/PropertiesEntrySetTest.java new file mode 100644 --- /dev/null +++ b/test/jdk/java/util/Properties/PropertiesEntrySetTest.java @@ -0,0 +1,90 @@ +/* + * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @summary tests the entrySet() method of Properties class + * @author Yu Li + * @bug 8245694 + */ + +import java.util.Map; +import java.util.Properties; +import java.util.Set; + +public class PropertiesEntrySetTest { + + public static void main(String[] args) { + + testEntrySet(); + + } + + private static void assertTrue(boolean value) { + if (!value) { + throw new RuntimeException("Failure in Properties testing."); + } + } + + private static void assertFalse(boolean value) { + if (value) { + throw new RuntimeException("Failure in Properties testing."); + } + } + + private static void testEntrySet() { + Properties a = new Properties(); + Set> aEntrySet = a.entrySet(); + assertFalse(aEntrySet.equals(null)); + assertTrue(aEntrySet.equals(aEntrySet)); + + Properties b = new Properties(); + Set> bEntrySet = b.entrySet(); + assertTrue(aEntrySet.equals(bEntrySet)); + assertTrue(aEntrySet.hashCode() == bEntrySet.hashCode()); + + a.setProperty("p1", "1"); + assertFalse(aEntrySet.equals(bEntrySet)); + assertFalse(bEntrySet.equals(aEntrySet)); + assertFalse(aEntrySet.hashCode() == bEntrySet.hashCode()); + + b.setProperty("p1", "1"); + assertTrue(aEntrySet.equals(bEntrySet)); + assertTrue(aEntrySet.hashCode() == bEntrySet.hashCode()); + + Properties c = new Properties(); + c.setProperty("p1", "2"); + Set> cEntrySet = c.entrySet(); + assertFalse(cEntrySet.equals(bEntrySet)); + assertFalse(cEntrySet.hashCode() == bEntrySet.hashCode()); + assertFalse(cEntrySet.equals(aEntrySet)); + assertFalse(cEntrySet.hashCode() == aEntrySet.hashCode()); + + a.setProperty("p2", "2"); + Properties d = new Properties(); + d.setProperty("p2", "2"); + d.setProperty("p1", "1"); + Set> dEntrySet = d.entrySet(); + assertTrue(dEntrySet.equals(aEntrySet)); + } +} Best regards, Yu Li From lance.andersen at oracle.com Sat May 30 19:08:44 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Sat, 30 May 2020 15:08:44 -0400 Subject: RFR: https://bugs.openjdk.java.net/browse/JDK-8246198 (formally: Re: [PATCH] Typo in java.util.regex.Pattern) In-Reply-To: <7C8C8AED-D33B-4C65-8297-9F22580410A5@oracle.com> References: <0714E2ED-0229-4C11-BF8B-A1C702474376@oracle.com> <6d649f2d-a3ab-8980-bc60-497819fb4f28@oracle.com> <7C8C8AED-D33B-4C65-8297-9F22580410A5@oracle.com> Message-ID: <5B6B4BB1-DBB8-4BBF-9A17-385133AD1B30@oracle.com> I create issue: https://bugs.openjdk.java.net/browse/JDK-8246198 for this typo Here is the updated diff ???????? $ hg diff src/java.base/share/classes/java/util/regex/Pattern.java diff -r 968b57610c0f src/java.base/share/classes/java/util/regex/Pattern.java --- a/src/java.base/share/classes/java/util/regex/Pattern.java Sat May 30 10:33:28 2020 +0530 +++ b/src/java.base/share/classes/java/util/regex/Pattern.java Sat May 30 15:02:58 2020 -0400 @@ -760,8 +760,8 @@ * *

    For a more precise description of the behavior of regular expression * constructs, please see - * Mastering Regular Expressions, 3nd Edition, Jeffrey E. F. Friedl, - * O'Reilly and Associates, 2006. + * Mastering Regular Expressions, 3rd Edition, Jeffrey E. F. Friedl, + * O'Reilly and Associates, 2009. *

    * * @see java.lang.String#split(String, int) ljanders-mac:open ljanders$ ???????????? Best Lance > On May 30, 2020, at 2:30 PM, Lance Andersen wrote: > > Thank you Naoto, I am building now with both changes and will send a final diff out later along with the bug number! > > Best > Lance > >> On May 30, 2020, at 2:13 PM, naoto.sato at oracle.com wrote: >> >> Just noticed that the release year of the 3rd ed. should also be changed to 2009 in the next line. >> >> Naoto >> >> On 5/30/20 4:02 AM, Lance Andersen wrote: >>> I can sponsor this for you >>> Best >>> Lance >>> -- >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> Sent from my iPhone >>>> On May 29, 2020, at 10:25 PM, Hong Shao Yang wrote: >>>> >>>> ?Hi! >>>> >>>> I found a typo which has been long undetected in the documentation. >>>> >>>> In case you think this is worthwhile, I would appreciate it if someone >>>> can sponsor this patch. >>>> >>>> Cheers, >>>> Shao Yang >>>> >>>> ========= PATCH ========== >>>> >>>> diff --git a/src/java.base/share/classes/java/util/regex/Pattern.java >>>> b/src/java.base/share/classes/java/util/regex/Pattern.java >>>> index 0d7d0738965..82325d04f25 100644 >>>> --- a/src/java.base/share/classes/java/util/regex/Pattern.java >>>> +++ b/src/java.base/share/classes/java/util/regex/Pattern.java >>>> @@ -760,7 +760,7 @@ import jdk.internal.util.ArraysSupport; >>>> * >>>> *

    For a more precise description of the behavior of regular expression >>>> * constructs, please see >>>> - * Mastering Regular Expressions, 3nd Edition, Jeffrey E. F. Friedl, >>>> + * Mastering Regular Expressions, 3rd Edition, Jeffrey E. F. Friedl, >>>> * O'Reilly and Associates, 2006. >>>> *

    >>>> * > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From openjdk at icemanx.nl Sat May 30 20:00:41 2020 From: openjdk at icemanx.nl (Rob Spoor) Date: Sat, 30 May 2020 22:00:41 +0200 Subject: [PATCH] 8245694 : java.util.Properties.entrySet() does not override java.lang.Object methods In-Reply-To: References: Message-ID: <9487a1c9-d0bc-3632-156d-5927e5801dc8@icemanx.nl> There's still a little regression there since Java 8, if you add the keySet(), values() or entrySet() to the Properties object as either key or value; in Java 8 this would cause "(this Collection)" to be included, while even with this fix that would cause a StackOverflowError. However, given that it's only a corner case for most Collections and Maps in the first place, and with Properties objects even more so, I don't think anyone would mind this regression. Rob On 30/05/2020 20:31, Lisa Li wrote: > Hi, > > Please help review the fix for JDK-8245694 > . And this is my very > first patch submission. I know it's not perfect. > > > > *BUG DESCRIPTION*: > > JDK-8245694 : > java.util.Properties.entrySet() > does not override java.lang.Object methods since java 9. > > > *PROPOSED FIX*: > > Add delegating overrides for equals(), hashCode(), and toString(). > > > *PATCH*: > > # HG changeset patch > # User yuli > # Date 1590841711 -28800 > # Sat May 30 20:28:31 2020 +0800 > # Node ID 7dc946e5b5863291fa070bfdbdce48aefbe87b7b > # Parent 8e28aae5068069e853673148e4d3f44cb50350a7 > 8245694: java.util.Properties.entrySet() does not override Object methods > Summary: Add missing override methods > Contributed-by: Yu Li > > diff --git a/src/java.base/share/classes/java/util/Properties.java > b/src/java.base/share/classes/java/util/Properties.java > --- a/src/java.base/share/classes/java/util/Properties.java > +++ b/src/java.base/share/classes/java/util/Properties.java > @@ -1414,6 +1414,21 @@ > return entrySet.retainAll(c); > } > > + @Override > + public boolean equals(Object o) { > + return entrySet.equals(o); > + } > + > + @Override > + public int hashCode() { > + return entrySet.hashCode(); > + } > + > + @Override > + public String toString() { > + return entrySet.toString(); > + } > + > @Override > public Iterator> iterator() { > return entrySet.iterator(); > diff --git a/test/jdk/java/util/Properties/PropertiesEntrySetTest.java > b/test/jdk/java/util/Properties/PropertiesEntrySetTest.java > new file mode 100644 > --- /dev/null > +++ b/test/jdk/java/util/Properties/PropertiesEntrySetTest.java > @@ -0,0 +1,90 @@ > +/* > + * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights > reserved. > + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > + * > + * This code is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2 only, as > + * published by the Free Software Foundation. > + * > + * This code is distributed in the hope that it will be useful, but WITHOUT > + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License > + * version 2 for more details (a copy is included in the LICENSE file that > + * accompanied this code). > + * > + * You should have received a copy of the GNU General Public License > version > + * 2 along with this work; if not, write to the Free Software Foundation, > + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. > + * > + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > + * or visit www.oracle.com if you need additional information or have any > + * questions. > + */ > + > +/* > + * @test > + * @summary tests the entrySet() method of Properties class > + * @author Yu Li > + * @bug 8245694 > + */ > + > +import java.util.Map; > +import java.util.Properties; > +import java.util.Set; > + > +public class PropertiesEntrySetTest { > + > + public static void main(String[] args) { > + > + testEntrySet(); > + > + } > + > + private static void assertTrue(boolean value) { > + if (!value) { > + throw new RuntimeException("Failure in Properties testing."); > + } > + } > + > + private static void assertFalse(boolean value) { > + if (value) { > + throw new RuntimeException("Failure in Properties testing."); > + } > + } > + > + private static void testEntrySet() { > + Properties a = new Properties(); > + Set> aEntrySet = a.entrySet(); > + assertFalse(aEntrySet.equals(null)); > + assertTrue(aEntrySet.equals(aEntrySet)); > + > + Properties b = new Properties(); > + Set> bEntrySet = b.entrySet(); > + assertTrue(aEntrySet.equals(bEntrySet)); > + assertTrue(aEntrySet.hashCode() == bEntrySet.hashCode()); > + > + a.setProperty("p1", "1"); > + assertFalse(aEntrySet.equals(bEntrySet)); > + assertFalse(bEntrySet.equals(aEntrySet)); > + assertFalse(aEntrySet.hashCode() == bEntrySet.hashCode()); > + > + b.setProperty("p1", "1"); > + assertTrue(aEntrySet.equals(bEntrySet)); > + assertTrue(aEntrySet.hashCode() == bEntrySet.hashCode()); > + > + Properties c = new Properties(); > + c.setProperty("p1", "2"); > + Set> cEntrySet = c.entrySet(); > + assertFalse(cEntrySet.equals(bEntrySet)); > + assertFalse(cEntrySet.hashCode() == bEntrySet.hashCode()); > + assertFalse(cEntrySet.equals(aEntrySet)); > + assertFalse(cEntrySet.hashCode() == aEntrySet.hashCode()); > + > + a.setProperty("p2", "2"); > + Properties d = new Properties(); > + d.setProperty("p2", "2"); > + d.setProperty("p1", "1"); > + Set> dEntrySet = d.entrySet(); > + assertTrue(dEntrySet.equals(aEntrySet)); > + } > +} > > Best regards, > Yu Li From pavel.rappo at oracle.com Sat May 30 21:34:35 2020 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Sat, 30 May 2020 22:34:35 +0100 Subject: [PATCH] Typo in java.util.regex.Pattern In-Reply-To: <6d649f2d-a3ab-8980-bc60-497819fb4f28@oracle.com> References: <0714E2ED-0229-4C11-BF8B-A1C702474376@oracle.com> <6d649f2d-a3ab-8980-bc60-497819fb4f28@oracle.com> Message-ID: I'm holding a copy in my hands right now. I can see "ISBN: 978-0-596-52812-6" written on the back of the book. Searching that number in the database yields the following record: Mastering Regular Expressions ISBN-13: 9780596528126 ISBN-10: 0596528124 Author: Friedl, Jeffrey E. F. Edition: Third Binding: Paperback Publisher: O'Reilly Media Published: August 2006 I think it's reasonable to assume that a changeset pushed in November 2006 was referring to a book published no later than that. Certainly, not in August 2009. Which is what the page refers to http://shop.oreilly.com/product/9780596528126.do Is it a newer print of the same edition? It does looks like it. I would use the original patch as is. -Pavel > On 30 May 2020, at 19:13, naoto.sato at oracle.com wrote: > > Just noticed that the release year of the 3rd ed. should also be changed to 2009 in the next line. > > Naoto > > On 5/30/20 4:02 AM, Lance Andersen wrote: >> I can sponsor this for you >> Best >> Lance >> -- >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> Sent from my iPhone >>> On May 29, 2020, at 10:25 PM, Hong Shao Yang wrote: >>> >>> ?Hi! >>> >>> I found a typo which has been long undetected in the documentation. >>> >>> In case you think this is worthwhile, I would appreciate it if someone >>> can sponsor this patch. >>> >>> Cheers, >>> Shao Yang >>> >>> ========= PATCH ========== >>> >>> diff --git a/src/java.base/share/classes/java/util/regex/Pattern.java >>> b/src/java.base/share/classes/java/util/regex/Pattern.java >>> index 0d7d0738965..82325d04f25 100644 >>> --- a/src/java.base/share/classes/java/util/regex/Pattern.java >>> +++ b/src/java.base/share/classes/java/util/regex/Pattern.java >>> @@ -760,7 +760,7 @@ import jdk.internal.util.ArraysSupport; >>> * >>> *

    For a more precise description of the behavior of regular expression >>> * constructs, please see >>> - * Mastering Regular Expressions, 3nd Edition, Jeffrey E. F. Friedl, >>> + * Mastering Regular Expressions, 3rd Edition, Jeffrey E. F. Friedl, >>> * O'Reilly and Associates, 2006. >>> *

    >>> * From naoto.sato at oracle.com Sat May 30 22:35:04 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Sat, 30 May 2020 15:35:04 -0700 Subject: [PATCH] Typo in java.util.regex.Pattern In-Reply-To: References: <0714E2ED-0229-4C11-BF8B-A1C702474376@oracle.com> <6d649f2d-a3ab-8980-bc60-497819fb4f28@oracle.com> Message-ID: Thanks, Pavel. I think the year stays 2006 then. Sorry, Lance, for the false alarm. Naoto On 5/30/20 2:34 PM, Pavel Rappo wrote: > I'm holding a copy in my hands right now. I can see "ISBN: 978-0-596-52812-6" written on the back of the book. Searching that number in the database yields the following record: > > Mastering Regular Expressions > ISBN-13: 9780596528126 > ISBN-10: 0596528124 > Author: Friedl, Jeffrey E. F. > Edition: Third > Binding: Paperback > Publisher: O'Reilly Media > Published: August 2006 > > I think it's reasonable to assume that a changeset pushed in November 2006 was referring to a book published no later than that. Certainly, not in August 2009. Which is what the page refers to http://shop.oreilly.com/product/9780596528126.do Is it a newer print of the same edition? It does looks like it. > > I would use the original patch as is. > > -Pavel > >> On 30 May 2020, at 19:13, naoto.sato at oracle.com wrote: >> >> Just noticed that the release year of the 3rd ed. should also be changed to 2009 in the next line. >> >> Naoto >> >> On 5/30/20 4:02 AM, Lance Andersen wrote: >>> I can sponsor this for you >>> Best >>> Lance >>> -- >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> Sent from my iPhone >>>> On May 29, 2020, at 10:25 PM, Hong Shao Yang wrote: >>>> >>>> ?Hi! >>>> >>>> I found a typo which has been long undetected in the documentation. >>>> >>>> In case you think this is worthwhile, I would appreciate it if someone >>>> can sponsor this patch. >>>> >>>> Cheers, >>>> Shao Yang >>>> >>>> ========= PATCH ========== >>>> >>>> diff --git a/src/java.base/share/classes/java/util/regex/Pattern.java >>>> b/src/java.base/share/classes/java/util/regex/Pattern.java >>>> index 0d7d0738965..82325d04f25 100644 >>>> --- a/src/java.base/share/classes/java/util/regex/Pattern.java >>>> +++ b/src/java.base/share/classes/java/util/regex/Pattern.java >>>> @@ -760,7 +760,7 @@ import jdk.internal.util.ArraysSupport; >>>> * >>>> *

    For a more precise description of the behavior of regular expression >>>> * constructs, please see >>>> - * Mastering Regular Expressions, 3nd Edition, Jeffrey E. F. Friedl, >>>> + * Mastering Regular Expressions, 3rd Edition, Jeffrey E. F. Friedl, >>>> * O'Reilly and Associates, 2006. >>>> *

    >>>> * > From lance.andersen at oracle.com Sat May 30 22:40:37 2020 From: lance.andersen at oracle.com (Lance Andersen) Date: Sat, 30 May 2020 18:40:37 -0400 Subject: [PATCH] Typo in java.util.regex.Pattern In-Reply-To: References: <0714E2ED-0229-4C11-BF8B-A1C702474376@oracle.com> <6d649f2d-a3ab-8980-bc60-497819fb4f28@oracle.com> Message-ID: <54E5ED8D-8E3D-4BAA-89BF-EF0C1F954271@oracle.com> All good Naoto Here is the revised diff ????? $ hg diff src/java.base/share/classes/java/util/regex/Pattern.java diff -r 968b57610c0f src/java.base/share/classes/java/util/regex/Pattern.java --- a/src/java.base/share/classes/java/util/regex/Pattern.java Sat May 30 10:33:28 2020 +0530 +++ b/src/java.base/share/classes/java/util/regex/Pattern.java Sat May 30 18:39:02 2020 -0400 @@ -760,7 +760,7 @@ * *

    For a more precise description of the behavior of regular expression * constructs, please see - * Mastering Regular Expressions, 3nd Edition, Jeffrey E. F. Friedl, + * Mastering Regular Expressions, 3rd Edition, Jeffrey E. F. Friedl, * O'Reilly and Associates, 2006. *

    * ljanders-mac:open ljanders$ --------------- Best Lance > On May 30, 2020, at 6:35 PM, naoto.sato at oracle.com wrote: > > Thanks, Pavel. I think the year stays 2006 then. > Sorry, Lance, for the false alarm. > > Naoto > > On 5/30/20 2:34 PM, Pavel Rappo wrote: >> I'm holding a copy in my hands right now. I can see "ISBN: 978-0-596-52812-6" written on the back of the book. Searching that number in the database yields the following record: >> Mastering Regular Expressions >> ISBN-13: 9780596528126 >> ISBN-10: 0596528124 >> Author: Friedl, Jeffrey E. F. >> Edition: Third >> Binding: Paperback >> Publisher: O'Reilly Media >> Published: August 2006 >> I think it's reasonable to assume that a changeset pushed in November 2006 was referring to a book published no later than that. Certainly, not in August 2009. Which is what the page refers to http://shop.oreilly.com/product/9780596528126.do Is it a newer print of the same edition? It does looks like it. >> I would use the original patch as is. >> -Pavel >>> On 30 May 2020, at 19:13, naoto.sato at oracle.com wrote: >>> >>> Just noticed that the release year of the 3rd ed. should also be changed to 2009 in the next line. >>> >>> Naoto >>> >>> On 5/30/20 4:02 AM, Lance Andersen wrote: >>>> I can sponsor this for you >>>> Best >>>> Lance >>>> -- >>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>>> Sent from my iPhone >>>>> On May 29, 2020, at 10:25 PM, Hong Shao Yang wrote: >>>>> >>>>> ?Hi! >>>>> >>>>> I found a typo which has been long undetected in the documentation. >>>>> >>>>> In case you think this is worthwhile, I would appreciate it if someone >>>>> can sponsor this patch. >>>>> >>>>> Cheers, >>>>> Shao Yang >>>>> >>>>> ========= PATCH ========== >>>>> >>>>> diff --git a/src/java.base/share/classes/java/util/regex/Pattern.java >>>>> b/src/java.base/share/classes/java/util/regex/Pattern.java >>>>> index 0d7d0738965..82325d04f25 100644 >>>>> --- a/src/java.base/share/classes/java/util/regex/Pattern.java >>>>> +++ b/src/java.base/share/classes/java/util/regex/Pattern.java >>>>> @@ -760,7 +760,7 @@ import jdk.internal.util.ArraysSupport; >>>>> * >>>>> *

    For a more precise description of the behavior of regular expression >>>>> * constructs, please see >>>>> - * Mastering Regular Expressions, 3nd Edition, Jeffrey E. F. Friedl, >>>>> + * Mastering Regular Expressions, 3rd Edition, Jeffrey E. F. Friedl, >>>>> * O'Reilly and Associates, 2006. >>>>> *

    >>>>> * Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From naoto.sato at oracle.com Sat May 30 22:47:02 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Sat, 30 May 2020 15:47:02 -0700 Subject: [PATCH] Typo in java.util.regex.Pattern In-Reply-To: <54E5ED8D-8E3D-4BAA-89BF-EF0C1F954271@oracle.com> References: <0714E2ED-0229-4C11-BF8B-A1C702474376@oracle.com> <6d649f2d-a3ab-8980-bc60-497819fb4f28@oracle.com> <54E5ED8D-8E3D-4BAA-89BF-EF0C1F954271@oracle.com> Message-ID: <2de1c45b-86ba-7e7c-9db1-0259f8e77f02@oracle.com> Looks good! Naoto On 5/30/20 3:40 PM, Lance Andersen wrote: > All good Naoto > > Here is the revised diff > > ????? > $ hg diff src/java.base/share/classes/java/util/regex/Pattern.java > *diff -r 968b57610c0f > src/java.base/share/classes/java/util/regex/Pattern.java* > *--- a/src/java.base/share/classes/java/util/regex/Pattern.java? Sat May > 30 10:33:28 2020 +0530* > *+++ b/src/java.base/share/classes/java/util/regex/Pattern.java? Sat May > 30 18:39:02 2020 -0400* > @@ -760,7 +760,7 @@ > ? * > ? *

    For a more precise description of the behavior of regular > expression > ? * constructs, please see href="http://www.oreilly.com/catalog/regex3/"> > - * Mastering Regular Expressions, 3nd Edition, Jeffrey E. F. Friedl, > + * Mastering Regular Expressions, 3rd Edition, Jeffrey E. F. Friedl, > ? * O'Reilly and Associates, 2006. > ? *

    > ? * > ljanders-mac:open ljanders$ > --------------- > > > Best > Lance >> On May 30, 2020, at 6:35 PM, naoto.sato at oracle.com >> wrote: >> >> Thanks, Pavel. I think the year stays 2006 then. >> Sorry, Lance, for the false alarm. >> >> Naoto >> >> On 5/30/20 2:34 PM, Pavel Rappo wrote: >>> I'm holding a copy in my hands right now. I can see "ISBN: >>> 978-0-596-52812-6" written on the back of the book. Searching that >>> number in the database yields the following record: >>> ????Mastering Regular Expressions >>> ????ISBN-13: 9780596528126 >>> ????ISBN-10: 0596528124 >>> ????Author: Friedl, Jeffrey E. F. >>> ????Edition: Third >>> ????Binding: Paperback >>> ????Publisher: O'Reilly Media >>> ????Published: August 2006 >>> I think it's reasonable to assume that a changeset pushed in November >>> 2006 was referring to a book published no later than that. Certainly, >>> not in August 2009. Which is what the page refers to >>> http://shop.oreilly.com/product/9780596528126.do Is it a newer print >>> of the same edition? It does looks like it. >>> I would use the original patch as is. >>> -Pavel >>>> On 30 May 2020, at 19:13, naoto.sato at oracle.com >>>> wrote: >>>> >>>> Just noticed that the release year of the 3rd ed. should also be >>>> changed to 2009 in the next line. >>>> >>>> Naoto >>>> >>>> On 5/30/20 4:02 AM, Lance Andersen wrote: >>>>> I can sponsor this for you >>>>> Best >>>>> Lance >>>>> -- >>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>> Oracle Java Engineering >>>>> 1 Network Drive >>>>> Burlington, MA 01803 >>>>> Lance.Andersen at oracle.com >>>>> Sent from my iPhone >>>>>> On May 29, 2020, at 10:25 PM, Hong Shao Yang >>>>>> wrote: >>>>>> >>>>>> ?Hi! >>>>>> >>>>>> I found a typo which has been long undetected in the documentation. >>>>>> >>>>>> In case you think this is worthwhile, I would appreciate it if someone >>>>>> can sponsor this patch. >>>>>> >>>>>> Cheers, >>>>>> Shao Yang >>>>>> >>>>>> ========= PATCH ========== >>>>>> >>>>>> diff --git a/src/java.base/share/classes/java/util/regex/Pattern.java >>>>>> b/src/java.base/share/classes/java/util/regex/Pattern.java >>>>>> index 0d7d0738965..82325d04f25 100644 >>>>>> --- a/src/java.base/share/classes/java/util/regex/Pattern.java >>>>>> +++ b/src/java.base/share/classes/java/util/regex/Pattern.java >>>>>> @@ -760,7 +760,7 @@ import jdk.internal.util.ArraysSupport; >>>>>> ?* >>>>>> ?*

    For a more precise description of the behavior of regular >>>>>> expression >>>>>> ?* constructs, please see >>>>> href="http://www.oreilly.com/catalog/regex3/"> >>>>>> - * Mastering Regular Expressions, 3nd Edition, Jeffrey E. >>>>>> F. Friedl, >>>>>> + * Mastering Regular Expressions, 3rd Edition, Jeffrey E. >>>>>> F. Friedl, >>>>>> ?* O'Reilly and Associates, 2006. >>>>>> ?*

    >>>>>> ?* > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From martinrb at google.com Sat May 30 23:33:56 2020 From: martinrb at google.com (Martin Buchholz) Date: Sat, 30 May 2020 16:33:56 -0700 Subject: Sometimes constraints are questionable In-Reply-To: <87ftbh5m4h.fsf@mid.deneb.enyo.de> References: <4A5AC9D1-AEB7-47E3-9E25-BF74FE01F3B0@oracle.com> <87ftbh5m4h.fsf@mid.deneb.enyo.de> Message-ID: On Sat, May 30, 2020 at 11:11 AM Florian Weimer wrote: > > * Martin Buchholz: > > > I wrote an earlier version of this grow logic, and then it was > > transplanted into other classes. > > > > We strongly suspect that the VM will throw OOME when we try to > > allocate an array beyond MAX_ARRAY_SIZE, so are reluctant to do so, > > but we also consider the VM behavior a bug that may eventually get > > fixed (or is already a non-issue with a different VM). We are trying > > for good behavior with both sorts of VM. > > I still don't think this explains the present code. It's very easy for nano-bugs in code like this to creep in, because of the difficulty of testing. > However, I > wouldn't be surprised if there have been early bugs where the VM would > produce a corrupt array instead of failing the allocation. But these > bugs will have been fixed by now. IIRC I invented MAX_ARRAY_SIZE and there was no thought of such VM bugs. VM engineers are expected to fix any such bugs quickly. > C++ has a subclass of std::bad_alloc for certain allocations that > exceed implementation limits (std::bad_array_new_length). Since > memory is rarely tight when this happens, it allows providing better > diagnostics. And hotspot itself includes a meaningful detail when it throws an exception from new Object[Integer.MAX_VALUE]. But that behavior is unspecified. We could have introduced a new subclass of Throwable that was specified to be thrown when implementation limits were exceeded. As usual, probably too late now. From andy.herrick at oracle.com Sun May 31 16:13:43 2020 From: andy.herrick at oracle.com (Andy Herrick) Date: Sun, 31 May 2020 12:13:43 -0400 Subject: RFR: JDK-8246010: AdditionalLaunchersTest is not enabled, and fails. In-Reply-To: <0cc1a351-c23c-7d7c-be81-77cbdf317d66@oracle.com> References: <1d333406-e903-e5b0-c247-609293cc8322@oracle.com> <2c32ab4d-e434-2e0e-b615-f4338dba2d56@oracle.com> <0cc1a351-c23c-7d7c-be81-77cbdf317d66@oracle.com> Message-ID: <880c0edb-8d95-aba0-8a74-2394605e6134@oracle.com> Please revice revised webrev at [3] I have revised to only throw FileServiceException right before operations that will fail. [3] webrev: http://cr.openjdk.java.net/~herrick/8246010/webrev.02 /Andy On 5/29/2020 7:38 PM, Andy Herrick wrote: > > On 5/29/20 7:16 PM, Alexey Semenyuk wrote: >> Andy, >> >> The check is added to WindowsAppImageBuilder.java which means it will >> be done for app image bundling too. However the problem is with msi >> bundling only as far as I understood from your explanation. >> Did you try fix suggested at [1]? > > Yes - should add more comments in the bug report. > > The problem exists for app-image bundle as well, from within > ExecutableRebrander. > > /Z > >> >> [1] >> https://stackoverflow.com/questions/15431210/wix-relative-path-ends-up-being-too-long >> >> - Alexey >> >> On 5/29/2020 7:12 PM, Andy Herrick wrote: >>> >>> On 5/29/20 7:00 PM, alexander.matveev at oracle.com wrote: >>>> Hi Andy, >>>> >>>> Why we need error.lock-resource? >>> because resource was used , but never defined. >>>> >>>> Also, I do not like 194 limit obtained by testing, since once new >>>> files are introduced in runtime this value might not work anymore. >>>> Can we check on actual file paths to make sure they have valid length? >>> >>> I don't like it either, but otherwise we need to test length every >>> time we create a path, and the check needs to be platform dependent. >>> >>> /Andy >>> >>>> >>>> Thanks, >>>> Alexander >>>> >>>> On 5/29/20 7:36 AM, Andy Herrick wrote: >>>>> Please review jpackage fix at [1] to issue [2] >>>>> >>>>> /Andy >>>>> >>>>> [1] http://cr.openjdk.java.net/~herrick/8246010/webrev.01/ >>>>> >>>>> [2] https://bugs.openjdk.java.net/browse/JDK-8246010 >>>>> >>>> >> From alexey.semenyuk at oracle.com Sun May 31 21:28:14 2020 From: alexey.semenyuk at oracle.com (Alexey Semenyuk) Date: Sun, 31 May 2020 17:28:14 -0400 Subject: RFR: 8232841: [TESTBUG] [macos] SigningPackageTest fails when untrusted certificates exist on machine In-Reply-To: <1d1ab383-61ff-c573-8846-80c801f977b2@oracle.com> References: <1d1ab383-61ff-c573-8846-80c801f977b2@oracle.com> Message-ID: <6fcbab62-9759-0973-9364-2088f0371492@oracle.com> Looks good. - Alexey On 5/29/2020 7:39 PM, alexander.matveev at oracle.com wrote: > Please review the jpackage fix for bug [1] at [2]. > > - I was not able to reproduce this issue. Not sure why this command > returns non zero code in some cases. It still returns output which we > need, so fixed by ignoring exit code, since we will scan output for > presence of certificate anyway. > > [1] https://bugs.openjdk.java.net/browse/JDK-8232841 > > [2] http://cr.openjdk.java.net/~almatvee/8232841/webrev.00/ > > Thanks, > Alexander From harold.seigel at oracle.com Sun May 31 22:57:41 2020 From: harold.seigel at oracle.com (Harold Seigel) Date: Sun, 31 May 2020 18:57:41 -0400 Subject: RFR: JDK-8225056 VM support for sealed classes In-Reply-To: <0749bff1-02ac-841e-4bd7-4a511a90be9d@oracle.com> References: <7b3430e1-f821-1e2d-2c8b-f1c621f059da@oracle.com> <9d7da8af-cda3-693d-1ea1-1db5069fea97@oracle.com> <9b32addd-d576-268e-61ab-0ac4921d22f5@oracle.com> <151289f6-820c-08d1-c2f9-85b18d1bcaf5@oracle.com> <0749bff1-02ac-841e-4bd7-4a511a90be9d@oracle.com> Message-ID: <9da783ba-edd9-b5fe-0476-644ba7d01990@oracle.com> Thanks for the comments. Here's version 3 of the JDK and VM changes for sealed classes. full webrev: http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.3/webrev/ The new webrev contains just the following three changes: 1. The sealed classes API's in Class.java (permittedSubclasses() and isSealed()) were revised and, in particular, API permittedSubclasses() no longer uses reflection. 2. An unneeded 'if' statement was removed from JVM_GetPermittedSubclasses() (pointed out by David.) 3. VM runtime test files SealedUnnamedModuleIntfTest.java and Permitted.java were changed to add a test case for a non-public permitted subclass and its sealed superclass being in the same module and package. Additionally, two follow on RFE's will be filed.? One to add additional VM sealed classes tests and one to improve the implementations of the sealed classes API's in Class.java. Thanks, Harold On 5/28/2020 8:30 PM, David Holmes wrote: > > Hi Harold, > > Sorry Mandy's comment raised a couple of issues ... > > On 29/05/2020 7:12 am, Mandy Chung wrote: >> Hi Harold, >> >> On 5/27/20 1:35 PM, Harold Seigel wrote: >>> >>> Incremental webrev: >>> http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.incr.2/ >>> >>> full webrev: >>> http://cr.openjdk.java.net/~hseigel/sealedClasses.8225056.2/webrev/ >>> >> Class.java >> >> 4406 ReflectionData rd = reflectionData(); >> 4407 ClassDesc[] tmp = rd.permittedSubclasses; >> 4408 if (tmp != null) { >> 4409 return tmp; >> 4410 } >> 4411 >> 4412 if (isArray() || isPrimitive()) { >> 4413 rd.permittedSubclasses = new ClassDesc[0]; >> 4414 return rd.permittedSubclasses; >> 4415 } >> >> This causes an array class or primitive type to create a >> ReflectionData.?? It should first check if this is non-sealed class >> and returns a constant empty array. > > It can't check if this is a non-sealed class as the isSealed() check > calls the above code! But for arrays and primitives which can't be > sealed we should just do: > > 4412 if (isArray() || isPrimitive()) { > 4413 return new ClassDesc[0]; > 4414 } > > But this then made me realize that we need to be creating defensive > copies of the returned arrays, as happens with other APIs that use > ReflectionData. > > Backing up a bit I complained that: > > public boolean isSealed() { > return permittedSubclasses().length != 0; > } > > is a very inefficient way to answer the question as to whether a class > is sealed, so I suggested that the result of permittedSubclasses() be > cached. Caching is not without its own issues as we are discovering, > and when you add in defensive copies this seems to be trading one > inefficiency for another. For nestmates we don't cache > getNestMembers() because we don;t think it will be called often - it > is there to complete the introspection API of Class rather than being > anticipated as used in a regular programmatic sense. I expect the same > is true for permittedSubclasses(). Do we expect isSealed() to be used > often or is it too just there for completeness? If just for > completeness then perhaps a VM query would be a better compromise on > the efficiency front? Otherwise I can accept the current > implementation of isSealed(), and a non-caching permittedClasses() for > this initial implementation of sealed classes. If efficiency turns out > to be a problem for isSealed() then we can revisit it then. > > Thanks, > David > > >> In fact, ReflectionData caches the derived names and reflected >> members for performance and also they may be invalidated when the >> class is redefined.?? It might be okay to add >> ReflectionData::permittedSubclasses while `PermittedSubclasses` >> attribute can't be redefined and getting this attribute is not >> performance sensitive.?? For example, the result of `getNestMembers` >> is not cached in ReflectionData.? It may be better not to add it in >> ReflectionData for modifiable and performance-sensitive data. >> >> >> 4421 tmp = new ClassDesc[subclassNames.length]; >> 4422 int i = 0; >> 4423 for (String subclassName : subclassNames) { >> 4424 try { >> 4425 tmp[i++] = ClassDesc.of(subclassName.replace('/', '.')); >> 4426 } catch (IllegalArgumentException iae) { >> 4427 throw new InternalError("Invalid type in permitted subclasses >> information: " + subclassName, iae); >> 4428 } >> 4429 } >> Nit: rename tmp to some other name e.g. descs >> >> I read the JVMS but it isn't clear to me that the VM will validate >> the names in `PermittedSubclasses`attribute are valid class >> descriptors.?? I see ConstantPool::is_klass_or_reference check but >> can't find where it validates the name is a valid class descriptor - >> can you point me there??? (otherwise, maybe define it to be unspecified?) >> >> >> W.r.t. the APIs. I don't want to delay this review.? I see that you >> renamed the method to new API style as I brought up.? OTOH,? I expect >> more discussion is needed.? Below is a recent comment from John on >> this topic [1] >> >>> One comment, really for the future, regarding the shape of the Java >>> API here: It uses Optional and omits the "get" prefix on accessors. >>> This is the New Style, as opposed to the Classic Style using null >>> (for "empty" results) and a "get" prefix ("getComponentType") to get >>> a related type. We may choose to to use the New Style for new >>> reflection API points, and if so let's not choose N different New >>> Styles, but one New Style. Personally I like removing "get"; I >>> accept Optional instead of null; and I also suggest that arrays (if >>> any) be replaced by (immutable) Lists in the New Style >> >> There are a few existing Class APIs that use the new API style: >> Class arrayClass(); >> Optional describeConstable(); >> String descriptorString(); >> >> This will set up a precedence of the new API style in this class.? >> Should this new permittedSubclasses method return a List instead of >> an array?? It's okay with me if you prefer to revert back to the old >> API style and follow this up after integration. >> >> 4442 * Returns true if this {@linkplain Class} is sealed. >> 4443 * >> 4444 * @return returns true if this class is sealed >> >> NIt: {@code true} instead of true -? consistent with the style this >> class uses (in most methods) >> >> test/jdk/java/lang/reflect/sealed_classes/SealedClassesReflectionTest.java >> >> Nit: s/sealed_classes/sealedClasses/ >> - the test directory/file naming convention use camel case or java >> variable name convention. >> >> Thanks >> [1] https://github.com/openjdk/valhalla/pull/53#issuecomment-633116043 From david.holmes at oracle.com Sun May 31 23:34:42 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Jun 2020 09:34:42 +1000 Subject: Sometimes constraints are questionable In-Reply-To: <4A5AC9D1-AEB7-47E3-9E25-BF74FE01F3B0@oracle.com> References: <4A5AC9D1-AEB7-47E3-9E25-BF74FE01F3B0@oracle.com> Message-ID: On 31/05/2020 12:29 am, Jim Laskey wrote: > I'm working through https://bugs.openjdk.java.net/browse/JDK-8230744 Several classes throw OutOfMemoryError without message . > > I'm wondering why hugeCapacity in src/jdk.zipfs/share/classes/jdk/nio/zipfs/ByteArrayChannel.java is defined as > > /** > * The maximum size of array to allocate. > * Some VMs reserve some header words in an array. > * Attempts to allocate larger arrays may result in > * OutOfMemoryError: Requested array size exceeds VM limit > */ > private static final int MAX_ARRAY_SIZE = Integer.MAX_VALUE - 8; > > /** > * Increases the capacity to ensure that it can hold at least the > * number of elements specified by the minimum capacity argument. > * > * @param minCapacity the desired minimum capacity > */ > private void grow(int minCapacity) { > // overflow-conscious code > int oldCapacity = buf.length; > int newCapacity = oldCapacity << 1; > if (newCapacity - minCapacity < 0) > newCapacity = minCapacity; > if (newCapacity - MAX_ARRAY_SIZE > 0) > newCapacity = hugeCapacity(minCapacity); > buf = Arrays.copyOf(buf, newCapacity); > } > > private static int hugeCapacity(int minCapacity) { > if (minCapacity < 0) // overflow > throw new OutOfMemoryError(); Not sure how we could have minCapacity < 0 at this point. It should have been checked before the call to grow, and grow will not make it negative. > return (minCapacity > MAX_ARRAY_SIZE) ? > Integer.MAX_VALUE : > MAX_ARRAY_SIZE; That's a bug plain and simple. It should never report a size > MAX_ARRAY_SIZE. > } > > It just seems that it's pushing the inevitable off to Arrays.copyOf. Shouldn't it be: > > private static int hugeCapacity(int minCapacity) { > if (minCapacity < 0 || minCapacity > MAX_ARRAY_SIZE) { > throw > new OutOfMemoryError("ByteArrayChannel exceeds maximum size: " + > MAX_ARRAY_SIZE); > } > > return MAX_ARRAY_SIZE; > } That seems more appropriate to me - modulo the question mark over minCapacity being negative. > Real question: is there some hidden purpose behind this kind of logic? The basic strategy is to double the current capacity unless that will trigger an unnecessary exception, in which case just use the requested capacity, but again watch for the implementation limits. Cheers, David ----- > > Cheers, > > -- Jim > > From martinrb at google.com Sun May 31 23:52:35 2020 From: martinrb at google.com (Martin Buchholz) Date: Sun, 31 May 2020 16:52:35 -0700 Subject: Sometimes constraints are questionable In-Reply-To: References: <4A5AC9D1-AEB7-47E3-9E25-BF74FE01F3B0@oracle.com> Message-ID: On Sun, May 31, 2020 at 4:35 PM David Holmes wrote: > Not sure how we could have minCapacity < 0 at this point. It should have > been checked before the call to grow, and grow will not make it negative. At least some of the grow methods were designed so that callers did not have to do the checking, and grow would interpret negative values as int overflow > > It just seems that it's pushing the inevitable off to Arrays.copyOf. Shouldn't it be: > > > > private static int hugeCapacity(int minCapacity) { > > if (minCapacity < 0 || minCapacity > MAX_ARRAY_SIZE) { > > throw > > new OutOfMemoryError("ByteArrayChannel exceeds maximum size: " + > > MAX_ARRAY_SIZE); > > } > > > > return MAX_ARRAY_SIZE; > > } > > That seems more appropriate to me - modulo the question mark over > minCapacity being negative. Again, the original design was to allow a capacity with MAX_ARRAY_SIZE < capacity <= Integer.MAX_VALUE if and when the VM also allowed it. From liyu.italy at gmail.com Sat May 30 14:28:42 2020 From: liyu.italy at gmail.com (Lisa Li) Date: Sat, 30 May 2020 22:28:42 +0800 Subject: [PATCH] 8245694 : java.util.Properties.entrySet() does not override java.lang.Object methods Message-ID: Hi, Please help review the fix for JDK-8245694 . And this is my very first patch submission. I know it's not perfect. *BUG DESCRIPTION*: JDK-8245694 : java.util.Properties.entrySet() does not override java.lang.Object methods since java 9. *PROPOSED FIX*: Add delegating overrides for equals(), hashCode(), and toString(). *PATCH*: # HG changeset patch # User yuli # Date 1590841711 -28800 # Sat May 30 20:28:31 2020 +0800 # Node ID 7dc946e5b5863291fa070bfdbdce48aefbe87b7b # Parent 8e28aae5068069e853673148e4d3f44cb50350a7 8245694: java.util.Properties.entrySet() does not override Object methods Summary: Add missing override methods Contributed-by: Yu Li diff --git a/src/java.base/share/classes/java/util/Properties.java b/src/java.base/share/classes/java/util/Properties.java --- a/src/java.base/share/classes/java/util/Properties.java +++ b/src/java.base/share/classes/java/util/Properties.java @@ -1414,6 +1414,21 @@ return entrySet.retainAll(c); } + @Override + public boolean equals(Object o) { + return entrySet.equals(o); + } + + @Override + public int hashCode() { + return entrySet.hashCode(); + } + + @Override + public String toString() { + return entrySet.toString(); + } + @Override public Iterator> iterator() { return entrySet.iterator(); diff --git a/test/jdk/java/util/Properties/PropertiesEntrySetTest.java b/test/jdk/java/util/Properties/PropertiesEntrySetTest.java new file mode 100644 --- /dev/null +++ b/test/jdk/java/util/Properties/PropertiesEntrySetTest.java @@ -0,0 +1,90 @@ +/* + * Copyright (c) 2018, 2019, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @summary tests the entrySet() method of Properties class + * @author Yu Li + * @bug 8245694 + */ + +import java.util.Map; +import java.util.Properties; +import java.util.Set; + +public class PropertiesEntrySetTest { + + public static void main(String[] args) { + + testEntrySet(); + + } + + private static void assertTrue(boolean value) { + if (!value) { + throw new RuntimeException("Failure in Properties testing."); + } + } + + private static void assertFalse(boolean value) { + if (value) { + throw new RuntimeException("Failure in Properties testing."); + } + } + + private static void testEntrySet() { + Properties a = new Properties(); + Set> aEntrySet = a.entrySet(); + assertFalse(aEntrySet.equals(null)); + assertTrue(aEntrySet.equals(aEntrySet)); + + Properties b = new Properties(); + Set> bEntrySet = b.entrySet(); + assertTrue(aEntrySet.equals(bEntrySet)); + assertTrue(aEntrySet.hashCode() == bEntrySet.hashCode()); + + a.setProperty("p1", "1"); + assertFalse(aEntrySet.equals(bEntrySet)); + assertFalse(bEntrySet.equals(aEntrySet)); + assertFalse(aEntrySet.hashCode() == bEntrySet.hashCode()); + + b.setProperty("p1", "1"); + assertTrue(aEntrySet.equals(bEntrySet)); + assertTrue(aEntrySet.hashCode() == bEntrySet.hashCode()); + + Properties c = new Properties(); + c.setProperty("p1", "2"); + Set> cEntrySet = c.entrySet(); + assertFalse(cEntrySet.equals(bEntrySet)); + assertFalse(cEntrySet.hashCode() == bEntrySet.hashCode()); + assertFalse(cEntrySet.equals(aEntrySet)); + assertFalse(cEntrySet.hashCode() == aEntrySet.hashCode()); + + a.setProperty("p2", "2"); + Properties d = new Properties(); + d.setProperty("p2", "2"); + d.setProperty("p1", "1"); + Set> dEntrySet = d.entrySet(); + assertTrue(dEntrySet.equals(aEntrySet)); + } +} Best regards, Yu Li Attachments area