Re: RFR (s): 8217412 deprecate rmic for removal

[Sundararajan Athijegannathan]

Looks good.

-Sundar

On 31/05/19, 6:40 AM, Stuart Marks wrote:

Hi all,

Please review this patch and CSR request for upgrading the deprecation 
status of the rmic to from ordinary to terminal (i.e., conceptually 
set forRemoval=true, though there are no actual annotations involved 
here).


There are no code changes, just documentation changes and changes to 
the warning message that rmic emits when run.


Webrev:

http://cr.openjdk.java.net/~smarks/reviews/8217412/webrev.0/

(Sorry, the long lines in these files make most of the webrev output
unreadable. It might be easiest to look directly at the patch.)

JIRA bug:

https://bugs.openjdk.java.net/browse/JDK-8217412

Also please review this CSR request:

https://bugs.openjdk.java.net/browse/JDK-8225025

If you review the CSR, please edit its JIRA issue and add yourself to 
the "Reviewed By" field.


Thanks,

s'marks

Re: RFR [XS/docs] JDK-8225094: Fix minor HTML issues in jdk.zipfs

[Mandy Chung]

+1

Mandy

On 5/30/19 6:07 PM, Jonathan Gibbons wrote:

Please review a simple docs fix for jdk.zipfs module-info.java.

The ranks of the headings are updated to close up the gaps, and a 
couple of superfluous  are removed.


Webrev link below, but the patch is small enough to read inline if you 
want.


-- Jon

JBS: https://bugs.openjdk.java.net/browse/JDK-8225094
Webrev: 
http://cr.openjdk.java.net/~jjg/8225094/webrev.00/webrev/index.html



--- old/src/jdk.zipfs/share/classes/module-info.java    2019-05-30 
17:57:05.203832090 -0700
+++ new/src/jdk.zipfs/share/classes/module-info.java    2019-05-30 
17:57:04.991832098 -0700

