Re: RFR: 8282191: Implementation of Foreign Function & Memory API (Preview) [v16]

[Paul Sandoz]

On Wed, 30 Mar 2022 21:51:16 GMT, Maurizio Cimadamore  
wrote:

>> This PR contains the API and implementation changes for JEP-424 [1]. A more 
>> detailed description of such changes, to avoid repetitions during the review 
>> process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/424
>
> Maurizio Cimadamore has updated the pull request with a new target base due 
> to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - Merge branch 'master' into foreign-preview
>  - Tweak FunctionDescriptor::argumentLayouts to return an immutable list
>  - Fix bad usage of `@link` with primitive array types
>  - Switch to daemon threads for async upcalls
>  - Use thread local storage to optimize attach of async threads
>  - Drop support for Constable from MemoryLayout/FunctionDescriptor
>  - Merge branch 'master' into foreign-preview
>  - Revert changes to RunTests.gmk
>  - Add --enable-preview to micro benchmark java options
>  - Address more review comments
>  - ... and 21 more: 
> https://git.openjdk.java.net/jdk/compare/ce27d9dd...247e5eb5

Java code looks good (i did not go through the tests). As is common no 
comments, since code was reviewed in smaller steps in the panama-foreign 
respository.

-

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/7888

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v10]

[Paul Sandoz]

On Tue, 2 Nov 2021 10:30:42 GMT, Maurizio Cimadamore  
wrote:

>> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java line 
>> 111:
>> 
>>> 109: class VarHandleCache {
>>> 110: private static final Map handleMap 
>>> = new ConcurrentHashMap<>();
>>> 111: private static final Map 
>>> handleMapNoAlignCheck = new ConcurrentHashMap<>();
>> 
>> Something to consider later if this is an issue. Since the number of 
>> `ValueLayout` instances is fixed, carrier x order = 18, we can use stable 
>> arrays with ordinals on the instances.
>
> What about alignment?

Drat, `skipAlignmentCheck` misled me but perhaps there is still benefit for 
common constants with 8 bit and size alignment and fallback otherwise.

-

PR: https://git.openjdk.java.net/jdk/pull/5907

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v12]

[Paul Sandoz]

On Mon, 1 Nov 2021 22:36:40 GMT, Maurizio Cimadamore  
wrote:

>> This PR contains the API and implementation changes for JEP-419 [1]. A more 
>> detailed description of such changes, to avoid repetitions during the review 
>> process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/419
>
> Maurizio Cimadamore has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Tweak javadoc of loaderLookup

Marked as reviewed by psandoz (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/5907

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v10]

[Paul Sandoz]

On Mon, 1 Nov 2021 12:05:32 GMT, Maurizio Cimadamore  
wrote:

>> This PR contains the API and implementation changes for JEP-419 [1]. A more 
>> detailed description of such changes, to avoid repetitions during the review 
>> process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/419
>
> Maurizio Cimadamore has updated the pull request with a new target base due 
> to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Add cache for memory address var handles
>  - Merge branch 'master' into JEP-419
>  - Fix regression in VaList treatment on AArch64 (contributed by @nick-arm)
>  - Merge branch 'master' into JEP-419
>  - Fix copyright header in TestArrayCopy
>  - Fix failing microbenchmarks. Contributed by @FrauBoes (thanks!)
>  - * use `invokeWithArguments` to simplify new test
>  - Add test for liveness check with high-aririty downcalls
>(make sure that if an exception occurs in a downcall because of liveness,
>ref count of other resources are left intact).
>  - * Fix javadoc issue in VaList
>* Fix bug in concurrent logic for shared scope acquire
>  - Address review comments
>  - ... and 7 more: 
> https://git.openjdk.java.net/jdk/compare/5bb1992b...9b519343

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/Utils.java line 
111:

> 109: class VarHandleCache {
> 110: private static final Map handleMap = 
> new ConcurrentHashMap<>();
> 111: private static final Map 
> handleMapNoAlignCheck = new ConcurrentHashMap<>();

Something to consider later if this is an issue. Since the number of 
`ValueLayout` instances is fixed, carrier x order = 18, we can use stable 
arrays with ordinals on the instances.

-

PR: https://git.openjdk.java.net/jdk/pull/5907

Re: RFR: 8275063: Implementation of Foreign Function & Memory API (Second incubator) [v2]

[Paul Sandoz]

On Tue, 12 Oct 2021 20:51:02 GMT, Maurizio Cimadamore  
wrote:

>> This PR contains the API and implementation changes for JEP-419 [1]. A more 
>> detailed description of such changes, to avoid repetitions during the review 
>> process, is included as a separate comment.
>> 
>> [1] - https://openjdk.java.net/jeps/419
>
> Maurizio Cimadamore has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Fix TestLinkToNativeRBP test

Like with previous reviews of code for Panama JEPs there are not many comments 
on this PR, since prior reviews occurred for PRs in the panama-foreign repo.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 
77:

> 75:  * Furthermore, if the function descriptor's return layout is a group 
> layout, the resulting downcall method handle accepts
> 76:  * an extra parameter of type {@link SegmentAllocator}, which is used by 
> the linker runtime to allocate the
> 77:  * memory region associated with the struct returned by  the downcall 
> method handle.

Suggestion:

 * memory region associated with the struct returned by the downcall method 
handle.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 
88:

> 86:  * in which the specialized signature of a given variable arity callsite 
> is described in full. Alternatively,
> 87:  * if the foreign library allows it, clients might also be able to 
> interact with variable arity methods
> 88:  * using by passing a trailing parameter of type {@link VaList}.

Suggestion:

 * by passing a trailing parameter of type {@link VaList}.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 
145:

> 143:  * Lookup a symbol in the standard libraries associated with this 
> linker.
> 144:  * The set of symbols available for lookup is unspecified, as it 
> depends on the platform and on the operating system.
> 145:  * @return a linker-specific library lookup which is suitable to 
> find symbols in the standard libraries associated with this linker.

Suggestion:

 * @return a symbol in the standard libraries associated with this linker.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/FunctionDescriptor.java
 line 93:

> 91: Objects.requireNonNull(argLayouts);
> 92: Arrays.stream(argLayouts).forEach(Objects::requireNonNull);
> 93: return new FunctionDescriptor(null, argLayouts);

We need to clone `argLayouts`, otherwise the user can modify the contents. 
Internally, using `List.of` is useful, since it does the cloning and null 
checks, and that is the type that is returned. Also `argumentLayouts` uses 
`Arrays.asList` which supports modification of the contents.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/SegmentAllocator.java
 line 394:

> 392:  * 
> 393:  * The returned allocator might throw an {@link OutOfMemoryError} if 
> the total memory allocated with this allocator
> 394:  * exceeds the arena size, or the system capacity. Furthermore, the 
> returned allocator is not thread safe, and all

The "the returned allocator is not thread safe" contradicts the prior sentence 
"An allocator associated with a shared resource scope is thread-safe 
and allocation requests may be performed concurrently".

Perhaps just say:
"

The returned allocator is not thread safe if the given scope is a shared scope. 
Concurrent allocation needs to be guarded with synchronization primitives. 
"

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java
 line 260:

> 258: 
> 259: @Override
> 260: public final MemorySegment asOverlappingSlice(MemorySegment other) {

Please ignore these comments if you wish.

Adding `max() // exclusive` to complement `min()` might be useful.

In these cases i find it easier to sort the segments e.g. `var a = this; var b 
= other; if (a.min() > b.min()) { // swap a and b }` then the subsequent logic 
tends to get simpler e.g. overlap test is `if (b.min() < a.max())`, 
`segmentOffset` is always +ve.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/ConfinedScope.java 
line 100:

> 98: do {
> 99: value = (int)ASYNC_RELEASE_COUNT.getVolatile(this);
> 100: } while (!ASYNC_RELEASE_COUNT.compareAndSet(this, value, 
> value + 1));

Use `getAndAdd` (and ignore the return value).

-

PR: https://git.openjdk.java.net/jdk/pull/5907

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v7]

[Paul Sandoz]

On Tue, 22 Jun 2021 02:58:28 GMT, Yi Yang  wrote:

> I found that after solving the problem that Preconditions cannot be used 
> during the VM startup, a series of functions such as 
> String.checkIndex/checkOffset/.. can also be harmlessly replaced, but this 
> changeset is somewhat large and may overwrite the previous review progress. 
> If it will confuse the current review progress for reviewers involving in 
> this PR, I'd like to file a new PR to do this change later.

Yes, I think that helps to review. It's often easier, review-wise, to have 
separate PRs for specific areas, rather than keep expanding an existing PR.

-

PR: https://git.openjdk.java.net/jdk/pull/4507

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v6]

[Paul Sandoz]

On Mon, 21 Jun 2021 05:17:09 GMT, Yi Yang  wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of 
>> checkIndex by 
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in 
>> the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally with one additional commit 
> since the last revision:
> 
>   more replacement 2

All the updates to the check* methods look ok (requires some careful looking!).

I cannot recall what others said about the change in exception messages. 
@jddarcy any advice here?

src/java.base/share/classes/jdk/internal/util/Preconditions.java line 78:

> 76: = Preconditions.outOfBoundsExceptionFormatter(new 
> StringIndexOutOfBoundsExceptionProducer());
> 77: 
> 78: public static final BiFunction, 
> StringIndexOutOfBoundsException> AIOOBE_FORMATTER

Using incorrect exception type. Suggest you embed as inner class rather than 
separate declaration, since they are only used in one place.

-

PR: https://git.openjdk.java.net/jdk/pull/4507

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible [v2]

[Paul Sandoz]

On Fri, 18 Jun 2021 05:54:01 GMT, Yi Yang  wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of 
>> checkIndex by 
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in 
>> the whole JDK codebase.
>
> Yi Yang has updated the pull request incrementally with one additional commit 
> since the last revision:
> 
>   restore IndexOfOufBoundsException; split exception line

@kahatlen for cases earlier in VM startup you need to avoid method references 
and lambda expressions. See the implementation of 
`outOfBoundsExceptionFormatter`, and see the usage in `VarHandle` for two 
examples.

Custom exception formaters should ideally be constants held in static final 
fields.

I think the API complexity comes down to whether it is necessary to preserve 
existing exception messages or not when converting existing code to use the 
precondition methods. The API is designed to do that and composes reasonably 
well for default exception messages with a non-default exceptions. We could 
argue (i would!) it is preferable to have a consistent exception messages for 
index out of bounds exceptions, thereby we could collapse and simplify, but 
this is sometimes considered a change in behaviour.

src/java.base/share/classes/java/util/Base64.java line 935:

> 933: throw new IOException("Stream is closed");
> 934: Preconditions.checkFromIndexSize(len, off, b.length,
> 935: 
> Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new));

`outOfBoundsExceptionFormatter` will allocate. Store the result of 
`Preconditions.outOfBoundsExceptionFormatter(ArrayIndexOutOfBoundsException::new))`
 in a public static final on `Preconditions`, and replace the method ref with a 
