RFR: 8076458: java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java timeout

[Hamlin Li]

Hi everyone,

Would you please help to review the fix for bug 
https://bugs.openjdk.java.net/browse/JDK-8076458, 
java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java 
timeout.

webrev: http://cr.openjdk.java.net/~mli/8076458/webrev.00/

Thank you
-Hamlin

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

[Mikael Vidstedt]

I've finally found some time to return to this and have a new version of 
the patch which looks more promising:


http://cr.openjdk.java.net/~mikael/webrevs/8141491/webrev.02/webrev/

This uses memcpy to read/write the native data and the preliminary 
benchmark numbers on linux/x64 shows the expected performance. I'll work 
on verifying that it doesn't impact other platforms negatively over the 
next days/weeks.


Btw, I also played around with implementing it in pure Java, but there 
are some issues getting C2 to correctly vectorize the loop given the 
native data accesses, so the native code seems to be needed for now.


Cheers,
Mikael

On 2015-11-25 13:32, Mikael Vidstedt wrote:


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


Cheers,
Mikael


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


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

Sending to core-libs mailing list.

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

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

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

I need a sponsor.

Sasha

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

[Alan Bateman]

On 24/01/2016 17:10, Peter Levart wrote:

Hi,

I had an idea recently on how to expedite the collection of an object. 
It is simple - just don't let it live long.


Here's a concept prototype:

http://cr.openjdk.java.net/~plevart/misc/CloseableMemory/CloseableMemory.java 



The overhead of the check in access methods (getByte()/setByte()) 
amounts to one volatile read of an oop variable that changes once per 
say 5 to 10 seconds. That's the period a special guard object is 
alive. It's reachability is tracked by the GC and extends to the end 
of each access method (using Reference.reachabilityFence). Every few 
seconds, the guard object is changed with new fresh one so that the 
chance of the guard and its tracking Cleaner being promoted to old 
generation is very low.


Could something like that enable a low-overhead 
CloseableMappedByteBuffer?


If I read this correctly then this still depends on timely reference 
processing. The switching guard trick to keep the Cleaner from being 
promoted is interesting of course. So if we were to do something like 
this with MBB then it would mean the file mapping would still exist and 
so we'd have the usual issue of trying to delete the underlying file. 
Then we have the issue of file or socket I/O where threads could be 
blocked doing I/O with regions of the buffer and so delay indefinitely 
any release.


That said, maybe it is an option for Uwe.

-Alan.

Re: RFR 8065076/9, test/java/net/SocketPermission/SocketPermissionTest.java failed intermittently

[Seán Coffey]

The changes look fine to me also Chris.

Regards,
Sean.

On 22/01/16 14:49, Chris Hegarty wrote:

On 21/01/16 22:55, Felix Yang wrote:

Hi Chris,
  your fix is cool. I will assign the bug to you:)
  a comment on this fix. The test changed system SecurityManager and
it is not executed with othervm mode. I think you need to rollback the
change after test.


I will revert the change and have the test run in othervm mode.

I did do a complete test run with this change and it did not cause
any problems, but then again the policy is all permissions!

Thanks Felix.

-Chris.

> Otherwise it may affect other tests.


Thanks,
Felix

On Jan 20, 2016, at 12:45 PM, Chris Hegarty > wrote:

On 20 Jan 2016, at 06:36, Chris Hegarty > wrote:


Felix,

On 14 Jan 2016, at 06:07, Felix Yang > wrote:


Hi all,
 please review the fix for
test/java/net/SocketPermission/SocketPermissionTest.java, which
fails frequently with "java.net.BindException: Address already in 
use".


Bug: https://bugs.openjdk.java.net/browse/JDK-8065076
Webrev: http://cr.openjdk.java.net/~xiaofeya/8065076/webrev.00


My preference is to avoid getFreePort. It is problematic and I
believe just obfuscates
the intermittent failures further.

In many of the test scenarios the “listening” socket can be created
before the specific
access control context and associated permission are created.

I’ll see if I can get some time to try this out.


I spent a little time on this today. I basically rewrote the test, but
kept the
same test scenarios. The use of data providers was cute, but not 
workable

since there is no common supertype for the socket classes. I decided to
just expand out the test cases manually. This will give the same test
coverage, but should be stable since it creates the sockets first, 
on an

ephemeral port, and then constructs the permissions appropriately given
that port.

http://cr.openjdk.java.net/~chegar/8065076/

The webrev diffs are almost useless, just review the new file, and 
compare

test scenarios against the what is in the old file.

-Chris.

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

[Peter Levart]

On 01/25/2016 02:31 PM, Alan Bateman wrote:

On 24/01/2016 17:10, Peter Levart wrote:

Hi,

I had an idea recently on how to expedite the collection of an 
object. It is simple - just don't let it live long.


Here's a concept prototype:

http://cr.openjdk.java.net/~plevart/misc/CloseableMemory/CloseableMemory.java 



The overhead of the check in access methods (getByte()/setByte()) 
amounts to one volatile read of an oop variable that changes once per 
say 5 to 10 seconds. That's the period a special guard object is 
alive. It's reachability is tracked by the GC and extends to the end 
of each access method (using Reference.reachabilityFence). Every few 
seconds, the guard object is changed with new fresh one so that the 
chance of the guard and its tracking Cleaner being promoted to old 
generation is very low.


Could something like that enable a low-overhead 
CloseableMappedByteBuffer?


If I read this correctly then this still depends on timely reference 
processing.


Right, the hope is that Reference(s) and referents that only live for a 
few seconds get this timely processing.


The switching guard trick to keep the Cleaner from being promoted is 
interesting of course. So if we were to do something like this with 
MBB then it would mean the file mapping would still exist and so we'd 
have the usual issue of trying to delete the underlying file. 


There could be a method on MBB to register a callback to be called after 
the buffer is unmapped.


Then we have the issue of file or socket I/O where threads could be 
blocked doing I/O with regions of the buffer and so delay indefinitely 
any release.


Yes, that could be a problem. If the access to mapped memory blocked for 
a very long time, then the guard and its Cleaner could be promoted to 
old gen in the meanwhile. But let me ask something. Doesn't GC 
processing require (at least in some phases) that user threads be 
stopped in a safepoint? What happens when a user thread is blocked by 
kernel on memory access? Such thread can't be stopped in a safepoint. 
Safepoint can't begin, so GC can't proceed and therefore can't promote 
objects to old generation at that time. Am I right? If yes, then time 
does not pass for objects while a user thread is blocked on memory 
access, so they won't get promoted to old gen any time sooner after the 
user thread is unblocked.


