Re: JDK 9 RFR of JDK-8144215: Test development task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and Service

[Hamlin Li]

Hi Daniel,

Thanks for the review, I follow you suggestion to create a new RFE 
https://bugs.openjdk.java.net/browse/JDK-8144460 to track the pushing 
for this new test.

webrev : http://cr.openjdk.java.net/~mli/8144460/webrev.01/
old one is moved to http://cr.openjdk.java.net/~mli/8144460/webrev.00/

Thank you
-Hamlin

On 2015/12/1 18:40, Daniel Fuchs wrote:

Hi Hamlin,

You should probably create a new open RFE for pushing this new
test.
I'm not sure we can use internal task ids in commit/push comments.

From looking at the test, it would be preferable to create
the loggers after setting up the stub that pretend that the
VM is not yet booted. In other words - in BootstrapLoggerAPIsTest
lines 53-56 should preferably be moved after line 74.

best regards,

-- daniel

On 01/12/15 04:37, Hamlin Li wrote:

Hi all,

Would you please help to review the test development of JDK-8144215
: Test development
task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and
Service.
webrev : http://cr.openjdk.java.net/~mli/8144215/webrev.00/

Thank you
-Hamlin

Re: RFR(xxs): 8143858: typo in Timer.purge() doc

[joe darcy]

Look good,

-Joe

On 12/1/2015 10:25 PM, Stuart Marks wrote:

Hi all,

Please review this tiny fix for a typo in the
the documentation of the Timer.purge() method.

Diff appended below.

Thanks!

s'marks

# HG changeset patch
# User smarks
# Date 1449025313 28800
#  Tue Dec 01 19:01:53 2015 -0800
# Node ID 01aa186248334bf669f075dd7913391b07387747
# Parent  8c9484fe1bb22b13e873ef8fcaeeff234e4dabca
8143858: typo in Timer.purge() doc
Reviewed-by: XXX

diff -r 8c9484fe1bb2 -r 01aa18624833 
src/java.base/share/classes/java/util/Timer.java
--- a/src/java.base/share/classes/java/util/Timer.javaTue Dec 01 
09:22:01 2015 +0100
+++ b/src/java.base/share/classes/java/util/Timer.javaTue Dec 01 
19:01:53 2015 -0800

@@ -447,7 +447,7 @@
  * is the number of tasks in the queue and c is the number of 
cancelled

  * tasks.
  *
- * Note that it is permissible to call this method from within a
+ * Note that it is permissible to call this method from within
  * a task scheduled on this timer.
  *
  * @return the number of tasks removed from the queue.

RFR(xxs): 8143858: typo in Timer.purge() doc

[Stuart Marks]

Hi all,

Please review this tiny fix for a typo in the
the documentation of the Timer.purge() method.

Diff appended below.

Thanks!

s'marks

# HG changeset patch
# User smarks
# Date 1449025313 28800
#  Tue Dec 01 19:01:53 2015 -0800
# Node ID 01aa186248334bf669f075dd7913391b07387747
# Parent  8c9484fe1bb22b13e873ef8fcaeeff234e4dabca
8143858: typo in Timer.purge() doc
Reviewed-by: XXX

diff -r 8c9484fe1bb2 -r 01aa18624833 
src/java.base/share/classes/java/util/Timer.java
--- a/src/java.base/share/classes/java/util/Timer.java	Tue Dec 01 09:22:01 2015 
+0100
+++ b/src/java.base/share/classes/java/util/Timer.java	Tue Dec 01 19:01:53 2015 
-0800

@@ -447,7 +447,7 @@
  * is the number of tasks in the queue and c is the number of cancelled
  * tasks.
  *
- * Note that it is permissible to call this method from within a
+ * Note that it is permissible to call this method from within
  * a task scheduled on this timer.
  *
  * @return the number of tasks removed from the queue.

Re: RFE Pre-review: Support for cloning exceptions

[Martin Buchholz]

I very much want object copying to be simple and easy, but Cloneable has
been under a cloud for a very long time and Effective Java Item 11 advises
to stay away from it.

Josh writes: """Given all of the problems associated with Cloneable, it’s
safe to say that other interfaces should not extend it, and that classes
designed for inheritance (Item 17) should not implement it. Because of its
many shortcomings, some expert programmers simply choose never to override
the clone method and never to invoke it except, perhaps, to copy arrays."""

I don't think we have any history of introducing Cloneable into an
inheritance hierarchy where it was not present before.  Most Throwable
subclasses are "mostly" immutable, but there is no rule that they cannot
have mutable state, which may be corrupted by cloning+mutating, as
explained in Item 11.

Technically, I think you'll need to provide a synchronized clone method on
Throwable to prevent a data race, although an actual bug may be impossible
to reproduce.  We'd like to have Throwable.clone declared to return
Throwable, but that would break subclasses that implemented Cloneable where
clone returned Object.


On Tue, Dec 1, 2015 at 3:22 AM, Peter Levart  wrote:

