Re: RFR: JDK-8080511 - Refresh of jimage support

2015-09-16 Thread Sergey Bylokhov 

On 24.07.15 20:17, Jean-Francois Denise wrote:

Hi,
you need to prefix your path with /modules, so “/modules/java.desktop”.

Thanks. It works.

JF


On 24 Jul 2015, at 19:10, Sergey Bylokhov  wrote:


After the latest merge I got some issue, I assume related to this fix.
Can somebody take a look to this code:

import java.net.URI;
import java.nio.file.*;
import java.nio.file.attribute.BasicFileAttributes;

public class JRTFileSystemError {

public static void main(final String[] args) throws Exception {
FileSystem fs = FileSystems.getFileSystem(URI.create("jrt:/"));
Files.walkFileTree(fs.getPath("/java.desktop"), new 
SimpleFileVisitor() {
@Override
public FileVisitResult visitFile(Path file,
 BasicFileAttributes attrs) {
return FileVisitResult.CONTINUE;
}
});
}
}

It fails with "Exception in thread "main" java.nio.file.NoSuchFileException: 
/java.desktop".
Bur previously it works correctly. Can somebody confirm this is an issue in the 
test(and how to change it) or in jdk?
It seems that IntelliJ also broken in some way so it cannot take classes from 
the jdk9 after this fix. probably they should update jrt-fs.jar?


On 23.06.15 19:08, Jean-Francois Denise wrote:

Hi,
an updated webrev that takes into account reviews. In addition the hotspot 
tests have been reworked following Christian Tornqvist suggestions.

top: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-top/
langtools: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-langtools/
hotspot: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-hotspot/
jdk: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-jdk/

Testing:
JCK(s) tests are passing (ran only on Mac OS)
Hotspot tests are passing (All platforms)
Java PIT tests are passing (All platforms). Ran once on 
https://bugs.openjdk.java.net/browse/JDK-8129592

Thanks.
JF

On 23 Jun 2015, at 14:10, Jean-Francois Denise 
 wrote:


Hi Paul,

On 19 Jun 2015, at 16:39, Paul Sandoz  wrote:


On Jun 18, 2015, at 2:08 AM, Jim Laskey (Oracle)  
wrote:


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

This is an long overdue refresh of the jimage support in the JDK9-dev repo.  
This includes native support for reading jimage files, improved jrt-fs (java 
runtime file system) support for retrieving modules and packages from the 
runtime, and improved performance for langtools in the presence of jrt-fs.

http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 

http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk 


I eyeballed the JDK changes. Just two thing:

make/src/classes/build/tools/module/ModuleArchive.java

90 @Override
91 public Stream entries() {
92 List entries = new ArrayList<>();
93 try {
94 if (classes != null)
95 Files.walk(classes)
96 .sorted()
97 .filter(p -> !Files.isDirectory(p)
98 && 
!classes.relativize(p).toString().startsWith("_the.")
99 && 
!classes.relativize(p).toString().equals("javac_state"))
100 .map(p -> toEntry(p, classes, 
EntryType.CLASS_OR_RESOURCE))
101 .forEach(entries::add);
102 if (cmds != null)
103 Files.walk(cmds)
104 .filter(p -> !Files.isDirectory(p))
105 .map(p -> toEntry(p, cmds, EntryType.NATIVE_CMD))
106 .forEach(entries::add);
107 if (libs != null)
108 Files.walk(libs)
109 .filter(p -> !Files.isDirectory(p))
110 .map(p -> toEntry(p, libs, EntryType.NATIVE_LIB))
111 .forEach(entries::add);
112 if (configs != null)
113 Files.walk(configs)
114 .filter(p -> !Files.isDirectory(p))
115 .map(p -> toEntry(p, configs, EntryType.CONFIG))
116 .forEach(entries::add);
117 } catch (IOException ioe) {
118 throw new UncheckedIOException(ioe);
119 }
120 return entries.stream();
121 }

You can use collect(toList())

==> OK collect used. In addition, filter first then sort, tryWithResource for 4 
Files stream.


In general the contract for Archive.entries probably has to say the stream 
needs to be closed after use since it might cover lazy I/O based resources, so 
callers will need to use a try-with-resources block.

==> Added a note in javadoc, implemented explicit close for non lazy streams, 
added missing tryWithResource. Added a

Re: RFR: JDK-8080511 - Refresh of jimage support

2015-09-16 Thread Sergey Bylokhov 

After the latest merge I got some issue, I assume related to this fix.
Can somebody take a look to this code:

import java.net.URI;
import java.nio.file.*;
import java.nio.file.attribute.BasicFileAttributes;

public class JRTFileSystemError {

public static void main(final String[] args) throws Exception {
FileSystem fs = FileSystems.getFileSystem(URI.create("jrt:/"));
Files.walkFileTree(fs.getPath("/java.desktop"), new 
SimpleFileVisitor() {

@Override
public FileVisitResult visitFile(Path file,
 BasicFileAttributes attrs) {
return FileVisitResult.CONTINUE;
}
});
}
}

It fails with "Exception in thread "main" 
java.nio.file.NoSuchFileException: /java.desktop".
Bur previously it works correctly. Can somebody confirm this is an issue 
in the test(and how to change it) or in jdk?
It seems that IntelliJ also broken in some way so it cannot take classes 
from the jdk9 after this fix. probably they should update jrt-fs.jar?



On 23.06.15 19:08, Jean-Francois Denise wrote:

Hi,
an updated webrev that takes into account reviews. In addition the hotspot 
tests have been reworked following Christian Tornqvist suggestions.

top: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-top/
langtools: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-langtools/
hotspot: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-hotspot/
jdk: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-jdk/