Regards, Peter



That said, maybe it is an option for Uwe.

-Alan.

Re: RFR [9]: 8145104: NPE is thrown when JAXBContextFactory implementation is specified in system property, 8145112: newInstance(String, ClassLoader): java.lang.JAXBException should not be wrapped as

[Miroslav Kos]

Ping again - would somebody find some time to review those, please?

Thanks
M.


On 11/01/16 12:14, Miroslav Kos wrote:

Ping ... anybody?

On 22/12/15 14:44, Miroslav Kos wrote:

Hi everybody,
I'd like to ask for reviewing following patch. It fixes two issues:

JBS: https://bugs.openjdk.java.net/browse/JDK-8145104
NPE is thrown when JAXBContextFactory implementation is specified in 
system property


In short, it's a regression of recent changes in JAXB-AP. The old 
version of API is using static methods to create JAXBContext 
instance, where as the new configuration facility uses defined 
interface. The methods are called via core reflection, so when 
invoking non-static method of spi implemetation, instance of the spi 
must be created first. This fixes NPE which occured in certain 
scenarios.


JBS: https://bugs.openjdk.java.net/browse/JDK-8145112
newInstance(String, ClassLoader): java.lang.JAXBException should not 
be wrapped as expected according to spec


There are still some changes in javadoc being discussed, but anyway 
this double-wrapping exception into JAXBException doesn't make any 
sense. JAXBException thrown from JAXB spi provider is re-thrown as is.


Fix: http://cr.openjdk.java.net/~mkos/8145104/jaxws.01/
Tests: http://cr.openjdk.java.net/~mkos/8145104/jdk.02/

Added 2 new jtreg tests, the tests added also to standalone project.

Thanks
Miran

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

[Chris Hegarty]

On 25/01/16 15:47, Alan Bateman wrote:



On 25/01/2016 15:38, Chris Hegarty wrote:

JOpt Simple [1] is a Java library for parsing command line options.
The JDK has several different home-grown versions of command line
option-parsing code. Where possible, new and existing tools in the
JDK should consider using JOpt Simple. JOpt Simple is being used in
a number of tools in project jigsaw [2].

This issue proposes to integrate JOpt Simple into JDK 9 as a new
module that can be used internally by tools in the JDK. The webrev
proposes to add the new module, it is yet to be used. Qualified
exports to specific JDK tool modules can be added later.

http://cr.openjdk.java.net/~chegar/8148154/

Bringing this into jdk9/dev in the advance looks good. One thing, should
we add a README so that we know exactly which version of JOpt Simple
this is?


Good idea Alan. Added and webrev updated in-place.

-Chris.

Re: ClassFileTransformer does not apply to anonymous classes

[Rafael Winterhalter]

Hi Vladmir, hello Remi,

what bothers me about instrumenting a lambda expression's target
method is the difficulty of locating the method that contains the code
and setting it into context. This is a lot of work to do since one
needs to first locate any invokedynamic call sites and interpret the
connection via the LambdaMetafactory. This is difficult to instrument
without greater efforts and does not feel like a clean solution.

Many real life instrumentations are based on the assumption of being
able to instrument any class of a given subtype or other any other
class property. For example, one would want to instrument any class
that implements InputStream to discover a resource leak. If the
interface is however functional and implemented as a lambda
expression, a tool that manipulating all class files of this type
stops working. At the same time, end users do not really understand
the difference of their former anonymous class that is now expressed a
lambda expression and perceive the beaviour as a regression.

I have myself implemented a custom solution for my code generation
library that instruments the LambdaMetafactory to apply class file
transformers to these classes manually. This does however show two
disadvantages:

1. javac creates the target method of a lambda expression as a private
method. The only way to implement a lambda expression legally in byte
code is by loading the generated implementation anonymously what
requires non-public API. While it is possible to call
Unsafe::defineAnonymousClass from the instrumented LambdaMetafactory,
it is again required to use non-standardized APIs which might fail on
differing implementations of the JVM.

2. At the same time, there is no standardized way to receive all
ClassFileTransformers that are currently registered on the VM. this
also requires calls into internal APIs that are not necessarily
supported on other platforms.

I fully understand the hesitation to support this from a technical
point of view but in reality, people are already dependant on this
feature and disallowing the instrumentation of lambda classes will
only inspire work-arrounds that reduce the stability of software using
this APIs that does currently work without problems for non-lambda
classes.

Best regards, Rafael

PS: While implementing my solution, I found that the LambdaMetafactory
of the Open JDK creates private, final methods for the serialization
bits. The methods should however not be final as they are already
private.


2016-01-23 13:55 GMT+01:00 Remi Forax :
> I agree with Vladimir,
>
> You should not be able to transform/redefine a VM anonymous class because the 
> transformer will certainly mess up with the order of the constant pool 
> entries.
>
> Slightly off-topic, about ASM, when you create a ClassWriter [1], you can 
> pass a ClassReader of an existing class, in that case ASM copy the constant 
> pool from the class reader to the class writer so the constant pool is 
> preserved.
>
> Rémi
>
> [1] 
> http://asm.ow2.org/asm50/javadoc/user/org/objectweb/asm/ClassWriter.html#ClassWriter%28org.objectweb.asm.ClassReader,%20int%29
>
> - Mail original -
>> De: "Vladimir Ivanov" 
>> À: "Rafael Winterhalter" 
>> Cc: "Coleen Phillimore" , 
>> core-libs-dev@openjdk.java.net, "serguei.spit...@oracle.com
>> Spitsyn" , "Daniel Daugherty" 
>> 
>> Envoyé: Vendredi 22 Janvier 2016 18:47:31
>> Objet: Re: ClassFileTransformer does not apply to anonymous classes
>>
>> Rafael,
>>
>> First of all, I'd like to agree on the terminology. There's some
>> confusion there. Anonymous term is ambiguous in Java. There are
>> anonymous classes on language level and there's
>> Unsafe.defineAnonymousClass() which produce anonymous-in-VM-sense
>> classes. I prefer to call them VM anonymous classes to avoid confusion.
>>
>> I assume that whenever you use anonymous you assume "VM anonymous".
>>
>> > thank you for your response. While I completely understand your view
>> > from a VM implementor's point of view, as a practicioner I would
>> > recommend against it. Not being able to instrument lambda expressions
>> > puts a severe limitation onto using the instrumentation API
>> > alltogether. For example, a monitoring application that promises to
>> > record all invocations of a method of a certain interface that only
>> > works 95% of the time is not 5% less usefull but might no longer be
>> > useful at all. People have build large applications based on the
>> > assumption that all user application code can be instrumented and such
>> > a regression would hurt them. For example, until today, over 30 people
>> > that use my code generation framework reached out to me and reported
>> > the reported behavior as a bug in my library and people are only
>> > starting to migrate their applications to Java 8. The outcome is
>> > simply not 

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

