June 2015 - core-libs-dev

[9] Review request for 8085979: Make some DTLS feature functional tests work also for TLS protocol
by Konstantin Shefov 09 Jun '15

09 Jun '15

Hello, Please review distribution of some DTLS feature tests to TLS protocol. Some DTLS tests may also be used to test the same functionality in TLS protocol and its versions. It is test only improvement. bug: https://bugs.openjdk.java.net/browse/JDK-8085979 webrev: http://cr.openjdk.java.net/~kshefov/8085979/webrev.00/ Thanks -Konstantin

2 5

Re: [8u-dev] Review request : JDK-8062904: TEST_BUG: Tests java/lang/invoke/LFCaching fail when run with -Xcomp option
by Vladimir Ivanov 09 Jun '15

09 Jun '15

Konstantin, thanks for figuring that out. I had a private discussion with Igor and we agreed that catching "expected" exceptions (NSME and VME) is more robust than hand tuning test limits to particular configurations. The idea is to gracefully finish the test once code cache is full, instead of trying to avoid code cache overflow at all costs in all test configurations. In order to lower the risk of missing product issues, exception messages can be checked as well: NSME: "no such method: java.lang.invoke.MethodHandle.linkTo.*" VME: "out of space in CodeCache for adapters" Though checking error messages is fragile as well, IMO in lesser extent than hardcoded limits. Do you have any objections to such approach? As a strawman proposal, you can introduce a helper in test library: ignoreException(Runnable test, Function<Throwable, Boolean> filter) Also, please, find and adjust other tests where hard coded limits are set. Best regards, Vladimir Ivanov On 6/8/15 7:22 PM, Konstantin Shefov wrote: > Vladimir, > > You were right when you said that problem is not in JDK 8u. > I have examined the test code once more and found the following. > > In JDK 9 because of the Segmented code cache feature I have modified the > tests to support it, and in JDK 9 the number of iterations is limited by > the size of "NonProfiledCodeHeapSize", while in JDK 8u the number of > iterations is limited by "ReservedCodeCacheSize". > > But "ReservedCodeCacheSize" is usually about 256 MB, while > "NonProfiledCodeHeapSize" is about 128 MB. So in JDK 8u there are twice > more iterations happen when in JDK 9. > > If we run JDK 8u tests against JDK 9 with the same "-Dseed", we will > have VirtualMachineError on JDK 9. > > So there is NO product issue. > > In the file "test/java/lang/invoke/LFCaching/LambdaFormTestCase.java" > there is a constant defined called "ITERATIONS_TO_CODE_CACHE_SIZE_RATIO". > This constant has been measured with respect to -Xmixed mode only. > > So my suggestion to fix this test is to define one more constant for > "-Xcomp" mode and use it in "-Xcomp" mode. > > -Konstantin > > On 06/05/2015 09:04 PM, Vladimir Ivanov wrote: >> Konstantin, >> >>>> I'd like to get an answer to my previous question: >>>> "How reliable the test is if it ignores NoSuchMethodException & >>>> VirtualMachineError? Are there other manifestations of the problem?" >>>> >>>> Most notably, have you seen VM crashes w/ -Xcomp running that test? >>> I have seen no crashes with -Xcomp in our tests results base, only >>> NoSuchMethodException and VirtualMachineError. >> Good. Thanks for the info. >> >>> This failure does not occur with JDK 9 on -Xcomp, I used the same random >>> seeds (-Dseed), and the problem exists only with JDK 8u, not JDK 9. >>> >>> Because there is no failure with JDK 9 I can suppose there could be a >>> product issue in JDK 8u. >> That's strange. There should be no difference in MethodHandle stub >> management between 8u & 9 now (once allocated they stay forever). 9 >> has segmented code cache feature and it can lead to observable >> differences in behavior. >> >> How many iterations does the test perform on 8u & 9? What if you >> increase the number? Also, I'd suggest you to monitor code cache usage >> during the run and when the test finishes. >> >> Best regards, >> Vladimir Ivanov >

2 1

RFR 8071597 Add Stream dropWhile and takeWhile operations
by Paul Sandoz 09 Jun '15

09 Jun '15