Testing:
JCK(s) tests are passing (ran only on Mac OS)
Hotspot tests are passing (All platforms)
Java PIT tests are passing (All platforms). Ran once on 
https://bugs.openjdk.java.net/browse/JDK-8129592

Thanks.
JF

On 23 Jun 2015, at 14:10, Jean-Francois Denise 
 wrote:


Hi Paul,

On 19 Jun 2015, at 16:39, Paul Sandoz  wrote:


On Jun 18, 2015, at 2:08 AM, Jim Laskey (Oracle)  
wrote:


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

This is an long overdue refresh of the jimage support in the JDK9-dev repo.  
This includes native support for reading jimage files, improved jrt-fs (java 
runtime file system) support for retrieving modules and packages from the 
runtime, and improved performance for langtools in the presence of jrt-fs.

http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 

http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk 


I eyeballed the JDK changes. Just two thing:

make/src/classes/build/tools/module/ModuleArchive.java

90 @Override
91 public Stream entries() {
92 List entries = new ArrayList<>();
93 try {
94 if (classes != null)
95 Files.walk(classes)
96 .sorted()
97 .filter(p -> !Files.isDirectory(p)
98 && 
!classes.relativize(p).toString().startsWith("_the.")
99 && 
!classes.relativize(p).toString().equals("javac_state"))
100 .map(p -> toEntry(p, classes, 
EntryType.CLASS_OR_RESOURCE))
101 .forEach(entries::add);
102 if (cmds != null)
103 Files.walk(cmds)
104 .filter(p -> !Files.isDirectory(p))
105 .map(p -> toEntry(p, cmds, EntryType.NATIVE_CMD))
106 .forEach(entries::add);
107 if (libs != null)
108 Files.walk(libs)
109 .filter(p -> !Files.isDirectory(p))
110 .map(p -> toEntry(p, libs, EntryType.NATIVE_LIB))
111 .forEach(entries::add);
112 if (configs != null)
113 Files.walk(configs)
114 .filter(p -> !Files.isDirectory(p))
115 .map(p -> toEntry(p, configs, EntryType.CONFIG))
116 .forEach(entries::add);
117 } catch (IOException ioe) {
118 throw new UncheckedIOException(ioe);
119 }
120 return entries.stream();
121 }

You can use collect(toList())

==> OK collect used. In addition, filter first then sort, tryWithResource for 4 
Files stream.


In general the contract for Archive.entries probably has to say the stream 
needs to be closed after use since it might cover lazy I/O based resources, so 
callers will need to use a try-with-resources block.

==> Added a note in javadoc, implemented explicit close for non lazy streams, 
added missing tryWithResource. Added a comment on what should be done in 
ModuleArchive to keep laziness.

Paul.

Thanks.


http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot

Re: RFR: JDK-8080511 - Refresh of jimage support

2015-08-21 Thread Jim Laskey (Oracle) 
The API is still a work in progress.  Stay tuned.


 On Aug 21, 2015, at 4:37 AM, deven you ydwch...@gmail.com wrote:
 
 Hi Jim,
 
 I have one question. I see Hotspot already supports in decompressing 
 compressed resource and there is a method newCompressedResource in 
 jdk/src/java.base/share/classes/jdk/internal/jimage/ResourcePool.java
  for creating a compressed resource but I did not find any API uses this 
 method and not find there is any compressed resource in bootmodules.jimage.
 
 What I want to know is 1. if I want to compress one resource in a certain 
 module what are the steps?  I assume I need write some code which first gets 
 the plugin and compressed buffer and then pass to newCompressedResource? If 
 there is some compressed zip or jar files in a certain module how the 
 relevant code deals with this condition?
   2. Any plan that bootmodules.jiamge or 
 other jimage files will contain such compressed resources?
 
 Thanks a lot!
 
 2015-06-18 8:08 GMT+08:00 Jim Laskey (Oracle) james.las...@oracle.com 
 mailto:james.las...@oracle.com:
 https://bugs.openjdk.java.net/browse/JDK-8080511 
 https://bugs.openjdk.java.net/browse/JDK-8080511
 
 This is an long overdue refresh of the jimage support in the JDK9-dev repo.  
 This includes native support for reading jimage files, improved jrt-fs (java 
 runtime file system) support for retrieving modules and packages from the 
 runtime, and improved performance for langtools in the presence of jrt-fs.
 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools
 
 
 Details:
 
 - jrt-fs provides access, via the nio FileSystem API, to the classes in a 
 .jimage file, organized by module or by package.
 - Shared code for jimage support converted to native.  Currently residing in 
 hotspot, but will migrate to it’s own jdk library 
 https://bugs.openjdk.java.net/browse/JDK-8087181 
 https://bugs.openjdk.java.net/browse/JDK-8087181 
 https://bugs.openjdk.java.net/browse/JDK-8087181 
 https://bugs.openjdk.java.net/browse/JDK-8087181
 - A new archive abstraction for class/resource sources.
 - java based implementation layer for jimage reading to allow backport to 
 JDK8 (jrt-fs.jar - IDE support.)
 - JNI support for jimage into hotspot.
 - White box tests written to exercise native jimage support.

Re: RFR: JDK-8080511 - Refresh of jimage support

2015-07-27 Thread A. Sundararajan 
Please see also: 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-July/004403.html


-Sundar

On Friday 24 July 2015 10:47 PM, Jean-Francois Denise wrote:

Hi,
you need to prefix your path with /modules, so “/modules/java.desktop”.
JF


On 24 Jul 2015, at 19:10, Sergey Bylokhov sergey.bylok...@oracle.com wrote:


After the latest merge I got some issue, I assume related to this fix.
Can somebody take a look to this code:

import java.net.URI;
import java.nio.file.*;
import java.nio.file.attribute.BasicFileAttributes;

public class JRTFileSystemError {

public static void main(final String[] args) throws Exception {
FileSystem fs = FileSystems.getFileSystem(URI.create(jrt:/));
Files.walkFileTree(fs.getPath(/java.desktop), new 
SimpleFileVisitorPath() {
@Override
public FileVisitResult visitFile(Path file,
 BasicFileAttributes attrs) {
return FileVisitResult.CONTINUE;
}
});
}
}

It fails with Exception in thread main java.nio.file.NoSuchFileException: 
/java.desktop.
Bur previously it works correctly. Can somebody confirm this is an issue in the 
test(and how to change it) or in jdk?
It seems that IntelliJ also broken in some way so it cannot take classes from 
the jdk9 after this fix. probably they should update jrt-fs.jar?


On 23.06.15 19:08, Jean-Francois Denise wrote:

Hi,
an updated webrev that takes into account reviews. In addition the hotspot 
tests have been reworked following Christian Tornqvist suggestions.

top: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-top/
langtools: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-langtools/
hotspot: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-hotspot/
jdk: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-jdk/

Testing:
JCK(s) tests are passing (ran only on Mac OS)
Hotspot tests are passing (All platforms)
Java PIT tests are passing (All platforms). Ran once on 
https://bugs.openjdk.java.net/browse/JDK-8129592

Thanks.
JF

On 23 Jun 2015, at 14:10, Jean-Francois Denise 
jean-francois.den...@oracle.com wrote:


Hi Paul,

On 19 Jun 2015, at 16:39, Paul Sandoz paul.san...@oracle.com wrote:


On Jun 18, 2015, at 2:08 AM, Jim Laskey (Oracle) james.las...@oracle.com 
wrote:


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

This is an long overdue refresh of the jimage support in the JDK9-dev repo.  
This includes native support for reading jimage files, improved jrt-fs (java 
runtime file system) support for retrieving modules and packages from the 
runtime, and improved performance for langtools in the presence of jrt-fs.

http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 
http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top
http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk 
http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk

I eyeballed the JDK changes. Just two thing:

make/src/classes/build/tools/module/ModuleArchive.java

90 @Override
91 public StreamEntry entries() {
92 ListEntry entries = new ArrayList();
93 try {
94 if (classes != null)
95 Files.walk(classes)
96 .sorted()
97 .filter(p - !Files.isDirectory(p)
98  
!classes.relativize(p).toString().startsWith(_the.)
99  
!classes.relativize(p).toString().equals(javac_state))
100 .map(p - toEntry(p, classes, 
EntryType.CLASS_OR_RESOURCE))
101 .forEach(entries::add);
102 if (cmds != null)
103 Files.walk(cmds)
104 .filter(p - !Files.isDirectory(p))
105 .map(p - toEntry(p, cmds, EntryType.NATIVE_CMD))
106 .forEach(entries::add);
107 if (libs != null)
108 Files.walk(libs)
109 .filter(p - !Files.isDirectory(p))
110 .map(p - toEntry(p, libs, EntryType.NATIVE_LIB))
111 .forEach(entries::add);
112 if (configs != null)
113 Files.walk(configs)
114 .filter(p - !Files.isDirectory(p))
115 .map(p - toEntry(p, configs, EntryType.CONFIG))
116 .forEach(entries::add);
117 } catch (IOException ioe) {
118 throw new UncheckedIOException(ioe);
119 }
120 return entries.stream();
121 }

You can use collect(toList())

== OK collect used. In addition, filter first then sort, tryWithResource for 4 
Files stream.


In general the contract for Archive.entries probably has to say the stream 
needs to be closed after use since it might cover lazy I/O based resources, so 
callers will need to use a try-with-resources block.

== Added a note in javadoc, implemented explicit close

Re: RFR: JDK-8080511 - Refresh of jimage support

2015-07-24 Thread Jean-Francois Denise 
Hi,
you need to prefix your path with /modules, so “/modules/java.desktop”.
JF