[Gil Tene]

I assume your goal here is to get the resources released with the next newgen 
collections (following a close()), rather than wait for an oldgen (if the 
resource was held by an old object). That's a cool thing.

With that in mind, you can replace the repeated periodic 
polling/flipping/allocation and external calling changeGuard() with a simple 
internal GC-detecor that would call changeGuard() allocate a new guard only 
once per newgen GC cycle.

This can take the form of adding a simple GCDetector inside your implementation:

private class GCDetector {
@Override
protected void finalize() throws Throwable {
GCDetector detector = new GCDetector();
changeGuard();
Reference.reachabilityFence(detector);
}
}

// The reason to use finalize here instead of a phantom ref
// based cleaner is that it would trigger immediately after the cycle,
// rather than potentially take an extra cycle to trigger.
// This can be done with a weakRef based cleaner instead
// (but probably when one is added to the JDK, otherwise you'd
// need your own polling thread and logic here...).

You'll need to allocate a single instance of GCDetector during construction of 
a CloseableMemory, without retaining a reference to it after construction. This 
will start a finalize-triggering chain per instance, with the chain "ticking" 
once per newgen cycle.

If you want to avoid having one of these (coming and going on each GC cycle) 
per CloseableMemory instance, you can use a common static detector and a 
registration mechanism (where each registered instance would have it's 
changeGuard() method call…

— Gil.


> On Jan 24, 2016, at 9:10 AM, Peter Levart  wrote:
> 
> Hi,
> 
> I had an idea recently on how to expedite the collection of an object. It is 
> simple - just don't let it live long.
> 
> Here's a concept prototype:
> 
> http://cr.openjdk.java.net/~plevart/misc/CloseableMemory/CloseableMemory.java
> 
> The overhead of the check in access methods (getByte()/setByte()) amounts to 
> one volatile read of an oop variable that changes once per say 5 to 10 
> seconds. That's the period a special guard object is alive. It's reachability 
> is tracked by the GC and extends to the end of each access method (using 
> Reference.reachabilityFence). Every few seconds, the guard object is changed 
> with new fresh one so that the chance of the guard and its tracking Cleaner 
> being promoted to old generation is very low.
> 
> Could something like that enable a low-overhead CloseableMappedByteBuffer?
> 
> Regards, Peter
> 
> On 01/23/2016 09:31 PM, Andrew Haley wrote:
>> On 23/01/16 20:01, Uwe Schindler wrote:
>> 
>>> It depends how small! If the speed is still somewhere between Java 8
>>> ByteBuffer performance and the recent Hotspot improvements in Java
>>> 9, I agree with trying it out. But some volatile memory access on
>>> every access is a no-go. The code around ByteBufferIndexInput in
>>> Lucene is the most performance-critical critical code, because on
>>> every search query or sorting there is all the work happening in
>>> there (millions of iterations with positional ByteBuffer.get*
>>> calls). As ByteBuffers are limited to 2 GiB, we also need lots of
>>> hairy code to work around that limitation!
>> Yes, I see that code.  It would be helpful if there were a
>> self-contained but realistic benchmark using that code.  That way,
>> some simple experiments would allow changes to be measured.
>> 
>>> If you look at ByteBufferIndexInput's code you will see that we
>>> simply do stuff like trying to read from one bytebuffer and only if
>>> we catch an BufferUnderflowException we fall back to handling buffer
>>> switches: Instead of checking bounds on every access, we have
>>> fallback code only happening on exceptions. E.g. if you are 3 bytes
>>> before end of one buffer slice and read a long, it will throw
>>> BufferUnderflow. When this happens the code will fall back to read
>>> byte by byte from 2 different buffers and reassemble the long):
>> I'm surprised you don't see painful deoptimization traps when that
>> happens.  I suppose it's rare enough that you don't care.  There's a
>> new group of methods in JDK9 called Objects.checkIndex() which are
>> intended to provide a very efficient way to do bounds checks. It might
>> be interesting to see if they work well with ByteBufferIndexInput:
>> that's an important use case.
>> 
>> BTW, does anyone here know why we don't have humongous ByteBuffers
>> with a long index?
>> 
>> Andrew.
> 

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

[Chris Hegarty]

On 25/01/16 15:39, Claes Redestad wrote:

+1


Thanks for looking at this Claes.


module-info.java missing?


No. There is an update to modules.xml. This is all that is required
in jdk9/dev, for now.


"jdk.internal.opt" might be ever so slightly misleading, wouldn't
"jdk.internal.joptsimple" be a better name for the module?


For consistency, I took the same terse approach applied to the
jdk.internal.le module.

-Chris.



/Claes

On 2016-01-25 16:38, Chris Hegarty wrote:

JOpt Simple [1] is a Java library for parsing command line options.
The JDK has several different home-grown versions of command line
option-parsing code. Where possible, new and existing tools in the
JDK should consider using JOpt Simple. JOpt Simple is being used in
a number of tools in project jigsaw [2].

This issue proposes to integrate JOpt Simple into JDK 9 as a new
module that can be used internally by tools in the JDK. The webrev
proposes to add the new module, it is yet to be used. Qualified
exports to specific JDK tool modules can be added later.

http://cr.openjdk.java.net/~chegar/8148154/

-Chris.

[1] https://pholser.github.io/jopt-simple/
[2]
http://hg.openjdk.java.net/jigsaw/jake/jdk/file/tip/src/jdk.internal.opt/share/classes

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

[Roger Riggs]

Hi Chris,

