From martijnverburg at gmail.com Mon Dec 1 15:23:33 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 1 Dec 2014 15:23:33 +0000 Subject: Official and community supported build platforms for JDK 8 and 9 In-Reply-To: <80D05DC7-C7F3-4169-A49C-92DE0ED4668E@reini.net> References: <546F82E0.9070909@oracle.com> <80D05DC7-C7F3-4169-A49C-92DE0ED4668E@reini.net> Message-ID: Likewise - is it possible to get edit access? Cheers, Martijn On 21 November 2014 at 20:46, Patrick Reinhart wrote: > Hi Magnus, > > > A recurring theme in the build-dev list is confusion on which platforms > it is possible to build OpenJDK. Unfortunately, information about this has > not been easy to gather. It has also not been clear what kind of build > issues the Build Team will respond to and with what kind of urgency. > > > > To help address this, I?ve created a publicly available wiki page: > https://wiki.openjdk.java.net/display/Build/Supported+build+platforms > > Nice work, that belongs on my shortcut list from now on. > > > Support for building on different platforms come in two varieties: > official support and community support. > > > > Oracle defines a number of official build platforms, with carefully > specified versions of operating systems, compilers and other build tools. > If you report a failure to build on any of these platforms, the report will > be processed with high priority from the build team in Oracle. Under normal > circumstances, a build on any of these platforms will always succeed. > > > > In addition to the official build platforms, OpenJDK can normally be > built on many more platforms. For these platforms, there is no guarantee > that the build will succeed. The Oracle build team can help to solve some > problems encountered, but only on a best-effort basis. In addition to the > Oracle build team, the OpenJDK community at large is welcome to help with > making OpenJDK compile on these platforms. > > > > The official and community supported build platforms are listed on the > wiki page. Note that build support is different for different versions of > the JDK. We welcome updates from the community to the list of community > supported platforms. If you have succeeded (or not!) in building OpenJDK on > a platform that is substantially different from the ones already listed, > please document your experience in the list. > > I?m able to fluently build JDK 8u and JDK 9 on Fedora 21 x64 > > > The list of community supported platforms on the wiki is currently much > shorter than the number of platforms I expect OpenJDK to build on. Once > again, please help us by filling in the wiki! > > > > /Magnus > > I would like to help improve also documentations for the community? > > Patrick From paul.sandoz at oracle.com Mon Dec 1 16:11:52 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 1 Dec 2014 17:11:52 +0100 Subject: RFR [JEP 220] Modular Run-Time Images In-Reply-To: References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> Message-ID: On Nov 20, 2014, at 10:41 PM, Chris Hegarty wrote: >> >> Webrevs: >> http://cr.openjdk.java.net/~chegar/8061971/00/ >> Below is a review of JDK code. I did not spot any showstoppers. It's mostly cleanup related with maybe one or two bugs. Paul. In src/java.base/share/classes/java/util/jar/Attributes.java /** * Name object for Implementation-URL * manifest attribute used for package versioning. - * @see - * Java Product Versioning Specification + * + * @deprecated Extension mechanism is no longer supported. */ + @Deprecated public static final Name IMPLEMENTATION_URL = new Name("Implementation-URL"); Is that is marked as deprecated should all the other IMPLEMENTATION_* names be marked as deprecated? In src/java.base/share/classes/sun/misc/Launcher.java + private static URL[] getExtURLs(File[] files) throws IOException { + List urls = new ArrayList<>(); + for (File f : files) { + urls.add(getFileURL(f)); } - return null; + return urls.toArray(new URL[0]); } Not important, but you can just create the URL array of the correct size rather than going through an ArrayList. In make/src/classes/build/tools/module/ImageBuilder.java, some stream usages, take 'em or leave 'em: + class SimpleResolver { + private final Set initialMods; + private final Map nameToModule = new HashMap<>(); + + SimpleResolver(Set mods, Set graph) { + graph.stream() + .forEach(m -> nameToModule.put(m.name(), m)); + initialMods = mods.stream() + .map(this::nameToModule) + .collect(Collectors.toSet()); + } You might be able to use toMap to create a map: nameToModule = graph.stream().collect(toMap(Module::name, m -> m)); That will throw an error on duplicate keys, but you can use the three-arg form to override that. + private Set getModuleDependences(Module m) { + return m.requires().stream() + .map(d -> d.name()) + .map(this::nameToModule) + .collect(Collectors.toSet()); + } You can return a stream, change "collect" to "distinct", then you don't need to stream over the set again when using forEach (but the exception code needs to be updated to collect as a set) + private Path moduleToPath(String name, List paths, boolean expect) { + Set foundPaths = new HashSet<>(); + if (paths != null) { + for (Path p : paths) { + Path rp = p.resolve(name); + if (Files.exists(rp)) + foundPaths.add(rp); + } + } + if (foundPaths.size() > 1) + throw new RuntimeException("Found more that one path for " + name); + if (expect && foundPaths.size() != 1) + throw new RuntimeException("Expected to find classes path for " + name); + return foundPaths.size() == 0 ? null : foundPaths.iterator().next(); + } // Stop when there is more than 1 Set foundPaths = paths == null ? Collections.emptySet() : paths.stream().map(p -> p.resolve(name)).filter(Files::exists).limit(2).collect(toSet()); + private Option getOption(String name) throws BadArgs { + for (Option o : recognizedOptions) { + if (o.matches(name)) { + return o; + } + } + throw new BadArgs("Unknown option %s", name).showUsage(true); + } Stream.of(recognizedOptions).filter(o -> o.matches(name)).findFirst().orElseThrow(() -> new BadArgs("Unknown option %s", name).showUsage(true)); In src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java + public String[] getEntryNames(boolean sorted) { + int count = header.getLocationCount(); + List list = new ArrayList<>(); + + for (int i = 0; i < count; i++) { + int offset = getOffset(i); + + if (offset != 0) { + ImageLocation location = ImageLocation.readFrom(locationsBuffer, offset, strings); + list.add(location.getFullnameString()); + } + } + + String[] array = list.toArray(new String[0]); + + if (sorted) { + Arrays.sort(array); + } + + return array; + } Stream names = IntStream.range(0, count).map(offsetsBuffer::get).filter(o -> o != 0).mapToObj(...); if (sorted) names = names.sorted(); return names.toArray(String[]::new); + protected ImageLocation[] getAllLocations(boolean sorted) { + int count = header.getLocationCount(); + List list = new ArrayList<>(); + + for (int i = 0; i < count; i++) { + int offset = getOffset(i); + + if (offset != 0) { + ImageLocation location = ImageLocation.readFrom(locationsBuffer, offset, strings); + list.add(location); + } + } + + ImageLocation[] array = list.toArray(new ImageLocation[0]); + + if (sorted) { + Arrays.sort(array, (ImageLocation loc1, ImageLocation loc2) -> + loc1.getFullnameString().compareTo(loc2.getFullnameString())); + } + + return array; + } Stream locations = IntStream.range(0, count).map(offsetsBuffer::get).filter(o -> o != 0).mapToObj(...); if (sorted) locations = locations.sorted(Comparing.comparing(ImageLocation::getFullnameString)); return locations.toArray(ImageLocation[]::new); In src/java.base/share/classes/jdk/internal/jimage/BasicImageWriter.java + private ImageBucket[] createBuckets() { + ImageBucket[] buckets = new ImageBucket[count]; + + input.stream().forEach((location) -> { + int index = location.hashCode() % count; + ImageBucket bucket = buckets[index]; + + if (bucket == null) { + buckets[index] = bucket = new ImageBucket(); + } + + bucket.add(location); + }); + + ImageBucket[] sorted = Arrays.asList(buckets).stream() + .filter((bucket) -> (bucket != null)) + .sorted() + .toArray(ImageBucket[]::new); + + return sorted; + } Use Stream.of(buckets).filter(....). In src/java.base/share/classes/jdk/internal/jimage/ImageFile.java + private void readModuleEntries(ImageModules modules, + Set archives) + throws IOException + { + for (Archive archive : archives) { + List res = new ArrayList<>(); + archive.visitResources(x-> res.add(x)); + res::add + String mn = archive.moduleName(); + resourcesForModule.put(mn, res); + + Set pkgs = res.stream().map(Resource::name) + .filter(n -> n.endsWith(".class")) + .map(this::toPackage) + .distinct() + .collect(Collectors.toSet()); + modules.setPackages(mn, pkgs); + } + } "distinct" is not required since the values are collected into a set. + static class Compressor { + public static byte[] compress(byte[] bytesIn) { + Deflater deflater = new Deflater(); + deflater.setInput(bytesIn); + ByteArrayOutputStream stream = new ByteArrayOutputStream(bytesIn.length); + byte[] buffer = new byte[1024]; + + deflater.finish(); + while (!deflater.finished()) { + int count = deflater.deflate(buffer); + stream.write(buffer, 0, count); + } + + try { + stream.close(); + } catch (IOException ex) { + return bytesIn; + } + + byte[] bytesOut = stream.toByteArray(); + deflater.end(); + + return bytesOut; + } ByteArrayOutputStream.close does not need to be called, it's a nop. Same applies for the decompress method that follows the above method. In src/java.base/share/classes/jdk/internal/jimage/ImageModules.java + private void mapModulesToLoader(Loader loader, Set modules) { + if (modules.isEmpty()) + return; + + // put java.base first + Set mods = new LinkedHashSet<>(); + modules.stream() + .filter(m -> m.equals("java.base")) + .forEach(mods::add); + modules.stream().sorted() + .filter(m -> !m.equals("java.base")) + .forEach(mods::add); + loaders.put(loader, new LoaderModuleData(loader, mods)); + } Since the second pass sorts it should be possible to avoid the first pass by using a comparator that sorts java.base before all other names. Comparator cs = (a, b) -> { boolean ajb = a.equals("java.base"); boolean bjb = b.equals("java.base"); return (ajb && bjb) ? 0 : ajb ? -1 : bjb ? 1 : a.compareTo(b); }; Set mods = modules.stream().sorted(cs).collect(toCollection(LinkedHashSet::new)); + public class ModuleIndex { + final Map moduleOffsets = new LinkedHashMap<>(); + final Map> packageOffsets = new HashMap<>(); + final int size; Might want to consider changing List to int[]. The two maps could be unified to just one Map since the same key is used, and the first element in the array corresponds to the module name string index. In src/java.base/share/classes/jdk/internal/jimage/ImageReader.java + private void fillPackageModuleInfo() { + assert rootDir != null; + + packageMap.entrySet().stream().sorted((x, y)->x.getKey().compareTo(y.getKey())).forEach((entry) -> { Use Map.Entry.comparingByKey(). In src/java.base/share/classes/jdk/internal/jrtfs/JrtDirectoryStream.java +final class JrtDirectoryStream implements DirectoryStream { + private final JrtFileSystem jrtfs; + private final byte[] path; + private final DirectoryStream.Filter filter; + private volatile boolean isClosed; + private volatile Iterator itr; Why are itr and isClosed fields marked volatile when the iterator() and closed() methods are synchronized? + return new Iterator() { + private Path next; Field not used. + @Override + public boolean hasNext() { + if (isClosed) + return false; + return itr.hasNext(); + } + + @Override + public synchronized Path next() { + if (isClosed) + throw new NoSuchElementException(); + return itr.next(); + } + + @Override + public void remove() { + throw new UnsupportedOperationException(); + } Do not need to implemented "remove" now it is defined as a default method. In src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystem.java + @Override + public Iterable getRootDirectories() { + ArrayList pathArr = new ArrayList<>(); + pathArr.add(rootPath); + return pathArr; + } Can use Arrays.asList(rootPath) since it is unspecified what happens if iterator().remove() is called? same for implementation of getFileStores. + private Iterator nodesToIterator(Path path, List childNodes) { + List childPaths = new ArrayList<>(childNodes.size()); + childNodes.stream().forEach((child) -> { + childPaths.add(toJrtPath(child.getNameString())); + }); + return childPaths.iterator(); + } Assuming that removal is not supported and you are allowed to be lazy over the contents of childNodes: childNodes.stream().map(c -> toJrtPath(c.getNameString())).iterator(); Otherwise if you need to make a copy: childNodes.stream().map(c -> toJrtPath(c.getNameString())).collect(toList()).iterator(); In src/java.base/share/classes/jdk/internal/jrtfs/JrtFileSystemProvider.java + private FileSystem getTheFileSystem() { + FileSystem fs = this.theFileSystem; + if (fs == null) { + synchronized (this) { + fs = this.theFileSystem; + if (fs == null) { + try { + fs = new JrtFileSystem(this, null) { + @Override public void close() { + throw new UnsupportedOperationException(); + } + }; + } catch (IOException ioe) { + throw new InternalError(ioe); + } + } + this.theFileSystem = fs; + } + } + return fs; + } More readable if you do: this.fileSystem = fs = ...; rather than have a potentially redundant volatile store. In src/java.base/share/classes/jdk/internal/jrtfs/JrtPath.java +final class JrtPath implements Path { + + private final JrtFileSystem jrtfs; + private final byte[] path; + private volatile int[] offsets; Some of the code in JrtPath is gonna take a hit on repeated volatile loads of "offsets" so recommend reading it once to a local variable. Perhaps initOffset can return the offset array so one can easily use it as a local variable: int[] localOffsets = initOffsets(); You might want to document that equalsNameAt does not need to initialize the offsets of this and the other path and perhaps add some asserts. + // resolved path for locating jrt entry inside the jrt file, + // the result path does not contain ./ and .. components + private volatile byte[] resolved = null; + byte[] getResolvedPath() { + byte[] r = resolved; + if (r == null) { + if (isAbsolute()) + r = getResolved(); + else + r = toAbsolutePath().getResolvedPath(); + if (r.length > 0 && r[0] == '/') + r = Arrays.copyOfRange(r, 1, r.length); + resolved = r; + } + return resolved; + } Return "r" instead of "resolved". In src/java.base/share/classes/sun/net/www/protocol/jrt/JavaRuntimeURLConnection.java + @Override + public int getContentLength() { + long len = getContentLengthLong(); + return Math.min((int)len, Integer.MAX_VALUE); + } That is not correct as the narrowing conversion will just discard the higher order bits (e.g. Math.min((int)(1L << 32), Integer.MAX_VALUE) ). I think you need to do: return len > Integer.MAX_VALUE ? -1 : (int)len; In src/jdk.dev/share/classes/jdk/tools/jimage/JImageTask.java In the method "recreate" a Stream.reduce function is used over files in the image. This reduction returns the total size but also performs some side-effects and supplies a bogus combiner since the total result is never used. I think it would be better to use a peek to perform some side-effects then you can consume that stream to create a new image and there is no need to create a List. The code here: + Stream offsets = Files.readAllLines(path) + .stream() + .map(writer::addString); + size = offsets.count() * 4; Can be replaced with: // The peek op has side-effects size = Files.lines(path).peek(s -> writer.addString(s)).count() * 4; The code here: + List offsets = Files.readAllLines(path) + .stream() + .map(writer::addString) + .collect(Collectors.toList()); + for (int off : offsets) { + out.writeInt(off); + } Can be replaced with: // The mapToInt op has side-effects Files.lines(path).mapToInt(writer::addString).forEach(out::writeInt); Paul. From Alan.Bateman at oracle.com Mon Dec 1 16:33:43 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 01 Dec 2014 16:33:43 +0000 Subject: RFR [JEP 220] Modular Run-Time Images In-Reply-To: References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> Message-ID: <547C9867.2050901@oracle.com> On 01/12/2014 16:11, Paul Sandoz wrote: > : > > > In src/java.base/share/classes/java/util/jar/Attributes.java > /** > * Name object for Implementation-URL > * manifest attribute used for package versioning. > - * @see > - * Java Product Versioning Specification > + * > + * @deprecated Extension mechanism is no longer supported. > */ > + @Deprecated > public static final Name IMPLEMENTATION_URL = new Name("Implementation-URL"); > Is that is marked as deprecated should all the other IMPLEMENTATION_* names be marked as deprecated? The webrev isn't quite up to date but just to say that the proposal is to only deprecate EXTENSION_INSTALLATION, IMPLEMENTATION_VENDOR_ID, and IMPLEMENTATION_URL. It took a while to completely sort out all the issues with the extensions mechanism and the JEP was updated a few days ago to make it clearer the aspects that are retained. > : > > > In make/src/classes/build/tools/module/ImageBuilder.java, some stream usages, take 'em or leave 'em: I agree there this could be good much more nicely in several places but it's just a temporary tool for the build and will be replaced completely once we have a proper linker. -Alan. From paul.sandoz at oracle.com Mon Dec 1 16:36:38 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 1 Dec 2014 17:36:38 +0100 Subject: RFR [JEP 220] Modular Run-Time Images In-Reply-To: <547C9867.2050901@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <547C9867.2050901@oracle.com> Message-ID: On Dec 1, 2014, at 5:33 PM, Alan Bateman wrote: > On 01/12/2014 16:11, Paul Sandoz wrote: >> : >> >> >> In src/java.base/share/classes/java/util/jar/Attributes.java >> /** >> * Name object for Implementation-URL >> * manifest attribute used for package versioning. >> - * @see >> - * Java Product Versioning Specification >> + * >> + * @deprecated Extension mechanism is no longer supported. >> */ >> + @Deprecated >> public static final Name IMPLEMENTATION_URL = new Name("Implementation-URL"); >> Is that is marked as deprecated should all the other IMPLEMENTATION_* names be marked as deprecated? > The webrev isn't quite up to date but just to say that the proposal is to only deprecate EXTENSION_INSTALLATION, IMPLEMENTATION_VENDOR_ID, and IMPLEMENTATION_URL. It took a while to completely sort out all the issues with the extensions mechanism and the JEP was updated a few days ago to make it clearer the aspects that are retained. > Ok. > >> : >> >> >> In make/src/classes/build/tools/module/ImageBuilder.java, some stream usages, take 'em or leave 'em: > I agree there this could be good much more nicely in several places but it's just a temporary tool for the build and will be replaced completely once we have a proper linker. > That's fine. My hope is that people, if looking, may find such comments instructive on streams usages. Paul. From harold.seigel at oracle.com Mon Dec 1 18:38:25 2014 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 01 Dec 2014 13:38:25 -0500 Subject: RFR [JEP 220] Modular Run-Time Images In-Reply-To: References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> Message-ID: <547CB5A1.90404@oracle.com> Hi Chris, Does this addition to hotspot/src/share/vm/runtime/arguments.cpp mean that all jar files must end in ".jar" ? +static bool has_jar_files(const char* directory) { + DIR* dir = os::opendir(directory); + if (dir == NULL) return false; + + struct dirent *entry; + char *dbuf = NEW_C_HEAP_ARRAY(char, os::readdir_buf_size(directory), mtInternal); + bool hasJarFile = false; + while (!hasJarFile && (entry = os::readdir(dir, (dirent *) dbuf)) != NULL) { + const char* name = entry->d_name; + const char* ext = name + strlen(name) - 4; *+ hasJarFile = ext > name && (os::file_name_strcmp(ext, ".jar") == 0);* + } + FREE_C_HEAP_ARRAY(char, dbuf, mtInternal); + os::closedir(dir); + return hasJarFile ; +} Thanks, Harold On 11/20/2014 4:41 PM, Chris Hegarty wrote: >> From: Chris Hegarty >> Subject: RFR [JEP 220] Modular Run-Time Images >> Date: 20 November 2014 21:39:14 GMT >> To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons , Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie , Mandy Chung , Mark Reinhold , Paul Sandoz , "A. Sundararajan" >> >> This is a review request for the changes for JEP 220: Modular Run-Time Images [1]. >> >> There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the 'To' section of this mail, and they will help address any comments arising from this review request. >> >> The new run-time image structure is defined in JEP 220 [1], and can be seen as a result of building the staging forest [2], or in the early access builds [3]. >> >> Webrevs: >> http://cr.openjdk.java.net/~chegar/8061971/00/ >> >> Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev. >> >> -Chris. >> >> [1] http://openjdk.java.net/jeps/220 >> [2] http://hg.openjdk.java.net/jigsaw/m2/ >> [3] http://openjdk.java.net/projects/jigsaw/ea From iris.clark at oracle.com Mon Dec 1 19:02:33 2014 From: iris.clark at oracle.com (Iris Clark) Date: Mon, 1 Dec 2014 11:02:33 -0800 (PST) Subject: Official and community supported build platforms for JDK 8 and 9 In-Reply-To: References: <546F82E0.9070909@oracle.com> <80D05DC7-C7F3-4169-A49C-92DE0ED4668E@reini.net> Message-ID: Hi, Martijn. > Likewise - is it possible to get edit access? https://wiki.openjdk.java.net/display/Build/Supported+build+platforms That wikispace is owned by the Build Group, so all Members of that Group as listed in the Census [0] should be able to edit the page. Thanks, iris [0] http://openjdk.java.net/census#build -----Original Message----- From: Martijn Verburg [mailto:martijnverburg at gmail.com] Sent: Monday, December 01, 2014 7:24 AM To: Patrick Reinhart Cc: jdk8-dev; build-dev; jdk9-dev at openjdk.java.net Subject: Re: Official and community supported build platforms for JDK 8 and 9 Likewise - is it possible to get edit access? Cheers, Martijn From mandy.chung at oracle.com Mon Dec 1 20:13:12 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 01 Dec 2014 12:13:12 -0800 Subject: RFR [JEP 220] Modular Run-Time Images In-Reply-To: <547CB5A1.90404@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <547CB5A1.90404@oracle.com> Message-ID: <547CCBD8.6090404@oracle.com> On 12/1/14 10:38 AM, harold seigel wrote: > Hi Chris, > > Does this addition to hotspot/src/share/vm/runtime/arguments.cpp mean > that all jar files must end in ".jar" ? > In practice, is there any JAR file installed in the extension/endorsed directory with a different file extension than ".jar"? This addition is to be used by -XX:+CheckEndorsedAndExtDirs flag to help identity if the application is using endorsed/extension mechanism. The other way to determine this is by opening the file and accept any zip file. That could be done while I think it's rare to find any use of extension and endorsed mechanism with JAR files without ".jar" file extension. Mandy > +static bool has_jar_files(const char* directory) { > + DIR* dir = os::opendir(directory); > + if (dir == NULL) return false; > + > + struct dirent *entry; > + char *dbuf = NEW_C_HEAP_ARRAY(char, > os::readdir_buf_size(directory), mtInternal); > + bool hasJarFile = false; > + while (!hasJarFile && (entry = os::readdir(dir, (dirent *) dbuf)) > != NULL) { > + const char* name = entry->d_name; > + const char* ext = name + strlen(name) - 4; > *+ hasJarFile = ext > name && (os::file_name_strcmp(ext, ".jar") == > 0);* > + } > + FREE_C_HEAP_ARRAY(char, dbuf, mtInternal); > + os::closedir(dir); > + return hasJarFile ; > +} > > Thanks, Harold > > > On 11/20/2014 4:41 PM, Chris Hegarty wrote: >>> From: Chris Hegarty >>> Subject: RFR [JEP 220] Modular Run-Time Images >>> Date: 20 November 2014 21:39:14 GMT >>> To: jigsaw-dev , jdk9-dev >>> , build-dev , >>> Alan Bateman , Alex Buckley >>> , Chris Hegarty , >>> Erik Joelsson , Jonathan Gibbons >>> , Karen Kinnear >>> , "Jim Laskey (Oracle)" >>> , Magnus Ihse Bursie >>> , Mandy Chung >>> , Mark Reinhold , >>> Paul Sandoz , "A. Sundararajan" >>> >>> >>> This is a review request for the changes for JEP 220: Modular >>> Run-Time Images [1]. >>> >>> There are a number of individuals responsible for these changes. >>> Some, possibly not all, are explicitly listed in the 'To' section of >>> this mail, and they will help address any comments arising from this >>> review request. >>> >>> The new run-time image structure is defined in JEP 220 [1], and can >>> be seen as a result of building the staging forest [2], or in the >>> early access builds [3]. >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~chegar/8061971/00/ >>> >>> Due to the significant impact of these changes, a JDK 9 promotion >>> has been tentatively reserved for their integration. All comments >>> are welcome, although given the nature of the changes then we might >>> have to create separate issues in JIRA to address some of them later >>> in jdk9/dev. >>> >>> -Chris. >>> >>> [1] http://openjdk.java.net/jeps/220 >>> [2] http://hg.openjdk.java.net/jigsaw/m2/ >>> [3] http://openjdk.java.net/projects/jigsaw/ea > From jan.lahoda at oracle.com Mon Dec 1 20:38:31 2014 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 01 Dec 2014 21:38:31 +0100 Subject: RFR [JEP 220] Modular Run-Time Images In-Reply-To: References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> Message-ID: <547CD1C7.60809@oracle.com> javac changes seem generally OK to me with a few nits below (I am OK if these are handled separately as needed). Jan -ClassFinder, above getSupplementaryFlags: typo "superceded"? -Locations, method systemClasses, in the jimage branch, there is: Collection images = files .filter(f -> f.getFileName().toString().endsWith(".jimage")) .map(Path::toFile) .collect(Collectors.toList()); if (!images.isEmpty()) { return Collections.singleton(JRT_MARKER_FILE); } this could use Stream.anyMatch(f -> f.getFileName().toString().endsWith(".jimage")) instead of collecting to list and using List.isEmpty? -JRTIndex.java: --I would prefer to use Reference instead of SoftReference wherever possible. --in getEntry method, there is: subdirs.add(new RelativeDirectory(rd, entry.getFileName().toString())); this recomputes entry.getFileName().toString() which is already in a local var ("name"). -test/tools/javac/T6558476.java: just a copyright year change -in test/tools/javac/api/T6412669.java there is: fm.setLocation(StandardLocation.CLASS_PATH, Arrays.asList(testClasses)); which may have a wrong ident -in test/tools/javac/api/T6877206.java there is a comment referring to ct.sym/rt.jar, which does not seem to be valid anymore -test/tools/javac/diags/examples/NotInProfile.java - why this change? -in test/tools/javac/profiles/ProfileOptionTest.java there is comment: // no equivalent -source? is that still true/valid? -in test/tools/lib/ToolBox.java there are stray changes like: - for (String p : paths) + for (String p: paths) On 20.11.2014 22:41, Chris Hegarty wrote: > >> From: Chris Hegarty >> Subject: RFR [JEP 220] Modular Run-Time Images >> Date: 20 November 2014 21:39:14 GMT >> To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons , Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie , Mandy Chung , Mark Reinhold , Paul Sandoz , "A. Sundararajan" >> >> This is a review request for the changes for JEP 220: Modular Run-Time Images [1]. >> >> There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the 'To' section of this mail, and they will help address any comments arising from this review request. >> >> The new run-time image structure is defined in JEP 220 [1], and can be seen as a result of building the staging forest [2], or in the early access builds [3]. >> >> Webrevs: >> http://cr.openjdk.java.net/~chegar/8061971/00/ >> >> Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev. >> >> -Chris. >> >> [1] http://openjdk.java.net/jeps/220 >> [2] http://hg.openjdk.java.net/jigsaw/m2/ >> [3] http://openjdk.java.net/projects/jigsaw/ea > From mark.reinhold at oracle.com Mon Dec 1 22:20:06 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 01 Dec 2014 14:20:06 -0800 Subject: JEPs proposed to target JDK 9 (2014/11/20) In-Reply-To: <20141120154904.230961@eggemoggin.niobe.net> References: <20141120154904.230961@eggemoggin.niobe.net> Message-ID: <20141201142006.485357@eggemoggin.niobe.net> 2014/11/20 3:49 -0800, mark.reinhold at oracle.com: > For your consideration: The following JEPs have been placed into the > "Proposed to Target" state by their respective owners after discussion > and review. > > 220: Modular Run-Time Images http://openjdk.java.net/jeps/220 > 231: Remove Launch-Time JRE Version Selection http://openjdk.java.net/jeps/231 > > Feedback is more than welcome, as are reasoned objections. If no such > objections are raised by 22:00 UTC on Monday, 1 December 2014, or if > they're raised and then satisfactorily answered, then per the JEP 2.0 > process proposal [1] I'll target these JEPs to JDK 9. (The review > period ends on Monday 12/1 due to the Thanksgiving holiday here in > the U.S.) Hearing no objections, I've targeted these two JEPs to JDK 9. - Mark From staffan.friberg at oracle.com Tue Dec 2 19:53:34 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Tue, 02 Dec 2014 11:53:34 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547DD133.1050706@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> Message-ID: <547E18BE.2070201@oracle.com> Hi, (Adding the jdk9-dev list to increase the visibility of the discussion) With the multiple sub-repository commit mechanism improved I believe this might be less of an issue. JPRT can push JDK and HS changes at together and the same functionality should be possible to use for this as well. I wonder if the test issue earlier was that it was a completely separate repository outside of the JDK forest, and less of an issue when being part of the same forest as the JDK source code. Perhaps someone from SQE can chime? Otherwise the main reason for having a separate sub-repository on the top level is making it easier to find what benchmarks are available and have a single place to add new once avoid any risk of name duplication. JMH is superb in filtering during execution during runtime so running just a single test or a group of tests is very straight forward and the recommended way, rather than having multiple benchmark JARs. It also makes the build process easier as the building can be done using a single Makefile and a single benchmark JAR (actually two, one for JDK 8 compatible tests and one for JDK 9) that can be picked up by automatic performance testing. Cheers, Staffan On 12/02/2014 06:48 AM, roger riggs wrote: > Hi Staffan, > > An earlier issue was keeping tests in sync with the code under test, > hence > the use of test directories within each repository. > I think a structure in which the benchmarks for some function and the > function > itself are in the same repository that is easier to understand and > maintain. > > $.02, Roger > > > On 12/1/2014 7:08 PM, Staffan Friberg wrote: >> Hi, >> >> Hopefully this is the right list for this discussion. >> >> As part of adding Microbenchmarks to the OpenJDK source tree, I'm >> trying to understand how we best would add the benchmark sources to >> the existing OpenJDK tree structure. >> >> Since the microbenchmark suite will cover all parts of the JDK, >> covering HotSpot, JDK libraries and Nashorn, it would be preferred to >> add the microbenchmark directory as a new top level directory. >> Something similar to the following structure. Having "benchmark" as >> the top-level directory would allow us to later add different types >> of benchmarks without colliding with the microbenchmark suite. >> >> / >> benchmark/microbenchmark/... >> hotspot/... >> jdk/... >> nashorn/... >> >> With this as the premise I can see the following 3 options for how >> this could be added to the source code layout >> >> 1. Part of jdk-root repository >> * Only makes sense if we want to move in a direction with fewer >> trees (and eventually a single tree) >> 2. Part of another already existing tree >> * Not sure if this is possible without converting and moving the >> directory to a subdirectory of that tree >> 3. New tree in the forest/tree structure >> * Most logical option as it follows the current setup and structure >> >> >> Anyone have any comments and/or concerns on the suggested directory >> location and the tree structure in option 3. >> >> Would the build-dev team be the right group to later help setup a new >> tree if decided to be the right way to go? >> >> Regards, >> Staffan >> > From chris.hegarty at oracle.com Tue Dec 2 21:23:37 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 2 Dec 2014 21:23:37 +0000 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547E18BE.2070201@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> Message-ID: <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> Staffan, Having all the benchmarks located in a single place makes sense to me, but this doesn?t necessarily mean that they need their own repository, in the forest. If I can build, run, and test ( usual development cycle ) without any dependency on these benchmarks, or their infrastructure, essential working with a partial forest ( without the ?benchmark? repository ), then I can see the possible value in having a separate repository ( so I can skip cloning and updating it ). But, I?m not sure if that is a reasonable justification for a new repository, as it is probably at odds with your goals, or maybe not? -Chris On 2 Dec 2014, at 19:53, Staffan Friberg wrote: > Hi, > > (Adding the jdk9-dev list to increase the visibility of the discussion) > > With the multiple sub-repository commit mechanism improved I believe this might be less of an issue. JPRT can push JDK and HS changes at together and the same functionality should be possible to use for this as well. I wonder if the test issue earlier was that it was a completely separate repository outside of the JDK forest, and less of an issue when being part of the same forest as the JDK source code. Perhaps someone from SQE can chime? > > Otherwise the main reason for having a separate sub-repository on the top level is making it easier to find what benchmarks are available and have a single place to add new once avoid any risk of name duplication. JMH is superb in filtering during execution during runtime so running just a single test or a group of tests is very straight forward and the recommended way, rather than having multiple benchmark JARs. It also makes the build process easier as the building can be done using a single Makefile and a single benchmark JAR (actually two, one for JDK 8 compatible tests and one for JDK 9) that can be picked up by automatic performance testing. > > Cheers, > Staffan > > On 12/02/2014 06:48 AM, roger riggs wrote: >> Hi Staffan, >> >> An earlier issue was keeping tests in sync with the code under test, hence >> the use of test directories within each repository. >> I think a structure in which the benchmarks for some function and the function >> itself are in the same repository that is easier to understand and maintain. >> >> $.02, Roger >> >> >> On 12/1/2014 7:08 PM, Staffan Friberg wrote: >>> Hi, >>> >>> Hopefully this is the right list for this discussion. >>> >>> As part of adding Microbenchmarks to the OpenJDK source tree, I'm trying to understand how we best would add the benchmark sources to the existing OpenJDK tree structure. >>> >>> Since the microbenchmark suite will cover all parts of the JDK, covering HotSpot, JDK libraries and Nashorn, it would be preferred to add the microbenchmark directory as a new top level directory. Something similar to the following structure. Having "benchmark" as the top-level directory would allow us to later add different types of benchmarks without colliding with the microbenchmark suite. >>> >>> / >>> benchmark/microbenchmark/... >>> hotspot/... >>> jdk/... >>> nashorn/... >>> >>> With this as the premise I can see the following 3 options for how this could be added to the source code layout >>> >>> 1. Part of jdk-root repository >>> * Only makes sense if we want to move in a direction with fewer >>> trees (and eventually a single tree) >>> 2. Part of another already existing tree >>> * Not sure if this is possible without converting and moving the >>> directory to a subdirectory of that tree >>> 3. New tree in the forest/tree structure >>> * Most logical option as it follows the current setup and structure >>> >>> >>> Anyone have any comments and/or concerns on the suggested directory location and the tree structure in option 3. >>> >>> Would the build-dev team be the right group to later help setup a new tree if decided to be the right way to go? >>> >>> Regards, >>> Staffan >>> >> > From staffan.friberg at oracle.com Tue Dec 2 22:08:20 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Tue, 02 Dec 2014 14:08:20 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> Message-ID: <547E3854.3060705@oracle.com> Hi Chris, Agree, there is no major reason this needs to be a new repository, as I mentioned in the 3 options below it would work well without it. The main thing I want to achieve is that the benchmarks are located on the top level. The suite will contain benchmarks for all parts of the JDK so having it in either jdk or hotspot doesn't feel like it makes sense. If people agree on having it as folder in the top level JDK repository I'm perfectly fine with that. As for building it will most likely not be of the general build process for building the JDK (do not want to increase the compilation time for anyone not requiring the benchmark suite). It would have its own target 'build-microbenchmark' which would depend on 'exploded-image', but not the reverse. //Staffan On 12/02/2014 01:23 PM, Chris Hegarty wrote: > Staffan, > > Having all the benchmarks located in a single place makes sense to me, but this doesn?t necessarily mean that they need their own repository, in the forest. > > If I can build, run, and test ( usual development cycle ) without any dependency on these benchmarks, or their infrastructure, essential working with a partial forest ( without the ?benchmark? repository ), then I can see the possible value in having a separate repository ( so I can skip cloning and updating it ). But, I?m not sure if that is a reasonable justification for a new repository, as it is probably at odds with your goals, or maybe not? > > -Chris > > On 2 Dec 2014, at 19:53, Staffan Friberg wrote: > >> Hi, >> >> (Adding the jdk9-dev list to increase the visibility of the discussion) >> >> With the multiple sub-repository commit mechanism improved I believe this might be less of an issue. JPRT can push JDK and HS changes at together and the same functionality should be possible to use for this as well. I wonder if the test issue earlier was that it was a completely separate repository outside of the JDK forest, and less of an issue when being part of the same forest as the JDK source code. Perhaps someone from SQE can chime? >> >> Otherwise the main reason for having a separate sub-repository on the top level is making it easier to find what benchmarks are available and have a single place to add new once avoid any risk of name duplication. JMH is superb in filtering during execution during runtime so running just a single test or a group of tests is very straight forward and the recommended way, rather than having multiple benchmark JARs. It also makes the build process easier as the building can be done using a single Makefile and a single benchmark JAR (actually two, one for JDK 8 compatible tests and one for JDK 9) that can be picked up by automatic performance testing. >> >> Cheers, >> Staffan >> >> On 12/02/2014 06:48 AM, roger riggs wrote: >>> Hi Staffan, >>> >>> An earlier issue was keeping tests in sync with the code under test, hence >>> the use of test directories within each repository. >>> I think a structure in which the benchmarks for some function and the function >>> itself are in the same repository that is easier to understand and maintain. >>> >>> $.02, Roger >>> >>> >>> On 12/1/2014 7:08 PM, Staffan Friberg wrote: >>>> Hi, >>>> >>>> Hopefully this is the right list for this discussion. >>>> >>>> As part of adding Microbenchmarks to the OpenJDK source tree, I'm trying to understand how we best would add the benchmark sources to the existing OpenJDK tree structure. >>>> >>>> Since the microbenchmark suite will cover all parts of the JDK, covering HotSpot, JDK libraries and Nashorn, it would be preferred to add the microbenchmark directory as a new top level directory. Something similar to the following structure. Having "benchmark" as the top-level directory would allow us to later add different types of benchmarks without colliding with the microbenchmark suite. >>>> >>>> / >>>> benchmark/microbenchmark/... >>>> hotspot/... >>>> jdk/... >>>> nashorn/... >>>> >>>> With this as the premise I can see the following 3 options for how this could be added to the source code layout >>>> >>>> 1. Part of jdk-root repository >>>> * Only makes sense if we want to move in a direction with fewer >>>> trees (and eventually a single tree) >>>> 2. Part of another already existing tree >>>> * Not sure if this is possible without converting and moving the >>>> directory to a subdirectory of that tree >>>> 3. New tree in the forest/tree structure >>>> * Most logical option as it follows the current setup and structure >>>> >>>> >>>> Anyone have any comments and/or concerns on the suggested directory location and the tree structure in option 3. >>>> >>>> Would the build-dev team be the right group to later help setup a new tree if decided to be the right way to go? >>>> >>>> Regards, >>>> Staffan >>>> From jonathan.gibbons at oracle.com Tue Dec 2 22:14:10 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 02 Dec 2014 14:14:10 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547E3854.3060705@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> <547E3854.3060705@oracle.com> Message-ID: <547E39B2.4050108@oracle.com> Staffan, I would also ask how many files are eventually likely to be involved. If it's tens of files up to low hundreds, then a top level dir makes sense. If it's tens of thousands of files, then a separate repo makes more sense. -- Jon On 12/02/2014 02:08 PM, Staffan Friberg wrote: > Hi Chris, > > Agree, there is no major reason this needs to be a new repository, as > I mentioned in the 3 options below it would work well without it. The > main thing I want to achieve is that the benchmarks are located on the > top level. The suite will contain benchmarks for all parts of the JDK > so having it in either jdk or hotspot doesn't feel like it makes > sense. If people agree on having it as folder in the top level JDK > repository I'm perfectly fine with that. > > As for building it will most likely not be of the general build > process for building the JDK (do not want to increase the compilation > time for anyone not requiring the benchmark suite). It would have its > own target 'build-microbenchmark' which would depend on > 'exploded-image', but not the reverse. > > //Staffan > > On 12/02/2014 01:23 PM, Chris Hegarty wrote: >> Staffan, >> >> Having all the benchmarks located in a single place makes sense to >> me, but this doesn?t necessarily mean that they need their own >> repository, in the forest. >> >> If I can build, run, and test ( usual development cycle ) without any >> dependency on these benchmarks, or their infrastructure, essential >> working with a partial forest ( without the ?benchmark? repository ), >> then I can see the possible value in having a separate repository ( >> so I can skip cloning and updating it ). But, I?m not sure if that is >> a reasonable justification for a new repository, as it is probably at >> odds with your goals, or maybe not? >> >> -Chris >> >> On 2 Dec 2014, at 19:53, Staffan Friberg >> wrote: >> >>> Hi, >>> >>> (Adding the jdk9-dev list to increase the visibility of the discussion) >>> >>> With the multiple sub-repository commit mechanism improved I believe >>> this might be less of an issue. JPRT can push JDK and HS changes at >>> together and the same functionality should be possible to use for >>> this as well. I wonder if the test issue earlier was that it was a >>> completely separate repository outside of the JDK forest, and less >>> of an issue when being part of the same forest as the JDK source >>> code. Perhaps someone from SQE can chime? >>> >>> Otherwise the main reason for having a separate sub-repository on >>> the top level is making it easier to find what benchmarks are >>> available and have a single place to add new once avoid any risk of >>> name duplication. JMH is superb in filtering during execution during >>> runtime so running just a single test or a group of tests is very >>> straight forward and the recommended way, rather than having >>> multiple benchmark JARs. It also makes the build process easier as >>> the building can be done using a single Makefile and a single >>> benchmark JAR (actually two, one for JDK 8 compatible tests and one >>> for JDK 9) that can be picked up by automatic performance testing. >>> >>> Cheers, >>> Staffan >>> >>> On 12/02/2014 06:48 AM, roger riggs wrote: >>>> Hi Staffan, >>>> >>>> An earlier issue was keeping tests in sync with the code under >>>> test, hence >>>> the use of test directories within each repository. >>>> I think a structure in which the benchmarks for some function and >>>> the function >>>> itself are in the same repository that is easier to understand and >>>> maintain. >>>> >>>> $.02, Roger >>>> >>>> >>>> On 12/1/2014 7:08 PM, Staffan Friberg wrote: >>>>> Hi, >>>>> >>>>> Hopefully this is the right list for this discussion. >>>>> >>>>> As part of adding Microbenchmarks to the OpenJDK source tree, I'm >>>>> trying to understand how we best would add the benchmark sources >>>>> to the existing OpenJDK tree structure. >>>>> >>>>> Since the microbenchmark suite will cover all parts of the JDK, >>>>> covering HotSpot, JDK libraries and Nashorn, it would be preferred >>>>> to add the microbenchmark directory as a new top level directory. >>>>> Something similar to the following structure. Having "benchmark" >>>>> as the top-level directory would allow us to later add different >>>>> types of benchmarks without colliding with the microbenchmark suite. >>>>> >>>>> / >>>>> benchmark/microbenchmark/... >>>>> hotspot/... >>>>> jdk/... >>>>> nashorn/... >>>>> >>>>> With this as the premise I can see the following 3 options for how >>>>> this could be added to the source code layout >>>>> >>>>> 1. Part of jdk-root repository >>>>> * Only makes sense if we want to move in a direction with fewer >>>>> trees (and eventually a single tree) >>>>> 2. Part of another already existing tree >>>>> * Not sure if this is possible without converting and moving the >>>>> directory to a subdirectory of that tree >>>>> 3. New tree in the forest/tree structure >>>>> * Most logical option as it follows the current setup and >>>>> structure >>>>> >>>>> >>>>> Anyone have any comments and/or concerns on the suggested >>>>> directory location and the tree structure in option 3. >>>>> >>>>> Would the build-dev team be the right group to later help setup a >>>>> new tree if decided to be the right way to go? >>>>> >>>>> Regards, >>>>> Staffan >>>>> > From staffan.friberg at oracle.com Tue Dec 2 22:27:27 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Tue, 02 Dec 2014 14:27:27 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547E39B2.4050108@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> <547E3854.3060705@oracle.com> <547E39B2.4050108@oracle.com> Message-ID: <547E3CCF.8040009@oracle.com> Hi Jon, As part of the initial set of benchmarks we hope to add as part of this JEP I'm guessing it will be around 200-300 files. This would grow overtime, but I believe we won't see tens of thousands of files, it is more likely it will be something like a 1000 files. //Staffan On 12/02/2014 02:14 PM, Jonathan Gibbons wrote: > Staffan, > > I would also ask how many files are eventually likely to be involved. > > If it's tens of files up to low hundreds, then a top level dir makes > sense. > > If it's tens of thousands of files, then a separate repo makes more > sense. > > -- Jon > > > On 12/02/2014 02:08 PM, Staffan Friberg wrote: >> Hi Chris, >> >> Agree, there is no major reason this needs to be a new repository, as >> I mentioned in the 3 options below it would work well without it. The >> main thing I want to achieve is that the benchmarks are located on >> the top level. The suite will contain benchmarks for all parts of the >> JDK so having it in either jdk or hotspot doesn't feel like it makes >> sense. If people agree on having it as folder in the top level JDK >> repository I'm perfectly fine with that. >> >> As for building it will most likely not be of the general build >> process for building the JDK (do not want to increase the compilation >> time for anyone not requiring the benchmark suite). It would have its >> own target 'build-microbenchmark' which would depend on >> 'exploded-image', but not the reverse. >> >> //Staffan >> >> On 12/02/2014 01:23 PM, Chris Hegarty wrote: >>> Staffan, >>> >>> Having all the benchmarks located in a single place makes sense to >>> me, but this doesn?t necessarily mean that they need their own >>> repository, in the forest. >>> >>> If I can build, run, and test ( usual development cycle ) without >>> any dependency on these benchmarks, or their infrastructure, >>> essential working with a partial forest ( without the ?benchmark? >>> repository ), then I can see the possible value in having a separate >>> repository ( so I can skip cloning and updating it ). But, I?m not >>> sure if that is a reasonable justification for a new repository, as >>> it is probably at odds with your goals, or maybe not? >>> >>> -Chris >>> >>> On 2 Dec 2014, at 19:53, Staffan Friberg >>> wrote: >>> >>>> Hi, >>>> >>>> (Adding the jdk9-dev list to increase the visibility of the >>>> discussion) >>>> >>>> With the multiple sub-repository commit mechanism improved I >>>> believe this might be less of an issue. JPRT can push JDK and HS >>>> changes at together and the same functionality should be possible >>>> to use for this as well. I wonder if the test issue earlier was >>>> that it was a completely separate repository outside of the JDK >>>> forest, and less of an issue when being part of the same forest as >>>> the JDK source code. Perhaps someone from SQE can chime? >>>> >>>> Otherwise the main reason for having a separate sub-repository on >>>> the top level is making it easier to find what benchmarks are >>>> available and have a single place to add new once avoid any risk of >>>> name duplication. JMH is superb in filtering during execution >>>> during runtime so running just a single test or a group of tests is >>>> very straight forward and the recommended way, rather than having >>>> multiple benchmark JARs. It also makes the build process easier as >>>> the building can be done using a single Makefile and a single >>>> benchmark JAR (actually two, one for JDK 8 compatible tests and one >>>> for JDK 9) that can be picked up by automatic performance testing. >>>> >>>> Cheers, >>>> Staffan >>>> >>>> On 12/02/2014 06:48 AM, roger riggs wrote: >>>>> Hi Staffan, >>>>> >>>>> An earlier issue was keeping tests in sync with the code under >>>>> test, hence >>>>> the use of test directories within each repository. >>>>> I think a structure in which the benchmarks for some function and >>>>> the function >>>>> itself are in the same repository that is easier to understand and >>>>> maintain. >>>>> >>>>> $.02, Roger >>>>> >>>>> >>>>> On 12/1/2014 7:08 PM, Staffan Friberg wrote: >>>>>> Hi, >>>>>> >>>>>> Hopefully this is the right list for this discussion. >>>>>> >>>>>> As part of adding Microbenchmarks to the OpenJDK source tree, I'm >>>>>> trying to understand how we best would add the benchmark sources >>>>>> to the existing OpenJDK tree structure. >>>>>> >>>>>> Since the microbenchmark suite will cover all parts of the JDK, >>>>>> covering HotSpot, JDK libraries and Nashorn, it would be >>>>>> preferred to add the microbenchmark directory as a new top level >>>>>> directory. Something similar to the following structure. Having >>>>>> "benchmark" as the top-level directory would allow us to later >>>>>> add different types of benchmarks without colliding with the >>>>>> microbenchmark suite. >>>>>> >>>>>> / >>>>>> benchmark/microbenchmark/... >>>>>> hotspot/... >>>>>> jdk/... >>>>>> nashorn/... >>>>>> >>>>>> With this as the premise I can see the following 3 options for >>>>>> how this could be added to the source code layout >>>>>> >>>>>> 1. Part of jdk-root repository >>>>>> * Only makes sense if we want to move in a direction with fewer >>>>>> trees (and eventually a single tree) >>>>>> 2. Part of another already existing tree >>>>>> * Not sure if this is possible without converting and moving >>>>>> the >>>>>> directory to a subdirectory of that tree >>>>>> 3. New tree in the forest/tree structure >>>>>> * Most logical option as it follows the current setup and >>>>>> structure >>>>>> >>>>>> >>>>>> Anyone have any comments and/or concerns on the suggested >>>>>> directory location and the tree structure in option 3. >>>>>> >>>>>> Would the build-dev team be the right group to later help setup a >>>>>> new tree if decided to be the right way to go? >>>>>> >>>>>> Regards, >>>>>> Staffan >>>>>> >> > From jonathan.gibbons at oracle.com Tue Dec 2 22:40:14 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 02 Dec 2014 14:40:14 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547E3CCF.8040009@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> <547E3854.3060705@oracle.com> <547E39B2.4050108@oracle.com> <547E3CCF.8040009@oracle.com> Message-ID: <547E3FCE.2010001@oracle.com> Staffan, That seems to put it on the low end for reasonably being its own repo, if you wanted that, at least, as indicated by the numbers. Here's the file counts for where we are now corba 1192 hotspot 4761 jaxp 2883 jaxws 3748 jdk 22776 langtools 6785 -- Jon On 12/02/2014 02:27 PM, Staffan Friberg wrote: > Hi Jon, > > As part of the initial set of benchmarks we hope to add as part of > this JEP I'm guessing it will be around 200-300 files. This would grow > overtime, but I believe we won't see tens of thousands of files, it is > more likely it will be something like a 1000 files. > > //Staffan > > On 12/02/2014 02:14 PM, Jonathan Gibbons wrote: >> Staffan, >> >> I would also ask how many files are eventually likely to be involved. >> >> If it's tens of files up to low hundreds, then a top level dir makes >> sense. >> >> If it's tens of thousands of files, then a separate repo makes more >> sense. >> >> -- Jon >> >> >> On 12/02/2014 02:08 PM, Staffan Friberg wrote: >>> Hi Chris, >>> >>> Agree, there is no major reason this needs to be a new repository, >>> as I mentioned in the 3 options below it would work well without it. >>> The main thing I want to achieve is that the benchmarks are located >>> on the top level. The suite will contain benchmarks for all parts of >>> the JDK so having it in either jdk or hotspot doesn't feel like it >>> makes sense. If people agree on having it as folder in the top level >>> JDK repository I'm perfectly fine with that. >>> >>> As for building it will most likely not be of the general build >>> process for building the JDK (do not want to increase the >>> compilation time for anyone not requiring the benchmark suite). It >>> would have its own target 'build-microbenchmark' which would depend >>> on 'exploded-image', but not the reverse. >>> >>> //Staffan >>> >>> On 12/02/2014 01:23 PM, Chris Hegarty wrote: >>>> Staffan, >>>> >>>> Having all the benchmarks located in a single place makes sense to >>>> me, but this doesn?t necessarily mean that they need their own >>>> repository, in the forest. >>>> >>>> If I can build, run, and test ( usual development cycle ) without >>>> any dependency on these benchmarks, or their infrastructure, >>>> essential working with a partial forest ( without the ?benchmark? >>>> repository ), then I can see the possible value in having a >>>> separate repository ( so I can skip cloning and updating it ). But, >>>> I?m not sure if that is a reasonable justification for a new >>>> repository, as it is probably at odds with your goals, or maybe not? >>>> >>>> -Chris >>>> >>>> On 2 Dec 2014, at 19:53, Staffan Friberg >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> (Adding the jdk9-dev list to increase the visibility of the >>>>> discussion) >>>>> >>>>> With the multiple sub-repository commit mechanism improved I >>>>> believe this might be less of an issue. JPRT can push JDK and HS >>>>> changes at together and the same functionality should be possible >>>>> to use for this as well. I wonder if the test issue earlier was >>>>> that it was a completely separate repository outside of the JDK >>>>> forest, and less of an issue when being part of the same forest as >>>>> the JDK source code. Perhaps someone from SQE can chime? >>>>> >>>>> Otherwise the main reason for having a separate sub-repository on >>>>> the top level is making it easier to find what benchmarks are >>>>> available and have a single place to add new once avoid any risk >>>>> of name duplication. JMH is superb in filtering during execution >>>>> during runtime so running just a single test or a group of tests >>>>> is very straight forward and the recommended way, rather than >>>>> having multiple benchmark JARs. It also makes the build process >>>>> easier as the building can be done using a single Makefile and a >>>>> single benchmark JAR (actually two, one for JDK 8 compatible tests >>>>> and one for JDK 9) that can be picked up by automatic performance >>>>> testing. >>>>> >>>>> Cheers, >>>>> Staffan >>>>> >>>>> On 12/02/2014 06:48 AM, roger riggs wrote: >>>>>> Hi Staffan, >>>>>> >>>>>> An earlier issue was keeping tests in sync with the code under >>>>>> test, hence >>>>>> the use of test directories within each repository. >>>>>> I think a structure in which the benchmarks for some function and >>>>>> the function >>>>>> itself are in the same repository that is easier to understand >>>>>> and maintain. >>>>>> >>>>>> $.02, Roger >>>>>> >>>>>> >>>>>> On 12/1/2014 7:08 PM, Staffan Friberg wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Hopefully this is the right list for this discussion. >>>>>>> >>>>>>> As part of adding Microbenchmarks to the OpenJDK source tree, >>>>>>> I'm trying to understand how we best would add the benchmark >>>>>>> sources to the existing OpenJDK tree structure. >>>>>>> >>>>>>> Since the microbenchmark suite will cover all parts of the JDK, >>>>>>> covering HotSpot, JDK libraries and Nashorn, it would be >>>>>>> preferred to add the microbenchmark directory as a new top level >>>>>>> directory. Something similar to the following structure. Having >>>>>>> "benchmark" as the top-level directory would allow us to later >>>>>>> add different types of benchmarks without colliding with the >>>>>>> microbenchmark suite. >>>>>>> >>>>>>> / >>>>>>> benchmark/microbenchmark/... >>>>>>> hotspot/... >>>>>>> jdk/... >>>>>>> nashorn/... >>>>>>> >>>>>>> With this as the premise I can see the following 3 options for >>>>>>> how this could be added to the source code layout >>>>>>> >>>>>>> 1. Part of jdk-root repository >>>>>>> * Only makes sense if we want to move in a direction with >>>>>>> fewer >>>>>>> trees (and eventually a single tree) >>>>>>> 2. Part of another already existing tree >>>>>>> * Not sure if this is possible without converting and >>>>>>> moving the >>>>>>> directory to a subdirectory of that tree >>>>>>> 3. New tree in the forest/tree structure >>>>>>> * Most logical option as it follows the current setup and >>>>>>> structure >>>>>>> >>>>>>> >>>>>>> Anyone have any comments and/or concerns on the suggested >>>>>>> directory location and the tree structure in option 3. >>>>>>> >>>>>>> Would the build-dev team be the right group to later help setup >>>>>>> a new tree if decided to be the right way to go? >>>>>>> >>>>>>> Regards, >>>>>>> Staffan >>>>>>> >>> >> > From christian.thalinger at oracle.com Tue Dec 2 22:45:53 2014 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 2 Dec 2014 14:45:53 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547E3FCE.2010001@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> <547E3854.3060705@oracle.com> <547E39B2.4050108@oracle.com> <547E3CCF.8040009@oracle.com> <547E3FCE.2010001@oracle.com> Message-ID: > On Dec 2, 2014, at 2:40 PM, Jonathan Gibbons wrote: > > Staffan, > > That seems to put it on the low end for reasonably being its own repo, if you wanted that, at least, as indicated by the numbers. Do we really want more repositories? > > Here's the file counts for where we are now > > corba 1192 > hotspot 4761 > jaxp 2883 > jaxws 3748 > jdk 22776 > langtools 6785 > > -- Jon > > On 12/02/2014 02:27 PM, Staffan Friberg wrote: >> Hi Jon, >> >> As part of the initial set of benchmarks we hope to add as part of this JEP I'm guessing it will be around 200-300 files. This would grow overtime, but I believe we won't see tens of thousands of files, it is more likely it will be something like a 1000 files. >> >> //Staffan >> >> On 12/02/2014 02:14 PM, Jonathan Gibbons wrote: >>> Staffan, >>> >>> I would also ask how many files are eventually likely to be involved. >>> >>> If it's tens of files up to low hundreds, then a top level dir makes sense. >>> >>> If it's tens of thousands of files, then a separate repo makes more sense. >>> >>> -- Jon >>> >>> >>> On 12/02/2014 02:08 PM, Staffan Friberg wrote: >>>> Hi Chris, >>>> >>>> Agree, there is no major reason this needs to be a new repository, as I mentioned in the 3 options below it would work well without it. The main thing I want to achieve is that the benchmarks are located on the top level. The suite will contain benchmarks for all parts of the JDK so having it in either jdk or hotspot doesn't feel like it makes sense. If people agree on having it as folder in the top level JDK repository I'm perfectly fine with that. >>>> >>>> As for building it will most likely not be of the general build process for building the JDK (do not want to increase the compilation time for anyone not requiring the benchmark suite). It would have its own target 'build-microbenchmark' which would depend on 'exploded-image', but not the reverse. >>>> >>>> //Staffan >>>> >>>> On 12/02/2014 01:23 PM, Chris Hegarty wrote: >>>>> Staffan, >>>>> >>>>> Having all the benchmarks located in a single place makes sense to me, but this doesn?t necessarily mean that they need their own repository, in the forest. >>>>> >>>>> If I can build, run, and test ( usual development cycle ) without any dependency on these benchmarks, or their infrastructure, essential working with a partial forest ( without the ?benchmark? repository ), then I can see the possible value in having a separate repository ( so I can skip cloning and updating it ). But, I?m not sure if that is a reasonable justification for a new repository, as it is probably at odds with your goals, or maybe not? >>>>> >>>>> -Chris >>>>> >>>>> On 2 Dec 2014, at 19:53, Staffan Friberg wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> (Adding the jdk9-dev list to increase the visibility of the discussion) >>>>>> >>>>>> With the multiple sub-repository commit mechanism improved I believe this might be less of an issue. JPRT can push JDK and HS changes at together and the same functionality should be possible to use for this as well. I wonder if the test issue earlier was that it was a completely separate repository outside of the JDK forest, and less of an issue when being part of the same forest as the JDK source code. Perhaps someone from SQE can chime? >>>>>> >>>>>> Otherwise the main reason for having a separate sub-repository on the top level is making it easier to find what benchmarks are available and have a single place to add new once avoid any risk of name duplication. JMH is superb in filtering during execution during runtime so running just a single test or a group of tests is very straight forward and the recommended way, rather than having multiple benchmark JARs. It also makes the build process easier as the building can be done using a single Makefile and a single benchmark JAR (actually two, one for JDK 8 compatible tests and one for JDK 9) that can be picked up by automatic performance testing. >>>>>> >>>>>> Cheers, >>>>>> Staffan >>>>>> >>>>>> On 12/02/2014 06:48 AM, roger riggs wrote: >>>>>>> Hi Staffan, >>>>>>> >>>>>>> An earlier issue was keeping tests in sync with the code under test, hence >>>>>>> the use of test directories within each repository. >>>>>>> I think a structure in which the benchmarks for some function and the function >>>>>>> itself are in the same repository that is easier to understand and maintain. >>>>>>> >>>>>>> $.02, Roger >>>>>>> >>>>>>> >>>>>>> On 12/1/2014 7:08 PM, Staffan Friberg wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Hopefully this is the right list for this discussion. >>>>>>>> >>>>>>>> As part of adding Microbenchmarks to the OpenJDK source tree, I'm trying to understand how we best would add the benchmark sources to the existing OpenJDK tree structure. >>>>>>>> >>>>>>>> Since the microbenchmark suite will cover all parts of the JDK, covering HotSpot, JDK libraries and Nashorn, it would be preferred to add the microbenchmark directory as a new top level directory. Something similar to the following structure. Having "benchmark" as the top-level directory would allow us to later add different types of benchmarks without colliding with the microbenchmark suite. >>>>>>>> >>>>>>>> / >>>>>>>> benchmark/microbenchmark/... >>>>>>>> hotspot/... >>>>>>>> jdk/... >>>>>>>> nashorn/... >>>>>>>> >>>>>>>> With this as the premise I can see the following 3 options for how this could be added to the source code layout >>>>>>>> >>>>>>>> 1. Part of jdk-root repository >>>>>>>> * Only makes sense if we want to move in a direction with fewer >>>>>>>> trees (and eventually a single tree) >>>>>>>> 2. Part of another already existing tree >>>>>>>> * Not sure if this is possible without converting and moving the >>>>>>>> directory to a subdirectory of that tree >>>>>>>> 3. New tree in the forest/tree structure >>>>>>>> * Most logical option as it follows the current setup and structure >>>>>>>> >>>>>>>> >>>>>>>> Anyone have any comments and/or concerns on the suggested directory location and the tree structure in option 3. >>>>>>>> >>>>>>>> Would the build-dev team be the right group to later help setup a new tree if decided to be the right way to go? >>>>>>>> >>>>>>>> Regards, >>>>>>>> Staffan >>>>>>>> >>>> >>> >> > From jonathan.gibbons at oracle.com Tue Dec 2 22:48:22 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 02 Dec 2014 14:48:22 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> <547E3854.3060705@oracle.com> <547E39B2.4050108@oracle.com> <547E3CCF.8040009@oracle.com> <547E3FCE.2010001@oracle.com> Message-ID: <547E41B6.1000909@oracle.com> On 12/02/2014 02:45 PM, Christian Thalinger wrote: >> >On Dec 2, 2014, at 2:40 PM, Jonathan Gibbons wrote: >> > >> >Staffan, >> > >> >That seems to put it on the low end for reasonably being its own repo, if you wanted that, at least, as indicated by the numbers. > Do we really want more repositories? > Conversely, do we really want bigger repositories? :-) (The bike shed is that-a-way.) -- Jon From alejandro.murillo at oracle.com Tue Dec 2 22:51:38 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 02 Dec 2014 15:51:38 -0700 Subject: jdk9-dev: HotSpot Message-ID: <547E427A.1030407@oracle.com> jdk9-hs-2014-11-27 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/c3ee089305d6 http://hg.openjdk.java.net/jdk9/dev/corba/rev/41b8bcd42418 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/214d70baa4db http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/60fbfe34a757 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/bcb36c5cb610 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/e784cdeb95d2 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/caa3490d5aee http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/083bbe7e2d5f Component : VM Status : Go for integration Date : 02/12/2014 at 20:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2014-11-27-152352.amurillo.jdk9-hs-2014-11-27-snapshot Testing: 91 new failures, 2380 known failures, 413995 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 6542634: TEST BUG: MISC_REGRESSION tests need to have minimum timeouts examined 8007993: hotspot.log w/ enabled LogCompilation can be an invalid XML 8033602: wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC 8034005: cannot debug in synchronizer.o or objectMonitor.o on Solaris X86 8042235: redefining method used by multiple MethodHandles crashes VM 8043491: warning LNK4197: export '... ...' specified multiple times; using first specification 8048050: Agent NullPointerException when rmi.port in use 8050079: crash while compiling java.lang.ref.Finalizer::runFinalizer 8054008: Using -XX:-LazyBootClassLoader crashes with ACCESS_VIOLATION on Win 64bit. 8054478: C2: Incorrectly compiled char[] array access crashes JVM 8058148: MaxNodeLimit and LiveNodeCountInliningCutoff 8058209: Race in G1 card scanning could allow scanning of memory covered by PLABs 8058255: Native jbyte Atomic::cmpxchg for supported x86 platforms 8059492: Wrong spelling in assert: "Not initialied properly?" 8059550: JEP-JDK-8043304: Test task: segment overflow w/ empty others 8059677: Thread.getName() instantiates Strings 8059732: improve hotspot_*test targets 8060449: Obsolete command line flags accept arbitrary appendix 8061256: com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java timed out 8062036: ConcurrentMarkThread::slt may be invoked before ConcurrentMarkThread::makeSurrogateLockerThread causing intermittent crashes 8062258: compiler/debug/TraceIterativeGVN.java segfaults in trace_PhaseIterGVN 8062307: 'Reference handler' thread triggers assert w/ TraceThreadEvents 8062536: [TESTBUG] Conflicting GC combinations in jdk tests 8062537: [TESTBUG] Conflicting GC combinations in hotspot tests 8062808: Turn on the -Wreturn-type warning 8062854: move compiler jtreg test to corresponding subfolders and use those in TEST.groups 8064471: Port 8013895: G1: G1SummarizeRSetStats output on Linux needs improvement to AIX 8064473: Improved handling of age during object copy in G1 8064571: java/lang/instrument/IsModifiableClassAgent.java: assert(length > 0) failed: should only be called if table is present 8064580: Move INCLUDE_CDS include section to the end of the include list 8064581: Move INCLUDE_ALL_GCS include section to the end of the include list 8064696: compiler/startup/SmallCodeCacheStartup.java doesn't check exit code 8064701: Some CDS optimizations should be disabled if bootclasspath is modified by JVMTI 8064702: Remove the CMS foreground collector 8064721: The card tables only ever need two covering regions 8064749: -XX:-UseCompilerSafepoints breaks safepoint rendezvous 8064779: Add additional comments for "8062370: Various minor code improvements" 8064786: Fix debug build after 8062808: Turn on the -Wreturn-type warning 8064799: [TESTBUG] JT-Reg Serviceability tests to be run as part of JPRT submit job 8064811: Use THREAD instead of CHECK_NULL in return statements 8064815: Zero+PPC64: Stack overflow when running Maven 8064865: Remove the debug funciontality RotateCMSCollectionTypes for CMS 8065220: Include alternate sa.make file for MacOSX 8065339: Failed compilation does not always trigger a JFR event 'CompilerFailure' 8065346: WB_AddToBootstrapClassLoaderSearch calls JvmtiEnv::create_a_jvmti when not in _thread_in_vm state 8065361: Fixup headers and definitions for INCLUDE_TRACE 8065618: C2 RA incorrectly removes kill projections -- Alejandro From martinrb at google.com Tue Dec 2 22:53:17 2014 From: martinrb at google.com (Martin Buchholz) Date: Tue, 2 Dec 2014 14:53:17 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547E41B6.1000909@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> <547E3854.3060705@oracle.com> <547E39B2.4050108@oracle.com> <547E3CCF.8040009@oracle.com> <547E3FCE.2010001@oracle.com> <547E41B6.1000909@oracle.com> Message-ID: On Tue, Dec 2, 2014 at 2:48 PM, Jonathan Gibbons wrote: >> Do we really want more repositories? >> > > Conversely, do we really want bigger repositories? :-) Yes, we want bigger repositories, not more repositories. Put the benchmarks into the existing repo test directories. Name them all FooBenchmark.java Make it easy to run them, the same way jtreg makes it easy to run tests. Alternatively, start a bench directory hierarchy parallel and organized identically to, existing test directories. > (The bike shed is that-a-way.) > > -- Jon From magnus.ihse.bursie at oracle.com Wed Dec 3 10:58:44 2014 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 03 Dec 2014 11:58:44 +0100 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> <547E3854.3060705@oracle.com> <547E39B2.4050108@oracle.com> <547E3CCF.8040009@oracle.com> <547E3FCE.2010001@oracle.com> Message-ID: <547EECE4.9030809@oracle.com> On 2014-12-02 23:45, Christian Thalinger wrote: >> On Dec 2, 2014, at 2:40 PM, Jonathan Gibbons wrote: >> >> Staffan, >> >> That seems to put it on the low end for reasonably being its own repo, if you wanted that, at least, as indicated by the numbers. > Do we really want more repositories? As long as the number of repositories are around a dozen, one more or less does not really matter. But our model will probably not scale well with hundreds of repos (e.g. if someone would suggest that every module should reside in a separate repo). My suggestion is that the microbenchmarks are put in the top-level repo, if only for the reason that it seems fully possible to split them out to a separate repo some time in the future if it grows too much, but it seems much more unlikely that it will ever be moved back into the top-level repo if we realized it was a stupid idea to put it in a separate repo. /Magnus From xerxes at zafena.se Wed Dec 3 13:37:46 2014 From: xerxes at zafena.se (=?windows-1252?Q?Xerxes_R=E5nby?=) Date: Wed, 03 Dec 2014 14:37:46 +0100 Subject: RFR [JEP 220] Modular Run-Time Images - fix zero build In-Reply-To: References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> Message-ID: <547F122A.2000705@zafena.se> Hi Chris! The build changes introduced a new dependency that sa-jdi.jar is always built. The sa-jdi.jar do not get built for Zero and Itanium builds. Zero is built using the --with-jvm-interpreter=cpp --with-jvm-variants=zero configure options. The sa-jdi.jar also do not exist if you use the --with-import-hotspot= to import alternative OpenJDK JVM such as a pre-compiled CACAO JVM or JamVM libjvm.so . I would suggest to change the jdk/make/Import.gmk and jdk/make/gensrc/Gensrc-jdk.jdi.gmk to first check if sa-jdi.jar exist before adding it to the SA_TARGETS and GENSRC_JDK_JDI something like this: Index: openjdk-jdk9-b38/jdk/make/Import.gmk =================================================================== --- openjdk-jdk9-b38.orig/jdk/make/Import.gmk 2014-11-17 17:34:13.830175424 +0100 +++ openjdk-jdk9-b38/jdk/make/Import.gmk 2014-11-18 09:10:25.420715300 +0100 @@ -221,6 +221,8 @@ # even if zip is already unpacked. $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services: $(HOTSPOT_DIST)/lib/sa-jdi.jar +# sa-jdi.jar do not exist for Itanium and zero +if [ -a $(HOTSPOT_DIST)/lib/sa-jdi.jar ] ; \ SA_TARGETS += $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \ $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services Index: openjdk-jdk9-b38/jdk/make/gensrc/Gensrc-jdk.jdi.gmk =================================================================== --- openjdk-jdk9-b38.orig/jdk/make/gensrc/Gensrc-jdk.jdi.gmk 2014-11-18 08:57:26.504852865 +0100 +++ openjdk-jdk9-b38/jdk/make/gensrc/Gensrc-jdk.jdi.gmk 2014-11-18 09:10:43.348804201 +0100 @@ -78,12 +78,10 @@ $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector $(install-file) +# sa-jdi.jar do not exist for Itanium and zero +if [ -a $(HOTSPOT_DIST)/lib/sa-jdi.jar ] ; \ GENSRC_JDK_JDI += $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector \ $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/META-INF/services/com.sun.jdi.connect.Connector Cheers Xerxes >> From: Chris Hegarty >> Subject: RFR [JEP 220] Modular Run-Time Images >> Date: 20 November 2014 21:39:14 GMT >> To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons , Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie , Mandy Chung , Mark Reinhold , Paul Sandoz , "A. Sundararajan" >> >> This is a review request for the changes for JEP 220: Modular Run-Time Images [1]. >> >> There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the 'To' section of this mail, and they will help address any comments arising from this review request. >> >> The new run-time image structure is defined in JEP 220 [1], and can be seen as a result of building the staging forest [2], or in the early access builds [3]. >> >> Webrevs: >> http://cr.openjdk.java.net/~chegar/8061971/00/ >> >> Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev. >> >> -Chris. >> >> [1] http://openjdk.java.net/jeps/220 >> [2] http://hg.openjdk.java.net/jigsaw/m2/ >> [3] http://openjdk.java.net/projects/jigsaw/ea From erik.joelsson at oracle.com Wed Dec 3 14:30:16 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 03 Dec 2014 15:30:16 +0100 Subject: RFR [JEP 220] Modular Run-Time Images - fix zero build In-Reply-To: <547F122A.2000705@zafena.se> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <547F122A.2000705@zafena.se> Message-ID: <547F1E78.8080709@oracle.com> Hello Xerxes, Thanks for the suggestion. I have created https://bugs.openjdk.java.net/browse/JDK-8066589 to track this issue. Unfortunately we won't have time to fix it before pushing JEP 220 to jdk9. I hope this won't inconvenience you too much. Your suggested patch does correctly highlight the problem areas, but will not work since gnu make does not accept shell logic outside of recipes or $(shell ...) constructs. /Erik On 2014-12-03 14:37, Xerxes R?nby wrote: > Hi Chris! > > The build changes introduced a new dependency that sa-jdi.jar is > always built. > > The sa-jdi.jar do not get built for Zero and Itanium builds. > Zero is built using the --with-jvm-interpreter=cpp > --with-jvm-variants=zero configure options. > > The sa-jdi.jar also do not exist if you use the --with-import-hotspot= > to import alternative OpenJDK JVM such as > a pre-compiled CACAO JVM or JamVM libjvm.so . > > I would suggest to change the jdk/make/Import.gmk and > jdk/make/gensrc/Gensrc-jdk.jdi.gmk to first check if sa-jdi.jar > exist before adding it to the SA_TARGETS and GENSRC_JDK_JDI something > like this: > > Index: openjdk-jdk9-b38/jdk/make/Import.gmk > =================================================================== > --- openjdk-jdk9-b38.orig/jdk/make/Import.gmk 2014-11-17 > 17:34:13.830175424 +0100 > +++ openjdk-jdk9-b38/jdk/make/Import.gmk 2014-11-18 > 09:10:25.420715300 +0100 > @@ -221,6 +221,8 @@ > # even if zip is already unpacked. > $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services: > $(HOTSPOT_DIST)/lib/sa-jdi.jar > > +# sa-jdi.jar do not exist for Itanium and zero > +if [ -a $(HOTSPOT_DIST)/lib/sa-jdi.jar ] ; \ > SA_TARGETS += > $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \ > $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services > > Index: openjdk-jdk9-b38/jdk/make/gensrc/Gensrc-jdk.jdi.gmk > =================================================================== > --- openjdk-jdk9-b38.orig/jdk/make/gensrc/Gensrc-jdk.jdi.gmk > 2014-11-18 08:57:26.504852865 +0100 > +++ openjdk-jdk9-b38/jdk/make/gensrc/Gensrc-jdk.jdi.gmk 2014-11-18 > 09:10:43.348804201 +0100 > @@ -78,12 +78,10 @@ > $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector > $(install-file) > > +# sa-jdi.jar do not exist for Itanium and zero > +if [ -a $(HOTSPOT_DIST)/lib/sa-jdi.jar ] ; \ > GENSRC_JDK_JDI += > $(SUPPORT_OUTPUTDIR)/gensrc/jdk.jdi/META-INF/services/com.sun.jdi.connect.Connector > \ > $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/META-INF/services/com.sun.jdi.connect.Connector > > > Cheers > Xerxes > > > >>> From: Chris Hegarty >>> Subject: RFR [JEP 220] Modular Run-Time Images >>> Date: 20 November 2014 21:39:14 GMT >>> To: jigsaw-dev , jdk9-dev >>> , build-dev , >>> Alan Bateman , Alex Buckley >>> , Chris Hegarty , >>> Erik Joelsson , Jonathan Gibbons >>> , Karen Kinnear >>> , "Jim Laskey (Oracle)" >>> , Magnus Ihse Bursie >>> , Mandy Chung >>> , Mark Reinhold , >>> Paul Sandoz , "A. Sundararajan" >>> >>> >>> This is a review request for the changes for JEP 220: Modular >>> Run-Time Images [1]. >>> >>> There are a number of individuals responsible for these changes. >>> Some, possibly not all, are explicitly listed in the 'To' section of >>> this mail, and they will help address any comments arising from this >>> review request. >>> >>> The new run-time image structure is defined in JEP 220 [1], and can >>> be seen as a result of building the staging forest [2], or in the >>> early access builds [3]. >>> >>> Webrevs: >>> http://cr.openjdk.java.net/~chegar/8061971/00/ >>> >>> Due to the significant impact of these changes, a JDK 9 promotion >>> has been tentatively reserved for their integration. All comments >>> are welcome, although given the nature of the changes then we might >>> have to create separate issues in JIRA to address some of them later >>> in jdk9/dev. >>> >>> -Chris. >>> >>> [1] http://openjdk.java.net/jeps/220 >>> [2] http://hg.openjdk.java.net/jigsaw/m2/ >>> [3] http://openjdk.java.net/projects/jigsaw/ea > From pointo1d at gmail.com Wed Dec 3 14:47:00 2014 From: pointo1d at gmail.com (Dave Pointon) Date: Wed, 3 Dec 2014 14:47:00 +0000 Subject: RFR [JEP 220] Modular Run-Time Images - fix zero build In-Reply-To: <547F1E78.8080709@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <547F122A.2000705@zafena.se> <547F1E78.8080709@oracle.com> Message-ID: Hmmm , Would it not be possible to modify Xerxes' suggested patch to do something along the lines of ... # sa-jdi.jar do not exist for Itanium and zero ifeq ($(shell if test -a $(HOTSPOT_DIST)/lib/sa-jdi.jar; then echo N; fi),N) SA_TARGETS += \ $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \ $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services endif Just a thought -- Dave Pointon FIAP MBCS - ? contractor engaged by IBM? Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe On 3 December 2014 at 14:30, Erik Joelsson wrote: > Hello Xerxes, > > Thanks for the suggestion. I have created https://bugs.openjdk.java.net/ > browse/JDK-8066589 to track this issue. Unfortunately we won't have time > to fix it before pushing JEP 220 to jdk9. I hope this won't inconvenience > you too much. > > Your suggested patch does correctly highlight the problem areas, but will > not work since gnu make does not accept shell logic outside of recipes or > $(shell ...) constructs. > > /Erik > > ?? > From erik.joelsson at oracle.com Wed Dec 3 17:46:15 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 03 Dec 2014 18:46:15 +0100 Subject: RFR [JEP 220] Modular Run-Time Images - fix zero build In-Reply-To: References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <547F122A.2000705@zafena.se> <547F1E78.8080709@oracle.com> Message-ID: <547F4C67.6030608@oracle.com> Yes, it can be modified. My preferred variant for file existence checking in make is "ifneq ($(wildcard /path/to/file), )". Also, in Gensrc-jdk.jdi.gmk, I would probably like some other logical condition to check on than sa-jdi.jar. We will address this at some point soon. /Erik On 2014-12-03 15:47, Dave Pointon wrote: > Hmmm , > > Would it not be possible to modify Xerxes' suggested patch to do > something along the lines of ... > > # sa-jdi.jar do not exist for Itanium and zero > ifeq ($(shell if test -a $(HOTSPOT_DIST)/lib/sa-jdi.jar; then echo N; > fi),N) > SA_TARGETS += \ > $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \ > $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa > .services > endif > > Just a thought > > -- > Dave Pointon FIAP MBCS - > ? contractor engaged by IBM? > > > Now I saw, tho' too late, the folly of beginning a work before we > count the cost and before we we judge rightly of our strength to go > thro' with it - Robinson Crusoe > > On 3 December 2014 at 14:30, Erik Joelsson > wrote: > > Hello Xerxes, > > Thanks for the suggestion. I have created > https://bugs.openjdk.java.net/browse/JDK-8066589 to track this > issue. Unfortunately we won't have time to fix it before pushing > JEP 220 to jdk9. I hope this won't inconvenience you too much. > > Your suggested patch does correctly highlight the problem areas, > but will not work since gnu make does not accept shell logic > outside of recipes or $(shell ...) constructs. > > /Erik > > ? ? > > From pointo1d at gmail.com Wed Dec 3 18:13:52 2014 From: pointo1d at gmail.com (Dave Pointon) Date: Wed, 3 Dec 2014 18:13:52 +0000 Subject: RFR [JEP 220] Modular Run-Time Images - fix zero build In-Reply-To: <547F4C67.6030608@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <547F122A.2000705@zafena.se> <547F1E78.8080709@oracle.com> <547F4C67.6030608@oracle.com> Message-ID: Yep , I like that even more, Erik :-) -- Dave Pointon FIAP MBCS Now I saw, tho' too late, the folly of beginning a work before we count the cost and before we we judge rightly of our strength to go thro' with it - Robinson Crusoe On 3 December 2014 at 17:46, Erik Joelsson wrote: > Yes, it can be modified. My preferred variant for file existence checking > in make is "ifneq ($(wildcard /path/to/file), )". Also, in > Gensrc-jdk.jdi.gmk, I would probably like some other logical condition to > check on than sa-jdi.jar. We will address this at some point soon. > > /Erik > > On 2014-12-03 15:47, Dave Pointon wrote: > > Hmmm , > > Would it not be possible to modify Xerxes' suggested patch to do > something along the lines of ... > > # sa-jdi.jar do not exist for Itanium and zero > ifeq ($(shell if test -a $(HOTSPOT_DIST)/lib/sa-jdi.jar; then echo N; > fi),N) > SA_TARGETS += \ > $(JDK_OUTPUTDIR)/modules/jdk.hotspot.agent/_the.sa.jar.unpacked \ > $(SUPPORT_OUTPUTDIR)/gensrc/jdk.hotspot.agent/_the.sa.services > endif > > Just a thought > > -- > Dave Pointon FIAP MBCS - > ? contractor engaged by IBM? > > > Now I saw, tho' too late, the folly of beginning a work before we count > the cost and before we we judge rightly of our strength to go thro' with it > - Robinson Crusoe > > On 3 December 2014 at 14:30, Erik Joelsson > wrote: > >> Hello Xerxes, >> >> Thanks for the suggestion. I have created >> https://bugs.openjdk.java.net/browse/JDK-8066589 to track this issue. >> Unfortunately we won't have time to fix it before pushing JEP 220 to jdk9. >> I hope this won't inconvenience you too much. >> >> Your suggested patch does correctly highlight the problem areas, but will >> not work since gnu make does not accept shell logic outside of recipes or >> $(shell ...) constructs. >> >> /Erik >> >> ? ? >> > > > From mark.reinhold at oracle.com Wed Dec 3 20:01:11 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 03 Dec 2014 12:01:11 -0800 Subject: JDK 9 images are now modular Message-ID: <20141203120111.45613@eggemoggin.niobe.net> FYI, the initial changesets for JEP 220: Modular Run-Time Images [1] were pushed just a few minutes ago. If you build JDK 9 yourself, or if you download the next early-access build [2] (which should be available tomorrow), you'll see all of the changes documented in JEP 220. To summarize (please see the JEP for details): - The "jre" subdirectory is no longer present in JDK images. - The user-editable configuration files in the "lib" subdirectory have been moved to the new "conf" directory. - The endorsed-standards override mechanism has been removed. - The extension mechanism has been removed. - rt.jar, tools.jar, and dt.jar have been removed. - A new URI scheme for naming stored modules, classes, and resources has been defined. - For tools that previously accessed rt.jar directly, a built-in NIO file-system provider has been defined to provide access to the class and resource files within a run-time image. We have a few open issues to finish up, so further changes will follow for this JEP, but none will be as disruptive as today's merge. - Mark [1] http://openjdk.java.net/jeps/220 [2] https://jdk9.java.net/download/ From xerxes at zafena.se Thu Dec 4 12:58:54 2014 From: xerxes at zafena.se (=?windows-1252?Q?Xerxes_R=E5nby?=) Date: Thu, 04 Dec 2014 13:58:54 +0100 Subject: RFR [JEP 220] Modular Run-Time Images - compact profiles footprint In-Reply-To: References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> Message-ID: <54805A8E.4030806@zafena.se> The footprint of the compact profiles have been inflated by ~12Mb each after the JEP 220 changes. before # du -s -h j2re-compact1-image 17.9M j2re-compact1-image # du -s -h j2re-compact2-image 28.7M j2re-compact2-image # du -s -h j2re-compact3-image 35.5M j2re-compact3-image after # du -s -h jre-compact1 31.3M jre-compact1 # du -s -h jre-compact2 41.5M jre-compact2 # du -s -h jre-compact3 47.4M jre-compact3 The attached file compact1.diff.tar.gz contains the list diff of the files bundled in the j2re-compact1-image/lib/rt.jar compared to jre-compact1/lib/*.jimage most of the class diff is located in com/sun/security/ntlm com/sun/crypto javax/crypto sun/net/www/protocol/http/ntlm sun/net/www/protocol/ftp sun/net/www/protocol/mailto sun/net/ftp sun/net/smtp sun/net/dns sun/util/resources <- a lot of extra internationalized classes sun/security/ssl sun/security/ec sun/security/pkcs11 sun/text/resources <- a lot of extra internationalized classes Cheers Xerxes Den 2014-11-20 22:41, Chris Hegarty skrev: >> From: Chris Hegarty >> Subject: RFR [JEP 220] Modular Run-Time Images >> Date: 20 November 2014 21:39:14 GMT >> To: jigsaw-dev , jdk9-dev , build-dev , Alan Bateman , Alex Buckley , Chris Hegarty , Erik Joelsson , Jonathan Gibbons , Karen Kinnear , "Jim Laskey (Oracle)" , Magnus Ihse Bursie , Mandy Chung , Mark Reinhold , Paul Sandoz , "A. Sundararajan" >> >> This is a review request for the changes for JEP 220: Modular Run-Time Images [1]. >> >> There are a number of individuals responsible for these changes. Some, possibly not all, are explicitly listed in the 'To' section of this mail, and they will help address any comments arising from this review request. >> >> The new run-time image structure is defined in JEP 220 [1], and can be seen as a result of building the staging forest [2], or in the early access builds [3]. >> >> Webrevs: >> http://cr.openjdk.java.net/~chegar/8061971/00/ >> >> Due to the significant impact of these changes, a JDK 9 promotion has been tentatively reserved for their integration. All comments are welcome, although given the nature of the changes then we might have to create separate issues in JIRA to address some of them later in jdk9/dev. >> >> -Chris. >> >> [1] http://openjdk.java.net/jeps/220 >> [2] http://hg.openjdk.java.net/jigsaw/m2/ >> [3] http://openjdk.java.net/projects/jigsaw/ea From xerxes at zafena.se Thu Dec 4 13:03:31 2014 From: xerxes at zafena.se (=?windows-1252?Q?Xerxes_R=E5nby?=) Date: Thu, 04 Dec 2014 14:03:31 +0100 Subject: RFR [JEP 220] Modular Run-Time Images - compact profiles footprint In-Reply-To: <54805A8E.4030806@zafena.se> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <54805A8E.4030806@zafena.se> Message-ID: <54805BA3.9040705@zafena.se> Den 2014-12-04 13:58, Xerxes R?nby skrev: > The footprint of the compact profiles have been inflated by ~12Mb each > after the JEP 220 changes. > > before > # du -s -h j2re-compact1-image > 17.9M j2re-compact1-image > # du -s -h j2re-compact2-image > 28.7M j2re-compact2-image > # du -s -h j2re-compact3-image > 35.5M j2re-compact3-image > > after > # du -s -h jre-compact1 > 31.3M jre-compact1 > # du -s -h jre-compact2 > 41.5M jre-compact2 > # du -s -h jre-compact3 > 47.4M jre-compact3 > > The attached file compact1.diff.tar.gz contains the list diff of the > files bundled in the > j2re-compact1-image/lib/rt.jar compared to jre-compact1/lib/*.jimage compact1.diff.tar.gz is attached in this mail. > most of the class diff is located in > > com/sun/security/ntlm > com/sun/crypto > javax/crypto > sun/net/www/protocol/http/ntlm > sun/net/www/protocol/ftp > sun/net/www/protocol/mailto > sun/net/ftp > sun/net/smtp > sun/net/dns > sun/util/resources <- a lot of extra internationalized classes > sun/security/ssl > sun/security/ec > sun/security/pkcs11 > sun/text/resources <- a lot of extra internationalized classes > > Cheers > Xerxes From Alan.Bateman at oracle.com Thu Dec 4 13:48:55 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Dec 2014 13:48:55 +0000 Subject: RFR [JEP 220] Modular Run-Time Images - compact profiles footprint In-Reply-To: <54805A8E.4030806@zafena.se> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <54805A8E.4030806@zafena.se> Message-ID: <54806647.5050300@oracle.com> On 04/12/2014 12:58, Xerxes R?nby wrote: > The footprint of the compact profiles have been inflated by ~12Mb each > after the JEP 220 changes. > > before > # du -s -h j2re-compact1-image > 17.9M j2re-compact1-image > # du -s -h j2re-compact2-image > 28.7M j2re-compact2-image > # du -s -h j2re-compact3-image > 35.5M j2re-compact3-image > > after > # du -s -h jre-compact1 > 31.3M jre-compact1 > # du -s -h jre-compact2 > 41.5M jre-compact2 > # du -s -h jre-compact3 > 47.4M jre-compact3 > > The attached file compact1.diff.tar.gz contains the list diff of the > files bundled in the > j2re-compact1-image/lib/rt.jar compared to jre-compact1/lib/*.jimage > most of the class diff is located in > > com/sun/security/ntlm > com/sun/crypto > javax/crypto > sun/net/www/protocol/http/ntlm > sun/net/www/protocol/ftp > sun/net/www/protocol/mailto > sun/net/ftp > sun/net/smtp > sun/net/dns > sun/util/resources <- a lot of extra internationalized classes > sun/security/ssl > sun/security/ec > sun/security/pkcs11 > sun/text/resources <- a lot of extra internationalized classes The release file in the top directory of the runtime image gives a good indication as to what is going on. If you look at the value of the MODULES key then you'll the see the modules that are actually linked in. For jre-compact1 then you should see a line like this: MODULES="java.base jdk.localedata java.scripting java.logging java.compact1 jdk.crypto.ec jdk.crypto.pkcs11" The java.* modules are the modules that make up compact1, the jdk.* modules are additional service providers linked into the image. The service providers aren't strictly required to be there, we've just chosen to include them so that "profiles" make target gives us images that approximately correspond to what we had previously. If you want to play around with leaving them out then look in make/Images.gmk and COMPACT_EXTRA_MODULES. Going forward then I expect we will have a tool that will allow for a lot more flexibility to create images with just the modules that you want (and their transitive dependences of course). So I think the bulk of the difference that you are seeing is explained by the service providers and mostly jdk.localedata. That module is big and contains all of non-US_en JRE locale data and all of the CLDR data. We still need to figure out what how to split this, you might recall the discussion on i18n-dev and jigsaw-dev where they was some recent discussion on this. It's also listed in JEP 200 as an open issue. So when comparing to JDK 8 or previous JDK 9 compact profile builds then think of the new images has having the equivalent of both localedata.jar and cldrdata.jar present. If you edit COMPACT_EXTRA_MODULES to remove jdk.localdata.jar then it should make it easier to compare. Another thing to point out is that rt.jar isn't everything in the legacy image. You need to take account of jce.jar, jsse.jar and ext/sunjce_provider.jar. That should explain the javax.crypto, com.sun.crypto and sun.security.ssl packages in your list. Another thing to mention is the java.base module currently contains a few legacy items that we previously stripped out of the profiles builds in JDK 8. We still need to figure out what to do with these. The ftp and smtp protocol handlers come to mind, also the NTLM htto authentication scheme. At one point we have a "compat" module for legacy stuff that people might want for compatibility reasons. So expect some tweaking here, we know people focused on footprint will not thank us for bringing back legacy stuff. A few final point to mention. (a) there are a few additional launchers (and maybe debug info/diz files if build with those) that were not there previously. This is a consequence of modularization where modules with launchers and where the classes for those launchers were previously in tools.jar. (b) there are some additional classes that didn't previously exist in JDK 9, this is to support the new image format. I expect some churn with those over the next few months. So hopefully this helps to explain what you are seeing. I think folks might be interested in see j2re-image vs. jre and j2sdk-image vs. jdk sizes too. -Alan. From naoto.sato at oracle.com Thu Dec 4 16:38:48 2014 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 04 Dec 2014 08:38:48 -0800 Subject: RFR [JEP 220] Modular Run-Time Images - compact profiles footprint In-Reply-To: <54806647.5050300@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <54805A8E.4030806@zafena.se> <54806647.5050300@oracle.com> Message-ID: <54808E18.4070403@oracle.com> Quick question. Why is jdk.localedata module included in the compact profiles? The data there used to be in lib/ext/localedata.jar and lib/ext/cldrdata.jar which weren't included in those compact profiles. Naoto On 12/4/14, 5:48 AM, Alan Bateman wrote: > On 04/12/2014 12:58, Xerxes R?nby wrote: >> The footprint of the compact profiles have been inflated by ~12Mb each >> after the JEP 220 changes. >> >> before >> # du -s -h j2re-compact1-image >> 17.9M j2re-compact1-image >> # du -s -h j2re-compact2-image >> 28.7M j2re-compact2-image >> # du -s -h j2re-compact3-image >> 35.5M j2re-compact3-image >> >> after >> # du -s -h jre-compact1 >> 31.3M jre-compact1 >> # du -s -h jre-compact2 >> 41.5M jre-compact2 >> # du -s -h jre-compact3 >> 47.4M jre-compact3 >> >> The attached file compact1.diff.tar.gz contains the list diff of the >> files bundled in the >> j2re-compact1-image/lib/rt.jar compared to jre-compact1/lib/*.jimage >> most of the class diff is located in >> >> com/sun/security/ntlm >> com/sun/crypto >> javax/crypto >> sun/net/www/protocol/http/ntlm >> sun/net/www/protocol/ftp >> sun/net/www/protocol/mailto >> sun/net/ftp >> sun/net/smtp >> sun/net/dns >> sun/util/resources <- a lot of extra internationalized classes >> sun/security/ssl >> sun/security/ec >> sun/security/pkcs11 >> sun/text/resources <- a lot of extra internationalized classes > > The release file in the top directory of the runtime image gives a good > indication as to what is going on. If you look at the value of the > MODULES key then you'll the see the modules that are actually linked in. > For jre-compact1 then you should see a line like this: > > MODULES="java.base jdk.localedata java.scripting java.logging > java.compact1 jdk.crypto.ec jdk.crypto.pkcs11" > > The java.* modules are the modules that make up compact1, the jdk.* > modules are additional service providers linked into the image. The > service providers aren't strictly required to be there, we've just > chosen to include them so that "profiles" make target gives us images > that approximately correspond to what we had previously. If you want to > play around with leaving them out then look in make/Images.gmk and > COMPACT_EXTRA_MODULES. Going forward then I expect we will have a tool > that will allow for a lot more flexibility to create images with just > the modules that you want (and their transitive dependences of course). > > So I think the bulk of the difference that you are seeing is explained > by the service providers and mostly jdk.localedata. That module is big > and contains all of non-US_en JRE locale data and all of the CLDR data. > We still need to figure out what how to split this, you might recall the > discussion on i18n-dev and jigsaw-dev where they was some recent > discussion on this. It's also listed in JEP 200 as an open issue. > > So when comparing to JDK 8 or previous JDK 9 compact profile builds then > think of the new images has having the equivalent of both localedata.jar > and cldrdata.jar present. If you edit COMPACT_EXTRA_MODULES to remove > jdk.localdata.jar then it should make it easier to compare. > > Another thing to point out is that rt.jar isn't everything in the legacy > image. You need to take account of jce.jar, jsse.jar and > ext/sunjce_provider.jar. That should explain the javax.crypto, > com.sun.crypto and sun.security.ssl packages in your list. > > Another thing to mention is the java.base module currently contains a > few legacy items that we previously stripped out of the profiles builds > in JDK 8. We still need to figure out what to do with these. The ftp and > smtp protocol handlers come to mind, also the NTLM htto authentication > scheme. At one point we have a "compat" module for legacy stuff that > people might want for compatibility reasons. So expect some tweaking > here, we know people focused on footprint will not thank us for bringing > back legacy stuff. > > A few final point to mention. (a) there are a few additional launchers > (and maybe debug info/diz files if build with those) that were not there > previously. This is a consequence of modularization where modules with > launchers and where the classes for those launchers were previously in > tools.jar. (b) there are some additional classes that didn't previously > exist in JDK 9, this is to support the new image format. I expect some > churn with those over the next few months. > > So hopefully this helps to explain what you are seeing. I think folks > might be interested in see j2re-image vs. jre and j2sdk-image vs. jdk > sizes too. > > -Alan. From Alan.Bateman at oracle.com Thu Dec 4 17:11:19 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 04 Dec 2014 17:11:19 +0000 Subject: RFR [JEP 220] Modular Run-Time Images - compact profiles footprint In-Reply-To: <54808E18.4070403@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <54805A8E.4030806@zafena.se> <54806647.5050300@oracle.com> <54808E18.4070403@oracle.com> Message-ID: <548095B7.2020809@oracle.com> On 04/12/2014 16:38, Naoto Sato wrote: > Quick question. Why is jdk.localedata module included in the compact > profiles? The data there used to be in lib/ext/localedata.jar and > lib/ext/cldrdata.jar which weren't included in those compact profiles. > > Naoto The "profiles" make target on JDK 8 (and JDK 9 before yesterday) always included localedata.jar in the images. I would expect this would be pruned or removed before deploying to an embedded device of course, same thing for the security providers that get included by default. We've now moved to world where the runtime images are created from a set of modules and this should give a lot of flexibility once. We're just not there yet with locale data so we have to temporarily link in the big jdk.localedata module so that the profiles images have all locales. -Alan. From staffan.friberg at oracle.com Thu Dec 4 17:51:33 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Thu, 04 Dec 2014 09:51:33 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547EECE4.9030809@oracle.com> References: <547D02E5.8070507@oracle.com> <547DD133.1050706@oracle.com> <547E18BE.2070201@oracle.com> <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com> <547E3854.3060705@oracle.com> <547E39B2.4050108@oracle.com> <547E3CCF.8040009@oracle.com> <547E3FCE.2010001@oracle.com> <547EECE4.9030809@oracle.com> Message-ID: <54809F25.90702@oracle.com> On 12/03/2014 02:58 AM, Magnus Ihse Bursie wrote: > On 2014-12-02 23:45, Christian Thalinger wrote: >>> On Dec 2, 2014, at 2:40 PM, Jonathan Gibbons >>> wrote: >>> >>> Staffan, >>> >>> That seems to put it on the low end for reasonably being its own >>> repo, if you wanted that, at least, as indicated by the numbers. >> Do we really want more repositories? > As long as the number of repositories are around a dozen, one more or > less does not really matter. But our model will probably not scale > well with hundreds of repos (e.g. if someone would suggest that every > module should reside in a separate repo). > > My suggestion is that the microbenchmarks are put in the top-level > repo, if only for the reason that it seems fully possible to split > them out to a separate repo some time in the future if it grows too > much, but it seems much more unlikely that it will ever be moved back > into the top-level repo if we realized it was a stupid idea to put it > in a separate repo. > > /Magnus I like this idea, and agree that shifting in the opposite direction is probably something that would be much more work than breaking it out if size becomes an issue further down the road. When moving a directory to a new sub-repository, is there any concern about the diffs for that set of files still lingering in the top repo, or can those be moved as well? Thanks, Staffan From mark.reinhold at oracle.com Thu Dec 4 19:43:20 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 04 Dec 2014 11:43:20 -0800 Subject: Proposed to Drop: JEP 198: Light-Weight JSON API Message-ID: <20141204114320.655240@eggemoggin.niobe.net> This JEP [1] would be a useful addition to the platform but, in the grand scheme of things, it's not as important as the other features that Oracle is funding, or considering funding, for JDK 9. I've therefore moved it to the Proposed to Drop state. We may reconsider this JEP for JDK 10 or a later release, especially if new language features such as value types [2] and generics over primitive types (JEP 218 [3]) enable a more compact and expressive API. - Mark [1] http://openjdk.java.net/jeps/198 [2] http://cr.openjdk.java.net/~jrose/values/values-0.html [3] http://openjdk.java.net/jeps/218 From mark.reinhold at oracle.com Thu Dec 4 21:56:54 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 04 Dec 2014 13:56:54 -0800 Subject: JEPs proposed to target, or drop from, JDK 9 (2014/12/4) Message-ID: <20141204135654.798484@eggemoggin.niobe.net> The following JEPs have been placed into the "Proposed to Target" state by their respective owners after discussion and review: 228: Add More Diagnostic Commands http://openjdk.java.net/jeps/228 229: Create PKCS12 Keystores by Default http://openjdk.java.net/jeps/229 The following JEP has been placed in the "Proposed to Drop" state: 198: Light-Weight JSON API http://openjdk.java.net/jeps/198 Feedback on these proposals is more than welcome, as are reasoned objections. If no such objections are raised by 22:00 UTC next Thursday, 11 December, or if they're raised and then satisfactorily answered, then per the JEP 2.0 process proposal [1] I'll make these proposed changes. (This information is also available on the JDK 9 Project Page [2]). - Mark [1] http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html[3] [2] http://openjdk.java.net/projects/jdk9/[4] From mark.reinhold at oracle.com Fri Dec 5 00:11:47 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 04 Dec 2014 16:11:47 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <54809F25.90702@oracle.com> References: <547D02E5.8070507@oracle.com>, <547DD133.1050706@oracle.com>, <547E18BE.2070201@oracle.com>, <29B2F131-7CAE-4BA3-B6C7-9414431F2982@oracle.com>, <547E3854.3060705@oracle.com>, <547E39B2.4050108@oracle.com>, <547E3CCF.8040009@oracle.com>, <547E3FCE.2010001@oracle.com>, , <547EECE4.9030809@oracle.com>, <54809F25.90702@oracle.com> Message-ID: <20141204161147.170828@eggemoggin.niobe.net> 2014/12/4 9:51 -0800, staffan.friberg at oracle.com: > On 12/03/2014 02:58 AM, Magnus Ihse Bursie wrote: >> ... >> >> My suggestion is that the microbenchmarks are put in the top-level >> repo, if only for the reason that it seems fully possible to split >> them out to a separate repo some time in the future if it grows too >> much, but it seems much more unlikely that it will ever be moved back >> into the top-level repo if we realized it was a stupid idea to put it >> in a separate repo. > > I like this idea, and agree that shifting in the opposite direction is > probably something that would be much more work than breaking it out if > size becomes an issue further down the road. > > When moving a directory to a new sub-repository, is there any concern > about the diffs for that set of files still lingering in the top repo, > or can those be moved as well? The files can be moved, but their earlier history will remain in the top-level repo. Given the forest structure that we have today, and the fact that this set of tests could grow to a thousand or so files over time, I think it makes more sense to place them in a new top-level repo of their own. In the (very?) long term we might dramatically reduce the number of repositories but that will be a huge change, and in the mean time adding one more repo is a pretty minor change and also consistent with current practice. A pleasant property of the current root repo is that it's very small (< 9MB) and easy to understand, containing mostly makefiles, build utilities, and some metadata. Placing tests in it would start turning it into more of a grab-bag. I don't think it makes sense to split the microbenchmarks across different repos, as we already do with the unit and regression tests. The latter types of tests primarily address the correctness of the code in one repo, on the assumption that any code in other repos upon which that code depends is correct. In most cases, therefore, it's pretty easy to tell whether a unit or regression test is specific to, say, the jdk repo, the langtools repo, or some other repo. Microbenchmarks, by contrast, address the performance of a particular API, language construct, or other programmatic interface and also all of the code upon which it depends, regardless of which repo it came from. By nature they're more holistic, and so less strongly associated with the code in any particular repo. - Mark From david.holmes at oracle.com Fri Dec 5 00:34:01 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Dec 2014 10:34:01 +1000 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <547D02E5.8070507@oracle.com> References: <547D02E5.8070507@oracle.com> Message-ID: <5480FD79.2050802@oracle.com> Hi Staffan, On 2/12/2014 10:08 AM, Staffan Friberg wrote: > Hi, > > Hopefully this is the right list for this discussion. > > As part of adding Microbenchmarks to the OpenJDK source tree, I'm trying > to understand how we best would add the benchmark sources to the > existing OpenJDK tree structure. Is there a reason this needs to be inside the OpenJDK instead of a stand-alone project? If it ends up in its own repo and the repo is not needed by anything else, then it is already like a stand-alone project. David > Since the microbenchmark suite will cover all parts of the JDK, covering > HotSpot, JDK libraries and Nashorn, it would be preferred to add the > microbenchmark directory as a new top level directory. Something similar > to the following structure. Having "benchmark" as the top-level > directory would allow us to later add different types of benchmarks > without colliding with the microbenchmark suite. > > / > benchmark/microbenchmark/... > hotspot/... > jdk/... > nashorn/... > > With this as the premise I can see the following 3 options for how this > could be added to the source code layout > > 1. Part of jdk-root repository > * Only makes sense if we want to move in a direction with fewer > trees (and eventually a single tree) > 2. Part of another already existing tree > * Not sure if this is possible without converting and moving the > directory to a subdirectory of that tree > 3. New tree in the forest/tree structure > * Most logical option as it follows the current setup and structure > > > Anyone have any comments and/or concerns on the suggested directory > location and the tree structure in option 3. > > Would the build-dev team be the right group to later help setup a new > tree if decided to be the right way to go? > > Regards, > Staffan > From joe.darcy at oracle.com Fri Dec 5 06:23:22 2014 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 04 Dec 2014 22:23:22 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <5480FD79.2050802@oracle.com> References: <547D02E5.8070507@oracle.com> <5480FD79.2050802@oracle.com> Message-ID: <54814F5A.9010009@oracle.com> Hello, On 12/4/2014 4:34 PM, David Holmes wrote: > Hi Staffan, > > On 2/12/2014 10:08 AM, Staffan Friberg wrote: >> Hi, >> >> Hopefully this is the right list for this discussion. >> >> As part of adding Microbenchmarks to the OpenJDK source tree, I'm trying >> to understand how we best would add the benchmark sources to the >> existing OpenJDK tree structure. > > Is there a reason this needs to be inside the OpenJDK instead of a > stand-alone project? If it ends up in its own repo and the repo is not > needed by anything else, then it is already like a stand-alone project. I think David is raising a good question here. A related question is if we want to update/fix the microbenchmarks, in how many release trains will we want to make that fix? If the expected answer is much greater than one, to me that would seem to me to argue for a separate forest in the overall OpenJDK effort, but not bundled into a particular release. For example, in the past, the webrev.ksh script was included in the JDK forest. That was an improvement over every engineer having his or her personal fork, but still made keeping webrev updated unnecessarily difficult since any changes would need to be done multiple time and there is nothing fundamentally binding a version of webrev to a particular JDK release. Likewise, even though (to my knowledge) jtreg is only used for testing the JDK, jtreg has its own repository and release schedule separate from any JDK release. So if the microbenchmarks are to a first-approximation version agnostic, then they should probably have a forest not associated with a JDK release. If they are tightly bound to a release, that argues for putting them into the JDK forest itself. -Joe > > David > >> Since the microbenchmark suite will cover all parts of the JDK, covering >> HotSpot, JDK libraries and Nashorn, it would be preferred to add the >> microbenchmark directory as a new top level directory. Something similar >> to the following structure. Having "benchmark" as the top-level >> directory would allow us to later add different types of benchmarks >> without colliding with the microbenchmark suite. >> >> / >> benchmark/microbenchmark/... >> hotspot/... >> jdk/... >> nashorn/... >> >> With this as the premise I can see the following 3 options for how this >> could be added to the source code layout >> >> 1. Part of jdk-root repository >> * Only makes sense if we want to move in a direction with fewer >> trees (and eventually a single tree) >> 2. Part of another already existing tree >> * Not sure if this is possible without converting and moving the >> directory to a subdirectory of that tree >> 3. New tree in the forest/tree structure >> * Most logical option as it follows the current setup and >> structure >> >> >> Anyone have any comments and/or concerns on the suggested directory >> location and the tree structure in option 3. >> >> Would the build-dev team be the right group to later help setup a new >> tree if decided to be the right way to go? >> >> Regards, >> Staffan >> From alan at aw20.co.uk Fri Dec 5 02:29:54 2014 From: alan at aw20.co.uk (Alan Williamson) Date: Thu, 04 Dec 2014 21:29:54 -0500 Subject: Proposed to Drop: JEP 198: Light-Weight JSON API In-Reply-To: <20141204114320.655240@eggemoggin.niobe.net> References: <20141204114320.655240@eggemoggin.niobe.net> Message-ID: <548118A2.3090609@aw20.co.uk> Mark, i would love to understand your reasoning behind this move. Java has always suffered from poor core support for popular formats. It took a long time before XML came to the core language and while that happened there was no real great alternative. JSON is a little different I grant you, considering how strong and popular Jackson/GSON/Mongo 3rd party libraries are. However I believe JSON will be with the industry far longer than even XML. With its deep roots in JavaScript (which Java has entered that game in a big way with Nashorn), JSON is the number one choice for web services, data storage and generate NoSQL communications. By not having an official answer for this format, is going to hurt Java in the long run. thanks a -- http://alan.aw20.net/ On 04/12/2014 14:43, mark.reinhold at oracle.com wrote: > This JEP [1] would be a useful addition to the platform but, in the grand > scheme of things, it's not as important as the other features that Oracle > is funding, or considering funding, for JDK 9. I've therefore moved it > to the Proposed to Drop state. > > We may reconsider this JEP for JDK 10 or a later release, especially if > new language features such as value types [2] and generics over primitive > types (JEP 218 [3]) enable a more compact and expressive API. > > - Mark > > > [1] http://openjdk.java.net/jeps/198 > [2] http://cr.openjdk.java.net/~jrose/values/values-0.html > [3] http://openjdk.java.net/jeps/218 From Sergey.Bylokhov at oracle.com Fri Dec 5 17:57:14 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 05 Dec 2014 20:57:14 +0300 Subject: RFR [JEP 220] Modular Run-Time Images - compact profiles footprint In-Reply-To: <548095B7.2020809@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <54805A8E.4030806@zafena.se> <54806647.5050300@oracle.com> <54808E18.4070403@oracle.com> <548095B7.2020809@oracle.com> Message-ID: <5481F1FA.6050500@oracle.com> On 04.12.2014 20:11, Alan Bateman wrote: > We've now moved to world where the runtime images are created from a > set of modules and this should give a lot of flexibility once. We're > just not there yet with locale data so we have to temporarily link in > the big jdk.localedata module so that the profiles images have all > locales. Just curious, how will we track the size of modules? Probably we can save this information during the build time, so regressions will be found easily? > > -Alan. -- Best regards, Sergey. From sean.coffey at oracle.com Fri Dec 5 18:35:26 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 05 Dec 2014 18:35:26 +0000 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov Message-ID: <5481FAEE.2020102@oracle.com> I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. Ivan is a member of the Java SE Sustaining team and works mainly on issues connected to the JDK core libraries. Over the past year, he's demonstrated a strong understanding of how the core libraries code works and has contributed significant bug fixes and enhancements in JDK 9 [3]. Votes are due by 19:00 GMT December 19th 2014. Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Regards, Sean. [1] : http://openjdk.java.net/census#jdk9 [2] : http://openjdk.java.net/projects/#reviewer-vote [3] $hg log -M -u igerasim -R jdk --template "{desc}\n" | grep "^[0-9]\{7,7\}: " 8023173: FileDescriptor should respect append flag 8059840: (bb) Typo in javadoc for ByteBuffer.wrap() 8059450: Not quite correct code sample in javadoc 8058099: (fc) Cleanup in FileChannel/FileDispatcher native implementation [win] 8054029: (fc) FileChannel.size() returns 0 for block devices on Linux 7010989: Duplicate closure of file descriptors leads to unexpected and incorrect closure of sockets 8056310: Cleanup in WinNTFileSystem_md.c 8054714: Use StringJoiner where it makes the code cleaner 8055421: (fs) bad error handling in java.base/unix/native/libnio/fs/UnixNativeDispatcher.c 8055731: sun/security/smartcardio/TestDirect.java throws java.lang.IndexOutOfBoundsException 8054841: (process) ProcessBuilder leaks native memory 8046343: (smartcardio) CardTerminal.connect('direct') does not work on MacOSX 8054221: StringJoiner imlementation optimization 8051382: Optimize java.lang.reflect.Modifier.toString() 8050893: (smartcardio) Invert reset argument in tests in sun/security/smartcardio 8035975: Pattern.compile(String, int) fails to throw IllegalArgumentException 6904367: (coll) IdentityHashMap is resized before exceeding the expected maximum size 8048080: (smartcardio) javax.smartcardio.Card.openLogicalChannel() dosn't work on MacOSX 8037866: Replace the Fun class in tests with lambdas 8044342: build failure on Windows noticed with recent smartcardio fix 8043720: (smartcardio) Native memory should be handled more accurately 7047033: (smartcardio) Card.disconnect(boolean reset) does not reset when reset is true 8039319: (smartcardio) Card.transmitControlCommand() does not work on Mac OS X 8043476: java/util/BitSet/BSMethods.java failed with: java.lang.OutOfMemoryError: Java heap space 8043507: javax.smartcardio.CardTerminals.list() fails on MacOSX 8043772: Typos in Double/Int/LongSummaryStatistics.java 7195480: javax.smartcardio does not detect cards on Mac OS X 8042470: (fs) Path.register doesn't throw IllegalArgumentException if multiple OVERFLOW events are specified 8011537: (fs) Path.register(..) clears interrupt status of thread with no InterruptedException 8040806: BitSet.toString() can throw IndexOutOfBoundsException 8038982: java/lang/ref/EarlyTimeout.java failed again 8039396: NPE when writing a class descriptor object to a custom ObjectOutputStream 8009637: Some error messages are missing a space 8038333: TEST_BUG: java/lang/ref/EarlyTimeout.java fails with a non-adequate message 8014066: Remove redundant restriction from ArrayList#removeRange() spec 6943190: TEST_BUG: some tests in java/lang/Runtime/exec have hard-coded path to shell commands 7011804: SequenceInputStream with lots of empty substreams can cause StackOverflowError 8036088: Replace strtok() with its safe equivalent strtok_s() in DefaultProxySelector.c 8034262: Test java/lang/ProcessBuilder/CloseRace.java fails 6853696: (ref) ReferenceQueue.remove(timeout) may return null even if timeout has not expired 8023022: Some more typos in javadoc 4682009: Typo in javadocs in javax/naming 8033943: Typo in the documentation for the class Arrays 8027348: (process) Enhancement of handling async close of ProcessInputStream 8025886: replace [[ and == bash extensions in regtest 8030698: Several GUI labels in jconsole need correction 8024521: (process) Async close issues with Process InputStream 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the latest jdk8 build 8026756: Test java/util/zip/GZIP/GZIPInZip.java failed 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions 7129312: BufferedInputStream calculates negative array size with large streams and mark 8022584: Memory leak in some NetworkInterface methods 8020669: (fs) Files.readAllBytes() does not read any data when Files.size() is 0 7192942: (coll) Inefficient calculation of power of two in HashMap 8016838: improvement of RedefineBigClass and RetransformBigClass tests 7181748: java/lang/ThreadGroup/Suspend.java test fails intermittently $hg log -M -u igerasim -R hotspot --template "{desc}\n" | grep "^[0-9]\{7,7\}: " 8059533: (process) Make exiting process wait for exiting threads [win] 8057744: (process) Synchronize exiting of threads and process [win] 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java fails with openjdk build 8055338: (process) Add instrumentation to help diagnose JDK-6573254 8035893: JVM_GetVersionInfo fails to zero structure From abhi.saha at oracle.com Fri Dec 5 18:37:19 2014 From: abhi.saha at oracle.com (Abhi Saha) Date: Fri, 05 Dec 2014 10:37:19 -0800 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <5481FB5F.5000402@oracle.com> Vote: Yes. Thanks Abhijit On 12/5/2014 10:35 AM, Se?n Coffey wrote: > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. > > Ivan is a member of the Java SE Sustaining team and works mainly on > issues connected to the JDK core libraries. Over the past year, he's > demonstrated a strong understanding of how the core libraries code > works and has contributed significant bug fixes and enhancements in > JDK 9 [3]. > > Votes are due by 19:00 GMT December 19th 2014. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Sean. > > [1] : http://openjdk.java.net/census#jdk9 > [2] : http://openjdk.java.net/projects/#reviewer-vote > > > > > > -- Lead, Java SE Updates Java Platform Group Oracle Corporation. (408)276-7564 From chris.hegarty at oracle.com Fri Dec 5 18:39:10 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 5 Dec 2014 18:39:10 +0000 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <73DC2FD3-ACA7-404F-B49B-C4089857AAFD@oracle.com> Vote: YES. -Chris. On 5 Dec 2014, at 18:35, Se?n Coffey wrote: > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. > > Ivan is a member of the Java SE Sustaining team and works mainly on issues connected to the JDK core libraries. Over the past year, he's demonstrated a strong understanding of how the core libraries code works and has contributed significant bug fixes and enhancements in JDK 9 [3]. > > Votes are due by 19:00 GMT December 19th 2014. > > Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Sean. > > [1] : http://openjdk.java.net/census#jdk9 > [2] : http://openjdk.java.net/projects/#reviewer-vote > > [3] > $hg log -M -u igerasim -R jdk --template "{desc}\n" | grep "^[0-9]\{7,7\}: " > 8023173: FileDescriptor should respect append flag > 8059840: (bb) Typo in javadoc for ByteBuffer.wrap() > 8059450: Not quite correct code sample in javadoc > 8058099: (fc) Cleanup in FileChannel/FileDispatcher native implementation [win] > 8054029: (fc) FileChannel.size() returns 0 for block devices on Linux > 7010989: Duplicate closure of file descriptors leads to unexpected and incorrect closure of sockets > 8056310: Cleanup in WinNTFileSystem_md.c > 8054714: Use StringJoiner where it makes the code cleaner > 8055421: (fs) bad error handling in java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > 8055731: sun/security/smartcardio/TestDirect.java throws java.lang.IndexOutOfBoundsException > 8054841: (process) ProcessBuilder leaks native memory > 8046343: (smartcardio) CardTerminal.connect('direct') does not work on MacOSX > 8054221: StringJoiner imlementation optimization > 8051382: Optimize java.lang.reflect.Modifier.toString() > 8050893: (smartcardio) Invert reset argument in tests in sun/security/smartcardio > 8035975: Pattern.compile(String, int) fails to throw IllegalArgumentException > 6904367: (coll) IdentityHashMap is resized before exceeding the expected maximum size > 8048080: (smartcardio) javax.smartcardio.Card.openLogicalChannel() dosn't work on MacOSX > 8037866: Replace the Fun class in tests with lambdas > 8044342: build failure on Windows noticed with recent smartcardio fix > 8043720: (smartcardio) Native memory should be handled more accurately > 7047033: (smartcardio) Card.disconnect(boolean reset) does not reset when reset is true > 8039319: (smartcardio) Card.transmitControlCommand() does not work on Mac OS X > 8043476: java/util/BitSet/BSMethods.java failed with: java.lang.OutOfMemoryError: Java heap space > 8043507: javax.smartcardio.CardTerminals.list() fails on MacOSX > 8043772: Typos in Double/Int/LongSummaryStatistics.java > 7195480: javax.smartcardio does not detect cards on Mac OS X > 8042470: (fs) Path.register doesn't throw IllegalArgumentException if multiple OVERFLOW events are specified > 8011537: (fs) Path.register(..) clears interrupt status of thread with no InterruptedException > 8040806: BitSet.toString() can throw IndexOutOfBoundsException > 8038982: java/lang/ref/EarlyTimeout.java failed again > 8039396: NPE when writing a class descriptor object to a custom ObjectOutputStream > 8009637: Some error messages are missing a space > 8038333: TEST_BUG: java/lang/ref/EarlyTimeout.java fails with a non-adequate message > 8014066: Remove redundant restriction from ArrayList#removeRange() spec > 6943190: TEST_BUG: some tests in java/lang/Runtime/exec have hard-coded path to shell commands > 7011804: SequenceInputStream with lots of empty substreams can cause StackOverflowError > 8036088: Replace strtok() with its safe equivalent strtok_s() in DefaultProxySelector.c > 8034262: Test java/lang/ProcessBuilder/CloseRace.java fails > 6853696: (ref) ReferenceQueue.remove(timeout) may return null even if timeout has not expired > 8023022: Some more typos in javadoc > 4682009: Typo in javadocs in javax/naming > 8033943: Typo in the documentation for the class Arrays > 8027348: (process) Enhancement of handling async close of ProcessInputStream > 8025886: replace [[ and == bash extensions in regtest > 8030698: Several GUI labels in jconsole need correction > 8024521: (process) Async close issues with Process InputStream > 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the latest jdk8 build > 8026756: Test java/util/zip/GZIP/GZIPInZip.java failed > 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed > 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions > 7129312: BufferedInputStream calculates negative array size with large streams and mark > 8022584: Memory leak in some NetworkInterface methods > 8020669: (fs) Files.readAllBytes() does not read any data when Files.size() is 0 > 7192942: (coll) Inefficient calculation of power of two in HashMap > 8016838: improvement of RedefineBigClass and RetransformBigClass tests > 7181748: java/lang/ThreadGroup/Suspend.java test fails intermittently > > > $hg log -M -u igerasim -R hotspot --template "{desc}\n" | grep "^[0-9]\{7,7\}: " > 8059533: (process) Make exiting process wait for exiting threads [win] > 8057744: (process) Synchronize exiting of threads and process [win] > 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java fails with openjdk build > 8055338: (process) Add instrumentation to help diagnose JDK-6573254 > 8035893: JVM_GetVersionInfo fails to zero structure > > > > > From vladimir.x.ivanov at oracle.com Fri Dec 5 17:41:16 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 05 Dec 2014 21:41:16 +0400 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <5481EE3C.40007@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 12/5/14, 10:35 PM, Se?n Coffey wrote: > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. > > Ivan is a member of the Java SE Sustaining team and works mainly on > issues connected to the JDK core libraries. Over the past year, he's > demonstrated a strong understanding of how the core libraries code works > and has contributed significant bug fixes and enhancements in JDK 9 [3]. > > Votes are due by 19:00 GMT December 19th 2014. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Sean. > > [1] : http://openjdk.java.net/census#jdk9 > [2] : http://openjdk.java.net/projects/#reviewer-vote > > [3] > $hg log -M -u igerasim -R jdk --template "{desc}\n" | grep > "^[0-9]\{7,7\}: " > 8023173: FileDescriptor should respect append flag > 8059840: (bb) Typo in javadoc for ByteBuffer.wrap() > 8059450: Not quite correct code sample in javadoc > 8058099: (fc) Cleanup in FileChannel/FileDispatcher native > implementation [win] > 8054029: (fc) FileChannel.size() returns 0 for block devices on Linux > 7010989: Duplicate closure of file descriptors leads to unexpected and > incorrect closure of sockets > 8056310: Cleanup in WinNTFileSystem_md.c > 8054714: Use StringJoiner where it makes the code cleaner > 8055421: (fs) bad error handling in > java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > 8055731: sun/security/smartcardio/TestDirect.java throws > java.lang.IndexOutOfBoundsException > 8054841: (process) ProcessBuilder leaks native memory > 8046343: (smartcardio) CardTerminal.connect('direct') does not work on > MacOSX > 8054221: StringJoiner imlementation optimization > 8051382: Optimize java.lang.reflect.Modifier.toString() > 8050893: (smartcardio) Invert reset argument in tests in > sun/security/smartcardio > 8035975: Pattern.compile(String, int) fails to throw > IllegalArgumentException > 6904367: (coll) IdentityHashMap is resized before exceeding the expected > maximum size > 8048080: (smartcardio) javax.smartcardio.Card.openLogicalChannel() > dosn't work on MacOSX > 8037866: Replace the Fun class in tests with lambdas > 8044342: build failure on Windows noticed with recent smartcardio fix > 8043720: (smartcardio) Native memory should be handled more accurately > 7047033: (smartcardio) Card.disconnect(boolean reset) does not reset > when reset is true > 8039319: (smartcardio) Card.transmitControlCommand() does not work on > Mac OS X > 8043476: java/util/BitSet/BSMethods.java failed with: > java.lang.OutOfMemoryError: Java heap space > 8043507: javax.smartcardio.CardTerminals.list() fails on MacOSX > 8043772: Typos in Double/Int/LongSummaryStatistics.java > 7195480: javax.smartcardio does not detect cards on Mac OS X > 8042470: (fs) Path.register doesn't throw IllegalArgumentException if > multiple OVERFLOW events are specified > 8011537: (fs) Path.register(..) clears interrupt status of thread with > no InterruptedException > 8040806: BitSet.toString() can throw IndexOutOfBoundsException > 8038982: java/lang/ref/EarlyTimeout.java failed again > 8039396: NPE when writing a class descriptor object to a custom > ObjectOutputStream > 8009637: Some error messages are missing a space > 8038333: TEST_BUG: java/lang/ref/EarlyTimeout.java fails with a > non-adequate message > 8014066: Remove redundant restriction from ArrayList#removeRange() spec > 6943190: TEST_BUG: some tests in java/lang/Runtime/exec have hard-coded > path to shell commands > 7011804: SequenceInputStream with lots of empty substreams can cause > StackOverflowError > 8036088: Replace strtok() with its safe equivalent strtok_s() in > DefaultProxySelector.c > 8034262: Test java/lang/ProcessBuilder/CloseRace.java fails > 6853696: (ref) ReferenceQueue.remove(timeout) may return null even if > timeout has not expired > 8023022: Some more typos in javadoc > 4682009: Typo in javadocs in javax/naming > 8033943: Typo in the documentation for the class Arrays > 8027348: (process) Enhancement of handling async close of > ProcessInputStream > 8025886: replace [[ and == bash extensions in regtest > 8030698: Several GUI labels in jconsole need correction > 8024521: (process) Async close issues with Process InputStream > 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the > latest jdk8 build > 8026756: Test java/util/zip/GZIP/GZIPInZip.java failed > 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed > 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf > descriptions > 7129312: BufferedInputStream calculates negative array size with large > streams and mark > 8022584: Memory leak in some NetworkInterface methods > 8020669: (fs) Files.readAllBytes() does not read any data when > Files.size() is 0 > 7192942: (coll) Inefficient calculation of power of two in HashMap > 8016838: improvement of RedefineBigClass and RetransformBigClass tests > 7181748: java/lang/ThreadGroup/Suspend.java test fails intermittently > > > $hg log -M -u igerasim -R hotspot --template "{desc}\n" | grep > "^[0-9]\{7,7\}: " > 8059533: (process) Make exiting process wait for exiting threads [win] > 8057744: (process) Synchronize exiting of threads and process [win] > 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java > fails with openjdk build > 8055338: (process) Add instrumentation to help diagnose JDK-6573254 > 8035893: JVM_GetVersionInfo fails to zero structure > > > > > From xueming.shen at oracle.com Fri Dec 5 18:49:52 2014 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 05 Dec 2014 10:49:52 -0800 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <5481FE50.8050407@oracle.com> Vote: YES On 12/05/2014 10:35 AM, Se?n Coffey wrote: > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. > > Ivan is a member of the Java SE Sustaining team and works mainly on issues connected to the JDK core libraries. Over the past year, he's demonstrated a strong understanding of how the core libraries code works and has contributed significant bug fixes and enhancements in JDK 9 [3]. > > Votes are due by 19:00 GMT December 19th 2014. > > Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Sean. > > [1] : http://openjdk.java.net/census#jdk9 > [2] : http://openjdk.java.net/projects/#reviewer-vote > > [3] > $hg log -M -u igerasim -R jdk --template "{desc}\n" | grep "^[0-9]\{7,7\}: " > 8023173: FileDescriptor should respect append flag > 8059840: (bb) Typo in javadoc for ByteBuffer.wrap() > 8059450: Not quite correct code sample in javadoc > 8058099: (fc) Cleanup in FileChannel/FileDispatcher native implementation [win] > 8054029: (fc) FileChannel.size() returns 0 for block devices on Linux > 7010989: Duplicate closure of file descriptors leads to unexpected and incorrect closure of sockets > 8056310: Cleanup in WinNTFileSystem_md.c > 8054714: Use StringJoiner where it makes the code cleaner > 8055421: (fs) bad error handling in java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > 8055731: sun/security/smartcardio/TestDirect.java throws java.lang.IndexOutOfBoundsException > 8054841: (process) ProcessBuilder leaks native memory > 8046343: (smartcardio) CardTerminal.connect('direct') does not work on MacOSX > 8054221: StringJoiner imlementation optimization > 8051382: Optimize java.lang.reflect.Modifier.toString() > 8050893: (smartcardio) Invert reset argument in tests in sun/security/smartcardio > 8035975: Pattern.compile(String, int) fails to throw IllegalArgumentException > 6904367: (coll) IdentityHashMap is resized before exceeding the expected maximum size > 8048080: (smartcardio) javax.smartcardio.Card.openLogicalChannel() dosn't work on MacOSX > 8037866: Replace the Fun class in tests with lambdas > 8044342: build failure on Windows noticed with recent smartcardio fix > 8043720: (smartcardio) Native memory should be handled more accurately > 7047033: (smartcardio) Card.disconnect(boolean reset) does not reset when reset is true > 8039319: (smartcardio) Card.transmitControlCommand() does not work on Mac OS X > 8043476: java/util/BitSet/BSMethods.java failed with: java.lang.OutOfMemoryError: Java heap space > 8043507: javax.smartcardio.CardTerminals.list() fails on MacOSX > 8043772: Typos in Double/Int/LongSummaryStatistics.java > 7195480: javax.smartcardio does not detect cards on Mac OS X > 8042470: (fs) Path.register doesn't throw IllegalArgumentException if multiple OVERFLOW events are specified > 8011537: (fs) Path.register(..) clears interrupt status of thread with no InterruptedException > 8040806: BitSet.toString() can throw IndexOutOfBoundsException > 8038982: java/lang/ref/EarlyTimeout.java failed again > 8039396: NPE when writing a class descriptor object to a custom ObjectOutputStream > 8009637: Some error messages are missing a space > 8038333: TEST_BUG: java/lang/ref/EarlyTimeout.java fails with a non-adequate message > 8014066: Remove redundant restriction from ArrayList#removeRange() spec > 6943190: TEST_BUG: some tests in java/lang/Runtime/exec have hard-coded path to shell commands > 7011804: SequenceInputStream with lots of empty substreams can cause StackOverflowError > 8036088: Replace strtok() with its safe equivalent strtok_s() in DefaultProxySelector.c > 8034262: Test java/lang/ProcessBuilder/CloseRace.java fails > 6853696: (ref) ReferenceQueue.remove(timeout) may return null even if timeout has not expired > 8023022: Some more typos in javadoc > 4682009: Typo in javadocs in javax/naming > 8033943: Typo in the documentation for the class Arrays > 8027348: (process) Enhancement of handling async close of ProcessInputStream > 8025886: replace [[ and == bash extensions in regtest > 8030698: Several GUI labels in jconsole need correction > 8024521: (process) Async close issues with Process InputStream > 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the latest jdk8 build > 8026756: Test java/util/zip/GZIP/GZIPInZip.java failed > 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed > 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions > 7129312: BufferedInputStream calculates negative array size with large streams and mark > 8022584: Memory leak in some NetworkInterface methods > 8020669: (fs) Files.readAllBytes() does not read any data when Files.size() is 0 > 7192942: (coll) Inefficient calculation of power of two in HashMap > 8016838: improvement of RedefineBigClass and RetransformBigClass tests > 7181748: java/lang/ThreadGroup/Suspend.java test fails intermittently > > > $hg log -M -u igerasim -R hotspot --template "{desc}\n" | grep "^[0-9]\{7,7\}: " > 8059533: (process) Make exiting process wait for exiting threads [win] > 8057744: (process) Synchronize exiting of threads and process [win] > 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java fails with openjdk build > 8055338: (process) Add instrumentation to help diagnose JDK-6573254 > 8035893: JVM_GetVersionInfo fails to zero structure > > > > > From daniel.daugherty at oracle.com Fri Dec 5 18:54:03 2014 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 05 Dec 2014 11:54:03 -0700 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <5481FF4B.6080606@oracle.com> Vote: yes Dan On 12/5/14 11:35 AM, Se?n Coffey wrote: > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. > > Ivan is a member of the Java SE Sustaining team and works mainly on > issues connected to the JDK core libraries. Over the past year, he's > demonstrated a strong understanding of how the core libraries code > works and has contributed significant bug fixes and enhancements in > JDK 9 [3]. > > Votes are due by 19:00 GMT December 19th 2014. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Sean. > > [1] : http://openjdk.java.net/census#jdk9 > [2] : http://openjdk.java.net/projects/#reviewer-vote > > [3] > $hg log -M -u igerasim -R jdk --template "{desc}\n" | grep > "^[0-9]\{7,7\}: " > 8023173: FileDescriptor should respect append flag > 8059840: (bb) Typo in javadoc for ByteBuffer.wrap() > 8059450: Not quite correct code sample in javadoc > 8058099: (fc) Cleanup in FileChannel/FileDispatcher native > implementation [win] > 8054029: (fc) FileChannel.size() returns 0 for block devices on Linux > 7010989: Duplicate closure of file descriptors leads to unexpected and > incorrect closure of sockets > 8056310: Cleanup in WinNTFileSystem_md.c > 8054714: Use StringJoiner where it makes the code cleaner > 8055421: (fs) bad error handling in > java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > 8055731: sun/security/smartcardio/TestDirect.java throws > java.lang.IndexOutOfBoundsException > 8054841: (process) ProcessBuilder leaks native memory > 8046343: (smartcardio) CardTerminal.connect('direct') does not work on > MacOSX > 8054221: StringJoiner imlementation optimization > 8051382: Optimize java.lang.reflect.Modifier.toString() > 8050893: (smartcardio) Invert reset argument in tests in > sun/security/smartcardio > 8035975: Pattern.compile(String, int) fails to throw > IllegalArgumentException > 6904367: (coll) IdentityHashMap is resized before exceeding the > expected maximum size > 8048080: (smartcardio) javax.smartcardio.Card.openLogicalChannel() > dosn't work on MacOSX > 8037866: Replace the Fun class in tests with lambdas > 8044342: build failure on Windows noticed with recent smartcardio fix > 8043720: (smartcardio) Native memory should be handled more accurately > 7047033: (smartcardio) Card.disconnect(boolean reset) does not reset > when reset is true > 8039319: (smartcardio) Card.transmitControlCommand() does not work on > Mac OS X > 8043476: java/util/BitSet/BSMethods.java failed with: > java.lang.OutOfMemoryError: Java heap space > 8043507: javax.smartcardio.CardTerminals.list() fails on MacOSX > 8043772: Typos in Double/Int/LongSummaryStatistics.java > 7195480: javax.smartcardio does not detect cards on Mac OS X > 8042470: (fs) Path.register doesn't throw IllegalArgumentException if > multiple OVERFLOW events are specified > 8011537: (fs) Path.register(..) clears interrupt status of thread with > no InterruptedException > 8040806: BitSet.toString() can throw IndexOutOfBoundsException > 8038982: java/lang/ref/EarlyTimeout.java failed again > 8039396: NPE when writing a class descriptor object to a custom > ObjectOutputStream > 8009637: Some error messages are missing a space > 8038333: TEST_BUG: java/lang/ref/EarlyTimeout.java fails with a > non-adequate message > 8014066: Remove redundant restriction from ArrayList#removeRange() spec > 6943190: TEST_BUG: some tests in java/lang/Runtime/exec have > hard-coded path to shell commands > 7011804: SequenceInputStream with lots of empty substreams can cause > StackOverflowError > 8036088: Replace strtok() with its safe equivalent strtok_s() in > DefaultProxySelector.c > 8034262: Test java/lang/ProcessBuilder/CloseRace.java fails > 6853696: (ref) ReferenceQueue.remove(timeout) may return null even if > timeout has not expired > 8023022: Some more typos in javadoc > 4682009: Typo in javadocs in javax/naming > 8033943: Typo in the documentation for the class Arrays > 8027348: (process) Enhancement of handling async close of > ProcessInputStream > 8025886: replace [[ and == bash extensions in regtest > 8030698: Several GUI labels in jconsole need correction > 8024521: (process) Async close issues with Process InputStream > 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with > the latest jdk8 build > 8026756: Test java/util/zip/GZIP/GZIPInZip.java failed > 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed > 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf > descriptions > 7129312: BufferedInputStream calculates negative array size with large > streams and mark > 8022584: Memory leak in some NetworkInterface methods > 8020669: (fs) Files.readAllBytes() does not read any data when > Files.size() is 0 > 7192942: (coll) Inefficient calculation of power of two in HashMap > 8016838: improvement of RedefineBigClass and RetransformBigClass tests > 7181748: java/lang/ThreadGroup/Suspend.java test fails intermittently > > > $hg log -M -u igerasim -R hotspot --template "{desc}\n" | grep > "^[0-9]\{7,7\}: " > 8059533: (process) Make exiting process wait for exiting threads [win] > 8057744: (process) Synchronize exiting of threads and process [win] > 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java > fails with openjdk build > 8055338: (process) Add instrumentation to help diagnose JDK-6573254 > 8035893: JVM_GetVersionInfo fails to zero structure > > > > > > > From Alan.Bateman at oracle.com Fri Dec 5 19:09:42 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 05 Dec 2014 19:09:42 +0000 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <548202F6.4080909@oracle.com> Vote: yes From daniel.fuchs at oracle.com Fri Dec 5 19:11:09 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 05 Dec 2014 20:11:09 +0100 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <5482034D.5020700@oracle.com> Vote: Yes -- daniel On 05/12/14 19:35, Se?n Coffey wrote: > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. > > Ivan is a member of the Java SE Sustaining team and works mainly on > issues connected to the JDK core libraries. Over the past year, he's > demonstrated a strong understanding of how the core libraries code works > and has contributed significant bug fixes and enhancements in JDK 9 [3]. > > Votes are due by 19:00 GMT December 19th 2014. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. From vladimir.kozlov at oracle.com Fri Dec 5 19:33:49 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 05 Dec 2014 11:33:49 -0800 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <5482089D.6030208@oracle.com> Vote: yes On 12/5/14 10:35 AM, Se?n Coffey wrote: > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. > > Ivan is a member of the Java SE Sustaining team and works mainly on > issues connected to the JDK core libraries. Over the past year, he's > demonstrated a strong understanding of how the core libraries code works > and has contributed significant bug fixes and enhancements in JDK 9 [3]. > > Votes are due by 19:00 GMT December 19th 2014. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Sean. > > [1] : http://openjdk.java.net/census#jdk9 > [2] : http://openjdk.java.net/projects/#reviewer-vote > > [3] > $hg log -M -u igerasim -R jdk --template "{desc}\n" | grep > "^[0-9]\{7,7\}: " > 8023173: FileDescriptor should respect append flag > 8059840: (bb) Typo in javadoc for ByteBuffer.wrap() > 8059450: Not quite correct code sample in javadoc > 8058099: (fc) Cleanup in FileChannel/FileDispatcher native > implementation [win] > 8054029: (fc) FileChannel.size() returns 0 for block devices on Linux > 7010989: Duplicate closure of file descriptors leads to unexpected and > incorrect closure of sockets > 8056310: Cleanup in WinNTFileSystem_md.c > 8054714: Use StringJoiner where it makes the code cleaner > 8055421: (fs) bad error handling in > java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > 8055731: sun/security/smartcardio/TestDirect.java throws > java.lang.IndexOutOfBoundsException > 8054841: (process) ProcessBuilder leaks native memory > 8046343: (smartcardio) CardTerminal.connect('direct') does not work on > MacOSX > 8054221: StringJoiner imlementation optimization > 8051382: Optimize java.lang.reflect.Modifier.toString() > 8050893: (smartcardio) Invert reset argument in tests in > sun/security/smartcardio > 8035975: Pattern.compile(String, int) fails to throw > IllegalArgumentException > 6904367: (coll) IdentityHashMap is resized before exceeding the expected > maximum size > 8048080: (smartcardio) javax.smartcardio.Card.openLogicalChannel() > dosn't work on MacOSX > 8037866: Replace the Fun class in tests with lambdas > 8044342: build failure on Windows noticed with recent smartcardio fix > 8043720: (smartcardio) Native memory should be handled more accurately > 7047033: (smartcardio) Card.disconnect(boolean reset) does not reset > when reset is true > 8039319: (smartcardio) Card.transmitControlCommand() does not work on > Mac OS X > 8043476: java/util/BitSet/BSMethods.java failed with: > java.lang.OutOfMemoryError: Java heap space > 8043507: javax.smartcardio.CardTerminals.list() fails on MacOSX > 8043772: Typos in Double/Int/LongSummaryStatistics.java > 7195480: javax.smartcardio does not detect cards on Mac OS X > 8042470: (fs) Path.register doesn't throw IllegalArgumentException if > multiple OVERFLOW events are specified > 8011537: (fs) Path.register(..) clears interrupt status of thread with > no InterruptedException > 8040806: BitSet.toString() can throw IndexOutOfBoundsException > 8038982: java/lang/ref/EarlyTimeout.java failed again > 8039396: NPE when writing a class descriptor object to a custom > ObjectOutputStream > 8009637: Some error messages are missing a space > 8038333: TEST_BUG: java/lang/ref/EarlyTimeout.java fails with a > non-adequate message > 8014066: Remove redundant restriction from ArrayList#removeRange() spec > 6943190: TEST_BUG: some tests in java/lang/Runtime/exec have hard-coded > path to shell commands > 7011804: SequenceInputStream with lots of empty substreams can cause > StackOverflowError > 8036088: Replace strtok() with its safe equivalent strtok_s() in > DefaultProxySelector.c > 8034262: Test java/lang/ProcessBuilder/CloseRace.java fails > 6853696: (ref) ReferenceQueue.remove(timeout) may return null even if > timeout has not expired > 8023022: Some more typos in javadoc > 4682009: Typo in javadocs in javax/naming > 8033943: Typo in the documentation for the class Arrays > 8027348: (process) Enhancement of handling async close of > ProcessInputStream > 8025886: replace [[ and == bash extensions in regtest > 8030698: Several GUI labels in jconsole need correction > 8024521: (process) Async close issues with Process InputStream > 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the > latest jdk8 build > 8026756: Test java/util/zip/GZIP/GZIPInZip.java failed > 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed > 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf > descriptions > 7129312: BufferedInputStream calculates negative array size with large > streams and mark > 8022584: Memory leak in some NetworkInterface methods > 8020669: (fs) Files.readAllBytes() does not read any data when > Files.size() is 0 > 7192942: (coll) Inefficient calculation of power of two in HashMap > 8016838: improvement of RedefineBigClass and RetransformBigClass tests > 7181748: java/lang/ThreadGroup/Suspend.java test fails intermittently > > > $hg log -M -u igerasim -R hotspot --template "{desc}\n" | grep > "^[0-9]\{7,7\}: " > 8059533: (process) Make exiting process wait for exiting threads [win] > 8057744: (process) Synchronize exiting of threads and process [win] > 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java > fails with openjdk build > 8055338: (process) Add instrumentation to help diagnose JDK-6573254 > 8035893: JVM_GetVersionInfo fails to zero structure > > > > > From staffan.friberg at oracle.com Fri Dec 5 19:46:38 2014 From: staffan.friberg at oracle.com (Staffan Friberg) Date: Fri, 05 Dec 2014 11:46:38 -0800 Subject: Adding Microbenchmarks to the JDK forest/trees (JEP-230) In-Reply-To: <54814F5A.9010009@oracle.com> References: <547D02E5.8070507@oracle.com> <5480FD79.2050802@oracle.com> <54814F5A.9010009@oracle.com> Message-ID: <54820B9E.3080209@oracle.com> Hi, On 12/04/2014 10:23 PM, joe darcy wrote: > Hello, > > On 12/4/2014 4:34 PM, David Holmes wrote: >> Hi Staffan, >> >> On 2/12/2014 10:08 AM, Staffan Friberg wrote: >>> Hi, >>> >>> Hopefully this is the right list for this discussion. >>> >>> As part of adding Microbenchmarks to the OpenJDK source tree, I'm >>> trying >>> to understand how we best would add the benchmark sources to the >>> existing OpenJDK tree structure. >> >> Is there a reason this needs to be inside the OpenJDK instead of a >> stand-alone project? If it ends up in its own repo and the repo is >> not needed by anything else, then it is already like a stand-alone >> project. > > I think David is raising a good question here. A related question is > if we want to update/fix the microbenchmarks, in how many release > trains will we want to make that fix? If the expected answer is much > greater than one, to me that would seem to me to argue for a separate > forest in the overall OpenJDK effort, but not bundled into a > particular release. > > For example, in the past, the webrev.ksh script was included in the > JDK forest. That was an improvement over every engineer having his or > her personal fork, but still made keeping webrev updated unnecessarily > difficult since any changes would need to be done multiple time and > there is nothing fundamentally binding a version of webrev to a > particular JDK release. Likewise, even though (to my knowledge) jtreg > is only used for testing the JDK, jtreg has its own repository and > release schedule separate from any JDK release. > > So if the microbenchmarks are to a first-approximation version > agnostic, then they should probably have a forest not associated with > a JDK release. If they are tightly bound to a release, that argues for > putting them into the JDK forest itself. > The reasons are similar to co-locating functional tests, stable test base that is not moving after FC, tests support new features and all work with the JDK you are developing. Looking at some of the goals in the JEP and why I think co-locating helps. * Stable and tuned benchmarks, targeted for continuous performance testing o A stable and non-moving suite after the Feature Complete milestone of a feature release, and for non-feature releases To fulfill this having a separate repository would force us to branch and create builds in sync with the JDK we want to test. As the number of JDK version increases so will the microbenchmark suite. Making it complex for anyone adding or running tests to keep track of which version one should use for a specific JDK branch. As an example, for a stable branch we probably do not want to update the JMH version, unless there is a critical bug, as doing so can invalidate any earlier results causing us to lose all history that is critical when tracking a release. However during development of a new release we probably want to do that to take advantage of new features in JMH. And we might require new features in JMH to support changes in the JDK. Fixing bugs in microbenchmarks will in a similar fashion to any bugs sometimes need to be backported, but we would have similar struggles in a separate repository if we want to keep the suite stable for multiple releases and have multiple branches to support that. JMH similar to jtreg is a separate repository already, and will stay that way. The co-located part would be the benchmarks, which similar to the tests written using jtreg benefit from being co-located. * Simplicity o Easy to add new benchmarks o Easy to update tests as APIs and options change, are deprecated, or are removed during development o Easy to find and run a benchmark Having it co-located reduces the steps for anyone developing a new feature to push benchmarks at the same time as the feature in the same way as functional tests can be pushed. Any benchmark relying on a feature being removed can easily be deleted without concern about reducing the test coverage of older releases still providing it. Having it in a completely separate repository I fear will cause microbenchmark to be out of sight and out of mind, which is the opposite of the intention of creating the suite. We want more people to write and run benchmarks in a simple way. Co-location will allow anyone to simply just add and do make to build for their current branch and test the feature they are working on, and those benchmarks will directly be picked up for regression testing once pushed. Hope this helps to further clarify the reason for having the suite as part of the OpenJDK source tree. Regards, Staffan From staffan.larsen at oracle.com Fri Dec 5 19:49:18 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 5 Dec 2014 20:49:18 +0100 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <133CBCB3-AAFB-4EEF-A9A2-09FB41605F6C@oracle.com> Vote: yes. > On 5 dec 2014, at 19:35, Se?n Coffey wrote: > > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. > > Ivan is a member of the Java SE Sustaining team and works mainly on issues connected to the JDK core libraries. Over the past year, he's demonstrated a strong understanding of how the core libraries code works and has contributed significant bug fixes and enhancements in JDK 9 [3]. > > Votes are due by 19:00 GMT December 19th 2014. > > Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Sean. > > [1] : http://openjdk.java.net/census#jdk9 > [2] : http://openjdk.java.net/projects/#reviewer-vote > > [3] > $hg log -M -u igerasim -R jdk --template "{desc}\n" | grep "^[0-9]\{7,7\}: " > 8023173: FileDescriptor should respect append flag > 8059840: (bb) Typo in javadoc for ByteBuffer.wrap() > 8059450: Not quite correct code sample in javadoc > 8058099: (fc) Cleanup in FileChannel/FileDispatcher native implementation [win] > 8054029: (fc) FileChannel.size() returns 0 for block devices on Linux > 7010989: Duplicate closure of file descriptors leads to unexpected and incorrect closure of sockets > 8056310: Cleanup in WinNTFileSystem_md.c > 8054714: Use StringJoiner where it makes the code cleaner > 8055421: (fs) bad error handling in java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > 8055731: sun/security/smartcardio/TestDirect.java throws java.lang.IndexOutOfBoundsException > 8054841: (process) ProcessBuilder leaks native memory > 8046343: (smartcardio) CardTerminal.connect('direct') does not work on MacOSX > 8054221: StringJoiner imlementation optimization > 8051382: Optimize java.lang.reflect.Modifier.toString() > 8050893: (smartcardio) Invert reset argument in tests in sun/security/smartcardio > 8035975: Pattern.compile(String, int) fails to throw IllegalArgumentException > 6904367: (coll) IdentityHashMap is resized before exceeding the expected maximum size > 8048080: (smartcardio) javax.smartcardio.Card.openLogicalChannel() dosn't work on MacOSX > 8037866: Replace the Fun class in tests with lambdas > 8044342: build failure on Windows noticed with recent smartcardio fix > 8043720: (smartcardio) Native memory should be handled more accurately > 7047033: (smartcardio) Card.disconnect(boolean reset) does not reset when reset is true > 8039319: (smartcardio) Card.transmitControlCommand() does not work on Mac OS X > 8043476: java/util/BitSet/BSMethods.java failed with: java.lang.OutOfMemoryError: Java heap space > 8043507: javax.smartcardio.CardTerminals.list() fails on MacOSX > 8043772: Typos in Double/Int/LongSummaryStatistics.java > 7195480: javax.smartcardio does not detect cards on Mac OS X > 8042470: (fs) Path.register doesn't throw IllegalArgumentException if multiple OVERFLOW events are specified > 8011537: (fs) Path.register(..) clears interrupt status of thread with no InterruptedException > 8040806: BitSet.toString() can throw IndexOutOfBoundsException > 8038982: java/lang/ref/EarlyTimeout.java failed again > 8039396: NPE when writing a class descriptor object to a custom ObjectOutputStream > 8009637: Some error messages are missing a space > 8038333: TEST_BUG: java/lang/ref/EarlyTimeout.java fails with a non-adequate message > 8014066: Remove redundant restriction from ArrayList#removeRange() spec > 6943190: TEST_BUG: some tests in java/lang/Runtime/exec have hard-coded path to shell commands > 7011804: SequenceInputStream with lots of empty substreams can cause StackOverflowError > 8036088: Replace strtok() with its safe equivalent strtok_s() in DefaultProxySelector.c > 8034262: Test java/lang/ProcessBuilder/CloseRace.java fails > 6853696: (ref) ReferenceQueue.remove(timeout) may return null even if timeout has not expired > 8023022: Some more typos in javadoc > 4682009: Typo in javadocs in javax/naming > 8033943: Typo in the documentation for the class Arrays > 8027348: (process) Enhancement of handling async close of ProcessInputStream > 8025886: replace [[ and == bash extensions in regtest > 8030698: Several GUI labels in jconsole need correction > 8024521: (process) Async close issues with Process InputStream > 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the latest jdk8 build > 8026756: Test java/util/zip/GZIP/GZIPInZip.java failed > 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed > 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions > 7129312: BufferedInputStream calculates negative array size with large streams and mark > 8022584: Memory leak in some NetworkInterface methods > 8020669: (fs) Files.readAllBytes() does not read any data when Files.size() is 0 > 7192942: (coll) Inefficient calculation of power of two in HashMap > 8016838: improvement of RedefineBigClass and RetransformBigClass tests > 7181748: java/lang/ThreadGroup/Suspend.java test fails intermittently > > > $hg log -M -u igerasim -R hotspot --template "{desc}\n" | grep "^[0-9]\{7,7\}: " > 8059533: (process) Make exiting process wait for exiting threads [win] > 8057744: (process) Synchronize exiting of threads and process [win] > 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java fails with openjdk build > 8055338: (process) Add instrumentation to help diagnose JDK-6573254 > 8035893: JVM_GetVersionInfo fails to zero structure > > > > > From sean.mullan at oracle.com Fri Dec 5 21:46:24 2014 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 05 Dec 2014 16:46:24 -0500 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <548227B0.8040906@oracle.com> On 12/05/2014 01:35 PM, Se?n Coffey wrote: > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. Vote: yes --Sean From xuelei.fan at oracle.com Fri Dec 5 23:44:28 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 06 Dec 2014 07:44:28 +0800 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <5482435C.5020504@oracle.com> Vote: yes. Xuelei On 12/6/2014 2:35 AM, Se?n Coffey wrote: > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. > > Ivan is a member of the Java SE Sustaining team and works mainly on > issues connected to the JDK core libraries. Over the past year, he's > demonstrated a strong understanding of how the core libraries code works > and has contributed significant bug fixes and enhancements in JDK 9 [3]. > > Votes are due by 19:00 GMT December 19th 2014. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Sean. > > [1] : http://openjdk.java.net/census#jdk9 > [2] : http://openjdk.java.net/projects/#reviewer-vote > > [3] > $hg log -M -u igerasim -R jdk --template "{desc}\n" | grep > "^[0-9]\{7,7\}: " > 8023173: FileDescriptor should respect append flag > 8059840: (bb) Typo in javadoc for ByteBuffer.wrap() > 8059450: Not quite correct code sample in javadoc > 8058099: (fc) Cleanup in FileChannel/FileDispatcher native > implementation [win] > 8054029: (fc) FileChannel.size() returns 0 for block devices on Linux > 7010989: Duplicate closure of file descriptors leads to unexpected and > incorrect closure of sockets > 8056310: Cleanup in WinNTFileSystem_md.c > 8054714: Use StringJoiner where it makes the code cleaner > 8055421: (fs) bad error handling in > java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > 8055731: sun/security/smartcardio/TestDirect.java throws > java.lang.IndexOutOfBoundsException > 8054841: (process) ProcessBuilder leaks native memory > 8046343: (smartcardio) CardTerminal.connect('direct') does not work on > MacOSX > 8054221: StringJoiner imlementation optimization > 8051382: Optimize java.lang.reflect.Modifier.toString() > 8050893: (smartcardio) Invert reset argument in tests in > sun/security/smartcardio > 8035975: Pattern.compile(String, int) fails to throw > IllegalArgumentException > 6904367: (coll) IdentityHashMap is resized before exceeding the expected > maximum size > 8048080: (smartcardio) javax.smartcardio.Card.openLogicalChannel() > dosn't work on MacOSX > 8037866: Replace the Fun class in tests with lambdas > 8044342: build failure on Windows noticed with recent smartcardio fix > 8043720: (smartcardio) Native memory should be handled more accurately > 7047033: (smartcardio) Card.disconnect(boolean reset) does not reset > when reset is true > 8039319: (smartcardio) Card.transmitControlCommand() does not work on > Mac OS X > 8043476: java/util/BitSet/BSMethods.java failed with: > java.lang.OutOfMemoryError: Java heap space > 8043507: javax.smartcardio.CardTerminals.list() fails on MacOSX > 8043772: Typos in Double/Int/LongSummaryStatistics.java > 7195480: javax.smartcardio does not detect cards on Mac OS X > 8042470: (fs) Path.register doesn't throw IllegalArgumentException if > multiple OVERFLOW events are specified > 8011537: (fs) Path.register(..) clears interrupt status of thread with > no InterruptedException > 8040806: BitSet.toString() can throw IndexOutOfBoundsException > 8038982: java/lang/ref/EarlyTimeout.java failed again > 8039396: NPE when writing a class descriptor object to a custom > ObjectOutputStream > 8009637: Some error messages are missing a space > 8038333: TEST_BUG: java/lang/ref/EarlyTimeout.java fails with a > non-adequate message > 8014066: Remove redundant restriction from ArrayList#removeRange() spec > 6943190: TEST_BUG: some tests in java/lang/Runtime/exec have hard-coded > path to shell commands > 7011804: SequenceInputStream with lots of empty substreams can cause > StackOverflowError > 8036088: Replace strtok() with its safe equivalent strtok_s() in > DefaultProxySelector.c > 8034262: Test java/lang/ProcessBuilder/CloseRace.java fails > 6853696: (ref) ReferenceQueue.remove(timeout) may return null even if > timeout has not expired > 8023022: Some more typos in javadoc > 4682009: Typo in javadocs in javax/naming > 8033943: Typo in the documentation for the class Arrays > 8027348: (process) Enhancement of handling async close of > ProcessInputStream > 8025886: replace [[ and == bash extensions in regtest > 8030698: Several GUI labels in jconsole need correction > 8024521: (process) Async close issues with Process InputStream > 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the > latest jdk8 build > 8026756: Test java/util/zip/GZIP/GZIPInZip.java failed > 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed > 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf > descriptions > 7129312: BufferedInputStream calculates negative array size with large > streams and mark > 8022584: Memory leak in some NetworkInterface methods > 8020669: (fs) Files.readAllBytes() does not read any data when > Files.size() is 0 > 7192942: (coll) Inefficient calculation of power of two in HashMap > 8016838: improvement of RedefineBigClass and RetransformBigClass tests > 7181748: java/lang/ThreadGroup/Suspend.java test fails intermittently > > > $hg log -M -u igerasim -R hotspot --template "{desc}\n" | grep > "^[0-9]\{7,7\}: " > 8059533: (process) Make exiting process wait for exiting threads [win] > 8057744: (process) Synchronize exiting of threads and process [win] > 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java > fails with openjdk build > 8055338: (process) Add instrumentation to help diagnose JDK-6573254 > 8035893: JVM_GetVersionInfo fails to zero structure > > > > > From weijun.wang at oracle.com Sat Dec 6 00:15:08 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Sat, 6 Dec 2014 08:15:08 +0800 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5482435C.5020504@oracle.com> References: <5481FAEE.2020102@oracle.com> <5482435C.5020504@oracle.com> Message-ID: <27C4EA7F-7DA3-4227-B4A3-2EC01DCE6B50@oracle.com> Vote: yes. -Weijun From Alan.Bateman at oracle.com Sat Dec 6 11:28:07 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 06 Dec 2014 11:28:07 +0000 Subject: RFR [JEP 220] Modular Run-Time Images - compact profiles footprint In-Reply-To: <5481F1FA.6050500@oracle.com> References: <2C7B42C6-B72C-4B7F-A75E-ABB9BF4B14EE@oracle.com> <54805A8E.4030806@zafena.se> <54806647.5050300@oracle.com> <54808E18.4070403@oracle.com> <548095B7.2020809@oracle.com> <5481F1FA.6050500@oracle.com> Message-ID: <5482E847.1030103@oracle.com> On 05/12/2014 17:57, Sergey Bylokhov wrote: > On 04.12.2014 20:11, Alan Bateman wrote: >> We've now moved to world where the runtime images are created from a >> set of modules and this should give a lot of flexibility once. We're >> just not there yet with locale data so we have to temporarily link in >> the big jdk.localedata module so that the profiles images have all >> locales. > Just curious, how will we track the size of modules? Probably we can > save this information during the build time, so regressions will be > found easily? Once we are a bit further then I expect we will generate a directory of modules, format TBD. This will be important to have when creating images outside of the JDK build environment, say a custom image with your application, some libraries and their transitive dependences. That might be the time to track the size, although it would really be just an indication, it may be very different when linked in to the eventual image (due to compression and other transformations that might happen at link time). -Alan From martin.grebac at oracle.com Sat Dec 6 12:35:55 2014 From: martin.grebac at oracle.com (Martin Grebac) Date: Sat, 06 Dec 2014 13:35:55 +0100 Subject: Proposed to Drop: JEP 198: Light-Weight JSON API In-Reply-To: <548118A2.3090609@aw20.co.uk> References: <20141204114320.655240@eggemoggin.niobe.net> <548118A2.3090609@aw20.co.uk> Message-ID: <5482F82B.90103@oracle.com> On 05.12.14 3:29, Alan Williamson wrote: > Mark, i would love to understand your reasoning behind this move. > > Java has always suffered from poor core support for popular formats. > It took a long time before XML came to the core language and while > that happened there was no real great alternative. Why does this need to be part of the language? As you mentioned - formats come and go, Java stays ;O). Have you consideredhttp://jsonp.java.net/ ? MartiNG > JSON is a little different I grant you, considering how strong and > popular Jackson/GSON/Mongo 3rd party libraries are. > > However I believe JSON will be with the industry far longer than even > XML. With its deep roots in JavaScript (which Java has entered that > game in a big way with Nashorn), JSON is the number one choice for web > services, data storage and generate NoSQL communications. > > By not having an official answer for this format, is going to hurt > Java in the long run. > > thanks > a From paul.sandoz at oracle.com Mon Dec 8 08:56:21 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 8 Dec 2014 09:56:21 +0100 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <590000FF-3DC1-4DC5-8A15-09A6F22A74DE@oracle.com> On Dec 5, 2014, at 7:35 PM, Se?n Coffey wrote: > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. > Vote: yes. Paul. From tobias.hartmann at oracle.com Mon Dec 8 09:06:57 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 08 Dec 2014 10:06:57 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com> <547DF8D8.8080601@oracle.com> <547E190F.1090407@oracle.com> <54800E21.2050700@oracle.com> <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <54855234.3050400@oracle.com> <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> Message-ID: <54856A31.9020702@oracle.com> CC'ing to jdk9-dev for wider audience. Summary: The tests for the 'Segmented Code Cache' JEP [1] and other JDK tests [2] need access to the Whitebox API testlibrary that is part of the hotspot repository. We therefore propose to move the Whitebox API from the hotspot repository to the top level repository (test/testlibrary/) in the following steps: 1) Copy testlibrary to top level repository 2) Adapt existing hotspot tests (> 200 tests) 3) Remove testlibrary from hotspot repository First step: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/ Thanks, Tobias [1] https://bugs.openjdk.java.net/browse/JDK-8066625 [2] https://bugs.openjdk.java.net/browse/JDK-8064875 On 08.12.2014 08:37, Staffan Larsen wrote: > I am for this change in principle, but before we go ahead I think this warrants a larger discussion on build-dev at ojn or jdk9-dev at ojn. We need to propose and get acceptance for this from the larger group. > > (I was also surprised to see a Makefile here - who calls that?) > > /Staffan > >> On 8 dec 2014, at 08:24, Tobias Hartmann wrote: >> >> Hi, >> >> As we discussed off-thread I copied the Whitebox API to the top level repository >> (test/testlibrary). We will then file a RFE to adopt the hotspot tests and >> eventually remove the testlibrary from the hotspot repo. >> >> New webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/ >> >> Can I get reviews for this? >> >> Thanks, >> Tobias >> >> On 04.12.2014 11:29, Staffan Larsen wrote: >>> I don?t know which tests you are planning to write that require this feature, but can the tests be put into the hotspot repo instead of the jdk repo so that we avoid the duplication? It seems like the decision for JDK-8057707 was to not duplicate the code. >>> >>> /Staffan >>> >>>> On 4 dec 2014, at 08:32, Tobias Hartmann wrote: >>>> >>>> Mikael, Staffan, it looks like as if we don't have a nice solution for sharing >>>> the library at the moment. What do you think about having the duplication as an >>>> intermediate solution until we get the necessary support from jtreg / jprt to >>>> share the library? >>>> >>>> There are also other JDK tests that would benefit from having the Whitebox API >>>> available. For example, JDK-8057707 [1]. >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028532.html >>>> >>>> On 02.12.2014 20:54, Tobias Hartmann wrote: >>>>> Hi Staffan, >>>>> >>>>> thanks for the feedback. >>>>> >>>>> On 02.12.2014 20:45, Staffan Larsen wrote: >>>>>> >>>>>>> On 2 dec 2014, at 20:25, Staffan Larsen wrote: >>>>>>> >>>>>>> >>>>>>>> On 2 dec 2014, at 18:37, Tobias Hartmann wrote: >>>>>>>> >>>>>>>> Hi Mikael, >>>>>>>> >>>>>>>> On 02.12.2014 18:22, Mikael Vidstedt wrote: >>>>>>>>> >>>>>>>>> Tobias, >>>>>>>>> >>>>>>>>> Have you looked at what it would take to move the testlibrary somewhere where it >>>>>>>>> can actually be shared instead? I think it would be extremely unfortunate to >>>>>>>>> copy the code. I can't stress that enough. >>>>>>>> >>>>>>>> I agree that having the testlibrary in a shared location is definitely the best >>>>>>>> solution. Unfortunately, I don't know how to do that since we have to access the >>>>>>>> library from different repositories and I don't think we want to have path >>>>>>>> dependencies between the repositories. >>>>>>>> >>>>>>>> Any suggestions? >>>>>>> >>>>>>> jtreg currently requires the testlibrary to be located in or under the directory with the TEST.ROOT file. To move it somewhere else we need to change jtreg first - and I think we should. >>>>>> >>>>>> I?ve been told that it is actually possible to do this with the current jtreg by using an ugly path such as: >>>>>> >>>>>> @library /../../test/testlibrary >>>>>> >>>>>> I don?t think that is what we want to do? >>>>> >>>>> Yes, that's what I meant with "path dependencies between repositories". I don't >>>>> think this is a very robust solution. >>>>> >>>>> Best, >>>>> Tobias >>>>> >>>>>> >>>>>> /Staffan >>>>>> >>>>>> >>>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tobias >>>>>>>> >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Mikael >>>>>>>>> >>>>>>>>> On 2014-12-02 06:40, Tobias Hartmann wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> please review the following patch that copies the Whitebox testlibrary to >>>>>>>>>> /jdk/test. This is needed to enhance and fix jdk tests (for example, see [1]). >>>>>>>>>> >>>>>>>>>> The change leads to code duplication but in my opinion we should favour stable >>>>>>>>>> tests over code duplication here. Hopefully, there is a solution to share the >>>>>>>>>> library in the future. >>>>>>>>>> >>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433 >>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/ >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tobias >>>>>>>>> >>>>>>> >>>>>> >>> > From jaroslav.bachorik at oracle.com Mon Dec 8 09:12:14 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 08 Dec 2014 10:12:14 +0100 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <54856B6E.9030504@oracle.com> Vote: yes -JB- On 12/05/2014 07:35 PM, Se?n Coffey wrote: > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. > > Ivan is a member of the Java SE Sustaining team and works mainly on > issues connected to the JDK core libraries. Over the past year, he's > demonstrated a strong understanding of how the core libraries code works > and has contributed significant bug fixes and enhancements in JDK 9 [3]. > > Votes are due by 19:00 GMT December 19th 2014. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Sean. > > [1] : http://openjdk.java.net/census#jdk9 > [2] : http://openjdk.java.net/projects/#reviewer-vote > > [3] > $hg log -M -u igerasim -R jdk --template "{desc}\n" | grep > "^[0-9]\{7,7\}: " > 8023173: FileDescriptor should respect append flag > 8059840: (bb) Typo in javadoc for ByteBuffer.wrap() > 8059450: Not quite correct code sample in javadoc > 8058099: (fc) Cleanup in FileChannel/FileDispatcher native > implementation [win] > 8054029: (fc) FileChannel.size() returns 0 for block devices on Linux > 7010989: Duplicate closure of file descriptors leads to unexpected and > incorrect closure of sockets > 8056310: Cleanup in WinNTFileSystem_md.c > 8054714: Use StringJoiner where it makes the code cleaner > 8055421: (fs) bad error handling in > java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > 8055731: sun/security/smartcardio/TestDirect.java throws > java.lang.IndexOutOfBoundsException > 8054841: (process) ProcessBuilder leaks native memory > 8046343: (smartcardio) CardTerminal.connect('direct') does not work on > MacOSX > 8054221: StringJoiner imlementation optimization > 8051382: Optimize java.lang.reflect.Modifier.toString() > 8050893: (smartcardio) Invert reset argument in tests in > sun/security/smartcardio > 8035975: Pattern.compile(String, int) fails to throw > IllegalArgumentException > 6904367: (coll) IdentityHashMap is resized before exceeding the expected > maximum size > 8048080: (smartcardio) javax.smartcardio.Card.openLogicalChannel() > dosn't work on MacOSX > 8037866: Replace the Fun class in tests with lambdas > 8044342: build failure on Windows noticed with recent smartcardio fix > 8043720: (smartcardio) Native memory should be handled more accurately > 7047033: (smartcardio) Card.disconnect(boolean reset) does not reset > when reset is true > 8039319: (smartcardio) Card.transmitControlCommand() does not work on > Mac OS X > 8043476: java/util/BitSet/BSMethods.java failed with: > java.lang.OutOfMemoryError: Java heap space > 8043507: javax.smartcardio.CardTerminals.list() fails on MacOSX > 8043772: Typos in Double/Int/LongSummaryStatistics.java > 7195480: javax.smartcardio does not detect cards on Mac OS X > 8042470: (fs) Path.register doesn't throw IllegalArgumentException if > multiple OVERFLOW events are specified > 8011537: (fs) Path.register(..) clears interrupt status of thread with > no InterruptedException > 8040806: BitSet.toString() can throw IndexOutOfBoundsException > 8038982: java/lang/ref/EarlyTimeout.java failed again > 8039396: NPE when writing a class descriptor object to a custom > ObjectOutputStream > 8009637: Some error messages are missing a space > 8038333: TEST_BUG: java/lang/ref/EarlyTimeout.java fails with a > non-adequate message > 8014066: Remove redundant restriction from ArrayList#removeRange() spec > 6943190: TEST_BUG: some tests in java/lang/Runtime/exec have hard-coded > path to shell commands > 7011804: SequenceInputStream with lots of empty substreams can cause > StackOverflowError > 8036088: Replace strtok() with its safe equivalent strtok_s() in > DefaultProxySelector.c > 8034262: Test java/lang/ProcessBuilder/CloseRace.java fails > 6853696: (ref) ReferenceQueue.remove(timeout) may return null even if > timeout has not expired > 8023022: Some more typos in javadoc > 4682009: Typo in javadocs in javax/naming > 8033943: Typo in the documentation for the class Arrays > 8027348: (process) Enhancement of handling async close of > ProcessInputStream > 8025886: replace [[ and == bash extensions in regtest > 8030698: Several GUI labels in jconsole need correction > 8024521: (process) Async close issues with Process InputStream > 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the > latest jdk8 build > 8026756: Test java/util/zip/GZIP/GZIPInZip.java failed > 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed > 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf > descriptions > 7129312: BufferedInputStream calculates negative array size with large > streams and mark > 8022584: Memory leak in some NetworkInterface methods > 8020669: (fs) Files.readAllBytes() does not read any data when > Files.size() is 0 > 7192942: (coll) Inefficient calculation of power of two in HashMap > 8016838: improvement of RedefineBigClass and RetransformBigClass tests > 7181748: java/lang/ThreadGroup/Suspend.java test fails intermittently > > > $hg log -M -u igerasim -R hotspot --template "{desc}\n" | grep > "^[0-9]\{7,7\}: " > 8059533: (process) Make exiting process wait for exiting threads [win] > 8057744: (process) Synchronize exiting of threads and process [win] > 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java > fails with openjdk build > 8055338: (process) Add instrumentation to help diagnose JDK-6573254 > 8035893: JVM_GetVersionInfo fails to zero structure > > > > > From sean.coffey at oracle.com Mon Dec 8 09:41:03 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Mon, 08 Dec 2014 09:41:03 +0000 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <5485722F.4010403@oracle.com> Vote: yes regards, Sean. On 05/12/2014 18:35, Se?n Coffey wrote: > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. > > Ivan is a member of the Java SE Sustaining team and works mainly on > issues connected to the JDK core libraries. Over the past year, he's > demonstrated a strong understanding of how the core libraries code > works and has contributed significant bug fixes and enhancements in > JDK 9 [3]. > > Votes are due by 19:00 GMT December 19th 2014. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Sean. > From volker.simonis at gmail.com Mon Dec 8 10:16:17 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 8 Dec 2014 11:16:17 +0100 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: Vote: Yes. Regards, Volker On Fri, Dec 5, 2014 at 7:35 PM, Se?n Coffey wrote: > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. > > Ivan is a member of the Java SE Sustaining team and works mainly on issues > connected to the JDK core libraries. Over the past year, he's demonstrated a > strong understanding of how the core libraries code works and has > contributed significant bug fixes and enhancements in JDK 9 [3]. > > Votes are due by 19:00 GMT December 19th 2014. > > Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Sean. > > [1] : http://openjdk.java.net/census#jdk9 > [2] : http://openjdk.java.net/projects/#reviewer-vote > > [3] > $hg log -M -u igerasim -R jdk --template "{desc}\n" | grep "^[0-9]\{7,7\}: " > 8023173: FileDescriptor should respect append flag > 8059840: (bb) Typo in javadoc for ByteBuffer.wrap() > 8059450: Not quite correct code sample in javadoc > 8058099: (fc) Cleanup in FileChannel/FileDispatcher native implementation > [win] > 8054029: (fc) FileChannel.size() returns 0 for block devices on Linux > 7010989: Duplicate closure of file descriptors leads to unexpected and > incorrect closure of sockets > 8056310: Cleanup in WinNTFileSystem_md.c > 8054714: Use StringJoiner where it makes the code cleaner > 8055421: (fs) bad error handling in > java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > 8055731: sun/security/smartcardio/TestDirect.java throws > java.lang.IndexOutOfBoundsException > 8054841: (process) ProcessBuilder leaks native memory > 8046343: (smartcardio) CardTerminal.connect('direct') does not work on > MacOSX > 8054221: StringJoiner imlementation optimization > 8051382: Optimize java.lang.reflect.Modifier.toString() > 8050893: (smartcardio) Invert reset argument in tests in > sun/security/smartcardio > 8035975: Pattern.compile(String, int) fails to throw > IllegalArgumentException > 6904367: (coll) IdentityHashMap is resized before exceeding the expected > maximum size > 8048080: (smartcardio) javax.smartcardio.Card.openLogicalChannel() dosn't > work on MacOSX > 8037866: Replace the Fun class in tests with lambdas > 8044342: build failure on Windows noticed with recent smartcardio fix > 8043720: (smartcardio) Native memory should be handled more accurately > 7047033: (smartcardio) Card.disconnect(boolean reset) does not reset when > reset is true > 8039319: (smartcardio) Card.transmitControlCommand() does not work on Mac OS > X > 8043476: java/util/BitSet/BSMethods.java failed with: > java.lang.OutOfMemoryError: Java heap space > 8043507: javax.smartcardio.CardTerminals.list() fails on MacOSX > 8043772: Typos in Double/Int/LongSummaryStatistics.java > 7195480: javax.smartcardio does not detect cards on Mac OS X > 8042470: (fs) Path.register doesn't throw IllegalArgumentException if > multiple OVERFLOW events are specified > 8011537: (fs) Path.register(..) clears interrupt status of thread with no > InterruptedException > 8040806: BitSet.toString() can throw IndexOutOfBoundsException > 8038982: java/lang/ref/EarlyTimeout.java failed again > 8039396: NPE when writing a class descriptor object to a custom > ObjectOutputStream > 8009637: Some error messages are missing a space > 8038333: TEST_BUG: java/lang/ref/EarlyTimeout.java fails with a non-adequate > message > 8014066: Remove redundant restriction from ArrayList#removeRange() spec > 6943190: TEST_BUG: some tests in java/lang/Runtime/exec have hard-coded path > to shell commands > 7011804: SequenceInputStream with lots of empty substreams can cause > StackOverflowError > 8036088: Replace strtok() with its safe equivalent strtok_s() in > DefaultProxySelector.c > 8034262: Test java/lang/ProcessBuilder/CloseRace.java fails > 6853696: (ref) ReferenceQueue.remove(timeout) may return null even if > timeout has not expired > 8023022: Some more typos in javadoc > 4682009: Typo in javadocs in javax/naming > 8033943: Typo in the documentation for the class Arrays > 8027348: (process) Enhancement of handling async close of ProcessInputStream > 8025886: replace [[ and == bash extensions in regtest > 8030698: Several GUI labels in jconsole need correction > 8024521: (process) Async close issues with Process InputStream > 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the > latest jdk8 build > 8026756: Test java/util/zip/GZIP/GZIPInZip.java failed > 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed > 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions > 7129312: BufferedInputStream calculates negative array size with large > streams and mark > 8022584: Memory leak in some NetworkInterface methods > 8020669: (fs) Files.readAllBytes() does not read any data when Files.size() > is 0 > 7192942: (coll) Inefficient calculation of power of two in HashMap > 8016838: improvement of RedefineBigClass and RetransformBigClass tests > 7181748: java/lang/ThreadGroup/Suspend.java test fails intermittently > > > $hg log -M -u igerasim -R hotspot --template "{desc}\n" | grep > "^[0-9]\{7,7\}: " > 8059533: (process) Make exiting process wait for exiting threads [win] > 8057744: (process) Synchronize exiting of threads and process [win] > 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java fails > with openjdk build > 8055338: (process) Add instrumentation to help diagnose JDK-6573254 > 8035893: JVM_GetVersionInfo fails to zero structure > > > > > From stefan.sarne at oracle.com Mon Dec 8 10:19:26 2014 From: stefan.sarne at oracle.com (=?UTF-8?B?U3RlZmFuIFPDpHJuZQ==?=) Date: Mon, 08 Dec 2014 11:19:26 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <54856A31.9020702@oracle.com> References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com> <547DF8D8.8080601@oracle.com> <547E190F.1090407@oracle.com> <54800E21.2050700@oracle.com> <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <54855234.3050400@oracle.com> <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <54856A31.9020702@oracle.com> Message-ID: <54857B2E.8020100@oracle.com> I think this is a good path forward. The WhiteBox api is just the next example of test library code which we want to use both from the hotspot and the jdk repo. There are other classes which exists in both repos, which currently are copies. And just as expected with copies - time is spent to keep them in sync and yet they are not. Copy vs. share is a trade off but in this case I lean towards share, since this has been brought up as an issue at multiple times. Other examples are ProcessTools, OutputAnalyzer and friends. If we treat the WhiteBox API as a pilot, we should create an RFE that follows up for the other utilities. This would also be a good place to discuss the structure of the test library. I don't see a shared test library replacing the local ones - it would just a be a complement when the library code is shared. If we do setup a shared place for this, we also should have a good way to handle changes to it. It would be easy to start here - on jdk9-dev, but if it turns out to be needed, we could setup a separate list. Based on the discussion around microbenchmarks, it may make sense to break out the test folder to a separate repo if it starts growing. But again, perhaps this is something we can wait for and handle in the RFE. The test folder already exists in the top repo. Cheers, Stefan Tobias Hartmann skrev 2014-12-08 10:06: > CC'ing to jdk9-dev for wider audience. > > Summary: > The tests for the 'Segmented Code Cache' JEP [1] and other JDK tests [2] need > access to the Whitebox API testlibrary that is part of the hotspot repository. > > We therefore propose to move the Whitebox API from the hotspot repository to the > top level repository (test/testlibrary/) in the following steps: > > 1) Copy testlibrary to top level repository > 2) Adapt existing hotspot tests (> 200 tests) > 3) Remove testlibrary from hotspot repository > > First step: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/ > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8066625 > [2] https://bugs.openjdk.java.net/browse/JDK-8064875 > > On 08.12.2014 08:37, Staffan Larsen wrote: >> I am for this change in principle, but before we go ahead I think this warrants a larger discussion on build-dev at ojn or jdk9-dev at ojn. We need to propose and get acceptance for this from the larger group. >> >> (I was also surprised to see a Makefile here - who calls that?) >> >> /Staffan >> >>> On 8 dec 2014, at 08:24, Tobias Hartmann wrote: >>> >>> Hi, >>> >>> As we discussed off-thread I copied the Whitebox API to the top level repository >>> (test/testlibrary). We will then file a RFE to adopt the hotspot tests and >>> eventually remove the testlibrary from the hotspot repo. >>> >>> New webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/ >>> >>> Can I get reviews for this? >>> >>> Thanks, >>> Tobias >>> >>> On 04.12.2014 11:29, Staffan Larsen wrote: >>>> I don?t know which tests you are planning to write that require this feature, but can the tests be put into the hotspot repo instead of the jdk repo so that we avoid the duplication? It seems like the decision for JDK-8057707 was to not duplicate the code. >>>> >>>> /Staffan >>>> >>>>> On 4 dec 2014, at 08:32, Tobias Hartmann wrote: >>>>> >>>>> Mikael, Staffan, it looks like as if we don't have a nice solution for sharing >>>>> the library at the moment. What do you think about having the duplication as an >>>>> intermediate solution until we get the necessary support from jtreg / jprt to >>>>> share the library? >>>>> >>>>> There are also other JDK tests that would benefit from having the Whitebox API >>>>> available. For example, JDK-8057707 [1]. >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028532.html >>>>> >>>>> On 02.12.2014 20:54, Tobias Hartmann wrote: >>>>>> Hi Staffan, >>>>>> >>>>>> thanks for the feedback. >>>>>> >>>>>> On 02.12.2014 20:45, Staffan Larsen wrote: >>>>>>>> On 2 dec 2014, at 20:25, Staffan Larsen wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On 2 dec 2014, at 18:37, Tobias Hartmann wrote: >>>>>>>>> >>>>>>>>> Hi Mikael, >>>>>>>>> >>>>>>>>> On 02.12.2014 18:22, Mikael Vidstedt wrote: >>>>>>>>>> Tobias, >>>>>>>>>> >>>>>>>>>> Have you looked at what it would take to move the testlibrary somewhere where it >>>>>>>>>> can actually be shared instead? I think it would be extremely unfortunate to >>>>>>>>>> copy the code. I can't stress that enough. >>>>>>>>> I agree that having the testlibrary in a shared location is definitely the best >>>>>>>>> solution. Unfortunately, I don't know how to do that since we have to access the >>>>>>>>> library from different repositories and I don't think we want to have path >>>>>>>>> dependencies between the repositories. >>>>>>>>> >>>>>>>>> Any suggestions? >>>>>>>> jtreg currently requires the testlibrary to be located in or under the directory with the TEST.ROOT file. To move it somewhere else we need to change jtreg first - and I think we should. >>>>>>> I?ve been told that it is actually possible to do this with the current jtreg by using an ugly path such as: >>>>>>> >>>>>>> @library /../../test/testlibrary >>>>>>> >>>>>>> I don?t think that is what we want to do? >>>>>> Yes, that's what I meant with "path dependencies between repositories". I don't >>>>>> think this is a very robust solution. >>>>>> >>>>>> Best, >>>>>> Tobias >>>>>> >>>>>>> /Staffan >>>>>>> >>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Tobias >>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Mikael >>>>>>>>>> >>>>>>>>>> On 2014-12-02 06:40, Tobias Hartmann wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> please review the following patch that copies the Whitebox testlibrary to >>>>>>>>>>> /jdk/test. This is needed to enhance and fix jdk tests (for example, see [1]). >>>>>>>>>>> >>>>>>>>>>> The change leads to code duplication but in my opinion we should favour stable >>>>>>>>>>> tests over code duplication here. Hopefully, there is a solution to share the >>>>>>>>>>> library in the future. >>>>>>>>>>> >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433 >>>>>>>>>>> Webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Tobias From roger.riggs at oracle.com Mon Dec 8 14:27:19 2014 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 08 Dec 2014 09:27:19 -0500 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <5485B547.1020701@oracle.com> Vote: Yes On 12/5/2014 1:35 PM, Se?n Coffey wrote: > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. From mark.reinhold at oracle.com Mon Dec 8 19:18:59 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Mon, 08 Dec 2014 11:18:59 -0800 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <54857B2E.8020100@oracle.com> References: <547DCF47.9000608@oracle.com>, <547DF563.8080509@oracle.com>, <547DF8D8.8080601@oracle.com>, , , <547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>, <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>, <54855234.3050400@oracle.com>, <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>, <54856A31.9020702@oracle.com>, <54857B2E.8020100@oracle.com> Message-ID: <20141208111859.936395@eggemoggin.niobe.net> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com: > ... > > This would also be a good place to discuss the structure of the test > library. Yes. The various "testlibrary" directories in different repos are, at the moment, a bit of a mess and in some cases appear to be redundant. For the present root-repo proposal: - Why is it named test/testlibrary rather than test/lib, which is what's used in the jdk repo? - Why does the white-box library get its own directory? Shouldn't all test-library classes have the same package root? - The package name "sun.hotspot" is archaic. We should figure out a proper naming scheme for test-library packages, preferably starting with "jdk.". > ... > > Based on the discussion around microbenchmarks, it may make sense to > break out the test folder to a separate repo if it starts growing. > But again, perhaps this is something we can wait for and handle in the > RFE. The test folder already exists in the top repo. The jdk/test/lib directory has been around for many years now and only contains 28 files. It seems unlikely that the root-repo equivalent will ever be much larger than that, so a separate repo would be overkill. - Mark From staffan.larsen at oracle.com Mon Dec 8 19:46:59 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 8 Dec 2014 20:46:59 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <20141208111859.936395@eggemoggin.niobe.net> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com>, , , <547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>, <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>, <54855234.3050400@oracle.com>, <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>, <54856A31.9020702@oracle.com>, <54857B2E.8020100@oracle.com>>> <20141208111859.936395@eggemoggin.niobe.net> Message-ID: <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> > On 8 dec 2014, at 20:18, mark.reinhold at oracle.com wrote: > > 2014/12/8 2:19 -0800, stefan.sarne at oracle.com: >> ... >> >> This would also be a good place to discuss the structure of the test >> library. > > Yes. The various "testlibrary" directories in different repos are, at > the moment, a bit of a mess and in some cases appear to be redundant. > > For the present root-repo proposal: > > - Why is it named test/testlibrary rather than test/lib, which is > what's used in the jdk repo? Probably because it?s called test/testlibrary in the hotspot repo :-) > - Why does the white-box library get its own directory? Shouldn't > all test-library classes have the same package root? +1 > - The package name "sun.hotspot" is archaic. We should figure out a > proper naming scheme for test-library packages, preferably starting > with "jdk.?. So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? > >> ... >> >> Based on the discussion around microbenchmarks, it may make sense to >> break out the test folder to a separate repo if it starts growing. >> But again, perhaps this is something we can wait for and handle in the >> RFE. The test folder already exists in the top repo. > > The jdk/test/lib directory has been around for many years now and only > contains 28 files. It seems unlikely that the root-repo equivalent will > ever be much larger than that, so a separate repo would be overkill. The corresponding directory in hotspot has 56 files and has expanded quite a bit recently. I expect some growth to continue. Many of these overlap with the files in the jdk directory, however. /Staffan From bradford.wetmore at oracle.com Mon Dec 8 22:35:05 2014 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 08 Dec 2014 14:35:05 -0800 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <54862799.5060400@oracle.com> Vote: Yes Brad On 12/5/2014 10:35 AM, Se?n Coffey wrote: > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. > > Ivan is a member of the Java SE Sustaining team and works mainly on > issues connected to the JDK core libraries. Over the past year, he's > demonstrated a strong understanding of how the core libraries code works > and has contributed significant bug fixes and enhancements in JDK 9 [3]. > > Votes are due by 19:00 GMT December 19th 2014. > > Only current JDK 9 Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Sean. > > [1] : http://openjdk.java.net/census#jdk9 > [2] : http://openjdk.java.net/projects/#reviewer-vote > > [3] > $hg log -M -u igerasim -R jdk --template "{desc}\n" | grep > "^[0-9]\{7,7\}: " > 8023173: FileDescriptor should respect append flag > 8059840: (bb) Typo in javadoc for ByteBuffer.wrap() > 8059450: Not quite correct code sample in javadoc > 8058099: (fc) Cleanup in FileChannel/FileDispatcher native > implementation [win] > 8054029: (fc) FileChannel.size() returns 0 for block devices on Linux > 7010989: Duplicate closure of file descriptors leads to unexpected and > incorrect closure of sockets > 8056310: Cleanup in WinNTFileSystem_md.c > 8054714: Use StringJoiner where it makes the code cleaner > 8055421: (fs) bad error handling in > java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > 8055731: sun/security/smartcardio/TestDirect.java throws > java.lang.IndexOutOfBoundsException > 8054841: (process) ProcessBuilder leaks native memory > 8046343: (smartcardio) CardTerminal.connect('direct') does not work on > MacOSX > 8054221: StringJoiner imlementation optimization > 8051382: Optimize java.lang.reflect.Modifier.toString() > 8050893: (smartcardio) Invert reset argument in tests in > sun/security/smartcardio > 8035975: Pattern.compile(String, int) fails to throw > IllegalArgumentException > 6904367: (coll) IdentityHashMap is resized before exceeding the expected > maximum size > 8048080: (smartcardio) javax.smartcardio.Card.openLogicalChannel() > dosn't work on MacOSX > 8037866: Replace the Fun class in tests with lambdas > 8044342: build failure on Windows noticed with recent smartcardio fix > 8043720: (smartcardio) Native memory should be handled more accurately > 7047033: (smartcardio) Card.disconnect(boolean reset) does not reset > when reset is true > 8039319: (smartcardio) Card.transmitControlCommand() does not work on > Mac OS X > 8043476: java/util/BitSet/BSMethods.java failed with: > java.lang.OutOfMemoryError: Java heap space > 8043507: javax.smartcardio.CardTerminals.list() fails on MacOSX > 8043772: Typos in Double/Int/LongSummaryStatistics.java > 7195480: javax.smartcardio does not detect cards on Mac OS X > 8042470: (fs) Path.register doesn't throw IllegalArgumentException if > multiple OVERFLOW events are specified > 8011537: (fs) Path.register(..) clears interrupt status of thread with > no InterruptedException > 8040806: BitSet.toString() can throw IndexOutOfBoundsException > 8038982: java/lang/ref/EarlyTimeout.java failed again > 8039396: NPE when writing a class descriptor object to a custom > ObjectOutputStream > 8009637: Some error messages are missing a space > 8038333: TEST_BUG: java/lang/ref/EarlyTimeout.java fails with a > non-adequate message > 8014066: Remove redundant restriction from ArrayList#removeRange() spec > 6943190: TEST_BUG: some tests in java/lang/Runtime/exec have hard-coded > path to shell commands > 7011804: SequenceInputStream with lots of empty substreams can cause > StackOverflowError > 8036088: Replace strtok() with its safe equivalent strtok_s() in > DefaultProxySelector.c > 8034262: Test java/lang/ProcessBuilder/CloseRace.java fails > 6853696: (ref) ReferenceQueue.remove(timeout) may return null even if > timeout has not expired > 8023022: Some more typos in javadoc > 4682009: Typo in javadocs in javax/naming > 8033943: Typo in the documentation for the class Arrays > 8027348: (process) Enhancement of handling async close of > ProcessInputStream > 8025886: replace [[ and == bash extensions in regtest > 8030698: Several GUI labels in jconsole need correction > 8024521: (process) Async close issues with Process InputStream > 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the > latest jdk8 build > 8026756: Test java/util/zip/GZIP/GZIPInZip.java failed > 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed > 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf > descriptions > 7129312: BufferedInputStream calculates negative array size with large > streams and mark > 8022584: Memory leak in some NetworkInterface methods > 8020669: (fs) Files.readAllBytes() does not read any data when > Files.size() is 0 > 7192942: (coll) Inefficient calculation of power of two in HashMap > 8016838: improvement of RedefineBigClass and RetransformBigClass tests > 7181748: java/lang/ThreadGroup/Suspend.java test fails intermittently > > > $hg log -M -u igerasim -R hotspot --template "{desc}\n" | grep > "^[0-9]\{7,7\}: " > 8059533: (process) Make exiting process wait for exiting threads [win] > 8057744: (process) Synchronize exiting of threads and process [win] > 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java > fails with openjdk build > 8055338: (process) Add instrumentation to help diagnose JDK-6573254 > 8035893: JVM_GetVersionInfo fails to zero structure > > > > > From valerie.peng at oracle.com Mon Dec 8 23:00:22 2014 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 08 Dec 2014 15:00:22 -0800 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <54862799.5060400@oracle.com> References: <5481FAEE.2020102@oracle.com> <54862799.5060400@oracle.com> Message-ID: <54862D86.9030804@oracle.com> Vote: Yes Valerie > > On 12/5/2014 10:35 AM, Se?n Coffey wrote: >> I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. >> >> Ivan is a member of the Java SE Sustaining team and works mainly on >> issues connected to the JDK core libraries. Over the past year, he's >> demonstrated a strong understanding of how the core libraries code works >> and has contributed significant bug fixes and enhancements in JDK 9 [3]. >> >> Votes are due by 19:00 GMT December 19th 2014. >> >> Only current JDK 9 Reviewers [1] are eligible to vote on this >> nomination. Votes must be cast in the open by replying to this mailing >> list. >> >> For Three-Vote Consensus voting instructions, see [2]. >> >> Regards, >> Sean. >> >> [1] : http://openjdk.java.net/census#jdk9 >> [2] : http://openjdk.java.net/projects/#reviewer-vote >> >> [3] >> $hg log -M -u igerasim -R jdk --template "{desc}\n" | grep >> "^[0-9]\{7,7\}: " >> 8023173: FileDescriptor should respect append flag >> 8059840: (bb) Typo in javadoc for ByteBuffer.wrap() >> 8059450: Not quite correct code sample in javadoc >> 8058099: (fc) Cleanup in FileChannel/FileDispatcher native >> implementation [win] >> 8054029: (fc) FileChannel.size() returns 0 for block devices on Linux >> 7010989: Duplicate closure of file descriptors leads to unexpected and >> incorrect closure of sockets >> 8056310: Cleanup in WinNTFileSystem_md.c >> 8054714: Use StringJoiner where it makes the code cleaner >> 8055421: (fs) bad error handling in >> java.base/unix/native/libnio/fs/UnixNativeDispatcher.c >> 8055731: sun/security/smartcardio/TestDirect.java throws >> java.lang.IndexOutOfBoundsException >> 8054841: (process) ProcessBuilder leaks native memory >> 8046343: (smartcardio) CardTerminal.connect('direct') does not work on >> MacOSX >> 8054221: StringJoiner imlementation optimization >> 8051382: Optimize java.lang.reflect.Modifier.toString() >> 8050893: (smartcardio) Invert reset argument in tests in >> sun/security/smartcardio >> 8035975: Pattern.compile(String, int) fails to throw >> IllegalArgumentException >> 6904367: (coll) IdentityHashMap is resized before exceeding the expected >> maximum size >> 8048080: (smartcardio) javax.smartcardio.Card.openLogicalChannel() >> dosn't work on MacOSX >> 8037866: Replace the Fun class in tests with lambdas >> 8044342: build failure on Windows noticed with recent smartcardio fix >> 8043720: (smartcardio) Native memory should be handled more accurately >> 7047033: (smartcardio) Card.disconnect(boolean reset) does not reset >> when reset is true >> 8039319: (smartcardio) Card.transmitControlCommand() does not work on >> Mac OS X >> 8043476: java/util/BitSet/BSMethods.java failed with: >> java.lang.OutOfMemoryError: Java heap space >> 8043507: javax.smartcardio.CardTerminals.list() fails on MacOSX >> 8043772: Typos in Double/Int/LongSummaryStatistics.java >> 7195480: javax.smartcardio does not detect cards on Mac OS X >> 8042470: (fs) Path.register doesn't throw IllegalArgumentException if >> multiple OVERFLOW events are specified >> 8011537: (fs) Path.register(..) clears interrupt status of thread with >> no InterruptedException >> 8040806: BitSet.toString() can throw IndexOutOfBoundsException >> 8038982: java/lang/ref/EarlyTimeout.java failed again >> 8039396: NPE when writing a class descriptor object to a custom >> ObjectOutputStream >> 8009637: Some error messages are missing a space >> 8038333: TEST_BUG: java/lang/ref/EarlyTimeout.java fails with a >> non-adequate message >> 8014066: Remove redundant restriction from ArrayList#removeRange() spec >> 6943190: TEST_BUG: some tests in java/lang/Runtime/exec have hard-coded >> path to shell commands >> 7011804: SequenceInputStream with lots of empty substreams can cause >> StackOverflowError >> 8036088: Replace strtok() with its safe equivalent strtok_s() in >> DefaultProxySelector.c >> 8034262: Test java/lang/ProcessBuilder/CloseRace.java fails >> 6853696: (ref) ReferenceQueue.remove(timeout) may return null even if >> timeout has not expired >> 8023022: Some more typos in javadoc >> 4682009: Typo in javadocs in javax/naming >> 8033943: Typo in the documentation for the class Arrays >> 8027348: (process) Enhancement of handling async close of >> ProcessInputStream >> 8025886: replace [[ and == bash extensions in regtest >> 8030698: Several GUI labels in jconsole need correction >> 8024521: (process) Async close issues with Process InputStream >> 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the >> latest jdk8 build >> 8026756: Test java/util/zip/GZIP/GZIPInZip.java failed >> 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed >> 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf >> descriptions >> 7129312: BufferedInputStream calculates negative array size with large >> streams and mark >> 8022584: Memory leak in some NetworkInterface methods >> 8020669: (fs) Files.readAllBytes() does not read any data when >> Files.size() is 0 >> 7192942: (coll) Inefficient calculation of power of two in HashMap >> 8016838: improvement of RedefineBigClass and RetransformBigClass tests >> 7181748: java/lang/ThreadGroup/Suspend.java test fails intermittently >> >> >> $hg log -M -u igerasim -R hotspot --template "{desc}\n" | grep >> "^[0-9]\{7,7\}: " >> 8059533: (process) Make exiting process wait for exiting threads [win] >> 8057744: (process) Synchronize exiting of threads and process [win] >> 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java >> fails with openjdk build >> 8055338: (process) Add instrumentation to help diagnose JDK-6573254 >> 8035893: JVM_GetVersionInfo fails to zero structure >> >> >> >> >> From stuart.marks at oracle.com Tue Dec 9 00:17:35 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 08 Dec 2014 16:17:35 -0800 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <54863F9F.2090304@oracle.com> Vote: Yes. On 12/5/14 10:35 AM, Se?n Coffey wrote: > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. > > Ivan is a member of the Java SE Sustaining team and works mainly on issues > connected to the JDK core libraries. Over the past year, he's demonstrated a > strong understanding of how the core libraries code works and has contributed > significant bug fixes and enhancements in JDK 9 [3]. > > Votes are due by 19:00 GMT December 19th 2014. > > Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. Votes > must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Sean. > > [1] : http://openjdk.java.net/census#jdk9 > [2] : http://openjdk.java.net/projects/#reviewer-vote > > [3] > $hg log -M -u igerasim -R jdk --template "{desc}\n" | grep "^[0-9]\{7,7\}: " > 8023173: FileDescriptor should respect append flag > 8059840: (bb) Typo in javadoc for ByteBuffer.wrap() > 8059450: Not quite correct code sample in javadoc > 8058099: (fc) Cleanup in FileChannel/FileDispatcher native implementation [win] > 8054029: (fc) FileChannel.size() returns 0 for block devices on Linux > 7010989: Duplicate closure of file descriptors leads to unexpected and incorrect > closure of sockets > 8056310: Cleanup in WinNTFileSystem_md.c > 8054714: Use StringJoiner where it makes the code cleaner > 8055421: (fs) bad error handling in > java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > 8055731: sun/security/smartcardio/TestDirect.java throws > java.lang.IndexOutOfBoundsException > 8054841: (process) ProcessBuilder leaks native memory > 8046343: (smartcardio) CardTerminal.connect('direct') does not work on MacOSX > 8054221: StringJoiner imlementation optimization > 8051382: Optimize java.lang.reflect.Modifier.toString() > 8050893: (smartcardio) Invert reset argument in tests in sun/security/smartcardio > 8035975: Pattern.compile(String, int) fails to throw IllegalArgumentException > 6904367: (coll) IdentityHashMap is resized before exceeding the expected maximum > size > 8048080: (smartcardio) javax.smartcardio.Card.openLogicalChannel() dosn't work > on MacOSX > 8037866: Replace the Fun class in tests with lambdas > 8044342: build failure on Windows noticed with recent smartcardio fix > 8043720: (smartcardio) Native memory should be handled more accurately > 7047033: (smartcardio) Card.disconnect(boolean reset) does not reset when reset > is true > 8039319: (smartcardio) Card.transmitControlCommand() does not work on Mac OS X > 8043476: java/util/BitSet/BSMethods.java failed with: > java.lang.OutOfMemoryError: Java heap space > 8043507: javax.smartcardio.CardTerminals.list() fails on MacOSX > 8043772: Typos in Double/Int/LongSummaryStatistics.java > 7195480: javax.smartcardio does not detect cards on Mac OS X > 8042470: (fs) Path.register doesn't throw IllegalArgumentException if multiple > OVERFLOW events are specified > 8011537: (fs) Path.register(..) clears interrupt status of thread with no > InterruptedException > 8040806: BitSet.toString() can throw IndexOutOfBoundsException > 8038982: java/lang/ref/EarlyTimeout.java failed again > 8039396: NPE when writing a class descriptor object to a custom ObjectOutputStream > 8009637: Some error messages are missing a space > 8038333: TEST_BUG: java/lang/ref/EarlyTimeout.java fails with a non-adequate > message > 8014066: Remove redundant restriction from ArrayList#removeRange() spec > 6943190: TEST_BUG: some tests in java/lang/Runtime/exec have hard-coded path to > shell commands > 7011804: SequenceInputStream with lots of empty substreams can cause > StackOverflowError > 8036088: Replace strtok() with its safe equivalent strtok_s() in > DefaultProxySelector.c > 8034262: Test java/lang/ProcessBuilder/CloseRace.java fails > 6853696: (ref) ReferenceQueue.remove(timeout) may return null even if timeout > has not expired > 8023022: Some more typos in javadoc > 4682009: Typo in javadocs in javax/naming > 8033943: Typo in the documentation for the class Arrays > 8027348: (process) Enhancement of handling async close of ProcessInputStream > 8025886: replace [[ and == bash extensions in regtest > 8030698: Several GUI labels in jconsole need correction > 8024521: (process) Async close issues with Process InputStream > 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the latest > jdk8 build > 8026756: Test java/util/zip/GZIP/GZIPInZip.java failed > 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed > 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions > 7129312: BufferedInputStream calculates negative array size with large streams > and mark > 8022584: Memory leak in some NetworkInterface methods > 8020669: (fs) Files.readAllBytes() does not read any data when Files.size() is 0 > 7192942: (coll) Inefficient calculation of power of two in HashMap > 8016838: improvement of RedefineBigClass and RetransformBigClass tests > 7181748: java/lang/ThreadGroup/Suspend.java test fails intermittently > > > $hg log -M -u igerasim -R hotspot --template "{desc}\n" | grep "^[0-9]\{7,7\}: " > 8059533: (process) Make exiting process wait for exiting threads [win] > 8057744: (process) Synchronize exiting of threads and process [win] > 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java fails with > openjdk build > 8055338: (process) Add instrumentation to help diagnose JDK-6573254 > 8035893: JVM_GetVersionInfo fails to zero structure > > > > > From tobias.hartmann at oracle.com Tue Dec 9 09:51:40 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 09 Dec 2014 10:51:40 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com>, , , <547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>, <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>, <54855234.3050400@oracle.com>, <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>, <54856A31.9020702@oracle.com>, <54857B2E.8020100@oracle.com>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> Message-ID: <5486C62C.2040906@oracle.com> Hi, thanks for the feedback. On 08.12.2014 20:46, Staffan Larsen wrote: > >> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com wrote: >> >> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com: >>> ... >>> >>> This would also be a good place to discuss the structure of the test >>> library. >> >> Yes. The various "testlibrary" directories in different repos are, at >> the moment, a bit of a mess and in some cases appear to be redundant. >> >> For the present root-repo proposal: >> >> - Why is it named test/testlibrary rather than test/lib, which is >> what's used in the jdk repo? > > Probably because it?s called test/testlibrary in the hotspot repo :-) Yes, do you prefer 'test/lib'? > >> - Why does the white-box library get its own directory? Shouldn't >> all test-library classes have the same package root? > > +1 I agree. I'll remove the whitebox directory. > >> - The package name "sun.hotspot" is archaic. We should figure out a >> proper naming scheme for test-library packages, preferably starting >> with "jdk.?. > > So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? Whatever you prefer. Thanks, Tobias > >> >>> ... >>> >>> Based on the discussion around microbenchmarks, it may make sense to >>> break out the test folder to a separate repo if it starts growing. >>> But again, perhaps this is something we can wait for and handle in the >>> RFE. The test folder already exists in the top repo. >> >> The jdk/test/lib directory has been around for many years now and only >> contains 28 files. It seems unlikely that the root-repo equivalent will >> ever be much larger than that, so a separate repo would be overkill. > > The corresponding directory in hotspot has 56 files and has expanded quite a bit recently. I expect some growth to continue. Many of these overlap with the files in the jdk directory, however. > > /Staffan > From stefan.sarne at oracle.com Tue Dec 9 09:56:11 2014 From: stefan.sarne at oracle.com (Stefan Sarne) Date: Tue, 09 Dec 2014 10:56:11 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <5486C62C.2040906@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com>, , , <547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>, <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>, <54855234.3050400@oracle.com>, <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>, <54856A31.9020702@oracle.com>, <54857B2E.8020100@oracle.com>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> <5486C62C.2040906@oracle.com> Message-ID: <5486C73B.5080206@oracle.com> Hi, On 2014-12-09 10:51, Tobias Hartmann wrote: > Hi, > > thanks for the feedback. > > On 08.12.2014 20:46, Staffan Larsen wrote: >>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com wrote: >>> >>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com: >>>> ... >>>> >>>> This would also be a good place to discuss the structure of the test >>>> library. >>> Yes. The various "testlibrary" directories in different repos are, at >>> the moment, a bit of a mess and in some cases appear to be redundant. >>> >>> For the present root-repo proposal: >>> >>> - Why is it named test/testlibrary rather than test/lib, which is >>> what's used in the jdk repo? >> Probably because it?s called test/testlibrary in the hotspot repo :-) > Yes, do you prefer 'test/lib'? Now sounds like a good time to align. :) We can update testlibrary in hotspot to the same as well I think (as a second step). Let's go with test/lib. > >>> - Why does the white-box library get its own directory? Shouldn't >>> all test-library classes have the same package root? >> +1 > I agree. I'll remove the whitebox directory. Sounds good, the same package root is better. > >>> - The package name "sun.hotspot" is archaic. We should figure out a >>> proper naming scheme for test-library packages, preferably starting >>> with "jdk.?. >> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? > Whatever you prefer. If we go with test/lib - I think jdk.testlib make sense. Thanks Stefan > > Thanks, > Tobias > >>>> ... >>>> >>>> Based on the discussion around microbenchmarks, it may make sense to >>>> break out the test folder to a separate repo if it starts growing. >>>> But again, perhaps this is something we can wait for and handle in the >>>> RFE. The test folder already exists in the top repo. >>> The jdk/test/lib directory has been around for many years now and only >>> contains 28 files. It seems unlikely that the root-repo equivalent will >>> ever be much larger than that, so a separate repo would be overkill. >> The corresponding directory in hotspot has 56 files and has expanded quite a bit recently. I expect some growth to continue. Many of these overlap with the files in the jdk directory, however. >> >> /Staffan >> From staffan.larsen at oracle.com Tue Dec 9 10:00:12 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 9 Dec 2014 11:00:12 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <5486C73B.5080206@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com> <, <, , <547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>, <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>, <54855234.3050400@oracle.com>, <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>, <54856A31.9020702@oracle.com>, <54857B2E.8020100@oracle.com>>>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> <5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com> Message-ID: <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com> +1 > On 9 dec 2014, at 10:56, Stefan Sarne wrote: > > > Hi, > > On 2014-12-09 10:51, Tobias Hartmann wrote: >> Hi, >> >> thanks for the feedback. >> >> On 08.12.2014 20:46, Staffan Larsen wrote: >>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com wrote: >>>> >>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com: >>>>> ... >>>>> >>>>> This would also be a good place to discuss the structure of the test >>>>> library. >>>> Yes. The various "testlibrary" directories in different repos are, at >>>> the moment, a bit of a mess and in some cases appear to be redundant. >>>> >>>> For the present root-repo proposal: >>>> >>>> - Why is it named test/testlibrary rather than test/lib, which is >>>> what's used in the jdk repo? >>> Probably because it?s called test/testlibrary in the hotspot repo :-) >> Yes, do you prefer 'test/lib'? > > Now sounds like a good time to align. :) > We can update testlibrary in hotspot to the same as well I think (as a second step). > Let's go with test/lib. > >> >>>> - Why does the white-box library get its own directory? Shouldn't >>>> all test-library classes have the same package root? >>> +1 >> I agree. I'll remove the whitebox directory. > > Sounds good, the same package root is better. > >> >>>> - The package name "sun.hotspot" is archaic. We should figure out a >>>> proper naming scheme for test-library packages, preferably starting >>>> with "jdk.?. >>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? >> Whatever you prefer. > > If we go with test/lib - I think jdk.testlib make sense. > > Thanks > Stefan > >> >> Thanks, >> Tobias >> >>>>> ... >>>>> >>>>> Based on the discussion around microbenchmarks, it may make sense to >>>>> break out the test folder to a separate repo if it starts growing. >>>>> But again, perhaps this is something we can wait for and handle in the >>>>> RFE. The test folder already exists in the top repo. >>>> The jdk/test/lib directory has been around for many years now and only >>>> contains 28 files. It seems unlikely that the root-repo equivalent will >>>> ever be much larger than that, so a separate repo would be overkill. >>> The corresponding directory in hotspot has 56 files and has expanded quite a bit recently. I expect some growth to continue. Many of these overlap with the files in the jdk directory, however. >>> >>> /Staffan From Alan.Bateman at oracle.com Tue Dec 9 10:08:11 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 09 Dec 2014 10:08:11 +0000 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <54856A31.9020702@oracle.com> References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com> <547DF8D8.8080601@oracle.com> <547E190F.1090407@oracle.com> <54800E21.2050700@oracle.com> <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <54855234.3050400@oracle.com> <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <54856A31.9020702@oracle.com> Message-ID: <5486CA0B.4010501@oracle.com> On 08/12/2014 09:06, Tobias Hartmann wrote: > CC'ing to jdk9-dev for wider audience. > > Summary: > The tests for the 'Segmented Code Cache' JEP [1] and other JDK tests [2] need > access to the Whitebox API testlibrary that is part of the hotspot repository. > > We therefore propose to move the Whitebox API from the hotspot repository to the > top level repository (test/testlibrary/) in the following steps: > > 1) Copy testlibrary to top level repository > 2) Adapt existing hotspot tests (> 200 tests) > 3) Remove testlibrary from hotspot repository > > First step: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/ > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8066625 > [2] https://bugs.openjdk.java.net/browse/JDK-8064875 > Maybe this has been discussed previously but how do test libraries in the top-level repo work for test roots that are in the hotspot and jdk repos? Is there jtreg support for this or are you proposing @library ../../../../../ ? I realize this might be a question for future steps but still useful to know where this is going. -Alan From staffan.larsen at oracle.com Tue Dec 9 10:15:05 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 9 Dec 2014 11:15:05 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <5486CA0B.4010501@oracle.com> References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com> <547DF8D8.8080601@oracle.com> <547E190F.1090407@oracle.com> <54800E21.2050700@oracle.com> <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <54855234.3050400@oracle.com> <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <54856A31.9020702@oracle.com> <5486CA0B.4010501@oracle.com> Message-ID: <43F17AFB-5E36-41BF-BB29-429ECEF9D977@oracle.com> > On 9 dec 2014, at 11:08, Alan Bateman wrote: > > On 08/12/2014 09:06, Tobias Hartmann wrote: >> CC'ing to jdk9-dev for wider audience. >> >> Summary: >> The tests for the 'Segmented Code Cache' JEP [1] and other JDK tests [2] need >> access to the Whitebox API testlibrary that is part of the hotspot repository. >> >> We therefore propose to move the Whitebox API from the hotspot repository to the >> top level repository (test/testlibrary/) in the following steps: >> >> 1) Copy testlibrary to top level repository >> 2) Adapt existing hotspot tests (> 200 tests) >> 3) Remove testlibrary from hotspot repository >> >> First step: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/ >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8066625 >> [2] https://bugs.openjdk.java.net/browse/JDK-8064875 >> > Maybe this has been discussed previously but how do test libraries in the top-level repo work for test roots that are in the hotspot and jdk repos? Is there jtreg support for this or are you proposing @library ../../../../../ ? I realize this might be a question for future steps but still useful to know where this is going. The suggestion is to use "@library /../../test/lib?. Using an initial slash means that the path is relative to TEST.ROOT, not to the test itself. I?m not sure if this was intended in jtreg or if it just happens to work. I?m sure we can think of cleaner approach in the future. /Staffan From tobias.hartmann at oracle.com Tue Dec 9 14:43:01 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 09 Dec 2014 15:43:01 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com> <, <, , <547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>, <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>, <54855234.3050400@oracle.com>, <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>, <54856A31.9020702@oracle.com>, <54857B2E.8020100@oracle.com>>>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> <5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com> <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com> Message-ID: <54870A75.2000008@oracle.com> Hi, I just noticed that if we want to access the Whitebox API in the top level repository we also have to adapt the native lookup code in src/share/vm/prims/nativeLookup.cpp because it depends on the package name. I therefore suggest to move the Whitebox API completely and adapt all tests in the hotspot repository. Here are the corresponding webrevs: Top level repo: http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ Hotspot repo: http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/ Tested on JPRT. Thanks, Tobias On 09.12.2014 11:00, Staffan Larsen wrote: > +1 > >> On 9 dec 2014, at 10:56, Stefan Sarne > > wrote: >> >> >> Hi, >> >> On 2014-12-09 10:51, Tobias Hartmann wrote: >>> Hi, >>> >>> thanks for the feedback. >>> >>> On 08.12.2014 20:46, Staffan Larsen wrote: >>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com >>>>> wrote: >>>>> >>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com : >>>>>> ... >>>>>> >>>>>> This would also be a good place to discuss the structure of the test >>>>>> library. >>>>> Yes. The various "testlibrary" directories in different repos are, at >>>>> the moment, a bit of a mess and in some cases appear to be redundant. >>>>> >>>>> For the present root-repo proposal: >>>>> >>>>> - Why is it named test/testlibrary rather than test/lib, which is >>>>> what's used in the jdk repo? >>>> Probably because it?s called test/testlibrary in the hotspot repo :-) >>> Yes, do you prefer 'test/lib'? >> >> Now sounds like a good time to align. :) >> We can update testlibrary in hotspot to the same as well I think (as a second >> step). >> Let's go with test/lib. >> >>> >>>>> - Why does the white-box library get its own directory? Shouldn't >>>>> all test-library classes have the same package root? >>>> +1 >>> I agree. I'll remove the whitebox directory. >> >> Sounds good, the same package root is better. >> >>> >>>>> - The package name "sun.hotspot" is archaic. We should figure out a >>>>> proper naming scheme for test-library packages, preferably starting >>>>> with "jdk.?. >>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? >>> Whatever you prefer. >> >> If we go with test/lib - I think jdk.testlib make sense. >> >> Thanks >> Stefan >> >>> >>> Thanks, >>> Tobias >>> >>>>>> ... >>>>>> >>>>>> Based on the discussion around microbenchmarks, it may make sense to >>>>>> break out the test folder to a separate repo if it starts growing. >>>>>> But again, perhaps this is something we can wait for and handle in the >>>>>> RFE. The test folder already exists in the top repo. >>>>> The jdk/test/lib directory has been around for many years now and only >>>>> contains 28 files. It seems unlikely that the root-repo equivalent will >>>>> ever be much larger than that, so a separate repo would be overkill. >>>> The corresponding directory in hotspot has 56 files and has expanded quite a >>>> bit recently. I expect some growth to continue. Many of these overlap with >>>> the files in the jdk directory, however. >>>> >>>> /Staffan > From mark.reinhold at oracle.com Tue Dec 9 17:09:30 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 09 Dec 2014 09:09:30 -0800 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <5486C73B.5080206@oracle.com> References: <547DCF47.9000608@oracle.com>, <>, <<547DF563.8080509@oracle.com>, <5486C62C.2040906@oracle.com>, <5486C73B.5080206@oracle.com> Message-ID: <20141209090930.405310@eggemoggin.niobe.net> 2014/12/9 1:56 -0800, stefan.sarne at oracle.com: > On 2014-12-09 10:51, Tobias Hartmann wrote: >> On 08.12.2014 20:46, Staffan Larsen wrote: >>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com wrote: >>>> ... >>>> >>>> - Why is it named test/testlibrary rather than test/lib, which is >>>> what's used in the jdk repo? >>> >>> Probably because it?s called test/testlibrary in the hotspot repo :-) >> >> Yes, do you prefer 'test/lib'? > > Now sounds like a good time to align. :) > We can update testlibrary in hotspot to the same as well I think (as a > second step). > > Let's go with test/lib. Works for me. > ... >>>> - The package name "sun.hotspot" is archaic. We should figure out a >>>> proper naming scheme for test-library packages, preferably starting >>>> with "jdk.?. >>> >>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? >> >> Whatever you prefer. > > If we go with test/lib - I think jdk.testlib make sense. I suggest jdk.test.lib -- that way the prefix "jdk.test" can be used in other situations where test code needs a package name. - Mark From dmitry.samersoff at oracle.com Tue Dec 9 17:45:46 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 09 Dec 2014 20:45:46 +0300 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <54857B2E.8020100@oracle.com> References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com> <547DF8D8.8080601@oracle.com> <547E190F.1090407@oracle.com> <54800E21.2050700@oracle.com> <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <54855234.3050400@oracle.com> <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <54856A31.9020702@oracle.com> <54857B2E.8020100@oracle.com> Message-ID: <5487354A.8090201@oracle.com> Stefan, Moving tests to separate repo solves countless number of problems, in a range from testlibrary access/development to better jprt load. As soon as we have all tests in jtreg format, jdk/test and hotspot/test become too large. So we have to move these tests to separate repo sooner or later. Is it possible to do it now? -Dmitry On 2014-12-08 13:19, Stefan S?rne wrote: > > I think this is a good path forward. > > The WhiteBox api is just the next example of test library code which we > want to use both from the hotspot and the jdk repo. There are other > classes which exists in both repos, which currently are copies. And just > as expected with copies - time is spent to keep them in sync and yet > they are not. Copy vs. share is a trade off but in this case I lean > towards share, since this has been brought up as an issue at multiple > times. Other examples are ProcessTools, OutputAnalyzer and friends. > > If we treat the WhiteBox API as a pilot, we should create an RFE that > follows up for the other utilities. > This would also be a good place to discuss the structure of the test > library. > > I don't see a shared test library replacing the local ones - it would > just a be a complement when the library code is shared. > > If we do setup a shared place for this, we also should have a good way > to handle changes to it. > It would be easy to start here - on jdk9-dev, but if it turns out to be > needed, we could setup a separate list. > > Based on the discussion around microbenchmarks, it may make sense to > break out the test folder to a separate repo if it starts growing. > But again, perhaps this is something we can wait for and handle in the > RFE. The test folder already exists in the top repo. > > Cheers, > Stefan > > > Tobias Hartmann skrev 2014-12-08 10:06: >> CC'ing to jdk9-dev for wider audience. >> >> Summary: >> The tests for the 'Segmented Code Cache' JEP [1] and other JDK tests >> [2] need >> access to the Whitebox API testlibrary that is part of the hotspot >> repository. >> >> We therefore propose to move the Whitebox API from the hotspot >> repository to the >> top level repository (test/testlibrary/) in the following steps: >> >> 1) Copy testlibrary to top level repository >> 2) Adapt existing hotspot tests (> 200 tests) >> 3) Remove testlibrary from hotspot repository >> >> First step: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/ >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8066625 >> [2] https://bugs.openjdk.java.net/browse/JDK-8064875 >> >> On 08.12.2014 08:37, Staffan Larsen wrote: >>> I am for this change in principle, but before we go ahead I think >>> this warrants a larger discussion on build-dev at ojn or jdk9-dev at ojn. >>> We need to propose and get acceptance for this from the larger group. >>> >>> (I was also surprised to see a Makefile here - who calls that?) >>> >>> /Staffan >>> >>>> On 8 dec 2014, at 08:24, Tobias Hartmann >>>> wrote: >>>> >>>> Hi, >>>> >>>> As we discussed off-thread I copied the Whitebox API to the top >>>> level repository >>>> (test/testlibrary). We will then file a RFE to adopt the hotspot >>>> tests and >>>> eventually remove the testlibrary from the hotspot repo. >>>> >>>> New webrev: http://cr.openjdk.java.net/~thartmann/8066433/webrev.01/ >>>> >>>> Can I get reviews for this? >>>> >>>> Thanks, >>>> Tobias >>>> >>>> On 04.12.2014 11:29, Staffan Larsen wrote: >>>>> I don?t know which tests you are planning to write that require >>>>> this feature, but can the tests be put into the hotspot repo >>>>> instead of the jdk repo so that we avoid the duplication? It seems >>>>> like the decision for JDK-8057707 was to not duplicate the code. >>>>> >>>>> /Staffan >>>>> >>>>>> On 4 dec 2014, at 08:32, Tobias Hartmann >>>>>> wrote: >>>>>> >>>>>> Mikael, Staffan, it looks like as if we don't have a nice solution >>>>>> for sharing >>>>>> the library at the moment. What do you think about having the >>>>>> duplication as an >>>>>> intermediate solution until we get the necessary support from >>>>>> jtreg / jprt to >>>>>> share the library? >>>>>> >>>>>> There are also other JDK tests that would benefit from having the >>>>>> Whitebox API >>>>>> available. For example, JDK-8057707 [1]. >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>> [1] >>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-September/028532.html >>>>>> >>>>>> >>>>>> On 02.12.2014 20:54, Tobias Hartmann wrote: >>>>>>> Hi Staffan, >>>>>>> >>>>>>> thanks for the feedback. >>>>>>> >>>>>>> On 02.12.2014 20:45, Staffan Larsen wrote: >>>>>>>>> On 2 dec 2014, at 20:25, Staffan Larsen >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 2 dec 2014, at 18:37, Tobias Hartmann >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Mikael, >>>>>>>>>> >>>>>>>>>> On 02.12.2014 18:22, Mikael Vidstedt wrote: >>>>>>>>>>> Tobias, >>>>>>>>>>> >>>>>>>>>>> Have you looked at what it would take to move the testlibrary >>>>>>>>>>> somewhere where it >>>>>>>>>>> can actually be shared instead? I think it would be extremely >>>>>>>>>>> unfortunate to >>>>>>>>>>> copy the code. I can't stress that enough. >>>>>>>>>> I agree that having the testlibrary in a shared location is >>>>>>>>>> definitely the best >>>>>>>>>> solution. Unfortunately, I don't know how to do that since we >>>>>>>>>> have to access the >>>>>>>>>> library from different repositories and I don't think we want >>>>>>>>>> to have path >>>>>>>>>> dependencies between the repositories. >>>>>>>>>> >>>>>>>>>> Any suggestions? >>>>>>>>> jtreg currently requires the testlibrary to be located in or >>>>>>>>> under the directory with the TEST.ROOT file. To move it >>>>>>>>> somewhere else we need to change jtreg first - and I think we >>>>>>>>> should. >>>>>>>> I?ve been told that it is actually possible to do this with the >>>>>>>> current jtreg by using an ugly path such as: >>>>>>>> >>>>>>>> @library /../../test/testlibrary >>>>>>>> >>>>>>>> I don?t think that is what we want to do? >>>>>>> Yes, that's what I meant with "path dependencies between >>>>>>> repositories". I don't >>>>>>> think this is a very robust solution. >>>>>>> >>>>>>> Best, >>>>>>> Tobias >>>>>>> >>>>>>>> /Staffan >>>>>>>> >>>>>>>> >>>>>>>>> /Staffan >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tobias >>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Mikael >>>>>>>>>>> >>>>>>>>>>> On 2014-12-02 06:40, Tobias Hartmann wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> please review the following patch that copies the Whitebox >>>>>>>>>>>> testlibrary to >>>>>>>>>>>> /jdk/test. This is needed to enhance and fix jdk tests (for >>>>>>>>>>>> example, see [1]). >>>>>>>>>>>> >>>>>>>>>>>> The change leads to code duplication but in my opinion we >>>>>>>>>>>> should favour stable >>>>>>>>>>>> tests over code duplication here. Hopefully, there is a >>>>>>>>>>>> solution to share the >>>>>>>>>>>> library in the future. >>>>>>>>>>>> >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8066433 >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Tobias > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From igor.ignatyev at oracle.com Tue Dec 9 18:19:41 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 09 Dec 2014 21:19:41 +0300 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <54870A75.2000008@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com> <, <, , <547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>, <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>, <54855234.3050400@oracle.com>, <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>, <54856A31.9020702@oracle.com>, <54857B2E.8020100@oracle.com>>>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> <5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com> <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com> <54870A75.2000008@oracle.com> Message-ID: <54873D3D.2030704@oracle.com> Guys, changing Whitebox package name will cause failures in the tens tests which and aren't co-located w/ the product. right now, we have jigsaw m2 integrating into group repos, this also can lead to some failures. and I'd like not to have these failures mixed up. so I don't want to have whitebox renamed this and next week. however I do want to have whitebox available in jdk and hotspot repo this week. can we move whitebox to top repo now and do renaming later? On 12/09/2014 05:43 PM, Tobias Hartmann wrote: > Hi, > > I just noticed that if we want to access the Whitebox API in the top level > repository we also have to adapt the native lookup code in > src/share/vm/prims/nativeLookup.cpp because it depends on the package name. > > I therefore suggest to move the Whitebox API completely and adapt all tests in > the hotspot repository. Here are the corresponding webrevs: > > Top level repo: > http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ > > Hotspot repo: > http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/ > > Tested on JPRT. > > Thanks, > Tobias > > On 09.12.2014 11:00, Staffan Larsen wrote: >> +1 >> >>> On 9 dec 2014, at 10:56, Stefan Sarne >> > wrote: >>> >>> >>> Hi, >>> >>> On 2014-12-09 10:51, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> thanks for the feedback. >>>> >>>> On 08.12.2014 20:46, Staffan Larsen wrote: >>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com >>>>>> wrote: >>>>>> >>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com : >>>>>>> ... >>>>>>> >>>>>>> This would also be a good place to discuss the structure of the test >>>>>>> library. >>>>>> Yes. The various "testlibrary" directories in different repos are, at >>>>>> the moment, a bit of a mess and in some cases appear to be redundant. >>>>>> >>>>>> For the present root-repo proposal: >>>>>> >>>>>> - Why is it named test/testlibrary rather than test/lib, which is >>>>>> what's used in the jdk repo? >>>>> Probably because it?s called test/testlibrary in the hotspot repo :-) >>>> Yes, do you prefer 'test/lib'? >>> >>> Now sounds like a good time to align. :) >>> We can update testlibrary in hotspot to the same as well I think (as a second >>> step). >>> Let's go with test/lib. >>> >>>> >>>>>> - Why does the white-box library get its own directory? Shouldn't >>>>>> all test-library classes have the same package root? >>>>> +1 >>>> I agree. I'll remove the whitebox directory. >>> >>> Sounds good, the same package root is better. >>> >>>> >>>>>> - The package name "sun.hotspot" is archaic. We should figure out a >>>>>> proper naming scheme for test-library packages, preferably starting >>>>>> with "jdk.?. >>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? >>>> Whatever you prefer. >>> >>> If we go with test/lib - I think jdk.testlib make sense. >>> >>> Thanks >>> Stefan >>> >>>> >>>> Thanks, >>>> Tobias >>>> >>>>>>> ... >>>>>>> >>>>>>> Based on the discussion around microbenchmarks, it may make sense to >>>>>>> break out the test folder to a separate repo if it starts growing. >>>>>>> But again, perhaps this is something we can wait for and handle in the >>>>>>> RFE. The test folder already exists in the top repo. >>>>>> The jdk/test/lib directory has been around for many years now and only >>>>>> contains 28 files. It seems unlikely that the root-repo equivalent will >>>>>> ever be much larger than that, so a separate repo would be overkill. >>>>> The corresponding directory in hotspot has 56 files and has expanded quite a >>>>> bit recently. I expect some growth to continue. Many of these overlap with >>>>> the files in the jdk directory, however. >>>>> >>>>> /Staffan >> -- Igor From stefan.sarne at oracle.com Tue Dec 9 19:04:52 2014 From: stefan.sarne at oracle.com (=?UTF-8?B?U3RlZmFuIFPDpHJuZQ==?=) Date: Tue, 09 Dec 2014 20:04:52 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <54873D3D.2030704@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com> <, <, , <547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>, <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>, <54855234.3050400@oracle.com>, <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>, <54856A31.9020702@oracle.com>, <54857B2E.8020100@oracle.com>>>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> <5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com> <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com> <54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com> Message-ID: <548747D4.40805@oracle.com> Make sense. I am ok with delaying the name change. There is a phase two with the bulk of the job to this anyway. Dmitry, this is where we can have the repo discussion as well. I think there is an interesting part here anyway. Best regards, Stefan Igor Ignatyev skrev 2014-12-09 19:19: > Guys, > > changing Whitebox package name will cause failures in the tens tests > which and aren't co-located w/ the product. > right now, we have jigsaw m2 integrating into group repos, this also > can lead to some failures. and I'd like not to have these failures > mixed up. so I don't want to have whitebox renamed this and next week. > however I do want to have whitebox available in jdk and hotspot repo > this week. > > can we move whitebox to top repo now and do renaming later? > > On 12/09/2014 05:43 PM, Tobias Hartmann wrote: >> Hi, >> >> I just noticed that if we want to access the Whitebox API in the top >> level >> repository we also have to adapt the native lookup code in >> src/share/vm/prims/nativeLookup.cpp because it depends on the package >> name. >> >> I therefore suggest to move the Whitebox API completely and adapt all >> tests in >> the hotspot repository. Here are the corresponding webrevs: >> >> Top level repo: >> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >> >> Hotspot repo: >> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/ >> >> Tested on JPRT. >> >> Thanks, >> Tobias >> >> On 09.12.2014 11:00, Staffan Larsen wrote: >>> +1 >>> >>>> On 9 dec 2014, at 10:56, Stefan Sarne >>> > wrote: >>>> >>>> >>>> Hi, >>>> >>>> On 2014-12-09 10:51, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> thanks for the feedback. >>>>> >>>>> On 08.12.2014 20:46, Staffan Larsen wrote: >>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com >>>>>>> wrote: >>>>>>> >>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com >>>>>>> : >>>>>>>> ... >>>>>>>> >>>>>>>> This would also be a good place to discuss the structure of the >>>>>>>> test >>>>>>>> library. >>>>>>> Yes. The various "testlibrary" directories in different repos >>>>>>> are, at >>>>>>> the moment, a bit of a mess and in some cases appear to be >>>>>>> redundant. >>>>>>> >>>>>>> For the present root-repo proposal: >>>>>>> >>>>>>> - Why is it named test/testlibrary rather than test/lib, which is >>>>>>> what's used in the jdk repo? >>>>>> Probably because it?s called test/testlibrary in the hotspot repo >>>>>> :-) >>>>> Yes, do you prefer 'test/lib'? >>>> >>>> Now sounds like a good time to align. :) >>>> We can update testlibrary in hotspot to the same as well I think >>>> (as a second >>>> step). >>>> Let's go with test/lib. >>>> >>>>> >>>>>>> - Why does the white-box library get its own directory? >>>>>>> Shouldn't >>>>>>> all test-library classes have the same package root? >>>>>> +1 >>>>> I agree. I'll remove the whitebox directory. >>>> >>>> Sounds good, the same package root is better. >>>> >>>>> >>>>>>> - The package name "sun.hotspot" is archaic. We should figure >>>>>>> out a >>>>>>> proper naming scheme for test-library packages, preferably >>>>>>> starting >>>>>>> with "jdk.?. >>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? >>>>> Whatever you prefer. >>>> >>>> If we go with test/lib - I think jdk.testlib make sense. >>>> >>>> Thanks >>>> Stefan >>>> >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>>>>> ... >>>>>>>> >>>>>>>> Based on the discussion around microbenchmarks, it may make >>>>>>>> sense to >>>>>>>> break out the test folder to a separate repo if it starts growing. >>>>>>>> But again, perhaps this is something we can wait for and handle >>>>>>>> in the >>>>>>>> RFE. The test folder already exists in the top repo. >>>>>>> The jdk/test/lib directory has been around for many years now >>>>>>> and only >>>>>>> contains 28 files. It seems unlikely that the root-repo >>>>>>> equivalent will >>>>>>> ever be much larger than that, so a separate repo would be >>>>>>> overkill. >>>>>> The corresponding directory in hotspot has 56 files and has >>>>>> expanded quite a >>>>>> bit recently. I expect some growth to continue. Many of these >>>>>> overlap with >>>>>> the files in the jdk directory, however. >>>>>> >>>>>> /Staffan >>> > From stefan.sarne at oracle.com Tue Dec 9 19:09:25 2014 From: stefan.sarne at oracle.com (=?UTF-8?B?U3RlZmFuIFPDpHJuZQ==?=) Date: Tue, 09 Dec 2014 20:09:25 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <20141209090930.405310@eggemoggin.niobe.net> References: <547DCF47.9000608@oracle.com>, <>, <<547DF563.8080509@oracle.com>, <5486C62C.2040906@oracle.com>, <5486C73B.5080206@oracle.com> <20141209090930.405310@eggemoggin.niobe.net> Message-ID: <548748E5.80304@oracle.com> Sure. /Stefan > I suggest jdk.test.lib -- that way the prefix "jdk.test" can be used > in other situations where test code needs a package name. > > - Mark From alejandro.murillo at oracle.com Tue Dec 9 22:47:52 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 09 Dec 2014 15:47:52 -0700 Subject: jdk9-dev: HotSpot Message-ID: <54877C18.2090805@oracle.com> jdk9-hs-2014-12-05 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/4021692a9e46 http://hg.openjdk.java.net/jdk9/dev/corba/rev/078bb11af876 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e2457e3f8c0e http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/47b0d3fa4118 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/301ddb4478fb http://hg.openjdk.java.net/jdk9/dev/jdk/rev/50cb7c75d05e http://hg.openjdk.java.net/jdk9/dev/langtools/rev/f114c0889340 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/e5b476bff0bd Component : VM Status : Go for integration Date : 09/12/2014 at 20:30 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2014-12-06-004132.amurillo.jdk9-hs-2014-12-05-snapshot Testing: 402 new failures, 4765 known failures, 355690 passed. Issues and Notes: All JCK tests failed. We need to switch on JCK version adapted to jigsaw (not ready yet) No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 7176220: 'Full GC' events miss date stamp information occasionally 8035663: Suspicious failure of test java/util/concurrent/Phaser/FickleRegister.java 8037968: Add tests on alignment of objects copied to survivor space 8039995: Test serviceability/sa/jmap-hashcode/Test8028623.java fails on some Linux/Mac machines. 8053995: Add method to WhiteBox to get vm pagesize. 8055239: assert(_thread == Thread::current()->osthread()) failed: The PromotionFailedInfo should be thread local 8058846: c.o.j.t.Platform::isX86 and isX64 may simultaneously return true 8058935: CPU detection gives 0 cores per cpu, 2 threads per core in Amazon EC2 environment 8060074: os::free() takes MemoryTrackingLevel but doesn't need it 8062943: REDO - Parallelize clearing the next mark bitmap 8064669: compiler/whitebox/AllocationCodeBlobTest.java crashes / asserts 8064694: Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 8064703: crash running specjvm98's javac following 8060252 8064953: Asserts.assert* should print values 8065218: Move CMS-specific fields from Space to CompactibleFreeListSpace 8065227: Report allocation context stats at end of cleanup 8065305: Make it possible to extend the G1CollectorPolicy 8065358: Refactor G1s usage of save_marks and reduce related races 8065579: WB method to start G1 concurrent mark cycle should be introduced 8065656: Use DWARF debug symbols for Solaris 8065749: [TESTBUG]: gc/arguments/TestG1HeapRegionSize.java fails at nightly 8065783: DCMD parser fails to recognize one character argument when it's positioned last 8065865: gc/TestSoftReferencesBehaviorOnOOME.java: Error. Can't find source file: TestSoftReference.java 8065915: Fix includes after 8058148: MaxNodeLimit and LiveNodeCountInliningCutoff 8065972: Remove support for ParNew+SerialOld and DefNew+CMS 8065992: Change CMSCollector::_young_gen to be a ParNewGeneration* 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration 8066045: opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1 8066133: Fix missing reivew changes for JDK-8065972 8066141: compiler/whitebox/GetNMethodTest.java: java.lang.RuntimeException: blob_type[MethodProfiled] for 2 level isn't MethodNonProfiled 8066199: C2 escape analysis prevents VM from exiting quickly 8066290: Port JDK-8066191 into hotspot 8066448: SmallCodeCacheStartup.java exits with exit code 1 8066662: Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration 8066713: ignore compiler/types/correctness -- Alejandro From tobias.hartmann at oracle.com Wed Dec 10 10:52:34 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 10 Dec 2014 11:52:34 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <548747D4.40805@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com> <, <, , <547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>, <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>, <54855234.3050400@oracle.com>, <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>, <54856A31.9020702@oracle.com>, <54857B2E.8020100@oracle.com>>>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> <5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com> <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com> <54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com> <548747D4.40805@oracle.com> Message-ID: <548825F2.4010900@oracle.com> Hi, I'm fine with postponing the renaming. I'll file a RFE for this after the change is in. Here are the new webrevs for moving only: Top level repo: http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ Hotspot repo: http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ If there are no objections I would like to push the change soon. Thanks, Tobias On 09.12.2014 20:04, Stefan S?rne wrote: > > Make sense. > > I am ok with delaying the name change. > There is a phase two with the bulk of the job to this anyway. > Dmitry, this is where we can have the repo discussion as well. > > I think there is an interesting part here anyway. > > Best regards, > Stefan > > Igor Ignatyev skrev 2014-12-09 19:19: >> Guys, >> >> changing Whitebox package name will cause failures in the tens tests which and >> aren't co-located w/ the product. >> right now, we have jigsaw m2 integrating into group repos, this also can lead >> to some failures. and I'd like not to have these failures mixed up. so I don't >> want to have whitebox renamed this and next week. >> however I do want to have whitebox available in jdk and hotspot repo this week. >> >> can we move whitebox to top repo now and do renaming later? >> >> On 12/09/2014 05:43 PM, Tobias Hartmann wrote: >>> Hi, >>> >>> I just noticed that if we want to access the Whitebox API in the top level >>> repository we also have to adapt the native lookup code in >>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name. >>> >>> I therefore suggest to move the Whitebox API completely and adapt all tests in >>> the hotspot repository. Here are the corresponding webrevs: >>> >>> Top level repo: >>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>> >>> Hotspot repo: >>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/ >>> >>> Tested on JPRT. >>> >>> Thanks, >>> Tobias >>> >>> On 09.12.2014 11:00, Staffan Larsen wrote: >>>> +1 >>>> >>>>> On 9 dec 2014, at 10:56, Stefan Sarne >>>> > wrote: >>>>> >>>>> >>>>> Hi, >>>>> >>>>> On 2014-12-09 10:51, Tobias Hartmann wrote: >>>>>> Hi, >>>>>> >>>>>> thanks for the feedback. >>>>>> >>>>>> On 08.12.2014 20:46, Staffan Larsen wrote: >>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com >>>>>>>> wrote: >>>>>>>> >>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com >>>>>>>> : >>>>>>>>> ... >>>>>>>>> >>>>>>>>> This would also be a good place to discuss the structure of the test >>>>>>>>> library. >>>>>>>> Yes. The various "testlibrary" directories in different repos are, at >>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant. >>>>>>>> >>>>>>>> For the present root-repo proposal: >>>>>>>> >>>>>>>> - Why is it named test/testlibrary rather than test/lib, which is >>>>>>>> what's used in the jdk repo? >>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-) >>>>>> Yes, do you prefer 'test/lib'? >>>>> >>>>> Now sounds like a good time to align. :) >>>>> We can update testlibrary in hotspot to the same as well I think (as a second >>>>> step). >>>>> Let's go with test/lib. >>>>> >>>>>> >>>>>>>> - Why does the white-box library get its own directory? Shouldn't >>>>>>>> all test-library classes have the same package root? >>>>>>> +1 >>>>>> I agree. I'll remove the whitebox directory. >>>>> >>>>> Sounds good, the same package root is better. >>>>> >>>>>> >>>>>>>> - The package name "sun.hotspot" is archaic. We should figure out a >>>>>>>> proper naming scheme for test-library packages, preferably starting >>>>>>>> with "jdk.?. >>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? >>>>>> Whatever you prefer. >>>>> >>>>> If we go with test/lib - I think jdk.testlib make sense. >>>>> >>>>> Thanks >>>>> Stefan >>>>> >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>>>>> ... >>>>>>>>> >>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to >>>>>>>>> break out the test folder to a separate repo if it starts growing. >>>>>>>>> But again, perhaps this is something we can wait for and handle in the >>>>>>>>> RFE. The test folder already exists in the top repo. >>>>>>>> The jdk/test/lib directory has been around for many years now and only >>>>>>>> contains 28 files. It seems unlikely that the root-repo equivalent will >>>>>>>> ever be much larger than that, so a separate repo would be overkill. >>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a >>>>>>> bit recently. I expect some growth to continue. Many of these overlap with >>>>>>> the files in the jdk directory, however. >>>>>>> >>>>>>> /Staffan >>>> >> > From staffan.larsen at oracle.com Wed Dec 10 10:54:45 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 10 Dec 2014 11:54:45 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <548825F2.4010900@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com> <, <, <, > <547E190F.1090407@oracle.com> <, > <54800E21.2050700@oracle.com> <, > <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <, > <54855234.3050400@oracle.com> <, > <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <, > <54856A31.9020702@oracle.com> <, > <54857B2E.8020100@oracle.com> <>>>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> <5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com> <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com> <54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com> <548747D4.40805@oracle.com> <548825F2.4010900@oracle.com> Message-ID: <5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com> I think we agreed to use jdk.test.lib as the package name (one dot more). /Staffan > On 10 dec 2014, at 11:52, Tobias Hartmann wrote: > > Hi, > > I'm fine with postponing the renaming. I'll file a RFE for this after the change > is in. Here are the new webrevs for moving only: > > Top level repo: > http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ > > Hotspot repo: > http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ > > If there are no objections I would like to push the change soon. > > Thanks, > Tobias > > On 09.12.2014 20:04, Stefan S?rne wrote: >> >> Make sense. >> >> I am ok with delaying the name change. >> There is a phase two with the bulk of the job to this anyway. >> Dmitry, this is where we can have the repo discussion as well. >> >> I think there is an interesting part here anyway. >> >> Best regards, >> Stefan >> >> Igor Ignatyev skrev 2014-12-09 19:19: >>> Guys, >>> >>> changing Whitebox package name will cause failures in the tens tests which and >>> aren't co-located w/ the product. >>> right now, we have jigsaw m2 integrating into group repos, this also can lead >>> to some failures. and I'd like not to have these failures mixed up. so I don't >>> want to have whitebox renamed this and next week. >>> however I do want to have whitebox available in jdk and hotspot repo this week. >>> >>> can we move whitebox to top repo now and do renaming later? >>> >>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> I just noticed that if we want to access the Whitebox API in the top level >>>> repository we also have to adapt the native lookup code in >>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name. >>>> >>>> I therefore suggest to move the Whitebox API completely and adapt all tests in >>>> the hotspot repository. Here are the corresponding webrevs: >>>> >>>> Top level repo: >>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>>> >>>> Hotspot repo: >>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/ >>>> >>>> Tested on JPRT. >>>> >>>> Thanks, >>>> Tobias >>>> >>>> On 09.12.2014 11:00, Staffan Larsen wrote: >>>>> +1 >>>>> >>>>>> On 9 dec 2014, at 10:56, Stefan Sarne >>>>> > wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote: >>>>>>> Hi, >>>>>>> >>>>>>> thanks for the feedback. >>>>>>> >>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote: >>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com >>>>>>>>> : >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> This would also be a good place to discuss the structure of the test >>>>>>>>>> library. >>>>>>>>> Yes. The various "testlibrary" directories in different repos are, at >>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant. >>>>>>>>> >>>>>>>>> For the present root-repo proposal: >>>>>>>>> >>>>>>>>> - Why is it named test/testlibrary rather than test/lib, which is >>>>>>>>> what's used in the jdk repo? >>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-) >>>>>>> Yes, do you prefer 'test/lib'? >>>>>> >>>>>> Now sounds like a good time to align. :) >>>>>> We can update testlibrary in hotspot to the same as well I think (as a second >>>>>> step). >>>>>> Let's go with test/lib. >>>>>> >>>>>>> >>>>>>>>> - Why does the white-box library get its own directory? Shouldn't >>>>>>>>> all test-library classes have the same package root? >>>>>>>> +1 >>>>>>> I agree. I'll remove the whitebox directory. >>>>>> >>>>>> Sounds good, the same package root is better. >>>>>> >>>>>>> >>>>>>>>> - The package name "sun.hotspot" is archaic. We should figure out a >>>>>>>>> proper naming scheme for test-library packages, preferably starting >>>>>>>>> with "jdk.?. >>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? >>>>>>> Whatever you prefer. >>>>>> >>>>>> If we go with test/lib - I think jdk.testlib make sense. >>>>>> >>>>>> Thanks >>>>>> Stefan >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to >>>>>>>>>> break out the test folder to a separate repo if it starts growing. >>>>>>>>>> But again, perhaps this is something we can wait for and handle in the >>>>>>>>>> RFE. The test folder already exists in the top repo. >>>>>>>>> The jdk/test/lib directory has been around for many years now and only >>>>>>>>> contains 28 files. It seems unlikely that the root-repo equivalent will >>>>>>>>> ever be much larger than that, so a separate repo would be overkill. >>>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a >>>>>>>> bit recently. I expect some growth to continue. Many of these overlap with >>>>>>>> the files in the jdk directory, however. >>>>>>>> >>>>>>>> /Staffan >>>>> >>> >> From tobias.hartmann at oracle.com Wed Dec 10 10:55:14 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 10 Dec 2014 11:55:14 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <548825F2.4010900@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com> <, <, , <547E190F.1090407@oracle.com>, <54800E21.2050700@oracle.com>, <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com>, <54855234.3050400@oracle.com>, <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com>, <54856A31.9020702@oracle.com>, <54857B2E.8020100@oracle.com>>>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> <5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com> <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com> <54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com> <548747D4.40805@oracle.com> <548825F2.4010900@oracle.com> Message-ID: <54882692.2000702@oracle.com> Sorry, I sent the wrong webrev link for the top level repository: http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/ Tobias On 10.12.2014 11:52, Tobias Hartmann wrote: > Hi, > > I'm fine with postponing the renaming. I'll file a RFE for this after the change > is in. Here are the new webrevs for moving only: > > Top level repo: > http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ > > Hotspot repo: > http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ > > If there are no objections I would like to push the change soon. > > Thanks, > Tobias > > On 09.12.2014 20:04, Stefan S?rne wrote: >> >> Make sense. >> >> I am ok with delaying the name change. >> There is a phase two with the bulk of the job to this anyway. >> Dmitry, this is where we can have the repo discussion as well. >> >> I think there is an interesting part here anyway. >> >> Best regards, >> Stefan >> >> Igor Ignatyev skrev 2014-12-09 19:19: >>> Guys, >>> >>> changing Whitebox package name will cause failures in the tens tests which and >>> aren't co-located w/ the product. >>> right now, we have jigsaw m2 integrating into group repos, this also can lead >>> to some failures. and I'd like not to have these failures mixed up. so I don't >>> want to have whitebox renamed this and next week. >>> however I do want to have whitebox available in jdk and hotspot repo this week. >>> >>> can we move whitebox to top repo now and do renaming later? >>> >>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> I just noticed that if we want to access the Whitebox API in the top level >>>> repository we also have to adapt the native lookup code in >>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name. >>>> >>>> I therefore suggest to move the Whitebox API completely and adapt all tests in >>>> the hotspot repository. Here are the corresponding webrevs: >>>> >>>> Top level repo: >>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>>> >>>> Hotspot repo: >>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/ >>>> >>>> Tested on JPRT. >>>> >>>> Thanks, >>>> Tobias >>>> >>>> On 09.12.2014 11:00, Staffan Larsen wrote: >>>>> +1 >>>>> >>>>>> On 9 dec 2014, at 10:56, Stefan Sarne >>>>> > wrote: >>>>>> >>>>>> >>>>>> Hi, >>>>>> >>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote: >>>>>>> Hi, >>>>>>> >>>>>>> thanks for the feedback. >>>>>>> >>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote: >>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com >>>>>>>>> : >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> This would also be a good place to discuss the structure of the test >>>>>>>>>> library. >>>>>>>>> Yes. The various "testlibrary" directories in different repos are, at >>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant. >>>>>>>>> >>>>>>>>> For the present root-repo proposal: >>>>>>>>> >>>>>>>>> - Why is it named test/testlibrary rather than test/lib, which is >>>>>>>>> what's used in the jdk repo? >>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-) >>>>>>> Yes, do you prefer 'test/lib'? >>>>>> >>>>>> Now sounds like a good time to align. :) >>>>>> We can update testlibrary in hotspot to the same as well I think (as a second >>>>>> step). >>>>>> Let's go with test/lib. >>>>>> >>>>>>> >>>>>>>>> - Why does the white-box library get its own directory? Shouldn't >>>>>>>>> all test-library classes have the same package root? >>>>>>>> +1 >>>>>>> I agree. I'll remove the whitebox directory. >>>>>> >>>>>> Sounds good, the same package root is better. >>>>>> >>>>>>> >>>>>>>>> - The package name "sun.hotspot" is archaic. We should figure out a >>>>>>>>> proper naming scheme for test-library packages, preferably starting >>>>>>>>> with "jdk.?. >>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? >>>>>>> Whatever you prefer. >>>>>> >>>>>> If we go with test/lib - I think jdk.testlib make sense. >>>>>> >>>>>> Thanks >>>>>> Stefan >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to >>>>>>>>>> break out the test folder to a separate repo if it starts growing. >>>>>>>>>> But again, perhaps this is something we can wait for and handle in the >>>>>>>>>> RFE. The test folder already exists in the top repo. >>>>>>>>> The jdk/test/lib directory has been around for many years now and only >>>>>>>>> contains 28 files. It seems unlikely that the root-repo equivalent will >>>>>>>>> ever be much larger than that, so a separate repo would be overkill. >>>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a >>>>>>>> bit recently. I expect some growth to continue. Many of these overlap with >>>>>>>> the files in the jdk directory, however. >>>>>>>> >>>>>>>> /Staffan >>>>> >>> >> From tobias.hartmann at oracle.com Wed Dec 10 10:56:56 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 10 Dec 2014 11:56:56 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com> <, <, <, > <547E190F.1090407@oracle.com> <, > <54800E21.2050700@oracle.com> <, > <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <, > <54855234.3050400@oracle.com> <, > <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <, > <54856A31.9020702@oracle.com> <, > <54857B2E.8020100@oracle.com> <>>>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> <5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com> <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com> <54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com> <548747D4.40805@oracle.com> <548825F2.4010900@oracle.com> <5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com> Message-ID: <548826F8.4040100@oracle.com> On 10.12.2014 11:54, Staffan Larsen wrote: > I think we agreed to use jdk.test.lib as the package name (one dot more). Yes, but as Igor suggested we postpone the renaming and first only move it. I've also sent the wrong link. This is the right one: http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/ Thanks, Tobias > > /Staffan > >> On 10 dec 2014, at 11:52, Tobias Hartmann wrote: >> >> Hi, >> >> I'm fine with postponing the renaming. I'll file a RFE for this after the change >> is in. Here are the new webrevs for moving only: >> >> Top level repo: >> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >> >> Hotspot repo: >> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ >> >> If there are no objections I would like to push the change soon. >> >> Thanks, >> Tobias >> >> On 09.12.2014 20:04, Stefan S?rne wrote: >>> >>> Make sense. >>> >>> I am ok with delaying the name change. >>> There is a phase two with the bulk of the job to this anyway. >>> Dmitry, this is where we can have the repo discussion as well. >>> >>> I think there is an interesting part here anyway. >>> >>> Best regards, >>> Stefan >>> >>> Igor Ignatyev skrev 2014-12-09 19:19: >>>> Guys, >>>> >>>> changing Whitebox package name will cause failures in the tens tests which and >>>> aren't co-located w/ the product. >>>> right now, we have jigsaw m2 integrating into group repos, this also can lead >>>> to some failures. and I'd like not to have these failures mixed up. so I don't >>>> want to have whitebox renamed this and next week. >>>> however I do want to have whitebox available in jdk and hotspot repo this week. >>>> >>>> can we move whitebox to top repo now and do renaming later? >>>> >>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote: >>>>> Hi, >>>>> >>>>> I just noticed that if we want to access the Whitebox API in the top level >>>>> repository we also have to adapt the native lookup code in >>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name. >>>>> >>>>> I therefore suggest to move the Whitebox API completely and adapt all tests in >>>>> the hotspot repository. Here are the corresponding webrevs: >>>>> >>>>> Top level repo: >>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>>>> >>>>> Hotspot repo: >>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/ >>>>> >>>>> Tested on JPRT. >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> On 09.12.2014 11:00, Staffan Larsen wrote: >>>>>> +1 >>>>>> >>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne >>>>>> > wrote: >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> thanks for the feedback. >>>>>>>> >>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote: >>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com >>>>>>>>>> : >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> This would also be a good place to discuss the structure of the test >>>>>>>>>>> library. >>>>>>>>>> Yes. The various "testlibrary" directories in different repos are, at >>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant. >>>>>>>>>> >>>>>>>>>> For the present root-repo proposal: >>>>>>>>>> >>>>>>>>>> - Why is it named test/testlibrary rather than test/lib, which is >>>>>>>>>> what's used in the jdk repo? >>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-) >>>>>>>> Yes, do you prefer 'test/lib'? >>>>>>> >>>>>>> Now sounds like a good time to align. :) >>>>>>> We can update testlibrary in hotspot to the same as well I think (as a second >>>>>>> step). >>>>>>> Let's go with test/lib. >>>>>>> >>>>>>>> >>>>>>>>>> - Why does the white-box library get its own directory? Shouldn't >>>>>>>>>> all test-library classes have the same package root? >>>>>>>>> +1 >>>>>>>> I agree. I'll remove the whitebox directory. >>>>>>> >>>>>>> Sounds good, the same package root is better. >>>>>>> >>>>>>>> >>>>>>>>>> - The package name "sun.hotspot" is archaic. We should figure out a >>>>>>>>>> proper naming scheme for test-library packages, preferably starting >>>>>>>>>> with "jdk.?. >>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? >>>>>>>> Whatever you prefer. >>>>>>> >>>>>>> If we go with test/lib - I think jdk.testlib make sense. >>>>>>> >>>>>>> Thanks >>>>>>> Stefan >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tobias >>>>>>>> >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to >>>>>>>>>>> break out the test folder to a separate repo if it starts growing. >>>>>>>>>>> But again, perhaps this is something we can wait for and handle in the >>>>>>>>>>> RFE. The test folder already exists in the top repo. >>>>>>>>>> The jdk/test/lib directory has been around for many years now and only >>>>>>>>>> contains 28 files. It seems unlikely that the root-repo equivalent will >>>>>>>>>> ever be much larger than that, so a separate repo would be overkill. >>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a >>>>>>>>> bit recently. I expect some growth to continue. Many of these overlap with >>>>>>>>> the files in the jdk directory, however. >>>>>>>>> >>>>>>>>> /Staffan >>>>>> >>>> >>> > From lana.steuck at oracle.com Wed Dec 10 20:19:20 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 10 Dec 2014 12:19:20 -0800 (PST) Subject: jdk9-b42: dev Message-ID: <201412102019.sBAKJK6D000392@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/f7c11da0b048 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/498d1d6c4219 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/23a3a063a906 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6b2314173433 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/301ddb4478fb http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/47b0d3fa4118 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/38cb4fbd47e3 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/078bb11af876 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8065998 client-libs Avoid use of _ as a one-character identifier JDK-8023723 client-libs Can not paste and copy the text from the text area into the editor JDK-8063102 client-libs Change open awt regression tests to avoid sun.awt.SunToolkit.realSync, part 1 JDK-8063106 client-libs Change open swing regression tests to avoid sun.awt.SunToolkit.realSync, part 1 JDK-8059739 client-libs Dragged and Dropped data is corrupted for two data types JDK-7169583 client-libs JInternalFrame title not antialiased in Nimbus LaF JDK-8004148 client-libs NPE in sun.awt.SunToolkit.getWindowDeactivationTime JDK-8052162 client-libs REGRESSION: sun/java2d/cmm/ColorConvertOp tests fail since 7u71 b01 JDK-7195187 client-libs [TEST_BUG] [macosx] javax/swing/SwingUtilities/7088744/bug7088744.java failed JDK-8062163 client-libs java/awt/geom/AffineTransform/TestInvertMethods.java test fails JDK-8064468 client-libs ownedWindowList access requires synchronization in Window.setAlwaysOnTop() method JDK-8058322 core-libs Zero name_index item of MethodParameters attribute cause MalformedParameterException. JDK-8065720 core-libs (ch) AbstractInterruptibleChannel.end sets interrupted to null JDK-8053963 core-libs (dc) Use DatagramChannel.receive() instead of read() in connect() JDK-8065070 core-libs (fmt) Avoid creating substrings when building FormatSpecifier JDK-8058887 core-libs (fmt) Improve java/util/Formatter test coverage of group separators and width JDK-8062955 core-libs (fs spec) Files.setLastModifiedTime should specify SecurityException more clearly JDK-8062949 core-libs (fs) Files.setLastModifiedTime(path, null) does not throw NPE JDK-8066196 core-libs (fs) Typo in Path::normalize, empty path only returned if path does not have a root component JDK-8064560 core-libs (tz) Support tzdata2014j JDK-6321472 core-libs Add CRC32C class, similar to java.util.zip.CRC32 JDK-8062556 core-libs Add jdk tests for JDK-8058322 and JDK-8058313 JDK-8065159 core-libs AttributedString has quadratic resize algorithm JDK-8066188 core-libs BaseRowSet returns the wrong default value for escape processing JDK-8062773 core-libs Clarifications for Class specification JDK-8063147 core-libs Class.getFields spec should state that fields are inherited from superinterfaces JDK-8063135 core-libs Enable full LF sharing by default JDK-8051778 core-libs Function.prototype.bind doesn't work on all callables JDK-8066222 core-libs Fuzzing bug: Assertion error in NativeArray.sort JDK-8066238 core-libs Fuzzing bug: AssertionError in ParserContext.pop JDK-8066232 core-libs Fuzzing bug: AssertionError when defining local variable in Block JDK-8066214 core-libs Fuzzing bug: Object.prototype.toLocaleString(0) JDK-8059880 core-libs Get rid of LambdaForm interpretation JDK-8060132 core-libs Handlers configured on abstract nodes in logging.properties are not always properly closed JDK-8065985 core-libs Inlining failure of Number.doubleValue() in JSType.toNumeric() causes 15% peak perf regresion on Box2D JDK-8066191 core-libs Introduce time limited test executor JDK-8057020 core-libs LambdaForm caches should support eviction JDK-8064846 core-libs Lazy-init thread safety problems in core reflection JDK-8058313 core-libs Mismatch of method descriptor and MethodParameters.parameters_count should cause MalformedParameterException JDK-8050983 core-libs Misplaced parentheses in sun.net.www.http.HttpClient break HTTP PUT streaming JDK-8066119 core-libs Missing resource type.error.not.an.arraybuffer JDK-8062638 core-libs Nashorn: RuntimeException when run command from js with -scripting on Cygwin JDK-8057691 core-libs Nashorn: let & const declarations are not shared between scripts JDK-8065769 core-libs OOM on Window/Solaris in test compile-octane-splitter.js JDK-8065372 core-libs Object.wait(ms, ns) timeout returns early JDK-8060068 core-libs Possible Deadlock scenario with DriverManager.loadInitialDrivers JDK-8066397 core-libs Remove network-related seed initialization code in ThreadLocal/SplittableRandom JDK-8066617 core-libs Suppress deprecation warnings in java.base module JDK-8066632 core-libs Suppress deprecation warnings in java.rmi module JDK-8056313 core-libs TEST_BUG: java/util/Timer/NameConstructors.java fails intermittently JDK-8035000 core-libs TEST_BUG: remove ActivationLibrary.DestroyThread and have callers call rmid.destroy() instead JDK-8049407 core-libs Test NASHORN-377.js fails on Solaris sparc JDK-8059677 core-libs Thread.getName() instantiates Strings JDK-8066261 core-libs Typo in isValid(int timeout) API in java.sql.Connection JDK-8066131 core-libs Update java/nio/charset/Charset/NIOCharsetAvailabilityTest.java to eliminate dependency on sun.misc.Launcher JDK-8060026 core-libs Update jdk/test/tools/launcher tests to eliminate dependency on sun.tools.jar.Main JDK-8062536 core-libs [TESTBUG] Conflicting GC combinations in jdk tests JDK-8039953 core-libs [TESTBUG] Timeout java/lang/invoke/MethodHandles/CatchExceptionTest.java JDK-8059070 core-libs [TESTBUG] java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed - timeout JDK-8065377 core-libs [TEST_BUG] test/closed/java/util/Calendar tests failures with 2014j tzdata JDK-8066130 core-libs com.sun.net.httpserver stop() throws NullPointerException if it is not started JDK-8065096 core-libs java.net.Authenticator.theAuthenticator should be properly synchronized JDK-8015692 core-libs java.net.BindException is thrown on Windows XP when HTTP server is started and stopped in the loop. JDK-8062194 core-libs java.util.jar.Attributes should use insertion-ordered iteration JDK-8064932 core-libs java/lang/ProcessBuilder/Basic.java: waitFor didn't take long enough JDK-8066146 core-libs jdk.nashorn.api.scripting package javadoc should be included in jdk docs JDK-8057980 core-libs let & const: remaining issues with lexical scoping JDK-8066683 core-libs nashorn test failures after modular image changes JDK-8065552 core-libs setAccessible(true) on fields of Class may throw a SecurityException JDK-8065072 core-libs sun/net/www/http/HttpClient/StreamingRetry.java failed intermittently JDK-8065222 core-libs sun/net/www/protocol/http/B6369510.java doesn't execute as expected JDK-8066696 core-libs test/script/nosecurity/JDK-8055034.js -Xbootclasspath option is wrong JDK-8064914 core-libs tzdb.dat compilation failure when using tzdata2014j JDK-8048050 core-svc Agent NullPointerException when rmi.port in use JDK-8061200 core-svc CMM: Commercial feature changes (docs) JDK-6988950 core-svc JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) JDK-6542634 core-svc TEST BUG: MISC_REGRESSION tests need to have minimum timeouts examined JDK-8065764 core-svc javax/management/monitor/CounterMonitorTest.java hangs JDK-8066588 core-svc javax/management/remote/mandatory/connection/RMIConnector_NPETest.java fails to compile JDK-8064288 core-svc sun.management.Flag should loadLibrary() JDK-8055851 deploy "Embedding JavaFX 2 in Swing" sample does not run with 8u25 JDK-8062295 deploy Background update doesn't work properly JDK-8062183 deploy Change the order of linux proxy detection JDK-8034952 deploy Extra warning in IE running applet with javascript writeln call JDK-8054034 deploy JCP Proxy configuration using script doesn't work since 8u25 b08 on Mac/Linux JDK-8049443 deploy Java process won't start and protection fault throws on WinXP JDK-8064737 deploy Javaws relaunch fails. JDK-8062392 deploy Jnlp fails to load with CouldNotLoadArgumentException JDK-8061349 deploy No crossdomain checking for connection to localhost from host with the same IP but another alias JDK-8051891 deploy SWT cannot load native look&feel JDK-8051358 deploy Step 6:There are java.io.FileNotFoundException and ava.lang.ClassNotFoundException thrown in java console after clicking "Continue" Button,and there is no security dialog with "Run" Button . JDK-8011182 deploy Unable to enable the last jre remaining on the system JDK-8039112 deploy Unexpected exception in accessibility class for all-perms vs sandbox javaws app testcase JDK-8062375 deploy Warning message doesn't contain additional info: "Launched from downloaded JNLP file" when launched from shortcut or cache viewer JDK-8054904 deploy Webstart cache path error for Java >= 7u65 JDK-8046482 deploy [Regression] SSLHandshake fail if there's a locally trusted cert whose common name is the same as the one from https server side. JDK-8055680 deploy [linux] LSP 1.1 ''force" rule causes UnsatisfiedLinkError when 2 JRE families are installed JDK-8049587 deploy [nightly] 7u71/8u25 Windows x64 - running any applet causes JRE relaunch JDK-8064772 deploy [test] Need to remove the AMC propeties from deploy.args file JDK-8059967 deploy [test] testIsExcluded fails JDK-8064442 deploy [test] update 2 cases in FXExpiredJREScenarios to add ESL instruction JDK-8064445 deploy [test] window number needs to be updated in focusScenarios/DocumentModalTest JDK-8023699 deploy adjust windows browser applet / webstart application java process integrity level JDK-8059969 deploy testParse_trivialInvalidArg - Expect to skip invalid arg JDK-8062774 deploy testTrustedArguments - jnlp.* properties should NOT cause mismatch (webstart mode) JDK-8064315 deploy use javaagent instead of accessibility to automate tests JDK-8060734 embedded compiler/intrinsics/sha/cli/TestUseSHA{,1,256,512}IntrinsicsOptionOnUnsupportedCPU.java tests failed on ARM platforms JDK-8055798 globalization Japanese translation for a warning from javac looks incorrect. JDK-8062307 hotspot 'Reference handler' thread triggers assert w/ TraceThreadEvents JDK-8064749 hotspot -XX:-UseCompilerSafepoints breaks safepoint rendezvous JDK-8064348 hotspot Add TraceEvent::is_enabled() for embedded/minimal builds JDK-8064779 hotspot Add additional comments for "8062370: Various minor code improvements" JDK-8061594 hotspot Add parameter to DestroyResourceContext for re-assign context JDK-8060592 hotspot AppCDS should be disabled if bootclasspath is modified by JVMTI JDK-8062836 hotspot BACKOUT - Parallelize clearing the next mark bitmap JDK-8061467 hotspot Bad page size passed to setup_large_pages() on Solaris JDK-8062950 hotspot Bug in locking code when UseOptoBiasInlining is disabled: assert(dmw->is_neutral()) failed: invariant JDK-8065618 hotspot C2 RA incorrectly removes kill projections JDK-8054478 hotspot C2: Incorrectly compiled char[] array access crashes JVM JDK-8043767 hotspot CMM Testing: 8u40 reaction on various memory pressure should be checked. JDK-8062601 hotspot CMM: CMM should require -XX:+UnlockCommercialFeatures JDK-8060467 hotspot CMS: small OldPLABSize and -XX:-ResizePLAB cause assert(ResizePLAB || n_blks == OldPLABSize) failed: Error JDK-8064375 hotspot Change certain errors to warnings in CDS output JDK-8062036 hotspot ConcurrentMarkThread::slt may be invoked before ConcurrentMarkThread::makeSurrogateLockerThread causing intermittent crashes JDK-8065150 hotspot Cooperative Memory Management (CMM) should not be available in a non-commercial build. JDK-8065339 hotspot Failed compilation does not always trigger a JFR event 'CompilerFailure' JDK-8064786 hotspot Fix debug build after 8062808: Turn on the -Wreturn-type warning JDK-8065361 hotspot Fixup headers and definitions for INCLUDE_TRACE JDK-8061449 hotspot G1: FreeRegionList_test() fails with G1 after the JDK-8058534 fix to HeapRegion::orig_end() JDK-8062957 hotspot Heap is not shrunk when deallocating under memory pressure JDK-8055271 hotspot Implement DumpJFR for Mac OS X JDK-8064473 hotspot Improved handling of age during object copy in G1 JDK-8065220 hotspot Include alternate sa.make file for MacOSX JDK-8061964 hotspot Insufficient compiler barriers for GCC in OrderAccess functions JDK-8059624 hotspot JEP-JDK-8043304: Test task: WhiteBox API for testing segmented codecache feature JDK-8059550 hotspot JEP-JDK-8043304: Test task: segment overflow w/ empty others JDK-8049714 hotspot JFR: -XX:StartFlightRecording doesn't accept empty argument JDK-8062011 hotspot JT_HS/compiler/7068051 uses jre/lib/javaws.jar JDK-8015272 hotspot Make @Contended within the same group to use the same oop map JDK-8058148 hotspot MaxNodeLimit and LiveNodeCountInliningCutoff should be increased JDK-8064911 hotspot Missing includes required for INCLUDE_TRACE JDK-8064581 hotspot Move INCLUDE_ALL_GCS include section to the end of the include list JDK-8064580 hotspot Move INCLUDE_CDS include section to the end of the include list JDK-8058255 hotspot Native jbyte Atomic::cmpxchg for supported x86 platforms JDK-8060449 hotspot Obsolete command line flags accept arbitrary appendix JDK-6351437 hotspot PIT : compiler/6329104/Test6329104.sh fails due to execution time variation JDK-8049341 hotspot Parallelize clearing the next mark bitmap JDK-8064471 hotspot Port 8013895: G1: G1SummarizeRSetStats output on Linux needs improvement to AIX JDK-8059770 hotspot Push JFR bootstrap state to Java instead of pulling from VM JDK-8061952 hotspot Quarantine closed/compiler/6457611/log.sh JDK-8058209 hotspot Race in G1 card scanning could allow scanning of memory covered by PLABs JDK-8061956 hotspot Remove hotspot/test/closed/serviceability/commercialfeatures tests from quarantine JDK-8061308 hotspot Remove iCMS JDK-8064702 hotspot Remove the CMS foreground collector JDK-8064865 hotspot Remove the debug funciontality RotateCMSCollectionTypes for CMS JDK-8062206 hotspot Remove unusable G1RSLogCheckCardTable command line argument JDK-8054491 hotspot Remove wrong assert and refactor code in G1CollectorPolicy::record_concurrent_mark_end JDK-8061234 hotspot ResourceContext.requestAccurateUpdate() is unreliable JDK-8060147 hotspot SIGSEGV in Metadata::mark_on_stack() while marking metadata in ciEnv JDK-8064701 hotspot Some CDS optimizations should be disabled if bootclasspath is modified by JVMTI JDK-8059661 hotspot Test SoftReference and OOM behavior JDK-8060721 hotspot Test runtime/SharedArchiveFile/LimitSharedSizes.java fails in jdk 9 fcs new platforms/compiler JDK-8064716 hotspot TestHumongousShrinkHeap.java can not be run with -XX:+ExplicitGCInvokesConcurrent JDK-8058958 hotspot TestInternedStrings.java fails with "The actual heap usage for context 2 : 792" JDK-8064695 hotspot Tests expect preload errors, but product gives preload warnings JDK-8064721 hotspot The card tables only ever need two covering regions JDK-8062808 hotspot Turn on the -Wreturn-type warning JDK-8064719 hotspot Unconfigured event settings in JFR are displayed with units JDK-8062382 hotspot Update JFR dynamic load jdk code from security assessment JDK-8064811 hotspot Use THREAD instead of CHECK_NULL in return statements JDK-8054008 hotspot Using -XX:-LazyBootClassLoader crashes with ACCESS_VIOLATION on Win 64bit JDK-8065346 hotspot WB_AddToBootstrapClassLoaderSearch calls JvmtiEnv::create_a_jvmti when not in _thread_in_vm state JDK-8059492 hotspot Wrong spelling in assert: "Not initialied properly?" JDK-8064815 hotspot Zero+PPC64: Stack overflow when running Maven JDK-8062247 hotspot [TESTBUG] Allow WhiteBox test to access JVM offsets JDK-8062537 hotspot [TESTBUG] Conflicting GC combinations in hotspot tests JDK-8056070 hotspot [TESTBUG] Improve gc/TestMemoryPressureReactionDecommit.java JDK-8056073 hotspot [TESTBUG] closed/compiler/jsr292/LongLambdaFormDynamicStackDepth.java fails with StackOverFlow JDK-8057664 hotspot [TESTBUG] closed/gc/TestMemoryPressureReactionDecommit.java fails with OOM on Linux 32 JDK-8056178 hotspot [TESTBUG] closed/runtime/AppCDS/ArchiveSize.java fails with java.lang.NumberFormatException: null JDK-8061431 hotspot [TESTBUG] closed/runtime/AppCDS/SharedArchiveConsistency.java fails on all platforms JDK-8064799 hotspot [TESTBUG] jtreg Serviceability tests to be run as part of JPRT submit job JDK-8063157 hotspot add targets for optimized builds JDK-8034005 hotspot cannot debug in synchronizer.o or objectMonitor.o on Solaris X86 debug/jvmg bits JDK-8062851 hotspot cleanup ObjectMonitor offset adjustments JDK-8061256 hotspot com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java timed out JDK-8062742 hotspot compiler/EliminateAutoBox/UnsignedLoads.java fails with client vm JDK-8062258 hotspot compiler/debug/TraceIterativeGVN.java segfaults in trace_PhaseIterGVN JDK-8064696 hotspot compiler/startup/SmallCodeCacheStartup.java doesn't check exit code JDK-8056071 hotspot compiler/whitebox/IsMethodCompilableTest.java fails with 'method() is not compilable after 3 iterations' JDK-8043243 hotspot convert SCAN_AND_FORWARD, SCAN_AND_ADJUST_POINTERS, SCAN_AND_COMPACT macros to methods JDK-8050079 hotspot crash while compiling java.lang.ref.Finalizer::runFinalizer JDK-8007993 hotspot hotspot.log w/ enabled LogCompilation can be an invalid XML JDK-8059732 hotspot improve hotspot_*test targets JDK-8064571 hotspot java/lang/instrument/IsModifiableClassAgent.java: assert(length > 0) failed: should only be called if table is present JDK-8062037 hotspot java/lang/instrument/RetransformBigClass.sh should be quarantined JDK-8057622 hotspot java/util/stream/test/org/openjdk/tests/java/util/stream/InfiniteStreamWithLimitOpTest: SEGV inside compiled code (sparc) JDK-8062854 hotspot move compiler jtreg test to corresponding subfolders and use those in TEST.groups JDK-8042235 hotspot redefining method used by multiple MethodHandles crashes VM JDK-8059131 hotspot sawindbg.dll is not compiled with /SAFESEH JDK-8062870 hotspot src/share/vm/services/mallocTracker.hpp:64 assert(_count > 0) failed: Negative counter JDK-8064802 hotspot very low performance of oracle.jrockit.jfr.parser.Parser JDK-8043491 hotspot warning LNK4197: export '... ...' specified multiple times; using first specification JDK-8033602 hotspot wrong stabs data in libjvm.debuginfo on JDK 8 - SPARC JDK-8065617 infrastructure 9-dev failed on Bundle_Source on 2014-11-21 JDK-8065183 infrastructure Add --with-copyright-year option to configure JDK-8062666 infrastructure Blacklist Cooperative Memory Management ("CMM") closed code JDK-8065368 infrastructure Configure --with-java-devtools should no longer set --with-freetype or --with-cups JDK-8065911 infrastructure Introduce EvalDebugWrapper for all Setup* macros JDK-8065215 infrastructure Print warning summary at end of configure JDK-8064497 infrastructure Remove nroff man pages from JDK / JRE binaries and repositories JDK-8065648 infrastructure Remove the flag -fsanitize=undefined for GCC 4.9 and later JDK-8058631 infrastructure Rename posix to unix in build system to match file name changes JDK-8065914 infrastructure Various improvements and cleanup of build system JDK-8065913 infrastructure Various improvements in SetupNativeCompilation JDK-8065412 infrastructure generated source to compile .properties file incorreectly includes the module name in the package name JDK-8062921 install Any windows greater than Window 8 is reported as win8 JDK-8064506 install JRT is crashing when checking list of removed/remaining JREs JDK-8044582 install Need to update the code for the new ping format JDK-8060057 install No checkbox "Enable JAB" after installation of public JRE 8 (only x86 JRE) JDK-8064591 install OEMUPDATE task expires Jan 01 2015 JDK-8062325 install Static 64-bit AU to NEXTVER crashes AU JDK-8062318 install Title text missing on the 'Install Complete' dialog when installing any new sponsor JDK-8059542 install java.exe and javaw.exe exist in System32 after specific chain of install/uninstall JDK-8063125 install log reports jucheck does not verify integrity of iftw-au JDK-8066500 other-libs CMM / ResMan JavaDoc: links to core SE APIs are broken JDK-8060004 other-libs Remove support for ContextRetainedThresholds JDK-8050916 security-libs Add 3 new GoDaddy root certificates JDK-8042480 security-libs CipherInputStream.close() throws AEADBadTagException in some cases JDK-8043200 security-libs Decrease the preference mode of RC4 in the enabled cipher suite list JDK-8046949 security-libs Generify the javax.xml.crypto API JDK-8048619 security-libs Implement tests for converting PKCS12 keystores JDK-8061253 security-libs Spec cleanup for some security-related classes JDK-8044440 security-libs [TEST] closed/java/security/Signature/Overflow.java fails due to Solaris PKCS11 bug JDK-8034031 security-libs [parfait] JNI exception pending in jdk/src/macosx/native/apple/security/KeystoreImpl.m JDK-8062747 tools Compiler error when anonymous class uses method with parametrized exception JDK-8065986 tools Compiler fails to NullPointerException when calling super with Object<>() JDK-7101822 tools Compiling depends on order of imports JDK-8032211 tools Don't issue deprecation warnings on import statements JDK-8063052 tools Inference chokes on wildcard derived from method reference JDK-8058112 tools Invalid BootstrapMethod for constructor/method reference JDK-8064803 tools Javac erroneously uses instantiated signatures when merging abstract most-specific methods JDK-8058445 tools Javac throws exception when displaying info JDK-8059921 tools Missing compile error in Java 8 mode for Interface.super.field access JDK-8065132 tools Parameter annotations not updated when synthetic parameters are prepended JDK-7196163 tools Project Coin: Allow final or effectively final variables to be used as resources in try-with-resources JDK-8065054 tools Some tests have junk before the legal header JDK-7177813 tools Static import to local nested class fails JDK-8062359 tools javac Attr crashes with NPE in TypeAnnotationsValidator visitNewClass JDK-8066731 tools javac does not work on exploded image JDK-6598104 tools javac should not warn about imports of deprecated classes JDK-8061876 tools replace java.io.File with java.nio.file.Path (again) JDK-8065748 xml Add a test to verify that non ascii characters in Encodings.properties do not cause issues JDK-8065138 xml Encodings.isRecognizedEnconding sometimes fails to recognize 'UTF8' JDK-8065870 xml Update JAX-WS RI integration to latest version (2.2.11-b141124.1933) JDK-8043084 xml XML JAXP unittest co-location From tobias.hartmann at oracle.com Thu Dec 11 08:22:18 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 11 Dec 2014 09:22:18 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <548826F8.4040100@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com> <, <, <, > <547E190F.1090407@oracle.com> <, > <54800E21.2050700@oracle.com> <, > <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <, > <54855234.3050400@oracle.com> <, > <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <, > <54856A31.9020702@oracle.com> <, > <54857B2E.8020100@oracle.com> <>>>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> <5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com> <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com> <54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com> <548747D4.40805@oracle.com> <548825F2.4010900@oracle.com> <5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com> <548826F8.4040100@oracle.com> Message-ID: <5489543A.7020300@oracle.com> Hi, are you fine with these changes? We will do the renaming with a separate change. http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/ http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ Thanks, Tobias On 10.12.2014 11:56, Tobias Hartmann wrote: > > On 10.12.2014 11:54, Staffan Larsen wrote: >> I think we agreed to use jdk.test.lib as the package name (one dot more). > > Yes, but as Igor suggested we postpone the renaming and first only move it. > > I've also sent the wrong link. This is the right one: > > http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/ > > Thanks, > Tobias > >> >> /Staffan >> >>> On 10 dec 2014, at 11:52, Tobias Hartmann wrote: >>> >>> Hi, >>> >>> I'm fine with postponing the renaming. I'll file a RFE for this after the change >>> is in. Here are the new webrevs for moving only: >>> >>> Top level repo: >>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>> >>> Hotspot repo: >>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ >>> >>> If there are no objections I would like to push the change soon. >>> >>> Thanks, >>> Tobias >>> >>> On 09.12.2014 20:04, Stefan S?rne wrote: >>>> >>>> Make sense. >>>> >>>> I am ok with delaying the name change. >>>> There is a phase two with the bulk of the job to this anyway. >>>> Dmitry, this is where we can have the repo discussion as well. >>>> >>>> I think there is an interesting part here anyway. >>>> >>>> Best regards, >>>> Stefan >>>> >>>> Igor Ignatyev skrev 2014-12-09 19:19: >>>>> Guys, >>>>> >>>>> changing Whitebox package name will cause failures in the tens tests which and >>>>> aren't co-located w/ the product. >>>>> right now, we have jigsaw m2 integrating into group repos, this also can lead >>>>> to some failures. and I'd like not to have these failures mixed up. so I don't >>>>> want to have whitebox renamed this and next week. >>>>> however I do want to have whitebox available in jdk and hotspot repo this week. >>>>> >>>>> can we move whitebox to top repo now and do renaming later? >>>>> >>>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote: >>>>>> Hi, >>>>>> >>>>>> I just noticed that if we want to access the Whitebox API in the top level >>>>>> repository we also have to adapt the native lookup code in >>>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name. >>>>>> >>>>>> I therefore suggest to move the Whitebox API completely and adapt all tests in >>>>>> the hotspot repository. Here are the corresponding webrevs: >>>>>> >>>>>> Top level repo: >>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>>>>> >>>>>> Hotspot repo: >>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/ >>>>>> >>>>>> Tested on JPRT. >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>> On 09.12.2014 11:00, Staffan Larsen wrote: >>>>>>> +1 >>>>>>> >>>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne >>>>>>> > wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> thanks for the feedback. >>>>>>>>> >>>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote: >>>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com >>>>>>>>>>> : >>>>>>>>>>>> ... >>>>>>>>>>>> >>>>>>>>>>>> This would also be a good place to discuss the structure of the test >>>>>>>>>>>> library. >>>>>>>>>>> Yes. The various "testlibrary" directories in different repos are, at >>>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant. >>>>>>>>>>> >>>>>>>>>>> For the present root-repo proposal: >>>>>>>>>>> >>>>>>>>>>> - Why is it named test/testlibrary rather than test/lib, which is >>>>>>>>>>> what's used in the jdk repo? >>>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-) >>>>>>>>> Yes, do you prefer 'test/lib'? >>>>>>>> >>>>>>>> Now sounds like a good time to align. :) >>>>>>>> We can update testlibrary in hotspot to the same as well I think (as a second >>>>>>>> step). >>>>>>>> Let's go with test/lib. >>>>>>>> >>>>>>>>> >>>>>>>>>>> - Why does the white-box library get its own directory? Shouldn't >>>>>>>>>>> all test-library classes have the same package root? >>>>>>>>>> +1 >>>>>>>>> I agree. I'll remove the whitebox directory. >>>>>>>> >>>>>>>> Sounds good, the same package root is better. >>>>>>>> >>>>>>>>> >>>>>>>>>>> - The package name "sun.hotspot" is archaic. We should figure out a >>>>>>>>>>> proper naming scheme for test-library packages, preferably starting >>>>>>>>>>> with "jdk.?. >>>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? >>>>>>>>> Whatever you prefer. >>>>>>>> >>>>>>>> If we go with test/lib - I think jdk.testlib make sense. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Stefan >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Tobias >>>>>>>>> >>>>>>>>>>>> ... >>>>>>>>>>>> >>>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to >>>>>>>>>>>> break out the test folder to a separate repo if it starts growing. >>>>>>>>>>>> But again, perhaps this is something we can wait for and handle in the >>>>>>>>>>>> RFE. The test folder already exists in the top repo. >>>>>>>>>>> The jdk/test/lib directory has been around for many years now and only >>>>>>>>>>> contains 28 files. It seems unlikely that the root-repo equivalent will >>>>>>>>>>> ever be much larger than that, so a separate repo would be overkill. >>>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a >>>>>>>>>> bit recently. I expect some growth to continue. Many of these overlap with >>>>>>>>>> the files in the jdk directory, however. >>>>>>>>>> >>>>>>>>>> /Staffan >>>>>>> >>>>> >>>> >> From stefan.sarne at oracle.com Thu Dec 11 08:33:42 2014 From: stefan.sarne at oracle.com (Stefan Sarne) Date: Thu, 11 Dec 2014 09:33:42 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <5489543A.7020300@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com> <, <, <, > <547E190F.1090407@oracle.com> <, > <54800E21.2050700@oracle.com> <, > <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <, > <54855234.3050400@oracle.com> <, > <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <, > <54856A31.9020702@oracle.com> <, > <54857B2E.8020100@oracle.com> <>>>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> <5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com> <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com> <54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com> <548747D4.40805@oracle.com> <548825F2.4010900@oracle.com> <5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com> <548826F8.4040100@oracle.com> <5489543A.7020300@oracle.com> Message-ID: <548956E6.4030001@oracle.com> Quick check - it looks as expected with the updated paths in tests - I am ok with this. But take it for what it is - I am not a reviewer. Thanks for your patience, while we figure out how we want to do this. Best regards, Stefan On 2014-12-11 09:22, Tobias Hartmann wrote: > Hi, > > are you fine with these changes? We will do the renaming with a separate change. > > http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/ > http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ > > Thanks, > Tobias > > On 10.12.2014 11:56, Tobias Hartmann wrote: >> On 10.12.2014 11:54, Staffan Larsen wrote: >>> I think we agreed to use jdk.test.lib as the package name (one dot more). >> Yes, but as Igor suggested we postpone the renaming and first only move it. >> >> I've also sent the wrong link. This is the right one: >> >> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/ >> >> Thanks, >> Tobias >> >>> /Staffan >>> >>>> On 10 dec 2014, at 11:52, Tobias Hartmann wrote: >>>> >>>> Hi, >>>> >>>> I'm fine with postponing the renaming. I'll file a RFE for this after the change >>>> is in. Here are the new webrevs for moving only: >>>> >>>> Top level repo: >>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>>> >>>> Hotspot repo: >>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ >>>> >>>> If there are no objections I would like to push the change soon. >>>> >>>> Thanks, >>>> Tobias >>>> >>>> On 09.12.2014 20:04, Stefan S?rne wrote: >>>>> Make sense. >>>>> >>>>> I am ok with delaying the name change. >>>>> There is a phase two with the bulk of the job to this anyway. >>>>> Dmitry, this is where we can have the repo discussion as well. >>>>> >>>>> I think there is an interesting part here anyway. >>>>> >>>>> Best regards, >>>>> Stefan >>>>> >>>>> Igor Ignatyev skrev 2014-12-09 19:19: >>>>>> Guys, >>>>>> >>>>>> changing Whitebox package name will cause failures in the tens tests which and >>>>>> aren't co-located w/ the product. >>>>>> right now, we have jigsaw m2 integrating into group repos, this also can lead >>>>>> to some failures. and I'd like not to have these failures mixed up. so I don't >>>>>> want to have whitebox renamed this and next week. >>>>>> however I do want to have whitebox available in jdk and hotspot repo this week. >>>>>> >>>>>> can we move whitebox to top repo now and do renaming later? >>>>>> >>>>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I just noticed that if we want to access the Whitebox API in the top level >>>>>>> repository we also have to adapt the native lookup code in >>>>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name. >>>>>>> >>>>>>> I therefore suggest to move the Whitebox API completely and adapt all tests in >>>>>>> the hotspot repository. Here are the corresponding webrevs: >>>>>>> >>>>>>> Top level repo: >>>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>>>>>> >>>>>>> Hotspot repo: >>>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/ >>>>>>> >>>>>>> Tested on JPRT. >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> >>>>>>> On 09.12.2014 11:00, Staffan Larsen wrote: >>>>>>>> +1 >>>>>>>> >>>>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> thanks for the feedback. >>>>>>>>>> >>>>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote: >>>>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com >>>>>>>>>>>> : >>>>>>>>>>>>> ... >>>>>>>>>>>>> >>>>>>>>>>>>> This would also be a good place to discuss the structure of the test >>>>>>>>>>>>> library. >>>>>>>>>>>> Yes. The various "testlibrary" directories in different repos are, at >>>>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant. >>>>>>>>>>>> >>>>>>>>>>>> For the present root-repo proposal: >>>>>>>>>>>> >>>>>>>>>>>> - Why is it named test/testlibrary rather than test/lib, which is >>>>>>>>>>>> what's used in the jdk repo? >>>>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-) >>>>>>>>>> Yes, do you prefer 'test/lib'? >>>>>>>>> Now sounds like a good time to align. :) >>>>>>>>> We can update testlibrary in hotspot to the same as well I think (as a second >>>>>>>>> step). >>>>>>>>> Let's go with test/lib. >>>>>>>>> >>>>>>>>>>>> - Why does the white-box library get its own directory? Shouldn't >>>>>>>>>>>> all test-library classes have the same package root? >>>>>>>>>>> +1 >>>>>>>>>> I agree. I'll remove the whitebox directory. >>>>>>>>> Sounds good, the same package root is better. >>>>>>>>> >>>>>>>>>>>> - The package name "sun.hotspot" is archaic. We should figure out a >>>>>>>>>>>> proper naming scheme for test-library packages, preferably starting >>>>>>>>>>>> with "jdk.?. >>>>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? >>>>>>>>>> Whatever you prefer. >>>>>>>>> If we go with test/lib - I think jdk.testlib make sense. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Stefan >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tobias >>>>>>>>>> >>>>>>>>>>>>> ... >>>>>>>>>>>>> >>>>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to >>>>>>>>>>>>> break out the test folder to a separate repo if it starts growing. >>>>>>>>>>>>> But again, perhaps this is something we can wait for and handle in the >>>>>>>>>>>>> RFE. The test folder already exists in the top repo. >>>>>>>>>>>> The jdk/test/lib directory has been around for many years now and only >>>>>>>>>>>> contains 28 files. It seems unlikely that the root-repo equivalent will >>>>>>>>>>>> ever be much larger than that, so a separate repo would be overkill. >>>>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a >>>>>>>>>>> bit recently. I expect some growth to continue. Many of these overlap with >>>>>>>>>>> the files in the jdk directory, however. >>>>>>>>>>> >>>>>>>>>>> /Staffan From igor.ignatyev at oracle.com Thu Dec 11 08:50:04 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 11 Dec 2014 11:50:04 +0300 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <5489543A.7020300@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com> <, <, <, > <547E190F.1090407@oracle.com> <, > <54800E21.2050700@oracle.com> <, > <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <, > <54855234.3050400@oracle.com> <, > <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <, > <54856A31.9020702@oracle.com> <, > <54857B2E.8020100@oracle.com> <>>>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> <5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com> <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com> <54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com> <548747D4.40805@oracle.com> <548825F2.4010900@oracle.com> <5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com> <548826F8.4040100@oracle.com> <5489543A.7020300@oracle.com> Message-ID: <54895ABC.70208@oracle.com> Tobias, /test/lib/Makefile years in copyright should be updated otherwise LGTM Thanks, Igor On 12/11/2014 11:22 AM, Tobias Hartmann wrote: > Hi, > > are you fine with these changes? We will do the renaming with a separate change. > > http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/ > http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ > > Thanks, > Tobias > > On 10.12.2014 11:56, Tobias Hartmann wrote: >> >> On 10.12.2014 11:54, Staffan Larsen wrote: >>> I think we agreed to use jdk.test.lib as the package name (one dot more). >> >> Yes, but as Igor suggested we postpone the renaming and first only move it. >> >> I've also sent the wrong link. This is the right one: >> >> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/ >> >> Thanks, >> Tobias >> >>> >>> /Staffan >>> >>>> On 10 dec 2014, at 11:52, Tobias Hartmann wrote: >>>> >>>> Hi, >>>> >>>> I'm fine with postponing the renaming. I'll file a RFE for this after the change >>>> is in. Here are the new webrevs for moving only: >>>> >>>> Top level repo: >>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>>> >>>> Hotspot repo: >>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ >>>> >>>> If there are no objections I would like to push the change soon. >>>> >>>> Thanks, >>>> Tobias >>>> >>>> On 09.12.2014 20:04, Stefan S?rne wrote: >>>>> >>>>> Make sense. >>>>> >>>>> I am ok with delaying the name change. >>>>> There is a phase two with the bulk of the job to this anyway. >>>>> Dmitry, this is where we can have the repo discussion as well. >>>>> >>>>> I think there is an interesting part here anyway. >>>>> >>>>> Best regards, >>>>> Stefan >>>>> >>>>> Igor Ignatyev skrev 2014-12-09 19:19: >>>>>> Guys, >>>>>> >>>>>> changing Whitebox package name will cause failures in the tens tests which and >>>>>> aren't co-located w/ the product. >>>>>> right now, we have jigsaw m2 integrating into group repos, this also can lead >>>>>> to some failures. and I'd like not to have these failures mixed up. so I don't >>>>>> want to have whitebox renamed this and next week. >>>>>> however I do want to have whitebox available in jdk and hotspot repo this week. >>>>>> >>>>>> can we move whitebox to top repo now and do renaming later? >>>>>> >>>>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I just noticed that if we want to access the Whitebox API in the top level >>>>>>> repository we also have to adapt the native lookup code in >>>>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name. >>>>>>> >>>>>>> I therefore suggest to move the Whitebox API completely and adapt all tests in >>>>>>> the hotspot repository. Here are the corresponding webrevs: >>>>>>> >>>>>>> Top level repo: >>>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>>>>>> >>>>>>> Hotspot repo: >>>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/ >>>>>>> >>>>>>> Tested on JPRT. >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> >>>>>>> On 09.12.2014 11:00, Staffan Larsen wrote: >>>>>>>> +1 >>>>>>>> >>>>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> thanks for the feedback. >>>>>>>>>> >>>>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote: >>>>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com >>>>>>>>>>>> : >>>>>>>>>>>>> ... >>>>>>>>>>>>> >>>>>>>>>>>>> This would also be a good place to discuss the structure of the test >>>>>>>>>>>>> library. >>>>>>>>>>>> Yes. The various "testlibrary" directories in different repos are, at >>>>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant. >>>>>>>>>>>> >>>>>>>>>>>> For the present root-repo proposal: >>>>>>>>>>>> >>>>>>>>>>>> - Why is it named test/testlibrary rather than test/lib, which is >>>>>>>>>>>> what's used in the jdk repo? >>>>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-) >>>>>>>>>> Yes, do you prefer 'test/lib'? >>>>>>>>> >>>>>>>>> Now sounds like a good time to align. :) >>>>>>>>> We can update testlibrary in hotspot to the same as well I think (as a second >>>>>>>>> step). >>>>>>>>> Let's go with test/lib. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> - Why does the white-box library get its own directory? Shouldn't >>>>>>>>>>>> all test-library classes have the same package root? >>>>>>>>>>> +1 >>>>>>>>>> I agree. I'll remove the whitebox directory. >>>>>>>>> >>>>>>>>> Sounds good, the same package root is better. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> - The package name "sun.hotspot" is archaic. We should figure out a >>>>>>>>>>>> proper naming scheme for test-library packages, preferably starting >>>>>>>>>>>> with "jdk.?. >>>>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? >>>>>>>>>> Whatever you prefer. >>>>>>>>> >>>>>>>>> If we go with test/lib - I think jdk.testlib make sense. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Stefan >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tobias >>>>>>>>>> >>>>>>>>>>>>> ... >>>>>>>>>>>>> >>>>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to >>>>>>>>>>>>> break out the test folder to a separate repo if it starts growing. >>>>>>>>>>>>> But again, perhaps this is something we can wait for and handle in the >>>>>>>>>>>>> RFE. The test folder already exists in the top repo. >>>>>>>>>>>> The jdk/test/lib directory has been around for many years now and only >>>>>>>>>>>> contains 28 files. It seems unlikely that the root-repo equivalent will >>>>>>>>>>>> ever be much larger than that, so a separate repo would be overkill. >>>>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a >>>>>>>>>>> bit recently. I expect some growth to continue. Many of these overlap with >>>>>>>>>>> the files in the jdk directory, however. >>>>>>>>>>> >>>>>>>>>>> /Staffan >>>>>>>> >>>>>> >>>>> >>> -- Igor From staffan.larsen at oracle.com Thu Dec 11 09:02:32 2014 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 11 Dec 2014 10:02:32 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <5489543A.7020300@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com> <, <, <, > <547E190F.1090407@oracle.com> <, > <54800E21.2050700@oracle.com> <, > <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <, > <54855234.3050400@oracle.com> <, > <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <, > <54856A31.9020702@oracle.com> <, > <54857B2E.8020100@oracle.com> <>>>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> <5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com> <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com> <54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com> <548747D4.40805@oracle.com> <548825F2.4010900@oracle.com> <5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com> <548826F8.4040100@oracle.com> <5489543A.7020300@oracle.com> Message-ID: <891F1C17-337D-4E33-9BD0-9CB246C1A203@oracle.com> Looks good! Have we filed a bug for the rename? I assume you have run the changed tests and verified that they do not fail? Thanks, /Staffan > On 11 dec 2014, at 09:22, Tobias Hartmann wrote: > > Hi, > > are you fine with these changes? We will do the renaming with a separate change. > > http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/ > http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ > > Thanks, > Tobias > > On 10.12.2014 11:56, Tobias Hartmann wrote: >> >> On 10.12.2014 11:54, Staffan Larsen wrote: >>> I think we agreed to use jdk.test.lib as the package name (one dot more). >> >> Yes, but as Igor suggested we postpone the renaming and first only move it. >> >> I've also sent the wrong link. This is the right one: >> >> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/ >> >> Thanks, >> Tobias >> >>> >>> /Staffan >>> >>>> On 10 dec 2014, at 11:52, Tobias Hartmann wrote: >>>> >>>> Hi, >>>> >>>> I'm fine with postponing the renaming. I'll file a RFE for this after the change >>>> is in. Here are the new webrevs for moving only: >>>> >>>> Top level repo: >>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>>> >>>> Hotspot repo: >>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ >>>> >>>> If there are no objections I would like to push the change soon. >>>> >>>> Thanks, >>>> Tobias >>>> >>>> On 09.12.2014 20:04, Stefan S?rne wrote: >>>>> >>>>> Make sense. >>>>> >>>>> I am ok with delaying the name change. >>>>> There is a phase two with the bulk of the job to this anyway. >>>>> Dmitry, this is where we can have the repo discussion as well. >>>>> >>>>> I think there is an interesting part here anyway. >>>>> >>>>> Best regards, >>>>> Stefan >>>>> >>>>> Igor Ignatyev skrev 2014-12-09 19:19: >>>>>> Guys, >>>>>> >>>>>> changing Whitebox package name will cause failures in the tens tests which and >>>>>> aren't co-located w/ the product. >>>>>> right now, we have jigsaw m2 integrating into group repos, this also can lead >>>>>> to some failures. and I'd like not to have these failures mixed up. so I don't >>>>>> want to have whitebox renamed this and next week. >>>>>> however I do want to have whitebox available in jdk and hotspot repo this week. >>>>>> >>>>>> can we move whitebox to top repo now and do renaming later? >>>>>> >>>>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I just noticed that if we want to access the Whitebox API in the top level >>>>>>> repository we also have to adapt the native lookup code in >>>>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name. >>>>>>> >>>>>>> I therefore suggest to move the Whitebox API completely and adapt all tests in >>>>>>> the hotspot repository. Here are the corresponding webrevs: >>>>>>> >>>>>>> Top level repo: >>>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>>>>>> >>>>>>> Hotspot repo: >>>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/ >>>>>>> >>>>>>> Tested on JPRT. >>>>>>> >>>>>>> Thanks, >>>>>>> Tobias >>>>>>> >>>>>>> On 09.12.2014 11:00, Staffan Larsen wrote: >>>>>>>> +1 >>>>>>>> >>>>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> thanks for the feedback. >>>>>>>>>> >>>>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote: >>>>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com >>>>>>>>>>>> : >>>>>>>>>>>>> ... >>>>>>>>>>>>> >>>>>>>>>>>>> This would also be a good place to discuss the structure of the test >>>>>>>>>>>>> library. >>>>>>>>>>>> Yes. The various "testlibrary" directories in different repos are, at >>>>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant. >>>>>>>>>>>> >>>>>>>>>>>> For the present root-repo proposal: >>>>>>>>>>>> >>>>>>>>>>>> - Why is it named test/testlibrary rather than test/lib, which is >>>>>>>>>>>> what's used in the jdk repo? >>>>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-) >>>>>>>>>> Yes, do you prefer 'test/lib'? >>>>>>>>> >>>>>>>>> Now sounds like a good time to align. :) >>>>>>>>> We can update testlibrary in hotspot to the same as well I think (as a second >>>>>>>>> step). >>>>>>>>> Let's go with test/lib. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> - Why does the white-box library get its own directory? Shouldn't >>>>>>>>>>>> all test-library classes have the same package root? >>>>>>>>>>> +1 >>>>>>>>>> I agree. I'll remove the whitebox directory. >>>>>>>>> >>>>>>>>> Sounds good, the same package root is better. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>>> - The package name "sun.hotspot" is archaic. We should figure out a >>>>>>>>>>>> proper naming scheme for test-library packages, preferably starting >>>>>>>>>>>> with "jdk.?. >>>>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? >>>>>>>>>> Whatever you prefer. >>>>>>>>> >>>>>>>>> If we go with test/lib - I think jdk.testlib make sense. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Stefan >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Tobias >>>>>>>>>> >>>>>>>>>>>>> ... >>>>>>>>>>>>> >>>>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to >>>>>>>>>>>>> break out the test folder to a separate repo if it starts growing. >>>>>>>>>>>>> But again, perhaps this is something we can wait for and handle in the >>>>>>>>>>>>> RFE. The test folder already exists in the top repo. >>>>>>>>>>>> The jdk/test/lib directory has been around for many years now and only >>>>>>>>>>>> contains 28 files. It seems unlikely that the root-repo equivalent will >>>>>>>>>>>> ever be much larger than that, so a separate repo would be overkill. >>>>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a >>>>>>>>>>> bit recently. I expect some growth to continue. Many of these overlap with >>>>>>>>>>> the files in the jdk directory, however. >>>>>>>>>>> >>>>>>>>>>> /Staffan >>>>>>>> >>>>>> >>>>> >>> From tobias.hartmann at oracle.com Thu Dec 11 11:54:17 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 11 Dec 2014 12:54:17 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <54895ABC.70208@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com> <, <, <, > <547E190F.1090407@oracle.com> <, > <54800E21.2050700@oracle.com> <, > <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <, > <54855234.3050400@oracle.com> <, > <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <, > <54856A31.9020702@oracle.com> <, > <54857B2E.8020100@oracle.com> <>>>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> <5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com> <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com> <54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com> <548747D4.40805@oracle.com> <548825F2.4010900@oracle.com> <5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com> <548826F8.4040100@oracle.com> <5489543A.7020300@oracle.com> <54895ABC.70208@oracle.com> Message-ID: <548985E9.5020303@oracle.com> Thanks, Igor. I updated the copyrights. http://cr.openjdk.java.net/~thartmann/8066433/webrev.04/ http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ Best, Tobias On 11.12.2014 09:50, Igor Ignatyev wrote: > Tobias, > > /test/lib/Makefile > years in copyright should be updated > > otherwise LGTM > > Thanks, > Igor > > On 12/11/2014 11:22 AM, Tobias Hartmann wrote: >> Hi, >> >> are you fine with these changes? We will do the renaming with a separate change. >> >> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/ >> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ >> >> Thanks, >> Tobias >> >> On 10.12.2014 11:56, Tobias Hartmann wrote: >>> >>> On 10.12.2014 11:54, Staffan Larsen wrote: >>>> I think we agreed to use jdk.test.lib as the package name (one dot more). >>> >>> Yes, but as Igor suggested we postpone the renaming and first only move it. >>> >>> I've also sent the wrong link. This is the right one: >>> >>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/ >>> >>> Thanks, >>> Tobias >>> >>>> >>>> /Staffan >>>> >>>>> On 10 dec 2014, at 11:52, Tobias Hartmann wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm fine with postponing the renaming. I'll file a RFE for this after the >>>>> change >>>>> is in. Here are the new webrevs for moving only: >>>>> >>>>> Top level repo: >>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>>>> >>>>> Hotspot repo: >>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ >>>>> >>>>> If there are no objections I would like to push the change soon. >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> On 09.12.2014 20:04, Stefan S?rne wrote: >>>>>> >>>>>> Make sense. >>>>>> >>>>>> I am ok with delaying the name change. >>>>>> There is a phase two with the bulk of the job to this anyway. >>>>>> Dmitry, this is where we can have the repo discussion as well. >>>>>> >>>>>> I think there is an interesting part here anyway. >>>>>> >>>>>> Best regards, >>>>>> Stefan >>>>>> >>>>>> Igor Ignatyev skrev 2014-12-09 19:19: >>>>>>> Guys, >>>>>>> >>>>>>> changing Whitebox package name will cause failures in the tens tests >>>>>>> which and >>>>>>> aren't co-located w/ the product. >>>>>>> right now, we have jigsaw m2 integrating into group repos, this also can >>>>>>> lead >>>>>>> to some failures. and I'd like not to have these failures mixed up. so I >>>>>>> don't >>>>>>> want to have whitebox renamed this and next week. >>>>>>> however I do want to have whitebox available in jdk and hotspot repo this >>>>>>> week. >>>>>>> >>>>>>> can we move whitebox to top repo now and do renaming later? >>>>>>> >>>>>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I just noticed that if we want to access the Whitebox API in the top level >>>>>>>> repository we also have to adapt the native lookup code in >>>>>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name. >>>>>>>> >>>>>>>> I therefore suggest to move the Whitebox API completely and adapt all >>>>>>>> tests in >>>>>>>> the hotspot repository. Here are the corresponding webrevs: >>>>>>>> >>>>>>>> Top level repo: >>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>>>>>>> >>>>>>>> Hotspot repo: >>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/ >>>>>>>> >>>>>>>> Tested on JPRT. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tobias >>>>>>>> >>>>>>>> On 09.12.2014 11:00, Staffan Larsen wrote: >>>>>>>>> +1 >>>>>>>>> >>>>>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> thanks for the feedback. >>>>>>>>>>> >>>>>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote: >>>>>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com >>>>>>>>>>>>> : >>>>>>>>>>>>>> ... >>>>>>>>>>>>>> >>>>>>>>>>>>>> This would also be a good place to discuss the structure of the test >>>>>>>>>>>>>> library. >>>>>>>>>>>>> Yes. The various "testlibrary" directories in different repos are, at >>>>>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant. >>>>>>>>>>>>> >>>>>>>>>>>>> For the present root-repo proposal: >>>>>>>>>>>>> >>>>>>>>>>>>> - Why is it named test/testlibrary rather than test/lib, which is >>>>>>>>>>>>> what's used in the jdk repo? >>>>>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-) >>>>>>>>>>> Yes, do you prefer 'test/lib'? >>>>>>>>>> >>>>>>>>>> Now sounds like a good time to align. :) >>>>>>>>>> We can update testlibrary in hotspot to the same as well I think (as a >>>>>>>>>> second >>>>>>>>>> step). >>>>>>>>>> Let's go with test/lib. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> - Why does the white-box library get its own directory? Shouldn't >>>>>>>>>>>>> all test-library classes have the same package root? >>>>>>>>>>>> +1 >>>>>>>>>>> I agree. I'll remove the whitebox directory. >>>>>>>>>> >>>>>>>>>> Sounds good, the same package root is better. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> - The package name "sun.hotspot" is archaic. We should figure out a >>>>>>>>>>>>> proper naming scheme for test-library packages, preferably >>>>>>>>>>>>> starting >>>>>>>>>>>>> with "jdk.?. >>>>>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? >>>>>>>>>>> Whatever you prefer. >>>>>>>>>> >>>>>>>>>> If we go with test/lib - I think jdk.testlib make sense. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Stefan >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Tobias >>>>>>>>>>> >>>>>>>>>>>>>> ... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to >>>>>>>>>>>>>> break out the test folder to a separate repo if it starts growing. >>>>>>>>>>>>>> But again, perhaps this is something we can wait for and handle in >>>>>>>>>>>>>> the >>>>>>>>>>>>>> RFE. The test folder already exists in the top repo. >>>>>>>>>>>>> The jdk/test/lib directory has been around for many years now and only >>>>>>>>>>>>> contains 28 files. It seems unlikely that the root-repo equivalent >>>>>>>>>>>>> will >>>>>>>>>>>>> ever be much larger than that, so a separate repo would be overkill. >>>>>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded >>>>>>>>>>>> quite a >>>>>>>>>>>> bit recently. I expect some growth to continue. Many of these >>>>>>>>>>>> overlap with >>>>>>>>>>>> the files in the jdk directory, however. >>>>>>>>>>>> >>>>>>>>>>>> /Staffan >>>>>>>>> >>>>>>> >>>>>> >>>> > From igor.ignatyev at oracle.com Thu Dec 11 11:58:05 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 11 Dec 2014 14:58:05 +0300 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <548985E9.5020303@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com> <, <, <, > <547E190F.1090407@oracle.com> <, > <54800E21.2050700@oracle.com> <, > <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <, > <54855234.3050400@oracle.com> <, > <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <, > <54856A31.9020702@oracle.com> <, > <54857B2E.8020100@oracle.com> <>>>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> <5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com> <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com> <54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com> <548747D4.40805@oracle.com> <548825F2.4010900@oracle.com> <5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com> <548826F8.4040100@oracle.com> <5489543A.7020300@oracle.com> <54895ABC.70208@oracle.com> <548985E9.5020303@orac! le.com> Message-ID: <548986CD.7040700@oracle.com> Tobias, thanks, push it. -- Igor On 12/11/2014 02:54 PM, Tobias Hartmann wrote: > Thanks, Igor. > > I updated the copyrights. > > http://cr.openjdk.java.net/~thartmann/8066433/webrev.04/ > http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ > > Best, > Tobias > > On 11.12.2014 09:50, Igor Ignatyev wrote: >> Tobias, >> >> /test/lib/Makefile >> years in copyright should be updated >> >> otherwise LGTM >> >> Thanks, >> Igor >> >> On 12/11/2014 11:22 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> are you fine with these changes? We will do the renaming with a separate change. >>> >>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/ >>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ >>> >>> Thanks, >>> Tobias >>> >>> On 10.12.2014 11:56, Tobias Hartmann wrote: >>>> >>>> On 10.12.2014 11:54, Staffan Larsen wrote: >>>>> I think we agreed to use jdk.test.lib as the package name (one dot more). >>>> >>>> Yes, but as Igor suggested we postpone the renaming and first only move it. >>>> >>>> I've also sent the wrong link. This is the right one: >>>> >>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/ >>>> >>>> Thanks, >>>> Tobias >>>> >>>>> >>>>> /Staffan >>>>> >>>>>> On 10 dec 2014, at 11:52, Tobias Hartmann wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I'm fine with postponing the renaming. I'll file a RFE for this after the >>>>>> change >>>>>> is in. Here are the new webrevs for moving only: >>>>>> >>>>>> Top level repo: >>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>>>>> >>>>>> Hotspot repo: >>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ >>>>>> >>>>>> If there are no objections I would like to push the change soon. >>>>>> >>>>>> Thanks, >>>>>> Tobias >>>>>> >>>>>> On 09.12.2014 20:04, Stefan S?rne wrote: >>>>>>> >>>>>>> Make sense. >>>>>>> >>>>>>> I am ok with delaying the name change. >>>>>>> There is a phase two with the bulk of the job to this anyway. >>>>>>> Dmitry, this is where we can have the repo discussion as well. >>>>>>> >>>>>>> I think there is an interesting part here anyway. >>>>>>> >>>>>>> Best regards, >>>>>>> Stefan >>>>>>> >>>>>>> Igor Ignatyev skrev 2014-12-09 19:19: >>>>>>>> Guys, >>>>>>>> >>>>>>>> changing Whitebox package name will cause failures in the tens tests >>>>>>>> which and >>>>>>>> aren't co-located w/ the product. >>>>>>>> right now, we have jigsaw m2 integrating into group repos, this also can >>>>>>>> lead >>>>>>>> to some failures. and I'd like not to have these failures mixed up. so I >>>>>>>> don't >>>>>>>> want to have whitebox renamed this and next week. >>>>>>>> however I do want to have whitebox available in jdk and hotspot repo this >>>>>>>> week. >>>>>>>> >>>>>>>> can we move whitebox to top repo now and do renaming later? >>>>>>>> >>>>>>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I just noticed that if we want to access the Whitebox API in the top level >>>>>>>>> repository we also have to adapt the native lookup code in >>>>>>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name. >>>>>>>>> >>>>>>>>> I therefore suggest to move the Whitebox API completely and adapt all >>>>>>>>> tests in >>>>>>>>> the hotspot repository. Here are the corresponding webrevs: >>>>>>>>> >>>>>>>>> Top level repo: >>>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>>>>>>>> >>>>>>>>> Hotspot repo: >>>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/ >>>>>>>>> >>>>>>>>> Tested on JPRT. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Tobias >>>>>>>>> >>>>>>>>> On 09.12.2014 11:00, Staffan Larsen wrote: >>>>>>>>>> +1 >>>>>>>>>> >>>>>>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> thanks for the feedback. >>>>>>>>>>>> >>>>>>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote: >>>>>>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com >>>>>>>>>>>>>> : >>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This would also be a good place to discuss the structure of the test >>>>>>>>>>>>>>> library. >>>>>>>>>>>>>> Yes. The various "testlibrary" directories in different repos are, at >>>>>>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For the present root-repo proposal: >>>>>>>>>>>>>> >>>>>>>>>>>>>> - Why is it named test/testlibrary rather than test/lib, which is >>>>>>>>>>>>>> what's used in the jdk repo? >>>>>>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-) >>>>>>>>>>>> Yes, do you prefer 'test/lib'? >>>>>>>>>>> >>>>>>>>>>> Now sounds like a good time to align. :) >>>>>>>>>>> We can update testlibrary in hotspot to the same as well I think (as a >>>>>>>>>>> second >>>>>>>>>>> step). >>>>>>>>>>> Let's go with test/lib. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> - Why does the white-box library get its own directory? Shouldn't >>>>>>>>>>>>>> all test-library classes have the same package root? >>>>>>>>>>>>> +1 >>>>>>>>>>>> I agree. I'll remove the whitebox directory. >>>>>>>>>>> >>>>>>>>>>> Sounds good, the same package root is better. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>> - The package name "sun.hotspot" is archaic. We should figure out a >>>>>>>>>>>>>> proper naming scheme for test-library packages, preferably >>>>>>>>>>>>>> starting >>>>>>>>>>>>>> with "jdk.?. >>>>>>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? >>>>>>>>>>>> Whatever you prefer. >>>>>>>>>>> >>>>>>>>>>> If we go with test/lib - I think jdk.testlib make sense. >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Stefan >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Tobias >>>>>>>>>>>> >>>>>>>>>>>>>>> ... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to >>>>>>>>>>>>>>> break out the test folder to a separate repo if it starts growing. >>>>>>>>>>>>>>> But again, perhaps this is something we can wait for and handle in >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> RFE. The test folder already exists in the top repo. >>>>>>>>>>>>>> The jdk/test/lib directory has been around for many years now and only >>>>>>>>>>>>>> contains 28 files. It seems unlikely that the root-repo equivalent >>>>>>>>>>>>>> will >>>>>>>>>>>>>> ever be much larger than that, so a separate repo would be overkill. >>>>>>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded >>>>>>>>>>>>> quite a >>>>>>>>>>>>> bit recently. I expect some growth to continue. Many of these >>>>>>>>>>>>> overlap with >>>>>>>>>>>>> the files in the jdk directory, however. >>>>>>>>>>>>> >>>>>>>>>>>>> /Staffan >>>>>>>>>> >>>>>>>> >>>>>>> >>>>> >> From tobias.hartmann at oracle.com Thu Dec 11 12:38:48 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 11 Dec 2014 13:38:48 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <891F1C17-337D-4E33-9BD0-9CB246C1A203@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF563.8080509@oracle.com> <, <547DF8D8.8080601@oracle.com> <, <, <, > <547E190F.1090407@oracle.com> <, > <54800E21.2050700@oracle.com> <, > <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <, > <54855234.3050400@oracle.com> <, > <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <, > <54856A31.9020702@oracle.com> <, > <54857B2E.8020100@oracle.com> <>>>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> <5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com> <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com> <54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com> <548747D4.40805@oracle.com> <548825F2.4010900@oracle.com> <5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com> <548826F8.4040100@oracle.com> <5489543A.7020300@oracle.com> <891F1C17-337D-4E33-9BD0-9CB246C1A203@oracle.com> Message-ID: <54899058.2020909@oracle.com> Hi Staffan, On 11.12.2014 10:02, Staffan Larsen wrote: > Looks good! > > Have we filed a bug for the rename? Thanks. I filed JDK-8067223. > I assume you have run the changed tests and verified that they do not fail? Yes, I did. Thanks, Tobias > > Thanks, > /Staffan > > >> On 11 dec 2014, at 09:22, Tobias Hartmann wrote: >> >> Hi, >> >> are you fine with these changes? We will do the renaming with a separate change. >> >> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/ >> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ >> >> Thanks, >> Tobias >> >> On 10.12.2014 11:56, Tobias Hartmann wrote: >>> >>> On 10.12.2014 11:54, Staffan Larsen wrote: >>>> I think we agreed to use jdk.test.lib as the package name (one dot more). >>> >>> Yes, but as Igor suggested we postpone the renaming and first only move it. >>> >>> I've also sent the wrong link. This is the right one: >>> >>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.03/ >>> >>> Thanks, >>> Tobias >>> >>>> >>>> /Staffan >>>> >>>>> On 10 dec 2014, at 11:52, Tobias Hartmann wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm fine with postponing the renaming. I'll file a RFE for this after the change >>>>> is in. Here are the new webrevs for moving only: >>>>> >>>>> Top level repo: >>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>>>> >>>>> Hotspot repo: >>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.01/ >>>>> >>>>> If there are no objections I would like to push the change soon. >>>>> >>>>> Thanks, >>>>> Tobias >>>>> >>>>> On 09.12.2014 20:04, Stefan S?rne wrote: >>>>>> >>>>>> Make sense. >>>>>> >>>>>> I am ok with delaying the name change. >>>>>> There is a phase two with the bulk of the job to this anyway. >>>>>> Dmitry, this is where we can have the repo discussion as well. >>>>>> >>>>>> I think there is an interesting part here anyway. >>>>>> >>>>>> Best regards, >>>>>> Stefan >>>>>> >>>>>> Igor Ignatyev skrev 2014-12-09 19:19: >>>>>>> Guys, >>>>>>> >>>>>>> changing Whitebox package name will cause failures in the tens tests which and >>>>>>> aren't co-located w/ the product. >>>>>>> right now, we have jigsaw m2 integrating into group repos, this also can lead >>>>>>> to some failures. and I'd like not to have these failures mixed up. so I don't >>>>>>> want to have whitebox renamed this and next week. >>>>>>> however I do want to have whitebox available in jdk and hotspot repo this week. >>>>>>> >>>>>>> can we move whitebox to top repo now and do renaming later? >>>>>>> >>>>>>> On 12/09/2014 05:43 PM, Tobias Hartmann wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I just noticed that if we want to access the Whitebox API in the top level >>>>>>>> repository we also have to adapt the native lookup code in >>>>>>>> src/share/vm/prims/nativeLookup.cpp because it depends on the package name. >>>>>>>> >>>>>>>> I therefore suggest to move the Whitebox API completely and adapt all tests in >>>>>>>> the hotspot repository. Here are the corresponding webrevs: >>>>>>>> >>>>>>>> Top level repo: >>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433/webrev.02/ >>>>>>>> >>>>>>>> Hotspot repo: >>>>>>>> http://cr.openjdk.java.net/~thartmann/8066433_hotspot/webrev.00/ >>>>>>>> >>>>>>>> Tested on JPRT. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tobias >>>>>>>> >>>>>>>> On 09.12.2014 11:00, Staffan Larsen wrote: >>>>>>>>> +1 >>>>>>>>> >>>>>>>>>> On 9 dec 2014, at 10:56, Stefan Sarne >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 2014-12-09 10:51, Tobias Hartmann wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> thanks for the feedback. >>>>>>>>>>> >>>>>>>>>>> On 08.12.2014 20:46, Staffan Larsen wrote: >>>>>>>>>>>>> On 8 dec 2014, at 20:18, mark.reinhold at oracle.com >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> 2014/12/8 2:19 -0800, stefan.sarne at oracle.com >>>>>>>>>>>>> : >>>>>>>>>>>>>> ... >>>>>>>>>>>>>> >>>>>>>>>>>>>> This would also be a good place to discuss the structure of the test >>>>>>>>>>>>>> library. >>>>>>>>>>>>> Yes. The various "testlibrary" directories in different repos are, at >>>>>>>>>>>>> the moment, a bit of a mess and in some cases appear to be redundant. >>>>>>>>>>>>> >>>>>>>>>>>>> For the present root-repo proposal: >>>>>>>>>>>>> >>>>>>>>>>>>> - Why is it named test/testlibrary rather than test/lib, which is >>>>>>>>>>>>> what's used in the jdk repo? >>>>>>>>>>>> Probably because it?s called test/testlibrary in the hotspot repo :-) >>>>>>>>>>> Yes, do you prefer 'test/lib'? >>>>>>>>>> >>>>>>>>>> Now sounds like a good time to align. :) >>>>>>>>>> We can update testlibrary in hotspot to the same as well I think (as a second >>>>>>>>>> step). >>>>>>>>>> Let's go with test/lib. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> - Why does the white-box library get its own directory? Shouldn't >>>>>>>>>>>>> all test-library classes have the same package root? >>>>>>>>>>>> +1 >>>>>>>>>>> I agree. I'll remove the whitebox directory. >>>>>>>>>> >>>>>>>>>> Sounds good, the same package root is better. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>> - The package name "sun.hotspot" is archaic. We should figure out a >>>>>>>>>>>>> proper naming scheme for test-library packages, preferably starting >>>>>>>>>>>>> with "jdk.?. >>>>>>>>>>>> So jdk.testlibrary.whitebox.* for these? Or jdk.testlib.whitebox? >>>>>>>>>>> Whatever you prefer. >>>>>>>>>> >>>>>>>>>> If we go with test/lib - I think jdk.testlib make sense. >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Stefan >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Tobias >>>>>>>>>>> >>>>>>>>>>>>>> ... >>>>>>>>>>>>>> >>>>>>>>>>>>>> Based on the discussion around microbenchmarks, it may make sense to >>>>>>>>>>>>>> break out the test folder to a separate repo if it starts growing. >>>>>>>>>>>>>> But again, perhaps this is something we can wait for and handle in the >>>>>>>>>>>>>> RFE. The test folder already exists in the top repo. >>>>>>>>>>>>> The jdk/test/lib directory has been around for many years now and only >>>>>>>>>>>>> contains 28 files. It seems unlikely that the root-repo equivalent will >>>>>>>>>>>>> ever be much larger than that, so a separate repo would be overkill. >>>>>>>>>>>> The corresponding directory in hotspot has 56 files and has expanded quite a >>>>>>>>>>>> bit recently. I expect some growth to continue. Many of these overlap with >>>>>>>>>>>> the files in the jdk directory, however. >>>>>>>>>>>> >>>>>>>>>>>> /Staffan >>>>>>>>> >>>>>>> >>>>>> >>>> > From tobias.hartmann at oracle.com Thu Dec 11 12:39:46 2014 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 11 Dec 2014 13:39:46 +0100 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <548986CD.7040700@oracle.com> References: <547DCF47.9000608@oracle.com> <, <547DF8D8.8080601@oracle.com> <, <, <, > <547E190F.1090407@oracle.com> <, > <54800E21.2050700@oracle.com> <, > <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <, > <54855234.3050400@oracle.com> <, > <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <, > <54856A31.9020702@oracle.com> <, > <54857B2E.8020100@oracle.com> <>>>>> <20141208111859.936395@eggemoggin.niobe.net> <24F35775-6B79-4F74-AD97-37F5E5F1815A@oracle.com> <5486C62C.2040906@oracle.com> <5486C73B.5080206@oracle.com> <2B38452A-20B2-4954-B7A8-11B794357907@oracle.com> <54870A75.2000008@oracle.com> <54873D3D.2030704@oracle.com> <548747D4.40805@oracle.com> <548825F2.4010900@oracle.com> <5E715A8D-4A24-48B3-93AF-478FD3D1B5BE@oracle.com> <548826F8.4040100@oracle.com> <5489543A.7020300@oracle.com> <54895ABC.70208@oracle.com> <548985E9.5020303@oracle.com> <548986CD.7040700@oracle.! com> Message-ID: <54899092.9020108@oracle.com> Thanks, Igor. Best, Tobias On 11.12.2014 12:58, Igor Ignatyev wrote: > Tobias, > > thanks, push it. > From jonathan.gibbons at oracle.com Fri Dec 12 02:16:36 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 11 Dec 2014 18:16:36 -0800 Subject: [9] RFR(S): 8066433: Copy Whitebox testlibrary to top level repository In-Reply-To: <43F17AFB-5E36-41BF-BB29-429ECEF9D977@oracle.com> References: <547DCF47.9000608@oracle.com> <547DF563.8080509@oracle.com> <547DF8D8.8080601@oracle.com> <547E190F.1090407@oracle.com> <54800E21.2050700@oracle.com> <66C91A07-D38F-46AC-8130-9E11C9C8B47E@oracle.com> <54855234.3050400@oracle.com> <260A31D3-5B70-4530-AAFF-91C2D059337F@oracle.com> <54856A31.9020702@oracle.com> <5486CA0B.4010501@oracle.com> <43F17AFB-5E36-41BF-BB29-429ECEF9D977@oracle.com> Message-ID: <548A5004.2030101@oracle.com> On 12/09/2014 02:15 AM, Staffan Larsen wrote: > The suggestion is to use "@library /../../test/lib?. Using an initial slash means that the path is relative to TEST.ROOT, not to the test itself. I?m not sure if this was intended in jtreg or if it just happens to work. I?m sure we can think of cleaner approach in the future. > > /Staffan This is remarkably ugly, and I'm sorry that it even works. I welcome suggestions for a better way of expressing this, although I have a horrible feeling the ../.. sequence is going to have to show up somewhere, although it would be better if it was not in every test that uses the library. -- Jon From mark.reinhold at oracle.com Fri Dec 12 17:11:00 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Fri, 12 Dec 2014 09:11:00 -0800 Subject: JEPs proposed to target, or drop from, JDK 9 (2014/12/4) In-Reply-To: <20141204135654.798484@eggemoggin.niobe.net> References: <20141204135654.798484@eggemoggin.niobe.net> Message-ID: <20141212091100.887766@eggemoggin.niobe.net> 2014/12/4 1:56 -0800, mark.reinhold at oracle.com: > The following JEPs have been placed into the "Proposed to Target" state > by their respective owners after discussion and review: > > 228: Add More Diagnostic Commands http://openjdk.java.net/jeps/228 > 229: Create PKCS12 Keystores by Default http://openjdk.java.net/jeps/229 > > The following JEP has been placed in the "Proposed to Drop" state: > > 198: Light-Weight JSON API http://openjdk.java.net/jeps/198 > > Feedback on these proposals is more than welcome, as are reasoned > objections. If no such objections are raised by 22:00 UTC next > Thursday, 11 December, or if they're raised and then satisfactorily > answered, then per the JEP 2.0 process proposal [1] I'll make these > proposed changes. Hearing no objections, I've targeted JEPs 228 and 229 to JDK 9, and dropped JEP 198. - Mark From rich.midwinter at gmail.com Sun Dec 14 19:01:55 2014 From: rich.midwinter at gmail.com (Rich Midwinter) Date: Sun, 14 Dec 2014 19:01:55 +0000 Subject: New switch for jdk keytool command Message-ID: Hi I'd like to see a new switch added to keytool to initialise an empty keystore, for which I've attached a first shot at a patch. Could someone point me in the right direction to see if this can be included (on the assumption this email alone isn't sufficient). Thanks Rich -------------- next part -------------- diff --git a/src/java.base/share/classes/sun/security/tools/keytool/Main.java b/src/java.base/share/classes/sun/security/tools/keytool/Main.java --- a/src/java.base/share/classes/sun/security/tools/keytool/Main.java +++ b/src/java.base/share/classes/sun/security/tools/keytool/Main.java @@ -204,6 +204,7 @@ SRCALIAS, DESTALIAS, SRCKEYPASS, DESTKEYPASS, NOPROMPT, PROVIDERCLASS, PROVIDERARG, PROVIDERPATH, V), + INIT("Creates.an.initial.empty.keystore", KEYSTORE, STOREPASS), KEYPASSWD("Changes.the.key.password.of.an.entry", ALIAS, KEYPASS, NEW, KEYSTORE, STOREPASS, STORETYPE, PROVIDERNAME, PROVIDERCLASS, PROVIDERARG, @@ -784,6 +785,7 @@ command != IMPORTCERT && command != IMPORTPASS && command != IMPORTKEYSTORE && + command != INIT && command != PRINTCRL) { throw new Exception(rb.getString ("Keystore.file.does.not.exist.") + ksfname); @@ -1067,6 +1069,8 @@ } else if (command == IMPORTKEYSTORE) { doImportKeyStore(); kssave = true; + } else if (command == INIT) { + kssave = true; } else if (command == KEYCLONE) { keyPassNew = newPass; diff --git a/src/java.base/share/classes/sun/security/tools/keytool/Resources.java b/src/java.base/share/classes/sun/security/tools/keytool/Resources.java --- a/src/java.base/share/classes/sun/security/tools/keytool/Resources.java +++ b/src/java.base/share/classes/sun/security/tools/keytool/Resources.java @@ -78,6 +78,8 @@ "Imports a password"}, //-importpass {"Imports.one.or.all.entries.from.another.keystore", "Imports one or all entries from another keystore"}, //-importkeystore + {"Creates.an.initial.empty.keystore", + "Creates an initial empty keystore"}, //-init {"Clones.a.key.entry", "Clones a key entry"}, //-keyclone {"Changes.the.key.password.of.an.entry", From Alan.Bateman at oracle.com Sun Dec 14 20:05:20 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 14 Dec 2014 20:05:20 +0000 Subject: New switch for jdk keytool command In-Reply-To: References: Message-ID: <548DED80.4090509@oracle.com> On 14/12/2014 19:01, Rich Midwinter wrote: > Hi > > I'd like to see a new switch added to keytool to initialise an empty > keystore, for which I've attached a first shot at a patch. > > Could someone point me in the right direction to see if this can be > included (on the assumption this email alone isn't sufficient). > > Thanks > Rich The security-dev list is the place to bring up this proposal and get agreement that it's an option that make sense. If there is agreement you'll need to develop some tests as part of the patch and then seek a sponsor. -Alan From vincent.x.ryan at oracle.com Mon Dec 15 10:56:51 2014 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 15 Dec 2014 10:56:51 +0000 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <475F5926-A06A-446B-B4A4-EDD1E582906B@oracle.com> Vote: yes On 5 Dec 2014, at 18:35, Se?n Coffey wrote: > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. > > Ivan is a member of the Java SE Sustaining team and works mainly on issues connected to the JDK core libraries. Over the past year, he's demonstrated a strong understanding of how the core libraries code works and has contributed significant bug fixes and enhancements in JDK 9 [3]. > > Votes are due by 19:00 GMT December 19th 2014. > > Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Sean. > > [1] : http://openjdk.java.net/census#jdk9 > [2] : http://openjdk.java.net/projects/#reviewer-vote > > [3] > $hg log -M -u igerasim -R jdk --template "{desc}\n" | grep "^[0-9]\{7,7\}: " > 8023173: FileDescriptor should respect append flag > 8059840: (bb) Typo in javadoc for ByteBuffer.wrap() > 8059450: Not quite correct code sample in javadoc > 8058099: (fc) Cleanup in FileChannel/FileDispatcher native implementation [win] > 8054029: (fc) FileChannel.size() returns 0 for block devices on Linux > 7010989: Duplicate closure of file descriptors leads to unexpected and incorrect closure of sockets > 8056310: Cleanup in WinNTFileSystem_md.c > 8054714: Use StringJoiner where it makes the code cleaner > 8055421: (fs) bad error handling in java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > 8055731: sun/security/smartcardio/TestDirect.java throws java.lang.IndexOutOfBoundsException > 8054841: (process) ProcessBuilder leaks native memory > 8046343: (smartcardio) CardTerminal.connect('direct') does not work on MacOSX > 8054221: StringJoiner imlementation optimization > 8051382: Optimize java.lang.reflect.Modifier.toString() > 8050893: (smartcardio) Invert reset argument in tests in sun/security/smartcardio > 8035975: Pattern.compile(String, int) fails to throw IllegalArgumentException > 6904367: (coll) IdentityHashMap is resized before exceeding the expected maximum size > 8048080: (smartcardio) javax.smartcardio.Card.openLogicalChannel() dosn't work on MacOSX > 8037866: Replace the Fun class in tests with lambdas > 8044342: build failure on Windows noticed with recent smartcardio fix > 8043720: (smartcardio) Native memory should be handled more accurately > 7047033: (smartcardio) Card.disconnect(boolean reset) does not reset when reset is true > 8039319: (smartcardio) Card.transmitControlCommand() does not work on Mac OS X > 8043476: java/util/BitSet/BSMethods.java failed with: java.lang.OutOfMemoryError: Java heap space > 8043507: javax.smartcardio.CardTerminals.list() fails on MacOSX > 8043772: Typos in Double/Int/LongSummaryStatistics.java > 7195480: javax.smartcardio does not detect cards on Mac OS X > 8042470: (fs) Path.register doesn't throw IllegalArgumentException if multiple OVERFLOW events are specified > 8011537: (fs) Path.register(..) clears interrupt status of thread with no InterruptedException > 8040806: BitSet.toString() can throw IndexOutOfBoundsException > 8038982: java/lang/ref/EarlyTimeout.java failed again > 8039396: NPE when writing a class descriptor object to a custom ObjectOutputStream > 8009637: Some error messages are missing a space > 8038333: TEST_BUG: java/lang/ref/EarlyTimeout.java fails with a non-adequate message > 8014066: Remove redundant restriction from ArrayList#removeRange() spec > 6943190: TEST_BUG: some tests in java/lang/Runtime/exec have hard-coded path to shell commands > 7011804: SequenceInputStream with lots of empty substreams can cause StackOverflowError > 8036088: Replace strtok() with its safe equivalent strtok_s() in DefaultProxySelector.c > 8034262: Test java/lang/ProcessBuilder/CloseRace.java fails > 6853696: (ref) ReferenceQueue.remove(timeout) may return null even if timeout has not expired > 8023022: Some more typos in javadoc > 4682009: Typo in javadocs in javax/naming > 8033943: Typo in the documentation for the class Arrays > 8027348: (process) Enhancement of handling async close of ProcessInputStream > 8025886: replace [[ and == bash extensions in regtest > 8030698: Several GUI labels in jconsole need correction > 8024521: (process) Async close issues with Process InputStream > 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the latest jdk8 build > 8026756: Test java/util/zip/GZIP/GZIPInZip.java failed > 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed > 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions > 7129312: BufferedInputStream calculates negative array size with large streams and mark > 8022584: Memory leak in some NetworkInterface methods > 8020669: (fs) Files.readAllBytes() does not read any data when Files.size() is 0 > 7192942: (coll) Inefficient calculation of power of two in HashMap > 8016838: improvement of RedefineBigClass and RetransformBigClass tests > 7181748: java/lang/ThreadGroup/Suspend.java test fails intermittently > > > $hg log -M -u igerasim -R hotspot --template "{desc}\n" | grep "^[0-9]\{7,7\}: " > 8059533: (process) Make exiting process wait for exiting threads [win] > 8057744: (process) Synchronize exiting of threads and process [win] > 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java fails with openjdk build > 8055338: (process) Add instrumentation to help diagnose JDK-6573254 > 8035893: JVM_GetVersionInfo fails to zero structure > > > > > From ron.durbin at oracle.com Mon Dec 15 15:17:45 2014 From: ron.durbin at oracle.com (Ron Durbin) Date: Mon, 15 Dec 2014 07:17:45 -0800 (PST) Subject: New switch for jdk keytool command In-Reply-To: References: Message-ID: Rich -Djavax.net.ssl.trustStorePassword -Djavax.net.ssl.keyStorePassword Are you referring to the options above? Or something new and additional. Ron Durbin -----Original Message----- From: Rich Midwinter [mailto:rich.midwinter at gmail.com] Sent: Sunday, December 14, 2014 12:02 PM To: jdk9-dev at openjdk.java.net Subject: New switch for jdk keytool command Hi I'd like to see a new switch added to keytool to initialise an empty keystore, for which I've attached a first shot at a patch. Could someone point me in the right direction to see if this can be included (on the assumption this email alone isn't sufficient). Thanks Rich From erik.helin at oracle.com Mon Dec 15 15:20:47 2014 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 15 Dec 2014 16:20:47 +0100 Subject: 8067442: Tests using -Xshare:dump does not work with 'make test' Message-ID: <20141215152047.GC24542@ehelin.jrpg.bea.com> Hi all, this patch changes the dependency for the target `test` in make/Main.gmk from exploded-image to jimages. This is needed because PRODUCT_HOME in `make test` needs to be set to a full JDK image directory, because there are tests in hotspot/test that uses -Xshare:dump and -Xshare:dump does not work with an exploded jdk image. There are currently 9 tests that are failing due to this when running: $ make test TEST=hotspot_runtime Webrev: http://cr.openjdk.java.net/~ehelin/8067442/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8067442 Testing: - Run `make test TEST=hotspot_runtime` on Linux x86-64 and verified that all tests now passes. Thanks, Erik From erik.joelsson at oracle.com Mon Dec 15 15:35:11 2014 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 15 Dec 2014 16:35:11 +0100 Subject: 8067442: Tests using -Xshare:dump does not work with 'make test' In-Reply-To: <20141215152047.GC24542@ehelin.jrpg.bea.com> References: <20141215152047.GC24542@ehelin.jrpg.bea.com> Message-ID: <548EFFAF.5010209@oracle.com> Hello, Change looks good to me. Note that the dependencies used to be on images, but I recently changed this to the exploded images thinking that it would be more convenient and that most tests would work anyway (or at least those that people wanted to run). Since that is not the case, I support changing it back. /Erik On 2014-12-15 16:20, Erik Helin wrote: > Hi all, > > this patch changes the dependency for the target `test` in make/Main.gmk > from exploded-image to jimages. This is needed because PRODUCT_HOME in > `make test` needs to be set to a full JDK image directory, because there > are tests in hotspot/test that uses -Xshare:dump and -Xshare:dump does > not work with an exploded jdk image. > > There are currently 9 tests that are failing due to this when running: > $ make test TEST=hotspot_runtime > > Webrev: > http://cr.openjdk.java.net/~ehelin/8067442/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8067442 > > Testing: > - Run `make test TEST=hotspot_runtime` on Linux x86-64 and verified > that all tests now passes. > > Thanks, > Erik From mandy.chung at oracle.com Mon Dec 15 15:39:00 2014 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 15 Dec 2014 07:39:00 -0800 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: <548F0094.5080707@oracle.com> Vote: yes From chris.hegarty at oracle.com Mon Dec 15 19:38:32 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 15 Dec 2014 19:38:32 +0000 Subject: JDK 9 Sandbox Development Forest Message-ID: <7E1D9AA4-1EAD-4401-A52D-BF297C4C6AB3@oracle.com> Hi, Announcing the JDK 9 Sandbox Development Forest, as proposed by Mike Duigou [1]. The primary purpose of the JDK 9 Sandbox Development Forest is to facilitate OpenJDK developers that are working on non-trivial changes, possibly JEP-scale effort, whose scope and duration make it necessary to collaborate with others in an open shared version control system, rather than just using privately shared patches. Working in the sandbox can facilitate rapid iterative development, as there is no requirement for changes to be reviewed or accompanied by bug numbers, i.e. jcheck is not enabled. Just create a new branch and start working. When the changes are ready for integration into the main-line, then they will need to follow the appropriate forest integration rules. Any committer to the JDK 9 project can push changes to the sandbox. Questions or issues relating to it should be directed to the maintainer, Chris Hegarty. It is strongly recommended that you subscribed to the changes mailing list if you are actively developing changes in the sandbox. ? Forest location: http://hg.openjdk.java.net/jdk9/sandbox ? Changeset notifications: jdk9-sandbox-changes at openjdk dot java dot net Please read the following common questions and guidance before using the sandbox. http://cr.openjdk.java.net/~chegar/docs/sandbox.html The most important rule to keep in mind when using the sandbox is; You should never push changes to the default branch. All active development should happen in branches ( other than the default ), leaving the default branch ?clean?, so it can easily be updated with changes from the upstream main-line forest. Individual branch owners can, at their discretion, sync up their branch with the main-line changes in the default branch. -Chris. [1] http://mail.openjdk.java.net/pipermail/discuss/2014-September/003552.html From stuart.marks at oracle.com Tue Dec 16 02:23:35 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 15 Dec 2014 18:23:35 -0800 Subject: JDK 9 Sandbox Development Forest In-Reply-To: <7E1D9AA4-1EAD-4401-A52D-BF297C4C6AB3@oracle.com> References: <7E1D9AA4-1EAD-4401-A52D-BF297C4C6AB3@oracle.com> Message-ID: <548F97A7.2030100@oracle.com> Yay sandbox! Thanks for following through with this, Chris. Just to try things out, I've created my own test branch "smarks-test0". And I've already run into a bug in hgforest.sh. :-) The problem is that following the instructions in the sandbox guidance: http://cr.openjdk.java.net/~chegar/docs/sandbox.html The example line to commit an initial changeset to the branch: sh common/bin/hgforest.sh commit -m "Initial changes for JDK-8000000" doesn't work. The problem is that hgforest.sh breaks the quoted string into separate arguments, which the commit command doesn't like. I've filed https://bugs.openjdk.java.net/browse/JDK-8067631 on this. The workaround is to put the commit comment into a file and do something like sh common/bin/hgforest.sh commit -l /absolute/path/to/comment.txt Meanwhile, I've done a bit of hacking on the hgforest.sh script, and I've posted a webrev--, er, no, I've pushed a changeset (!) here: http://hg.openjdk.java.net/jdk9/sandbox/rev/886037762070 It's on my own branch, of course. If people could try this out, I'll transplant it back to jdk9-dev at some point. All hail the new era of the JDK Sandbox! s'marks On 12/15/14 11:38 AM, Chris Hegarty wrote: > Hi, > > Announcing the JDK 9 Sandbox Development Forest, as proposed by Mike Duigou [1]. > > The primary purpose of the JDK 9 Sandbox Development Forest is to facilitate OpenJDK developers that are working on non-trivial changes, possibly JEP-scale effort, whose scope and duration make it necessary to collaborate with others in an open shared version control system, rather than just using privately shared patches. > > Working in the sandbox can facilitate rapid iterative development, as there is no requirement for changes to be reviewed or accompanied by bug numbers, i.e. jcheck is not enabled. Just create a new branch and start working. When the changes are ready for integration into the main-line, then they will need to follow the appropriate forest integration rules. Any committer to the JDK 9 project can push changes to the sandbox. > > Questions or issues relating to it should be directed to the maintainer, Chris Hegarty. It is strongly recommended that you subscribed to the changes mailing list if you are actively developing changes in the sandbox. > > ? Forest location: http://hg.openjdk.java.net/jdk9/sandbox > ? Changeset notifications: jdk9-sandbox-changes at openjdk dot java dot net > > Please read the following common questions and guidance before using the sandbox. > http://cr.openjdk.java.net/~chegar/docs/sandbox.html > > The most important rule to keep in mind when using the sandbox is; You should never push changes to the default branch. All active development should happen in branches ( other than the default ), leaving the default branch ?clean?, so it can easily be updated with changes from the upstream main-line forest. Individual branch owners can, at their discretion, sync up their branch with the main-line changes in the default branch. > > -Chris. > > [1] http://mail.openjdk.java.net/pipermail/discuss/2014-September/003552.html > From weijun.wang at oracle.com Tue Dec 16 03:01:04 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 16 Dec 2014 11:01:04 +0800 Subject: JDK 9 Sandbox Development Forest In-Reply-To: <7E1D9AA4-1EAD-4401-A52D-BF297C4C6AB3@oracle.com> References: <7E1D9AA4-1EAD-4401-A52D-BF297C4C6AB3@oracle.com> Message-ID: > On Dec 16, 2014, at 03:38, Chris Hegarty wrote: > > Please read the following common questions and guidance before using the sandbox. > http://cr.openjdk.java.net/~chegar/docs/sandbox.html I normally only work on one repo. Is there a guideline on using the simple commit and push commands without calling hgforest.sh? Is mq friendly with branch? Is it easy to push anything to the default branch if I am mostly working on my own branch? Also, is there a server-side hook that rejects such pushes? Thanks Max From david.holmes at oracle.com Tue Dec 16 05:23:51 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Dec 2014 15:23:51 +1000 Subject: 8067442: Tests using -Xshare:dump does not work with 'make test' In-Reply-To: <20141215152047.GC24542@ehelin.jrpg.bea.com> References: <20141215152047.GC24542@ehelin.jrpg.bea.com> Message-ID: <548FC1E7.4020308@oracle.com> On 16/12/2014 1:20 AM, Erik Helin wrote: > Hi all, > > this patch changes the dependency for the target `test` in make/Main.gmk > from exploded-image to jimages. This is needed because PRODUCT_HOME in > `make test` needs to be set to a full JDK image directory, because there > are tests in hotspot/test that uses -Xshare:dump and -Xshare:dump does > not work with an exploded jdk image. Is that something that should be fixed? What you are doing now seems a temporary workaround. David > There are currently 9 tests that are failing due to this when running: > $ make test TEST=hotspot_runtime > > Webrev: > http://cr.openjdk.java.net/~ehelin/8067442/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8067442 > > Testing: > - Run `make test TEST=hotspot_runtime` on Linux x86-64 and verified > that all tests now passes. > > Thanks, > Erik > From joel.franck at oracle.com Tue Dec 16 08:50:17 2014 From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=) Date: Tue, 16 Dec 2014 09:50:17 +0100 Subject: CFV: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <5481FAEE.2020102@oracle.com> References: <5481FAEE.2020102@oracle.com> Message-ID: Vote: yes cheers /Joel > On 5 dec 2014, at 19:35, Se?n Coffey wrote: > > I hearby nominate Ivan Gerasimov (igerasim) to JDK 9 Reviewer. > > Ivan is a member of the Java SE Sustaining team and works mainly on issues connected to the JDK core libraries. Over the past year, he's demonstrated a strong understanding of how the core libraries code works and has contributed significant bug fixes and enhancements in JDK 9 [3]. > > Votes are due by 19:00 GMT December 19th 2014. > > Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > Regards, > Sean. > > [1] : http://openjdk.java.net/census#jdk9 > [2] : http://openjdk.java.net/projects/#reviewer-vote > > [3] > $hg log -M -u igerasim -R jdk --template "{desc}\n" | grep "^[0-9]\{7,7\}: " > 8023173: FileDescriptor should respect append flag > 8059840: (bb) Typo in javadoc for ByteBuffer.wrap() > 8059450: Not quite correct code sample in javadoc > 8058099: (fc) Cleanup in FileChannel/FileDispatcher native implementation [win] > 8054029: (fc) FileChannel.size() returns 0 for block devices on Linux > 7010989: Duplicate closure of file descriptors leads to unexpected and incorrect closure of sockets > 8056310: Cleanup in WinNTFileSystem_md.c > 8054714: Use StringJoiner where it makes the code cleaner > 8055421: (fs) bad error handling in java.base/unix/native/libnio/fs/UnixNativeDispatcher.c > 8055731: sun/security/smartcardio/TestDirect.java throws java.lang.IndexOutOfBoundsException > 8054841: (process) ProcessBuilder leaks native memory > 8046343: (smartcardio) CardTerminal.connect('direct') does not work on MacOSX > 8054221: StringJoiner imlementation optimization > 8051382: Optimize java.lang.reflect.Modifier.toString() > 8050893: (smartcardio) Invert reset argument in tests in sun/security/smartcardio > 8035975: Pattern.compile(String, int) fails to throw IllegalArgumentException > 6904367: (coll) IdentityHashMap is resized before exceeding the expected maximum size > 8048080: (smartcardio) javax.smartcardio.Card.openLogicalChannel() dosn't work on MacOSX > 8037866: Replace the Fun class in tests with lambdas > 8044342: build failure on Windows noticed with recent smartcardio fix > 8043720: (smartcardio) Native memory should be handled more accurately > 7047033: (smartcardio) Card.disconnect(boolean reset) does not reset when reset is true > 8039319: (smartcardio) Card.transmitControlCommand() does not work on Mac OS X > 8043476: java/util/BitSet/BSMethods.java failed with: java.lang.OutOfMemoryError: Java heap space > 8043507: javax.smartcardio.CardTerminals.list() fails on MacOSX > 8043772: Typos in Double/Int/LongSummaryStatistics.java > 7195480: javax.smartcardio does not detect cards on Mac OS X > 8042470: (fs) Path.register doesn't throw IllegalArgumentException if multiple OVERFLOW events are specified > 8011537: (fs) Path.register(..) clears interrupt status of thread with no InterruptedException > 8040806: BitSet.toString() can throw IndexOutOfBoundsException > 8038982: java/lang/ref/EarlyTimeout.java failed again > 8039396: NPE when writing a class descriptor object to a custom ObjectOutputStream > 8009637: Some error messages are missing a space > 8038333: TEST_BUG: java/lang/ref/EarlyTimeout.java fails with a non-adequate message > 8014066: Remove redundant restriction from ArrayList#removeRange() spec > 6943190: TEST_BUG: some tests in java/lang/Runtime/exec have hard-coded path to shell commands > 7011804: SequenceInputStream with lots of empty substreams can cause StackOverflowError > 8036088: Replace strtok() with its safe equivalent strtok_s() in DefaultProxySelector.c > 8034262: Test java/lang/ProcessBuilder/CloseRace.java fails > 6853696: (ref) ReferenceQueue.remove(timeout) may return null even if timeout has not expired > 8023022: Some more typos in javadoc > 4682009: Typo in javadocs in javax/naming > 8033943: Typo in the documentation for the class Arrays > 8027348: (process) Enhancement of handling async close of ProcessInputStream > 8025886: replace [[ and == bash extensions in regtest > 8030698: Several GUI labels in jconsole need correction > 8024521: (process) Async close issues with Process InputStream > 8023390: Test java/net/NetworkInterface/MemLeakTest.java failed with the latest jdk8 build > 8026756: Test java/util/zip/GZIP/GZIPInZip.java failed > 8023431: Test java/util/zip/GZIP/GZIPInZip.java failed > 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions > 7129312: BufferedInputStream calculates negative array size with large streams and mark > 8022584: Memory leak in some NetworkInterface methods > 8020669: (fs) Files.readAllBytes() does not read any data when Files.size() is 0 > 7192942: (coll) Inefficient calculation of power of two in HashMap > 8016838: improvement of RedefineBigClass and RetransformBigClass tests > 7181748: java/lang/ThreadGroup/Suspend.java test fails intermittently > > > $hg log -M -u igerasim -R hotspot --template "{desc}\n" | grep "^[0-9]\{7,7\}: " > 8059533: (process) Make exiting process wait for exiting threads [win] > 8057744: (process) Synchronize exiting of threads and process [win] > 8057745: TEST_BUG: runtime/SharedArchiveFile/ArchiveDoesNotExist.java fails with openjdk build > 8055338: (process) Add instrumentation to help diagnose JDK-6573254 > 8035893: JVM_GetVersionInfo fails to zero structure > > > > > From erik.helin at oracle.com Tue Dec 16 09:50:35 2014 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 16 Dec 2014 10:50:35 +0100 Subject: 8067442: Tests using -Xshare:dump does not work with 'make test' In-Reply-To: <548FC1E7.4020308@oracle.com> References: <20141215152047.GC24542@ehelin.jrpg.bea.com> <548FC1E7.4020308@oracle.com> Message-ID: <20141216095035.GC3493@ehelin.jrpg.bea.com> On 2014-12-16, David Holmes wrote: > On 16/12/2014 1:20 AM, Erik Helin wrote: > >Hi all, > > > >this patch changes the dependency for the target `test` in make/Main.gmk > >from exploded-image to jimages. This is needed because PRODUCT_HOME in > >`make test` needs to be set to a full JDK image directory, because there > >are tests in hotspot/test that uses -Xshare:dump and -Xshare:dump does > >not work with an exploded jdk image. > > Is that something that should be fixed? What you are doing now seems a > temporary workaround. I am not familiar with the class data sharing (CDS) implementation, but the failures all give the same error: Hint: enable -XX:+TraceClassPaths to diagnose the failure Error occurred during initialization of VM CDS allows only empty directories in archived classpaths I don't know why CDS does not allow non-empty directories on the archived classpath, maybe Ioi can answer that? Anyhow, I believe that eventually enhancing CDS to allow non-empty directories on the archived classpath is a separate patch. This patch is about reversing the change that Erik did (see his reply for more details) to make sure that we can run the tests. What do you think? Thanks, Erik > David > > >There are currently 9 tests that are failing due to this when running: > >$ make test TEST=hotspot_runtime > > > >Webrev: > >http://cr.openjdk.java.net/~ehelin/8067442/webrev.00/ > > > >Bug: > >https://bugs.openjdk.java.net/browse/JDK-8067442 > > > >Testing: > >- Run `make test TEST=hotspot_runtime` on Linux x86-64 and verified > > that all tests now passes. > > > >Thanks, > >Erik > > From david.holmes at oracle.com Tue Dec 16 09:59:16 2014 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Dec 2014 19:59:16 +1000 Subject: 8067442: Tests using -Xshare:dump does not work with 'make test' In-Reply-To: <20141216095035.GC3493@ehelin.jrpg.bea.com> References: <20141215152047.GC24542@ehelin.jrpg.bea.com> <548FC1E7.4020308@oracle.com> <20141216095035.GC3493@ehelin.jrpg.bea.com> Message-ID: <54900274.8040908@oracle.com> On 16/12/2014 7:50 PM, Erik Helin wrote: > On 2014-12-16, David Holmes wrote: >> On 16/12/2014 1:20 AM, Erik Helin wrote: >>> Hi all, >>> >>> this patch changes the dependency for the target `test` in make/Main.gmk >> >from exploded-image to jimages. This is needed because PRODUCT_HOME in >>> `make test` needs to be set to a full JDK image directory, because there >>> are tests in hotspot/test that uses -Xshare:dump and -Xshare:dump does >>> not work with an exploded jdk image. >> >> Is that something that should be fixed? What you are doing now seems a >> temporary workaround. > > I am not familiar with the class data sharing (CDS) implementation, but > the failures all give the same error: > > Hint: enable -XX:+TraceClassPaths to diagnose the failure > Error occurred during initialization of VM > CDS allows only empty directories in archived classpaths > > I don't know why CDS does not allow non-empty directories on the > archived classpath, maybe Ioi can answer that? It is because the classpath has ot be known to be the same at dump time and runtime. If we allowed directories in the classpath (versus jars) then we would have to track the directory contents. > Anyhow, I believe that eventually enhancing CDS to allow non-empty > directories on the archived classpath is a separate patch. This patch is > about reversing the change that Erik did (see his reply for more > details) to make sure that we can run the tests. > > What do you think? Yes that is fine. I think these tests would also have failed in the non-modular image if run against the jdk directory rather than the image. Thanks, David > > Thanks, > Erik > >> David >> >>> There are currently 9 tests that are failing due to this when running: >>> $ make test TEST=hotspot_runtime >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8067442/webrev.00/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8067442 >>> >>> Testing: >>> - Run `make test TEST=hotspot_runtime` on Linux x86-64 and verified >>> that all tests now passes. >>> >>> Thanks, >>> Erik >>> From chris.hegarty at oracle.com Tue Dec 16 10:02:21 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 16 Dec 2014 10:02:21 +0000 Subject: JDK 9 Sandbox Development Forest In-Reply-To: <548F97A7.2030100@oracle.com> References: <7E1D9AA4-1EAD-4401-A52D-BF297C4C6AB3@oracle.com> <548F97A7.2030100@oracle.com> Message-ID: <2A3011A6-FD70-4246-9B29-930A84AA2423@oracle.com> On 16 Dec 2014, at 02:23, Stuart Marks wrote: > Yay sandbox! > > Thanks for following through with this, Chris. > > Just to try things out, I've created my own test branch "smarks-test0". And I've already run into a bug in hgforest.sh. :-) The problem is that following the instructions in the sandbox guidance: > > http://cr.openjdk.java.net/~chegar/docs/sandbox.html > > The example line to commit an initial changeset to the branch: > > sh common/bin/hgforest.sh commit -m "Initial changes for JDK-8000000? D?oh! I used '-l? when testing, but ?-m? appeared clearer in the documentation. > doesn't work. The problem is that hgforest.sh breaks the quoted string into separate arguments, which the commit command doesn't like. I've filed https://bugs.openjdk.java.net/browse/JDK-8067631 on this. > > The workaround is to put the commit comment into a file and do something like > > sh common/bin/hgforest.sh commit -l /absolute/path/to/comment.txt Yes, this will work. Thanks. > Meanwhile, I've done a bit of hacking on the hgforest.sh script, and I've posted a webrev--, er, no, I've pushed a changeset (!) here: > > http://hg.openjdk.java.net/jdk9/sandbox/rev/886037762070 > > It's on my own branch, of course. > > If people could try this out, I'll transplant it back to jdk9-dev at some point. I played with this on Mac and Linux, and it works. I also reviewed the changes in the changeset. Consider it Reviewed. If you can push this to jdk9/dev, then I?ll hold off changing the documentation to use ?-l?. -Chris. > All hail the new era of the JDK Sandbox! > > s'marks > > > > > > > On 12/15/14 11:38 AM, Chris Hegarty wrote: >> Hi, >> >> Announcing the JDK 9 Sandbox Development Forest, as proposed by Mike Duigou [1]. >> >> The primary purpose of the JDK 9 Sandbox Development Forest is to facilitate OpenJDK developers that are working on non-trivial changes, possibly JEP-scale effort, whose scope and duration make it necessary to collaborate with others in an open shared version control system, rather than just using privately shared patches. >> >> Working in the sandbox can facilitate rapid iterative development, as there is no requirement for changes to be reviewed or accompanied by bug numbers, i.e. jcheck is not enabled. Just create a new branch and start working. When the changes are ready for integration into the main-line, then they will need to follow the appropriate forest integration rules. Any committer to the JDK 9 project can push changes to the sandbox. >> >> Questions or issues relating to it should be directed to the maintainer, Chris Hegarty. It is strongly recommended that you subscribed to the changes mailing list if you are actively developing changes in the sandbox. >> >> ? Forest location: http://hg.openjdk.java.net/jdk9/sandbox >> ? Changeset notifications: jdk9-sandbox-changes at openjdk dot java dot net >> >> Please read the following common questions and guidance before using the sandbox. >> http://cr.openjdk.java.net/~chegar/docs/sandbox.html >> >> The most important rule to keep in mind when using the sandbox is; You should never push changes to the default branch. All active development should happen in branches ( other than the default ), leaving the default branch ?clean?, so it can easily be updated with changes from the upstream main-line forest. Individual branch owners can, at their discretion, sync up their branch with the main-line changes in the default branch. >> >> -Chris. >> >> [1] http://mail.openjdk.java.net/pipermail/discuss/2014-September/003552.html >> From chris.hegarty at oracle.com Tue Dec 16 10:51:07 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 16 Dec 2014 10:51:07 +0000 Subject: JDK 9 Sandbox Development Forest In-Reply-To: References: <7E1D9AA4-1EAD-4401-A52D-BF297C4C6AB3@oracle.com> Message-ID: On 16 Dec 2014, at 03:01, Wang Weijun wrote: > >> On Dec 16, 2014, at 03:38, Chris Hegarty wrote: >> >> Please read the following common questions and guidance before using the sandbox. >> http://cr.openjdk.java.net/~chegar/docs/sandbox.html > > I normally only work on one repo. Is there a guideline on using the simple commit and push commands without calling hgforest.sh? You can use just a single repo, and the commands are the same, s/sh common\/bin\/hgforest.sh/hg/. But, 1) your branch name is not guaranteed to available in other repos if/when you need it, 2) your branch will not have a consistent view of the forest. Other repos, using the default branch, will continue to be updated with changes from jdk9/dev, which may cause build failures as your branch will have to be manually synced with the default branch. > Is mq friendly with branch? I have not experimented too much with queues on branches, but it appears to push and pop simple patches fine for me. Of course, you need to 'qpop -a' before updating between branches otherwise it gets confused, but then this is no different from a normal 'hg update -r?, without branches. > Is it easy to push anything to the default branch if I am mostly working on my own branch? Also, is there a server-side hook that rejects such pushes? There is no hook preventing pushes to the default branch. Please be careful. If this becomes an issue over time, then we can look at the possibility of adding such a hook. I would like to get some experience with using branches and see how it goes before deciding if this is necessary. -Chris. > Thanks > Max > From weijun.wang at oracle.com Tue Dec 16 10:55:57 2014 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 16 Dec 2014 18:55:57 +0800 Subject: JDK 9 Sandbox Development Forest In-Reply-To: References: <7E1D9AA4-1EAD-4401-A52D-BF297C4C6AB3@oracle.com> Message-ID: <907E08E5-5964-4431-BB9B-2F1B3BFA0DC7@oracle.com> Thanks for the answers. I also noticed that in order to disable jcheck hooks locally, I'll have to add [hooks] pretxnchangegroup.jcheck= pretxncommit.jcheck= to every repo. Is there a simpler way? Thanks Max From chris.hegarty at oracle.com Tue Dec 16 11:01:01 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 16 Dec 2014 11:01:01 +0000 Subject: JDK 9 Sandbox Development Forest In-Reply-To: <907E08E5-5964-4431-BB9B-2F1B3BFA0DC7@oracle.com> References: <7E1D9AA4-1EAD-4401-A52D-BF297C4C6AB3@oracle.com> <907E08E5-5964-4431-BB9B-2F1B3BFA0DC7@oracle.com> Message-ID: On 16 Dec 2014, at 10:55, Wang Weijun wrote: > Thanks for the answers. > > I also noticed that in order to disable jcheck hooks locally, I'll have to add > > [hooks] > pretxnchangegroup.jcheck= > pretxncommit.jcheck= > > to every repo. Is there a simpler way? Disabling jcheck is quite common for anyone working in non main-line projects. I just disable the pre commit hooks in my ~/.hgrc, and run it manually when needed. I would like to propose a laxify branches option for the jcheck configuration, at some point. If the sandbox turns out to be useful. Then each branch can laxify jcheck as needed, and continue to get tab and whitespace checking. -Chris. > > Thanks > Max > From jaroslav.bachorik at oracle.com Tue Dec 16 12:19:50 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Tue, 16 Dec 2014 13:19:50 +0100 Subject: JDK 9 Sandbox Development Forest In-Reply-To: References: <7E1D9AA4-1EAD-4401-A52D-BF297C4C6AB3@oracle.com> Message-ID: <54902366.6060202@oracle.com> On 12/16/2014 11:51 AM, Chris Hegarty wrote: > On 16 Dec 2014, at 03:01, Wang Weijun wrote: > >> >>> On Dec 16, 2014, at 03:38, Chris Hegarty wrote: >>> >>> Please read the following common questions and guidance before using the sandbox. >>> http://cr.openjdk.java.net/~chegar/docs/sandbox.html >> >> I normally only work on one repo. Is there a guideline on using the simple commit and push commands without calling hgforest.sh? > > You can use just a single repo, and the commands are the same, s/sh common\/bin\/hgforest.sh/hg/. But, > > 1) your branch name is not guaranteed to available in other repos if/when you need it, > > 2) your branch will not have a consistent view of the forest. > > Other repos, using the default branch, will continue to be updated > with changes from jdk9/dev, which may cause build failures > as your branch will have to be manually synced with the > default branch. > >> Is mq friendly with branch? > > I have not experimented too much with queues on branches, but it appears to push and pop simple patches fine for me. Of course, you need to 'qpop -a' before updating between branches otherwise it gets confused, but then this is no different from a normal 'hg update -r?, without branches. MQ is agnostic to branches - it's up to the user to qpush on the correct branch. Also, you can use `hg rebase` after updating instead of `hg qpop -a` before updating. It will 'rebase' the 'qbase' changeset on top of the branch tip. When there is a conflict you will need to perform the merge manually and refresh the patch. > >> Is it easy to push anything to the default branch if I am mostly working on my own branch? Also, is there a server-side hook that rejects such pushes? > > There is no hook preventing pushes to the default branch. Please be careful. There is a workaround. In your /.hg/hgrc you can specify 'defaults' ``` [defaults] push = -b outgoing = -b ``` After this the `hg push` and `hg outgoing` will have the '-b' option appended, effectively allowing you to work on the only. -JB- > > If this becomes an issue over time, then we can look at the possibility of adding such a hook. I would like to get some experience with using branches and see how it goes before deciding if this is necessary. > > -Chris. > >> Thanks >> Max >> > From chris.hegarty at oracle.com Tue Dec 16 14:18:19 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 16 Dec 2014 14:18:19 +0000 Subject: JDK 9 Sandbox Development Forest In-Reply-To: <54902366.6060202@oracle.com> References: <7E1D9AA4-1EAD-4401-A52D-BF297C4C6AB3@oracle.com> <54902366.6060202@oracle.com> Message-ID: On 16 Dec 2014, at 12:19, Jaroslav Bachorik wrote: > ... >> >>> Is it easy to push anything to the default branch if I am mostly working on my own branch? Also, is there a server-side hook that rejects such pushes? >> >> There is no hook preventing pushes to the default branch. Please be careful. > > There is a workaround. In your /.hg/hgrc you can specify 'defaults' > > ``` > [defaults] > push = -b > outgoing = -b > ``` > > After this the `hg push` and `hg outgoing` will have the '-b' option appended, effectively allowing you to work on the only. Thanks for this Jaroslav. You need to be on the specific branch when you commit, of course, but the ?-b? option on ?out? and ?push? will help catch mistakes. I?ll update the document. -Chris. > > -JB- From stuart.marks at oracle.com Tue Dec 16 16:43:43 2014 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 16 Dec 2014 08:43:43 -0800 Subject: JDK 9 Sandbox Development Forest In-Reply-To: References: <7E1D9AA4-1EAD-4401-A52D-BF297C4C6AB3@oracle.com> Message-ID: <5490613F.4090004@oracle.com> On 12/16/14 2:51 AM, Chris Hegarty wrote: > On 16 Dec 2014, at 03:01, Wang Weijun wrote: >> Is it easy to push anything to the default branch if I am mostly working on my own branch? Also, is there a server-side hook that rejects such pushes? > > There is no hook preventing pushes to the default branch. Please be careful. > > If this becomes an issue over time, then we can look at the possibility of adding such a hook. I would like to get some experience with using branches and see how it goes before deciding if this is necessary. Right. Fortunately, once you're working on a branch, the branch is "sticky" and subsequent commits will remain on the same branch. With no argument, "hg update" will update to the head of the current branch. You'll only switch branches if you explicitly switch branches using "hg update " or give a specific rev that happens to be on another branch. If, however, you say "hg update tip" you might be updated to some arbitrary branch, perhaps the default branch or even somebody else's. The reason is that the "tip" is simply the latest changeset in the repository, and it is not attached to any particular branch. For this reason I recommend avoiding "hg update tip" if you've been in the habit of doing this. To avoid accidentally pushing something to the default branch, I'd recommend that the first thing you do after cloning the sandbox is either to create your own branch or update to an existing non-default branch. That way, your next push won't go on the default branch. s'marks From alejandro.murillo at oracle.com Tue Dec 16 21:40:22 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 16 Dec 2014 14:40:22 -0700 Subject: jdk9-dev: HotSpot Message-ID: <5490A6C6.2080001@oracle.com> jdk9-hs2-2014-12-12 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/49f961cf19ad http://hg.openjdk.java.net/jdk9/dev/corba/rev/9645e35616b6 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/fb4ba04c587b http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/f6b83b15628f http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/edc13d27dc87 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/cc4f004df279 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/a3c4196fc990 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/afdeed4d671a Component : VM Status : Go for integration Date : 16/12/2014 at 18:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2014-12-12-155652.amurillo.jdk9-hs2-2014-12-12-snapshot Testing: 381 new failures, 4964 known failures, 362386 passed. Issues and Notes: JCK tests were not executed, because jck4jdk is not adjusted to jigsaw yet. No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 6364329: jstat displays "invalid argument count" with usage 6522873: Java not print "Unrecognized option" when it is invalid option. 6618335: ThreadReference.stop(null) throws NPE instead of InvalidTypeException 6762191: Setting stack size to 16K causes segmentation fault 6898462: The escape analysis with G1 cause crash assertion src/share/vm/runtime/vframeArray.cpp:94 8038468: java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError 8044591: [TESTBUG] com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationp[Content]Test.java fail when -XX:+ExplicitGCInvokesConcurrent 8048170: Test closed/java/text/Normalizer/ConformanceTest.java failed 8059066: CardTableModRefBS might commit the same page twice 8059949: com/sun/tools/attach/StartManagementAgent.java interrupted! (timed out?) 8061785: [TEST_BUG] serviceability/sa/jmap-hashcode/Test8028623.java has utf8 character corrupted by earlier merge 8064441: java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object 8065050: vm crashes during CDS dump when very small SharedMiscDataSize is specified 8065134: Need WhiteBox::allocateCodeBlob(long, int) method to be implemented 8065634: Crash in InstanceKlass::clean_method_data when _method is NULL 8065788: os::reserve_memory() on Windows should not assert that allocation size is aligned to OS allocation granularity 8066102: Clean up HeapRegionRemSet files 8066103: C2's range check smearing allows out of bound array accesses 8066106: sun/tools/jps/TestJpsClass.java failed to remove stale attach pid file 8066171: Out of order with Metaspace allocation lock 8066250: compiler/dependencies/MonomorphicObjectCall/TestMonomorphicObjectCall.java fails product 8066441: Add PLAB trace event 8066508: JTReg tests timeout on slow devices when run using JPRT 8066670: PrintSharedArchiveAndExit does not exit the VM when the archive is invalid 8066775: opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1 8066780: Split CardGeneration out to its own file 8066781: Minor cleanups to TenuredGeneration 8066782: Move common code from CMSGeneration and TenuredGeneration to CardGeneration 8066900: Array Out Of Bounds Exception causes variable corruption 8067144: SIGSEGV with +TraceDeoptimization in Deoptimization::print_objects -- Alejandro From lana.steuck at oracle.com Wed Dec 17 22:08:57 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 17 Dec 2014 14:08:57 -0800 (PST) Subject: jdk9-b43: dev Message-ID: <201412172208.sBHM8vGL027034@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/02ee8c65622e http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/8ae8dff2a28f http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/6a06008aec10 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8c6ad41974f9 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/edc13d27dc87 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/40b242363040 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/65a9747147b8 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/9645e35616b6 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8064407 core-libs (fc) FileChannel transferTo should use TransmitFile on Windows JDK-8066915 core-libs (fs) Files.newByteChannel opens directories for cases where subsequent reads may fail JDK-8046219 core-libs (str spec) String(byte[], int, int, Charset) should be clearer when IndexOutOfBoundsException is thrown JDK-8066643 core-libs (zipfs) Suppress deprecation warnings in jdk.zipfs module JDK-8067136 core-libs BrowserJSObjectLinker does not handle call on JSObjects JDK-8066221 core-libs Fuzzing bug: Assertion error related to bytecode slots JDK-8066227 core-libs Fuzzing bug: CodeGenerator load unitialized slot JDK-8066236 core-libs Fuzzing bug: StackMapTable error: bad offset, ClassFormatError JDK-8066230 core-libs Fuzzing bug: Undefined object type assertion when computing TypeBounds JDK-8066224 core-libs Fuzzing bug: constant folding of ternary operator and IfNode with constant test JDK-8066225 core-libs Fuzzing bug: duplicate integer switch cases JDK-8065991 core-libs LogManager unecessarily calls JavaAWTAccess from within a critical section JDK-8066746 core-libs MHs.explicitCastArguments does incorrect type checks for VarargsCollector JDK-8067219 core-libs NPE in ScriptObject.clone() when running with object fields JDK-8066753 core-libs OptimisticTypePersistence.java should work properly with "jrt" URL JDK-8066777 core-libs OptimisticTypesPersistence.java should use Files.readAllBytes instead of getting size and then read JDK-8055723 core-libs Replace concat String to append in StringBuilder parameters JDK-8066641 core-libs Suppress deprecation warnings in jdk.naming module JDK-8066835 core-libs TEST_BUG: javax/management/remote/mandatory/connection/RMIConnector_NPETest.java fails JDK-8035001 core-libs TEST_BUG: the retry logic in RMID.start() should check that the subprocess hasn't terminated JDK-8066748 core-libs Update lambda/SAND to work with modular image JDK-8066798 core-libs [TEST] Make java/lang/invoke/LFCaching tests use lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java to define their number of iterations JDK-8066932 core-libs __noSuchMethod__ binds to this-object without proper guard JDK-8066669 core-libs dust.js performance regression caused by primitive field conversion JDK-8066678 core-libs java.nio.channels.Channels cleanup JDK-8065238 core-libs javax.naming.NamingException after upgrade to JDK 8 JDK-8066749 core-libs jdk9-dev/nashorn ant build fails with jdk9 modular image build as JAVA_HOME JDK-8066745 core-libs tools/pack200/Pack200Props.java failed with java.lang.OutOfMemoryError: Java heap space JDK-8067030 core-svc JDWP crash in transport_startTransport on OOM JDK-8066634 core-svc Suppress deprecation warnings in java.management module JDK-8066636 core-svc Suppress deprecation warnings in the jdk.jvmstat and jdk.jdi modules JDK-8066105 core-svc closed/sun/management/snmp/jvmMemory/JvmMemGCTest.sh should be quarantined JDK-8035663 embedded Suspicious failure of test java/util/concurrent/Phaser/FickleRegister.java JDK-7176220 hotspot 'Full GC' events miss date stamp information occasionally JDK-8053995 hotspot Add method to WhiteBox to get vm pagesize. JDK-8065754 hotspot Add test to verify that JFR dynamic start is locked in non-commercial builds JDK-8037968 hotspot Add tests on alignment of objects copied to survivor space JDK-8064953 hotspot Asserts.assert* should print values JDK-8066137 hotspot Backslash missing in TEST.groups JDK-8066199 hotspot C2 escape analysis prevents VM from exiting quickly JDK-8066019 hotspot CMM: Defaults to high memory restriction in 8u40-b16 JDK-8058160 hotspot CMM: Improve G1's reaction to memory pressure JDK-8058935 hotspot CPU detection gives 0 cores per cpu, 2 threads per core in Amazon EC2 environment JDK-8065992 hotspot Change CMSCollector::_young_gen to be a ParNewGeneration* JDK-8065783 hotspot DCMD parser fails to recognize one character argument when it's positioned last JDK-8065872 hotspot Exclude new resource management tests forward ported from 8u40 JDK-8066662 hotspot Fix include after 8065993: Merge OneContigSpaceCardGeneration with TenuredGeneration JDK-8065915 hotspot Fix includes after 8058148: MaxNodeLimit and LiveNodeCountInliningCutoff JDK-8066133 hotspot Fix missing reivew changes for JDK-8065972 JDK-8067015 hotspot Implement os::pd_map_memory() on AIX JDK-8065889 hotspot JFR: -XX:StartFlightRecording doesn't accept empty argument - take 2 JDK-8064694 hotspot Kitchensink: WaitForMultipleObjects failed in hotspot\src\os\windows\vm\os_windows.cpp: 3844 JDK-8065305 hotspot Make it possible to extend the G1CollectorPolicy JDK-8065993 hotspot Merge OneContigSpaceCardGeneration with TenuredGeneration JDK-8065218 hotspot Move CMS-specific fields from Space to CompactibleFreeListSpace JDK-8065664 hotspot Need defensive checks in PDH if perf counters are disabled or not visible JDK-8066290 hotspot Port JDK-8066191 into hotspot JDK-8062943 hotspot REDO - Parallelize clearing the next mark bitmap JDK-8065358 hotspot Refactor G1s usage of save_marks and reduce related races JDK-8065972 hotspot Remove support for ParNew+SerialOld and DefNew+CMS JDK-8065227 hotspot Report allocation context stats at end of cleanup JDK-8066448 hotspot SmallCodeCacheStartup.java exits with exit code 1 JDK-8039995 hotspot Test serviceability/sa/jmap-hashcode/Test8028623.java fails on some Linux/Mac machines. JDK-8062161 hotspot Threads might be deleted before used in jmm_ext code JDK-8065579 hotspot WB method to start G1 concurrent mark cycle should be introduced JDK-8062584 hotspot [TESTBUG] AppCDS: ensure test coverage for class loader constraints JDK-8062550 hotspot [TESTBUG] additional test is needed for 8061234 ResourceContext.requestAccurateUpdate() is unreliable JDK-8061300 hotspot [TESTBUG] closed/gc/TestMemoryPressureReactionDecommit.java still fails with OOM JDK-8065875 hotspot [TESTBUG] closed/runtime/AppCDS/JvmtiAddPath.java: Cannot find /export/local/aurora/sandbox/results/workDir/classes/1/closed/runtime/AppCDS/jvmti_app.jar JDK-8065868 hotspot [TESTBUG] closed/runtime/AppCDS/JvmtiAddPath.java: [Loaded ExtraClass from shared object' missing from stdout/stderr JDK-8065752 hotspot [TESTBUG]: closed/runtime/AppCDS/CommandLineFlagCombo.java fails because of conflicting GC JDK-8065749 hotspot [TESTBUG]: gc/arguments/TestG1HeapRegionSize.java fails at nightly JDK-8055239 hotspot assert(_thread == Thread::current()->osthread()) failed: The PromotionFailedInfo should be thread local. JDK-8058846 hotspot c.o.j.t.Platform::isX86 and isX64 may simultaneously return true JDK-8064669 hotspot compiler/whitebox/AllocationCodeBlobTest.java crashes / asserts JDK-8066141 hotspot compiler/whitebox/GetNMethodTest.java: java.lang.RuntimeException: blob_type[MethodProfiled] for 2 level isn't MethodNonProfiled JDK-8064703 hotspot crash running specjvm98's javac following 8060252 JDK-8065865 hotspot gc/TestSoftReferencesBehaviorOnOOME.java: Error. Can't find source file: TestSoftReference.java JDK-8066713 hotspot ignore compiler/types/correctness JDK-8066045 hotspot opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1 JDK-8060074 hotspot os::free() takes MemoryTrackingLevel but doesn't need it JDK-8066761 infrastructure Investigate -sourcepath usage when compiling java JDK-8066507 infrastructure JPRT is not capable of running jtreg tests located jdk/test JDK-8066589 infrastructure Make importing sa-jdi.jar optional on its existance JDK-8066752 infrastructure Remove space after -L on linker lines JDK-8066766 infrastructure The commands in the modular images are executable by the owner only JDK-8065656 infrastructure Use DWARF debug symbols for Solaris JDK-8066828 infrastructure configure fails if it's set --with-boot-jdk to use JDK 9 modular image JDK-8062230 other-libs [TESTBUG] Create tests to check that Resource Management is not available in non commercial build JDK-8044500 security-libs Add kinit options and krb5.conf flags that allow users to obtain renewable tickets and specify ticket lifetimes JDK-8049432 security-libs New tests for TLS property jdk.tls.client.protocols JDK-8066638 security-libs Suppress deprecation warnings in jdk.crypto module JDK-8067001 tools DetectMutableStaticFields fails after modular images push JDK-8061549 tools Disallow _ as a one-character identifier JDK-8064794 tools Implement a negative test for cyclic dependencies in import statements JDK-8065360 tools Implement a test that checks possibilty of class members to be imported JDK-8066889 tools IntelliJ langtools launcher ought to be Windows friendly JDK-8066902 tools JavacParserTest fails on Windows JDK-8066841 tools Need to exclude javacpl in tools/launcher/VersionCheck.java JDK-8066961 tools NegativeCyclicDependencyTest.java fails on Windows JDK-8058407 tools Remove Multiple JRE support in the Java launcher JDK-8067006 tools Tweak IntelliJ langtools project to show jtreg report directory JDK-8065753 tools javac crashing on a html-like file JDK-8066737 tools langtools/test/tools/javac/processing/6348193/T6348193.java fails JDK-8051536 xml Convert JAXP function tests: javax.xml.parsers to jtreg(testng) tests JDK-8067183 xml TEST_BUG:File locked when processing the cleanup on test jaxp/test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerFactoryTest.java From mparchet at sunrise.ch Thu Dec 18 21:41:12 2014 From: mparchet at sunrise.ch (=?ISO-8859-1?Q?Micha=EBl_Parchet?=) Date: Thu, 18 Dec 2014 22:41:12 +0100 Subject: How to test : JEP 222: Java Read-Eval-Print Loop (REPL) Message-ID: <549349F8.7010105@sunrise.ch> Hello, How could I test the JEP 222: Java Read-Eval-Print Loop (REPL) ? Thanks for your answer Best regards mparchet From jonathan.gibbons at oracle.com Thu Dec 18 21:55:13 2014 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 18 Dec 2014 13:55:13 -0800 Subject: How to test : JEP 222: Java Read-Eval-Print Loop (REPL) In-Reply-To: <549349F8.7010105@sunrise.ch> References: <549349F8.7010105@sunrise.ch> Message-ID: <54934D41.5070603@oracle.com> On 12/18/2014 01:41 PM, Micha?l Parchet wrote: > Hello, > > How could I test the JEP 222: Java Read-Eval-Print Loop (REPL) ? > > Thanks for your answer > > Best regards > > mparchet This question is better directed at the mailing list for the project where the work is ongoing. See http://openjdk.java.net/projects/kulla/ http://mail.openjdk.java.net/mailman/listinfo/kulla-dev -- Jon From david.holmes at oracle.com Fri Dec 19 05:00:14 2014 From: david.holmes at oracle.com (David Holmes) Date: Fri, 19 Dec 2014 15:00:14 +1000 Subject: CFV: New JDK 9 Committer: Yasumasa Suenaga Message-ID: <5493B0DE.3090702@oracle.com> I hereby nominate Yasumasa Suenaga to JDK 9 Committer. He has been contributing to OpenJDK since 2011 and has eight changesets attributed directly to him and several other contributions that were made but not formally acknowledged: * changesets: 1. 7015169: GC Cause not always set http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c798c277ddd1 2. 8011934: sun.misc.PerfCounter calls Perf.createLong with incorrect parameters http://hg.openjdk.java.net/jdk9/hs/jdk/rev/3b81fac25d26 3. 6989981: jstack causes "fatal error: ExceptionMark destructor expects no pending exceptions" http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8ddc26f62476 4. 7090324: gclog rotation via external tool http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b5748753ad2f 5. 8017773: OpenJDK7 returns incorrect TrueType font metrics http://hg.openjdk.java.net/jdk9/client/jdk/rev/2559e1d816ae 6. 8057556: JDP should better handle non-active interfaces http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a1afd6e36f0 7. 8057746: Cannot handle JdpException in JMX agent initialization. http://hg.openjdk.java.net/jdk9/dev/jdk/rev/37ac8a27a427 8. 8059586: hs_err report should treat redirected core pattern http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/30ed7423ae23 * Other contribution (Not attributed in changeset) - JDK-7003789: PTRACE_GETREGS problems with SA on Linux. http://mail.openjdk.java.net/pipermail/serviceability-dev/2010-December/003081.html - JDK-7044285: 64 bit VM crashes in Java_sun_java2d_loops_MaskFill_MaskFill http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-June/002233.html - JDK-7133122: SA throws sun.jvm.hotspot.debugger.UnmappedAddressException when it should not http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-September/011737.html - JDK-7186278: Build error after CR#6995781 / 7151532 with GCC 4.7.0 http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-July/004153.html - JDK-8004898: library_call.cpp build error after 7172640 with GCC 4.7.2 http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009116.html - JDK-8027059: (sctp) fatal warnings overly restrictive with gcc 4.8.1 http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018791.html Votes are due by 15:00 Friday January 2, 2015 (Australian Eastern Standard Time). Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. David Holmes [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote From vladimir.x.ivanov at oracle.com Fri Dec 19 10:55:41 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 19 Dec 2014 13:55:41 +0300 Subject: CFV: New JDK 9 Committer: Yasumasa Suenaga In-Reply-To: <5493B0DE.3090702@oracle.com> References: <5493B0DE.3090702@oracle.com> Message-ID: <5494042D.3070508@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 12/19/14 8:00 AM, David Holmes wrote: > I hereby nominate Yasumasa Suenaga to JDK 9 Committer. > > He has been contributing to OpenJDK since 2011 and has eight changesets > attributed directly to him and several other contributions that were > made but not formally acknowledged: > > * changesets: > 1. 7015169: GC Cause not always set > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c798c277ddd1 > 2. 8011934: sun.misc.PerfCounter calls Perf.createLong with > incorrect parameters > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/3b81fac25d26 > 3. 6989981: jstack causes "fatal error: ExceptionMark destructor > expects no pending exceptions" > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8ddc26f62476 > 4. 7090324: gclog rotation via external tool > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b5748753ad2f > 5. 8017773: OpenJDK7 returns incorrect TrueType font metrics > http://hg.openjdk.java.net/jdk9/client/jdk/rev/2559e1d816ae > 6. 8057556: JDP should better handle non-active interfaces > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a1afd6e36f0 > 7. 8057746: Cannot handle JdpException in JMX agent initialization. > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/37ac8a27a427 > 8. 8059586: hs_err report should treat redirected core pattern > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/30ed7423ae23 > > * Other contribution (Not attributed in changeset) > - JDK-7003789: PTRACE_GETREGS problems with SA on Linux. > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2010-December/003081.html > > - JDK-7044285: 64 bit VM crashes in > Java_sun_java2d_loops_MaskFill_MaskFill > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-June/002233.html > > - JDK-7133122: SA throws > sun.jvm.hotspot.debugger.UnmappedAddressException when it should not > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-September/011737.html > > - JDK-7186278: Build error after CR#6995781 / 7151532 with GCC 4.7.0 > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-July/004153.html > > - JDK-8004898: library_call.cpp build error after 7172640 with GCC > 4.7.2 > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009116.html > > - JDK-8027059: (sctp) fatal warnings overly restrictive with gcc 4.8.1 > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018791.html > > Votes are due by 15:00 Friday January 2, 2015 (Australian Eastern > Standard Time). > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From neugens.limasoftware at gmail.com Fri Dec 19 11:29:50 2014 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Fri, 19 Dec 2014 12:29:50 +0100 Subject: CFV: New JDK 9 Committer: Yasumasa Suenaga In-Reply-To: <5493B0DE.3090702@oracle.com> References: <5493B0DE.3090702@oracle.com> Message-ID: Vote: Yes! Mario 2014-12-19 6:00 GMT+01:00 David Holmes : > I hereby nominate Yasumasa Suenaga to JDK 9 Committer. > > He has been contributing to OpenJDK since 2011 and has eight changesets > attributed directly to him and several other contributions that were made > but not formally acknowledged: > > * changesets: > 1. 7015169: GC Cause not always set > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c798c277ddd1 > 2. 8011934: sun.misc.PerfCounter calls Perf.createLong with incorrect > parameters > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/3b81fac25d26 > 3. 6989981: jstack causes "fatal error: ExceptionMark destructor expects > no pending exceptions" > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8ddc26f62476 > 4. 7090324: gclog rotation via external tool > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b5748753ad2f > 5. 8017773: OpenJDK7 returns incorrect TrueType font metrics > http://hg.openjdk.java.net/jdk9/client/jdk/rev/2559e1d816ae > 6. 8057556: JDP should better handle non-active interfaces > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a1afd6e36f0 > 7. 8057746: Cannot handle JdpException in JMX agent initialization. > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/37ac8a27a427 > 8. 8059586: hs_err report should treat redirected core pattern > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/30ed7423ae23 > > * Other contribution (Not attributed in changeset) > - JDK-7003789: PTRACE_GETREGS problems with SA on Linux. > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2010-December/003081.html > - JDK-7044285: 64 bit VM crashes in > Java_sun_java2d_loops_MaskFill_MaskFill > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-June/002233.html > - JDK-7133122: SA throws > sun.jvm.hotspot.debugger.UnmappedAddressException when it should not > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-September/011737.html > - JDK-7186278: Build error after CR#6995781 / 7151532 with GCC 4.7.0 > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-July/004153.html > - JDK-8004898: library_call.cpp build error after 7172640 with GCC 4.7.2 > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009116.html > - JDK-8027059: (sctp) fatal warnings overly restrictive with gcc 4.8.1 > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018791.html > > Votes are due by 15:00 Friday January 2, 2015 (Australian Eastern Standard > Time). > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From harold.seigel at oracle.com Fri Dec 19 13:17:24 2014 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 19 Dec 2014 08:17:24 -0500 Subject: CFV: New JDK 9 Committer: Yasumasa Suenaga In-Reply-To: <5493B0DE.3090702@oracle.com> References: <5493B0DE.3090702@oracle.com> Message-ID: <54942564.3060309@oracle.com> Vote: yes Harold On 12/19/2014 12:00 AM, David Holmes wrote: > I hereby nominate Yasumasa Suenaga to JDK 9 Committer. > > He has been contributing to OpenJDK since 2011 and has eight > changesets attributed directly to him and several other contributions > that were made but not formally acknowledged: > > * changesets: > 1. 7015169: GC Cause not always set > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c798c277ddd1 > 2. 8011934: sun.misc.PerfCounter calls Perf.createLong with > incorrect parameters > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/3b81fac25d26 > 3. 6989981: jstack causes "fatal error: ExceptionMark destructor > expects no pending exceptions" > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8ddc26f62476 > 4. 7090324: gclog rotation via external tool > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b5748753ad2f > 5. 8017773: OpenJDK7 returns incorrect TrueType font metrics > http://hg.openjdk.java.net/jdk9/client/jdk/rev/2559e1d816ae > 6. 8057556: JDP should better handle non-active interfaces > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a1afd6e36f0 > 7. 8057746: Cannot handle JdpException in JMX agent initialization. > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/37ac8a27a427 > 8. 8059586: hs_err report should treat redirected core pattern > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/30ed7423ae23 > > * Other contribution (Not attributed in changeset) > - JDK-7003789: PTRACE_GETREGS problems with SA on Linux. > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2010-December/003081.html > > - JDK-7044285: 64 bit VM crashes in > Java_sun_java2d_loops_MaskFill_MaskFill > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-June/002233.html > > - JDK-7133122: SA throws > sun.jvm.hotspot.debugger.UnmappedAddressException when it should not > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-September/011737.html > > - JDK-7186278: Build error after CR#6995781 / 7151532 with GCC 4.7.0 > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-July/004153.html > > - JDK-8004898: library_call.cpp build error after 7172640 with GCC > 4.7.2 > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009116.html > > - JDK-8027059: (sctp) fatal warnings overly restrictive with gcc > 4.8.1 > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018791.html > > > Votes are due by 15:00 Friday January 2, 2015 (Australian Eastern > Standard Time). > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From jaroslav.bachorik at oracle.com Fri Dec 19 16:32:12 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Fri, 19 Dec 2014 17:32:12 +0100 Subject: CFV: New JDK 9 Committer: Yasumasa Suenaga In-Reply-To: <5493B0DE.3090702@oracle.com> References: <5493B0DE.3090702@oracle.com> Message-ID: <5494530C.60409@oracle.com> Vote: yes -JB- On 12/19/2014 06:00 AM, David Holmes wrote: > I hereby nominate Yasumasa Suenaga to JDK 9 Committer. > > He has been contributing to OpenJDK since 2011 and has eight changesets > attributed directly to him and several other contributions that were > made but not formally acknowledged: > > * changesets: > 1. 7015169: GC Cause not always set > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c798c277ddd1 > 2. 8011934: sun.misc.PerfCounter calls Perf.createLong with > incorrect parameters > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/3b81fac25d26 > 3. 6989981: jstack causes "fatal error: ExceptionMark destructor > expects no pending exceptions" > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8ddc26f62476 > 4. 7090324: gclog rotation via external tool > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b5748753ad2f > 5. 8017773: OpenJDK7 returns incorrect TrueType font metrics > http://hg.openjdk.java.net/jdk9/client/jdk/rev/2559e1d816ae > 6. 8057556: JDP should better handle non-active interfaces > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a1afd6e36f0 > 7. 8057746: Cannot handle JdpException in JMX agent initialization. > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/37ac8a27a427 > 8. 8059586: hs_err report should treat redirected core pattern > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/30ed7423ae23 > > * Other contribution (Not attributed in changeset) > - JDK-7003789: PTRACE_GETREGS problems with SA on Linux. > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2010-December/003081.html > > - JDK-7044285: 64 bit VM crashes in > Java_sun_java2d_loops_MaskFill_MaskFill > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-June/002233.html > > - JDK-7133122: SA throws > sun.jvm.hotspot.debugger.UnmappedAddressException when it should not > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-September/011737.html > > - JDK-7186278: Build error after CR#6995781 / 7151532 with GCC 4.7.0 > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-July/004153.html > > - JDK-8004898: library_call.cpp build error after 7172640 with GCC > 4.7.2 > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009116.html > > - JDK-8027059: (sctp) fatal warnings overly restrictive with gcc 4.8.1 > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018791.html > > Votes are due by 15:00 Friday January 2, 2015 (Australian Eastern > Standard Time). > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From yumin.qi at oracle.com Fri Dec 19 18:15:40 2014 From: yumin.qi at oracle.com (Yumin Qi) Date: Fri, 19 Dec 2014 10:15:40 -0800 Subject: CFV: New JDK 9 Committer: Yasumasa Suenaga In-Reply-To: <5493B0DE.3090702@oracle.com> References: <5493B0DE.3090702@oracle.com> Message-ID: <54946B4C.1040503@oracle.com> Vote: Yes On 12/18/2014 9:00 PM, David Holmes wrote: > I hereby nominate Yasumasa Suenaga to JDK 9 Committer. > > He has been contributing to OpenJDK since 2011 and has eight > changesets attributed directly to him and several other contributions > that were made but not formally acknowledged: > > * changesets: > 1. 7015169: GC Cause not always set > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c798c277ddd1 > 2. 8011934: sun.misc.PerfCounter calls Perf.createLong with > incorrect parameters > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/3b81fac25d26 > 3. 6989981: jstack causes "fatal error: ExceptionMark destructor > expects no pending exceptions" > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8ddc26f62476 > 4. 7090324: gclog rotation via external tool > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b5748753ad2f > 5. 8017773: OpenJDK7 returns incorrect TrueType font metrics > http://hg.openjdk.java.net/jdk9/client/jdk/rev/2559e1d816ae > 6. 8057556: JDP should better handle non-active interfaces > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a1afd6e36f0 > 7. 8057746: Cannot handle JdpException in JMX agent initialization. > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/37ac8a27a427 > 8. 8059586: hs_err report should treat redirected core pattern > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/30ed7423ae23 > > * Other contribution (Not attributed in changeset) > - JDK-7003789: PTRACE_GETREGS problems with SA on Linux. > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2010-December/003081.html > > - JDK-7044285: 64 bit VM crashes in > Java_sun_java2d_loops_MaskFill_MaskFill > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-June/002233.html > > - JDK-7133122: SA throws > sun.jvm.hotspot.debugger.UnmappedAddressException when it should not > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-September/011737.html > > - JDK-7186278: Build error after CR#6995781 / 7151532 with GCC 4.7.0 > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-July/004153.html > > - JDK-8004898: library_call.cpp build error after 7172640 with GCC > 4.7.2 > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009116.html > > - JDK-8027059: (sctp) fatal warnings overly restrictive with gcc > 4.8.1 > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018791.html > > > Votes are due by 15:00 Friday January 2, 2015 (Australian Eastern > Standard Time). > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From serguei.spitsyn at oracle.com Fri Dec 19 20:59:04 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 19 Dec 2014 12:59:04 -0800 Subject: CFV: New JDK 9 Committer: Yasumasa Suenaga In-Reply-To: <5493B0DE.3090702@oracle.com> References: <5493B0DE.3090702@oracle.com> Message-ID: <54949198.70603@oracle.com> Vote: yes On 12/18/14 9:00 PM, David Holmes wrote: > I hereby nominate Yasumasa Suenaga to JDK 9 Committer. > > He has been contributing to OpenJDK since 2011 and has eight > changesets attributed directly to him and several other contributions > that were made but not formally acknowledged: > > * changesets: > 1. 7015169: GC Cause not always set > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c798c277ddd1 > 2. 8011934: sun.misc.PerfCounter calls Perf.createLong with > incorrect parameters > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/3b81fac25d26 > 3. 6989981: jstack causes "fatal error: ExceptionMark destructor > expects no pending exceptions" > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8ddc26f62476 > 4. 7090324: gclog rotation via external tool > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b5748753ad2f > 5. 8017773: OpenJDK7 returns incorrect TrueType font metrics > http://hg.openjdk.java.net/jdk9/client/jdk/rev/2559e1d816ae > 6. 8057556: JDP should better handle non-active interfaces > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a1afd6e36f0 > 7. 8057746: Cannot handle JdpException in JMX agent initialization. > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/37ac8a27a427 > 8. 8059586: hs_err report should treat redirected core pattern > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/30ed7423ae23 > > * Other contribution (Not attributed in changeset) > - JDK-7003789: PTRACE_GETREGS problems with SA on Linux. > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2010-December/003081.html > > - JDK-7044285: 64 bit VM crashes in > Java_sun_java2d_loops_MaskFill_MaskFill > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-June/002233.html > > - JDK-7133122: SA throws > sun.jvm.hotspot.debugger.UnmappedAddressException when it should not > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-September/011737.html > > - JDK-7186278: Build error after CR#6995781 / 7151532 with GCC 4.7.0 > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-July/004153.html > > - JDK-8004898: library_call.cpp build error after 7172640 with GCC > 4.7.2 > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009116.html > > - JDK-8027059: (sctp) fatal warnings overly restrictive with gcc > 4.8.1 > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018791.html > > > Votes are due by 15:00 Friday January 2, 2015 (Australian Eastern > Standard Time). > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote From dmitry.samersoff at oracle.com Fri Dec 19 21:45:29 2014 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 20 Dec 2014 00:45:29 +0300 Subject: CFV: New JDK 9 Committer: Yasumasa Suenaga In-Reply-To: <5493B0DE.3090702@oracle.com> References: <5493B0DE.3090702@oracle.com> Message-ID: <54949C79.5020408@oracle.com> Vote: Yes On 2014-12-19 08:00, David Holmes wrote: > I hereby nominate Yasumasa Suenaga to JDK 9 Committer. > > He has been contributing to OpenJDK since 2011 and has eight changesets > attributed directly to him and several other contributions that were > made but not formally acknowledged: > > * changesets: > 1. 7015169: GC Cause not always set > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c798c277ddd1 > 2. 8011934: sun.misc.PerfCounter calls Perf.createLong with > incorrect parameters > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/3b81fac25d26 > 3. 6989981: jstack causes "fatal error: ExceptionMark destructor > expects no pending exceptions" > http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/8ddc26f62476 > 4. 7090324: gclog rotation via external tool > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/b5748753ad2f > 5. 8017773: OpenJDK7 returns incorrect TrueType font metrics > http://hg.openjdk.java.net/jdk9/client/jdk/rev/2559e1d816ae > 6. 8057556: JDP should better handle non-active interfaces > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a1afd6e36f0 > 7. 8057746: Cannot handle JdpException in JMX agent initialization. > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/37ac8a27a427 > 8. 8059586: hs_err report should treat redirected core pattern > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/30ed7423ae23 > > * Other contribution (Not attributed in changeset) > - JDK-7003789: PTRACE_GETREGS problems with SA on Linux. > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2010-December/003081.html > > - JDK-7044285: 64 bit VM crashes in > Java_sun_java2d_loops_MaskFill_MaskFill > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2011-June/002233.html > > - JDK-7133122: SA throws > sun.jvm.hotspot.debugger.UnmappedAddressException when it should not > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-September/011737.html > > - JDK-7186278: Build error after CR#6995781 / 7151532 with GCC 4.7.0 > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2012-July/004153.html > > - JDK-8004898: library_call.cpp build error after 7172640 with GCC > 4.7.2 > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-December/009116.html > > - JDK-8027059: (sctp) fatal warnings overly restrictive with gcc 4.8.1 > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-July/018791.html > > Votes are due by 15:00 Friday January 2, 2015 (Australian Eastern > Standard Time). > > Only current JDK 9 Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > David Holmes > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From rodionef at cs.helsinki.fi Sun Dec 21 10:13:09 2014 From: rodionef at cs.helsinki.fi (Rodion Efremov) Date: Sun, 21 Dec 2014 10:13:09 +0000 Subject: A parallel integer sort for parallel arrays? Message-ID: <14fde5cf5347230fca14f31fbcf527a8@webmail.cs.helsinki.fi> Hello, everybody! I am new to Open JDK and have no clue regarding the way developers communicate within this project so bare with me. However, I have this parallel MSD radix sort for parallel arrays with long keys at https://github.com/coderodde/parallelsort It systematically beats java.util.Arrays.parallelSort by factor of 4 on dual-core machine. So my question boils down to following: Is there a need for such a sorting routine in JDK 9? -TIA, Rodion From omajid at redhat.com Mon Dec 22 14:25:48 2014 From: omajid at redhat.com (Omair Majid) Date: Mon, 22 Dec 2014 09:25:48 -0500 Subject: CFV: New JDK 9 Committer: Yasumasa Suenaga In-Reply-To: <5493B0DE.3090702@oracle.com> References: <5493B0DE.3090702@oracle.com> Message-ID: <20141222142547.GA7536@redhat.com> Vote: Yes * David Holmes [2014-12-19 00:00]: > I hereby nominate Yasumasa Suenaga to JDK 9 Committer. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From sean.coffey at oracle.com Mon Dec 22 15:42:39 2014 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Mon, 22 Dec 2014 15:42:39 +0000 Subject: Result: New JDK 9 Reviewer: Ivan Gerasimov Message-ID: <54983BEF.7010807@oracle.com> Voting for Ivan Gerasimov [1] is now closed. Yes: 22 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Regards, Sean. [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-December/001677.html From alejandro.murillo at oracle.com Mon Dec 22 19:03:17 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 22 Dec 2014 12:03:17 -0700 Subject: CFV: New JDK 9 Committer: Yasumasa Suenaga In-Reply-To: <5493B0DE.3090702@oracle.com> References: <5493B0DE.3090702@oracle.com> Message-ID: <54986AF5.3040101@oracle.com> vote: yes On 12/18/2014 10:00 PM, David Holmes wrote: > I hereby nominate Yasumasa Suenaga to JDK 9 Committer. -- Alejandro From ivan.gerasimov at oracle.com Tue Dec 23 07:15:37 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 23 Dec 2014 10:15:37 +0300 Subject: Result: New JDK 9 Reviewer: Ivan Gerasimov In-Reply-To: <54983BEF.7010807@oracle.com> References: <54983BEF.7010807@oracle.com> Message-ID: <54991699.10707@oracle.com> Thanks everyone! :) Sincerely yours, Ivan On 22.12.2014 18:42, Se?n Coffey wrote: > Voting for Ivan Gerasimov [1] is now closed. > > Yes: 22 > Veto: 0 > Abstain: 0 > > According to the Bylaws definition of Three-Vote Consensus, this is > sufficient to approve the nomination. > > Regards, > Sean. > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-December/001677.html > > From Sergey.Bylokhov at oracle.com Tue Dec 23 13:00:53 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 23 Dec 2014 16:00:53 +0300 Subject: CFV: New jdk9 Reviewer: Alexander Zvegintsev Message-ID: <54996785.4090900@oracle.com> I hereby nominate Alexander Zvegintsev (OpenJDK user name: azvegint) to JDK9 Reviewer. Alexander is currently a JDK9 Committer and a member of AWT/Swing and JavaFX teams at Oracle. Here is the list of fixes(41 fix): http://hg.openjdk.java.net/jdk9/client/jdk/log?revcount=300&rev=alexander.zvegintsev%40oracle.com http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=azvegint&revcount=200 Votes are due by 17:00 PM CEST, January 6, 2015. Only current jdk9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote -- Best regards, Sergey. From vladimir.x.ivanov at oracle.com Tue Dec 23 13:04:01 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 23 Dec 2014 16:04:01 +0300 Subject: CFV: New jdk9 Reviewer: Alexander Zvegintsev In-Reply-To: <54996785.4090900@oracle.com> References: <54996785.4090900@oracle.com> Message-ID: <54996841.3020605@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 12/23/14 4:00 PM, Sergey Bylokhov wrote: > I hereby nominate Alexander Zvegintsev (OpenJDK user name: azvegint) to > JDK9 Reviewer. > > Alexander is currently a JDK9 Committer and a member of AWT/Swing and > JavaFX teams at Oracle. > > Here is the list of fixes(41 fix): > http://hg.openjdk.java.net/jdk9/client/jdk/log?revcount=300&rev=alexander.zvegintsev%40oracle.com > > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=azvegint&revcount=200 > > > Votes are due by 17:00 PM CEST, January 6, 2015. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From yuri.nesterenko at oracle.com Tue Dec 23 14:29:52 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Tue, 23 Dec 2014 17:29:52 +0300 Subject: CFV: New jdk9 Reviewer: Alexander Zvegintsev In-Reply-To: <54996785.4090900@oracle.com> References: <54996785.4090900@oracle.com> Message-ID: <54997C60.6070605@oracle.com> Vote: yes -yan On 12/23/2014 04:00 PM, Sergey Bylokhov wrote: > I hereby nominate Alexander Zvegintsev (OpenJDK user name: azvegint) to > JDK9 Reviewer. > > Alexander is currently a JDK9 Committer and a member of AWT/Swing and > JavaFX teams at Oracle. > > Here is the list of fixes(41 fix): > http://hg.openjdk.java.net/jdk9/client/jdk/log?revcount=300&rev=alexander.zvegintsev%40oracle.com > > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=azvegint&revcount=200 > > > Votes are due by 17:00 PM CEST, January 6, 2015. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From alejandro.murillo at oracle.com Tue Dec 23 19:21:06 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 23 Dec 2014 12:21:06 -0700 Subject: jdk9-dev: HotSpot Message-ID: <5499C0A1.30109@oracle.com> jdk9-hs2-2014-12-19 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/3bbadbebbf4f http://hg.openjdk.java.net/jdk9/dev/corba/rev/9645e35616b6 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/86ba9eb66d03 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/f6b83b15628f http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/edc13d27dc87 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b00419e9c9b6 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/20475c78a0a6 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/5f6a840fc19d Component : VM Status : Go for integration Date : 22/12/2014 at 19:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2014-12-20-010712.amurillo.jdk9-hs2-2014-12-19-snapshot Testing: 254 new failures, 3733 known failures, 351601 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 8028773: warnings from b116 for hotspot.agent.src.share.native: JNI exception pending 8034263: Test java/lang/management/MemoryMXBean/LowMemoryTest.java fails intermittently 8042418: Remove JVM_FindClassFromClassLoader 8047290: Make Mutex::_no_safepoint_check_flag locks verify that this lock never checks for safepoint 8059586: hs_err report should treat redirected core pattern 8064319: Need to enable -XX:+TraceExceptions in release builds 8064909: FragmentMetaspace.java got OutOfMemoryError 8066143: [TESTBUG] New tests in gc/survivorAlignment/ fails 8066442: Add PS and ParOld support for promotion event 8066803: compiler/intrinsics/mathexact/SubExactINonConstantTest.java crashed in os::is_first_C_frame(frame*) 8066822: Remove PSMarkSweep::set_reference_processor 8066862: TestMutuallyExclusivePlatformPredicates fails on all platforms 8066863: bigapps/runThese/nowarnings fails: Java HotSpot(TM) 64-Bit Server VM warning: WaitForMultipleObjects 8067115: Add jtreg gc tests to Hotspot JPRT jobs 8067366: Allow java.{endorsed,ext}.dirs property be set to empty string 8067452: Rename hotspot_all in hotspot/test/TEST.groups -- Alejandro From volker.simonis at gmail.com Tue Dec 23 19:31:51 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 Dec 2014 20:31:51 +0100 Subject: CFV: New jdk9 Reviewer: Alexander Zvegintsev In-Reply-To: <54996785.4090900@oracle.com> References: <54996785.4090900@oracle.com> Message-ID: Vote: yes Best regards, Volker On Tue, Dec 23, 2014 at 2:00 PM, Sergey Bylokhov wrote: > I hereby nominate Alexander Zvegintsev (OpenJDK user name: azvegint) to JDK9 > Reviewer. > > Alexander is currently a JDK9 Committer and a member of AWT/Swing and JavaFX > teams at Oracle. > > Here is the list of fixes(41 fix): > http://hg.openjdk.java.net/jdk9/client/jdk/log?revcount=300&rev=alexander.zvegintsev%40oracle.com > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=azvegint&revcount=200 > > Votes are due by 17:00 PM CEST, January 6, 2015. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > -- > Best regards, Sergey. > From lana.steuck at oracle.com Wed Dec 24 00:04:48 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 23 Dec 2014 16:04:48 -0800 (PST) Subject: jdk9-b44: dev Message-ID: <201412240004.sBO04mtU007775@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/8994f5d87b3b http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/50ee57606272 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/de2ce70d907c http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8cc4dc300041 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/2a03baa4d849 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/0cb0844b5892 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/43a44b56dca6 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/1f57bd728c9e --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8066142 client-libs closed/javax/swing/JComboBox/4212498/bug4212498.java:Edit the value in the text field and then press.. JDK-8065098 client-libs JColorChooser no longer supports drag and drop between two JVM instances JDK-8064809 client-libs [TEST_BUG] javax/swing/JComboBox/4199622/bug4199622.java contains a lot of keyPress and not a single.. JDK-8064575 client-libs [TEST_BUG] javax/swing/JEditorPane/6917744/bug6917744.java 100 times press keys and never releases JDK-8064573 client-libs [TEST_BUG] javax/swing/text/AbstractDocument/6968363/Test6968363.java is asocial pressing VK_LEFT and JDK-8063107 client-libs Change open swing regression tests to avoid sun.awt.SunToolkit.realSync, part 2 JDK-8063104 client-libs Change open awt regression tests to avoid sun.awt.SunToolkit.realSync, part 2 JDK-8061832 client-libs J2DBench can be improved JDK-8059998 client-libs Broken link in java.awt.event Interface KeyListener JDK-8059944 client-libs [OGL] Metrics for a method choice copying of texture should be improved JDK-8059942 client-libs Default implementation of DrawImage.renderImageXform() should be improved for d3d/ogl JDK-8058193 client-libs [macosx] Potential incomplete fix for JDK-8031485 JDK-8055836 client-libs move awt tests from AWT_Modality to OpenJDK repository - part 9 JDK-8054359 client-libs move awt automated tests from AWT_Modality to OpenJDK repository - part 8 JDK-8054143 client-libs move awt automated tests from AWT_Modality to OpenJDK repository - part 6 JDK-8031696 client-libs [macosx] TwentyThousandTest test failed with OOM JDK-8029536 client-libs JFileChooser filter uses .toString() instead of getDescription() for filter text on GTK laf JDK-8024626 client-libs CTW CRASH: SIGSEGV in ctw/jre/lib/rt_jar/preloading_1 and ctw/jre/lib/rt_jar/sun_awt_X11_ListHelper JDK-6345095 client-libs regression test EmptyClipRenderingTest fails JDK-8067904 core-libs Additional DriverManager clean-up from 8060068 JDK-8067870 core-libs Fix java.io.ObjectInputStream.PeekInputStream#skip JDK-8067854 core-libs bound java static method throws NPE when 'null' is used for this argument JDK-8067777 core-libs NetBeans nashorn debug target is broken. Nashorn source directory config. is wrong JDK-8067774 core-libs Local variable type calculation mismatch JDK-8067636 core-libs ant javadoc target is broken JDK-8067486 core-libs Add diagnostics for Exception: Read from closed pipe hangs JDK-8067420 core-libs BrowserJSObjectLinker should give priority to beans linker for property get/set JDK-8067377 core-libs My hobby: caning, then then canning, the the can-can JDK-8067289 core-libs Fix deprecation warnings in java.base module - CRC32C JDK-8067112 core-libs Update java/util/Collections/EmptyIterator.java to eliminate dependency on sun.tools.java JDK-8066867 core-libs Add InputStream transferTo to transfer content to an OutputStream JDK-8066642 core-libs Fix deprecation warnings in jdk.naming module JDK-8066633 core-libs Fix deprecation warnings in java.rmi module JDK-8066612 core-libs Add a test that will call getDeclaredFields() on all classes and try to set them accessible. JDK-8066226 core-libs Fuzzing bug: parameter counts differ in TypeConverterFactory JDK-8066215 core-libs Fuzzing bug: length valueOf bug JDK-8065804 core-libs JEP 171: Clarifications/corrections for fence intrinsics JDK-8065172 core-libs More core reflection final and volatile annotations JDK-8062588 core-libs Support java.util.spi.*, java.text.spi.*, java.awt.im.spi loaded from classpath JDK-8062030 core-libs Nashorn bug retrieving array property after key string concatenation JDK-8056238 core-libs (process) ProcessBuilder.redirectError spec has a broken link JDK-8051641 core-libs Africa/Casablanca transitions is incorrectly calculated starting from 2027 JDK-8035117 core-libs TEST_BUG: java/rmi/server/RemoteObject/notExtending/NotExtending.java can fail with timeout JDK-8025619 core-libs (fc) FileInputStream.getChannel on closed stream returns FileChannel that doesn't know that stream is closed JDK-8067241 core-svc DeadlockTest.java failed with negative timeout value JDK-8066952 core-svc [TEST-BUG] javax/management/monitor/CounterMonitorTest.java hangs JDK-8064441 core-svc java/lang/management/ThreadMXBean/Locks.java fails intermittently, blocked on wrong object JDK-8044591 core-svc [TESTBUG] com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationp[Content]Test.java JDK-6618335 core-svc ThreadReference.stop(null) throws NPE instead of InvalidTypeException JDK-6364329 core-svc jstat displays "invalid argument count" with usage JDK-8066546 deploy miss dependency on ant target "compile-driver" when just running liveconnect suite for plugin manual o JDK-8066447 deploy 8u40: URL.openConnection fails with exception if "use browser settings" is set and browser itself uses JDK-8064358 deploy JnlpxArgs NullPointerException JDK-8057671 deploy unable to find nativelib on windows when case-sensitivity mismatch JDK-8039007 deploy jdeps incorrectly reports javax.jnlp as JDK internal APIs JDK-8067144 hotspot SIGSEGV with +TraceDeoptimization in Deoptimization::print_objects JDK-8066900 hotspot Array Out Of Bounds Exception causes variable corruption JDK-8066782 hotspot Move common code from CMSGeneration and TenuredGeneration to CardGeneration JDK-8066781 hotspot Minor cleanups to TenuredGeneration JDK-8066780 hotspot Split CardGeneration out to its own file JDK-8066775 hotspot opto/node.hpp:355, assert(i < _max) failed: oob: i=1, _max=1 JDK-8066670 hotspot -XX:+PrintSharedArchiveAndExit does not exit the VM when the archive is invalid JDK-8066508 hotspot JTReg tests timeout on slow devices when run using JPRT JDK-8066441 hotspot Add PLAB trace event JDK-8066250 hotspot compiler/dependencies/MonomorphicObjectCall/TestMonomorphicObjectCall.java fails product JDK-8066171 hotspot Out of order with Metaspace allocation lock JDK-8066103 hotspot C2's range check smearing allows out of bound array accesses JDK-8066102 hotspot Clean up HeapRegionRemSet files JDK-8065788 hotspot os::reserve_memory() on Windows should not assert that allocation size is aligned to OS allocation gra JDK-8065634 hotspot Crash in InstanceKlass::clean_method_data when _method is NULL JDK-8065134 hotspot Need WhiteBox::allocateCodeBlob(long, int) method to be implemented JDK-8065050 hotspot vm crashes during CDS dump when very small SharedMiscDataSize is specified JDK-8061785 hotspot [TEST_BUG] serviceability/sa/jmap-hashcode/Test8028623.java has utf8 character corrupted by earlier merge JDK-8059595 hotspot Verifier::verify is wasting time before is_eligible_for_verification check JDK-8059066 hotspot CardTableModRefBS might commit the same page twice JDK-8038468 hotspot java/lang/instrument/ParallelTransformerLoader.sh fails with ClassCircularityError JDK-6898462 hotspot The escape analysis with G1 cause crash assertion src/share/vm/runtime/vframeArray.cpp:94 JDK-6762191 hotspot Setting stack size to 16K causes segmentation fault JDK-6522873 hotspot Java not print "Unrecognized option" when it is invalid option. JDK-8067898 infrastructure Disable verify-modules until JDK-8067479 is resolved JDK-8067829 infrastructure Remove setting -bootclasspath $(JDK_OUTPUTDIR)/classes from Javadoc.gmk JDK-8067631 infrastructure hgforest.sh mishandles arguments with spaces JDK-8067442 infrastructure Tests using -Xshare:dump does not work with 'make test' JDK-8067330 infrastructure ZERO_ARCHDEF incorrectly defined for PPC/PPC64 architectures JDK-8066138 infrastructure Trailing whitespace in title of javadoc: "Overview (Java Platform SE 7 )" JDK-8065940 install not compressing the non-english msi's will speed up the build JDK-8062407 install jucheck incorrectly uses cached iftw-au.exe if already present in %TEMP% JDK-8067091 security-libs Suppress Windows-specific deprecation warnings in the jdk.crypto.mscapi module JDK-8067088 security-libs Suppress solaris-specific deprecation warnings in the jdk.crypto.ucrypto module JDK-8062170 security-libs java.security.ProviderException: Error parsing configuration with space JDK-8048819 security-libs Implement reliability test for DH algorithm JDK-8067792 tools Javac crashes in finder mode with nested implicit lambdas JDK-8067663 tools Add bugId to tests that have been modified as part of JDK-8064365 JDK-8067422 tools Lambda method names are unnecessarily unstable JDK-8067411 tools tools/launcher/MultipleJRE.sh requires adjustments to work with module boundaries JDK-8067384 tools Facilitate extension of the javac parser JDK-8067360 tools verify-modules target was dropped in jdk9 b41 JDK-8067290 tools Missing bug id in test/tools/launcher/* JDK-8066974 tools Compiler doesn't infer method's generic type information in lambda body JDK-8066808 tools langtools/test/Makefile should not use OS-specific jtreg binary JDK-8066807 tools langtools/test/Makefile should use -agentvm not -samevm JDK-8064365 tools Better support for finder capabilities in target-typing context JDK-8061442 tools Update jdk/tools tests to remove check for the "jre" directory Note: the list does not include confidential fixes. From alexandr.scherbatiy at oracle.com Wed Dec 24 08:57:50 2014 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 24 Dec 2014 11:57:50 +0300 Subject: CFV: New jdk9 Reviewer: Alexander Zvegintsev In-Reply-To: <54996785.4090900@oracle.com> References: <54996785.4090900@oracle.com> Message-ID: <549A800E.2020102@oracle.com> Vote: yes. Thanks, Alexandr. On 12/23/2014 4:00 PM, Sergey Bylokhov wrote: > I hereby nominate Alexander Zvegintsev (OpenJDK user name: azvegint) > to JDK9 Reviewer. > > Alexander is currently a JDK9 Committer and a member of AWT/Swing and > JavaFX teams at Oracle. > > Here is the list of fixes(41 fix): > http://hg.openjdk.java.net/jdk9/client/jdk/log?revcount=300&rev=alexander.zvegintsev%40oracle.com > > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=azvegint&revcount=200 > > > Votes are due by 17:00 PM CEST, January 6, 2015. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From anton.tarasov at oracle.com Wed Dec 24 09:16:34 2014 From: anton.tarasov at oracle.com (Anton V. Tarasov) Date: Wed, 24 Dec 2014 12:16:34 +0300 Subject: CFV: New jdk9 Reviewer: Alexander Zvegintsev In-Reply-To: <54996785.4090900@oracle.com> References: <54996785.4090900@oracle.com> Message-ID: <549A8472.9020405@oracle.com> Vote: YES Anton. On 23.12.2014 16:00, Sergey Bylokhov wrote: > I hereby nominate Alexander Zvegintsev (OpenJDK user name: azvegint) to JDK9 Reviewer. > > Alexander is currently a JDK9 Committer and a member of AWT/Swing and JavaFX teams at Oracle. > > Here is the list of fixes(41 fix): > http://hg.openjdk.java.net/jdk9/client/jdk/log?revcount=300&rev=alexander.zvegintsev%40oracle.com > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=azvegint&revcount=200 > > Votes are due by 17:00 PM CEST, January 6, 2015. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From alexander.zuev at oracle.com Wed Dec 24 12:22:52 2014 From: alexander.zuev at oracle.com (Alexander Zuev) Date: Wed, 24 Dec 2014 16:22:52 +0400 Subject: CFV: New jdk9 Reviewer: Alexander Zvegintsev In-Reply-To: <54996785.4090900@oracle.com> References: <54996785.4090900@oracle.com> Message-ID: <549AB01C.1090205@oracle.com> Vote: yes On 12/23/14 17:00, Sergey Bylokhov wrote: > I hereby nominate Alexander Zvegintsev (OpenJDK user name: azvegint) > to JDK9 Reviewer. > > Alexander is currently a JDK9 Committer and a member of AWT/Swing and > JavaFX teams at Oracle. > > Here is the list of fixes(41 fix): > http://hg.openjdk.java.net/jdk9/client/jdk/log?revcount=300&rev=alexander.zvegintsev%40oracle.com > > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=azvegint&revcount=200 > > > Votes are due by 17:00 PM CEST, January 6, 2015. > > Only current jdk9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From igor.ignatyev at oracle.com Thu Dec 25 09:17:33 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 25 Dec 2014 12:17:33 +0300 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin Message-ID: <549BD62D.8000308@oracle.com> I hereby nominate Filipp Zhinkin (fzhinkin) to JDK 9 Committer. Filipp Zhinkin is a member of STT group. He has contributed 21 changesets to JDK 9[1]. Votes are due by 1300 MSK (UTC+3), January 8, 2015. Only current JDK 9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. -- Igor [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/d536758aa7bb http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3c17077e9882 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/94df826bd8ec http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c196aca52cab http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4d1463933e28 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/676f67452a76 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/846fc505810a http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a274904ceb95 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4f55d92a7b97 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0705d38e2d50 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1eb404df2268 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/140b7b205a04 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/835010e4380c http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/aabca16ccbca http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3c9c3ba62dfd http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1a5ba18a35c8 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0f44d1eb81f5 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/d519bb4b9d11 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/15d507abfc7a http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f765bfec8f07 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ccc57295818b [2] http://openjdk.java.net/census [3] http://openjdk.java.net/projects/#committer-vote From igor.ignatyev at oracle.com Thu Dec 25 09:25:57 2014 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 25 Dec 2014 12:25:57 +0300 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin In-Reply-To: <549BD62D.8000308@oracle.com> References: <549BD62D.8000308@oracle.com> Message-ID: <549BD825.4060506@oracle.com> vote: yes Igor On 12/25/2014 12:17 PM, Igor Ignatyev wrote: > I hereby nominate Filipp Zhinkin (fzhinkin) to JDK 9 Committer. > > Filipp Zhinkin is a member of STT group. He has contributed 21 > changesets to JDK 9[1]. > > Votes are due by 1300 MSK (UTC+3), January 8, 2015. > > Only current JDK 9 Committers [2] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. From andrei.eremeev at oracle.com Thu Dec 25 09:29:26 2014 From: andrei.eremeev at oracle.com (andrei.eremeev) Date: Thu, 25 Dec 2014 12:29:26 +0300 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin In-Reply-To: <549BD62D.8000308@oracle.com> References: <549BD62D.8000308@oracle.com> Message-ID: <549BD8F6.4010302@oracle.com> Vote: yes Andrei Eremeev On 12/25/2014 12:17 PM, Igor Ignatyev wrote: > I hereby nominate Filipp Zhinkin (fzhinkin) to JDK 9 Committer. > > Filipp Zhinkin is a member of STT group. He has contributed 21 > changesets to JDK 9[1]. > > Votes are due by 1300 MSK (UTC+3), January 8, 2015. > > Only current JDK 9 Committers [2] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. From Sergey.Bylokhov at oracle.com Thu Dec 25 11:14:14 2014 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 25 Dec 2014 14:14:14 +0300 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin In-Reply-To: <549BD62D.8000308@oracle.com> References: <549BD62D.8000308@oracle.com> Message-ID: <549BF186.5080901@oracle.com> Vote: yes On 25.12.2014 12:17, Igor Ignatyev wrote: > I hereby nominate Filipp Zhinkin (fzhinkin) to JDK 9 Committer. > > Filipp Zhinkin is a member of STT group. He has contributed 21 > changesets to JDK 9[1]. > > Votes are due by 1300 MSK (UTC+3), January 8, 2015. > > Only current JDK 9 Committers [2] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. -- Best regards, Sergey. From yuri.nesterenko at oracle.com Thu Dec 25 11:36:33 2014 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 25 Dec 2014 14:36:33 +0300 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin In-Reply-To: <549BD62D.8000308@oracle.com> References: <549BD62D.8000308@oracle.com> Message-ID: <549BF6C1.1000404@oracle.com> Vote: yes -yan On 12/25/2014 12:17 PM, Igor Ignatyev wrote: > I hereby nominate Filipp Zhinkin (fzhinkin) to JDK 9 Committer. > > Filipp Zhinkin is a member of STT group. He has contributed 21 > changesets to JDK 9[1]. > > Votes are due by 1300 MSK (UTC+3), January 8, 2015. > > Only current JDK 9 Committers [2] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. From alexander.zvegintsev at oracle.com Thu Dec 25 12:42:07 2014 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Thu, 25 Dec 2014 15:42:07 +0300 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin In-Reply-To: <549BD62D.8000308@oracle.com> References: <549BD62D.8000308@oracle.com> Message-ID: <549C061F.5070608@oracle.com> Vote: yes -- Thanks, Alexander. 25.12.2014 12:17, Igor Ignatyev ?????: > I hereby nominate Filipp Zhinkin (fzhinkin) to JDK 9 Committer. > > Filipp Zhinkin is a member of STT group. He has contributed 21 > changesets to JDK 9[1]. > > Votes are due by 1300 MSK (UTC+3), January 8, 2015. > > Only current JDK 9 Committers [2] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. From vladimir.x.ivanov at oracle.com Thu Dec 25 13:25:44 2014 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 25 Dec 2014 16:25:44 +0300 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin In-Reply-To: <549BD62D.8000308@oracle.com> References: <549BD62D.8000308@oracle.com> Message-ID: <549C1058.7080800@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 12/25/14 12:17 PM, Igor Ignatyev wrote: > I hereby nominate Filipp Zhinkin (fzhinkin) to JDK 9 Committer. > > Filipp Zhinkin is a member of STT group. He has contributed 21 > changesets to JDK 9[1]. > > Votes are due by 1300 MSK (UTC+3), January 8, 2015. > > Only current JDK 9 Committers [2] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. From serguei.spitsyn at oracle.com Fri Dec 26 07:55:06 2014 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 25 Dec 2014 23:55:06 -0800 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin In-Reply-To: <549BD62D.8000308@oracle.com> References: <549BD62D.8000308@oracle.com> Message-ID: <549D145A.4010305@oracle.com> Vote: yes On 12/25/14 1:17 AM, Igor Ignatyev wrote: > I hereby nominate Filipp Zhinkin (fzhinkin) to JDK 9 Committer. > > Filipp Zhinkin is a member of STT group. He has contributed 21 > changesets to JDK 9[1]. > > Votes are due by 1300 MSK (UTC+3), January 8, 2015. > > Only current JDK 9 Committers [2] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. From ivan.gerasimov at oracle.com Fri Dec 26 08:06:14 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 26 Dec 2014 11:06:14 +0300 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin In-Reply-To: <549BD62D.8000308@oracle.com> References: <549BD62D.8000308@oracle.com> Message-ID: <549D16F6.9060206@oracle.com> Vote: Yes From vladimir.kozlov at oracle.com Fri Dec 26 19:32:39 2014 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 26 Dec 2014 11:32:39 -0800 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin In-Reply-To: <549BD62D.8000308@oracle.com> References: <549BD62D.8000308@oracle.com> Message-ID: <549DB7D7.5000701@oracle.com> Vote: yes On 12/25/14 1:17 AM, Igor Ignatyev wrote: > I hereby nominate Filipp Zhinkin (fzhinkin) to JDK 9 Committer. > > Filipp Zhinkin is a member of STT group. He has contributed 21 changesets to JDK 9[1]. > > Votes are due by 1300 MSK (UTC+3), January 8, 2015. > > Only current JDK 9 Committers [2] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. From volker.simonis at gmail.com Mon Dec 29 08:28:05 2014 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 29 Dec 2014 09:28:05 +0100 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin In-Reply-To: <549BD62D.8000308@oracle.com> References: <549BD62D.8000308@oracle.com> Message-ID: Vote: yes Regards, Volker PS: for all people outside Oracle - could you please explain what "STT group" stands for? On Thu, Dec 25, 2014 at 10:17 AM, Igor Ignatyev wrote: > I hereby nominate Filipp Zhinkin (fzhinkin) to JDK 9 Committer. > > Filipp Zhinkin is a member of STT group. He has contributed 21 changesets to > JDK 9[1]. > > Votes are due by 1300 MSK (UTC+3), January 8, 2015. > > Only current JDK 9 Committers [2] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > -- > Igor > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/d536758aa7bb > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3c17077e9882 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/94df826bd8ec > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/c196aca52cab > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4d1463933e28 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/676f67452a76 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/846fc505810a > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/a274904ceb95 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/4f55d92a7b97 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0705d38e2d50 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1eb404df2268 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/140b7b205a04 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/835010e4380c > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/aabca16ccbca > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/3c9c3ba62dfd > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/1a5ba18a35c8 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/0f44d1eb81f5 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/d519bb4b9d11 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/15d507abfc7a > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f765bfec8f07 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/ccc57295818b > [2] http://openjdk.java.net/census > [3] http://openjdk.java.net/projects/#committer-vote From jaroslav.bachorik at oracle.com Mon Dec 29 10:14:59 2014 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Mon, 29 Dec 2014 11:14:59 +0100 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin In-Reply-To: <549BD62D.8000308@oracle.com> References: <549BD62D.8000308@oracle.com> Message-ID: <54A129A3.4050606@oracle.com> Vote: yes -JB- On 25.12.2014 10:17, Igor Ignatyev wrote: > I hereby nominate Filipp Zhinkin (fzhinkin) to JDK 9 Committer. > > Filipp Zhinkin is a member of STT group. He has contributed 21 > changesets to JDK 9[1]. > > Votes are due by 1300 MSK (UTC+3), January 8, 2015. > > Only current JDK 9 Committers [2] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. From jon.masamitsu at oracle.com Mon Dec 29 15:17:43 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Mon, 29 Dec 2014 07:17:43 -0800 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin In-Reply-To: <549BD62D.8000308@oracle.com> References: <549BD62D.8000308@oracle.com> Message-ID: <54A17097.8040807@oracle.com> vote: yes On 12/25/2014 1:17 AM, Igor Ignatyev wrote: > I hereby nominate Filipp Zhinkin (fzhinkin) to JDK 9 Committer. > > Filipp Zhinkin is a member of STT group. He has contributed 21 > changesets to JDK 9[1]. > > Votes are due by 1300 MSK (UTC+3), January 8, 2015. > > Only current JDK 9 Committers [2] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. From joseph.provino at oracle.com Mon Dec 29 17:51:30 2014 From: joseph.provino at oracle.com (Joseph Provino) Date: Mon, 29 Dec 2014 12:51:30 -0500 Subject: Review request: Add barrier set kind for G1 throughput barrier Message-ID: <54A194A2.7040009@oracle.com> Can I get reviews for this very small change? I also need a sponsor to push the change. Bug report is here: https://bugs.openjdk.java.net/browse/JDK-8067191 Webrev is here: http://cr.openjdk.java.net/~jprovino/8067191/webrev.00 Testing: jprt From coleen.phillimore at oracle.com Mon Dec 29 20:12:38 2014 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 29 Dec 2014 15:12:38 -0500 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin In-Reply-To: <549BD62D.8000308@oracle.com> References: <549BD62D.8000308@oracle.com> Message-ID: <54A1B5B6.60807@oracle.com> Vote: yes On 12/25/14, 4:17 AM, Igor Ignatyev wrote: > I hereby nominate Filipp Zhinkin (fzhinkin) to JDK 9 Committer. > > Filipp Zhinkin is a member of STT group. He has contributed 21 > changesets to JDK 9[1]. > > Votes are due by 1300 MSK (UTC+3), January 8, 2015. > > Only current JDK 9 Committers [2] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. From aleksej.efimov at oracle.com Mon Dec 29 20:34:08 2014 From: aleksej.efimov at oracle.com (Aleksej Efimov) Date: Mon, 29 Dec 2014 23:34:08 +0300 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin In-Reply-To: <549BD62D.8000308@oracle.com> References: <549BD62D.8000308@oracle.com> Message-ID: <54A1BAC0.5000306@oracle.com> Vote: yes On 12/25/2014 12:17 PM, Igor Ignatyev wrote: > I hereby nominate Filipp Zhinkin (fzhinkin) to JDK 9 Committer. > > Filipp Zhinkin is a member of STT group. He has contributed 21 > changesets to JDK 9[1]. > > Votes are due by 1300 MSK (UTC+3), January 8, 2015. > > Only current JDK 9 Committers [2] are eligible to vote > on this nomination. Votes must be cast in the open by replying > to this mailing list. > > For Lazy Consensus voting instructions, see [3]. From aka.bash0r at gmail.com Tue Dec 30 07:53:13 2014 From: aka.bash0r at gmail.com (Nils Jonsson) Date: Tue, 30 Dec 2014 08:53:13 +0100 Subject: JVM struct types Message-ID: Hi everyone, I like the way how .NET handles managed to native interaction via struct like data types. This is a feature I am missing in the JVM. Even if I like the JVM more than .NET this is somewhat struggling with me. I'd like to contribute to the OpenJDK project and implement a similar feature in the JVM. What I am missing is how and where to start. Can somebody give me some guidance? Thanks in advance, Nils Jonsson From martijnverburg at gmail.com Tue Dec 30 10:17:37 2014 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 30 Dec 2014 10:17:37 +0000 Subject: JVM struct types In-Reply-To: References: Message-ID: Hi Nils, You'll want to join the project Valhalla mailing list where they are currently researching and discussing *possible* solutions to this. Cheers, Martijn On Tuesday, 30 December 2014, Nils Jonsson wrote: > Hi everyone, > > I like the way how .NET handles managed to native interaction via struct > like data types. This is a feature I am missing in the JVM. Even if I like > the JVM more than .NET this is somewhat struggling with me. I'd like to > contribute to the OpenJDK project and implement a similar feature in the > JVM. > > What I am missing is how and where to start. Can somebody give me some > guidance? > > Thanks in advance, > Nils Jonsson > -- Cheers, Martijn From jon.masamitsu at oracle.com Tue Dec 30 17:48:46 2014 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 30 Dec 2014 09:48:46 -0800 Subject: Review request: Add barrier set kind for G1 throughput barrier In-Reply-To: <54A194A2.7040009@oracle.com> References: <54A194A2.7040009@oracle.com> Message-ID: <54A2E57E.10902@oracle.com> Joe, Change looks good as long as the bug for this change is really https://bugs.openjdk.java.net/browse/JDK-8064947 Or maybe the webrev link is not right? Jon On 12/29/2014 09:51 AM, Joseph Provino wrote: > Can I get reviews for this very small change? I also need a sponsor > to push the change. > > Bug report is here: > > https://bugs.openjdk.java.net/browse/JDK-8067191 > > Webrev is here: > > http://cr.openjdk.java.net/~jprovino/8067191/webrev.00 > > Testing: jprt From joseph.provino at oracle.com Tue Dec 30 20:02:48 2014 From: joseph.provino at oracle.com (Joseph Provino) Date: Tue, 30 Dec 2014 15:02:48 -0500 Subject: Review request: Add barrier set kind for G1 throughput barrier In-Reply-To: <54A2E57E.10902@oracle.com> References: <54A194A2.7040009@oracle.com> <54A2E57E.10902@oracle.com> Message-ID: <54A304E8.6000508@oracle.com> Jon, you are right about the bug id being incorrect. I think to completely fix the problem described in the real bug report I also have to add a protected destructor to barrierSet.hpp. I'll submit to jprt then send another webrev with the right bug id. thanks. joe PS I'm planning to fix https://bugs.openjdk.java.net/browse/JDK-8067191 next. On 12/30/2014 12:48 PM, Jon Masamitsu wrote: > Joe, > > Change looks good as long as the bug for this change > is really > > https://bugs.openjdk.java.net/browse/JDK-8064947 > > Or maybe the webrev link is not right? > > Jon > > On 12/29/2014 09:51 AM, Joseph Provino wrote: >> Can I get reviews for this very small change? I also need a sponsor >> to push the change. >> >> Bug report is here: >> >> https://bugs.openjdk.java.net/browse/JDK-8067191 >> >> Webrev is here: >> >> http://cr.openjdk.java.net/~jprovino/8067191/webrev.00 >> >> Testing: jprt > From alejandro.murillo at oracle.com Tue Dec 30 22:23:55 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 30 Dec 2014 15:23:55 -0700 Subject: jdk9-dev: HotSpot Message-ID: <54A325FB.6040404@oracle.com> jdk9-hs2-2014-12-24 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/7063bdada583 http://hg.openjdk.java.net/jdk9/dev/corba/rev/9645e35616b6 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/91ff67f0a160 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/f6b83b15628f http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/edc13d27dc87 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/edd7a67585a5 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d442757afcdd http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/5f6a840fc19d Component : VM Status : Go for integration Date : 12/29/2014 at 20:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2014-12-24-181133.amurillo.jdk9-hs2-2014-12-24-snapshot Testing: 208 new failures, 4184 known failures, 367917 passed. Issues and Notes: No detailed analysis. No stoppers have been detected so far. Go for integration CRs for testing: 8028595: WhiteBox API for stress testing of TieredCompilation 8054892: Improve compiler's CLI tests error reporting 8059575: JEP-JDK-8043304: Test task: Tiered Compilation level transition tests 8060025: Object copy time regressions after JDK-8031323 and JDK-8057536 8061611: Remove deprecated command line flags 8065279: Remove testlibrary_tests from compact profile in jtreg 8066433: Move Whitebox test library to top level repository 8066473: Port timeout utils from jdk test library into hotspot 8066763: fatal error "assert(false) failed: unexpected yanked node" in postaloc.cpp:139 8066827: Remove ReferenceProcessor::clean_up_discovered_references() 8066964: ppc64: argument and return type profiling, fix problem with popframe 8067211: rewrite Utils::fileAsString 8067231: Zero builds fails after JDK-6898462 8067337: Remove Whitebox API from hotspot repository 8067338: compiler/debug/TraceIterativeGVN.java segfaults 8067438: Add test to verify minimal heap size 8067469: G1 ignores AlwaysPreTouch 8067499: G1SATBCardTableModRefBS should not inherit from CardTableModRefBSForCTRS 8067647: [TESTBUG] compiler/rangechecks/TestRangeCheckSmearing.java uses wrong path to Whitebox API 8067655: Clean up G1 remembered set oop iteration 8067823: CheckCompileThresholdScaling.java throws RuntimeException 8067865: Changes 8066780/8066782 broke the non-PCH build 8067873: gc/TestSmallHeap.java does not compile 8067972: Bring changes made to WhiteBox.java in 8047290 to that file new location in the top repo 8067985: merging hs-comp to hs blocked by some tests not updated in 8054892 8068036: assert(is_available(index)) failed in G1 cset -- Alejandro From alejandro.murillo at oracle.com Tue Dec 30 22:26:55 2014 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Tue, 30 Dec 2014 15:26:55 -0700 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin In-Reply-To: <549BD62D.8000308@oracle.com> References: <549BD62D.8000308@oracle.com> Message-ID: <54A326AF.1060809@oracle.com> vote: yes On 12/25/2014 2:17 AM, Igor Ignatyev wrote: > I hereby nominate Filipp Zhinkin (fzhinkin) to JDK 9 Committer. -- Alejandro From lana.steuck at oracle.com Wed Dec 31 01:05:53 2014 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 30 Dec 2014 17:05:53 -0800 (PST) Subject: jdk9-b45: dev Message-ID: <201412310105.sBV15rin001462@jano-app.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/1510f6e52044 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/3c2bbeda038a http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/73bbdcf236b2 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1d0b8d17fe1e http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/e529374fbe52 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/0dab3e848229 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b6b89b8f8531 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/9e3f2bed80c0 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8065627 client-libs Animated GIFs fail to display on a HiDPI display JDK-7155963 client-libs Deadlock in SystemFlavorMap.getFlavorsForNative and SunToolkit.awtLock JDK-8067207 client-libs Replace concat String to append in StringBuilder parameters (client) JDK-8067441 client-libs Some tests fails with error: cannot find symbol getSystemMnemonicKeyCo JDK-8066621 client-libs Suppress deprecation warnings in java.desktop module JDK-8067086 client-libs Suppress mac-specific deprecation warnings in the java.desktop module JDK-8067092 client-libs Suppress windows-specific deprecation warnings in the java.desktop mod JDK-6470361 client-libs Swing's Threading Policy example does not compile JDK-8066756 client-libs Test test/sun/awt/dnd/8024061/bug8024061.java fails JDK-8057788 client-libs [macosx] "Pinch to zoom" does not work since jdk7 JDK-8065373 client-libs [macosx] jdk8, jdk7u60 Regression in Graphics2D drawing of derived Fon JDK-8030090 core-libs (fs) Add default methods to Path for derived methods JDK-8067366 core-libs Allow java.{endorsed,ext}.dirs property be set to empty string JDK-8065420 core-libs Eliminate internal API dependency from java/net/ResponseCache/Response JDK-8067964 core-libs Native2ascii doesn't close one of the streams it opens JDK-8034263 core-svc Test java/lang/management/MemoryMXBean/LowMemoryTest.java fails interm JDK-8062032 deploy Client certificate authentication issues with TLS 1.2 and browser keys JDK-8067236 deploy DRS with non-force version run rule can block when it should not. JDK-8061648 deploy JavaWS fails with proxy autoconfig due to missing "dnsResolve" JDK-8066776 deploy Replace use of sun.misc.BASE64Encoder/Decoder with java.util.Base64 JDK-8066545 deploy Simplify parameters in deploy.args JDK-8066376 deploy There is option labeled as 'Suppress sponsors offers when installing o JDK-8067481 deploy Update tests with conf/accessibility.properties instead of lib JDK-8067172 deploy Xcode javaws Project to Debug Native Code JDK-8066406 deploy [test] aurora failed to submit for windows result JDK-8066442 hotspot Add PS and ParOld support for promotion event JDK-8067115 hotspot Add jtreg gc tests to Hotspot JPRT jobs JDK-8064909 hotspot FragmentMetaspace.java got OutOfMemoryError JDK-8061726 hotspot JEP-JDK-8044022: Test task: Check that deprecated combinations do not JDK-8047290 hotspot Make Mutex::_no_safepoint_check_flag locks verify that this lock never JDK-8064319 hotspot Need to enable -XX:+TraceExceptions in release builds JDK-8066822 hotspot Remove PSMarkSweep::set_reference_processor JDK-8067452 hotspot Rename hotspot_all in hotspot/test/TEST.groups JDK-8066921 hotspot Specifying UseAppCDS flag twice crashes VM JDK-8066862 hotspot TestMutuallyExclusivePlatformPredicates fails on all platforms JDK-8066143 hotspot [TESTBUG] New tests in gc/survivorAlignment/ fails JDK-8066863 hotspot bigapps/runThese/nowarnings fails: Java HotSpot(TM) 64-Bit Server VM w JDK-8066803 hotspot compiler/intrinsics/mathexact/SubExactINonConstantTest.java crashed in JDK-8059586 hotspot hs_err report should treat redirected core pattern. JDK-8043349 security-libs Consider adding aliases for Ucrypto algorithm-only Cipher transformati JDK-8044445 security-libs JEP 229: Create PKCS12 Keystores by Default JDK-8054689 tools Split large SJavac.java test source into multiple files JDK-8061472 tools String.format in DeferredAttr.DeferredTypeMap constructor leads to exc (excluding confidential bugs) From John.Coomes at oracle.com Wed Dec 31 23:06:10 2014 From: John.Coomes at oracle.com (John Coomes) Date: Wed, 31 Dec 2014 15:06:10 -0800 Subject: CFV: New JDK 9 Committer: Filipp Zhinkin In-Reply-To: <549BD62D.8000308@oracle.com> References: <549BD62D.8000308@oracle.com> Message-ID: <21668.33122.131861.192413@mykonos.us.oracle.com> Vote: yes -John