> Hi,
>
> There are at least two places in java.util.concurrent where it would be
> beneficial if java.lang.Throwable was Cloneable:
>
> - ForkJoinTask::getException() returns original exception thrown by the
> computation of the task when the task is completed exceptionally. The same
> exception is re-thrown in ForkJoinTask::join() or ForkJoinTask::invoke().
> In order for the re-thrown exception to contain meaningful and
> non-misleading stack-trace, the original exception is attempted to be
> replaced with the exception of the same type, with original exception
> attached as the cause, so both stack-traces are visible - the original
> stack trace and the stack-trace of the thread executing join() or invoke().
> In order to do that, ForkJoinTask resorts to using reflection and trying to
> construct new exception by invoking a constructor on the j.l.Class of the
> original exception. It 1st tries the constructor taking j.l.Throwable
> parameter (assumes it will be the cause) and if that doesn't work, it tries
> the no-arg constructor followed by calling initCause() on the result.
>
> This usually works for public exceptions with suitable public
> constructors, but is not guaranteed. So in case it doesn't work, it simply
> re-throws the original exception with the original stack-trace, which hides
> the point at which it was re-thrown (at join() or invoke()). I assume this
> will become more problematic with jigsaw where constructors of non-exported
> exceptions will become inaccessible.
>
> - CompletableFuture::whenComplete[Async]() are methods that return: "...a
> new CompletionStage with the same result or exception as  this stage, that
> executes the given action when this stage completes...". Given 'action' is
> a BiConsumer receiving the result or exception from 'this' stage, so it can
> act as a clean-up action. If this cleanup throws an exception, it becomes
> the result of the returned stage unless 'this' stage also completes with
> exception. Like in try-with-resources, the exception thrown in the body of
> try-with-resources statement has precedence over clean-up exception.
> Clean-up exception is added as suppressed exception. In CompletableFuture
> this presents a problem, because adding a suppressed exception to the
> exception of previous stage effectively modifies the result of the previous
> stage that has already completed. This is undesirable.
>
> So I would like to ask for feedback on a proposal to add cloning support
> to java.lang.Throwable and also how to proceed if this turns out to be
> acceptable (perhaps a CCC request?).
>
> The proposal is as follows:
>
> - add "implements Cloneable" to the j.l.Throwable
>
> - add the following public static method to j.l.Throwable:
>
>
> /**
>  * 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 an uninitialized state so 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
> cleared.
>  * 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)

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

[Joseph D. Darcy]

Hi Brian,

On 11/30/2015 3:24 PM, Brian Burkhalter wrote:

Hi Joe,

On Nov 29, 2015, at 10:01 AM, joe darcy > wrote:


The "if (...) " logic that is repeated a few times in this method 
could be pulled out into its own method, possibly one structured a 
bit differently to return the number of errors.


I think it would be acceptable to push the tests in their current 
state, but I would prefer to see a little more refactoring.


I would have expected some tests to directly work off of the 
definition of integer square root, namely that k^2 is less or or 
equal to the argument but (k+1)^2 is larger.


I have updated the patch per your comments above. The new version is here:

http://cr.openjdk.java.net/~bpb/8032027/webrev.03/ 



Thanks,

Brian


Current version looks okay. One more request, before pushing please add 
explicit test cases for the for the largest number having 63 bits and 
the smallest number having 64 bits. No need for another round of webrevs 
for that.


Thanks,

-Joe

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

[Rezaei, Mohammad A.]

That makes sense (and it's consistent with my layman's interpretation that 
List as a value-based is weird). In this particular case, I believe Stuart 
does want to make explicit claims for immutability and serializability.

In the case of the empty methods, I don't see why a strong claim about identity 
can't be made. The same claim exists today in Collections.empty*. As a user of 
the API, the more clarity/guarantees I can get, the better I feel about using 
the method. If I know a method is garbage-free, for example, I will use it, but 
if I don't have that guarantee, I might as well do my own "static final List 
EMPTY = ...".

Thanks
Moh

>-Original Message-
>From: Brian Goetz [mailto:brian.go...@oracle.com]
>Sent: Tuesday, December 01, 2015 10:03 PM
>To: Stuart Marks; Rezaei, Mohammad A. [Tech]
>Cc: 'core-libs-dev'
>Subject: Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK-
>8139232)
>
>Value-based is a property of types, not of instances.
>
>For disclaimers regarding the result of factory methods, it seems
>clearer to go to the traditional "make no assumptions about the type,
>mutability, serializability, or identity..." sort of language.
>
>
>
>On 11/25/2015 7:37 PM, Stuart Marks wrote:
>> 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

 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)

[Brian Goetz]

Value-based is a property of types, not of instances.

For disclaimers regarding the result of factory methods, it seems 
clearer to go to the traditional "make no assumptions about the type, 
mutability, serializability, or identity..." sort of language.




On 11/25/2015 7:37 PM, Stuart Marks wrote:
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 8136924 Vectorized support for array equals/compare/mismatch using Unsafe

[John Rose]

On Nov 25, 2015, at 3:21 AM, Peter Levart  wrote:
> 
> 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.

Here's the scoop on reading references as ints or longs:  Just don't.

Calling Unsafe.getLong or Unsafe.getInt on a reference variable is never a good 
idea.
The reason is that the GC is allowed to run between the moment the reference is 
picked up
(as a bit image in a primitive value) and the moment something is done with it. 
 This is
rare but if it happens, it will cause the bit image to be stale, with 
unpredictable results.
Can the GC execute if the live interval of the bit image is very, very short?
Probably not if the code was compiled, but remember that the code might
sometimes be interpreted also, even after it is compiled.

In the case of array-mismatch, comparing a broken bit-image of a pointer
against another non-broken one might produce a false equality result.
Very, very rarely.  And won't that be a nice surprise for someone?

— John

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

[Stuart Marks]

Hi all,

Thanks for the previous round of review comments. Here's an updated API and 
implementation for review.


I've run specdiff with the --hu ("hide unchanged") option, so only the bits of 
the specification that have changed are shown. As before, though, please ignore 
the spurious change to EnumSet caused by a javadoc bug.


API changes:
 - add clarifying notes on immutability
 - remove wording that implied creation of new objects
 - add "value-based" disclaimers
 - add ordering specification for List and non-ordering disclaimers
   for Set and Map
 - clarify that Map.ofEntries() doesn't store the Map.Entry objects, instead
   it extracts keys and values
 - Map.Entry instances returned from Map.entry() are *not* serializable

Other:
 - markup cleanups
 - small implementation cleanups

JEP:

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

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

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

Specdiff:


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

Webrev:

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

Thanks,

s'marks

Re: RFR: 8144214 Some log messages will be discarded when VM is bootstrapping.

[Hamlin Li]

On 2015/12/1 18:32, Daniel Fuchs wrote:

Hi Hamlin,

I see that you're going to push a test for this with
JDK-8144215;
I will also ask for your help to push the test code after the test pass 
the open review.


Looks good to me.

Do you need a sponsor for this fix?

Hi Daniel,

Yes, I need a sponsor for this fix, it will be great if you could help 
to push the code. :-)

Please check the push message below :

8144214: Some log messages will be discarded when VM is bootstrapping
Summary: use logp rather than log.
Reviewed-by: dfuchs
Contributed-by: Hamlin Li 

Thank you
-Hamlin



best regards,

-- daniel

On 30/11/15 12:28, Hamlin Li wrote:

Hi all,

Would you please help to review for
http://cr.openjdk.java.net/~mli/8144214/webrev.00/, which fixes bug
https://bugs.openjdk.java.net/browse/JDK-8144214.

Thank you
-Hamlin

Re: RFR 9: 8143876 : test/java/lang/ProcessHandle/TreeTest.java failed intermittently with assertion error

[joe darcy]

Hi Roger,

On 12/1/2015 6:05 PM, Roger Riggs wrote:

Hi Joe,

I do not know of any specific skew issues at the resolutions used. For 
example,
Linux records the start time in ticks  (1/60th to 100th of a second), 
not the full resolution
of the time of day clock. Typically, the child start time is at least 
a bit later
than the parent. If the maximum possible skew was known or estimated, 
the comparison
could take that into account.  For example, I would expect the skew 
across processors
to be less than 1sec (or more likely 10ms) or there would be bigger 
issues among native processes.


Okay; if the start time precision is relatively coarse that reduces the 
hazard of a problem here.


I think it is reasonable to go ahead with the current changes if is this 
kind of issue comes up in the future, a "fuzz" factor is determined and 
taken into consideration.


Thanks,

-Joe



Thanks, Roger


On 12/1/15 8:54 PM, Joseph D. Darcy wrote:

Hi Roger,

Looks fine.

Do you know if there are clock skew issues to be concerned with if 
the parent and child are spawned on different CPUs?


Thanks,

-Joe

On 12/1/2015 5:49 PM, Roger Riggs wrote:
Please review this change in ProcessHandle to validate parent pids 
provided by the OS.
Children of a process have start times that are the same or later 
than the parent.

The implementation of descendants(), and children(), and getParent()
are updated to validate the parent pid.

The problem is most pronounced on Windows; the parent pid reported 
for a
process may be stale if the parent exited.  The validation is 
applied in
platform neutral code and used on all platforms.  Platform specific 
code
is used on Windows for getParent(); the Linux platforms do the right 
thing.


Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-validate-ppid-8143879/

Issue:
   https://bugs.openjdk.java.net/browse/JDK-8143876

Thanks, Roger

Re: RFR 9: 8143876 : test/java/lang/ProcessHandle/TreeTest.java failed intermittently with assertion error

[Roger Riggs]

Hi Joe,

I do not know of any specific skew issues at the resolutions used. For 
example,
Linux records the start time in ticks  (1/60th to 100th of a second), 
not the full resolution
of the time of day clock. Typically, the child start time is at least a 
bit later
than the parent. If the maximum possible skew was known or estimated, 
the comparison
could take that into account.  For example, I would expect the skew 
across processors
to be less than 1sec (or more likely 10ms) or there would be bigger 
issues among native processes.


Thanks, Roger


On 12/1/15 8:54 PM, Joseph D. Darcy wrote:

Hi Roger,

Looks fine.

Do you know if there are clock skew issues to be concerned with if the 
parent and child are spawned on different CPUs?


Thanks,

-Joe

On 12/1/2015 5:49 PM, Roger Riggs wrote:
Please review this change in ProcessHandle to validate parent pids 
provided by the OS.
Children of a process have start times that are the same or later 
than the parent.

The implementation of descendants(), and children(), and getParent()
are updated to validate the parent pid.

The problem is most pronounced on Windows; the parent pid reported for a
process may be stale if the parent exited.  The validation is applied in
platform neutral code and used on all platforms.  Platform specific code
is used on Windows for getParent(); the Linux platforms do the right 
thing.


Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-validate-ppid-8143879/

Issue:
   https://bugs.openjdk.java.net/browse/JDK-8143876

Thanks, Roger

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

[Vladimir Kozlov]

I reviewed 8143355 today and my main question is where are range checks?

Thanks,
Vladimir

On 11/25/15 1: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

Re: RFR 9: 8143876 : test/java/lang/ProcessHandle/TreeTest.java failed intermittently with assertion error

[Joseph D. Darcy]

Hi Roger,

Looks fine.

Do you know if there are clock skew issues to be concerned with if the 
parent and child are spawned on different CPUs?


Thanks,

-Joe

On 12/1/2015 5:49 PM, Roger Riggs wrote:
Please review this change in ProcessHandle to validate parent pids 
provided by the OS.
Children of a process have start times that are the same or later than 
the parent.

The implementation of descendants(), and children(), and getParent()
are updated to validate the parent pid.

The problem is most pronounced on Windows; the parent pid reported for a
process may be stale if the parent exited.  The validation is applied in
platform neutral code and used on all platforms.  Platform specific code
is used on Windows for getParent(); the Linux platforms do the right 
thing.


Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-validate-ppid-8143879/

Issue:
   https://bugs.openjdk.java.net/browse/JDK-8143876

Thanks, Roger

RFR 9: 8143876 : test/java/lang/ProcessHandle/TreeTest.java failed intermittently with assertion error

[Roger Riggs]

Please review this change in ProcessHandle to validate parent pids 
provided by the OS.
Children of a process have start times that are the same or later than 
the parent.

The implementation of descendants(), and children(), and getParent()
are updated to validate the parent pid.

The problem is most pronounced on Windows; the parent pid reported for a
process may be stale if the parent exited.  The validation is applied in
platform neutral code and used on all platforms.  Platform specific code
is used on Windows for getParent(); the Linux platforms do the right thing.

Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-validate-ppid-8143879/

Issue:
   https://bugs.openjdk.java.net/browse/JDK-8143876

Thanks, Roger

Re: Deprecation of LogRecord.getMillis in JDK9

[Stuart Marks]

I think #3 or a variation is best. Clearly, #1 is inconsistent and simply 
documenting it (#2) isn't much better.


I'd recommend making setInstant() be more explicit about the range of Instant 
values that are allowed, namely those created from Instant.ofEpochMilli(long), 
which allows +/- 292 million years from the epoch. Otherwise the reader is 
forced to try to understand when Instant.toEpochMilli() throws the exception.


Now that we've constrained the range of instants that a LogRecord can contain, 
is it still necessary for setMillis(long) to be deprecated? Every value is 
valid. It can set (almost) the full range of Instant values, just not with 
nanosecond resolution. If you don't care about nanosecond resolution, this seems 
like a perfectly fine method to use.


s'marks

On 12/1/15 10:48 AM, Daniel Fuchs wrote:

Hi Jason, Stuart,

Here is a potential fix for the issue:

http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00/src/java.logging/share/classes/java/util/logging/LogRecord.java.frames.html


http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html



As Stuart noted, java.time.Instant has a greater range than what can
be constructed from a long milliseconds-since-epoch + a nano-time
adjustment. This does not apply to instants returned by the system
clock, since those are constructed precisely from such long
milliseconds-since-epoch + nano-time adjustment.

However - someone could conceivably construct such an Instant
and pass it to a LogRecord. If that happens, then LogRecord.getMillis()
could potentially throw an undocumented ArithmeticException.

So we have at least 3 possibilities:

1. do nothing
2. document that getMillis() can throw ArithmeticException, with the
additional consequence that serializing a LogRecord thus constructed
would also throw an ArithmeticException.
3. modify setInstant() to validate that the instant will fit in a
long milliseconds-since-epoch.


The above patch implements option 3 (which currently has my
preference). Is that the best solution?

I would very much like to hear your opinion.
If it seems like the best then I'll add a unit test, send an RFR, and
do the paper work for the spec change...

best regards, and thanks for all the valuable feedback!

-- daniel



On 30/11/15 18:04, Jason Mehrens wrote:

Hi Daniel,


When JDK-8072645 - java.util.logging should use java.time to get more precise
time stamps was commited the LogRecord.getMillis() method was marked as
deprecated with the reason "To get the full nanosecond resolution event time,
use getInstant".  I can see marking LogRecord.setMillis as deprecated since
using that would be an untended loss of precision.  However, it seems
excessive to deprecate LogRecord.getMillis when it could be treated as a
convenience method that could simply note that if the caller wants nanosecond
resolution use getInstant.  It would be extremely helpful compatibility wise
to have this undeprecated for libs that have support pre-Java 9.  If it can't
be undeprecated what is the proper way to target support as low as JDK7 but
might end up executing on JDK9?


Thanks,


Jason

Re: Deprecation of LogRecord.getMillis in JDK9

[Jason Mehrens]

Hi Daniel,

I like proposed #3 solution too.  Usually is best to not allow "poisoning the 
well".  This will really help me out with supporting older platforms and 
keeping the code smell to a minimum.

Thanks for taking this on,

Jason


From: Daniel Fuchs 
Sent: Tuesday, December 1, 2015 12:48 PM
To: Jason Mehrens; Core-Libs-Dev; Stuart Marks
Subject: Re: Deprecation of LogRecord.getMillis in JDK9

Hi Jason, Stuart,

Here is a potential fix for the issue:

http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00/src/java.logging/share/classes/java/util/logging/LogRecord.java.frames.html

http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html


As Stuart noted, java.time.Instant has a greater range than what can
be constructed from a long milliseconds-since-epoch + a nano-time
adjustment. This does not apply to instants returned by the system
clock, since those are constructed precisely from such long
milliseconds-since-epoch + nano-time adjustment.

However - someone could conceivably construct such an Instant
and pass it to a LogRecord. If that happens, then LogRecord.getMillis()
could potentially throw an undocumented ArithmeticException.

So we have at least 3 possibilities:

1. do nothing
2. document that getMillis() can throw ArithmeticException, with the
additional consequence that serializing a LogRecord thus constructed
would also throw an ArithmeticException.
3. modify setInstant() to validate that the instant will fit in a
long milliseconds-since-epoch.


The above patch implements option 3 (which currently has my
preference). Is that the best solution?

I would very much like to hear your opinion.
If it seems like the best then I'll add a unit test, send an RFR, and
do the paper work for the spec change...

best regards, and thanks for all the valuable feedback!

-- daniel



On 30/11/15 18:04, Jason Mehrens wrote:
> Hi Daniel,
>
>
> When JDK-8072645 - java.util.logging should use java.time to get more precise 
> time stamps was commited the LogRecord.getMillis() method was marked as 
> deprecated with the reason "To get the full nanosecond resolution event time, 
> use getInstant".  I can see marking LogRecord.setMillis as deprecated since 
> using that would be an untended loss of precision.  However, it seems 
> excessive to deprecate LogRecord.getMillis when it could be treated as a 
> convenience method that could simply note that if the caller wants nanosecond 
> resolution use getInstant.  It would be extremely helpful compatibility wise 
> to have this undeprecated for libs that have support pre-Java 9.  If it can't 
> be undeprecated what is the proper way to target support as low as JDK7 but 
> might end up executing on JDK9?
>
>
> Thanks,
>
>
> Jason
>

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

[Mikael Vidstedt]

This is as far as I got before I got interrupted:

http://cr.openjdk.java.net/~mikael/NioBenchmark.java

I haven't had time yet to verify that the benchmark code even measures 
the right thing, much less figure out why I get the performance impact 
with my fix. I can see many reasons why that could be the case, but it 
would be good to know if it's something trivial which can be easily 
fixed. In general, it sure would be nice to make this code behave and 
perform without compiler specific annotations, especially given that 
reliance on unaligned memory accesses and the cast specifically is 
sketchy at best.


Cheers,
Mikael

On 2015-11-30 10:13, Alexander Smundak wrote:

On Wed, Nov 25, 2015 at 2:52 PM,   wrote:

Have you looked anything at the performance of the generated code?

No. I looked at the emitted code, saw 'MOVQDU' instruction being used
(it was 'MOVQDA' before that resulted in alignment error), and concluded
  that the compiler knows what it's doing :-)

It would be interesting to understand what type of performance you see with
your patch.

If you have specific benchmark in mind, I am willing to run it.

Sasha

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

[John Rose]

On Nov 24, 2015, at 6:17 AM, Aleksey Shipilev  
wrote:
> 
> Oh no, I don't. Pre-integration JPRT runs exposed an opaque dependency
> on Integer.sizeTable field from C2 OptimizeStringConcat. I added the
> field declaration back:
> http://cr.openjdk.java.net/~shade/8136500/webrev.07/ 
> 
> 
> Cleaning up the compiler code would require much more time, so I would
> like to push this JDK part now, and deal with Hotspot compiler later:
>  https://bugs.openjdk.java.net/browse/JDK-8143900 
> 
> 
> Objections?

None.

Is there a tracking bug for CDE-ing OptimizeStringConcat?  There should be.
(I realize that will require sorting through some indy bootstrap issues.)

— John

Re: RFR: 8143131: Remove unused code from java.lang.invoke

[Claes Redestad]

John, Michael,

thanks for reviewing!

/Claes

On 2015-12-01 19:53, John Rose wrote:

CDE = Code Deletion Engineering.  Yes!

Reviewed.

— John

On Dec 1, 2015, at 8:06 AM, Claes Redestad  wrote:

Hi,

please review this patch to cleanup various things in and around 
java.lang.invoke:

Bug: https://bugs.openjdk.java.net/browse/JDK-8143131
Webrev: http://cr.openjdk.java.net/~redestad/8143131/webrev.01/

/Claes

RE: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

[Christian Tornqvist]

Hi Paul,

Tests in hotspot/test/runtime needs to be jtreg tests. Looking at your tests, I 
can't see a reason why they can't easily be modified to be jtreg tests instead?

(adding the hotspot-dev mail alias)

Thanks,
Christian

-Original Message-
From: hotspot-compiler-dev 
[mailto:hotspot-compiler-dev-boun...@openjdk.java.net] On Behalf Of Paul Sandoz
Sent: Tuesday, December 1, 2015 5:28 AM
Cc: hotspot-compiler-...@openjdk.java.net; core-libs-dev@openjdk.java.net
Subject: Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe 
native method tables



> On 30 Nov 2015, at 23:33, Paul Sandoz  wrote:
> 
> 
>> On 30 Nov 2015, at 23:05, Christian Tornqvist 
>>  wrote:
>> 
>> Because jtreg is the test framework that we use, we've been working hard to 
>> reduce the number of test frameworks in use.
>> 
> 
> jtreg comes bundled with testng so what is there to reduce?
> 

Here is an analogy:

  jtreg is to testng as launcher is to library

They are complementary to each other i.e. think of testng as an implicit 
@library that helps one better organize tests and report errors.

—

Would i be correct in stating that the HotSpot runtime team is taking a 
conservative position and does not want to deal with such a library, contrary 
to other areas of the JDK?

Sorry to push back, but I don’t agree with that position (if correct). I am 
reluctant to change the tests. Please don’t think that complete pigheadedness 
on my part :-) I just don’t think it’s the right thing to do.

If the HotSpot runtime team will not accept the use of TestNG then I suppose I 
could unblock by proposing to move the tests to the JDK repo, which I would 
also be reluctant to do since they caught an issue lying dormant for at least 8 
years on certain platforms (not covered by the core testset) that existing 
hotspot tests never caught.

Paul.

Re: RFR: 8143131: Remove unused code from java.lang.invoke

[John Rose]

CDE = Code Deletion Engineering.  Yes!

Reviewed.

— John

On Dec 1, 2015, at 8:06 AM, Claes Redestad  wrote:
> 
> Hi,
> 
> please review this patch to cleanup various things in and around 
> java.lang.invoke:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8143131
> Webrev: http://cr.openjdk.java.net/~redestad/8143131/webrev.01/
> 
> /Claes

Re: Deprecation of LogRecord.getMillis in JDK9

[Daniel Fuchs]

Hi Jason, Stuart,

Here is a potential fix for the issue:

http://cr.openjdk.java.net/~dfuchs/webrev_8144262/webrev.00/src/java.logging/share/classes/java/util/logging/LogRecord.java.frames.html

http://cr.openjdk.java.net/~dfuchs/webrev_8144262/specdiff-logging/java/util/logging/LogRecord.html


As Stuart noted, java.time.Instant has a greater range than what can
be constructed from a long milliseconds-since-epoch + a nano-time
adjustment. This does not apply to instants returned by the system
clock, since those are constructed precisely from such long
milliseconds-since-epoch + nano-time adjustment.

However - someone could conceivably construct such an Instant
and pass it to a LogRecord. If that happens, then LogRecord.getMillis()
could potentially throw an undocumented ArithmeticException.

So we have at least 3 possibilities:

1. do nothing
2. document that getMillis() can throw ArithmeticException, with the
   additional consequence that serializing a LogRecord thus constructed
   would also throw an ArithmeticException.
3. modify setInstant() to validate that the instant will fit in a
   long milliseconds-since-epoch.


The above patch implements option 3 (which currently has my
preference). Is that the best solution?

I would very much like to hear your opinion.
If it seems like the best then I'll add a unit test, send an RFR, and
do the paper work for the spec change...

best regards, and thanks for all the valuable feedback!

-- daniel



On 30/11/15 18:04, Jason Mehrens wrote:

Hi Daniel,


When JDK-8072645 - java.util.logging should use java.time to get more precise time stamps 
was commited the LogRecord.getMillis() method was marked as deprecated with the reason 
"To get the full nanosecond resolution event time, use getInstant".  I can see 
marking LogRecord.setMillis as deprecated since using that would be an untended loss of 
precision.  However, it seems excessive to deprecate LogRecord.getMillis when it could be 
treated as a convenience method that could simply note that if the caller wants 
nanosecond resolution use getInstant.  It would be extremely helpful compatibility wise 
to have this undeprecated for libs that have support pre-Java 9.  If it can't be 
undeprecated what is the proper way to target support as low as JDK7 but might end up 
executing on JDK9?


Thanks,


Jason

Re: RFR:JDK-8144349: @since tag missed

[Roger Riggs]

Hi Nadeesh,

Thanks for the correction, looks fine.

Reviewed,  Roger

p.s.  I can sponsor that and get it integrated

On 12/1/2015 1:38 PM, nadeesh tv wrote:

Hi ,
Sorry. I made a mistake.
Please see the updated webrev

http://cr.openjdk.java.net/~ntv/8144349/webrev.01

Regards,
Nadeesh

On 12/1/2015 10:24 PM, Stephen Colebourne wrote:

Those are not the right methods on LocalDate and LocalTime
Stephen

On 1 December 2015 at 16:50, nadeesh tv  wrote:

Hi all,
Please review a fix for
BugID - https://bugs.openjdk.java.net/browse/JDK-814434
Issue - while fixing JDK-8071919, JDK-8133079 I forgot to 
add @since

9 tag.
webrev - http://cr.openjdk.java.net/~ntv/8144349/webrev.00/

--
  Thanks and Regards,
Nadeesh TV

Re: RFR:JDK-8144349: @since tag missed

[nadeesh tv]

Hi ,
Sorry. I made a mistake.
Please see the updated webrev

http://cr.openjdk.java.net/~ntv/8144349/webrev.01

Regards,
Nadeesh

On 12/1/2015 10:24 PM, Stephen Colebourne wrote:

Those are not the right methods on LocalDate and LocalTime
Stephen

On 1 December 2015 at 16:50, nadeesh tv  wrote:

Hi all,
Please review a fix for
BugID - https://bugs.openjdk.java.net/browse/JDK-814434
Issue - while fixing JDK-8071919, JDK-8133079 I forgot to add @since
9 tag.
webrev - http://cr.openjdk.java.net/~ntv/8144349/webrev.00/

--
  Thanks and Regards,
Nadeesh TV


--
Thanks and Regards,
Nadeesh TV

Re: RFR:8143413:add toEpochSecond methods for efficient access

[Xueming Shen]

On 12/1/15 6:36 AM, Stephen Colebourne wrote:

As Roger says, these new methods are about performance as well as conversion.

While I fully acknowledge the time methods make an assumption, it is
not a crazy one, after all 1970-01-01 is just zero.

Key I think is it allows:
  long epochSecs = date.toEpochSeconds(offset) + time.toEpochSeconds(offset);
to efficiently merge two objects without garbage.


So it's not about j.t.LD/LT <-> j.u.Date, but instead of the clean approach

LocalDate date = ...
LocalDate time = ...
ZoneOffset offset = ...

==> long spochSecs = LocalDateTime.of(date, time).toEpochSeconds(offset);

we are adding APIs to provide a "fastpath" with the special assumption 
that the LocalDate "date"
here is actually a "LocalDateTime" object ("date" + LocalTime.MIDNIGHT) 
and the LocalTime "time"
again actually means a "LocalDateTime" (the "time" of 1970-01-01), to  
let the third party "libraries"
to fool the basic date/time abstract in java.time package,  simply to 
avoid creating the garbage

middle man, localDateTime? it really does not sound right to me.

First, if someone needs to mix/link LocalDate, LocalTime and Offset to 
epoch seconds in their
libraries, they really SHOULD think hard about the conversion and make 
it right (it should not
be encouraged to use these classes LocalDate, LocalTime and Offset 
without  even understand
what these classes are). But if we really have to provide such fastpath, 
personally I think it might
be better either to provide these "utility/convenient" methods in a 
"utilities" class, or with an
explicit date/time parameters (instead of the false assumption) for the 
missing date/time piece,

such as

localDate.toEpochSeconds(LocalTime.MIDNIGHT, offset);
localTime.toEpochSeconds(LocalDate.EPOCHDAY, offset);

Sherman




It also means that no-one has to think hard about the conversion, as
it is just there. It tends to be when people try to work this stuff
out for themselves that they get it wrong.

Stephen


On 1 December 2015 at 14:21, Roger Riggs  wrote:

Hi Sherman,

On 11/30/2015 6:09 PM, Xueming Shen wrote:

On 11/30/2015 01:26 PM, Stephen Colebourne wrote:

Converting LocalDate<-> java.util.Date is the question with the
largest number of votes on SO:

http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111
The proposed method is designed to make the conversion easier. It also
plugs an obvious gap in the API.

While the LocalTime/OffsetTime methods are of lower importance, not
having them would result in inconsistency between the various classes.
We've already added factory methods to LocalTime for Java 9, these are
just the other half of the picture.


I'm not sure I understand the idea of "the proposed method is designed to
make the conversion easier", as the SO is mainly about
j.u.Date->LocalDate,
not the other way around, from LocalDate -> j.u.Date.


I think the issue is about *other* libraries that manipulate time via
epochSeconds
not about j.u.Date conversions.  The concern was about performance and
creating garbage along the way.

Roger




As I said in the previous email, it might be "common" to use the j.u.Date
to
abstract a "local date" and/or a "local time" (no other choice) before
java.time,
and now there is the need to provide a migration path from those "local
date/
time" to the j.t.LocalDate/Time. But convert backward from the new
date/time
type to the "old" j.u.Date should not be encouraged (guess this is also
the
consensus we agreed on back to jsr203).

What are the "factory methods" you are referring to here? JDK-8133079, The
LocalDate/LocalTime.ofInstant()?
(btw, these two methods see missing the "since 1.9/9" tag)

It seems to me that the ofInstant(Instant, ZondId) is from a "super-set"
of
date/time to a "sub-set", without any assumption of "default value", it is
similar to the conversion from zdt->ldt->ld/lt, and I can see the "small"
improvement

from|
Date input = new Date();
LocalDatedate
=input.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();|

to

|LocalDatedate
=LocalDate.ofInstant(input.toInstant(),ZoneId.systemDefault()));|

The proposed pair toEpochSecond() however is doing the other way around
and
with an unusual assumption of the missing date/time piece to a "default
value"
(midnight, the epoch day).

personally I think

localDate.atTime(LocalTime.MIDNIGHT).toEpochSecond(ZoneOffset);
localTime.atDate(LocalDate.EPOCHDATE).toEpochSecond(ZoneOffset);

is clean and good enough to help this backward conversion (with the
addition
of LocalDate.EPOCHDATE/DAY constant). Maybe, the vm can even help to
remove that LocalDateTime middle man, with some arrangement.

-Sherman


Note that these methods are specifically not referencing
java.util.Date itself. Epoch seconds is the appropriate intermediate
form here, and still widely used.

Stephen



On 30 November 2015 at 19:36, Xueming Shen
wrote:

On 11/30/2015 10:37 AM, Stephen Colebourne wrote:

This is based on user difficulties 

Re: RFR:JDK-8144349: @since tag missed

[Stephen Colebourne]

Those are not the right methods on LocalDate and LocalTime
Stephen

On 1 December 2015 at 16:50, nadeesh tv  wrote:
> Hi all,
> Please review a fix for
>BugID - https://bugs.openjdk.java.net/browse/JDK-814434
>Issue - while fixing JDK-8071919, JDK-8133079 I forgot to add @since
> 9 tag.
>webrev - http://cr.openjdk.java.net/~ntv/8144349/webrev.00/
>
> --
>  Thanks and Regards,
> Nadeesh TV

RFR:JDK-8144349: @since tag missed

[nadeesh tv]

Hi all,
Please review a fix for
   BugID - https://bugs.openjdk.java.net/browse/JDK-814434
   Issue - while fixing JDK-8071919, JDK-8133079 I forgot to add 
@since 9 tag.

   webrev - http://cr.openjdk.java.net/~ntv/8144349/webrev.00/

--
 Thanks and Regards,
Nadeesh TV

Re: RFR: 8143131: Remove unused code from java.lang.invoke

[Michael Haupt]

Hi Claes,

note that this is a lower-case review: thumbs up. Good catches! Thanks! :-)

Best,

Michael

> Am 01.12.2015 um 17:06 schrieb Claes Redestad :
> 
> Hi,
> 
> please review this patch to cleanup various things in and around 
> java.lang.invoke:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8143131
> Webrev: http://cr.openjdk.java.net/~redestad/8143131/webrev.01/
> 
> /Claes

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG, Schiffbauergasse 14 | 14467 Potsdam, Germany
  Oracle is committed to developing 
practices and products that help protect the environment

Re: RFR(L): JDK-8046936 : JEP 270: Reserved Stack Areas for Critical Sections

[Frederic Parain]

Hi Dan,

Thank you for your detailed review.
My answers are in-lined below.

New webrev:

http://cr.openjdk.java.net/~fparain/8046936/webrev.02/hotspot/


On 24/11/2015 17:26, Daniel D. Daugherty wrote:


src/cpu/sparc/vm/frame_sparc.cpp
 (old) L635:   if (fp() - sp() > 1024 +
m->max_stack()*Interpreter::stackElementSize) {
 (new) L635:   if (fp() - unextended_sp() > 1024 +
m->max_stack()*Interpreter::stackElementSize) {
 This looks like a bug fix independent of this fix.


Correct, this is the SPARC version of JDK-8068655.


src/share/vm/runtime/thread.hpp
 L953:   intptr_t*_reserved_stack_activation;
 L1382:   intptr_t* reserved_stack_activation() const { return
_reserved_stack_activation; }
 L1383:   void  set_reserved_stack_activation(intptr_t* addr) {

 I was expecting this type to be 'address' instead of 'intptr_t*'.

 Update: I've gone back through the changes and I still don't
 see a reason that this is 'intptr_t*'.


The _reserved_stack_activation has been declared as an 'intptr_t*'
just to be consistent with the _sp and _fp fields of the frame class.
However, this is not really a requirement, the content stored at the
_reserved_stack_activation address is never read. This address is just
a "marker" on the stack to quickly check if the thread has exited the
annotated code section or not. I've change the type to address, there's
slightly less casts, and it doesn't impact the ReservedStackArea logic.

Note: I've removed all further comments about _reserved_stack_activation
type in order to improve the e-mail readability.


 L1341: { return stack_yellow_zone_base();}
 '{' should be at the end of the previous line.
 Missing space after ';'.


Fixed


 L1343: { return StackReservedPages * os::vm_page_size(); }
 '{' should be at the end of the previous line.


Fixed


src/share/vm/runtime/thread.cpp
 L2543:   // The base notation is from the stacks point of view,
growing downward.
 L2565:   // The base notation is from the stacks point of view,
growing downward.
 Typo: "stacks point of view" -> "stack's point of view"


Fixed


 L2552:   } else {
 L2553: warning("Attempt to guard stack reserved zone failed.");
 L2554:   }
 L2555:   enable_register_stack_guard();

 Should enable_register_stack_guard() be called when we issued
 the warning on L2553?

 L2571:   } else {
 L2572: warning("Attempt to unguard stack reserved zone failed.");
 L2573:   }
 L2574:   disable_register_stack_guard();

 Should disable_register_stack_guard() be called when we issued
 the warning on L2572?


enable_register_stack_guard() and disable_register_stack_guard() are
relics of the Itanium code (Itanium had a very different stack
management). These methods are currently empty on all OpenJDK and
Oracle platforms. May be another clean up opportunity here.
Regarding the placement of the calls, I followed the same pattern
as the other red/yellow pages management functions.


src/share/vm/runtime/sharedRuntime.cpp

 L784: java_lang_Throwable::set_message(exception_oop,
 L785: Universe::delayed_stack_overflow_error_message());
 Wrong indent; this should line up under the 'e' after the '('.


Fixed


 L2976:   if (fr.is_interpreted_frame()) {
 L2978: prv_fr = fr;
 L2982: prv_fr = fr;
 This line is in both branches of the if-statement on L2976.
 Is there a reason not to save prv_fr before L2976?


No particular reason, fixed.


 L2996  continue;
 Wrong indent; needs one more space.


Fixed


 L2958:   frame activation;
 L3013:   return activation;
 The return on L3013 can return a default constructed 'frame'.
 Is that default safe to return here?


Yes, the caller performs a check before using the returned
frame:
  if (activation.sp() != NULL) { ...



src/os/bsd/vm/os_bsd.hpp
 L109:static bool get_frame_at_stack_banging_point(JavaThread*
thread, ucontext_t* uc, frame* fr);
 Wrong indent; needs one less space.


Fixed


src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp
 L322: // For Forte Analyzer AsyncGetCallTrace profiling support -
thread
 L323: // is currently interrupted by SIGPROF.
 Now fetch_frame_from_ucontext() is also used for stack overflow
 signal handling.


Fixed


 L379: assert(fr->safe_for_sender(thread), "Safety check");
 L380: if (!fr->is_first_java_frame()) {
 L381:   *fr = fr->java_sender();
 The assert() on L379 should be before the java_sender()
 call on L381.


Fixed


src/os/linux/vm/os_linux.cpp
 L1902:   jt->stack_guards_enabled()) {   // No pending
stack overflow exceptions
 This line's comment used to align with the previous line's comment.
 Can you move the previous line's comment to align with this one?


Do

RFR: 8143131: Remove unused code from java.lang.invoke

[Claes Redestad]

Hi,

please review this patch to cleanup various things in and around 
java.lang.invoke:


Bug: https://bugs.openjdk.java.net/browse/JDK-8143131
Webrev: http://cr.openjdk.java.net/~redestad/8143131/webrev.01/

/Claes

Re: Deprecation of LogRecord.getMillis in JDK9

[Daniel Fuchs]

Hi Stuart,

Thanks for the feedback!

On 30/11/15 23:53, Stuart Marks wrote:

Hi all,

Thanks for considering JEP 277 in this discussion. It's far from being
finalized at this point, but SUPERSEDED seems like the most likely of
the deprecation reasons from the proposal that would be applied here.

While it seems that getMillis() is merely a convenience method for
calling getInstant().toEpochMilli(), there are a couple subtle semantic
differences that might warrant consideration beyond the loss of
nanosecond resolution.

First, LogRecord now contains an Instant instead of a millis-since-epoch
value. Instant is explicitly intended to support points in time prior to
the epoch. It's possible for a LogRecord to contain such a time via
setInstant(). Thus, getMillis() can now return a negative number. This
isn't explicitly allowed or disallowed as far as I can see, but
historically millis-since-epoch values have always been non-negative. I
suspect that most code out there implicitly assumes this and would
unprepared to deal with negative return values.


This would only apply to code that explicitly used to call
LogRecord.setMillis() with negative values: the number of milliseconds
in LogRecord historically comes from System.currentTimeMillis() - and
using Instant is not changing that - since we are now
using Instant.now() - which underneath still ends up calling
System.currentTimeMillis() with an additional nano second adjsutment.


Second, Instant uses a long to store seconds before or after the epoch,
whereas a long millis-since-epoch value can only represent 1/1000th of
that range. Instant.toEpochMilli() throws an exception in such cases.
This behavior would show through to LogRecord.getMillis(). (It looks
like this limitation is also present in the serial form of LogRecord.)


Interesting. Maybe we should throw an IllegalArgumentException in
setInstant() if the instant we're given exceeds the capacity of
a long millis-since-epoch value. Or maybe it is acceptable to
let the exception be thrown at serialization time - and deal
with the issue in serialization when it is clear that there is a
requirement for representing such points in time in LogRecord
(dealing with this would mean altering the serial form
of LogRecord - and I'm not convinced we need to support such
extreme values). In any case, such an Instant would have to be
constructed from the calling code - and set explicitely through
setInstant() since Instant.now() is precisely constructed behind
the scene from a long millis-since-epoch + a nano second adjustment,
and therefore it should always be possible to retrofit it in those
two quantities.


My hunch is that it's exceedingly rare for a LogRecord contain a time
before 1970 or 292 million years in the future, but the API allows it,
so it could happen, and it should be specified.


Time before 1970 shouldn't be a problem - I think.
I mean that using Instant makes it now clear what a negative
value represents.

In what concerns 292 million years in the future, then
maybe we could schedule a RFE for Java 9733.0 ;-)
Or more seriously wait until the Clock.systemClock()/Instant.now()
are able to return such value?


This doesn't imply that getMillis() should or shouldn't be deprecated.
The deciding factor here is whether you think it's important for
programmers to migrate away from this API. It may be that getMillis()
works just fine under all but the most extreme cases, so there's no
practical need for programmers to migrate away from it.


Right. Stephen has convinced me that removing the @Deprecated and
adding an @apiNote is the appropriate thing to do :-)

best regards,

-- daniel



s'marks



On 11/30/15 10:20 AM, Daniel Fuchs wrote:

On 30/11/15 18:43, Roger Riggs wrote:

Hi Daniel,

I think it makes sense to keep getMillis (and document it) as a
convenience method.


Thanks Roger, Jason, I logged
https://bugs.openjdk.java.net/browse/JDK-8144262

best regards,

-- daniel



Roger


On 11/30/2015 12:25 PM, Daniel Fuchs wrote:

On 30/11/15 18:04, Jason Mehrens wrote:

Hi Daniel,


When JDK-8072645 - java.util.logging should use java.time to get more
precise time stamps was commited the LogRecord.getMillis() method was
marked as deprecated with the reason "To get the full nanosecond
resolution event time, use getInstant".  I can see marking
LogRecord.setMillis as deprecated since using that would be an
untended loss of precision.  However, it seems excessive to deprecate
LogRecord.getMillis when it could be treated as a convenience method
that could simply note that if the caller wants nanosecond resolution
use getInstant.  It would be extremely helpful compatibility wise to
have this undeprecated for libs that have support pre-Java 9.  If it
can't be undeprecated what is the proper way to target support as low
as JDK7 but might end up executing on JDK9?


Hi Jason,

I see your point.

As you noted, the main reason for deprecating getMillis() is that we
actually wanted to deprecate setMillis().
I

Re: RFR:8143413:add toEpochSecond methods for efficient access

[Stephen Colebourne]

As Roger says, these new methods are about performance as well as conversion.

While I fully acknowledge the time methods make an assumption, it is
not a crazy one, after all 1970-01-01 is just zero.

Key I think is it allows:
 long epochSecs = date.toEpochSeconds(offset) + time.toEpochSeconds(offset);
to efficiently merge two objects without garbage.

It also means that no-one has to think hard about the conversion, as
it is just there. It tends to be when people try to work this stuff
out for themselves that they get it wrong.

Stephen


On 1 December 2015 at 14:21, Roger Riggs  wrote:
> Hi Sherman,
>
> On 11/30/2015 6:09 PM, Xueming Shen wrote:
>>
>> On 11/30/2015 01:26 PM, Stephen Colebourne wrote:
>>>
>>> Converting LocalDate<-> java.util.Date is the question with the
>>> largest number of votes on SO:
>>>
>>> http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111
>>> The proposed method is designed to make the conversion easier. It also
>>> plugs an obvious gap in the API.
>>>
>>> While the LocalTime/OffsetTime methods are of lower importance, not
>>> having them would result in inconsistency between the various classes.
>>> We've already added factory methods to LocalTime for Java 9, these are
>>> just the other half of the picture.
>>>
>>
>> I'm not sure I understand the idea of "the proposed method is designed to
>> make the conversion easier", as the SO is mainly about
>> j.u.Date->LocalDate,
>> not the other way around, from LocalDate -> j.u.Date.
>
>
> I think the issue is about *other* libraries that manipulate time via
> epochSeconds
> not about j.u.Date conversions.  The concern was about performance and
> creating garbage along the way.
>
> Roger
>
>
>
>>
>> As I said in the previous email, it might be "common" to use the j.u.Date
>> to
>> abstract a "local date" and/or a "local time" (no other choice) before
>> java.time,
>> and now there is the need to provide a migration path from those "local
>> date/
>> time" to the j.t.LocalDate/Time. But convert backward from the new
>> date/time
>> type to the "old" j.u.Date should not be encouraged (guess this is also
>> the
>> consensus we agreed on back to jsr203).
>>
>> What are the "factory methods" you are referring to here? JDK-8133079, The
>> LocalDate/LocalTime.ofInstant()?
>> (btw, these two methods see missing the "since 1.9/9" tag)
>>
>> It seems to me that the ofInstant(Instant, ZondId) is from a "super-set"
>> of
>> date/time to a "sub-set", without any assumption of "default value", it is
>> similar to the conversion from zdt->ldt->ld/lt, and I can see the "small"
>> improvement
>>
>> from|
>> Date input = new Date();
>> LocalDatedate
>> =input.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();|
>>
>> to
>>
>> |LocalDatedate
>> =LocalDate.ofInstant(input.toInstant(),ZoneId.systemDefault()));|
>>
>> The proposed pair toEpochSecond() however is doing the other way around
>> and
>> with an unusual assumption of the missing date/time piece to a "default
>> value"
>> (midnight, the epoch day).
>>
>> personally I think
>>
>> localDate.atTime(LocalTime.MIDNIGHT).toEpochSecond(ZoneOffset);
>> localTime.atDate(LocalDate.EPOCHDATE).toEpochSecond(ZoneOffset);
>>
>> is clean and good enough to help this backward conversion (with the
>> addition
>> of LocalDate.EPOCHDATE/DAY constant). Maybe, the vm can even help to
>> remove that LocalDateTime middle man, with some arrangement.
>>
>> -Sherman
>>
>>> Note that these methods are specifically not referencing
>>> java.util.Date itself. Epoch seconds is the appropriate intermediate
>>> form here, and still widely used.
>>>
>>> Stephen
>>>
>>>
>>>
>>> On 30 November 2015 at 19:36, Xueming Shen
>>> wrote:

 On 11/30/2015 10:37 AM, Stephen Colebourne wrote:
>
> This is based on user difficulties picked up via Stack Overflow. These
> methods aim to provide a simpler and faster approach, particularly for
> cases converting to/from java.util.Date.

 Can you be a little more specific on this one? We now have Instance<=>
 Date,
 and considerably we might add LocalDateTime<=>  Date with an offset, if
 really
 really desired (for performance? to save a Instant object as the
 bridge?).
 But I'm
 a little confused about the connection among LocalDate/LocalTime, epoch
 seconds
 and j.u.Date here. Are you saying someone wants to convert

 j.t.LocalDate ->  epoch seconds ->  j.u.Date
 j.t.LocalTime ->  epoch seconds ->  j.u.Date

 and uses the converted j.u.Date to represent a local date (date with
 time
 part to
 be 0) and/or the local time (with year/month/day to be epoch time) in
 the
 "old"
 system which only has j.u.Date, and has to use the j.u.Date to abstract
 the
 "local
 date" and "local time"?

 I think we agreed back to JSR310 that we don't try to add such kind of
 "bridge/
 convenient/utility" methods into the new ja

Re: RFR:8143413:add toEpochSecond methods for efficient access

[Roger Riggs]

Hi Sherman,

On 11/30/2015 6:09 PM, Xueming Shen wrote:

On 11/30/2015 01:26 PM, Stephen Colebourne wrote:

Converting LocalDate<-> java.util.Date is the question with the
largest number of votes on SO:
http://stackoverflow.com/questions/21242110/convert-java-util-date-to-java-time-localdate/21242111 


The proposed method is designed to make the conversion easier. It also
plugs an obvious gap in the API.

While the LocalTime/OffsetTime methods are of lower importance, not
having them would result in inconsistency between the various classes.
We've already added factory methods to LocalTime for Java 9, these are
just the other half of the picture.



I'm not sure I understand the idea of "the proposed method is designed to
make the conversion easier", as the SO is mainly about 
j.u.Date->LocalDate,

not the other way around, from LocalDate -> j.u.Date.


I think the issue is about *other* libraries that manipulate time via 
epochSeconds
not about j.u.Date conversions.  The concern was about performance and 
creating garbage along the way.


Roger




As I said in the previous email, it might be "common" to use the 
j.u.Date to
abstract a "local date" and/or a "local time" (no other choice) before 
java.time,
and now there is the need to provide a migration path from those 
"local date/
time" to the j.t.LocalDate/Time. But convert backward from the new 
date/time
type to the "old" j.u.Date should not be encouraged (guess this is 
also the

consensus we agreed on back to jsr203).

What are the "factory methods" you are referring to here? JDK-8133079, 
The

LocalDate/LocalTime.ofInstant()?
(btw, these two methods see missing the "since 1.9/9" tag)

It seems to me that the ofInstant(Instant, ZondId) is from a 
"super-set" of
date/time to a "sub-set", without any assumption of "default value", 
it is

similar to the conversion from zdt->ldt->ld/lt, and I can see the "small"
improvement

from|
Date input = new Date();
LocalDatedate 
=input.toInstant().atZone(ZoneId.systemDefault()).toLocalDate();|


to

|LocalDatedate 
=LocalDate.ofInstant(input.toInstant(),ZoneId.systemDefault()));|


The proposed pair toEpochSecond() however is doing the other way 
around and
with an unusual assumption of the missing date/time piece to a 
"default value"

(midnight, the epoch day).

personally I think

localDate.atTime(LocalTime.MIDNIGHT).toEpochSecond(ZoneOffset);
localTime.atDate(LocalDate.EPOCHDATE).toEpochSecond(ZoneOffset);

is clean and good enough to help this backward conversion (with the 
addition

of LocalDate.EPOCHDATE/DAY constant). Maybe, the vm can even help to
remove that LocalDateTime middle man, with some arrangement.

-Sherman


Note that these methods are specifically not referencing
java.util.Date itself. Epoch seconds is the appropriate intermediate
form here, and still widely used.

Stephen



On 30 November 2015 at 19:36, Xueming Shen  
wrote:

On 11/30/2015 10:37 AM, Stephen Colebourne wrote:

This is based on user difficulties picked up via Stack Overflow. These
methods aim to provide a simpler and faster approach, particularly for
cases converting to/from java.util.Date.

Can you be a little more specific on this one? We now have Instance<=>
Date,
and considerably we might add LocalDateTime<=>  Date with an offset, if
really
really desired (for performance? to save a Instant object as the 
bridge?).

But I'm
a little confused about the connection among LocalDate/LocalTime, epoch
seconds
and j.u.Date here. Are you saying someone wants to convert

j.t.LocalDate ->  epoch seconds ->  j.u.Date
j.t.LocalTime ->  epoch seconds ->  j.u.Date

and uses the converted j.u.Date to represent a local date (date with 
time

part to
be 0) and/or the local time (with year/month/day to be epoch time) 
in the

"old"
system which only has j.u.Date, and has to use the j.u.Date to 
abstract the

"local
date" and "local time"?

I think we agreed back to JSR310 that we don't try to add such kind of
"bridge/
convenient/utility" methods into the new java.time package, but only 
in the
old date/calendar classes, if really needed. So if these methods are 
only to

help
migrate/bridge between the "old" and "new" calendar systems, the 
java.time

might not be the best place for them?


For the time cases, the convention of 1970-01-01 is natural and
commonly used in many codebases.

I'm not sure about that, especially the "natural" part. It might be 
"common"

in
the old days if you only have j.u.Date", and might be forced to use
1970-01-01
to fill in the "date" part even when you are really only interested in
"time" part
of it in your app. One of the advantage of java.time.LDT/LD/LT is 
now we

have
separate abstract for these different need, I don't see the common 
need of

having a LocalTime only meas the "local time" of 1970-01-01, or I
misunderstood
something here.

-Sherman




Stephen



On 30 November 2015 at 18:15, Xueming Shen
wrote:

Hi,

While it is kinda understandable to have LocalDate.toEpochSecond(...)
to get the e

Re: [PING] RFR 6425769: jmx remote bind address

[Severin Gehwolf]

Hi Jaroslav,

On Tue, 2015-12-01 at 12:33 +0100, Jaroslav Bachorik wrote:
> On 1.12.2015 11:17, Severin Gehwolf wrote:
> > On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote:
> > > On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > Updated webrev with jtreg test in Java:
> > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/
> > > > bug: https://bugs.openjdk.java.net/browse/JDK-6425769
> > > > 
> > > > I believe this updated webrev addresses all concerns and
> > > > incorporates
> > > > suggestions brought up by Jaroslav and Daniel.
> > > > 
> > > > I'm still looking for a sponsor and a hotspot/servicability-dev
> > > > reviewer. Could somebody maintaining javax.rmi.ssl have a look at
> > > > this
> > > > as well? Thank you!
> > > 
> > > Ping? Friendly reminder that I still need reviewers and a sponsor for
> > > this.
> > 
> > Anyone?
> 
> I'm sorry for not spotting this earlier:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi-ssl-factory-changes/jdk/src/java.management/share/classes/sun/management/jmxremote/ConnectorBootstrap.java.sdiff.html
> * L442 - the log would contain 'com.sun.management.jmxremote.host = 
> null' if host is not specified; might be better not to print this out at all

Updated webrev which does not print
'com.sun.management.jmxremote.host = null' if unset:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/05/

> Other than that the change looks good to me. If no one else is 
> volunteering I may sponsor this change.

Thank you!

Cheers,
Severin

> Cheers,
> 
> -JB-

ClassFileTransformer does not apply to anonymous classes

[Rafael Winterhalter]

Hello everybody,

classes that are loaded via Unsafe::defineAnonymousClass are not
transformed by a registered ClassFileTransformer. At the same time, it is
possible to retransform / redefine such an anonymous classes using the
instrumentation API.

Here is a rather confusing bug that I encountered when working with an
internally used Java agent after upgrading a code base to Java 8:

The Java agent attaches at runtime (agentmain). It then registers a
ClassFileTransformer that also applies for retransformation. Afterwards,
all loaded classes that fullfil a given condition are explicitly registered
to be retransformed by the agent. (Doing so, anonymous classes are returned
by Instrumentation::getAllLoadedClasses.) This resulted in the following
behavior of the agent:

a) If the agent was attached after an anonymous class was loaded, the
retransformation would apply to an anonymous class.
b) If the agent was attached "too early", the (non-re-)transformation would
not apply to an anonymous class.

I wonder if it is intentional that a ClassFileTransformer is not applied
when an anonymous class is loaded. Personally, I find this
counter-intuitive, especially when converting anonymous inner classes to
lambda expressions where many users of instrumentation do not forsee the
behavioral change. It also puts a very unforseeable limit to the
instrumentation API. I would therefore like to suggest that
ClassFileTransformers are also applied to anonymous classes when
Unsafe::defineAnonymousClass is called just as when going via
ClassLoader::defineClass.

I can tell that this behavior has not only affected me as I had this
question comming up by multiple users of my open-source code generation
library.

What is your view on this?

Thank you for your feedback!
Best regards, Rafael

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

[Doug Lea]

On 12/01/2015 05:36 AM, Paul Sandoz wrote:



On 1 Dec 2015, at 03:58, Gil Tene  wrote:

class Runtime { /...
/**
  * Method signifying that the caller is momentarily unable to
  * progress until the occurrence of one or more actions of one or
  * more other activities.  When invoked within each iteration, this
  * method typically improves performance of spin wait loop
  * constructions.
  */
 public static void onSpinWait() {};
}