Are there any tests that can be included?

Roger


On 1/25/2016 10:39 AM, Claes Redestad wrote:

+1

module-info.java missing?

"jdk.internal.opt" might be ever so slightly misleading, wouldn't 
"jdk.internal.joptsimple" be a better name for the module?


/Claes

On 2016-01-25 16:38, Chris Hegarty wrote:

JOpt Simple [1] is a Java library for parsing command line options.
The JDK has several different home-grown versions of command line
option-parsing code. Where possible, new and existing tools in the
JDK should consider using JOpt Simple. JOpt Simple is being used in
a number of tools in project jigsaw [2].

This issue proposes to integrate JOpt Simple into JDK 9 as a new
module that can be used internally by tools in the JDK. The webrev
proposes to add the new module, it is yet to be used. Qualified
exports to specific JDK tool modules can be added later.

http://cr.openjdk.java.net/~chegar/8148154/

-Chris.

[1] https://pholser.github.io/jopt-simple/
[2] 
http://hg.openjdk.java.net/jigsaw/jake/jdk/file/tip/src/jdk.internal.opt/share/classes 

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

[Roger Riggs]

Hi Chris,


On 1/25/2016 10:45 AM, Chris Hegarty wrote:

On 25/01/16 15:39, Claes Redestad wrote:


"jdk.internal.opt" might be ever so slightly misleading, wouldn't
"jdk.internal.joptsimple" be a better name for the module?


For consistency, I took the same terse approach applied to the
jdk.internal.le module.

More explicit is better;  I think 'le' was/is too terse to be informative.
and a simple 'opt' is too vague.

$.02, Roger


-Chris.



/Claes

On 2016-01-25 16:38, Chris Hegarty wrote:

JOpt Simple [1] is a Java library for parsing command line options.
The JDK has several different home-grown versions of command line
option-parsing code. Where possible, new and existing tools in the
JDK should consider using JOpt Simple. JOpt Simple is being used in
a number of tools in project jigsaw [2].

This issue proposes to integrate JOpt Simple into JDK 9 as a new
module that can be used internally by tools in the JDK. The webrev
proposes to add the new module, it is yet to be used. Qualified
exports to specific JDK tool modules can be added later.

http://cr.openjdk.java.net/~chegar/8148154/

-Chris.

[1] https://pholser.github.io/jopt-simple/
[2]
http://hg.openjdk.java.net/jigsaw/jake/jdk/file/tip/src/jdk.internal.opt/share/classes 

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

[Chris Hegarty]

On 25/01/16 15:45, Roger Riggs wrote:

Hi Chris,

Are there any tests that can be included?


No, I am not planning to add specific tests for JOpt Simple.
The tools that eventually use it, should provide sufficient
testing.

-Chris.


Roger


On 1/25/2016 10:39 AM, Claes Redestad wrote:

+1

module-info.java missing?

"jdk.internal.opt" might be ever so slightly misleading, wouldn't
"jdk.internal.joptsimple" be a better name for the module?

/Claes

On 2016-01-25 16:38, Chris Hegarty wrote:

JOpt Simple [1] is a Java library for parsing command line options.
The JDK has several different home-grown versions of command line
option-parsing code. Where possible, new and existing tools in the
JDK should consider using JOpt Simple. JOpt Simple is being used in
a number of tools in project jigsaw [2].

This issue proposes to integrate JOpt Simple into JDK 9 as a new
module that can be used internally by tools in the JDK. The webrev
proposes to add the new module, it is yet to be used. Qualified
exports to specific JDK tool modules can be added later.

http://cr.openjdk.java.net/~chegar/8148154/

-Chris.

[1] https://pholser.github.io/jopt-simple/
[2]
http://hg.openjdk.java.net/jigsaw/jake/jdk/file/tip/src/jdk.internal.opt/share/classes

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

[Alan Bateman]

On 22/01/2016 23:10, Steve Drach wrote:

Hi Alan, et. al.,

I’ve released a new webrev that addresses all the issues you raised.

http://cr.openjdk.java.net/~sdrach/8132734/webrev.03/index.html 



Specifically:

For Release then I have to admit that I dislike _9 and wonder if 
other options were considered? javax.lang.model.SourceVersion uses 
the RELEASE_xx convention for example.


Changed to VERSION_9, i.e. Release.VERSION_9



Also I wonder about Release.ROOT and whether Release.UNVERSIONED was 
considered? In general the phrase "root entry" in the javadoc makes 
me think the root or top-most directory. An alternative that might be 
clearer is to say "unversioned entry" and define that term clearly in 
the class description.


Changed to BASE, i.e. Release.BASE

This looks better. Release.BASE is probably okay although it still feels 
like Release.UNVERSIONED, esp. when it is defined as "Represents 
unversioned entries".


I'm still wondering about the phrase "root entry" as it continues to 
give the impression (to me anyway) that it's a resource in the root 
directory. I think "root" works in the JEP because it deals with simple 
resources like A.class and B.class that are in the root directory but 
it's confusing when there resources with a slash in the name. Add to 
this is the META-INF/versions/ directories which are roots for the 
version specific resources. I think part of the confusion is that the 
first mention of "root entry" is in the second paragraph where it has 
"overrides the unversioned root entry" without defining what it means. 
In summary, I'm wondering whether you would be up for change the 
terminology so that "root entry" isn't in the javadoc?


-Alan.

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

[Alan Bateman]

On 25/01/2016 15:38, Chris Hegarty wrote:

JOpt Simple [1] is a Java library for parsing command line options.
The JDK has several different home-grown versions of command line
option-parsing code. Where possible, new and existing tools in the
JDK should consider using JOpt Simple. JOpt Simple is being used in
a number of tools in project jigsaw [2].

This issue proposes to integrate JOpt Simple into JDK 9 as a new
module that can be used internally by tools in the JDK. The webrev
proposes to add the new module, it is yet to be used. Qualified
exports to specific JDK tool modules can be added later.

http://cr.openjdk.java.net/~chegar/8148154/
Bringing this into jdk9/dev in the advance looks good. One thing, should 
we add a README so that we know exactly which version of JOpt Simple 
this is?


-Alan

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

[Alan Bateman]

On 25/01/2016 15:45, Chris Hegarty wrote:

:


"jdk.internal.opt" might be ever so slightly misleading, wouldn't
"jdk.internal.joptsimple" be a better name for the module?