On 24 Jul 2015, at 19:10, Sergey Bylokhov sergey.bylok...@oracle.com wrote:

 After the latest merge I got some issue, I assume related to this fix.
 Can somebody take a look to this code:
 
 import java.net.URI;
 import java.nio.file.*;
 import java.nio.file.attribute.BasicFileAttributes;
 
 public class JRTFileSystemError {
 
public static void main(final String[] args) throws Exception {
FileSystem fs = FileSystems.getFileSystem(URI.create(jrt:/));
Files.walkFileTree(fs.getPath(/java.desktop), new 
 SimpleFileVisitorPath() {
@Override
public FileVisitResult visitFile(Path file,
 BasicFileAttributes attrs) {
return FileVisitResult.CONTINUE;
}
});
}
 }
 
 It fails with Exception in thread main java.nio.file.NoSuchFileException: 
 /java.desktop.
 Bur previously it works correctly. Can somebody confirm this is an issue in 
 the test(and how to change it) or in jdk?
 It seems that IntelliJ also broken in some way so it cannot take classes from 
 the jdk9 after this fix. probably they should update jrt-fs.jar?
 
 
 On 23.06.15 19:08, Jean-Francois Denise wrote:
 Hi,
 an updated webrev that takes into account reviews. In addition the hotspot 
 tests have been reworked following Christian Tornqvist suggestions.
 
 top: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-top/
 langtools: 
 http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-langtools/
 hotspot: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-hotspot/
 jdk: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-jdk/
 
 Testing:
 JCK(s) tests are passing (ran only on Mac OS)
 Hotspot tests are passing (All platforms)
 Java PIT tests are passing (All platforms). Ran once on 
 https://bugs.openjdk.java.net/browse/JDK-8129592
 
 Thanks.
 JF
 
 On 23 Jun 2015, at 14:10, Jean-Francois Denise 
 jean-francois.den...@oracle.com wrote:
 
 Hi Paul,
 
 On 19 Jun 2015, at 16:39, Paul Sandoz paul.san...@oracle.com wrote:
 
 On Jun 18, 2015, at 2:08 AM, Jim Laskey (Oracle) james.las...@oracle.com 
 wrote:
 
 https://bugs.openjdk.java.net/browse/JDK-8080511
 
 This is an long overdue refresh of the jimage support in the JDK9-dev 
 repo.  This includes native support for reading jimage files, improved 
 jrt-fs (java runtime file system) support for retrieving modules and 
 packages from the runtime, and improved performance for langtools in the 
 presence of jrt-fs.
 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk
 I eyeballed the JDK changes. Just two thing:
 
 make/src/classes/build/tools/module/ModuleArchive.java
 
 90 @Override
 91 public StreamEntry entries() {
 92 ListEntry entries = new ArrayList();
 93 try {
 94 if (classes != null)
 95 Files.walk(classes)
 96 .sorted()
 97 .filter(p - !Files.isDirectory(p)
 98  
 !classes.relativize(p).toString().startsWith(_the.)
 99  
 !classes.relativize(p).toString().equals(javac_state))
 100 .map(p - toEntry(p, classes, 
 EntryType.CLASS_OR_RESOURCE))
 101 .forEach(entries::add);
 102 if (cmds != null)
 103 Files.walk(cmds)
 104 .filter(p - !Files.isDirectory(p))
 105 .map(p - toEntry(p, cmds, 
 EntryType.NATIVE_CMD))
 106 .forEach(entries::add);
 107 if (libs != null)
 108 Files.walk(libs)
 109 .filter(p - !Files.isDirectory(p))
 110 .map(p - toEntry(p, libs, 
 EntryType.NATIVE_LIB))
 111 .forEach(entries::add);
 112 if (configs != null)
 113 Files.walk(configs)
 114 .filter(p - !Files.isDirectory(p))
 115 .map(p - toEntry(p, configs, 
 EntryType.CONFIG))
 116 .forEach(entries::add);
 117 } catch (IOException ioe) {
 118 throw new UncheckedIOException(ioe);
 119 }
 120 return entries.stream();
 121 }
 
 You can use collect(toList())
 == OK collect used. In addition, filter first then sort, tryWithResource 
 for 4 Files stream.
 
 In general the contract for Archive.entries probably has to say the stream 
 needs to be closed after use since it might cover lazy I/O based 
 resources, so callers will need to use a try-with-resources block.
 == Added a note in javadoc, implemented explicit close for non lazy 
 streams, added missing

Re: RFR: JDK-8080511 - Refresh of jimage support

2015-06-23 Thread Jean-Francois Denise 
Hi,
an updated webrev that takes into account reviews. In addition the hotspot 
tests have been reworked following Christian Tornqvist suggestions.

top: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-top/
langtools: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-langtools/
hotspot: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-hotspot/
jdk: http://cr.openjdk.java.net/~jfdenise/hs-rt-jimage.3/webrev-jdk/

Testing:
JCK(s) tests are passing (ran only on Mac OS)
Hotspot tests are passing (All platforms)
Java PIT tests are passing (All platforms). Ran once on 
https://bugs.openjdk.java.net/browse/JDK-8129592

Thanks.
JF

On 23 Jun 2015, at 14:10, Jean-Francois Denise 
jean-francois.den...@oracle.com wrote:

 Hi Paul,
 
 On 19 Jun 2015, at 16:39, Paul Sandoz paul.san...@oracle.com wrote:
 
 
 On Jun 18, 2015, at 2:08 AM, Jim Laskey (Oracle) james.las...@oracle.com 
 wrote:
 
 https://bugs.openjdk.java.net/browse/JDK-8080511
 
 This is an long overdue refresh of the jimage support in the JDK9-dev repo. 
  This includes native support for reading jimage files, improved jrt-fs 
 (java runtime file system) support for retrieving modules and packages from 
 the runtime, and improved performance for langtools in the presence of 
 jrt-fs.
 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk
 
 I eyeballed the JDK changes. Just two thing:
 
 make/src/classes/build/tools/module/ModuleArchive.java
 
 90 @Override
 91 public StreamEntry entries() {
 92 ListEntry entries = new ArrayList();
 93 try {
 94 if (classes != null)
 95 Files.walk(classes)
 96 .sorted()
 97 .filter(p - !Files.isDirectory(p)
 98  
 !classes.relativize(p).toString().startsWith(_the.)
 99  
 !classes.relativize(p).toString().equals(javac_state))
 100 .map(p - toEntry(p, classes, 
 EntryType.CLASS_OR_RESOURCE))
 101 .forEach(entries::add);
 102 if (cmds != null)
 103 Files.walk(cmds)
 104 .filter(p - !Files.isDirectory(p))
 105 .map(p - toEntry(p, cmds, EntryType.NATIVE_CMD))
 106 .forEach(entries::add);
 107 if (libs != null)
 108 Files.walk(libs)
 109 .filter(p - !Files.isDirectory(p))
 110 .map(p - toEntry(p, libs, EntryType.NATIVE_LIB))
 111 .forEach(entries::add);
 112 if (configs != null)
 113 Files.walk(configs)
 114 .filter(p - !Files.isDirectory(p))
 115 .map(p - toEntry(p, configs, EntryType.CONFIG))
 116 .forEach(entries::add);
 117 } catch (IOException ioe) {
 118 throw new UncheckedIOException(ioe);
 119 }
 120 return entries.stream();
 121 }
 
 You can use collect(toList())
 
 == OK collect used. In addition, filter first then sort, tryWithResource for 
 4 Files stream.
 
 
 In general the contract for Archive.entries probably has to say the stream 
 needs to be closed after use since it might cover lazy I/O based resources, 
 so callers will need to use a try-with-resources block.
 
 == Added a note in javadoc, implemented explicit close for non lazy streams, 
 added missing tryWithResource. Added a comment on what should be done in 
 ModuleArchive to keep laziness.
 
 Paul.
 
 Thanks.
 
 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools
 
 
 Details:
 
 - jrt-fs provides access, via the nio FileSystem API, to the classes in a 
 .jimage file, organized by module or by package.
 - Shared code for jimage support converted to native.  Currently residing 
 in hotspot, but will migrate to it’s own jdk library 
 https://bugs.openjdk.java.net/browse/JDK-8087181 
 https://bugs.openjdk.java.net/browse/JDK-8087181
 - A new archive abstraction for class/resource sources.
 - java based implementation layer for jimage reading to allow backport to 
 JDK8 (jrt-fs.jar - IDE support.)
 - JNI support for jimage into hotspot.
 - White box tests written to exercise native jimage support.