Short and sweet. I like it. I think it would be useful to add an @apiNote with 
explanatory text similar to that in the motivation section of the JEP.




Or maybe not. Recent experience suggests that it is hard to add a brief
explanatory note or usage guidance without saying something
confusing or wrong wrt usages focussing on latency, throughput,
or power -- these effects may vary across processors with
different instructions (possibly just no-op) used to implement it.
Not a lot, but this accounts for the bland wording of
"typically improves performance".

-Doug

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

[Vitaly Davidovich]

Minor quibble, but why the "on" prefix in the name? Maybe just me, but
onXYX is typically used for event notification style APIs.

Also, the "wait" part seems inappropriate as the method itself isn't doing
any waiting.  What was wrong with the original spinLoopHint name? Or
cpuRelax()?

sent from my phone
On Nov 30, 2015 9:59 PM, "Gil Tene"  wrote:

> Update: After some significant back-and-forth between Doug and I on naming
> and JavaDoc'ing, and with Martin (Thompson) stepping in to help, we have
> what we think is a good spec and name selection for this thing. We're
> proposing to add a new static method to the Runtime class:
>
> class Runtime { /...
> /**
>   * Method signifying that the caller is momentarily unable to
>   * progress until the occurrence of one or more actions of one or
>   * more other activities.  When invoked within each iteration, this
>   * method typically improves performance of spin wait loop
>   * constructions.
>   */
>  public static void onSpinWait() {};
> }
>
> See updated details, including a link to the updated JEP draft, as well as
> links to working prototype implementations, webrevs against OpenJDK9b94,
> and example here:
> https://github.com/giltene/GilExamples/tree/master/SpinWaitTest <
> https://github.com/giltene/GilExamples/tree/master/SpinWaitTest> . All
> names have changed to reflect the new naming (onSpinWait,
> -XX:+UseOnSpinWaitIntrinsic, SpinWaitTest, etc.).
>
> As an interesting stat, the total changes in the WebRevs amount to 78
> added lines (across 14 files) , and 0 lines removed or changed. Hopefully a
> good indication of relatively low footprint and risk.
>
> — Gil.
>
>
>
>
>
>