For consistency, I took the same terse approach applied to the
jdk.internal.le module.
Right, and the module name is deliberately named because it is 
JDK-internal, it will not have any unconditional exports.


-Alan.

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

[Alan Bateman]

On 25/01/2016 16:09, Chris Hegarty wrote:

Bringing this into jdk9/dev in the advance looks good. One thing, should

we add a README so that we know exactly which version of JOpt Simple
this is?


Good idea Alan. Added and webrev updated in-place.
Thanks, that should make it easy to identify. We need to make sure there 
is a bug tracking an update to the THIRD_PARTY_README too.


-Alan.

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

[nadeesh tv]

Hi all,

Please see the updated webrev 
http://cr.openjdk.java.net/~ntv/8141452/webrev.00/


--
Thanks and Regards,
Nadeesh TV


On 1/25/2016 9:01 PM, Stephen Colebourne wrote:

Typo "TimeUnitequivalent"
Otherwise looks good.
thanks
Stephen



On 25 January 2016 at 15:25, nadeesh tv  wrote:


Hi all,

Please review a fix for conversion between Chronounit and Timeunit

Bug ID : https://bugs.openjdk.java.net/browse/JDK-8141452

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

--
Thanks and Regards,
Nadeesh TV




--
Thanks and Regards,
Nadeesh TV

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

[Roger Riggs]

Hi Stephen, Nadeesh,

TimeUnit.toChronoUnit is a static method.  It seems redundant to have to 
pass an instance to a static method of its type.

 cu = TimeUnit.toChronoUnit(TimeUnit.SECONDS);

Instead of:
   TimeUnit tu = TimeUnit.SECONDS;
ChronoUnit  cu = tu.toChronoUnit();


Minor edits please:

in @param and @return use the type name when referring to the type.
For example, TimeUnit vs timeUnit (the parameter).

in @throws, use the parameter name instead of "the unit";
For example,

+ * @throws IllegalArgumentException if timeUnit cannot be converted 
Thanks, Roger



On 1/25/2016 11:06 AM, nadeesh tv wrote:

Hi all,

Please see the updated webrev 
http://cr.openjdk.java.net/~ntv/8141452/webrev.00/


--
Thanks and Regards,
Nadeesh TV


On 1/25/2016 9:01 PM, Stephen Colebourne wrote:

Typo "TimeUnitequivalent"
Otherwise looks good.
thanks
Stephen



On 25 January 2016 at 15:25, nadeesh tv  wrote:


Hi all,

Please review a fix for conversion between Chronounit and Timeunit

Bug ID : https://bugs.openjdk.java.net/browse/JDK-8141452

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

--
Thanks and Regards,
Nadeesh TV

RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

[nadeesh tv]

Hi all,

Please review a fix for conversion between Chronounit and Timeunit

Bug ID : https://bugs.openjdk.java.net/browse/JDK-8141452

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

--
Thanks and Regards,
Nadeesh TV

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

[Claes Redestad]

+1

module-info.java missing?

"jdk.internal.opt" might be ever so slightly misleading, wouldn't 
"jdk.internal.joptsimple" be a better name for the module?


/Claes

On 2016-01-25 16:38, Chris Hegarty wrote:

JOpt Simple [1] is a Java library for parsing command line options.
The JDK has several different home-grown versions of command line
option-parsing code. Where possible, new and existing tools in the
JDK should consider using JOpt Simple. JOpt Simple is being used in
a number of tools in project jigsaw [2].

This issue proposes to integrate JOpt Simple into JDK 9 as a new
module that can be used internally by tools in the JDK. The webrev
proposes to add the new module, it is yet to be used. Qualified
exports to specific JDK tool modules can be added later.

http://cr.openjdk.java.net/~chegar/8148154/

-Chris.

[1] https://pholser.github.io/jopt-simple/
[2] 
http://hg.openjdk.java.net/jigsaw/jake/jdk/file/tip/src/jdk.internal.opt/share/classes 

Re: RFR [9] 8148117: Move sun.misc.Cleaner to jdk.internal.ref

[Alan Bateman]

On 25/01/2016 15:27, Peter Levart wrote:


But let me ask something. Doesn't GC processing require (at least in 
some phases) that user threads be stopped in a safepoint? What happens 
when a user thread is blocked by kernel on memory access? Such thread 
can't be stopped in a safepoint. Safepoint can't begin, so GC can't 
proceed and therefore can't promote objects to old generation at that 
time. Am I right? If yes, then time does not pass for objects while a 
user thread is blocked on memory access, so they won't get promoted to 
old gen any time sooner after the user thread is unblocked.
With memory mapping then it's very possible that a memory access to 
stall waiting for pages to be faulted in. So yes, I assume any 
STW/safepoint is going to be stall. On the other hand then threads doing 
file or socket I/O on these buffers will be in native (maybe blocked, 
maybe not) and so aren't an issue. They will safepoint on return or if 
they attempt to re-enter.


-Alan

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

[Stephen Colebourne]

Typo "TimeUnitequivalent"
Otherwise looks good.
thanks
Stephen



On 25 January 2016 at 15:25, nadeesh tv  wrote:

> Hi all,
>
> Please review a fix for conversion between Chronounit and Timeunit
>
> Bug ID : https://bugs.openjdk.java.net/browse/JDK-8141452
>
> webrev: http://cr.openjdk.java.net/~ntv/8141452/webrev.00/
>
> --
> Thanks and Regards,
> Nadeesh TV
>
>

RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

[Chris Hegarty]

JOpt Simple [1] is a Java library for parsing command line options.
The JDK has several different home-grown versions of command line
option-parsing code. Where possible, new and existing tools in the
JDK should consider using JOpt Simple. JOpt Simple is being used in
a number of tools in project jigsaw [2].

This issue proposes to integrate JOpt Simple into JDK 9 as a new
module that can be used internally by tools in the JDK. The webrev
proposes to add the new module, it is yet to be used. Qualified
exports to specific JDK tool modules can be added later.

http://cr.openjdk.java.net/~chegar/8148154/

-Chris.

[1] https://pholser.github.io/jopt-simple/
[2] 
http://hg.openjdk.java.net/jigsaw/jake/jdk/file/tip/src/jdk.internal.opt/share/classes 