Hi, Please review this webrev that adds take/dropWhile operations to streams: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8071597-take-drop-while/webrev/ I opted to weight the documentation of the operations towards ordered streams in the first paragraph. That is what makes most sense in terms of usage and what most people will read. Thus i refer to the "longest prefix" in the first paragraph then define what that means in subsequent paragraphs for ordered and unordered streams: 482 /** 483 * Returns a stream consisting of the longest prefix of elements taken from 484 * this stream that match the given predicate. 485 * 486 * If this stream is ordered then the prefix is a contiguous sequence of 487 * elements of this stream. All elements of the sequence match the given 488 * predicate, the first element of the sequence is the first element 489 * (if any) of this stream, and the element (if any) immediately following 490 * the last element of the sequence does not match the given predicate. 491 * 492 * If this stream is unordered then the prefix is a subset of elements of 493 * this stream. All elements (if any) of the subset match the given 494 * predicate. In this case the behavior of this operation is 495 * nondeterministic; it is free to select any valid subset as the prefix. 496 * 497 * This is a <a href="package-summary.html#StreamOps">short-circuiting 498 * stateful intermediate operation</a>. 499 * ... 528 default Stream<T> takeWhile(Predicate<? super T> predicate) { 537 /** 538 * Returns a stream consisting of the remaining elements of this stream 539 * after dropping the longest prefix of elements that match the given 540 * predicate. 541 * 542 * If this stream is ordered then the prefix is a contiguous sequence of 543 * elements of this stream. All elements of the sequence match the given 544 * predicate, the first element of the sequence is the first element 545 * (if any) of this stream, and the element (if any) immediately following 546 * the last element of the sequence does not match the given predicate. 547 * 548 * If this stream is unordered then the prefix is a subset of elements of 549 * this stream. All elements (if any) of the subset match the given 550 * predicate. In this case the behavior of this operation is 551 * nondeterministic; it is free to select any valid subset as the prefix. 552 * ... 584 default Stream<T> dropWhile(Predicate<? super T> predicate) { After this has been reviewed i will follow up with a further issue regarding the specification of takeWhile, stateful predicates and cancellation. I avoided such specification here as it's likely to rathole :-) Basically the takeWhile operation is implemented such that one can do: long t = System.currentTimeMillis(); List<BigInteger> pps = Stream .generate(() -> BigInteger.probablePrime(1024, ThreadLocalRandom.current())) .parallel() .takeWhile(e -> (System.currentTimeMillis() - t) < TimeUnit.SECONDS.toMillis(5)) .collect(toList()); Paul.

6 20

JDK 9 RFR of JDK-8086029: Fix doclint reference warnings in org.omg.CORBA
by joe darcy 09 Jun '15

09 Jun '15

Hello, As an addendum to the fix-the-warnings JEP, please review this change which fixes some bad @throws references and the like over in corba: 8086029: Fix doclint reference warnings in org.omg.CORBA http://cr.openjdk.java.net/~darcy/8086029.0/ Patch below. Thanks, -Joe --- old/src/java.corba/share/classes/org/omg/CORBA/DynAny.java 2015-06-08 18:21:46.550021735 -0700 +++ new/src/java.corba/share/classes/org/omg/CORBA/DynAny.java 2015-06-08 18:21:46.478021732 -0700 @@ -52,8 +52,8 @@ * * @param dyn_any the <code>DynAny</code> object whose contents * are assigned to this <code>DynAny</code>. - * @throws Invalid if the source <code>DynAny</code> is - * invalid + * @throws org.omg.CORBA.DynAnyPackage.Invalid if the source + * <code>DynAny</code> is invalid */ public void assign(org.omg.CORBA.DynAny dyn_any) throws org.omg.CORBA.DynAnyPackage.Invalid; @@ -63,8 +63,8 @@ * object. * * @param value the <code>Any</code> object. - * @throws Invalid if the source <code>Any</code> object is - * empty or bad + * @throws org.omg.CORBA.DynAnyPackage.Invalid if the source + * <code>Any</code> object is empty or bad */ public void from_any(org.omg.CORBA.Any value) throws org.omg.CORBA.DynAnyPackage.Invalid; @@ -74,9 +74,9 @@ * object. * * @return the <code>Any</code> object. - * @throws Invalid if this <code>DynAny</code> is empty or - * bad. - * created or does not contain a meaningful value + * @throws org.omg.CORBA.DynAnyPackage.Invalid if this + * <code>DynAny</code> is empty or bad. created or does not + * contain a meaningful value */ public org.omg.CORBA.Any to_any() throws org.omg.CORBA.DynAnyPackage.Invalid; --- old/src/java.corba/share/classes/org/omg/CORBA/DynArray.java 2015-06-08 18:21:46.866021744 -0700 +++ new/src/java.corba/share/classes/org/omg/CORBA/DynArray.java 2015-06-08 18:21:46.798021742 -0700 @@ -38,8 +38,8 @@ * Returns the value of all the elements of this array. * * @return the array of <code>Any</code> objects that is the value - * for this <code>DynArray</code> object - * @see #set_elements + * for this <code>DynArray</code> object + * @see #set_elements */ public org.omg.CORBA.Any[] get_elements(); @@ -48,8 +48,9 @@ * <code>DynArray</code> object to the given array. * * @param value the array of <code>Any</code> objects - * @exception InvalidSeq if the sequence is bad - * @see #get_elements + * @exception org.omg.CORBA.DynAnyPackage.InvalidSeq if the + * sequence is bad + * @see #get_elements */ public void set_elements(org.omg.CORBA.Any[] value) throws org.omg.CORBA.DynAnyPackage.InvalidSeq; --- old/src/java.corba/share/classes/org/omg/CORBA/DynSequence.java 2015-06-08 18:21:47.154021753 -0700 +++ new/src/java.corba/share/classes/org/omg/CORBA/DynSequence.java 2015-06-08 18:21:47.082021751 -0700 @@ -65,8 +65,9 @@ * array. * * @param value the array of <code>Any</code> objects to be set - * @exception InvalidSeq if the array of values is bad - * @see #get_elements + * @exception org.omg.CORBA.DynAnyPackage.InvalidSeq if the array + * of values is bad + * @see #get_elements */ public void set_elements(org.omg.CORBA.Any[] value) throws org.omg.CORBA.DynAnyPackage.InvalidSeq; --- old/src/java.corba/share/classes/org/omg/CORBA/ServerRequest.java 2015-06-08 18:21:47.450021762 -0700 +++ new/src/java.corba/share/classes/org/omg/CORBA/ServerRequest.java 2015-06-08 18:21:47.374021759 -0700 @@ -248,7 +248,7 @@ * contain an exception will result in a BAD_PARAM system exception. Passing * in an unlisted user exception will result in either the DIR receiving a * BAD_PARAM system exception or in the client receiving an - * UNKNOWN_EXCEPTION system exception. + * UNKNOWN system exception. * * @param any the <code>Any</code> object containing the exception * @deprecated use set_exception() @@ -272,13 +272,13 @@ * will cause a BAD_PARAM system exception to be thrown. Passing * in an unlisted user exception will result in either the DIR receiving a * BAD_PARAM system exception or in the client receiving an - * UNKNOWN_EXCEPTION system exception. + * UNKNOWN system exception. * * @param any the <code>Any</code> object containing the exception * @exception BAD_PARAM if the given <code>Any</code> object does not * contain an exception or the exception is an * unlisted user exception - * @exception UNKNOWN_EXCEPTION if the given exception is an unlisted + * @exception UNKNOWN if the given exception is an unlisted * user exception and the DIR did not * receive a BAD_PARAM exception * @see <a href="package-summary.html#unimpl"><code>CORBA</code>