Re: [PING] RFR 6425769: jmx remote bind address

[Jaroslav Bachorik]

On 1.12.2015 11:17, Severin Gehwolf wrote:

On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote:

On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote:

Hi,

Updated webrev with jtreg test in Java:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/
bug: https://bugs.openjdk.java.net/browse/JDK-6425769

I believe this updated webrev addresses all concerns and
incorporates
suggestions brought up by Jaroslav and Daniel.

I'm still looking for a sponsor and a hotspot/servicability-dev
reviewer. Could somebody maintaining javax.rmi.ssl have a look at
this
as well? Thank you!


Ping? Friendly reminder that I still need reviewers and a sponsor for
this.


Anyone?


I'm sorry for not spotting this earlier:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/03.no-rmi-ssl-factory-changes/jdk/src/java.management/share/classes/sun/management/jmxremote/ConnectorBootstrap.java.sdiff.html
* L442 - the log would contain 'com.sun.management.jmxremote.host = 
null' if host is not specified; might be better not to print this out at all


Other than that the change looks good to me. If no one else is 
volunteering I may sponsor this change.


Cheers,

-JB-




Thanks,
Severin


Cheers,
Severin

On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote:

On 2.11.2015 19:06, Severin Gehwolf wrote:

Hi,

Thanks Jaroslav and Daniel for the reviews! Comments inline.