@@ -26,9 +26,8 @@
 /**
  * Provides the implementation of the Zip file system provider.
  * The Zip file system provider treats the contents of a Zip or JAR 
file as a file system.

- * 
  *
- * Accessing a Zip File System
+ * Accessing a Zip File System
  *
  * The {@linkplain java.nio.file.FileSystems FileSystems} {@code 
newFileSystem}

  * static factory methods can be used to:
@@ -41,11 +40,10 @@
  *
  * The URI {@link java.net.URI#getScheme scheme} that identifies the 
ZIP file system is {@code jar}.

  *
- * Zip File System Properties
+ * Zip File System Properties
  *
  * The following properties may be specified when creating a Zip
  * file system:
- * 
  * 
  * 
  * Configurable properties that may be specified when creating
@@ -82,7 +80,7 @@
  * 
  * 
  *
- * Examples:
+ * Examples:
  *
  * Construct a new Zip file system that is identified by a URI. If 
the Zip file does not exist,

  * it will be created:

RFR [XS/docs] JDK-8225094: Fix minor HTML issues in jdk.zipfs

[Jonathan Gibbons]

Please review a simple docs fix for jdk.zipfs module-info.java.

The ranks of the headings are updated to close up the gaps, and a couple 
of superfluous  are removed.


Webrev link below, but the patch is small enough to read inline if you want.

-- Jon

JBS: https://bugs.openjdk.java.net/browse/JDK-8225094
Webrev: http://cr.openjdk.java.net/~jjg/8225094/webrev.00/webrev/index.html


--- old/src/jdk.zipfs/share/classes/module-info.java2019-05-30 
17:57:05.203832090 -0700
+++ new/src/jdk.zipfs/share/classes/module-info.java2019-05-30 
17:57:04.991832098 -0700
@@ -26,9 +26,8 @@
 /**
  * Provides the implementation of the Zip file system provider.
  * The Zip file system provider treats the contents of a Zip or JAR file as a 
file system.
- * 
  *
- * Accessing a Zip File System
+ * Accessing a Zip File System
  *
  * The {@linkplain java.nio.file.FileSystems FileSystems} {@code newFileSystem}
  * static factory methods can be used to:
@@ -41,11 +40,10 @@
  *
  * The URI {@link java.net.URI#getScheme scheme} that identifies the ZIP file 
system is {@code jar}.
  *
- * Zip File System Properties
+ * Zip File System Properties
  *
  * The following properties may be specified when creating a Zip
  * file system:
- * 
  * 
  * 
  * Configurable properties that may be specified when creating
@@ -82,7 +80,7 @@
  * 
  * 
  *
- * Examples:
+ * Examples:
  *
  * Construct a new Zip file system that is identified by a URI.  If the Zip 
file does not exist,
  * it will be created:

RFR (s): 8217412 deprecate rmic for removal

[Stuart Marks]

Hi all,

Please review this patch and CSR request for upgrading the deprecation status of 
the rmic to from ordinary to terminal (i.e., conceptually set forRemoval=true, 
though there are no actual annotations involved here).


There are no code changes, just documentation changes and changes to the warning 
message that rmic emits when run.


Webrev:

http://cr.openjdk.java.net/~smarks/reviews/8217412/webrev.0/

(Sorry, the long lines in these files make most of the webrev output
unreadable. It might be easiest to look directly at the patch.)

JIRA bug:

https://bugs.openjdk.java.net/browse/JDK-8217412

Also please review this CSR request:

https://bugs.openjdk.java.net/browse/JDK-8225025

If you review the CSR, please edit its JIRA issue and add yourself to the 
"Reviewed By" field.


Thanks,

s'marks

Re: RFR: docs/accessibility: JDK-8220251: fix headings in java.management

[Lance Andersen]

looks ok Jon

> On May 30, 2019, at 7:53 PM, Jonathan Gibbons  
> wrote:
> 
> Please review a conceptually simple fix to adjust the rank of the headings in 
> the following files in 4 management-related modules:
> 
> src/java.management.rmi/share/classes/javax/management/remote/rmi/package.html
> src/java.management/share/classes/java/lang/management/LockInfo.java
> src/java.management/share/classes/java/lang/management/ManagementFactory.java
> src/java.management/share/classes/java/lang/management/MemoryMXBean.java
> src/java.management/share/classes/java/lang/management/MemoryPoolMXBean.java
> src/java.management/share/classes/java/lang/management/MemoryUsage.java
> src/java.management/share/classes/java/lang/management/MonitorInfo.java
> src/java.management/share/classes/java/lang/management/ThreadInfo.java
> src/java.management/share/classes/java/lang/management/ThreadMXBean.java
> src/java.management/share/classes/java/lang/management/package.html
> src/java.management/share/classes/javax/management/MXBean.java
> src/java.management/share/classes/javax/management/NotificationBroadcaster.java
> src/java.management/share/classes/javax/management/NotificationEmitter.java
> src/java.management/share/classes/javax/management/remote/package.html
> src/jdk.management.jfr/share/classes/jdk/management/jfr/FlightRecorderMXBean.java
> src/jdk.management/share/classes/com/sun/management/GcInfo.java
> 
> In most files, the headings are simply adjusted "up" to close up "gaps" in 
> the sequence of headings. In a couple of files, the headings were 
> inconsistent and have been updated as seems best. To help understand the 
> changes, I've attached the output of a script that shows the lines containing 
> headings before and after the change.
> 
> -- Jon
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8220251
> Webrev: http://cr.openjdk.java.net/~jjg/8220251/webrev.00/webrev/index.html
> Docs: http://cr.openjdk.java.net/~jjg/8220251/docs/api/index.html
> 
> 

 
  

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

RFR: docs/accessibility: JDK-8220251: fix headings in java.management

[Jonathan Gibbons]

Please review a conceptually simple fix to adjust the rank of the 
headings in the following files in 4 management-related modules:


src/java.management.rmi/share/classes/javax/management/remote/rmi/package.html
src/java.management/share/classes/java/lang/management/LockInfo.java
src/java.management/share/classes/java/lang/management/ManagementFactory.java
src/java.management/share/classes/java/lang/management/MemoryMXBean.java
src/java.management/share/classes/java/lang/management/MemoryPoolMXBean.java
src/java.management/share/classes/java/lang/management/MemoryUsage.java
src/java.management/share/classes/java/lang/management/MonitorInfo.java
src/java.management/share/classes/java/lang/management/ThreadInfo.java
src/java.management/share/classes/java/lang/management/ThreadMXBean.java
src/java.management/share/classes/java/lang/management/package.html
src/java.management/share/classes/javax/management/MXBean.java
src/java.management/share/classes/javax/management/NotificationBroadcaster.java
src/java.management/share/classes/javax/management/NotificationEmitter.java
src/java.management/share/classes/javax/management/remote/package.html
src/jdk.management.jfr/share/classes/jdk/management/jfr/FlightRecorderMXBean.java
src/jdk.management/share/classes/com/sun/management/GcInfo.java

In most files, the headings are simply adjusted "up" to close up "gaps" 
in the sequence of headings. In a couple of files, the headings were 
inconsistent and have been updated as seems best. To help understand the 
changes, I've attached the output of a script that shows the lines 
containing headings before and after the change.


-- Jon

JBS: https://bugs.openjdk.java.net/browse/JDK-8220251
Webrev: http://cr.openjdk.java.net/~jjg/8220251/webrev.00/webrev/index.html
Docs: http://cr.openjdk.java.net/~jjg/8220251/docs/api/index.html

>>> open/src/java.management.rmi/share/classes/javax/management/remote/rmi/package.html
BEFORE:
Creating an RMI connector server
Choosing the RMI transport
Connector addresses generated by the
server
Connector addresses based on directory
entries
Connector server attributes
Creating an RMI connector client
Dynamic code downloading

AFTER:
Creating an RMI connector server
Choosing the RMI transport
Connector addresses generated by the
server
Connector addresses based on directory
entries
Connector server attributes
Creating an RMI connector client
Dynamic code downloading


>>> open/src/java.management/share/classes/java/lang/management/LockInfo.java
BEFORE:
 * MXBean Mapping

AFTER:
 * MXBean Mapping


>>> open/src/java.management/share/classes/java/lang/management/ManagementFactory.java
BEFORE:
 * Platform MXBeans
 * 1. Direct access to an MXBean interface
 * 2. Indirect access to an MXBean interface via MBeanServer

AFTER:
 * Platform MXBeans
 * 1. Direct access to an MXBean interface
 * 2. Indirect access to an MXBean interface via MBeanServer


>>> open/src/java.management/share/classes/java/lang/management/MemoryMXBean.java
BEFORE:
 *  Memory 
 *  1. Heap 
 *  2. Non-Heap Memory
 * Memory Pools and Memory Managers
 * Memory Usage Monitoring
 * Notifications
 * NotificationEmitter

AFTER:
 *  Memory 
 *  1. Heap 
 *  2. Non-Heap Memory
 * Memory Pools and Memory Managers
 * Memory Usage Monitoring
 * Notifications
 * NotificationEmitter


>>> open/src/java.management/share/classes/java/lang/management/MemoryPoolMXBean.java
BEFORE:
 * Memory Type
 * Memory Usage Monitoring
 * 1. Memory Usage
 * 2. Peak Memory Usage
 * 3. Usage Threshold
 * 4. Collection Usage Threshold

AFTER:
 * Memory Type
 * Memory Usage Monitoring
 * 1. Memory Usage
 * 2. Peak Memory Usage
 * 3. Usage Threshold
 * 4. Collection Usage Threshold


>>> open/src/java.management/share/classes/java/lang/management/MemoryUsage.java
BEFORE:
 * MXBean Mapping

AFTER:
 * MXBean Mapping


>>> open/src/java.management/share/classes/java/lang/management/MonitorInfo.java
BEFORE:
 * MXBean Mapping

AFTER:
 * MXBean Mapping


>>> open/src/java.management/share/classes/java/lang/management/ThreadInfo.java
BEFORE:
 * General thread information
 * Execution information
 * Synchronization Statistics
 * MXBean Mapping

AFTER:
 * General thread information
 * Execution information
 * Synchronization Statistics
 * MXBean Mapping


>>> open/src/java.management/share/classes/java/lang/management/ThreadMXBean.java
BEFORE:
 * Thread ID
 * Thread CPU time
 * Thread Contention Monitoring
 * Synchronization Information and Deadlock Detection

AFTER:
 * Thread ID
 * Thread CPU time
 * Thread Contention Monitoring
 * Synchronization Information and Deadlock Detection


>>> open/src/java.management/share/classes/java/lang/management/package.html
BEFORE:
Platform MXBean
ManagementFactory
Interoperability
Ways to Access MXBeans
Platform Extension

AFTER:
Platform MXBean
ManagementFactory
Interoperability
Ways to Access MXBeans
Platform Extension


>>> 

Re: RFR 8212807: tools/jar/multiRelease/Basic.java times out

[Brent Christian]

Thank you for elaborating.  The new version looks good.

-Brent

On 5/30/19 1:29 PM, Lance Andersen wrote:

Hi Brent,
On May 30, 2019, at 4:02 PM, Brent Christian 
mailto:brent.christ...@oracle.com>> wrote:


Hi, Lance


Thank you for the review.



This change is to collect more information in case this happens again, 
yes?


This changes reduces the use of ProcessBuilder resulting in much 
improved test runs similar to what I did for:

https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059471.html

I took out the timing output from the tests after verifying the 
reduction in the test runs (which I ran 100 on the failing systems via 
mach 5 comparing before/after times)


Using ToolProvider is much more efficient than ProcessBuilder as I found 
out from the previous issue.  The reduction in time was in line with the 
previous issue :-)


Looks pretty good - just a couple comments:


test/jdk/tools/jar/multiRelease/Basic.java

536 jar("ufm", jarfile, manifest.toString(),

Is there a reason not to convert this to call jarTool() ?


Yes,  java.util.jar.Attributes uses java.util.Logging to emit a warning 
for some reason which makes it a bit more difficult to deal with in this 
specific test.  So I left this one test for now.  At some point I want 
to go back through the other tests which use MRTestBase  and convert the 
tests to also use ToolProvider and I can look to  revisit the issue then.


Right now I am trying to cut down on the noise of some of the random 
timeouts :-)


--

test/jdk/tools/jar/multiRelease/MRTestBase.java


L146-L152

indentation looks off-by-one



Thank you for catching this,  I updated the webrev : 
http://cr.openjdk.java.net/~lancea/8212807/webrev.01/


Best
Lance


Thanks,
-Brent

On 5/30/19 9:21 AM, Lance Andersen wrote:

Hi all,
The following fix addresses an issue with an occasional timeout for 
tools/jar/multiRelease/Basic.java.
The webrev can be found at: 
http://cr.openjdk.java.net/~lancea/8212807/webrev.00/index.html 


Best,
Lance
 
  

 Lance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037

Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com  





Lance Andersen| 
Principal Member of Technical Staff | +1.781.442.2037

Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses

[Kim Barrett]

> On May 30, 2019, at 3:58 PM, Roger Riggs  wrote:
> 
> Hi Kim,
> 
> To ensure you see some messages in the case of timeouts, it would be
> useful to call System.out.flush() after printing the message in logProcess().

Good idea; added.

full: http://cr.openjdk.java.net/~kbarrett/8219149/open.01/
incr: http://cr.openjdk.java.net/~kbarrett/8219149/open.01.inc/

> I'm ok with the timestamps, as is, though the Duration might be useful in
> some cases.

As I discussed with Roger, I want to keep the change simple for now,
as we're not yet sure where to expend effort looking deeper.  I think
comparing timestamps in just a few cases will tell us a lot (possibly
that we're looking in entirely the wrong place, in which case we might
just undo this change).

Re: RFR: [XS,doc] JDK-8225077: fix references to broken link in java.compiler module

[Lance Andersen]

+1

> On May 30, 2019, at 4:32 PM, Jonathan Gibbons  
> wrote:
> 
> Please review a one line change to fix a 404 link in 
> javax/annotation/processing/Filer.java
> With this fix, DocCheck finds no errors in the java.compiler module.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8225077
> 
> -- Jon
> 
> 
> Patch inline:
> 
> $ hg diff -R open
> diff -r a0d4e61acb6b 
> src/java.compiler/share/classes/javax/annotation/processing/Filer.java
> --- a/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 
> Thu May 30 12:45:02 2019 -0700
> +++ b/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 
> Thu May 30 13:27:15 2019 -0700
> @@ -60,7 +60,7 @@
>   * by {@code '/'}; {@code '.'} and {@code '..'} are invalid path
>   * segments.  A valid relative name must match the
>   * path-rootless rule of  - * href="http://www.ietf.org/html/rfc3986.txt;>RFC 3986, section
> + * href="http://www.ietf.org/rfc/rfc3986.txt;>RFC3986, section
>   * 3.3.
>   *
>   * The file creation methods take a variable number of arguments to
> 

 
  

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

Re: RFR: [XS, doc] JDK-8225077: fix references to broken link in java.compiler module

[Joseph D. Darcy]

+1

Thanks Jon,

-Joe

On 5/30/2019 1:32 PM, Jonathan Gibbons wrote:
Please review a one line change to fix a 404 link in 
javax/annotation/processing/Filer.java

With this fix, DocCheck finds no errors in the java.compiler module.

JBS: https://bugs.openjdk.java.net/browse/JDK-8225077

-- Jon


Patch inline:

$ hg diff -R open
diff -r a0d4e61acb6b 
src/java.compiler/share/classes/javax/annotation/processing/Filer.java
--- 
a/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 
Thu May 30 12:45:02 2019 -0700
+++ 
b/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 
Thu May 30 13:27:15 2019 -0700

@@ -60,7 +60,7 @@
  * by {@code '/'}; {@code '.'} and {@code '..'} are invalid path
  * segments.  A valid relative name must match the
  * path-rootless rule of http://www.ietf.org/html/rfc3986.txt;>RFC 3986, section
+ * href="http://www.ietf.org/rfc/rfc3986.txt;>RFC3986, section
  * 3.3.
  *
  * The file creation methods take a variable number of arguments to

RFR: [XS,doc] JDK-8225077: fix references to broken link in java.compiler module

[Jonathan Gibbons]

Please review a one line change to fix a 404 link in 
javax/annotation/processing/Filer.java

With this fix, DocCheck finds no errors in the java.compiler module.

JBS: https://bugs.openjdk.java.net/browse/JDK-8225077

-- Jon


Patch inline:

$ hg diff -R open
diff -r a0d4e61acb6b 
src/java.compiler/share/classes/javax/annotation/processing/Filer.java
--- 
a/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 
Thu May 30 12:45:02 2019 -0700
+++ 
b/src/java.compiler/share/classes/javax/annotation/processing/Filer.java 
Thu May 30 13:27:15 2019 -0700

@@ -60,7 +60,7 @@
  * by {@code '/'}; {@code '.'} and {@code '..'} are invalid path
  * segments.  A valid relative name must match the
  * path-rootless rule of http://www.ietf.org/html/rfc3986.txt;>RFC 3986, section
+ * href="http://www.ietf.org/rfc/rfc3986.txt;>RFC3986, section
  * 3.3.
  *
  * The file creation methods take a variable number of arguments to

Re: RFR 8212807: tools/jar/multiRelease/Basic.java times out

[Lance Andersen]

Hi Brent,
> On May 30, 2019, at 4:02 PM, Brent Christian  
> wrote:
> 
> Hi, Lance

Thank you for the review.

> 
> This change is to collect more information in case this happens again, yes?

This changes reduces the use of ProcessBuilder resulting in much improved test 
runs similar to what I did for:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-April/059471.html 


I took out the timing output from the tests after verifying the reduction in 
the test runs (which I ran 100 on the failing systems via mach 5 comparing 
before/after times)

Using ToolProvider is much more efficient than ProcessBuilder as I found out 
from the previous issue.  The reduction in time was in line with the previous 
issue :-) 
> 
> Looks pretty good - just a couple comments:
> 
> 
> test/jdk/tools/jar/multiRelease/Basic.java
> 
> 536 jar("ufm", jarfile, manifest.toString(),
> 
> Is there a reason not to convert this to call jarTool() ?

Yes,  java.util.jar.Attributes uses java.util.Logging to emit a warning for 
some reason which makes it a bit more difficult to deal with in this specific 
test.  So I left this one test for now.  At some point I want to go back 
through the other tests which use MRTestBase  and convert the tests to also use 
ToolProvider and I can look to  revisit the issue then.

Right now I am trying to cut down on the noise of some of the random timeouts 
:-)
> 
> --
> 
> test/jdk/tools/jar/multiRelease/MRTestBase.java
> 
> 
> L146-L152
> 
> indentation looks off-by-one
> 

Thank you for catching this,  I updated the webrev : 
http://cr.openjdk.java.net/~lancea/8212807/webrev.01/ 


Best
Lance
> 
> Thanks,
> -Brent
> 
> On 5/30/19 9:21 AM, Lance Andersen wrote:
>> Hi all,
>> The following fix addresses an issue with an occasional timeout for 
>> tools/jar/multiRelease/Basic.java.
>> The webrev can be found at: 
>> http://cr.openjdk.java.net/~lancea/8212807/webrev.00/index.html 
>> 
>> Best,
>> Lance
>>  
>>   
>> 
>>  Lance Andersen| 
>> Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> lance.ander...@oracle.com 

 
  

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

Re: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses

[Kim Barrett]

> On May 30, 2019, at 12:42 AM, David Holmes  wrote:
> 
> Adding back hotspot-dev. I don't think Kim saw this.

I did see it, though nearly missed, and not spotted until late evening.  Thanks 
for making sure…

> 
> David
> 
> On 30/05/2019 4:04 am, Roger Riggs wrote:
>> Hi Kim,
>> In the normal output less output is cleaner.
>> It would be more useful to have the Duration of the wait and end time of the 
>> wait.
>> (It saves the reader doing subtraction of times).
>> +  Instant start = Instant.now();
>> +  boolean aborted = true;
>> +  try {
>> +  int result = p.waitFor();
>> +  aborted = false;
>> +  return result;
>> +  } finally {
>> +  Duration dur = Duration.between(start, Instant.now());
>> +  if (aborted) {
>> +  logProgress("Waiting for completion FAILED after: " + 
>> dur);
>> +  } else {
>> +  logProgress("Waiting for completion finished after: " + 
>> dur);
>> +  }
>> +  }
>> Or something like that.
>> Roger
>> On 05/29/2019 01:24 PM, Kim Barrett wrote:
>>> [I’m not completely sure where this RFR should be sent, but core-libs-dev
>>> and hotspot-dev seems likely to get reasonable coverage of those who
>>> might care.]
>>> 
>>> Please review this change to the test library to add some "logging"
>>> output to tests that spawn a child process to perform the test and
>>> then analyze that child's output.  We are seeing occasional timeouts
>>> in such tests whose cause is hard to pin down.  It's not clear whether
>>> the excess time is in the child or instead some problem in the testing
>>> framework.  The new logging output provides timestamps for (1) the
>>> start of output collection from the child, (2) the start of waiting
>>> for the child to terminate, and (3) the child's termination.  This
>>> should be enough to determine whether the child is taking too long,
>>> and hint at where (e.g. termination or not).
>>> 
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8219149
>>> 
>>> Webrev:
>>> http://cr.openjdk.java.net/~kbarrett/8219149/open.00/
>>> 
>>> Testing:
>>> Local hs-tier1 and verified the expected logging output is present.
>>> mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems
>>> caused by the new logging.  (It seems unlikely, but...)

Re: RFR 8212807: tools/jar/multiRelease/Basic.java times out

[Brent Christian]

Hi, Lance

This change is to collect more information in case this happens again, yes?

Looks pretty good - just a couple comments:


test/jdk/tools/jar/multiRelease/Basic.java

 536 jar("ufm", jarfile, manifest.toString(),

Is there a reason not to convert this to call jarTool() ?

--

test/jdk/tools/jar/multiRelease/MRTestBase.java


L146-L152

indentation looks off-by-one


Thanks,
-Brent

On 5/30/19 9:21 AM, Lance Andersen wrote:

Hi all,

The following fix addresses an issue with an occasional timeout for 
tools/jar/multiRelease/Basic.java.

The webrev can be found at: 
http://cr.openjdk.java.net/~lancea/8212807/webrev.00/index.html 



Best,
Lance
  
   

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

Re: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses

[Roger Riggs]

Hi Kim,

To ensure you see some messages in the case of timeouts, it would be
useful to call System.out.flush() after printing the message in 
logProcess().


I'm ok with the timestamps, as is, though the Duration might be useful in
some cases.

+1, Roger


On 05/30/2019 12:42 AM, David Holmes wrote:

Adding back hotspot-dev. I don't think Kim saw this.

David

On 30/05/2019 4:04 am, Roger Riggs wrote:

Hi Kim,

In the normal output less output is cleaner.
It would be more useful to have the Duration of the wait and end time 
of the wait.

(It saves the reader doing subtraction of times).

+  Instant start = Instant.now();
+  boolean aborted = true;
+  try {
+  int result = p.waitFor();
+  aborted = false;
+  return result;
+  } finally {
+  Duration dur = Duration.between(start, Instant.now());
+  if (aborted) {
+  logProgress("Waiting for completion FAILED after: 
" + dur);

+  } else {
+  logProgress("Waiting for completion finished 
after: " + dur);

+  }
+  }

Or something like that.

Roger


On 05/29/2019 01:24 PM, Kim Barrett wrote:
[I’m not completely sure where this RFR should be sent, but 
core-libs-dev

and hotspot-dev seems likely to get reasonable coverage of those who
might care.]

Please review this change to the test library to add some "logging"
output to tests that spawn a child process to perform the test and
then analyze that child's output.  We are seeing occasional timeouts
in such tests whose cause is hard to pin down.  It's not clear whether
the excess time is in the child or instead some problem in the testing
framework.  The new logging output provides timestamps for (1) the
start of output collection from the child, (2) the start of waiting
for the child to terminate, and (3) the child's termination. This
should be enough to determine whether the child is taking too long,
and hint at where (e.g. termination or not).

CR:
https://bugs.openjdk.java.net/browse/JDK-8219149

Webrev:
http://cr.openjdk.java.net/~kbarrett/8219149/open.00/

Testing:
Local hs-tier1 and verified the expected logging output is present.
mach5 tier1-3 to ensure there aren't any "obvious" unexpected problems
caused by the new logging.  (It seems unlikely, but...)

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

[Martin Buchholz]

If you are calling System.gc() for correctness (e.g. in a test), it is
probably because some sort of finalization is being triggered.  And that
happens in some Java thread (e.g. Reference Handler) that System.gc() has
no control over.  So in practice, users need to call System.gc() and then
wait for subsequent reference processing somehow.

Re: RFR: 8224974: Implement JEP 352

[Vladimir Kozlov]

On 5/30/19 9:08 AM, Andrew Dinn wrote:

HI Vladimir,

Thank you for reviewing the patch.

On 29/05/2019 20:49, Vladimir Kozlov wrote:

I tried to test these changes and build failed on all systems except
Linux because:

workspace/open/src/hotspot/share/prims/unsafe.cpp:446:3: error: use of
undeclared identifier 'JNU_ThrowRuntimeException'
    JNU_ThrowRuntimeException(env, "writeback is not implemented");
    ^


Apologies for that. I forgot to test this via the submit repo after
cut-and-pasting the checks for OS and CPU support from the map0 native
method to the Unsafe writeback method.

I had to make some tweaks to this code anyway in order to spot an issue
Alan noticed when checking the CSR (the map code was not distinguishing
the precise cases where IOException and UnsupportedOperationException
needed to be thrown and would sometimes have replaced the latter with
the former on Windows/x86_64).


Okay.



I have uploaded a new webrev which attempts to address the problem.

   http://cr.openjdk.java.net/~adinn/8224974/webrev.03


I looked only on HotSpot code.

stubGenerator_x86_64.cpp - in generate_data_cache_writeback() next are not used:

+bool optimized = VM_Version::supports_clflushopt();
+bool no_evict = VM_Version::supports_clwb();

vm_version_x86.hpp it should check CPUID flag in 32-bit:

+#else
+  static bool supports_clflush() { return true; }


We don't check has_match_rule() in LibraryCallKit any more.
In .ad files you need to add predicate to new insrtructions:

  predicate(VM_Version::supports_data_cache_line_flush());

Also add this check to Matcher::match_rule_supported() which you can use then 
in C2Compiler::is_intrinsic_supported().
DISABLE_UNSAFE_WRITEBACK_INTRINSIC should be checked much early may be together with os::supports_map_sync() when you 
set _data_cache_line_flush_size.




The test to see whether writeback is enabled on the current cpu_os
combination is now performed in Java from methods Unsafe.writebackMemory
and FileChannelImpl.map, using a call to Unsafe.isWritebackEnabled()

There are also 'belt and braces' checks in the corresponding native
implementation methods:

Unsafe asserts that VM_Version::supports_data_cache_line_writeback()
returns true. The result of this method indicates whether support is
available on both CPU and OS. It returns a value computed using a call
to a new OS-specific method os::supports_map_sync() and, on hardware for
which that is true (AArch64 and x86_64), a test of the relevant CPU
status bits.

FileChannelImpl still relies on conditional compilation to reject calls
on invalid OS/CPU combinations (the VM_VERSION method is not available
for it to call). In the branch for !LINUX || !(AArch64 || amd64) it
throws an InternalError as this path not be reached.

Unfortunately, this latest webrev still fails when uploaded to the
submit repo. The problem seems to be specific to Windows/x86_64 builds.
The branch that failed is JDK-8224974-03. The returned text is appended
after my signature. Would you be able to provide some details about the
errors
 t:/workspace/open/src/java.base/windows/native/libnio/ch/FileChannelImpl.c(64): error C2220: warning treated as error 
- no 'object' file generated
 t:/workspace/open/src/java.base/windows/native/libnio/ch/FileChannelImpl.c(64): warning C4029: declared formal 
parameter list different from definition






Also Graal test should be fixed for new intrinsics (add them to
'toBeInvestigated' for isJDK13orHigher):

src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java

That has been fixed in the webrev mentioned above.


Good.

Thanks,
Vladimir



regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander


- 8<  8<  8<  8<  8<  8< ---

BuildId: 2019-05-30-1509485.adinn.source
No failed tests
Tasks Summary

 UNABLE_TO_RUN: 18
 NOTHING_TO_RUN: 0
 KILLED: 0
 EXECUTED_WITH_FAILURE: 4
 FAILED: 0
 HARNESS_ERROR: 0
 NA: 0
 PASSED: 55
 Build

 1 Unable to run
 windows-x64-install-windows-x64-build-19 Dependency task
failed: mach5...1512-2804499-windows-x64-windows-x64-build-12
 4 Executed with failure
 windows-x64-windows-x64-build-12 error while building,
return value: 2
 windows-x64-debug-windows-x64-build-13 error while building,
return value: 2
 windows-x64-open-windows-x64-build-14 error while building,
return value: 2
 windows-x64-open-debug-windows-x64-build-15 error while
building, return value: 2

 Test

 17 Unable to run

tier1-product-open_test_hotspot_jtreg_tier1_common-windows-x64-22
Dependency task failed:

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

[Aleksey Shipilev]

On 5/30/19 6:48 PM, Roger Riggs wrote:
> There are several ways to monitor the progress/"completion" of gc,
> including visible affects on WeakReference, etc., Runtime.availableMemory, 
> etc.
> Without the ("or ever"), the case can be made that eventually some kind of 
> completion
> should be/must be visible directly or indirectly.

Yes. I had implemented that code several times before, and it sucked every 
time. That was before I
discovered System.gc() is actually blocking by the virtue of "When control from 
the method call,
...". If we are relaxing that, can we at least provide the implementation note 
that some
implementations choose to block, for users' convenience?

-Aleksey

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

[Roger Riggs]

Hi Peter,

There are several ways to monitor the progress/"completion" of gc,
including visible affects on WeakReference, etc., 
Runtime.availableMemory, etc.
Without the ("or ever"), the case can be made that eventually some kind 
of completion

should be/must be visible directly or indirectly.

Roger


On 05/30/2019 11:55 AM, Peter Levart wrote:

Yes Roger, this sounds better to me.

Maybe even easier:

"There is no guarantee that this effort will recycle any particular 
number of unused objects, reclaim any particular amount of space, or 
complete before the method returns (or ever)."


So, hypothetically, the effort triggered by System.gc() may never 
complete although the method will eventually return. Is this what was 
meant to be said?

yes


Is it necessary to have this (or ever) at the end? What's the purpose 
of it? If the method returns before the attempt completes, there's no 
way to track the attempt to its completion and doesn't matter if it 
eventually completes or not. The completion is already out of bounds 
for this method when it says: "there is not guarantee that the attempt 
completes before the method returns"...


Regards, Peter

On 5/30/19 4:42 PM, Roger Riggs wrote:

Hi,

Though I see your point about gc() eventually returns, the spec 
typically does not
guarantee than any method eventually returns.  That's more a quality 
of service attribute.

The sentence refers to the effort to reclaim space, not the method call.

Would it clarify the case to add a qualification to the end of the 
sentence:

" before the method returns or ever."

As a whole:

 * Runs the garbage collector in the Java Virtual Machine.
 * 
 * Calling this method suggests that the Java Virtual Machine
 * expend effort toward recycling unused objects in order to
 * make the memory they currently occupy available for reuse
 * by the Java Virtual Machine.
 * When control returns from the method call, the Java Virtual 
Machine

 * has made a best effort to reclaim space from all unused objects.
 * There is no guarantee that this effort will recycle any particular
 * number of unused objects, reclaim any particular amount of space,
 * or complete at any particular time, if at all before the 
method returns or ever.


Thanks, Roger

On 05/30/2019 06:27 AM, Roman Kennke wrote:

Any other comments on:
"* Runs the garbage collector in the Java Virtual Machine.
* 
* Calling this method suggests that the Java Virtual Machine
* expend effort toward recycling unused objects in order to
* make the memory they currently occupy available for reuse
* by the Java Virtual Machine.

The following two statements...

1st:

* When control returns from the method call, the Java Virtual Machine
* has made a best effort to reclaim space from all discarded objects.

2nd:

* There is no guarantee that this effort will recycle any particular
* number of unused objects, reclaim any particular amount of space,
* *or complete* at any particular time, if *at all*.
"

...makes one think that it is OK (by the spec) for System.gc() to never
complete.

Could it rather be specified that System.gc() eventually completes?


+1 I was thinking the same.

I think the intention is that GC may never actually complete, but
System.gc() must be guaranteed to eventually return.

Roman

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

[Roger Riggs]

Hi Mandy,

Yes, the method returns and something may have happened.

But "or even" is a essential element, because there can be no guarantee that
any reclamation will ever happen, whether or not the method returns.
For example, EpilsonGC.

Thanks, Roger

On 05/30/2019 12:11 PM, Mandy Chung wrote:


On 5/30/19 8:55 AM, Peter Levart wrote:

Yes Roger, this sounds better to me.

Maybe even easier:

"There is no guarantee that this effort will recycle any particular 
number of unused objects, reclaim any particular amount of space, or 
complete before the method returns (or ever)."




+1 and take out "(or ever)"

I agree that this is simpler and clear that there is no guarantee of 
GC completion when this method returns.


Mandy

So, hypothetically, the effort triggered by System.gc() may never 
complete although the method will eventually return. Is this what was 
meant to be said?


Is it necessary to have this (or ever) at the end? What's the purpose 
of it? If the method returns before the attempt completes, there's no 
way to track the attempt to its completion and doesn't matter if it 
eventually completes or not. The completion is already out of bounds 
for this method when it says: "there is not guarantee that the 
attempt completes before the method returns"...


Regards, Peter

On 5/30/19 4:42 PM, Roger Riggs wrote:

Hi,

Though I see your point about gc() eventually returns, the spec 
typically does not
guarantee than any method eventually returns.  That's more a quality 
of service attribute.
The sentence refers to the effort to reclaim space, not the method 
call.


Would it clarify the case to add a qualification to the end of the 
sentence:

" before the method returns or ever."

As a whole:

 * Runs the garbage collector in the Java Virtual Machine.
 * 
 * Calling this method suggests that the Java Virtual Machine
 * expend effort toward recycling unused objects in order to
 * make the memory they currently occupy available for reuse
 * by the Java Virtual Machine.
 * When control returns from the method call, the Java Virtual 
Machine

 * has made a best effort to reclaim space from all unused objects.
 * There is no guarantee that this effort will recycle any 
particular
 * number of unused objects, reclaim any particular amount of 
space,
 * or complete at any particular time, if at all before the 
method returns or ever.


Thanks, Roger

On 05/30/2019 06:27 AM, Roman Kennke wrote:

Any other comments on:
"* Runs the garbage collector in the Java Virtual Machine.
* 
* Calling this method suggests that the Java Virtual Machine
* expend effort toward recycling unused objects in order to
* make the memory they currently occupy available for reuse
* by the Java Virtual Machine.

The following two statements...

1st:
* When control returns from the method call, the Java Virtual 
Machine
* has made a best effort to reclaim space from all discarded 
objects.

2nd:

* There is no guarantee that this effort will recycle any particular
* number of unused objects, reclaim any particular amount of space,
* *or complete* at any particular time, if *at all*.
"
...makes one think that it is OK (by the spec) for System.gc() to 
never

complete.

Could it rather be specified that System.gc() eventually completes?


+1 I was thinking the same.

I think the intention is that GC may never actually complete, but
System.gc() must be guaranteed to eventually return.

Roman

RFR 8212807: tools/jar/multiRelease/Basic.java times out

[Lance Andersen]

Hi all,

The following fix addresses an issue with an occasional timeout for 
tools/jar/multiRelease/Basic.java.

The webrev can be found at: 
http://cr.openjdk.java.net/~lancea/8212807/webrev.00/index.html 



Best,
Lance
 
  

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

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

[Mandy Chung]

On 5/30/19 8:55 AM, Peter Levart wrote:

Yes Roger, this sounds better to me.

Maybe even easier:

"There is no guarantee that this effort will recycle any particular 
number of unused objects, reclaim any particular amount of space, or 
complete before the method returns (or ever)."




+1 and take out "(or ever)"

I agree that this is simpler and clear that there is no guarantee of GC 
completion when this method returns.


Mandy

So, hypothetically, the effort triggered by System.gc() may never 
complete although the method will eventually return. Is this what was 
meant to be said?


Is it necessary to have this (or ever) at the end? What's the purpose 
of it? If the method returns before the attempt completes, there's no 
way to track the attempt to its completion and doesn't matter if it 
eventually completes or not. The completion is already out of bounds 
for this method when it says: "there is not guarantee that the attempt 
completes before the method returns"...


Regards, Peter

On 5/30/19 4:42 PM, Roger Riggs wrote:

Hi,

Though I see your point about gc() eventually returns, the spec 
typically does not
guarantee than any method eventually returns.  That's more a quality 
of service attribute.

The sentence refers to the effort to reclaim space, not the method call.

Would it clarify the case to add a qualification to the end of the 
sentence:

" before the method returns or ever."

As a whole:

 * Runs the garbage collector in the Java Virtual Machine.
 * 
 * Calling this method suggests that the Java Virtual Machine
 * expend effort toward recycling unused objects in order to
 * make the memory they currently occupy available for reuse
 * by the Java Virtual Machine.
 * When control returns from the method call, the Java Virtual 
Machine

 * has made a best effort to reclaim space from all unused objects.
 * There is no guarantee that this effort will recycle any 
particular

 * number of unused objects, reclaim any particular amount of space,
 * or complete at any particular time, if at all before the 
method returns or ever.


Thanks, Roger

On 05/30/2019 06:27 AM, Roman Kennke wrote:

Any other comments on:
"* Runs the garbage collector in the Java Virtual Machine.
* 
* Calling this method suggests that the Java Virtual Machine
* expend effort toward recycling unused objects in order to
* make the memory they currently occupy available for reuse
* by the Java Virtual Machine.

The following two statements...

1st:

* When control returns from the method call, the Java Virtual Machine
* has made a best effort to reclaim space from all discarded objects.

2nd:

* There is no guarantee that this effort will recycle any particular
* number of unused objects, reclaim any particular amount of space,
* *or complete* at any particular time, if *at all*.
"
...makes one think that it is OK (by the spec) for System.gc() to 
never

complete.

Could it rather be specified that System.gc() eventually completes?


+1 I was thinking the same.

I think the intention is that GC may never actually complete, but
System.gc() must be guaranteed to eventually return.

Roman

Re: RFR: 8224974: Implement JEP 352

[Andrew Dinn]

HI Vladimir,

Thank you for reviewing the patch.

On 29/05/2019 20:49, Vladimir Kozlov wrote:
> I tried to test these changes and build failed on all systems except
> Linux because:
> 
> workspace/open/src/hotspot/share/prims/unsafe.cpp:446:3: error: use of
> undeclared identifier 'JNU_ThrowRuntimeException'
>    JNU_ThrowRuntimeException(env, "writeback is not implemented");
>    ^

Apologies for that. I forgot to test this via the submit repo after
cut-and-pasting the checks for OS and CPU support from the map0 native
method to the Unsafe writeback method.

I had to make some tweaks to this code anyway in order to spot an issue
Alan noticed when checking the CSR (the map code was not distinguishing
the precise cases where IOException and UnsupportedOperationException
needed to be thrown and would sometimes have replaced the latter with
the former on Windows/x86_64).

I have uploaded a new webrev which attempts to address the problem.

  http://cr.openjdk.java.net/~adinn/8224974/webrev.03

The test to see whether writeback is enabled on the current cpu_os
combination is now performed in Java from methods Unsafe.writebackMemory
and FileChannelImpl.map, using a call to Unsafe.isWritebackEnabled()

There are also 'belt and braces' checks in the corresponding native
implementation methods:

Unsafe asserts that VM_Version::supports_data_cache_line_writeback()
returns true. The result of this method indicates whether support is
available on both CPU and OS. It returns a value computed using a call
to a new OS-specific method os::supports_map_sync() and, on hardware for
which that is true (AArch64 and x86_64), a test of the relevant CPU
status bits.

FileChannelImpl still relies on conditional compilation to reject calls
on invalid OS/CPU combinations (the VM_VERSION method is not available
for it to call). In the branch for !LINUX || !(AArch64 || amd64) it
throws an InternalError as this path not be reached.

Unfortunately, this latest webrev still fails when uploaded to the
submit repo. The problem seems to be specific to Windows/x86_64 builds.
The branch that failed is JDK-8224974-03. The returned text is appended
after my signature. Would you be able to provide some details about the
errors?

> 
> Also Graal test should be fixed for new intrinsics (add them to
> 'toBeInvestigated' for isJDK13orHigher):
> 
> src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
That has been fixed in the webrev mentioned above.

regards,


Andrew Dinn
---
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander


- 8<  8<  8<  8<  8<  8< ---

BuildId: 2019-05-30-1509485.adinn.source
No failed tests
Tasks Summary

UNABLE_TO_RUN: 18
NOTHING_TO_RUN: 0
KILLED: 0
EXECUTED_WITH_FAILURE: 4
FAILED: 0
HARNESS_ERROR: 0
NA: 0
PASSED: 55
Build

1 Unable to run
windows-x64-install-windows-x64-build-19 Dependency task
failed: mach5...1512-2804499-windows-x64-windows-x64-build-12
4 Executed with failure
windows-x64-windows-x64-build-12 error while building,
return value: 2
windows-x64-debug-windows-x64-build-13 error while building,
return value: 2
windows-x64-open-windows-x64-build-14 error while building,
return value: 2
windows-x64-open-debug-windows-x64-build-15 error while
building, return value: 2

Test

17 Unable to run

tier1-product-open_test_hotspot_jtreg_tier1_common-windows-x64-22
Dependency task failed:
mach5...1512-2804499-windows-x64-windows-x64-build-12

tier1-debug-open_test_hotspot_jtreg_tier1_common-windows-x64-debug-28
Dependency task failed:
mach5...804499-windows-x64-debug-windows-x64-build-13

tier1-debug-open_test_hotspot_jtreg_tier1_compiler_1-windows-x64-debug-31 
Dependency
task failed: mach5...804499-windows-x64-debug-windows-x64-build-13

tier1-debug-open_test_hotspot_jtreg_tier1_compiler_2-windows-x64-debug-34 
Dependency
task failed: mach5...804499-windows-x64-debug-windows-x64-build-13

tier1-debug-open_test_hotspot_jtreg_tier1_compiler_3-windows-x64-debug-37 
Dependency
task failed: mach5...804499-windows-x64-debug-windows-x64-build-13

tier1-debug-open_test_hotspot_jtreg_tier1_compiler_not_xcomp-windows-x64-debug-40
Dependency task failed:
mach5...804499-windows-x64-debug-windows-x64-build-13

tier1-debug-open_test_hotspot_jtreg_tier1_gc_1-windows-x64-debug-43
Dependency task failed:
mach5...804499-windows-x64-debug-windows-x64-build-13

tier1-debug-open_test_hotspot_jtreg_tier1_gc_2-windows-x64-debug-46
Dependency task failed:
mach5...804499-windows-x64-debug-windows-x64-build-13

tier1-product-open_test_hotspot_jtreg_tier1_gc_gcbasher-windows-x64-25

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

[Peter Levart]

Yes Roger, this sounds better to me.

Maybe even easier:

"There is no guarantee that this effort will recycle any particular 
number of unused objects, reclaim any particular amount of space, or 
complete before the method returns (or ever)."


So, hypothetically, the effort triggered by System.gc() may never 
complete although the method will eventually return. Is this what was 
meant to be said?


Is it necessary to have this (or ever) at the end? What's the purpose of 
it? If the method returns before the attempt completes, there's no way 
to track the attempt to its completion and doesn't matter if it 
eventually completes or not. The completion is already out of bounds for 
this method when it says: "there is not guarantee that the attempt 
completes before the method returns"...


Regards, Peter

On 5/30/19 4:42 PM, Roger Riggs wrote:

Hi,

Though I see your point about gc() eventually returns, the spec 
typically does not
guarantee than any method eventually returns.  That's more a quality 
of service attribute.

The sentence refers to the effort to reclaim space, not the method call.

Would it clarify the case to add a qualification to the end of the 
sentence:

" before the method returns or ever."

As a whole:

 * Runs the garbage collector in the Java Virtual Machine.
 * 
 * Calling this method suggests that the Java Virtual Machine
 * expend effort toward recycling unused objects in order to
 * make the memory they currently occupy available for reuse
 * by the Java Virtual Machine.
 * When control returns from the method call, the Java Virtual Machine
 * has made a best effort to reclaim space from all unused objects.
 * There is no guarantee that this effort will recycle any particular
 * number of unused objects, reclaim any particular amount of space,
 * or complete at any particular time, if at all before the 
method returns or ever.


Thanks, Roger

On 05/30/2019 06:27 AM, Roman Kennke wrote:

Any other comments on:
"* Runs the garbage collector in the Java Virtual Machine.
* 
* Calling this method suggests that the Java Virtual Machine
* expend effort toward recycling unused objects in order to
* make the memory they currently occupy available for reuse
* by the Java Virtual Machine.

The following two statements...

1st:

* When control returns from the method call, the Java Virtual Machine
* has made a best effort to reclaim space from all discarded objects.

2nd:

* There is no guarantee that this effort will recycle any particular
* number of unused objects, reclaim any particular amount of space,
* *or complete* at any particular time, if *at all*.
"

...makes one think that it is OK (by the spec) for System.gc() to never
complete.

Could it rather be specified that System.gc() eventually completes?


+1 I was thinking the same.

I think the intention is that GC may never actually complete, but
System.gc() must be guaranteed to eventually return.

Roman

Re: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

[Roger Riggs]

Hi,

A release note would be a good idea to explain the change in behavior of 
SMART mode,

I added label "release-note=yes"

Regards, Roger

On 05/30/2019 09:50 AM, Roger Riggs wrote:

Hi,

The behavior is within the spec and seems more just like a bug in the 
implementation.

Also, an exception was thrown but it was for the wrong reason.

$.02, Roger


On 05/29/2019 06:55 PM, naoto.s...@oracle.com wrote:

Hi Joe,

Right, I will file a corresponding CSR.

Naoto

On 5/29/19 3:51 PM, Joseph D. Darcy wrote:

Hi Naoto,

Should this bug get a CSR for the behavioral change?

Cheers,

-Joe

On 5/29/2019 2:12 PM, naoto.s...@oracle.com wrote:

Hi,

Please review the fix for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8223773

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8223773/webrev.00/

Checking the range of HourOfAmPm with the range of AmPmOfDay is 
apparently incorrect. Fixing it will change the behavior of parsing 
with SMART resolver style to throw a DateTimeParseException. This 
is a change in which an app will start to see an exception with 
incorrect data, but that is what should be in the first place.


Naoto

Re: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

[naoto . sato]

Thanks, Roger.

On 5/30/19 6:55 AM, Roger Riggs wrote:

Hi Naoto,

This looks ok.
Typically, it is not necessary to check the exception message text.


I just wanted to make sure that the thrown DateTimeParseException is 
none other than the exception that is expected. There seems no other way 
to check that.


Naoto



Thanks, Roger

On 05/29/2019 05:21 PM, Lance Andersen wrote:

Hi Naoto,

This is OK.

Could you please add an @summary as it is missing so that we are 
consistent with other tests.


No need to spin a webrev again though


Best
Lance

On May 29, 2019, at 5:12 PM, naoto.s...@oracle.com wrote:

Hi,

Please review the fix for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8223773

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8223773/webrev.00/

Checking the range of HourOfAmPm with the range of AmPmOfDay is 
apparently incorrect. Fixing it will change the behavior of parsing 
with SMART resolver style to throw a DateTimeParseException. This is 
a change in which an app will start to see an exception with 
incorrect data, but that is what should be in the first place.


Naoto

  
   

  Lance 
Andersen| Principal Member of Technical Staff | +1.781.442.2037

Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com 

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

[Roger Riggs]

Hi,

Though I see your point about gc() eventually returns, the spec 
typically does not
guarantee than any method eventually returns.  That's more a quality of 
service attribute.

The sentence refers to the effort to reclaim space, not the method call.

Would it clarify the case to add a qualification to the end of the sentence:
" before the method returns or ever."

As a whole:

 * Runs the garbage collector in the Java Virtual Machine.
 * 
 * Calling this method suggests that the Java Virtual Machine
 * expend effort toward recycling unused objects in order to
 * make the memory they currently occupy available for reuse
 * by the Java Virtual Machine.
 * When control returns from the method call, the Java Virtual Machine
 * has made a best effort to reclaim space from all unused objects.
 * There is no guarantee that this effort will recycle any particular
 * number of unused objects, reclaim any particular amount of space,
 * or complete at any particular time, if at all before the 
method returns or ever.


Thanks, Roger

On 05/30/2019 06:27 AM, Roman Kennke wrote:



Any other comments on:
"* Runs the garbage collector in the Java Virtual Machine.
* 
* Calling this method suggests that the Java Virtual Machine
* expend effort toward recycling unused objects in order to
* make the memory they currently occupy available for reuse
* by the Java Virtual Machine.

The following two statements...

1st:

* When control returns from the method call, the Java Virtual Machine
* has made a best effort to reclaim space from all discarded objects.

2nd:

* There is no guarantee that this effort will recycle any particular
* number of unused objects, reclaim any particular amount of space,
* *or complete* at any particular time, if *at all*.
"

...makes one think that it is OK (by the spec) for System.gc() to never
complete.

Could it rather be specified that System.gc() eventually completes?


+1 I was thinking the same.

I think the intention is that GC may never actually complete, but
System.gc() must be guaranteed to eventually return.

Roman

Re: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

[Roger Riggs]

Hi Naoto,

This looks ok.
Typically, it is not necessary to check the exception message text.

Thanks, Roger

On 05/29/2019 05:21 PM, Lance Andersen wrote:

Hi Naoto,

This is OK.

Could you please add an @summary as it is missing so that we are consistent 
with other tests.

No need to spin a webrev again though


Best
Lance

On May 29, 2019, at 5:12 PM, naoto.s...@oracle.com wrote:

Hi,

Please review the fix for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8223773

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8223773/webrev.00/

Checking the range of HourOfAmPm with the range of AmPmOfDay is apparently 
incorrect. Fixing it will change the behavior of parsing with SMART resolver 
style to throw a DateTimeParseException. This is a change in which an app will 
start to see an exception with incorrect data, but that is what should be in 
the first place.

Naoto

  
   

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

Re: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

[Roger Riggs]

Hi,

The behavior is within the spec and seems more just like a bug in the 
implementation.

Also, an exception was thrown but it was for the wrong reason.

$.02, Roger


On 05/29/2019 06:55 PM, naoto.s...@oracle.com wrote:

Hi Joe,

Right, I will file a corresponding CSR.

Naoto

On 5/29/19 3:51 PM, Joseph D. Darcy wrote:

Hi Naoto,

Should this bug get a CSR for the behavioral change?

Cheers,

-Joe

On 5/29/2019 2:12 PM, naoto.s...@oracle.com wrote:

Hi,

Please review the fix for the following issue:

https://bugs.openjdk.java.net/browse/JDK-8223773

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8223773/webrev.00/

Checking the range of HourOfAmPm with the range of AmPmOfDay is 
apparently incorrect. Fixing it will change the behavior of parsing 
with SMART resolver style to throw a DateTimeParseException. This is 
a change in which an app will start to see an exception with 
incorrect data, but that is what should be in the first place.


Naoto

jpackage EA Build Question Followup

[Andrew Auclair]

Hi,

I had sent in a question in January about the jpackage (see below link and 
email). Due to issues with our email filtering service I did not see the 
response and wandered upon it last night. So apologies in advance for such a 
long time between messages, I am now a subscriber and hopefully the email 
filtering issue is fixed properly by IT.

I'm experimenting with build 49 of jpackage in the JDK 13 EA. I'm still not 
sure if what I want to do is currently possible. I would like to execute 
"jpackage create-app-image" with all my info for a non-modular application 
image (input, output, name, icon, jar, main class). I would then like to move 
the cfg and jar up one directory so that the applauncher.dll, cfg, exe, ico and 
jar are all in the same folder. Then rename the cfg and exe, we have a standard 
exe name that I don't want to be used by windows as the app name (this all 
works fine as is as long as the cfg and exe names match). If I'm able to 
reorder the generated files from create-app-image, I can install our native 64 
bit C++ apps in the same folder and share the 64 bit dll's between all the C++ 
and Java applications. Lots of moving parts, hopefully the layout is clear in 
my initial message, I've had a hell of a time explaining this to my coworkers.

One thing I wanted to clarify from the previous thread is that we do not use 
the installer portion of javapackager, we use a different installer, with 
javapackager we just use the "-native image" option. I would like to also note 
that we have a fairly large install which has about 50 executables that are 
installed, including 6 java applications, so minimizing duplication helps save 
space and install time.

We are also in the process of porting several dozen more of these applications 
to 64 bit which makes that issue a little more important to sort out.

Previous thread: 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057775.html



Thanks again for any help, much appreciated!



interesting ...



I would think I would want to do this by first building the app image,

then moving the pieces around before building the installer.



But that doesn't work:



1.) the installer expects to find a "runtime" sub-directory of the

app-image directory.  This could be considered a bug, and I will fix it,

but it can be worked around by creating an extra empty "runtime" subdir

in the app image.



2.) the installer needs to find the app itself (for installing shortcuts

to it).  When using an app-image it determines the app name by looking

for a cfg file in the "app" sub-directory of the app-image.  Then given

the name, it looks for executable and ico of that name in the top level

app-image directory.



I suspect I could work around even that by using drop-in resources with

the new --resource-dir arg but not sure.  I will look into it and get

back to you. (this is significantly different since JDK-8215515

 , so even if I can

work around this in that way - you would have to wait for the next EA drop).



The bigger question is should there be some way to express the install

root differently from the app root ?



/Andy

Original Email Below


We are currently using JDK 10 with javapackager and have looked at the Early 
Access build available for the jpackage enhancement. We have a question about 
an issue we are currently experiencing with javapackager, which appears to have 
the same behavior in jpackage.

Background:

In our install we have several 32 bit C++ applications, some 64 bit C++ 
applications and 64 bit JDK 10 Java applications. The 64 bit C++ and Java 
applications both use a set of C++ DLLs. This has forced us to place the 64 bit 
C++ applications in the app folder that the javapackager creates. Jpackage 
appears to create the same app folder.

Our folder structure is outlined below. The executable generated by 
javapackager appears to be hardcoded to use the app/*.cfg files. We would like 
the ability to place the contents of the app folder directly in our bin64 
folder along with the exe and ico that are generated.

Install / bin64 / app / native64.dll
Install / bin64 / app / cpp64bitapp.exe
Install / bin64 / app / javaapp.jar
Install / bin64 / app / javaapp.cfg
Install / bin64 / javaapp.exe
Install / bin64 / runtime <-- JRE 10 runtime
Install / native.dll
Install / cpp32bitapp.exe

Question:
Is it possible for us to rename or change the app folder, or to place the 
contents of the app folder in the parent directory?


Andrew Auclair
Software Engineer
Tactical Communications Group
A Curtiss-Wright Company
2 Highwood Drive, Building 2, Suite 200
Tewksbury, MA  01876-1157

Direct: 978-654-4849   Fax: 978-654-4801
www.g2tcg.com

Re: RFR 8224946: jrtfs URI to Path and Path to URI conversions are wrong

[Alan Bateman]

On 30/05/2019 11:55, Sundararajan Athijegannathan wrote:

Please review.

Bug: https://bugs.openjdk.java.net/browse/JDK-8224946
Webrev: https://cr.openjdk.java.net/~sundar/8224946/webrev.00/

Earlier attempt for the fix of the same bug resulted in test failures 
and so the fix was reverted. The current webrev has the same fix - but 
fixes 2 jlink tests that used wrong jrt: URI. With this change, 
internal mach5 test run is fine.

The update to the two jlink tests missed in the original push looks fine.

-Alan

RFR 8224946: jrtfs URI to Path and Path to URI conversions are wrong

[Sundararajan Athijegannathan]

Please review.

Bug: https://bugs.openjdk.java.net/browse/JDK-8224946
Webrev: https://cr.openjdk.java.net/~sundar/8224946/webrev.00/

Earlier attempt for the fix of the same bug resulted in test failures 
and so the fix was reverted. The current webrev has the same fix - but 
fixes 2 jlink tests that used wrong jrt: URI. With this change, internal 
mach5 test run is fine.


Related email threads of earlier fix attempt & reversal:

https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060434.html
https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060459.html

Thanks,
-Sundar

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

[Roman Kennke]

>> Any other comments on:
>> "* Runs the garbage collector in the Java Virtual Machine.
>> * 
>> * Calling this method suggests that the Java Virtual Machine
>> * expend effort toward recycling unused objects in order to
>> * make the memory they currently occupy available for reuse
>> * by the Java Virtual Machine.
> 
> The following two statements...
> 
> 1st:
>> * When control returns from the method call, the Java Virtual Machine
>> * has made a best effort to reclaim space from all discarded objects.
> 
> 2nd:
>> * There is no guarantee that this effort will recycle any particular
>> * number of unused objects, reclaim any particular amount of space,
>> * *or complete* at any particular time, if *at all*.
>> " 
> 
> ...makes one think that it is OK (by the spec) for System.gc() to never
> complete.
> 
> Could it rather be specified that System.gc() eventually completes?
> 

+1 I was thinking the same.

I think the intention is that GC may never actually complete, but
System.gc() must be guaranteed to eventually return.

Roman

Re: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

[Stephen Colebourne]

+1

On Wed, 29 May 2019, 22:13 ,  wrote:

> Hi,
>
> Please review the fix for the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8223773
>
> The proposed changeset is located at:
>
> https://cr.openjdk.java.net/~naoto/8223773/webrev.00/
>
> Checking the range of HourOfAmPm with the range of AmPmOfDay is
> apparently incorrect. Fixing it will change the behavior of parsing with
> SMART resolver style to throw a DateTimeParseException. This is a change
> in which an app will start to see an exception with incorrect data, but
> that is what should be in the first place.
>
> Naoto
>