Re: RFR: JDK-8080511 - Refresh of jimage support

2015-06-23 Thread Jean-Francois Denise 
Hi Karen,
On 18 Jun 2015, at 16:59, Karen Kinnear karen.kinn...@oracle.com wrote:

 Code review for the hotspot component:
 
 Thank you for the cleanups to jvm.cpp to make them JVM_ENTRY and fix 
 thread_state.
 
You are welcome.

 If you pass the testing and Lois ok's the hotspot code, then I am ok with 
 checking in the
 hotspot code as is.
 

Thanks.

 Comments for next round of changes:
 
 1. mutexLocker.cpp - new lock should say false not true for whether the 
 VMThread should block

Done, along with not-leaf.

 
 2. os.hpp
 restartable_read_at is added but I don't see it used

Removed.

 
 3. imageFile.cpp
 We've been asked to always used the counted form of strcpy - i.e. strncpy  to 
 ensure we never
 have buffer overruns. e.g. 311, 437, ...
 
 4. jvm.cpp - seems odd that the interface would need to know if the resource 
 was compressed 
 or uncompressed. In the next round of API design, seems like the java code 
 would pass in
 the uncompressedAddress and let the internals handle buffering the compressed 
 data and
 doing the uncompressing transparently.
 
 5. imageDecompressor.hpp
 get_decompressor
 I think you've mixed your exception handling approaches. You have a 
 CHECK_NULL for new_symbol
 call, which means it will throw an exception if it returns NULL. Then you 
 check for HAS_PENDING_EXCEPTION
 which is the logic you would use if did not have the CHECK, but then you 
 throw the exception away.
 If you want to throw an exception from get_decompressor you should pass in 
 the last argument as TRAPS macro
 which will give you the THREAD.
 
 see macros in exceptions.hpp
 
 So the way it is right now, you will throw an exception.
 
 You have a choice - you can throw an exception
  pass in TRAPS to get_decompressor, keep the CHECK_NULL and remove the if 
 HAS_PENDING_EXCEPTION.
  - this is the recommended approach
 
 Alternative - change CHECK_NULL to pass in THREAD. Keep the rest. Given you 
 are planning to take this
 out of the vm - this would make more sense.
 

Thanks, we will implement 3/4/5 in the next round.

 thanks,
 Karen
 
 
 
 On Jun 17, 2015, at 8:08 PM, Jim Laskey (Oracle) wrote:
 
 https://bugs.openjdk.java.net/browse/JDK-8080511
 
 This is an long overdue refresh of the jimage support in the JDK9-dev repo.  
 This includes native support for reading jimage files, improved jrt-fs (java 
 runtime file system) support for retrieving modules and packages from the 
 runtime, and improved performance for langtools in the presence of jrt-fs.
 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools
 
 
 Details:
 
 - jrt-fs provides access, via the nio FileSystem API, to the classes in a 
 .jimage file, organized by module or by package.
 - Shared code for jimage support converted to native.  Currently residing in 
 hotspot, but will migrate to it’s own jdk library 
 https://bugs.openjdk.java.net/browse/JDK-8087181 
 https://bugs.openjdk.java.net/browse/JDK-8087181
 - A new archive abstraction for class/resource sources.
 - java based implementation layer for jimage reading to allow backport to 
 JDK8 (jrt-fs.jar - IDE support.)
 - JNI support for jimage into hotspot.
 - White box tests written to exercise native jimage support.

Re: RFR: JDK-8080511 - Refresh of jimage support

2015-06-23 Thread Jean-Francois Denise 
Hi Lois,

