January 2018 - core-libs-dev

Draft JEP: Enhanced pseudo-random number generators
by Guy Steele 23 May '19

23 May '19

Please check out a new draft JEP https://bugs.openjdk.java.net/browse/JDK-8193209 <https://bugs.openjdk.java.net/browse/JDK-8193209> that proposes new interface types and implementations for pseudo-random number generators. —Guy

2 3

The new optimized version of Dual-Pivot Quicksort
by Vladimir Yaroslavskiy 20 Nov '18

20 Nov '18

Hi team, In Sept 2009 Josh Bloch, Jon Bentley and I introduced new sorting algorithm, Dual-Pivot Quicksort, for primitives in JDK 7 and later I suggested several improvements of Dual-Pivot Quicksort, which were integrated into JDK 8. Now I have more optimized and faster version of Dual-Pivot Quicksort. I have been working on it for the last 5 years. Please, find the summary of changes below and sources / diff at webrev [1]. All tests and benchmarking were run on the most recent build of JDK 10, jdk-10-ea+39. The new version shows the better performance on different inputs and guarantees n*log(n) on any data. The new implementation of Dual-Pivot Quicksort is 'all-in-one' version: it contains one code for both parallel and sequential sorting algorithms. Suggested version is 10-20% faster on random data, 1.5-4 times faster on nearly structured arrays, 1.5-2 times faster on period inputs. Parallel Dual-Pivot Quicksort is 1.5-3 times faster than current algorithm based on merge sort. Benchmarking on the test suite, suggested by Jon Bentley, shows the boost of performance in 1.4 times. This test suite contains several types of inputs, such as random data, nearly structured arrays, data with period and so on. Also there are several modifications of inputs and parameters which are used in data building. We run sorting on all combinations to compare two algorithms. Please let me know if you have any questions / comments. Summary of changes: DualPivotQuicksort class ------------------------ * Pivots are chosen with another step, the 1-st and 5-th candidates are taken as pivots instead of 2-nd and 4-th. * Splitting into parts is related to the golden ratio * Pivot candidates are sorted by combination of 5-element network sorting + insertion sort * New backwards partitioning is simpler and more efficient * Quicksort tuning parameters were updated * Merging sort is invoked on each iteration from Quicksort * Additional steps for float/double were fully rewritten * Heap sort is invoked on the leftmost part * Heap sort is used as a guard against quadratic time * Parallel sorting is based on Dual-Pivot Quicksort instead of merge sort SortingAlgorithms class ----------------------- * Merging sort and pair insertion sort were moved from DualPivotQuicksort class * Pair insertion sort was simplified and optimized * New nano insertion sort was introduced for tiny arrays * Merging sort was fully rewritten * Optimized merging partitioning is used * Merging parameters were updated * Merging of runs was fully rewritten * Fast version of heap sort was introduced * Parallel merging sort was also provided Sorting / ParallelSorting classes --------------------------------- * New test cases were added * Sources of these classes were unified Arrays class ------------ * Calls of Dual-Pivot Quicksort were updated * Parallel sorting of primitives was switched to parallel Dual-Pivot Quicksort * Javadoc was modified ArraysParallelSortHelpers class ------------------------------- * Old implementation of parallel sorting for primitives was removed * Javadoc was updated Thank you, Vladimir -------------------------------------------------------------------- [1] http://cr.openjdk.java.net/~alanb/DualPivotSortUpdate/webrev.01/ --------------------------------------------------------------------

5 18

Patch fixing JDK-8176553
by Jan Kalina 04 Apr '18

04 Apr '18

Hi, I has prepared trivial patch for bug JDK-8176553, which I has reported. I will welcome if it could be merged into JDK. (The bug is present in JDK9 and JDK8 too.) I am covered by Red Hat OCA. The patch is attached, bug reproducer is already in JIRA: https://bugs.openjdk.java.net/browse/JDK-8176553 Thanks, Jan Kalina

3 3