3 2

JDK 9 RFR of JDK-8075551: Add tiered testing definitions to the jaxp repo
by joe darcy 09 Jun '15

09 Jun '15

Hello, Please review these changes to regularize the jaxp regression testing infrastructure with the JDK tiered testing policy. [1] JDK-8075551: Add tiered testing definitions to the jaxp repo http://cr.openjdk.java.net/~darcy/8075551.0/ In brief, testing tiers are defined (with an empty tier 1 for jaxp) and an empty problem list is added. When analogous changes are made in all the repositories, it will be possible to use a jtreg command like jtreg -exclude:ProblemList.txt [... other options...] :tier$N for any repo. Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html

4 4

RFR: 7130985: Four helper classes missing in Sun JDK
by Rob McKenna 08 Jun '15

08 Jun '15

Meant to get this sorted a while back. There was a thread on this last year ( http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-July/027779.html ) A test has been added since then: http://cr.openjdk.java.net/~robm/7130985/webrev.corba/ http://cr.openjdk.java.net/~robm/7130985/webrev.j2se/ -Rob

3 3

RFR [9] 8081517: minor cleanup for docs
by alexander stepanov 08 Jun '15

08 Jun '15

Hello, Could you please review the fix http://cr.openjdk.java.net/~avstepan/8081517/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8081517 Just some cleanup for docs. Thanks, Alexander

3 9

Re: RFR(M): JDK-8059036 : Implement Diagnostic Commands for heap and finalizerinfo
by Staffan Larsen 08 Jun '15

08 Jun '15

Dmitry, I think this should be reviewed on hotspot-gc and core-libs-dev as well considering the changes to Finalizer. I’m a little worried about the potentially very large String that is returned from printFinalizationQueue(). A possible different approach would be to write printFinalizationQueue() in C++ inside Hotspot. That would allow for outputting one line at a time. The output would still be saved in memory (since the stream is buffered), but at least the data is only saved once in memory, then. It would make the code a bit harder to write, so its a question of how scared we are of running out of memory. I see you are traversing the ‘unfinalized’ list in Finalizer, whereas the old SA code for ‘-finalizerinfo' traverses the ‘queue’ list. I am not sure of the difference, perhaps someone from the GC team can help out? For the output, it would be a nice touch to sort it on the number of references for each type. Perhaps outputting it more like a table (see the old code again) would also make it easier to digest. In diagnosticCommand.hpp, the new commands should override permission() and limit access: static const JavaPermission permission() { JavaPermission p = {"java.lang.management.ManagementPermission", "monitor", NULL}; return p; } The two tests don’t validate the output in any way. Would it be possible to add validation? Perhaps hard to make sure an object is on the finalizer queue… Hmm. Thanks, /Staffan > On 5 maj 2015, at 12:01, Dmitry Samersoff <dmitry.samersoff(a)oracle.com> wrote: > > Everyone, > > Please review the fix: > > http://cr.openjdk.java.net/~dsamersoff/JDK-8059036/webrev.01/ > > heap dcmd outputs the same information as SIGBREAK > > finalizerinfo dcmd outputs a list of all classes in finalization queue > with count > > -Dmitry > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources.