inner class (thereby making it usable earlier at VM startup.

-

PR: https://git.openjdk.java.net/jdk/pull/4507

Re: RFR: 8268698: Use Objects.check{Index, FromToIndex, FromIndexSize} where possible

[Paul Sandoz]

On Thu, 17 Jun 2021 10:21:35 GMT, Alan Bateman  wrote:

>> After JDK-8265518(#3615), it's possible to replace all variants of 
>> checkIndex by 
>> Objects.checkIndex/Objects.checkFromToIndex/Objects.checkFromIndexSize in 
>> the whole JDK codebase.
>
> src/java.base/share/classes/java/util/Base64.java line 934:
> 
>> 932: if (closed)
>> 933: throw new IOException("Stream is closed");
>> 934: Preconditions.checkFromIndexSize(len, off, b.length, (xa, 
>> xb) -> new ArrayIndexOutOfBoundsException());
> 
> You might want to split this really long line too, to avoid inconsistent line 
> length in this source file.

I would suggest factoring out `(xa, xb) -> new 
ArrayIndexOutOfBoundsException()` as a reusable component on `Preconditions`, 
and maybe even supplying an exception message (since it is rather useful, and 
way better than no message).

See the usages of `Preconditions.outOfBoundsExceptionFormatter` (where there 
just happens to be many repeated cases of supplying AIOOBE with a message, that 
could also be consolidated, separate fix perhaps).

-

PR: https://git.openjdk.java.net/jdk/pull/4507

Re: RFR: 8268129: LibraryLookup::ofDefault leaks symbols from loaded libraries [v2]

[Paul Sandoz]

On Wed, 2 Jun 2021 20:17:20 GMT, Maurizio Cimadamore  
wrote:

>> This patch overhauls the library loading mechanism used by the Foreign 
>> Linker API. We realized that, while handy, the *default* lookup abstraction 
>> (`LibraryLookup::ofDefault`) was behaving inconsistentlt across platforms.
>> 
>> This patch replaces `LibraryLookup` with a simpler `SymbolLookup` 
>> abstraction, a functional interface. Crucially, `SymbolLookup` does not 
>> concern with library loading, only symbol lookup. For this reason, two 
>> factories are added:
>> 
>> * `SymbolLookup::loaderLookup` - which obtains a lookup that can be used to 
>> lookup symbols in libraries loaded by current loader
>> * `CLinker::systemLookup` - a more stable replacement for the *default* 
>> lookup, which looks for symbols in libc.so (or its equivalent in other 
>> platforms). The contents of this lookup are unspecified.
>> 
>> Both factories are *restricted*, so they can only be called when 
>> `--enable-native-access` is set.
>
> Maurizio Cimadamore has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Update 
> test/micro/org/openjdk/bench/jdk/incubator/foreign/points/support/PanamaPoint.java
>   
>   Co-authored-by: Jorn Vernee 

Looks good. Just minor comments to accept/reject.

The shim library is an interesting approach. I did wonder if the libvm library 
could be used, but it might have some weird side-effects or bring in more 
symbols than necessary.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 
138:

> 136:  * 
> 137:  * This method is  href="package-summary.html#restricted">restricted.
> 138:  * Restricted method are unsafe, and, if used incorrectly, their use 
> might crash

Suggestion:

 * Restricted methods are unsafe, and, if used incorrectly, their use might 
crash

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 
160:

> 158:  * to allocate structs returned by-value.
> 159:  *
> 160:  * @see SymbolLookup

For JDK code it is more common for `@See` to occur after the 
parameters/return/throws, and before any `@Since`.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/abi/SharedUtils.java
 line 418:

> 416: private static class AllocHolder {
> 417: 
> 418: private static final CLinker linker = getSystemLinker();

Suggestion:

private static final CLinker SYS_LINKER = getSystemLinker();

test/jdk/java/foreign/SafeFunctionAccessTest.java line 53:

> 51: );
> 52: 
> 53: static SymbolLookup lookup = SymbolLookup.loaderLookup();

Suggestion:

static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup();

test/jdk/java/foreign/StdLibTest.java line 158:

> 156: static class StdLibHelper {
> 157: 
> 158: final static SymbolLookup LOOKUP;

Suggestion:

static final SymbolLookup LOOKUP;

test/jdk/java/foreign/TestDowncall.java line 60:

> 58: }
> 59: 
> 60: static SymbolLookup lookup = SymbolLookup.loaderLookup();

Suggestion:

static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup();

test/jdk/java/foreign/TestIllegalLink.java line 48:

> 46: public class TestIllegalLink {
> 47: 
> 48: private static final MemoryAddress dummyTarget = 
> MemoryAddress.ofLong(1);

Suggestion:

private static final MemoryAddress DUMMY_TARGET = MemoryAddress.ofLong(1);

test/jdk/java/foreign/TestIntrinsics.java line 60:

> 58: }
> 59: 
> 60: static SymbolLookup lookup = SymbolLookup.loaderLookup();

Suggestion:

static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup();

test/jdk/java/foreign/TestSymbolLookup.java line 50:

> 48: }
> 49: 
> 50: static SymbolLookup lookup = SymbolLookup.loaderLookup();

Suggestion:

static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup();

test/jdk/java/foreign/TestUpcall.java line 69:

> 67: static CLinker abi = CLinker.getInstance();
> 68: 
> 69: static SymbolLookup lookup = SymbolLookup.loaderLookup();

Suggestion:

static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup();

test/jdk/java/foreign/TestVarArgs.java line 68:

> 66: }
> 67: 
> 68: static final MemoryAddress varargsAddr =

Suggestion:

static final MemoryAddress VARARGS_ADDR =

test/jdk/java/foreign/valist/VaListTest.java line 74:

> 72: }
> 73: 
> 74: static SymbolLookup lookup = SymbolLookup.loaderLookup();

Suggestion:

static final SymbolLookup LOOKUP = SymbolLookup.loaderLookup();

-

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/4316

Re: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator)

[Paul Sandoz]

On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore  
wrote:

> This PR contains the API and implementation changes for JEP-412 [1]. A more 
> detailed description of such changes, to avoid repetitions during the review 
> process, is included as a separate comment.
> 
> [1] - https://openjdk.java.net/jeps/412

The Java changes are mostly familiar to me, having reviewed many PRs in the 
Panama repository, hence the lack of specific comments here. I did a pass 
through the changes and nothing major stood out to me.

The new API changes make it much easy to build APIs around memory segments, 
exposing and reusing resource scope, acquiring/releasing on resource scope, 
where necessary.

-

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3699

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

[Paul Sandoz]

On Fri, 26 Feb 2021 13:15:28 GMT, Rémi Forax 
 wrote:

>> Looking for some final code reviews.
>
> I still don't like the fact that the factory uses reflection but i don't see 
> how to do better

This is now looking very nicely structured.

The only thing i am unsure are the details around `RandomGenerator` being a 
service provider interface. The documentation mentions this at various points 
(mostly as implementation notes), but it's not really called out on 
`RandomGenerator`. 

Trying out the patch, I can implement `RandomGenerator` and register it as a 
service:

public class AlwaysZero implements RandomGenerator {
@Override
public long nextLong() {
return 0;
}
}
...
RandomGenerator alwaysZero = RandomGenerator.of("AlwaysZero");
 

Is that intended? (esp. since the annotation `RandomGeneratorProperties` is not 
public). If i rename the above to `L32X64MixRandom` an 
`ExceptionInInitializerError` is produced due to duplicate keys.

I suspect you want to filter out the service providers to those that only 
declare `RandomGeneratorProperties`, thereby restricting to providers only 
supplied by the platform.

-

PR: https://git.openjdk.java.net/jdk/pull/1292

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]

[Paul Sandoz]

On Tue, 17 Nov 2020 22:21:18 GMT, Jim Laskey  wrote:

>> This PR is to introduce a new random number API for the JDK. The primary API 
>> is found in RandomGenerator and RandomGeneratorFactory. Further description 
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> Jim Laskey has updated the pull request with a new target base due to a merge 
> or a rebase. The pull request now contains 40 commits:
> 
>  - Merge branch 'master' into 8248862
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>
>Update package-info.java
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>
>Updated RandomGeneratorFactory javadoc.
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>
>Updated documentation for RandomGeneratorFactory.
>  - Merge branch 'master' into 8248862
>  - Merge branch 'master' into 8248862
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>
>Move RandomGeneratorProperty
>  - Merge branch 'master' into 8248862
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>
>Clear up javadoc
>  - 8248862; Implement Enhanced Pseudo-Random Number Generators
>
>remove RandomGeneratorProperty from API
>  - ... and 30 more: 
> https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68

I am unsure if the intent is also to support external libraries providing 
`RandomGenerator` implementations. Currently there is an implicit contract for 
properties (reflectively invoking a method returning a map with a set of 
entries with known keys). Since the service provider implementation is the 
`RandomGenerator` itself, rather than `RandomGeneratorFactory` it is harder 
expose the meta-data with a clearer contract.

src/java.base/share/classes/java/util/Random.java line 592:

> 590: 
> 591: @Override
> 592: public Spliterator.OfInt makeIntsSpliterator(long index, long fence, 
> int origin, int bound) {

Unsure if this and the other two methods are intended to be public or not, 
since they are at the end of the class and override methods of a module private 
class. In principle there is nothing wrong with such `Spliterator` factories, 
but wonder if they are really needed given the `Stream` returning methods. The 
arrangement of classes makes it awkward to hide these methods.

src/java.base/share/classes/java/util/SplittableRandom.java line 171:

> 169:  * RandomGenerator properties.
> 170:  */
> 171: static Map getProperties() {

With records exiting preview in 16 this map of properties could i think be 
represented as a record instance, with better type safety, where 
`RandomSupport.RandomGeneratorProperty` enum values become typed fields 
declared on the record class. Something to consider after integration perhaps?

src/java.base/share/classes/java/util/SplittableRandom.java line 211:

> 209:  * 
> http://zimbry.blogspot.com/2011/09/better-bit-mixing-improving-on.html
> 210:  */
> 211: private static long mix64(long z) {

Usages be replaced with calls to `RandomSupport.mixStafford13`?

src/java.base/share/classes/module-info.java line 250:

> 248: exports jdk.internal.util.xml.impl to
> 249: jdk.jfr;
> 250: exports jdk.internal.util.random;

Unqualified export, should this be `to jdk.random`?

src/jdk.random/share/classes/module-info.java line 50:

> 48:  */
> 49: module jdk.random {
> 50: uses java.util.random.RandomGenerator;

Are these `uses` declarations needed? `ServiceLoader` is not used by this 
module, and `RandomSupport` is not a service interface.

src/jdk.random/share/classes/module-info.java line 53:

> 51: uses RandomSupport;
> 52: 
> 53: exports jdk.random to

Why is this needed?

src/java.base/share/classes/java/util/random/package-info.java line 50:

> 48:  * given its name.
> 49:  *
> 50:  *  The principal supporting class is {@link RandomGenertatorFactor}. 
> This

s/RandomGenertatorFactor/RandomGenertatorFactory

src/java.base/share/classes/java/util/random/package-info.java line 140:

> 138:  *
> 139:  *  For applications with no special requirements,
> 140:  * "L64X128MixRandom" has a good balance among speed, space,

The documentation assumes that the `jdk.random` module is present in the JDK 
image. Perhaps we need to spit the specifics to `jdk.random`?

src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 
1211:

> 1209: Udiff = -Udiff;
> 1210: U2 = U1;
> 1211: U1 -= Udiff;

Updated `U1` never used (recommend running the code through a checker e.g. use 
IntelliJ)

src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 
331:

> 329: }
> 330: // Finally, we need to make sure the last z words are not all 
> zero.
> 331: search: {

Nice! a rarely used feature :-)

src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 
1157:

> 1155: /*
> 1156:

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v9]

[Paul Sandoz]

On Thu, 22 Oct 2020 14:26:37 GMT, Maurizio Cimadamore  
wrote:

>> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/AbstractNativeScope.java
>>  line 120:
>> 
>>> 118: }
>>> 119: }
>>> 120: throw new AssertionError("Cannot get here!");
>> 
>> This code is a little confusing, effectively using an exception for control 
>> flow, within a retry loop. I recommend performing an explicit bounds check 
>> to determine if a new segment of `BLOCK_SIZE` is required from which to 
>> slice into. It will also be faster than the exceptional case.
>
> I hear you - that said, note that doing the bound check is not as trivial as 
> it seems; you have to take into account the value of `sp` and add required 
> alignment padding, and then perform a bound check against that - all logic 
> which would need to be duplicated across the normal and the exceptional 
> cases. Which is why the code settled the way it is. I'll see what I can do.

Yeah, i would have probably done the same thing initially.

-

PR: https://git.openjdk.java.net/jdk/pull/634

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v7]

[Paul Sandoz]

On Thu, 22 Oct 2020 13:30:13 GMT, Maurizio Cimadamore  
wrote:

>> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java 
>> line 126:
>> 
>>> 124:  *
>>> 125:  * @param symbol   downcall symbol.
>>> 126:  * @param type the method type.
>> 
>> s/method type/carrier type ?
>
> Not sure about this one? E.g. in my mental model, I often have seen "carrier 
> type" associated with j.l.Class ?

Ah, i see, i find it confusing that "carrier type" is mentioned in the 
`@throws`, and was assuming it was an alias for method type, did you really 
mean method type?

>> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java 
>> line 139:
>> 
>>> 137:  *
>>> 138:  * The returned segment is not thread-confined, and it 
>>> only features
>>> 139:  * the {@link MemorySegment#CLOSE} access mode. When the returned 
>>> segment is closed,
>> 
>> Implying that it is shared? If so might be better to state that directly 
>> (with a link), and can be closed explicitly or left until can be collected 
>> by the GC?
>
> `The returned segment is not thread-confined` ? Since it features 
> CLOSE, it can be closed explicitly - I'm not sure 100% of what additional 
> clarification is required - but I'm happy to make this clearer (I need more 
> info).

Sometimes it's clearer to state the non-negative term i.e. _shared_ which is 
now something more explicit e.g.
> The returned segment is _shared_ [add link?] (not thread-confined)

That is really what i was trying to get at, rather than the CLOSE+GC aspects.

-

PR: https://git.openjdk.java.net/jdk/pull/634

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v7]

[Paul Sandoz]

On Thu, 22 Oct 2020 14:31:12 GMT, Jorn Vernee  wrote:

>> src/java.base/share/classes/java/lang/invoke/NativeMethodHandle.java line 36:
>> 
>>> 34: import static java.lang.invoke.MethodHandleStatics.newInternalError;
>>> 35: 
>>> 36: /** TODO */
>> 
>> Is the TODO to make this class public later and adjust the return type of 
>> `downcallHandle`?
>
> IIRC this was added to silence a javac linter warning. Something should be 
> added here. There is/was no plan to make this class public though.

It's odd the lint warning is triggering on a package private class and private 
methods. Separately, I recommend updating `make/CompileJavaModules.gmk` and 
adding `-Xdoclint:all/protected` for the module (i recently did this for the 
vector API see 
[here](https://github.com/openjdk/jdk/commit/000143504408ac7938e9f493c17c4dbb994045f9#diff-118e609b9974c0ce8af7950711461c7ab4620c9d4f4c99d231f598696f8e05d0)

-

PR: https://git.openjdk.java.net/jdk/pull/634

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v7]

[Paul Sandoz]

On Tue, 20 Oct 2020 17:23:26 GMT, Maurizio Cimadamore  
wrote:

>> This patch contains the changes associated with the first incubation round 
>> of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory 
>> access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from 
>> Java code without the need of intermediate JNI glue code. In order to do 
>> this, native calls are modeled through the MethodHandle API. I suggest 
>> reading the writeup [4] I put together few weeks ago, which illustrates what 
>> the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* 
>> reviews. For this reasons, I'm attaching a webrev which contains only the 
>> differences between this PR and the memory access PR. I will be periodically 
>> uploading new webrevs, as new iterations come out, to try and make the life 
>> of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main 
>> architects of all the hotspot changes you see here, and without their help, 
>> the foreign linker support wouldn't be what it is today. As usual, a big 
>> thank to Paul Sandoz, who provided many insights (often by trying the bits 
>> first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the 
>> interface is fairly simple; you can load a library by name, or absolute 
>> path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; 
>> it is, at its core, an aggregate of memory layouts for the function 
>> arguments/return type. A function descriptor is used to describe the 
>> signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: 
>> `downcallHandle` and `upcallStub`; the first takes a native symbol (as 
>> obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` 
>> and returns a `MethodHandle` instance which can be used to call the target 
>> native symbol. The second takes an existing method handle, and a 
>> `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a 
>> code stub allocated by the VM which acts as a trampoline from native code to 
>> the user-provided method handle. This is very useful for implementing 
>> upcalls.
>>* This class also contains the various layout constants that should be 
>> used by clients when describing native signatures (e.g. `C_LONG` and 
>> friends); these layouts contain additional ABI classfication information (in 
>> the form of layout attributes) which is used by the runtime to *infer* how 
>> Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients 
>> can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically 
>> related allocations; that is, rather than allocating separate memory 
>> segments using separate *try-with-resource* constructs, a `NativeScope` 
>> allows clients to use a _single_ block, and allocate all the required 
>> segments there. This is not only an usability boost, but also a performance 
>> boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows 
>> a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong 
>> when requesting a native method handle. For instance, the description of the 
>> native signature might be wrong (e.g. have too 

Re: RFR: 8254231: Implementation of Foreign Linker API (Incubator) [v9]

[Paul Sandoz]

On Wed, 21 Oct 2020 11:33:27 GMT, Maurizio Cimadamore  
wrote:

>> This patch contains the changes associated with the first incubation round 
>> of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory 
>> access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from 
>> Java code without the need of intermediate JNI glue code. In order to do 
>> this, native calls are modeled through the MethodHandle API. I suggest 
>> reading the writeup [4] I put together few weeks ago, which illustrates what 
>> the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* 
>> reviews. For this reasons, I'm attaching a webrev which contains only the 
>> differences between this PR and the memory access PR. I will be periodically 
>> uploading new webrevs, as new iterations come out, to try and make the life 
>> of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main 
>> architects of all the hotspot changes you see here, and without their help, 
>> the foreign linker support wouldn't be what it is today. As usual, a big 
>> thank to Paul Sandoz, who provided many insights (often by trying the bits 
>> first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the 
>> interface is fairly simple; you can load a library by name, or absolute 
>> path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; 
>> it is, at its core, an aggregate of memory layouts for the function 
>> arguments/return type. A function descriptor is used to describe the 
>> signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: 
>> `downcallHandle` and `upcallStub`; the first takes a native symbol (as 
>> obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` 
>> and returns a `MethodHandle` instance which can be used to call the target 
>> native symbol. The second takes an existing method handle, and a 
>> `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a 
>> code stub allocated by the VM which acts as a trampoline from native code to 
>> the user-provided method handle. This is very useful for implementing 
>> upcalls.
>>* This class also contains the various layout constants that should be 
>> used by clients when describing native signatures (e.g. `C_LONG` and 
>> friends); these layouts contain additional ABI classfication information (in 
>> the form of layout attributes) which is used by the runtime to *infer* how 
>> Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients 
>> can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically 
>> related allocations; that is, rather than allocating separate memory 
>> segments using separate *try-with-resource* constructs, a `NativeScope` 
>> allows clients to use a _single_ block, and allocate all the required 
>> segments there. This is not only an usability boost, but also a performance 
>> boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows 
>> a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong 
>> when requesting a native method handle. For instance, the description of the 
>> native signature might be wrong (e.g. have too 

Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v5]

[Paul Sandoz]

On Fri, 9 Oct 2020 11:34:56 GMT, Maurizio Cimadamore  
wrote:

>> This patch contains the changes associated with the third incubation round 
>> of the foreign memory access API incubation
>> (see JEP 393 [1]). This iteration focus on improving the usability of the 
>> API in 3 main ways:
>> * first, by providing a way to obtain truly *shared* segments, which can be 
>> accessed and closed concurrently from
>>   multiple threads
>> * second, by providing a way to register a memory segment against a 
>> `Cleaner`, so as to have some (optional) guarantee
>>   that the memory will be deallocated, eventually
>> * third, by not requiring users to dive deep into var handles when they 
>> first pick up the API; a new `MemoryAccess` class
>>   has been added, which defines several useful dereference routines; these 
>> are really just thin wrappers around memory
>>   access var handles, but they make the barrier of entry for using this API 
>> somewhat lower.
>> 
>> A big conceptual shift that comes with this API refresh is that the role of 
>> `MemorySegment` and `MemoryAddress` is not
>> the same as it used to be; it used to be the case that a memory address 
>> could (sometimes, not always) have a back link
>> to the memory segment which originated it; additionally, memory access var 
>> handles used `MemoryAddress` as a basic unit
>> of dereference.  This has all changed as per this API refresh;  now a 
>> `MemoryAddress` is just a dumb carrier which
>> wraps a pair of object/long addressing coordinates; `MemorySegment` has 
>> become the star of the show, as far as
>> dereferencing memory is concerned. You cannot dereference memory if you 
>> don't have a segment. This improves usability
>> in a number of ways - first, it is a lot easier to wrap native addresses 
>> (`long`, essentially) into a `MemoryAddress`;
>> secondly, it is crystal clear what a client has to do in order to 
>> dereference memory: if a client has a segment, it can
>> use that; otherwise, if the client only has an address, it will have to 
>> create a segment *unsafely* (this can be done
>> by calling `MemoryAddress::asSegmentRestricted`).  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.   A big thank to Erik Osterlund,
>> Vladimir Ivanov and David Holmes, without whom the work on shared memory 
>> segment would not have been possible; also I'd
>> like to thank Paul Sandoz, whose insights on API design have been very 
>> helpful in this journey.  Thanks  Maurizio
>> Javadoc:   
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> Specdiff:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254163
>> 
>> 
>> 
>> ### API Changes
>> 
>> * `MemorySegment`
>>   * drop factory for restricted segment (this has been moved to 
>> `MemoryAddress`, see below)
>>   * added a no-arg factory for a native restricted segment representing 
>> entire native heap
>>   * rename `withOwnerThread` to `handoff`
>>   * add new `share` method, to create shared segments
>>   * add new `registerCleaner` method, to register a segment against a cleaner
>>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>>   * add some `asSlice` overloads (to make up for the fact that now segments 
>> are more frequently used as cursors)
>>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement 
>> `Addressable`)
>> * `MemoryAddress`
>>   * drop `segment` accessor
>>   * drop `rebase` method and replace it with `segmentOffset` which returns 
>> the offset (a `long`) of this address relative
>> to a given segment
>> * `MemoryAccess`
>>   * New class supporting several static dereference helpers; the helpers are 
>> organized by carrier and access mode, where a
>> carrier is one of the usual suspect (a Java primitive, minus `boolean`); 
>> the access mode can be simple (e.g. access
>> base address of given segment), or indexed, in which case the accessor 
>> takes a segment and either a low-level byte
>> offset,or a high level logical index. The classification is reflected in 
>> the naming scheme (e.g. `

Re: RFR: 8254162: Implementation of Foreign-Memory Access API (Third Incubator) [v3]

[Paul Sandoz]

On Thu, 8 Oct 2020 13:59:20 GMT, Maurizio Cimadamore  
wrote:

>> This patch contains the changes associated with the third incubation round 
>> of the foreign memory access API incubation
>> (see JEP 393 [1]). This iteration focus on improving the usability of the 
>> API in 3 main ways:
>> * first, by providing a way to obtain truly *shared* segments, which can be 
>> accessed and closed concurrently from
>>   multiple threads
>> * second, by providing a way to register a memory segment against a 
>> `Cleaner`, so as to have some (optional) guarantee
>>   that the memory will be deallocated, eventually
>> * third, by not requiring users to dive deep into var handles when they 
>> first pick up the API; a new `MemoryAccess` class
>>   has been added, which defines several useful dereference routines; these 
>> are really just thin wrappers around memory
>>   access var handles, but they make the barrier of entry for using this API 
>> somewhat lower.
>> 
>> A big conceptual shift that comes with this API refresh is that the role of 
>> `MemorySegment` and `MemoryAddress` is not
>> the same as it used to be; it used to be the case that a memory address 
>> could (sometimes, not always) have a back link
>> to the memory segment which originated it; additionally, memory access var 
>> handles used `MemoryAddress` as a basic unit
>> of dereference.  This has all changed as per this API refresh;  now a 
>> `MemoryAddress` is just a dumb carrier which
>> wraps a pair of object/long addressing coordinates; `MemorySegment` has 
>> become the star of the show, as far as
>> dereferencing memory is concerned. You cannot dereference memory if you 
>> don't have a segment. This improves usability
>> in a number of ways - first, it is a lot easier to wrap native addresses 
>> (`long`, essentially) into a `MemoryAddress`;
>> secondly, it is crystal clear what a client has to do in order to 
>> dereference memory: if a client has a segment, it can
>> use that; otherwise, if the client only has an address, it will have to 
>> create a segment *unsafely* (this can be done
>> by calling `MemoryAddress::asSegmentRestricted`).  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.   A big thank to Erik Osterlund,
>> Vladimir Ivanov and David Holmes, without whom the work on shared memory 
>> segment would not have been possible; also I'd
>> like to thank Paul Sandoz, whose insights on API design have been very 
>> helpful in this journey.  Thanks  Maurizio
>> Javadoc:   
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> Specdiff:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254163
>> 
>> 
>> 
>> ### API Changes
>> 
>> * `MemorySegment`
>>   * drop factory for restricted segment (this has been moved to 
>> `MemoryAddress`, see below)
>>   * added a no-arg factory for a native restricted segment representing 
>> entire native heap
>>   * rename `withOwnerThread` to `handoff`
>>   * add new `share` method, to create shared segments
>>   * add new `registerCleaner` method, to register a segment against a cleaner
>>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>>   * add some `asSlice` overloads (to make up for the fact that now segments 
>> are more frequently used as cursors)
>>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement 
>> `Addressable`)
>> * `MemoryAddress`
>>   * drop `segment` accessor
>>   * drop `rebase` method and replace it with `segmentOffset` which returns 
>> the offset (a `long`) of this address relative
>> to a given segment
>> * `MemoryAccess`
>>   * New class supporting several static dereference helpers; the helpers are 
>> organized by carrier and access mode, where a
>> carrier is one of the usual suspect (a Java primitive, minus `boolean`); 
>> the access mode can be simple (e.g. access
>> base address of given segment), or indexed, in which case the accessor 
>> takes a segment and either a low-level byte
>> offset,or a high level logical index. The classification is reflected in 
>> the naming scheme (e.g. `

Re: RFR: 8156071: List.of: reduce array copying during creation

[Paul Sandoz]

On Thu, 1 Oct 2020 00:13:28 GMT, Stuart Marks  wrote:

> Plumb new internal static factory method to trust the array passed in, 
> avoiding unnecessary copying. JMH results for
> the benchmark show about 15% improvement for the cases that were optimized, 
> namely the 3 to 10 fixed arg cases.
> # VM options: -verbose:gc -XX:+UseParallelGC -Xms4g -Xmx4g --enable-preview 
> -verbose:gc -XX:+UsePara
> llelGC -Xms4g -Xmx4g -Xint
> # Warmup: 5 iterations, 1 s each
> # Measurement: 5 iterations, 2 s each
> 
> WITHOUT varargs optimization:
> 
> Benchmark Mode  Cnt Score Error   Units
> ListArgs.list00  thrpt   15  6019.539 ± 144.040  ops/ms
> ListArgs.list01  thrpt   15  1985.009 ±  40.606  ops/ms
> ListArgs.list02  thrpt   15  1854.812 ±  17.488  ops/ms
> ListArgs.list03  thrpt   15   963.866 ±  10.262  ops/ms
> ListArgs.list04  thrpt   15   908.116 ±   6.278  ops/ms
> ListArgs.list05  thrpt   15   848.607 ±  16.701  ops/ms
> ListArgs.list06  thrpt   15   822.282 ±   8.905  ops/ms
> ListArgs.list07  thrpt   15   780.057 ±  11.214  ops/ms
> ListArgs.list08  thrpt   15   745.295 ±  19.204  ops/ms
> ListArgs.list09  thrpt   15   704.596 ±  14.003  ops/ms
> ListArgs.list10  thrpt   15   696.436 ±   4.914  ops/ms
> ListArgs.list11  thrpt   15   661.908 ±  11.041  ops/ms
> 
> WITH varargs optimization:
> 
> Benchmark Mode  Cnt ScoreError   Units
> ListArgs.list00  thrpt   15  6172.298 ± 62.736  ops/ms
> ListArgs.list01  thrpt   15  1987.724 ± 45.468  ops/ms
> ListArgs.list02  thrpt   15  1843.419 ± 10.693  ops/ms
> ListArgs.list03  thrpt   15  1126.946 ± 30.952  ops/ms
> ListArgs.list04  thrpt   15  1050.440 ± 17.859  ops/ms
> ListArgs.list05  thrpt   15   999.275 ± 23.656  ops/ms
> ListArgs.list06  thrpt   15   948.844 ± 19.615  ops/ms
> ListArgs.list07  thrpt   15   897.541 ± 15.531  ops/ms
> ListArgs.list08  thrpt   15   853.359 ± 18.755  ops/ms
> ListArgs.list09  thrpt   15   826.394 ±  8.284  ops/ms
> ListArgs.list10  thrpt   15   779.231 ±  4.104  ops/ms
> ListArgs.list11  thrpt   15   650.888 ±  3.948  ops/ms

Looks good, i wondered why the performance results were so slow then i looked 
more closely and saw "-Xint" was used. I
usually don't ascribe much value to micro benchmarks run in interpreter only 
mode, but hey any shaving off startup time
is welcome. Less allocation is definitely welcome (although i do wish C2 was 
better at eliding redundant array
initialization and allocation).

-

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/449

Re: RFR: 8138732: Rename @HotSpotIntrinsicCandidate to @IntrinsicCandidate and move it to the jdk.internal.vm.annotation package [v2]

[Paul Sandoz]

On Wed, 9 Sep 2020 09:49:44 GMT, Philippe Marschall 
 wrote:

>> Hello, newbie here
>> 
>> I picked JDK-8138732 to work on because it has a "starter" label and I 
>> believe I understand what to do.
>> 
>> - I tried to update the copyright year to 2020 in every file.
>> - I decided to change `@since` from 9 to 16 since it is a new annotation 
>> name in a new package.
>> - I tried to keep code changes to a minimum, eg not change to imports if 
>> fully qualified class names are used instead of
>>   imports. In some cases I did minor reordering of imports to keep them 
>> sorted alphabetically.
>> - All tier1 tests pass.
>> - One jpackage/jlink tier2 test fails but I don't believe it is related.
>> - Some tier3 Swing tests fail but I don't think they are related.
>
> Philippe Marschall has refreshed the contents of this pull request, and 
> previous commits have been removed. The
> incremental views will show differences compared to the previous content of 
> the PR. The pull request contains one new
> commit since the last revision:
>   8138732: Rename HotSpotIntrinsicCandidate to IntrinsicCandidate

Marked as reviewed by psandoz (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/45

Re: RFR [15] 8241014: Miscellaneous typos in documentation comments

[Paul Sandoz]

+1

Paul.

> On Mar 13, 2020, at 8:42 AM, Pavel Rappo  wrote:
> 
> Hello,
> 
> Please review the change for https://bugs.openjdk.java.net/browse/JDK-8241014:
> 
>  http://cr.openjdk.java.net/~prappo/8241014/webrev.00/
> 
> This is a documentation cleanup. There are no code changes involved,
> and the changes in documentation are mostly trivial.
> 
> The following packages are affected:
> 
>java.lang,
>java.nio.file,
>java.nio.file.attribute,
>java.security,
>java.time.chrono,
>java.time.temporal,
>java.util,
>java.util.regex,
>java.util.stream,
>javax.crypto,
>javax.security.cert,
>javax.tools
> 
> That said, there are two changes that I'd prefer to be carefully reviewed by
> the experts in the corresponding areas.
> 
> The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser
> class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept and
> supported for the sake of backward compatibility. Sadly, we have a number of
> those in OpenJDK. Even though I performed reasonable checks, the proposed fix
> should better be verified by the security folk.
> 
> The second one is for the doc comment for the java.util.stream.Stream.collect 
> method.
> 
> @apiNote
> The following will accumulate strings into an ArrayList:
> 
> List asList = stringStream.collect(Collectors.toList());
> 
> Given that the spec for Collectors.toList() clearly says that
> 
>...There are no guarantees on the type, mutability, serializability, or
>thread-safety of the List returned;...
> 
> I'd assume that @apiNote should be fixed as proposed.
> 
> -Pavel
> 
> P.S. Apologies for spamming multiple mailing lists. 
> 

Re: RFR [15] 8241014: Miscellaneous typos in documentation comments

[Paul Sandoz]

--- a/src/java.base/share/classes/java/lang/invoke/MethodType.java
+++ b/src/java.base/share/classes/java/lang/invoke/MethodType.java
@@ -1379,12 +1379,12 @@
 
 /**
  * This implementation returns {@code true} if {@code obj} is 
another
- * {@code WeakEntry} whose referent is equals to this referent, or
- * if {@code obj} is equals to the referent of this. This allows
+ * {@code WeakEntry} whose referent equals to this referent, or
+ * if {@code obj} equals to the referent of this. This allows
  * lookups to be made without wrapping in a {@code WeakEntry}.
  *
  * @param obj the object to compare
- * @return true if {@code obj} is equals to this or the referent 
of this
+ * @return true if {@code obj} equals to this or the referent of 
this
  * @see MethodType#equals(Object)
  * @see Object#equals(Object)
 
Use either:

  whose referent is equal to this referent,

or 

  whose referent equals this referent,

The former is easier just delete the ’s’.

Other bits look good.

Paul.

> On Mar 13, 2020, at 7:03 PM, Ivan Gerasimov  wrote:
> 
> Hi Pavel!
> 
> Can this please be combined with my collection of typos?
> 
> http://cr.openjdk.java.net/~igerasim/XXX-typos/00/webrev/
> 
> Just to save cycles on reviewing :)
> 
> With kind regards,
> 
> Ivan
> 
> 
> On 3/13/20 8:42 AM, Pavel Rappo wrote:
>> Hello,
>> 
>> Please review the change for 
>> https://bugs.openjdk.java.net/browse/JDK-8241014:
>> 
>>   http://cr.openjdk.java.net/~prappo/8241014/webrev.00/
>> 
>> This is a documentation cleanup. There are no code changes involved,
>> and the changes in documentation are mostly trivial.
>> 
>> The following packages are affected:
>> 
>> java.lang,
>> java.nio.file,
>> java.nio.file.attribute,
>> java.security,
>> java.time.chrono,
>> java.time.temporal,
>> java.util,
>> java.util.regex,
>> java.util.stream,
>> javax.crypto,
>> javax.security.cert,
>> javax.tools
>> 
>> That said, there are two changes that I'd prefer to be carefully reviewed by
>> the experts in the corresponding areas.
>> 
>> The first one is for a suspected typo in the javax.crypto.CryptoPolicyParser
>> class, "AlgrithomParameterSpec". It is not unheard-of for typos to be kept 
>> and
>> supported for the sake of backward compatibility. Sadly, we have a number of
>> those in OpenJDK. Even though I performed reasonable checks, the proposed fix
>> should better be verified by the security folk.
>> 
>> The second one is for the doc comment for the 
>> java.util.stream.Stream.collect method.
>> 
>>  @apiNote
>>  The following will accumulate strings into an ArrayList:
>> 
>>  List asList = stringStream.collect(Collectors.toList());
>> 
>> Given that the spec for Collectors.toList() clearly says that
>> 
>> ...There are no guarantees on the type, mutability, serializability, or
>> thread-safety of the List returned;...
>> 
>> I'd assume that @apiNote should be fixed as proposed.
>> 
>> -Pavel
>> 
>> P.S. Apologies for spamming multiple mailing lists.
>> 
> -- 
> With kind regards,
> Ivan Gerasimov
> 

Re: RFR 8177784 Use CounterMode intrinsic for AES/GCM

[Paul Sandoz]

> On 7 Apr 2017, at 12:47, Anthony Scarpino  wrote:
> 
> On 04/07/2017 06:58 AM, Chris Hegarty wrote:
>> On 06/04/17 21:39, Anthony Scarpino wrote:
>>> 
>>> I'd like to get a review for this performance change to use the existing
>>> CounterMode parallelized intrinsic instead of GCTR's own version. The
>>> two classes were nearly identical except for the doFinal() method which
>>> doesn't belong in CounterMode.java.
>>> 
>>> I could have been more aggressive with this change, but I'm looking to
>>> get this into 9, so I stayed away from completely merging GCTR into
>>> CounterMode in case of incompatibilities.  All tests security and
>>> hotspot tests pass.
>>> 
>>> http://cr.openjdk.java.net/~ascarpino/8177784/webrev/
>> 
>> This change looks good to me. Trivially, the class-level comment in
>> GCTR should be updated ( it refers to removed fields ). Also,
>> CounterMode.counter could be protected ( rather than package-private ).
>> 
>> -Chris.
> 
> Thanks Chris,
> 
> I left CounterMode.counter as package-private because the package is what 
> becomes the SunJCE provider.  I don't believe there should be any outside 
> package classes accessing this code.
> 
> I updated the webrev at with the comment update:
>  http://cr.openjdk.java.net/~ascarpino/8177784/webrev.01/
> 

It’s the same pattern for “iv” with CounterMode and FeedbackCipher, although i 
prefer protected as well if never accessed by other classes in the same 
package, it makes it easier to reason about the code, since i know more about 
what can access it.

Suggestion, take it or leave it: personally i would prefer to see an additional 
constructor in CounterMode:

  GCTR(SymmetricCipher cipher, byte[] initialCounterBlk) {
super(cipher, checkBlockSize(initialCounterBlk));
   }

Where new CounterMode constructor performs the clone, assignmentm and reset, 
the static method checkBlockSize checks the array length is equal to 
AES_BLOCK_SIZE Thereby you have a cleaner separation of concerns.

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: JDK 10 RFR of JDK-8173903: Update various tests to pass under JDK 10

[Paul Sandoz]

+1

Paul.

> On 3 Feb 2017, at 11:21, joe darcy  wrote:
> 
> Hello,
> 
> After the version update to "10" in JDK 10 ( JDK-8029942 ), various libraries 
> tests failed including:
> 
>java/lang/module/MultiReleaseJarTest.java
>java/security/Provider/ProviderVersionCheck.java
> sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java
> 
> These tests need to be updated for the new JDK. When it is clear how to do 
> so, I've updated the tests in a way so that they don't need to be updated 
> again for JDK 11.
> 
> Webrev:
> 
>http://cr.openjdk.java.net/~darcy/8173903.0/
> 
> and patch below. I'll update the other copyrights before pushing.
> 
> Thanks,
> 
> -Joe
> 
> 
> diff -r 72f33dbfcf3b test/java/lang/module/MultiReleaseJarTest.java
> --- a/test/java/lang/module/MultiReleaseJarTest.javaTue Jan 31 19:26:10 
> 2017 -0500
> +++ b/test/java/lang/module/MultiReleaseJarTest.javaFri Feb 03 11:18:23 
> 2017 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 2016, 2017, 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
> @@ -65,7 +65,7 @@
> 
> private static final String MODULE_INFO = "module-info.class";
> 
> -private static final int RELEASE = Runtime.version().major();
> +private static final String RELEASE = "" + Runtime.version().major();
> 
> // are multi-release JARs enabled?
> private static final boolean MULTI_RELEASE;
> @@ -88,8 +88,8 @@
> .moduleInfo("module-info.class", descriptor)
> .resource("p/Main.class")
> .resource("p/Helper.class")
> -.resource("META-INF/versions/9/p/Helper.class")
> - .resource("META-INF/versions/9/p/internal/Helper9.class")
> +.resource("META-INF/versions/" + RELEASE + "/p/Helper.class")
> +.resource("META-INF/versions/" + RELEASE + 
> "/p/internal/HelperNew.class")
> .build();
> 
> // find the module
> @@ -131,9 +131,9 @@
> .moduleInfo(MODULE_INFO, descriptor1)
> .resource("p/Main.class")
> .resource("p/Helper.class")
> -.moduleInfo("META-INF/versions/9/" + MODULE_INFO, 
> descriptor2)
> -.resource("META-INF/versions/9/p/Helper.class")
> - .resource("META-INF/versions/9/p/internal/Helper9.class")
> +.moduleInfo("META-INF/versions/" + RELEASE + "/" + 
> MODULE_INFO, descriptor2)
> +.resource("META-INF/versions/" + RELEASE + "/p/Helper.class")
> +.resource("META-INF/versions/" + RELEASE + 
> "/p/internal/HelperNew.class")
> .build();
> 
> // find the module
> @@ -161,8 +161,8 @@
> Path jar = new JarBuilder(name)
> .resource("p/Main.class")
> .resource("p/Helper.class")
> -.resource("META-INF/versions/9/p/Helper.class")
> - .resource("META-INF/versions/9/p/internal/Helper9.class")
> +.resource("META-INF/versions/" + RELEASE + "/p/Helper.class")
> +.resource("META-INF/versions/" + RELEASE + 
> "/p/internal/HelperNew.class")
> .build();
> 
> // find the module
> @@ -200,7 +200,7 @@
> 
> Path jar = new JarBuilder(name)
> .moduleInfo(MODULE_INFO, descriptor1)
> -.moduleInfo("META-INF/versions/9/" + MODULE_INFO, 
> descriptor2)
> +.moduleInfo("META-INF/versions/" + RELEASE + "/" + 
> MODULE_INFO, descriptor2)
> .build();
> 
> // find the module
> diff -r 72f33dbfcf3b test/java/security/Provider/ProviderVersionCheck.java
> --- a/test/java/security/Provider/ProviderVersionCheck.javaTue Jan 31 
> 19:26:10 2017 -0500
> +++ b/test/java/security/Provider/ProviderVersionCheck.javaFri Feb 03 
> 11:18:23 2017 -0800
> @@ -42,7 +42,7 @@
> 
> for (Provider p: Security.getProviders()) {
> System.out.print(p.getName() + " ");
> -if (p.getVersion() != 9.0d) {
> +if (p.getVersion() != 10.0d) {
> System.out.println("failed. " + "Version received was " +
> p.getVersion());
> failure = true;
> diff -r 72f33dbfcf3b 
> test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java
> --- a/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java 
> Tue Jan 31 19:26:10 2017 -0500
> +++ b/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java 
> Fri Feb 03 11:18:23 2017 -0800
> @@ -74,7 +74,8 @@
> private static final String KEYPASS = "changeit";
> private static final String SIGNED_JAR = "Signed.jar";
> private static final String POLICY_FILE = "SignedJar.policy";
> -private static final String VERSION_MESSAGE 

Re: RFR [9] 8144995: Move sun.misc.HexDumpEncoder to sun.security.util

[Paul Sandoz]

Looks ok to me,
Paul.

> On 10 Dec 2015, at 16:56, Chris Hegarty  wrote:
> 
> sun.misc.HexDumpEncoder is an internal private API that is used almost
> exclusively by the security library code. It should be moved out of sun.misc
> and into a package more appropriate to its use, sun.security.util.
> 
> HexDumpEncoder extends CharacterEncoder, which is slated for later
> removal, so the minimal implementation was copied in-place ( no new
> code ).
> 
> http://cr.openjdk.java.net/~chegar/8144995/00/webrev/
> 
> -Chris.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8144995



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR [9] 8144480: Remove test dependencies on sun.misc.BASE64Encoder and BASE64Decoder

[Paul Sandoz]

> On 2 Dec 2015, at 13:08, Chris Hegarty  wrote:
> 
> The regression tests in the jdk should be updated, where possible, to use 
> java.util.Base64.
> 
> http://cr.openjdk.java.net/~chegar/Base64-test-updates/webrev/
> 

+1

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils

[Paul Sandoz]

> On 7 Oct 2015, at 22:28, Alan Bateman  wrote:
> 
> 
> On 07/10/2015 20:57, Chris Hegarty wrote:
>> :
>> I updated Connection with a readFully that has the same
>> semantics as IOUtils.
>> 
>>   http://cr.openjdk.java.net/~chegar/8138978/webrev.01/jdk/
>> 
> I agree with Roger. Couldn't this be changed to use create an array of length 
> seqlen and use readNBytes?
> 

It reads at most “seqlen" bytes, so the array may be larger than necessary, 
which might be ok depending on whether one can trust "seqlen".


The following pattern occurs a few times:

  byte[] b = is.readAllBytes();
  if (len !- -1 && b.length != len) throw new EOFException(…)

A further useful addition to consider would be an IS.readFulyl(int 
expectedLength).

I suspect you could probably remove sun.security.util.IOUtils, if the 
assumption is correct than one never relies on a length of -1 or 
Integer.MAX_VALUE to signal “readAllBytes”. That seems to be the case since all 
security usages pass in a true value for readAll. From what i can tell the 
length passed in is never < 0, since it is checked before hand. So that leaves 
the Integer.MAX_VALUE case, which i am not sure is intentional in the 
use-cases, as that will mean readAllBytes and not readNBytes.

Paul



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils

[Paul Sandoz]

> On 8 Oct 2015, at 10:46, Chris Hegarty  wrote:
>> It reads at most “seqlen" bytes, so the array may be larger than necessary, 
>> which might be ok depending on whether one can trust "seqlen”.
> 
> We do no trust ‘seqlen’. :-(
> 

Good!


>> The following pattern occurs a few times:
>> 
>> byte[] b = is.readAllBytes();
>> if (len !- -1 && b.length != len) throw new EOFException(…)
>> 
>> A further useful addition to consider would be an IS.readFulyl(int 
>> expectedLength).
> 
> Yes, I think a variant of readNBytes(long expectedLength),
> would  be a useful addition. I can file a bug and add it to
> the I/O grab bag, 6852033 [1]. Then a further round of
> cleanup could possibly remove IOUtils completely.
> 

Ok.

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: The future of Serialization

[Paul Sandoz]

On Aug 9, 2014, at 7:20 PM, Brian Goetz brian.go...@oracle.com wrote:

 I've noticed there's not much interest in improving Serialization on
 these lists.  This makes me wonder if java Serialization has lost
 relevance in recent years with the rise of protocol buffers apache
 thrift and other means of data transfer over byte streams.
 
 I sense your frustration, but I think you may be reaching the wrong 
 conclusion.  The lack of response is probably not evidence that there's no 
 interest in fixing serialization; its that fixing serialization, with all the 
 constraints that fix entails, is just really really hard, and its much 
 easier to complain about it (and even say let's just get rid of it) than to 
 fix it.
 
 Should Serializable eventually be deprecated? Should Serialization be
 disabled by default? Should a new mechanism be developed? If a new
 mechanism is developed, what about circular object relationships?
 
 As I delved into my own explorations of serialization, I started to realize 
 why such a horrible approach was the one that was ultimately chosen; while 
 serialization is horrible and awful and leaky and insecure and complex and 
 brittle, it does address problems like cyclic data structures and independent 
 evolution of subclass and superclass better than the clean models.
 
 My conclusion is, at best, a new mechanism would have to live side-by-side 
 with the old one, since it could only handle 95% of the cases.  It might 
 handle those 95% much better -- more cleanly, securely, and allowing easier 
 schema evolution -- but the hard cases are still there.  Still, reducing the 
 use of the horrible old mechanism may still be a worthy goal, even if it 
 can't be killed outright.
 


Also many serialization-based libraries use sun.misc.Unsafe or 
sun.reflect.ReflectionFactory for various reasons (with backup plans if such 
classes are not available or accessible).

As part to the future of serialization i think we need to evaluate libraries 
such as XStream and Objenesis  to see what unsafe/internal mechanisms can be 
replaced by functionally equivalent safe public mechanisms.

I have more questions than answers at the moment with regards to that :-(

Paul.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: RFR (S) 8035974: Refactor DigestBase.engineUpdate() method for better code generation by JIT compiler

[Paul Sandoz]

On May 22, 2014, at 1:34 AM, Vladimir Kozlov vladimir.koz...@oracle.com wrote:

 http://cr.openjdk.java.net/~kvn/8035974/webrev
 https://bugs.openjdk.java.net/browse/JDK-8035974
 
 Contributed by James Cheng and modified by me.
 

Looks good to me.

Paul.

 To use intrinsics to accelerate SHA operations on multiple blocks [1], it is 
 needed to pull a loop out of DigestBase.engineUpdate() and make a new method 
 implCompressMultiBlock() which contains only the loop and can be intrinsified.
 
 On platforms which does not use intrinsic implCompressMultiBlock() method 
 will be inlined by JIT and the same code will be generated as before. So no 
 performance regression with the pure Java SUN provider is expected.
 
 About arithmetic change. limit = ofs + len will not overflow integer because 
 ofs = b.length - len (there is check).
 
 Tested with jdk jtreg tests and new hotspot jtreg test James wrote for 
 8035968.
 
 Thanks,
 Vladimir
 
 [1] https://bugs.openjdk.java.net/browse/JDK-8035968



signature.asc
Description: Message signed with OpenPGP using GPGMail

hg: jdk8/tl/jdk: 4 new changesets

[paul . sandoz]

Changeset: 9f098aed44c0
Author:anazarov
Date:  2014-01-31 12:01 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9f098aed44c0

8032025: Update repeating annotations demo
Reviewed-by: jfranck

+ 
src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Device.java
+ 
src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Kettle.xml
+ 
src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Module.java
+ 
src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/PluginChecker.java
+ 
src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/Require.java
+ 
src/share/sample/annotations/DependencyChecker/PluginChecker/src/checker/RequireContainer.java
+ 
src/share/sample/annotations/DependencyChecker/Plugins/src/plugins/BoilerPlugin.java
+ 
src/share/sample/annotations/DependencyChecker/Plugins/src/plugins/ExtendedBoilerPlugin.java
+ 
src/share/sample/annotations/DependencyChecker/Plugins/src/plugins/TimerPlugin.java
+ src/share/sample/annotations/Validator/src/PositiveIntegerSupplier.java
+ src/share/sample/annotations/Validator/src/SupplierValidator.java
+ src/share/sample/annotations/Validator/src/Validate.java
+ src/share/sample/annotations/Validator/src/Validator.java
+ src/share/sample/annotations/index.html

Changeset: f72a8df6a2ed
Author:anazarov
Date:  2014-01-31 12:01 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f72a8df6a2ed

8031650: Update bulk operation demo
Reviewed-by: psandoz, mduigou

+ src/share/sample/lambda/BulkDataOperations/index.html
+ src/share/sample/lambda/BulkDataOperations/src/CSVProcessor.java
+ src/share/sample/lambda/BulkDataOperations/src/Grep.java
+ src/share/sample/lambda/BulkDataOperations/src/PasswordGenerator.java
+ src/share/sample/lambda/BulkDataOperations/src/WC.java

Changeset: 4574011c1689
Author:anazarov
Date:  2014-01-31 12:01 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4574011c1689

8032020: Update try-with-resources demo
Reviewed-by: darcy, alanb, smarks

+ src/share/sample/try-with-resources/index.html
+ src/share/sample/try-with-resources/src/CustomAutoCloseableSample.java
+ src/share/sample/try-with-resources/src/Unzip.java
+ src/share/sample/try-with-resources/src/ZipCat.java

Changeset: a4f68fc5f353
Author:psandoz
Date:  2014-01-31 12:01 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a4f68fc5f353

8032056: Create demo to illustrate new practices of the default methods usage
Reviewed-by: briangoetz, rfield, psandoz
Contributed-by: taras.led...@oracle.com

+ src/share/sample/lambda/DefaultMethods/ArrayIterator.java
+ src/share/sample/lambda/DefaultMethods/DiamondInheritance.java
+ src/share/sample/lambda/DefaultMethods/Inheritance.java
+ src/share/sample/lambda/DefaultMethods/MixIn.java
+ src/share/sample/lambda/DefaultMethods/Reflection.java
+ src/share/sample/lambda/DefaultMethods/SimplestUsage.java

hg: jdk8/tl/jdk: 8032190: Specifications of stream flatMap methods should require mapped streams to be closed

[paul . sandoz]

Changeset: 68eb0c55a8c0
Author:psandoz
Date:  2014-01-21 10:49 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68eb0c55a8c0

8032190: Specifications of stream flatMap methods should require mapped streams 
to be closed
Reviewed-by: chegar, alanb

! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/Stream.java

hg: jdk8/tl/jdk: 8031187: DoubleStream.count is incorrect for a stream containing Integer.MAX_VALUE elements

[paul . sandoz]

Changeset: 630a92015993
Author:psandoz
Date:  2014-01-09 10:52 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/630a92015993

8031187: DoubleStream.count is incorrect for a stream containing  
Integer.MAX_VALUE elements
Reviewed-by: darcy

! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountLargeTest.java
+ test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest.java

hg: jdk8/tl/jdk: 8028564: Concurrent calls to CHM.put can fail to add the key/value to the map

[paul . sandoz]

Changeset: dc2f0c40399a
Author:psandoz
Date:  2013-12-05 09:44 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dc2f0c40399a

8028564: Concurrent calls to CHM.put can fail to add the key/value to the map
Reviewed-by: psandoz, chegar, alanb
Contributed-by: Doug Lea d...@cs.oswego.edu

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
+ test/java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java
+ test/java/util/concurrent/ConcurrentHashMap/ConcurrentContainsKeyTest.java

hg: jdk8/tl/jdk: 8029164: Race condition in CompletableFuture.thenCompose with asynchronous task

[paul . sandoz]

Changeset: 2aa455506c49
Author:psandoz
Date:  2013-12-04 10:27 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2aa455506c49

8029164: Race condition in CompletableFuture.thenCompose with asynchronous task
Reviewed-by: dl, chegar, mduigou

! src/share/classes/java/util/concurrent/CompletableFuture.java
+ test/java/util/concurrent/CompletableFuture/ThenComposeAsyncTest.java

hg: jdk8/tl/jdk: 8028516: Java doc error in Int/Long/Double/Stream.peek

[paul . sandoz]

Changeset: 1f45b24ffe4b
Author:psandoz
Date:  2013-11-25 09:55 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f45b24ffe4b

8028516: Java doc error in Int/Long/Double/Stream.peek
Reviewed-by: chegar

! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/Stream.java

hg: jdk8/tl/jdk: 8027712: DistinctOpTest fails for unordered test

[paul . sandoz]

Changeset: d5b3f83ffc40
Author:psandoz
Date:  2013-11-05 12:08 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5b3f83ffc40

8027712: DistinctOpTest fails for unordered test
Reviewed-by: henryjen, alanb

! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java

hg: jdk8/tl/jdk: 8020061: Clarify reporting characteristics between splits

[paul . sandoz]

Changeset: 1cd20806fd5c
Author:psandoz
Date:  2013-10-09 15:19 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1cd20806fd5c

8020061: Clarify reporting characteristics between splits
Reviewed-by: alanb, chegar

! src/share/classes/java/util/Spliterator.java

hg: jdk8/tl/jdk: 8025136: SplittableRandom enchancements

[paul . sandoz]

Changeset: b90dcd1a71bf
Author:psandoz
Date:  2013-10-08 11:17 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b90dcd1a71bf

8025136: SplittableRandom enchancements
Reviewed-by: psandoz, martin
Contributed-by: Doug Lea d...@cs.oswego.edu, Guy Steele 
guy.ste...@oracle.com

! src/share/classes/java/util/Random.java
! src/share/classes/java/util/SplittableRandom.java
! src/share/classes/java/util/concurrent/ThreadLocalRandom.java

hg: jdk8/tl/jdk: 2 new changesets

[paul . sandoz]

Changeset: 811c35a6a58f
Author:psandoz
Date:  2013-10-02 16:34 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/811c35a6a58f

8025534: Unsafe typecast in java.util.stream.Streams.Nodes
8025538: Unsafe typecast in java.util.stream.SpinedBuffer
8025533: Unsafe typecast in 
java.util.stream.Streams.RangeIntSpliterator.splitPoint()
8025525: Unsafe typecast in java.util.stream.Node.OfPrimitive.asArray()
Reviewed-by: chegar

! src/share/classes/java/util/stream/Node.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/SortedOps.java
! src/share/classes/java/util/stream/SpinedBuffer.java
! src/share/classes/java/util/stream/Streams.java

Changeset: c55a7941050c
Author:psandoz
Date:  2013-10-03 10:59 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c55a7941050c

8025567: Mark relevant public stream tests as serialization hostile
Reviewed-by: alanb

! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java

hg: jdk8/tl/jdk: 8024253: ThreadLocal random can use SecureRandom for the initial seed

[paul . sandoz]

Changeset: 7913855ff66c
Author:psandoz
Date:  2013-09-20 11:07 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7913855ff66c

8024253: ThreadLocal random can use SecureRandom for the initial seed
Reviewed-by: psandoz, chegar, alanb
Contributed-by: Doug Lea d...@cs.oswego.edu, Peter Levart 
peter.lev...@gmail.com, Guy Steele guy.ste...@oracle.com

! src/share/classes/java/util/SplittableRandom.java
! src/share/classes/java/util/concurrent/ThreadLocalRandom.java
! test/java/util/concurrent/ThreadLocalRandom/ThreadLocalRandomTest.java

hg: jdk8/tl/jdk: 8024341: j.u.regex.Pattern.splitAsStream() doesn't correspond to split() method if using an example from the spec

[paul . sandoz]

Changeset: c30dc8e7744e
Author:psandoz
Date:  2013-09-20 17:11 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c30dc8e7744e

8024341: j.u.regex.Pattern.splitAsStream() doesn't correspond to split() method 
if using an example from the spec
Reviewed-by: alanb

! src/share/classes/java/util/regex/Pattern.java
+ test/java/util/regex/PatternStreamTest.java
- test/java/util/regex/PatternTest.java

hg: jdk8/tl/jdk: 8025002: .codePoints().sorted().iterator().hasNext() causes NegativeArraySizeException

[paul . sandoz]

Changeset: f36714707c38
Author:psandoz
Date:  2013-09-18 10:49 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f36714707c38

8025002: .codePoints().sorted().iterator().hasNext() causes 
NegativeArraySizeException
Reviewed-by: henryjen, alanb

! src/share/classes/java/lang/CharSequence.java
! test/java/lang/CharSequence/DefaultTest.java

hg: jdk8/tl/jdk: 8024405: Spliterators.spliterator should support CONCURRENT characteristic

[paul . sandoz]

Changeset: 0ef7ddef9de0
Author:psandoz
Date:  2013-09-19 20:41 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ef7ddef9de0

8024405: Spliterators.spliterator should support CONCURRENT characteristic
Reviewed-by: martin

! src/share/classes/java/util/Spliterator.java
! src/share/classes/java/util/Spliterators.java
! test/java/util/Spliterator/SpliteratorCharacteristics.java
! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java

hg: jdk8/tl/jdk: 8010293: java/util/concurrent/ConcurrentHashMap/toArray.java fails intermittently

[paul . sandoz]

Changeset: ff6c76f7733e
Author:psandoz
Date:  2013-09-02 11:59 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff6c76f7733e

8010293: java/util/concurrent/ConcurrentHashMap/toArray.java fails 
intermittently
Reviewed-by: forax, chegar, alanb
Contributed-by: Doug Lea d...@cs.oswego.edu, Peter Levart 
peter.lev...@gmail.com, Paul Sandoz paul.san...@oracle.com

! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! test/java/util/concurrent/ConcurrentHashMap/toArray.java

hg: jdk8/tl/jdk: 8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom

[paul . sandoz]

Changeset: b1f41565b806
Author:psandoz
Date:  2013-08-28 22:11 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b1f41565b806

8023155: Ensure functional consistency across Random, ThreadLocalRandom, 
SplittableRandom
Reviewed-by: mduigou
Contributed-by: Doug Lea d...@cs.oswego.edu, Paul Sandoz 
paul.san...@oracle.com

! src/share/classes/java/util/Random.java
! src/share/classes/java/util/concurrent/ThreadLocalRandom.java
! test/java/util/Random/RandomStreamTest.java
+ test/java/util/Random/RandomTest.java
! test/java/util/SplittableRandom/SplittableRandomTest.java
+ test/java/util/concurrent/ThreadLocalRandom/ThreadLocalRandomTest.java

hg: jdk8/tl/jdk: 8023234: StampedLock serializes readers on writer unlock

[paul . sandoz]

Changeset: 8a36fc7f494c
Author:shade
Date:  2013-08-26 17:50 +0400
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a36fc7f494c

8023234: StampedLock serializes readers on writer unlock
Summary: Sync-up the fix from jsr166 CVS, signal more readers on writer unlock
Reviewed-by: martin, shade
Contributed-by: Doug Lea d...@cs.oswego.edu

! src/share/classes/java/util/concurrent/locks/StampedLock.java
+ test/java/util/concurrent/locks/StampedLock/ReadersUnlockAfterWriteUnlock.java

hg: jdk8/tl/jdk: 8020292: j.u.SplittableRandom

[paul . sandoz]

Changeset: 5ce9025c9e1a
Author:psandoz
Date:  2013-08-26 22:55 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ce9025c9e1a

8020292: j.u.SplittableRandom
Reviewed-by: mduigou
Contributed-by: Guy Steele guy.ste...@oracle.com, Doug Lea 
d...@cs.oswego.edu, Brian Goetz brian.go...@oracle.com, Paul Sandoz 
paul.san...@oracle.com

+ src/share/classes/java/util/SplittableRandom.java
+ test/java/util/SplittableRandom/SplittableRandomTest.java
+ 
test/java/util/stream/test/org/openjdk/tests/java/util/SplittableRandomTest.java

hg: jdk8/tl/jdk: 8022318: Document Spliterator characteristics and binding policy of java util concurrent collection impls

[paul . sandoz]

Changeset: 9e9f5713b26d
Author:psandoz
Date:  2013-08-06 14:26 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e9f5713b26d

8022318: Document Spliterator characteristics and binding policy of java util 
concurrent collection impls
Reviewed-by: chegar
Contributed-by: Martin Buchholz marti...@google.com, Paul Sandoz 
paul.san...@oracle.com

! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/share/classes/java/util/concurrent/ConcurrentHashMap.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/share/classes/java/util/concurrent/DelayQueue.java
! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/share/classes/java/util/concurrent/SynchronousQueue.java
! src/share/classes/java/util/concurrent/package-info.java

hg: jdk8/tl/jdk: 8014824: Document Spliterator characteristics and binding policy of java util collection impls

[paul . sandoz]

Changeset: 3647aab7b1d5
Author:psandoz
Date:  2013-08-06 14:26 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3647aab7b1d5

8014824: Document Spliterator characteristics and binding policy of java util 
collection impls
Reviewed-by: chegar

! src/share/classes/java/util/ArrayDeque.java
! src/share/classes/java/util/ArrayList.java
! src/share/classes/java/util/HashSet.java
! src/share/classes/java/util/LinkedHashMap.java
! src/share/classes/java/util/LinkedHashSet.java
! src/share/classes/java/util/LinkedList.java
! src/share/classes/java/util/List.java
! src/share/classes/java/util/PriorityQueue.java
! src/share/classes/java/util/Set.java
! src/share/classes/java/util/SortedSet.java
! src/share/classes/java/util/Spliterator.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/TreeSet.java
! src/share/classes/java/util/Vector.java

hg: jdk8/tl/jdk: 2 new changesets

[paul . sandoz]

Changeset: 2eebaff52a94
Author:psandoz
Date:  2013-08-16 12:46 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2eebaff52a94

8012940: More than 50 tests failed in Serialization/DeSerialization testing 
(test-mangled)
Reviewed-by: ksrini

+ test/java/util/stream/bootlib/java/util/stream/LambdaTestMode.java
! test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java

Changeset: 02ce5a0e4b98
Author:psandoz
Date:  2013-08-16 12:46 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/02ce5a0e4b98

8022898: java/util/Spliterator/SpliteratorCollisions.java fails in 
HashableIntSpliteratorWithNull data provider
Reviewed-by: henryjen, alanb, rriggs

! test/java/util/Spliterator/SpliteratorCollisions.java

hg: jdk8/tl/jdk: 8020016: Numerous splitereator impls do not throw NPE for null Consumers

[paul . sandoz]

Changeset: 0be7839d4599
Author:psandoz
Date:  2013-08-01 15:28 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0be7839d4599

8020016: Numerous splitereator impls do not throw NPE for null Consumers
Reviewed-by: mduigou, alanb, henryjen

! src/share/classes/java/util/stream/SpinedBuffer.java
! src/share/classes/java/util/stream/StreamSpliterators.java
! src/share/classes/java/util/stream/Streams.java
! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java

hg: jdk8/tl/jdk: 8021863: Stream.concat incorrectly calculates unsized state

[paul . sandoz]

Changeset: 76d88a752a03
Author:psandoz
Date:  2013-07-30 11:32 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/76d88a752a03

8021863: Stream.concat incorrectly calculates unsized state
Reviewed-by: chegar

! src/share/classes/java/util/stream/Streams.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ConcatOpTest.java

hg: jdk8/tl/jdk: 8021883: j.u.Random/RandomStream.java test needs more robust timeout duration

[paul . sandoz]

Changeset: d30f357c6050
Author:psandoz
Date:  2013-07-30 14:03 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d30f357c6050

8021883: j.u.Random/RandomStream.java test needs more robust timeout duration
Reviewed-by: chegar

! test/java/util/Random/RandomStreamTest.java

hg: jdk8/tl/jdk: 8020156: TreeMap.values().spliterator() does not report ORDERED; ...

[paul . sandoz]

Changeset: e83fc6d9cf03
Author:psandoz
Date:  2013-07-29 19:41 +0100
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e83fc6d9cf03

8020156: TreeMap.values().spliterator() does not report ORDERED
8020009: TreeMap.entrySet().spliterator() reports SORTED + null comparator but 
the elements are not Comparable
Reviewed-by: mduigou

! src/share/classes/java/util/TreeMap.java
+ test/java/util/Spliterator/SpliteratorCharacteristics.java

hg: jdk8/tl/jdk: 8019395: Consolidate StreamSupport.{stream, parallelStream} into a single method

[paul . sandoz]

Changeset: be096613bfb5
Author:psandoz
Date:  2013-07-03 21:43 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/be096613bfb5

8019395: Consolidate StreamSupport.{stream,parallelStream} into a single method
Reviewed-by: henryjen, briangoetz

! src/share/classes/java/io/BufferedReader.java
! src/share/classes/java/lang/CharSequence.java
! src/share/classes/java/nio/X-Buffer.java.template
! src/share/classes/java/nio/file/Files.java
! src/share/classes/java/util/Arrays.java
! src/share/classes/java/util/BitSet.java
! src/share/classes/java/util/Collection.java
! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/jar/JarFile.java
! src/share/classes/java/util/regex/Pattern.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/StreamSupport.java
! src/share/classes/java/util/stream/Streams.java
! src/share/classes/java/util/zip/ZipFile.java
! test/java/util/stream/bootlib/java/util/stream/DoubleStreamTestScenario.java
! test/java/util/stream/bootlib/java/util/stream/IntStreamTestScenario.java
! test/java/util/stream/bootlib/java/util/stream/LongStreamTestScenario.java
! test/java/util/stream/bootlib/java/util/stream/StreamTestScenario.java
! test/java/util/stream/bootlib/java/util/stream/TestData.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java

hg: jdk8/tl/jdk: 8017447: Unmodifiable map entry becomes modifiable if taken from a stream of map entries

[paul . sandoz]

Changeset: ff5df05222d1
Author:psandoz
Date:  2013-07-10 09:52 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ff5df05222d1

8017447: Unmodifiable map entry becomes modifiable if taken from a stream of 
map entries
Reviewed-by: briangoetz

! src/share/classes/java/util/Collections.java
+ test/java/util/Collections/UnmodifiableMapEntrySet.java

hg: jdk8/tl/jdk: 8017141: java.util/stream Spliterators from sequential sources should not catch OOME

[paul . sandoz]

Changeset: 628432ee4d68
Author:henryjen
Date:  2013-07-09 09:15 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/628432ee4d68

8017141: java.util/stream Spliterators from sequential sources should not catch 
OOME
Reviewed-by: mchung
Contributed-by: paul.san...@oracle.com

! src/share/classes/java/util/LinkedList.java
! src/share/classes/java/util/Spliterators.java

hg: jdk8/tl/jdk: 8019551: Make BaseStream public

[paul . sandoz]

Changeset: 44a634c1edc4
Author:psandoz
Date:  2013-07-09 10:44 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44a634c1edc4

8019551: Make BaseStream public
Reviewed-by: chegar, psandoz
Contributed-by: brian goetz brian.go...@oracle.com

! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/BaseStream.java

hg: jdk8/tl/jdk: 8019370: Sync j.u.c Fork/Join from 166 to tl

[paul . sandoz]

Changeset: 43134e79c0bb
Author:psandoz
Date:  2013-07-09 16:04 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43134e79c0bb

8019370: Sync j.u.c Fork/Join from 166 to tl
Reviewed-by: chegar, martin
Contributed-by: Doug Lea d...@cs.oswego.edu

! src/share/classes/java/util/concurrent/AbstractExecutorService.java
! src/share/classes/java/util/concurrent/Callable.java
! src/share/classes/java/util/concurrent/CancellationException.java
! src/share/classes/java/util/concurrent/CompletableFuture.java
! src/share/classes/java/util/concurrent/CompletionService.java
! src/share/classes/java/util/concurrent/CountedCompleter.java
! src/share/classes/java/util/concurrent/ExecutionException.java
! src/share/classes/java/util/concurrent/Executor.java
! src/share/classes/java/util/concurrent/ExecutorService.java
! src/share/classes/java/util/concurrent/Executors.java
! src/share/classes/java/util/concurrent/ForkJoinPool.java
! src/share/classes/java/util/concurrent/ForkJoinTask.java
! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java
! src/share/classes/java/util/concurrent/Future.java
! src/share/classes/java/util/concurrent/FutureTask.java
! src/share/classes/java/util/concurrent/RecursiveAction.java
! src/share/classes/java/util/concurrent/RecursiveTask.java
! src/share/classes/java/util/concurrent/RejectedExecutionException.java
! src/share/classes/java/util/concurrent/RunnableFuture.java
! src/share/classes/java/util/concurrent/RunnableScheduledFuture.java
! src/share/classes/java/util/concurrent/ScheduledExecutorService.java
! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java
! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java

hg: jdk8/tl/jdk: 2 new changesets

[paul . sandoz]

Changeset: dfd7fb0ce54b
Author:psandoz
Date:  2013-07-03 11:58 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dfd7fb0ce54b

8011427: java.util.concurrent collection Spliterator implementations
Reviewed-by: martin
Contributed-by: Doug Lea d...@cs.oswego.edu

! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java
! src/share/classes/java/util/concurrent/BlockingDeque.java
! src/share/classes/java/util/concurrent/BlockingQueue.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java
! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java
! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java
! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java
! src/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/share/classes/java/util/concurrent/DelayQueue.java
! src/share/classes/java/util/concurrent/Delayed.java
! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java
! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java
! src/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/share/classes/java/util/concurrent/SynchronousQueue.java

Changeset: bb4ae17c98cf
Author:psandoz
Date:  2013-07-03 11:58 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb4ae17c98cf

8019481: Sync misc j.u.c classes from 166 to tl
Reviewed-by: martin
Contributed-by: Doug Lea d...@cs.oswego.edu

! src/share/classes/java/util/concurrent/BrokenBarrierException.java
! src/share/classes/java/util/concurrent/CountDownLatch.java
! src/share/classes/java/util/concurrent/CyclicBarrier.java
! src/share/classes/java/util/concurrent/Exchanger.java
! src/share/classes/java/util/concurrent/Phaser.java
! src/share/classes/java/util/concurrent/TimeUnit.java
! src/share/classes/java/util/concurrent/TimeoutException.java
! src/share/classes/java/util/concurrent/package-info.java

hg: jdk8/tl/jdk: 8017329: 8b92-lambda regression: TreeSet(a, b).stream().substream(1).parallel().iterator() is empty

[paul . sandoz]

Changeset: 7532bb2d6476
Author:psandoz
Date:  2013-07-03 21:19 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7532bb2d6476

8017329: 8b92-lambda regression: TreeSet(a, 
b).stream().substream(1).parallel().iterator() is empty
Reviewed-by: alanb

! src/share/classes/java/util/stream/SliceOps.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java

hg: jdk8/tl/jdk: 8009736: Comparator API cleanup

[paul . sandoz]

Changeset: c1df54fd19b2
Author:henryjen
Date:  2013-06-11 13:41 -0700
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1df54fd19b2

8009736: Comparator API cleanup
Reviewed-by: psandoz, briangoetz, mduigou, plevart

! src/share/classes/java/util/Collections.java
! src/share/classes/java/util/Comparator.java
! src/share/classes/java/util/Comparators.java
! src/share/classes/java/util/Map.java
! src/share/classes/java/util/TreeMap.java
! src/share/classes/java/util/function/BinaryOperator.java
! src/share/classes/java/util/stream/Collectors.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/SortedOps.java
! test/java/nio/file/Files/StreamTest.java
! test/java/util/Collection/ListDefaults.java
+ test/java/util/Comparator/BasicTest.java
+ test/java/util/Comparator/TypeTest.java
- test/java/util/Comparators/BasicTest.java
+ test/java/util/Map/EntryComparators.java
+ test/java/util/function/BinaryOperator/BasicTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/SequentialOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java
! test/sun/misc/JavaLangAccess/NewUnsafeString.java

hg: jdk8/tl/jdk: 8012987: Optimizations for Stream.limit/substream

[paul . sandoz]

Changeset: 28b71c97a72d
Author:psandoz
Date:  2013-06-28 10:29 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/28b71c97a72d

8012987: Optimizations for Stream.limit/substream
Reviewed-by: mduigou
Contributed-by: Brian Goetz brian.go...@oracle.com, Paul Sandoz 
paul.san...@oracle.com

! src/share/classes/java/util/stream/AbstractPipeline.java
! src/share/classes/java/util/stream/AbstractTask.java
! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/ForEachOps.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/PipelineHelper.java
! src/share/classes/java/util/stream/SliceOps.java
! src/share/classes/java/util/stream/Stream.java
! src/share/classes/java/util/stream/StreamSpliterators.java
! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java
! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java
+ test/java/util/stream/boottest/java/util/stream/SliceSpliteratorTest.java
! test/java/util/stream/boottest/java/util/stream/StreamFlagsTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest.java

hg: jdk8/tl/jdk: 8016308: Updates to j.u.stream.Node/Nodes

[paul . sandoz]

Changeset: 656ea2349aa5
Author:psandoz
Date:  2013-06-20 10:45 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/656ea2349aa5

8016308: Updates to j.u.stream.Node/Nodes
Reviewed-by: mduigou
Contributed-by: Brian Goetz brian.go...@oracle.com, Paul Sandoz 
paul.san...@oracle.com

! src/share/classes/java/util/stream/Node.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/SliceOps.java
! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java
! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java
! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java

hg: jdk8/tl/jdk: 8016324: filter/flatMap pipeline sinks should pass size information to downstream sink

[paul . sandoz]

Changeset: 85524d9839dc
Author:psandoz
Date:  2013-06-20 11:02 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/85524d9839dc

8016324: filter/flatMap pipeline sinks should pass size information to 
downstream sink
Reviewed-by: chegar, mduigou
Contributed-by: Brian Goetz brian.go...@oracle.com

! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/ReferencePipeline.java

hg: jdk8/tl/jdk: 8016455: Sync stream tests from lambda to tl

[paul . sandoz]

Changeset: f758d7c24396
Author:psandoz
Date:  2013-06-20 11:15 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f758d7c24396

8016455: Sync stream tests from lambda to tl
Reviewed-by: mduigou
Contributed-by: Brian Goetz brian.go...@oracle.com, Paul Sandoz 
paul.san...@oracle.com

! test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java
! test/java/util/stream/bootlib/java/util/stream/LambdaTestHelpers.java
+ test/java/util/stream/bootlib/java/util/stream/LoggingTestCase.java
! test/java/util/stream/bootlib/java/util/stream/OpTestCase.java
! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java
! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java
! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java
! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java
! test/java/util/stream/boottest/java/util/stream/NodeTest.java
! test/java/util/stream/boottest/java/util/stream/UnorderedTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/DistinctOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/GroupByOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntSliceOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/IntUniqOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ReduceByOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/SequentialOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamLinkTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ToArrayOpTest.java

hg: jdk8/tl/jdk: 8016139: PrimitiveIterator.forEachRemaining

[paul . sandoz]

Changeset: 562f5cf13a9c
Author:psandoz
Date:  2013-06-20 11:21 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/562f5cf13a9c

8016139: PrimitiveIterator.forEachRemaining
Reviewed-by: alanb

! src/share/classes/java/util/PrimitiveIterator.java

hg: jdk8/tl/jdk: 8016251: Balanced spliterator for SpinedBuffer

[paul . sandoz]

Changeset: a50394c44464
Author:psandoz
Date:  2013-06-13 11:13 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a50394c44464

8016251: Balanced spliterator for SpinedBuffer
Reviewed-by: mduigou
Contributed-by: Brian Goetz brian.go...@oracle.com, Peter Levart 
peter.lev...@gmail.com, Paul Sandoz paul.san...@oracle.com

! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/Node.java
! src/share/classes/java/util/stream/Nodes.java
! src/share/classes/java/util/stream/SortedOps.java
! src/share/classes/java/util/stream/SpinedBuffer.java
! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java
! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java
! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java
! test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java

hg: jdk8/tl/jdk: 8015895: Int/LongStream.range/rangeClosed; ...

[paul . sandoz]

Changeset: 8d627f324c38
Author:psandoz
Date:  2013-06-11 12:13 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d627f324c38

8015895: Int/LongStream.range/rangeClosed
8012986: Right-bias range spliterators for large ranges
Reviewed-by: mduigou

! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/Streams.java
! test/java/util/stream/bootlib/java/util/stream/IntStreamTestDataProvider.java
! test/java/util/stream/bootlib/java/util/stream/LongStreamTestDataProvider.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/RangeTest.java

hg: jdk8/tl/jdk: 8015792: Rename Spliterators.spliteratorFromIterator to Spliterators.iterator

[paul . sandoz]

Changeset: 9c462579b624
Author:psandoz
Date:  2013-06-10 12:26 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c462579b624

8015792: Rename Spliterators.spliteratorFromIterator to Spliterators.iterator
Reviewed-by: chegar

! src/share/classes/java/util/Spliterators.java
! src/share/classes/java/util/stream/DoublePipeline.java
! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/ReferencePipeline.java
! src/share/classes/java/util/stream/SpinedBuffer.java
! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java
! test/java/util/stream/bootlib/java/util/stream/TestData.java
! test/java/util/stream/boottest/java/util/stream/DoubleNodeTest.java
! test/java/util/stream/boottest/java/util/stream/IntNodeTest.java
! test/java/util/stream/boottest/java/util/stream/LongNodeTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java

hg: jdk8/tl/jdk: 8015798: Rename IntStream.longs/doubles and LongStream.doubles to asXxxStream

[paul . sandoz]

Changeset: 7322e8ad7c01
Author:psandoz
Date:  2013-06-10 12:20 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7322e8ad7c01

8015798: Rename IntStream.longs/doubles and LongStream.doubles to asXxxStream
Reviewed-by: alanb

! src/share/classes/java/util/stream/IntPipeline.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongPipeline.java
! src/share/classes/java/util/stream/LongStream.java
! test/java/util/stream/boottest/java/util/stream/SpinedBufferTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/DoublePrimitiveOpsTests.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ExplodeOpTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/ForEachOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MapOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MatchOpTest.java
! test/java/util/stream/test/org/openjdk/tests/java/util/stream/MinMaxTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/PrimitiveSumTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamBuilderTest.java
! 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/StreamSpliteratorTest.java

hg: jdk8/tl/jdk: 8013649: HashMap spliterator tryAdvance() encounters remaining elements after forEachRemaining()

[paul . sandoz]

Changeset: de11b20f8c01
Author:psandoz
Date:  2013-05-31 10:53 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de11b20f8c01

8013649: HashMap spliterator tryAdvance() encounters remaining elements after 
forEachRemaining()
Reviewed-by: chegar

! src/share/classes/java/util/HashMap.java
! src/share/classes/java/util/WeakHashMap.java
! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java

hg: jdk8/tl/jdk: 8015790: Remove duplicate spliterator tests

[paul . sandoz]

Changeset: fad4ef2123ca
Author:psandoz
Date:  2013-06-04 11:53 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fad4ef2123ca

8015790: Remove duplicate spliterator tests
Reviewed-by: alanb, mduigou

- 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorLateBindingFailFastTest.java
- 
test/java/util/stream/test/org/openjdk/tests/java/util/stream/SpliteratorTraversingAndSplittingTest.java

hg: jdk8/tl/jdk: 8014732: Minor spec issue: java.util.Spliterator.getExactSizeIfKnown

[paul . sandoz]

Changeset: b47044426bcd
Author:psandoz
Date:  2013-05-31 09:58 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b47044426bcd

8014732: Minor spec issue: java.util.Spliterator.getExactSizeIfKnown
Summary: A minor documentation issue (not a spec issue).
Reviewed-by: chegar, dl

! src/share/classes/java/util/Spliterator.java

hg: jdk8/tl/jdk: 8015008: Primitive iterator over empty sequence, null consumer: forEachRemaining methods do not throw NPE

[paul . sandoz]

Changeset: f3c7c5f753dc
Author:psandoz
Date:  2013-06-03 10:28 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f3c7c5f753dc

8015008: Primitive iterator over empty sequence, null consumer: 
forEachRemaining methods do not throw NPE
Reviewed-by: chegar

! src/share/classes/java/util/PrimitiveIterator.java
+ test/java/util/Iterator/PrimitiveIteratorDefaults.java

hg: jdk8/tl/jdk: 8014731: j.u.stream.StreamSupport class has default constructor generated

[paul . sandoz]

Changeset: 44ef47f3efed
Author:psandoz
Date:  2013-06-03 10:45 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44ef47f3efed

8014731: j.u.stream.StreamSupport class has default constructor generated
Summary: This change set also fixes broken links
Reviewed-by: alanb, chegar
Contributed-by: Paul Sandoz paul.san...@oracle.com, Henry Jen 
henry@oracle.com

! src/share/classes/java/util/stream/StreamSupport.java

hg: jdk8/tl/jdk: 8014383: StringJoiner example in class description not in sync with streams API

[paul . sandoz]

Changeset: a79e2683eae3
Author:psandoz
Date:  2013-06-03 17:37 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a79e2683eae3

8014383: StringJoiner example in class description not in sync with streams API
Reviewed-by: alanb

! src/share/classes/java/util/StringJoiner.java

hg: jdk8/tl/jdk: 8014393: Minor typo in the spec for j.u.stream.Stream.findFirst()

[paul . sandoz]

Changeset: b4742d038100
Author:psandoz
Date:  2013-05-28 15:22 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4742d038100

8014393: Minor typo in the spec for j.u.stream.Stream.findFirst()
Reviewed-by: alanb, chegar

! src/share/classes/java/util/stream/DoubleStream.java
! src/share/classes/java/util/stream/IntStream.java
! src/share/classes/java/util/stream/LongStream.java
! src/share/classes/java/util/stream/Stream.java

hg: jdk8/tl/jdk: 8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder

[paul . sandoz]

Changeset: 156ee44cd456
Author:psandoz
Date:  2013-05-30 16:08 +0200
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/156ee44cd456

8014409: Spec typo: extra } in the spec for j.u.s.StreamBuilder
Summary: Also fixes documentation on StreamBuilder.OfDouble
Reviewed-by: alanb, chegar, mduigou

! src/share/classes/java/util/stream/StreamBuilder.java