Re: RFR [9] 8148154: JOpt Simple - a Java library for parsing command line options

[Chris Hegarty]

On 25/01/16 16:16, Alan Bateman wrote:



On 25/01/2016 16:09, Chris Hegarty wrote:

Bringing this into jdk9/dev in the advance looks good. One thing, should

we add a README so that we know exactly which version of JOpt Simple
this is?


Good idea Alan. Added and webrev updated in-place.

Thanks, that should make it easy to identify.


Thanks.

> We need to make sure there

is a bug tracking an update to the THIRD_PARTY_README too.


Filed: https://bugs.openjdk.java.net/browse/JDK-8148164

-Chris.

Re: RFR:8146218: Producing streams in java.time?

[Xueming Shen]

The proposed change looks fine with me.

sherman

On 1/23/16 1:40 PM, Roger Riggs wrote:

Hi,

Looks good.

I would want to verify that it is defined such that if it later needs 
to be

abstracted up to ChronoLocalDate and apply to compatible Chronologies
and respective local dates such as JapaneseDate there is no conflict.
It should not be an issue since Period implements ChronoPeriod.
In the respective implementations, the estimation/computation of the 
number of steps

would need to depend on the Chronology's definition of months.

I can sponsor this enhancement.

Thanks, Roger



On 1/20/16 10:15 AM, Stephen Colebourne wrote:

I'm happy with the logic and specification of this proposal. I think it
will be a useful addition.

I'll let the Oracle team chime in to do a further review.

thanks
Stephen



On 16 January 2016 at 13:31, Tagir F. Valeev  wrote:


Hello!

Thanks for review! Here's the updated patch:
http://cr.openjdk.java.net/~tvaleev/webrev/8146218/r2/

SC> The docs say that if the end date is before the start date, the
SC> stream is empty. While I can see just about why LongStream.range()
SC> works that way, I don't think this API should. The minimum is an
SC> exception, but it would be easy to support negative in the
SC> days-only case or the months-only case. The problem is where there
SC> are both months/years and days and those should be exceptions.

Now datesUntil(endExclusive) throws an IllegalArgumentException if end
date is before start date.

datesUntil(endExclusive, step) supports negative periods. It throws
IllegalArgumentException if:
- step is zero
- step.toTotalMonths() and step.getDays() both non-zero and have
opposite sign
- step is negative and end date is after start date
- step is positive and end date is before start date

Otherwise it works correctly: you can use
LocalDate.of(2016, 1, 1)
   .datesUntil(LocalDate.of(2015, 1, 1), Period.ofMonths(-1));

Steps like Period.of(-1, -1, -1) are also supported.

SC> The single-arg implementation uses plusDays() with an
SC> incrementing number. When the performance patch goes in, the
SC> proposed streaming implementation will be optimal for small
SC> streams but less optimal for large ones. The fastest way to loop
SC> over a list of dates would be to manually generate them by
SC> incrementing the day until it exceeds the length of month, and so
SC> on. However, this would be serial.

As I understand, plusDays performance patch is already pushed.

It's possible to write custom Spliterator which would use
previous.plusDays(1) in tryAdvance() and jump (via
LocalDate.of(startEpochDay+n)) in trySplit() if parallel processing is
requested. However this adds at least one additional class and more
complexity. I guess, such optimization can be considered later as
separate issue when API is stabilized.

SC> As such, I think the best way to write this, taking account of
SC> how plusDays() is implemented, is as follows:

SC> LongStream.range(start.toEpochDay(),
SC> end.toEpochDay()).mapToObj(LocalDate::ofEpochDay);

Ok, now it's done this way.

SC> In the period-based method, it would be best to capture the case
SC> where totalMonths == 0 and days > 0 and forward to another method
SC> that ignores months. That private method can share implementation
SC> with the public single-arg method (passing in 1).

This case still more complex than one-day case as it requires division
and multiplication. Thus I'd keep these case separately. However I
simplified "months = 0" path using ofEpochDay, now it should be
faster.

SC> The docs for the period-based method should specify the strategy
SC> that produces the results (in abstract terms). This needs to cover
SC> that the result is equivalent to always adding to the start period
SC> a multiple of the period.

I added some clarifications, please check.

SC> Some nits:
SC> I prefer to avoid @link in the first sentence. Just using 'stream'
would be sufficient.

Done.

SC> The first sentence should be a summary. In this case it probably 
has a

bit too much detail.

Done.

SC> The @return has 'values' on a new line when it could be on the same
line.

I set now line length = 100 characters in my IDE. Is it ok?

SC> If statements need braces.

Done.

With best regards,
Tagir Valeev.

Re: Stream.limit parallel ordered performance

[Stefan Zobel]

2016-01-24 12:36 GMT+01:00 Tagir F. Valeev :
> Hello!
>
> I'm investigating Stream.limit() performance for parallel ordered
> streams when no SUBSIZED optimization is performed.
>
> Consider the following code, for example:
>
> AtomicInteger counter = new AtomicInteger();
> int[] result = IntStream.range(0, 1_000_000).parallel().filter(x -> true)
> .peek(x -> counter.incrementAndGet()).limit(10).toArray();
> System.out.println(Arrays.toString(result));
> System.out.println(counter.get());
>
> How much the counter.get() would print? It changes from launch to
> launch, but usually within 375000..625000. This is just insane. On my
> 4-core system parallel stream creates 16 individual tasks. I expect
> that every individual task should consume no more than 10 elements, so
> in total no more than 160 elements should be consumed in this case.
>
> Here's a patch which addresses this issue:
> http://cr.openjdk.java.net/~tvaleev/patches/limit/limit-patch.txt
>
> In the limit case non-root leaf tasks may switch to copyIntoWithCancel
> to control the count of consumed elements and do not consume more than
> necessary.
>
> This change seems to fix the issue addressed in comment (at least
> partially):
>
> // @@@ OOMEs will occur for LongStream.range(0, Long.MAX_VALUE).filter(i -> 
> true).limit(n)
> // regardless of the value of n
> // Need to adjust the target size of splitting for the
> // SliceTask from say (size / k) to say min(size / k, 1 << 14)
> // This will limit the size of the buffers created at the leaf nodes
> // cancellation will be more aggressive cancelling later tasks
> // if the target slice size has been reached from a given task,
> // cancellation should also clear local results if any
>
> I checked with the following code:
>
> for(int n : new int[] {10, 100, 1000, 5000, 1, 5, 10, 50, 
> 100}) {
> System.out.println(n);
> long[] arr = LongStream.range(0, Long.MAX_VALUE).filter(i -> 
> true).parallel().limit(n).toArray();
> long[] ref = LongStream.range(0, n).toArray();
> System.out.println(Arrays.equals(arr, ref));
> }
>
> It works correctly after applying my patch (while dies with OOME
> without patch, as comment suggests).
>
> Currently existing unit tests also pass with my patch. However I'm
> very new in the internals of parallel stream processing, so it's
> possible that I'm missing something. Please review! If this looks
> reasonable I will log an issue and write new test cases.
>
> Thank you in advance,
> With best regards,
> Tagir Valeev.
>


