Re: RFR : 8132961 : JEP 279 Improve Test-Failure Troubleshooting

[Leonid Mesnik]

Hi

These changes were already reviewed internally.
Looks good for me. Please get official review from Reviewers.

Leonid

On 24.11.2015 22:13, Igor Ignatyev wrote:

http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/

3579 lines changed: 3579 ins; 0 del; 0 mod; 0 unchg

Hi,

Could you please review the webrev[0] for JEP 279[1]?

The scope of the JEP is an implementation of a library which uses jtreg timeout 
handler and observer extension points to collect information about environment 
in case of test failures (including timeouts) and about test processes in case 
of timeouts. This data is then presented together with the test failure to 
simplify analysis.

To make it easier to specify which tools should be run by the library on which 
platform when a test failure or timeout occurs, we use properties files to configure 
the library. Each platform family uses its own property file (named 
.properties) and common.properties, which contains platform independent 
tools, such as jps. Using property files allows to easily extend the tools that are 
used to collect information on test failure or timeout in the future. See the JEP for 
a more thorough overview of the collected data. Currently, we are using the following 
tools:
- on all platforms[3]: jps, jstack, jmap, jinfo, jcmd
- on linux[4]: ps, pmap, lsof, lslocks, gdb, gcore, id, who, last, df, env, 
dmesg, sysctl, top, free, vmstat, netstat
- on solaris[5]: pgrep, pmap, pfiles, pstack, gcore, id, who, last, df, env, 
dmesg, prtconf, sysdef, swap, ps, top, vmstat, pagesize, netstat
- on mac[6]: pgrep, vmmap, heap, leaks, spindump, lldb, gcore, id, who, last, 
df, env, dmesg, sysctl, ps, top, vm_stat, netstat
- on windows[7]: wmic, pmap, handle, cdb, id, who, last, df, env, powershell, 
tasklist, ps, top, free, vmstat, openfiles, netstat

More information can be found in the JEP[1] and README[2].

The library integration into makefiles will be done later as the fix for 
JDK-8132962[8].

[0] http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/
[1] https://bugs.openjdk.java.net/browse/JDK-8075621
[2] 
http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/README.html
[3] 
http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/common.properties.html
[4] 
http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/linux.properties.html
[5] 
http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/solaris.properties.html
[6] 
http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/mac.properties.html
[7] 
http://cr.openjdk.java.net/~iignatyev/8132961/webrev.00/test/failure_handler/src/share/conf/windows.properties.html
[8] https://bugs.openjdk.java.net/browse/JDK-8132962

Thanks,
— Igor

Re: PoC for JDK-4347142: Need method to set Password protection to Zip entries

[KUBOTA Yuji]

Hi all,

* Sorry for my mistake. I re-post this mail because I sent before get
a response of subscription confirmation of core-libs-dev.

Our customers have to handle password-protected zip files. However,
Java SE does not provide the APIs to handle it yet, so we must use
third party library so far.

Recently, we found JDK-4347142: "Need method to set Password
protection to Zip entries", and we tried to implement it.

The current zlib in JDK is completely unaffected by this proposal. The
traditional zip encryption encrypts a data after it is has been
compressed by zlib.[1] So we do NOT need to change existing zlib
implementation.

We've created PoC and uploaded it as webrev:

http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/

Test code is as below. This code will let you know how this PoC works.
http://cr.openjdk.java.net/~ysuenaga/JDK-4347142/webrev.00/Test.java

In NTT, a Japanese telecommunications company. We are providing many
enterprise systems to customers. Some of them, we need to implement to
handle password-protected zip file. I guess that this proposal is
desired for many developers and users.

I'm working together with Yasumasa Suenaga, jdk9 committer (ysuenaga).
We want to implement it if this proposal accepted.

[1]: https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.3.3.TXT
(6.0  Traditional PKWARE Encryption)

Thanks,
Yuji

Re: RFR: jsr166 jdk9 integration wave 2

[Martin Buchholz]

Wave 2 all pushed, with the exception of unresolved CompletableFuture
changes.

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

[Coleen Phillimore]

Sending to core-libs mailing list.

On 11/25/15 2:19 PM, Alexander Smundak wrote:

Please take a look at
http://cr.openjdk.java.net/~asmundak/8141491/jdk/webrev.00
that fixes the problem.

It utilizes the ability of some (GCC and Clang) to declare data
alignment explicitly.
I have verified it works on x86_64 Linux by running
jdk/test/java/nio/Buffer/Basic.java test

I need a sponsor.

Sasha

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

[Stuart Marks]

On 11/25/15 1:02 PM, Roger Riggs wrote:

Set.java:
  - of methods:  @throws IAE   "if the elements are duplicates" -> "if elements
*contains *duplicates"


That specific wording comes from the two-arg overload, so it's shorthand for "if 
the (two) elements are duplicates (of each other)". The overloads with more args 
are worded "if there are any duplicate elements" which I think is ok; similar 
wording is used in Map.



  - in the of() methods, would it be more efficient to add the individual object
to the hashset w/o
the intermediate list; don't create garbage that needs to be collected.


Sure. I'll consider this for the optimized implementation, since all of this 
code is going to replaced at some point.



EnumSet.java:

  - the javadoc for the of(e) method says it is specified by: "..."


Yes, this is a javadoc bug, https://bugs.openjdk.java.net/browse/JDK-8139101 .


List.java:
  - The use of 'Creates an immutable list...' implies a new List is created each
time. (ditto @returns "newly created")
I would use 'Returns an immutable list...'


Agreed, will fix here, in the @return clauses, and in corresponding locations 
for Set and Map.



  - I think I would have gone for 7 or 9 elements in the constructor, the 10 and
11 args forms
just look like they would never be used.  (your comments not with standing)

  - in the implementation, it would helpful to use Objects.requireNonNull(e1,
"e1") form to aid in debugging which arg was null.  (Ditto Map, and Set)


Will reconsider for the optimized implementation.


Map.java:
  - Might want to clarify that the duplicate check uses equals (not ==).


The general contracts of Set and Map talk about duplicates and the use of 
equals(), so I think we're covered here.



  - Same comments about the description using "creates/created" and "newly".
  - Map is even stranger than List with 20 arguments (10 arg/value pairs)
  - Capacity and load factor are not relevant for an immutable Map; can that be
noted somewhere?


The concepts of capacity and load factor are defined by HashMap, so they aren't 
present in the Map interface at all, irrespective of these changes. The 
discussion on this topic earlier in the thread is about the HashMap capacity 
values used internally within the skeleton implementation, which doesn't affect 
the API.



  - KeyValueHolder is more general than is needed; it does not need to inherit
from Entry and could be a nested class in Map.


KeyValueHolder is a private class; interfaces can't have nested private classes. 
(The "Milling Project Coin" feature [1] was adding private *methods* to 
interfaces.) The new Map.entry() method's return type is Map.Entry and it 
returns a KeyValueHolder, which therefore must implement Map.Entry. 
KeyValueHolder was a public class in a previous version of this proposal. After 
a suggestion from Stephen Colebourne, and some consultation with Brian Goetz, we 
were able to convince ourselves that having KVH be a private class implementing 
Map.Entry would still allow us to get the benefit of turning it into a value 
type in the future.


s'marks


[1] http://openjdk.java.net/jeps/213

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

[Stuart Marks]

I think the main point of including the "value-based" admonition is to warn 
developers not to depend on identity semantics of these things. This should help 
preserve flexibility when/if we decide to convert them to value types in the 
future. It might be that there's no advantage in doing so, in which case we 
presumably won't do it. :-)


I'm somewhat distant from the current state of the value types work, but I can 
imagine that it would provide some advantage even for the empty List. Clearly 
the overall heap savings wouldn't be large, since as you point out, there's only 
ever a single instance. But if it were a value type, it could live entirely on 
the stack, avoiding a memory dereference, a cache miss, etc.


s'marks

On 11/24/15 7:52 PM, Rezaei, Mohammad A. wrote:

Value based things make a lot of sense for types that don't belong to well 
established reference hierarchies. I can even see great uses for a value based 
List implementation, so long as it's preferentially referenced as the exact 
type (e.g. private ValueBasedList someList = ...) and rarely cast to the 
interface type (List).

But I've been scratching my head about the empty collections (of()) and I can't 
figure out why value based would be a good idea. Currently, there is only one 
instance in the entire VM, so it's unlikely to get any memory benefits. The most 
likely use for the return value is either a variable/member of type List or something 
that can hold a List (like a Map), which will likely cause an 
immediate boxing. In some cases this can be elided (lots of inlining and 
optimization), but that's the less likely case.

What's the rationale for the value based spec for the empty implementations?

Thanks
Moh


-Original Message-
From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf
Of John Rose
Sent: Tuesday, November 24, 2015 9:08 PM
To: Stuart Marks
Cc: core-libs-dev
Subject: Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-
8139232)

On Nov 23, 2015, at 10:26 PM, Stuart Marks  wrote:


Please review these API and implementation changes that comprise the first

integration of JEP 269. I intend to push this under the "initial API and
skeleton implementation" subtask, JDK-8139232.

Please strengthen the specification to assert that the new immutables are in
fact value-based.

http://docs.oracle.com/javase/8/docs/api/java/lang/doc-files/ValueBased.html


This will prevent people from relying on their identity (acmp) and
synchronization (monitorenter).
It will allow optimizations more freedom to use flatter storage formats and to
reuse list values.

If we don't do this now, then we will not be able to retroactively make or
enforce the claim,
and the optimizations will be impossible.

— John

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

[Stuart Marks]

On 11/25/15 8:25 AM, Paul Benedict wrote:

Chris, you raise a good question. Example: JPA entities stored in an immutable
list and the list belongs to a stateful EJB that gets passivated or clustered.
Obviously, serialization would be occuring.

On Wed, Nov 25, 2015 at 10:14 AM, Chris Hegarty mailto:chris.hega...@oracle.com>> wrote:

Is there any impact on the Serializability of these collections, if
they are “value” based?  I don’t think so, but I’m not sure, since
their serial form is not documented.  Note to self: should we
document their serial form?