On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote:

Hi,

On 2.11.2015 16:19, Daniel Fuchs wrote:

Hi Severin,

Adding serviceability-...@openjdk.java.net into the loop -
that's
a better alias than hotspot-dev for this kind of changes -
maybe
someone from serviceability-dev will offer to sponsor :-)

I will let serviceability team members comment on the
hotspot
changes.

ConnectorBootstrap.java

I have one suggestion and one concern:

Suggestion: I would suggest to reuse 'csf' (Client Socket
Factory)
and
ssf  (Server Socket Factory) variables rather than
introduce
the
two
new variables rmiServerSocketFactory and
rmiClientSocketFactory.
You might want to create a new boolean 'useSocketFactory'
variable,
if that makes the code more readable.

Concern: If I understand correctly how RMI socket factories
work,
the client socket factory will be serialized and sent to
the
client
side. This is problematic for interoperability, as the
class
may
not
present in the remote client - if the remote client is e.g.
jdk
8.

As far as I can see, your new DefaultClientSocketFactory
doesn't do
anything useful - so I would suggest to simply get rid of
it,
and
only
set the Server Socket Factory when SSL is not involved.


Thanks. Fixed in updated webrev.


Tests:

Concerning the tests - we're trying to get rid of shell
scripts
rather than introducing new ones :-)
Could the test be rewritten in pure java using the Process
API?