Hi Tagir,

I'm not an expert. To me, your suggestion appears to be very sensible.

Regards,
Stefan

Re: API review of VarHandles

[Vitaly Davidovich]

Hi Doug,

I somehow missed your reply and just now noticed it after Martin's last
email quoted it -- thanks for elaborating.

The new name is required because opaque is only "like" C++
> memory_order_relaxed.
> See the jmm-dev list discussions last year for details, but annoyingly,
> Java normal variables and C++ memory_order_relaxed are not quite the
> same, and neither are the same as C-volatile/opaque.


AFAICT, difference between java normal load/store and memory_order_relaxed
is the latter guaranteeing atomicity.  If I'm understanding you correctly,
"opaque" is *just* compiler barrier and does not guarantee atomicity? If
that's so, what is/are the use case(s) for opaque? Andrew mentioned
preventing roach motel movement of loads/stores into the motel.  Is there
something more than that?

Assuming my above statement is correct, it would seem like having
memory_order_relaxed would be more useful than simply "no code motion
around this load/store", or if not more useful, just useful on its own;
there's plenty of code that doesn't care about ordering but would not
tolerate torn reads/stores.


On Fri, Jan 22, 2016 at 8:23 AM, Doug Lea  wrote:

> On 01/22/2016 04:51 AM, Andrew Haley wrote:
>
>> On 22/01/16 00:01, Vitaly Davidovich wrote:
>>
>>> I think the get/setOpaque methods need a bit more explanation ("opaque"
>>> is
>>> an odd naming choice, IMO).  Specifically, it says the operations are
>>> done
>>> in program order but have no effect on inter-thread ordering/visibility.
>>> Is this spec verbiage for a full compiler-only fence?
>>>
>>
>
> Basically yes. It would be the same as C "volatile" (not C++/C11
> "atomic"), if C volatile had a memory model spec. But in any case
> we can't use "volatile" for this in Java because it already means
> something else.
>
>
>> It's like C++ memory_order_relaxed, I guessed.  I understand that but
>> not "opaque".
>>
>>
> The new name is required because opaque is only "like" C++
> memory_order_relaxed.
> See the jmm-dev list discussions last year for details, but annoyingly,
> Java normal variables and C++ memory_order_relaxed are not quite the
> same, and neither are the same as C-volatile/opaque.
>
> -Doug
>
>
>
>

Re: API review of VarHandles

[Martin Buchholz]

On Fri, Jan 22, 2016 at 5:23 AM, Doug Lea  wrote:
> On 01/22/2016 04:51 AM, Andrew Haley wrote:
>>
>> On 22/01/16 00:01, Vitaly Davidovich wrote:
>>>
>>> I think the get/setOpaque methods need a bit more explanation ("opaque"
>>> is
>>> an odd naming choice, IMO).  Specifically, it says the operations are
>>> done
>>> in program order but have no effect on inter-thread ordering/visibility.
>>> Is this spec verbiage for a full compiler-only fence?
>
>
>
> Basically yes. It would be the same as C "volatile" (not C++/C11
> "atomic"), if C volatile had a memory model spec. But in any case
> we can't use "volatile" for this in Java because it already means
> something else.

It would be nice if we could actually say this in the (non-normative
part of the) javadoc.

>>
>> It's like C++ memory_order_relaxed, I guessed.  I understand that but
>> not "opaque".
>>
>
> The new name is required because opaque is only "like" C++
> memory_order_relaxed.
> See the jmm-dev list discussions last year for details, but annoyingly,
> Java normal variables and C++ memory_order_relaxed are not quite the
> same, and neither are the same as C-volatile/opaque.

Could we make atomicity guarantees clear for every method?  When can
we be sure not to get OOTA values?

Re: API review of VarHandles

[Martin Buchholz]

This is my first attempt to understand  java.lang.invoke. It seems
like a new alien world, non-java-like.  I'll need to rebuild my
internal performance model of java code, perhaps by staring at jit
compiled code.

I expect new APIs for atomic variable access to appear in
j.u.c.atomic, not j.l.invoke.  Aleksey has made atomic updaters fast.
Can we continue on that road, providing more updaters or more methods
on current updaters?

Sequential consistency is much easier than release/acquire, which is
in turn much easier than load/load store/store. (using the latter is
almost always a mistake?)
Memory ordering combined with variables is easier than independent fences.
I continue to be uneasy about handing out the sharpest knives in public APIs.
We're not providing much in the way of scare text to get users to think twice.

Regarding the removal of com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java

[Langer, Christoph]

Hi,

as I was using the xslt EnvironmentCheck class in my private testcase and 
recognizing it didn't exist anymore in JDK 9, I stumbled over this thread from 
last July below.

I understand that you want to clean up and remove unnecessary code but I found 
the class quite useful as it would some up several (to me seemingly) 
interesting jaxp version information. The other Version.java class was removed, 
too. Was the information collected by these classes really that crappy that it 
could just be removed? Where would I get my XML version information from now?

Thanks and best regards
Christoph


