October 2017 - core-libs-dev

Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be exited by java
by Adam Farley8 25 Oct '17

25 Oct '17

Hi All, Updated summary, based on the responses: 1) Exit(0) (during VM startup) is a big bug because it imitates successful completion of external cpp code accessing JNI methods. 2) One solution for (1) is to specify a new return code for JNI. 3) The supplied code (diff) generates, facilitates, and handles that return code for the exit(0) scenario: -agentlib:jdwp=help 4) The exit(0) problem (in general) is worth fixing, however we may choose not to support the use of this new code in the jdwp example case. 5) The supplied test confirms that the supplied code works (run via unzip, and then bash TestStart.sh <path to jdk home dir that contains bin dir>). 6) To implement this new return code, plus the code that handles it, we would need to follow the CSR process to modify the JNI spec. 7) To implement the jdwp scenario fix, if we choose to support it at all, we would also need to use the CSR process the JVM TI spec. 8) To address all of the worst instances of exit(0), we would need to search for exit(0) and raise a bug for each significant one (or group). 9) To solve (8) in one bug would be a lot of work, arguably too much work for a single bug. 10) If the new return code is identified as the appropriate solution to this problem, we will need to agree on the right name and return code value. Also, here's a shortlist of the main questions I recall being raised here, plus answers people have given. A) What are the potential solutions for the exit(0) problem? i) New JNI Return Code. ii) Remove the info-only options, at least via the JNI, and return a standard error code if they are used. iii) Remove the info-only options, at least via the JNI, and filter them out if they are used. iv) Retain existing behaviour, and document a need for the user to filter out help options before starting the VM via the JNI. B) What are the criteria for the "Best" solution? i) It must prevent "exit(0)" calls. ii) It must be proven to work. iii) It should require minimal (none, ideally) behaviour change from the java.exe user. iv) It should allow the external cpp code accessing the JNI to complete normally, without being prematurely terminated. C) Which solutions meet the (B) criteria? i) Both the "new return code" and the "remove info-only options" solutions meet the (B) criteria. D) Is it right to have any "Do X and then exit." arguments at all, and (if no) what would be the alternatives? i) ? Best Regards Adam Farley P.S. As per Alan and David's emails, the exit(#) references have been removed entirely, as discussing them alongside the original exit(0) problem risks scope creep. This bug, if raised, should only cover the exit(0) cases. I believe we have consensus here. From: David Holmes <david.holmes(a)oracle.com> To: Adam Farley8 <adam.farley(a)uk.ibm.com>, Alan Bateman <Alan.Bateman(a)oracle.com>, core-libs-dev(a)openjdk.java.net, hotspot-runtime-dev(a)openjdk.java.net, thomas.stuefe(a)gmail.com Date: 13/10/2017 14:31 Subject: Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be exited by java Hi Adam, On 13/10/2017 10:16 PM, Adam Farley8 wrote: > Hi All, > > Here's a summary of the email below (which is intended, partly, as a > summary of the emails before it). > > Let me know if you agree/disagree with any of these points. > > 1) Exit(#) during vm startup is a bug because it should return a code > regardless of the state of the VM. Yes it's a bug but not one that is likely to be addressed in any foreseeable timeframe. There are simply too many "exit on error" paths. If we were to start using C++ exceptions within the VM that might provide a way to quickly get back to the CreateJavaVM routine where we could return an error code - but that is itself a major project that has barely even been discussed AFAIK. (Compiler folk have talked about it because compiler paths are fairly self-contained - though that was before Graal and AOT.) > 2) Exit(0) is an *especially* big bug because it imitates successful > completion of external cpp code accessing JNI methods. > 3) One solution is to specify a new return code for JNI. A solution for 2) yes. > 4) The supplied code (diff) generates, facilitates, and handles that > return code for the exit(0) scenario: -agentlib:jdwp=help > 5) The supplied test confirms that the supplied code works (run via > unzip, and then bash TestStart.sh <path to jdk home dir that contains > bin dir>). > 6) To implement this new return code, plus the code that handles it, we > would need to follow the CSR process. > 7) To implement the fix for the scenario used as an example of the new > return code's use, we would need to modify the JVM TI spec. Yes you have demonstrated a potential solution for the agent case. The question is, is it the right solution? Is it a worthwhile solution? (As I've said I'd prefer not to have any "do something then exit" VM arguments.) And can we make it fit into the existing specs without contorting things too much. I still think it easier/preferable for whatever loads the VM to filter out the VM args that trigger this behaviour. I mean if you pass -Xshare:dump you don't have any right to expect a functioning VM after JNI_CreateJavaVM returns - at least I don't think so. Just don't do it. Yes it is an imperfection in the invocation API, but life isn't perfect. > 8) To address all of the worst instances of exit(#), we would need to > search for exit(#) and raise a bug for each significant one (or group). > 9) To solve (8) in one bug would be a lot of work, arguably too much > work for a single bug. This is simply impractical. You may be able to pick off a few low-hanging cases, but that won't really make any practical difference. > 10) If the new return code is chosen as the appropriate solution to this > problem, we may need to choose a better name for the return code. > > Is this a fair assessment of the current state of the debate? It's a fair summary of your position and proposal. Cheers, David > I'm on IRC every weekday from 9am-5pm (4pm fridays) BST (GMT+1) if > anyone wants to discuss this in real-time on the openjdk channel. > > Best Regards > > Adam Farley > > > > -- Previous Email -- > > Hi David, Alan, > > You are right in that the changes to HotSpot would be nontrivial. > I see a number of places in (e.g.) arguments.cpp that seem to > exit in the same manner as Xlog (such as -Xinternalversion). > > I would advise ploughing through the CSR process to alter the > JNI spec, and simultaneously identify some key paths that can > be raised as bugs. That way, when people have time to address > these issues, the mechanism to handle a silent exit is already > in place. > > The JDWP fix can be raised separately as one of these bugs, if > it would make things simpler. > > As for the name, JNI_SILENT_EXIT is a placeholder, and can be > readily changed. Do you have any suggestions? > > Lastly, in an ideal world, the VM initialisation should never exit(#). It > should return a return code that tells the caller something, pass or > fail, messy or tidy. That way, if someone is using the JNI as part of > something bigger (like a database or a web server), one of these > scenarios is just a bug, rather than a world-ender like exit(#). > > And now for the individual messages. :) > > David: Having help data returned by the launcher seems like a > good way to avoid exit(0) calls, but I'm not sure how we'd prevent > a JNI-caller using those options. Ultimately, to be sure, we'd have > to remove the logic for those options, centralise the data to better > enable launcher access, and add some logic in there so it can find > any other help data (e.g. from the jdwp agent library). I feel this would > be a bigger task than adding the new return code and changing the > vm, plus it wouldn't provide for any non-help scenarios where the > vm wants to shut down without error during initialisation. > > Alan: I should mention that the silent exit solution is already in > use in the OpenJ9 VM. Not all of the exit paths have been > resolved, but many have. > > The code is open and can be found here: < https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse_ope… > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_eclipse_ope… > > And though the silent exit code is disabled for the time being, it > can be re-enabled by entering this class: > > runtime/vm/jvminit.c > > and altering line 2343 ( ctrl-f for exit(1) if it's not there). > > I won't paste the full code here in case people are concerned > about contamination, but I would assert that this code (and the > associated vm files) prove that the concept is possible. > > Note that that code should not be enabled until after we've > integrated the code that can handle a silent exit. > > Best Regards > > Adam Farley > > P.S. Thank you both for your efforts on this. :) > > > > From: David Holmes <david.holmes(a)oracle.com> > To: Alan Bateman <Alan.Bateman(a)oracle.com>, Adam Farley8 > <adam.farley(a)uk.ibm.com>, core-libs-dev(a)openjdk.java.net, > hotspot-runtime-dev(a)openjdk.java.net, thomas.stuefe(a)gmail.com > Date: 15/09/2017 12:03 > Subject: Re: [BUG PROPOSAL]: C++ code that calls JNI_CreateJavaVM can be > exited by java > ------------------------------------------------------------------------ > > > > > > On 15/09/2017 8:17 PM, Alan Bateman wrote: > > On 15/09/2017 02:47, David Holmes wrote: > >> Hi Adam, > >> > >> I am still very much torn over this one. I think the idea of > >> print-and-exit flags for a potentially hosted library like the JVM is > >> just wrong - we should never have done that, but we did. Fixing that > >> by moving the flags to the launcher is far from trivial**. Endorsing > >> and encouraging these sorts of flag by adding JNI support seems to be > >> sending the wrong message. > >> > >> ** I can envisage a "help xxx" Dcmd that can read back the info from > >> the VM. The launcher can send the Dcmd, print the output and exit. The > >> launcher would not need to know what the xxx values mean, but would > >> have to intercept the existing ones. > >> > >> Another option is just to be aware of these flags (are there more than > >> jdwp and Xlog?) and deal with them specially in your custom launcher - > >> either filter them out and ignore them, or else launch the VM in its > >> own process to respond to them. > >> > >> Any changes to the JNI specification need to go through the CSR process. > > Yes, it would require an update to the JNI spec, also a change to the > > JVM TI spec where Agent_OnLoad returning a non-0 value is specified to > > terminates the VM. The name and value needs discussion too, esp. as the > > JNI spec uses negative values for failure. > > > > In any case, I'm also torn over this one as it's a corner case that is > > only interesting for custom launchers that load agents with options that > > print usage messages. It wouldn't be hard to have the Agent_OnLoad > > specify a printf hook that the agent could use for output although there > > are complications with agents such as JDWP that also announce their > > transport end point. Beyond that there is still the issue of the custom > > launcher that would need to know to destroy the VM without reporting an > > error. > > > > So what happened to the more meaty part to this which is fixing the > > various cases in HotSpot that terminate the process during > > initialization? I would expect some progress could be made on those > > cases while trying to decide whether to rev the JNI and JVM TI specs to > > cover the help case. > > Trying to eliminate the vm_exit_during_initialization paths in hotspot > is a huge undertaking IMHO. > > David > > > > > -Alan > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

2 1

[10] RFR: 8189272 & 8189291
by Naoto Sato 24 Oct '17

24 Oct '17

Hello, Please review the changes for the following two issues: 8189272: CLDR and JRE LocaleProviderAdapters silently swallow exceptions [1] 8189291: Test policy should extend the default system policy [2] The proposed fixes for the above issues are located below, respectively: http://cr.openjdk.java.net/~naoto/8189272/webrev.00/ http://cr.openjdk.java.net/~naoto/8189291/webrev.00/ The fix to 8189272 will throw exceptions that were swallowed in those providers, which should not happen in proper environment. That fix makes test cases with security manager fail. The fix to 8189291 addresses it. Naoto [1] https://bugs.openjdk.java.net/browse/JDK-8189272 [2] https://bugs.openjdk.java.net/browse/JDK-8189291

2 5

RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()
by Kazunori Ogata 24 Oct '17

24 Oct '17

Hi all, Please review a change for JDK-8188858. Bug report: https://bugs.openjdk.java.net/browse/JDK-8188858 Webrev: http://cr.openjdk.java.net/~horii/8188858/webrev.00/ This change caches the result of latestUserDefinedLoader() when objects are deserialized, so the decerializer can avoid redundant stack walking to resolve classes of deserializing objects. This change improved maxjOPS of SPECjbb2015 by 6% on a POWER8 machine. Regards, Ogata

4 13

Re: RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()
by Kazunori Ogata 24 Oct '17

24 Oct '17

Hi Peter, Thank you for your review and summarizing the change. Regards, Ogata Peter Levart <peter.levart(a)gmail.com> wrote on 2017/10/24 14:11:01: > From: Peter Levart <peter.levart(a)gmail.com> > To: Kazunori Ogata <OGATAK(a)jp.ibm.com> > Cc: Alan Bateman <Alan.Bateman(a)oracle.com>, core-libs-dev(a)openjdk.java.net > Date: 2017/10/24 14:11 > Subject: Re: RFR: 8188858: Caching latestUserDefinedLoader() results in > ObjectInputStream.readObject() > > Hi, > > I think that what Ogata has in webrev.03 is correct and the reasoning > could be as follows: > > - each thread writes to field 'cachedLoader' only from its own set of > values that are distinct from the sets of values that may be written by > any other thread, except null value. > - each thread reads field 'cachedLoader' and can verfy that it has read a > value that belongs to the set of its own written values, or null value (in > other words, a thread can verify that it has read a value that was written > by self or null value). > - reads and writes of own set of non-null values always appear in program > order since they are performed by same thread > - a sequence of writes of own set of non-null values performed by some > thread begins after this thread 1st observes a null value read from the > field and ends before this thread finally writes null value back to the > field. The last write performed by some thread is therefore always a write > of null value. > > No matter how writes performed by a mixture of threads finally hit the > actual field, since each thread that writes to it issues its final write > of null value, the value that eventually ends in the field is null value. > > Does this make sense? > > Regards, Peter > On 10/23/17 22:47, Peter Levart wrote: > Hi Ogata, > > Sorry for late reply. You are absolutely right. Good catch! I missed this > scenario. The criteria for placing the mark (current Thread) on a > cachedLoader must include the check that validates previous value for > later restoration which uses the same criteria. Only in such case will one > thread never restore something that has not been placed by it. And this > guarantees that consumed OIS will never retain a reference to any > ClassLoader or Thread. Your webrev.03 looks good to me. > > Regards, Peter > On 10/17/17 13:48, Kazunori Ogata wrote: > Hi Peter, > > Thank you for your comments and the fix. It's a good idea to mark > cachedLoader with the Thread object. > > > I think we need to check the marking thread of cachedLoader before > updating it. Otherwise, there is a scenario that can leak a CachedLoader > object: > > //1. Thread-A enters readObject() and then call resolveClass() > outerCL-A <- null > cachedLoader <- Thread-A > cachedLoader <- CachedLoader-A > > //2. Thread-B enters readObject() and then call resolveClass() > outerCL-B <- CachedLoader-A > cachedLoader <- Thread-B > cachedLoader <- CachedLoader-B1 > > //3. Thread-B returns from readObject() > cachedLoader is unchanged because outerCL.thread == Thread-A > > //4. Thread-B enters readObject() again and then call resolveClass() > outerCL-B <- CachedLoader-B1 > cachedLoader <- Thread-B > cachedLoader <- CachedLoader-B2 > > //5. Thread-A returns from readObject() > cachedLoader <- null > > //6. Thread-B returns from readObject() > cachedLoader <- CachedLoader-B1 // Because outerCL-B.thread is Thread-B > > > By adding checking before updating the mark, Thread-B won't update > cachedLoader, or it only saves null when race occurs (and always restores > to null on exit). > > > Here is the updated webrev: > http://cr.openjdk.java.net/~horii/8188858/webrev.03/ > > I also made minor changes to reduce the number of invocation of the JNI > method Thread.currentThread(). > > > Regards, > Ogata > > > > From: Peter Levart <peter.levart(a)gmail.com> > To: Kazunori Ogata <OGATAK(a)jp.ibm.com>, Alan Bateman > <Alan.Bateman(a)oracle.com> > Cc: core-libs-dev(a)openjdk.java.net > Date: 2017/10/16 19:58 > Subject: Re: RFR: 8188858: Caching latestUserDefinedLoader() > results in ObjectInputStream.readObject() > > > > Hi Ogata, > > I found a problem in my last suggestion. See below... > > On 10/16/2017 11:36 AM, Peter Levart wrote: > On 10/16/2017 11:02 AM, Peter Levart wrote: > For example: > - let public readObject() / readUnshared() entry and exit points just > clear the cached loader (set it to null). > An alternative would be for entry point to save and clear the cached > loader while exit point would restore / clear it if it is from correct > thread / when the call was not nested. Like the following: > > public Object readObject() { > CachedLoader outerCL = cachedLoader; > cachedLoader = null; > try { > ... > } finally { > if (outerCL == null || outerCL.thread == > Thread.currentThread()) { > // restore/clear cached loader when nested/outer call ends > cachedLoader = outerCL; > } > } > } > > with resolveClass() fragment repeated here for comparison: > > CachedLoader cl = cachedLoader; > Thread curThread = Thread.currentThread(); > ClassLoader loader; > if (cl == null) { > loader = latestUserDefinedLoader(); > cachedLoader = new CachedLoader(loader, curThread); > } else if (cl.thread == curThread) { > loader = cl.loader; > } else { > // multi threaded use > loader = latestUserDefinedLoader(); > } > > // and then... > return Class.forName(name, false, loader); > > > There are all sorts of races possible when called concurrently from > multiple threads, but the worst consequence is that the loader is not > cached. I also think that even in the presence of races, the > cachedLoader is eventually cleared when all calls to OIS complete. I > couldn't think of a situation where such cached loader would remain > hanging off the completed OIS because of races. > > Well, there is one such situation but for a different reason. For > example, if an OIS subclass is constructed solely to override > resolveClass method to make it accessible to custom code (for example, > make it public and call super.resolveClass()) in order to provide a > utility for resolving classes with the default OIS semantics, but such > OIS instance is never used for deserialization itself > (readObject()/readUnshared() is never called). > > To solve this problem, resolveClass() logic, including lazy caching, > should be moved to a private method (resolveClass0()) with protected > resolveClass() treated like public readObject()/readUnshared() with > before/after treatment of cached loader around delegation to > resolveClass0(). All OIS internal uses of resolveClass() should then > be redirected to resolveClass0(). > Oops, this would not work for subclasses that override resolveClass() > with custom logic. Hm... > > The correct and optimal solution is a little bit more involved, I think. > Here's what I think should work (did not run any tests yet): > > https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eplevart_jdk10-2Ddev_8188858-5FOIS.latestUserDefinedLoader.caching_webrev. > 01_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=p- > FJcrbNvnCOLkbIdmQ2tigCrcpdU77tlI2EIdaEcJw&m=PbaGqOdJOR6jMQkXDVYmjn6832m7o0LU2bzwt2awUgQ&s=gKz_rwcTcGIw8JvmRqlg1- > OtjqFNXmIs4oQmIXlF3Wc&e= > > > > Regards, Peter > > > >

1 0

RFR (JDK10/JAXP) 8176891: Fix lint warnings in JAXP repo: serial
by Joe Wang 24 Oct '17

24 Oct '17

Hi, Please review a fix that cleans up [serial] warnings by adding the serialVersionUID. The following tests showed that the serialVersionUID for the classes in this patch have not changed from JDK 1.4 to JDK 9: for each cls in classes that are missing serialVersionUID for jdk from 1.4 to 9 run: $jdkversion/bin/serialver $jdkversion/jre/lib/rt.jar cls One exception is javax.xml.namespace.QName. Its serialVersionUID was different in the standalone JAXP 1.3 before it was integrated into JDK 1.5. Since JAXP 1.3 was EOLed in 2008 and the serialVersionUID has been consistent in the JDKs, it is now set with a static value from the JDK. The original workaround is discarded and the proprietary property (com.sun.xml.namespace.QName.useCompatibleSerialVersionUID) retired. Another difference is between JDK 1.5 and 1.6 for class com.sun.org.apache.xml.internal.utils.URI. Since the UID was changed from 1.5 to 1.6 and then consistent through JDK 9, the incompatibility was already absorbed in JDK 1.6. This patch therefore simply adopts the later. JBS: https://bugs.openjdk.java.net/browse/JDK-8176891 webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8176891/webrev/index.html Thanks, Joe P.S. Full test results: JDK14 Class javax.xml.datatype.DatatypeConfigurationException not found. JDK15 javax.xml.datatype.DatatypeConfigurationException: static final long serialVersionUID = -1699373159027047238L; JDK16 javax.xml.datatype.DatatypeConfigurationException: static final long serialVersionUID = -1699373159027047238L; JDK17 javax.xml.datatype.DatatypeConfigurationException: static final long serialVersionUID = -1699373159027047238L; JDK18 javax.xml.datatype.DatatypeConfigurationException: private static final long serialVersionUID = -1699373159027047238L; JDK19 javax.xml.datatype.DatatypeConfigurationException: private static final long serialVersionUID = -1699373159027047238L; JDK14 Class javax.xml.namespace.QName not found. JDK15 javax.xml.namespace.QName: static final long serialVersionUID = -9120448754896609940L; JDK16 javax.xml.namespace.QName: static final long serialVersionUID = -9120448754896609940L; JDK17 javax.xml.namespace.QName: static final long serialVersionUID = -9120448754896609940L; JDK18 javax.xml.namespace.QName: private static final long serialVersionUID = -9120448754896609940L; JDK19 javax.xml.namespace.QName: private static final long serialVersionUID = -9120448754896609940L; JDK14 javax.xml.parsers.ParserConfigurationException: static final long serialVersionUID = -3688849216575373917L; JDK15 javax.xml.parsers.ParserConfigurationException: static final long serialVersionUID = -3688849216575373917L; JDK16 javax.xml.parsers.ParserConfigurationException: static final long serialVersionUID = -3688849216575373917L; JDK17 javax.xml.parsers.ParserConfigurationException: static final long serialVersionUID = -3688849216575373917L; JDK18 javax.xml.parsers.ParserConfigurationException: private static final long serialVersionUID = -3688849216575373917L; JDK19 javax.xml.parsers.ParserConfigurationException: private static final long serialVersionUID = -3688849216575373917L; JDK14 Class javax.xml.stream.XMLStreamException not found. JDK15 Class javax.xml.stream.XMLStreamException not found. JDK16 javax.xml.stream.XMLStreamException: static final long serialVersionUID = 2018819321811497362L; JDK17 javax.xml.stream.XMLStreamException: static final long serialVersionUID = 2018819321811497362L; JDK18 javax.xml.stream.XMLStreamException: private static final long serialVersionUID = 2018819321811497362L; JDK19 javax.xml.stream.XMLStreamException: private static final long serialVersionUID = 2018819321811497362L; JDK14 org.w3c.dom.events.EventException: static final long serialVersionUID = 242753408332692061L; JDK15 org.w3c.dom.events.EventException: static final long serialVersionUID = 242753408332692061L; JDK16 org.w3c.dom.events.EventException: static final long serialVersionUID = 242753408332692061L; JDK17 org.w3c.dom.events.EventException: static final long serialVersionUID = 242753408332692061L; JDK18 org.w3c.dom.events.EventException: private static final long serialVersionUID = 242753408332692061L; JDK19 org.w3c.dom.events.EventException: private static final long serialVersionUID = 242753408332692061L; JDK14 Class org.w3c.dom.ls.LSException not found. JDK15 org.w3c.dom.ls.LSException: static final long serialVersionUID = 5371691160978884690L; JDK16 org.w3c.dom.ls.LSException: static final long serialVersionUID = 5371691160978884690L; JDK17 org.w3c.dom.ls.LSException: static final long serialVersionUID = 5371691160978884690L; JDK18 org.w3c.dom.ls.LSException: private static final long serialVersionUID = 5371691160978884690L; JDK19 org.w3c.dom.ls.LSException: private static final long serialVersionUID = 5371691160978884690L; JDK14 Class org.w3c.dom.ranges.RangeException not found. JDK15 org.w3c.dom.ranges.RangeException: static final long serialVersionUID = 2427563372446661889L; JDK16 org.w3c.dom.ranges.RangeException: static final long serialVersionUID = 2427563372446661889L; JDK17 org.w3c.dom.ranges.RangeException: static final long serialVersionUID = 2427563372446661889L; JDK18 org.w3c.dom.ranges.RangeException: private static final long serialVersionUID = 2427563372446661889L; JDK19 org.w3c.dom.ranges.RangeException: private static final long serialVersionUID = 2427563372446661889L; JDK14 Class com.sun.org.apache.xalan.internal.utils.ConfigurationError not found. JDK15 com.sun.org.apache.xalan.internal.utils.ConfigurationError: static final long serialVersionUID = 749136645488750664L; JDK16 com.sun.org.apache.xalan.internal.utils.ConfigurationError: static final long serialVersionUID = 749136645488750664L; JDK17 com.sun.org.apache.xalan.internal.utils.ConfigurationError: static final long serialVersionUID = 749136645488750664L; JDK18 com.sun.org.apache.xalan.internal.utils.ConfigurationError: private static final long serialVersionUID = 749136645488750664L; JDK19 com.sun.org.apache.xalan.internal.utils.ConfigurationError: private static final long serialVersionUID = 749136645488750664L; JDK14 Class com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError not found. JDK15 Class com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError not found. JDK16 Class com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError not found. JDK17 com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError: static final long serialVersionUID = -6690855975016554786L; JDK18 com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError: private static final long serialVersionUID = -6690855975016554786L; JDK19 com.sun.org.apache.xalan.internal.xsltc.compiler.util.InternalError: private static final long serialVersionUID = -6690855975016554786L; JDK14 Class com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError not found. JDK15 Class com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError not found. JDK16 Class com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError not found. JDK17 com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError: static final long serialVersionUID = 2802784919179095307L; JDK18 com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError: private static final long serialVersionUID = 2802784919179095307L; JDK19 com.sun.org.apache.xalan.internal.xsltc.runtime.InternalRuntimeError: private static final long serialVersionUID = 2802784919179095307L; JDK14 Class com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl not found. JDK15 Class com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl not found. JDK16 com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl: static final long serialVersionUID = 844792794952655204L; JDK17 com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl: static final long serialVersionUID = 844792794952655204L; JDK18 com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl: private static final long serialVersionUID = 844792794952655204L; JDK19 com.sun.org.apache.xerces.internal.jaxp.datatype.DurationDayTimeImpl: private static final long serialVersionUID = 844792794952655204L; JDK14 Class com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl not found. JDK15 Class com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl not found. JDK16 com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl: static final long serialVersionUID = -4430140662861507958L; JDK17 com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl: static final long serialVersionUID = -4430140662861507958L; JDK18 com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl: private static final long serialVersionUID = -4430140662861507958L; JDK19 com.sun.org.apache.xerces.internal.jaxp.datatype.DurationYearMonthImpl: private static final long serialVersionUID = -4430140662861507958L; JDK14 Class com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException not found. JDK15 com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException: static final long serialVersionUID = -3201986204982729962L; JDK16 com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException: static final long serialVersionUID = -3201986204982729962L; JDK17 com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException: static final long serialVersionUID = -3201986204982729962L; JDK18 com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException: private static final long serialVersionUID = -3201986204982729962L; JDK19 com.sun.org.apache.xerces.internal.jaxp.validation.WrappedSAXException: private static final long serialVersionUID = -3201986204982729962L; JDK14 Class com.sun.org.apache.xerces.internal.utils.ConfigurationError not found. JDK15 com.sun.org.apache.xerces.internal.utils.ConfigurationError: static final long serialVersionUID = 8095902236393167968L; JDK16 com.sun.org.apache.xerces.internal.utils.ConfigurationError: static final long serialVersionUID = 8095902236393167968L; JDK17 com.sun.org.apache.xerces.internal.utils.ConfigurationError: static final long serialVersionUID = 8095902236393167968L; JDK18 com.sun.org.apache.xerces.internal.utils.ConfigurationError: private static final long serialVersionUID = 8095902236393167968L; JDK19 com.sun.org.apache.xerces.internal.utils.ConfigurationError: private static final long serialVersionUID = 8095902236393167968L; JDK14 Class com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException not found. JDK15 Class com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException not found. JDK16 com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException: static final long serialVersionUID = 4651455286983598951L; JDK17 com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException: static final long serialVersionUID = 4651455286983598951L; JDK18 com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException: private static final long serialVersionUID = 4651455286983598951L; JDK19 com.sun.org.apache.xml.internal.serializer.utils.URI.MalformedURIException: private static final long serialVersionUID = 4651455286983598951L; JDK14 Class com.sun.org.apache.xml.internal.utils.URI not found. JDK15 com.sun.org.apache.xml.internal.utils.URI: static final long serialVersionUID = -4864335621934089776L; JDK16 com.sun.org.apache.xml.internal.utils.URI: static final long serialVersionUID = 7096266377907081897L; JDK17 com.sun.org.apache.xml.internal.utils.URI: static final long serialVersionUID = 7096266377907081897L; JDK18 com.sun.org.apache.xml.internal.utils.URI: private static final long serialVersionUID = 7096266377907081897L; JDK19 com.sun.org.apache.xml.internal.utils.URI: private static final long serialVersionUID = 7096266377907081897L; JDK14 Class com.sun.org.apache.xml.internal.utils.URI.MalformedURIException not found. JDK15 com.sun.org.apache.xml.internal.utils.URI.MalformedURIException: static final long serialVersionUID = -8498313684991136829L; JDK16 com.sun.org.apache.xml.internal.utils.URI.MalformedURIException: static final long serialVersionUID = -8498313684991136829L; JDK17 com.sun.org.apache.xml.internal.utils.URI.MalformedURIException: static final long serialVersionUID = -8498313684991136829L; JDK18 com.sun.org.apache.xml.internal.utils.URI.MalformedURIException: private static final long serialVersionUID = -8498313684991136829L; JDK19 com.sun.org.apache.xml.internal.utils.URI.MalformedURIException: private static final long serialVersionUID = -8498313684991136829L;

2 2

Re: java 9 AKST timezone parsing
by Naoto Sato 23 Oct '17

23 Oct '17

(replying to appropriate aliases, instead of generic jdk9-dev alias) Hi Clément, The locale data, where those time zone names are derived from, have been switched to use Unicode Consortium's CLDR, instead of the ones that are previously used prior to JDK9. So there will be some differences you may encounter. However it seems not right to parse "AKST" to SystemV time zone. I'd appreciate it if you file a JIRA issue for this. In the mean time, you can revert to the JDK8 behavior by setting the system property "-Djava.locale.providers=COMPAT" to the command line. HTH, Naoto On 10/10/17 7:37 PM, Clément Guillaume wrote: > Hello, > > When parsing a date time string that contains a time zone like AKST, AKDT, > HST or AST with a DateTimeFormatter built from a pattern containing 'z', > java 9 returns the SystemV variant of those timezone, which then behave > differently as the "modern" ones. Looks like it's also an issue with long > time zone ("Alaska Standard Time") > > From my digging I noticed that the PrefixTree generated > by ZoneTextPrinterParser.getTree is different in java 8 and java 9, and > this may be caused by a different order in the content returned > by TimeZoneNameUtility.getZoneStrings(Locale.getDefault()) > > Is this an expected behavior of java 9? (other american time zones are > parsed to the modern version: PST -> America/Los_Angeles) > > I tested it with java 9 build 9+181 and java 8 build 1.8.0_131-b11 (both > linux 64 with en_US as local) on this code: > > import java.time.ZoneOffset; > import java.time.format.DateTimeFormatter; > import java.time.temporal.TemporalAccessor; > > public class Main{ > > public static void main(String[] args){ > DateTimeFormatter timezoneFormatter = DateTimeFormatter.ofPattern("z"); > TemporalAccessor temporalAccessor = timezoneFormatter.parse("AKST"); > System.out.println(temporalAccessor); > temporalAccessor = timezoneFormatter.parse("AKDT"); > System.out.println(temporalAccessor); > temporalAccessor = timezoneFormatter.parse("HST"); > System.out.println(temporalAccessor); > temporalAccessor = timezoneFormatter.parse("AST"); > System.out.println(temporalAccessor); > > DateTimeFormatter isoFormatter = > DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mmX").withZone(ZoneOffset.UTC); > temporalAccessor = > DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSz").parse("2017-09-13T06:30:33.123AKST"); > System.out.println(temporalAccessor); > System.out.println(isoFormatter.format(temporalAccessor)); > temporalAccessor = > DateTimeFormatter.ofPattern("yyyy-MM-dd'T'HH:mm:ss.SSSVV").parse("2017-09-13T06:30:33.123America/Anchorage"); > System.out.println(temporalAccessor); > System.out.println(isoFormatter.format(temporalAccessor)); > } > > } >

2 4

AVL tree implemented in the style of TreeMap for better performance
by David McManamon 23 Oct '17

23 Oct '17

If the BBST performance numbers from Ben Pfaff's c language research in 2004 https://benpfaff.org/papers/libavl.pdf are correct then it seems the red-black tree implementations that are so popular in the JDK might be worth another look. However, when I surveyed the AVL implementations in the Java world I didn't find the variety I was looking for - specifically an implementation similar to that of the red-black TreeMap (parent pointers, no recursion), so I wrote insert & delete in TreeMapAVL here: https://github.com/dmcmanam/bbst-showdown Although an old topic, it may be worth another look in Java since AVL trees do much better in some circumstances. Next week I'll write a WAVL implementation and expand the performance testing comparison which so far looks like this: Results for inserting 262143 random integers (height 18 for a complete BST) - Mean insertion time: 171ms and 169ms, runs to converge:2. AVL tree of size: 262126, height: 21, rotations 183194 Mean insertion time: 165ms and 169ms, runs to converge:2. Red-black tree of size: 262126, height: 22, rotations 152622 Mean insertion time: 170ms and 167ms, runs to converge:1. BST of size: 262126, height: 46, rotations 0 Time to copy a red-black tree (sorted insertion via recursion): 44ms. Red-black tree of size: 262126, height: 18, rotations 0 Results for inserting integer clusters in sequences of 12 and total size: 262143 - Mean insertion time: 63ms and 62ms, runs to converge:3. AVL tree of size: 262125, height: 21, rotations 325176 Mean insertion time: 70ms and 72ms, runs to converge:2. Red-black tree of size: 262125, height: 24, rotations 320990 --David

4 3

Decreased latency performance with Stack Walker API compared to sun.misc.JavaLangAccess
by Rafael Winterhalter 20 Oct '17

20 Oct '17

Hello, a typical patern when reading the stack of the current thread in tooling like performance monitoring used to imply the creation of an instance of Throwable and to process this instance's attached stack in another thread. The performance cost is shared about 10/90 for creating a new throwable compared to reading its frames, so this is really a worthy optimization. It is also common to use the JavaLangAccess API which offers selective access of single frames. This API does no longer exist as it was superseeded by the Stack Walker API which is of course much safer and even a more performant alternative when looking at the total performance. However, using a stack walker, it is no longer possible to move the stack processing out of the user thread but it must be done at the moment the snapshot of the stack is taken. It turns out that this increases latency dramatically when processing stacks compared to the asyncronous alternative. In a quick benchmark, it seems like walking 35 frames of a 100 frames stack allows me 70k operations per second whereas creating a new throwable yields about 200k operations per second. Also, within a less isolated test, I can infer this additional overhead from the actual latency numbers of a web service when using the stack walker API to extract the top 35 frames compared to the "old" solution using JavaLangAccess. For this reason, it seems to be the best solution to avoid the stack walker when aiming for latency at the moment if the stack is not required immediately and if access resources are available in other threads. I would therefore like to propose to extend the stack walker API to allow walking the stack of an existing throwable to allow for similar performance as with JavaLangAccess. I understand that the VM must do more work altogether. When receving the full stack from a throwable, this takes about three times as long. In practice, for a product I am involved in, this casues a noticable overhead when running a Java 9 VM compared to Java 8. Alternatively, it would of course even be better if one could take a snapshot of only the top x frames to walk on this object rather then a throwable. I have added my benchmarks (snapshot for the current user thread operation, complete for the entire processing) into this Gist: https://gist.github.com/raphw/96e7c81d7c719cf7991b361bb7266c70 Thank you for any feedback on my finding! Best regards, Rafael

4 6

RFR: 8189266: (ann) Optimize AnnotationInvocationHandler.invoke
by Claes Redestad 20 Oct '17

20 Oct '17

Hi, please review this patch, contributed by Christoph Dreis, to speed up AnnotationInvocationHandler.invoke, primarily by avoiding cloning the Method parameterTypes array unnecessarily. Webrev: http://cr.openjdk.java.net/~redestad/8189266/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8189266 Thanks! /Claes

2 1

RE: RFR: 8029019: (ann) Optimize annotation handling in core reflection
by Christoph Dreis 20 Oct '17

20 Oct '17

Hi Claes, with JDK 9 being out - congrats to everyone - I'll try my chance to raise issue https://bugs.openjdk.java.net/browse/JDK-8029019 again. A little recap: In November 2016 I reported the unnecessary allocation of Method.getParameterTypes() in AnnotationInvocationHandler.invoke() and a patch that would fix this. As it turned out, this and other improvements were already suggested by Peter in above mentioned ticket. Because it was reasonably late in February 2017 to cover the complete story for 9, I suggested to only include the low-risk patch, which was understandably also too late. So I'm trying again to bring this into the JDK - I hope you don't mind me being so persistent on this one. For completeness find the initial patch attached below for the initial problem I was trying to solve. Cheers, Christoph ================================ Reduce allocations in sun.reflect.annotation.AnnotationInvocationHandler.invoke() diff -r ba70dcd8de76 -r 86bbc5442c1d src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java --- a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java Fri Nov 11 13:11:27 2016 +0000 +++ b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java Mon Nov 14 19:04:33 2016 +0100 @@ -57,13 +57,13 @@ public Object invoke(Object proxy, Method method, Object[] args) { String member = method.getName(); - Class<?>[] paramTypes = method.getParameterTypes(); + int parameterCount = method.getParameterCount(); // Handle Object and Annotation methods - if (member.equals("equals") && paramTypes.length == 1 && - paramTypes[0] == Object.class) + if (parameterCount == 1 && member.equals("equals") && + method.getParameterTypes()[0] == Object.class) return equalsImpl(proxy, args[0]); - if (paramTypes.length != 0) + if (parameterCount != 0) throw new AssertionError("Too many parameters for an annotation method"); switch(member) { > -----Original Message----- > From: Christoph Dreis [mailto:christoph.dreis@freenet.de] > Sent: Friday, February 10, 2017 11:22 AM > To: 'Claes Redestad' <claes.redestad(a)oracle.com>; 'Peter Levart' > <peter.levart(a)gmail.com>; 'Core-Libs-Dev' <core-libs- > dev(a)openjdk.java.net> > Subject: RE: RFR: 8029019: (ann) Optimize annotation handling in core > reflection > > Hi Claes, > > > > > I think this all seems reasonable, but subtle behavior changes like > > this needs more scrutiny than I can provide. I've discussed this > > offline with Joe and sadly concluded it's probably too much, too late > > for 9 at this point. > > > > Hope you don't mind re-targetting this to JDK 10. > > Do you mean the error handling change or the ticket in general? In case of > the latter, may I start a proposal? > > As the original issue for me was to reduce the allocations coming from > AnnotationInvocationHandler.invoke() caused by > Method.getParameterTypes(), what about creating a sub-ticket of 8029019 > and just take care of the low-risk change below? That would eventually allow > a backbort to JDK 8 as well, although I'm not quite sure yet how the backport > process is working. > > What do you think? > > Cheers, > Christoph > > ========= PATCH =========== > diff --git > a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocation > Handler.java > b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocation > Handler.java > --- > a/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocation > Handler.java > +++ b/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvoc > +++ ationHandler.java > @@ -57,13 +57,13 @@ > > public Object invoke(Object proxy, Method method, Object[] args) { > String member = method.getName(); > - Class<?>[] paramTypes = method.getParameterTypes(); > + int parameterCount = method.getParameterCount(); > > // Handle Object and Annotation methods > - if (member.equals("equals") && paramTypes.length == 1 && > - paramTypes[0] == Object.class) > + if (parameterCount == 1 && member.equals("equals") && > + method.getParameterTypes()[0] == Object.class) > return equalsImpl(proxy, args[0]); > - if (paramTypes.length != 0) > + if (parameterCount != 0) > throw new AssertionError("Too many parameters for an annotation > method"); > > switch(member) {

4 8