I believe there's even a test library that will let you do
that
easily jdk/test/lib/testlibrary/jdk/testlibrary/
(see ProcessTools.java)


It'll take me a bit to rewrite the test in pure Java, but
should
be
fine. This is not yet fixed in the updated webrev.


Other:

Also - I believe the new option should be documented in:
src/java.management/share/conf/management.properties


Docs have been updated
in src/java.management/share/conf/management.properties.


I share Daniel's concerns. Also, the part of the changeset is
related
to javax.rmi.ssl - someone maintaining this library should
also
comment here.

Also, the change is introducing new API (system property) and
changing the existing one (adding SslRmiServerSocketFactory
public
constructors) so compatibility review process will have to be
involved.


OK. What exactly is there for me to do? I'm not familiar with
this
process. Note that the intent would be to get this backported
to
JDK 8.

Not much for you. But for the potential Oracle sponsor this means
she
will have to remember to go through some extra hoops before
integrating your patch.


I see. Thanks for clarifying it.


-JB-



New webrev at:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/

Thanks,
Severin


-JB-


best regards,

-- daniel

On 02/11/15 11:38, Severin Gehwolf wrote:

Hi,

Here is a patch addressing JDK-6425769. The issue is that
the
JMX
agent
binds to the wildcard address by default, preventing
users
to
use
system properties for JMX agents on multi-homed hosts.
Given
a
host
with local network interfaces, 192.168.0.1 and
192.168.0.2
say,
it's
impossible to start two JMX agents binding to fixed ports
but
to
different network interfaces, 192.168.0.1:{9111,9112} and
192.168.0.2:{9111,9112} say.