On 18 Jun 2015, at 19:55, Lois Foltan lois.fol...@oracle.com wrote:

 
 On 6/18/2015 10:59 AM, Karen Kinnear wrote:
 Code review for the hotspot component:
 
 Thank you for the cleanups to jvm.cpp to make them JVM_ENTRY and fix 
 thread_state.
 
 If you pass the testing and Lois ok's the hotspot code, then I am ok with 
 checking in the
 hotspot code as is.
 
 I have reviewed and am okay with checking in the hotspot code as is once 
 testing is complete.  One comment inlined below.
 Lois
 
 
 Comments for next round of changes:
 
 1. mutexLocker.cpp - new lock should say false not true for whether the 
 VMThread should block
 
 2. os.hpp
 restartable_read_at is added but I don't see it used
 
 3. imageFile.cpp
 We've been asked to always used the counted form of strcpy - i.e. strncpy  
 to ensure we never
 have buffer overruns. e.g. 311, 437, ...
 
 4. jvm.cpp - seems odd that the interface would need to know if the resource 
 was compressed
 or uncompressed. In the next round of API design, seems like the java code 
 would pass in
 the uncompressedAddress and let the internals handle buffering the 
 compressed data and
 doing the uncompressing transparently.
 
 5. imageDecompressor.hpp
 get_decompressor
 I think you've mixed your exception handling approaches. You have a 
 CHECK_NULL for new_symbol
 call, which means it will throw an exception if it returns NULL. Then you 
 check for HAS_PENDING_EXCEPTION
 which is the logic you would use if did not have the CHECK, but then you 
 throw the exception away.
 If you want to throw an exception from get_decompressor you should pass in 
 the last argument as TRAPS macro
 which will give you the THREAD.
 
 see macros in exceptions.hpp
 
 So the way it is right now, you will throw an exception.
 
 You have a choice - you can throw an exception
   pass in TRAPS to get_decompressor, keep the CHECK_NULL and remove the if 
 HAS_PENDING_EXCEPTION.
   - this is the recommended approach
 
 Alternative - change CHECK_NULL to pass in THREAD. Keep the rest. Given you 
 are planning to take this
 out of the vm - this would make more sense.
 
 Whatever mechanism you choose to use in get_decompressor, please also use for 
 image_decompressor_init( )/createSymbol() within imageDecompressor.cpp as 
 well.

OK, well noted.

Thanks.
JF
 
 
 thanks,
 Karen
 
 
 
 On Jun 17, 2015, at 8:08 PM, Jim Laskey (Oracle) wrote:
 
 https://bugs.openjdk.java.net/browse/JDK-8080511
 
 This is an long overdue refresh of the jimage support in the JDK9-dev repo. 
  This includes native support for reading jimage files, improved jrt-fs 
 (java runtime file system) support for retrieving modules and packages from 
 the runtime, and improved performance for langtools in the presence of 
 jrt-fs.
 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools
 
 
 Details:
 
 - jrt-fs provides access, via the nio FileSystem API, to the classes in a 
 .jimage file, organized by module or by package.
 - Shared code for jimage support converted to native.  Currently residing 
 in hotspot, but will migrate to it’s own jdk library 
 https://bugs.openjdk.java.net/browse/JDK-8087181 
 https://bugs.openjdk.java.net/browse/JDK-8087181
 - A new archive abstraction for class/resource sources.
 - java based implementation layer for jimage reading to allow backport to 
 JDK8 (jrt-fs.jar - IDE support.)
 - JNI support for jimage into hotspot.
 - White box tests written to exercise native jimage support.

Re: RFR: JDK-8080511 - Refresh of jimage support

2015-06-23 Thread Jean-Francois Denise 

On 18 Jun 2015, at 20:48, Mandy Chung mandy.ch...@oracle.com wrote:

 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 
modules.xml looks fine.
 
test/lib/sun/hotspot/WhiteBox.java
This adds the native entry points.  Where are they implemented?  It’s 
 not obvious to me.

The native is in hotspot repo vm/prims
 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools 
the jdeps change looks fine.
 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk/
 This is a huge patch that I have to rely on the extensive testing to catch 
 potential issues.  I tried running the jrt-fs tests using JDK 8 with 
 jrt-fs.jar that work well.   Some comments and mostly minor.
 
 make/gensrc/Gensrc-jdk.dev.gmk
 - you could revert this one
Done
 
 make/src/classes/build/tools/module/ImageBuilder.java
 Nit: line 366, 382 - left over commented lines
 some indentation/formatting nits line 386-397

Done
 
 jdk/tools/jimage/TaskHelper.java
 43 static final long serialVersionUID = 8765093759964640721L;  // ## 
 re-generate

Removed the comment

 
 jdk/tools/jimage/JImageTask.java
 The start year is replaced in the copyright header.   You should add the end 
 year instead.

Done
 
 test/java/nio/Buffer/LimitDirectMemory.sh
 test/java/nio/file/spi/SetDefaultProvider.java
   Why this test is ignored? 

Done, JDK bug logged.
 
 Mandy

Thanks.
JF

 
 On Jun 17, 2015, at 5:08 PM, Jim Laskey (Oracle) james.las...@oracle.com 
 wrote:
 
 https://bugs.openjdk.java.net/browse/JDK-8080511
 
 This is an long overdue refresh of the jimage support in the JDK9-dev repo.  
 This includes native support for reading jimage files, improved jrt-fs (java 
 runtime file system) support for retrieving modules and packages from the 
 runtime, and improved performance for langtools in the presence of jrt-fs.
 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools
 
 
 Details:
 
 - jrt-fs provides access, via the nio FileSystem API, to the classes in a 
 .jimage file, organized by module or by package.
 - Shared code for jimage support converted to native.  Currently residing in 
 hotspot, but will migrate to it’s own jdk library 
 https://bugs.openjdk.java.net/browse/JDK-8087181 
 https://bugs.openjdk.java.net/browse/JDK-8087181
 - A new archive abstraction for class/resource sources.
 - java based implementation layer for jimage reading to allow backport to 
 JDK8 (jrt-fs.jar - IDE support.)
 - JNI support for jimage into hotspot.
 - White box tests written to exercise native jimage support.

Re: RFR: JDK-8080511 - Refresh of jimage support