For JDK 9, the plan is as follows. The current API specification requires the 
collections be serializable. My plan is for the optimized implementations to use 
a common serialization proxy class; that class is the only one that will have 
its serial form documented. This preserves flexibility to change the optimized 
implementations.


The collections returned by the skeleton implementation are in fact 
serializable, and this is tested by the regression tests. However, the 
serialized form is not final. I've asked the JCK team to hold off developing 
serialization tests until the serial proxy stuff gets in, at which time we can 
commit to its documented serial form.


I don't know how serialization will work in the hypothetical value-typed future. 
Using a serial proxy will, I hope, sidestep the issue of how a value type is 
represented in the serialized object stream. Of course, this assumes that the 
serialization mechanism, including proxying, continues to work similarly for 
value types as it does for ordinary objects.


s'marks

Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

[joe darcy]

PS If the concepts the two classes Version and OracleVersion are trying 
to capture is a "Vendor-Version" then perhaps that can be surfaced more 
directly in the API. That is, if the basic notion is to interpret a 
version string in a way appropriate to and specialized for a given 
vendor of the JDK (a la the java.vendor system property), then perhaps a 
type like


// API sketch
public final class VendorVersion {
public VendorVersion(String vendor, Version version, 
Comparator versionComp>) { ...}


@Override
public boolean equals(VendorVersion vv) {
// Usual instance of checks
return Objects.equals(vendor, vv.vendor()) && 
versionComp.version(), vv.version());

}

int compareVersion(VendorVersion vv) {
if (!vendor.equals(vv.vendor()))
// throw an exception
return versionComp(version, vv.version);
}

// ...
}

might serve the purposes at hand.

HTH,

-Joe

On 11/25/2015 1:31 PM, joe darcy wrote:

Hello,

On 11/25/2015 8:48 AM, Mandy Chung wrote:

On Nov 24, 2015, at 5:54 PM, Iris Clark  wrote:

Hi.

Please review the new classes jdk.Version and jdk.OracleVersion.  
These are

simple Java APIs to parse, validate, and compare version numbers.

  Webrev

http://cr.openjdk.java.net/~irisa/verona/8072379/webrev.1/
This looks good to me.  Alan raises a good question whether 
jdk.OracleVersion is intended to be pushed to OpenJDK.





I share the concerns that have been raised about the naming and 
placement of a class named "OracleVersion".


Is the intention that downstream JDK distributions, such as IcedTea, 
whether based on OpenJDK or otherwise, would provide their own 
specialization of the jdk.Version class?


If so, should there be some kind of provider interface to find 
system's the version interpreter?


For example, what class, if any would be expected to provide detailed 
analysis of the version string emitted by, say, a OpenJDK build used 
as the reference implementation of Java SE 9?


The equals / hashCode behavior of Version and OracleVersion is bit 
surprising and I think somewhat underspecified given the possibility 
of defining subclasses.


The (overridable) equals method in Version says "Two Versions are 
equal if and only if they represent the same version string." If that 
is interpreted to mean the Versions are equal if their toString output 
is equal, the toString spec says "Returns a string representation of 
this version." and the (overridable) implementation in Version looks 
at versions, pre, build, and optional.


Since OracleVersion does not override equals, a plain Version object 
and an OracleVersion object can compare as equal. Additionally, a 
VersionWithDifferentToStringOutput("1.2.3") object which overrides 
toString would not be semantically equivalent to a Version("1.2.3") 
object. Worse, there could be a non-communicability behavior in the 
equals method since


(new Version("1.2.3")).equals(new 
VersionWithDifferentToStringOutput("1.2.3"))


could return "true" while

(new VersionWithDifferentToStringOutput("1.2.3")).equals(new 
Version("1.2.3"))


could easily and legitimately return "false" by the specification.

How is this API supposed to behave if the component version strings 
have a numerical value greater than Integer.MAX_VALUE?


Was using Longs to record numerical versions rather than Integers 
considered?


Thanks,

-Joe

Re: Code (Pre-)Review for JEP 280: Indify String Concat

[Aleksey Shipilev]

On 11/25/2015 03:07 AM, Claes Redestad wrote:
> Some variants might be non-existent in a majority of programs, others
> might not be needed early on, which could help reduce the footprint a bit.

Thanks, indeed, it is savvy to make the MH resolution lazier.

See the update:

 http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.02/
 http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.01/
 http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/

More reviews please :) Especially the langtools part.

Thanks,
-Aleksey

Re: RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe

[Paul Sandoz]

> On 25 Nov 2015, at 18:29, Peter Levart  wrote:
> 
> 
> 
> On 11/25/2015 12:46 PM, Paul Sandoz wrote:
>> We are in Unsafe territory :-)
>> 
>> 
>> Since the Java mismatch method and the intrinsic only make temporary reads, 
>> IIUC such updates by GC to the array can only occur at a safe points, and i 
>> don’t think int loops produce a safe point check within the hot loop and nor 
>> does the intrinsic, is this really an issue?
>> 
> 
> IIUC, in interpreter, safepoint can happen between any two bytecodes:
> 
> "Safepoints are initiated using a cooperative, polling-based mechanism. In 
> simple terms, every so often a thread asks “should I block for a safepoint?”. 
> Asking this question efficiently is not so simple. One place where the 
> question is often asked is during a thread state transition. Not all state 
> transitions do this, for example a thread leaving the VM to go to native 
> code, but many do. The other places where a thread asks are in compiled code 
> when returning from a method or at certain stages during loop iteration. 
> Threads executing interpreted code don't usually ask the question, instead 
> when the safepoint is requested the interpreter switches to a different 
> dispatch table that includes the code to ask the question; when the safepoint 
> is over, the dispatch table is switched back again. Once a safepoint has been 
> requested, the VMThread must wait until all threads are known to be in a 
> safepoint-safe state before proceeding to execute the VM operation. During a 
> safepoint the Threads_lock is used to block any threads that were running, 
> with the VMThread finally releasing the Threads_lock after the VM operation 
> has been performed."
> 

Ah, i see, if in the interpreter the dispatch table is switched between getting 
av and bv then that would be a problem:

  long av = U.getLongUnaligned(a, aOffset + bi);
  long bv = U.getLongUnaligned(b, bOffset + bi);

I will document that this method should not be used with reference component 
types :-) (i anyway neglected to mention about alignment in those cases).

Thanks,
Paul.

> 
> You could treat a "false positive" mismatch like you do with NaN floats and 
> doubles (fall-back to normal code), but what about "false negatives"?
> 
> Suppose that you take a snapshot of address of object A from the 1st array, 
> followed by safepoint which moves object A to somewhere else and moves object 
> B to the same address A has occupied before (compacting collector). After 
> safepoint returns, you take the snapshot of address of object B from the 
> corresponding slot of the 2nd array. Now you compare the addresses and they 
> are the same, but they  represent(ed) pointers to distinct objects.
> 
> Regards, Peter
> 

Re: RFR (JAXP): 8144094: Add Catalog API to java.xml module

[Lance Andersen]

looks fine Joe

On Nov 25, 2015, at 5:50 PM, huizhe wang  wrote:

> Hi,
> 
> The new Catalog API needs to be added to the java.xml module. Please review 
> the following change:
> 
> diff --git a/make/common/CORE_PKGS.gmk b/make/common/CORE_PKGS.gmk
> --- a/make/common/CORE_PKGS.gmk
> +++ b/make/common/CORE_PKGS.gmk
> @@ -224,6 +224,7 @@
> javax.tools \
> javax.transaction \
> javax.transaction.xa \
> +javax.xml.catalog \
> javax.xml.parsers \
> javax.xml.bind \
> javax.xml.bind.annotation \
> diff --git a/modules.xml b/modules.xml
> --- a/modules.xml
> +++ b/modules.xml
> @@ -1066,6 +1066,9 @@
>   javax.xml
> 
> 
> +  javax.xml.catalog
> +
> +
>   javax.xml.datatype
> 
> 
> 
> Thanks,
> Joe
> 



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
lance.ander...@oracle.com

RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

[Iris Clark]

Hi, Mandy.

Thanks for looking at this.

> We will need to find a home for this jdk.* API since java.base only 
> exports Java SE API per the design principles in JEP 200 The Modular 
> JDK.  It’s fine to file an issue to follow up this.   

I've filed this bug and assigned it to myself:

  8144062: Determine appropriate module for jdk.Version and jdk.OracleVersion
  https://bugs.openjdk.java.net/browse/JDK-8144062

> You will also need to find a docs page to publish this new API as well 
> (the current way is a page linked from the layer cake and this may be
> changed).

Yes, I'm aware of these discussions.  Since I suspect that they won't be
resolved within the next week or so, I've filed this bug:

  8144069: Determine correct publication for jdk.Version and jdk.OracleVersion 
APIs 
  https://bugs.openjdk.java.net/browse/JDK-8144069

Regards,
iris

-Original Message-
From: Mandy Chung 
Sent: Wednesday, November 25, 2015 8:48 AM
To: Iris Clark
Cc: core-libs-dev@openjdk.java.net; verona-...@openjdk.java.net
Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion


> On Nov 24, 2015, at 5:54 PM, Iris Clark  wrote:
> 
> Hi.
> 
> Please review the new classes jdk.Version and jdk.OracleVersion.  
> These are simple Java APIs to parse, validate, and compare version numbers.
> 
>  Webrev
> 
>http://cr.openjdk.java.net/~iris/verona/8072379/webrev.1/

This looks good to me.  Alan raises a good question whether jdk.OracleVersion 
is intended to be pushed to OpenJDK.

We will need to find a home for this jdk.* API since java.base only exports 
Java SE API per the design principles in JEP 200 The Modular JDK.  It’s fine to 
file an issue to follow up this.   W.r.t. the docs build, jdk is listed in 
top/make/common/NON_CORE_PKGS.gmk but there is no target in make/Javadoc.gmk 
building it.  You will also need to find a docs page to publish this new API as 
well (the current way is a page linked from the layer cake and this may be 
changed).

Mandy