The JDK would bind to all local interfaces by default. In
the
above
example to 192.168.0.1 *and* 192.168.0.2. The effect is
that
the
second
Java process would get a "Connection refused" error
because
another
process has already been bound to the specified JMX/RMI
port
pairs.

Bug: https://bugs.openjdk.java.net/browse/JDK-6425769
webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-
64
25
769/
00/

Testing d

RFE Pre-review: Support for cloning exceptions

[Peter Levart]

Hi,

There are at least two places in java.util.concurrent where it would be 
beneficial if java.lang.Throwable was Cloneable:


- ForkJoinTask::getException() returns original exception thrown by the 
computation of the task when the task is completed exceptionally. The 
same exception is re-thrown in ForkJoinTask::join() or 
ForkJoinTask::invoke(). In order for the re-thrown exception to contain 
meaningful and non-misleading stack-trace, the original exception is 
attempted to be replaced with the exception of the same type, with 
original exception attached as the cause, so both stack-traces are 
visible - the original stack trace and the stack-trace of the thread 
executing join() or invoke(). In order to do that, ForkJoinTask resorts 
to using reflection and trying to construct new exception by invoking a 
constructor on the j.l.Class of the original exception. It 1st tries the 
constructor taking j.l.Throwable parameter (assumes it will be the 
cause) and if that doesn't work, it tries the no-arg constructor 
followed by calling initCause() on the result.


This usually works for public exceptions with suitable public 
constructors, but is not guaranteed. So in case it doesn't work, it 
simply re-throws the original exception with the original stack-trace, 
which hides the point at which it was re-thrown (at join() or invoke()). 
I assume this will become more problematic with jigsaw where 
constructors of non-exported exceptions will become inaccessible.


- CompletableFuture::whenComplete[Async]() are methods that return: 
"...a new CompletionStage with the same result or exception as  this 
stage, that executes the given action when this stage completes...". 
Given 'action' is a BiConsumer receiving the result or exception from 
'this' stage, so it can act as a clean-up action. If this cleanup throws 
an exception, it becomes the result of the returned stage unless 'this' 
stage also completes with exception. Like in try-with-resources, the 
exception thrown in the body of try-with-resources statement has 
precedence over clean-up exception. Clean-up exception is added as 
suppressed exception. In CompletableFuture this presents a problem, 
because adding a suppressed exception to the exception of previous stage 
effectively modifies the result of the previous stage that has already 
completed. This is undesirable.


So I would like to ask for feedback on a proposal to add cloning support 
to java.lang.Throwable and also how to proceed if this turns out to be 
acceptable (perhaps a CCC request?).


The proposal is as follows:

- add "implements Cloneable" to the j.l.Throwable

- add the following public static method to j.l.Throwable:


/**
 * 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 an uninitialized state so 
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 
cleared.

 * 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;

Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

[Chris Hegarty]

On 26 Nov 2015, at 12:00, Aleksey Shipilev  wrote:

> On 11/26/2015 12:55 PM, Paul Sandoz wrote:
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-jdk/
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8143628-unsafe-native-hotspot/
> 
> Both JDK and Hotspot changes look good to me.

+1, both webrevs look good to me.  Thanks for fixing my shortcut when
moving Unsafe.

-Chris.

Re: JDK 9 RFR of JDK-8144215: Test development task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and Service

[Daniel Fuchs]

Hi Hamlin,

You should probably create a new open RFE for pushing this new
test.
I'm not sure we can use internal task ids in commit/push comments.

From looking at the test, it would be preferable to create
the loggers after setting up the stub that pretend that the
VM is not yet booted. In other words - in BootstrapLoggerAPIsTest
lines 53-56 should preferably be moved after line 74.

best regards,

-- daniel

On 01/12/15 04:37, Hamlin Li wrote:

Hi all,

Would you please help to review the test development of JDK-8144215
: Test development
task for : JEP-JDK-8046565: SQE Test Plan for Platform Logging API and
Service.
webrev : http://cr.openjdk.java.net/~mli/8144215/webrev.00/

Thank you
-Hamlin

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

[Paul Sandoz]

> On 1 Dec 2015, at 03:58, Gil Tene  wrote:
> 
> Update: After some significant back-and-forth between Doug and I on naming 
> and JavaDoc'ing, and with Martin (Thompson) stepping in to help, we have what 
> we think is a good spec and name selection for this thing. We're proposing to 
> add a new static method to the Runtime class:
> 
> class Runtime { /...
>/**
>  * Method signifying that the caller is momentarily unable to
>  * progress until the occurrence of one or more actions of one or
>  * more other activities.  When invoked within each iteration, this
>  * method typically improves performance of spin wait loop
>  * constructions.
>  */
> public static void onSpinWait() {};
> }
> 

Short and sweet. I like it. I think it would be useful to add an @apiNote with 
explanatory text similar to that in the motivation section of the JEP.

If you like I can help guide this through the JEP process.


> See updated details, including a link to the updated JEP draft, as well as 
> links to working prototype implementations, webrevs against OpenJDK9b94, and 
> example here: https://github.com/giltene/GilExamples/tree/master/SpinWaitTest 
>  . All names 
> have changed to reflect the new naming (onSpinWait, 
> -XX:+UseOnSpinWaitIntrinsic, SpinWaitTest, etc.).
> 
> As an interesting stat, the total changes in the WebRevs amount to 78 added 
> lines (across 14 files) , and 0 lines removed or changed. Hopefully a good 
> indication of relatively low footprint and risk.
> 

I agree, the JDK and hotspot patches (for x86 support) are quite small.

Paul.

Re: RFR: 8144214 Some log messages will be discarded when VM is bootstrapping.

[Daniel Fuchs]

Hi Hamlin,

I see that you're going to push a test for this with
JDK-8144215;

Looks good to me.

Do you need a sponsor for this fix?

best regards,

-- daniel

On 30/11/15 12:28, Hamlin Li wrote:

Hi all,

Would you please help to review for
http://cr.openjdk.java.net/~mli/8144214/webrev.00/, which fixes bug
https://bugs.openjdk.java.net/browse/JDK-8144214.

Thank you
-Hamlin

Re: RFR 8143628: Fork sun.misc.Unsafe and jdk.internal.misc.Unsafe native method tables

[Paul Sandoz]

> On 30 Nov 2015, at 23:33, Paul Sandoz  wrote:
> 
> 
>> On 30 Nov 2015, at 23:05, Christian Tornqvist 
>>  wrote:
>> 
>> Because jtreg is the test framework that we use, we've been working hard to 
>> reduce the number of test frameworks in use.
>> 
> 
> jtreg comes bundled with testng so what is there to reduce?
> 

Here is an analogy:

  jtreg is to testng as launcher is to library