On 7/28/2015 10:32 AM, Daniel Fuchs wrote:
> On 28/07/15 19:20, huizhe wang wrote:
>> Hi Daniel,
>>
>>
>> On 7/28/2015 8:22 AM, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below a fix for yet another cleanup for jaxp:
>>
>> Thanks for yet another cleanup! And, there is a lot more to come :-)
>>>
>>> 8130059: jaxp: Investigate removal of
>>> com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java
>>> https://bugs.openjdk.java.net/browse/JDK-8130059
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8130059/webrev.00/
>>>
>>> EnvironmentCheck doesn't seem to serve any purpose in JDK 9.
>>
>> Agree. It'd be a confusion more than anything else if used since it
>> produces many irrelevant information.
>>
>>> It is not called anywhere. The proposal is to remove it.
>>> By doing a full grep on the JDK I also identified another
>>> unused class (Hashtree2Node.java) which referred to EnvironmentCheck
>>> inside a comment.
>>> I took the liberty to remove that class as well.
>>
>> Ok.  The webrev looks good to me. If you'd want to remove the two
>> Version classes as shown in the test, that would be fine with me too.
>> Then you could remove the whole test.
>
> Thanks Joe!
>
> One of the two version classes (xalan) is used by ...xslt.Process.java
> I already logged another bug to investigate removing that as
> well (JDK-8130058).

Great!
>
> Maybe we should remove the two versions classes as part of that
> other bug? Or I could update my webrev to just remove the xerces
> Version.java now, which as far as I can see is not called anywhere.
>
> As you prefer :-)

I agree as you planned, considering removing the two version classes in
JDK-8130058.

Cheers :-)

Joe

>
> cheers,
>
> -- daniel
>
>>
>> Best regards,
>> Joe
>>
>>>
>>> As for the latter cleanup, what triggered this is that EnvironmentCheck
>>> is using sun.boot.class.path...
>>>
>>> best regards,
>>>
>>> -- daniel
>>
>

Re: Regarding the removal of com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java

[huizhe wang]

Hi Christoph,

What did you use from the class?

As in the discussion, many of the information are either inaccurate or 
irrelevant in the JDK (vs as a standalone impl).


Thanks,
Joe

On 1/25/2016 3:49 PM, Langer, Christoph wrote:

Hi,
  
as I was using the xslt EnvironmentCheck class in my private testcase and recognizing it didn't exist anymore in JDK 9, I stumbled over this thread from last July below.
  
I understand that you want to clean up and remove unnecessary code but I found the class quite useful as it would some up several (to me seemingly) interesting jaxp version information. The other Version.java class was removed, too. Was the information collected by these classes really that crappy that it could just be removed? Where would I get my XML version information from now?
  
Thanks and best regards

Christoph
  
  
On 7/28/2015 10:32 AM, Daniel Fuchs wrote:

>/  On 28/07/15 19:20, huizhe wang wrote:/
>>/  Hi Daniel,/
>>/  /
>>/  /
>>/  On 7/28/2015 8:22 AM, Daniel Fuchs wrote:/
>>>/  Hi,/
>>>/  /
>>>/  Please find below a fix for yet another cleanup for jaxp:/
>>/  /
>>/  Thanks for yet another cleanup! And, there is a lot more to come :-)/
>>>/  /
>>>/  8130059: jaxp: Investigate removal of/
>>>/  com/sun/org/apache/xalan/internal/xslt/EnvironmentCheck.java/
>>>/  //https://bugs.openjdk.java.net/browse/JDK-8130059///
>>>/  /
>>>/  //http://cr.openjdk.java.net/~dfuchs/webrev_8130059/webrev.00/  
///
>>>/  /
>>>/  EnvironmentCheck doesn't seem to serve any purpose in JDK 9./
>>/  /
>>/  Agree. It'd be a confusion more than anything else if used since it/
>>/  produces many irrelevant information./
>>/  /
>>>/  It is not called anywhere. The proposal is to remove it./
>>>/  By doing a full grep on the JDK I also identified another/
>>>/  unused class (Hashtree2Node.java) which referred to EnvironmentCheck/
>>>/  inside a comment./
>>>/  I took the liberty to remove that class as well./
>>/  /
>>/  Ok.  The webrev looks good to me. If you'd want to remove the two/
>>/  Version classes as shown in the test, that would be fine with me too./
>>/  Then you could remove the whole test./
>/  /
>/  Thanks Joe!/
>/  /
>/  One of the two version classes (xalan) is used by ...xslt.Process.java/
>/  I already logged another bug to investigate removing that as/
>/  well (JDK-8130058)./
  
Great!

>/  /
>/  Maybe we should remove the two versions classes as part of that/
>/  other bug? Or I could update my webrev to just remove the xerces/
>/  Version.java now, which as far as I can see is not called anywhere./
>/  /
>/  As you prefer :-)/
  
I agree as you planned, considering removing the two version classes in

JDK-8130058.
  
Cheers :-)
  
Joe
  
>/  /

>/  cheers,/
>/  /
>/  -- daniel/
>/  /
>>/  /
>>/  Best regards,/
>>/  Joe/
>>/  /
>>>/  /
>>>/  As for the latter cleanup, what triggered this is that EnvironmentCheck/
>>>/  is using sun.boot.class.path.../
>>>/  /
>>>/  best regards,/
>>>/  /
>>>/  -- daniel/
>>/  /
>  

Re: RFR: JDK-8146568 NegativeArraySizeException in ArrayList.grow(int)

[Martin Buchholz]

I already regret touching crufty old Vector, but it had the same bug
to fix, and more surprisingly the same sort of performance improvement
from doing the obvious port.  So ... Stuart, please review also

http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Vector-grow/
https://bugs.openjdk.java.net/browse/JDK-8148174


On Fri, Jan 22, 2016 at 2:30 PM, Stuart Marks  wrote:
>
>
> On 1/22/16 12:02 PM, Martin Buchholz wrote:
>>
>> I went "by the book" as you suggested and now throw
>> InvalidObjectException when size < 0.
>> (But I've been saying for a decade: if we're serious about
>> Serialization, it needs to be someone's full time job)
>
>
> "Admiral, if we go by the book, years could turn into decades."
>
> Thanks for the update; this looks great to me.
>
> s'marks

Re: OpenJDK8: java.util.stream.Stream.onClose

[Paul Sandoz]

> On 23 Jan 2016, at 10:50, Timo Kinnunen  wrote:
> 
> Hi,
> 
> The pipeline stages don’t really need to mutate themselves (as they can 
> mutate the Stream if needed). So they should be shareable between Streams, 
> alleviating some of cost of creating new copies of a Stream, right?

Yes, we want to avoid creating new stages (Stream instances) in the pipeline 
for stuff that can be associated more efficiently as state of the pipeline 
(attached to the head)

Paul.