2015-06-23 Thread Jean-Francois Denise 
Hi Mandy,
I logged https://bugs.openjdk.java.net/browse/JDK-8129343 
Thanks.
JF
On 19 Jun 2015, at 16:26, Mandy Chung mandy.ch...@oracle.com wrote:

 
 On Jun 19, 2015, at 6:27 AM, Alan Bateman alan.bate...@oracle.com wrote:
 
 
 
 On 18/06/2015 19:48, Mandy Chung wrote:
 :
 
 test/java/nio/Buffer/LimitDirectMemory.sh
 test/java/nio/file/spi/SetDefaultProvider.java
   Why this test is ignored?
 
 
 For LimitDirectMemory.sh then the test needs to be adjusted to take account 
 of the direct buffers that the jimage code is created. We can do this after 
 Jim's push if it makes things easier.
 
 The SetDefaultProvider.java test is more tricky. I suggested to Jim that he 
 exclude it temporarily because interposing on the default provider with this 
 version of jimage code will lead to recursive initialization issues. Once we 
 get to one jimage file and replacing the ext/app class loaders then it will 
 become a non-issue and we liberate the test then.
 
 It’s fine to exclude them.   Jean-Francois - can you file a bug and add the 
 bug number next to @ignore?
 
 Mandy

Re: RFR: JDK-8080511 - Refresh of jimage support

2015-06-23 Thread Jean-Francois Denise 
Hi Paul,

On 19 Jun 2015, at 16:39, Paul Sandoz paul.san...@oracle.com wrote:

 
 On Jun 18, 2015, at 2:08 AM, Jim Laskey (Oracle) james.las...@oracle.com 
 wrote:
 
 https://bugs.openjdk.java.net/browse/JDK-8080511
 
 This is an long overdue refresh of the jimage support in the JDK9-dev repo.  
 This includes native support for reading jimage files, improved jrt-fs (java 
 runtime file system) support for retrieving modules and packages from the 
 runtime, and improved performance for langtools in the presence of jrt-fs.
 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk
 
 I eyeballed the JDK changes. Just two thing:
 
 make/src/classes/build/tools/module/ModuleArchive.java
 
  90 @Override
  91 public StreamEntry entries() {
  92 ListEntry entries = new ArrayList();
  93 try {
  94 if (classes != null)
  95 Files.walk(classes)
  96 .sorted()
  97 .filter(p - !Files.isDirectory(p)
  98  
 !classes.relativize(p).toString().startsWith(_the.)
  99  
 !classes.relativize(p).toString().equals(javac_state))
 100 .map(p - toEntry(p, classes, 
 EntryType.CLASS_OR_RESOURCE))
 101 .forEach(entries::add);
 102 if (cmds != null)
 103 Files.walk(cmds)
 104 .filter(p - !Files.isDirectory(p))
 105 .map(p - toEntry(p, cmds, EntryType.NATIVE_CMD))
 106 .forEach(entries::add);
 107 if (libs != null)
 108 Files.walk(libs)
 109 .filter(p - !Files.isDirectory(p))
 110 .map(p - toEntry(p, libs, EntryType.NATIVE_LIB))
 111 .forEach(entries::add);
 112 if (configs != null)
 113 Files.walk(configs)
 114 .filter(p - !Files.isDirectory(p))
 115 .map(p - toEntry(p, configs, EntryType.CONFIG))
 116 .forEach(entries::add);
 117 } catch (IOException ioe) {
 118 throw new UncheckedIOException(ioe);
 119 }
 120 return entries.stream();
 121 }
 
 You can use collect(toList())

== OK collect used. In addition, filter first then sort, tryWithResource for 4 
Files stream.

 
 In general the contract for Archive.entries probably has to say the stream 
 needs to be closed after use since it might cover lazy I/O based resources, 
 so callers will need to use a try-with-resources block.

== Added a note in javadoc, implemented explicit close for non lazy streams, 
added missing tryWithResource. Added a comment on what should be done in 
ModuleArchive to keep laziness.
 
 Paul.

Thanks.

 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools
 
 
 Details:
 
 - jrt-fs provides access, via the nio FileSystem API, to the classes in a 
 .jimage file, organized by module or by package.
 - Shared code for jimage support converted to native.  Currently residing in 
 hotspot, but will migrate to it’s own jdk library 
 https://bugs.openjdk.java.net/browse/JDK-8087181 
 https://bugs.openjdk.java.net/browse/JDK-8087181
 - A new archive abstraction for class/resource sources.
 - java based implementation layer for jimage reading to allow backport to 
 JDK8 (jrt-fs.jar - IDE support.)
 - JNI support for jimage into hotspot.
 - White box tests written to exercise native jimage support.

Re: RFR: JDK-8080511 - Refresh of jimage support

2015-06-19 Thread Mandy Chung 

 On Jun 19, 2015, at 6:27 AM, Alan Bateman alan.bate...@oracle.com wrote:
 
 
 
 On 18/06/2015 19:48, Mandy Chung wrote:
 :
 
 test/java/nio/Buffer/LimitDirectMemory.sh
 test/java/nio/file/spi/SetDefaultProvider.java
Why this test is ignored?
 
 
 For LimitDirectMemory.sh then the test needs to be adjusted to take account 
 of the direct buffers that the jimage code is created. We can do this after 
 Jim's push if it makes things easier.
 
 The SetDefaultProvider.java test is more tricky. I suggested to Jim that he 
 exclude it temporarily because interposing on the default provider with this 
 version of jimage code will lead to recursive initialization issues. Once we 
 get to one jimage file and replacing the ext/app class loaders then it will 
 become a non-issue and we liberate the test then.

It’s fine to exclude them.   Jean-Francois - can you file a bug and add the bug 
number next to @ignore?

Mandy

Re: RFR: JDK-8080511 - Refresh of jimage support