RFR (JAXP): 8144094: Add Catalog API to java.xml module

[huizhe wang]

Hi,

The new Catalog API needs to be added to the java.xml module. Please 
review the following change:


diff --git a/make/common/CORE_PKGS.gmk b/make/common/CORE_PKGS.gmk
--- a/make/common/CORE_PKGS.gmk
+++ b/make/common/CORE_PKGS.gmk
@@ -224,6 +224,7 @@
 javax.tools \
 javax.transaction \
 javax.transaction.xa \
+javax.xml.catalog \
 javax.xml.parsers \
 javax.xml.bind \
 javax.xml.bind.annotation \
diff --git a/modules.xml b/modules.xml
--- a/modules.xml
+++ b/modules.xml
@@ -1066,6 +1066,9 @@
   javax.xml
 
 
+  javax.xml.catalog
+
+
   javax.xml.datatype
 
 

Thanks,
Joe

Re: RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe

[Peter Levart]

On 11/25/2015 12:46 PM, Paul Sandoz wrote:

We are in Unsafe territory:-)

Since the Java mismatch method and the intrinsic only make temporary reads, 
IIUC such updates by GC to the array can only occur at a safe points, and i 
don’t think int loops produce a safe point check within the hot loop and nor 
does the intrinsic, is this really an issue?


IIUC, in interpreter, safepoint can happen between any two bytecodes:

"Safepoints are initiated using a cooperative, polling-based mechanism. 
In simple terms, every so often a thread asks “should I block for a 
safepoint?”. Asking this question efficiently is not so simple. One 
place where the question is often asked is during a thread state 
transition. Not all state transitions do this, for example a thread 
leaving the VM to go to native code, but many do. The other places where 
a thread asks are in compiled code when returning from a method or at 
certain stages during loop iteration. *Threads executing interpreted 
code don't usually ask the question, instead when the safepoint is 
requested the interpreter switches to a different dispatch table that 
includes the code to ask the question; when the safepoint is over, the 
dispatch table is switched back again*. Once a safepoint has been 
requested, the VMThread must wait until all threads are known to be in a 
safepoint-safe state before proceeding to execute the VM operation. 
During a safepoint the Threads_lock is used to block any threads that 
were running, with the VMThread finally releasing the Threads_lock after 
the VM operation has been performed."



You could treat a "false positive" mismatch like you do with NaN floats 
and doubles (fall-back to normal code), but what about "false negatives"?


Suppose that you take a snapshot of address of object A from the 1st 
array, followed by safepoint which moves object A to somewhere else and 
moves object B to the same address A has occupied before (compacting 
collector). After safepoint returns, you take the snapshot of address of 
object B from the corresponding slot of the 2nd array. Now you compare 
the addresses and they are the same, but they  represent(ed) pointers to 
distinct objects.


Regards, Peter

Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

[Mandy Chung]

> On Nov 24, 2015, at 5:54 PM, Iris Clark  wrote:
> 
> Hi.
> 
> Please review the new classes jdk.Version and jdk.OracleVersion.  These are
> simple Java APIs to parse, validate, and compare version numbers.
> 
>  Webrev
> 
>http://cr.openjdk.java.net/~iris/verona/8072379/webrev.1/

This looks good to me.  Alan raises a good question whether jdk.OracleVersion 
is intended to be pushed to OpenJDK.

We will need to find a home for this jdk.* API since java.base only exports 
Java SE API per the design principles in JEP 200 The Modular JDK.  It’s fine to 
file an issue to follow up this.   W.r.t. the docs build, jdk is listed in 
top/make/common/NON_CORE_PKGS.gmk but there is no target in make/Javadoc.gmk 
building it.  You will also need to find a docs page to publish this new API as 
well (the current way is a page linked from the layer cake and this may be 
changed).

Mandy

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

[Chris Hegarty]

On 24 Nov 2015, at 23:27, Stuart Marks  wrote:
> ….
> 
> But in the hypothetical value-typed future, we might want to return value 
> types from at least some of the factory methods. Value types have no notion 
> of identity, so we don't want to make any statements that lead to thinking 
> about the identity of the returned object, even to the extent of saying that 
> it "might" be the "same" instance as one previously returned.
> 
> Based on this, it occurs to me that I should add the "value-based" disclaimer 
> to the relevant section of class doc. (I also note that, off-line, John Rose 
> had already prompted me to do this, so I should heed his advice.)

Is there any impact on the Serializability of these collections, if
they are “value” based?  I don’t think so, but I’m not sure, since
their serial form is not documented.  Note to self: should we
document their serial form?

> I'll also change the method docs to say something like,
> 
> * Returns an immutable list containing  elements.
> * ...
> * @return a list containing the specified elements

Looks fine.

-Chris.

Re: RFR (S) 8136500: Integer/Long getChars and stringSize should be more idiomatic

[Ulf]

Hi Aleksey,

Am 24.11.2015 um 23:44 schrieb Aleksey Shipilev:

On 11/24/2015 07:50 PM, Ulf wrote:

Am 24.11.2015 um 12:07 schrieb Aleksey Shipilev:

Thanks for reviews, Ivan, John, Sherman and Paul!

I am pushing this change now.

I know, I'm late, but have you ever tried? :

No, but you can try it yourself. OpenJDK workspace has tests covering
that codepath. Pick up the benchmarks from here:
   http://cr.openjdk.java.net/~shade/8136500/


thanks for your answer and hints.

Currently I don't have a development environment, so maybe later I can try this.

-Ulf

Promptly cleaning direct ByteBuffer(s) - was: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

[Peter Levart]

Changing the subject to not hijack the thread...

On 11/25/2015 01:54 PM, Andrew Haley wrote:

On 11/25/2015 12:39 PM, Peter Levart wrote:

What do you think?

It's very problematic.  First off, collection often clears the young
generation altogether, promoting everything.


This could be a best-effort algorithm. If it must clear the young 
generation, it would. User would have to size it accordingly to 
accommodate for extra space needed by direct ByteBuffers staying in the 
young gen forever.



   Secondly, I think we are
already short of header bits in some cases.


How many bits are there for object age? 4 ? This means 16 values. If one 
value is "reserved" for eternally-young objects, there would still be 15 
values for normal operation.



   Thirdly, this requires
all collectors to be changed.


Why? For start, only the most popular collector used in those 
applications could be modified and the feature could be optional 
(guarded by switch). API calls would be no-ops in unsupported collectors 
or when the feature is not enabled.



   Fourthy, some collectors don't use
multiple generations: they can just allow a dense prefix to pile up at
the left-hand end of the heap which they don't bother to collect.


Those would not be supported.


Etc, etc...


Maybe. Would have to dive into VM to find out. ;-)



Andrew.


Regards, Peter

Re: RFR 6856817: Poor performance of Writer#append with CharBuffer

[Aleksey Shipilev]

On 11/25/2015 06:22 PM, Aleksey Shipilev wrote:
> On 11/25/2015 05:29 PM, vyom wrote:
>> Please review my changes for below bug.
>>
>> Bug:JDK-6856817 : Poor performance of Writer#append with CharBuffer
>> Webrev: http://cr.openjdk.java.net/~vtewari/6856817/webrev0.4/
> 
> Interesting change.
> 
> But, I think the "null" handling in new OSW.append methods is incorrect.
> Javadoc says that those methods should behave exactly as:
> 
>   out.write(csq.toString())
> 
> or:
> 
>  out.write(csq.subSequence(start, end).toString())
> 
> If CharSequence is null, we should throw NullPointerException, not doing
> any "null" mangling, as your patch does? If so, can you please fix this
> and add more tests?

Ah, apologies, the Javadoc is puzzling for Writer.append(CharSequence):
the @param declaration says that if CharSequence is null, it is treated
as if containing "null", contradicting what is said before in the same
method.

OTOH, Writer.append(CharSequence, int, int) has the escape clause "when
csq is not null". I think that specification for
Writer.append(CharSequence) should mention that as well, please file a
cleanup RFE and CCC?

Otherwise the changes look good to me.

Thanks,
-Aleksey

Re: RFR 6856817: Poor performance of Writer#append with CharBuffer

[Aleksey Shipilev]

Hi vyom,

On 11/25/2015 05:29 PM, vyom wrote:
> Hi All,
> 
> Please review my changes for below bug.
> 
> Bug:JDK-6856817 : Poor performance of Writer#append with CharBuffer
> Webrev: http://cr.openjdk.java.net/~vtewari/6856817/webrev0.4/

Interesting change.

But, I think the "null" handling in new OSW.append methods is incorrect.
Javadoc says that those methods should behave exactly as:

  out.write(csq.toString())

or:

 out.write(csq.subSequence(start, end).toString())

If CharSequence is null, we should throw NullPointerException, not doing
any "null" mangling, as your patch does? If so, can you please fix this
and add more tests?

Cheers,
-Aleksey

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

[Claes Redestad]

On 2015-11-25 16:06, Aleksey Shipilev wrote:

On 11/25/2015 05:44 PM, Claes Redestad wrote:

please review this small cleanup/startup improvement which defers a few
classes from loading during startup and consolidates some static utility
methods to generate type signatures:

webrev: http://cr.openjdk.java.net/~redestad/8143926/webrev.01/
bug: https://bugs.openjdk.java.net/browse/JDK-8143926

Looks okay, even as the cleanup, not taking the performance improvements
into account.


Thanks!



Nit: don't you want to inline BD.getTypeChar into BD.unparseSig to avoid
"c != 'L')" comparison? Or you want to keep it separate as the utility
method?


Inlining the isPrimitive check should be enough to avoid extra comparisons:

http://cr.openjdk.java.net/~redestad/8143926/webrev.02

/Claes

Re: RFR: jsr166 jdk9 integration wave 2

[Peter Levart]

Hi Doug,

On 11/25/2015 12:47 PM, Doug Lea wrote:

On 11/25/2015 03:05 AM, Peter Levart wrote:

On 11/25/2015 01:59 AM, Martin Buchholz wrote:

On Tue, Nov 24, 2015 at 2:30 PM, Peter Levart mailto:peter.lev...@gmail.com>> wrote:
What do you think of exception cloning?
Making copies of java objects has historically been troublesome (e.g.
Cloneable).


I was only thinking of Cloneable. Serialization is troublesome. If 
Throwable was
retrofitted to implement Cloneable and have the following new static 
method:


I still think this would be a useful feature, assuming no hidden snags.
In addition to CompletableFuture, we might be able to use it instead of
emulating a variant of it in ForkJoinTask.getThrowableException.
There are probably other candidate uses elsewhere (although I can't
think of any offhand).


For ForkJoinTask you would need an additional feature. Reinitializing of 
the cause and clearing any suppressed exceptions on the clone. This 
could be controlled via two additional boolean flags:



/**
 * Returns a {@link Object#clone() clone} of given {@code exception}
 * which shares all state with original exception (shallow clone) 
and is

 * augmented in the following way:
 * 
 * If {@code resetCause} parameter is {@code true}, then clone's
 * {@link #getCause() cause} is reset to a state where it can be
 * {@link #initCause(Throwable) initialized} again. If {@code 
resetCause}
 * parameter is {@code false}, then clone's cause is inherited from 
original

 * exception (either initialized or uninitialized).
 * 
 * If {@code resetSuppressed} parameter is {@code true} and 
original exception
 * has suppression enabled, then clone's suppressed exceptions are 
reset
 * to an empty list. If {@code resetSuppressed} parameter is {@code 
false}

 * (or original exception has suppression disabled) then clone's
 * suppressed exceptions are inherited from original exception (or 
clone's

 * suppression is disabled too). In either case, clone's suppressed
 * exceptions are independent of original exception's suppressed
 * exceptions. Any further {@link #addSuppressed(Throwable) 
additions} to

 * the clone's suppressed exceptions do not affect original exception's
 * suppressed exceptions and vice versa.
 *
 * @param exception   the exception to clone.
 * @param  the type of exception
 * @param resetCause  if {@code true}, clone's cause is reset to an
 *uninitialized state.
 * @param resetSuppressed if {@code true} and original exception 
has suppression
 *enabled, clone's suppressed exceptions 
are cleared.
 * @return shallow clone of given exception augmented according to 
passed-in

 * flags.
 * @since 1.9
 */
@SuppressWarnings("unchecked")
public static  T clone(T exception,
boolean resetCause,
boolean resetSuppressed) {
try {
synchronized (exception) {
Throwable clone = (Throwable) exception.clone();
if (resetCause) {
// reset to uninitialized state
clone.cause = clone;
}
if (clone.suppressedExceptions != null &&
clone.suppressedExceptions != SUPPRESSED_SENTINEL) {
// suppressedExceptions has already been added to
// and suppression is enabled
clone.suppressedExceptions = resetSuppressed
? new ArrayList<>()
: new ArrayList<>(clone.suppressedExceptions);
}
return (T) clone;
}
} catch (CloneNotSupportedException e) {
throw new InternalError(e);
}
}


In ForkJoinTask.getThrowableException you could then replace the following:

private Throwable getThrowableException() {
int h = System.identityHashCode(this);
ExceptionNode e;
final ReentrantLock lock = exceptionTableLock;
lock.lock();
try {
expungeStaleExceptions();
ExceptionNode[] t = exceptionTable;
e = t[h & (t.length - 1)];
while (e != null && e.get() != this)
e = e.next;
} finally {
lock.unlock();
}
Throwable ex;
if (e == null || (ex = e.ex) == null)
return null;
if (e.thrower != Thread.currentThread().getId()) {
Class ec = ex.getClass();
try {
Constructor noArgCtor = null;
Constructor[] cs = ec.getConstructors();// public 
ctors only

for (int i = 0; i < cs.length; ++i) {
Constructor c = cs[i];
Class[] ps = c.getParameterTypes();
 

Re: RFR JDK-8141491: Unaligned memory access in Bits.c

[Mikael Vidstedt]

Have you looked anything at the performance of the generated code? As 
you may have seen I was playing around with an alternative 
implementation[1] which has the benefit of being pure C++ without 
compiler specific hints. That said, when I did some initial benchmarking 
of that it did seem like the performance impact was significant. I 
didn't have time to look at more in detail why, and will not have time 
to return to that until late next week earliest. It would be interesting 
to understand what type of performance you see with your patch.


Cheers,
Mikael


[1] 
http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.01/webrev/jdk.patch


On 2015-11-25 11:42, Coleen Phillimore wrote:

Sending to core-libs mailing list.

On 11/25/15 2:19 PM, Alexander Smundak wrote:

Please take a look at
http://cr.openjdk.java.net/~asmundak/8141491/jdk/webrev.00
that fixes the problem.

It utilizes the ability of some (GCC and Clang) to declare data
alignment explicitly.
I have verified it works on x86_64 Linux by running
jdk/test/java/nio/Buffer/Basic.java test

I need a sponsor.

Sasha

Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

[joe darcy]

Hello,

On 11/25/2015 8:48 AM, Mandy Chung wrote:

On Nov 24, 2015, at 5:54 PM, Iris Clark  wrote:

Hi.

Please review the new classes jdk.Version and jdk.OracleVersion.  These are
simple Java APIs to parse, validate, and compare version numbers.

  Webrev

http://cr.openjdk.java.net/~irisa/verona/8072379/webrev.1/

This looks good to me.  Alan raises a good question whether jdk.OracleVersion 
is intended to be pushed to OpenJDK.




I share the concerns that have been raised about the naming and 
placement of a class named "OracleVersion".


Is the intention that downstream JDK distributions, such as IcedTea, 
whether based on OpenJDK or otherwise, would provide their own 
specialization of the jdk.Version class?


If so, should there be some kind of provider interface to find system's 
the version interpreter?


For example, what class, if any would be expected to provide detailed 
analysis of the version string emitted by, say, a OpenJDK build used as 
the reference implementation of Java SE 9?


The equals / hashCode behavior of Version and OracleVersion is bit 
surprising and I think somewhat underspecified given the possibility of 
defining subclasses.


The (overridable) equals method in Version says "Two Versions are equal 
if and only if they represent the same version string." If that is 
interpreted to mean the Versions are equal if their toString output is 
equal, the toString spec says "Returns a string representation of this 
version." and the (overridable) implementation in Version looks at 
versions, pre, build, and optional.


Since OracleVersion does not override equals, a plain Version object and 
an OracleVersion object can compare as equal. Additionally, a 
VersionWithDifferentToStringOutput("1.2.3") object which overrides 
toString would not be semantically equivalent to a Version("1.2.3") 
object. Worse, there could be a non-communicability behavior in the 
equals method since


(new Version("1.2.3")).equals(new 
VersionWithDifferentToStringOutput("1.2.3"))


could return "true" while

(new VersionWithDifferentToStringOutput("1.2.3")).equals(new 
Version("1.2.3"))


could easily and legitimately return "false" by the specification.

How is this API supposed to behave if the component version strings have 
a numerical value greater than Integer.MAX_VALUE?


Was using Longs to record numerical versions rather than Integers 
considered?


Thanks,

-Joe

Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

[Roger Riggs]

Hi Iris,

I see the JEP says JDK specific, but does that rule out putting the 
version API in a Java.* package?

It would support the values found in the java.version, etc properties.
Perhaps as an nested class of System or Runtime?

Version.java:

Line 213:  Seems a bit wasteful to reparse the string after the matcher 
has done its work;

   but does not use the groups for the version components.

229:  The IAE("Terminal...") exception may not be that easily 
understood; can it say concisely

   that the build and optional elements are missing

264: current() should cache the value from the parse; it is likely to be 
called more than once and parsing

an version string is a relatively expensive.

334: the naming of one of the version elements as 'optional' may be 
confusing because optional is an adjective.
  Especially when the element is optional and the method named optional 
returns an Optional.

  Can the name be a cogent noun. how about 'info' for informational string

396:  I'm not sure why BigInteger is needed; other than perhaps because 
it has a constructor that takes a string.


433:  Optional has a .ifPresent(xxx) method that could be used to 
streamline the code.

  pre.ifPresent( v -> sb.append("-").append(v));


OracleVersion.java:   Can this be renamed more functionally to reflect 
that the 4'th component is a patch number.

   It might be useful to folks other than Oracle.

107: the constructor should be declared private since it is not needed 
outside the class.


I would have preferred the Tests to be written using TestNG.

Thanks, Roger



On 11/24/2015 8:54 PM, Iris Clark wrote:

Hi.

Please review the new classes jdk.Version and jdk.OracleVersion.  These are
simple Java APIs to parse, validate, and compare version numbers.

   Bug

 8072379: Implement jdk.Version and jdk.OracleVersion
 https://bugs.openjdk.java.net/browse/JDK-8072379

   Webrev

 http://cr.openjdk.java.net/~iris/verona/8072379/webrev.1/

   JavaDoc

 http://cr.openjdk.java.net/~iris/verona/8072379/doc.1/jdk/Version.html
 
http://cr.openjdk.java.net/~iris/verona/8072379/doc.1/jdk/OracleVersion.html

The .java files are predominantly javadoc. The code is relatively
straight-forward.

jdk.Version is the representation of the JDK version string as described in
JEP 223 ([0], 8061493).  The javadoc is largely taken from the description
section in the JEP.  The API is described in the "API" section.

jdk.OracleVersion extends jdk.Version and is the representation of the Oracle
JDK version string.  Its only purpose is to interpret the fourth element of
the version number as a patch release.

There are some minor discrepancies between the implementation and the JEP.
The JEP will need to be updated.  The most notable is the name of the package
("jdk" vs. the original "jdk.util").  The rename was recommended by Mark.

Thanks,
iris
  
[0] http://openjdk.java.net/jeps/223

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

[Roger Riggs]

Hi Stuart,

Comments:

Set.java:
 - of methods:  @throws IAE   "if the elements are duplicates" -> "if 
elements *contains *duplicates"


 - in the of() methods, would it be more efficient to add the 
individual object to the hashset w/o

   the intermediate list; don't create garbage that needs to be collected.

EnumSet.java:

 - the javadoc for the of(e) method says it is specified by: "

   |of
   
|
 in
   interface |Set
   
http://cr.openjdk.java.net/%7Esmarks/reviews/jep269/specdiff.20151123/java/util/EnumSet.html>
   extends java.lang.Enumhttp://cr.openjdk.java.net/%7Esmarks/reviews/jep269/specdiff.20151123/java/util/EnumSet.html>>>|"
   Must be a javadoc bug because Set is an interface and of is a static 
method.


   This anomaly incorrectly makes EnumSet show up in the diff.


List.java:
 - The use of 'Creates an immutable list...' implies a new List is 
created each time. (ditto @returns "newly created")

   I would use 'Returns an immutable list...'

 - I think I would have gone for 7 or 9 elements in the constructor, 
the 10 and 11 args forms
   just look like they would never be used.  (your comments not with 
standing)


 - in the implementation, it would helpful to use 
Objects.requireNonNull(e1, "e1") form to aid in debugging which arg was 
null.  (Ditto Map, and Set)



Map.java:
 - Might want to clarify that the duplicate check uses equals (not ==).
 - Same comments about the description using "creates/created" and "newly".
 - Map is even stranger than List with 20 arguments (10 arg/value pairs)
 - Capacity and load factor are not relevant for an immutable Map; can 
that be noted somewhere?
 - KeyValueHolder is more general than is needed; it does not need to 
inherit from Entry and could be a nested class in Map.


$,02, Roger



On 11/24/2015 1:26 AM, Stuart Marks wrote:

Hi all,

Please review these API and implementation changes that comprise the 
first integration of JEP 269. I intend to push this under the "initial 
API and skeleton implementation" subtask, JDK-8139232.


Changes since the previous review:
 - more precise wording regarding static factory methods (thanks Remi)
 - add defensive copy and test for List.of(E...) (thanks Michael Hixson)
 - more null checking and tests
 - various small wording cleanups
 - @since 9

I've left the fixed-arg overloads at ten for all three interfaces. The 
fixed-arg methods provide a useful fast path for initialization and 
non-desktop, non-server cases. The cost is some API clutter; ten 
elements or pairs is rather a lot. This number should be sufficient, 
though, to handle the vast majority of cases without having to switch 
to varargs. Note that the clutter is only in the API definitions, and 
it doesn't intrude into the point of call (at least for List and Set). 
For the Map case, it's particularly useful to have lots of fixed-arg 
overloads, since the varargs case requires switching APIs and adding 
more boilerplate.


I've also updated the JEP text to reflect the current proposal, mainly 
the removal of the static factory methods from the concrete classes.


JEP:

http://openjdk.java.net/jeps/269

API spec (basically List, Map, and Set):

http://cr.openjdk.java.net/~smarks/reviews/jep269/api.20151123/

Specdiff:

http://cr.openjdk.java.net/~smarks/reviews/jep269/specdiff.20151123/overview-summary.html 



Webrev:

http://cr.openjdk.java.net/~smarks/reviews/jep269/webrev.20151123/

Thanks,

s'marks

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

[Peter Levart]

On 11/25/2015 12:42 PM, Andrew Haley wrote:

On 11/24/2015 05:47 PM, Roger Riggs wrote:


Memory is an increasingly critical resource, we should be giving
developers more tools to manage their use of memory.  The Weak and
Soft reference forms of the cleaner make it easier to be aware of
and respond to increased memory pressure.

The management of memory is not hypothetical for most large
applications.  It was one topic that came up in questions at J1.
Developers do quite a bit of work trying to figure out algorithms
for working caches, serializing to disk, and having the data
available when it is needed.  There is a lot of guesswork about how
GC is working and how it behaves at/near the limits.  SoftReferences
are a bit of a blunt instrument but they provide evidence an
application can use to regulate its long term memory use.

The WeakReference forms, if provided, can be an alternative to the
ideosyncratic cleanup approaches used in various Weak keyed and weak
values collections.  If there are other mechanisms contemplated for
more efficient memory management then perhaps these are not
necessary but if not the current mechanisms should be easier to use.

By "memory" here, do you mean native memory for buffers, etc?  I'm
guessing so.  If so, I'm not sure that it makes sense to think of this
as a cure for flaky finalization.  We've got a cure for early
finalization now with keepAlive() (or whatever it gets called) but
late (or never) finalization is as far as I can see unfixable.  IMVHO
it makes more sense to encourage developers to get away from lifecycle
maintenance based on reachability.

Unfortunately the current design for ByteBuffers does not allow
unmap(), so large mapped buffers may hang around for a long time.
4724038 says

  "We ... have given this problem a lot of thought ...  We have yet to
  come up with a way to implement an unmap() method that's safe,
  efficient, and plausibly portable across operating systems.  We've
  explored several other alternatives aside from the two described
  above, but all of them were even more problematic.  We'd be thrilled
  if someone could come up with a workable solution, so we'll leave
  this bug open in the hope that it will attract attention from someone
  more clever than we are."

I'm very tempted to take a bite at this, but the above text is rather
forbidding.  I think I know how to do it. (Famous last words?)

Andrew.


I wish you luck, Andrew. But in case you find any obstacles on the road 
which you can't solve, I have an idea for an alternative solution. As I 
understand, the problem is when a ByteBuffer that lives long enough is 
moved to an old-generation region which is very rarely scanned and so 
its life is prolonged more than necessary. If that's the case then what 
about the following:


- reserve a special value of object age in the object header to mean: 
This is a "Dorian Grey" object. (or if there is a spare bit that could 
be used in object header, it could be used to mark it so)
- make collectors treat this value specially (i.e. don't increment it 
and treat it as a young object - don't ever move such object to 
old-generation)
- have an internal API to patch this value on a given object's header at 
construction time (maybe also reset it to initial young value if needed 
later)


direct ByteBuffer's could use this internal API to declare themselves 
"Dorian Greys" at construction. They would never be moved to 
old-generation and so would be scanned frequently enough to be found 
phantom-reachable in-time.


I think this could work as there are not many instances of direct 
buffers alive at any one time and so this would not affect young 
generation too much. I understand that such byte buffers would 
frequently have old-to-young links that would have to be tracked with 
all the needed overhead. But that might be a good solution anyway for 
some applications.


What do you think?

Regards, Peter

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

[Andrew Haley]

On 11/25/2015 12:39 PM, Peter Levart wrote:
> What do you think?

It's very problematic.  First off, collection often clears the young
generation altogether, promoting everything.  Secondly, I think we are
already short of header bits in some cases.  Thirdly, this requires
all collectors to be changed.  Fourthy, some collectors don't use
multiple generations: they can just allow a dense prefix to pile up at
the left-hand end of the heap which they don't bother to collect.
Etc, etc...

Andrew.

Re: [9] RFR of 8032027: Add BigInteger square root methods

[Brian Burkhalter]

On Nov 16, 2015, at 10:00 AM, joe darcy  wrote:

> Returning to this review…

Likewise …

Please refer to the updated patch at 
http://cr.openjdk.java.net/~bpb/8032027/webrev.02/.

> A few comments and suggestions:
> 
> 2452 public BigInteger[] sqrtAndRemainder() {
> 2453 BigInteger s = sqrt();
> 2454 BigInteger r = this.subtract(s.square());
> 2455 return new BigInteger[] {s, r};
> 2456 }
> 
> It that "remainder >= 0" would be a good assert to add before line 2455.

Assert added.

> As a stylistic matter, in MutableBigInteger I would prefer a direct check of 
> bitLength rather than relying on the exception being thrown from 
> longValueExact. Something like
> 
> if (bitLength < 63)
>   // use double initial approx
> else
>  // use other technique

Changed as suggested.

> In the tests, use of lambda could allow the core testing logic to be shared.

I don’t know precisely what was expected but the test has been modified to 
reduce redundant code.

Thanks,

Brian

Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

[Alan Bateman]

On 25/11/2015 01:54, Iris Clark wrote:

Hi.

Please review the new classes jdk.Version and jdk.OracleVersion.  These are
simple Java APIs to parse, validate, and compare version numbers.


Is jdk.OracleVersion really intended to be pushed to OpenJDK? Should it 
be final? There are few imports at the top that don't appear to be used.


jdk.Version looks good. Has there been any thought/suggestions yet on 
which module this API will move too?


I suspect the docs build will need to be looked at. The javadoc for 
jdk.Exported is currently generated in the javac tree javadoc for some 
reason (maybe because that annotation started out in the langtools repo).


-Alan

Re: RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe

[Peter Levart]

Hi Paul,

Browsing through ArraysSupport. So far I noticed just two nits ...

You define those nice constants like LOG2_ARRAY_CHAR_INDEX_SCALE, etc., 
but then use hard-coded literals in mismatch methods:


 295 static int mismatch(char[] a, int aFromIndex,
 296 char[] b, int bFromIndex,
 297 int length) {
 298 int i = 0;
 299 if (length > 3) {
 300 int aOffset = Unsafe.ARRAY_CHAR_BASE_OFFSET + 
(aFromIndex << 1); // << here
 301 int bOffset = Unsafe.ARRAY_CHAR_BASE_OFFSET + 
(bFromIndex << 1); // << here

 302 i = vectorizedMismatch(
 303 a, aOffset,
 304 b, bOffset,
 305 length, LOG2_ARRAY_CHAR_INDEX_SCALE);
 306 if (i >= 0)
 307 return i;
 308 i = length - ~i;
 309 }
 310 for (; i < length; i++) {
 311 if (a[aFromIndex + i] != b[bFromIndex + i])
 312 return i;must
 313 }
 314 return -1;
 315 }


The mentioning of "reference component types" in javadoc for 
vectorizedMismatch:


  52 /**
  53  * Find the relative index of the first mismatching pair of 
elements in two
  54  * arrays of the same component type.   For reference 
component types the
  55  * reference values (as opposed to what they reference) will 
be matched.
  56  * Pairs of elements will be tested in order relative to given 
offsets into

  57  * both arrays.

... is probably a left-over, since there is no caller of the method 
using reference arrays (yet?). You should probably mention that doing so 
is not safe. As you might know, object pointers are a "movable target". 
GC can rewrite them as it moves objects around and if you "cast" an 
object pointer (or two of them) into a long value and store it in a long 
variable, GC can't track that and update the value, so you might be 
comparing an old address of an object with new address of the same 
object and get a mismatch.


I don't know much about intrinsified code. Whether it can be interrupted 
by GC or not, so it might be able to compare object references directly, 
but then the bytecode version of the method would have to have a 
special-case for reference arrays if it is executed in this form anytime.



Regards, Peter

On 11/25/2015 10:53 AM, Paul Sandoz wrote:

Hi,

And this is the review for the Java part:

   
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/

Which will be updated to add @HotSpotIntrinsicCandidate when JDK-8143355 is 
pushed. [1]

The plan is all reviewed changes will be pushed to hs-comp and then we follow 
up:

   1) adding the intrinsic to other platforms

   2) improving C1 (perhaps even the interpreter?) since the intrinsic is a 
stub which IIUC makes it easier to plug in.

   3) take a swing at consolidating other equal/compare intrinsics, such as 
those for char[]/String-based equal/compare

   4) adding methods to String such as mismatch method.

I can help by pushing all reviewed patches. I will kick off a JPRT run with all 
patches applied.

I did evaluate/test the HotSpot patch (stared at the patch and generated code for 
UseAVX < 2, and measured) and reviewed with my limited knowledge of HotSpot.

Paul.

[1]
diff -r 01b49c2960fd src/java.base/share/classes/java/util/ArraysSupport.java
--- a/src/java.base/share/classes/java/util/ArraysSupport.java  Tue Nov 17 
15:42:53 2015 +0100
+++ b/src/java.base/share/classes/java/util/ArraysSupport.java  Tue Nov 17 
17:05:09 2015 +0100
@@ -24,7 +24,7 @@
  */
package java.util;

-//import jdk.internal.HotSpotIntrinsicCandidate;
+import jdk.internal.HotSpotIntrinsicCandidate;
import jdk.internal.misc.Unsafe;

class ArraysSupport {
@@ -72,7 +72,7 @@
  * If a mismatch is not found the negation of one plus the number of
  * remaining pairs of elements to be checked in the tail of the two arrays.
  */
-//@HotSpotIntrinsicCandidate
+@HotSpotIntrinsicCandidate
 static int vectorizedMismatch(Object a, long aOffset,
   Object b, long bOffset,
   int length,


On 25 Nov 2015, at 01:00, Deshpande, Vivek R  
wrote:

Hi all

We would like to contribute a patch from Intel which optimizes 
vectorizedMismatch() method in java.util.ArraysSupport.java for X86 
architecture using AVX instructions.
The improvement gives more than 2x gain over Unsafe implementation for long 
arrays.
The bug is blocked by bug: vectorized support for array equals/compare/mismatch 
using Unsafe (https://bugs.openjdk.java.net/browse/JDK-8136924.)
Could you please review and sponsor this patch.

Bug-id:
https://bugs.openjdk.java.net/browse/JDK-8143355
webrev:
http://cr.openjdk.java.net/~mcberg/8143355/webrev.01/

Thanks and regards,
Vivek

RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe

[Paul Sandoz]

Hi,

And this is the review for the Java part:

  
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/

Which will be updated to add @HotSpotIntrinsicCandidate when JDK-8143355 is 
pushed. [1]

The plan is all reviewed changes will be pushed to hs-comp and then we follow 
up:

  1) adding the intrinsic to other platforms

  2) improving C1 (perhaps even the interpreter?) since the intrinsic is a stub 
which IIUC makes it easier to plug in.

  3) take a swing at consolidating other equal/compare intrinsics, such as 
those for char[]/String-based equal/compare

  4) adding methods to String such as mismatch method.

I can help by pushing all reviewed patches. I will kick off a JPRT run with all 
patches applied.

I did evaluate/test the HotSpot patch (stared at the patch and generated code 
for UseAVX < 2, and measured) and reviewed with my limited knowledge of HotSpot.

Paul.

[1]
diff -r 01b49c2960fd src/java.base/share/classes/java/util/ArraysSupport.java
--- a/src/java.base/share/classes/java/util/ArraysSupport.java  Tue Nov 17 
15:42:53 2015 +0100
+++ b/src/java.base/share/classes/java/util/ArraysSupport.java  Tue Nov 17 
17:05:09 2015 +0100
@@ -24,7 +24,7 @@
 */
package java.util;

-//import jdk.internal.HotSpotIntrinsicCandidate;
+import jdk.internal.HotSpotIntrinsicCandidate;
import jdk.internal.misc.Unsafe;

class ArraysSupport {
@@ -72,7 +72,7 @@
 * If a mismatch is not found the negation of one plus the number of
 * remaining pairs of elements to be checked in the tail of the two arrays.
 */
-//@HotSpotIntrinsicCandidate
+@HotSpotIntrinsicCandidate
static int vectorizedMismatch(Object a, long aOffset,
  Object b, long bOffset,
  int length,

> On 25 Nov 2015, at 01:00, Deshpande, Vivek R  
> wrote:
> 
> Hi all
> 
> We would like to contribute a patch from Intel which optimizes 
> vectorizedMismatch() method in java.util.ArraysSupport.java for X86 
> architecture using AVX instructions.
> The improvement gives more than 2x gain over Unsafe implementation for long 
> arrays.
> The bug is blocked by bug: vectorized support for array 
> equals/compare/mismatch using Unsafe 
> (https://bugs.openjdk.java.net/browse/JDK-8136924.)
> Could you please review and sponsor this patch.
> 
> Bug-id:
> https://bugs.openjdk.java.net/browse/JDK-8143355
> webrev:
> http://cr.openjdk.java.net/~mcberg/8143355/webrev.01/
> 
> Thanks and regards,
> Vivek

RE: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion

[Iris Clark]

Hi, Alan.

Thanks for looking.

> Is jdk.OracleVersion really intended to be pushed to OpenJDK? 

That class should be available to users of the Oracle JDK.  It is
not applicable to OpenJDK.

> Should it be final? 

Yes.

> There are few imports at the top that don't appear to be used.

Oops.  Thought I cleaned those up. 

Here's the diff for both of these changes to OracleVersion:

28,33d27
< import java.util.regex.Matcher;
< import java.util.regex.Pattern;
< import java.util.ArrayList;
< import java.util.List;
< import java.util.Optional;
<
86c80
< public class OracleVersion extends Version
---
> public final class OracleVersion extends Version

> jdk.Version looks good. Has there been any thought/suggestions yet on 
> which module this API will move too?

No.  My best guess is jdk.dev for Version but I'm willing to take 
suggestions.  I'd prefer to keep Version and OracleVersion in the same 
module, but if they need to be split, I'll need to change the access 
modifier for the Version constructor.

> I suspect the docs build will need to be looked at.

Definitely.  I was surprised (but pleased) that javadoc ran on the new 
files, but the actual bundle surprised me.  It is not correct for either
jdk.Exported or these classes.  I was unable to find a more suitable 
existing javadoc bundle.  Is there one?  

Regards,
iris

-Original Message-
From: Alan Bateman 
Sent: Wednesday, November 25, 2015 4:02 AM
To: Iris Clark; core-libs-dev@openjdk.java.net
Cc: verona-...@openjdk.java.net
Subject: Re: RFR: 8072379: Implement jdk.Version and jdk.OracleVersion


On 25/11/2015 01:54, Iris Clark wrote:
> Hi.
>
> Please review the new classes jdk.Version and jdk.OracleVersion.  
> These are simple Java APIs to parse, validate, and compare version numbers.

Is jdk.OracleVersion really intended to be pushed to OpenJDK? Should it be 
final? There are few imports at the top that don't appear to be used.

jdk.Version looks good. Has there been any thought/suggestions yet on which 
module this API will move too?

I suspect the docs build will need to be looked at. The javadoc for 
jdk.Exported is currently generated in the javac tree javadoc for some reason 
(maybe because that annotation started out in the langtools repo).

-Alan

Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-8139232)

[Paul Benedict]

Chris, you raise a good question. Example: JPA entities stored in an
immutable list and the list belongs to a stateful EJB that gets passivated
or clustered. Obviously, serialization would be occuring.

Cheers,
Paul

On Wed, Nov 25, 2015 at 10:14 AM, Chris Hegarty 
wrote:

> On 24 Nov 2015, at 23:27, Stuart Marks  wrote:
> > ….
> >
> > But in the hypothetical value-typed future, we might want to return
> value types from at least some of the factory methods. Value types have no
> notion of identity, so we don't want to make any statements that lead to
> thinking about the identity of the returned object, even to the extent of
> saying that it "might" be the "same" instance as one previously returned.
> >
> > Based on this, it occurs to me that I should add the "value-based"
> disclaimer to the relevant section of class doc. (I also note that,
> off-line, John Rose had already prompted me to do this, so I should heed
> his advice.)
>
> Is there any impact on the Serializability of these collections, if
> they are “value” based?  I don’t think so, but I’m not sure, since
> their serial form is not documented.  Note to self: should we
> document their serial form?
>
> > I'll also change the method docs to say something like,
> >
> > * Returns an immutable list containing  elements.
> > * ...
> > * @return a list containing the specified elements
>
> Looks fine.
>
> -Chris.
>
>

Re: Promptly cleaning direct ByteBuffer(s) - was: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

[Andrew Haley]

On 11/25/2015 03:45 PM, Roger Riggs wrote:
> Prompt cleanup can't rely on GC.

Yes, that's the key.  If people need prompt cleanup, they *really* need it
because they've run out of memory or address space.  Best effort won't do it.

Andrew.

Re: Promptly cleaning direct ByteBuffer(s) - was: Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

[Roger Riggs]

Hi,

Seems like a reprise from September of "Suggested fix for JDK-4724038 
(Add unmap method to MappedByteBuffer)".

Prompt cleanup can't rely on GC.

Roger


On 11/25/2015 10:31 AM, Peter Levart wrote:

Changing the subject to not hijack the thread...

On 11/25/2015 01:54 PM, Andrew Haley wrote:

On 11/25/2015 12:39 PM, Peter Levart wrote:

What do you think?

It's very problematic.  First off, collection often clears the young
generation altogether, promoting everything.


This could be a best-effort algorithm. If it must clear the young 
generation, it would. User would have to size it accordingly to 
accommodate for extra space needed by direct ByteBuffers staying in 
the young gen forever.



   Secondly, I think we are
already short of header bits in some cases.


How many bits are there for object age? 4 ? This means 16 values. If 
one value is "reserved" for eternally-young objects, there would still 
be 15 values for normal operation.



   Thirdly, this requires
all collectors to be changed.


Why? For start, only the most popular collector used in those 
applications could be modified and the feature could be optional 
(guarded by switch). API calls would be no-ops in unsupported 
collectors or when the feature is not enabled.



   Fourthy, some collectors don't use
multiple generations: they can just allow a dense prefix to pile up at
the left-hand end of the heap which they don't bother to collect.


Those would not be supported.


Etc, etc...


Maybe. Would have to dive into VM to find out. ;-)



Andrew.


Regards, Peter

Re: Reference.reachabilityFence

[David Holmes]

On 25/11/2015 3:27 AM, Vitaly Davidovich wrote:


The choice of reachabilityFence was in part motivated by hearing
about mistakes in using C# keepAlive where people would place keepAlive
before uses of fields, rather than after them. A more accurate name
should reduce this error in Java.



I don't see how reachabilityFence would help prevent that type of
mistake/usage.  Having used KeepAlive in .NET, I personally think it's a
better and more appropriate name and has the "demarcation" aspect (i.e.
"keep this alive until the point where I wrote KeepAlive").  But, it's a
bikeshed so I won't get hung up on it.


KeepAlive sounds like it might "tag" the reference in some way so that 
it is always kept alive with a scope - and hence suggests incorrect usage:


Foo f = ...
Reference.keepAlive(f);
...
// oops f not live here after all

keepAliveAtLeastTillHere would be more explicit. reachabilityFence has 
no obvious intepretation so one is forced to consult the documentation 
and check one is using it correctly. :)


Cheers,
David


On Tue, Nov 24, 2015 at 12:06 PM, Doug Lea  wrote:


On 11/24/2015 09:09 AM, Andrew Haley wrote:


Bikeshedding,

On 11/24/2015 01:07 PM, Vitaly Davidovich wrote:


How about keepAlive? Reference.keepAlive(Object) reads better, IMO.



It does indeed.  Imperative names for methods almost always read better,
IMO.  And although we probably don't don't much care about C#, it too
uses the name KeepAlive() for this.



Well, it is not an imperative notion, it is a demarcation.
More like a semicolon than an action. (Which is the realm of fences.)

The choice of reachabilityFence was in part motivated by hearing
about mistakes in using C# keepAlive where people would place keepAlive
before uses of fields, rather than after them. A more accurate name
should reduce this error in Java.

-Doug

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

[Aleksey Shipilev]

On 11/25/2015 06:14 PM, Claes Redestad wrote:
> On 2015-11-25 16:06, Aleksey Shipilev wrote:
>> On 11/25/2015 05:44 PM, Claes Redestad wrote:
>> Nit: don't you want to inline BD.getTypeChar into BD.unparseSig to avoid
>> "c != 'L')" comparison? Or you want to keep it separate as the utility
>> method?
> 
> Inlining the isPrimitive check should be enough to avoid extra comparisons:
> 
> http://cr.openjdk.java.net/~redestad/8143926/webrev.02

Yes. Looks good!

-Aleksey

Re: RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

[Aleksey Shipilev]

On 11/25/2015 05:44 PM, Claes Redestad wrote:
> please review this small cleanup/startup improvement which defers a few
> classes from loading during startup and consolidates some static utility
> methods to generate type signatures:
> 
> webrev: http://cr.openjdk.java.net/~redestad/8143926/webrev.01/
> bug: https://bugs.openjdk.java.net/browse/JDK-8143926

Looks okay, even as the cleanup, not taking the performance improvements
into account.

Nit: don't you want to inline BD.getTypeChar into BD.unparseSig to avoid
"c != 'L')" comparison? Or you want to keep it separate as the utility
method?

Thanks,
-Aleksey

RFR: 8143926: ObjectStreamField constructor eagerly load ObjectStreamClass

[Claes Redestad]

Hi,

please review this small cleanup/startup improvement which defers a few 
classes from loading during startup and consolidates some static utility 
methods to generate type signatures:


webrev: http://cr.openjdk.java.net/~redestad/8143926/webrev.01/
bug: https://bugs.openjdk.java.net/browse/JDK-8143926

/Claes

RFR 6856817: Poor performance of Writer#append with CharBuffer

[vyom]

Hi All,

Please review my changes for below bug.

Bug:JDK-6856817 : Poor performance of Writer#append with CharBuffer
Webrev: http://cr.openjdk.java.net/~vtewari/6856817/webrev0.4/ 



This change will avoid the redundant toString/CharBuffer.wrap in case of 
OutputStreamWriter.append(CharBuffer).


In case of OutputStreamWriter.append(CharBuffer) we are doing 
CharBuffer->String->char[]->CharBuffer conversion this change will avoid 
redundant conversion.


Thanks,
Vyom

Re: RFR: jsr166 jdk9 integration wave 2

[Doug Lea]

On 11/25/2015 03:05 AM, Peter Levart wrote:

On 11/25/2015 01:59 AM, Martin Buchholz wrote:

On Tue, Nov 24, 2015 at 2:30 PM, Peter Levart mailto:peter.lev...@gmail.com>> wrote:
What do you think of exception cloning?
Making copies of java objects has historically been troublesome (e.g.
Cloneable).


I was only thinking of Cloneable. Serialization is troublesome. If Throwable was
retrofitted to implement Cloneable and have the following new static method:


I still think this would be a useful feature, assuming no hidden snags.
In addition to CompletableFuture, we might be able to use it instead of
emulating a variant of it in ForkJoinTask.getThrowableException.
There are probably other candidate uses elsewhere (although I can't
think of any offhand).

In the mean time though, I think using addSuppressed in
CompletableFuture.whenComplete is the best we can do, and
surely better than not doing it.

-Doug



 /**
  * {@link Object#clone() Clones} given {@code exception} and returns it's
clone which
  * shares all state with original exception (shallow clone) except for the
possible list of already
  * {@link #addSuppressed(Throwable) added} {@link #getSuppressed() 
suppressed}
  * exceptions. The suppressed exception instances are not cloned, just the
  * list containing them. Further {@link #addSuppressed(Throwable) 
additions}
  * to the suppressed exceptions of the returned clone instance
  * don't affect the suppressed exceptions of original exception and vice 
versa.
  *
  * @param exception the exception to clone.
  * @paramthe type of exception
  * @return shallow clone of given exception with suppressed exception
  * list shallow-cloned
  * @since 1.9
  */
 @SuppressWarnings("unchecked")
 public static  T clone(T exception) {
 try {
 Throwable clone = (Throwable) exception.clone();
 if (clone.suppressedExceptions != null &&
 clone.suppressedExceptions != SUPPRESSED_SENTINEL) {
 clone.suppressedExceptions = new
ArrayList<>(clone.suppressedExceptions);
 }
 return (T) clone;
 } catch (CloneNotSupportedException e) {
 throw new InternalError(e);
 }
 }


...then would you prefer using it or would you nevertheless prefer swapping the
roles of exceptions in whenComplete?

Regards, Peter

Re: RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe

[Paul Sandoz]

Hi Peter,

> On 25 Nov 2015, at 12:21, Peter Levart  wrote:
> 
> Hi Paul,
> 
> Browsing through ArraysSupport. So far I noticed just two nits ...
> 
> You define those nice constants like LOG2_ARRAY_CHAR_INDEX_SCALE, etc., but 
> then use hard-coded literals in mismatch methods:
> 
> 295 static int mismatch(char[] a, int aFromIndex,
> 296 char[] b, int bFromIndex,
> 297 int length) {
> 298 int i = 0;
> 299 if (length > 3) {
> 300 int aOffset = Unsafe.ARRAY_CHAR_BASE_OFFSET + (aFromIndex << 
> 1); // << here
> 301 int bOffset = Unsafe.ARRAY_CHAR_BASE_OFFSET + (bFromIndex << 
> 1); // << here
> 302 i = vectorizedMismatch(
> 303 a, aOffset,
> 304 b, bOffset,
> 305 length, LOG2_ARRAY_CHAR_INDEX_SCALE);
> 306 if (i >= 0)
> 307 return i;
> 308 i = length - ~i;
> 309 }
> 310 for (; i < length; i++) {
> 311 if (a[aFromIndex + i] != b[bFromIndex + i])
> 312 return i;must
> 313 }
> 314 return -1;
> 315 }
> 

Doh, thanks i will update to use those constants.


> 
> The mentioning of "reference component types" in javadoc for 
> vectorizedMismatch:
> 
>  52 /**
>  53  * Find the relative index of the first mismatching pair of elements 
> in two
>  54  * arrays of the same component type.   For reference component types 
> the
>  55  * reference values (as opposed to what they reference) will be 
> matched.
>  56  * Pairs of elements will be tested in order relative to given 
> offsets into
>  57  * both arrays.
> 
> ... is probably a left-over, since there is no caller of the method using 
> reference arrays (yet?).

Right “yet", we were contemplating how useful it would be for ref types, with 
the likely hood being it would bail out of the mismatch more frequently (far 
more so than say that for NaNs of float/double). At this point there seems to 
be little value using it for ref arrays.


> You should probably mention that doing so is not safe. As you might know, 
> object pointers are a "movable target". GC can rewrite them as it moves 
> objects around and if you "cast" an object pointer (or two of them) into a 
> long value and store it in a long variable, GC can't track that and update 
> the value, so you might be comparing an old address of an object with new 
> address of the same object and get a mismatch.

We are in Unsafe territory :-)

Since the Java mismatch method and the intrinsic only make temporary reads, 
IIUC such updates by GC to the array can only occur at a safe points, and i 
don’t think int loops produce a safe point check within the hot loop and nor 
does the intrinsic, is this really an issue?


I forgot to mention in my TODO list that i have plans to reuse the unsafe 
vectorizedMismatch method within nio heap/direct buffers, so it is likely 
ArraysSupport will get moved to some jdk.internal.* package at some point.

Paul.

> 
> I don't know much about intrinsified code. Whether it can be interrupted by 
> GC or not, so it might be able to compare object references directly, but 
> then the bytecode version of the method would have to have a special-case for 
> reference arrays if it is executed in this form anytime.
> 
> 
> Regards, Peter
> 
> On 11/25/2015 10:53 AM, Paul Sandoz wrote:
>> Hi,
>> 
>> And this is the review for the Java part:
>> 
>>   
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/
>> 
>> Which will be updated to add @HotSpotIntrinsicCandidate when JDK-8143355 is 
>> pushed. [1]
>> 
>> The plan is all reviewed changes will be pushed to hs-comp and then we 
>> follow up:
>> 
>>   1) adding the intrinsic to other platforms
>> 
>>   2) improving C1 (perhaps even the interpreter?) since the intrinsic is a 
>> stub which IIUC makes it easier to plug in.
>> 
>>   3) take a swing at consolidating other equal/compare intrinsics, such as 
>> those for char[]/String-based equal/compare
>> 
>>   4) adding methods to String such as mismatch method.
>> 
>> I can help by pushing all reviewed patches. I will kick off a JPRT run with 
>> all patches applied.
>> 
>> I did evaluate/test the HotSpot patch (stared at the patch and generated 
>> code for UseAVX < 2, and measured) and reviewed with my limited knowledge of 
>> HotSpot.
>> 
>> Paul.
>> 
>> [1]
>> diff -r 01b49c2960fd src/java.base/share/classes/java/util/ArraysSupport.java
>> --- a/src/java.base/share/classes/java/util/ArraysSupport.java   Tue Nov 
>> 17 15:42:53 2015 +0100
>> +++ b/src/java.base/share/classes/java/util/ArraysSupport.java   Tue Nov 
>> 17 17:05:09 2015 +0100
>> @@ -24,7 +24,7 @@
>>  */
>> package java.util;
>> 
>> -//import jdk.internal.HotSpotIntrinsicCandidate;
>> +import jdk.internal.HotSpotIntrinsicCandidate;
>> import jdk.internal.misc.Unsafe;
>> 
>> class ArraysSupp

Re: RFR 9: 8138696 : java.lang.ref.Cleaner - an easy to use alternative to finalization

[Andrew Haley]

On 11/24/2015 05:47 PM, Roger Riggs wrote:

> Memory is an increasingly critical resource, we should be giving
> developers more tools to manage their use of memory.  The Weak and
> Soft reference forms of the cleaner make it easier to be aware of
> and respond to increased memory pressure.
> 
> The management of memory is not hypothetical for most large
> applications.  It was one topic that came up in questions at J1.
> Developers do quite a bit of work trying to figure out algorithms
> for working caches, serializing to disk, and having the data
> available when it is needed.  There is a lot of guesswork about how
> GC is working and how it behaves at/near the limits.  SoftReferences
> are a bit of a blunt instrument but they provide evidence an
> application can use to regulate its long term memory use.
> 
> The WeakReference forms, if provided, can be an alternative to the
> ideosyncratic cleanup approaches used in various Weak keyed and weak
> values collections.  If there are other mechanisms contemplated for
> more efficient memory management then perhaps these are not
> necessary but if not the current mechanisms should be easier to use.

By "memory" here, do you mean native memory for buffers, etc?  I'm
guessing so.  If so, I'm not sure that it makes sense to think of this
as a cure for flaky finalization.  We've got a cure for early
finalization now with keepAlive() (or whatever it gets called) but
late (or never) finalization is as far as I can see unfixable.  IMVHO
it makes more sense to encourage developers to get away from lifecycle
maintenance based on reachability.

Unfortunately the current design for ByteBuffers does not allow
unmap(), so large mapped buffers may hang around for a long time.
4724038 says

 "We ... have given this problem a lot of thought ...  We have yet to
 come up with a way to implement an unmap() method that's safe,
 efficient, and plausibly portable across operating systems.  We've
 explored several other alternatives aside from the two described
 above, but all of them were even more problematic.  We'd be thrilled
 if someone could come up with a workable solution, so we'll leave
 this bug open in the hope that it will attract attention from someone
 more clever than we are."

I'm very tempted to take a bite at this, but the above text is rather
forbidding.  I think I know how to do it. (Famous last words?)

Andrew.

Re: RFR: jsr166 jdk9 integration wave 2

[Martin Buchholz]

On Mon, Nov 16, 2015 at 2:42 PM, Aleksey Shipilev <
aleksey.shipi...@oracle.com> wrote:

>
>
> PhaserBasic/:
>  * Are those tracing statements ("// trace("barrier action",
> startTime);") kept for a reason? Should we conditionalize them with
> "static final boolean"-s?
>

Those tracing/debugging statements are now rewritten to be less horrible,
as in StampedLock/Basic.java.  Future improvements should probably leverage
power of testng.

Re: [preview] Adding java.lang.Runtime.getVMArguments() method

[Staffan Larsen]

Also remember that that java launcher is not the only launcher used with the 
JVM. There are lots of apps that use the invocation API to start the JVM, and 
there is no standardized way to propagate the command line or even the 
Main-Class to the JVM. This is currently an outage in serviceability tools such 
as jps and jcmd. 

https://bugs.openjdk.java.net/browse/JDK-6174973: 
 "Process names don't appear 
in jps output when JNI is used to launch”
https://bugs.openjdk.java.net/browse/JDK-6456333: 
 "Incorrect jar name handle 
by jps in case java -jar.”
https://bugs.openjdk.java.net/browse/JDK-7012002: 
 "JPS output is wrong”

Thanks,
/Staffan

> On 25 nov. 2015, at 03:53, Roger Riggs  wrote:
> 
> Hi,
> 
> The ProcessHandle.current().info().arguments() has the operating system's view
> of the command and arguments.  Which may differ from what is passed to main[] 
> args.
> Perhaps for current() it should be special cased to exactly and always match 
> main(args)
> but that's a different question.
> 
> If the desired set of arguments is different from what is typed on the command
> line or is passed to main, the perhaps it should remain in RuntimeMXBean.
> A method on Runtime to return the arguments would be understood to be
> more general and match either main(args) or the true command line as typed.
> 
> Roger
> 
> 
> On 11/24/15 9:24 PM, David Holmes wrote:
>> On 25/11/2015 10:06 AM, Mandy Chung wrote:
>>> 
 On Nov 24, 2015, at 3:45 PM, Peter Levart  wrote:
 
 
 
 On 11/24/2015 05:49 PM, Jaroslav Bachorik wrote:
> Hi,
> 
> while working on an issue to clean up a code in java.base module using 
> reflection to access RuntimeMXBean (from java.management module) in order 
> to get hold of the VM arguments (yes, this won't work with module 
> boundaries in place) it was pointed out that this functionality should be 
> available in java.base without going through JMX.
 
 Isn't the following JDK9 API already providing that:
 
 ProcessHandle.current().info().arguments();
>>> 
>>> This is what I also start going after.
>>> 
>>> The launcher does some job on the command-line before passing to the VM, 
>>> e.g. @argfile support that expands the options specified in the file, add 
>>> -Djava.class.path and some system properties passing to the VM, take out -J 
>>> if they are JDK tool launchers etc.
>> 
>> I haven't looked at the two APIs but the command-line is potentially very 
>> different from the "VM arguments". The VM can get its arguments from the 
>> command-line, the launcher, options file and environment variables.
>> 
>> David
>> 
>>> Mandy
>>> 
> 

Re: RFR: jsr166 jdk9 integration wave 2

[Peter Levart]

On 11/25/2015 01:59 AM, Martin Buchholz wrote:



On Tue, Nov 24, 2015 at 2:30 PM, Peter Levart > wrote:



What do you think of exception cloning?


Making copies of java objects has historically been troublesome (e.g. 
Cloneable).  I have made clones of objects often in tests via 
deserialization + reserialization, but never in serious code.  So I'm 
hesitant.  We could try to make the serial clone + addSuppressed, and 
fall back to the original exception in case of failure.  This might 
work well in practice.  We might also discover lots of latent 
serialization bugs in exceptions.  Has decades of RMI caught most of 
the problems with this approach?  Can we have a serialization expert 
bless this?




I was only thinking of Cloneable. Serialization is troublesome. If 
Throwable was retrofitted to implement Cloneable and have the following 
new static method:


/**
 * {@link Object#clone() Clones} given {@code exception} and 
returns it's clone which
 * shares all state with original exception (shallow clone) except 
for the possible list of already
 * {@link #addSuppressed(Throwable) added} {@link #getSuppressed() 
suppressed}
 * exceptions. The suppressed exception instances are not cloned, 
just the
 * list containing them. Further {@link #addSuppressed(Throwable) 
additions}

 * to the suppressed exceptions of the returned clone instance
 * don't affect the suppressed exceptions of original exception and 
vice versa.

 *
 * @param exception the exception to clone.
 * @paramthe type of exception
 * @return shallow clone of given exception with suppressed exception
 * list shallow-cloned
 * @since 1.9
 */
@SuppressWarnings("unchecked")
public static  T clone(T exception) {
try {
Throwable clone = (Throwable) exception.clone();
if (clone.suppressedExceptions != null &&
clone.suppressedExceptions != SUPPRESSED_SENTINEL) {
clone.suppressedExceptions = new 
ArrayList<>(clone.suppressedExceptions);

}
return (T) clone;
} catch (CloneNotSupportedException e) {
throw new InternalError(e);
}
}


...then would you prefer using it or would you nevertheless prefer 
swapping the roles of exceptions in whenComplete?


Regards, Peter