7 59

Another take on Finalization
by Jonathan Payne 08 Jun '15

08 Jun '15

Hi. I have had an interest in the topic of finalization ever since it caused me to abandon the G1 collector 3 or 4 years ago. I’ve recently implemented a fix for my interpretation of the problem, which might be very different from the discussion currently ongoing in the thread entitled "JEP 132: More-prompt finalization”. My problem was that finalization was not being run at all with the G1 collector. Not at all. That would have been fine with me because none of the existing objects in the Finalizer queue actually needed the service anymore: the files, sockets, streams, etc. had all been properly closed by my application, otherwise the server would have long since failed completely. However, those objects started to accumulate in the VM and eventually (8 hours later) brought the server down. Which brings me to a few points: Finalization as conceived in the early JDKs was a bad idea. To make matters worse, the way we then made use of it in those early days was A REALLY REALLY bad idea. None of this mattered in those days because the GC ran often and quickly and finalization occurred during every GC cycle. There may be situations where finalization as a feature actually matters, but in the intervening years the JDK has added new technologies that provide a way to accomplish finalization on your own, in your own code. A few helper classes and it might even be easy when it’s necessary, which is hopefully almost never. Many of the uses of finalize() in the JDK today are bad and should be deleted. My fix, BTW, was to use a back door (that I added to SharedSecrets) in all the JDK classes that had a finalize() method, so that when a resource is properly closed, by calling the close() method for example, the back door would remove the Finalizer for the specified object from the linked list of Finalizer objects, thus removing it from the finalization equation altogether. I implemented this, and then the various tests of creating a huge number of objects with a finalize() method ran quickly and flawlessly with no horrific GCs or even a growing memory pool. The main problem with my solution was that there was this nasty SharedSecrets back door, so it has been rejected and probably rightly so. However, it proved a point. But now I am wondering why the actual right thing to do is not simply this: Remove the finalize() method from all the worst offenders in the JDK. I cannot remember all the places I patched when I implemented my fix, but the majority of them were pieces of code that absolutely had a close() method. If you don’t close objects when you’re done with them, your program PROBABLY SHOULD BE BROKEN. But even if you do not accept that, for all practical purposes, the program IS broken today because finalization is absolutely NOT run in a timely enough fashion. BTW - I never understood why CMS and other GC’s had absolutely no problem running finalization in a very timely fashion while the G1 collector just never seemed to get around to it. My interpretation of that fact has always led me to believe that it’s not a throughput issue with the finalization thread (not in real world examples, anyway) but rather a GC implementation that didn’t feel the need to be thorough enough to make sure something is ready to be finalized. I mean, when the G1 collector was forced to run a full collection (a death sentence on a 15Gb heap but it did occur) all the finalizable objects were found AND finalized immediately, all 15 or 20 million of them. So in summary: (1) The problem with finalization is that people use it. And more importantly, that the JDK is filled with inappropriate uses of it. (2) The main solution is probably just to delete the inappropriate uses in the JDK. But if that’s not OK, then some sort of patch like what I did which allows the JDK classes to unregister the Finalizer’s when they are no longer needed, i.e., when the object knows that it has cleaned itself up. I am curious to hear your thoughts. JP

4 3

Review request for JDK-8080906 & JDK-8080908: Develop tests for JEP 255 Xerces Updates
by Frank Yuan 05 Jun '15

05 Jun '15

Hi Joe and all I have been working on the test task of JEP 255 Xerces Updates. Here I would invite you to review the changes for 2 bugs of this task: 1. JDK-8080906 Develop test for Xerces Update: DOM L3 Serializer To verify default LSSerializer is Xalan dom 3 serializer 2. JDK-8080908 Develop test for Xerces Update: XPointer To verify Xerces revision 415823: XERCESJ-1134. It should have been fixed in JDK-6794483, however, the test Bug6794483Test.java need to be revised to really cover this bug. I also added module dependencies for exported API in this path, it's recommended for Jigsaw change, refer to https://wiki.se.oracle.com/display/JPG/@modules+in+JTReg+tests The webrev is at http://cr.openjdk.java.net/~fyuan/8080906_8080908/webrev.00/, your comment will be appreciated. Best Regards Frank

3 2