2015-06-18 Thread Lois Foltan 


On 6/18/2015 10:59 AM, Karen Kinnear wrote:

Code review for the hotspot component:

Thank you for the cleanups to jvm.cpp to make them JVM_ENTRY and fix 
thread_state.

If you pass the testing and Lois ok's the hotspot code, then I am ok with 
checking in the
hotspot code as is.


I have reviewed and am okay with checking in the hotspot code as is once 
testing is complete.  One comment inlined below.

Lois



Comments for next round of changes:

1. mutexLocker.cpp - new lock should say false not true for whether the 
VMThread should block

2. os.hpp
restartable_read_at is added but I don't see it used

3. imageFile.cpp
We've been asked to always used the counted form of strcpy - i.e. strncpy  to 
ensure we never
have buffer overruns. e.g. 311, 437, ...

4. jvm.cpp - seems odd that the interface would need to know if the resource 
was compressed
or uncompressed. In the next round of API design, seems like the java code 
would pass in
the uncompressedAddress and let the internals handle buffering the compressed 
data and
doing the uncompressing transparently.

5. imageDecompressor.hpp
get_decompressor
I think you've mixed your exception handling approaches. You have a CHECK_NULL 
for new_symbol
call, which means it will throw an exception if it returns NULL. Then you check 
for HAS_PENDING_EXCEPTION
which is the logic you would use if did not have the CHECK, but then you throw 
the exception away.
If you want to throw an exception from get_decompressor you should pass in the 
last argument as TRAPS macro
which will give you the THREAD.

see macros in exceptions.hpp

So the way it is right now, you will throw an exception.

You have a choice - you can throw an exception
   pass in TRAPS to get_decompressor, keep the CHECK_NULL and remove the if 
HAS_PENDING_EXCEPTION.
   - this is the recommended approach

Alternative - change CHECK_NULL to pass in THREAD. Keep the rest. Given you are 
planning to take this
out of the vm - this would make more sense.


Whatever mechanism you choose to use in get_decompressor, please also 
use for image_decompressor_init( )/createSymbol() within 
imageDecompressor.cpp as well.




thanks,
Karen



On Jun 17, 2015, at 8:08 PM, Jim Laskey (Oracle) wrote:


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

This is an long overdue refresh of the jimage support in the JDK9-dev repo.  
This includes native support for reading jimage files, improved jrt-fs (java 
runtime file system) support for retrieving modules and packages from the 
runtime, and improved performance for langtools in the presence of jrt-fs.

http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 
http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top
http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk 
http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk
http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot 
http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot
http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools 
http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools


Details:

- jrt-fs provides access, via the nio FileSystem API, to the classes in a 
.jimage file, organized by module or by package.
- Shared code for jimage support converted to native.  Currently residing in hotspot, 
but will migrate to it’s own jdk library 
https://bugs.openjdk.java.net/browse/JDK-8087181 
https://bugs.openjdk.java.net/browse/JDK-8087181
- A new archive abstraction for class/resource sources.
- java based implementation layer for jimage reading to allow backport to JDK8 
(jrt-fs.jar - IDE support.)
- JNI support for jimage into hotspot.
- White box tests written to exercise native jimage support.

Re: RFR: JDK-8080511 - Refresh of jimage support

2015-06-18 Thread Mandy Chung 
http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 
modules.xml looks fine.

test/lib/sun/hotspot/WhiteBox.java
This adds the native entry points.  Where are they implemented?  It’s 
not obvious to me.

http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools 
the jdeps change looks fine.

http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk/
This is a huge patch that I have to rely on the extensive testing to catch 
potential issues.  I tried running the jrt-fs tests using JDK 8 with jrt-fs.jar 
that work well.   Some comments and mostly minor.

make/gensrc/Gensrc-jdk.dev.gmk
 - you could revert this one

make/src/classes/build/tools/module/ImageBuilder.java
 Nit: line 366, 382 - left over commented lines
 some indentation/formatting nits line 386-397

jdk/tools/jimage/TaskHelper.java
43 static final long serialVersionUID = 8765093759964640721L;  // ## 
re-generate

jdk/tools/jimage/JImageTask.java
The start year is replaced in the copyright header.   You should add the end 
year instead.

test/java/nio/Buffer/LimitDirectMemory.sh
test/java/nio/file/spi/SetDefaultProvider.java
   Why this test is ignored? 

Mandy

 On Jun 17, 2015, at 5:08 PM, Jim Laskey (Oracle) james.las...@oracle.com 
 wrote:
 
 https://bugs.openjdk.java.net/browse/JDK-8080511
 
 This is an long overdue refresh of the jimage support in the JDK9-dev repo.  
 This includes native support for reading jimage files, improved jrt-fs (java 
 runtime file system) support for retrieving modules and packages from the 
 runtime, and improved performance for langtools in the presence of jrt-fs.
 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-top
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-jdk
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-hotspot
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools 
 http://cr.openjdk.java.net/~jlaskey/hs-rt-jimage/webrev-langtools
 
 
 Details:
 
 - jrt-fs provides access, via the nio FileSystem API, to the classes in a 
 .jimage file, organized by module or by package.
 - Shared code for jimage support converted to native.  Currently residing in 
 hotspot, but will migrate to it’s own jdk library 
 https://bugs.openjdk.java.net/browse/JDK-8087181 
 https://bugs.openjdk.java.net/browse/JDK-8087181
 - A new archive abstraction for class/resource sources.
 - java based implementation layer for jimage reading to allow backport to 
 JDK8 (jrt-fs.jar - IDE support.)
 - JNI support for jimage into hotspot.
 - White box tests written to exercise native jimage support.