[10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()
by Claes Redestad 26 Mar '18

26 Mar '18

Hi, please help review this patch to consolidate the number of implementation classes returned by the static collection factories: http://cr.openjdk.java.net/~redestad/8193128/open.00/ I set out to explore options for addressing small inefficiencies we've been running into, the latest after replacing use of @Stable arrays in java.lang.invoke with List.of() (JDK-8184777): - List.indexOf deferred to the iterator in AbstractList, which check for concurrent modification - Warmup takes a bit longer due to having to warm up four different classes and associated methods - Slowdowns in certain code paths attributable to certain calls becoming megamorphic Microbenchmark: http://cr.openjdk.java.net/~redestad/scratch/less_immutables/ListMorphism.j… http://cr.openjdk.java.net/~redestad/scratch/less_immutables/benchmarks.jar The benchmark explores how call-sites behave when performing some naive operations on a few different Lists. For every benchmark using List.of() there's a variant using ArrayList for comparison: Baseline: Benchmark Mode Cnt Score Error Units ListMorphism.finalGetFromArrayList thrpt 25 92.659 ± 3.058 ops/us ListMorphism.finalGetFromList thrpt 25 335.245 ± 0.244 ops/us # 3.6x ListMorphism.finalSumSizesArrayList thrpt 25 245.020 ± 0.106 ops/us ListMorphism.finalSumSizesList thrpt 25 335.107 ± 0.439 ops/us # 1.4x ListMorphism.getFromArrayList thrpt 25 70.343 ± 0.972 ops/us ListMorphism.getFromList thrpt 25 37.121 ± 0.135 ops/us # 0.53x ListMorphism.getFromArrayList12 thrpt 25 109.890 ± 0.286 ops/us ListMorphism.getFromList12 thrpt 25 109.552 ± 6.972 ops/us # 1.0x ListMorphism.sumSizesArrayList thrpt 25 131.467 ± 4.672 ops/us ListMorphism.sumSizesList thrpt 25 57.877 ± 0.102 ops/us # 0.45x ListMorphism.sumSizesArrayList12 thrpt 25 208.652 ± 11.294 ops/us ListMorphism.sumSizesList12 thrpt 25 227.269 ± 0.961 ops/us # 1.1x The good: When dealing with List literals (the final* benchmarks), List.of() allows really nice speed-ups compared to ArrayList. The bad: When not used as a literal, List.of() implementations at call-sites can cause a substantial slowdown (megamorphic dispatch) The ugly: After some explorations[1], I narrowed in on the following experiment: http://cr.openjdk.java.net/~redestad/scratch/less_immutables/webrev/ Basically: Merge List1 and List2 into a single class, List12, merge List0 into ListN (List0 has a singleton instance, so might as well be an instance of ListN). Same for Set0,1,2,N. Map0 is merged into MapN. This strikes a balance between throughput, footprint and slightly better startup/warmup behavior. According to jol estimates[2] the size of List12 is the same as both List1 and List2 in the current JDK implementation. Set12 is footprint neutral compared to Set2 on all platforms but lose a few bytes on 64-bit VMs compared to Set1. Benchmark Mode Cnt Score Error Units ListMorphism.finalGetFromArrayList thrpt 25 93.046 ± 0.569 ops/us ListMorphism.finalGetFromList thrpt 25 335.280 ± 0.154 ops/us # 3.6x ListMorphism.finalSumSizesArrayList thrpt 25 244.595 ± 1.085 ops/us ListMorphism.finalSumSizesList thrpt 25 303.351 ± 0.182 ops/us # 1.2x ListMorphism.getFromArrayList thrpt 25 70.631 ± 0.070 ops/us ListMorphism.getFromList thrpt 25 73.258 ± 2.955 ops/us # 1.04x ListMorphism.getFromArrayList12 thrpt 25 109.921 ± 0.096 ops/us ListMorphism.getFromList12 thrpt 25 127.392 ± 0.088 ops/us # 1.16x ListMorphism.sumSizesArrayList thrpt 25 131.393 ± 4.882 ops/us ListMorphism.sumSizesList thrpt 25 107.686 ± 5.286 ops/us # 0.82x ListMorphism.sumSizesArrayList12 thrpt 25 212.350 ± 0.134 ops/us ListMorphism.sumSizesList12 thrpt 25 198.778 ± 0.479 ops/us # 0.94x The experiment has a flag to change number of specialized List/Set/Map classes (-Djdk.ImmutableCollections.specializations=0|1|2, default=2). 1 specialization (List1 + ListN, Set1 + SetN) is more or less the same as 2, some ~1-2% improvements, mainly in sumSizes micros. 0 specializations (List-, Set, MapN only) achieves a small increase in throughput on some micros by ensuring callsites stay monomorphic, but it's not very substantial by my measures (~5%, but mostly in sumSizes micros). Keeping the footprint more or less the same, while evening out a few rough edges and improving startup and static footprint seems like the overall best option. An alternative would be to keep the experimental flag, but I don't think a 5% gain on micros warrants the extra maintenance burden and testing that entails. The proposed patch is more or less this experiment with 2 specializations, but having removed the flag and code movement needed to support it removed (along with a fix in the writeReplace methods of List12/Set12) Thanks! /Claes [1] Older experiments: http://cr.openjdk.java.net/~redestad/immutable/list12N.0/ -- simply merge L0 into LN (still have L1, L2 and LN) - nothing really changed, though http://cr.openjdk.java.net/~redestad/immutable/list1N.0/ -- L0 merged into LN, drop L2. Substantial performance boost on micros. Footprint drop for 2-element lists. http://cr.openjdk.java.net/~redestad/immutable/listNdouble.0/ -- L0+L1+L2+LN merged into one implementation. Same footprint with a single class, but loses a lot on throughput in micros. http://cr.openjdk.java.net/~redestad/immutable/listNsingle.0/ -- L0+L1+LN merged, drop L2. Simplification of the previous. Like the list1N.0 experiment in footprint, but a loss in throughput on all measures. No approach seemed a win across the board here: we either had to accept a footprint reduction, or see throughput suffer dramatically. [2] http://openjdk.java.net/projects/code-tools/jol/

11 51

RFR of 8180451: ByteArrayInputStream should override readAllBytes, readNBytes, and transferTo
by Brian Burkhalter 23 Mar '18

23 Mar '18

https://bugs.openjdk.java.net/browse/JDK-8180451 http://cr.openjdk.java.net/~bpb/8180451/webrev.00 1. Add overrides of readAllBytes(), readNBytes(), and transferTo(). 2. Simplify parameter checks in read(byte[],int,int). 3. Change <code>foo</code> to {@code foo}. Thanks, Brian

5 11

Re: RFR 8181594: Efficient and constant-time modular arithmetic
by Adam Petcher 20 Mar '18

20 Mar '18

+core-libs-dev On 1/26/2018 4:06 PM, Adam Petcher wrote: > JBS: https://bugs.openjdk.java.net/browse/JDK-8181594 > Webrev: http://cr.openjdk.java.net/~apetcher/8181594/webrev.00/ > > This is a code review for the field arithmetic that will be used in > implementations of X25519/X448 key agreement, the Poly1305 > authenticator, and EdDSA signatures. I believe that the library has > all the features necessary for X25519/X448 and Poly1305, and I expect > at most a couple of minor enhancements will be required to support > EdDSA. There is no public API for this library, so we can change it in > the future to suit the needs of new algorithms without breaking > compatibility with external code. Still, I made an attempt to clearly > structure and document the (internal) API, and I want to make sure it > is understandable and easy to use. > > This is not a general-purpose modular arithmetic library. It will only > work well in circumstances where the sequence of operations is > restricted, and where the prime that defines the field has some useful > structure. Moreover, each new field will require some field-specific > code that takes into account the structure of the prime and the way > the field is used in the application. The initial implementation > includes a field for Poly1305 and the fields for X25519/X448 which > should also work for EdDSA. > > The benefits of using this library are that it is much more efficient > than using similar operations in BigInteger. Also, many operations are > branch-free, making them suitable for use in a side-channel resistant > implementation that does not branch on secrets. > > To provide some context, I have attached a code snippet describing how > this library can be used. The snippet is the constant-time Montgomery > ladder from my X25519/X448 implementation, which I expect to be out > for review soon. X25519/X448 only uses standard arithmetic operations, > and the more unusual features (e.g. add modulo a power of 2) are > needed by Poly1305. > > The field arithmetic (for all fields) is implemented using a 32-bit > representation similar to the one described in the Ed448 paper[1] (in > the "Implementation on 32-bit platforms" section). Though my > implementation uses signed limbs, and grade-school multiplication > instead of Karatsuba. The argument for correctness is essentially the > same for all three fields: the magnitude of each 64-bit limb is at > most 2^(k-1) after reduction, except for the last limb which may have > a magnitude of up to 2^k. The values of k are between 26 to 28 > (depending on the field), and we can calculate that the maximum > magnitude for any limb during an add-multiply-carry-reduce sequence is > always less than 2^63. Therefore, no overflow occurs and all > operations are correct. > > Process note: this enhancement is part of JEP 324 (Key Agreement with > Curve25519 and Curve448). When this code review is complete, nothing > will happen until all other work for this JEP is complete, and the JEP > is accepted as part of some release. This means that this code will be > pushed to the repo along with the X25519/X448 code that uses it. > > [1] https://eprint.iacr.org/2015/625.pdf > > >

2 5

Oracle Java 8u161 regression in XML Schema Factory
by Bernd 02 Mar '18

02 Mar '18

Hello, some of our unit tests (using PowerMock and xmlunit) fail with 8u161 (and u162) but work with 8u152. I cant reproduce the fault in a stand-alone program so it seems to be related to classloader/reflection magic of those tools, sorry. Is this a regression of 8159240 <http://bugs.java.com/view_bug.do?bug_id=JDK-8159240> (not public?) Here is the stacktrace anyway: com.sun.org.apache.xerces.internal.impl.dv.DVFactoryException: Schema factory class com.sun.org.apache.xerces.internal.impl.dv.xs.SchemaDVFactoryImpl does not extend from SchemaDVFactory. at com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.getInstance(SchemaDVFactory.java:75) at com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory.getInstance(SchemaDVFactory.java:57) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.reset(XMLSchemaLoader.java:1024) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:556) at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadGrammar(XMLSchemaLoader.java:535) at com.sun.org.apache.xerces.internal.jaxp.validation.XMLSchemaFactory.newSchema(XMLSchemaFactory.java:254) at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:638) at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:654) at com.seeburger.api.test.helpers.BuilderTestHelper.getCRSchemaValidator(BuilderTestHelper.java:57) at com.seeburger.api.test.helpers.BuilderTestHelper.validateAndCompare(BuilderTestHelper.java:73) at com.seeburger.api.test.KSMBuilderTest.testDeletePGP(KSMBuilderTest.java:196) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:68) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:310) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:89) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:97) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.executeTest(PowerMockJUnit44RunnerDelegateImpl.java:294) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTestInSuper(PowerMockJUnit47RunnerDelegateImpl.java:127) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit47RunnerDelegateImpl$PowerMockJUnit47MethodRunner.executeTest(PowerMockJUnit47RunnerDelegateImpl.java:82) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$PowerMockJUnit44MethodRunner.runBeforesThenTestThenAfters(PowerMockJUnit44RunnerDelegateImpl.java:282) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:50) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.invokeTestMethod(PowerMockJUnit44RunnerDelegateImpl.java:207) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.runMethods(PowerMockJUnit44RunnerDelegateImpl.java:146) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl$1.run(PowerMockJUnit44RunnerDelegateImpl.java:120) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:34) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:44) at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.run(PowerMockJUnit44RunnerDelegateImpl.java:122) at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.run(JUnit4TestSuiteChunkerImpl.java:106) at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.run(AbstractCommonPowerMockRunner.java:53) at org.powermock.modules.junit4.PowerMockRunner.run(PowerMockRunner.java:59) at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:539) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:761) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:461) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:207) on the classpath jaxb-impl-2.2.5.jar but the specific packages are only loaded from rt.jar and redefined. I asume the later is done by Powermock. Line 611: [Loaded com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory from C:\Program Files\Java\jdk1.8.0_161\jre\lib\rt.jar] Line 616: [Loaded com.sun.org.apache.xerces.internal.impl.dv.xs.BaseSchemaDVFactory from C:\Program Files\Java\jdk1.8.0_161\jre\lib\rt.jar] Line 617: [Loaded com.sun.org.apache.xerces.internal.impl.dv.xs.SchemaDVFactoryImpl from C:\Program Files\Java\jdk1.8.0_161\jre\lib\rt.jar] Line 618: [Loaded com.sun.org.apache.xerces.internal.impl.dv.SchemaDVFactory from __JVM_DefineClass__] Line 619: [Loaded com.sun.org.apache.xerces.internal.impl.dv.xs.BaseSchemaDVFactory from __JVM_DefineClass__] Line 620: [Loaded com.sun.org.apache.xerces.internal.impl.dv.xs.SchemaDVFactoryImpl from __JVM_DefineClass__] Is that something you are concerned? Gruss Bernd <http://bugs.java.com/view_bug.do?bug_id=JDK-8159240>

6 12

Re: Manifest Related Bugs JDK-6372077, JDK-6202130, JDK-8176843, JDK-4842483, JDK-6443578, JDK-6910466, JDK-4935610, and JDK-4271239
by Sean Mullan 01 Mar '18

01 Mar '18

Hi Phillip, All of these bugs are in the core-libs area, so I am copying the core-libs-dev list since that is where they should be discussed and reviewed. I have -bcc-ed security-dev (where this was originally posted). --Sean On 10/2/17 1:24 PM, Philipp Kunz wrote: > Hi, > > While fixing JDK-6695402 I came across other related bugs to manifests > such as JDK-6372077, JDK-6202130, JDK-8176843, JDK-4842483, and > JDK-6443578 which all relate to manifest reading and writing. Somewhere > bug 7071055 is mentioned but I cannot find anywhere. Another group of > bugs, JDK-6910466, JDK-4935610, and JDK-4271239 concern the mandatory > manifest main attributes Manifest-Version or Signature-Version and at > first glance are duplicates. If you know of more known bugs, not > necessarily present in jira, I'd be glad to get notified. > > There are also some comments about utf handling and line breaking in the > code of Manifest: > http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/sha… > http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/sha… > http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/sha… > > Furthermore, Attributes.map should declare appropriate type parameters: > http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/sha… > The specification would also require that `header names must not start > with _, - or "From"` > (http://docs.oracle.com/javase/7/docs/technotes/guides/jar/jar.html#Section-…) > but I would opt not to add this as a hard restriction because I guess it > can be assumed that such names are in use now after having been working > for years. A warning to a logger might be conceivable such as in > http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/sha… > Attribute values are never checked at all and invalid characters such as > line breaks are never detected except that when reading the manifest > again the values are cut off. > The tab character (U+0008) does not work in manifest values. > I suspect that there are also issues regarding the iteration order but I > haven't got a prove yet unlike for the other points above: > http://hg.openjdk.java.net/jdk10/master/file/a0116bcc65b7/src/java.base/sha… > There is duplicated or very similar code in Attributes and Manifest: > Attributes.write-Manifest.write-Attributes.writeMain and > Attributes.read-Manifest.read. > Resolving JDK-6202130 would have the additional benefit to be able to > view manifests with any utf-8 capable editor even if multi-byte > characters break across lines. > > Fixing these issues individually looks like more complicated work than > fixing them all at once, I guess, also because of a very low current > test coverage. So I'd suggest to add some thorough tests along with > fixing these issues. But before I start I would like to get some > guidance, assistance or at least confirmation on how to proceed. I'm new > to open jdk and have submitted only one patch so far. > > Is it ok to add tests for things that have worked before? > Is it ok to refactor duplicated code just for the added value to reduce > effort for testing? > I assume compatibility to and from existing manifests is the highest > priority, correct? This would also be the hard part in adding as > complete test coverage as possible. What would be acceptable criteria to > meet? > Why does Attributes not extend LinkedHashMap and why does Manifest not > extend HashMap? Any objection? > While I would not want to write code that looks slow or change more than > necessary one can never know before having performance actually > measured. Is there some way this is dealt with or should I wait for such > feedback until after patch submission? > > Would someone sponsor? > > Regards, > Philipp > > > > > ------------------------------------------------------------------------ > > > > Paratix GmbH > St Peterhofstatt 11 > 8001 Zürich > > +41 (0)76 397 79 35 > philipp.kunz(a)paratix.ch <mailto:philipp.kunz@paratix.ch>

5 12

RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer
by Joe Wang 28 Feb '18

28 Feb '18

Hi, Adding methods for comparing CharSequence, StringBuilder, and StringBuffer. The Comparable implementations for StringBuilder/Buffer are similar to that of String, allowing comparison operations between two StringBuilders/Buffers, e.g. aStringBuilder.compareTo(anotherStringBuilder). For CharSequence however, refer to the comments in JIRA, a static method 'compare' is added instead of implementing the Comparable interface. This 'compare' method may take CharSequence implementations such as String, StringBuilder and StringBuffer, making it possible to perform comparison among them. The previous example for example is equivalent to CharSequence.compare(aStringBuilder, anotherStringBuilder). Tests for java.base have been independent from each other. The new tests are therefore created to have no dependency on each other or sharing any code. JBS: https://bugs.openjdk.java.net/browse/JDK-8137326 webrev: http://cr.openjdk.java.net/~joehw/jdk11/8137326/webrev/ Thanks, Joe

8 26

Thread.single_step field, anything using it?
by Alan Bateman 15 Feb '18

15 Feb '18

I've been going through the fields in java.lang.Thread and I'm wondering if this field can be removed: /* Whether or not to single_step this thread. */ private boolean single_step; This field was used in the original Classic VM (pre-OpenJDK history). It doesn't appear to be used in the HotSpot VM. Does anyone know of any reason to keep it? Are there other VMs using it by any chance? -Alan

3 3