They are complementary to each other i.e. think of testng as an implicit 
@library that helps one better organize tests and report errors.

—

Would i be correct in stating that the HotSpot runtime team is taking a 
conservative position and does not want to deal with such a library, contrary 
to other areas of the JDK?

Sorry to push back, but I don’t agree with that position (if correct). I am 
reluctant to change the tests. Please don’t think that complete pigheadedness 
on my part :-) I just don’t think it’s the right thing to do.

If the HotSpot runtime team will not accept the use of TestNG then I suppose I 
could unblock by proposing to move the tests to the JDK repo, which I would 
also be reluctant to do since they caught an issue lying dormant for at least 8 
years on certain platforms (not covered by the core testset) that existing 
hotspot tests never caught.

Paul.

Re: [PING] RFR 6425769: jmx remote bind address

[Severin Gehwolf]

On Mon, 2015-11-09 at 10:32 +0100, Severin Gehwolf wrote:
> On Wed, 2015-11-04 at 11:54 +0100, Severin Gehwolf wrote:
> > Hi,
> > 
> > Updated webrev with jtreg test in Java:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/02/
> > bug: https://bugs.openjdk.java.net/browse/JDK-6425769
> > 
> > I believe this updated webrev addresses all concerns and
> > incorporates
> > suggestions brought up by Jaroslav and Daniel.
> > 
> > I'm still looking for a sponsor and a hotspot/servicability-dev
> > reviewer. Could somebody maintaining javax.rmi.ssl have a look at
> > this
> > as well? Thank you!
> 
> Ping? Friendly reminder that I still need reviewers and a sponsor for
> this.

Anyone?

> Thanks,
> Severin
> 
> > Cheers,
> > Severin
> > 
> > On Tue, 2015-11-03 at 15:45 +0100, Jaroslav Bachorik wrote:
> > > On 2.11.2015 19:06, Severin Gehwolf wrote:
> > > > Hi,
> > > > 
> > > > Thanks Jaroslav and Daniel for the reviews! Comments inline.
> > > > 
> > > > On Mon, 2015-11-02 at 16:54 +0100, Jaroslav Bachorik wrote:
> > > > > Hi,
> > > > > 
> > > > > On 2.11.2015 16:19, Daniel Fuchs wrote:
> > > > > > Hi Severin,
> > > > > > 
> > > > > > Adding serviceability-...@openjdk.java.net into the loop -
> > > > > > that's
> > > > > > a better alias than hotspot-dev for this kind of changes -
> > > > > > maybe
> > > > > > someone from serviceability-dev will offer to sponsor :-)
> > > > > > 
> > > > > > I will let serviceability team members comment on the
> > > > > > hotspot
> > > > > > changes.
> > > > > > 
> > > > > > ConnectorBootstrap.java
> > > > > > 
> > > > > > I have one suggestion and one concern:
> > > > > > 
> > > > > > Suggestion: I would suggest to reuse 'csf' (Client Socket
> > > > > > Factory)
> > > > > > and
> > > > > > ssf  (Server Socket Factory) variables rather than
> > > > > > introduce
> > > > > > the
> > > > > > two
> > > > > > new variables rmiServerSocketFactory and
> > > > > > rmiClientSocketFactory.
> > > > > > You might want to create a new boolean 'useSocketFactory'
> > > > > > variable,
> > > > > > if that makes the code more readable.
> > > > > > 
> > > > > > Concern: If I understand correctly how RMI socket factories
> > > > > > work,
> > > > > > the client socket factory will be serialized and sent to
> > > > > > the
> > > > > > client
> > > > > > side. This is problematic for interoperability, as the
> > > > > > class
> > > > > > may
> > > > > > not
> > > > > > present in the remote client - if the remote client is e.g.
> > > > > > jdk
> > > > > > 8.
> > > > > > 
> > > > > > As far as I can see, your new DefaultClientSocketFactory
> > > > > > doesn't do
> > > > > > anything useful - so I would suggest to simply get rid of
> > > > > > it,
> > > > > > and
> > > > > > only
> > > > > > set the Server Socket Factory when SSL is not involved.
> > > > 
> > > > Thanks. Fixed in updated webrev.
> > > > 
> > > > > > Tests:
> > > > > > 
> > > > > > Concerning the tests - we're trying to get rid of shell
> > > > > > scripts
> > > > > > rather than introducing new ones :-)
> > > > > > Could the test be rewritten in pure java using the Process
> > > > > > API?
> > > > > > 
> > > > > > I believe there's even a test library that will let you do
> > > > > > that
> > > > > > easily jdk/test/lib/testlibrary/jdk/testlibrary/
> > > > > > (see ProcessTools.java)
> > > > 
> > > > It'll take me a bit to rewrite the test in pure Java, but
> > > > should
> > > > be
> > > > fine. This is not yet fixed in the updated webrev.
> > > > 
> > > > > > Other:
> > > > > > 
> > > > > > Also - I believe the new option should be documented in:
> > > > > > src/java.management/share/conf/management.properties
> > > > 
> > > > Docs have been updated
> > > > in src/java.management/share/conf/management.properties.
> > > > 
> > > > > I share Daniel's concerns. Also, the part of the changeset is
> > > > > related
> > > > > to javax.rmi.ssl - someone maintaining this library should
> > > > > also
> > > > > comment here.
> > > > > 
> > > > > Also, the change is introducing new API (system property) and
> > > > > changing the existing one (adding SslRmiServerSocketFactory
> > > > > public
> > > > > constructors) so compatibility review process will have to be
> > > > > involved.
> > > > 
> > > > OK. What exactly is there for me to do? I'm not familiar with
> > > > this
> > > > process. Note that the intent would be to get this backported
> > > > to
> > > > JDK 8.
> > > Not much for you. But for the potential Oracle sponsor this means
> > > she
> > > will have to remember to go through some extra hoops before
> > > integrating your patch.
> > 
> > I see. Thanks for clarifying it.
> > 
> > > -JB-
> > > 
> > > > 
> > > > New webrev at:
> > > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6425769/01/
> > > > 
> > > > Thanks,
> > > > Severin
> > > > 
> > > > > -JB-
> > > > > > 
> > > > > > best regards,
> > > > > > 
> > > > > > -- daniel
> > > > > > 
> > > > > > On 02/11/15 11:38, Severin Gehwolf wrote:
> > > > > > > Hi,
> > > 

Unexpected BindException in Endpoint.publish

[KUBOTA Yuji]

Hi Miroslav and all,

Could you please review the below issue and patch?

I got the advice by Alan at net-dev. So I want to ask you.
http://mail.openjdk.java.net/pipermail/net-dev/2015-December/009361.html


I'm at the HackerGarten @ JavaOne15, and write a patch for OpenJDK
community. This's second times from JavaOne14. :)

We find an unexpected exception in JAX-WS, so I write a patch to fix it.
We think that this issue may block the migration to JDK9 from JDK7.

If we bind 0.0.0.0 ( using as wildcard ) to publish multiple as the
following test code, JDK9 (and JDK8) returns "java.net.BindException:
Address already in use.” as the below. But JDK7 does NOT return the
exception.

- Test code for reproduce
---
import javax.jws.*;
import javax.xml.ws.*;

public class WSTest{

  @WebService
  public static class Method1{
@WebMethod
public String getMethod1Value(){
  return "from Method1";
}
  }

  @WebService
  public static class Method2{
@WebMethod
public String getMethod2Value(){
  return "from Method2";
}
  }

  public static void main(String[] args) throws Exception{
Endpoint endPoint1 = Endpoint.publish("http://0.0.0.0:8081/method1";,
 new Method1());
Endpoint endPoint2 = Endpoint.publish("http://0.0.0.0:8081/method2";,
 new Method2());

System.out.println("Sleep 3 secs...");

Thread.sleep(3000);

endPoint2.stop();
endPoint1.stop();
  }

}
---

- StackTrace
---
Exception in thread "main"
com.sun.xml.internal.ws.server.ServerRtException: Server Runtime
Error: java.net.BindException: Address already in use
at 
com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:117)
at 
com.sun.xml.internal.ws.transport.http.server.HttpEndpoint.publish(HttpEndpoint.java:64)
at 
com.sun.xml.internal.ws.transport.http.server.EndpointImpl.publish(EndpointImpl.java:232)
at 
com.sun.xml.internal.ws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:126)
at javax.xml.ws.Endpoint.publish(Endpoint.java:240)
at wstest.WSTest.main(WSTest.java:27)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:432)
at sun.nio.ch.Net.bind(Net.java:424)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at sun.net.httpserver.ServerImpl.(ServerImpl.java:102)
at sun.net.httpserver.HttpServerImpl.(HttpServerImpl.java:50)
at 
sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:35)
at com.sun.net.httpserver.HttpServer.create(HttpServer.java:130)
at 
com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:86)
... 5 more
-

To publishes the Endpoint, JAX-WS checks whether the HttpContext has
been created by given address, then creates a HttpContext if do not
exist.
If we sets 0.0.0.0 as given address, JAX-WS checks by
ServerSocket#getLocalSocketAddress() (server local address), so
returns BindException when 0.0.0.0 has been blinded already.

Why so? JAX_WS-941[1] fixes NPE in Endpoint.stop but do not think
about above situation. And JAX_WS-941 does not back port to JDK7.

So I write a patch which is based jdk9/dev/jaxws
(changeset:637:2d84c6f4cbba) to fix the BindException with JAX_WS-941.

Please review this patch :)

[1]: https://java.net/jira/browse/JAX_WS-941

- Patch
---
diff -r 2d84c6f4cbba
src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java
--- 
a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java
Thu Oct 22 08:47:47 2015 -0700
+++ 
b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java
Tue Oct 27 19:48:35 2015 +0900
@@ -38,6 +38,7 @@
 import java.util.concurrent.ExecutorService;
 import java.util.concurrent.Executors;
 import java.util.logging.Logger;
+import java.util.Optional;

 /**
  * Manages all the WebService HTTP servers created by JAXWS runtime.
@@ -81,24 +82,38 @@
 synchronized(servers) {
 state = servers.get(inetAddress);
 if (state == null) {
-logger.fine("Creating new HTTP Server at "+inetAddress);
-// Creates server with default socket backlog
-server = HttpServer.create(inetAddress, 0);
-server.setExecutor(Executors.newCachedThreadPool());
-String path = url.toURI().getPath();
-logger.fine("Creating HTTP Context at = "+path);
-HttpContext context = server.createContext(path);
-server.start();
+final 

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

[Staffan Larsen]

Looks good and sorry for the delay.

Thanks,
/Staffan

> On 24 nov. 2015, at 20: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