From david.holmes at oracle.com  Mon Dec  1 00:09:40 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 01 Dec 2014 10:09:40 +1000
Subject: [8u60] RFR: 8038189: Add cross-platform compact profiles support
Message-ID: <547BB1C4.1000303@oracle.com>

Main bug is 8038189 but that is a closed bug, the open backport issue is:

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

Compact Profiles support was added in 8, but only for the Linux 
platform. I've now generalized this support to all the other platforms. 
This is an 8u only change, targetting 8u60, as soon as the jdk8u/dev 
starts accepting things for 8u60.

The changes are not that extensive - mostly generalizing the lists and 
accounting for different platforms putting files into different places 
(jre/lib/<arch> vs jre/lib vs jre/bin). It isn't necessary to produce 
detailed per-platform lists as files that don't exist simply don't get 
copied; but when files are obviously platform specific then I add them 
under suitable guards.

The biggest complexity comes from the debuginfo files, and in particular 
unzipped debuginfo files. This accounts for the bulk of the changes in 
profiles-includes.txt, as we try to identify the set of debug files that 
might exist for each library (and OSX is the main complication due to 
the .dSYM directory because the existing rules only copy files not 
directories). Suggestions for reducing the duplicated patterns would be 
appreciated.

Platform specific contents were determined in conjunction with 
examination of what Jigsaw is using in JDK 9 for the base module.

I tested all the main platforms (Windows, Linux, Solaris and OSX) and 
with/without zipping of debuginfo files. Note that Windows builds will 
not work with unzipped debuginfo files due to 8025936, but I checked 
that multiple debug info files were expanded into the right set of targets.

webrevs:

http://cr.openjdk.java.net/~dholmes/8038189/webrev.top/

make/Main.gmk:
  - Remove the os-check that constrained profiles to linux

http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk/

make/CreateJars.gmk:
  - Check for empty variables (Solaris doesn't like them)
  - Fix # # comments
  - Add explicit targets for the beanless classes with $ in them (the % 
substitution doesn't work on all platforms when $ is also present)

make/Images.gmk
  - Don't filter out server VM from compact profiles

make/Import.gmk
  - Add Info.plist to the exported files (for unzipped debuginfo files - 
this is a general fix not profiles specific so may warrant its own CR)

make/Profiles.gmk
  - Remove linux-only comment

make/Tools.gmk
  - Fix tool definitions to use $(PATH_SEP) and quote cp entries

make/profile-includes.txt
  - Bulk of changes as described above

make/profile-rtjar-includes.txt
  - Additional packages that exist on OSX only (but don't need to be 
conditionally added)
  - NOTE: if AIX or other platform add platform specific packages not 
already included by an enclosing package, then they will also need to be 
added

Thanks,
David


From amy.lu at oracle.com  Mon Dec  1 07:55:15 2014
From: amy.lu at oracle.com (Amy Lu)
Date: Mon, 01 Dec 2014 15:55:15 +0800
Subject: RFR: Update
	java/nio/charset/Charset/NIOCharsetAvailabilityTest.java
	to eliminate dependency on sun.misc.Launcher
In-Reply-To: <547877BD.3070400@oracle.com>
References: <54784FE3.2040508@oracle.com> <547877BD.3070400@oracle.com>
Message-ID: <547C1EE3.2080309@oracle.com>

On 11/28/14 9:25 PM, Alan Bateman wrote:
> On 28/11/2014 10:35, Amy Lu wrote:
>> jdk/test/java/nio/charset/Charset/NIOCharsetAvailabilityTest.java has 
>> dependency on sun.misc.Launcher
>> This fix is to remove above internal API dependency from the test.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8066131
>> webrev: http://cr.openjdk.java.net/~weijun/8066131/webrev.00/
> The change looks okay but I think the test needs a bigger overhaul. 
> The main thing is that the extensions directory goes away via JEP 220 
> so I think some of this test can go away too. The other thing is that 
> getClassList appears to treat URL paths as file paths so it might not 
> never have worked as expected on all platforms.
>
> -Alan.
Yes, the extensions part should be removed.

Please review the updated version: 
http://cr.openjdk.java.net/~weijun/8066131/webrev.01

Thanks,
Amy


From youdwei at linux.vnet.ibm.com  Mon Dec  1 08:06:22 2014
From: youdwei at linux.vnet.ibm.com (deven you)
Date: Mon, 1 Dec 2014 16:06:22 +0800
Subject: FilePermission Canonical path optimization
Message-ID: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>

Hi All,
 File.getCanonicalPath() is a very time-consuming method, we observed
significant performance degradation from some application's startup stage
with java.io.FilePermission. However, lazying load the calls to
getCanonicalPath() from java.ioFilePermission is straightforward and solve
this problem effectively. Openjdk bug[1]  tracks this bug and here is the
patch [2]. Could anyone take a look?

[1] https://bugs.openjdk.java.net/browse/JDK-8066211
[2] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.00/


From youdwei at linux.vnet.ibm.com  Mon Dec  1 08:06:53 2014
From: youdwei at linux.vnet.ibm.com (deven you)
Date: Mon, 1 Dec 2014 16:06:53 +0800
Subject: Better NewIO2 file system implementation for AIX platform
Message-ID: <CADsbJLmbk4s4CyeEqzHVU=QTx6EhRrOdD5B0yY==uaPZ9e6-Gg@mail.gmail.com>

Hi All,

Our current NIO2 file system support to AIX is very limited, hence I took
some time to try to complete it. Openjdk bug[1] tracks this bug and here is
my patch[2] which enhances the AIX file system especially by adding the
support by Implementing AixDosFileAttributeView.java and
AixUserDefinedFileAttributeView.java.

Could anyone take a look?


[1] https://bugs.openjdk.java.net/browse/JDK-8066212
[2] http://cr.openjdk.java.net/~youdwei/ojdk-909/webrev.00/

Thanks a lot!


From weijun.wang at oracle.com  Mon Dec  1 08:36:20 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 1 Dec 2014 16:36:20 +0800
Subject: FilePermission Canonical path optimization
In-Reply-To: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
Message-ID: <EBD2F710-DFBB-4C27-86EA-8E6825C86208@oracle.com>

Do you need some kind of synchronization on the get_dir_rec() method?

--Max

> On Dec 1, 2014, at 16:06, deven you <youdwei at linux.vnet.ibm.com> wrote:
> 
> Hi All,
> File.getCanonicalPath() is a very time-consuming method, we observed
> significant performance degradation from some application's startup stage
> with java.io.FilePermission. However, lazying load the calls to
> getCanonicalPath() from java.ioFilePermission is straightforward and solve
> this problem effectively. Openjdk bug[1]  tracks this bug and here is the
> patch [2]. Could anyone take a look?
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8066211
> [2] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.00/



From Alan.Bateman at oracle.com  Mon Dec  1 08:42:25 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 01 Dec 2014 08:42:25 +0000
Subject: Better NewIO2 file system implementation for AIX platform
In-Reply-To: <CADsbJLmbk4s4CyeEqzHVU=QTx6EhRrOdD5B0yY==uaPZ9e6-Gg@mail.gmail.com>
References: <CADsbJLmbk4s4CyeEqzHVU=QTx6EhRrOdD5B0yY==uaPZ9e6-Gg@mail.gmail.com>
Message-ID: <547C29F1.6040303@oracle.com>

On 01/12/2014 08:06, deven you wrote:
> Hi All,
>
> Our current NIO2 file system support to AIX is very limited, hence I took
> some time to try to complete it. Openjdk bug[1] tracks this bug and here is
> my patch[2] which enhances the AIX file system especially by adding the
> support by Implementing AixDosFileAttributeView.java and
> AixUserDefinedFileAttributeView.java.
>
> Could anyone take a look?
>
Does SAMBA or other CIFS servers running on AIX store the DOS attributes 
as extended attributes? I'm just wondering if the DOS file attribute 
view makes sense or not.

I suspect you will need to update a number of tests to (like 
FileSystem/Basic.java) and Files/CopyAndMove.java) to ensure that this 
new code is exercised by the tests.

A minor comment but we usually use 4-space indentation in the library 
native code.

-Alan


From ecki at zusammenkunft.net  Mon Dec  1 08:43:43 2014
From: ecki at zusammenkunft.net (Bernd)
Date: Mon, 1 Dec 2014 09:43:43 +0100
Subject: FilePermission Canonical path optimization
In-Reply-To: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
Message-ID: <CABOR3+xsbTmT-JgiKnstgTQJQBEwTiHqxggm1PYkKBxqyQk=Qw@mail.gmail.com>

Hello,

I thik the underscores in method and field do not match very the other
names in that file (or the JCL).

If I understand right, this is an optimization for the case a security
manager is not present? For the other case, maybe having absolute but not
canonical file names is an option? Or maybe have a special optimization for
JAVA_HOME prefixed names? Or does it help in that case as well?

Gruss
Bernd
Am 01.12.2014 09:18 schrieb "deven you" <youdwei at linux.vnet.ibm.com>:

> Hi All,
>  File.getCanonicalPath() is a very time-consuming method, we observed
> significant performance degradation from some application's startup stage
> with java.io.FilePermission. However, lazying load the calls to
> getCanonicalPath() from java.ioFilePermission is straightforward and solve
> this problem effectively. Openjdk bug[1]  tracks this bug and here is the
> patch [2]. Could anyone take a look?
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8066211
> [2] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.00/
>


From Alan.Bateman at oracle.com  Mon Dec  1 09:18:29 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 01 Dec 2014 09:18:29 +0000
Subject: [8u60] RFR: 8038189: Add cross-platform compact profiles support
In-Reply-To: <547BB1C4.1000303@oracle.com>
References: <547BB1C4.1000303@oracle.com>
Message-ID: <547C3265.2000506@oracle.com>

On 01/12/2014 00:09, David Holmes wrote:
> :
>
> Compact Profiles support was added in 8, but only for the Linux 
> platform. I've now generalized this support to all the other 
> platforms. This is an 8u only change, targetting 8u60, as soon as the 
> jdk8u/dev starts accepting things for 8u60.
>
Just to to David's comment, this change does not need to be pushed to 
JDK 9 because the way that images are created will be completely 
replaced once JEP 220 is targeted and pushed to JDK 9. When that happens 
then it the "profiles" target will work on all platforms there too.

-Alan


From erik.joelsson at oracle.com  Mon Dec  1 09:19:18 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 01 Dec 2014 10:19:18 +0100
Subject: [8u60] RFR: 8038189: Add cross-platform compact profiles support
In-Reply-To: <547BB1C4.1000303@oracle.com>
References: <547BB1C4.1000303@oracle.com>
Message-ID: <547C3296.8000000@oracle.com>

Hello David,

Most of it looks good, but profile-includes.txt could certainly benefit 
from some reduction in duplication. (Aside from the extension of the 
file itself, which I find a bit weird, but it's already there.) The two 
common structures that I can see are:
1. Expanding debuginfo files for macosx.
2. Assigning/expanding libraries to the correct variable.

For macosx debuginfo expanding, I would define a macro to something like 
this:

# Expand the contents of the .dSYM directories on macosx.
# Param 1 - debug files list
# Param 2 - libraries list
define expand-debuginfo
   $(if $(and $(filter-out true, $(ZIP_DEBUGINFO_FILES)), $(filter 
macosx, $(OPENJDK_TARGET_OS))), \
       $(foreach i, $1, $(addsuffix /Contents/Info.plist, $i)) \
           $(foreach i, $2, $(addsuffix /Contents/Resources/DWARF/$i, 
$(filter $i.%, $1))), \
       $1)
endef

And use it like this:

PROFILE_1_DEBUG_FILES := $(call expand-debuginfo, 
$(PROFILE_1_DEBUG_FILES), $(PROFILE_1_LIBRARIES))

Filtering out jsig can be done on the parameters at the macro call.

For the conditional addprefix of OPENJDK_TARGET_CPU_LEGACY_LIB, I would 
do something like:

ifeq (, $(findstring $(OPENJDK_TARGET_OS), windows macosx))
   LIB_SUBDIR := $(OPENJDK_TARGET_CPU_LEGACY_LIB)/
else
   LIB_SUBDIR :=
endif

And then always assign PROFILE_*_JRE_LIB_FILES with $(addprefix 
$(LIB_SUBDIR), ...). The conditional on Windows for assigning to 
...BIN_FILES or ...LIB_FILES I would leave in place since I don't think 
a macro solution would make it easier to understand.

/Erik


On 2014-12-01 01:09, David Holmes wrote:
> Main bug is 8038189 but that is a closed bug, the open backport issue is:
>
> https://bugs.openjdk.java.net/browse/JDK-8066200
>
> Compact Profiles support was added in 8, but only for the Linux 
> platform. I've now generalized this support to all the other 
> platforms. This is an 8u only change, targetting 8u60, as soon as the 
> jdk8u/dev starts accepting things for 8u60.
>
> The changes are not that extensive - mostly generalizing the lists and 
> accounting for different platforms putting files into different places 
> (jre/lib/<arch> vs jre/lib vs jre/bin). It isn't necessary to produce 
> detailed per-platform lists as files that don't exist simply don't get 
> copied; but when files are obviously platform specific then I add them 
> under suitable guards.
>
> The biggest complexity comes from the debuginfo files, and in 
> particular unzipped debuginfo files. This accounts for the bulk of the 
> changes in profiles-includes.txt, as we try to identify the set of 
> debug files that might exist for each library (and OSX is the main 
> complication due to the .dSYM directory because the existing rules 
> only copy files not directories). Suggestions for reducing the 
> duplicated patterns would be appreciated.
>
> Platform specific contents were determined in conjunction with 
> examination of what Jigsaw is using in JDK 9 for the base module.
>
> I tested all the main platforms (Windows, Linux, Solaris and OSX) and 
> with/without zipping of debuginfo files. Note that Windows builds will 
> not work with unzipped debuginfo files due to 8025936, but I checked 
> that multiple debug info files were expanded into the right set of 
> targets.
>
> webrevs:
>
> http://cr.openjdk.java.net/~dholmes/8038189/webrev.top/
>
> make/Main.gmk:
>  - Remove the os-check that constrained profiles to linux
>
> http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk/
>
> make/CreateJars.gmk:
>  - Check for empty variables (Solaris doesn't like them)
>  - Fix # # comments
>  - Add explicit targets for the beanless classes with $ in them (the % 
> substitution doesn't work on all platforms when $ is also present)
>
> make/Images.gmk
>  - Don't filter out server VM from compact profiles
>
> make/Import.gmk
>  - Add Info.plist to the exported files (for unzipped debuginfo files 
> - this is a general fix not profiles specific so may warrant its own CR)
>
> make/Profiles.gmk
>  - Remove linux-only comment
>
> make/Tools.gmk
>  - Fix tool definitions to use $(PATH_SEP) and quote cp entries
>
> make/profile-includes.txt
>  - Bulk of changes as described above
>
> make/profile-rtjar-includes.txt
>  - Additional packages that exist on OSX only (but don't need to be 
> conditionally added)
>  - NOTE: if AIX or other platform add platform specific packages not 
> already included by an enclosing package, then they will also need to 
> be added
>
> Thanks,
> David



From paul.sandoz at oracle.com  Mon Dec  1 10:46:18 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 1 Dec 2014 11:46:18 +0100
Subject: RFR(S) : 8039953 : [TESTBUG] Timeout
	java/lang/invoke/MethodHandles/CatchExceptionTest.java
In-Reply-To: <5479F60D.70403@oracle.com>
References: <5479F60D.70403@oracle.com>
Message-ID: <64AA5A1A-6A39-4C6C-904C-A85FF75712B5@oracle.com>

Hi Igor,

This looks ok. 

I like how you have factored out things into TimeLimitedRunner. Do you plan in a future patch to update lambda form test code that uses similar functionality?

Is the adjustment "timeout *= 0.9" necessary? does reduction by 10% make a difference?

Paul.

On Nov 29, 2014, at 5:36 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:

> http://cr.openjdk.java.net/~iignatyev/8039953/webrev.00
> 98 lines changed: 93 ins; 3 del; 2 mod;
> 
> Hi all,
> 
> Please review the patch:
> 
> Problem:
> on some configurations, java/lang/invoke/MethodHandles/CatchExceptionTest.java can timeout before all test cases are run
> 
> Fix:
> interrupt test execution if it's not enough time to continue
> 
> bug : https://bugs.openjdk.java.net/browse/JDK-8039953
> changes in testlibrary : https://bugs.openjdk.java.net/browse/JDK-8066191
> testing: locally
> 
> -- 
> Igor



From vladimir.x.ivanov at oracle.com  Mon Dec  1 10:29:59 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 01 Dec 2014 14:29:59 +0400
Subject: RFR(S) : 8039953 : [TESTBUG] Timeout
	java/lang/invoke/MethodHandles/CatchExceptionTest.java
In-Reply-To: <64AA5A1A-6A39-4C6C-904C-A85FF75712B5@oracle.com>
References: <5479F60D.70403@oracle.com>
	<64AA5A1A-6A39-4C6C-904C-A85FF75712B5@oracle.com>
Message-ID: <547C4327.7050101@oracle.com>

On 12/1/14, 2:46 PM, Paul Sandoz wrote:
> Hi Igor,
>
> This looks ok.
>
> I like how you have factored out things into TimeLimitedRunner. Do you plan in a future patch to update lambda form test code that uses similar functionality?
>

> Is the adjustment "timeout *= 0.9" necessary? does reduction by 10% make a difference?
It improves test stability (on highly loaded hosts and in heavy testing 
modes), but I doubt it's the right way to go. I'd measure actual startup 
time and adjust timeout value, but it seems jtreg doesn't provide such 
info.

So, I'd leave it as is for now, file an RFE on jtreg and rewrite this 
logic once support in jtreg is implemented.

Otherwise, looks good.

Best regards,
Vladimir Ivanov

>
> Paul.
>
> On Nov 29, 2014, at 5:36 PM, Igor Ignatyev <igor.ignatyev at oracle.com> wrote:
>
>> http://cr.openjdk.java.net/~iignatyev/8039953/webrev.00
>> 98 lines changed: 93 ins; 3 del; 2 mod;
>>
>> Hi all,
>>
>> Please review the patch:
>>
>> Problem:
>> on some configurations, java/lang/invoke/MethodHandles/CatchExceptionTest.java can timeout before all test cases are run
>>
>> Fix:
>> interrupt test execution if it's not enough time to continue
>>
>> bug : https://bugs.openjdk.java.net/browse/JDK-8039953
>> changes in testlibrary : https://bugs.openjdk.java.net/browse/JDK-8066191
>> testing: locally
>>
>> --
>> Igor
>


From igor.ignatyev at oracle.com  Mon Dec  1 11:39:04 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 01 Dec 2014 14:39:04 +0300
Subject: RFR(S) : 8039953 : [TESTBUG] Timeout
	java/lang/invoke/MethodHandles/CatchExceptionTest.java
In-Reply-To: <547C4327.7050101@oracle.com>
References: <5479F60D.70403@oracle.com>
	<64AA5A1A-6A39-4C6C-904C-A85FF75712B5@oracle.com>
	<547C4327.7050101@oracle.com>
Message-ID: <547C5358.7060308@oracle.com>

Paul/Vladimir,

thanks for review.

On 12/01/2014 01:29 PM, Vladimir Ivanov wrote:
> On 12/1/14, 2:46 PM, Paul Sandoz wrote:
>> Hi Igor,
>>
>> This looks ok.
>>
>> I like how you have factored out things into TimeLimitedRunner. Do you
>> plan in a future patch to update lambda form test code that uses
>> similar functionality?
yes, I plan to update existing tests as well as backport 
TimeLimitedRunner into hotspot and refactor hotspot tests.
>
>> Is the adjustment "timeout *= 0.9" necessary? does reduction by 10%
>> make a difference?
> It improves test stability (on highly loaded hosts and in heavy testing
> modes), but I doubt it's the right way to go. I'd measure actual startup
> time and adjust timeout value, but it seems jtreg doesn't provide such
> info.
>
> So, I'd leave it as is for now, file an RFE on jtreg and rewrite this
> logic once support in jtreg is implemented.
Yes, I also don't think that it's a right way, but it's the best that we 
can do now. Even if jtreg provides startup time, it won't help us w/ vm 
shutdown time estimation.
>
> Otherwise, looks good.
>
> Best regards,
> Vladimir Ivanov
>
>>
>> Paul.
>>
>> On Nov 29, 2014, at 5:36 PM, Igor Ignatyev <igor.ignatyev at oracle.com>
>> wrote:
>>
>>> http://cr.openjdk.java.net/~iignatyev/8039953/webrev.00
>>> 98 lines changed: 93 ins; 3 del; 2 mod;
>>>
>>> Hi all,
>>>
>>> Please review the patch:
>>>
>>> Problem:
>>> on some configurations,
>>> java/lang/invoke/MethodHandles/CatchExceptionTest.java can timeout
>>> before all test cases are run
>>>
>>> Fix:
>>> interrupt test execution if it's not enough time to continue
>>>
>>> bug : https://bugs.openjdk.java.net/browse/JDK-8039953
>>> changes in testlibrary :
>>> https://bugs.openjdk.java.net/browse/JDK-8066191
>>> testing: locally
>>>
>>> --
>>> Igor
>>


From jan.lahoda at oracle.com  Mon Dec  1 12:10:29 2014
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 01 Dec 2014 13:10:29 +0100
Subject: RFR 8065998: Avoid use of _ as a one-character identifier
Message-ID: <547C5AB5.2020404@oracle.com>

Hi,

In a preparation for JDK-8061549, I'd like to rename all uses of '_' as 
a one-character identifier in the jaxp and jdk repositories. All the 
uses I was able to find are in tests, and the identifier is used as a 
name of a catch parameter. The proposed new name is "ignore", but if a 
different name would be more appropriate, I'll be happy to use it.

Webrev for the jaxp repository:
http://cr.openjdk.java.net/~jlahoda/8065998/webrev.00/jaxp/

Webrev for the jdk repository:
http://cr.openjdk.java.net/~jlahoda/8065998/webrev.00/jdk/

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

Any comments are appreciated.

Thanks,
     Jan


From Alan.Bateman at oracle.com  Mon Dec  1 12:50:58 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 01 Dec 2014 12:50:58 +0000
Subject: FilePermission Canonical path optimization
In-Reply-To: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
Message-ID: <547C6432.5050003@oracle.com>

On 01/12/2014 08:06, deven you wrote:
> Hi All,
>   File.getCanonicalPath() is a very time-consuming method, we observed
> significant performance degradation from some application's startup stage
> with java.io.FilePermission. However, lazying load the calls to
> getCanonicalPath() from java.ioFilePermission is straightforward and solve
> this problem effectively. Openjdk bug[1]  tracks this bug and here is the
> patch [2]. Could anyone take a look?
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8066211
> [2] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.00/

Do you run with canonicalization cache enabled or disabled? While I 
don't agree with this cache, it seem to mostly eliminate complaints in 
this area after it was added (in JDK 1.4 I think).

As regards the patch then it is a bit ugly. Could you use cpath == null 
instead of introducing a flag? If a flag is required then I think it 
will need a better name. Also if init is split then it might be cleaner 
to have initMask and initCanonicalPath.

-Alan




From martijnverburg at gmail.com  Mon Dec  1 12:55:07 2014
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 1 Dec 2014 12:55:07 +0000
Subject: RFR 8065998: Avoid use of _ as a one-character identifier
In-Reply-To: <547C5AB5.2020404@oracle.com>
References: <547C5AB5.2020404@oracle.com>
Message-ID: <CAP7YuATW5pDBtx1sNLgwuvvfJxHSr8SMRhkQ+QGVZRs4+AN2Hg@mail.gmail.com>

If it helps "ignore" is a bit of a defacto std that I've seen many projects
use, it conveys exactly the right intent :-).

Cheers,
Martijn

On 1 December 2014 at 12:10, Jan Lahoda <jan.lahoda at oracle.com> wrote:

> Hi,
>
> In a preparation for JDK-8061549, I'd like to rename all uses of '_' as a
> one-character identifier in the jaxp and jdk repositories. All the uses I
> was able to find are in tests, and the identifier is used as a name of a
> catch parameter. The proposed new name is "ignore", but if a different name
> would be more appropriate, I'll be happy to use it.
>
> Webrev for the jaxp repository:
> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.00/jaxp/
>
> Webrev for the jdk repository:
> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.00/jdk/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8065998
>
> Any comments are appreciated.
>
> Thanks,
>     Jan
>


From andreas.lundblad at oracle.com  Mon Dec  1 13:01:03 2014
From: andreas.lundblad at oracle.com (Andreas Lundblad)
Date: Mon, 1 Dec 2014 14:01:03 +0100
Subject: RFR 8065998: Avoid use of _ as a one-character identifier
In-Reply-To: <547C5AB5.2020404@oracle.com>
References: <547C5AB5.2020404@oracle.com>
Message-ID: <20141201130102.GA26711@e6430>

On Mon, Dec 01, 2014 at 01:10:29PM +0100, Jan Lahoda wrote:
> Hi,
> 
> In a preparation for JDK-8061549, I'd like to rename all uses of '_'
> as a one-character identifier in the jaxp and jdk repositories. All
> the uses I was able to find are in tests, and the identifier is used
> as a name of a catch parameter. The proposed new name is "ignore",
> but if a different name would be more appropriate, I'll be happy to
> use it.

To me "ignore" signals "I don't care if this exception occurred." In tests, when an exception *should* occurr, I usually name the variable "expected". Ignore is a bit shorter though, so in the end it's a matter of taste I guess.

-- Andreas


From martijnverburg at gmail.com  Mon Dec  1 13:00:47 2014
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Mon, 1 Dec 2014 13:00:47 +0000
Subject: RFR 8065998: Avoid use of _ as a one-character identifier
In-Reply-To: <20141201130102.GA26711@e6430>
References: <547C5AB5.2020404@oracle.com>
	<20141201130102.GA26711@e6430>
Message-ID: <CAP7YuASyvd9NX=ThL_3wzLfZRrP8EQNnpM2GSCKSb3MLf1mAkg@mail.gmail.com>

I know this is descending into bike shedding - but I like that split of
definition, shamelessly stealing for my future projects, thanks!

Cheers,
Martijn

On 1 December 2014 at 13:01, Andreas Lundblad <andreas.lundblad at oracle.com>
wrote:

> On Mon, Dec 01, 2014 at 01:10:29PM +0100, Jan Lahoda wrote:
> > Hi,
> >
> > In a preparation for JDK-8061549, I'd like to rename all uses of '_'
> > as a one-character identifier in the jaxp and jdk repositories. All
> > the uses I was able to find are in tests, and the identifier is used
> > as a name of a catch parameter. The proposed new name is "ignore",
> > but if a different name would be more appropriate, I'll be happy to
> > use it.
>
> To me "ignore" signals "I don't care if this exception occurred." In
> tests, when an exception *should* occurr, I usually name the variable
> "expected". Ignore is a bit shorter though, so in the end it's a matter of
> taste I guess.
>
> -- Andreas
>


From Alan.Bateman at oracle.com  Mon Dec  1 13:20:20 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 01 Dec 2014 13:20:20 +0000
Subject: RFR 8065998: Avoid use of _ as a one-character identifier
In-Reply-To: <547C5AB5.2020404@oracle.com>
References: <547C5AB5.2020404@oracle.com>
Message-ID: <547C6B14.8020209@oracle.com>

On 01/12/2014 12:10, Jan Lahoda wrote:
> Hi,
>
> In a preparation for JDK-8061549, I'd like to rename all uses of '_' 
> as a one-character identifier in the jaxp and jdk repositories. All 
> the uses I was able to find are in tests, and the identifier is used 
> as a name of a catch parameter. The proposed new name is "ignore", but 
> if a different name would be more appropriate, I'll be happy to use it.
>
> Webrev for the jaxp repository:
> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.00/jaxp/
>
> Webrev for the jdk repository:
> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.00/jdk/

In JAXP test Bug4969089 then "ignore" looks a bit odd given that it's in 
a method declaration.

In TypeCheckMicroBenchmark then "ignore" is might be a misleading too 
given that the ArrayStoreException causes a CCE to be thrown.

-Alan






From jan.lahoda at oracle.com  Mon Dec  1 13:25:45 2014
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 01 Dec 2014 14:25:45 +0100
Subject: RFR 8065998: Avoid use of _ as a one-character identifier
In-Reply-To: <20141201130102.GA26711@e6430>
References: <547C5AB5.2020404@oracle.com> <20141201130102.GA26711@e6430>
Message-ID: <547C6C59.10807@oracle.com>

Thanks, makes sense. I've updated the patches so that in cases where (I 
think) the exception is expected, the name is "expected". I used 
"unused" in other cases where the fact that an exception was thrown is 
not ignored, but where the value of the exception parameter is not used.

I've forgot (sorry for that) that in jaxp tests, there are two unused 
method parameters named _ - I've named them "unused" as well.

Updated patches:
jaxp:
http://cr.openjdk.java.net/~jlahoda/8065998/webrev.01/jaxp/
jdk:
http://cr.openjdk.java.net/~jlahoda/8065998/webrev.01/jdk/

Does this make sense?

Thanks!

Jan

On 1.12.2014 14:01, Andreas Lundblad wrote:
> On Mon, Dec 01, 2014 at 01:10:29PM +0100, Jan Lahoda wrote:
>> Hi,
>>
>> In a preparation for JDK-8061549, I'd like to rename all uses of '_'
>> as a one-character identifier in the jaxp and jdk repositories. All
>> the uses I was able to find are in tests, and the identifier is used
>> as a name of a catch parameter. The proposed new name is "ignore",
>> but if a different name would be more appropriate, I'll be happy to
>> use it.
>
> To me "ignore" signals "I don't care if this exception occurred." In tests, when an exception *should* occurr, I usually name the variable "expected". Ignore is a bit shorter though, so in the end it's a matter of taste I guess.
>
> -- Andreas
>


From jan.lahoda at oracle.com  Mon Dec  1 13:37:17 2014
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Mon, 01 Dec 2014 14:37:17 +0100
Subject: RFR 8065998: Avoid use of _ as a one-character identifier
In-Reply-To: <547C6B14.8020209@oracle.com>
References: <547C5AB5.2020404@oracle.com> <547C6B14.8020209@oracle.com>
Message-ID: <547C6F0D.3010308@oracle.com>

On 1.12.2014 14:20, Alan Bateman wrote:
> On 01/12/2014 12:10, Jan Lahoda wrote:
>> Hi,
>>
>> In a preparation for JDK-8061549, I'd like to rename all uses of '_'
>> as a one-character identifier in the jaxp and jdk repositories. All
>> the uses I was able to find are in tests, and the identifier is used
>> as a name of a catch parameter. The proposed new name is "ignore", but
>> if a different name would be more appropriate, I'll be happy to use it.
>>
>> Webrev for the jaxp repository:
>> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.00/jaxp/
>>
>> Webrev for the jdk repository:
>> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.00/jdk/
>
> In JAXP test Bug4969089 then "ignore" looks a bit odd given that it's in
> a method declaration.

Sorry for that - I've forgot about these uses in method declarations. 
I've updated the patch to use "unused" for them.

>
> In TypeCheckMicroBenchmark then "ignore" is might be a misleading too
> given that the ArrayStoreException causes a CCE to be thrown.

I've updated the patch to use "expected" where the exception appears to 
be expected and "unused" where exception appears to be unexpected, but 
the variable is not used.

Updated patches:
jaxp:
http://cr.openjdk.java.net/~jlahoda/8065998/webrev.01/jaxp/
jdk:
http://cr.openjdk.java.net/~jlahoda/8065998/webrev.01/jdk/

Thanks,
     Jan

>
> -Alan
>
>
>
>


From chris.hegarty at oracle.com  Mon Dec  1 15:11:55 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 01 Dec 2014 15:11:55 +0000
Subject: RFR 8065998: Avoid use of _ as a one-character identifier
In-Reply-To: <547C6C59.10807@oracle.com>
References: <547C5AB5.2020404@oracle.com> <20141201130102.GA26711@e6430>
	<547C6C59.10807@oracle.com>
Message-ID: <547C853B.5040608@oracle.com>

The changes looks fine to me Jan.

-Chris.

On 01/12/14 13:25, Jan Lahoda wrote:
> Thanks, makes sense. I've updated the patches so that in cases where (I
> think) the exception is expected, the name is "expected". I used
> "unused" in other cases where the fact that an exception was thrown is
> not ignored, but where the value of the exception parameter is not used.
>
> I've forgot (sorry for that) that in jaxp tests, there are two unused
> method parameters named _ - I've named them "unused" as well.
>
> Updated patches:
> jaxp:
> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.01/jaxp/
> jdk:
> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.01/jdk/
>
> Does this make sense?
>
> Thanks!
>
> Jan
>
> On 1.12.2014 14:01, Andreas Lundblad wrote:
>> On Mon, Dec 01, 2014 at 01:10:29PM +0100, Jan Lahoda wrote:
>>> Hi,
>>>
>>> In a preparation for JDK-8061549, I'd like to rename all uses of '_'
>>> as a one-character identifier in the jaxp and jdk repositories. All
>>> the uses I was able to find are in tests, and the identifier is used
>>> as a name of a catch parameter. The proposed new name is "ignore",
>>> but if a different name would be more appropriate, I'll be happy to
>>> use it.
>>
>> To me "ignore" signals "I don't care if this exception occurred." In
>> tests, when an exception *should* occurr, I usually name the variable
>> "expected". Ignore is a bit shorter though, so in the end it's a
>> matter of taste I guess.
>>
>> -- Andreas
>>


From lance.andersen at oracle.com  Mon Dec  1 16:04:10 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 1 Dec 2014 11:04:10 -0500
Subject: RFR 8066261:  Typo in Connection.isValid
Message-ID: <BCC179B3-E163-4F66-97C6-94955BC582F5@oracle.com>

Hi all,

Looking for a reviewer for this trivial typo in Connection.isValid

hg diff
diff -r f619341171c0 src/java.sql/share/classes/java/sql/Connection.java
--- a/src/java.sql/share/classes/java/sql/Connection.java	Sat Nov 29 11:14:20 2014 -0500
+++ b/src/java.sql/share/classes/java/sql/Connection.java	Mon Dec 01 11:01:14 2014 -0500
@@ -1116,7 +1116,7 @@
          *
          * @return true if the connection is valid, false otherwise
          * @exception SQLException if the value supplied for <code>timeout</code>
-         * is less then 0
+         * is less than 0
          * @since 1.6
          *
          * @see java.sql.DatabaseMetaData#getClientInfoProperties
ljanders-mac:jdk ljanders$ 


Best
Lance


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





From daniel.fuchs at oracle.com  Mon Dec  1 16:25:28 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 01 Dec 2014 17:25:28 +0100
Subject: RFR 8066261:  Typo in Connection.isValid
In-Reply-To: <BCC179B3-E163-4F66-97C6-94955BC582F5@oracle.com>
References: <BCC179B3-E163-4F66-97C6-94955BC582F5@oracle.com>
Message-ID: <547C9678.6070903@oracle.com>

Looks good Lance.

I had to stare at the diff for a while before seeing it ;-)

best regards,

-- daniel

On 01/12/14 17:04, Lance Andersen wrote:
> Hi all,
>
> Looking for a reviewer for this trivial typo in Connection.isValid
>
> hg diff
> diff -r f619341171c0 src/java.sql/share/classes/java/sql/Connection.java
> --- a/src/java.sql/share/classes/java/sql/Connection.java	Sat Nov 29 11:14:20 2014 -0500
> +++ b/src/java.sql/share/classes/java/sql/Connection.java	Mon Dec 01 11:01:14 2014 -0500
> @@ -1116,7 +1116,7 @@
>            *
>            * @return true if the connection is valid, false otherwise
>            * @exception SQLException if the value supplied for <code>timeout</code>
> -         * is less then 0
> +         * is less than 0
>            * @since 1.6
>            *
>            * @see java.sql.DatabaseMetaData#getClientInfoProperties
> ljanders-mac:jdk ljanders$
>
>
> Best
> Lance
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>



From daniel.fuchs at oracle.com  Mon Dec  1 16:29:36 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 01 Dec 2014 17:29:36 +0100
Subject: RFR - 8065552: setAccessible(true) on fields of Class may throw a
	SecurityException
Message-ID: <547C9770.50007@oracle.com>

Hi,

Please find below a patch for:

8065552: setAccessible(true) on fields of Class may throw
          a SecurityException

webrev:
http://cr.openjdk.java.net/~dfuchs/webrev_8065552/webrev.00/

Description of the problem:

The following test case passes on 8u20 but fails on 8u40 and above:

  public class Test {
      public static void main(String[] args) throws Throwable {
          for (Field f : Class.class.getDeclaredFields()) {
              f.setAccessible(true);
          }
      }
  }

The fix for JDK-6642881 introduced a new private field to Class, named 
"classloader", whose accessibility can never be modified (from the 
default of non-accessible to accessible).

This issue manifests itself in Jython where, when the 
Options.respectJavaAccessibility is false (by default it is true), a 
SecurityException occurs when it tries to setAccessible(true) all 
declared fields on Class:


https://hg.python.org/jython/file/tip/src/org/python/core/PyJavaType.java#l405

The SecurityException is lost in the noise of other exceptions as the 
error propagates through the runtime. The observable symptom is
a NullPointerException which occurs when one tries to load the
Jython engine. With 8u40 it fails with exception:

java.lang.NullPointerException
at org.python.core.Py.recursiveIsInstance(Py.java:1861)
at org.python.core.Py.isInstance(Py.java:1828)
at org.python.core.__builtin__.isinstance(__builtin__.java:725)
at org.python.core.Py.displayException(Py.java:1009)
at org.python.core.PyException.printStackTrace(PyException.java:79)
at org.python.core.PyException.toString(PyException.java:98)
at org.apache.commons.logging.impl.SimpleLog.log(SimpleLog.java:329)
at org.apache.commons.logging.impl.SimpleLog.error(SimpleLog.java:525)
at org.apache.bsf.BSFManager.loadScriptingEngine(BSFManager.java:717)
...

The fix is to hide the field from reflection instead of simply
preventing it to be set as accessible.

best regards,

-- daniel


From lance.andersen at oracle.com  Mon Dec  1 16:30:27 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 1 Dec 2014 11:30:27 -0500
Subject: RFR 8066261:  Typo in Connection.isValid
In-Reply-To: <547C9678.6070903@oracle.com>
References: <BCC179B3-E163-4F66-97C6-94955BC582F5@oracle.com>
	<547C9678.6070903@oracle.com>
Message-ID: <C6DC746B-A4EC-4500-9481-34C37C8E1FD1@oracle.com>

Thank you Daniel.

Yes, it is easy to miss (which is probably why it was not caught before :-) )

Best,
Lance
On Dec 1, 2014, at 11:25 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:

> Looks good Lance.
> 
> I had to stare at the diff for a while before seeing it ;-)
> 
> best regards,
> 
> -- daniel
> 
> On 01/12/14 17:04, Lance Andersen wrote:
>> Hi all,
>> 
>> Looking for a reviewer for this trivial typo in Connection.isValid
>> 
>> hg diff
>> diff -r f619341171c0 src/java.sql/share/classes/java/sql/Connection.java
>> --- a/src/java.sql/share/classes/java/sql/Connection.java	Sat Nov 29 11:14:20 2014 -0500
>> +++ b/src/java.sql/share/classes/java/sql/Connection.java	Mon Dec 01 11:01:14 2014 -0500
>> @@ -1116,7 +1116,7 @@
>>           *
>>           * @return true if the connection is valid, false otherwise
>>           * @exception SQLException if the value supplied for <code>timeout</code>
>> -         * is less then 0
>> +         * is less than 0
>>           * @since 1.6
>>           *
>>           * @see java.sql.DatabaseMetaData#getClientInfoProperties
>> ljanders-mac:jdk ljanders$
>> 
>> 
>> Best
>> Lance
>> 
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>> 
>> 
>> 
> 



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





From lance.andersen at oracle.com  Mon Dec  1 16:52:19 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 1 Dec 2014 11:52:19 -0500
Subject: RFR 8060068 : Remove the static initializer block from DriverManager
Message-ID: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>

Hi all,

Looking for a review for this change to DriverManager to reduce the possibility on a deadlock on <clinit>. that I have been discussing with Mandy.


The change removes the static initializer block as well as the synchronized keyword from registerDriver.

The webrev can be found at http://cr.openjdk.java.net/%7Elancea/8060068/webrev.02/


Best,
Lance


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





From vitalyd at gmail.com  Mon Dec  1 17:27:16 2014
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Mon, 1 Dec 2014 12:27:16 -0500
Subject: Packing 2 data points into 1 field in ThreadPoolExecutor
In-Reply-To: <0F081861-ACBA-484E-9FA7-784D2EE4A023@icloud.com>
References: <F20EAFC5-2BD8-4787-901B-413B9D4A84E2@icloud.com>
	<0F081861-ACBA-484E-9FA7-784D2EE4A023@icloud.com>
Message-ID: <CAHjP37HSFqk7sHSZ6cQuCo9m3tousaEb5dM7NDwcGFrTg8=5Tg@mail.gmail.com>

It allows to manipulate two (related) bits of info atomically without
needing a lock and when efficient double CAS is not available (which it
isn't on supported archs).

Sent from my phone
On Dec 1, 2014 12:23 PM, "Alex Yursha" <alexyursha at gmail.com> wrote:

> Hi all,
>
> According to javadoc current implementation of ThreadPoolExecutor packs
> two conceptual fields ?workerCount? and ?runState? into one actual field
> ?ctl? of type AtomicInteger.
>
> Could you please explain are there any performance or other benefits for
> this? It seems to complicate the class design and I can?t find the positive
> side of this.
>
> Thanks,
> Alex
>
>


From martinrb at google.com  Mon Dec  1 17:27:46 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 1 Dec 2014 09:27:46 -0800
Subject: Packing 2 data points into 1 field in ThreadPoolExecutor
In-Reply-To: <0F081861-ACBA-484E-9FA7-784D2EE4A023@icloud.com>
References: <F20EAFC5-2BD8-4787-901B-413B9D4A84E2@icloud.com>
	<0F081861-ACBA-484E-9FA7-784D2EE4A023@icloud.com>
Message-ID: <CA+kOe08odwpUrUeeniY+j8SyraATDLbBSHWF+S2=1ECoT_R1wA@mail.gmail.com>

The only way to use atomic compare and set is to pack all your state
into a single primitive unit.  The largest we have is "long".  So we
regularly pack what the C folks would call bitfields into longs.

On Sat, Nov 29, 2014 at 8:13 AM, Alex Yursha <alexyursha at gmail.com> wrote:
> Hi all,
>
> According to javadoc current implementation of ThreadPoolExecutor packs two conceptual fields ?workerCount? and ?runState? into one actual field ?ctl? of type AtomicInteger.
>
> Could you please explain are there any performance or other benefits for this? It seems to complicate the class design and I can?t find the positive side of this.
>
> Thanks,
> Alex
>


From alex.yursha at icloud.com  Mon Dec  1 17:36:11 2014
From: alex.yursha at icloud.com (Alex Yursha)
Date: Mon, 01 Dec 2014 20:36:11 +0300
Subject: Packing 2 data points into 1 field in ThreadPoolExecutor
In-Reply-To: <CAHjP37HSFqk7sHSZ6cQuCo9m3tousaEb5dM7NDwcGFrTg8=5Tg@mail.gmail.com>
References: <F20EAFC5-2BD8-4787-901B-413B9D4A84E2@icloud.com>
	<0F081861-ACBA-484E-9FA7-784D2EE4A023@icloud.com>
	<CAHjP37HSFqk7sHSZ6cQuCo9m3tousaEb5dM7NDwcGFrTg8=5Tg@mail.gmail.com>
Message-ID: <EE38E6D3-3C7B-470C-910B-1A63B5514F9C@icloud.com>

Thanks a lot.

Seems like i need to look deeper into the JVM and hardware intrinsics to understand some pecularities of core libs class designs.

Sent from my iPhone

> On Dec 1, 2014, at 20:27, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> It allows to manipulate two (related) bits of info atomically without needing a lock and when efficient double CAS is not available (which it isn't on supported archs).
> 
> Sent from my phone
> 
>> On Dec 1, 2014 12:23 PM, "Alex Yursha" <alexyursha at gmail.com> wrote:
>> Hi all,
>> 
>> According to javadoc current implementation of ThreadPoolExecutor packs two conceptual fields ?workerCount? and ?runState? into one actual field ?ctl? of type AtomicInteger.
>> 
>> Could you please explain are there any performance or other benefits for this? It seems to complicate the class design and I can?t find the positive side of this.
>> 
>> Thanks,
>> Alex


From alex.yursha at icloud.com  Mon Dec  1 17:44:57 2014
From: alex.yursha at icloud.com (Alex Yursha)
Date: Mon, 01 Dec 2014 20:44:57 +0300
Subject: Packing 2 data points into 1 field in ThreadPoolExecutor
In-Reply-To: <CA+kOe08odwpUrUeeniY+j8SyraATDLbBSHWF+S2=1ECoT_R1wA@mail.gmail.com>
References: <F20EAFC5-2BD8-4787-901B-413B9D4A84E2@icloud.com>
	<0F081861-ACBA-484E-9FA7-784D2EE4A023@icloud.com>
	<CA+kOe08odwpUrUeeniY+j8SyraATDLbBSHWF+S2=1ECoT_R1wA@mail.gmail.com>
Message-ID: <CBACF05C-2856-43BB-8EAE-D46680D8AD05@icloud.com>

1. Do you mean 'the only way', except using a lock? 

2. I also cant imagine how we can use long primitive type for CAS atomicity without a lock if only its not an AtomicLong. Any hint here, please?

Thanks


Sent from my iPhone

> On Dec 1, 2014, at 20:27, Martin Buchholz <martinrb at google.com> wrote:
> 
> The only way to use atomic compare and set is to pack all your state
> into a single primitive unit.  The largest we have is "long".  So we
> regularly pack what the C folks would call bitfields into longs.
> 
>> On Sat, Nov 29, 2014 at 8:13 AM, Alex Yursha <alexyursha at gmail.com> wrote:
>> Hi all,
>> 
>> According to javadoc current implementation of ThreadPoolExecutor packs two conceptual fields ?workerCount? and ?runState? into one actual field ?ctl? of type AtomicInteger.
>> 
>> Could you please explain are there any performance or other benefits for this? It seems to complicate the class design and I can?t find the positive side of this.
>> 
>> Thanks,
>> Alex
>> 


From sean.coffey at oracle.com  Mon Dec  1 17:48:32 2014
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Mon, 01 Dec 2014 17:48:32 +0000
Subject: RFR - 8065552: setAccessible(true) on fields of Class may throw
	a SecurityException
In-Reply-To: <547C9770.50007@oracle.com>
References: <547C9770.50007@oracle.com>
Message-ID: <547CA9F0.9040100@oracle.com>

Looks fine to me Daniel. Thanks for handling it. I can work on the 7u 
backport if necessary.

on the test side would it be worth testing all public classes available 
(e.g in rt.jar ?) to ensure that
Field.setAccessible works as expected and that we don't hit this issue 
again ? It might be some
what of a heavy test for jtreg inclusion though.

regards,
Sean.

On 01/12/14 16:29, Daniel Fuchs wrote:
> Hi,
>
> Please find below a patch for:
>
> 8065552: setAccessible(true) on fields of Class may throw
>          a SecurityException
>
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8065552/webrev.00/
>
> Description of the problem:
>
> The following test case passes on 8u20 but fails on 8u40 and above:
>
>  public class Test {
>      public static void main(String[] args) throws Throwable {
>          for (Field f : Class.class.getDeclaredFields()) {
>              f.setAccessible(true);
>          }
>      }
>  }
>
> The fix for JDK-6642881 introduced a new private field to Class, named 
> "classloader", whose accessibility can never be modified (from the 
> default of non-accessible to accessible).
>
> This issue manifests itself in Jython where, when the 
> Options.respectJavaAccessibility is false (by default it is true), a 
> SecurityException occurs when it tries to setAccessible(true) all 
> declared fields on Class:
>
>
> https://hg.python.org/jython/file/tip/src/org/python/core/PyJavaType.java#l405 
>
>
> The SecurityException is lost in the noise of other exceptions as the 
> error propagates through the runtime. The observable symptom is
> a NullPointerException which occurs when one tries to load the
> Jython engine. With 8u40 it fails with exception:
>
> java.lang.NullPointerException
> at org.python.core.Py.recursiveIsInstance(Py.java:1861)
> at org.python.core.Py.isInstance(Py.java:1828)
> at org.python.core.__builtin__.isinstance(__builtin__.java:725)
> at org.python.core.Py.displayException(Py.java:1009)
> at org.python.core.PyException.printStackTrace(PyException.java:79)
> at org.python.core.PyException.toString(PyException.java:98)
> at org.apache.commons.logging.impl.SimpleLog.log(SimpleLog.java:329)
> at org.apache.commons.logging.impl.SimpleLog.error(SimpleLog.java:525)
> at org.apache.bsf.BSFManager.loadScriptingEngine(BSFManager.java:717)
> ...
>
> The fix is to hide the field from reflection instead of simply
> preventing it to be set as accessible.
>
> best regards,
>
> -- daniel



From joe.darcy at oracle.com  Mon Dec  1 17:54:34 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 01 Dec 2014 09:54:34 -0800
Subject: RFR 8065998: Avoid use of _ as a one-character identifier
In-Reply-To: <547C6F0D.3010308@oracle.com>
References: <547C5AB5.2020404@oracle.com> <547C6B14.8020209@oracle.com>
	<547C6F0D.3010308@oracle.com>
Message-ID: <547CAB5A.7050503@oracle.com>

Hi Jan,

The changes look good to me; thanks,

-Joe

On 12/1/2014 5:37 AM, Jan Lahoda wrote:
> On 1.12.2014 14:20, Alan Bateman wrote:
>> On 01/12/2014 12:10, Jan Lahoda wrote:
>>> Hi,
>>>
>>> In a preparation for JDK-8061549, I'd like to rename all uses of '_'
>>> as a one-character identifier in the jaxp and jdk repositories. All
>>> the uses I was able to find are in tests, and the identifier is used
>>> as a name of a catch parameter. The proposed new name is "ignore", but
>>> if a different name would be more appropriate, I'll be happy to use it.
>>>
>>> Webrev for the jaxp repository:
>>> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.00/jaxp/
>>>
>>> Webrev for the jdk repository:
>>> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.00/jdk/
>>
>> In JAXP test Bug4969089 then "ignore" looks a bit odd given that it's in
>> a method declaration.
>
> Sorry for that - I've forgot about these uses in method declarations. 
> I've updated the patch to use "unused" for them.
>
>>
>> In TypeCheckMicroBenchmark then "ignore" is might be a misleading too
>> given that the ArrayStoreException causes a CCE to be thrown.
>
> I've updated the patch to use "expected" where the exception appears 
> to be expected and "unused" where exception appears to be unexpected, 
> but the variable is not used.
>
> Updated patches:
> jaxp:
> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.01/jaxp/
> jdk:
> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.01/jdk/
>
> Thanks,
>     Jan
>
>>
>> -Alan
>>
>>
>>
>>



From vladimir.x.ivanov at oracle.com  Mon Dec  1 16:58:31 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 01 Dec 2014 20:58:31 +0400
Subject: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support eviction
Message-ID: <547C9E37.8080809@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8057020

There are 2 major LambdaForm caches: LambdaFormEditor-based and 
MethodTypeForm. The former is per-LambdaForm and the latter is per 
method type erased to basic types. The problem is that these caches 
don't support eviction, so they can hold LambdaForms forever.

Usually, it's not a problem since an application has very limited number 
of unique erased method types (e.g. on Octane/Nashorn it varies 1,5-3k 
shapes).

The fix is to use SoftReferences to keep LambdaForms alive as long as 
possible, but avoid throwing OOME until the caches are evicted. I 
experimented with WeakReferences, but it doesn't hold LambdaForms for 
long enough: LambdaForm cache hit rate degrades significantly and it 
negatively affects application startup and warmup, since every 
instantiated LambdaForm is precompiled to bytecode before usage.

Testing: jdk/java/lang/invoke/LFCache in stress mode + jck 
(api/java_lang/invoke), jdk/java/lang/invoke, jdk/java/util/streams, octane

Thanks!

Best regards,
Vladimir Ivanov


From martinrb at google.com  Mon Dec  1 18:32:41 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 1 Dec 2014 10:32:41 -0800
Subject: RFR - 8065552: setAccessible(true) on fields of Class may throw a
	SecurityException
In-Reply-To: <547CA9F0.9040100@oracle.com>
References: <547C9770.50007@oracle.com>
	<547CA9F0.9040100@oracle.com>
Message-ID: <CA+kOe09USUu1cD5XZAWrQdhG5YJSns65pjdyqW_pQS0TfpCdCQ@mail.gmail.com>

There's a whole set of invariant tests that should be applied to the entire jdk.
"Find all the classes that can be loaded, load them, and check all the
invariants you can think of!"

http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Class.getMethods-benchmark/test/java/lang/Class/getMethods/LoadAllClassesAndMethods.java.html

But do we have any professional test-writers?

On Mon, Dec 1, 2014 at 9:48 AM, Se?n Coffey <sean.coffey at oracle.com> wrote:
> on the test side would it be worth testing all public classes available (e.g
> in rt.jar ?) to ensure that
> Field.setAccessible works as expected and that we don't hit this issue again
> ? It might be some
> what of a heavy test for jtreg inclusion though.


From volker.simonis at gmail.com  Mon Dec  1 18:38:44 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 1 Dec 2014 19:38:44 +0100
Subject: Better NewIO2 file system implementation for AIX platform
In-Reply-To: <547C29F1.6040303@oracle.com>
References: <CADsbJLmbk4s4CyeEqzHVU=QTx6EhRrOdD5B0yY==uaPZ9e6-Gg@mail.gmail.com>
	<547C29F1.6040303@oracle.com>
Message-ID: <CA+3eh12YE97A6qYBVaPTp-GHi00b1R4Aws3z75F03LwbyxnAjw@mail.gmail.com>

On Mon, Dec 1, 2014 at 9:42 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 01/12/2014 08:06, deven you wrote:
>>
>> Hi All,
>>

Hi Deven,

thank you for your contribution. Please find my comments inline:

>> Our current NIO2 file system support to AIX is very limited, hence I took
>> some time to try to complete it. Openjdk bug[1] tracks this bug and here
>> is
>> my patch[2] which enhances the AIX file system especially by adding the
>> support by Implementing AixDosFileAttributeView.java and
>> AixUserDefinedFileAttributeView.java.
>>.
>> Could anyone take a look?
>>
> Does SAMBA or other CIFS servers running on AIX store the DOS attributes as
> extended attributes? I'm just wondering if the DOS file attribute view makes
> sense or not.
>

I'm by no means an expert in this area and just started to experiment
a little bit. While looking at tests like
'java/nio/file/attribute/DosFileAttributeView/Basic.java' I was
surprised to see that DosFileAttributeView can also be used on Linux.
While this makes sense for DOS file systems mounted into Linux which
map the DOS attributes to extended attributes on Unix it is probably
academic for file systems like ext2/3/4 which support extended
attributes as well. Unfortunately, tests like
DosFileAttributeView/Basic.java mostly test extended attributes on a
Linux files system because they only create and change files in /tmp
which is hardly ever a mounted DOS file system.

All that said, on AIX the JFS2 file system also supports extended
attributes (see
http://en.wikipedia.org/wiki/Extended_file_attributes). Hopefully the
CIFS client correctly maps the DOS attributes to extended user
attributes but I couldn't check that today because I couldn't find a
AIX box with CIFS client today. I'll try to find one tomorrow, but
perhaps Deven can already confirm this?

Following some more comments:

AixDosFileAttributeView.java
 - please replace "ext3" by "JFS2" in the comment as I'm not aware of
any ext3 support in AIX

AixFileStore.java
 - the detection if extended attributes are supported doesn't seem to
work. It seems like supportsFileAttributeView() has been just copied
from the corresponding Linux implementation but that won't work on
AIX. Please remove the ext3/4 stuff and do a real check (i.e. check if
the file system is JFS2 and if extended attributes have been enabled
on on the corresponding file system. See 'chfs -a ea=v2', 'man 2
getea', setea, ...).
 - the test DosFileAttributeView/Basic.java should succeed without
saying "DOS file attribute not supported."

AixNativeDispatcher.java
AixNativeDispatcher.c
 - you define 'getAixMountEntries()', 'queryMountEntrySize()' and the
corresponding native implementations but they don't seemed to be used
anywhere. Please remove this dead code. If you need to get a list of
all mounted file systems you could use 'getmntctl()' which is already
there and does exactly that.

> I suspect you will need to update a number of tests to (like
> FileSystem/Basic.java) and Files/CopyAndMove.java) to ensure that this new
> code is exercised by the tests.
>

Yes, could you please elaborate how you have tested your
implementation until now?

Thank you and best regards,
Volker

> A minor comment but we usually use 4-space indentation in the library native
> code.
>
> -Alan


From stuart.marks at oracle.com  Mon Dec  1 18:50:06 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 01 Dec 2014 10:50:06 -0800
Subject: RFR(s): 8035000: TEST_BUG: remove ActivationLibrary.DestroyThread
	and have callers call rmid.destroy() instead
In-Reply-To: <5473E8D1.8040606@oracle.com>
References: <5473E8D1.8040606@oracle.com>
Message-ID: <547CB85E.6050000@oracle.com>

Hi all, any reviewers for this one?

s'marks

On 11/24/14 6:26 PM, Stuart Marks wrote:
> Hi all,
>
> Here's another test cleanup fix. Basically this normalizes the shutdown/destroy
> policy for rmid processes that are started by RMI's test library in support of a
> few dozen of the RMI activation tests. The previous implementation was, well,
> confused, and it had a redundant timing loop that can be subsumed by other code
> in RMI's test library (JavaVM.waitFor).
>
> I've listed this as a "small" changeset even though lots of files have changed.
> In all but three or so of the files, the only change is from calling
> "ActivationLibrary.rmidCleanup(rmid)" to calling "rmid.cleanup()" which is a
> refactoring enabled by the cleanup. The real action is in the files
> test/java/rmi/testlibrary/ActivationLibrary.java and RMID.java.
>
> Webrev:
>
>      http://cr.openjdk.java.net/~smarks/reviews/8035000/webrev.0/
>
> Bug:
>
>      https://bugs.openjdk.java.net/browse/JDK-8035000
>
> Thanks,
>
> s'marks


From mandy.chung at oracle.com  Mon Dec  1 18:50:32 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 01 Dec 2014 10:50:32 -0800
Subject: RFR - 8065552: setAccessible(true) on fields of Class may throw
	a SecurityException
In-Reply-To: <547C9770.50007@oracle.com>
References: <547C9770.50007@oracle.com>
Message-ID: <547CB878.3030004@oracle.com>

On 12/1/14 8:29 AM, Daniel Fuchs wrote:
> 8065552: setAccessible(true) on fields of Class may throw
>          a SecurityException
>
> webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8065552/webrev.00/ 

Thanks for taking this on.  Looks okay in general.  The comment on 
Class.classLoader field - may simply say "this field is filtered from 
reflection access, i.e. getDeclaredField will throw NoSuchFieldException".

ClassDeclaredFieldsTest.java
    copyright year should be 2014.
    @summary - this test also verifies that Class.classLoader final 
private field is hidden from reflection access.
    line 86: nit:  can just call "new ThreadLocal<>"

Mandy


From lance.andersen at oracle.com  Mon Dec  1 18:53:54 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 1 Dec 2014 13:53:54 -0500
Subject: RFR(s): 8035000: TEST_BUG: remove ActivationLibrary.DestroyThread
	and have callers call rmid.destroy() instead
In-Reply-To: <547CB85E.6050000@oracle.com>
References: <5473E8D1.8040606@oracle.com> <547CB85E.6050000@oracle.com>
Message-ID: <61D1F880-2CD8-4D30-AAC2-A4D6CDC17B21@oracle.com>

Sorry Stuart,  I looked at this last week but guess I forgot to reply.

It looks fine and a nice clean up :-)

Best
Lance
On Dec 1, 2014, at 1:50 PM, Stuart Marks <stuart.marks at oracle.com> wrote:

> Hi all, any reviewers for this one?
> 
> s'marks
> 
> On 11/24/14 6:26 PM, Stuart Marks wrote:
>> Hi all,
>> 
>> Here's another test cleanup fix. Basically this normalizes the shutdown/destroy
>> policy for rmid processes that are started by RMI's test library in support of a
>> few dozen of the RMI activation tests. The previous implementation was, well,
>> confused, and it had a redundant timing loop that can be subsumed by other code
>> in RMI's test library (JavaVM.waitFor).
>> 
>> I've listed this as a "small" changeset even though lots of files have changed.
>> In all but three or so of the files, the only change is from calling
>> "ActivationLibrary.rmidCleanup(rmid)" to calling "rmid.cleanup()" which is a
>> refactoring enabled by the cleanup. The real action is in the files
>> test/java/rmi/testlibrary/ActivationLibrary.java and RMID.java.
>> 
>> Webrev:
>> 
>>     http://cr.openjdk.java.net/~smarks/reviews/8035000/webrev.0/
>> 
>> Bug:
>> 
>>     https://bugs.openjdk.java.net/browse/JDK-8035000
>> 
>> Thanks,
>> 
>> s'marks



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





From daniel.fuchs at oracle.com  Mon Dec  1 18:54:24 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 01 Dec 2014 19:54:24 +0100
Subject: RFR - 8065552: setAccessible(true) on fields of Class may throw
	a SecurityException
In-Reply-To: <547CA9F0.9040100@oracle.com>
References: <547C9770.50007@oracle.com> <547CA9F0.9040100@oracle.com>
Message-ID: <547CB960.7040402@oracle.com>

Hi Se?n,

On 01/12/14 18:48, Se?n Coffey wrote:
> Looks fine to me Daniel. Thanks for handling it. I can work on the 7u
> backport if necessary.

Thanks :-)

> on the test side would it be worth testing all public classes available
> (e.g in rt.jar ?) to ensure that
> Field.setAccessible works as expected and that we don't hit this issue
> again ? It might be some
> what of a heavy test for jtreg inclusion though.

It could be worth a try. But let's wait until JEP 220 is in.

best regards,

-- daniel


> regards,
> Sean.
>
> On 01/12/14 16:29, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a patch for:
>>
>> 8065552: setAccessible(true) on fields of Class may throw
>>          a SecurityException
>>
>> webrev:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8065552/webrev.00/
>>
>> Description of the problem:
>>
>> The following test case passes on 8u20 but fails on 8u40 and above:
>>
>>  public class Test {
>>      public static void main(String[] args) throws Throwable {
>>          for (Field f : Class.class.getDeclaredFields()) {
>>              f.setAccessible(true);
>>          }
>>      }
>>  }
>>
>> The fix for JDK-6642881 introduced a new private field to Class, named
>> "classloader", whose accessibility can never be modified (from the
>> default of non-accessible to accessible).
>>
>> This issue manifests itself in Jython where, when the
>> Options.respectJavaAccessibility is false (by default it is true), a
>> SecurityException occurs when it tries to setAccessible(true) all
>> declared fields on Class:
>>
>>
>> https://hg.python.org/jython/file/tip/src/org/python/core/PyJavaType.java#l405
>>
>>
>> The SecurityException is lost in the noise of other exceptions as the
>> error propagates through the runtime. The observable symptom is
>> a NullPointerException which occurs when one tries to load the
>> Jython engine. With 8u40 it fails with exception:
>>
>> java.lang.NullPointerException
>> at org.python.core.Py.recursiveIsInstance(Py.java:1861)
>> at org.python.core.Py.isInstance(Py.java:1828)
>> at org.python.core.__builtin__.isinstance(__builtin__.java:725)
>> at org.python.core.Py.displayException(Py.java:1009)
>> at org.python.core.PyException.printStackTrace(PyException.java:79)
>> at org.python.core.PyException.toString(PyException.java:98)
>> at org.apache.commons.logging.impl.SimpleLog.log(SimpleLog.java:329)
>> at org.apache.commons.logging.impl.SimpleLog.error(SimpleLog.java:525)
>> at org.apache.bsf.BSFManager.loadScriptingEngine(BSFManager.java:717)
>> ...
>>
>> The fix is to hide the field from reflection instead of simply
>> preventing it to be set as accessible.
>>
>> best regards,
>>
>> -- daniel
>



From igor.ignatyev at oracle.com  Mon Dec  1 18:58:35 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 01 Dec 2014 21:58:35 +0300
Subject: RFR(S) : 8039953 : [TESTBUG] Timeout
	java/lang/invoke/MethodHandles/CatchExceptionTest.java
In-Reply-To: <547C5358.7060308@oracle.com>
References: <5479F60D.70403@oracle.com>	<64AA5A1A-6A39-4C6C-904C-A85FF75712B5@oracle.com>	<547C4327.7050101@oracle.com>
	<547C5358.7060308@oracle.com>
Message-ID: <547CBA5B.8060404@oracle.com>

http://cr.openjdk.java.net/~iignatyev/8039953/webrev.01/

to have TimeLimitedRunner more general, I've added 'factor' argument to 
its ctor.

Thanks,
Igor

On 12/01/2014 02:39 PM, Igor Ignatyev wrote:
> Paul/Vladimir,
>
> thanks for review.
>
> On 12/01/2014 01:29 PM, Vladimir Ivanov wrote:
>> On 12/1/14, 2:46 PM, Paul Sandoz wrote:
>>> Hi Igor,
>>>
>>> This looks ok.
>>>
>>> I like how you have factored out things into TimeLimitedRunner. Do you
>>> plan in a future patch to update lambda form test code that uses
>>> similar functionality?
> yes, I plan to update existing tests as well as backport
> TimeLimitedRunner into hotspot and refactor hotspot tests.
>>
>>> Is the adjustment "timeout *= 0.9" necessary? does reduction by 10%
>>> make a difference?
>> It improves test stability (on highly loaded hosts and in heavy testing
>> modes), but I doubt it's the right way to go. I'd measure actual startup
>> time and adjust timeout value, but it seems jtreg doesn't provide such
>> info.
>>
>> So, I'd leave it as is for now, file an RFE on jtreg and rewrite this
>> logic once support in jtreg is implemented.
> Yes, I also don't think that it's a right way, but it's the best that we
> can do now. Even if jtreg provides startup time, it won't help us w/ vm
> shutdown time estimation.
>>
>> Otherwise, looks good.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>>>
>>> Paul.
>>>
>>> On Nov 29, 2014, at 5:36 PM, Igor Ignatyev <igor.ignatyev at oracle.com>
>>> wrote:
>>>
>>>> http://cr.openjdk.java.net/~iignatyev/8039953/webrev.00
>>>> 98 lines changed: 93 ins; 3 del; 2 mod;
>>>>
>>>> Hi all,
>>>>
>>>> Please review the patch:
>>>>
>>>> Problem:
>>>> on some configurations,
>>>> java/lang/invoke/MethodHandles/CatchExceptionTest.java can timeout
>>>> before all test cases are run
>>>>
>>>> Fix:
>>>> interrupt test execution if it's not enough time to continue
>>>>
>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8039953
>>>> changes in testlibrary :
>>>> https://bugs.openjdk.java.net/browse/JDK-8066191
>>>> testing: locally
>>>>
>>>> --
>>>> Igor
>>>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From vladimir.x.ivanov at oracle.com  Mon Dec  1 18:18:38 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 01 Dec 2014 22:18:38 +0400
Subject: RFR(S) : 8039953 : [TESTBUG] Timeout
	java/lang/invoke/MethodHandles/CatchExceptionTest.java
In-Reply-To: <547CBA5B.8060404@oracle.com>
References: <5479F60D.70403@oracle.com>	<64AA5A1A-6A39-4C6C-904C-A85FF75712B5@oracle.com>	<547C4327.7050101@oracle.com>
	<547C5358.7060308@oracle.com> <547CBA5B.8060404@oracle.com>
Message-ID: <547CB0FE.5050808@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

On 12/1/14, 10:58 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev/8039953/webrev.01/
>
> to have TimeLimitedRunner more general, I've added 'factor' argument to
> its ctor.
>
> Thanks,
> Igor
>
> On 12/01/2014 02:39 PM, Igor Ignatyev wrote:
>> Paul/Vladimir,
>>
>> thanks for review.
>>
>> On 12/01/2014 01:29 PM, Vladimir Ivanov wrote:
>>> On 12/1/14, 2:46 PM, Paul Sandoz wrote:
>>>> Hi Igor,
>>>>
>>>> This looks ok.
>>>>
>>>> I like how you have factored out things into TimeLimitedRunner. Do you
>>>> plan in a future patch to update lambda form test code that uses
>>>> similar functionality?
>> yes, I plan to update existing tests as well as backport
>> TimeLimitedRunner into hotspot and refactor hotspot tests.
>>>
>>>> Is the adjustment "timeout *= 0.9" necessary? does reduction by 10%
>>>> make a difference?
>>> It improves test stability (on highly loaded hosts and in heavy testing
>>> modes), but I doubt it's the right way to go. I'd measure actual startup
>>> time and adjust timeout value, but it seems jtreg doesn't provide such
>>> info.
>>>
>>> So, I'd leave it as is for now, file an RFE on jtreg and rewrite this
>>> logic once support in jtreg is implemented.
>> Yes, I also don't think that it's a right way, but it's the best that we
>> can do now. Even if jtreg provides startup time, it won't help us w/ vm
>> shutdown time estimation.
>>>
>>> Otherwise, looks good.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>>>
>>>> Paul.
>>>>
>>>> On Nov 29, 2014, at 5:36 PM, Igor Ignatyev <igor.ignatyev at oracle.com>
>>>> wrote:
>>>>
>>>>> http://cr.openjdk.java.net/~iignatyev/8039953/webrev.00
>>>>> 98 lines changed: 93 ins; 3 del; 2 mod;
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Please review the patch:
>>>>>
>>>>> Problem:
>>>>> on some configurations,
>>>>> java/lang/invoke/MethodHandles/CatchExceptionTest.java can timeout
>>>>> before all test cases are run
>>>>>
>>>>> Fix:
>>>>> interrupt test execution if it's not enough time to continue
>>>>>
>>>>> bug : https://bugs.openjdk.java.net/browse/JDK-8039953
>>>>> changes in testlibrary :
>>>>> https://bugs.openjdk.java.net/browse/JDK-8066191
>>>>> testing: locally
>>>>>
>>>>> --
>>>>> Igor
>>>>
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


From mandy.chung at oracle.com  Mon Dec  1 19:17:43 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 01 Dec 2014 11:17:43 -0800
Subject: RFR - 8065552: setAccessible(true) on fields of Class may throw
	a SecurityException
In-Reply-To: <547CB960.7040402@oracle.com>
References: <547C9770.50007@oracle.com> <547CA9F0.9040100@oracle.com>
	<547CB960.7040402@oracle.com>
Message-ID: <547CBED7.1010607@oracle.com>

On 12/1/14 10:54 AM, Daniel Fuchs wrote:
>
>> on the test side would it be worth testing all public classes available
>> (e.g in rt.jar ?) to ensure that
>> Field.setAccessible works as expected and that we don't hit this issue
>> again ? It might be some
>> what of a heavy test for jtreg inclusion though.
>
> It could be worth a try. But let's wait until JEP 220 is in.
>

There will be a test to load all classes when we move to the modular image:
http://hg.openjdk.java.net/jigsaw/m2/jdk/file/26a4132a2fa9/test/jdk/internal/jimage/VerifyJimage.java

Mandy


From daniel.fuchs at oracle.com  Mon Dec  1 19:34:05 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 01 Dec 2014 20:34:05 +0100
Subject: RFR - 8065552: setAccessible(true) on fields of Class may throw
	a SecurityException
In-Reply-To: <547CB878.3030004@oracle.com>
References: <547C9770.50007@oracle.com> <547CB878.3030004@oracle.com>
Message-ID: <547CC2AD.9000401@oracle.com>

Hi Mandy,

Thanks for the review!

The new webrev is here:
http://cr.openjdk.java.net/~dfuchs/webrev_8065552/webrev.01/

The compiler doesn't want the diamond operator at line 86.
It says that it cannot infer the type argument.
So I left it unchanged. The rest of your comments are in.

best regards,

-- daniel


On 01/12/14 19:50, Mandy Chung wrote:
> On 12/1/14 8:29 AM, Daniel Fuchs wrote:
>> 8065552: setAccessible(true) on fields of Class may throw
>>          a SecurityException
>>
>> webrev:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8065552/webrev.00/
>
> Thanks for taking this on.  Looks okay in general.  The comment on
> Class.classLoader field - may simply say "this field is filtered from
> reflection access, i.e. getDeclaredField will throw NoSuchFieldException".
>
> ClassDeclaredFieldsTest.java
>     copyright year should be 2014.
>     @summary - this test also verifies that Class.classLoader final
> private field is hidden from reflection access.
>     line 86: nit:  can just call "new ThreadLocal<>"
>
> Mandy



From stuart.marks at oracle.com  Mon Dec  1 19:35:38 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 01 Dec 2014 11:35:38 -0800
Subject: RFR: 8065870 Update JAX-WS RI integration to latest version
	(2.2.11-b141124.1933)
In-Reply-To: <54770AB6.6050806@oracle.com>
References: <54770AB6.6050806@oracle.com>
Message-ID: <547CC30A.1020207@oracle.com>

Hi Miran,

I'm pretty distant from the JAX-WS code, but I looked through all of the files 
and most of the changes seem sensible. There are a few things that are 
questionable though.

** 
src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java

The catch-and-ignore of Throwable at line 565 seems questionable. Wouldn't it be 
better to catch a few specific exception types that might be thrown from 
setProperty()?

** 
src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/resources/Messages_en.properties

The copyright year is changed from 2013 to 2012.

The unknown character replacement (line 277) is replaced with a '?', though I'm 
not sure what's really happening here since webrev might be mishandling 
non-ascii characters. If this is intended to be an ascii file, shouldn't the 
replacement be a plain single quote (') ?

** 
src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle.properties

The version numbers in this file seem to be moved forward, but the copyright is 
updated from 2014 to 2012. The same appears to be true of the localized versions 
of this file.

** 
src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties

Copyright years 2014 => 2012 again. Also check localized versions of this file.

** 
src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle.properties

Copyright years 2013 => 2012. Possibly incorrect replacement "???" for unknown 
character in original file.

** src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/version.properties

Copyright years 2014 => 2013.

==========

Nothing earth-shattering here. If you want to push this changeset and fix up 
these issues later (if indeed they need to be fixed up), I'd be fine with that.

s'marks





On 11/27/14 3:27 AM, Miroslav Kos wrote:
> Hi,
> there is a bulk update of JAX-B/WS from upstream projects -
> webrev: http://cr.openjdk.java.net/~mkos/8065870/jaxws.00/
> more details in issue desc: https://bugs.openjdk.java.net/browse/JDK-8065870
>
> Could I ask for a review?
>
> It seems quite big (1126 lines changed) but there are just minor changes/fixes.
>
> Thanks
> Miran


From mandy.chung at oracle.com  Mon Dec  1 19:48:35 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 01 Dec 2014 11:48:35 -0800
Subject: RFR - 8065552: setAccessible(true) on fields of Class may throw
	a SecurityException
In-Reply-To: <547CC2AD.9000401@oracle.com>
References: <547C9770.50007@oracle.com> <547CB878.3030004@oracle.com>
	<547CC2AD.9000401@oracle.com>
Message-ID: <547CC613.2030804@oracle.com>

On 12/1/14 11:34 AM, Daniel Fuchs wrote:
> Hi Mandy,
>
> Thanks for the review!
>
> The new webrev is here:
> http://cr.openjdk.java.net/~dfuchs/webrev_8065552/webrev.01/

Looks good.

Mandy


From martinrb at google.com  Mon Dec  1 20:09:48 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 1 Dec 2014 12:09:48 -0800
Subject: RFR: 8061950: Class.getMethods() exhibits quadratic time
	complexity
In-Reply-To: <547B90A0.1080508@gmail.com>
References: <CA+kOe08YW=MG+W6sMOZS9cvLXMtVa1OX7u2P0LxEjfoeGT4CGw@mail.gmail.com>
	<900D2AE3-B3A6-4B1B-B25A-C564B10334AA@oracle.com>
	<54492255.3040108@gmail.com>
	<EAE058BE-B5F0-4F53-A9F8-36F3BFEEA703@oracle.com>
	<544D58D4.7020909@gmail.com> <544D7B74.5060607@gmail.com>
	<FF8A5786-0840-45D9-8B36-0B60BB2DBA98@oracle.com>
	<5450CEE9.7060707@gmail.com>
	<F81AE132-D4FE-48F6-AAA8-A3580F5194B4@oracle.com>
	<545120D2.5010301@gmail.com> <54526D10.5060101@gmail.com>
	<CA+kOe0_nf-fasgbhQA8zJ60wTxpAfuOYEC2YAvtHE6-awJsBrA@mail.gmail.com>
	<54551D2F.407@gmail.com> <545A572D.3050608@gmail.com>
	<F15D5F8E-2E65-4243-A7AA-C30CF4DBF935@oracle.com>
	<547B90A0.1080508@gmail.com>
Message-ID: <CA+kOe0-bC9WwOhkb6555oxGBHbLOX5aW7H3aB4Y187Q1CTpP5g@mail.gmail.com>

Looking at Peter's work here is still on my long TODO list, but I was
hoping first to get in my concurrency correctness fixes for core
reflection, which conflicts slightly...

On Sun, Nov 30, 2014 at 1:48 PM, Peter Levart <peter.levart at gmail.com> wrote:
> Hi Joel,
>
> I managed to find some time to create some tests for this patch:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods/webrev.07/
>
> Both MethodTable and HashArray unit tests are provided. I had to create a
> special TestProxy to access package-private classes from the tests.
>
> There are no changes to j.l.Class or j.l.r.Method from webrev.06 (I just
> re-based them to current tip).
>
> I also included the patch to StarInheritance test that I forgot to include
> in webrev.06.
>
> Comments inline...
>
> On 11/13/2014 10:39 AM, Joel Borggr?n-Franck wrote:
>>
>> Hi Peter,
>>
>> As always, thanks for taking a look at this,
>>
>> This is quite big so in order to make this more approachable perhaps you
>> can split the patch up into a series? If you start with creating the
>> MethodTable interface, adding tests for how the interface should behave and
>> refactored the current MethodArray into implementing that interface while
>> also changing the lookup logic that would be easier to review.
>
>
> Well, there's not much to refactor in MethodArray when implementing
> MethodTable. They are two entirely different APIs with entirely different
> implementations.
>
>> Then you could add different implementations of MethodTable (with
>> additional unit tests) as follow up patches.
>
>
> You can view the MethodTable.SimpleArrayImpl as the basic implementation of
> the MethodTable API  and a replacement for MethodArray.
> MethodTable.HashArrayImpl is the alternative implementation for bigger
> sizes. The same unit tests are executed against both implementations.
>
>> I am a bit concerned about the size and scope of the implementations. In
>> general I would prefer if you targeted these to the precise need of core
>> reflection today. If you want to expand these to general purpose data
>> structures (even internal ones) I think that is a larger effort.
>
>
> I stripped HashArray and only left those methods that are needed to
> implement MethodTable API and execute the tests.
>
>> In general I think the changes to Class are sound, but there is a slight
>> change in the default method pruning. The call to removeLessSpecifics was
>> deliberately placed at the end, so that all default methods would be present
>> (the algorithm is sensitive to the order of pair vise comparisons). Since we
>> add methods in a deterministic order, I think consolidate() as you go should
>> result in the same set of methods, but I haven?t 100% convinced myself of
>> this just yet.
>
>
> I think it results in the same methods. I haven't yet found an example where
> it would result in different set of methods. All JDK classes return same
> methods with current implementation as with patched one.
>
>> Have you double checked that all methods returning root Method/Ctors are
>> private?
>
>
> I checked all usages of private methods that I have changed and are now
> returning root objects and made sure those are copied before being exposed
> to the outside or being modified.
>
> Regards, Peter
>
>
>> On 5 nov 2014, at 17:58, Peter Levart <peter.levart at gmail.com> wrote:
>>
>>> Here's new webrev:
>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods/webrev.06/
>>>
>>>
>>> The optimizations made from webrev.05 are:
>>>
>>> - getMethod() skips construction of MethodTable if there are no
>>> (super)interfaces.
>>> - getMethods() returns just declared public methods if there are no
>>> superclass and no (super)interfaces.
>>> - comparing method parameter types is optimized by adding two methods to
>>> Method/LangReflectAccess/ReflectionFactory.
>>>
>>> New MethodTable implementation based on a linear-probe hash table is a
>>> space/garbage improvement. I took IdentityHashMap, removed unneeded stuff
>>> and modified it's API. The result is a HashArray. It's API is similar in
>>> function and form to java.util.Map, but doesn't use separate keys and
>>> values. An element of HashArray is a key and a value at the same time.
>>> Elements are always non-null, so the method return values are unambiguous.
>>> As HashArray is a linear-probe hash table and there are no Map.Entry objects
>>> involved, the underlying data structure is very simple and memory efficient.
>>> It is just a sparse array of elements with length that is always a power of
>>> two and larger than 3 * size / 2. It also features overriddable element
>>> equals/hashCode methods. I made it a separate generic class because I think
>>> it can find it's usage elsewhere (for example as a cannonicalizing cache).
>>>
>>> Since HashArray based MethodTable is more space-efficient I moved the
>>> line between simple array based and HashArray based MethodTable down to 20
>>> elements to minimize the worst-case scenario effect. Calling getMethods() on
>>> all rt.jar classes now constructs about 3/4 simple array based and 1/4
>>> HashArray based MethodTables.
>>>
>> HashArray.java:
>>
>> I was hoping for a decent set of unit tests for the new HashArray<T> data
>> structure. I think it is reasonable to test the corner cases/non-trivial
>> areas of the table (closeDeletion(), rezise() etc). Perhaps also run these
>> over the simple implementation. Also, please document thread safety (there
>> is none IFAICT it should just be noted).
>>
>> Instead of using inheritance to change the behavior of equals() and hash()
>> you could give it two lambdas at table creation time, a ToIntFunction<T> for
>> hash() and a BiPredicate<T,T> for equals(). Might not give you the
>> performance we need though.
>>
>> Note that the file doesn?t actually compile in jdk9/dev, you have two
>> unchecked casts and we build with -Werror.
>>
>> MethodTable.java
>>
>> HashMapImpl is missing serialVersionUID, but it looks like this class
>> won?t be needed at all.
>>
>>
>>> Here's also Martin's ManyMethodsBenchmark:
>>>
>>> Original:
>>>
>>> Base class load time: 129.95 ms
>>> getDeclaredMethods: 65521 methods, 36.58 ms total time, 0.0006 ms per
>>> method
>>> getMethods        : 65530 methods, 47.43 ms total time, 0.0007 ms per
>>> method
>>> Derived class load time: 32216.09 ms
>>> getDeclaredMethods: 65521 methods, 35.05 ms total time, 0.0005 ms per
>>> method
>>> getMethods        : 65530 methods, 8068.66 ms total time, 0.1231 ms per
>>> method
>>>
>>>
>>> Patched (using HashArray based MethodTable):
>>>
>>> Base class load time: 126.00 ms
>>> getDeclaredMethods: 65521 methods, 36.83 ms total time, 0.0006 ms per
>>> method
>>> getMethods        : 65530 methods, 45.08 ms total time, 0.0007 ms per
>>> method
>>> Derived class load time: 31865.27 ms
>>> getDeclaredMethods: 65521 methods, 35.01 ms total time, 0.0005 ms per
>>> method
>>> getMethods        : 65530 methods, 78.05 ms total time, 0.0012 ms per
>>> method
>>>
>>>
>>> All 86 jtreg test in java.lang/Class/ and java/lang/reflect/ still pass.
>>>
>> I have seen discussion about allocation, should we measure and compare?
>> You can probably use the Hotspot impl of ThreadMXBean to get the allocation
>> in the tread.
>>
>> Also, it might be time to fix the boolean parameters:
>>
>> 2741         Method[] declaredMethods = privateGetDeclaredMethods(true);
>> 2742         Class<?> superclass = getSuperclass();
>> 2743         Class<?>[] interfaces = getInterfaces(false);
>>
>> Perhaps just add boolean constants somewhere so that it is easier to
>> decode.
>>
>> 2741         Method[] declaredMethods =
>> privateGetDeclaredMethods(PUBLIC_METHOD_ONLY);
>> 2742         Class<?> superclass = getSuperclass();
>> 2743         Class<?>[] interfaces = getInterfaces(NO_COPY_RESULT);
>>
>> or so.
>>
>> HashArray.java:
>>
>> 155         if (lookupObj == null) throw new NullPointerException();
>>
>> use Objects.requreNonNull() ?
>>
>> cheers
>> /Joel
>>
>


From martinrb at google.com  Mon Dec  1 20:13:24 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 1 Dec 2014 12:13:24 -0800
Subject: RFR: 8065804: JEP 171: Clarifications/corrections for fence
	intrinsics
In-Reply-To: <5473A344.8090302@oracle.com>
References: <CA+kOe08RfnkJ4Dit8ng7HQaSuDer_pA0i4t568uAGMg9dzujhg@mail.gmail.com>
	<5473A344.8090302@oracle.com>
Message-ID: <CA+kOe0-mVZAJtFvT0jSU9+oLy9K4GdArXUSYpMOinuXdaTrjfw@mail.gmail.com>

On Mon, Nov 24, 2014 at 1:29 PM, Aleksey Shipilev
<aleksey.shipilev at oracle.com> wrote:
> I think "implies the effect of C++11" is too strong wording. "related"
> might be more appropriate.

I've been struggling to come up with better wording.  The latest webrev says

+     * Corresponds to C11 atomic_thread_fence(memory_order_acquire).

but I'm not totally happy with that either. "Essentially equivalent to" ?


From Ulf.Zibis at CoSoCo.de  Mon Dec  1 20:27:36 2014
From: Ulf.Zibis at CoSoCo.de (Ulf Zibis)
Date: Mon, 01 Dec 2014 21:27:36 +0100
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>
Message-ID: <547CCF38.4030108@CoSoCo.de>

Hi Lance,

to me it's irritating, why there are 2 methods:
- initDriversIfNeeded()
- loadInitialDrivers()
I would combine both to one method.
In lines 90 + 92 there are double spaces.

-Ulf


Am 01.12.2014 um 17:52 schrieb Lance Andersen:
> Hi all,
>
> Looking for a review for this change to DriverManager to reduce the possibility on a deadlock on <clinit>. that I have been discussing with Mandy.
>
>
> The change removes the static initializer block as well as the synchronized keyword from registerDriver.
>
> The webrev can be found at http://cr.openjdk.java.net/%7Elancea/8060068/webrev.02/
>
>
> Best,
> Lance
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>
>



From lance.andersen at oracle.com  Mon Dec  1 20:39:48 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 1 Dec 2014 15:39:48 -0500
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <547CCF38.4030108@CoSoCo.de>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>
	<547CCF38.4030108@CoSoCo.de>
Message-ID: <A57AD2B9-F1CC-43F3-B461-6BAD916474AB@oracle.com>

Hi Ulf,

thank you for the input and  suggestion


On Dec 1, 2014, at 3:27 PM, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:

> Hi Lance,
> 
> to me it's irritating, why there are 2 methods:
> - initDriversIfNeeded()
> - loadInitialDrivers()
> I would combine both to one method.

Mandy had asked me previously about this and here was my reply

-----------------
The reason I had the two methods was to further reduce contention checking to see if the drivers need to be loaded.  getConnection  gets called frequently so I thought that not having the initial check synchronized would be more efficient
-----------------


I think the code gets harder to read if I have one large synchronized block  assuming I move everything from loadInitialDrivers into the  existing synchronized block in initDriversIfNeeded.

> In lines 90 + 92 there are double spaces.

Thank you.
> 
> -Ulf
> 
> 

Best,
Lance
> Am 01.12.2014 um 17:52 schrieb Lance Andersen:
>> Hi all,
>> 
>> Looking for a review for this change to DriverManager to reduce the possibility on a deadlock on <clinit>. that I have been discussing with Mandy.
>> 
>> 
>> The change removes the static initializer block as well as the synchronized keyword from registerDriver.
>> 
>> The webrev can be found at http://cr.openjdk.java.net/%7Elancea/8060068/webrev.02/
>> 
>> 
>> Best,
>> Lance
>> 
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>> 
>> 
>> 
>> 
> 



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





From martinrb at google.com  Mon Dec  1 20:40:51 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 1 Dec 2014 12:40:51 -0800
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <CAPUmR1aZNSdk5znSfp4ei1M+ZK1M06uEYujH3Z2_B1wtOqMMhw@mail.gmail.com>
References: <CA+kOe08RfnkJ4Dit8ng7HQaSuDer_pA0i4t568uAGMg9dzujhg@mail.gmail.com>
	<5473A344.8090302@oracle.com>
	<CA+kOe0-KiKKNM-LyYvjZiXOGMF7c4FsHifcDq-ZZ65Bb1J=LLA@mail.gmail.com>
	<B84AA20B-5714-4FF0-AB17-E918395C9DDB@oracle.com>
	<21DC5F06-9597-4CCB-8A25-5CC354A0BCE5@flyingtroika.com>
	<CAPUmR1aZNSdk5znSfp4ei1M+ZK1M06uEYujH3Z2_B1wtOqMMhw@mail.gmail.com>
Message-ID: <CA+kOe0-FYxQ0_EgQULwuy_eJi5YfvVZ_rGYj0BGkj_fxWK7SvQ@mail.gmail.com>

Hans,

(Thanks for your excellent work on C/C++ 11 and your eternal patience)

On Tue, Nov 25, 2014 at 11:15 AM, Hans Boehm <boehm at acm.org> wrote:
> It seems to me that a (dubiuously named) loadFence is intended to have
> essentially the same semantics as the (perhaps slightly less dubiously
> named) C++ atomic_thread_fence(memory_order_acquire), and a storeFence
> matches atomic_thread_fence(memory_order_release).  The C++ standard and,
> even more so, Mark Batty's work have a precise definition of what those mean
> in terms of implied "synchronizes with" relationships.
>
> It looks to me like this whole implementation model for volatiles in terms
> of fences is fundamentally doomed, and it probably makes more sense to get
> rid of it rather than spending time on renaming it (though we just did the
> latter in Android to avoid similar confusion about semantics).  It's

I would also like to see alignment to leverage the technical and
cultural work done on C11.  I would like to see Unsafe get
load-acquire and store-release methods and these should be used in
preference to fences where possible.  I'd like to see the C11 wording
reused as much as possible.  The meanings of the words "acquire" and
"release" are now "owned" by the C11 community and we should tag
along.

A better API for Unsafe would be

putOrdered -> storeRelease
put -> storeRelaxed
(ordinary volatile write) -> store (default is sequential consistent)

etc ...

but the high cost of renaming methods in Unsafe probably makes this a
no-go, even though Unsafe is not a public API in theory.

At least the documentation of all the methods should indicate what the
memory effects and the corresponding C++11 memory model interpretation
is.

E.g. Unsafe.compareAndSwap should document the memory effects, i.e.
sequential consistency.

Unsafe doesn't currently have a readAcquire method (mirror of
putOrdered) probably because volatile read is _almost_ the same (but
not on ppc!).

> fundamentally incompatible with the way volatiles/atomics are intended to be
> implemented on ARMv8 (and Itanium).  Which I think fundamentally get this
> much closer to right than traditional fence-based ISAs.
>
> I'm no hardware architect, but fundamentally it seems to me that
>
> load x
> acquire_fence
>
> imposes a much more stringent constraint than
>
> load_acquire x
>
> Consider the case in which the load from x is an L1 hit, but a preceding
> load (from say y) is a long-latency miss.  If we enforce ordering by just
> waiting for completion of prior operation, the former has to wait for the
> load from y to complete; while the latter doesn't.  I find it hard to
> believe that this doesn't leave an appreciable amount of performance on the
> table, at least for some interesting microarchitectures.

I agree.  Fences should be used rarely.


From martinrb at google.com  Mon Dec  1 20:46:00 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 1 Dec 2014 12:46:00 -0800
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>
	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>
Message-ID: <CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>

David, Paul (i.e. Reviewers) and Doug,

I'd like to commit corrections so we make progress.

I think the current webrev is simple progress with the exception of my
attempt to translate volatiles into fences, which is marginal (but was
a good learning exercise for me).


From sean.coffey at oracle.com  Mon Dec  1 21:09:36 2014
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Mon, 01 Dec 2014 21:09:36 +0000
Subject: RFR - 8065552: setAccessible(true) on fields of Class may throw
	a SecurityException
In-Reply-To: <547CB960.7040402@oracle.com>
References: <547C9770.50007@oracle.com> <547CA9F0.9040100@oracle.com>
	<547CB960.7040402@oracle.com>
Message-ID: <547CD910.7050000@oracle.com>


On 01/12/2014 18:54, Daniel Fuchs wrote:
>> on the test side would it be worth testing all public classes available
>> (e.g in rt.jar ?) to ensure that
>> Field.setAccessible works as expected and that we don't hit this issue
>> again ? It might be some
>> what of a heavy test for jtreg inclusion though.
>
> It could be worth a try. But let's wait until JEP 220 is in.
I'm not sure why JEP 220 would be a factor for now. JDK 8u and 7u are 
the production
JDKs for a while to come. Martin's testcase looks like a good approach. 
I just
ran it through the rt.jar classes and had it test for 
"f.setAccessible(true);" on all
getDeclaredFields in each class. Run time shouldn't be an issue I think 
: (6-7 seconds)

> class load: 19624 classes, 5162.67 ms total time, 0.2631 ms per class
> getMethods: 19624 classes, 1076.00 ms total time, 0.0548 ms per class

regards,
Sean.


From boehm at acm.org  Mon Dec  1 21:51:15 2014
From: boehm at acm.org (Hans Boehm)
Date: Mon, 1 Dec 2014 13:51:15 -0800
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <CA+kOe0-FYxQ0_EgQULwuy_eJi5YfvVZ_rGYj0BGkj_fxWK7SvQ@mail.gmail.com>
References: <CA+kOe08RfnkJ4Dit8ng7HQaSuDer_pA0i4t568uAGMg9dzujhg@mail.gmail.com>
	<5473A344.8090302@oracle.com>
	<CA+kOe0-KiKKNM-LyYvjZiXOGMF7c4FsHifcDq-ZZ65Bb1J=LLA@mail.gmail.com>
	<B84AA20B-5714-4FF0-AB17-E918395C9DDB@oracle.com>
	<21DC5F06-9597-4CCB-8A25-5CC354A0BCE5@flyingtroika.com>
	<CAPUmR1aZNSdk5znSfp4ei1M+ZK1M06uEYujH3Z2_B1wtOqMMhw@mail.gmail.com>
	<CA+kOe0-FYxQ0_EgQULwuy_eJi5YfvVZ_rGYj0BGkj_fxWK7SvQ@mail.gmail.com>
Message-ID: <CAPUmR1bzdeMoDmwdZUtPYjnSZRijCo+9byJiVPfwdrCS3SFfpQ@mail.gmail.com>

Needless to say, I would clearly also like to see a simple correspondence.

But this does raise the interesting question of whether put/get and
store(..., memory_order_relaxed)/load(memory_order_relaxed) are intended to
have similar semantics.  I would guess not, in that the former don't
satisfy coherence; accesses to the same variable can be reordered as for
normal variable accesses, while the C++11/C11 variants do provide those
guarantees.  On most, but not all, architectures that's entirely a compiler
issue; the hardware claims to provide that guarantee.

This affects, for example, whether a variable that is only ever incremented
by one thread can appear to another thread to decrease in value.  Or if a
reference set to a non-null value exactly once can appear to change back to
null after appearing non-null.  In my opinion, it makes sense to always
provide coherence for atomics, since the overhead is small, and so are the
odds of getting code relying on non-coherent racing accesses correct.  But
for ordinary variables whose accesses are not intended to race the
trade-offs are very different.



Hans

On Mon, Dec 1, 2014 at 12:40 PM, Martin Buchholz <martinrb at google.com>
wrote:

> Hans,
>
> (Thanks for your excellent work on C/C++ 11 and your eternal patience)
>
> On Tue, Nov 25, 2014 at 11:15 AM, Hans Boehm <boehm at acm.org> wrote:
> > It seems to me that a (dubiuously named) loadFence is intended to have
> > essentially the same semantics as the (perhaps slightly less dubiously
> > named) C++ atomic_thread_fence(memory_order_acquire), and a storeFence
> > matches atomic_thread_fence(memory_order_release).  The C++ standard and,
> > even more so, Mark Batty's work have a precise definition of what those
> mean
> > in terms of implied "synchronizes with" relationships.
> >
> > It looks to me like this whole implementation model for volatiles in
> terms
> > of fences is fundamentally doomed, and it probably makes more sense to
> get
> > rid of it rather than spending time on renaming it (though we just did
> the
> > latter in Android to avoid similar confusion about semantics).  It's
>
> I would also like to see alignment to leverage the technical and
> cultural work done on C11.  I would like to see Unsafe get
> load-acquire and store-release methods and these should be used in
> preference to fences where possible.  I'd like to see the C11 wording
> reused as much as possible.  The meanings of the words "acquire" and
> "release" are now "owned" by the C11 community and we should tag
> along.
>
> A better API for Unsafe would be
>
> putOrdered -> storeRelease
> put -> storeRelaxed
> (ordinary volatile write) -> store (default is sequential consistent)
>
> etc ...
>
> but the high cost of renaming methods in Unsafe probably makes this a
> no-go, even though Unsafe is not a public API in theory.
>
> At least the documentation of all the methods should indicate what the
> memory effects and the corresponding C++11 memory model interpretation
> is.
>
> E.g. Unsafe.compareAndSwap should document the memory effects, i.e.
> sequential consistency.
>
> Unsafe doesn't currently have a readAcquire method (mirror of
> putOrdered) probably because volatile read is _almost_ the same (but
> not on ppc!).
>
> > fundamentally incompatible with the way volatiles/atomics are intended
> to be
> > implemented on ARMv8 (and Itanium).  Which I think fundamentally get this
> > much closer to right than traditional fence-based ISAs.
> >
> > I'm no hardware architect, but fundamentally it seems to me that
> >
> > load x
> > acquire_fence
> >
> > imposes a much more stringent constraint than
> >
> > load_acquire x
> >
> > Consider the case in which the load from x is an L1 hit, but a preceding
> > load (from say y) is a long-latency miss.  If we enforce ordering by just
> > waiting for completion of prior operation, the former has to wait for the
> > load from y to complete; while the latter doesn't.  I find it hard to
> > believe that this doesn't leave an appreciable amount of performance on
> the
> > table, at least for some interesting microarchitectures.
>
> I agree.  Fences should be used rarely.
>


From peter.levart at gmail.com  Mon Dec  1 22:09:23 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 01 Dec 2014 23:09:23 +0100
Subject: RFR: 8061950: Class.getMethods() exhibits quadratic time
	complexity
In-Reply-To: <CA+kOe0-bC9WwOhkb6555oxGBHbLOX5aW7H3aB4Y187Q1CTpP5g@mail.gmail.com>
References: <CA+kOe08YW=MG+W6sMOZS9cvLXMtVa1OX7u2P0LxEjfoeGT4CGw@mail.gmail.com>	<900D2AE3-B3A6-4B1B-B25A-C564B10334AA@oracle.com>	<54492255.3040108@gmail.com>	<EAE058BE-B5F0-4F53-A9F8-36F3BFEEA703@oracle.com>	<544D58D4.7020909@gmail.com>	<544D7B74.5060607@gmail.com>	<FF8A5786-0840-45D9-8B36-0B60BB2DBA98@oracle.com>	<5450CEE9.7060707@gmail.com>	<F81AE132-D4FE-48F6-AAA8-A3580F5194B4@oracle.com>	<545120D2.5010301@gmail.com>	<54526D10.5060101@gmail.com>	<CA+kOe0_nf-fasgbhQA8zJ60wTxpAfuOYEC2YAvtHE6-awJsBrA@mail.gmail.com>	<54551D2F.407@gmail.com>	<545A572D.3050608@gmail.com>	<F15D5F8E-2E65-4243-A7AA-C30CF4DBF935@oracle.com>	<547B90A0.1080508@gmail.com>
	<CA+kOe0-bC9WwOhkb6555oxGBHbLOX5aW7H3aB4Y187Q1CTpP5g@mail.gmail.com>
Message-ID: <547CE713.2020905@gmail.com>


On 12/01/2014 09:09 PM, Martin Buchholz wrote:
> Looking at Peter's work here is still on my long TODO list, but I was
> hoping first to get in my concurrency correctness fixes for core
> reflection, which conflicts slightly...

No problem. I can rebase the patch after your fixes are in.

Regards, Peter

> On Sun, Nov 30, 2014 at 1:48 PM, Peter Levart <peter.levart at gmail.com> wrote:
>> Hi Joel,
>>
>> I managed to find some time to create some tests for this patch:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods/webrev.07/
>>
>> Both MethodTable and HashArray unit tests are provided. I had to create a
>> special TestProxy to access package-private classes from the tests.
>>
>> There are no changes to j.l.Class or j.l.r.Method from webrev.06 (I just
>> re-based them to current tip).
>>
>> I also included the patch to StarInheritance test that I forgot to include
>> in webrev.06.
>>
>> Comments inline...
>>
>> On 11/13/2014 10:39 AM, Joel Borggr?n-Franck wrote:
>>> Hi Peter,
>>>
>>> As always, thanks for taking a look at this,
>>>
>>> This is quite big so in order to make this more approachable perhaps you
>>> can split the patch up into a series? If you start with creating the
>>> MethodTable interface, adding tests for how the interface should behave and
>>> refactored the current MethodArray into implementing that interface while
>>> also changing the lookup logic that would be easier to review.
>> Well, there's not much to refactor in MethodArray when implementing
>> MethodTable. They are two entirely different APIs with entirely different
>> implementations.
>>
>>> Then you could add different implementations of MethodTable (with
>>> additional unit tests) as follow up patches.
>> You can view the MethodTable.SimpleArrayImpl as the basic implementation of
>> the MethodTable API  and a replacement for MethodArray.
>> MethodTable.HashArrayImpl is the alternative implementation for bigger
>> sizes. The same unit tests are executed against both implementations.
>>
>>> I am a bit concerned about the size and scope of the implementations. In
>>> general I would prefer if you targeted these to the precise need of core
>>> reflection today. If you want to expand these to general purpose data
>>> structures (even internal ones) I think that is a larger effort.
>> I stripped HashArray and only left those methods that are needed to
>> implement MethodTable API and execute the tests.
>>
>>> In general I think the changes to Class are sound, but there is a slight
>>> change in the default method pruning. The call to removeLessSpecifics was
>>> deliberately placed at the end, so that all default methods would be present
>>> (the algorithm is sensitive to the order of pair vise comparisons). Since we
>>> add methods in a deterministic order, I think consolidate() as you go should
>>> result in the same set of methods, but I haven?t 100% convinced myself of
>>> this just yet.
>> I think it results in the same methods. I haven't yet found an example where
>> it would result in different set of methods. All JDK classes return same
>> methods with current implementation as with patched one.
>>
>>> Have you double checked that all methods returning root Method/Ctors are
>>> private?
>> I checked all usages of private methods that I have changed and are now
>> returning root objects and made sure those are copied before being exposed
>> to the outside or being modified.
>>
>> Regards, Peter
>>
>>
>>> On 5 nov 2014, at 17:58, Peter Levart <peter.levart at gmail.com> wrote:
>>>
>>>> Here's new webrev:
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods/webrev.06/
>>>>
>>>>
>>>> The optimizations made from webrev.05 are:
>>>>
>>>> - getMethod() skips construction of MethodTable if there are no
>>>> (super)interfaces.
>>>> - getMethods() returns just declared public methods if there are no
>>>> superclass and no (super)interfaces.
>>>> - comparing method parameter types is optimized by adding two methods to
>>>> Method/LangReflectAccess/ReflectionFactory.
>>>>
>>>> New MethodTable implementation based on a linear-probe hash table is a
>>>> space/garbage improvement. I took IdentityHashMap, removed unneeded stuff
>>>> and modified it's API. The result is a HashArray. It's API is similar in
>>>> function and form to java.util.Map, but doesn't use separate keys and
>>>> values. An element of HashArray is a key and a value at the same time.
>>>> Elements are always non-null, so the method return values are unambiguous.
>>>> As HashArray is a linear-probe hash table and there are no Map.Entry objects
>>>> involved, the underlying data structure is very simple and memory efficient.
>>>> It is just a sparse array of elements with length that is always a power of
>>>> two and larger than 3 * size / 2. It also features overriddable element
>>>> equals/hashCode methods. I made it a separate generic class because I think
>>>> it can find it's usage elsewhere (for example as a cannonicalizing cache).
>>>>
>>>> Since HashArray based MethodTable is more space-efficient I moved the
>>>> line between simple array based and HashArray based MethodTable down to 20
>>>> elements to minimize the worst-case scenario effect. Calling getMethods() on
>>>> all rt.jar classes now constructs about 3/4 simple array based and 1/4
>>>> HashArray based MethodTables.
>>>>
>>> HashArray.java:
>>>
>>> I was hoping for a decent set of unit tests for the new HashArray<T> data
>>> structure. I think it is reasonable to test the corner cases/non-trivial
>>> areas of the table (closeDeletion(), rezise() etc). Perhaps also run these
>>> over the simple implementation. Also, please document thread safety (there
>>> is none IFAICT it should just be noted).
>>>
>>> Instead of using inheritance to change the behavior of equals() and hash()
>>> you could give it two lambdas at table creation time, a ToIntFunction<T> for
>>> hash() and a BiPredicate<T,T> for equals(). Might not give you the
>>> performance we need though.
>>>
>>> Note that the file doesn?t actually compile in jdk9/dev, you have two
>>> unchecked casts and we build with -Werror.
>>>
>>> MethodTable.java
>>>
>>> HashMapImpl is missing serialVersionUID, but it looks like this class
>>> won?t be needed at all.
>>>
>>>
>>>> Here's also Martin's ManyMethodsBenchmark:
>>>>
>>>> Original:
>>>>
>>>> Base class load time: 129.95 ms
>>>> getDeclaredMethods: 65521 methods, 36.58 ms total time, 0.0006 ms per
>>>> method
>>>> getMethods        : 65530 methods, 47.43 ms total time, 0.0007 ms per
>>>> method
>>>> Derived class load time: 32216.09 ms
>>>> getDeclaredMethods: 65521 methods, 35.05 ms total time, 0.0005 ms per
>>>> method
>>>> getMethods        : 65530 methods, 8068.66 ms total time, 0.1231 ms per
>>>> method
>>>>
>>>>
>>>> Patched (using HashArray based MethodTable):
>>>>
>>>> Base class load time: 126.00 ms
>>>> getDeclaredMethods: 65521 methods, 36.83 ms total time, 0.0006 ms per
>>>> method
>>>> getMethods        : 65530 methods, 45.08 ms total time, 0.0007 ms per
>>>> method
>>>> Derived class load time: 31865.27 ms
>>>> getDeclaredMethods: 65521 methods, 35.01 ms total time, 0.0005 ms per
>>>> method
>>>> getMethods        : 65530 methods, 78.05 ms total time, 0.0012 ms per
>>>> method
>>>>
>>>>
>>>> All 86 jtreg test in java.lang/Class/ and java/lang/reflect/ still pass.
>>>>
>>> I have seen discussion about allocation, should we measure and compare?
>>> You can probably use the Hotspot impl of ThreadMXBean to get the allocation
>>> in the tread.
>>>
>>> Also, it might be time to fix the boolean parameters:
>>>
>>> 2741         Method[] declaredMethods = privateGetDeclaredMethods(true);
>>> 2742         Class<?> superclass = getSuperclass();
>>> 2743         Class<?>[] interfaces = getInterfaces(false);
>>>
>>> Perhaps just add boolean constants somewhere so that it is easier to
>>> decode.
>>>
>>> 2741         Method[] declaredMethods =
>>> privateGetDeclaredMethods(PUBLIC_METHOD_ONLY);
>>> 2742         Class<?> superclass = getSuperclass();
>>> 2743         Class<?>[] interfaces = getInterfaces(NO_COPY_RESULT);
>>>
>>> or so.
>>>
>>> HashArray.java:
>>>
>>> 155         if (lookupObj == null) throw new NullPointerException();
>>>
>>> use Objects.requreNonNull() ?
>>>
>>> cheers
>>> /Joel
>>>



From stuart.marks at oracle.com  Mon Dec  1 23:17:07 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 01 Dec 2014 15:17:07 -0800
Subject: RFR(s): 8035000: TEST_BUG: remove ActivationLibrary.DestroyThread
	and have callers call rmid.destroy() instead
In-Reply-To: <61D1F880-2CD8-4D30-AAC2-A4D6CDC17B21@oracle.com>
References: <5473E8D1.8040606@oracle.com> <547CB85E.6050000@oracle.com>
	<61D1F880-2CD8-4D30-AAC2-A4D6CDC17B21@oracle.com>
Message-ID: <547CF6F3.8050202@oracle.com>

Thanks Lance, I knew you'd come through. :-)


On 12/1/14 10:53 AM, Lance Andersen wrote:
> Sorry Stuart,  I looked at this last week but guess I forgot to reply.
>
> It looks fine and a nice clean up :-)
>
> Best
> Lance
> On Dec 1, 2014, at 1:50 PM, Stuart Marks <stuart.marks at oracle.com 
> <mailto:stuart.marks at oracle.com>> wrote:
>
>> Hi all, any reviewers for this one?
>>
>> s'marks
>>
>> On 11/24/14 6:26 PM, Stuart Marks wrote:
>>> Hi all,
>>>
>>> Here's another test cleanup fix. Basically this normalizes the shutdown/destroy
>>> policy for rmid processes that are started by RMI's test library in support of a
>>> few dozen of the RMI activation tests. The previous implementation was, well,
>>> confused, and it had a redundant timing loop that can be subsumed by other code
>>> in RMI's test library (JavaVM.waitFor).
>>>
>>> I've listed this as a "small" changeset even though lots of files have changed.
>>> In all but three or so of the files, the only change is from calling
>>> "ActivationLibrary.rmidCleanup(rmid)" to calling "rmid.cleanup()" which is a
>>> refactoring enabled by the cleanup. The real action is in the files
>>> test/java/rmi/testlibrary/ActivationLibrary.java and RMID.java.
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~smarks/reviews/8035000/webrev.0/ 
>>> <http://cr.openjdk.java.net/%7Esmarks/reviews/8035000/webrev.0/>
>>>
>>> Bug:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8035000
>>>
>>> Thanks,
>>>
>>> s'marks
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| 
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>



From dl at cs.oswego.edu  Tue Dec  2 00:58:26 2014
From: dl at cs.oswego.edu (Doug Lea)
Date: Mon, 01 Dec 2014 19:58:26 -0500
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>
	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>
Message-ID: <547D0EB2.3070802@cs.oswego.edu>

On 12/01/2014 03:46 PM, Martin Buchholz wrote:
> David, Paul (i.e. Reviewers) and Doug,
>
> I'd like to commit corrections so we make progress.

The current one looks OK to me.
(http://cr.openjdk.java.net/~martin/webrevs/openjdk9/fence-intrinsics/)

-Doug


>
> I think the current webrev is simple progress with the exception of my
> attempt to translate volatiles into fences, which is marginal (but was
> a good learning exercise for me).
>



From martinrb at google.com  Tue Dec  2 01:05:14 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 1 Dec 2014 17:05:14 -0800
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <CAPUmR1bzdeMoDmwdZUtPYjnSZRijCo+9byJiVPfwdrCS3SFfpQ@mail.gmail.com>
References: <CA+kOe08RfnkJ4Dit8ng7HQaSuDer_pA0i4t568uAGMg9dzujhg@mail.gmail.com>
	<5473A344.8090302@oracle.com>
	<CA+kOe0-KiKKNM-LyYvjZiXOGMF7c4FsHifcDq-ZZ65Bb1J=LLA@mail.gmail.com>
	<B84AA20B-5714-4FF0-AB17-E918395C9DDB@oracle.com>
	<21DC5F06-9597-4CCB-8A25-5CC354A0BCE5@flyingtroika.com>
	<CAPUmR1aZNSdk5znSfp4ei1M+ZK1M06uEYujH3Z2_B1wtOqMMhw@mail.gmail.com>
	<CA+kOe0-FYxQ0_EgQULwuy_eJi5YfvVZ_rGYj0BGkj_fxWK7SvQ@mail.gmail.com>
	<CAPUmR1bzdeMoDmwdZUtPYjnSZRijCo+9byJiVPfwdrCS3SFfpQ@mail.gmail.com>
Message-ID: <CA+kOe09BkdvpEEGJAo0WgA02Syx0KW18mkeEhDBSR2kc5PLvgg@mail.gmail.com>

On Mon, Dec 1, 2014 at 1:51 PM, Hans Boehm <boehm at acm.org> wrote:
> Needless to say, I would clearly also like to see a simple correspondence.
>
> But this does raise the interesting question of whether put/get and
> store(..., memory_order_relaxed)/load(memory_order_relaxed) are intended to
> have similar semantics.  I would guess not, in that the former don't satisfy
> coherence; accesses to the same variable can be reordered as for normal
> variable accesses, while the C++11/C11 variants do provide those guarantees.
> On most, but not all, architectures that's entirely a compiler issue; the
> hardware claims to provide that guarantee.
>
> This affects, for example, whether a variable that is only ever incremented
> by one thread can appear to another thread to decrease in value.  Or if a
> reference set to a non-null value exactly once can appear to change back to
> null after appearing non-null.  In my opinion, it makes sense to always
> provide coherence for atomics, since the overhead is small, and so are the
> odds of getting code relying on non-coherent racing accesses correct.  But
> for ordinary variables whose accesses are not intended to race the
> trade-offs are very different.

It would be nice to pretend that ordinary java loads and stores map
perfectly to C11 relaxed loads and stores.  This maps well to the lack
of undefined behavior for data races in Java.  But this fails also
with lack of atomicity of Java longs and doubles.  I have no intuition
as to whether always requiring per-variable sequential consistency
would be a performance problem.  Introducing an explicit relaxed
memory order mode in Java when the distinction between ordinary access
is smaller than in C/C++ 11 would be confusing.

Despite all that, it would be clean, consistent and seemingly
straightforward to simply add all of the C/C++ atomic loads, stores
and fences to sun.misc.Unsafe (with the possible exception of consume,
which is still under a cloud).  If that works out for jdk-internal
code, we can add them to a public API.  Providing the full set will
help with interoperability with C code running in another thread
accessing a direct buffer.


From boehm at acm.org  Tue Dec  2 01:54:49 2014
From: boehm at acm.org (Hans Boehm)
Date: Mon, 1 Dec 2014 17:54:49 -0800
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <CA+kOe09BkdvpEEGJAo0WgA02Syx0KW18mkeEhDBSR2kc5PLvgg@mail.gmail.com>
References: <CA+kOe08RfnkJ4Dit8ng7HQaSuDer_pA0i4t568uAGMg9dzujhg@mail.gmail.com>
	<5473A344.8090302@oracle.com>
	<CA+kOe0-KiKKNM-LyYvjZiXOGMF7c4FsHifcDq-ZZ65Bb1J=LLA@mail.gmail.com>
	<B84AA20B-5714-4FF0-AB17-E918395C9DDB@oracle.com>
	<21DC5F06-9597-4CCB-8A25-5CC354A0BCE5@flyingtroika.com>
	<CAPUmR1aZNSdk5znSfp4ei1M+ZK1M06uEYujH3Z2_B1wtOqMMhw@mail.gmail.com>
	<CA+kOe0-FYxQ0_EgQULwuy_eJi5YfvVZ_rGYj0BGkj_fxWK7SvQ@mail.gmail.com>
	<CAPUmR1bzdeMoDmwdZUtPYjnSZRijCo+9byJiVPfwdrCS3SFfpQ@mail.gmail.com>
	<CA+kOe09BkdvpEEGJAo0WgA02Syx0KW18mkeEhDBSR2kc5PLvgg@mail.gmail.com>
Message-ID: <CAPUmR1b54fc7ZEP-x8nDgyppmx-TrwA6f84uttm-wOY46+jzDA@mail.gmail.com>

I think that requiring coherence for ordinary Java accesses would be a
performance problem.  The pre-2005 Java memory model actually promised it,
but implementations ignored that requirement.  That was one significant
motivation of the 2005 memory model overhaul.

The basic problem is that if you have

r1 = x.f;
r2 = y.f;
r3 = x.f;

the compiler can no longer perform common subexpression elimination  on the
two loads from x.f unless it can prove that x and y do not alias, which is
probably rare.  Loads kill available expressions.  Clearly this can
significantly reduce the effectiveness of CSE and similar basic
optimizations.  Enforcing coherence also turns out to be somewhat expensive
on Itanium, and rather expensive on some slightly older ARM processors.

Those arguments probably don't apply to sun.misc.unsafe.  But no matter
what you do for sun.misc.unsafe, something will be inconsistent.

(The other problem of course is that we still don't really know how to
define memory_order_relaxed any better than we know how to define ordinary
Java memory references.)

On Mon, Dec 1, 2014 at 5:05 PM, Martin Buchholz <martinrb at google.com> wrote:

> On Mon, Dec 1, 2014 at 1:51 PM, Hans Boehm <boehm at acm.org> wrote:
> > Needless to say, I would clearly also like to see a simple
> correspondence.
> >
> > But this does raise the interesting question of whether put/get and
> > store(..., memory_order_relaxed)/load(memory_order_relaxed) are intended
> to
> > have similar semantics.  I would guess not, in that the former don't
> satisfy
> > coherence; accesses to the same variable can be reordered as for normal
> > variable accesses, while the C++11/C11 variants do provide those
> guarantees.
> > On most, but not all, architectures that's entirely a compiler issue; the
> > hardware claims to provide that guarantee.
> >
> > This affects, for example, whether a variable that is only ever
> incremented
> > by one thread can appear to another thread to decrease in value.  Or if a
> > reference set to a non-null value exactly once can appear to change back
> to
> > null after appearing non-null.  In my opinion, it makes sense to always
> > provide coherence for atomics, since the overhead is small, and so are
> the
> > odds of getting code relying on non-coherent racing accesses correct.
> But
> > for ordinary variables whose accesses are not intended to race the
> > trade-offs are very different.
>
> It would be nice to pretend that ordinary java loads and stores map
> perfectly to C11 relaxed loads and stores.  This maps well to the lack
> of undefined behavior for data races in Java.  But this fails also
> with lack of atomicity of Java longs and doubles.  I have no intuition
> as to whether always requiring per-variable sequential consistency
> would be a performance problem.  Introducing an explicit relaxed
> memory order mode in Java when the distinction between ordinary access
> is smaller than in C/C++ 11 would be confusing.
>
> Despite all that, it would be clean, consistent and seemingly
> straightforward to simply add all of the C/C++ atomic loads, stores
> and fences to sun.misc.Unsafe (with the possible exception of consume,
> which is still under a cloud).  If that works out for jdk-internal
> code, we can add them to a public API.  Providing the full set will
> help with interoperability with C code running in another thread
> accessing a direct buffer.
>


From david.holmes at oracle.com  Tue Dec  2 02:32:20 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 02 Dec 2014 12:32:20 +1000
Subject: Packing 2 data points into 1 field in ThreadPoolExecutor
In-Reply-To: <CBACF05C-2856-43BB-8EAE-D46680D8AD05@icloud.com>
References: <F20EAFC5-2BD8-4787-901B-413B9D4A84E2@icloud.com>	<0F081861-ACBA-484E-9FA7-784D2EE4A023@icloud.com>	<CA+kOe08odwpUrUeeniY+j8SyraATDLbBSHWF+S2=1ECoT_R1wA@mail.gmail.com>
	<CBACF05C-2856-43BB-8EAE-D46680D8AD05@icloud.com>
Message-ID: <547D24B4.2090001@oracle.com>

On 2/12/2014 3:44 AM, Alex Yursha wrote:
> 1. Do you mean 'the only way', except using a lock?
>
> 2. I also cant imagine how we can use long primitive type for CAS atomicity without a lock if only its not an AtomicLong. Any hint here, please?

AtomicFieldUpdater can apply atomic operations to plain (volatile) int 
and long fields. The Unsafe API can also be used to do it more performantly.

David

> Thanks
>
>
> Sent from my iPhone
>
>> On Dec 1, 2014, at 20:27, Martin Buchholz <martinrb at google.com> wrote:
>>
>> The only way to use atomic compare and set is to pack all your state
>> into a single primitive unit.  The largest we have is "long".  So we
>> regularly pack what the C folks would call bitfields into longs.
>>
>>> On Sat, Nov 29, 2014 at 8:13 AM, Alex Yursha <alexyursha at gmail.com> wrote:
>>> Hi all,
>>>
>>> According to javadoc current implementation of ThreadPoolExecutor packs two conceptual fields ?workerCount? and ?runState? into one actual field ?ctl? of type AtomicInteger.
>>>
>>> Could you please explain are there any performance or other benefits for this? It seems to complicate the class design and I can?t find the positive side of this.
>>>
>>> Thanks,
>>> Alex
>>>


From chris.plummer at oracle.com  Tue Dec  2 02:39:22 2014
From: chris.plummer at oracle.com (Chris Plummer)
Date: Mon, 01 Dec 2014 18:39:22 -0800
Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation
	fault
In-Reply-To: <546CBCAB.7040101@oracle.com>
References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com>
	<54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com>
	<546C5986.6010500@oracle.com> <546C6D1A.8050903@oracle.com>
	<546CBCAB.7040101@oracle.com>
Message-ID: <547D265A.20005@oracle.com>

Sorry about the long delay in getting back to this. I ran into two 
separate JPRT issues that were preventing me from testing these changes, 
plus I was on vacation last week. Here's an updated webrev. I'm not sure 
where we left things, so I'll just say what's changed since the original 
version:

1. Rewrote the test to be in Java instead of a shell script.
2. Moved the test from hotspot/test/runtime/memory to 
jdk/test/tools/launcher
3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to override 
the default 32k minimum value.

https://bugs.openjdk.java.net/browse/JDK-6762191
http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/

thanks,

Chris

On 11/19/14 7:52 AM, Chris Plummer wrote:
> On 11/19/14 2:12 AM, David Holmes wrote:
>> On 19/11/2014 6:49 PM, Chris Plummer wrote:
>>> I've update the webrev to add STACK_SIZE_MINIMUM in place of the 32k
>>> references, and also moved the test from hotspot/test/runtime to
>>> jdk/test/tools/launcher as David requested. That required some
>>> adjustments to the test script, since test_env.sh does not exist in
>>> jdk/test, so I had to pull in the bits I needed into the script.
>>
>> Is there a reason this needs a shell script instead of using the 
>> testlibrary tools to launch the VM and check the output?
> Not that I'm aware of. I guess I just really didn't look at what it 
> would take to make it all in java. I'll have a look at java examples 
> and convert it.
>
> Chris
>>
>> Sorry that should have been mentioned much earlier.
>>
>> David
>>
>>
>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.01/
>>>
>>> I still need to rerun through JPRT. I'll do so once there are no more
>>> suggested changes.
>>>
>>> thanks,
>>>
>>> Chris
>>>
>>> On 11/18/14 2:08 PM, Chris Plummer wrote:
>>>> Adding core-libs-dev at openjdk.java.net, since one of the changes is in
>>>> java.c.
>>>>
>>>> Chris
>>>>
>>>> On 11/12/14 6:43 PM, David Holmes wrote:
>>>>> Hi Chris,
>>>>>
>>>>> Sorry for the delay.
>>>>>
>>>>> On 13/11/2014 5:44 AM, Chris Plummer wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'm still looking for reviewers.
>>>>>
>>>>> As the change is to the launcher it needs to be reviewed by the
>>>>> launcher owner - which I think is serviceability (though also cc'd
>>>>> Kumar :) ).
>>>>>
>>>>> Launcher change, and your rationale, seems okay to me. I'd probably
>>>>> put the test in to jdk/test/tools/launcher/ though.
>>>>>
>>>>> Thanks,
>>>>> David
>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>> On 11/7/14 7:53 PM, Chris Plummer wrote:
>>>>>>> This is an initial review for 6762191. I'm guessing there will be
>>>>>>> recommendations to fix in a different way, but thought this 
>>>>>>> would be a
>>>>>>> good time to start the discussion.
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6762191
>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.jdk/
>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.hotspot/
>>>>>>>
>>>>>>> The bug is that if the -Xss size is set to something very small 
>>>>>>> (like
>>>>>>> 16k), on linux there will be a crash due to overwriting the end 
>>>>>>> of the
>>>>>>> stack. This happens before hotspot can compute its stack needs and
>>>>>>> verify that the stack is big enough.
>>>>>>>
>>>>>>> It didn't seem viable to move the hotspot stack size check 
>>>>>>> earlier. It
>>>>>>> depends on too much other work done before that point, and the 
>>>>>>> changes
>>>>>>> would have been disruptive. The stack size check is currently 
>>>>>>> done in
>>>>>>> os::init_2().
>>>>>>>
>>>>>>> What is needed is a check before the thread is created. That way we
>>>>>>> can create a thread with a big enough stack to handle all needs 
>>>>>>> up to
>>>>>>> the point of the check in os::init_2(). This initial check does not
>>>>>>> need to be the final check. It just needs to confirm that we have
>>>>>>> enough stack to get us to the check in os::init_2().
>>>>>>>
>>>>>>> I decided to check in java.c if the -Xss size is too small, and 
>>>>>>> set it
>>>>>>> to a larger size if it is. I hard coded this size to 32k (I'll 
>>>>>>> explain
>>>>>>> why 32k later). I suspect this is the part that will result in some
>>>>>>> debate. If you have better suggestions let me know. If it does stay
>>>>>>> here, then probably the 32k needs to be a #define, and maybe 
>>>>>>> even an
>>>>>>> OS porting interface, but I'm not sure where to put it.
>>>>>>>
>>>>>>> The reason I chose 32k is because this is big enough for all 
>>>>>>> platforms
>>>>>>> to get to the stack size check in os::init_2(). It is also smaller
>>>>>>> than the actual minimum stack size allowed on any platform. 32-bit
>>>>>>> windows has the smallest requirement at 64k. I add some printfs to
>>>>>>> print the minimum stack requirement, and then ran a simple JTReg 
>>>>>>> test
>>>>>>> with every JPRT supported platform to get the results.
>>>>>>>
>>>>>>> The TooSmallStackSize.sh will run "java -version" with -Xss16k,
>>>>>>> -Xss32k, and -XXss<minsize>, where <minsize> is the size from the
>>>>>>> error message produced by the JVM, such as in the following:
>>>>>>>
>>>>>>> $ java -Xss32k -version
>>>>>>> The stack size specified is too small, Specify at least 100k
>>>>>>> Error: Could not create the Java Virtual Machine.
>>>>>>> Error: A fatal exception has occurred. Program will exit.
>>>>>>>
>>>>>>> I ran this test through JPRT on all platforms, and they all pass.
>>>>>>>
>>>>>>> One thing to point out is that Windows behaves a bit different than
>>>>>>> the other platforms. It always rounds the stack size up to a 
>>>>>>> multiple
>>>>>>> of 64k , so even if you specify -Xss16k, you get a 64k stack. On
>>>>>>> 32-bit Windows with C1, 64k is also the minimum requirement, so 
>>>>>>> there
>>>>>>> is no error produced in this case. However, on 32-bit Windows 
>>>>>>> with C2,
>>>>>>> 68k is the minimum, so an error is produced since the stack will 
>>>>>>> only
>>>>>>> be 64k. There is no bug here. It's just a bit confusing.
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> Chris
>>>>>>
>>>>
>>>
>



From dt at flyingtroika.com  Tue Dec  2 02:54:02 2014
From: dt at flyingtroika.com (DT)
Date: Mon, 01 Dec 2014 18:54:02 -0800
Subject: [concurrency-interest] RFR:
	8065804:JEP171:Clarifications/corrections for fence intrinsics
In-Reply-To: <1417028404335.73215@devexperts.com>
References: <c806b219426c4c8aa9e5bfa79fc9901d@exchmb02.office.devexperts.com>	<NFBBKALFDCPFIDBNKAPCIECNKLAA.davidcholmes@aapt.net.au>
	<74ff42b06c314fc9998d512725bae69a@exchmb02.office.devexperts.com>,
	<54760CD7.9070704@flyingtroika.com>
	<1417028404335.73215@devexperts.com>
Message-ID: <547D29CA.2000905@flyingtroika.com>

Roman, thank you. As it has been mentioned before from practical 
perspective its quite difficult to incorporate. Though as I understood , 
can be wrong of course that volatile variables and immutable objects 
represent  lineariazable objects because they satisfy those concurrent 
conditions.

Dmitry

On 11/26/2014 11:00 AM, Roman Elizarov wrote:
>
> I'd suggest to start with the original paper by Herlihy who had come 
> up with the concept of Linearizability in 1990:
>
> Linearizability: A Correctness Condition for Concurrent Objects
>
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.142.5315
>
>
> There were lot of reasearch about linearizability since then (there 
> are almost a thouthand citations for this arcticle) expanding and 
> improving proof techniquies and applying it. There were no 
> breakthroughs of the comparable magnitude since then. All 
> "thread-safe" objects that you enconter in the modern word are 
> linearizable. It is a defacto "golden standard" correctness condition 
> for concurrent objects.
>
>
> This position is well deserved, because having lineariazable objects 
> as your building blocks makes it super-easy to formally reason about 
> correctness of your code. You will rarely encouter concurrent 
> algorithms that provide weaker guarantees (like quescient 
> consistency), because they all too hard to reason about -- they are 
> either not composable or not local. But when all your 
> concurrent objects are linearizable, then you can ditch 
> happens-before, forget that everything is actually parallel and 
> simply reason about your code in terms of interleaving of "atomic" 
> operations that happen in some global order. That is the beauty of 
> linearizability.
>
>
> But Linearizability is indeed a pretty strong requirement. 
> Linearizability of your shared memory requires that Independent Reads 
> of Independent Writes (IRIW) are consistent. Can you get away with 
> some weaker requirement and still get all the same goodies as 
> linearizability gets you? I have not seen anything promising in this 
> direction. Whoever makes this breakthrough will surely reap the 
> world's recognition and respect.
>
>
> /Roman
>
>
> ------------------------------------------------------------------------
> *??:* DT <dt at flyingtroika.com>
> *??????????:* 26 ?????? 2014 ?. 20:24
> *????:* Roman Elizarov; dholmes at ieee.org; Hans Boehm
> *?????:* core-libs-dev; concurrency-interest at cs.oswego.edu
> *????:* Re: [concurrency-interest] RFR: 
> 8065804:JEP171:Clarifications/corrections for fence intrinsics
> Roman,
> Can you point to any specific article providing the concurrency 
> problem statement with a further proof using linearizability to reason 
> about solution.
>
> Thanks,
> DT
>
> On 11/26/2014 2:59 AM, Roman Elizarov wrote:
>>
>> Whether IRIW has any _/practical/_ uses is definitely subject to 
>> debate. However, there is no tractable way for formal reasoning about 
>> properties of large concurrent systems, but via linearizability. 
>> Linearizability is the only property that is both local and 
>> hierarchical. It lets you build more complex linearizable algorithms 
>> from simpler ones, having quite succinct and compelling proofs at 
>> each step.
>>
>> In other words, if you want to be able to construct a formal proof 
>> that your [large] concurrent system if correct, then you must have 
>> IRIW consistency. Do you need a formal proof of correctness? Maybe 
>> not. In many applications hand-waving is enough,  but there are many 
>> other applications where hand-waving does not count as a proof. It 
>> may be possible to construct formal correctness proofs for some very 
>> simple algorithms even on a system that does not provide IRIW, but 
>> this is beyond the state of the art of formal verification for 
>> anything sufficiently complex.
>>
>> /Roman
>>
>> *From:*David Holmes [mailto:davidcholmes at aapt.net.au]
>> *Sent:* Wednesday, November 26, 2014 11:54 AM
>> *To:* Roman Elizarov; Hans Boehm
>> *Cc:* concurrency-interest at cs.oswego.edu; core-libs-dev
>> *Subject:* RE: [concurrency-interest] RFR: 
>> 8065804:JEP171:Clarifications/corrections for fence intrinsics
>>
>> Can you expand on that please. All previous discussion of IRIW I have 
>> seen indicated that the property, while a consequence of existing JMM 
>> rules, had no practical use.
>>
>> Thanks,
>>
>> David
>>
>>     -----Original Message-----
>>     *From:* Roman Elizarov [mailto:elizarov at devexperts.com]
>>     *Sent:* Wednesday, 26 November 2014 6:49 PM
>>     *To:* dholmes at ieee.org <mailto:dholmes at ieee.org>; Hans Boehm
>>     *Cc:* concurrency-interest at cs.oswego.edu
>>     <mailto:concurrency-interest at cs.oswego.edu>; core-libs-dev
>>     *Subject:* RE: [concurrency-interest] RFR:
>>     8065804:JEP171:Clarifications/corrections for fence intrinsics
>>
>>     There is no conceivable way to kill IRIW consistency requirement
>>     while retaining ability to prove correctness of large software
>>     systems. If IRIW of volatile variables are not consistent, then
>>     volatile reads and writes are not linearizable, which breaks
>>     linearizabiliy of all higher-level primitives build on top of
>>     them and makes formal reasoning about behavior of concurrent
>>     systems practically impossible. There are many fields where this
>>     is not acceptable.
>>
>>     /Roman
>>
>>     *From:*concurrency-interest-bounces at cs.oswego.edu
>>     <mailto:concurrency-interest-bounces at cs.oswego.edu>
>>     [mailto:concurrency-interest-bounces at cs.oswego.edu] *On Behalf Of
>>     *David Holmes
>>     *Sent:* Wednesday, November 26, 2014 5:11 AM
>>     *To:* Hans Boehm
>>     *Cc:* concurrency-interest at cs.oswego.edu
>>     <mailto:concurrency-interest at cs.oswego.edu>; core-libs-dev
>>     *Subject:* Re: [concurrency-interest] RFR: 8065804:
>>     JEP171:Clarifications/corrections for fence intrinsics
>>
>>     Hi Hans,
>>
>>     Given IRIW is a thorn in everyone's side and has no known useful
>>     benefit, and can hopefully be killed off in the future, lets not
>>     get bogged down in IRIW. But none of what you say below relates
>>     to multi-copy-atomicity.
>>
>>     Cheers,
>>
>>     David
>>
>>         -----Original Message-----
>>         *From:* hjkhboehm at gmail.com
>>         <mailto:hjkhboehm at gmail.com>[mailto:hjkhboehm at gmail.com]*On
>>         Behalf Of *Hans Boehm
>>         *Sent:* Wednesday, 26 November 2014 12:04 PM
>>         *To:* dholmes at ieee.org <mailto:dholmes at ieee.org>
>>         *Cc:* Stephan Diestelhorst;
>>         concurrency-interest at cs.oswego.edu
>>         <mailto:concurrency-interest at cs.oswego.edu>; core-libs-dev
>>         *Subject:* Re: [concurrency-interest] RFR: 8065804:
>>         JEP171:Clarifications/corrections for fence intrinsics
>>
>>         To be concrete here, on Power, loads can normally be ordered
>>         by an address dependency or light-weight fence (lwsync).
>>         However, neither is enough to prevent the questionable
>>         outcome for IRIW, since it doesn't ensure that the stores in
>>         T1 and T2 will be made visible to other threads in a
>>         consistent order. That outcome can be prevented by using
>>         heavyweight fences (sync) instructions between the loads
>>         instead.  Peter Sewell's group concluded that to enforce
>>         correct volatile behavior on Power, you essentially need a a
>>         heavyweight fence between every pair of volatile operations
>>         on Power.  That cannot be understood based on simple ordering
>>         constraints.
>>
>>         As Stephan pointed out, there are similar issues on ARM, but
>>         they're less commonly encountered in a Java implementation.
>>         If you're lucky, you can get to the right implementation
>>         recipe by looking at only reordering, I think.
>>
>>         On Tue, Nov 25, 2014 at 4:36 PM, David Holmes
>>         <davidcholmes at aapt.net.au <mailto:davidcholmes at aapt.net.au>>
>>         wrote:
>>
>>             Stephan Diestelhorst writes:
>>             >
>>             > David Holmes wrote:
>>             > > Stephan Diestelhorst writes:
>>             > > > Am Dienstag, 25. November 2014, 11:15:36 schrieb
>>             Hans Boehm:
>>             > > > > I'm no hardware architect, but fundamentally it
>>             seems to me that
>>             > > > >
>>             > > > > load x
>>             > > > > acquire_fence
>>             > > > >
>>             > > > > imposes a much more stringent constraint than
>>             > > > >
>>             > > > > load_acquire x
>>             > > > >
>>             > > > > Consider the case in which the load from x is an
>>             L1 hit, but a
>>             > > > > preceding load (from say y) is a long-latency
>>             miss.  If we enforce
>>             > > > > ordering by just waiting for completion of prior
>>             operation, the
>>             > > > > former has to wait for the load from y to
>>             complete; while the
>>             > > > > latter doesn't.  I find it hard to believe that
>>             this doesn't leave
>>             > > > > an appreciable amount of performance on the
>>             table, at least for
>>             > > > > some interesting microarchitectures.
>>             > > >
>>             > > > I agree, Hans, that this is a reasonable
>>             assumption.  Load_acquire x
>>             > > > does allow roach motel, whereas the acquire fence
>>             does not.
>>             > > >
>>             > > > >  In addition, for better or worse, fencing
>>             requirements on at least
>>             > > > >  Power are actually driven as much by store
>>             atomicity issues, as by
>>             > > > >  the ordering issues discussed in the cookbook. 
>>             This was not
>>             > > > >  understood in 2005, and unfortunately doesn't
>>             seem to be
>>             > amenable to
>>             > > > >  the kind of straightforward explanation as in
>>             Doug's cookbook.
>>             > > >
>>             > > > Coming from a strongly ordered architecture to a
>>             weakly ordered one
>>             > > > myself, I also needed some mental adjustment about
>>             store (multi-copy)
>>             > > > atomicity.  I can imagine others will be unaware of
>>             this difference,
>>             > > > too, even in 2014.
>>             > >
>>             > > Sorry I'm missing the connection between fences and
>>             multi-copy
>>             > atomicity.
>>             >
>>             > One example is the classic IRIW. With non-multi copy
>>             atomic stores, but
>>             > ordered (say through a dependency) loads in the
>>             following example:
>>             >
>>             > Memory: foo = bar = 0
>>             > _T1_         _T2_         _T3_                       _T4_
>>             > st (foo),1   st (bar),1   ld r1, (bar)                 
>>                 ld r3,(foo)
>>             >                           <addr dep / local "fence"
>>             here>   <addr dep>
>>             >                           ld r2, (foo)                 
>>                 ld r4, (bar)
>>             >
>>             > You may observe r1 = 1, r2 = 0, r3 = 1, r4 = 0 on
>>             non-multi-copy atomic
>>             > machines.  On TSO boxes, this is not possible.  That
>>             means that the
>>             > memory fence that will prevent such a behaviour (DMB on
>>             ARM) needs to
>>             > carry some additional oomph in ensuring multi-copy
>>             atomicity, or rather
>>             > prevent you from seeing it (which is the same thing).
>>
>>             I take it as given that any code for which you may have
>>             ordering
>>             constraints, must first have basic atomicity properties
>>             for loads and
>>             stores. I would not expect any kind of fence to add
>>             multi-copy-atomicity
>>             where there was none.
>>
>>             David
>>
>>
>>             > Stephan
>>             >
>>             > _______________________________________________
>>             > Concurrency-interest mailing list
>>             > Concurrency-interest at cs.oswego.edu
>>             <mailto:Concurrency-interest at cs.oswego.edu>
>>             > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>             _______________________________________________
>>             Concurrency-interest mailing list
>>             Concurrency-interest at cs.oswego.edu
>>             <mailto:Concurrency-interest at cs.oswego.edu>
>>             http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



From frank.yuan at oracle.com  Tue Dec  2 02:57:29 2014
From: frank.yuan at oracle.com (Frank Yuan)
Date: Tue, 2 Dec 2014 10:57:29 +0800
Subject: Review request for JDK-8051536: Convert JAXP function tests:
	javax.xml.parsers to jtreg(testng) tests 
Message-ID: <00d901d00ddb$b7e40f80$27ac2e80$@oracle.com>

Hi, Joe and All

We are working on moving internal jaxp functional tests to open jdk repo.
This is the parsers suite. Would you please review these test?  Any comment
will be appreciated.

bug: https://bugs.openjdk.java.net/browse/JDK-8051536
webrev: http://cr.openjdk.java.net/~joehw/jdk9/test/Frank/8051536/webrev/


Thanks,

Frank



From david.holmes at oracle.com  Tue Dec  2 04:24:41 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 02 Dec 2014 14:24:41 +1000
Subject: [8u60] RFR: 8038189: Add cross-platform compact profiles support
In-Reply-To: <547C3296.8000000@oracle.com>
References: <547BB1C4.1000303@oracle.com> <547C3296.8000000@oracle.com>
Message-ID: <547D3F09.5010308@oracle.com>

Erik,

Many thanks for the makefile macro wizardry! I will incorporate, test 
and return with an updated webreb.

David

On 1/12/2014 7:19 PM, Erik Joelsson wrote:
> Hello David,
>
> Most of it looks good, but profile-includes.txt could certainly benefit
> from some reduction in duplication. (Aside from the extension of the
> file itself, which I find a bit weird, but it's already there.) The two
> common structures that I can see are:
> 1. Expanding debuginfo files for macosx.
> 2. Assigning/expanding libraries to the correct variable.
>
> For macosx debuginfo expanding, I would define a macro to something like
> this:
>
> # Expand the contents of the .dSYM directories on macosx.
> # Param 1 - debug files list
> # Param 2 - libraries list
> define expand-debuginfo
>    $(if $(and $(filter-out true, $(ZIP_DEBUGINFO_FILES)), $(filter
> macosx, $(OPENJDK_TARGET_OS))), \
>        $(foreach i, $1, $(addsuffix /Contents/Info.plist, $i)) \
>            $(foreach i, $2, $(addsuffix /Contents/Resources/DWARF/$i,
> $(filter $i.%, $1))), \
>        $1)
> endef
>
> And use it like this:
>
> PROFILE_1_DEBUG_FILES := $(call expand-debuginfo,
> $(PROFILE_1_DEBUG_FILES), $(PROFILE_1_LIBRARIES))
>
> Filtering out jsig can be done on the parameters at the macro call.
>
> For the conditional addprefix of OPENJDK_TARGET_CPU_LEGACY_LIB, I would
> do something like:
>
> ifeq (, $(findstring $(OPENJDK_TARGET_OS), windows macosx))
>    LIB_SUBDIR := $(OPENJDK_TARGET_CPU_LEGACY_LIB)/
> else
>    LIB_SUBDIR :=
> endif
>
> And then always assign PROFILE_*_JRE_LIB_FILES with $(addprefix
> $(LIB_SUBDIR), ...). The conditional on Windows for assigning to
> ...BIN_FILES or ...LIB_FILES I would leave in place since I don't think
> a macro solution would make it easier to understand.
>
> /Erik
>
>
> On 2014-12-01 01:09, David Holmes wrote:
>> Main bug is 8038189 but that is a closed bug, the open backport issue is:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8066200
>>
>> Compact Profiles support was added in 8, but only for the Linux
>> platform. I've now generalized this support to all the other
>> platforms. This is an 8u only change, targetting 8u60, as soon as the
>> jdk8u/dev starts accepting things for 8u60.
>>
>> The changes are not that extensive - mostly generalizing the lists and
>> accounting for different platforms putting files into different places
>> (jre/lib/<arch> vs jre/lib vs jre/bin). It isn't necessary to produce
>> detailed per-platform lists as files that don't exist simply don't get
>> copied; but when files are obviously platform specific then I add them
>> under suitable guards.
>>
>> The biggest complexity comes from the debuginfo files, and in
>> particular unzipped debuginfo files. This accounts for the bulk of the
>> changes in profiles-includes.txt, as we try to identify the set of
>> debug files that might exist for each library (and OSX is the main
>> complication due to the .dSYM directory because the existing rules
>> only copy files not directories). Suggestions for reducing the
>> duplicated patterns would be appreciated.
>>
>> Platform specific contents were determined in conjunction with
>> examination of what Jigsaw is using in JDK 9 for the base module.
>>
>> I tested all the main platforms (Windows, Linux, Solaris and OSX) and
>> with/without zipping of debuginfo files. Note that Windows builds will
>> not work with unzipped debuginfo files due to 8025936, but I checked
>> that multiple debug info files were expanded into the right set of
>> targets.
>>
>> webrevs:
>>
>> http://cr.openjdk.java.net/~dholmes/8038189/webrev.top/
>>
>> make/Main.gmk:
>>  - Remove the os-check that constrained profiles to linux
>>
>> http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk/
>>
>> make/CreateJars.gmk:
>>  - Check for empty variables (Solaris doesn't like them)
>>  - Fix # # comments
>>  - Add explicit targets for the beanless classes with $ in them (the %
>> substitution doesn't work on all platforms when $ is also present)
>>
>> make/Images.gmk
>>  - Don't filter out server VM from compact profiles
>>
>> make/Import.gmk
>>  - Add Info.plist to the exported files (for unzipped debuginfo files
>> - this is a general fix not profiles specific so may warrant its own CR)
>>
>> make/Profiles.gmk
>>  - Remove linux-only comment
>>
>> make/Tools.gmk
>>  - Fix tool definitions to use $(PATH_SEP) and quote cp entries
>>
>> make/profile-includes.txt
>>  - Bulk of changes as described above
>>
>> make/profile-rtjar-includes.txt
>>  - Additional packages that exist on OSX only (but don't need to be
>> conditionally added)
>>  - NOTE: if AIX or other platform add platform specific packages not
>> already included by an enclosing package, then they will also need to
>> be added
>>
>> Thanks,
>> David
>


From volker.simonis at gmail.com  Tue Dec  2 08:39:13 2014
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 2 Dec 2014 09:39:13 +0100
Subject: Better NewIO2 file system implementation for AIX platform
In-Reply-To: <CA+3eh12YE97A6qYBVaPTp-GHi00b1R4Aws3z75F03LwbyxnAjw@mail.gmail.com>
References: <CADsbJLmbk4s4CyeEqzHVU=QTx6EhRrOdD5B0yY==uaPZ9e6-Gg@mail.gmail.com>
	<547C29F1.6040303@oracle.com>
	<CA+3eh12YE97A6qYBVaPTp-GHi00b1R4Aws3z75F03LwbyxnAjw@mail.gmail.com>
Message-ID: <CA+3eh12pRRq4QNE+pWhfu01L4=miqgkT_hKak_QeYD52EH8B_g@mail.gmail.com>

Hi Deven,

I've just realized that you still use the Linux functions fgetxattr,
fsetxattr, ... I don't think this will ever work on AIX. Please use
the corresponding functions from <sys/ea.h> (i.e. getea, setea,
removeea).

Thanks,
Volker


On Mon, Dec 1, 2014 at 7:38 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
> On Mon, Dec 1, 2014 at 9:42 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> On 01/12/2014 08:06, deven you wrote:
>>>
>>> Hi All,
>>>
>
> Hi Deven,
>
> thank you for your contribution. Please find my comments inline:
>
>>> Our current NIO2 file system support to AIX is very limited, hence I took
>>> some time to try to complete it. Openjdk bug[1] tracks this bug and here
>>> is
>>> my patch[2] which enhances the AIX file system especially by adding the
>>> support by Implementing AixDosFileAttributeView.java and
>>> AixUserDefinedFileAttributeView.java.
>>>.
>>> Could anyone take a look?
>>>
>> Does SAMBA or other CIFS servers running on AIX store the DOS attributes as
>> extended attributes? I'm just wondering if the DOS file attribute view makes
>> sense or not.
>>
>
> I'm by no means an expert in this area and just started to experiment
> a little bit. While looking at tests like
> 'java/nio/file/attribute/DosFileAttributeView/Basic.java' I was
> surprised to see that DosFileAttributeView can also be used on Linux.
> While this makes sense for DOS file systems mounted into Linux which
> map the DOS attributes to extended attributes on Unix it is probably
> academic for file systems like ext2/3/4 which support extended
> attributes as well. Unfortunately, tests like
> DosFileAttributeView/Basic.java mostly test extended attributes on a
> Linux files system because they only create and change files in /tmp
> which is hardly ever a mounted DOS file system.
>
> All that said, on AIX the JFS2 file system also supports extended
> attributes (see
> http://en.wikipedia.org/wiki/Extended_file_attributes). Hopefully the
> CIFS client correctly maps the DOS attributes to extended user
> attributes but I couldn't check that today because I couldn't find a
> AIX box with CIFS client today. I'll try to find one tomorrow, but
> perhaps Deven can already confirm this?
>
> Following some more comments:
>
> AixDosFileAttributeView.java
>  - please replace "ext3" by "JFS2" in the comment as I'm not aware of
> any ext3 support in AIX
>
> AixFileStore.java
>  - the detection if extended attributes are supported doesn't seem to
> work. It seems like supportsFileAttributeView() has been just copied
> from the corresponding Linux implementation but that won't work on
> AIX. Please remove the ext3/4 stuff and do a real check (i.e. check if
> the file system is JFS2 and if extended attributes have been enabled
> on on the corresponding file system. See 'chfs -a ea=v2', 'man 2
> getea', setea, ...).
>  - the test DosFileAttributeView/Basic.java should succeed without
> saying "DOS file attribute not supported."
>
> AixNativeDispatcher.java
> AixNativeDispatcher.c
>  - you define 'getAixMountEntries()', 'queryMountEntrySize()' and the
> corresponding native implementations but they don't seemed to be used
> anywhere. Please remove this dead code. If you need to get a list of
> all mounted file systems you could use 'getmntctl()' which is already
> there and does exactly that.
>
>> I suspect you will need to update a number of tests to (like
>> FileSystem/Basic.java) and Files/CopyAndMove.java) to ensure that this new
>> code is exercised by the tests.
>>
>
> Yes, could you please elaborate how you have tested your
> implementation until now?
>
> Thank you and best regards,
> Volker
>
>> A minor comment but we usually use 4-space indentation in the library native
>> code.
>>
>> -Alan


From patrick at reini.net  Tue Dec  2 09:22:02 2014
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 2 Dec 2014 10:22:02 +0100
Subject: Library enhancement proposal for copying data from/to
	Reader/Writer InputStream/OutputStream
In-Reply-To: <216A14EF-B62C-4971-8194-EFFBD30933B0@oracle.com>
References: <566A428C-1A13-4DEE-940B-2EBE375F2A7A@reini.net>
	<51329A99-55E5-4A42-9180-D872366B4DEE@oracle.com>
	<D677D240-A59F-4ED6-A740-53F98B7DD49A@reini.net>
	<546EABED.9030301@oracle.com> <546EF98C.40704@oracle.com>
	<B764DE29-57BB-4BD9-B538-7A650723BF2B@reini.net>
	<1D392C1F-E6CC-494D-97F8-C08C5BA36392@oracle.com>
	<E9277204-264A-49A8-971C-6B2FF0B831A4@reini.net>
	<FB33655F-D0D8-47CF-82B0-530C9A212B8E@oracle.com>
	<B10C4D8D-6A57-41FE-8ABC-54E09B4DA14D@reini.net>
	<A3953E4D-018A-44C8-8106-DC9E4663D67C@reini.net>
	<C62A3014-1F54-41E4-B560-198F87305B9E@reini.net>
	<54772C7D.7080209@oracle.com>
	<769E83F8-FD6D-4F8B-B415-DD044C5D08BA@reini.net>
	<D1E803CB-29AF-46AA-9990-77B2A05EFBD4@oracle.com>
	<547757EE.4090205@oracle.com>
	<ED697D7C-F60A-4CD7-B84E-88C10D45B9FB@reini.net>
	<D2DD43D0-5D86-446A-A67A-8D3AEB2541CD@oracle.com>
	<15B58029-95FA-4D9E-AA28-7A6C72D6CB3D@reini.net>
	<13156FAC-6EDC-462B-9BE7-2DFAFB9124FD@oracle.com>
	<20141128201546.000067ce.ecki@zusammenkunft.net>
	<216A14EF-B62C-4971-8194-E...
Message-ID: <8E1109C5-4C9E-4B7A-924E-9E92B3F93F89@reini.net>

Finally got the time to search thru the JDK codebase - at the moment JDK8 due the lack of a working Netbeans Project for JDK9 (I will try to make that working again) 

>> What usage would you actually search in the OpenJDK code base?
> 
> We're talking about copying with provided buffer, right?
> 
> long copy(InputStream source, OutputStream target, byte[] buffer)
>                                                   ^^^^^^^^^^^^^
> It would be very helpful to verify that this method is needed extremely rare,
> if at all. In our case it would be an array of very specific
> (other than 1024, 2048, 4096 or 8192) size, i.e. unusually large or small or
> heavily reused one.
> 
> To copy from an input stream to an output stream you need to try to read a byte
> from the input stream, at least once. Therefore search for usages of
> these methods will be a good start:
> 
> java.io.InputStream#read(byte[])

not referred within the JDK at all

> java.io.InputStream#read(byte[], int, int)

I found around 190 usage references in total of those there are the following 28 references that could use my proposed copy feature and 5 of those use 8192 bytes sized buffers.

The short list following shows the path to the resource, line where the byte buffer is initialized and the buffer size taken

jdk/src/solaris/classes/sun/print/UnixPrintJob.java 589 / 1024
jdk/src/windows/classes/sun/print/Win32PrintJob.java 444 / 1024
jdk/src/share/classes/sun/security/provider/X509Factory.java 119 / 2048
jdk/src/share/classes/com/sun/media/sound/JavaSoundAudioClip.java 356 / 16384
jdk/src/share/classes/com/sun/media/sound/AudioFileSoundbankReader.java 83 / 1024
jdk/src/share/classes/javax/swing/text/rtf/AbstractFilter.java 99 / 16384
jdk/src/share/classes/sun/net/NetworkServer.java 120 / 300
jdk/src/share/classes/sun/net/ftp/impl/FtpClient.java 1352 / 15000
jdk/src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java 2148 / 1024
jdk/src/share/classes/java/awt/Font.java 934 / 8192
jdk/src/share/classes/sun/security/provider/certpath/X509CertPath.java 259 / 8192
jdk/src/share/classes/com/sun/media/sound/AiffFileWriter.java 236 / 4096
jdk/src/share/classes/sun/net/www/MimeLauncher.java 118 / 2048
jdk/src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInput.java 492 / 4096
jdk/src/share/classes/java/util/jar/JarInputStream.java 109 / 8192
jdk/src/share/classes/sun/tools/jar/Main.java 822 / 8192
jdk/src/share/classes/javax/management/loading/MLet.java 1170 / 4096
jdk/src/share/classes/sun/awt/datatransfer/DataTransferer.java 1311 / 8192
jdk/src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java 144 / 4096
jdk/src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java 52 / 1024
jdk/src/share/classes/java/nio/file/Files.java 2906 / 8192
jdk/src/share/classes/sun/security/tools/keytool/Main.java 2140 / 4096
jdk/src/share/classes/com/sun/media/sound/ModelByteBuffer.java 194 / 1024
jdk/src/share/classes/sun/swing/SwingUtilities2.java 1566 / 1024
jdk/src/share/classes/com/sun/org/apache/xml/internal/security/utils/JavaUtils.java 140 / 4096
jdk/src/share/classes/com/sun/media/sound/SoftMixingClip.java 333 / multiple of 512
jdk/src/share/classes/com/sun/media/sound/StandardMidiFileWriter.java 141 / 16384
jdk/src/share/classes/com/sun/media/sound/WaveFileWriter.java 236 / 4096




From david.holmes at oracle.com  Tue Dec  2 09:35:05 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 02 Dec 2014 19:35:05 +1000
Subject: Packing 2 data points into 1 field in ThreadPoolExecutor
In-Reply-To: <CB6B7B6C-C167-40A1-B15A-7530150B1B7E@icloud.com>
References: <F20EAFC5-2BD8-4787-901B-413B9D4A84E2@icloud.com>
	<0F081861-ACBA-484E-9FA7-784D2EE4A023@icloud.com>
	<CA+kOe08odwpUrUeeniY+j8SyraATDLbBSHWF+S2=1ECoT_R1wA@mail.gmail.com>
	<CBACF05C-2856-43BB-8EAE-D46680D8AD05@icloud.com>
	<547D24B4.2090001@oracle.com>
	<CB6B7B6C-C167-40A1-B15A-7530150B1B7E@icloud.com>
Message-ID: <547D87C9.30806@oracle.com>

On 2/12/2014 4:51 PM, Alex Yursha wrote:
> Thanks for all responses. All this is much clearer now.
>
> Am I right that all this state packing is for better performance only and the same behaviour can be achieved by using explicit locks?

Sure.

David

>> On Dec 2, 2014, at 05:32, David Holmes <david.holmes at oracle.com> wrote:
>>
>> On 2/12/2014 3:44 AM, Alex Yursha wrote:
>>> 1. Do you mean 'the only way', except using a lock?
>>>
>>> 2. I also cant imagine how we can use long primitive type for CAS atomicity without a lock if only its not an AtomicLong. Any hint here, please?
>>
>> AtomicFieldUpdater can apply atomic operations to plain (volatile) int and long fields. The Unsafe API can also be used to do it more performantly.
>>
>> David
>>
>>> Thanks
>>>
>>>
>>> Sent from my iPhone
>>>
>>>> On Dec 1, 2014, at 20:27, Martin Buchholz <martinrb at google.com> wrote:
>>>>
>>>> The only way to use atomic compare and set is to pack all your state
>>>> into a single primitive unit.  The largest we have is "long".  So we
>>>> regularly pack what the C folks would call bitfields into longs.
>>>>
>>>>> On Sat, Nov 29, 2014 at 8:13 AM, Alex Yursha <alexyursha at gmail.com> wrote:
>>>>> Hi all,
>>>>>
>>>>> According to javadoc current implementation of ThreadPoolExecutor packs two conceptual fields ?workerCount? and ?runState? into one actual field ?ctl? of type AtomicInteger.
>>>>>
>>>>> Could you please explain are there any performance or other benefits for this? It seems to complicate the class design and I can?t find the positive side of this.
>>>>>
>>>>> Thanks,
>>>>> Alex
>>>>>
>


From paul.sandoz at oracle.com  Tue Dec  2 09:49:30 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 2 Dec 2014 10:49:30 +0100
Subject: RFR: 8065172: More core reflection final and volatile annotations
In-Reply-To: <CA+kOe0-AEf_1ZJ0rDziKo5cAStQSasdZ-eDeFGs+2Gqss1_uxA@mail.gmail.com>
References: <CA+kOe0_ek6UDjkOXEggp3JYo=ezxRqprLFUJxQb0v3Mnzj41JQ@mail.gmail.com>
	<546E09D6.9040800@gmail.com>
	<6B93C453-C558-4C0E-B7FA-4255507B154D@oracle.com>
	<54735081.5050201@gmail.com>
	<A1B7B5B4-9590-4155-8546-3117D47AD590@oracle.com>
	<CA+kOe0-AEf_1ZJ0rDziKo5cAStQSasdZ-eDeFGs+2Gqss1_uxA@mail.gmail.com>
Message-ID: <4E57D36E-1D9A-4EB4-9130-B80730C35069@oracle.com>

On Nov 25, 2014, at 3:06 AM, Martin Buchholz <martinrb at google.com> wrote:

> I tried to address all the known problems in sun/reflect (except for
> the performance ones), including the ones in Peter's webrev (although
> it now looks quite different).
> 
> I broke down and switched to using AtomicReferenceFieldUpdaters for
> all lazily initialized operations,
> like I had been thinking of doing.
> 
> For the weird classes where we need to lazily switch the
> implementation of bounds, I store in an Object[] and cas to update.
> 
> Now that we're using atomic updaters, it's hard to have any relaxed
> operations unless we also introduce Unsafe.  My current thinking is
> this code is not performance critical enough to do that sort of
> brittle thing.  Volatile reads are either already very cheap or are
> likely to get cheaper over time.  The code using updaters seems
> robust, efficient, and deadlock free, unlike some other code in the
> JDK.  Using updaters means there will never be an extremely rare bug
> due to different objects being returned from a reflection method.
> 
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/
> 

I am not convinced about the use of CAS. If we can get away with just volatile fields I think the code is simpler. Are you concerned there are cases of identity and mutability?

All other aspects look good.

Paul.



From paul.sandoz at oracle.com  Tue Dec  2 10:02:27 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 2 Dec 2014 11:02:27 +0100
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
Message-ID: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>

Hi,

Please find below a patch to remove the networking code computing a seed in ThreadLocal/SplittableRandom.

We thought it a good idea at the time :-) but subsequently on certain platforms this results in very high initalization costs that can propagate to other classes such as ConcurrentSkipList*.

The short-term solution is to remove this code and fallback just using current system time. This needs to be back-ported to 8u40.

A longer term solution is to provide a simple public API to get access to some seed bytes that is optimal for the underlying platform, for example, based on Peter's investigations. For linux /dev/urandom is sufficient as a source of bytes. The main problem seems to be Windows. It would also be nice to back-port to say 8u60 using a private API and update TLR/SR.

Paul.

[1] https://bugs.openjdk.java.net/browse/JDK-8060435

diff -r 1b599b4755bd src/java.base/share/classes/java/util/SplittableRandom.java
--- a/src/java.base/share/classes/java/util/SplittableRandom.java	Mon Dec 01 17:59:39 2014 -0800
+++ b/src/java.base/share/classes/java/util/SplittableRandom.java	Tue Dec 02 10:53:47 2014 +0100
@@ -237,34 +237,7 @@
                 s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
             return s;
         }
-        long h = 0L;
-        try {
-            Enumeration<NetworkInterface> ifcs =
-                    NetworkInterface.getNetworkInterfaces();
-            boolean retry = false; // retry once if getHardwareAddress is null
-            while (ifcs.hasMoreElements()) {
-                NetworkInterface ifc = ifcs.nextElement();
-                if (!ifc.isVirtual()) { // skip fake addresses
-                    byte[] bs = ifc.getHardwareAddress();
-                    if (bs != null) {
-                        int n = bs.length;
-                        int m = Math.min(n >>> 1, 4);
-                        for (int i = 0; i < m; ++i)
-                            h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
-                        if (m < 4)
-                            h = (h << 8) ^ bs[n-1-m];
-                        h = mix64(h);
-                        break;
-                    }
-                    else if (!retry)
-                        retry = true;
-                    else
-                        break;
-                }
-            }
-        } catch (Exception ignore) {
-        }
-        return (h ^ mix64(System.currentTimeMillis()) ^
+        return (mix64(System.currentTimeMillis()) ^
                 mix64(System.nanoTime()));
     }
 
diff -r 1b599b4755bd src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java
--- a/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java	Mon Dec 01 17:59:39 2014 -0800
+++ b/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java	Tue Dec 02 10:53:47 2014 +0100
@@ -147,34 +147,7 @@
                 s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
             return s;
         }
-        long h = 0L;
-        try {
-            Enumeration<NetworkInterface> ifcs =
-                    NetworkInterface.getNetworkInterfaces();
-            boolean retry = false; // retry once if getHardwareAddress is null
-            while (ifcs.hasMoreElements()) {
-                NetworkInterface ifc = ifcs.nextElement();
-                if (!ifc.isVirtual()) { // skip fake addresses
-                    byte[] bs = ifc.getHardwareAddress();
-                    if (bs != null) {
-                        int n = bs.length;
-                        int m = Math.min(n >>> 1, 4);
-                        for (int i = 0; i < m; ++i)
-                            h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
-                        if (m < 4)
-                            h = (h << 8) ^ bs[n-1-m];
-                        h = mix64(h);
-                        break;
-                    }
-                    else if (!retry)
-                        retry = true;
-                    else
-                        break;
-                }
-            }
-        } catch (Exception ignore) {
-        }
-        return (h ^ mix64(System.currentTimeMillis()) ^
+        return (mix64(System.currentTimeMillis()) ^
                 mix64(System.nanoTime()));
     }


From Alan.Bateman at oracle.com  Tue Dec  2 10:10:14 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 02 Dec 2014 10:10:14 +0000
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
Message-ID: <547D9006.3040401@oracle.com>

On 02/12/2014 10:02, Paul Sandoz wrote:
> Hi,
>
> Please find below a patch to remove the networking code computing a seed in ThreadLocal/SplittableRandom.
>
> We thought it a good idea at the time :-) but subsequently on certain platforms this results in very high initalization costs that can propagate to other classes such as ConcurrentSkipList*.
>
> The short-term solution is to remove this code and fallback just using current system time. This needs to be back-ported to 8u40.
>
> A longer term solution is to provide a simple public API to get access to some seed bytes that is optimal for the underlying platform, for example, based on Peter's investigations. For linux /dev/urandom is sufficient as a source of bytes. The main problem seems to be Windows. It would also be nice to back-port to say 8u60 using a private API and update TLR/SR.
>
> Paul.
The approach seems pragmatic and the change looks okay to me (you might 
have some unused imports to removed too).

-Alan.


From Alan.Bateman at oracle.com  Tue Dec  2 10:15:36 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 02 Dec 2014 10:15:36 +0000
Subject: RFR 8065998: Avoid use of _ as a one-character identifier
In-Reply-To: <547C6F0D.3010308@oracle.com>
References: <547C5AB5.2020404@oracle.com> <547C6B14.8020209@oracle.com>
	<547C6F0D.3010308@oracle.com>
Message-ID: <547D9148.2080400@oracle.com>

On 01/12/2014 13:37, Jan Lahoda wrote:
> :
>
>>
>> In TypeCheckMicroBenchmark then "ignore" is might be a misleading too
>> given that the ArrayStoreException causes a CCE to be thrown.
>
> I've updated the patch to use "expected" where the exception appears 
> to be expected and "unused" where exception appears to be unexpected, 
> but the variable is not used.
>
> Updated patches:
> jaxp:
> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.01/jaxp/
> jdk:
> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.01/jdk/
webrev.01 looks good to me.

-Alan


From Alan.Bateman at oracle.com  Tue Dec  2 10:18:07 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 02 Dec 2014 10:18:07 +0000
Subject: RFR - 8065552: setAccessible(true) on fields of Class may throw
	a SecurityException
In-Reply-To: <547CD910.7050000@oracle.com>
References: <547C9770.50007@oracle.com>
	<547CA9F0.9040100@oracle.com>	<547CB960.7040402@oracle.com>
	<547CD910.7050000@oracle.com>
Message-ID: <547D91DF.1040801@oracle.com>

On 01/12/2014 21:09, Se?n Coffey wrote:
>
> On 01/12/2014 18:54, Daniel Fuchs wrote:
>>> on the test side would it be worth testing all public classes available
>>> (e.g in rt.jar ?) to ensure that
>>> Field.setAccessible works as expected and that we don't hit this issue
>>> again ? It might be some
>>> what of a heavy test for jtreg inclusion though.
>>
>> It could be worth a try. But let's wait until JEP 220 is in.
> I'm not sure why JEP 220 would be a factor for now.
I assume this is only because the test would need changes to use the 
"jrt" file system to locate all class files (and infer the type names).

-Alan.


From paul.sandoz at oracle.com  Tue Dec  2 10:21:08 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 2 Dec 2014 11:21:08 +0100
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <547D9006.3040401@oracle.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
	<547D9006.3040401@oracle.com>
Message-ID: <5A461189-DA58-4546-8D7F-282604311538@oracle.com>


On Dec 2, 2014, at 11:10 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

> On 02/12/2014 10:02, Paul Sandoz wrote:
>> Hi,
>> 
>> Please find below a patch to remove the networking code computing a seed in ThreadLocal/SplittableRandom.
>> 
>> We thought it a good idea at the time :-) but subsequently on certain platforms this results in very high initalization costs that can propagate to other classes such as ConcurrentSkipList*.
>> 
>> The short-term solution is to remove this code and fallback just using current system time. This needs to be back-ported to 8u40.
>> 
>> A longer term solution is to provide a simple public API to get access to some seed bytes that is optimal for the underlying platform, for example, based on Peter's investigations. For linux /dev/urandom is sufficient as a source of bytes. The main problem seems to be Windows. It would also be nice to back-port to say 8u60 using a private API and update TLR/SR.
>> 
>> Paul.
> The approach seems pragmatic and the change looks okay to me

Thanks.


> (you might have some unused imports to removed too).
> 

Doh! yes, removed.

Paul.


From paul.sandoz at oracle.com  Tue Dec  2 10:41:31 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 2 Dec 2014 11:41:31 +0100
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <547D0EB2.3070802@cs.oswego.edu>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>
	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>
	<547D0EB2.3070802@cs.oswego.edu>
Message-ID: <C8007E24-9D2F-4909-9340-C3E57E37F9BE@oracle.com>


On Dec 2, 2014, at 1:58 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 12/01/2014 03:46 PM, Martin Buchholz wrote:
>> David, Paul (i.e. Reviewers) and Doug,
>> 
>> I'd like to commit corrections so we make progress.
> 
> The current one looks OK to me.
> (http://cr.openjdk.java.net/~martin/webrevs/openjdk9/fence-intrinsics/)
> 

Same here, looks ok.

I anticipate we will be revisiting this area with the enhanced volatiles [1] work and related JMM updates, where there will be a public API for low-level enhanced field/array access [2].

As you rightly observed Unsafe does not currently have a get/read-acquire method. Implementations of [2] currently emulate that with a relaxed read + Unsafe.loadFence. It's something we need to add.

Paul.

[1] http://openjdk.java.net/jeps/193
[2] http://hg.openjdk.java.net/valhalla/valhalla/jdk/file/2d4531473a89/src/java.base/share/classes/java/lang/invoke/VarHandle.java


From dl at cs.oswego.edu  Tue Dec  2 12:17:53 2014
From: dl at cs.oswego.edu (Doug Lea)
Date: Tue, 02 Dec 2014 07:17:53 -0500
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
Message-ID: <547DADF1.7030605@cs.oswego.edu>

On 12/02/2014 05:02 AM, Paul Sandoz wrote:
> Hi,
>
> Please find below a patch to remove the networking code computing a seed in ThreadLocal/SplittableRandom.
>

Thanks for pushing this through.
(I also adjusted 166 sources accordingly.)
One more touch-up for SplittableRandom is to remove mention
of network interface in internal comments:

***************
*** 140,150 ****
        * other cases, this split must be performed in a thread-safe
        * manner, so we use an AtomicLong to represent the seed rather
        * than use an explicit SplittableRandom. To bootstrap the
!      * defaultGen, we start off using a seed based on current time and
!      * network interface address unless the java.util.secureRandomSeed
!      * property is set. This serves as a slimmed-down (and insecure)
!      * variant of SecureRandom that also avoids stalls that may occur
!      * when using /dev/random.
        *
        * It is a relatively simple matter to apply the basic design here
        * to use 128 bit seeds. However, emulating 128bit arithmetic and
--- 139,148 ----
        * other cases, this split must be performed in a thread-safe
        * manner, so we use an AtomicLong to represent the seed rather
        * than use an explicit SplittableRandom. To bootstrap the
!      * defaultGen, we start off using a seed based on current time
!      * unless the java.util.secureRandomSeed property is set. This
!      * serves as a slimmed-down (and insecure) variant of SecureRandom
!      * that also avoids stalls that may occur when using /dev/random.
        *
        * It is a relatively simple matter to apply the basic design here
        * to use 128 bit seeds. However, emulating 128bit arithmetic and
***************



From paul.sandoz at oracle.com  Tue Dec  2 12:41:44 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 2 Dec 2014 13:41:44 +0100
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <547DADF1.7030605@cs.oswego.edu>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
	<547DADF1.7030605@cs.oswego.edu>
Message-ID: <B3E74E1B-DD82-4A0E-A36F-8DA9A76C88FA@oracle.com>


On Dec 2, 2014, at 1:17 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 12/02/2014 05:02 AM, Paul Sandoz wrote:
>> Hi,
>> 
>> Please find below a patch to remove the networking code computing a seed in ThreadLocal/SplittableRandom.
>> 
> 
> Thanks for pushing this through.
> (I also adjusted 166 sources accordingly.)
> One more touch-up for SplittableRandom is to remove mention
> of network interface in internal comments:
> 
> ***************
> *** 140,150 ****
>       * other cases, this split must be performed in a thread-safe
>       * manner, so we use an AtomicLong to represent the seed rather
>       * than use an explicit SplittableRandom. To bootstrap the
> !      * defaultGen, we start off using a seed based on current time and
> !      * network interface address unless the java.util.secureRandomSeed
> !      * property is set. This serves as a slimmed-down (and insecure)
> !      * variant of SecureRandom that also avoids stalls that may occur
> !      * when using /dev/random.
>       *
>       * It is a relatively simple matter to apply the basic design here
>       * to use 128 bit seeds. However, emulating 128bit arithmetic and
> --- 139,148 ----
>       * other cases, this split must be performed in a thread-safe
>       * manner, so we use an AtomicLong to represent the seed rather
>       * than use an explicit SplittableRandom. To bootstrap the
> !      * defaultGen, we start off using a seed based on current time
> !      * unless the java.util.secureRandomSeed property is set. This
> !      * serves as a slimmed-down (and insecure) variant of SecureRandom
> !      * that also avoids stalls that may occur when using /dev/random.
>       *
>       * It is a relatively simple matter to apply the basic design here
>       * to use 128 bit seeds. However, emulating 128bit arithmetic and
> ***************
> 

Thanks, updated my copy,
Paul.



From miroslav.kos at oracle.com  Tue Dec  2 14:03:06 2014
From: miroslav.kos at oracle.com (Miroslav Kos)
Date: Tue, 02 Dec 2014 15:03:06 +0100
Subject: RFR: 8065870 Update JAX-WS RI integration to latest version
	(2.2.11-b141124.1933)
In-Reply-To: <547CC30A.1020207@oracle.com>
References: <54770AB6.6050806@oracle.com> <547CC30A.1020207@oracle.com>
Message-ID: <547DC69A.2000908@oracle.com>

Hi Stuart,
minor stuff like invalid characters and copyright years I can fix before 
push, the rest will leave for next integration which should be soon.

Thanks!
Miran



On 01/12/14 20:35, Stuart Marks wrote:
> Hi Miran,
>
> I'm pretty distant from the JAX-WS code, but I looked through all of 
> the files and most of the changes seem sensible. There are a few 
> things that are questionable though.
>
> ** 
> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java
>
> The catch-and-ignore of Throwable at line 565 seems questionable. 
> Wouldn't it be better to catch a few specific exception types that 
> might be thrown from setProperty()?
>
> ** 
> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/resources/Messages_en.properties
>
> The copyright year is changed from 2013 to 2012.
>
> The unknown character replacement (line 277) is replaced with a '?', 
> though I'm not sure what's really happening here since webrev might be 
> mishandling non-ascii characters. If this is intended to be an ascii 
> file, shouldn't the replacement be a plain single quote (') ?
>
> ** 
> src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle.properties
>
> The version numbers in this file seem to be moved forward, but the 
> copyright is updated from 2014 to 2012. The same appears to be true of 
> the localized versions of this file.
>
> ** 
> src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties
>
> Copyright years 2014 => 2012 again. Also check localized versions of 
> this file.
>
> ** 
> src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle.properties
>
> Copyright years 2013 => 2012. Possibly incorrect replacement "???" for 
> unknown character in original file.
>
> ** 
> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/version.properties
>
> Copyright years 2014 => 2013.
>
> ==========
>
> Nothing earth-shattering here. If you want to push this changeset and 
> fix up these issues later (if indeed they need to be fixed up), I'd be 
> fine with that.
>
> s'marks
>
>
>
>
>
> On 11/27/14 3:27 AM, Miroslav Kos wrote:
>> Hi,
>> there is a bulk update of JAX-B/WS from upstream projects -
>> webrev: http://cr.openjdk.java.net/~mkos/8065870/jaxws.00/
>> more details in issue desc: 
>> https://bugs.openjdk.java.net/browse/JDK-8065870
>>
>> Could I ask for a review?
>>
>> It seems quite big (1126 lines changed) but there are just minor 
>> changes/fixes.
>>
>> Thanks
>> Miran



From jan.lahoda at oracle.com  Tue Dec  2 14:23:56 2014
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 02 Dec 2014 15:23:56 +0100
Subject: RFR 8065998: Avoid use of _ as a one-character identifier
In-Reply-To: <547D9148.2080400@oracle.com>
References: <547C5AB5.2020404@oracle.com> <547C6B14.8020209@oracle.com>
	<547C6F0D.3010308@oracle.com> <547D9148.2080400@oracle.com>
Message-ID: <547DCB7C.4060109@oracle.com>

Thanks to all for the comments!

Jan

On 2.12.2014 11:15, Alan Bateman wrote:
> On 01/12/2014 13:37, Jan Lahoda wrote:
>> :
>>
>>>
>>> In TypeCheckMicroBenchmark then "ignore" is might be a misleading too
>>> given that the ArrayStoreException causes a CCE to be thrown.
>>
>> I've updated the patch to use "expected" where the exception appears
>> to be expected and "unused" where exception appears to be unexpected,
>> but the variable is not used.
>>
>> Updated patches:
>> jaxp:
>> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.01/jaxp/
>> jdk:
>> http://cr.openjdk.java.net/~jlahoda/8065998/webrev.01/jdk/
> webrev.01 looks good to me.
>
> -Alan


From lance.andersen at oracle.com  Tue Dec  2 14:33:20 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 2 Dec 2014 09:33:20 -0500
Subject: Review request for JDK-8051536: Convert JAXP function tests:
	javax.xml.parsers to jtreg(testng) tests
In-Reply-To: <00d901d00ddb$b7e40f80$27ac2e80$@oracle.com>
References: <00d901d00ddb$b7e40f80$27ac2e80$@oracle.com>
Message-ID: <26947A65-EE8C-4F8A-86D9-24A045244DC4@oracle.com>

Hi Frank,

I think this looks good overall.

I might suggest that you consider utilizing the @BeforeMethod methods further, For example is SAXParserTest03.java you could move

SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setValidating(true);


 to your @BeforeMethod, or consider using a DataProvider that is accessible from all classes to reduce some code duplication which will make maintenance a bit easier.

I am not sure how much more additional info failUnexpected adds, but you could omit this if you choose and just have the test method throw Exception and you will get your failure.

Again the above are suggestions, but should not prevent you pushing this to the workspace

Best
Lance
On Dec 1, 2014, at 9:57 PM, Frank Yuan <frank.yuan at oracle.com> wrote:

> Hi, Joe and All
> 
> We are working on moving internal jaxp functional tests to open jdk repo.
> This is the parsers suite. Would you please review these test?  Any comment
> will be appreciated.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8051536
> webrev: http://cr.openjdk.java.net/~joehw/jdk9/test/Frank/8051536/webrev/
> 
> 
> Thanks,
> 
> Frank
> 



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





From chris.hegarty at oracle.com  Tue Dec  2 15:09:28 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 2 Dec 2014 15:09:28 +0000
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
Message-ID: <2B2068A1-9BA5-4D4E-885F-DF269647557D@oracle.com>

Thanks for doing this Paul. Looks good ( with Alan and Doug?s comments ).

-Chris.

On 2 Dec 2014, at 10:02, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
> 
> Please find below a patch to remove the networking code computing a seed in ThreadLocal/SplittableRandom.
> 
> We thought it a good idea at the time :-) but subsequently on certain platforms this results in very high initalization costs that can propagate to other classes such as ConcurrentSkipList*.
> 
> The short-term solution is to remove this code and fallback just using current system time. This needs to be back-ported to 8u40.
> 
> A longer term solution is to provide a simple public API to get access to some seed bytes that is optimal for the underlying platform, for example, based on Peter's investigations. For linux /dev/urandom is sufficient as a source of bytes. The main problem seems to be Windows. It would also be nice to back-port to say 8u60 using a private API and update TLR/SR.
> 
> Paul.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8060435
> 
> diff -r 1b599b4755bd src/java.base/share/classes/java/util/SplittableRandom.java
> --- a/src/java.base/share/classes/java/util/SplittableRandom.java	Mon Dec 01 17:59:39 2014 -0800
> +++ b/src/java.base/share/classes/java/util/SplittableRandom.java	Tue Dec 02 10:53:47 2014 +0100
> @@ -237,34 +237,7 @@
>                 s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
>             return s;
>         }
> -        long h = 0L;
> -        try {
> -            Enumeration<NetworkInterface> ifcs =
> -                    NetworkInterface.getNetworkInterfaces();
> -            boolean retry = false; // retry once if getHardwareAddress is null
> -            while (ifcs.hasMoreElements()) {
> -                NetworkInterface ifc = ifcs.nextElement();
> -                if (!ifc.isVirtual()) { // skip fake addresses
> -                    byte[] bs = ifc.getHardwareAddress();
> -                    if (bs != null) {
> -                        int n = bs.length;
> -                        int m = Math.min(n >>> 1, 4);
> -                        for (int i = 0; i < m; ++i)
> -                            h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
> -                        if (m < 4)
> -                            h = (h << 8) ^ bs[n-1-m];
> -                        h = mix64(h);
> -                        break;
> -                    }
> -                    else if (!retry)
> -                        retry = true;
> -                    else
> -                        break;
> -                }
> -            }
> -        } catch (Exception ignore) {
> -        }
> -        return (h ^ mix64(System.currentTimeMillis()) ^
> +        return (mix64(System.currentTimeMillis()) ^
>                 mix64(System.nanoTime()));
>     }
> 
> diff -r 1b599b4755bd src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java
> --- a/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java	Mon Dec 01 17:59:39 2014 -0800
> +++ b/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java	Tue Dec 02 10:53:47 2014 +0100
> @@ -147,34 +147,7 @@
>                 s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
>             return s;
>         }
> -        long h = 0L;
> -        try {
> -            Enumeration<NetworkInterface> ifcs =
> -                    NetworkInterface.getNetworkInterfaces();
> -            boolean retry = false; // retry once if getHardwareAddress is null
> -            while (ifcs.hasMoreElements()) {
> -                NetworkInterface ifc = ifcs.nextElement();
> -                if (!ifc.isVirtual()) { // skip fake addresses
> -                    byte[] bs = ifc.getHardwareAddress();
> -                    if (bs != null) {
> -                        int n = bs.length;
> -                        int m = Math.min(n >>> 1, 4);
> -                        for (int i = 0; i < m; ++i)
> -                            h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
> -                        if (m < 4)
> -                            h = (h << 8) ^ bs[n-1-m];
> -                        h = mix64(h);
> -                        break;
> -                    }
> -                    else if (!retry)
> -                        retry = true;
> -                    else
> -                        break;
> -                }
> -            }
> -        } catch (Exception ignore) {
> -        }
> -        return (h ^ mix64(System.currentTimeMillis()) ^
> +        return (mix64(System.currentTimeMillis()) ^
>                 mix64(System.nanoTime()));
>     }



From peter.levart at gmail.com  Tue Dec  2 16:42:41 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 02 Dec 2014 17:42:41 +0100
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
Message-ID: <547DEC01.2050501@gmail.com>

On 12/02/2014 11:02 AM, Paul Sandoz wrote:
> Hi,
>
> Please find below a patch to remove the networking code computing a seed in ThreadLocal/SplittableRandom.
>
> We thought it a good idea at the time :-) but subsequently on certain platforms this results in very high initalization costs that can propagate to other classes such as ConcurrentSkipList*.
>
> The short-term solution is to remove this code and fallback just using current system time. This needs to be back-ported to 8u40.
>
> A longer term solution is to provide a simple public API to get access to some seed bytes that is optimal for the underlying platform, for example, based on Peter's investigations. For linux /dev/urandom is sufficient as a source of bytes. The main problem seems to be Windows. It would also be nice to back-port to say 8u60 using a private API and update TLR/SR.

Hi,

Here's a proof of concept for an API that just delegates to 
system-provided "cryptographically secure" (as declared by the 
system(s)) pseudo random number generator:

http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.01/

On UNIX-es this uses /dev/urandom (which is non-blocking and uses system 
entropy at least for it's seed):

http://en.wikipedia.org/?title=/dev/random

On Windows it uses MS Crypto API's function CryptGenRandom (the JNI code 
is ripped from the sun.security.provider.NativeSeedGenerator), which 
also seeds from various system sources of entropy:

http://en.wikipedia.org/wiki/CryptGenRandom

http://msdn.microsoft.com/en-us/library/windows/desktop/aa379942%28v=vs.85%29.aspx

The initialization overhead is low on UNIX (the enclosed test run on 64 
bit Fedora 20, i7 PC):

SystemRandomTest... (8 bytes / invocation)
1st invocation: 112315 ns, result: [25, 61, -12, -106, 75, -7, -73, -55]
Following 1000000 invocations: 0.636644474 s, (636 ns/invocation)

The same test run on 32 bit Windows 7 (as VirtualBox guest on the same 
machine):

SystemRandomTest... (8 bytes / invocation)
1st invocation: 4880788 ns, result: [-32, 53, -31, 62, 51, 83, 9, -5]
Following 1000000 invocations: 1.761087512 s, (1761 ns/invocation)

I think the initialization on Windows has an initial latency of approx 
5ms because it has to initialize the whole MS Crypto API with it's 
providers. But CryptGenRandom, which is part of this API, actually 
delegates it's work to RtlGenRandom function:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa387694%28v=vs.85%29.aspx

...which might have lower initialization costs. Unfortunately, the 
wording in the Microsoft document states that it might be removed in the 
future. Perhaps we could try to use it and fallback to CryptGenRandom if 
it is not available...


Regards, Peter


>
> Paul.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8060435
>
> diff -r 1b599b4755bd src/java.base/share/classes/java/util/SplittableRandom.java
> --- a/src/java.base/share/classes/java/util/SplittableRandom.java	Mon Dec 01 17:59:39 2014 -0800
> +++ b/src/java.base/share/classes/java/util/SplittableRandom.java	Tue Dec 02 10:53:47 2014 +0100
> @@ -237,34 +237,7 @@
>                   s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
>               return s;
>           }
> -        long h = 0L;
> -        try {
> -            Enumeration<NetworkInterface> ifcs =
> -                    NetworkInterface.getNetworkInterfaces();
> -            boolean retry = false; // retry once if getHardwareAddress is null
> -            while (ifcs.hasMoreElements()) {
> -                NetworkInterface ifc = ifcs.nextElement();
> -                if (!ifc.isVirtual()) { // skip fake addresses
> -                    byte[] bs = ifc.getHardwareAddress();
> -                    if (bs != null) {
> -                        int n = bs.length;
> -                        int m = Math.min(n >>> 1, 4);
> -                        for (int i = 0; i < m; ++i)
> -                            h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
> -                        if (m < 4)
> -                            h = (h << 8) ^ bs[n-1-m];
> -                        h = mix64(h);
> -                        break;
> -                    }
> -                    else if (!retry)
> -                        retry = true;
> -                    else
> -                        break;
> -                }
> -            }
> -        } catch (Exception ignore) {
> -        }
> -        return (h ^ mix64(System.currentTimeMillis()) ^
> +        return (mix64(System.currentTimeMillis()) ^
>                   mix64(System.nanoTime()));
>       }
>   
> diff -r 1b599b4755bd src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java
> --- a/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java	Mon Dec 01 17:59:39 2014 -0800
> +++ b/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java	Tue Dec 02 10:53:47 2014 +0100
> @@ -147,34 +147,7 @@
>                   s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
>               return s;
>           }
> -        long h = 0L;
> -        try {
> -            Enumeration<NetworkInterface> ifcs =
> -                    NetworkInterface.getNetworkInterfaces();
> -            boolean retry = false; // retry once if getHardwareAddress is null
> -            while (ifcs.hasMoreElements()) {
> -                NetworkInterface ifc = ifcs.nextElement();
> -                if (!ifc.isVirtual()) { // skip fake addresses
> -                    byte[] bs = ifc.getHardwareAddress();
> -                    if (bs != null) {
> -                        int n = bs.length;
> -                        int m = Math.min(n >>> 1, 4);
> -                        for (int i = 0; i < m; ++i)
> -                            h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
> -                        if (m < 4)
> -                            h = (h << 8) ^ bs[n-1-m];
> -                        h = mix64(h);
> -                        break;
> -                    }
> -                    else if (!retry)
> -                        retry = true;
> -                    else
> -                        break;
> -                }
> -            }
> -        } catch (Exception ignore) {
> -        }
> -        return (h ^ mix64(System.currentTimeMillis()) ^
> +        return (mix64(System.currentTimeMillis()) ^
>                   mix64(System.nanoTime()));
>       }



From paul.sandoz at oracle.com  Tue Dec  2 17:02:25 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 2 Dec 2014 18:02:25 +0100
Subject: [9,
	8u40] RFR (M): 8057020: LambdaForm caches should support eviction
In-Reply-To: <547C9E37.8080809@oracle.com>
References: <547C9E37.8080809@oracle.com>
Message-ID: <AF48B73F-02B8-4B9A-A3C9-485AE9D8B1A3@oracle.com>


On Dec 1, 2014, at 5:58 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8057020
> 

That LambdaFormEditor.putInCache method just got more gnarly :-)

Generally looks good.

In src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java

 366                     lambdaForm.transformCache = c = ta;

Do you need to set "c"? It's a local variable and by this point the method should return rather than loop.


In test/java/lang/invoke/LFCaching/LambdaFormTestCase.java

  55     private static final List<GarbageCollectorMXBean> gcInfo;
  56 
  57     private static long gcCount() {
  58         return gcInfo.stream()
  59                 .map(GarbageCollectorMXBean::getCollectionCount)
  60                 .reduce(0L, Long::sum);
  61     }

You can do:

  gcInfo.stream().mapToLong(GarbageCollectorMXBean::getCollectionCount).sum();

Paul.

> There are 2 major LambdaForm caches: LambdaFormEditor-based and MethodTypeForm. The former is per-LambdaForm and the latter is per method type erased to basic types. The problem is that these caches don't support eviction, so they can hold LambdaForms forever.
> 
> Usually, it's not a problem since an application has very limited number of unique erased method types (e.g. on Octane/Nashorn it varies 1,5-3k shapes).
> 
> The fix is to use SoftReferences to keep LambdaForms alive as long as possible, but avoid throwing OOME until the caches are evicted. I experimented with WeakReferences, but it doesn't hold LambdaForms for long enough: LambdaForm cache hit rate degrades significantly and it negatively affects application startup and warmup, since every instantiated LambdaForm is precompiled to bytecode before usage.
> 
> Testing: jdk/java/lang/invoke/LFCache in stress mode + jck (api/java_lang/invoke), jdk/java/lang/invoke, jdk/java/util/streams, octane
> 
> Thanks!
> 
> Best regards,
> Vladimir Ivanov
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



From roger.riggs at oracle.com  Tue Dec  2 17:04:58 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Tue, 02 Dec 2014 12:04:58 -0500
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
Message-ID: <547DF13A.8090201@oracle.com>

Hi Paul,

Looks fine to me also.

Thanks, Roger

On 12/2/2014 5:02 AM, Paul Sandoz wrote:
> Hi,
>
> Please find below a patch to remove the networking code computing a seed in ThreadLocal/SplittableRandom.
>
> We thought it a good idea at the time :-) but subsequently on certain platforms this results in very high initalization costs that can propagate to other classes such as ConcurrentSkipList*.
>
> The short-term solution is to remove this code and fallback just using current system time. This needs to be back-ported to 8u40.
>
> A longer term solution is to provide a simple public API to get access to some seed bytes that is optimal for the underlying platform, for example, based on Peter's investigations. For linux /dev/urandom is sufficient as a source of bytes. The main problem seems to be Windows. It would also be nice to back-port to say 8u60 using a private API and update TLR/SR.
>
> Paul.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8060435
>
> diff -r 1b599b4755bd src/java.base/share/classes/java/util/SplittableRandom.java
> --- a/src/java.base/share/classes/java/util/SplittableRandom.java	Mon Dec 01 17:59:39 2014 -0800
> +++ b/src/java.base/share/classes/java/util/SplittableRandom.java	Tue Dec 02 10:53:47 2014 +0100
> @@ -237,34 +237,7 @@
>                   s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
>               return s;
>           }
> -        long h = 0L;
> -        try {
> -            Enumeration<NetworkInterface> ifcs =
> -                    NetworkInterface.getNetworkInterfaces();
> -            boolean retry = false; // retry once if getHardwareAddress is null
> -            while (ifcs.hasMoreElements()) {
> -                NetworkInterface ifc = ifcs.nextElement();
> -                if (!ifc.isVirtual()) { // skip fake addresses
> -                    byte[] bs = ifc.getHardwareAddress();
> -                    if (bs != null) {
> -                        int n = bs.length;
> -                        int m = Math.min(n >>> 1, 4);
> -                        for (int i = 0; i < m; ++i)
> -                            h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
> -                        if (m < 4)
> -                            h = (h << 8) ^ bs[n-1-m];
> -                        h = mix64(h);
> -                        break;
> -                    }
> -                    else if (!retry)
> -                        retry = true;
> -                    else
> -                        break;
> -                }
> -            }
> -        } catch (Exception ignore) {
> -        }
> -        return (h ^ mix64(System.currentTimeMillis()) ^
> +        return (mix64(System.currentTimeMillis()) ^
>                   mix64(System.nanoTime()));
>       }
>   
> diff -r 1b599b4755bd src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java
> --- a/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java	Mon Dec 01 17:59:39 2014 -0800
> +++ b/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java	Tue Dec 02 10:53:47 2014 +0100
> @@ -147,34 +147,7 @@
>                   s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
>               return s;
>           }
> -        long h = 0L;
> -        try {
> -            Enumeration<NetworkInterface> ifcs =
> -                    NetworkInterface.getNetworkInterfaces();
> -            boolean retry = false; // retry once if getHardwareAddress is null
> -            while (ifcs.hasMoreElements()) {
> -                NetworkInterface ifc = ifcs.nextElement();
> -                if (!ifc.isVirtual()) { // skip fake addresses
> -                    byte[] bs = ifc.getHardwareAddress();
> -                    if (bs != null) {
> -                        int n = bs.length;
> -                        int m = Math.min(n >>> 1, 4);
> -                        for (int i = 0; i < m; ++i)
> -                            h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
> -                        if (m < 4)
> -                            h = (h << 8) ^ bs[n-1-m];
> -                        h = mix64(h);
> -                        break;
> -                    }
> -                    else if (!retry)
> -                        retry = true;
> -                    else
> -                        break;
> -                }
> -            }
> -        } catch (Exception ignore) {
> -        }
> -        return (h ^ mix64(System.currentTimeMillis()) ^
> +        return (mix64(System.currentTimeMillis()) ^
>                   mix64(System.nanoTime()));
>       }



From vladimir.x.ivanov at oracle.com  Tue Dec  2 16:20:43 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 02 Dec 2014 20:20:43 +0400
Subject: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support
	eviction
In-Reply-To: <AF48B73F-02B8-4B9A-A3C9-485AE9D8B1A3@oracle.com>
References: <547C9E37.8080809@oracle.com>
	<AF48B73F-02B8-4B9A-A3C9-485AE9D8B1A3@oracle.com>
Message-ID: <547DE6DB.1020202@oracle.com>

Thanks, Paul!
Updated webrev in place.

> On Dec 1, 2014, at 5:58 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>
>> http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8057020
>>
>
> That LambdaFormEditor.putInCache method just got more gnarly :-)
>
> Generally looks good.
>
> In src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java
>
>   366                     lambdaForm.transformCache = c = ta;
>
> Do you need to set "c"? It's a local variable and by this point the method should return rather than loop.
I did it mostly as a cleanup. Now I think that it doesn't help much. 
Removed (+ similar change in another place).

> In test/java/lang/invoke/LFCaching/LambdaFormTestCase.java
>
>    55     private static final List<GarbageCollectorMXBean> gcInfo;
>    56
>    57     private static long gcCount() {
>    58         return gcInfo.stream()
>    59                 .map(GarbageCollectorMXBean::getCollectionCount)
>    60                 .reduce(0L, Long::sum);
>    61     }
>
> You can do:
>
>    gcInfo.stream().mapToLong(GarbageCollectorMXBean::getCollectionCount).sum();
Good point. Updated.

Best regards,
Vladimir Ivanov

>
> Paul.
>
>> There are 2 major LambdaForm caches: LambdaFormEditor-based and MethodTypeForm. The former is per-LambdaForm and the latter is per method type erased to basic types. The problem is that these caches don't support eviction, so they can hold LambdaForms forever.
>>
>> Usually, it's not a problem since an application has very limited number of unique erased method types (e.g. on Octane/Nashorn it varies 1,5-3k shapes).
>>
>> The fix is to use SoftReferences to keep LambdaForms alive as long as possible, but avoid throwing OOME until the caches are evicted. I experimented with WeakReferences, but it doesn't hold LambdaForms for long enough: LambdaForm cache hit rate degrades significantly and it negatively affects application startup and warmup, since every instantiated LambdaForm is precompiled to bytecode before usage.
>>
>> Testing: jdk/java/lang/invoke/LFCache in stress mode + jck (api/java_lang/invoke), jdk/java/lang/invoke, jdk/java/util/streams, octane
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>


From paul.sandoz at oracle.com  Tue Dec  2 17:27:26 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 2 Dec 2014 18:27:26 +0100
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <547DEC01.2050501@gmail.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
	<547DEC01.2050501@gmail.com>
Message-ID: <BC0E71DB-276D-4186-89D1-2EEF70246B85@oracle.com>


On Dec 2, 2014, at 5:42 PM, Peter Levart <peter.levart at gmail.com> wrote:

> On 12/02/2014 11:02 AM, Paul Sandoz wrote:
>> Hi,
>> 
>> Please find below a patch to remove the networking code computing a seed in ThreadLocal/SplittableRandom.
>> 
>> We thought it a good idea at the time :-) but subsequently on certain platforms this results in very high initalization costs that can propagate to other classes such as ConcurrentSkipList*.
>> 
>> The short-term solution is to remove this code and fallback just using current system time. This needs to be back-ported to 8u40.
>> 
>> A longer term solution is to provide a simple public API to get access to some seed bytes that is optimal for the underlying platform, for example, based on Peter's investigations. For linux /dev/urandom is sufficient as a source of bytes. The main problem seems to be Windows. It would also be nice to back-port to say 8u60 using a private API and update TLR/SR.
> 
> Hi,
> 
> Here's a proof of concept for an API that just delegates to system-provided "cryptographically secure" (as declared by the system(s)) pseudo random number generator:
> 
> http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.01/
> 

That's rather good. I updated the bug with a link to your email.

Paul.


From alexyursha at gmail.com  Tue Dec  2 06:51:06 2014
From: alexyursha at gmail.com (Alex Yursha)
Date: Tue, 2 Dec 2014 09:51:06 +0300
Subject: Packing 2 data points into 1 field in ThreadPoolExecutor
In-Reply-To: <547D24B4.2090001@oracle.com>
References: <F20EAFC5-2BD8-4787-901B-413B9D4A84E2@icloud.com>
	<0F081861-ACBA-484E-9FA7-784D2EE4A023@icloud.com>
	<CA+kOe08odwpUrUeeniY+j8SyraATDLbBSHWF+S2=1ECoT_R1wA@mail.gmail.com>
	<CBACF05C-2856-43BB-8EAE-D46680D8AD05@icloud.com>
	<547D24B4.2090001@oracle.com>
Message-ID: <CB6B7B6C-C167-40A1-B15A-7530150B1B7E@icloud.com>

Thanks for all responses. All this is much clearer now.

Am I right that all this state packing is for better performance only and the same behaviour can be achieved by using explicit locks?

> On Dec 2, 2014, at 05:32, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 2/12/2014 3:44 AM, Alex Yursha wrote:
>> 1. Do you mean 'the only way', except using a lock?
>> 
>> 2. I also cant imagine how we can use long primitive type for CAS atomicity without a lock if only its not an AtomicLong. Any hint here, please?
> 
> AtomicFieldUpdater can apply atomic operations to plain (volatile) int and long fields. The Unsafe API can also be used to do it more performantly.
> 
> David
> 
>> Thanks
>> 
>> 
>> Sent from my iPhone
>> 
>>> On Dec 1, 2014, at 20:27, Martin Buchholz <martinrb at google.com> wrote:
>>> 
>>> The only way to use atomic compare and set is to pack all your state
>>> into a single primitive unit.  The largest we have is "long".  So we
>>> regularly pack what the C folks would call bitfields into longs.
>>> 
>>>> On Sat, Nov 29, 2014 at 8:13 AM, Alex Yursha <alexyursha at gmail.com> wrote:
>>>> Hi all,
>>>> 
>>>> According to javadoc current implementation of ThreadPoolExecutor packs two conceptual fields ?workerCount? and ?runState? into one actual field ?ctl? of type AtomicInteger.
>>>> 
>>>> Could you please explain are there any performance or other benefits for this? It seems to complicate the class design and I can?t find the positive side of this.
>>>> 
>>>> Thanks,
>>>> Alex
>>>> 



From paul.sandoz at oracle.com  Tue Dec  2 17:32:54 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 2 Dec 2014 18:32:54 +0100
Subject: [9,
	8u40] RFR (M): 8057020: LambdaForm caches should support eviction
In-Reply-To: <547DE6DB.1020202@oracle.com>
References: <547C9E37.8080809@oracle.com>
	<AF48B73F-02B8-4B9A-A3C9-485AE9D8B1A3@oracle.com>
	<547DE6DB.1020202@oracle.com>
Message-ID: <E27521C0-433E-4759-9CBD-4966B0480C66@oracle.com>


On Dec 2, 2014, at 5:20 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> Thanks, Paul!
> Updated webrev in place.

+1.

Paul.


From Alan.Bateman at oracle.com  Tue Dec  2 17:36:26 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 02 Dec 2014 17:36:26 +0000
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <547DEC01.2050501@gmail.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
	<547DEC01.2050501@gmail.com>
Message-ID: <547DF89A.2020809@oracle.com>

On 02/12/2014 16:42, Peter Levart wrote:
> :
>
> Here's a proof of concept for an API that just delegates to 
> system-provided "cryptographically secure" (as declared by the 
> system(s)) pseudo random number generator:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.01/
>
The API looks reasonable to me too, I'm just not sure that java.util is 
the right place and whether it needs to be a Java SE API.

-Alan


From stuart.marks at oracle.com  Tue Dec  2 18:01:50 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 02 Dec 2014 10:01:50 -0800
Subject: RFR: 8065870 Update JAX-WS RI integration to latest version
	(2.2.11-b141124.1933)
In-Reply-To: <547DC69A.2000908@oracle.com>
References: <54770AB6.6050806@oracle.com> <547CC30A.1020207@oracle.com>
	<547DC69A.2000908@oracle.com>
Message-ID: <547DFE8E.8030400@oracle.com>

Great, this sounds fine.

s'marks

On 12/2/14 6:03 AM, Miroslav Kos wrote:
> Hi Stuart,
> minor stuff like invalid characters and copyright years I can fix before push,
> the rest will leave for next integration which should be soon.
>
> Thanks!
> Miran
>
>
>
> On 01/12/14 20:35, Stuart Marks wrote:
>> Hi Miran,
>>
>> I'm pretty distant from the JAX-WS code, but I looked through all of the files
>> and most of the changes seem sensible. There are a few things that are
>> questionable though.
>>
>> **
>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java
>>
>>
>> The catch-and-ignore of Throwable at line 565 seems questionable. Wouldn't it
>> be better to catch a few specific exception types that might be thrown from
>> setProperty()?
>>
>> **
>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/resources/Messages_en.properties
>>
>>
>> The copyright year is changed from 2013 to 2012.
>>
>> The unknown character replacement (line 277) is replaced with a '?', though
>> I'm not sure what's really happening here since webrev might be mishandling
>> non-ascii characters. If this is intended to be an ascii file, shouldn't the
>> replacement be a plain single quote (') ?
>>
>> **
>> src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/MessageBundle.properties
>>
>>
>> The version numbers in this file seem to be moved forward, but the copyright
>> is updated from 2014 to 2012. The same appears to be true of the localized
>> versions of this file.
>>
>> **
>> src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties
>>
>>
>> Copyright years 2014 => 2012 again. Also check localized versions of this file.
>>
>> **
>> src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle.properties
>>
>>
>> Copyright years 2013 => 2012. Possibly incorrect replacement "???" for unknown
>> character in original file.
>>
>> ** src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/version.properties
>>
>> Copyright years 2014 => 2013.
>>
>> ==========
>>
>> Nothing earth-shattering here. If you want to push this changeset and fix up
>> these issues later (if indeed they need to be fixed up), I'd be fine with that.
>>
>> s'marks
>>
>>
>>
>>
>>
>> On 11/27/14 3:27 AM, Miroslav Kos wrote:
>>> Hi,
>>> there is a bulk update of JAX-B/WS from upstream projects -
>>> webrev: http://cr.openjdk.java.net/~mkos/8065870/jaxws.00/
>>> more details in issue desc: https://bugs.openjdk.java.net/browse/JDK-8065870
>>>
>>> Could I ask for a review?
>>>
>>> It seems quite big (1126 lines changed) but there are just minor changes/fixes.
>>>
>>> Thanks
>>> Miran
>


From stuart.marks at oracle.com  Tue Dec  2 18:35:43 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 02 Dec 2014 10:35:43 -0800
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <A57AD2B9-F1CC-43F3-B461-6BAD916474AB@oracle.com>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>	<547CCF38.4030108@CoSoCo.de>
	<A57AD2B9-F1CC-43F3-B461-6BAD916474AB@oracle.com>
Message-ID: <547E067F.9000209@oracle.com>

Hi Lance,

Overall, looks fine.

Typo "earleir" at line 569.

I agree with having two separate init methods, since initDriversIfNeeded() 
conveniently separates the (safe) double-checked locking idiom from the actual 
initialization legwork in loadInitialDrivers().

I'm not entirely convinced, however :-), that DCL is necessary, but I could see 
that it might be helpful if some of these operations are called frequently. 
Sorry if this had been discussed previously.

s'marks



On 12/1/14 12:39 PM, Lance Andersen wrote:
> Hi Ulf,
>
> thank you for the input and  suggestion
>
>
> On Dec 1, 2014, at 3:27 PM, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>
>> Hi Lance,
>>
>> to me it's irritating, why there are 2 methods:
>> - initDriversIfNeeded()
>> - loadInitialDrivers()
>> I would combine both to one method.
>
> Mandy had asked me previously about this and here was my reply
>
> -----------------
> The reason I had the two methods was to further reduce contention checking to see if the drivers need to be loaded.  getConnection  gets called frequently so I thought that not having the initial check synchronized would be more efficient
> -----------------
>
>
> I think the code gets harder to read if I have one large synchronized block  assuming I move everything from loadInitialDrivers into the  existing synchronized block in initDriversIfNeeded.
>
>> In lines 90 + 92 there are double spaces.
>
> Thank you.
>>
>> -Ulf
>>
>>
>
> Best,
> Lance
>> Am 01.12.2014 um 17:52 schrieb Lance Andersen:
>>> Hi all,
>>>
>>> Looking for a review for this change to DriverManager to reduce the possibility on a deadlock on <clinit>. that I have been discussing with Mandy.
>>>
>>>
>>> The change removes the static initializer block as well as the synchronized keyword from registerDriver.
>>>
>>> The webrev can be found at http://cr.openjdk.java.net/%7Elancea/8060068/webrev.02/
>>>
>>>
>>> Best,
>>> Lance
>>>
>>>
>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com
>>>
>>>
>>>
>>>
>>
>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>


From lance.andersen at oracle.com  Tue Dec  2 18:46:23 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 2 Dec 2014 13:46:23 -0500
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <547E067F.9000209@oracle.com>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>	<547CCF38.4030108@CoSoCo.de>
	<A57AD2B9-F1CC-43F3-B461-6BAD916474AB@oracle.com>
	<547E067F.9000209@oracle.com>
Message-ID: <BF2C7555-0E80-47F6-AE98-4384863E7636@oracle.com>

Hi Stuart,
On Dec 2, 2014, at 1:35 PM, Stuart Marks <stuart.marks at oracle.com> wrote:

> Hi Lance,
> 
> Overall, looks fine.

Thank you for the review
> 
> Typo "earleir" at line 569.

fixed
> 
> I agree with having two separate init methods, since initDriversIfNeeded() conveniently separates the (safe) double-checked locking idiom from the actual initialization legwork in loadInitialDrivers().
> 
> I'm not entirely convinced, however :-), that DCL is necessary, but I could see that it might be helpful if some of these operations are called frequently. Sorry if this had been discussed previously.

getConnection in particular can get called often in some environments so I thought using DCL would be the safe way to go.

Best,
Lance

> 
> s'marks
> 
> 
> 
> On 12/1/14 12:39 PM, Lance Andersen wrote:
>> Hi Ulf,
>> 
>> thank you for the input and  suggestion
>> 
>> 
>> On Dec 1, 2014, at 3:27 PM, Ulf Zibis <Ulf.Zibis at CoSoCo.de> wrote:
>> 
>>> Hi Lance,
>>> 
>>> to me it's irritating, why there are 2 methods:
>>> - initDriversIfNeeded()
>>> - loadInitialDrivers()
>>> I would combine both to one method.
>> 
>> Mandy had asked me previously about this and here was my reply
>> 
>> -----------------
>> The reason I had the two methods was to further reduce contention checking to see if the drivers need to be loaded.  getConnection  gets called frequently so I thought that not having the initial check synchronized would be more efficient
>> -----------------
>> 
>> 
>> I think the code gets harder to read if I have one large synchronized block  assuming I move everything from loadInitialDrivers into the  existing synchronized block in initDriversIfNeeded.
>> 
>>> In lines 90 + 92 there are double spaces.
>> 
>> Thank you.
>>> 
>>> -Ulf
>>> 
>>> 
>> 
>> Best,
>> Lance
>>> Am 01.12.2014 um 17:52 schrieb Lance Andersen:
>>>> Hi all,
>>>> 
>>>> Looking for a review for this change to DriverManager to reduce the possibility on a deadlock on <clinit>. that I have been discussing with Mandy.
>>>> 
>>>> 
>>>> The change removes the static initializer block as well as the synchronized keyword from registerDriver.
>>>> 
>>>> The webrev can be found at http://cr.openjdk.java.net/%7Elancea/8060068/webrev.02/
>>>> 
>>>> 
>>>> Best,
>>>> Lance
>>>> 
>>>> 
>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>>> Oracle Java Engineering
>>>> 1 Network Drive
>>>> Burlington, MA 01803
>>>> Lance.Andersen at oracle.com
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>> 
>> 
>> 



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





From mandy.chung at oracle.com  Tue Dec  2 19:24:17 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 02 Dec 2014 11:24:17 -0800
Subject: RFR: 8065991: LogManager unecessarily calls JavaAWTAccess from
	within a critical section
In-Reply-To: <547609B9.3080206@oracle.com>
References: <547609B9.3080206@oracle.com>
Message-ID: <547E11E1.2050507@oracle.com>

Hi Daniel,

On 11/26/14 9:11 AM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a patch for:
>
> 8065991: LogManager unecessarily calls JavaAWTAccess from within
>          a critical section
> https://bugs.openjdk.java.net/browse/JDK-8065991
>
> Webrev:
> http://cr.openjdk.java.net/~dfuchs/webrev_8065991/webrev.00/
>
line 465 can be moved together with line 461.

For the logger created by EventQueue in non-applet env, do we
expect JavaAWTAccess.getAppletContext to return null (as it
should only find the main AppContext)?

As the deadlock reported from JDK-8065709, it hits the race when
main AppContext object has been created and the numAppContexts counter
has been incremented but mainAppContext is not set in which case
even with this patch, it will still call AppContext.getAppContext()
and hit that deadlockon sun.awt.AppContext$GetAppContextLock.

Should JavaAWTAccess.getAppletContext simply return null (not calling
getAppContext) if it determines the main AppContext is being initialized?

Mandy


  




From mandy.chung at oracle.com  Tue Dec  2 19:56:19 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 02 Dec 2014 11:56:19 -0800
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>
Message-ID: <547E1963.2000500@oracle.com>

On 12/1/14 8:52 AM, Lance Andersen wrote:
> Hi all,
>
> Looking for a review for this change to DriverManager to reduce the possibility on a deadlock on <clinit>. that I have been discussing with Mandy.
>
>
> The change removes the static initializer block as well as the synchronized keyword from registerDriver.
>
> The webrev can be found at http://cr.openjdk.java.net/%7Elancea/8060068/webrev.02/
>
initDriversIfNeeded() is called to ensure that the drivers are registered.
So it may be better to have a getter method to ensure driver classes are
loaded as well as return the registeredDrivers copy-on-write-arraylist.
i.e. you could rename initDriversIfNeeded to getRegisteredDrivers and
replace
   for(DriverInfo aDriver : registeredDrivers) {

with
   for(DriverInfo aDriver : getRegisteredDrivers())

line 564-567: this comment should belong to loadInitialDrivers right?
Nit line 567 - not align (one more space to the right needed)

Is driversSync object necessary?  Can you make loadInitialDrivers be
a synchronized method and move line 575-581 except 578 to the
loadInitialDrivers method (driversInitialized is volatile which is
good).

Mandy



From daniel.fuchs at oracle.com  Tue Dec  2 20:26:24 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 02 Dec 2014 21:26:24 +0100
Subject: RFR: 8065991: LogManager unecessarily calls JavaAWTAccess from
	within a critical section
In-Reply-To: <547E11E1.2050507@oracle.com>
References: <547609B9.3080206@oracle.com> <547E11E1.2050507@oracle.com>
Message-ID: <547E2070.5080705@oracle.com>

Hi Mandy,

On 02/12/14 20:24, Mandy Chung wrote:
> Hi Daniel,
>
> On 11/26/14 9:11 AM, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a patch for:
>>
>> 8065991: LogManager unecessarily calls JavaAWTAccess from within
>>          a critical section
>> https://bugs.openjdk.java.net/browse/JDK-8065991
>>
>> Webrev:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8065991/webrev.00/
>>
> line 465 can be moved together with line 461.

Good point. It should not matter much however.

> For the logger created by EventQueue in non-applet env, do we
> expect JavaAWTAccess.getAppletContext to return null (as it
> should only find the main AppContext)?

The mainAppContext is equivalent to 'null' for us.

> As the deadlock reported from JDK-8065709, it hits the race when
> main AppContext object has been created and the numAppContexts counter
> has been incremented but mainAppContext is not set in which case
> even with this patch, it will still call AppContext.getAppContext()
> and hit that deadlockon sun.awt.AppContext$GetAppContextLock.

I'm not sure I follow. I don't think it will. Only when the
LogManager has not yet been initialized - because getUserContext()
ends up being called inside the lock held by ensureLogManagerInitialized().

This patch doesn't pretend to solve JDK-8065709. This patch simply
removes one unnecessary lock around getAppContext().

> Should JavaAWTAccess.getAppletContext simply return null (not calling
> getAppContext) if it determines the main AppContext is being initialized?

I'd prefer not to touch this code unless it's proven wrong.

To solve the actual deadlock - several options have been proposed - and
I think they should be preferred - or at least experimented.

best regards,

-- daniel

>
> Mandy
>
>
>
>
>



From lance.andersen at oracle.com  Tue Dec  2 20:30:16 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 2 Dec 2014 15:30:16 -0500
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <547E1963.2000500@oracle.com>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>
	<547E1963.2000500@oracle.com>
Message-ID: <BAFE842B-A51B-49C3-956E-8D35A27CD54A@oracle.com>

Hi Mandy,

Thank you for the review, please see below

On Dec 2, 2014, at 2:56 PM, Mandy Chung <mandy.chung at oracle.com> wrote:

> On 12/1/14 8:52 AM, Lance Andersen wrote:
>> Hi all,
>> 
>> Looking for a review for this change to DriverManager to reduce the possibility on a deadlock on <clinit>. that I have been discussing with Mandy.
>> 
>> 
>> The change removes the static initializer block as well as the synchronized keyword from registerDriver.
>> 
>> The webrev can be found at http://cr.openjdk.java.net/%7Elancea/8060068/webrev.02/
>> 
> initDriversIfNeeded() is called to ensure that the drivers are registered. 
This is a one time operation  only those specified via the system property of supporting ServiceLoader.  

A user could invoke Class.forName(<my java.sql.Driver impl>) and cause a driver to be registered at any time
> So it may be better to have a getter method to ensure driver classes are 
> loaded as well as return the registeredDrivers copy-on-write-arraylist.
> i.e. you could rename initDriversIfNeeded to getRegisteredDrivers and
> replace
>   for(DriverInfo aDriver : registeredDrivers) {
> 
> with 
>   for(DriverInfo aDriver : getRegisteredDrivers()) 
I can do that if you think that is a cleaner approach?  I am flexible :-)
> 
> line 564-567: this comment should belong to loadInitialDrivers right?
I had left it there as both methods kind of flow together, but I moved it per your suggestion.  Thank you
> Nit line 567 - not align (one more space to the right needed)
fixed
> 
> Is driversSync object necessary? 
I am not 100% sure but I thought having its own monitor would further reduce the  contention possibility and given this was only reported in this one case, I was playing it safe :-).

>  Can you make loadInitialDrivers be
> a synchronized method and move line 575-581 except 578 to the 
> loadInitialDrivers method (driversInitialized is volatile which is 
> good).
That is doable, I just thought keeping the DCL code together makes it easier to read and decided to have its own monitor.  If you feel we should go this way, I will, just let me know 

Best,
Lance
> 
> Mandy



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





From ivan.st.ivanov at gmail.com  Tue Dec  2 21:00:25 2014
From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov)
Date: Tue, 2 Dec 2014 23:00:25 +0200
Subject: Help us with choosing issue BG JUG adopt hackathon
Message-ID: <CACYLA9F9hzfPYfK8g-NRgr1n8whjgjtiDW4JJn+=JQMjB9c99A@mail.gmail.com>

Hello core libs developers!

I am Ivan from the Bulgarian Java User Group. We are adopting OpenJDK for
quite some time in our JUG. So far we have done some sessions in our
community as well as on conferences in Bulgaria and neighboring countries,
where we just talked about the project and the adoption topic. We also did
some hackathons, where we showed the people how they can download, build,
change and use the changed images of the latest version of OpenJDK. On the
last Java2Days conference in Sofia we even went further and together with
Mani Sarkar from LJC we did Jigsaw project hands on lab, where besides
explaining the roadmap and JEPs for the modularity, we built and ran JBoss
Forge with the image that we built from the latest source from jigsaw/m2
repository!

And now we decided that we want to go one step further. We think that we
are ready for our first real contribution to OpenJDK. Of course, we want to
start small, we don't plan to implement project Valhalla in a day ;)

We took our time and analyzed the open issues that we found in the OpenJDK
JIRA. We selected a few items and before picking one for our hackathon on
11th December, we decided to ask for your opinion. So, this is what we
found appropriate:

https://bugs.openjdk.java.net/browse/JDK-5050783
*Throwable convenience method: String getStackTraceString()*
This stays open for quite some time. Maybe we could add a default method to
java.lang.Throwable or static convenience method to another class?

https://bugs.openjdk.java.net/browse/JDK-6201180
*(coll) Generics and collections support for generic arrays*
We believe that this issue was reported ahead of its time :). It basically
proposes adding new methods to the Collection interface, but the proposal
came in 2004! Now with default methods it is finally possible. We would
argue as well with the syntax: instead of addAll(<? extends E>[] array), we
would propose to have addAll(E... array) method (the same applies for the
other three proposed new methods as well).

https://bugs.openjdk.java.net/browse/JDK-4974893
*(ch) Retrofit scatter/gather interfaces with varargs where possible*
I guess we need to discuss this more. Especially the comment "I think this
job must be generalized to the whole API." We know that Joe Darcy and the
team already ran some effort on cleaning up things like that, but if you
still know about generifying/varargsifying/coinifying/labdaifying (wow! :))
internal APIs, we would be more than happy to help.

We that, I would conclude the list. Do you think that we can work on one of
these next Thursday? If not, what else would you propose?

We really hope that we'll be able to do such hackathons once per two months
at least. And our next goals is to participate in Jigsaw once it gets to
its final straight!

Thanks and regards,
Ivan


From mandy.chung at oracle.com  Tue Dec  2 21:09:45 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 02 Dec 2014 13:09:45 -0800
Subject: RFR: 8065991: LogManager unecessarily calls JavaAWTAccess from
	within a critical section
In-Reply-To: <547E2070.5080705@oracle.com>
References: <547609B9.3080206@oracle.com> <547E11E1.2050507@oracle.com>
	<547E2070.5080705@oracle.com>
Message-ID: <547E2A99.50407@oracle.com>

On 12/2/14 12:26 PM, Daniel Fuchs wrote:
> Hi Mandy,
>
> On 02/12/14 20:24, Mandy Chung wrote:
>> Hi Daniel,
>>
>> On 11/26/14 9:11 AM, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> Please find below a patch for:
>>>
>>> 8065991: LogManager unecessarily calls JavaAWTAccess from within
>>>          a critical section
>>> https://bugs.openjdk.java.net/browse/JDK-8065991
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8065991/webrev.00/
>>>
>> line 465 can be moved together with line 461.
>
> Good point. It should not matter much however.
>

For non-applet case, it will also be null (just a fast path).

>> For the logger created by EventQueue in non-applet env, do we
>> expect JavaAWTAccess.getAppletContext to return null (as it
>> should only find the main AppContext)?
>
> The mainAppContext is equivalent to 'null' for us.
>
>> As the deadlock reported from JDK-8065709, it hits the race when
>> main AppContext object has been created and the numAppContexts counter
>> has been incremented but mainAppContext is not set in which case
>> even with this patch, it will still call AppContext.getAppContext()
>> and hit that deadlockon sun.awt.AppContext$GetAppContextLock.
>
> I'm not sure I follow. I don't think it will. Only when the
> LogManager has not yet been initialized - because getUserContext()
> ends up being called inside the lock held by 
> ensureLogManagerInitialized().
>

I was referring to the original deadlock.

> This patch doesn't pretend to solve JDK-8065709. This patch simply
> removes one unnecessary lock around getAppContext().

I understand.
>
>> Should JavaAWTAccess.getAppletContext simply return null (not calling
>> getAppContext) if it determines the main AppContext is being 
>> initialized?
>
> I'd prefer not to touch this code unless it's proven wrong.
>

That's fair.  The real fix is to fix the synchronization issues with 
AppContext.
> To solve the actual deadlock - several options have been proposed - and
> I think they should be preferred - or at least experimented.
>

It's fine with me.  Your patch looks good to go.
Mandy


From mandy.chung at oracle.com  Tue Dec  2 21:12:38 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 02 Dec 2014 13:12:38 -0800
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <BAFE842B-A51B-49C3-956E-8D35A27CD54A@oracle.com>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>
	<547E1963.2000500@oracle.com>
	<BAFE842B-A51B-49C3-956E-8D35A27CD54A@oracle.com>
Message-ID: <547E2B46.50106@oracle.com>

On 12/2/14 12:30 PM, Lance Andersen wrote:
>
>> So it may be better to have a getter method to ensure driver classes are
>> loaded as well as return the registeredDrivers copy-on-write-arraylist.
>> i.e. you could rename initDriversIfNeeded to getRegisteredDrivers and
>> replace
>>    for(DriverInfo aDriver : registeredDrivers) {
>>
>> with
>>    for(DriverInfo aDriver : getRegisteredDrivers())
> I can do that if you think that is a cleaner approach?  I am flexible :-)

I think so.  It wasn't obvious to me at the beginning when you need to 
ensure drivers are initialized and whether any place needs to call 
initDirversIfNeeded.  IMO, having the getter method helps the reader 
easier to understand and future maintainence.

>> line 564-567: this comment should belong to loadInitialDrivers right?
> I had left it there as both methods kind of flow together, but I moved 
> it per your suggestion.  Thank you
>> Nit line 567 - not align (one more space to the right needed)
> fixed
>> Is driversSync object necessary?
> I am not 100% sure but I thought having its own monitor would further 
> reduce the  contention possibility and given this was only reported in 
> this one case, I was playing it safe :-).
>
>> Can you make loadInitialDrivers be
>> a synchronized method and move line 575-581 except 578 to the
>> loadInitialDrivers method (driversInitialized is volatile which is
>> good).
> That is doable, I just thought keeping the DCL code together makes it 
> easier to read and decided to have its own monitor.  If you feel we 
> should go this way, I will, just let me know
>

The lock is to make sure the drivers are loaded once.  AFAICT, there is 
no other method locking DriverManager class except getConnection and I 
don't see any issue.

I forgot to include this comment in my previous reply:

         /*
          * When callerCl is null, we should check the application's
          * (which is invoking this class indirectly)
          * classloader, so that the JDBC driver class outside rt.jar
          * can be loaded from here.
          */
         ClassLoader callerCL = caller != null ? caller.getClassLoader() : null;
         synchronized(DriverManager.class) {
             // synchronize loading of the correct classloader.
             if (callerCL == null) {
                 callerCL = Thread.currentThread().getContextClassLoader();
             }
         }

I don't understand why this needs to synchronize in order to get TCCL.
You are getting the TCCL of the current thread and callerCL is a local
variable. So I think this can be removed.

Mandy


From lance.andersen at oracle.com  Tue Dec  2 21:47:36 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 2 Dec 2014 16:47:36 -0500
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <547E2B46.50106@oracle.com>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>
	<547E1963.2000500@oracle.com>
	<BAFE842B-A51B-49C3-956E-8D35A27CD54A@oracle.com>
	<547E2B46.50106@oracle.com>
Message-ID: <08EA7392-50A0-4A15-AE00-FF886726C101@oracle.com>


On Dec 2, 2014, at 4:12 PM, Mandy Chung <mandy.chung at oracle.com> wrote:

> On 12/2/14 12:30 PM, Lance Andersen wrote:
>> 
>>> So it may be better to have a getter method to ensure driver classes are 
>>> loaded as well as return the registeredDrivers copy-on-write-arraylist.
>>> i.e. you could rename initDriversIfNeeded to getRegisteredDrivers and
>>> replace
>>>   for(DriverInfo aDriver : registeredDrivers) {
>>> 
>>> with 
>>>   for(DriverInfo aDriver : getRegisteredDrivers()) 
>> I can do that if you think that is a cleaner approach?  I am flexible :-)
> 
> I think so.  It wasn't obvious to me at the beginning when you need to ensure drivers are initialized and whether any place needs to call initDirversIfNeeded.  IMO, having the getter method helps the reader easier to understand and future maintenance.

OK, thank you, done
> 
>>> line 564-567: this comment should belong to loadInitialDrivers right?
>> I had left it there as both methods kind of flow together, but I moved it per your suggestion.  Thank you
>>> Nit line 567 - not align (one more space to the right needed)
>> fixed
>>> Is driversSync object necessary? 
>> I am not 100% sure but I thought having its own monitor would further reduce the  contention possibility and given this was only reported in this one case, I was playing it safe :-).
>> 
>>> Can you make loadInitialDrivers be
>>> a synchronized method and move line 575-581 except 578 to the 
>>> loadInitialDrivers method (driversInitialized is volatile which is 
>>> good).
>> That is doable, I just thought keeping the DCL code together makes it easier to read and decided to have its own monitor.  If you feel we should go this way, I will, just let me know 
>> 
> 
> The lock is to make sure the drivers are loaded once. 
correct
> AFAICT, there is no other method locking DriverManager class except getConnection and I don't see any issue.
Ok
> 
> I forgot to include this comment in my previous reply:
>         /*
>          * When callerCl is null, we should check the application's
>          * (which is invoking this class indirectly)
>          * classloader, so that the JDBC driver class outside rt.jar
>          * can be loaded from here.
>          */
>         ClassLoader callerCL = caller != null ? caller.getClassLoader() : null;
>         synchronized(DriverManager.class) {
>             // synchronize loading of the correct classloader.
>             if (callerCL == null) {
>                 callerCL = Thread.currentThread().getContextClassLoader();
>             }
>         }
> 
> I don't understand why this needs to synchronize in order to get TCCL.
> You are getting the TCCL of the current thread and callerCL is a local
> variable. So I think this can be removed.

I removed this as  I am not sure why that change was made (not by me).

I kicked off a build and will run the  jck tests after it completes

The revised webrev is here http://cr.openjdk.java.net/~lancea/8060068/webrev.03/

Note, I also tweaked the  doPriviliged block for the  JDBC property

Best,
Lance
> Mandy



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





From ecki at zusammenkunft.net  Tue Dec  2 21:49:27 2014
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 2 Dec 2014 22:49:27 +0100
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <BAFE842B-A51B-49C3-956E-8D35A27CD54A@oracle.com>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>
	<547E1963.2000500@oracle.com>
	<BAFE842B-A51B-49C3-956E-8D35A27CD54A@oracle.com>
Message-ID: <20141202224927.0000060e.ecki@zusammenkunft.net>

Hello,

just want to add two somewhat related observations:

we have a virtual JDBC driver which maps back to an real driver (or to
an Pool/Datasource which uses a real driver. This is to allow
JDBC URLs to work in different environments with no config. (Thats is
not the nices solution, but after we resolved the deadlocks it
works stable with the legacy code we need to support).

This does have two consequences which are related to this patch:

a) #getConnection() is used quite often, as it tunnels through to a
high performing pool (already mentioned as a good reason for DCL).

b) there have been some deadlock conditions in the past in this area. I
can try to find the details later on, but it involved class
loading/registration and the driver's synchronized.

So it is a bit risky (assuming we are not the only ones using the SPI
in this creative way) to play with the locking.

At the same time, it is also needed. Maybe the more finegrained lock
and the lock-free happy path help with it. I wonder, is there a
special procedure to warn in the release notes/compatibility guide
other than having the patch listed in a changelog? In order to warn
people switching to 9 (in 5 years or so :).

Gruss
Bernd


 Am Tue, 2 Dec
2014 15:30:16 -0500 schrieb Lance Andersen <lance.andersen at oracle.com>:

> Hi Mandy,
> 
> Thank you for the review, please see below
> 
> On Dec 2, 2014, at 2:56 PM, Mandy Chung <mandy.chung at oracle.com>
> wrote:
> 
> > On 12/1/14 8:52 AM, Lance Andersen wrote:
> >> Hi all,
> >> 
> >> Looking for a review for this change to DriverManager to reduce
> >> the possibility on a deadlock on <clinit>. that I have been
> >> discussing with Mandy.
> >> 
> >> 
> >> The change removes the static initializer block as well as the
> >> synchronized keyword from registerDriver.
> >> 
> >> The webrev can be found at
> >> http://cr.openjdk.java.net/%7Elancea/8060068/webrev.02/
> >> 
> > initDriversIfNeeded() is called to ensure that the drivers are
> > registered. 
> This is a one time operation  only those specified via the system
> property of supporting ServiceLoader.  
> 
> A user could invoke Class.forName(<my java.sql.Driver impl>) and
> cause a driver to be registered at any time
> > So it may be better to have a getter method to ensure driver
> > classes are loaded as well as return the registeredDrivers
> > copy-on-write-arraylist. i.e. you could rename initDriversIfNeeded
> > to getRegisteredDrivers and replace
> >   for(DriverInfo aDriver : registeredDrivers) {
> > 
> > with 
> >   for(DriverInfo aDriver : getRegisteredDrivers()) 
> I can do that if you think that is a cleaner approach?  I am
> flexible :-)
> > 
> > line 564-567: this comment should belong to loadInitialDrivers
> > right?
> I had left it there as both methods kind of flow together, but I
> moved it per your suggestion.  Thank you
> > Nit line 567 - not align (one more space to the right needed)
> fixed
> > 
> > Is driversSync object necessary? 
> I am not 100% sure but I thought having its own monitor would further
> reduce the  contention possibility and given this was only reported
> in this one case, I was playing it safe :-).
> 
> >  Can you make loadInitialDrivers be
> > a synchronized method and move line 575-581 except 578 to the 
> > loadInitialDrivers method (driversInitialized is volatile which is 
> > good).
> That is doable, I just thought keeping the DCL code together makes it
> easier to read and decided to have its own monitor.  If you feel we
> should go this way, I will, just let me know 
> 
> Best,
> Lance
> > 
> > Mandy
> 
> 
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com
> 
> 
> 



From aleksey.shipilev at oracle.com  Tue Dec  2 21:59:10 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 03 Dec 2014 00:59:10 +0300
Subject: More memory-efficient internal representation for Strings: call for
	more data
Message-ID: <547E362E.5010107@oracle.com>

Hi,

As you may already know, we are looking into more memory efficient
representation for Strings:
 https://bugs.openjdk.java.net/browse/JDK-8054307

As part of preliminary performance work for this JEP, we have to collect
the empirical data on usual characteristics of Strings and char[]-s
normal applications have, as well as figure out the early estimates for
the improvements based on that data. What we have so far is written up here:
 http://cr.openjdk.java.net/~shade/density/string-density-report.pdf

We would appreciate if people who are interested in this JEP can provide
the additional data on their applications. It is double-interesting to
have the data for the applications that process String data outside
Latin1 plane. Our current data says these cases are rather rare. Please
read the current report draft, and try to process your own heap dumps
using the instructions in the Appendix.

Thanks,
-Aleksey.



From mandy.chung at oracle.com  Tue Dec  2 22:10:06 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 02 Dec 2014 14:10:06 -0800
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <20141202224927.0000060e.ecki@zusammenkunft.net>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>	<547E1963.2000500@oracle.com>	<BAFE842B-A51B-49C3-956E-8D35A27CD54A@oracle.com>
	<20141202224927.0000060e.ecki@zusammenkunft.net>
Message-ID: <547E38BE.9000509@oracle.com>

Hi Bernd,

On 12/2/14 1:49 PM, Bernd Eckenfels wrote:
> Hello,
>
> just want to add two somewhat related observations:
>
> we have a virtual JDBC driver which maps back to an real driver (or to
> an Pool/Datasource which uses a real driver. This is to allow
> JDBC URLs to work in different environments with no config. (Thats is
> not the nices solution, but after we resolved the deadlocks it
> works stable with the legacy code we need to support).

Would you be able to try this patch and see if the deadlocks are 
reproducible?  Lance has been trying to get customers to verify this 
patch as this code has been deadlock-prone.  Your feedback would be very 
useful.
> This does have two consequences which are related to this patch:
>
> a) #getConnection() is used quite often, as it tunnels through to a
> high performing pool (already mentioned as a good reason for DCL).

Once the drivers are loaded and initialized (once), getConnection would
not need any locking (it just checks the volatile boolean field).

Do you see any potential performance issue with it?

>
> b) there have been some deadlock conditions in the past in this area. I
> can try to find the details later on, but it involved class
> loading/registration and the driver's synchronized.

This may be similar to the deadlock problem reported in this bug
during the class initialization of DriverManager class and the
driver classes (that also triggers DriverManager.<clinit>)

This patch changes the loading/registration of the drivers to be
lazy at the first time when getConnection, getDriver, getDrivers
is called.  No synchronized is done afterward.

I'm foreign to the JDBC spec and implementation and I may miss
some subtle issue here.

> So it is a bit risky (assuming we are not the only ones using the SPI
> in this creative way) to play with the locking.
>
> At the same time, it is also needed. Maybe the more finegrained lock
> and the lock-free happy path help with it. I wonder, is there a
> special procedure to warn in the release notes/compatibility guide
> other than having the patch listed in a changelog? In order to warn
> people switching to 9 (in 5 years or so :).

Yes the current way is to tag the JBS issue with "release-note=yes" and 
add the suggested release note in the bug.

On the other hand, if this fix is high risk, we should re-evaluate if 
this should be fixed differently.  This fix is not intended to cause any 
behavioral incompatibility.   Is that your concern with this patch?

Mandy


From lance.andersen at oracle.com  Tue Dec  2 22:11:14 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 2 Dec 2014 17:11:14 -0500
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <20141202224927.0000060e.ecki@zusammenkunft.net>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>
	<547E1963.2000500@oracle.com>
	<BAFE842B-A51B-49C3-956E-8D35A27CD54A@oracle.com>
	<20141202224927.0000060e.ecki@zusammenkunft.net>
Message-ID: <5C2EDCE5-DF5A-4026-BBDB-DE2D0635BC64@oracle.com>

Bernd,

Thank you for your input

On Dec 2, 2014, at 4:49 PM, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:

> Hello,
> 
> just want to add two somewhat related observations:
> 
> we have a virtual JDBC driver which maps back to an real driver (or to
> an Pool/Datasource which uses a real driver. This is to allow
> JDBC URLs to work in different environments with no config. (Thats is
> not the nices solution, but after we resolved the deadlocks it
> works stable with the legacy code we need to support).

A couple of comments

-  DataSources were never meant to register themselves via DriverManager.  Unfortunately some implementations of DataSource still do. 
-  The changes should reduce the potential  for deadlocks given we no longer use a synchronized method for registeredDriver.  We have been using CopyOnWriteArrayList since JDK 7
-  The removal of the static block with the removal of having registerDriver synchronized will further reduce the probability
> 
> This does have two consequences which are related to this patch:
> 
> a) #getConnection() is used quite often, as it tunnels through to a
> high performing pool (already mentioned as a good reason for DCL).
> 
> b) there have been some deadlock conditions in the past in this area. I
> can try to find the details later on, but it involved class
> loading/registration and the driver's synchronized.
These hopefully are gone with the change, but if you have a simple repro after trying the patch, that would be helpful

Best,
Lance
> 
> So it is a bit risky (assuming we are not the only ones using the SPI
> in this creative way) to play with the locking.
> 
> At the same time, it is also needed. Maybe the more finegrained lock
> and the lock-free happy path help with it. I wonder, is there a
> special procedure to warn in the release notes/compatibility guide
> other than having the patch listed in a changelog? In order to warn
> people switching to 9 (in 5 years or so :).
> 
> Gruss
> Bernd
> 
> 
> Am Tue, 2 Dec
> 2014 15:30:16 -0500 schrieb Lance Andersen <lance.andersen at oracle.com>:
> 
>> Hi Mandy,
>> 
>> Thank you for the review, please see below
>> 
>> On Dec 2, 2014, at 2:56 PM, Mandy Chung <mandy.chung at oracle.com>
>> wrote:
>> 
>>> On 12/1/14 8:52 AM, Lance Andersen wrote:
>>>> Hi all,
>>>> 
>>>> Looking for a review for this change to DriverManager to reduce
>>>> the possibility on a deadlock on <clinit>. that I have been
>>>> discussing with Mandy.
>>>> 
>>>> 
>>>> The change removes the static initializer block as well as the
>>>> synchronized keyword from registerDriver.
>>>> 
>>>> The webrev can be found at
>>>> http://cr.openjdk.java.net/%7Elancea/8060068/webrev.02/
>>>> 
>>> initDriversIfNeeded() is called to ensure that the drivers are
>>> registered. 
>> This is a one time operation  only those specified via the system
>> property of supporting ServiceLoader.  
>> 
>> A user could invoke Class.forName(<my java.sql.Driver impl>) and
>> cause a driver to be registered at any time
>>> So it may be better to have a getter method to ensure driver
>>> classes are loaded as well as return the registeredDrivers
>>> copy-on-write-arraylist. i.e. you could rename initDriversIfNeeded
>>> to getRegisteredDrivers and replace
>>>  for(DriverInfo aDriver : registeredDrivers) {
>>> 
>>> with 
>>>  for(DriverInfo aDriver : getRegisteredDrivers()) 
>> I can do that if you think that is a cleaner approach?  I am
>> flexible :-)
>>> 
>>> line 564-567: this comment should belong to loadInitialDrivers
>>> right?
>> I had left it there as both methods kind of flow together, but I
>> moved it per your suggestion.  Thank you
>>> Nit line 567 - not align (one more space to the right needed)
>> fixed
>>> 
>>> Is driversSync object necessary? 
>> I am not 100% sure but I thought having its own monitor would further
>> reduce the  contention possibility and given this was only reported
>> in this one case, I was playing it safe :-).
>> 
>>> Can you make loadInitialDrivers be
>>> a synchronized method and move line 575-581 except 578 to the 
>>> loadInitialDrivers method (driversInitialized is volatile which is 
>>> good).
>> That is doable, I just thought keeping the DCL code together makes it
>> easier to read and decided to have its own monitor.  If you feel we
>> should go this way, I will, just let me know 
>> 
>> Best,
>> Lance
>>> 
>>> Mandy
>> 
>> 
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering 
>> 1 Network Drive 
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>> 
>> 
>> 
> 



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





From vitalyd at gmail.com  Tue Dec  2 22:13:21 2014
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Tue, 2 Dec 2014 17:13:21 -0500
Subject: More memory-efficient internal representation for Strings: call
	for more data
In-Reply-To: <547E362E.5010107@oracle.com>
References: <547E362E.5010107@oracle.com>
Message-ID: <CAHjP37Fi0aw=NKi0mL3D9KHsHSimpmUk-Xp3pu2iQ_cwfXwqAQ@mail.gmail.com>

Any consideration towards removing the char[] (or byte[]) indirection
altogether? .NET for example stores the bytes inline with the instance.

Sent from my phone
On Dec 2, 2014 4:59 PM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
wrote:

> Hi,
>
> As you may already know, we are looking into more memory efficient
> representation for Strings:
>  https://bugs.openjdk.java.net/browse/JDK-8054307
>
> As part of preliminary performance work for this JEP, we have to collect
> the empirical data on usual characteristics of Strings and char[]-s
> normal applications have, as well as figure out the early estimates for
> the improvements based on that data. What we have so far is written up
> here:
>  http://cr.openjdk.java.net/~shade/density/string-density-report.pdf
>
> We would appreciate if people who are interested in this JEP can provide
> the additional data on their applications. It is double-interesting to
> have the data for the applications that process String data outside
> Latin1 plane. Our current data says these cases are rather rare. Please
> read the current report draft, and try to process your own heap dumps
> using the instructions in the Appendix.
>
> Thanks,
> -Aleksey.
>
>


From aleksey.shipilev at oracle.com  Tue Dec  2 22:15:29 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 03 Dec 2014 01:15:29 +0300
Subject: More memory-efficient internal representation for Strings: call
	for more data
In-Reply-To: <CAHjP37Fi0aw=NKi0mL3D9KHsHSimpmUk-Xp3pu2iQ_cwfXwqAQ@mail.gmail.com>
References: <547E362E.5010107@oracle.com>
	<CAHjP37Fi0aw=NKi0mL3D9KHsHSimpmUk-Xp3pu2iQ_cwfXwqAQ@mail.gmail.com>
Message-ID: <547E3A01.6020601@oracle.com>

Hi Vitaly,

Please read the JEP proposal. String/char[] fusion (that's what you are
describing) is out of scope for this work. Baby steps. Careful baby steps.

-Aleksey.

On 03.12.2014 01:13, Vitaly Davidovich wrote:
> Any consideration towards removing the char[] (or byte[]) indirection
> altogether? .NET for example stores the bytes inline with the instance.
> 
> Sent from my phone
> 
> On Dec 2, 2014 4:59 PM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com
> <mailto:aleksey.shipilev at oracle.com>> wrote:
> 
>     Hi,
> 
>     As you may already know, we are looking into more memory efficient
>     representation for Strings:
>      https://bugs.openjdk.java.net/browse/JDK-8054307
> 
>     As part of preliminary performance work for this JEP, we have to collect
>     the empirical data on usual characteristics of Strings and char[]-s
>     normal applications have, as well as figure out the early estimates for
>     the improvements based on that data. What we have so far is written
>     up here:
>      http://cr.openjdk.java.net/~shade/density/string-density-report.pdf
>     <http://cr.openjdk.java.net/%7Eshade/density/string-density-report.pdf>
> 
>     We would appreciate if people who are interested in this JEP can provide
>     the additional data on their applications. It is double-interesting to
>     have the data for the applications that process String data outside
>     Latin1 plane. Our current data says these cases are rather rare. Please
>     read the current report draft, and try to process your own heap dumps
>     using the instructions in the Appendix.
> 
>     Thanks,
>     -Aleksey.
> 




From lance.andersen at oracle.com  Tue Dec  2 22:25:43 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 2 Dec 2014 17:25:43 -0500
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <547E38BE.9000509@oracle.com>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>	<547E1963.2000500@oracle.com>	<BAFE842B-A51B-49C3-956E-8D35A27CD54A@oracle.com>
	<20141202224927.0000060e.ecki@zusammenkunft.net>
	<547E38BE.9000509@oracle.com>
Message-ID: <0E92FDD3-B8E2-4B3C-A9CB-F87CFC66236D@oracle.com>

Hi Mandy,
On Dec 2, 2014, at 5:10 PM, Mandy Chung <mandy.chung at oracle.com> wrote:

> Hi Bernd,
> 
> On 12/2/14 1:49 PM, Bernd Eckenfels wrote:
>> Hello,
>> 
>> just want to add two somewhat related observations:
>> 
>> we have a virtual JDBC driver which maps back to an real driver (or to
>> an Pool/Datasource which uses a real driver. This is to allow
>> JDBC URLs to work in different environments with no config. (Thats is
>> not the nices solution, but after we resolved the deadlocks it
>> works stable with the legacy code we need to support).
> 
> Would you be able to try this patch and see if the deadlocks are reproducible?  Lance has been trying to get customers to verify this patch as this code has been deadlock-prone.  Your feedback would be very useful.
>> This does have two consequences which are related to this patch:
>> 
>> a) #getConnection() is used quite often, as it tunnels through to a
>> high performing pool (already mentioned as a good reason for DCL).
> 
> Once the drivers are loaded and initialized (once), getConnection would
> not need any locking (it just checks the volatile boolean field).
correct as the registeredDrivers arraylist should be OK
> 
> Do you see any potential performance issue with it?
> 
>> 
>> b) there have been some deadlock conditions in the past in this area. I
>> can try to find the details later on, but it involved class
>> loading/registration and the driver's synchronized.
> 
> This may be similar to the deadlock problem reported in this bug
> during the class initialization of DriverManager class and the
> driver classes (that also triggers DriverManager.<clinit>)
> 
> This patch changes the loading/registration of the drivers to be
> lazy at the first time when getConnection, getDriver, getDrivers
> is called.  No synchronized is done afterward.

This is how it used to be prior to adding the static initializer block..  The difference is we do not do this any longer in registerDriver as it was in JDBC 10 it is not needed.  
The only time it is needed is when you are looking up a URL or return a driver.  There was no need to do this in registerDriver ever.
> 
> 

Best,
Lance



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





From martinrb at google.com  Tue Dec  2 22:34:07 2014
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 2 Dec 2014 14:34:07 -0800
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <547DF89A.2020809@oracle.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
	<547DEC01.2050501@gmail.com> <547DF89A.2020809@oracle.com>
Message-ID: <CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>

I support Peter's initiative and am willing to help review if we have
general consensus about the direction.

>From superficial review:

+                int nread = randomStream.read(bytes);
+                if (nread != bytes.length) {
+                    throw new InternalError("Short read from: " + RANDOM_FILE);

Martin's pet peeve: use readFully (why doesn't InputStream support
that yet?!) copy-paste from elsewhere in the jdk.

---

I'm not sure we need instances that hold on to system resources.  any
particular call site is likely to do a single read of a small number
of random bytes in a clinit method.


On Tue, Dec 2, 2014 at 9:36 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 02/12/2014 16:42, Peter Levart wrote:
>>
>> :
>>
>> Here's a proof of concept for an API that just delegates to
>> system-provided "cryptographically secure" (as declared by the system(s))
>> pseudo random number generator:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.01/
>>
> The API looks reasonable to me too, I'm just not sure that java.util is the
> right place and whether it needs to be a Java SE API.
>
> -Alan


From douglas.surber at oracle.com  Tue Dec  2 23:24:12 2014
From: douglas.surber at oracle.com (Douglas Surber)
Date: Tue, 02 Dec 2014 15:24:12 -0800
Subject: More memory-efficient internal representation for Strings:
	call for	more data
In-Reply-To: <mailman.30355.1417558403.10816.core-libs-dev@openjdk.java. net>
References: <mailman.30355.1417558403.10816.core-libs-dev@openjdk.java.net>
Message-ID: <6.2.5.6.2.20141202145839.058ac150@oracle.com>

String construction is a big performance issue for JDBC drivers. Most 
queries return some number of Strings. The overwhelming majority of 
those Strings will be short lived. The cost of constructing these 
Strings from network bytes is a large fraction of total execution 
time. Any increase in the cost of constructing a String will far out 
weigh any reduction in memory use, at least for query results.

All of the proposed compression methods require an additional scan of 
the entire string. That's exactly the wrong direction. Something like 
the following pseudo-code is common inside a driver.

   {
     char[] c = new char[n];
     for (i = 0; i < n; i++) c[i] = charSource.next();
     return new String(c);
   }

The array copy inside the String constructor is a significant 
fraction of JDBC driver execution time. Adding an additional scan on 
top of it is making things worse regardless of the transient benefit 
of more compact storage. In the case of a query result the String 
will be likely never be promoted out of new space; the benefit of 
compression would be minimal.

I don't dispute that Strings occupy a significant fraction of the 
heap or that a lot of those bytes are zero. And I certainly agree 
that reducing memory footprint is valuable, but any worsening of 
String construction time will likely be a problem.

Douglas

At 02:13 PM 12/2/2014, core-libs-dev-request at openjdk.java.net wrote:
>Date: Wed, 03 Dec 2014 00:59:10 +0300
>From: Aleksey Shipilev <aleksey.shipilev at oracle.com>
>To: Java Core Libs <core-libs-dev at openjdk.java.net>
>Cc: charlie hunt <charlie.hunt at oracle.com>
>Subject: More memory-efficient internal representation for Strings:
>         call for        more data
>Message-ID: <547E362E.5010107 at oracle.com>
>Content-Type: text/plain; charset=utf-8
>
>Hi,
>
>As you may already know, we are looking into more memory efficient
>representation for Strings:
>  https://bugs.openjdk.java.net/browse/JDK-8054307
>
>As part of preliminary performance work for this JEP, we have to 
>collect
>the empirical data on usual characteristics of Strings and char[]-s
>normal applications have, as well as figure out the early estimates 
>for
>the improvements based on that data. What we have so far is written 
>up here:
> 
>http://cr.openjdk.java.net/~shade/density/string-density-report.pdf
>
>We would appreciate if people who are interested in this JEP can 
>provide
>the additional data on their applications. It is double-interesting 
>to
>have the data for the applications that process String data outside
>Latin1 plane. Our current data says these cases are rather rare. 
>Please
>read the current report draft, and try to process your own heap 
>dumps
>using the instructions in the Appendix.
>
>Thanks,
>-Aleksey.



From ecki at zusammenkunft.net  Tue Dec  2 23:33:43 2014
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 3 Dec 2014 00:33:43 +0100
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <547E38BE.9000509@oracle.com>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>
	<547E1963.2000500@oracle.com>
	<BAFE842B-A51B-49C3-956E-8D35A27CD54A@oracle.com>
	<20141202224927.0000060e.ecki@zusammenkunft.net>
	<547E38BE.9000509@oracle.com>
Message-ID: <20141203003343.00002049.ecki@zusammenkunft.net>

Hello Mandy and Lance,

(sorry, not a full quote for more focused answers, inline)

Am Tue, 02 Dec 2014 14:10:06 -0800
schrieb Mandy Chung <mandy.chung at oracle.com>:

> Would you be able to try this patch and see if the deadlocks are 
> reproducible?  Lance has been trying to get customers to verify this 
> patch as this code has been deadlock-prone.  Your feedback would be
> very useful.

Hm, I might be able to test it with the unit tests (once I get the
binary to build). Currently I cant test the whole system with 8 or 9
(do you think porting it to 7 might be straight forward?). I think the
Unit tests have no reproducers for this issue, will check.

> > This does have two consequences which are related to this patch:
> >
> > a) #getConnection() is used quite often, as it tunnels through to a
> > high performing pool (already mentioned as a good reason for DCL).
> 
> Once the drivers are loaded and initialized (once), getConnection
> would not need any locking (it just checks the volatile boolean
> field).
> 
> Do you see any potential performance issue with it?

No, dont see a problem. I wanted to add another vote pro DCL.

> This may be similar to the deadlock problem reported in this bug
> during the class initialization of DriverManager class and the
> driver classes (that also triggers DriverManager.<clinit>)

Yes, all related.

> On the other hand, if this fix is high risk, we should re-evaluate if 
> this should be fixed differently.  This fix is not intended to cause
> any behavioral incompatibility.   Is that your concern with this
> patch?

I will have to find the stack traces from well-back-than where we had
the deadlocks and compare it with the proposed patch. Up until now it
is just a mild suspect :)

Greetings
Bernd


From nathan.a.clement at hotmail.com  Tue Dec  2 23:36:03 2014
From: nathan.a.clement at hotmail.com (Nathan Clement)
Date: Wed, 3 Dec 2014 10:36:03 +1100
Subject: Java 8 FilterOutputStream.close() bug
Message-ID: <COL131-W2153C3E53572217B544557CA7A0@phx.gbl>

Hi,

I have encountered a bug in FilterOutputStream under Java 8.  The bug is that calling close() on the same stream twice can now result in an exception, whereas under Java 7 it did not.  The reason is that FilterOutputStream.close() calls flush() before calling close() on the underlying stream.  Calling close() twice on the FilterOutputStream will thus result in flush() being called twice.  Some streams (such as OracleBlobOutputStream) will throw an exception if flush() is called after the stream is closed.  In Java 7 any exceptions when calling flush() were ignored, but in Java 8 these exceptions are passed on to the caller.

This bug appears to have been introduced in "7015589: (spec) BufferedWriter.close leaves stream open if close of underlying Writer fails".  The FilterOutputStream.close() method now does not obey the contract of AutoClosable.close(): "If the stream is already closed then invoking this method has no effect."

Some sample code that illustrates the problem:

try( InputStream bis = new BufferedInputStream( inputStream );
     OutputStream outStream = payloadData.setBinaryStream( 0 );
     BufferedOutputStream bos = new BufferedOutputStream( outStream );
     DeflaterOutputStream deflaterStream = new DeflaterOutputStream(
         bos, new Deflater( 3 ) ) )
{
    fileSize = IOUtil.copy( bis, deflaterStream );
}
The try-with-resources mechanism will call close on the DeflaterOutputStream, which will in turn call close on the BufferedOutputStream, which will call flush() then close() on the blob output stream.  The try-with-resources mechanism will then call close on the BufferedOutputStream which again calls flush() on the blob output stream, resulting in an exception.

My proposed fix is to change FilterOutputStream.close() as follows:

    @Override
    @SuppressWarnings("try")
    public void close() throws IOException {
        if (!closed) {
            closed = true;
            try (OutputStream ostream = out) {
                flush();
            }
        }
    }

    private boolean closed = false;

This will prevent flush() being called on an already closed stream.

I have reported this issue via the Oracle bug tracker and got Review ID JI-9014085, however I never received any follow up from Oracle.  I have also discussed the issue on Stack Overflow: http://stackoverflow.com/questions/25175882/java-8-filteroutputstream-exception.  Do people agree that this is a bug?  If so, what is the process for fixing it?

Thanks,

Nathan Clement
 		 	   		  

From aleksey.shipilev at oracle.com  Tue Dec  2 23:47:41 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 03 Dec 2014 02:47:41 +0300
Subject: More memory-efficient internal representation for Strings: call
	for	more data
In-Reply-To: <6.2.5.6.2.20141202145839.058ac150@oracle.com>
References: <mailman.30355.1417558403.10816.core-libs-dev@openjdk.java.net>
	<6.2.5.6.2.20141202145839.058ac150@oracle.com>
Message-ID: <547E4F9D.7060005@oracle.com>

Hi Douglas,

On 12/03/2014 02:24 AM, Douglas Surber wrote:
> String construction is a big performance issue for JDBC drivers. Most
> queries return some number of Strings. The overwhelming majority of
> those Strings will be short lived. The cost of constructing these
> Strings from network bytes is a large fraction of total execution time.
> Any increase in the cost of constructing a String will far out weigh any
> reduction in memory use, at least for query results.

You will also have to take into the account that shorter (compressed)
Strings allow for more efficient operations on them. This is not to
mention the GC costs are also usually "hidden" from the naive
performance estimations: even though you can perceive the mutator is
spending more time doing work, that might be offset by easier job for GC.

> All of the proposed compression methods require an additional scan of
> the entire string. That's exactly the wrong direction. Something like
> the following pseudo-code is common inside a driver.
> 
>   {
>     char[] c = new char[n];
>     for (i = 0; i < n; i++) c[i] = charSource.next();
>     return new String(c);
>   }

Good to know. We will be assessing the String(char[]) construction
performance in the course of this performance work. What would you say
is a characteristic high-level benchmark for the scenario you are
describing?

> The array copy inside the String constructor is a significant fraction
> of JDBC driver execution time. Adding an additional scan on top of it is
> making things worse regardless of the transient benefit of more compact
> storage. In the case of a query result the String will be likely never
> be promoted out of new space; the benefit of compression would be minimal.

It's hard to say at this point. We want to understand what footprint
improvements we are talking about. I agree that if cost-benefit analysis
will say the performance is degrading beyond the sane limits even if we
are happy with memory savings, there is little reason to push this into
the general JDK.

Thanks,
-Aleksey



From xueming.shen at oracle.com  Wed Dec  3 00:39:13 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 02 Dec 2014 16:39:13 -0800
Subject: More memory-efficient internal representation for Strings: call
	for	more data
In-Reply-To: <6.2.5.6.2.20141202145839.058ac150@oracle.com>
References: <mailman.30355.1417558403.10816.core-libs-dev@openjdk.java.net>
	<6.2.5.6.2.20141202145839.058ac150@oracle.com>
Message-ID: <547E5BB1.5030404@oracle.com>

On 12/02/2014 03:24 PM, Douglas Surber wrote:
> String construction is a big performance issue for JDBC drivers. Most queries return some number of Strings. The overwhelming majority of those Strings will be short lived. The cost of constructing these Strings from network bytes is a large fraction of total execution time. Any increase in the cost of constructing a String will far out weigh any reduction in memory use, at least for query results.
>
> All of the proposed compression methods require an additional scan of the entire string. That's exactly the wrong direction. Something like the following pseudo-code is common inside a driver.
>
>   {
>     char[] c = new char[n];
>     for (i = 0; i < n; i++) c[i] = charSource.next();
>     return new String(c);
>   }

In most use cases, the char[] is a waste if the final target is a String object and the input data is
byte[].  Optimization had been implemented in StringCoding in early releases to avoid redundant
char[] copy if possible. For compressed String project, however, if the final internal storage is
byte[], it might be ideal to avoid the char[] in the byte[] -> char[] -> byte[] -> String path. The
"extra scan" can be combined into the byte[] -> char[] -> byte[] decoding phase.

I do have some optimization in StringCoding for asccii, 8859-1 and utf8 in case of the data is ascii
only,

http://cr.openjdk.java.net/~sherman/8054307/jdk/src/java.base/share/classes/java/lang/StringCoding.java.html

But the benefit might be limited, and the current implementation has a bias on "single byte"
use scenario, with the assumption that most of the String objects inside a live vm heap is single
byte string. More work need to/can be done here, if data shows this indeed is a big issue.

-Sherman

>
> The array copy inside the String constructor is a significant fraction of JDBC driver execution time. Adding an additional scan on top of it is making things worse regardless of the transient benefit of more compact storage. In the case of a query result the String will be likely never be promoted out of new space; the benefit of compression would be minimal.
>
> I don't dispute that Strings occupy a significant fraction of the heap or that a lot of those bytes are zero. And I certainly agree that reducing memory footprint is valuable, but any worsening of String construction time will likely be a problem.
>
> Douglas
>
> At 02:13 PM 12/2/2014, core-libs-dev-request at openjdk.java.net wrote:
>> Date: Wed, 03 Dec 2014 00:59:10 +0300
>> From: Aleksey Shipilev <aleksey.shipilev at oracle.com>
>> To: Java Core Libs <core-libs-dev at openjdk.java.net>
>> Cc: charlie hunt <charlie.hunt at oracle.com>
>> Subject: More memory-efficient internal representation for Strings:
>>         call for        more data
>> Message-ID: <547E362E.5010107 at oracle.com>
>> Content-Type: text/plain; charset=utf-8
>>
>> Hi,
>>
>> As you may already know, we are looking into more memory efficient
>> representation for Strings:
>>  https://bugs.openjdk.java.net/browse/JDK-8054307
>>
>> As part of preliminary performance work for this JEP, we have to collect
>> the empirical data on usual characteristics of Strings and char[]-s
>> normal applications have, as well as figure out the early estimates for
>> the improvements based on that data. What we have so far is written up here:
>>
>> http://cr.openjdk.java.net/~shade/density/string-density-report.pdf
>>
>> We would appreciate if people who are interested in this JEP can provide
>> the additional data on their applications. It is double-interesting to
>> have the data for the applications that process String data outside
>> Latin1 plane. Our current data says these cases are rather rare. Please
>> read the current report draft, and try to process your own heap dumps
>> using the instructions in the Appendix.
>>
>> Thanks,
>> -Aleksey.
>



From douglas.surber at oracle.com  Wed Dec  3 00:42:46 2014
From: douglas.surber at oracle.com (Douglas Surber)
Date: Tue, 02 Dec 2014 16:42:46 -0800
Subject: More memory-efficient internal representation for Strings:
	call for	more data
In-Reply-To: <547E4F9D.7060005@oracle.com>
References: <mailman.30355.1417558403.10816.core-libs-dev@openjdk.java.net>
	<6.2.5.6.2.20141202145839.058ac150@oracle.com>
	<547E4F9D.7060005@oracle.com>
Message-ID: <6.2.5.6.2.20141202162048.058af9b0@oracle.com>

The most common operation on most Strings in query results is to do 
nothing. Just construct the String, hold onto it while the rest of 
the transaction completes, then drop it on the floor. Probably the 
next most common is to encode the chars to write them to an 
OutputStream or send them back to the database. I'd be curious how a 
compact representation would help those operations.

SPECjEnterprise is a widely used standard benchmark. It probably uses 
mostly (or even entirely) ASCII characters so it's not representative 
of many customers.

My definition of "sane limits" might be different than yours. As far 
as I'm concerned String construction is already too slow and should 
be made faster by eliminating the char[] copy when possible.

Douglas

At 03:47 PM 12/2/2014, Aleksey Shipilev wrote:
>Hi Douglas,
>
>On 12/03/2014 02:24 AM, Douglas Surber wrote:
> > String construction is a big performance issue for JDBC drivers. 
> Most
> > queries return some number of Strings. The overwhelming majority 
> of
> > those Strings will be short lived. The cost of constructing these
> > Strings from network bytes is a large fraction of total execution 
> time.
> > Any increase in the cost of constructing a String will far out 
> weigh any
> > reduction in memory use, at least for query results.
>
>You will also have to take into the account that shorter 
>(compressed)
>Strings allow for more efficient operations on them. This is not to
>mention the GC costs are also usually "hidden" from the naive
>performance estimations: even though you can perceive the mutator is
>spending more time doing work, that might be offset by easier job 
>for GC.
>
> > All of the proposed compression methods require an additional 
> scan of
> > the entire string. That's exactly the wrong direction. Something 
> like
> > the following pseudo-code is common inside a driver.
> >
> >   {
> >     char[] c = new char[n];
> >     for (i = 0; i < n; i++) c[i] = charSource.next();
> >     return new String(c);
> >   }
>
>Good to know. We will be assessing the String(char[]) construction
>performance in the course of this performance work. What would you 
>say
>is a characteristic high-level benchmark for the scenario you are
>describing?
>
> > The array copy inside the String constructor is a significant 
> fraction
> > of JDBC driver execution time. Adding an additional scan on top 
> of it is
> > making things worse regardless of the transient benefit of more 
> compact
> > storage. In the case of a query result the String will be likely 
> never
> > be promoted out of new space; the benefit of compression would be 
> minimal.
>
>It's hard to say at this point. We want to understand what footprint
>improvements we are talking about. I agree that if cost-benefit 
>analysis
>will say the performance is degrading beyond the sane limits even if 
>we
>are happy with memory savings, there is little reason to push this 
>into
>the general JDK.
>
>Thanks,
>-Aleksey
>



From xueming.shen at oracle.com  Wed Dec  3 00:56:46 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 02 Dec 2014 16:56:46 -0800
Subject: More memory-efficient internal representation for Strings: call
	for	more data
In-Reply-To: <6.2.5.6.2.20141202162048.058af9b0@oracle.com>
References: <mailman.30355.1417558403.10816.core-libs-dev@openjdk.java.net>	<6.2.5.6.2.20141202145839.058ac150@oracle.com>	<547E4F9D.7060005@oracle.com>
	<6.2.5.6.2.20141202162048.058af9b0@oracle.com>
Message-ID: <547E5FCE.3090500@oracle.com>

On 12/02/2014 04:42 PM, Douglas Surber wrote:
> The most common operation on most Strings in query results is to do nothing. Just construct the String, hold onto it while the rest of the transaction completes, then drop it on the floor. Probably the next most common is to encode the chars to write them to an OutputStream or send them back to the database. I'd be curious how a compact representation would help those operations.
>

It depends on what inside those "query results". If most of them are ascii, only a small portion
are double byted user data (for example, it is true for most of the "utf8" xml files), you might
be able to save the cpu time/throughput by only copying half length of the bytes around their
life circle, especially "copy around" is the only operation they are carrying on.

-Sherman


> SPECjEnterprise is a widely used standard benchmark. It probably uses mostly (or even entirely) ASCII characters so it's not representative of many customers.
>
> My definition of "sane limits" might be different than yours. As far as I'm concerned String construction is already too slow and should be made faster by eliminating the char[] copy when possible.
>
> Douglas
>
> At 03:47 PM 12/2/2014, Aleksey Shipilev wrote:
>> Hi Douglas,
>>
>> On 12/03/2014 02:24 AM, Douglas Surber wrote:
>> > String construction is a big performance issue for JDBC drivers. Most
>> > queries return some number of Strings. The overwhelming majority of
>> > those Strings will be short lived. The cost of constructing these
>> > Strings from network bytes is a large fraction of total execution time.
>> > Any increase in the cost of constructing a String will far out weigh any
>> > reduction in memory use, at least for query results.
>>
>> You will also have to take into the account that shorter (compressed)
>> Strings allow for more efficient operations on them. This is not to
>> mention the GC costs are also usually "hidden" from the naive
>> performance estimations: even though you can perceive the mutator is
>> spending more time doing work, that might be offset by easier job for GC.
>>
>> > All of the proposed compression methods require an additional scan of
>> > the entire string. That's exactly the wrong direction. Something like
>> > the following pseudo-code is common inside a driver.
>> >
>> >   {
>> >     char[] c = new char[n];
>> >     for (i = 0; i < n; i++) c[i] = charSource.next();
>> >     return new String(c);
>> >   }
>>
>> Good to know. We will be assessing the String(char[]) construction
>> performance in the course of this performance work. What would you say
>> is a characteristic high-level benchmark for the scenario you are
>> describing?
>>
>> > The array copy inside the String constructor is a significant fraction
>> > of JDBC driver execution time. Adding an additional scan on top of it is
>> > making things worse regardless of the transient benefit of more compact
>> > storage. In the case of a query result the String will be likely never
>> > be promoted out of new space; the benefit of compression would be minimal.
>>
>> It's hard to say at this point. We want to understand what footprint
>> improvements we are talking about. I agree that if cost-benefit analysis
>> will say the performance is degrading beyond the sane limits even if we
>> are happy with memory savings, there is little reason to push this into
>> the general JDK.
>>
>> Thanks,
>> -Aleksey
>>
>



From huizhe.wang at oracle.com  Wed Dec  3 03:52:52 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 02 Dec 2014 19:52:52 -0800
Subject: Review request for JDK-8051536: Convert JAXP function tests:
	javax.xml.parsers to jtreg(testng) tests
In-Reply-To: <26947A65-EE8C-4F8A-86D9-24A045244DC4@oracle.com>
References: <00d901d00ddb$b7e40f80$27ac2e80$@oracle.com>
	<26947A65-EE8C-4F8A-86D9-24A045244DC4@oracle.com>
Message-ID: <547E8914.4030302@oracle.com>

I agree with Lance's suggestion on utilizing the @BeforeMethod methods 
to instantiate factories, or DocumentBuilder where there's no change in 
state on the DocumentBuilderFactory (that is, no set** in any of the 
tests, such as DocumentBuilderImpl01), or using DataProvider.

However, if you do make the changes, you may need to reset the factory 
or force the tests to run in order. In case of SAXParserTest03, all 
three test cases do spf.setValidating(true) so it can be done in 
@BeforeMethod. But then test 02 and 03 test NamespaceAware, without 
ordering or setting it to false (default) explicitly in test01, it may 
affect test 01.

In other cases, for example DocumentBuilderFactory01, you'd need to set 
the feature back to default within a test in order to not cause negative 
impact on other tests.

As Lance said, these suggestions should not prevent you pushing it in 
the current state. But it may be an helpful exercise if you'd want to 
get familiar with the package.

Cheers,
Joe

On 12/2/2014 6:33 AM, Lance Andersen wrote:
> Hi Frank,
>
> I think this looks good overall.
>
> I might suggest that you consider utilizing the @BeforeMethod methods 
> further, For example is SAXParserTest03.java you could move
>
> SAXParserFactory spf = SAXParserFactory.newInstance();
> spf.setValidating(true);
>
>  to your @BeforeMethod, or consider using a DataProvider that is 
> accessible from all classes to reduce some code duplication which will 
> make maintenance a bit easier.
>
> I am not sure how much more additional info failUnexpected adds, but 
> you could omit this if you choose and just have the test method throw 
> Exception and you will get your failure.
>
> Again the above are suggestions, but should not prevent you pushing 
> this to the workspace
>
> Best
> Lance
> On Dec 1, 2014, at 9:57 PM, Frank Yuan <frank.yuan at oracle.com 
> <mailto:frank.yuan at oracle.com>> wrote:
>
>> Hi, Joe and All
>>
>> We are working on moving internal jaxp functional tests to open jdk repo.
>> This is the parsers suite. Would you please review these test?  Any 
>> comment
>> will be appreciated.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8051536
>> webrev: 
>> http://cr.openjdk.java.net/~joehw/jdk9/test/Frank/8051536/webrev/ 
>> <http://cr.openjdk.java.net/%7Ejoehw/jdk9/test/Frank/8051536/webrev/>
>>
>>
>> Thanks,
>>
>> Frank
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>



From mandy.chung at oracle.com  Wed Dec  3 04:28:46 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 02 Dec 2014 20:28:46 -0800
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <08EA7392-50A0-4A15-AE00-FF886726C101@oracle.com>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>
	<547E1963.2000500@oracle.com>
	<BAFE842B-A51B-49C3-956E-8D35A27CD54A@oracle.com>
	<547E2B46.50106@oracle.com>
	<08EA7392-50A0-4A15-AE00-FF886726C101@oracle.com>
Message-ID: <547E917E.30202@oracle.com>


On 12/2/2014 1:47 PM, Lance Andersen wrote:
> The revised webrev is here 
> http://cr.openjdk.java.net/~lancea/8060068/webrev.03/ 
> <http://cr.openjdk.java.net/%7Elancea/8060068/webrev.03/>
>

Looks good.  Nit:  line 443 and a few places in the getConnection need a 
space in "for(", "if("

> Note, I also tweaked the  doPriviliged block for the  JDBC property

It's nice to see use of limited doPrivileged.  Limited doPrivileged 
restricts the permissions be accessed by the doPrivileged block.  On the 
other hand, since it only calls System.getProperty, that won't leak any 
privileges to untrusted code.  I think we would need some guideline what 
can benefit from limited doPrivileged.  Anyway, I'm fine with your change.

Mandy


From john.r.rose at oracle.com  Wed Dec  3 06:38:20 2014
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 2 Dec 2014 22:38:20 -0800
Subject: [9,
	8u40] RFR (M): 8057020: LambdaForm caches should support eviction
In-Reply-To: <547C9E37.8080809@oracle.com>
References: <547C9E37.8080809@oracle.com>
Message-ID: <01F0EA0F-E957-46C3-8A50-2B2891C5C90F@oracle.com>

Reviewed.

I sympathize with Paul's "gnarly" comment.

Nice bit of stream-ology (rheology) in the test code.

Regarding:

> On Dec 2, 2014, at 8:20 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>> 
>> In src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java
>> 
>>  366                     lambdaForm.transformCache = c = ta;
>> 
>> Do you need to set "c"? It's a local variable and by this point the method should return rather than loop.
> I did it mostly as a cleanup. Now I think that it doesn't help much. Removed (+ similar change in another place).

The "c = " bit can be viewed as a bug-stopper.  It prevents a later expression (if introduced in a future change) from accidentally using 'c' and getting an out-of-date value.  A better bug-stopper would be a declaration that "c is dead as of this point, and cannot be used any more", but the language does not support that.  I don't mind seeing the assignment deleted.

? John

> On Dec 1, 2014, at 8:58 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8057020



From serguei.spitsyn at oracle.com  Wed Dec  3 07:48:17 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Tue, 02 Dec 2014 23:48:17 -0800
Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation
	fault
In-Reply-To: <547D265A.20005@oracle.com>
References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com>
	<54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com>
	<546C5986.6010500@oracle.com> <546C6D1A.8050903@oracle.com>
	<546CBCAB.7040101@oracle.com> <547D265A.20005@oracle.com>
Message-ID: <547EC041.4000103@oracle.com>

The fix still looks good to me.

Thanks,
Serguei


On 12/1/14 6:39 PM, Chris Plummer wrote:
> Sorry about the long delay in getting back to this. I ran into two 
> separate JPRT issues that were preventing me from testing these 
> changes, plus I was on vacation last week. Here's an updated webrev. 
> I'm not sure where we left things, so I'll just say what's changed 
> since the original version:
>
> 1. Rewrote the test to be in Java instead of a shell script.
> 2. Moved the test from hotspot/test/runtime/memory to 
> jdk/test/tools/launcher
> 3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to override 
> the default 32k minimum value.
>
> https://bugs.openjdk.java.net/browse/JDK-6762191
> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/
>
> thanks,
>
> Chris
>
> On 11/19/14 7:52 AM, Chris Plummer wrote:
>> On 11/19/14 2:12 AM, David Holmes wrote:
>>> On 19/11/2014 6:49 PM, Chris Plummer wrote:
>>>> I've update the webrev to add STACK_SIZE_MINIMUM in place of the 32k
>>>> references, and also moved the test from hotspot/test/runtime to
>>>> jdk/test/tools/launcher as David requested. That required some
>>>> adjustments to the test script, since test_env.sh does not exist in
>>>> jdk/test, so I had to pull in the bits I needed into the script.
>>>
>>> Is there a reason this needs a shell script instead of using the 
>>> testlibrary tools to launch the VM and check the output?
>> Not that I'm aware of. I guess I just really didn't look at what it 
>> would take to make it all in java. I'll have a look at java examples 
>> and convert it.
>>
>> Chris
>>>
>>> Sorry that should have been mentioned much earlier.
>>>
>>> David
>>>
>>>
>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.01/
>>>>
>>>> I still need to rerun through JPRT. I'll do so once there are no more
>>>> suggested changes.
>>>>
>>>> thanks,
>>>>
>>>> Chris
>>>>
>>>> On 11/18/14 2:08 PM, Chris Plummer wrote:
>>>>> Adding core-libs-dev at openjdk.java.net, since one of the changes is in
>>>>> java.c.
>>>>>
>>>>> Chris
>>>>>
>>>>> On 11/12/14 6:43 PM, David Holmes wrote:
>>>>>> Hi Chris,
>>>>>>
>>>>>> Sorry for the delay.
>>>>>>
>>>>>> On 13/11/2014 5:44 AM, Chris Plummer wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm still looking for reviewers.
>>>>>>
>>>>>> As the change is to the launcher it needs to be reviewed by the
>>>>>> launcher owner - which I think is serviceability (though also cc'd
>>>>>> Kumar :) ).
>>>>>>
>>>>>> Launcher change, and your rationale, seems okay to me. I'd probably
>>>>>> put the test in to jdk/test/tools/launcher/ though.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>> On 11/7/14 7:53 PM, Chris Plummer wrote:
>>>>>>>> This is an initial review for 6762191. I'm guessing there will be
>>>>>>>> recommendations to fix in a different way, but thought this 
>>>>>>>> would be a
>>>>>>>> good time to start the discussion.
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6762191
>>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.jdk/
>>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.hotspot/
>>>>>>>>
>>>>>>>> The bug is that if the -Xss size is set to something very small 
>>>>>>>> (like
>>>>>>>> 16k), on linux there will be a crash due to overwriting the end 
>>>>>>>> of the
>>>>>>>> stack. This happens before hotspot can compute its stack needs and
>>>>>>>> verify that the stack is big enough.
>>>>>>>>
>>>>>>>> It didn't seem viable to move the hotspot stack size check 
>>>>>>>> earlier. It
>>>>>>>> depends on too much other work done before that point, and the 
>>>>>>>> changes
>>>>>>>> would have been disruptive. The stack size check is currently 
>>>>>>>> done in
>>>>>>>> os::init_2().
>>>>>>>>
>>>>>>>> What is needed is a check before the thread is created. That 
>>>>>>>> way we
>>>>>>>> can create a thread with a big enough stack to handle all needs 
>>>>>>>> up to
>>>>>>>> the point of the check in os::init_2(). This initial check does 
>>>>>>>> not
>>>>>>>> need to be the final check. It just needs to confirm that we have
>>>>>>>> enough stack to get us to the check in os::init_2().
>>>>>>>>
>>>>>>>> I decided to check in java.c if the -Xss size is too small, and 
>>>>>>>> set it
>>>>>>>> to a larger size if it is. I hard coded this size to 32k (I'll 
>>>>>>>> explain
>>>>>>>> why 32k later). I suspect this is the part that will result in 
>>>>>>>> some
>>>>>>>> debate. If you have better suggestions let me know. If it does 
>>>>>>>> stay
>>>>>>>> here, then probably the 32k needs to be a #define, and maybe 
>>>>>>>> even an
>>>>>>>> OS porting interface, but I'm not sure where to put it.
>>>>>>>>
>>>>>>>> The reason I chose 32k is because this is big enough for all 
>>>>>>>> platforms
>>>>>>>> to get to the stack size check in os::init_2(). It is also smaller
>>>>>>>> than the actual minimum stack size allowed on any platform. 32-bit
>>>>>>>> windows has the smallest requirement at 64k. I add some printfs to
>>>>>>>> print the minimum stack requirement, and then ran a simple 
>>>>>>>> JTReg test
>>>>>>>> with every JPRT supported platform to get the results.
>>>>>>>>
>>>>>>>> The TooSmallStackSize.sh will run "java -version" with -Xss16k,
>>>>>>>> -Xss32k, and -XXss<minsize>, where <minsize> is the size from the
>>>>>>>> error message produced by the JVM, such as in the following:
>>>>>>>>
>>>>>>>> $ java -Xss32k -version
>>>>>>>> The stack size specified is too small, Specify at least 100k
>>>>>>>> Error: Could not create the Java Virtual Machine.
>>>>>>>> Error: A fatal exception has occurred. Program will exit.
>>>>>>>>
>>>>>>>> I ran this test through JPRT on all platforms, and they all pass.
>>>>>>>>
>>>>>>>> One thing to point out is that Windows behaves a bit different 
>>>>>>>> than
>>>>>>>> the other platforms. It always rounds the stack size up to a 
>>>>>>>> multiple
>>>>>>>> of 64k , so even if you specify -Xss16k, you get a 64k stack. On
>>>>>>>> 32-bit Windows with C1, 64k is also the minimum requirement, so 
>>>>>>>> there
>>>>>>>> is no error produced in this case. However, on 32-bit Windows 
>>>>>>>> with C2,
>>>>>>>> 68k is the minimum, so an error is produced since the stack 
>>>>>>>> will only
>>>>>>>> be 64k. There is no bug here. It's just a bit confusing.
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>>
>>>>>>>> Chris
>>>>>>>
>>>>>
>>>>
>>
>



From vladimir.x.ivanov at oracle.com  Wed Dec  3 08:04:04 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 03 Dec 2014 12:04:04 +0400
Subject: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support
	eviction
In-Reply-To: <01F0EA0F-E957-46C3-8A50-2B2891C5C90F@oracle.com>
References: <547C9E37.8080809@oracle.com>
	<01F0EA0F-E957-46C3-8A50-2B2891C5C90F@oracle.com>
Message-ID: <547EC3F4.5040504@oracle.com>

Paul, John, thanks!

Best regards,
Vladimir Ivanov

On 12/3/14, 10:38 AM, John Rose wrote:
> Reviewed.
>
> I sympathize with Paul's "gnarly" comment.
>
> Nice bit of stream-ology (rheology) in the test code.
>
> Regarding:
>
>> On Dec 2, 2014, at 8:20 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>>>
>>> In src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java
>>>
>>>   366                     lambdaForm.transformCache = c = ta;
>>>
>>> Do you need to set "c"? It's a local variable and by this point the method should return rather than loop.
>> I did it mostly as a cleanup. Now I think that it doesn't help much. Removed (+ similar change in another place).
>
> The "c = " bit can be viewed as a bug-stopper.  It prevents a later expression (if introduced in a future change) from accidentally using 'c' and getting an out-of-date value.  A better bug-stopper would be a declaration that "c is dead as of this point, and cannot be used any more", but the language does not support that.  I don't mind seeing the assignment deleted.
>
> ? John
>
>> On Dec 1, 2014, at 8:58 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>>
>> http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8057020
>


From Alan.Bateman at oracle.com  Wed Dec  3 09:06:12 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 03 Dec 2014 09:06:12 +0000
Subject: RFR: Update
	java/nio/charset/Charset/NIOCharsetAvailabilityTest.java
	to eliminate dependency on sun.misc.Launcher
In-Reply-To: <547C1EE3.2080309@oracle.com>
References: <54784FE3.2040508@oracle.com> <547877BD.3070400@oracle.com>
	<547C1EE3.2080309@oracle.com>
Message-ID: <547ED284.3090606@oracle.com>

On 01/12/2014 07:55, Amy Lu wrote:
> Yes, the extensions part should be removed.
>
> Please review the updated version: 
> http://cr.openjdk.java.net/~weijun/8066131/webrev.01
This looks okay for now and I can sponsor this for you. We might have to 
come back to this test later in JDK 9.

-Alan


From aleksey.shipilev at oracle.com  Wed Dec  3 09:24:22 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 03 Dec 2014 12:24:22 +0300
Subject: JEP 198 JDK-8046390 involvement
In-Reply-To: <CAPm=oFCvix9LHa=5JSnWmCk8QfD0__vE-FYzN2GE9dGwc1-A0A@mail.gmail.com>
References: <CAPm=oFCvix9LHa=5JSnWmCk8QfD0__vE-FYzN2GE9dGwc1-A0A@mail.gmail.com>
Message-ID: <547ED6C6.6050701@oracle.com>

Hi Hendrik,

On 11/28/2014 03:40 PM, Hendrik Dev wrote:
> Is it enough to read this mailing list or are other sources more 
> recommended and is http://hg.openjdk.java.net/jdk9/dev/jdk/ the
> correct repo?

I think yes, and yes.

Joe Wang (JEP assignee) is on this list.

-Aleksey.



From Alan.Bateman at oracle.com  Wed Dec  3 09:37:05 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 03 Dec 2014 09:37:05 +0000
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>	<547DEC01.2050501@gmail.com>	<547DF89A.2020809@oracle.com>
	<CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>
Message-ID: <547ED9C1.1020500@oracle.com>

On 02/12/2014 22:34, Martin Buchholz wrote:
> :
>
> Martin's pet peeve: use readFully (why doesn't InputStream support
> that yet?!) copy-paste from elsewhere in the jdk.
>
>
I agree, I think this should be #2 on the list to look at as part of the 
I/O convenience methods thread.

-Alan


From aleksey.shipilev at oracle.com  Wed Dec  3 10:37:37 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 03 Dec 2014 13:37:37 +0300
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
Message-ID: <547EE7F1.4090705@oracle.com>

Hi,

On 12/02/2014 01:02 PM, Paul Sandoz wrote:
> Please find below a patch to remove the networking code computing a
> seed in ThreadLocal/SplittableRandom.

Looks good.

> We thought it a good idea at the time :-) but subsequently on certain
> platforms this results in very high initalization costs that can
> propagate to other classes such as ConcurrentSkipList*.

Yes, that irked me a lot at the time we introduced this.

-Aleksey.



From aleksey.shipilev at oracle.com  Wed Dec  3 11:11:59 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 03 Dec 2014 14:11:59 +0300
Subject: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support
	eviction
In-Reply-To: <547C9E37.8080809@oracle.com>
References: <547C9E37.8080809@oracle.com>
Message-ID: <547EEFFF.4040409@oracle.com>

On 12/01/2014 07:58 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8057020

Looks okay, although the cache management logic gives me a headache
after the vacation. I thought I spotted a few bugs, but those were only
false positives.

> The fix is to use SoftReferences to keep LambdaForms alive as long as
> possible, but avoid throwing OOME until the caches are evicted. I
> experimented with WeakReferences, but it doesn't hold LambdaForms for
> long enough: LambdaForm cache hit rate degrades significantly and it
> negatively affects application startup and warmup, since every
> instantiated LambdaForm is precompiled to bytecode before usage.
> 
> Testing: jdk/java/lang/invoke/LFCache in stress mode + jck
> (api/java_lang/invoke), jdk/java/lang/invoke, jdk/java/util/streams, octane

SoftReferences are tricky in the way they can get suddenly drop the
referent, and normal testing would not catch it (e.g. the normal
operation would reclaim softrefs under your feet almost never). Does
this code survive with -XX:SoftRefLRUPolicyMSPerMB=0?

Thanks,
-Aleksey.




From vladimir.x.ivanov at oracle.com  Wed Dec  3 11:45:19 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Wed, 03 Dec 2014 15:45:19 +0400
Subject: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support
	eviction
In-Reply-To: <547EEFFF.4040409@oracle.com>
References: <547C9E37.8080809@oracle.com> <547EEFFF.4040409@oracle.com>
Message-ID: <547EF7CF.7070501@oracle.com>

Aleksey, thanks for the review.

I haven't tried -XX:SoftRefLRUPolicyMSPerMB=0, but I did extensive 
testing on Octane/Nashorn with multiple low -Xmx levels + frequent Full 
GCs (8060147 [1] was the result of those experiments) and stress tested 
cache eviction with jdk/java/lang/invoke/LFCache tests in long running 
mode.

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8060147

On 12/3/14, 3:11 PM, Aleksey Shipilev wrote:
> On 12/01/2014 07:58 PM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8057020
>
> Looks okay, although the cache management logic gives me a headache
> after the vacation. I thought I spotted a few bugs, but those were only
> false positives.
>
>> The fix is to use SoftReferences to keep LambdaForms alive as long as
>> possible, but avoid throwing OOME until the caches are evicted. I
>> experimented with WeakReferences, but it doesn't hold LambdaForms for
>> long enough: LambdaForm cache hit rate degrades significantly and it
>> negatively affects application startup and warmup, since every
>> instantiated LambdaForm is precompiled to bytecode before usage.
>>
>> Testing: jdk/java/lang/invoke/LFCache in stress mode + jck
>> (api/java_lang/invoke), jdk/java/lang/invoke, jdk/java/util/streams, octane
>
> SoftReferences are tricky in the way they can get suddenly drop the
> referent, and normal testing would not catch it (e.g. the normal
> operation would reclaim softrefs under your feet almost never). Does
> this code survive with -XX:SoftRefLRUPolicyMSPerMB=0?
>
> Thanks,
> -Aleksey.
>
>


From Alan.Bateman at oracle.com  Wed Dec  3 12:56:41 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 03 Dec 2014 12:56:41 +0000
Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation
	fault
In-Reply-To: <547D265A.20005@oracle.com>
References: <545D939D.2030308@oracle.com>
	<5463B896.10801@oracle.com>	<54641ADE.8030504@oracle.com>
	<546BC35E.4070402@oracle.com>	<546C5986.6010500@oracle.com>
	<546C6D1A.8050903@oracle.com>	<546CBCAB.7040101@oracle.com>
	<547D265A.20005@oracle.com>
Message-ID: <547F0889.5050204@oracle.com>

On 02/12/2014 02:39, Chris Plummer wrote:
> Sorry about the long delay in getting back to this. I ran into two 
> separate JPRT issues that were preventing me from testing these 
> changes, plus I was on vacation last week. Here's an updated webrev. 
> I'm not sure where we left things, so I'll just say what's changed 
> since the original version:
>
> 1. Rewrote the test to be in Java instead of a shell script.
> 2. Moved the test from hotspot/test/runtime/memory to 
> jdk/test/tools/launcher
> 3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to override 
> the default 32k minimum value.
>
> https://bugs.openjdk.java.net/browse/JDK-6762191
> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/
This looks to me. A minor comment for java.c is that this code uses 
4-space indent (different to hotspot).

The test looks okay too, you might just checking the copyright date as I 
assume was not written in 2010. Also I think the import of java.io.File 
may be left behind from the previous round.

-Alan


From roger.riggs at oracle.com  Wed Dec  3 14:14:26 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Wed, 03 Dec 2014 09:14:26 -0500
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <547DEC01.2050501@gmail.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
	<547DEC01.2050501@gmail.com>
Message-ID: <547F1AC2.1080303@oracle.com>

Hi Peter,

A few questions and comments:

  - Can/should this function be fit into one of the existing classes?

  - Is more than one instance needed?
    Seed material seems to be needed only as a one-shot so a simpler 
implementation that opens,
    uses and closes would leave fewer leftovers (and not introduce a new 
finalizer use).

- The Windows  native code could be simpler if the hCryptProv
    was returned from the init function and passed as an argument where 
needed in getBytes and close .

- The static checking tool we use will complain about JNI functions that may
    throw exceptions if those exceptions are not checked for.
    For example, SystemRandomImpl_md.c:80.
    The macros in jni_util.h like CHECK_NULL, CHECK_NULL_RETURN can be used.

Thanks, Roger


On 12/2/2014 11:42 AM, Peter Levart wrote:
> On 12/02/2014 11:02 AM, Paul Sandoz wrote:
>> Hi,
>>
>> Please find below a patch to remove the networking code computing a 
>> seed in ThreadLocal/SplittableRandom.
>>
>> We thought it a good idea at the time :-) but subsequently on certain 
>> platforms this results in very high initalization costs that can 
>> propagate to other classes such as ConcurrentSkipList*.
>>
>> The short-term solution is to remove this code and fallback just 
>> using current system time. This needs to be back-ported to 8u40.
>>
>> A longer term solution is to provide a simple public API to get 
>> access to some seed bytes that is optimal for the underlying 
>> platform, for example, based on Peter's investigations. For linux 
>> /dev/urandom is sufficient as a source of bytes. The main problem 
>> seems to be Windows. It would also be nice to back-port to say 8u60 
>> using a private API and update TLR/SR.
>
> Hi,
>
> Here's a proof of concept for an API that just delegates to 
> system-provided "cryptographically secure" (as declared by the 
> system(s)) pseudo random number generator:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.01/
>
> On UNIX-es this uses /dev/urandom (which is non-blocking and uses 
> system entropy at least for it's seed):
>
> http://en.wikipedia.org/?title=/dev/random
>
> On Windows it uses MS Crypto API's function CryptGenRandom (the JNI 
> code is ripped from the sun.security.provider.NativeSeedGenerator), 
> which also seeds from various system sources of entropy:
>
> http://en.wikipedia.org/wiki/CryptGenRandom
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa379942%28v=vs.85%29.aspx 
>
>
> The initialization overhead is low on UNIX (the enclosed test run on 
> 64 bit Fedora 20, i7 PC):
>
> SystemRandomTest... (8 bytes / invocation)
> 1st invocation: 112315 ns, result: [25, 61, -12, -106, 75, -7, -73, -55]
> Following 1000000 invocations: 0.636644474 s, (636 ns/invocation)
>
> The same test run on 32 bit Windows 7 (as VirtualBox guest on the same 
> machine):
>
> SystemRandomTest... (8 bytes / invocation)
> 1st invocation: 4880788 ns, result: [-32, 53, -31, 62, 51, 83, 9, -5]
> Following 1000000 invocations: 1.761087512 s, (1761 ns/invocation)
>
> I think the initialization on Windows has an initial latency of approx 
> 5ms because it has to initialize the whole MS Crypto API with it's 
> providers. But CryptGenRandom, which is part of this API, actually 
> delegates it's work to RtlGenRandom function:
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa387694%28v=vs.85%29.aspx 
>
>
> ...which might have lower initialization costs. Unfortunately, the 
> wording in the Microsoft document states that it might be removed in 
> the future. Perhaps we could try to use it and fallback to 
> CryptGenRandom if it is not available...
>
>
> Regards, Peter
>
>
>>
>> Paul.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8060435
>>
>> diff -r 1b599b4755bd 
>> src/java.base/share/classes/java/util/SplittableRandom.java
>> --- a/src/java.base/share/classes/java/util/SplittableRandom.java Mon 
>> Dec 01 17:59:39 2014 -0800
>> +++ b/src/java.base/share/classes/java/util/SplittableRandom.java Tue 
>> Dec 02 10:53:47 2014 +0100
>> @@ -237,34 +237,7 @@
>>                   s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
>>               return s;
>>           }
>> -        long h = 0L;
>> -        try {
>> -            Enumeration<NetworkInterface> ifcs =
>> -                    NetworkInterface.getNetworkInterfaces();
>> -            boolean retry = false; // retry once if 
>> getHardwareAddress is null
>> -            while (ifcs.hasMoreElements()) {
>> -                NetworkInterface ifc = ifcs.nextElement();
>> -                if (!ifc.isVirtual()) { // skip fake addresses
>> -                    byte[] bs = ifc.getHardwareAddress();
>> -                    if (bs != null) {
>> -                        int n = bs.length;
>> -                        int m = Math.min(n >>> 1, 4);
>> -                        for (int i = 0; i < m; ++i)
>> -                            h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
>> -                        if (m < 4)
>> -                            h = (h << 8) ^ bs[n-1-m];
>> -                        h = mix64(h);
>> -                        break;
>> -                    }
>> -                    else if (!retry)
>> -                        retry = true;
>> -                    else
>> -                        break;
>> -                }
>> -            }
>> -        } catch (Exception ignore) {
>> -        }
>> -        return (h ^ mix64(System.currentTimeMillis()) ^
>> +        return (mix64(System.currentTimeMillis()) ^
>>                   mix64(System.nanoTime()));
>>       }
>>   diff -r 1b599b4755bd 
>> src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java
>> --- 
>> a/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java 
>> Mon Dec 01 17:59:39 2014 -0800
>> +++ 
>> b/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java 
>> Tue Dec 02 10:53:47 2014 +0100
>> @@ -147,34 +147,7 @@
>>                   s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
>>               return s;
>>           }
>> -        long h = 0L;
>> -        try {
>> -            Enumeration<NetworkInterface> ifcs =
>> -                    NetworkInterface.getNetworkInterfaces();
>> -            boolean retry = false; // retry once if 
>> getHardwareAddress is null
>> -            while (ifcs.hasMoreElements()) {
>> -                NetworkInterface ifc = ifcs.nextElement();
>> -                if (!ifc.isVirtual()) { // skip fake addresses
>> -                    byte[] bs = ifc.getHardwareAddress();
>> -                    if (bs != null) {
>> -                        int n = bs.length;
>> -                        int m = Math.min(n >>> 1, 4);
>> -                        for (int i = 0; i < m; ++i)
>> -                            h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
>> -                        if (m < 4)
>> -                            h = (h << 8) ^ bs[n-1-m];
>> -                        h = mix64(h);
>> -                        break;
>> -                    }
>> -                    else if (!retry)
>> -                        retry = true;
>> -                    else
>> -                        break;
>> -                }
>> -            }
>> -        } catch (Exception ignore) {
>> -        }
>> -        return (h ^ mix64(System.currentTimeMillis()) ^
>> +        return (mix64(System.currentTimeMillis()) ^
>>                   mix64(System.nanoTime()));
>>       }
>



From chris.hegarty at oracle.com  Wed Dec  3 14:40:43 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 03 Dec 2014 14:40:43 +0000
Subject: RFR [9]:
	javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
	fails to compile
Message-ID: <547F20EB.3000103@oracle.com>

The changes in 8035000 [1] changed some common rmi testlibrary classes, 
RMID.java for one, and this test no longer compiles.

The test should call RMID destroy() instead of shutdown(..).

../chhegar/s/jdk/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java:64: 
error: method shutdown in class RMID cannot be applied to given types;
             rmid.shutdown(rmidPort);
                 ^
   required: no arguments
   found: int
   reason: actual and formal argument lists differ in length
1 error

diff --git 
a/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java 
b/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
--- 
a/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
+++ 
b/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
@@ -61,7 +61,7 @@
                      // ignore
                  }
              }
-            rmid.shutdown(rmidPort);
+            rmid.destroy();
          }

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8035000


From Alan.Bateman at oracle.com  Wed Dec  3 14:41:57 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 03 Dec 2014 14:41:57 +0000
Subject: RFR [9]:
	javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
	fails to compile
In-Reply-To: <547F20EB.3000103@oracle.com>
References: <547F20EB.3000103@oracle.com>
Message-ID: <547F2135.3000708@oracle.com>

On 03/12/2014 14:40, Chris Hegarty wrote:
> :
>
> diff --git 
> a/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java 
> b/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java 
>
> --- 
> a/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
> +++ 
> b/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
> @@ -61,7 +61,7 @@
>                      // ignore
>                  }
>              }
> -            rmid.shutdown(rmidPort);
> +            rmid.destroy();
>          }
I'm sure Stuart does a good "D'oh".

The change looks okay to me.

-Alan.




From lance.andersen at oracle.com  Wed Dec  3 15:03:00 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 3 Dec 2014 10:03:00 -0500
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <547E917E.30202@oracle.com>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>
	<547E1963.2000500@oracle.com>
	<BAFE842B-A51B-49C3-956E-8D35A27CD54A@oracle.com>
	<547E2B46.50106@oracle.com>
	<08EA7392-50A0-4A15-AE00-FF886726C101@oracle.com>
	<547E917E.30202@oracle.com>
Message-ID: <987DFED5-A43C-4F2E-B0AB-BAC1F2822028@oracle.com>

Hi Mandy,
On Dec 2, 2014, at 11:28 PM, Mandy Chung <mandy.chung at oracle.com> wrote:

> 
> On 12/2/2014 1:47 PM, Lance Andersen wrote:
>> The revised webrev is here http://cr.openjdk.java.net/~lancea/8060068/webrev.03/
>> 
> 
> Looks good.  Nit:  line 443 and a few places in the getConnection need a space in "for(", "if("

Thank you.  I made a pass and should have caught them all

http://cr.openjdk.java.net/~lancea/8060068/webrev.04/

I built this against JDK 8u and all JCK tests pass.  Also ran the unit tests and got the the expected tests to pass (these tests are only in JDK 9)
> 
>> Note, I also tweaked the  doPriviliged block for the  JDBC property
> 
> It's nice to see use of limited doPrivileged.  Limited doPrivileged restricts the permissions be accessed by the doPrivileged block.  On the other hand, since it only calls System.getProperty, that won't leak any privileges to untrusted code.  I think we would need some guideline what can benefit from limited doPrivileged.  Anyway, I'm fine with your change.

Trying to slowly add the limited doPrivileged when I do an update.  We did the same in RowSetProvider earlier for the same reason.

Best
Lance
> 
> Mandy



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





From lance.andersen at oracle.com  Wed Dec  3 15:06:37 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 3 Dec 2014 10:06:37 -0500
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <20141203003343.00002049.ecki@zusammenkunft.net>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>
	<547E1963.2000500@oracle.com>
	<BAFE842B-A51B-49C3-956E-8D35A27CD54A@oracle.com>
	<20141202224927.0000060e.ecki@zusammenkunft.net>
	<547E38BE.9000509@oracle.com>
	<20141203003343.00002049.ecki@zusammenkunft.net>
Message-ID: <CC7D3AEE-0F9C-4BF3-B945-BCEF5C410427@oracle.com>

Hi Bernd,
On Dec 2, 2014, at 6:33 PM, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:

> Hello Mandy and Lance,
> 
> (sorry, not a full quote for more focused answers, inline)
> 
> Am Tue, 02 Dec 2014 14:10:06 -0800
> schrieb Mandy Chung <mandy.chung at oracle.com>:
> 
>> Would you be able to try this patch and see if the deadlocks are 
>> reproducible?  Lance has been trying to get customers to verify this 
>> patch as this code has been deadlock-prone.  Your feedback would be
>> very useful.
> 
> Hm, I might be able to test it with the unit tests (once I get the
> binary to build). Currently I cant test the whole system with 8 or 9
> (do you think porting it to 7 might be straight forward?). I think the
> Unit tests have no reproducers for this issue, will check.

Yes, only change that needs to be done is to remove the change to use the limited doPrivileged which is trivial for JDK 7
> 
>>> This does have two consequences which are related to this patch:
>>> 
>>> a) #getConnection() is used quite often, as it tunnels through to a
>>> high performing pool (already mentioned as a good reason for DCL).
>> 
>> Once the drivers are loaded and initialized (once), getConnection
>> would not need any locking (it just checks the volatile boolean
>> field).
>> 
>> Do you see any potential performance issue with it?
> 
> No, dont see a problem. I wanted to add another vote pro DCL.
DCL is still there
> 
> 
Best,
Lance



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





From dl at cs.oswego.edu  Wed Dec  3 15:26:57 2014
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 03 Dec 2014 10:26:57 -0500
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>	<547DEC01.2050501@gmail.com>
	<547DF89A.2020809@oracle.com>
	<CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>
Message-ID: <547F2BC1.6040904@cs.oswego.edu>

On 12/02/2014 05:34 PM, Martin Buchholz wrote:
> I support Peter's initiative and am willing to help review if we have
> general consensus about the direction.
>

Peter's implementation scheme of using Unix /dev/urandom
or the Windows Crypto API (or something else on failure) seems
like the best options. I don't see why we shouldn't place this
as a jdk9 public static method in one of the existing random classes
though (Random, SplittableRandom, ThreadLocalRandom, SecureRandom),
rather than as separate entity. (If desired, for jdk8 backport,
it could be non-public, with cheats to access.)

-Doug


>>>
>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.01/
>>>
>> The API looks reasonable to me too, I'm just not sure that java.util is the
>> right place and whether it needs to be a Java SE API.
>>
>> -Alan
>



From sean.mullan at oracle.com  Wed Dec  3 15:39:24 2014
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 03 Dec 2014 10:39:24 -0500
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <987DFED5-A43C-4F2E-B0AB-BAC1F2822028@oracle.com>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>	<547E1963.2000500@oracle.com>	<BAFE842B-A51B-49C3-956E-8D35A27CD54A@oracle.com>	<547E2B46.50106@oracle.com>	<08EA7392-50A0-4A15-AE00-FF886726C101@oracle.com>	<547E917E.30202@oracle.com>
	<987DFED5-A43C-4F2E-B0AB-BAC1F2822028@oracle.com>
Message-ID: <547F2EAC.90203@oracle.com>

On 12/03/2014 10:03 AM, Lance Andersen wrote:
>>> Note, I also tweaked the  doPriviliged block for the  JDBC property
>> >
>> >It's nice to see use of limited doPrivileged.  Limited doPrivileged restricts the permissions be accessed by the doPrivileged block.  On the other hand, since it only calls System.getProperty, that won't leak any privileges to untrusted code.  I think we would need some guideline what can benefit from limited doPrivileged.  Anyway, I'm fine with your change.
> Trying to slowly add the limited doPrivileged when I do an update.  We did the same in RowSetProvider earlier for the same reason.

Use of limited doPrivileged may also incur more overhead when a 
SecurityManager is installed, so I recommend checking the performance 
impact before switching code to use it. I agree with Mandy that we need 
a guide as to when it is best to use limited doPrivileged, and I will 
look into that. In this case, I also agree with Mandy that this doesn't 
provide much security benefit since the scope of the privileged 
operation is already extremely narrow.

--Sean


From lance.andersen at oracle.com  Wed Dec  3 16:18:45 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 3 Dec 2014 11:18:45 -0500
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <547F2EAC.90203@oracle.com>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>	<547E1963.2000500@oracle.com>	<BAFE842B-A51B-49C3-956E-8D35A27CD54A@oracle.com>	<547E2B46.50106@oracle.com>	<08EA7392-50A0-4A15-AE00-FF886726C101@oracle.com>	<547E917E.30202@oracle.com>
	<987DFED5-A43C-4F2E-B0AB-BAC1F2822028@oracle.com>
	<547F2EAC.90203@oracle.com>
Message-ID: <7D7B583B-6793-4C92-8117-6F2780FBCACF@oracle.com>


On Dec 3, 2014, at 10:39 AM, Sean Mullan <sean.mullan at oracle.com> wrote:

> On 12/03/2014 10:03 AM, Lance Andersen wrote:
>>>> Note, I also tweaked the  doPriviliged block for the  JDBC property
>>> >
>>> >It's nice to see use of limited doPrivileged.  Limited doPrivileged restricts the permissions be accessed by the doPrivileged block.  On the other hand, since it only calls System.getProperty, that won't leak any privileges to untrusted code.  I think we would need some guideline what can benefit from limited doPrivileged.  Anyway, I'm fine with your change.
>> Trying to slowly add the limited doPrivileged when I do an update.  We did the same in RowSetProvider earlier for the same reason.
> 
> Use of limited doPrivileged may also incur more overhead when a SecurityManager is installed, so I recommend checking the performance impact before switching code to use it. I agree with Mandy that we need a guide as to when it is best to use limited doPrivileged, and I will look into that. In this case, I also agree with Mandy that this doesn't provide much security benefit since the scope of the privileged operation is already extremely narrow.

Thank you Sean.  As this code path is only called 1 time, i am not concerned  that performance will be an issue.  If you and Mandy prefer me to remove it, I can, just let me know.

Yes, I agree it is narrow.  The suggestion to add the limited doPriviliged came up in a review of RowSetProvider which is why I figured I would add it here also.  Now that was quite some time ago, so I understand our position might have changed.

Best,
Lance

> 
> --Sean



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





From rob.mckenna at oracle.com  Wed Dec  3 16:21:07 2014
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 03 Dec 2014 16:21:07 +0000
Subject: RFR: 8065238 - javax.naming.NamingException after upgrade to JDK
 8
Message-ID: <547F3873.3030606@oracle.com>

Hi folks,

Looking to fix a regression caused by 8042857. Basically the behaviour 
in 8042857 is incorrect. This fix reverts to the previous behaviour and 
attempts to beef up the tests a little around Ldap timeouts.

http://cr.openjdk.java.net/~robm/8065238/webrev.01/

The test itself looks quite complex but isn't really. There are two 
executor pools. (scheduled and fixed) The fixed pool is for running 
tests concurrently. The scheduled pool is for killing tests that test 
ldap connects / reads where no timeout is set. (according to the spec 
these should wait forever)

For these long running timeout tests, we schedule a thread to interrupt 
the test after waiting for 20s. There are 3 of these long running tests 
in total, hence the decision to run the tests in parallel.

I'm not averse to breaking this out into separate tests and a library 
for the helper classes if people think it makes more sense to leave the 
concurrency up to the test framework.

     -Rob



From pavel.rappo at oracle.com  Wed Dec  3 16:29:25 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 3 Dec 2014 16:29:25 +0000
Subject: Java 8 FilterOutputStream.close() bug
In-Reply-To: <COL131-W2153C3E53572217B544557CA7A0@phx.gbl>
References: <COL131-W2153C3E53572217B544557CA7A0@phx.gbl>
Message-ID: <42253A7E-E001-4309-9E62-32C72FE9D4E0@oracle.com>

Nathan, thanks a lot for reporting this. Sorry no one has replied to you earlier, 
but your bug report was actually entered into the JBS (JDK Bug System):

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

So don't worry, it won't get lost.
Now about the issue itself. It's indeed a bug. Though methods should be written in
an atomic fashion [1] (where possible and where it makes sense), you are right --
java.io.Closeable#close is certainly not one of these methods.
There is nothing you can do if 'close' fails. This method has a terminal semantics.
Implementations cannot rely on some external retry strategy. java.io.Closeable#close
should be called at most once in a lifetime of a Closeable object.

I skimmed through the JDK sources and found some more examples of this behaviour.
They should be fixed as well. As for this particular issue, I see two options:

	1. We just fix it and that's it
	2. You sign OCA [2], provide a test, prepare a change review
           and if everything is fine we push it with comment 
           'Contributed-by: nathan.a.clement at hotmail.com' (or whatever email you choose)

---------------------------------------------------------------------------------
[1] Effective Java, Second Edition, Item 64: Strive for failure atomicity
[2] http://openjdk.java.net/contribute/

-Pavel

> On 2 Dec 2014, at 23:36, Nathan Clement <nathan.a.clement at hotmail.com> wrote:
> 
> Hi,
> 
> I have encountered a bug in FilterOutputStream under Java 8.  The bug is that calling close() on the same stream twice can now result in an exception, whereas under Java 7 it did not.  The reason is that FilterOutputStream.close() calls flush() before calling close() on the underlying stream.  Calling close() twice on the FilterOutputStream will thus result in flush() being called twice.  Some streams (such as OracleBlobOutputStream) will throw an exception if flush() is called after the stream is closed.  In Java 7 any exceptions when calling flush() were ignored, but in Java 8 these exceptions are passed on to the caller.
> 
> This bug appears to have been introduced in "7015589: (spec) BufferedWriter.close leaves stream open if close of underlying Writer fails".  The FilterOutputStream.close() method now does not obey the contract of AutoClosable.close(): "If the stream is already closed then invoking this method has no effect."
> 
> Some sample code that illustrates the problem:
> 
> try( InputStream bis = new BufferedInputStream( inputStream );
>     OutputStream outStream = payloadData.setBinaryStream( 0 );
>     BufferedOutputStream bos = new BufferedOutputStream( outStream );
>     DeflaterOutputStream deflaterStream = new DeflaterOutputStream(
>         bos, new Deflater( 3 ) ) )
> {
>    fileSize = IOUtil.copy( bis, deflaterStream );
> }
> The try-with-resources mechanism will call close on the DeflaterOutputStream, which will in turn call close on the BufferedOutputStream, which will call flush() then close() on the blob output stream.  The try-with-resources mechanism will then call close on the BufferedOutputStream which again calls flush() on the blob output stream, resulting in an exception.
> 
> My proposed fix is to change FilterOutputStream.close() as follows:
> 
>    @Override
>    @SuppressWarnings("try")
>    public void close() throws IOException {
>        if (!closed) {
>            closed = true;
>            try (OutputStream ostream = out) {
>                flush();
>            }
>        }
>    }
> 
>    private boolean closed = false;
> 
> This will prevent flush() being called on an already closed stream.
> 
> I have reported this issue via the Oracle bug tracker and got Review ID JI-9014085, however I never received any follow up from Oracle.  I have also discussed the issue on Stack Overflow: http://stackoverflow.com/questions/25175882/java-8-filteroutputstream-exception.  Do people agree that this is a bug?  If so, what is the process for fixing it?
> 
> Thanks,
> 
> Nathan Clement
> 		 	   		  



From mandy.chung at oracle.com  Wed Dec  3 16:57:06 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 03 Dec 2014 08:57:06 -0800
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <7D7B583B-6793-4C92-8117-6F2780FBCACF@oracle.com>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>	<547E1963.2000500@oracle.com>	<BAFE842B-A51B-49C3-956E-8D35A27CD54A@oracle.com>	<547E2B46.50106@oracle.com>	<08EA7392-50A0-4A15-AE00-FF886726C101@oracle.com>	<547E917E.30202@oracle.com>
	<987DFED5-A43C-4F2E-B0AB-BAC1F2822028@oracle.com>
	<547F2EAC.90203@oracle.com>
	<7D7B583B-6793-4C92-8117-6F2780FBCACF@oracle.com>
Message-ID: <547F40E2.9080806@oracle.com>


On 12/3/2014 8:18 AM, Lance Andersen wrote:
>
> Thank you Sean.  As this code path is only called 1 time, i am not 
> concerned  that performance will be an issue.  If you and Mandy prefer 
> me to remove it, I can, just let me know.
>
> Yes, I agree it is narrow.  The suggestion to add the limited 
> doPriviliged came up in a review of RowSetProvider which is why I 
> figured I would add it here also.  Now that was quite some time ago, 
> so I understand our position might have changed.

Since Sean will look into the guide when it's best to use limited 
doPrivileged, you can add the appropriate ones later in JDK 9 and taking 
it out also makes it easier to backport if any customer requests it.   
I'm okay with webrev.04 and no need to generate a new webrev with the 
doPrivileged change reverted.

Thanks
Mandy




From lance.andersen at oracle.com  Wed Dec  3 17:10:25 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 3 Dec 2014 12:10:25 -0500
Subject: RFR 8060068 : Remove the static initializer block from
	DriverManager
In-Reply-To: <547F40E2.9080806@oracle.com>
References: <AD72A3D0-872F-4CEB-AE79-0EE398E9B279@oracle.com>	<547E1963.2000500@oracle.com>	<BAFE842B-A51B-49C3-956E-8D35A27CD54A@oracle.com>	<547E2B46.50106@oracle.com>	<08EA7392-50A0-4A15-AE00-FF886726C101@oracle.com>	<547E917E.30202@oracle.com>
	<987DFED5-A43C-4F2E-B0AB-BAC1F2822028@oracle.com>
	<547F2EAC.90203@oracle.com>
	<7D7B583B-6793-4C92-8117-6F2780FBCACF@oracle.com>
	<547F40E2.9080806@oracle.com>
Message-ID: <5248C6E2-F7B6-4A59-A09F-0108050DEC7A@oracle.com>


On Dec 3, 2014, at 11:57 AM, Mandy Chung <mandy.chung at oracle.com> wrote:

> 
> On 12/3/2014 8:18 AM, Lance Andersen wrote:
>> 
>> Thank you Sean.  As this code path is only called 1 time, i am not concerned  that performance will be an issue.  If you and Mandy prefer me to remove it, I can, just let me know.
>> 
>> Yes, I agree it is narrow.  The suggestion to add the limited doPriviliged came up in a review of RowSetProvider which is why I figured I would add it here also.  Now that was quite some time ago, so I understand our position might have changed.
> 
> Since Sean will look into the guide when it's best to use limited doPrivileged, you can add the appropriate ones later in JDK 9 and taking it out also makes it easier to backport if any customer requests it.   I'm okay with webrev.04 and no need to generate a new webrev with the doPrivileged change reverted.

Change reverted and for completeness, the  webrev is at http://cr.openjdk.java.net/~lancea/8060068/webrev.05/


Best,
Lance
> Thanks
> Mandy
> 
> 



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





From martinrb at google.com  Wed Dec  3 17:20:34 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 3 Dec 2014 09:20:34 -0800
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <547F2BC1.6040904@cs.oswego.edu>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
	<547DEC01.2050501@gmail.com> <547DF89A.2020809@oracle.com>
	<CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>
	<547F2BC1.6040904@cs.oswego.edu>
Message-ID: <CA+kOe0_h2EBbY51qh7MSUFpq44FpOspgtBVF6qVWENMwW2O0xA@mail.gmail.com>

On Wed, Dec 3, 2014 at 7:26 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 12/02/2014 05:34 PM, Martin Buchholz wrote:
>>
>> I support Peter's initiative and am willing to help review if we have
>> general consensus about the direction.
>>
>
> Peter's implementation scheme of using Unix /dev/urandom
> or the Windows Crypto API (or something else on failure) seems
> like the best options. I don't see why we shouldn't place this
> as a jdk9 public static method in one of the existing random classes
> though (Random, SplittableRandom, ThreadLocalRandom, SecureRandom),
> rather than as separate entity. (If desired, for jdk8 backport,
> it could be non-public, with cheats to access.)

I don't think such a general purpose utility belongs in
SplittableRandom or ThreadLocalRandom - those are the clients.  Random
is a slightly better fit, but still not great.

There is a generalized fear with initialization-time utilities that we
want as few dependencies as possible, to avoid a clinit method that we
are not yet ready to execute, or may never need to execute.  That is
my fear with SecureRandom, which does provider-y stuff I don't
understand.  We don't actually need java crypto yet.


From stuart.marks at oracle.com  Wed Dec  3 17:24:39 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 03 Dec 2014 09:24:39 -0800
Subject: RFR [9]:
	javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
	fails to compile
In-Reply-To: <547F2135.3000708@oracle.com>
References: <547F20EB.3000103@oracle.com> <547F2135.3000708@oracle.com>
Message-ID: <547F4757.1070402@oracle.com>

On 12/3/14 6:41 AM, Alan Bateman wrote:
> On 03/12/2014 14:40, Chris Hegarty wrote:
>> diff --git
>> a/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
>> b/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
>> --- a/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
>> +++ b/test/javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
>> @@ -61,7 +61,7 @@
>>                      // ignore
>>                  }
>>              }
>> -            rmid.shutdown(rmidPort);
>> +            rmid.destroy();
>>          }
> I'm sure Stuart does a good "D'oh".
>
> The change looks okay to me.

D'oh is right! Sorry about this. I didn't know that there were other 
dependencies on the RMI test library. Sigh... I guess I should have looked harder.

Thanks for cleaning this up.

s'marks



From dl at cs.oswego.edu  Wed Dec  3 17:38:37 2014
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 03 Dec 2014 12:38:37 -0500
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <CA+kOe0_h2EBbY51qh7MSUFpq44FpOspgtBVF6qVWENMwW2O0xA@mail.gmail.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>	<547DEC01.2050501@gmail.com>	<547DF89A.2020809@oracle.com>	<CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>	<547F2BC1.6040904@cs.oswego.edu>
	<CA+kOe0_h2EBbY51qh7MSUFpq44FpOspgtBVF6qVWENMwW2O0xA@mail.gmail.com>
Message-ID: <547F4A9D.3060805@cs.oswego.edu>

On 12/03/2014 12:20 PM, Martin Buchholz wrote:

> I don't think such a general purpose utility belongs in
> SplittableRandom or ThreadLocalRandom - those are the clients.  Random
> is a slightly better fit, but still not great.


Perhaps one of these could be made to be a good fit.
As of now, this new method (systemSeed) would be called at most
twice ever -- during static init of SplittableRandom and
ThreadLocalRandom. Either of these could be reworked to
use a high-quality derived seed from the other as its
initial seed. In which case systemSeed would be called only once.
Of the two choices, housing the code in ThreadLocalRandom
seems logistically a bit easier. Then SplittableRandom could use

  private static final AtomicLong defaultGen =
    new AtomicLong(ThreadLocalRandom.current().nextLong());

(For that matter, java.util.Random could use the same
idea for its initial seed.)

-Doug




From peter.levart at gmail.com  Wed Dec  3 17:59:41 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 03 Dec 2014 18:59:41 +0100
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <547F2BC1.6040904@cs.oswego.edu>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>	<547DEC01.2050501@gmail.com>	<547DF89A.2020809@oracle.com>	<CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>
	<547F2BC1.6040904@cs.oswego.edu>
Message-ID: <547F4F8D.9000606@gmail.com>

Hi all,

There seems to be a consensus that a simpler static method would be just 
fine, since it will be used only to gather secure seed for other java 
based PRNG implementations. UNIX file as well as Windows Crypro API 
implementation are naturally exposed as open/use/close API, so I did 
that at first. But when experimenting further with Windows, I replaced 
Crypro API's CryptGenRandom function with underlying implementation 
which is RtlGenRandom. This function does not need any crypto provider 
context to be initialized upfront and then closed.

So here's the 2nd approach exposing just a static method:

http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.02/

I moved it to sun.misc as a public class/method. In JDK9 it could be 
exposed via some standard API if desired, by delegating to it. In UNIX 
version I played a little with short-term caching of open file in case 
several invocations are performed one after the other.

Here are the results of the test on 64bit Linux:

SystemRandomTest... (8 bytes / invocation)
1st invocation: 135356 ns, result: [19, -107, -121, -54, 98, 28, -6, 36]
Following 1000000 invocations: 0.648048516 s, (648 ns/invocation)

When open file caching is not used (file is opened/closed for each 
invocation):

SystemRandomTest... (8 bytes / invocation)
1st invocation: 438672 ns, result: [-84, -71, -106, -126, 21, -42, 48, 0]
Following 1000000 invocations: 3.348318113 s, (3348 ns/invocation)

And the results on 32bit Windows 7 (VirtualBox guest on the same Linux 
host):

SystemRandomTest... (8 bytes / invocation)
1st invocation: 388038 ns, result: [-121, -18, -54, 116, -31, 3, 40, -7]
Following 1000000 invocations: 1.027277209 s, (1027 ns/invocation)


The initialization latency on Windows is much lower now.

What we need now is to try this on as much environments as possible. The 
Windows version needs Windows XP/Windows Server 2003 at least 
(RtlGenRandom has been introduced at that time). If the function is not 
found, JVM most probably crashes. The native code should be changed to 
use LoadLibrary/GetProcAddress to load and get the address of the 
function dynamically, so that an exception can be thrown if this fails. 
But I couldn't get a sample program to load the library (Advapi32.dll) 
successfully (although I could find the .dll file in Windows folder).


Regards, Peter


On 12/03/2014 04:26 PM, Doug Lea wrote:
> On 12/02/2014 05:34 PM, Martin Buchholz wrote:
>> I support Peter's initiative and am willing to help review if we have
>> general consensus about the direction.
>>
>
> Peter's implementation scheme of using Unix /dev/urandom
> or the Windows Crypto API (or something else on failure) seems
> like the best options. I don't see why we shouldn't place this
> as a jdk9 public static method in one of the existing random classes
> though (Random, SplittableRandom, ThreadLocalRandom, SecureRandom),
> rather than as separate entity. (If desired, for jdk8 backport,
> it could be non-public, with cheats to access.)
>
> -Doug
>
>
>>>>
>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.01/
>>>>
>>> The API looks reasonable to me too, I'm just not sure that java.util 
>>> is the
>>> right place and whether it needs to be a Java SE API.
>>>
>>> -Alan
>>
>



From peter.levart at gmail.com  Wed Dec  3 18:42:08 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 03 Dec 2014 19:42:08 +0100
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <547F1AC2.1080303@oracle.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>	<547DEC01.2050501@gmail.com>
	<547F1AC2.1080303@oracle.com>
Message-ID: <547F5980.8080108@gmail.com>

Hi Roger,

Thanks for looking at my baby steps in the JNI / Windows worlds...

Answers inline...

On 12/03/2014 03:14 PM, roger riggs wrote:
> Hi Peter,
>
> A few questions and comments:
>
>  - Can/should this function be fit into one of the existing classes?

As a static method perhaps, yes. The webrev.02 uses this approach.

>
>  - Is more than one instance needed?
>    Seed material seems to be needed only as a one-shot so a simpler 
> implementation that opens,
>    uses and closes would leave fewer leftovers (and not introduce a 
> new finalizer use).

If it is to be used only for seeding cryptographicaly insecure PRNGs 
then this would be simpler, yes. I have one concern though. If the 
"cryptographically secure" promise of the function is started to be 
exploited for seeding  cryptographically secure PRNGs with less secure 
backup plans, then an attacker could force using the backup plan by 
exhausting the resources which would make the function fail (in UNIX 
variant for example, the attacker could just open max. # of allowed 
files). The open/use/eventually-close variant of the API can be used in 
a setting where the resource is pre-allocated at the startup of the JVM 
(the file is opened), so the use part can happen anytime later without 
the worry to be prevented by an attacker.

>
> - The Windows  native code could be simpler if the hCryptProv
>    was returned from the init function and passed as an argument where 
> needed in getBytes and close .

It occurred to me, yes. No need for staticInit0() then. Native methods 
can all be static too...

>
> - The static checking tool we use will complain about JNI functions 
> that may
>    throw exceptions if those exceptions are not checked for.
> For example, SystemRandomImpl_md.c:80.
>    The macros in jni_util.h like CHECK_NULL, CHECK_NULL_RETURN can be 
> used.

I'll take a look at how these are used elsewhere. Thanks for comments.

Regards, Peter

>
> Thanks, Roger
>
>
> On 12/2/2014 11:42 AM, Peter Levart wrote:
>> On 12/02/2014 11:02 AM, Paul Sandoz wrote:
>>> Hi,
>>>
>>> Please find below a patch to remove the networking code computing a 
>>> seed in ThreadLocal/SplittableRandom.
>>>
>>> We thought it a good idea at the time :-) but subsequently on 
>>> certain platforms this results in very high initalization costs that 
>>> can propagate to other classes such as ConcurrentSkipList*.
>>>
>>> The short-term solution is to remove this code and fallback just 
>>> using current system time. This needs to be back-ported to 8u40.
>>>
>>> A longer term solution is to provide a simple public API to get 
>>> access to some seed bytes that is optimal for the underlying 
>>> platform, for example, based on Peter's investigations. For linux 
>>> /dev/urandom is sufficient as a source of bytes. The main problem 
>>> seems to be Windows. It would also be nice to back-port to say 8u60 
>>> using a private API and update TLR/SR.
>>
>> Hi,
>>
>> Here's a proof of concept for an API that just delegates to 
>> system-provided "cryptographically secure" (as declared by the 
>> system(s)) pseudo random number generator:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.01/
>>
>> On UNIX-es this uses /dev/urandom (which is non-blocking and uses 
>> system entropy at least for it's seed):
>>
>> http://en.wikipedia.org/?title=/dev/random
>>
>> On Windows it uses MS Crypto API's function CryptGenRandom (the JNI 
>> code is ripped from the sun.security.provider.NativeSeedGenerator), 
>> which also seeds from various system sources of entropy:
>>
>> http://en.wikipedia.org/wiki/CryptGenRandom
>>
>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa379942%28v=vs.85%29.aspx 
>>
>>
>> The initialization overhead is low on UNIX (the enclosed test run on 
>> 64 bit Fedora 20, i7 PC):
>>
>> SystemRandomTest... (8 bytes / invocation)
>> 1st invocation: 112315 ns, result: [25, 61, -12, -106, 75, -7, -73, -55]
>> Following 1000000 invocations: 0.636644474 s, (636 ns/invocation)
>>
>> The same test run on 32 bit Windows 7 (as VirtualBox guest on the 
>> same machine):
>>
>> SystemRandomTest... (8 bytes / invocation)
>> 1st invocation: 4880788 ns, result: [-32, 53, -31, 62, 51, 83, 9, -5]
>> Following 1000000 invocations: 1.761087512 s, (1761 ns/invocation)
>>
>> I think the initialization on Windows has an initial latency of 
>> approx 5ms because it has to initialize the whole MS Crypto API with 
>> it's providers. But CryptGenRandom, which is part of this API, 
>> actually delegates it's work to RtlGenRandom function:
>>
>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa387694%28v=vs.85%29.aspx 
>>
>>
>> ...which might have lower initialization costs. Unfortunately, the 
>> wording in the Microsoft document states that it might be removed in 
>> the future. Perhaps we could try to use it and fallback to 
>> CryptGenRandom if it is not available...
>>
>>
>> Regards, Peter
>>
>>
>>>
>>> Paul.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8060435
>>>
>>> diff -r 1b599b4755bd 
>>> src/java.base/share/classes/java/util/SplittableRandom.java
>>> --- a/src/java.base/share/classes/java/util/SplittableRandom.java 
>>> Mon Dec 01 17:59:39 2014 -0800
>>> +++ b/src/java.base/share/classes/java/util/SplittableRandom.java 
>>> Tue Dec 02 10:53:47 2014 +0100
>>> @@ -237,34 +237,7 @@
>>>                   s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
>>>               return s;
>>>           }
>>> -        long h = 0L;
>>> -        try {
>>> -            Enumeration<NetworkInterface> ifcs =
>>> -                    NetworkInterface.getNetworkInterfaces();
>>> -            boolean retry = false; // retry once if 
>>> getHardwareAddress is null
>>> -            while (ifcs.hasMoreElements()) {
>>> -                NetworkInterface ifc = ifcs.nextElement();
>>> -                if (!ifc.isVirtual()) { // skip fake addresses
>>> -                    byte[] bs = ifc.getHardwareAddress();
>>> -                    if (bs != null) {
>>> -                        int n = bs.length;
>>> -                        int m = Math.min(n >>> 1, 4);
>>> -                        for (int i = 0; i < m; ++i)
>>> -                            h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
>>> -                        if (m < 4)
>>> -                            h = (h << 8) ^ bs[n-1-m];
>>> -                        h = mix64(h);
>>> -                        break;
>>> -                    }
>>> -                    else if (!retry)
>>> -                        retry = true;
>>> -                    else
>>> -                        break;
>>> -                }
>>> -            }
>>> -        } catch (Exception ignore) {
>>> -        }
>>> -        return (h ^ mix64(System.currentTimeMillis()) ^
>>> +        return (mix64(System.currentTimeMillis()) ^
>>>                   mix64(System.nanoTime()));
>>>       }
>>>   diff -r 1b599b4755bd 
>>> src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java
>>> --- 
>>> a/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java 
>>> Mon Dec 01 17:59:39 2014 -0800
>>> +++ 
>>> b/src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java 
>>> Tue Dec 02 10:53:47 2014 +0100
>>> @@ -147,34 +147,7 @@
>>>                   s = (s << 8) | ((long)(seedBytes[i]) & 0xffL);
>>>               return s;
>>>           }
>>> -        long h = 0L;
>>> -        try {
>>> -            Enumeration<NetworkInterface> ifcs =
>>> -                    NetworkInterface.getNetworkInterfaces();
>>> -            boolean retry = false; // retry once if 
>>> getHardwareAddress is null
>>> -            while (ifcs.hasMoreElements()) {
>>> -                NetworkInterface ifc = ifcs.nextElement();
>>> -                if (!ifc.isVirtual()) { // skip fake addresses
>>> -                    byte[] bs = ifc.getHardwareAddress();
>>> -                    if (bs != null) {
>>> -                        int n = bs.length;
>>> -                        int m = Math.min(n >>> 1, 4);
>>> -                        for (int i = 0; i < m; ++i)
>>> -                            h = (h << 16) ^ (bs[i] << 8) ^ bs[n-1-i];
>>> -                        if (m < 4)
>>> -                            h = (h << 8) ^ bs[n-1-m];
>>> -                        h = mix64(h);
>>> -                        break;
>>> -                    }
>>> -                    else if (!retry)
>>> -                        retry = true;
>>> -                    else
>>> -                        break;
>>> -                }
>>> -            }
>>> -        } catch (Exception ignore) {
>>> -        }
>>> -        return (h ^ mix64(System.currentTimeMillis()) ^
>>> +        return (mix64(System.currentTimeMillis()) ^
>>>                   mix64(System.nanoTime()));
>>>       }
>>
>



From charlie.hunt at oracle.com  Tue Dec  2 22:18:26 2014
From: charlie.hunt at oracle.com (charlie hunt)
Date: Tue, 2 Dec 2014 16:18:26 -0600
Subject: More memory-efficient internal representation for Strings: call
	for more data
In-Reply-To: <CAHjP37Fi0aw=NKi0mL3D9KHsHSimpmUk-Xp3pu2iQ_cwfXwqAQ@mail.gmail.com>
References: <547E362E.5010107@oracle.com>
	<CAHjP37Fi0aw=NKi0mL3D9KHsHSimpmUk-Xp3pu2iQ_cwfXwqAQ@mail.gmail.com>
Message-ID: <A23E7A99-0FD3-4F6B-AD74-45708F2C22BE@oracle.com>

Potentially in the future. It has been on a list of candidate enhancements for quite some time.

As Aleksey just mentioned in his response, (he beat me to the punch), that work is not in scope as part of this project.

Should also mention that the work from this project would not prohibit such an enhancement.

hths,

charlie

> On Dec 2, 2014, at 4:13 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> Any consideration towards removing the char[] (or byte[]) indirection altogether? .NET for example stores the bytes inline with the instance.
> 
> Sent from my phone
> 
> On Dec 2, 2014 4:59 PM, "Aleksey Shipilev" <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>> wrote:
> Hi,
> 
> As you may already know, we are looking into more memory efficient
> representation for Strings:
>  https://bugs.openjdk.java.net/browse/JDK-8054307 <https://bugs.openjdk.java.net/browse/JDK-8054307>
> 
> As part of preliminary performance work for this JEP, we have to collect
> the empirical data on usual characteristics of Strings and char[]-s
> normal applications have, as well as figure out the early estimates for
> the improvements based on that data. What we have so far is written up here:
>  http://cr.openjdk.java.net/~shade/density/string-density-report.pdf <http://cr.openjdk.java.net/~shade/density/string-density-report.pdf>
> 
> We would appreciate if people who are interested in this JEP can provide
> the additional data on their applications. It is double-interesting to
> have the data for the applications that process String data outside
> Latin1 plane. Our current data says these cases are rather rare. Please
> read the current report draft, and try to process your own heap dumps
> using the instructions in the Appendix.
> 
> Thanks,
> -Aleksey.
> 



From patrick at reini.net  Wed Dec  3 18:54:32 2014
From: patrick at reini.net (Patrick Reinhart)
Date: Wed, 3 Dec 2014 19:54:32 +0100
Subject: OpenJDK 9 NetBeans project
Message-ID: <E1F68AE3-2C33-44BE-8420-7C953ECC706A@reini.net>

Hi there,

Has there been a effort jet to update the ?jdk/make/netbeans/j2se/nbproject/project.xml? to the modularized structure jet? 

In the past it was very help full in order to find certain references within the JDK code base.

-Patrick

From kumar.x.srinivasan at oracle.com  Wed Dec  3 18:58:24 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 03 Dec 2014 10:58:24 -0800
Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation
	fault
In-Reply-To: <547D265A.20005@oracle.com>
References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com>
	<54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com>
	<546C5986.6010500@oracle.com> <546C6D1A.8050903@oracle.com>
	<546CBCAB.7040101@oracle.com> <547D265A.20005@oracle.com>
Message-ID: <547F5D50.30309@oracle.com>

Hi Chris,

Approved with some minor nits, typos which needs correction.

yes java.c follows the JDK indenting as Alan pointed out.

TooSmallStackSize.java

Copyright should be 2014,

1.

   37  * stack size for the platform (as provided by the JVM error message when a very
   38  * small is used), and then verify that the JVM can be launched with that stack

s/small is/small stack is/

2.

  54      * Returns the minimum stack size this platform will allowed based on the

s/allowed/allow/

3.

58      * The TestResult argument must containthe result of having already run
s/containthe/contain the/

4.
92         if (verbose) System.out.println("*** Testing " + stackSize);

I know this is allowed in the HotSpot world but in JDK land we always
use with a LF + Indent, also in other places.

5.
85      * Returns the mimumum allowed stack size gleaned from the error message,
s/mimumum/minimum


Finally I am concerned with the integration, since it spans both
HotSpot and JDK, and it appears the test will fail if the HotSpot
changes are not integrated first, or has it already ?

Thanks
Kumar







On 12/1/2014 6:39 PM, Chris Plummer wrote:
> Sorry about the long delay in getting back to this. I ran into two 
> separate JPRT issues that were preventing me from testing these 
> changes, plus I was on vacation last week. Here's an updated webrev. 
> I'm not sure where we left things, so I'll just say what's changed 
> since the original version:
>
> 1. Rewrote the test to be in Java instead of a shell script.
> 2. Moved the test from hotspot/test/runtime/memory to 
> jdk/test/tools/launcher
> 3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to override 
> the default 32k minimum value.
>
> https://bugs.openjdk.java.net/browse/JDK-6762191
> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/
>
> thanks,
>
> Chris
>
> On 11/19/14 7:52 AM, Chris Plummer wrote:
>> On 11/19/14 2:12 AM, David Holmes wrote:
>>> On 19/11/2014 6:49 PM, Chris Plummer wrote:
>>>> I've update the webrev to add STACK_SIZE_MINIMUM in place of the 32k
>>>> references, and also moved the test from hotspot/test/runtime to
>>>> jdk/test/tools/launcher as David requested. That required some
>>>> adjustments to the test script, since test_env.sh does not exist in
>>>> jdk/test, so I had to pull in the bits I needed into the script.
>>>
>>> Is there a reason this needs a shell script instead of using the 
>>> testlibrary tools to launch the VM and check the output?
>> Not that I'm aware of. I guess I just really didn't look at what it 
>> would take to make it all in java. I'll have a look at java examples 
>> and convert it.
>>
>> Chris
>>>
>>> Sorry that should have been mentioned much earlier.
>>>
>>> David
>>>
>>>
>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.01/
>>>>
>>>> I still need to rerun through JPRT. I'll do so once there are no more
>>>> suggested changes.
>>>>
>>>> thanks,
>>>>
>>>> Chris
>>>>
>>>> On 11/18/14 2:08 PM, Chris Plummer wrote:
>>>>> Adding core-libs-dev at openjdk.java.net, since one of the changes is in
>>>>> java.c.
>>>>>
>>>>> Chris
>>>>>
>>>>> On 11/12/14 6:43 PM, David Holmes wrote:
>>>>>> Hi Chris,
>>>>>>
>>>>>> Sorry for the delay.
>>>>>>
>>>>>> On 13/11/2014 5:44 AM, Chris Plummer wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'm still looking for reviewers.
>>>>>>
>>>>>> As the change is to the launcher it needs to be reviewed by the
>>>>>> launcher owner - which I think is serviceability (though also cc'd
>>>>>> Kumar :) ).
>>>>>>
>>>>>> Launcher change, and your rationale, seems okay to me. I'd probably
>>>>>> put the test in to jdk/test/tools/launcher/ though.
>>>>>>
>>>>>> Thanks,
>>>>>> David
>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>> On 11/7/14 7:53 PM, Chris Plummer wrote:
>>>>>>>> This is an initial review for 6762191. I'm guessing there will be
>>>>>>>> recommendations to fix in a different way, but thought this 
>>>>>>>> would be a
>>>>>>>> good time to start the discussion.
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6762191
>>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.jdk/
>>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.hotspot/
>>>>>>>>
>>>>>>>> The bug is that if the -Xss size is set to something very small 
>>>>>>>> (like
>>>>>>>> 16k), on linux there will be a crash due to overwriting the end 
>>>>>>>> of the
>>>>>>>> stack. This happens before hotspot can compute its stack needs and
>>>>>>>> verify that the stack is big enough.
>>>>>>>>
>>>>>>>> It didn't seem viable to move the hotspot stack size check 
>>>>>>>> earlier. It
>>>>>>>> depends on too much other work done before that point, and the 
>>>>>>>> changes
>>>>>>>> would have been disruptive. The stack size check is currently 
>>>>>>>> done in
>>>>>>>> os::init_2().
>>>>>>>>
>>>>>>>> What is needed is a check before the thread is created. That 
>>>>>>>> way we
>>>>>>>> can create a thread with a big enough stack to handle all needs 
>>>>>>>> up to
>>>>>>>> the point of the check in os::init_2(). This initial check does 
>>>>>>>> not
>>>>>>>> need to be the final check. It just needs to confirm that we have
>>>>>>>> enough stack to get us to the check in os::init_2().
>>>>>>>>
>>>>>>>> I decided to check in java.c if the -Xss size is too small, and 
>>>>>>>> set it
>>>>>>>> to a larger size if it is. I hard coded this size to 32k (I'll 
>>>>>>>> explain
>>>>>>>> why 32k later). I suspect this is the part that will result in 
>>>>>>>> some
>>>>>>>> debate. If you have better suggestions let me know. If it does 
>>>>>>>> stay
>>>>>>>> here, then probably the 32k needs to be a #define, and maybe 
>>>>>>>> even an
>>>>>>>> OS porting interface, but I'm not sure where to put it.
>>>>>>>>
>>>>>>>> The reason I chose 32k is because this is big enough for all 
>>>>>>>> platforms
>>>>>>>> to get to the stack size check in os::init_2(). It is also smaller
>>>>>>>> than the actual minimum stack size allowed on any platform. 32-bit
>>>>>>>> windows has the smallest requirement at 64k. I add some printfs to
>>>>>>>> print the minimum stack requirement, and then ran a simple 
>>>>>>>> JTReg test
>>>>>>>> with every JPRT supported platform to get the results.
>>>>>>>>
>>>>>>>> The TooSmallStackSize.sh will run "java -version" with -Xss16k,
>>>>>>>> -Xss32k, and -XXss<minsize>, where <minsize> is the size from the
>>>>>>>> error message produced by the JVM, such as in the following:
>>>>>>>>
>>>>>>>> $ java -Xss32k -version
>>>>>>>> The stack size specified is too small, Specify at least 100k
>>>>>>>> Error: Could not create the Java Virtual Machine.
>>>>>>>> Error: A fatal exception has occurred. Program will exit.
>>>>>>>>
>>>>>>>> I ran this test through JPRT on all platforms, and they all pass.
>>>>>>>>
>>>>>>>> One thing to point out is that Windows behaves a bit different 
>>>>>>>> than
>>>>>>>> the other platforms. It always rounds the stack size up to a 
>>>>>>>> multiple
>>>>>>>> of 64k , so even if you specify -Xss16k, you get a 64k stack. On
>>>>>>>> 32-bit Windows with C1, 64k is also the minimum requirement, so 
>>>>>>>> there
>>>>>>>> is no error produced in this case. However, on 32-bit Windows 
>>>>>>>> with C2,
>>>>>>>> 68k is the minimum, so an error is produced since the stack 
>>>>>>>> will only
>>>>>>>> be 64k. There is no bug here. It's just a bit confusing.
>>>>>>>>
>>>>>>>> thanks,
>>>>>>>>
>>>>>>>> Chris
>>>>>>>
>>>>>
>>>>
>>
>



From martinrb at google.com  Wed Dec  3 19:03:00 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 3 Dec 2014 11:03:00 -0800
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <547F4A9D.3060805@cs.oswego.edu>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
	<547DEC01.2050501@gmail.com> <547DF89A.2020809@oracle.com>
	<CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>
	<547F2BC1.6040904@cs.oswego.edu>
	<CA+kOe0_h2EBbY51qh7MSUFpq44FpOspgtBVF6qVWENMwW2O0xA@mail.gmail.com>
	<547F4A9D.3060805@cs.oswego.edu>
Message-ID: <CA+kOe08vnvXtDE_Xv+6iqtpBaRR3MpdeRV0OtksqMJ_aJpi9Dg@mail.gmail.com>

On Wed, Dec 3, 2014 at 9:38 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 12/03/2014 12:20 PM, Martin Buchholz wrote:
>
>> I don't think such a general purpose utility belongs in
>> SplittableRandom or ThreadLocalRandom - those are the clients.  Random
>> is a slightly better fit, but still not great.
>
>
>
> Perhaps one of these could be made to be a good fit.
> As of now, this new method (systemSeed) would be called at most
> twice ever -- during static init of SplittableRandom and
> ThreadLocalRandom. Either of these could be reworked to
> use a high-quality derived seed from the other as its
> initial seed. In which case systemSeed would be called only once.
> Of the two choices, housing the code in ThreadLocalRandom
> seems logistically a bit easier. Then SplittableRandom could use
>
>  private static final AtomicLong defaultGen =
>    new AtomicLong(ThreadLocalRandom.current().nextLong());
>
> (For that matter, java.util.Random could use the same
> idea for its initial seed.)

Oh, I think I see - you're saying we don't need a new public API,
because ThreadLocalRandom.current() is already exactly the source of
random seed what we want?  That seems pretty good ... except that the
quality of TLR's PRNG is (expected to be) much lower than what we get
from the system - /dev/urandom should be at least a CSPRNG, but TLR is
not.  So ThreadLocalRandom.current().nextLong() is more predictable
than some users might like?  I'm still thinking a public API that
promises cryptographically secure bits without blocking seems
worthwhile.


From chris.plummer at oracle.com  Wed Dec  3 19:26:41 2014
From: chris.plummer at oracle.com (Chris Plummer)
Date: Wed, 03 Dec 2014 11:26:41 -0800
Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation
	fault
In-Reply-To: <547F5D50.30309@oracle.com>
References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com>
	<54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com>
	<546C5986.6010500@oracle.com> <546C6D1A.8050903@oracle.com>
	<546CBCAB.7040101@oracle.com> <547D265A.20005@oracle.com>
	<547F5D50.30309@oracle.com>
Message-ID: <547F63F1.5050202@oracle.com>

Hi Kumar,

On 12/3/14 10:58 AM, Kumar Srinivasan wrote:
> Hi Chris,
>
> Approved with some minor nits, typos which needs correction.
>
> yes java.c follows the JDK indenting as Alan pointed out.
>
> TooSmallStackSize.java
>
> Copyright should be 2014,
Copy/paste error from example test I was referred to. I will fix, and 
also remove the import if not needed.
>
> 1.
>
>   37  * stack size for the platform (as provided by the JVM error 
> message when a very
>   38  * small is used), and then verify that the JVM can be launched 
> with that stack
>
> s/small is/small stack is/
ok
>
> 2.
>
>  54      * Returns the minimum stack size this platform will allowed 
> based on the
>
> s/allowed/allow/
ok
>
> 3.
>
> 58      * The TestResult argument must containthe result of having 
> already run
> s/containthe/contain the/
ok
>
> 4.
> 92         if (verbose) System.out.println("*** Testing " + stackSize);
>
> I know this is allowed in the HotSpot world but in JDK land we always
> use with a LF + Indent, also in other places.
Are curly braces needed then? I know some coding conventions require them.
>
> 5.
> 85      * Returns the mimumum allowed stack size gleaned from the 
> error message,
> s/mimumum/minimum
ok.
>
>
> Finally I am concerned with the integration, since it spans both
> HotSpot and JDK, and it appears the test will fail if the HotSpot
> changes are not integrated first, or has it already ?
There are no hotspot changes. java.c is where the fix is.

thanks,

Chris
>
> Thanks
> Kumar
>
>
>
>
>
>
>
> On 12/1/2014 6:39 PM, Chris Plummer wrote:
>> Sorry about the long delay in getting back to this. I ran into two 
>> separate JPRT issues that were preventing me from testing these 
>> changes, plus I was on vacation last week. Here's an updated webrev. 
>> I'm not sure where we left things, so I'll just say what's changed 
>> since the original version:
>>
>> 1. Rewrote the test to be in Java instead of a shell script.
>> 2. Moved the test from hotspot/test/runtime/memory to 
>> jdk/test/tools/launcher
>> 3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to 
>> override the default 32k minimum value.
>>
>> https://bugs.openjdk.java.net/browse/JDK-6762191
>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/
>>
>> thanks,
>>
>> Chris
>>
>> On 11/19/14 7:52 AM, Chris Plummer wrote:
>>> On 11/19/14 2:12 AM, David Holmes wrote:
>>>> On 19/11/2014 6:49 PM, Chris Plummer wrote:
>>>>> I've update the webrev to add STACK_SIZE_MINIMUM in place of the 32k
>>>>> references, and also moved the test from hotspot/test/runtime to
>>>>> jdk/test/tools/launcher as David requested. That required some
>>>>> adjustments to the test script, since test_env.sh does not exist in
>>>>> jdk/test, so I had to pull in the bits I needed into the script.
>>>>
>>>> Is there a reason this needs a shell script instead of using the 
>>>> testlibrary tools to launch the VM and check the output?
>>> Not that I'm aware of. I guess I just really didn't look at what it 
>>> would take to make it all in java. I'll have a look at java examples 
>>> and convert it.
>>>
>>> Chris
>>>>
>>>> Sorry that should have been mentioned much earlier.
>>>>
>>>> David
>>>>
>>>>
>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.01/
>>>>>
>>>>> I still need to rerun through JPRT. I'll do so once there are no more
>>>>> suggested changes.
>>>>>
>>>>> thanks,
>>>>>
>>>>> Chris
>>>>>
>>>>> On 11/18/14 2:08 PM, Chris Plummer wrote:
>>>>>> Adding core-libs-dev at openjdk.java.net, since one of the changes 
>>>>>> is in
>>>>>> java.c.
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>> On 11/12/14 6:43 PM, David Holmes wrote:
>>>>>>> Hi Chris,
>>>>>>>
>>>>>>> Sorry for the delay.
>>>>>>>
>>>>>>> On 13/11/2014 5:44 AM, Chris Plummer wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I'm still looking for reviewers.
>>>>>>>
>>>>>>> As the change is to the launcher it needs to be reviewed by the
>>>>>>> launcher owner - which I think is serviceability (though also cc'd
>>>>>>> Kumar :) ).
>>>>>>>
>>>>>>> Launcher change, and your rationale, seems okay to me. I'd probably
>>>>>>> put the test in to jdk/test/tools/launcher/ though.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> David
>>>>>>>
>>>>>>>> thanks,
>>>>>>>>
>>>>>>>> Chris
>>>>>>>>
>>>>>>>> On 11/7/14 7:53 PM, Chris Plummer wrote:
>>>>>>>>> This is an initial review for 6762191. I'm guessing there will be
>>>>>>>>> recommendations to fix in a different way, but thought this 
>>>>>>>>> would be a
>>>>>>>>> good time to start the discussion.
>>>>>>>>>
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6762191
>>>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.jdk/
>>>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.hotspot/
>>>>>>>>>
>>>>>>>>> The bug is that if the -Xss size is set to something very 
>>>>>>>>> small (like
>>>>>>>>> 16k), on linux there will be a crash due to overwriting the 
>>>>>>>>> end of the
>>>>>>>>> stack. This happens before hotspot can compute its stack needs 
>>>>>>>>> and
>>>>>>>>> verify that the stack is big enough.
>>>>>>>>>
>>>>>>>>> It didn't seem viable to move the hotspot stack size check 
>>>>>>>>> earlier. It
>>>>>>>>> depends on too much other work done before that point, and the 
>>>>>>>>> changes
>>>>>>>>> would have been disruptive. The stack size check is currently 
>>>>>>>>> done in
>>>>>>>>> os::init_2().
>>>>>>>>>
>>>>>>>>> What is needed is a check before the thread is created. That 
>>>>>>>>> way we
>>>>>>>>> can create a thread with a big enough stack to handle all 
>>>>>>>>> needs up to
>>>>>>>>> the point of the check in os::init_2(). This initial check 
>>>>>>>>> does not
>>>>>>>>> need to be the final check. It just needs to confirm that we have
>>>>>>>>> enough stack to get us to the check in os::init_2().
>>>>>>>>>
>>>>>>>>> I decided to check in java.c if the -Xss size is too small, 
>>>>>>>>> and set it
>>>>>>>>> to a larger size if it is. I hard coded this size to 32k (I'll 
>>>>>>>>> explain
>>>>>>>>> why 32k later). I suspect this is the part that will result in 
>>>>>>>>> some
>>>>>>>>> debate. If you have better suggestions let me know. If it does 
>>>>>>>>> stay
>>>>>>>>> here, then probably the 32k needs to be a #define, and maybe 
>>>>>>>>> even an
>>>>>>>>> OS porting interface, but I'm not sure where to put it.
>>>>>>>>>
>>>>>>>>> The reason I chose 32k is because this is big enough for all 
>>>>>>>>> platforms
>>>>>>>>> to get to the stack size check in os::init_2(). It is also 
>>>>>>>>> smaller
>>>>>>>>> than the actual minimum stack size allowed on any platform. 
>>>>>>>>> 32-bit
>>>>>>>>> windows has the smallest requirement at 64k. I add some 
>>>>>>>>> printfs to
>>>>>>>>> print the minimum stack requirement, and then ran a simple 
>>>>>>>>> JTReg test
>>>>>>>>> with every JPRT supported platform to get the results.
>>>>>>>>>
>>>>>>>>> The TooSmallStackSize.sh will run "java -version" with -Xss16k,
>>>>>>>>> -Xss32k, and -XXss<minsize>, where <minsize> is the size from the
>>>>>>>>> error message produced by the JVM, such as in the following:
>>>>>>>>>
>>>>>>>>> $ java -Xss32k -version
>>>>>>>>> The stack size specified is too small, Specify at least 100k
>>>>>>>>> Error: Could not create the Java Virtual Machine.
>>>>>>>>> Error: A fatal exception has occurred. Program will exit.
>>>>>>>>>
>>>>>>>>> I ran this test through JPRT on all platforms, and they all pass.
>>>>>>>>>
>>>>>>>>> One thing to point out is that Windows behaves a bit different 
>>>>>>>>> than
>>>>>>>>> the other platforms. It always rounds the stack size up to a 
>>>>>>>>> multiple
>>>>>>>>> of 64k , so even if you specify -Xss16k, you get a 64k stack. On
>>>>>>>>> 32-bit Windows with C1, 64k is also the minimum requirement, 
>>>>>>>>> so there
>>>>>>>>> is no error produced in this case. However, on 32-bit Windows 
>>>>>>>>> with C2,
>>>>>>>>> 68k is the minimum, so an error is produced since the stack 
>>>>>>>>> will only
>>>>>>>>> be 64k. There is no bug here. It's just a bit confusing.
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>>
>>>>>>>>> Chris
>>>>>>>>
>>>>>>
>>>>>
>>>
>>
>



From kumar.x.srinivasan at oracle.com  Wed Dec  3 22:13:03 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 03 Dec 2014 14:13:03 -0800
Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation
	fault
In-Reply-To: <547F63F1.5050202@oracle.com>
References: <545D939D.2030308@oracle.com> <5463B896.10801@oracle.com>
	<54641ADE.8030504@oracle.com> <546BC35E.4070402@oracle.com>
	<546C5986.6010500@oracle.com> <546C6D1A.8050903@oracle.com>
	<546CBCAB.7040101@oracle.com> <547D265A.20005@oracle.com>
	<547F5D50.30309@oracle.com> <547F63F1.5050202@oracle.com>
Message-ID: <547F8AEF.3000002@oracle.com>


On 12/3/2014 11:26 AM, Chris Plummer wrote:
> Hi Kumar,
>
> On 12/3/14 10:58 AM, Kumar Srinivasan wrote:
>> Hi Chris,
>>
>> Approved with some minor nits, typos which needs correction.
>>
>> yes java.c follows the JDK indenting as Alan pointed out.
>>
>> TooSmallStackSize.java
>>
>> Copyright should be 2014,
> Copy/paste error from example test I was referred to. I will fix, and 
> also remove the import if not needed.
>>
>> 1.
>>
>>   37  * stack size for the platform (as provided by the JVM error 
>> message when a very
>>   38  * small is used), and then verify that the JVM can be launched 
>> with that stack
>>
>> s/small is/small stack is/
> ok
>>
>> 2.
>>
>>  54      * Returns the minimum stack size this platform will allowed 
>> based on the
>>
>> s/allowed/allow/
> ok
>>
>> 3.
>>
>> 58      * The TestResult argument must containthe result of having 
>> already run
>> s/containthe/contain the/
> ok
>>
>> 4.
>> 92         if (verbose) System.out.println("*** Testing " + stackSize);
>>
>> I know this is allowed in the HotSpot world but in JDK land we always
>> use with a LF + Indent, also in other places.
> Are curly braces needed then? I know some coding conventions require 
> them.

No not necessary for one liners.

>>
>> 5.
>> 85      * Returns the mimumum allowed stack size gleaned from the 
>> error message,
>> s/mimumum/minimum
> ok.
>>
>>
>> Finally I am concerned with the integration, since it spans both
>> HotSpot and JDK, and it appears the test will fail if the HotSpot
>> changes are not integrated first, or has it already ?
> There are no hotspot changes. java.c is where the fix is.

Great!.

Thanks
Kumar

>
> thanks,
>
> Chris
>>
>> Thanks
>> Kumar
>>
>>
>>
>>
>>
>>
>>
>> On 12/1/2014 6:39 PM, Chris Plummer wrote:
>>> Sorry about the long delay in getting back to this. I ran into two 
>>> separate JPRT issues that were preventing me from testing these 
>>> changes, plus I was on vacation last week. Here's an updated webrev. 
>>> I'm not sure where we left things, so I'll just say what's changed 
>>> since the original version:
>>>
>>> 1. Rewrote the test to be in Java instead of a shell script.
>>> 2. Moved the test from hotspot/test/runtime/memory to 
>>> jdk/test/tools/launcher
>>> 3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to 
>>> override the default 32k minimum value.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-6762191
>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/
>>>
>>> thanks,
>>>
>>> Chris
>>>
>>> On 11/19/14 7:52 AM, Chris Plummer wrote:
>>>> On 11/19/14 2:12 AM, David Holmes wrote:
>>>>> On 19/11/2014 6:49 PM, Chris Plummer wrote:
>>>>>> I've update the webrev to add STACK_SIZE_MINIMUM in place of the 32k
>>>>>> references, and also moved the test from hotspot/test/runtime to
>>>>>> jdk/test/tools/launcher as David requested. That required some
>>>>>> adjustments to the test script, since test_env.sh does not exist in
>>>>>> jdk/test, so I had to pull in the bits I needed into the script.
>>>>>
>>>>> Is there a reason this needs a shell script instead of using the 
>>>>> testlibrary tools to launch the VM and check the output?
>>>> Not that I'm aware of. I guess I just really didn't look at what it 
>>>> would take to make it all in java. I'll have a look at java 
>>>> examples and convert it.
>>>>
>>>> Chris
>>>>>
>>>>> Sorry that should have been mentioned much earlier.
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.01/
>>>>>>
>>>>>> I still need to rerun through JPRT. I'll do so once there are no 
>>>>>> more
>>>>>> suggested changes.
>>>>>>
>>>>>> thanks,
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>> On 11/18/14 2:08 PM, Chris Plummer wrote:
>>>>>>> Adding core-libs-dev at openjdk.java.net, since one of the changes 
>>>>>>> is in
>>>>>>> java.c.
>>>>>>>
>>>>>>> Chris
>>>>>>>
>>>>>>> On 11/12/14 6:43 PM, David Holmes wrote:
>>>>>>>> Hi Chris,
>>>>>>>>
>>>>>>>> Sorry for the delay.
>>>>>>>>
>>>>>>>> On 13/11/2014 5:44 AM, Chris Plummer wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I'm still looking for reviewers.
>>>>>>>>
>>>>>>>> As the change is to the launcher it needs to be reviewed by the
>>>>>>>> launcher owner - which I think is serviceability (though also cc'd
>>>>>>>> Kumar :) ).
>>>>>>>>
>>>>>>>> Launcher change, and your rationale, seems okay to me. I'd 
>>>>>>>> probably
>>>>>>>> put the test in to jdk/test/tools/launcher/ though.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> David
>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>>
>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>>> On 11/7/14 7:53 PM, Chris Plummer wrote:
>>>>>>>>>> This is an initial review for 6762191. I'm guessing there 
>>>>>>>>>> will be
>>>>>>>>>> recommendations to fix in a different way, but thought this 
>>>>>>>>>> would be a
>>>>>>>>>> good time to start the discussion.
>>>>>>>>>>
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-6762191
>>>>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.jdk/
>>>>>>>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.00.hotspot/
>>>>>>>>>>
>>>>>>>>>> The bug is that if the -Xss size is set to something very 
>>>>>>>>>> small (like
>>>>>>>>>> 16k), on linux there will be a crash due to overwriting the 
>>>>>>>>>> end of the
>>>>>>>>>> stack. This happens before hotspot can compute its stack 
>>>>>>>>>> needs and
>>>>>>>>>> verify that the stack is big enough.
>>>>>>>>>>
>>>>>>>>>> It didn't seem viable to move the hotspot stack size check 
>>>>>>>>>> earlier. It
>>>>>>>>>> depends on too much other work done before that point, and 
>>>>>>>>>> the changes
>>>>>>>>>> would have been disruptive. The stack size check is currently 
>>>>>>>>>> done in
>>>>>>>>>> os::init_2().
>>>>>>>>>>
>>>>>>>>>> What is needed is a check before the thread is created. That 
>>>>>>>>>> way we
>>>>>>>>>> can create a thread with a big enough stack to handle all 
>>>>>>>>>> needs up to
>>>>>>>>>> the point of the check in os::init_2(). This initial check 
>>>>>>>>>> does not
>>>>>>>>>> need to be the final check. It just needs to confirm that we 
>>>>>>>>>> have
>>>>>>>>>> enough stack to get us to the check in os::init_2().
>>>>>>>>>>
>>>>>>>>>> I decided to check in java.c if the -Xss size is too small, 
>>>>>>>>>> and set it
>>>>>>>>>> to a larger size if it is. I hard coded this size to 32k 
>>>>>>>>>> (I'll explain
>>>>>>>>>> why 32k later). I suspect this is the part that will result 
>>>>>>>>>> in some
>>>>>>>>>> debate. If you have better suggestions let me know. If it 
>>>>>>>>>> does stay
>>>>>>>>>> here, then probably the 32k needs to be a #define, and maybe 
>>>>>>>>>> even an
>>>>>>>>>> OS porting interface, but I'm not sure where to put it.
>>>>>>>>>>
>>>>>>>>>> The reason I chose 32k is because this is big enough for all 
>>>>>>>>>> platforms
>>>>>>>>>> to get to the stack size check in os::init_2(). It is also 
>>>>>>>>>> smaller
>>>>>>>>>> than the actual minimum stack size allowed on any platform. 
>>>>>>>>>> 32-bit
>>>>>>>>>> windows has the smallest requirement at 64k. I add some 
>>>>>>>>>> printfs to
>>>>>>>>>> print the minimum stack requirement, and then ran a simple 
>>>>>>>>>> JTReg test
>>>>>>>>>> with every JPRT supported platform to get the results.
>>>>>>>>>>
>>>>>>>>>> The TooSmallStackSize.sh will run "java -version" with -Xss16k,
>>>>>>>>>> -Xss32k, and -XXss<minsize>, where <minsize> is the size from 
>>>>>>>>>> the
>>>>>>>>>> error message produced by the JVM, such as in the following:
>>>>>>>>>>
>>>>>>>>>> $ java -Xss32k -version
>>>>>>>>>> The stack size specified is too small, Specify at least 100k
>>>>>>>>>> Error: Could not create the Java Virtual Machine.
>>>>>>>>>> Error: A fatal exception has occurred. Program will exit.
>>>>>>>>>>
>>>>>>>>>> I ran this test through JPRT on all platforms, and they all 
>>>>>>>>>> pass.
>>>>>>>>>>
>>>>>>>>>> One thing to point out is that Windows behaves a bit 
>>>>>>>>>> different than
>>>>>>>>>> the other platforms. It always rounds the stack size up to a 
>>>>>>>>>> multiple
>>>>>>>>>> of 64k , so even if you specify -Xss16k, you get a 64k stack. On
>>>>>>>>>> 32-bit Windows with C1, 64k is also the minimum requirement, 
>>>>>>>>>> so there
>>>>>>>>>> is no error produced in this case. However, on 32-bit Windows 
>>>>>>>>>> with C2,
>>>>>>>>>> 68k is the minimum, so an error is produced since the stack 
>>>>>>>>>> will only
>>>>>>>>>> be 64k. There is no bug here. It's just a bit confusing.
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>>
>>>>>>>>>> Chris
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>



From dl at cs.oswego.edu  Wed Dec  3 22:15:32 2014
From: dl at cs.oswego.edu (Doug Lea)
Date: Wed, 03 Dec 2014 17:15:32 -0500
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <CA+kOe08vnvXtDE_Xv+6iqtpBaRR3MpdeRV0OtksqMJ_aJpi9Dg@mail.gmail.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>	<547DEC01.2050501@gmail.com>	<547DF89A.2020809@oracle.com>	<CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>	<547F2BC1.6040904@cs.oswego.edu>	<CA+kOe0_h2EBbY51qh7MSUFpq44FpOspgtBVF6qVWENMwW2O0xA@mail.gmail.com>	<547F4A9D.3060805@cs.oswego.edu>
	<CA+kOe08vnvXtDE_Xv+6iqtpBaRR3MpdeRV0OtksqMJ_aJpi9Dg@mail.gmail.com>
Message-ID: <547F8B84.6090301@cs.oswego.edu>

On 12/03/2014 02:03 PM, Martin Buchholz wrote:
> On Wed, Dec 3, 2014 at 9:38 AM, Doug Lea <dl at cs.oswego.edu> wrote:
>> ... Of the two choices, housing the code in ThreadLocalRandom
>> seems logistically a bit easier. Then SplittableRandom could use
>>
>>   private static final AtomicLong defaultGen =
>>     new AtomicLong(ThreadLocalRandom.current().nextLong());
>>
> Oh, I think I see - you're saying we don't need a new public API,
> because ThreadLocalRandom.current() is already exactly the source of
> random seed what we want?

No public API because systemSeed need only be implemented
inside TLR, for its initial seed. Then the others can get their seeds
using ThreadLocalRandom.current().nextLong(), unless
java.util.secureRandomSeed is set (which I didn't illustrate above).
In other words, across all non-secure generators, you only need
one system-generated seed.

-Doug



From daniel.fuchs at oracle.com  Wed Dec  3 22:47:30 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 03 Dec 2014 23:47:30 +0100
Subject: [9 + 8u] RFR - 8066612: Add a test that will call getDeclaredFields()
	on all classes and try to set them accessible.
Message-ID: <547F9302.3060309@oracle.com>

Hi,

This is a review for a new test which has a different
implementation for JDK 8 & JDK 9

During the review of
JDK-8065552: setAccessible(true) on fields of Class may throw
              a SecurityException,
it was remarked that such a test would be useful.

So here is such a test that loads all classes from the BCL, calls
getDeclaredFields() for each of them, and attempt to set
each field to accessible.
On JDK 8 and JDK 9 this is quite fast (~ 3.2sec when a security
manager is on).

The differences between 8 & 9 are limited to:

    - ClassLoader:
         - on 8 we use 'null' (BCL)
         - on 9 we use the system class loader.

    - Building the stream of class names:
         - on 8 we have jars & folders in the boot class path
         - on 9 we have .jimage files


webrev jdk8:
http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8.00/

webrev jdk9:
http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/


best regards,

-- daniel

PS: For the curious I have also experimented with a version of this
test for JDK 7u [1] (where Streams have been replaced by Lists).
On 7 you need to either increase the PermGen size or split the
test into several invocations (the method I chose in [1]).

[1] don't review the link below - it's just for the record
     if/when someone wants to backport on 7u...
http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00


From stuart.marks at oracle.com  Wed Dec  3 23:27:09 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 03 Dec 2014 15:27:09 -0800
Subject: RFR(s): 8035001: TEST_BUG: the retry logic in RMID.start() should
	check that the subprocess hasn't terminated
Message-ID: <547F9C4D.4080306@oracle.com>

Hi all,

Moar RMI test cleanups!

The main issue is that the timing loop that waits for rmid to start will now 
check to make sure the process hasn't exited prematurely.

I've also taken the opportunity to simplify this and other timing loops in the 
RMI test library and to make their elapsed-time output more consistent.

Webrev:

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

Bug:

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

thanks,

s'marks


From martinrb at google.com  Wed Dec  3 23:32:12 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 3 Dec 2014 15:32:12 -0800
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <547F8B84.6090301@cs.oswego.edu>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>
	<547DEC01.2050501@gmail.com> <547DF89A.2020809@oracle.com>
	<CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>
	<547F2BC1.6040904@cs.oswego.edu>
	<CA+kOe0_h2EBbY51qh7MSUFpq44FpOspgtBVF6qVWENMwW2O0xA@mail.gmail.com>
	<547F4A9D.3060805@cs.oswego.edu>
	<CA+kOe08vnvXtDE_Xv+6iqtpBaRR3MpdeRV0OtksqMJ_aJpi9Dg@mail.gmail.com>
	<547F8B84.6090301@cs.oswego.edu>
Message-ID: <CA+kOe0_D0yxDEWq4DNQN_DL-yv-+Am3gFx_Foq-G63BDkrSHuQ@mail.gmail.com>

On Wed, Dec 3, 2014 at 2:15 PM, Doug Lea <dl at cs.oswego.edu> wrote:

> No public API because systemSeed need only be implemented
> inside TLR, for its initial seed. Then the others can get their seeds
> using ThreadLocalRandom.current().nextLong(), unless
> java.util.secureRandomSeed is set (which I didn't illustrate above).
> In other words, across all non-secure generators, you only need
> one system-generated seed.

That's good enough for seeding other non-cryptographically secure
PRNGs, but if you want each caller to get a
cryptographically secure random number, you need to avoid correlations
between them that would arise when you use a non-CS PRNG to generate
them from a single CS seed.


From lance.andersen at oracle.com  Wed Dec  3 23:54:01 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 3 Dec 2014 18:54:01 -0500
Subject: RFR(s): 8035001: TEST_BUG: the retry logic in RMID.start() should
	check that the subprocess hasn't terminated
In-Reply-To: <547F9C4D.4080306@oracle.com>
References: <547F9C4D.4080306@oracle.com>
Message-ID: <4AB13D56-4FCF-4F20-82C2-AAC6EDE4B5CF@oracle.com>

Hi Stuart,

This looks ok to me

Best,
Lance
On Dec 3, 2014, at 6:27 PM, Stuart Marks <stuart.marks at oracle.com> wrote:

> Hi all,
> 
> Moar RMI test cleanups!
> 
> The main issue is that the timing loop that waits for rmid to start will now check to make sure the process hasn't exited prematurely.
> 
> I've also taken the opportunity to simplify this and other timing loops in the RMI test library and to make their elapsed-time output more consistent.
> 
> Webrev:
> 
> 	http://cr.openjdk.java.net/~smarks/reviews/8035001/webrev.0/
> 
> Bug:
> 
> 	https://bugs.openjdk.java.net/browse/JDK-8035001
> 
> thanks,
> 
> s'marks



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





From david.holmes at oracle.com  Thu Dec  4 03:16:30 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 04 Dec 2014 13:16:30 +1000
Subject: [8u60] RFR: 8038189: Add cross-platform compact profiles support
In-Reply-To: <547D3F09.5010308@oracle.com>
References: <547BB1C4.1000303@oracle.com> <547C3296.8000000@oracle.com>
	<547D3F09.5010308@oracle.com>
Message-ID: <547FD20E.9020604@oracle.com>

Updated webrev:

http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk.v2/

Only changes are to profile-includes.txt.

Thanks,
David

On 2/12/2014 2:24 PM, David Holmes wrote:
> Erik,
>
> Many thanks for the makefile macro wizardry! I will incorporate, test
> and return with an updated webreb.
>
> David
>
> On 1/12/2014 7:19 PM, Erik Joelsson wrote:
>> Hello David,
>>
>> Most of it looks good, but profile-includes.txt could certainly benefit
>> from some reduction in duplication. (Aside from the extension of the
>> file itself, which I find a bit weird, but it's already there.) The two
>> common structures that I can see are:
>> 1. Expanding debuginfo files for macosx.
>> 2. Assigning/expanding libraries to the correct variable.
>>
>> For macosx debuginfo expanding, I would define a macro to something like
>> this:
>>
>> # Expand the contents of the .dSYM directories on macosx.
>> # Param 1 - debug files list
>> # Param 2 - libraries list
>> define expand-debuginfo
>>    $(if $(and $(filter-out true, $(ZIP_DEBUGINFO_FILES)), $(filter
>> macosx, $(OPENJDK_TARGET_OS))), \
>>        $(foreach i, $1, $(addsuffix /Contents/Info.plist, $i)) \
>>            $(foreach i, $2, $(addsuffix /Contents/Resources/DWARF/$i,
>> $(filter $i.%, $1))), \
>>        $1)
>> endef
>>
>> And use it like this:
>>
>> PROFILE_1_DEBUG_FILES := $(call expand-debuginfo,
>> $(PROFILE_1_DEBUG_FILES), $(PROFILE_1_LIBRARIES))
>>
>> Filtering out jsig can be done on the parameters at the macro call.
>>
>> For the conditional addprefix of OPENJDK_TARGET_CPU_LEGACY_LIB, I would
>> do something like:
>>
>> ifeq (, $(findstring $(OPENJDK_TARGET_OS), windows macosx))
>>    LIB_SUBDIR := $(OPENJDK_TARGET_CPU_LEGACY_LIB)/
>> else
>>    LIB_SUBDIR :=
>> endif
>>
>> And then always assign PROFILE_*_JRE_LIB_FILES with $(addprefix
>> $(LIB_SUBDIR), ...). The conditional on Windows for assigning to
>> ...BIN_FILES or ...LIB_FILES I would leave in place since I don't think
>> a macro solution would make it easier to understand.
>>
>> /Erik
>>
>>
>> On 2014-12-01 01:09, David Holmes wrote:
>>> Main bug is 8038189 but that is a closed bug, the open backport issue
>>> is:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8066200
>>>
>>> Compact Profiles support was added in 8, but only for the Linux
>>> platform. I've now generalized this support to all the other
>>> platforms. This is an 8u only change, targetting 8u60, as soon as the
>>> jdk8u/dev starts accepting things for 8u60.
>>>
>>> The changes are not that extensive - mostly generalizing the lists and
>>> accounting for different platforms putting files into different places
>>> (jre/lib/<arch> vs jre/lib vs jre/bin). It isn't necessary to produce
>>> detailed per-platform lists as files that don't exist simply don't get
>>> copied; but when files are obviously platform specific then I add them
>>> under suitable guards.
>>>
>>> The biggest complexity comes from the debuginfo files, and in
>>> particular unzipped debuginfo files. This accounts for the bulk of the
>>> changes in profiles-includes.txt, as we try to identify the set of
>>> debug files that might exist for each library (and OSX is the main
>>> complication due to the .dSYM directory because the existing rules
>>> only copy files not directories). Suggestions for reducing the
>>> duplicated patterns would be appreciated.
>>>
>>> Platform specific contents were determined in conjunction with
>>> examination of what Jigsaw is using in JDK 9 for the base module.
>>>
>>> I tested all the main platforms (Windows, Linux, Solaris and OSX) and
>>> with/without zipping of debuginfo files. Note that Windows builds will
>>> not work with unzipped debuginfo files due to 8025936, but I checked
>>> that multiple debug info files were expanded into the right set of
>>> targets.
>>>
>>> webrevs:
>>>
>>> http://cr.openjdk.java.net/~dholmes/8038189/webrev.top/
>>>
>>> make/Main.gmk:
>>>  - Remove the os-check that constrained profiles to linux
>>>
>>> http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk/
>>>
>>> make/CreateJars.gmk:
>>>  - Check for empty variables (Solaris doesn't like them)
>>>  - Fix # # comments
>>>  - Add explicit targets for the beanless classes with $ in them (the %
>>> substitution doesn't work on all platforms when $ is also present)
>>>
>>> make/Images.gmk
>>>  - Don't filter out server VM from compact profiles
>>>
>>> make/Import.gmk
>>>  - Add Info.plist to the exported files (for unzipped debuginfo files
>>> - this is a general fix not profiles specific so may warrant its own CR)
>>>
>>> make/Profiles.gmk
>>>  - Remove linux-only comment
>>>
>>> make/Tools.gmk
>>>  - Fix tool definitions to use $(PATH_SEP) and quote cp entries
>>>
>>> make/profile-includes.txt
>>>  - Bulk of changes as described above
>>>
>>> make/profile-rtjar-includes.txt
>>>  - Additional packages that exist on OSX only (but don't need to be
>>> conditionally added)
>>>  - NOTE: if AIX or other platform add platform specific packages not
>>> already included by an enclosing package, then they will also need to
>>> be added
>>>
>>> Thanks,
>>> David
>>


From david.holmes at oracle.com  Thu Dec  4 03:37:22 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 04 Dec 2014 13:37:22 +1000
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <547F9302.3060309@oracle.com>
References: <547F9302.3060309@oracle.com>
Message-ID: <547FD6F2.5060400@oracle.com>

Hi Daniel,

Once clarification please ...

On 4/12/2014 8:47 AM, Daniel Fuchs wrote:
> Hi,
>
> This is a review for a new test which has a different
> implementation for JDK 8 & JDK 9
>
> During the review of
> JDK-8065552: setAccessible(true) on fields of Class may throw
>               a SecurityException,
> it was remarked that such a test would be useful.
>
> So here is such a test that loads all classes from the BCL, calls
> getDeclaredFields() for each of them, and attempt to set
> each field to accessible.
> On JDK 8 and JDK 9 this is quite fast (~ 3.2sec when a security
> manager is on).
>
> The differences between 8 & 9 are limited to:
>
>     - ClassLoader:
>          - on 8 we use 'null' (BCL)
>          - on 9 we use the system class loader.

I haven't seen anything in JEP 220, regarding modules, that indicates 
that classes currently loaded  by the boot-loader will now be loaded by 
the system classloader ???

Thanks,
David

>     - Building the stream of class names:
>          - on 8 we have jars & folders in the boot class path
>          - on 9 we have .jimage files
>
>
> webrev jdk8:
> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8.00/
>
> webrev jdk9:
> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/
>
>
> best regards,
>
> -- daniel
>
> PS: For the curious I have also experimented with a version of this
> test for JDK 7u [1] (where Streams have been replaced by Lists).
> On 7 you need to either increase the PermGen size or split the
> test into several invocations (the method I chose in [1]).
>
> [1] don't review the link below - it's just for the record
>      if/when someone wants to backport on 7u...
> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00


From nathan.a.clement at hotmail.com  Thu Dec  4 06:18:03 2014
From: nathan.a.clement at hotmail.com (Nathan Clement)
Date: Thu, 4 Dec 2014 17:18:03 +1100
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw IOException
	if called twice and underlying flush or close fails
Message-ID: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>

Hi,

Here is my suggested fix for the FilterOuputStream issue in JDK-8054565.  I have been running this fix in my applications for several weeks (by adding it to the bootstrap classpath) and it solves my issue.  The fix creates a new member field to remember whether close has already been called on the stream, and if so, close() does nothing.

Attached is the output from hg diff -g

This is my first attempt at a patch for OpenJDK, so please let me know if I need to change anything.

Thanks,

Nathan
 		 	   		  

From joe.darcy at oracle.com  Thu Dec  4 07:18:48 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 03 Dec 2014 23:18:48 -0800
Subject: JDK 9 RFR of JDK-8066617: Suppress deprecation warnings in java.base
	module
Message-ID: <54800AD8.7080206@oracle.com>

Hello,

First some background, one of the JEPs targeted to JDK 9 is

     JEP 212: Resolve Lint and Doclint Warnings
     http://openjdk.java.net/jeps/212

In the jdk repository, only the deprecation category of lint warnings 
remain. While resolving the other categories of warnings mostly involved 
area-agnostic Java language expertise (say, to generify an API), fixing 
a deprecation warning by modifying code often involves very detailed 
area-specific knowledge. For that reason, to resolve the deprecation 
category of lint warnings, rather than updating the code per se, I'm 
only planning to @SuppressWarnings the issues. To track that work, I've 
filed the umbrella bug

     JDK-8066616: Suppress deprecation warnings in jdk libraries
     https://bugs.openjdk.java.net/browse/JDK-8066616

with subtasks for different modules in the build. I've also filed a 
sibling umbrella bug

     JDK-8066618: Fix deprecation warnings in jdk libraries
     https://bugs.openjdk.java.net/browse/JDK-8066618

which has a matching set of subtasks to have each deprecation location 
in the code be reexamined by someone familiar with the area.

With that background, first up is this review request for

     JDK-8066617: Suppress deprecation warnings in java.base module
     http://cr.openjdk.java.net/~darcy/8066617.0/

Thanks,

-Joe


From chris.plummer at oracle.com  Thu Dec  4 08:12:58 2014
From: chris.plummer at oracle.com (Chris Plummer)
Date: Thu, 04 Dec 2014 00:12:58 -0800
Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation
	fault
In-Reply-To: <547F0889.5050204@oracle.com>
References: <545D939D.2030308@oracle.com>
	<5463B896.10801@oracle.com>	<54641ADE.8030504@oracle.com>
	<546BC35E.4070402@oracle.com>	<546C5986.6010500@oracle.com>
	<546C6D1A.8050903@oracle.com>	<546CBCAB.7040101@oracle.com>
	<547D265A.20005@oracle.com> <547F0889.5050204@oracle.com>
Message-ID: <5480178A.9090709@oracle.com>

On 12/3/14 4:56 AM, Alan Bateman wrote:
> On 02/12/2014 02:39, Chris Plummer wrote:
>> Sorry about the long delay in getting back to this. I ran into two 
>> separate JPRT issues that were preventing me from testing these 
>> changes, plus I was on vacation last week. Here's an updated webrev. 
>> I'm not sure where we left things, so I'll just say what's changed 
>> since the original version:
>>
>> 1. Rewrote the test to be in Java instead of a shell script.
>> 2. Moved the test from hotspot/test/runtime/memory to 
>> jdk/test/tools/launcher
>> 3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to 
>> override the default 32k minimum value.
>>
>> https://bugs.openjdk.java.net/browse/JDK-6762191
>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/
> This looks to me. A minor comment for java.c is that this code uses 
> 4-space indent (different to hotspot).
>
> The test looks okay too, you might just checking the copyright date as 
> I assume was not written in 2010. Also I think the import of 
> java.io.File may be left behind from the previous round.
>
> -Alan
Hi Alan,

While removing the java.io.File import, I also questioned why I had 
java.io.IOException being imported. There were a couple of methods that 
declared it thrown, and the main method therefore had to catch it, but 
it turns out this was just copy/paste from the Settings.java test I used 
as a template, and is not actually needed. I removed the import, throws, 
and try/catch of IOException.

All the other issues mentioned by others have also been addressed. A new 
webrev can be found at:

http://cr.openjdk.java.net/~cjplummer/6762191/webrev.03/

thanks,

Chris


From peter.levart at gmail.com  Thu Dec  4 08:20:43 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 04 Dec 2014 09:20:43 +0100
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <CA+kOe0_D0yxDEWq4DNQN_DL-yv-+Am3gFx_Foq-G63BDkrSHuQ@mail.gmail.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>	<547DEC01.2050501@gmail.com>
	<547DF89A.2020809@oracle.com>	<CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>	<547F2BC1.6040904@cs.oswego.edu>	<CA+kOe0_h2EBbY51qh7MSUFpq44FpOspgtBVF6qVWENMwW2O0xA@mail.gmail.com>	<547F4A9D.3060805@cs.oswego.edu>	<CA+kOe08vnvXtDE_Xv+6iqtpBaRR3MpdeRV0OtksqMJ_aJpi9Dg@mail.gmail.com>	<547F8B84.6090301@cs.oswego.edu>
	<CA+kOe0_D0yxDEWq4DNQN_DL-yv-+Am3gFx_Foq-G63BDkrSHuQ@mail.gmail.com>
Message-ID: <5480195B.4070800@gmail.com>

On 12/04/2014 12:32 AM, Martin Buchholz wrote:
> On Wed, Dec 3, 2014 at 2:15 PM, Doug Lea <dl at cs.oswego.edu> wrote:
>
>> No public API because systemSeed need only be implemented
>> inside TLR, for its initial seed. Then the others can get their seeds
>> using ThreadLocalRandom.current().nextLong(), unless
>> java.util.secureRandomSeed is set (which I didn't illustrate above).
>> In other words, across all non-secure generators, you only need
>> one system-generated seed.
> That's good enough for seeding other non-cryptographically secure
> PRNGs, but if you want each caller to get a
> cryptographically secure random number, you need to avoid correlations
> between them that would arise when you use a non-CS PRNG to generate
> them from a single CS seed.

Unless java.util.Random is retrofitted to allocate new cryptographically 
secure seed for each new instance. In such case expression:

     new java.util.Random().nextLong()

...could be used to gather secure seed. Perhaps even SplittableRandom 
could allocate new seed from secure source for each new instance (only 
in public constructor - not when it is split()ed)...

What makes those workarounds unsuitable is failure mode. Gathering 
secure seed is inherently coupled with possible failure which must be 
communicated explicitly to the consumer. But one must not be bothered 
with failure in situations where security is not a necessary ingredient.

So for  non-CS PRNGs, cross-seeding is a possible solution, but it's 
nicer for all of them to just use a common (internal) API.

As far as public API is concerned, there already is one: 
SecureRandom.generateSeed(). It's as good as SystemRandom (uses same 
primary means) and has a nice cross-platform fallback 
(ThreadedSeedGenerator). It's only drawback is that it comes with all 
the baggage of security providers (Java and MS Crypto API on Windows). 
But that's ok for user code perhaps.

So what we have here is two desires:
- we want a resource-friendly / with as little dependencies as possible 
way to generate some unique seed, with implicit fall-back which need not 
be secure
- we want a resource-friendly / with as little dependencies as possible 
way to generate secure random bytes that can be pseudo-random, but still 
secure, with explicit failure mode

I'll try to address this dichotomy in the next iteration of the API.

Regards, Peter

P.S. Is anyone interested in generating truly random bytes?

http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf

https://software.intel.com/en-us/tags/35970



From peter.levart at gmail.com  Thu Dec  4 08:34:25 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 04 Dec 2014 09:34:25 +0100
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <5480195B.4070800@gmail.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>	<547DEC01.2050501@gmail.com>
	<547DF89A.2020809@oracle.com>	<CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>	<547F2BC1.6040904@cs.oswego.edu>	<CA+kOe0_h2EBbY51qh7MSUFpq44FpOspgtBVF6qVWENMwW2O0xA@mail.gmail.com>	<547F4A9D.3060805@cs.oswego.edu>	<CA+kOe08vnvXtDE_Xv+6iqtpBaRR3MpdeRV0OtksqMJ_aJpi9Dg@mail.gmail.com>	<547F8B84.6090301@cs.oswego.edu>
	<CA+kOe0_D0yxDEWq4DNQN_DL-yv-+Am3gFx_Foq-G63BDkrSHuQ@mail.gmail.com>
	<5480195B.4070800@gmail.com>
Message-ID: <54801C91.80305@gmail.com>

On 12/04/2014 09:20 AM, Peter Levart wrote:
> P.S. Is anyone interested in generating truly random bytes?
>
> http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf
>
> https://software.intel.com/en-us/tags/35970

Maybe not a good idea:

http://en.wikipedia.org/wiki/RdRand#Reception




From erik.joelsson at oracle.com  Thu Dec  4 08:53:28 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 04 Dec 2014 09:53:28 +0100
Subject: [8u60] RFR: 8038189: Add cross-platform compact profiles support
In-Reply-To: <547FD20E.9020604@oracle.com>
References: <547BB1C4.1000303@oracle.com> <547C3296.8000000@oracle.com>
	<547D3F09.5010308@oracle.com> <547FD20E.9020604@oracle.com>
Message-ID: <54802108.5030300@oracle.com>

Looks good to me.

/Erik

On 2014-12-04 04:16, David Holmes wrote:
> Updated webrev:
>
> http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk.v2/
>
> Only changes are to profile-includes.txt.
>
> Thanks,
> David
>
> On 2/12/2014 2:24 PM, David Holmes wrote:
>> Erik,
>>
>> Many thanks for the makefile macro wizardry! I will incorporate, test
>> and return with an updated webreb.
>>
>> David
>>
>> On 1/12/2014 7:19 PM, Erik Joelsson wrote:
>>> Hello David,
>>>
>>> Most of it looks good, but profile-includes.txt could certainly benefit
>>> from some reduction in duplication. (Aside from the extension of the
>>> file itself, which I find a bit weird, but it's already there.) The two
>>> common structures that I can see are:
>>> 1. Expanding debuginfo files for macosx.
>>> 2. Assigning/expanding libraries to the correct variable.
>>>
>>> For macosx debuginfo expanding, I would define a macro to something 
>>> like
>>> this:
>>>
>>> # Expand the contents of the .dSYM directories on macosx.
>>> # Param 1 - debug files list
>>> # Param 2 - libraries list
>>> define expand-debuginfo
>>>    $(if $(and $(filter-out true, $(ZIP_DEBUGINFO_FILES)), $(filter
>>> macosx, $(OPENJDK_TARGET_OS))), \
>>>        $(foreach i, $1, $(addsuffix /Contents/Info.plist, $i)) \
>>>            $(foreach i, $2, $(addsuffix /Contents/Resources/DWARF/$i,
>>> $(filter $i.%, $1))), \
>>>        $1)
>>> endef
>>>
>>> And use it like this:
>>>
>>> PROFILE_1_DEBUG_FILES := $(call expand-debuginfo,
>>> $(PROFILE_1_DEBUG_FILES), $(PROFILE_1_LIBRARIES))
>>>
>>> Filtering out jsig can be done on the parameters at the macro call.
>>>
>>> For the conditional addprefix of OPENJDK_TARGET_CPU_LEGACY_LIB, I would
>>> do something like:
>>>
>>> ifeq (, $(findstring $(OPENJDK_TARGET_OS), windows macosx))
>>>    LIB_SUBDIR := $(OPENJDK_TARGET_CPU_LEGACY_LIB)/
>>> else
>>>    LIB_SUBDIR :=
>>> endif
>>>
>>> And then always assign PROFILE_*_JRE_LIB_FILES with $(addprefix
>>> $(LIB_SUBDIR), ...). The conditional on Windows for assigning to
>>> ...BIN_FILES or ...LIB_FILES I would leave in place since I don't think
>>> a macro solution would make it easier to understand.
>>>
>>> /Erik
>>>
>>>
>>> On 2014-12-01 01:09, David Holmes wrote:
>>>> Main bug is 8038189 but that is a closed bug, the open backport issue
>>>> is:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8066200
>>>>
>>>> Compact Profiles support was added in 8, but only for the Linux
>>>> platform. I've now generalized this support to all the other
>>>> platforms. This is an 8u only change, targetting 8u60, as soon as the
>>>> jdk8u/dev starts accepting things for 8u60.
>>>>
>>>> The changes are not that extensive - mostly generalizing the lists and
>>>> accounting for different platforms putting files into different places
>>>> (jre/lib/<arch> vs jre/lib vs jre/bin). It isn't necessary to produce
>>>> detailed per-platform lists as files that don't exist simply don't get
>>>> copied; but when files are obviously platform specific then I add them
>>>> under suitable guards.
>>>>
>>>> The biggest complexity comes from the debuginfo files, and in
>>>> particular unzipped debuginfo files. This accounts for the bulk of the
>>>> changes in profiles-includes.txt, as we try to identify the set of
>>>> debug files that might exist for each library (and OSX is the main
>>>> complication due to the .dSYM directory because the existing rules
>>>> only copy files not directories). Suggestions for reducing the
>>>> duplicated patterns would be appreciated.
>>>>
>>>> Platform specific contents were determined in conjunction with
>>>> examination of what Jigsaw is using in JDK 9 for the base module.
>>>>
>>>> I tested all the main platforms (Windows, Linux, Solaris and OSX) and
>>>> with/without zipping of debuginfo files. Note that Windows builds will
>>>> not work with unzipped debuginfo files due to 8025936, but I checked
>>>> that multiple debug info files were expanded into the right set of
>>>> targets.
>>>>
>>>> webrevs:
>>>>
>>>> http://cr.openjdk.java.net/~dholmes/8038189/webrev.top/
>>>>
>>>> make/Main.gmk:
>>>>  - Remove the os-check that constrained profiles to linux
>>>>
>>>> http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk/
>>>>
>>>> make/CreateJars.gmk:
>>>>  - Check for empty variables (Solaris doesn't like them)
>>>>  - Fix # # comments
>>>>  - Add explicit targets for the beanless classes with $ in them (the %
>>>> substitution doesn't work on all platforms when $ is also present)
>>>>
>>>> make/Images.gmk
>>>>  - Don't filter out server VM from compact profiles
>>>>
>>>> make/Import.gmk
>>>>  - Add Info.plist to the exported files (for unzipped debuginfo files
>>>> - this is a general fix not profiles specific so may warrant its 
>>>> own CR)
>>>>
>>>> make/Profiles.gmk
>>>>  - Remove linux-only comment
>>>>
>>>> make/Tools.gmk
>>>>  - Fix tool definitions to use $(PATH_SEP) and quote cp entries
>>>>
>>>> make/profile-includes.txt
>>>>  - Bulk of changes as described above
>>>>
>>>> make/profile-rtjar-includes.txt
>>>>  - Additional packages that exist on OSX only (but don't need to be
>>>> conditionally added)
>>>>  - NOTE: if AIX or other platform add platform specific packages not
>>>> already included by an enclosing package, then they will also need to
>>>> be added
>>>>
>>>> Thanks,
>>>> David
>>>



From daniel.fuchs at oracle.com  Thu Dec  4 09:05:20 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 04 Dec 2014 10:05:20 +0100
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <547FD6F2.5060400@oracle.com>
References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com>
Message-ID: <548023D0.4020702@oracle.com>

Hi David,

On 12/4/14 4:37 AM, David Holmes wrote:
> Hi Daniel,
>
> Once clarification please ...
>
> On 4/12/2014 8:47 AM, Daniel Fuchs wrote:
>> Hi,
>>
>> This is a review for a new test which has a different
>> implementation for JDK 8 & JDK 9
>>
>> During the review of
>> JDK-8065552: setAccessible(true) on fields of Class may throw
>>               a SecurityException,
>> it was remarked that such a test would be useful.
>>
>> So here is such a test that loads all classes from the BCL, calls
>> getDeclaredFields() for each of them, and attempt to set
>> each field to accessible.
>> On JDK 8 and JDK 9 this is quite fast (~ 3.2sec when a security
>> manager is on).
>>
>> The differences between 8 & 9 are limited to:
>>
>>     - ClassLoader:
>>          - on 8 we use 'null' (BCL)
>>          - on 9 we use the system class loader.
>
> I haven't seen anything in JEP 220, regarding modules, that indicates 
> that classes currently loaded  by the boot-loader will now be loaded 
> by the system classloader ???

In [1] towards the end:

[1] http://openjdk.java.net/jeps/220

"The defining class loader of the types in some existing packages
  will change. Existing code that makes assumptions about the class
  loaders of these types might not work correctly."
  (then there is a list of specific changes).

This test looks up all class names in the image files and attempt
to load the corresponding class. But as indicated in [1]
some of these classes are now in the Boot CL, some in the
Extension CL, and some in the Application CL.

So the test uses the System CL to load each class - which ensures
that the loading will be delegated to the appropriate ClassLoader.

best regards,

-- daniel

>
> Thanks,
> David
>
>>     - Building the stream of class names:
>>          - on 8 we have jars & folders in the boot class path
>>          - on 9 we have .jimage files
>>
>>
>> webrev jdk8:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8.00/
>>
>> webrev jdk9:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/
>>
>>
>> best regards,
>>
>> -- daniel
>>
>> PS: For the curious I have also experimented with a version of this
>> test for JDK 7u [1] (where Streams have been replaced by Lists).
>> On 7 you need to either increase the PermGen size or split the
>> test into several invocations (the method I chose in [1]).
>>
>> [1] don't review the link below - it's just for the record
>>      if/when someone wants to backport on 7u...
>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00



From paul.sandoz at oracle.com  Thu Dec  4 09:40:22 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 4 Dec 2014 10:40:22 +0100
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <5480195B.4070800@gmail.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>	<547DEC01.2050501@gmail.com>
	<547DF89A.2020809@oracle.com>	<CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>	<547F2BC1.6040904@cs.oswego.edu>	<CA+kOe0_h2EBbY51qh7MSUFpq44FpOspgtBVF6qVWENMwW2O0xA@mail.gmail.com>	<547F4A9D.3060805@cs.oswego.edu>	<CA+kOe08vnvXtDE_Xv+6iqtpBaRR3MpdeRV0OtksqMJ_aJpi9Dg@mail.gmail.com>	<547F8B84.6090301@cs.oswego.edu>
	<CA+kOe0_D0yxDEWq4DNQN_DL-yv-+Am3gFx_Foq-G63BDkrSHuQ@mail.gmail.com>
	<5480195B.4070800@gmail.com>
Message-ID: <F498D1ED-6C4B-4F5B-8F82-036715009EEC@oracle.com>

Hi,

I think we may be over-rotating a little on this.

There is already a mechanism to create a cryptographically strong seed by setting a system property and using SecureRandom. That has a high initialization cost, but i think under those circumstances that cost is acceptable (it may well be possible to reduce that cost but i consider that to be a separate issue).

For the default case what we need is something with low initialization cost that is *good enough* for the majority of cases e.g. documents the lower bound of cryptographic strength.

I like Doug's approach to hide this under TLR, i think that fits well with the "good enough" aspect (cross seeding can be documented as an @implNote). But I still marginally prefer a public static method as well, and SecureRandom seems an appropriate choice (although it could easily be exposed on System or Runtime).

Paul.

On Dec 4, 2014, at 9:20 AM, Peter Levart <peter.levart at gmail.com> wrote:

> On 12/04/2014 12:32 AM, Martin Buchholz wrote:
>> On Wed, Dec 3, 2014 at 2:15 PM, Doug Lea <dl at cs.oswego.edu> wrote:
>> 
>>> No public API because systemSeed need only be implemented
>>> inside TLR, for its initial seed. Then the others can get their seeds
>>> using ThreadLocalRandom.current().nextLong(), unless
>>> java.util.secureRandomSeed is set (which I didn't illustrate above).
>>> In other words, across all non-secure generators, you only need
>>> one system-generated seed.
>> That's good enough for seeding other non-cryptographically secure
>> PRNGs, but if you want each caller to get a
>> cryptographically secure random number, you need to avoid correlations
>> between them that would arise when you use a non-CS PRNG to generate
>> them from a single CS seed.
> 
> Unless java.util.Random is retrofitted to allocate new cryptographically secure seed for each new instance. In such case expression:
> 
>    new java.util.Random().nextLong()
> 
> ...could be used to gather secure seed. Perhaps even SplittableRandom could allocate new seed from secure source for each new instance (only in public constructor - not when it is split()ed)...
> 
> What makes those workarounds unsuitable is failure mode. Gathering secure seed is inherently coupled with possible failure which must be communicated explicitly to the consumer. But one must not be bothered with failure in situations where security is not a necessary ingredient.
> 
> So for  non-CS PRNGs, cross-seeding is a possible solution, but it's nicer for all of them to just use a common (internal) API.
> 
> As far as public API is concerned, there already is one: SecureRandom.generateSeed(). It's as good as SystemRandom (uses same primary means) and has a nice cross-platform fallback (ThreadedSeedGenerator). It's only drawback is that it comes with all the baggage of security providers (Java and MS Crypto API on Windows). But that's ok for user code perhaps.
> 
> So what we have here is two desires:
> - we want a resource-friendly / with as little dependencies as possible way to generate some unique seed, with implicit fall-back which need not be secure
> - we want a resource-friendly / with as little dependencies as possible way to generate secure random bytes that can be pseudo-random, but still secure, with explicit failure mode
> 
> I'll try to address this dichotomy in the next iteration of the API.
> 
> Regards, Peter
> 
> P.S. Is anyone interested in generating truly random bytes?
> 
> http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf
> 
> https://software.intel.com/en-us/tags/35970
> 



From daniel.fuchs at oracle.com  Thu Dec  4 11:38:43 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 04 Dec 2014 12:38:43 +0100
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <548023D0.4020702@oracle.com>
References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com>
	<548023D0.4020702@oracle.com>
Message-ID: <548047C3.8000400@oracle.com>

Hi David,

In fact I could use 'null' on JDK 9 as well.
My first version of the JDK 9 test was parsing over all the .jimage
files under <jdk>/lib/modules - which explain why I needed to
use the System class loader.

Then I switched to only parsing the bootmodules.jimage - because
I noticed that the results where more coherent with what I had
observed on 8 & 7 - but I kept using the System class loader.

I am not sure whether we want the test for 9 should iterate over
the three .jimage - or continue to test only the boot .jimage.

I have updated the JDK 9 test (refreshed the webrev in place)
http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/
and added support for possibly running the test in the two modes
(I added a 'test.boot.only' system property, true by default)
as well as additional traces to print the loaded classes by
defining loader at the end (test.list.classes, false by default).

Thanks for your question, it triggered me into looking deeper
into what was happening :-)

best regards,

-- daniel

On 04/12/14 10:05, Daniel Fuchs wrote:
>>> The differences between 8 & 9 are limited to:
>>>
>>>     - ClassLoader:
>>>          - on 8 we use 'null' (BCL)
>>>          - on 9 we use the system class loader.
>>
>> I haven't seen anything in JEP 220, regarding modules, that indicates
>> that classes currently loaded  by the boot-loader will now be loaded
>> by the system classloader ???
>
> In [1] towards the end:
>
> [1] http://openjdk.java.net/jeps/220
>
> "The defining class loader of the types in some existing packages
>   will change. Existing code that makes assumptions about the class
>   loaders of these types might not work correctly."
>   (then there is a list of specific changes).
>
> This test looks up all class names in the image files and attempt
> to load the corresponding class. But as indicated in [1]
> some of these classes are now in the Boot CL, some in the
> Extension CL, and some in the Application CL.
>
> So the test uses the System CL to load each class - which ensures
> that the loading will be delegated to the appropriate ClassLoader.
>
> best regards,
>
> -- daniel



From david.holmes at oracle.com  Thu Dec  4 11:50:28 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 04 Dec 2014 21:50:28 +1000
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <548023D0.4020702@oracle.com>
References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com>
	<548023D0.4020702@oracle.com>
Message-ID: <54804A84.8040504@oracle.com>

Hi Daniel,

On 4/12/2014 7:05 PM, Daniel Fuchs wrote:
> On 12/4/14 4:37 AM, David Holmes wrote:
>>
>> Once clarification please ...
>>
>> On 4/12/2014 8:47 AM, Daniel Fuchs wrote:
>>> Hi,
>>>
>>> This is a review for a new test which has a different
>>> implementation for JDK 8 & JDK 9
>>>
>>> During the review of
>>> JDK-8065552: setAccessible(true) on fields of Class may throw
>>>               a SecurityException,
>>> it was remarked that such a test would be useful.
>>>
>>> So here is such a test that loads all classes from the BCL, calls
>>> getDeclaredFields() for each of them, and attempt to set
>>> each field to accessible.
>>> On JDK 8 and JDK 9 this is quite fast (~ 3.2sec when a security
>>> manager is on).
>>>
>>> The differences between 8 & 9 are limited to:
>>>
>>>     - ClassLoader:
>>>          - on 8 we use 'null' (BCL)
>>>          - on 9 we use the system class loader.
>>
>> I haven't seen anything in JEP 220, regarding modules, that indicates
>> that classes currently loaded  by the boot-loader will now be loaded
>> by the system classloader ???
>
> In [1] towards the end:
>
> [1] http://openjdk.java.net/jeps/220
>
> "The defining class loader of the types in some existing packages
>   will change. Existing code that makes assumptions about the class
>   loaders of these types might not work correctly."
>   (then there is a list of specific changes).
>
> This test looks up all class names in the image files and attempt
> to load the corresponding class. But as indicated in [1]
> some of these classes are now in the Boot CL, some in the
> Extension CL, and some in the Application CL.

Yes but that is a small set of specific types. The boot classes are 
still loaded by the boot loader.

> So the test uses the System CL to load each class - which ensures
> that the loading will be delegated to the appropriate ClassLoader.

It wasn't the use of the system loader to load the classes that I was 
concerned about but the check whether cls.getClassLoader() was the 
system loader - as it would not be for the boot classes.

David

> best regards,
>
> -- daniel
>
>>
>> Thanks,
>> David
>>
>>>     - Building the stream of class names:
>>>          - on 8 we have jars & folders in the boot class path
>>>          - on 9 we have .jimage files
>>>
>>>
>>> webrev jdk8:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8.00/
>>>
>>> webrev jdk9:
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/
>>>
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> PS: For the curious I have also experimented with a version of this
>>> test for JDK 7u [1] (where Streams have been replaced by Lists).
>>> On 7 you need to either increase the PermGen size or split the
>>> test into several invocations (the method I chose in [1]).
>>>
>>> [1] don't review the link below - it's just for the record
>>>      if/when someone wants to backport on 7u...
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00
>


From david.holmes at oracle.com  Thu Dec  4 12:06:35 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 04 Dec 2014 22:06:35 +1000
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <548047C3.8000400@oracle.com>
References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com>
	<548023D0.4020702@oracle.com> <548047C3.8000400@oracle.com>
Message-ID: <54804E4B.2070908@oracle.com>

Hi Daniel,

On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
> Hi David,
>
> In fact I could use 'null' on JDK 9 as well.
> My first version of the JDK 9 test was parsing over all the .jimage
> files under <jdk>/lib/modules - which explain why I needed to
> use the System class loader.
>
> Then I switched to only parsing the bootmodules.jimage - because
> I noticed that the results where more coherent with what I had
> observed on 8 & 7 - but I kept using the System class loader.
>
> I am not sure whether we want the test for 9 should iterate over
> the three .jimage - or continue to test only the boot .jimage.
>
> I have updated the JDK 9 test (refreshed the webrev in place)
> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/
> and added support for possibly running the test in the two modes
> (I added a 'test.boot.only' system property, true by default)
> as well as additional traces to print the loaded classes by
> defining loader at the end (test.list.classes, false by default).

A couple of initial comments:

  104     static ClassLoader getClassLoaderFor(String classFileName) {
  105         if (restrictToBoot) return null; // only bootmodules
  106         return ClassLoaders.systemClassLoader;
  107     }

I'm not clear the intent here. If it is to return a loader for which 
loadClass could be invoked then you can always just return the system 
loader - or just Class.forName. If it is meant to the return the 
expected defining loader then it isn't doing that as the extensions 
loader is not allowed for.

Similarly for:

  128         static ClassLoader getFor(String classFileName) {
  129             return systemClassLoader;
  130         }

Minor nit - In:

135                     System.err.println("Unexpected loader for "+c+": 
"+c.getClassLoader());

c.getClassLoader() can be replaced by cl. Also put spaces around the + 
operator.

David
(signing off for the night)

> Thanks for your question, it triggered me into looking deeper
> into what was happening :-)
>
> best regards,
>
> -- daniel
>
> On 04/12/14 10:05, Daniel Fuchs wrote:
>>>> The differences between 8 & 9 are limited to:
>>>>
>>>>     - ClassLoader:
>>>>          - on 8 we use 'null' (BCL)
>>>>          - on 9 we use the system class loader.
>>>
>>> I haven't seen anything in JEP 220, regarding modules, that indicates
>>> that classes currently loaded  by the boot-loader will now be loaded
>>> by the system classloader ???
>>
>> In [1] towards the end:
>>
>> [1] http://openjdk.java.net/jeps/220
>>
>> "The defining class loader of the types in some existing packages
>>   will change. Existing code that makes assumptions about the class
>>   loaders of these types might not work correctly."
>>   (then there is a list of specific changes).
>>
>> This test looks up all class names in the image files and attempt
>> to load the corresponding class. But as indicated in [1]
>> some of these classes are now in the Boot CL, some in the
>> Extension CL, and some in the Application CL.
>>
>> So the test uses the System CL to load each class - which ensures
>> that the loading will be delegated to the appropriate ClassLoader.
>>
>> best regards,
>>
>> -- daniel
>


From daniel.fuchs at oracle.com  Thu Dec  4 12:25:03 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 04 Dec 2014 13:25:03 +0100
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <54804E4B.2070908@oracle.com>
References: <547F9302.3060309@oracle.com> <547FD6F2.5060400@oracle.com>
	<548023D0.4020702@oracle.com> <548047C3.8000400@oracle.com>
	<54804E4B.2070908@oracle.com>
Message-ID: <5480529F.1020902@oracle.com>

On 04/12/14 13:06, David Holmes wrote:
> Hi Daniel,
>
> On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
>> Hi David,
>>
>> In fact I could use 'null' on JDK 9 as well.
>> My first version of the JDK 9 test was parsing over all the .jimage
>> files under <jdk>/lib/modules - which explain why I needed to
>> use the System class loader.
>>
>> Then I switched to only parsing the bootmodules.jimage - because
>> I noticed that the results where more coherent with what I had
>> observed on 8 & 7 - but I kept using the System class loader.
>>
>> I am not sure whether we want the test for 9 should iterate over
>> the three .jimage - or continue to test only the boot .jimage.
>>
>> I have updated the JDK 9 test (refreshed the webrev in place)
>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/
>> and added support for possibly running the test in the two modes
>> (I added a 'test.boot.only' system property, true by default)
>> as well as additional traces to print the loaded classes by
>> defining loader at the end (test.list.classes, false by default).
>
> A couple of initial comments:
>
>   104     static ClassLoader getClassLoaderFor(String classFileName) {
>   105         if (restrictToBoot) return null; // only bootmodules
>   106         return ClassLoaders.systemClassLoader;
>   107     }
>
> I'm not clear the intent here. If it is to return a loader for which
> loadClass could be invoked then you can always just return the system
> loader - or just Class.forName. If it is meant to the return the
> expected defining loader then it isn't doing that as the extensions
> loader is not allowed for.

The intent is to return the class loader that will be passed to
Class.forName( ). I've been fiddling & experimenting with this
test over 3 different platforms while trying to minimize the
differences - so that was my attempt at having a good place to
experiment with different strategy for loading classes.

> Similarly for:
>
>   128         static ClassLoader getFor(String classFileName) {
>   129             return systemClassLoader;
>   130         }

Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..)
was supposed to simply return ClassLoaders.getFor(...);
and all the code should be in ClassLoaders.getFor - my bad.

> Minor nit - In:
>
> 135                     System.err.println("Unexpected loader for "+c+":
> "+c.getClassLoader());
>
> c.getClassLoader() can be replaced by cl. Also put spaces around the +
> operator.

Good catch.

Thanks a lot David! Have a good night! (that's quite late - isn't it?)

-- daniel

>
> David
> (signing off for the night)
>
>> Thanks for your question, it triggered me into looking deeper
>> into what was happening :-)
>>
>> best regards,
>>
>> -- daniel
>>
>> On 04/12/14 10:05, Daniel Fuchs wrote:
>>>>> The differences between 8 & 9 are limited to:
>>>>>
>>>>>     - ClassLoader:
>>>>>          - on 8 we use 'null' (BCL)
>>>>>          - on 9 we use the system class loader.
>>>>
>>>> I haven't seen anything in JEP 220, regarding modules, that indicates
>>>> that classes currently loaded  by the boot-loader will now be loaded
>>>> by the system classloader ???
>>>
>>> In [1] towards the end:
>>>
>>> [1] http://openjdk.java.net/jeps/220
>>>
>>> "The defining class loader of the types in some existing packages
>>>   will change. Existing code that makes assumptions about the class
>>>   loaders of these types might not work correctly."
>>>   (then there is a list of specific changes).
>>>
>>> This test looks up all class names in the image files and attempt
>>> to load the corresponding class. But as indicated in [1]
>>> some of these classes are now in the Boot CL, some in the
>>> Extension CL, and some in the Application CL.
>>>
>>> So the test uses the System CL to load each class - which ensures
>>> that the loading will be delegated to the appropriate ClassLoader.
>>>
>>> best regards,
>>>
>>> -- daniel
>>



From sean.coffey at oracle.com  Thu Dec  4 13:02:21 2014
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Thu, 04 Dec 2014 13:02:21 +0000
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <5480529F.1020902@oracle.com>
References: <547F9302.3060309@oracle.com>
	<547FD6F2.5060400@oracle.com>	<548023D0.4020702@oracle.com>
	<548047C3.8000400@oracle.com>	<54804E4B.2070908@oracle.com>
	<5480529F.1020902@oracle.com>
Message-ID: <54805B5D.5020504@oracle.com>

Thanks for driving efforts in this area Daniel. I think it's a very 
useful test and is bound to help test code coverage. If it's currently 
passing on all JPRT platforms, it's a good measure.

Eventually I think we can bulk up the tests that can be run on the 
Iterable returned from your class search.
At moment you just test Field.setAccessible.

In the future, I don't see any harm in adding all simple Field method 
calls so that any corner cases in custom classes like the original issue 
are caught. e.g Field.getDeclaredAnnotations(), Field.getModifiers(), 
Field.isEnumConstant() etc., etc. Some methods won't be much value add 
but they're not a cost either.

Same argument for running through all Class methods, e.g 
Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a result this 
test might eventually become more general in test goal and might live 
better one level up in "test/java/lang/Class/" - it can be moved when 
the time comes.

regards,
Sean.

On 04/12/2014 12:25, Daniel Fuchs wrote:
> On 04/12/14 13:06, David Holmes wrote:
>> Hi Daniel,
>>
>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
>>> Hi David,
>>>
>>> In fact I could use 'null' on JDK 9 as well.
>>> My first version of the JDK 9 test was parsing over all the .jimage
>>> files under <jdk>/lib/modules - which explain why I needed to
>>> use the System class loader.
>>>
>>> Then I switched to only parsing the bootmodules.jimage - because
>>> I noticed that the results where more coherent with what I had
>>> observed on 8 & 7 - but I kept using the System class loader.
>>>
>>> I am not sure whether we want the test for 9 should iterate over
>>> the three .jimage - or continue to test only the boot .jimage.
>>>
>>> I have updated the JDK 9 test (refreshed the webrev in place)
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/
>>> and added support for possibly running the test in the two modes
>>> (I added a 'test.boot.only' system property, true by default)
>>> as well as additional traces to print the loaded classes by
>>> defining loader at the end (test.list.classes, false by default).
>>
>> A couple of initial comments:
>>
>>   104     static ClassLoader getClassLoaderFor(String classFileName) {
>>   105         if (restrictToBoot) return null; // only bootmodules
>>   106         return ClassLoaders.systemClassLoader;
>>   107     }
>>
>> I'm not clear the intent here. If it is to return a loader for which
>> loadClass could be invoked then you can always just return the system
>> loader - or just Class.forName. If it is meant to the return the
>> expected defining loader then it isn't doing that as the extensions
>> loader is not allowed for.
>
> The intent is to return the class loader that will be passed to
> Class.forName( ). I've been fiddling & experimenting with this
> test over 3 different platforms while trying to minimize the
> differences - so that was my attempt at having a good place to
> experiment with different strategy for loading classes.
>
>> Similarly for:
>>
>>   128         static ClassLoader getFor(String classFileName) {
>>   129             return systemClassLoader;
>>   130         }
>
> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..)
> was supposed to simply return ClassLoaders.getFor(...);
> and all the code should be in ClassLoaders.getFor - my bad.
>
>> Minor nit - In:
>>
>> 135                     System.err.println("Unexpected loader for "+c+":
>> "+c.getClassLoader());
>>
>> c.getClassLoader() can be replaced by cl. Also put spaces around the +
>> operator.
>
> Good catch.
>
> Thanks a lot David! Have a good night! (that's quite late - isn't it?)
>
> -- daniel
>
>>
>> David
>> (signing off for the night)
>>
>>> Thanks for your question, it triggered me into looking deeper
>>> into what was happening :-)
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> On 04/12/14 10:05, Daniel Fuchs wrote:
>>>>>> The differences between 8 & 9 are limited to:
>>>>>>
>>>>>>     - ClassLoader:
>>>>>>          - on 8 we use 'null' (BCL)
>>>>>>          - on 9 we use the system class loader.
>>>>>
>>>>> I haven't seen anything in JEP 220, regarding modules, that indicates
>>>>> that classes currently loaded  by the boot-loader will now be loaded
>>>>> by the system classloader ???
>>>>
>>>> In [1] towards the end:
>>>>
>>>> [1] http://openjdk.java.net/jeps/220
>>>>
>>>> "The defining class loader of the types in some existing packages
>>>>   will change. Existing code that makes assumptions about the class
>>>>   loaders of these types might not work correctly."
>>>>   (then there is a list of specific changes).
>>>>
>>>> This test looks up all class names in the image files and attempt
>>>> to load the corresponding class. But as indicated in [1]
>>>> some of these classes are now in the Boot CL, some in the
>>>> Extension CL, and some in the Application CL.
>>>>
>>>> So the test uses the System CL to load each class - which ensures
>>>> that the loading will be delegated to the appropriate ClassLoader.
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>
>



From roger.riggs at oracle.com  Thu Dec  4 14:40:24 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 04 Dec 2014 09:40:24 -0500
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>
Message-ID: <54807258.4040303@oracle.com>

Hi Nathan,

This list removes attachments.
Can the diff's be inlined in the email?

Thanks, Roger

On 12/4/2014 1:18 AM, Nathan Clement wrote:
> Hi,
>
> Here is my suggested fix for the FilterOuputStream issue in JDK-8054565.  I have been running this fix in my applications for several weeks (by adding it to the bootstrap classpath) and it solves my issue.  The fix creates a new member field to remember whether close has already been called on the stream, and if so, close() does nothing.
>
> Attached is the output from hg diff -g
>
> This is my first attempt at a patch for OpenJDK, so please let me know if I need to change anything.
>
> Thanks,
>
> Nathan
>   		 	   		



From paul.sandoz at oracle.com  Thu Dec  4 15:32:30 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 4 Dec 2014 16:32:30 +0100
Subject: Lambda-fied pattern matching
In-Reply-To: <546D234F.1090004@univ-mlv.fr>
References: <2F21F150-F3D1-4F7A-A2EB-38F26DE28169@oracle.com>
	<546D234F.1090004@univ-mlv.fr>
Message-ID: <F988DA31-3489-4C13-A0D8-03C611E97D15@oracle.com>

Hi,

Catching up on this.

This seems useful:

  Stream<MatchResult> Pattern.matchAsStream(...) 

MatchResult  stream elements need to be cloned via Matcher.toMatchResult.

The following is perhaps less useful though might be handy for some matcher updates before handing off to a stream:

  Stream<MatchResult> Pattern.match(...).stream()

The stream source implementation will need to check for co-omodification of the matcher.

I still think we need some point lamdification though because the Matcher.append* methods are stateful and don't play nicely with streams. So something like:

  String Matcher.replace(Function<MatchResult, String> f) 

is also useful (this was previously discussed a while back on lambda-dev).

Paul.

On Nov 20, 2014, at 12:10 AM, Remi Forax <forax at univ-mlv.fr> wrote:

> 
> On 11/19/2014 10:54 PM, Dan Smith wrote:
>> Working with the pattern matching API, I noticed that it could be made a lot less clumsy with some lambdafication.
>> 
>> Here's the status quo:
>> 
>> Pattern p = Pattern.compile("(\w)*, (\d)*, (\w)*");
>> for (String s : lines) {
>>     Matcher m = p.matcher(str);
>>     if (m.match(s)) {
>>         System.out.println(m.group(1));
>>     }
>> }
>> 
>> With a lambda-friendly API:
>> 
>> Pattern p = Pattern.compile("\d*, \d*, \d*");
>> for (String s : lines) {
>>     p.match(str, r -> System.out.println(r.group(1)));
>> }
>> 
>> The 'match' is declared as 'match(String, Consumer<MatchResult>)'.  You could argue that the functional interface should be a Function rather than a Consumer; whatever.
>> 
>> Could also do 'matchFirst', 'matchAll' -- the latter eliminates even more boilerplate.
>> 
>> If considered useful, this could be added to String too:
>> 
>> str.match("\d*, \d*, \d*", r -> System.out.println(r.group(1)));
>> 
>> Is this something that has been considered?  Should I file an RFE?
>> 
>> ?Dan
> 
> While I agree that we could have a more lambda-ish API,
> I prefer having a method Pattern.matchAsStream that returns a Stream of MatchResult
> because its more flexible that the API you propose.
> It's also more coherent with the fact that there is already a method splitAsStream().
> 
> Pattern p = Pattern.compile("(\d)*, (\d)*, (\d)*");
> for (String s : lines) {
>  p.matchAsStream(line).forEach(r -> System.out.println(r.group(1)));
> }
> 
> 
> or written using flatMap()
> 
> Pattern p = Pattern.compile("(\d)*, (\d)*, (\d)*");
> lines.stream().flatMap(line -> p.matchAsStream(line)).map(r -> r.group(1)).forEach(System.out::println);
> 
> 
> and yes, please log a RFE.
> 
> R?mi
> 
> 
> 
> 



From sean.coffey at oracle.com  Thu Dec  4 15:42:08 2014
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Thu, 04 Dec 2014 15:42:08 +0000
Subject: Should some JDK system properties be read only ?
Message-ID: <548080D0.1090506@oracle.com>

Apologies if this has been raised in past. I've run into issues in the 
past where bad user code (app server) has set the java.home system 
property to a value other than the default. This has consequences for 
apps/code that depend heavily on java.home returning the correct 
location. The case I saw was a JDK 7 runtime attempting to load JDK 6 
config files (since java.home was pointing to JDK 6)

It leads me to question on whether we should change this behaviour. 
There are a whole bunch of properties that make no sense to change. 
Those like : java.version, java.vendor, java.home, 
java.vm.specification.version, java.vm.specification.vendor, 
java.vm.specification.name, java.vm.version, java.vm.vendor, 
java.vm.name, java.specification.version, java.specification.vendor, 
java.specification.name.

Should we consider making them read only for JDK 9 and later ?

regards,
Sean.


From david.lloyd at redhat.com  Thu Dec  4 16:00:12 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 04 Dec 2014 10:00:12 -0600
Subject: Should some JDK system properties be read only ?
In-Reply-To: <548080D0.1090506@oracle.com>
References: <548080D0.1090506@oracle.com>
Message-ID: <5480850C.2010604@redhat.com>

On 12/04/2014 09:42 AM, Se?n Coffey wrote:
> Apologies if this has been raised in past. I've run into issues in the
> past where bad user code (app server) has set the java.home system
> property to a value other than the default. This has consequences for
> apps/code that depend heavily on java.home returning the correct
> location. The case I saw was a JDK 7 runtime attempting to load JDK 6
> config files (since java.home was pointing to JDK 6)
>
> It leads me to question on whether we should change this behaviour.
> There are a whole bunch of properties that make no sense to change.
> Those like : java.version, java.vendor, java.home,
> java.vm.specification.version, java.vm.specification.vendor,
> java.vm.specification.name, java.vm.version, java.vm.vendor,
> java.vm.name, java.specification.version, java.specification.vendor,
> java.specification.name.
>
> Should we consider making them read only for JDK 9 and later ?

Won't work unless you fundamentally change how System.setProperties() 
works.  Right now it will accept a user-created Properties instance and 
install it as the global system properties map.

-- 
- DML


From sean.coffey at oracle.com  Thu Dec  4 16:21:40 2014
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Thu, 04 Dec 2014 16:21:40 +0000
Subject: Should some JDK system properties be read only ?
In-Reply-To: <5480850C.2010604@redhat.com>
References: <548080D0.1090506@oracle.com> <5480850C.2010604@redhat.com>
Message-ID: <54808A14.9070309@oracle.com>


On 04/12/2014 16:00, David M. Lloyd wrote:
> On 12/04/2014 09:42 AM, Se?n Coffey wrote:
>> Apologies if this has been raised in past. I've run into issues in the
>> past where bad user code (app server) has set the java.home system
>> property to a value other than the default. This has consequences for
>> apps/code that depend heavily on java.home returning the correct
>> location. The case I saw was a JDK 7 runtime attempting to load JDK 6
>> config files (since java.home was pointing to JDK 6)
>>
>> It leads me to question on whether we should change this behaviour.
>> There are a whole bunch of properties that make no sense to change.
>> Those like : java.version, java.vendor, java.home,
>> java.vm.specification.version, java.vm.specification.vendor,
>> java.vm.specification.name, java.vm.version, java.vm.vendor,
>> java.vm.name, java.specification.version, java.specification.vendor,
>> java.specification.name.
>>
>> Should we consider making them read only for JDK 9 and later ?
>
> Won't work unless you fundamentally change how System.setProperties() 
> works.  Right now it will accept a user-created Properties instance 
> and install it as the global system properties map.
Some code change necessary but not much AFAIK. We can detect when JDK 
read-only values are (passed in && don't match orig. value) and throw an 
Exception or fail silently. Obviously a behavioural change which would 
require spec update.

regards,
Sean.



From pavel.rappo at oracle.com  Thu Dec  4 16:33:50 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 4 Dec 2014 16:33:50 +0000
Subject: Library enhancement proposal for copying data from/to
	Reader/Writer InputStream/OutputStream
In-Reply-To: <8E1109C5-4C9E-4B7A-924E-9E92B3F93F89@reini.net>
References: <566A428C-1A13-4DEE-940B-2EBE375F2A7A@reini.net>
	<51329A99-55E5-4A42-9180-D872366B4DEE@oracle.com>
	<D677D240-A59F-4ED6-A740-53F98B7DD49A@reini.net>
	<546EABED.9030301@oracle.com> <546EF98C.40704@oracle.com>
	<B764DE29-57BB-4BD9-B538-7A650723BF2B@reini.net>
	<1D392C1F-E6CC-494D-97F8-C08C5BA36392@oracle.com>
	<E9277204-264A-49A8-971C-6B2FF0B831A4@reini.net>
	<FB33655F-D0D8-47CF-82B0-530C9A212B8E@oracle.com>
	<B10C4D8D-6A57-41FE-8ABC-54E09B4DA14D@reini.net>
	<A3953E4D-018A-44C8-8106-DC9E4663D67C@reini.net>
	<C62A3014-1F54-41E4-B560-198F87305B9E@reini.net>
	<54772C7D.7080209@oracle.com>
	<769E83F8-FD6D-4F8B-B415-DD044C5D08BA@reini.net>
	<D1E803CB-29AF-46AA-9990-77B2A05EFBD4@oracle.com>
	<547757EE.4090205@oracle.com>
	<ED697D7C-F60A-4CD7-B84E-88C10D45B9FB@reini.net>
	<D2DD43D0-5D86-446A-A67A-8D3AEB2541CD@oracle.com>
	<15B58029-95FA-4D9E-AA28-7A6C72D6CB3D@reini.net>
	<13156FAC-6EDC-462B-9BE7-2DFAFB9124FD@oracle.com>
	<20141128201546.000067ce.ecki@zusammenkunft.net>
	<<216A14EF-B62C-4971!
	-!> <8194-E...> <8E1109C5-4C9E-4B7A-924E-9E92B3F93F89@reini.net>
Message-ID: <150A2C4B-E239-433C-B0C9-39F70E98D837@oracle.com>

Patrick, thanks a lot for doing this! I've had a look at these usages,  and I
think it's safe to say that in the JDK it has never been required (yet) to
provide a copy method with custom byte array. So let's skip it for now.

I think more and more about your initial suggestion of introducing a 'copyTo'
method directly into the types:

   InputStream, OutputStream, Readable and Appendable

I believe it will suit us a lot more. If we go this way, we can fully utilize
polymorphic calls. Implementations could then provide their own more efficient
solutions. Have a look at this:

/**
 * Reads all remaining bytes from this input stream and writes them to
 * a specified output stream.
 * <p>
 * There are no guarantees on streams state in a case error occurs. Even
 * if method returns normally you can't rely on previously marked positions
 * or the contents of any internal buffers.
 * That said, it is a terminal operation. It is strongly recommended that
 * both streams are promptly closed after this method returns:
 * <pre>{@code
 *     try (InputStream is = ...; OutputStream os = ...;) {
 *         is.read(os);
 *     } catch (IOException e) {
 *         ...
 *     }
 * }</pre>
 * <p>
 * This method may block indefinitely reading from the input stream
 * (or writing to the output stream). The behavior for the case that the
 * input and output streams is <i>asynchronously closed</i> or the thread
 * interrupted during the copy is highly input and output stream
 * system provider specific and therefore not specified.
 *
 * @param  target      the output stream to write to
 *                     ({@code target != null})
 * @return             the number of bytes copied
 * @throws IOException if an I/O error occurs when reading or writing
 *
 * @since 1.9
 */
public long copyTo(OutputStream target) throws IOException {
    Objects.requireNonNull(target, "target");
    int copied = 0;
    byte[] buffer = new byte[8192];
    for (int read; (read = this.read(buffer)) > -1; copied += read) {
        target.write(buffer, 0, read);
    }
    return copied;
}

This method will be defined in java.io.InputStream. And the following methods
will override 'copyTo' in java.io.ByteArrayInputStream and
java.io.BufferedInputStream respectively:

/**
 * {@inheritDoc}
 */
@Override
public synchronized long copyTo(OutputStream target) throws IOException {
    Objects.requireNonNull(target, "target");
    int avail = count - pos;
    target.write(buf, pos, avail);
    return avail;
}

/**
 * {@inheritDoc}
 */
@Override
public synchronized long copyTo(OutputStream target) throws IOException {
    Objects.requireNonNull(target, "target");
    long copied = 0;
    // 1. Get whatever is left unread in the buffer
    if (pos < count) {
        int len = count - pos;
        target.write(getBufIfOpen(), pos, len);
        copied += len;
    }
    // 2. Get everything else directly from the underlying stream
    for (int read; (read = getInIfOpen().read(getBufIfOpen())) > -1;
         copied += read) {
        target.write(getBufIfOpen(), 0, read);
    }
    return copied;
}


1. Please note, that this is not the actual code that will be pushed (if at
   all). It's merely a sketch to illustrate your proposal.
2. The equivalent thing will apply for Readable/Appendable.

-Pavel

> On 2 Dec 2014, at 09:22, Patrick Reinhart <patrick at reini.net> wrote:
> 
> I found around 190 usage references in total of those there are the following 28 references that could use my proposed copy feature and 5 of those use 8192 bytes sized buffers.



From david.lloyd at redhat.com  Thu Dec  4 16:34:23 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Thu, 04 Dec 2014 10:34:23 -0600
Subject: Should some JDK system properties be read only ?
In-Reply-To: <54808A14.9070309@oracle.com>
References: <548080D0.1090506@oracle.com> <5480850C.2010604@redhat.com>
	<54808A14.9070309@oracle.com>
Message-ID: <54808D0F.2090208@redhat.com>

On 12/04/2014 10:21 AM, Se?n Coffey wrote:
>
> On 04/12/2014 16:00, David M. Lloyd wrote:
>> On 12/04/2014 09:42 AM, Se?n Coffey wrote:
>>> Apologies if this has been raised in past. I've run into issues in the
>>> past where bad user code (app server) has set the java.home system
>>> property to a value other than the default. This has consequences for
>>> apps/code that depend heavily on java.home returning the correct
>>> location. The case I saw was a JDK 7 runtime attempting to load JDK 6
>>> config files (since java.home was pointing to JDK 6)
>>>
>>> It leads me to question on whether we should change this behaviour.
>>> There are a whole bunch of properties that make no sense to change.
>>> Those like : java.version, java.vendor, java.home,
>>> java.vm.specification.version, java.vm.specification.vendor,
>>> java.vm.specification.name, java.vm.version, java.vm.vendor,
>>> java.vm.name, java.specification.version, java.specification.vendor,
>>> java.specification.name.
>>>
>>> Should we consider making them read only for JDK 9 and later ?
>>
>> Won't work unless you fundamentally change how System.setProperties()
>> works.  Right now it will accept a user-created Properties instance
>> and install it as the global system properties map.
> Some code change necessary but not much AFAIK. We can detect when JDK
> read-only values are (passed in && don't match orig. value) and throw an
> Exception or fail silently. Obviously a behavioural change which would
> require spec update.

You can't do so without wrapping or replacing the user-provided 
Properties object.  I guess wrapping is a reasonable option though.
-- 
- DML


From ecki at zusammenkunft.net  Thu Dec  4 17:09:37 2014
From: ecki at zusammenkunft.net (Bernd)
Date: Thu, 4 Dec 2014 18:09:37 +0100
Subject: JDK 9 RFR of JDK-8066617: Suppress deprecation warnings in
	java.base module
In-Reply-To: <54800AD8.7080206@oracle.com>
References: <54800AD8.7080206@oracle.com>
Message-ID: <CABOR3+xoeR9gYs1DdfjZ8unN5gwubdZPZrZvFHxdkcGR0fBpgg@mail.gmail.com>

Hello,

I am not sure this is a good idea, while I can understand a policy of "no
(new) lint warnings" and also activities to remove them (based on the
asumption that every warning is a potential bug or code smell) I absolutely
think supressing all remaining warnings without working to resolve them
(i.e. w/o evaluating) is a bad thing. First of all it does not improve code
quality but glutter it. Secondly it makes it impossible later on to
distinguish between well considered supressions and mass supressions.

I would instead favor a solution which can easily detect if any change does
add more/new warnings and fail the review for it. (I.e. baselining the
current warnings which is yet another option you will kill when you supress
them all). The original JEP does BTW not even mention the possibility of
using supression.

Gruss
Bernd
Am 04.12.2014 09:49 schrieb "joe darcy" <joe.darcy at oracle.com>:

> Hello,
>
> First some background, one of the JEPs targeted to JDK 9 is
>
>     JEP 212: Resolve Lint and Doclint Warnings
>     http://openjdk.java.net/jeps/212
>
> In the jdk repository, only the deprecation category of lint warnings
> remain. While resolving the other categories of warnings mostly involved
> area-agnostic Java language expertise (say, to generify an API), fixing a
> deprecation warning by modifying code often involves very detailed
> area-specific knowledge. For that reason, to resolve the deprecation
> category of lint warnings, rather than updating the code per se, I'm only
> planning to @SuppressWarnings the issues. To track that work, I've filed
> the umbrella bug
>
>     JDK-8066616: Suppress deprecation warnings in jdk libraries
>     https://bugs.openjdk.java.net/browse/JDK-8066616
>
> with subtasks for different modules in the build. I've also filed a
> sibling umbrella bug
>
>     JDK-8066618: Fix deprecation warnings in jdk libraries
>     https://bugs.openjdk.java.net/browse/JDK-8066618
>
> which has a matching set of subtasks to have each deprecation location in
> the code be reexamined by someone familiar with the area.
>
> With that background, first up is this review request for
>
>     JDK-8066617: Suppress deprecation warnings in java.base module
>     http://cr.openjdk.java.net/~darcy/8066617.0/
>
> Thanks,
>
> -Joe
>


From daniel.fuchs at oracle.com  Thu Dec  4 17:13:11 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 04 Dec 2014 18:13:11 +0100
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <54805B5D.5020504@oracle.com>
References: <547F9302.3060309@oracle.com>
	<547FD6F2.5060400@oracle.com>	<548023D0.4020702@oracle.com>
	<548047C3.8000400@oracle.com>	<54804E4B.2070908@oracle.com>
	<5480529F.1020902@oracle.com> <54805B5D.5020504@oracle.com>
Message-ID: <54809627.8070103@oracle.com>

On 04/12/14 14:02, Se?n Coffey wrote:
> Thanks for driving efforts in this area Daniel. I think it's a very
> useful test and is bound to help test code coverage. If it's currently
> passing on all JPRT platforms, it's a good measure.

It seems to :-)

> Eventually I think we can bulk up the tests that can be run on the
> Iterable returned from your class search.
> At moment you just test Field.setAccessible.

Yes. If we change it later to test more, we will probably need to
change its name. I was already in lack of inspiration:
FieldSetAccessibleTest is not really a great name - but hopefully
it can do for now.

> In the future, I don't see any harm in adding all simple Field method
> calls so that any corner cases in custom classes like the original issue
> are caught. e.g Field.getDeclaredAnnotations(), Field.getModifiers(),
> Field.isEnumConstant() etc., etc. Some methods won't be much value add
> but they're not a cost either.

Agreed.

> Same argument for running through all Class methods, e.g
> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a result this
> test might eventually become more general in test goal and might live
> better one level up in "test/java/lang/Class/" - it can be moved when
> the time comes.

Agreed as well :-)

Here is a new revision of the webrev for 9 in which I have
incorporated David's comment:

http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/

best regards,

-- daniel

>
> regards,
> Sean.
>
> On 04/12/2014 12:25, Daniel Fuchs wrote:
>> On 04/12/14 13:06, David Holmes wrote:
>>> Hi Daniel,
>>>
>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
>>>> Hi David,
>>>>
>>>> In fact I could use 'null' on JDK 9 as well.
>>>> My first version of the JDK 9 test was parsing over all the .jimage
>>>> files under <jdk>/lib/modules - which explain why I needed to
>>>> use the System class loader.
>>>>
>>>> Then I switched to only parsing the bootmodules.jimage - because
>>>> I noticed that the results where more coherent with what I had
>>>> observed on 8 & 7 - but I kept using the System class loader.
>>>>
>>>> I am not sure whether we want the test for 9 should iterate over
>>>> the three .jimage - or continue to test only the boot .jimage.
>>>>
>>>> I have updated the JDK 9 test (refreshed the webrev in place)
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/
>>>> and added support for possibly running the test in the two modes
>>>> (I added a 'test.boot.only' system property, true by default)
>>>> as well as additional traces to print the loaded classes by
>>>> defining loader at the end (test.list.classes, false by default).
>>>
>>> A couple of initial comments:
>>>
>>>   104     static ClassLoader getClassLoaderFor(String classFileName) {
>>>   105         if (restrictToBoot) return null; // only bootmodules
>>>   106         return ClassLoaders.systemClassLoader;
>>>   107     }
>>>
>>> I'm not clear the intent here. If it is to return a loader for which
>>> loadClass could be invoked then you can always just return the system
>>> loader - or just Class.forName. If it is meant to the return the
>>> expected defining loader then it isn't doing that as the extensions
>>> loader is not allowed for.
>>
>> The intent is to return the class loader that will be passed to
>> Class.forName( ). I've been fiddling & experimenting with this
>> test over 3 different platforms while trying to minimize the
>> differences - so that was my attempt at having a good place to
>> experiment with different strategy for loading classes.
>>
>>> Similarly for:
>>>
>>>   128         static ClassLoader getFor(String classFileName) {
>>>   129             return systemClassLoader;
>>>   130         }
>>
>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..)
>> was supposed to simply return ClassLoaders.getFor(...);
>> and all the code should be in ClassLoaders.getFor - my bad.
>>
>>> Minor nit - In:
>>>
>>> 135                     System.err.println("Unexpected loader for "+c+":
>>> "+c.getClassLoader());
>>>
>>> c.getClassLoader() can be replaced by cl. Also put spaces around the +
>>> operator.
>>
>> Good catch.
>>
>> Thanks a lot David! Have a good night! (that's quite late - isn't it?)
>>
>> -- daniel
>>
>>>
>>> David
>>> (signing off for the night)
>>>
>>>> Thanks for your question, it triggered me into looking deeper
>>>> into what was happening :-)
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>>
>>>> On 04/12/14 10:05, Daniel Fuchs wrote:
>>>>>>> The differences between 8 & 9 are limited to:
>>>>>>>
>>>>>>>     - ClassLoader:
>>>>>>>          - on 8 we use 'null' (BCL)
>>>>>>>          - on 9 we use the system class loader.
>>>>>>
>>>>>> I haven't seen anything in JEP 220, regarding modules, that indicates
>>>>>> that classes currently loaded  by the boot-loader will now be loaded
>>>>>> by the system classloader ???
>>>>>
>>>>> In [1] towards the end:
>>>>>
>>>>> [1] http://openjdk.java.net/jeps/220
>>>>>
>>>>> "The defining class loader of the types in some existing packages
>>>>>   will change. Existing code that makes assumptions about the class
>>>>>   loaders of these types might not work correctly."
>>>>>   (then there is a list of specific changes).
>>>>>
>>>>> This test looks up all class names in the image files and attempt
>>>>> to load the corresponding class. But as indicated in [1]
>>>>> some of these classes are now in the Boot CL, some in the
>>>>> Extension CL, and some in the Application CL.
>>>>>
>>>>> So the test uses the System CL to load each class - which ensures
>>>>> that the loading will be delegated to the appropriate ClassLoader.
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>
>>
>



From Alan.Bateman at oracle.com  Thu Dec  4 17:26:06 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 04 Dec 2014 17:26:06 +0000
Subject: Should some JDK system properties be read only ?
In-Reply-To: <548080D0.1090506@oracle.com>
References: <548080D0.1090506@oracle.com>
Message-ID: <5480992E.1010007@oracle.com>

On 04/12/2014 15:42, Se?n Coffey wrote:
> Apologies if this has been raised in past. I've run into issues in the 
> past where bad user code (app server) has set the java.home system 
> property to a value other than the default. This has consequences for 
> apps/code that depend heavily on java.home returning the correct 
> location. The case I saw was a JDK 7 runtime attempting to load JDK 6 
> config files (since java.home was pointing to JDK 6)
>
> It leads me to question on whether we should change this behaviour. 
> There are a whole bunch of properties that make no sense to change. 
> Those like : java.version, java.vendor, java.home, 
> java.vm.specification.version, java.vm.specification.vendor, 
> java.vm.specification.name, java.vm.version, java.vm.vendor, 
> java.vm.name, java.specification.version, java.specification.vendor, 
> java.specification.name.
>
> Should we consider making them read only for JDK 9 and later ?
>
As it happens I ran into a test a few days ago that was changing 
java.home mid-flight. Lots of things can potentially go wrong when 
changing an important property like (user.dir is another one).

It would have been nice if there had been a concept of final/set-once 
system property a long time ago, hard to know if it's worth it now but 
no harm trying if you can come up with something that wouldn't have a 
significant compatibility impact. I could imagine System.setProperties 
requiring work to merge in the new properties so that the important 
properties are replaced.

-Alan.


From joe.darcy at oracle.com  Thu Dec  4 17:30:11 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 04 Dec 2014 09:30:11 -0800
Subject: JDK 9 RFR of JDK-8066617: Suppress deprecation warnings in
	java.base module
In-Reply-To: <CABOR3+xoeR9gYs1DdfjZ8unN5gwubdZPZrZvFHxdkcGR0fBpgg@mail.gmail.com>
References: <54800AD8.7080206@oracle.com>
	<CABOR3+xoeR9gYs1DdfjZ8unN5gwubdZPZrZvFHxdkcGR0fBpgg@mail.gmail.com>
Message-ID: <54809A23.6010805@oracle.com>

Greetings,

I was tempted to address this point my initial message, but since it has 
been raised I will do so now.

Many of the warnings in the JDK have been there for years or even more 
than a decade in some cases. Therefore, historically those of us who 
have worked on the JDK apparently have a very high tolerance for warning 
messages ;-)

The better should not be the enemy of the good. Suppressing the warnings 
can be done relatively quickly and the warnings can be turned on in the 
build, preventing new warnings from being introduced. The subtasks of

     JDK-8066618: Fix deprecation warnings in jdk libraries

contain a snapshot of the current deprecation warnings. Therefore, 
information about the state of the deprecation warnings has been 
captured and can be acted upon in due course.

-Joe

On 12/4/2014 9:09 AM, Bernd wrote:
> Hello,
>
> I am not sure this is a good idea, while I can understand a policy of "no
> (new) lint warnings" and also activities to remove them (based on the
> asumption that every warning is a potential bug or code smell) I absolutely
> think supressing all remaining warnings without working to resolve them
> (i.e. w/o evaluating) is a bad thing. First of all it does not improve code
> quality but glutter it. Secondly it makes it impossible later on to
> distinguish between well considered supressions and mass supressions.
>
> I would instead favor a solution which can easily detect if any change does
> add more/new warnings and fail the review for it. (I.e. baselining the
> current warnings which is yet another option you will kill when you supress
> them all). The original JEP does BTW not even mention the possibility of
> using supression.
>
> Gruss
> Bernd
> Am 04.12.2014 09:49 schrieb "joe darcy" <joe.darcy at oracle.com>:
>
>> Hello,
>>
>> First some background, one of the JEPs targeted to JDK 9 is
>>
>>      JEP 212: Resolve Lint and Doclint Warnings
>>      http://openjdk.java.net/jeps/212
>>
>> In the jdk repository, only the deprecation category of lint warnings
>> remain. While resolving the other categories of warnings mostly involved
>> area-agnostic Java language expertise (say, to generify an API), fixing a
>> deprecation warning by modifying code often involves very detailed
>> area-specific knowledge. For that reason, to resolve the deprecation
>> category of lint warnings, rather than updating the code per se, I'm only
>> planning to @SuppressWarnings the issues. To track that work, I've filed
>> the umbrella bug
>>
>>      JDK-8066616: Suppress deprecation warnings in jdk libraries
>>      https://bugs.openjdk.java.net/browse/JDK-8066616
>>
>> with subtasks for different modules in the build. I've also filed a
>> sibling umbrella bug
>>
>>      JDK-8066618: Fix deprecation warnings in jdk libraries
>>      https://bugs.openjdk.java.net/browse/JDK-8066618
>>
>> which has a matching set of subtasks to have each deprecation location in
>> the code be reexamined by someone familiar with the area.
>>
>> With that background, first up is this review request for
>>
>>      JDK-8066617: Suppress deprecation warnings in java.base module
>>      http://cr.openjdk.java.net/~darcy/8066617.0/
>>
>> Thanks,
>>
>> -Joe
>>



From Alan.Bateman at oracle.com  Thu Dec  4 17:30:48 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 04 Dec 2014 17:30:48 +0000
Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation
	fault
In-Reply-To: <5480178A.9090709@oracle.com>
References: <545D939D.2030308@oracle.com>
	<5463B896.10801@oracle.com>	<54641ADE.8030504@oracle.com>
	<546BC35E.4070402@oracle.com>	<546C5986.6010500@oracle.com>
	<546C6D1A.8050903@oracle.com>	<546CBCAB.7040101@oracle.com>
	<547D265A.20005@oracle.com> <547F0889.5050204@oracle.com>
	<5480178A.9090709@oracle.com>
Message-ID: <54809A48.5090201@oracle.com>

On 04/12/2014 08:12, Chris Plummer wrote:
> Hi Alan,
>
> While removing the java.io.File import, I also questioned why I had 
> java.io.IOException being imported. There were a couple of methods 
> that declared it thrown, and the main method therefore had to catch 
> it, but it turns out this was just copy/paste from the Settings.java 
> test I used as a template, and is not actually needed. I removed the 
> import, throws, and try/catch of IOException.
>
> All the other issues mentioned by others have also been addressed. A 
> new webrev can be found at:
>
> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.03/
This looks good to me.

-Alan.


From peter.levart at gmail.com  Thu Dec  4 18:15:16 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 04 Dec 2014 19:15:16 +0100
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <F498D1ED-6C4B-4F5B-8F82-036715009EEC@oracle.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>	<547DEC01.2050501@gmail.com>	<547DF89A.2020809@oracle.com>	<CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>	<547F2BC1.6040904@cs.oswego.edu>	<CA+kOe0_h2EBbY51qh7MSUFpq44FpOspgtBVF6qVWENMwW2O0xA@mail.gmail.com>	<547F4A9D.3060805@cs.oswego.edu>	<CA+kOe08vnvXtDE_Xv+6iqtpBaRR3MpdeRV0OtksqMJ_aJpi9Dg@mail.gmail.com>	<547F8B84.6090301@cs.oswego.edu>	<CA+kOe0_D0yxDEWq4DNQN_DL-yv-+Am3gFx_Foq-G63BDkrSHuQ@mail.gmail.com>	<5480195B.4070800@gmail.com>
	<F498D1ED-6C4B-4F5B-8F82-036715009EEC@oracle.com>
Message-ID: <5480A4B4.8080902@gmail.com>

On 12/04/2014 10:40 AM, Paul Sandoz wrote:
> Hi,
>
> I think we may be over-rotating a little on this.
>
> There is already a mechanism to create a cryptographically strong seed by setting a system property and using SecureRandom. That has a high initialization cost, but i think under those circumstances that cost is acceptable (it may well be possible to reduce that cost but i consider that to be a separate issue).
>
> For the default case what we need is something with low initialization cost that is *good enough* for the majority of cases e.g. documents the lower bound of cryptographic strength.
>
> I like Doug's approach to hide this under TLR, i think that fits well with the "good enough" aspect (cross seeding can be documented as an @implNote). But I still marginally prefer a public static method as well, and SecureRandom seems an appropriate choice (although it could easily be exposed on System or Runtime).
>
> Paul.

Right. I think the cleanest is to provide an internal public API 
(modules will effectively hide it from user code) and then expose it if 
desired by delegation or just use it internally. For JDK8u, the approach 
to disable the API for user code could use similar trick as Unsafe. If 
anyone wants to bother with reflection, let him do it. We can't prevent 
that in JDK8 no matter how deep the implementation is buried.

Here's the 3rd iteration of SystemRandom:

http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.03/

I managed to make LoadLibrary work (I used LoadLibraryA - the ANSI variant).

The API is back to getBytes() instance method and a getInstance() static 
method that lazily initializes a singleton instance. This way the 
initialization is clearly separated from use. Initialization is expected 
to fail if the system does not support the interface (/dev/urandom or 
ADVAPI32!RtlGenRandom), but use should always succeed unless there's 
something wrong with the state of the operating system (testing will 
show if my assumptions are correct).

The enclosed test results (on 64 bit Linux, i7 PC):

SystemRandomTest... (8 bytes / invocation)
1st invocation: 116368 ns, result: [47, -68, 15, -28, 76, -11, -70, -10]
Following 1000000 invocations: 0.624066896 s, (624 ns/invocation)

On 32 bit Windows 7 (VirtualBox guest on the same Linux host):

SystemRandomTest... (8 bytes / invocation)
1st invocation: 1329219 ns, result: [31, -5, 62, -34, -82, -69, 69, 80]
Following 1000000 invocations: 1.137231408 s, (1137 ns/invocation)


The initialization latency on Windows is higher that with code in 
webrev.02, but sill lower that when using MS Crypto API. I think that's 
because now the ADVAPI32.DLL is loaded lazily as part of singleton 
initialization, in webrev.02 it was loaded as part of libjava.dll, since 
it was linked with it, so the measurement did not include the 
ADVAPI32.DLL loading time.

We can now play in Java and use a strategy that releases the singleton 
after some time (thinking WeakReference) and ADVAPI32.DLL will be 
effectively unloaded and unmapped from the process address space. The 
same goes with UNIX variant and it's file descriptor open from 
/dev/urandom file...

I think webrev.03 is ready for testing.

Regards, Peter

>
> On Dec 4, 2014, at 9:20 AM, Peter Levart <peter.levart at gmail.com> wrote:
>
>> On 12/04/2014 12:32 AM, Martin Buchholz wrote:
>>> On Wed, Dec 3, 2014 at 2:15 PM, Doug Lea <dl at cs.oswego.edu> wrote:
>>>
>>>> No public API because systemSeed need only be implemented
>>>> inside TLR, for its initial seed. Then the others can get their seeds
>>>> using ThreadLocalRandom.current().nextLong(), unless
>>>> java.util.secureRandomSeed is set (which I didn't illustrate above).
>>>> In other words, across all non-secure generators, you only need
>>>> one system-generated seed.
>>> That's good enough for seeding other non-cryptographically secure
>>> PRNGs, but if you want each caller to get a
>>> cryptographically secure random number, you need to avoid correlations
>>> between them that would arise when you use a non-CS PRNG to generate
>>> them from a single CS seed.
>> Unless java.util.Random is retrofitted to allocate new cryptographically secure seed for each new instance. In such case expression:
>>
>>     new java.util.Random().nextLong()
>>
>> ...could be used to gather secure seed. Perhaps even SplittableRandom could allocate new seed from secure source for each new instance (only in public constructor - not when it is split()ed)...
>>
>> What makes those workarounds unsuitable is failure mode. Gathering secure seed is inherently coupled with possible failure which must be communicated explicitly to the consumer. But one must not be bothered with failure in situations where security is not a necessary ingredient.
>>
>> So for  non-CS PRNGs, cross-seeding is a possible solution, but it's nicer for all of them to just use a common (internal) API.
>>
>> As far as public API is concerned, there already is one: SecureRandom.generateSeed(). It's as good as SystemRandom (uses same primary means) and has a nice cross-platform fallback (ThreadedSeedGenerator). It's only drawback is that it comes with all the baggage of security providers (Java and MS Crypto API on Windows). But that's ok for user code perhaps.
>>
>> So what we have here is two desires:
>> - we want a resource-friendly / with as little dependencies as possible way to generate some unique seed, with implicit fall-back which need not be secure
>> - we want a resource-friendly / with as little dependencies as possible way to generate secure random bytes that can be pseudo-random, but still secure, with explicit failure mode
>>
>> I'll try to address this dichotomy in the next iteration of the API.
>>
>> Regards, Peter
>>
>> P.S. Is anyone interested in generating truly random bytes?
>>
>> http://www.cryptography.com/public/pdf/Intel_TRNG_Report_20120312.pdf
>>
>> https://software.intel.com/en-us/tags/35970
>>



From peter.levart at gmail.com  Thu Dec  4 18:47:11 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 04 Dec 2014 19:47:11 +0100
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <5480195B.4070800@gmail.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>	<547DEC01.2050501@gmail.com>
	<547DF89A.2020809@oracle.com>	<CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>	<547F2BC1.6040904@cs.oswego.edu>	<CA+kOe0_h2EBbY51qh7MSUFpq44FpOspgtBVF6qVWENMwW2O0xA@mail.gmail.com>	<547F4A9D.3060805@cs.oswego.edu>	<CA+kOe08vnvXtDE_Xv+6iqtpBaRR3MpdeRV0OtksqMJ_aJpi9Dg@mail.gmail.com>	<547F8B84.6090301@cs.oswego.edu>
	<CA+kOe0_D0yxDEWq4DNQN_DL-yv-+Am3gFx_Foq-G63BDkrSHuQ@mail.gmail.com>
	<5480195B.4070800@gmail.com>
Message-ID: <5480AC2F.6080200@gmail.com>

On 12/04/2014 09:20 AM, Peter Levart wrote:
> So what we have here is two desires:
> - we want a resource-friendly / with as little dependencies as 
> possible way to generate some unique seed, with implicit fall-back 
> which need not be secure
> - we want a resource-friendly / with as little dependencies as 
> possible way to generate secure random bytes that can be 
> pseudo-random, but still secure, with explicit failure mode
>
> I'll try to address this dichotomy in the next iteration of the API. 

I tried and found out that it is not that easy. The fall-back strategy 
is dependent on the use case and is better left to the consumer of 
SystemRandom which is just an interface to OS provided secure PRNG. The 
fact that we want to use it for seeding other PRNGs is just a coincidence.

Regarding the fall-back strategy: Besides System.currentTime() and 
System.nanoTime(), the following could be used in addition, to spice it 
up, and don't seem like dependencies that couldn't be handled:

Runtime.getRuntime().freeMemory()
Unsafe.getUnsafe().getLoadAverage()
Thread.currentThread().getId()


Regards, Peter



From patrick at reini.net  Thu Dec  4 19:45:18 2014
From: patrick at reini.net (Patrick Reinhart)
Date: Thu, 04 Dec 2014 20:45:18 +0100
Subject: Library enhancement proposal for copying data from/to
	Reader/Writer InputStream/OutputStream
In-Reply-To: <150A2C4B-E239-433C-B0C9-39F70E98D837@oracle.com>
References: <566A428C-1A13-4DEE-940B-2EBE375F2A7A@reini.net>
	<546EF98C.40704@oracle.com>
	<B764DE29-57BB-4BD9-B538-7A650723BF2B@reini.net>
	<1D392C1F-E6CC-494D-97F8-C08C5BA36392@oracle.com>
	<E9277204-264A-49A8-971C-6B2FF0B831A4@reini.net>
	<FB33655F-D0D8-47CF-82B0-530C9A212B8E@oracle.com>
	<B10C4D8D-6A57-41FE-8ABC-54E09B4DA14D@reini.net>
	<A3953E4D-018A-44C8-8106-DC9E4663D67C@reini.net>
	<C62A3014-1F54-41E4-B560-198F87305B9E@reini.net>
	<54772C7D.7080209@oracle.com>
	<769E83F8-FD6D-4F8B-B415-DD044C5D08BA@reini.net>
	<D1E803CB-29AF-46AA-9990-77B2A05EFBD4@oracle.com>
	<547757EE.4090205@oracle.com>
	<ED697D7C-F60A-4CD7-B84E-88C10D45B9FB@reini.net>
	<D2DD43D0-5D86-446A-A67A-8D3AEB2541CD@oracle.com>
	<15B58029-95FA-4D9E-AA28-7A6C72D6CB3D@reini.net>
	<13156FAC-6EDC-462B-9BE7-2DFAFB9124FD@oracle.com>
	<20141128201546.000067ce.ecki@zusammenkunft.net>
	<<216A14EF-B62C-4971! -!> <8194-E...>
	<8E1109C5-4C9E-4B7A-924E-9E92B3F93F89@reini.net>
	<150A2C4B-E239-433C-B0C9-39F70E98D837@oracle.com>
Message-ID: <5480B9CE.2090600@reini.net>

Hi Pavel,

> Patrick, thanks a lot for doing this! I've had a look at these usages,  and I
> think it's safe to say that in the JDK it has never been required (yet) to
> provide a copy method with custom byte array. So let's skip it for now.

Welcome, unfortunately I did not manage it to check those on the JDK9 
code base due the fact, that the NetBeans project does not work with the 
modularized codebase jet.

> I think more and more about your initial suggestion of introducing a 'copyTo'
> method directly into the types:
>
>     InputStream, OutputStream, Readable and Appendable

Having a "copyTo" method on InputStream and Readable was indeed my fist 
idea to have. Also to have a "copyFrom" method on the OutputStream and 
Appendable was then a natural fit. Looking at those methods it became 
clear to me that in fact we would have a the same code on either 
InputStream and OutputStream or Readable and Appendable.

Of course for OutputStream we could also have something like:

public long copyFrom(InputStream source) throws IOException {
     return source.copyTo(this);
}

For the Appendable could it be the same same with a Readable as the 
source in that case.

> I believe it will suit us a lot more. If we go this way, we can fully utilize
> polymorphic calls. Implementations could then provide their own more efficient
> solutions. Have a look at this:
>
> /**
>   * Reads all remaining bytes from this input stream and writes them to
>   * a specified output stream.
>   * <p>
>   * There are no guarantees on streams state in a case error occurs. Even
>   * if method returns normally you can't rely on previously marked positions
>   * or the contents of any internal buffers.
>   * That said, it is a terminal operation. It is strongly recommended that
>   * both streams are promptly closed after this method returns:
>   * <pre>{@code
>   *     try (InputStream is = ...; OutputStream os = ...;) {
>   *         is.read(os);
>   *     } catch (IOException e) {
>   *         ...
>   *     }
>   * }</pre>
>   * <p>
>   * This method may block indefinitely reading from the input stream
>   * (or writing to the output stream). The behavior for the case that the
>   * input and output streams is <i>asynchronously closed</i> or the thread
>   * interrupted during the copy is highly input and output stream
>   * system provider specific and therefore not specified.
>   *
>   * @param  target      the output stream to write to
>   *                     ({@code target != null})
>   * @return             the number of bytes copied
>   * @throws IOException if an I/O error occurs when reading or writing
>   *
>   * @since 1.9
>   */
> public long copyTo(OutputStream target) throws IOException {
>      Objects.requireNonNull(target, "target");
>      int copied = 0;
>      byte[] buffer = new byte[8192];
>      for (int read; (read = this.read(buffer)) > -1; copied += read) {
>          target.write(buffer, 0, read);
>      }
>      return copied;
> }
>
> This method will be defined in java.io.InputStream. And the following methods
> will override 'copyTo' in java.io.ByteArrayInputStream and
> java.io.BufferedInputStream respectively:

Should those methods also be on the FilterInput- and OutputStream?

> /**
>   * {@inheritDoc}
>   */
> @Override
> public synchronized long copyTo(OutputStream target) throws IOException {
>      Objects.requireNonNull(target, "target");
>      int avail = count - pos;
>      target.write(buf, pos, avail);
>      return avail;
> }
>
> /**
>   * {@inheritDoc}
>   */
> @Override
> public synchronized long copyTo(OutputStream target) throws IOException {
>      Objects.requireNonNull(target, "target");
>      long copied = 0;
>      // 1. Get whatever is left unread in the buffer
>      if (pos < count) {
>          int len = count - pos;
>          target.write(getBufIfOpen(), pos, len);
>          copied += len;
>      }
>      // 2. Get everything else directly from the underlying stream
>      for (int read; (read = getInIfOpen().read(getBufIfOpen())) > -1;
>           copied += read) {
>          target.write(getBufIfOpen(), 0, read);
>      }
>      return copied;
> }
>
>
> 1. Please note, that this is not the actual code that will be pushed (if at
>     all). It's merely a sketch to illustrate your proposal.
> 2. The equivalent thing will apply for Readable/Appendable.
>
> -Pavel

I like that solution almost more then having a separate utility class 
though.

I'm not quit sure about the impact on may already existing customer code 
that had implemented such a method without declaring a IOException for 
example. In this case the existing code would may break? (as a comment 
of Alan Bateman earlier before)

-Patrick


From chris.plummer at oracle.com  Thu Dec  4 20:11:57 2014
From: chris.plummer at oracle.com (Chris Plummer)
Date: Thu, 04 Dec 2014 12:11:57 -0800
Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation
	fault
In-Reply-To: <54809A48.5090201@oracle.com>
References: <545D939D.2030308@oracle.com>
	<5463B896.10801@oracle.com>	<54641ADE.8030504@oracle.com>
	<546BC35E.4070402@oracle.com>	<546C5986.6010500@oracle.com>
	<546C6D1A.8050903@oracle.com>	<546CBCAB.7040101@oracle.com>
	<547D265A.20005@oracle.com> <547F0889.5050204@oracle.com>
	<5480178A.9090709@oracle.com> <54809A48.5090201@oracle.com>
Message-ID: <5480C00D.1050003@oracle.com>

On 12/4/14 9:30 AM, Alan Bateman wrote:
> On 04/12/2014 08:12, Chris Plummer wrote:
>> Hi Alan,
>>
>> While removing the java.io.File import, I also questioned why I had 
>> java.io.IOException being imported. There were a couple of methods 
>> that declared it thrown, and the main method therefore had to catch 
>> it, but it turns out this was just copy/paste from the Settings.java 
>> test I used as a template, and is not actually needed. I removed the 
>> import, throws, and try/catch of IOException.
>>
>> All the other issues mentioned by others have also been addressed. A 
>> new webrev can be found at:
>>
>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.03/
> This looks good to me.
>
> -Alan.
Thanks everyone for the reviews!

Chris


From lance.andersen at oracle.com  Thu Dec  4 20:26:08 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 4 Dec 2014 15:26:08 -0500
Subject: JDK 9 RFR of JDK-8066617: Suppress deprecation warnings in
	java.base module
In-Reply-To: <54800AD8.7080206@oracle.com>
References: <54800AD8.7080206@oracle.com>
Message-ID: <04CE3E1C-BB3F-453C-9506-D536CE67261B@oracle.com>

Hi Joe,

The changes look fine.

Best,
Lance
On Dec 4, 2014, at 2:18 AM, joe darcy <joe.darcy at oracle.com> wrote:

> Hello,
> 
> First some background, one of the JEPs targeted to JDK 9 is
> 
>    JEP 212: Resolve Lint and Doclint Warnings
>    http://openjdk.java.net/jeps/212
> 
> In the jdk repository, only the deprecation category of lint warnings remain. While resolving the other categories of warnings mostly involved area-agnostic Java language expertise (say, to generify an API), fixing a deprecation warning by modifying code often involves very detailed area-specific knowledge. For that reason, to resolve the deprecation category of lint warnings, rather than updating the code per se, I'm only planning to @SuppressWarnings the issues. To track that work, I've filed the umbrella bug
> 
>    JDK-8066616: Suppress deprecation warnings in jdk libraries
>    https://bugs.openjdk.java.net/browse/JDK-8066616
> 
> with subtasks for different modules in the build. I've also filed a sibling umbrella bug
> 
>    JDK-8066618: Fix deprecation warnings in jdk libraries
>    https://bugs.openjdk.java.net/browse/JDK-8066618
> 
> which has a matching set of subtasks to have each deprecation location in the code be reexamined by someone familiar with the area.
> 
> With that background, first up is this review request for
> 
>    JDK-8066617: Suppress deprecation warnings in java.base module
>    http://cr.openjdk.java.net/~darcy/8066617.0/
> 
> Thanks,
> 
> -Joe



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





From nathan.a.clement at hotmail.com  Thu Dec  4 22:32:12 2014
From: nathan.a.clement at hotmail.com (Nathan Clement)
Date: Fri, 5 Dec 2014 09:32:12 +1100
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <54807258.4040303@oracle.com>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>,
	<54807258.4040303@oracle.com>
Message-ID: <COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>

Hi,

My apologies - the page http://openjdk.java.net/contribute/ gave me the impression that I could send the diff as an attachment.  I've included it inline below.

Regards,

Nathan

diff --git a/src/share/classes/java/io/FilterOutputStream.java b/src/share/classes/java/io/FilterOutputStream.java
--- a/src/share/classes/java/io/FilterOutputStream.java
+++ b/src/share/classes/java/io/FilterOutputStream.java
@@ -47,6 +47,11 @@
      * The underlying output stream to be filtered.
      */
     protected OutputStream out;
+    
+    /**
+     * Whether this stream has already been closed or not
+     */
+    protected boolean closed = false;
 
     /**
      * Creates an output stream filter built on top of the specified
@@ -154,8 +159,11 @@
      */
     @SuppressWarnings("try")
     public void close() throws IOException {
-        try (OutputStream ostream = out) {
-            flush();
+        if (!closed) {
+            closed = true;
+            try (OutputStream ostream = out) {
+                flush();
+            }
         }
     }
 }
diff --git a/test/java/io/FilterOutputStream/CloseTwiceTest.java b/test/java/io/FilterOutputStream/CloseTwiceTest.java
new file mode 100644
--- /dev/null
+++ b/test/java/io/FilterOutputStream/CloseTwiceTest.java
@@ -0,0 +1,88 @@
+/*
+ * Copyright (c) 2011, Oracle and/or its affiliates. All rights reserved.
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
+ *
+ * This code is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+ * or visit www.oracle.com if you need additional information or have any
+ * questions.
+ */
+
+package java.io.FilterOutputStream;
+
+import java.io.BufferedOutputStream;
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.IOException;
+import java.io.InputStream;
+import java.io.OutputStream;
+import java.lang.String;
+import java.util.zip.Deflater;
+import java.util.zip.DeflaterOutputStream;
+
+/**
+ * @test
+ * @bug 8054565
+ * @summary Test that closing a FilterOutputStream twice does not cause 
+ *    an exception when the underlying stream throws an exception when
+ *    close is called before flush.
+ */
+
+public class CloseTwiceTest
+{
+    /**
+     * This stream simulates a OracleBlobOutputStream which will throw
+     * an exception if flush is called after close.
+     */
+    static class MockBlobOutputStream extends ByteArrayOutputStream
+    {
+        private boolean closed;
+
+        @Override
+        public void flush() throws IOException
+        {
+            if (closed) {
+                throw new IOException("Stream closed");
+            }
+        }
+
+        @Override
+        public void close() throws IOException
+        {
+            closed = true;
+        }
+    }
+
+    public static void main( final String[] args ) throws Exception
+    {
+        try( InputStream bis = new ByteArrayInputStream( "Hello".getBytes() );
+             OutputStream outStream = new MockBlobOutputStream();
+             BufferedOutputStream bos = new BufferedOutputStream( outStream );
+             DeflaterOutputStream deflaterStream = new DeflaterOutputStream(
+                 bos, new Deflater( 3 ) ) )
+        {
+            int len = 0;
+            final byte[] buf = new byte[1024];
+            while ((len = bis.read(buf)) >= 0)
+            {
+                if ( len > 0 )
+                {
+                    deflaterStream.write(buf,0,len);
+                }
+            }
+        }
+    }
+}


> Date: Thu, 4 Dec 2014 09:40:24 -0500
> From: roger.riggs at oracle.com
> To: core-libs-dev at openjdk.java.net
> Subject: Re: [PATCH] JDK-8054565: FilterOutputStream.close may throw	IOException if called twice and underlying flush or close fails
> 
> Hi Nathan,
> 
> This list removes attachments.
> Can the diff's be inlined in the email?
> 
> Thanks, Roger
> 
> On 12/4/2014 1:18 AM, Nathan Clement wrote:
> > Hi,
> >
> > Here is my suggested fix for the FilterOuputStream issue in JDK-8054565.  I have been running this fix in my applications for several weeks (by adding it to the bootstrap classpath) and it solves my issue.  The fix creates a new member field to remember whether close has already been called on the stream, and if so, close() does nothing.
> >
> > Attached is the output from hg diff -g
> >
> > This is my first attempt at a patch for OpenJDK, so please let me know if I need to change anything.
> >
> > Thanks,
> >
> > Nathan
> >   		 	   		
> 
 		 	   		  

From joe.darcy at oracle.com  Thu Dec  4 22:46:07 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 04 Dec 2014 14:46:07 -0800
Subject: JDK 9 RFR of JDK-8066632: Suppress deprecation warnings in java.rmi
	module
Message-ID: <5480E42F.50209@oracle.com>

Hello,

Please review these changes to address

     JDK-8066632: Suppress deprecation warnings in java.rmi module
     http://cr.openjdk.java.net/~darcy/8066632.0/

Patch inlined below.

Thanks,

-Joe

--- old/src/java.rmi/share/classes/java/rmi/server/RemoteObject.java 
2014-12-04 14:43:37.806086378 -0800
+++ new/src/java.rmi/share/classes/java/rmi/server/RemoteObject.java 
2014-12-04 14:43:37.630086370 -0800
@@ -94,6 +94,7 @@
       * remote object could not be found.
       * @since 1.2
       */
+    @SuppressWarnings("deprecation")
      public static Remote toStub(Remote obj) throws NoSuchObjectException {
          if (obj instanceof RemoteStub ||
              (obj != null &&
--- old/src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java 
2014-12-04 14:43:38.382086405 -0800
+++ new/src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java 
2014-12-04 14:43:38.150086394 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2014, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -336,6 +336,7 @@
       * Main program to start a registry. <br>
       * The port number can be specified on the command line.
       */
+    @SuppressWarnings("deprecation")
      public static void main(String args[])
      {
          // Create and install the security manager if one is not installed
--- 
old/src/java.rmi/share/classes/sun/rmi/server/MarshalOutputStream.java 
2014-12-04 14:43:38.974086433 -0800
+++ 
new/src/java.rmi/share/classes/sun/rmi/server/MarshalOutputStream.java 
2014-12-04 14:43:38.762086423 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1996, 2008, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1996, 2014, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -76,6 +76,7 @@
       * Checks for objects that are instances of java.rmi.Remote
       * that need to be serialized as proxy objects.
       */
+    @SuppressWarnings("deprecation")
      protected final Object replaceObject(Object obj) throws IOException {
          if ((obj instanceof Remote) && !(obj instanceof RemoteStub)) {
              Target target = ObjectTable.getTarget((Remote) obj);
--- 
old/src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpInputStream.java 
2014-12-04 14:43:39.498086458 -0800
+++ 
new/src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpInputStream.java 
2014-12-04 14:43:39.290086448 -0800
@@ -45,6 +45,7 @@
       * Create new filter on a given input stream.
       * @param in the InputStream to filter from
       */
+    @SuppressWarnings("deprecation")
      public HttpInputStream(InputStream in) throws IOException
      {
          super(in);



From roger.riggs at oracle.com  Thu Dec  4 22:58:32 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 04 Dec 2014 17:58:32 -0500
Subject: JDK 9 RFR of JDK-8066632: Suppress deprecation warnings in
	java.rmi module
In-Reply-To: <5480E42F.50209@oracle.com>
References: <5480E42F.50209@oracle.com>
Message-ID: <5480E718.4060304@oracle.com>

Hi Joe,

Looks fine.

Roger

On 12/4/2014 5:46 PM, joe darcy wrote:
> Hello,
>
> Please review these changes to address
>
>     JDK-8066632: Suppress deprecation warnings in java.rmi module
>     http://cr.openjdk.java.net/~darcy/8066632.0/
>
> Patch inlined below.
>
> Thanks,
>
> -Joe
>
> --- old/src/java.rmi/share/classes/java/rmi/server/RemoteObject.java 
> 2014-12-04 14:43:37.806086378 -0800
> +++ new/src/java.rmi/share/classes/java/rmi/server/RemoteObject.java 
> 2014-12-04 14:43:37.630086370 -0800
> @@ -94,6 +94,7 @@
>       * remote object could not be found.
>       * @since 1.2
>       */
> +    @SuppressWarnings("deprecation")
>      public static Remote toStub(Remote obj) throws 
> NoSuchObjectException {
>          if (obj instanceof RemoteStub ||
>              (obj != null &&
> --- old/src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java 
> 2014-12-04 14:43:38.382086405 -0800
> +++ new/src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java 
> 2014-12-04 14:43:38.150086394 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2012, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2014, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -336,6 +336,7 @@
>       * Main program to start a registry. <br>
>       * The port number can be specified on the command line.
>       */
> +    @SuppressWarnings("deprecation")
>      public static void main(String args[])
>      {
>          // Create and install the security manager if one is not 
> installed
> --- 
> old/src/java.rmi/share/classes/sun/rmi/server/MarshalOutputStream.java 
> 2014-12-04 14:43:38.974086433 -0800
> +++ 
> new/src/java.rmi/share/classes/sun/rmi/server/MarshalOutputStream.java 
> 2014-12-04 14:43:38.762086423 -0800
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 1996, 2008, Oracle and/or its affiliates. All rights 
> reserved.
> + * Copyright (c) 1996, 2014, Oracle and/or its affiliates. All rights 
> reserved.
>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>   *
>   * This code is free software; you can redistribute it and/or modify it
> @@ -76,6 +76,7 @@
>       * Checks for objects that are instances of java.rmi.Remote
>       * that need to be serialized as proxy objects.
>       */
> +    @SuppressWarnings("deprecation")
>      protected final Object replaceObject(Object obj) throws 
> IOException {
>          if ((obj instanceof Remote) && !(obj instanceof RemoteStub)) {
>              Target target = ObjectTable.getTarget((Remote) obj);
> --- 
> old/src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpInputStream.java 
> 2014-12-04 14:43:39.498086458 -0800
> +++ 
> new/src/java.rmi/share/classes/sun/rmi/transport/proxy/HttpInputStream.java 
> 2014-12-04 14:43:39.290086448 -0800
> @@ -45,6 +45,7 @@
>       * Create new filter on a given input stream.
>       * @param in the InputStream to filter from
>       */
> +    @SuppressWarnings("deprecation")
>      public HttpInputStream(InputStream in) throws IOException
>      {
>          super(in);
>



From pavel.rappo at oracle.com  Thu Dec  4 23:13:52 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 4 Dec 2014 23:13:52 +0000
Subject: Library enhancement proposal for copying data from/to
	Reader/Writer InputStream/OutputStream
In-Reply-To: <5480B9CE.2090600@reini.net>
References: <566A428C-1A13-4DEE-940B-2EBE375F2A7A@reini.net>
	<546EF98C.40704@oracle.com>
	<B764DE29-57BB-4BD9-B538-7A650723BF2B@reini.net>
	<1D392C1F-E6CC-494D-97F8-C08C5BA36392@oracle.com>
	<E9277204-264A-49A8-971C-6B2FF0B831A4@reini.net>
	<FB33655F-D0D8-47CF-82B0-530C9A212B8E@oracle.com>
	<B10C4D8D-6A57-41FE-8ABC-54E09B4DA14D@reini.net>
	<A3953E4D-018A-44C8-8106-DC9E4663D67C@reini.net>
	<C62A3014-1F54-41E4-B560-198F87305B9E@reini.net>
	<54772C7D.7080209@oracle.com>
	<769E83F8-FD6D-4F8B-B415-DD044C5D08BA@reini.net>
	<D1E803CB-29AF-46AA-9990-77B2A05EFBD4@oracle.com>
	<547757EE.4090205@oracle.com>
	<ED697D7C-F60A-4CD7-B84E-88C10D45B9FB@reini.net>
	<D2DD43D0-5D86-446A-A67A-8D3AEB2541CD@oracle.com>
	<15B58029-95FA-4D9E-AA28-7A6C72D6CB3D@reini.net>
	<13156FAC-6EDC-462B-9BE7-2DFAFB9124FD@oracle.com>
	<20141128201546.000067ce.ecki@zusammenkunft.net>
	<<216A14EF-B62C-4971! -!> <8194-E...>
	<8E1109C5-4C9E-4B7A-924E-9E92B3F93F89@reini.net>
	<150A2C4B-E239-433C-B0C9-39F70E98D837@oracle.com> <5480B9CE.20!
	90600@reini.net>
Message-ID: <DAAE3744-D74C-4528-9498-B7389DC784EF@oracle.com>

Patrick,

> Should those methods also be on the FilterInput- and OutputStream?

I'm not sure I'm following you. j.i.FilterInputStream will get the base version
of InputStream.copyTo method for free as a child though it doesn't define it
itself. Every class down the hierarchy starting from the j.i.InputStream will
get InputStream.copyTo version unless it overrides it.
To override it, it should of course have some rationale behind it. I believe we
have found it for at least two widely used subclasses.

> I'm not quit sure about the impact on may already existing customer code that had implemented such a method without declaring a IOException for example. In this case the existing code would may break? (as a comment of Alan Bateman earlier before)

In the case you've mentioned everything should be just fine (technically) as
overriding method has right to neither throw nor even declare any exceptions
thrown by the parent method.

I said *technically* because the sole fact of overriding doesn't guarantee the 
child's method has the same semantics as the parent's one. 

It seems to me that it?s not the only possible problematic thing here. We'll see.

-Pavel

From ecki at zusammenkunft.net  Thu Dec  4 23:24:30 2014
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 5 Dec 2014 00:24:30 +0100
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>
	<54807258.4040303@oracle.com>
	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>
Message-ID: <20141205002430.000060c9.ecki@zusammenkunft.net>

Hello,

also using a stream in a multi threaded way is quite unusual most of
the implementations I have seen use a atomic solution. This makes
sense considering the fact that especially the close() might be called
by a timeout/cleanup/finalizer/timer/shutdown thread. Using a
AtomicUpdater would reduce the allocation:


volatile boolean closeFlag;
AtomicBoleanFieldUpdater CLOSEUPDATER = new
AtomicBooleanFieldUpdater<>(FilterOutputStream.class, "closeFlag");


close() {
  if (CLOSEUPDATER.compareAndSet(this, false, true) {
    // this is the first closer
  }
}

Let me add a comment that those stream classes are all heavily
overloaded in all parts of code. I think this kind of change is pretty
risky (and most people fixed this and other close insanities in the
derived methods anyway). Unfortunatelly. (remeber the
SupressionException problem?)

Gruss
Bernd



Am Fri, 5 Dec 2014
09:32:12 +1100 schrieb Nathan Clement <nathan.a.clement at hotmail.com>:

> Hi,
> 
> My apologies - the page http://openjdk.java.net/contribute/ gave me
> the impression that I could send the diff as an attachment.  I've
> included it inline below.
> 
> Regards,
> 
> Nathan
> 
> diff --git a/src/share/classes/java/io/FilterOutputStream.java
> b/src/share/classes/java/io/FilterOutputStream.java ---
> a/src/share/classes/java/io/FilterOutputStream.java +++
> b/src/share/classes/java/io/FilterOutputStream.java @@ -47,6 +47,11 @@
>       * The underlying output stream to be filtered.
>       */
>      protected OutputStream out;
> +    
> +    /**
> +     * Whether this stream has already been closed or not
> +     */
> +    protected boolean closed = false;
>  
>      /**
>       * Creates an output stream filter built on top of the specified
> @@ -154,8 +159,11 @@
>       */
>      @SuppressWarnings("try")
>      public void close() throws IOException {
> -        try (OutputStream ostream = out) {
> -            flush();
> +        if (!closed) {
> +            closed = true;
> +            try (OutputStream ostream = out) {
> +                flush();
> +            }
>          }
>      }
>  }
> diff --git a/test/java/io/FilterOutputStream/CloseTwiceTest.java
> b/test/java/io/FilterOutputStream/CloseTwiceTest.java new file mode
> 100644 --- /dev/null
> +++ b/test/java/io/FilterOutputStream/CloseTwiceTest.java
> @@ -0,0 +1,88 @@
> +/*
> + * Copyright (c) 2011, Oracle and/or its affiliates. All rights
> reserved.
> + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
> + *
> + * This code is free software; you can redistribute it and/or modify
> it
> + * under the terms of the GNU General Public License version 2 only,
> as
> + * published by the Free Software Foundation.
> + *
> + * This code is distributed in the hope that it will be useful, but
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
> License
> + * version 2 for more details (a copy is included in the LICENSE
> file that
> + * accompanied this code).
> + *
> + * You should have received a copy of the GNU General Public License
> version
> + * 2 along with this work; if not, write to the Free Software
> Foundation,
> + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
> + *
> + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA
> 94065 USA
> + * or visit www.oracle.com if you need additional information or
> have any
> + * questions.
> + */
> +
> +package java.io.FilterOutputStream;
> +
> +import java.io.BufferedOutputStream;
> +import java.io.ByteArrayInputStream;
> +import java.io.ByteArrayOutputStream;
> +import java.io.IOException;
> +import java.io.InputStream;
> +import java.io.OutputStream;
> +import java.lang.String;
> +import java.util.zip.Deflater;
> +import java.util.zip.DeflaterOutputStream;
> +
> +/**
> + * @test
> + * @bug 8054565
> + * @summary Test that closing a FilterOutputStream twice does not
> cause 
> + *    an exception when the underlying stream throws an exception
> when
> + *    close is called before flush.
> + */
> +
> +public class CloseTwiceTest
> +{
> +    /**
> +     * This stream simulates a OracleBlobOutputStream which will
> throw
> +     * an exception if flush is called after close.
> +     */
> +    static class MockBlobOutputStream extends ByteArrayOutputStream
> +    {
> +        private boolean closed;
> +
> +        @Override
> +        public void flush() throws IOException
> +        {
> +            if (closed) {
> +                throw new IOException("Stream closed");
> +            }
> +        }
> +
> +        @Override
> +        public void close() throws IOException
> +        {
> +            closed = true;
> +        }
> +    }
> +
> +    public static void main( final String[] args ) throws Exception
> +    {
> +        try( InputStream bis = new
> ByteArrayInputStream( "Hello".getBytes() );
> +             OutputStream outStream = new MockBlobOutputStream();
> +             BufferedOutputStream bos = new
> BufferedOutputStream( outStream );
> +             DeflaterOutputStream deflaterStream = new
> DeflaterOutputStream(
> +                 bos, new Deflater( 3 ) ) )
> +        {
> +            int len = 0;
> +            final byte[] buf = new byte[1024];
> +            while ((len = bis.read(buf)) >= 0)
> +            {
> +                if ( len > 0 )
> +                {
> +                    deflaterStream.write(buf,0,len);
> +                }
> +            }
> +        }
> +    }
> +}
> 
> 
> > Date: Thu, 4 Dec 2014 09:40:24 -0500
> > From: roger.riggs at oracle.com
> > To: core-libs-dev at openjdk.java.net
> > Subject: Re: [PATCH] JDK-8054565: FilterOutputStream.close may
> > throw	IOException if called twice and underlying flush or
> > close fails
> > 
> > Hi Nathan,
> > 
> > This list removes attachments.
> > Can the diff's be inlined in the email?
> > 
> > Thanks, Roger
> > 
> > On 12/4/2014 1:18 AM, Nathan Clement wrote:
> > > Hi,
> > >
> > > Here is my suggested fix for the FilterOuputStream issue in
> > > JDK-8054565.  I have been running this fix in my applications for
> > > several weeks (by adding it to the bootstrap classpath) and it
> > > solves my issue.  The fix creates a new member field to remember
> > > whether close has already been called on the stream, and if so,
> > > close() does nothing.
> > >
> > > Attached is the output from hg diff -g
> > >
> > > This is my first attempt at a patch for OpenJDK, so please let me
> > > know if I need to change anything.
> > >
> > > Thanks,
> > >
> > > Nathan
> > >   		 	   		
> > 
>  		 	   		  


From david.holmes at oracle.com  Thu Dec  4 23:27:36 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Dec 2014 09:27:36 +1000
Subject: [8u60] RFR: 8038189: Add cross-platform compact profiles support
In-Reply-To: <54802108.5030300@oracle.com>
References: <547BB1C4.1000303@oracle.com> <547C3296.8000000@oracle.com>
	<547D3F09.5010308@oracle.com> <547FD20E.9020604@oracle.com>
	<54802108.5030300@oracle.com>
Message-ID: <5480EDE8.6030605@oracle.com>

Thanks Erik. Once 8u/dev is open for 8u60 I'll request push approval.

David

On 4/12/2014 6:53 PM, Erik Joelsson wrote:
> Looks good to me.
>
> /Erik
>
> On 2014-12-04 04:16, David Holmes wrote:
>> Updated webrev:
>>
>> http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk.v2/
>>
>> Only changes are to profile-includes.txt.
>>
>> Thanks,
>> David
>>
>> On 2/12/2014 2:24 PM, David Holmes wrote:
>>> Erik,
>>>
>>> Many thanks for the makefile macro wizardry! I will incorporate, test
>>> and return with an updated webreb.
>>>
>>> David
>>>
>>> On 1/12/2014 7:19 PM, Erik Joelsson wrote:
>>>> Hello David,
>>>>
>>>> Most of it looks good, but profile-includes.txt could certainly benefit
>>>> from some reduction in duplication. (Aside from the extension of the
>>>> file itself, which I find a bit weird, but it's already there.) The two
>>>> common structures that I can see are:
>>>> 1. Expanding debuginfo files for macosx.
>>>> 2. Assigning/expanding libraries to the correct variable.
>>>>
>>>> For macosx debuginfo expanding, I would define a macro to something
>>>> like
>>>> this:
>>>>
>>>> # Expand the contents of the .dSYM directories on macosx.
>>>> # Param 1 - debug files list
>>>> # Param 2 - libraries list
>>>> define expand-debuginfo
>>>>    $(if $(and $(filter-out true, $(ZIP_DEBUGINFO_FILES)), $(filter
>>>> macosx, $(OPENJDK_TARGET_OS))), \
>>>>        $(foreach i, $1, $(addsuffix /Contents/Info.plist, $i)) \
>>>>            $(foreach i, $2, $(addsuffix /Contents/Resources/DWARF/$i,
>>>> $(filter $i.%, $1))), \
>>>>        $1)
>>>> endef
>>>>
>>>> And use it like this:
>>>>
>>>> PROFILE_1_DEBUG_FILES := $(call expand-debuginfo,
>>>> $(PROFILE_1_DEBUG_FILES), $(PROFILE_1_LIBRARIES))
>>>>
>>>> Filtering out jsig can be done on the parameters at the macro call.
>>>>
>>>> For the conditional addprefix of OPENJDK_TARGET_CPU_LEGACY_LIB, I would
>>>> do something like:
>>>>
>>>> ifeq (, $(findstring $(OPENJDK_TARGET_OS), windows macosx))
>>>>    LIB_SUBDIR := $(OPENJDK_TARGET_CPU_LEGACY_LIB)/
>>>> else
>>>>    LIB_SUBDIR :=
>>>> endif
>>>>
>>>> And then always assign PROFILE_*_JRE_LIB_FILES with $(addprefix
>>>> $(LIB_SUBDIR), ...). The conditional on Windows for assigning to
>>>> ...BIN_FILES or ...LIB_FILES I would leave in place since I don't think
>>>> a macro solution would make it easier to understand.
>>>>
>>>> /Erik
>>>>
>>>>
>>>> On 2014-12-01 01:09, David Holmes wrote:
>>>>> Main bug is 8038189 but that is a closed bug, the open backport issue
>>>>> is:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8066200
>>>>>
>>>>> Compact Profiles support was added in 8, but only for the Linux
>>>>> platform. I've now generalized this support to all the other
>>>>> platforms. This is an 8u only change, targetting 8u60, as soon as the
>>>>> jdk8u/dev starts accepting things for 8u60.
>>>>>
>>>>> The changes are not that extensive - mostly generalizing the lists and
>>>>> accounting for different platforms putting files into different places
>>>>> (jre/lib/<arch> vs jre/lib vs jre/bin). It isn't necessary to produce
>>>>> detailed per-platform lists as files that don't exist simply don't get
>>>>> copied; but when files are obviously platform specific then I add them
>>>>> under suitable guards.
>>>>>
>>>>> The biggest complexity comes from the debuginfo files, and in
>>>>> particular unzipped debuginfo files. This accounts for the bulk of the
>>>>> changes in profiles-includes.txt, as we try to identify the set of
>>>>> debug files that might exist for each library (and OSX is the main
>>>>> complication due to the .dSYM directory because the existing rules
>>>>> only copy files not directories). Suggestions for reducing the
>>>>> duplicated patterns would be appreciated.
>>>>>
>>>>> Platform specific contents were determined in conjunction with
>>>>> examination of what Jigsaw is using in JDK 9 for the base module.
>>>>>
>>>>> I tested all the main platforms (Windows, Linux, Solaris and OSX) and
>>>>> with/without zipping of debuginfo files. Note that Windows builds will
>>>>> not work with unzipped debuginfo files due to 8025936, but I checked
>>>>> that multiple debug info files were expanded into the right set of
>>>>> targets.
>>>>>
>>>>> webrevs:
>>>>>
>>>>> http://cr.openjdk.java.net/~dholmes/8038189/webrev.top/
>>>>>
>>>>> make/Main.gmk:
>>>>>  - Remove the os-check that constrained profiles to linux
>>>>>
>>>>> http://cr.openjdk.java.net/~dholmes/8038189/webrev.jdk/
>>>>>
>>>>> make/CreateJars.gmk:
>>>>>  - Check for empty variables (Solaris doesn't like them)
>>>>>  - Fix # # comments
>>>>>  - Add explicit targets for the beanless classes with $ in them (the %
>>>>> substitution doesn't work on all platforms when $ is also present)
>>>>>
>>>>> make/Images.gmk
>>>>>  - Don't filter out server VM from compact profiles
>>>>>
>>>>> make/Import.gmk
>>>>>  - Add Info.plist to the exported files (for unzipped debuginfo files
>>>>> - this is a general fix not profiles specific so may warrant its
>>>>> own CR)
>>>>>
>>>>> make/Profiles.gmk
>>>>>  - Remove linux-only comment
>>>>>
>>>>> make/Tools.gmk
>>>>>  - Fix tool definitions to use $(PATH_SEP) and quote cp entries
>>>>>
>>>>> make/profile-includes.txt
>>>>>  - Bulk of changes as described above
>>>>>
>>>>> make/profile-rtjar-includes.txt
>>>>>  - Additional packages that exist on OSX only (but don't need to be
>>>>> conditionally added)
>>>>>  - NOTE: if AIX or other platform add platform specific packages not
>>>>> already included by an enclosing package, then they will also need to
>>>>> be added
>>>>>
>>>>> Thanks,
>>>>> David
>>>>
>


From david.holmes at oracle.com  Thu Dec  4 23:36:08 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Dec 2014 09:36:08 +1000
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <54809627.8070103@oracle.com>
References: <547F9302.3060309@oracle.com>
	<547FD6F2.5060400@oracle.com>	<548023D0.4020702@oracle.com>
	<548047C3.8000400@oracle.com>	<54804E4B.2070908@oracle.com>
	<5480529F.1020902@oracle.com> <54805B5D.5020504@oracle.com>
	<54809627.8070103@oracle.com>
Message-ID: <5480EFE8.3090809@oracle.com>

Hi Daniel,

I still find your use of the classloader very confusing. You talk about 
the defining loader but you never check the defining loader against 
anything. In

  146         static void checkFor(Class<?> c, ClassLoader loader) {

the loader variable is never used. And if loader is simply the name of 
the loader passed to forName, then it may not be the defining loader 
anyway - so the whole use of this loader variable seems superfluous at 
best, and confusing/misleading at worst. And you can use the simple 
forName(name) variant rather than passing a loader.

David

On 5/12/2014 3:13 AM, Daniel Fuchs wrote:
> On 04/12/14 14:02, Se?n Coffey wrote:
>> Thanks for driving efforts in this area Daniel. I think it's a very
>> useful test and is bound to help test code coverage. If it's currently
>> passing on all JPRT platforms, it's a good measure.
>
> It seems to :-)
>
>> Eventually I think we can bulk up the tests that can be run on the
>> Iterable returned from your class search.
>> At moment you just test Field.setAccessible.
>
> Yes. If we change it later to test more, we will probably need to
> change its name. I was already in lack of inspiration:
> FieldSetAccessibleTest is not really a great name - but hopefully
> it can do for now.
>
>> In the future, I don't see any harm in adding all simple Field method
>> calls so that any corner cases in custom classes like the original issue
>> are caught. e.g Field.getDeclaredAnnotations(), Field.getModifiers(),
>> Field.isEnumConstant() etc., etc. Some methods won't be much value add
>> but they're not a cost either.
>
> Agreed.
>
>> Same argument for running through all Class methods, e.g
>> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a result this
>> test might eventually become more general in test goal and might live
>> better one level up in "test/java/lang/Class/" - it can be moved when
>> the time comes.
>
> Agreed as well :-)
>
> Here is a new revision of the webrev for 9 in which I have
> incorporated David's comment:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/
>
> best regards,
>
> -- daniel
>
>>
>> regards,
>> Sean.
>>
>> On 04/12/2014 12:25, Daniel Fuchs wrote:
>>> On 04/12/14 13:06, David Holmes wrote:
>>>> Hi Daniel,
>>>>
>>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
>>>>> Hi David,
>>>>>
>>>>> In fact I could use 'null' on JDK 9 as well.
>>>>> My first version of the JDK 9 test was parsing over all the .jimage
>>>>> files under <jdk>/lib/modules - which explain why I needed to
>>>>> use the System class loader.
>>>>>
>>>>> Then I switched to only parsing the bootmodules.jimage - because
>>>>> I noticed that the results where more coherent with what I had
>>>>> observed on 8 & 7 - but I kept using the System class loader.
>>>>>
>>>>> I am not sure whether we want the test for 9 should iterate over
>>>>> the three .jimage - or continue to test only the boot .jimage.
>>>>>
>>>>> I have updated the JDK 9 test (refreshed the webrev in place)
>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/
>>>>> and added support for possibly running the test in the two modes
>>>>> (I added a 'test.boot.only' system property, true by default)
>>>>> as well as additional traces to print the loaded classes by
>>>>> defining loader at the end (test.list.classes, false by default).
>>>>
>>>> A couple of initial comments:
>>>>
>>>>   104     static ClassLoader getClassLoaderFor(String classFileName) {
>>>>   105         if (restrictToBoot) return null; // only bootmodules
>>>>   106         return ClassLoaders.systemClassLoader;
>>>>   107     }
>>>>
>>>> I'm not clear the intent here. If it is to return a loader for which
>>>> loadClass could be invoked then you can always just return the system
>>>> loader - or just Class.forName. If it is meant to the return the
>>>> expected defining loader then it isn't doing that as the extensions
>>>> loader is not allowed for.
>>>
>>> The intent is to return the class loader that will be passed to
>>> Class.forName( ). I've been fiddling & experimenting with this
>>> test over 3 different platforms while trying to minimize the
>>> differences - so that was my attempt at having a good place to
>>> experiment with different strategy for loading classes.
>>>
>>>> Similarly for:
>>>>
>>>>   128         static ClassLoader getFor(String classFileName) {
>>>>   129             return systemClassLoader;
>>>>   130         }
>>>
>>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..)
>>> was supposed to simply return ClassLoaders.getFor(...);
>>> and all the code should be in ClassLoaders.getFor - my bad.
>>>
>>>> Minor nit - In:
>>>>
>>>> 135                     System.err.println("Unexpected loader for
>>>> "+c+":
>>>> "+c.getClassLoader());
>>>>
>>>> c.getClassLoader() can be replaced by cl. Also put spaces around the +
>>>> operator.
>>>
>>> Good catch.
>>>
>>> Thanks a lot David! Have a good night! (that's quite late - isn't it?)
>>>
>>> -- daniel
>>>
>>>>
>>>> David
>>>> (signing off for the night)
>>>>
>>>>> Thanks for your question, it triggered me into looking deeper
>>>>> into what was happening :-)
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>>
>>>>> On 04/12/14 10:05, Daniel Fuchs wrote:
>>>>>>>> The differences between 8 & 9 are limited to:
>>>>>>>>
>>>>>>>>     - ClassLoader:
>>>>>>>>          - on 8 we use 'null' (BCL)
>>>>>>>>          - on 9 we use the system class loader.
>>>>>>>
>>>>>>> I haven't seen anything in JEP 220, regarding modules, that
>>>>>>> indicates
>>>>>>> that classes currently loaded  by the boot-loader will now be loaded
>>>>>>> by the system classloader ???
>>>>>>
>>>>>> In [1] towards the end:
>>>>>>
>>>>>> [1] http://openjdk.java.net/jeps/220
>>>>>>
>>>>>> "The defining class loader of the types in some existing packages
>>>>>>   will change. Existing code that makes assumptions about the class
>>>>>>   loaders of these types might not work correctly."
>>>>>>   (then there is a list of specific changes).
>>>>>>
>>>>>> This test looks up all class names in the image files and attempt
>>>>>> to load the corresponding class. But as indicated in [1]
>>>>>> some of these classes are now in the Boot CL, some in the
>>>>>> Extension CL, and some in the Application CL.
>>>>>>
>>>>>> So the test uses the System CL to load each class - which ensures
>>>>>> that the loading will be delegated to the appropriate ClassLoader.
>>>>>>
>>>>>> best regards,
>>>>>>
>>>>>> -- daniel
>>>>>
>>>
>>
>


From david.holmes at oracle.com  Thu Dec  4 23:46:42 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Dec 2014 09:46:42 +1000
Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation
	fault
In-Reply-To: <5480178A.9090709@oracle.com>
References: <545D939D.2030308@oracle.com>
	<5463B896.10801@oracle.com>	<54641ADE.8030504@oracle.com>
	<546BC35E.4070402@oracle.com>	<546C5986.6010500@oracle.com>
	<546C6D1A.8050903@oracle.com>	<546CBCAB.7040101@oracle.com>
	<547D265A.20005@oracle.com> <547F0889.5050204@oracle.com>
	<5480178A.9090709@oracle.com>
Message-ID: <5480F262.9010407@oracle.com>

Looks good to me too Chris - sorry for the delay getting back to you. 
But at least Kumar spotted all the typos :)

David

On 4/12/2014 6:12 PM, Chris Plummer wrote:
> On 12/3/14 4:56 AM, Alan Bateman wrote:
>> On 02/12/2014 02:39, Chris Plummer wrote:
>>> Sorry about the long delay in getting back to this. I ran into two
>>> separate JPRT issues that were preventing me from testing these
>>> changes, plus I was on vacation last week. Here's an updated webrev.
>>> I'm not sure where we left things, so I'll just say what's changed
>>> since the original version:
>>>
>>> 1. Rewrote the test to be in Java instead of a shell script.
>>> 2. Moved the test from hotspot/test/runtime/memory to
>>> jdk/test/tools/launcher
>>> 3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to
>>> override the default 32k minimum value.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-6762191
>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/
>> This looks to me. A minor comment for java.c is that this code uses
>> 4-space indent (different to hotspot).
>>
>> The test looks okay too, you might just checking the copyright date as
>> I assume was not written in 2010. Also I think the import of
>> java.io.File may be left behind from the previous round.
>>
>> -Alan
> Hi Alan,
>
> While removing the java.io.File import, I also questioned why I had
> java.io.IOException being imported. There were a couple of methods that
> declared it thrown, and the main method therefore had to catch it, but
> it turns out this was just copy/paste from the Settings.java test I used
> as a template, and is not actually needed. I removed the import, throws,
> and try/catch of IOException.
>
> All the other issues mentioned by others have also been addressed. A new
> webrev can be found at:
>
> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.03/
>
> thanks,
>
> Chris


From pavel.rappo at oracle.com  Thu Dec  4 23:54:10 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 4 Dec 2014 23:54:10 +0000
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <20141205002430.000060c9.ecki@zusammenkunft.net>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>
	<54807258.4040303@oracle.com>
	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>
	<20141205002430.000060c9.ecki@zusammenkunft.net>
Message-ID: <2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>

> Hello,
> 
> also using a stream in a multi threaded way is quite unusual most of
> the implementations I have seen use a atomic solution.

Bernd, as far as I understand we are not talking about concurrent-proof solution
for the j.i.FilterOutputStream as this class is sure not even thread-safe. Most
of the subclasses provide their own implementation of close. If they feel they
should be thread-safe it's their responsibility to support it.

> Let me add a comment that those stream classes are all heavily
> overloaded in all parts of code. I think this kind of change is pretty
> risky (and most people fixed this and other close insanities in the
> derived methods anyway). Unfortunatelly. (remeber the
> SupressionException problem?)

I can?t see why this particular change is risky. We're just trying to make the
java.io.FilterOutputStream.close obey the java.io.Closeable.close contract.

-Pavel

From dl at cs.oswego.edu  Fri Dec  5 00:22:57 2014
From: dl at cs.oswego.edu (Doug Lea)
Date: Thu, 04 Dec 2014 19:22:57 -0500
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <F498D1ED-6C4B-4F5B-8F82-036715009EEC@oracle.com>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>	<547DEC01.2050501@gmail.com>	<547DF89A.2020809@oracle.com>	<CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>	<547F2BC1.6040904@cs.oswego.edu>	<CA+kOe0_h2EBbY51qh7MSUFpq44FpOspgtBVF6qVWENMwW2O0xA@mail.gmail.com>	<547F4A9D.3060805@cs.oswego.edu>	<CA+kOe08vnvXtDE_Xv+6iqtpBaRR3MpdeRV0OtksqMJ_aJpi9Dg@mail.gmail.com>	<547F8B84.6090301@cs.oswego.edu>	<CA+kOe0_D0yxDEWq4DNQN_DL-yv-+Am3gFx_Foq-G63BDkrSHuQ@mail.gmail.com>	<5480195B.4070800@gmail.com>
	<F498D1ED-6C4B-4F5B-8F82-036715009EEC@oracle.com>
Message-ID: <5480FAE1.4080909@cs.oswego.edu>

On 12/04/2014 04:40 AM, Paul Sandoz wrote:
>
> There is already a mechanism to create a cryptographically strong seed by
> setting a system property and using SecureRandom. That has a high
> initialization cost, but i think under those circumstances that cost is
> acceptable (it may well be possible to reduce that cost but i consider that
> to be a separate issue).
>
> For the default case what we need is something with low initialization cost
> that is *good enough* for the majority of cases e.g. documents the lower
> bound of cryptographic strength.

Further, in these cases, we are not concerned about cryptographic strength
in terms of algorithmic unpredictability by attackers. The default
constructor methods promise only to use a seed that is highly
likely to differ across invocations, including those of different programs
running on different machines. Using initial system seeds that include
some environmental entropy is the best way to get the first seed.
It just so happens that crypto-based RNGs need to do this as well,
so we use the cheapest forms of them that we can (or just use a time
based seed on failure). Good-quality PRNG techniques produce
more default-constructor seeds after the first one.
Because Random, SplittableRandom, and ThreadLocalRandom all use the
same basic approach, they can/should use the same mechanism.
Placing the mechanics in TLR seems to work out best.
In which case only TLR needs a static atomically updated seed
initialized from system seed, further reducing static init overhead.
I think I've convinced myself that this is the most promising approach,
so hope to try it out based on Peter's versions some time in
the next few days.

Relately, Guy Steele and I have been sporadically investigating
minor algorithmic and implementation improvements for SR and TLR
(including systematic tests of more than 2500 variants). I suspect
that we will settle on one of these sometime in the next few months.

(Also, at some point we might reconsider our cowardice about not
improving the internal java.util.Random algorithm. j.u.Random is
much more commonly used, and does not fare well on quality tests.
On the other hand, the more that users instead choose to use
SR or TLR, the better.)

-Doug



From serguei.spitsyn at oracle.com  Fri Dec  5 00:38:35 2014
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 04 Dec 2014 16:38:35 -0800
Subject: [9] RFR (S) 6762191: Setting stack size to 16K causes segmentation
	fault
In-Reply-To: <5480F262.9010407@oracle.com>
References: <545D939D.2030308@oracle.com>
	<5463B896.10801@oracle.com>	<54641ADE.8030504@oracle.com>
	<546BC35E.4070402@oracle.com>	<546C5986.6010500@oracle.com>
	<546C6D1A.8050903@oracle.com>	<546CBCAB.7040101@oracle.com>
	<547D265A.20005@oracle.com> <547F0889.5050204@oracle.com>
	<5480178A.9090709@oracle.com> <5480F262.9010407@oracle.com>
Message-ID: <5480FE8B.5010301@oracle.com>

It still looks good to me too. :)

Thanks,
Serguei

On 12/4/14 3:46 PM, David Holmes wrote:
> Looks good to me too Chris - sorry for the delay getting back to you. 
> But at least Kumar spotted all the typos :)
>
> David
>
> On 4/12/2014 6:12 PM, Chris Plummer wrote:
>> On 12/3/14 4:56 AM, Alan Bateman wrote:
>>> On 02/12/2014 02:39, Chris Plummer wrote:
>>>> Sorry about the long delay in getting back to this. I ran into two
>>>> separate JPRT issues that were preventing me from testing these
>>>> changes, plus I was on vacation last week. Here's an updated webrev.
>>>> I'm not sure where we left things, so I'll just say what's changed
>>>> since the original version:
>>>>
>>>> 1. Rewrote the test to be in Java instead of a shell script.
>>>> 2. Moved the test from hotspot/test/runtime/memory to
>>>> jdk/test/tools/launcher
>>>> 3. Added STACK_SIZE_MINIMUM to java.c, allowing a makefile to
>>>> override the default 32k minimum value.
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-6762191
>>>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.02/
>>> This looks to me. A minor comment for java.c is that this code uses
>>> 4-space indent (different to hotspot).
>>>
>>> The test looks okay too, you might just checking the copyright date as
>>> I assume was not written in 2010. Also I think the import of
>>> java.io.File may be left behind from the previous round.
>>>
>>> -Alan
>> Hi Alan,
>>
>> While removing the java.io.File import, I also questioned why I had
>> java.io.IOException being imported. There were a couple of methods that
>> declared it thrown, and the main method therefore had to catch it, but
>> it turns out this was just copy/paste from the Settings.java test I used
>> as a template, and is not actually needed. I removed the import, throws,
>> and try/catch of IOException.
>>
>> All the other issues mentioned by others have also been addressed. A new
>> webrev can be found at:
>>
>> http://cr.openjdk.java.net/~cjplummer/6762191/webrev.03/
>>
>> thanks,
>>
>> Chris



From nathan.a.clement at hotmail.com  Fri Dec  5 00:49:26 2014
From: nathan.a.clement at hotmail.com (Nathan Clement)
Date: Fri, 5 Dec 2014 11:49:26 +1100
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>
	<54807258.4040303@oracle.com>
	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>
	<20141205002430.000060c9.ecki@zusammenkunft.net>,
	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>
Message-ID: <COL131-W70AF8AFB5ECF1C626BECACCA790@phx.gbl>

Hi,

My problem is definitely not related to multi-threaded use.  The test shows basically the same code that we have in production that experienced the problem.  The stream is used from a single thread in a try-with-resources block.

I don't see that this change is any more risky than the change that introduced this bug.  I'm more than happy to have the bug fixed in a different way - this is just the first solution that occurred to me.

Regards,

Nathan

> Subject: Re: [PATCH] JDK-8054565: FilterOutputStream.close may throw IOException if called twice and underlying flush or close fails
> From: pavel.rappo at oracle.com
> Date: Thu, 4 Dec 2014 23:54:10 +0000
> CC: nathan.a.clement at hotmail.com; core-libs-dev at openjdk.java.net
> To: ecki at zusammenkunft.net
> 
> > Hello,
> > 
> > also using a stream in a multi threaded way is quite unusual most of
> > the implementations I have seen use a atomic solution.
> 
> Bernd, as far as I understand we are not talking about concurrent-proof solution
> for the j.i.FilterOutputStream as this class is sure not even thread-safe. Most
> of the subclasses provide their own implementation of close. If they feel they
> should be thread-safe it's their responsibility to support it.
> 
> > Let me add a comment that those stream classes are all heavily
> > overloaded in all parts of code. I think this kind of change is pretty
> > risky (and most people fixed this and other close insanities in the
> > derived methods anyway). Unfortunatelly. (remeber the
> > SupressionException problem?)
> 
> I can?t see why this particular change is risky. We're just trying to make the
> java.io.FilterOutputStream.close obey the java.io.Closeable.close contract.
> 
> -Pavel
 		 	   		  

From ecki at zusammenkunft.net  Fri Dec  5 00:58:27 2014
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 5 Dec 2014 01:58:27 +0100
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>
	<54807258.4040303@oracle.com>
	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>
	<20141205002430.000060c9.ecki@zusammenkunft.net>
	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>
Message-ID: <20141205015827.00007ac6.ecki@zusammenkunft.net>

Am Thu, 4 Dec 2014 23:54:10 +0000
schrieb Pavel Rappo <pavel.rappo at oracle.com>:

> Bernd, as far as I understand we are not talking about
> concurrent-proof solution for the j.i.FilterOutputStream as this
> class is sure not even thread-safe.

It is used very much, also in concurrent context. As I explained the
close() operation is very likely to happen in different threads
(especially in situation where it is called multiple times in addition
to the regular close of the using thread). Thats why I think it might
be a good idea to make this function thread safe.

> I can?t see why this particular change is risky. We're just trying to
> make the java.io.FilterOutputStream.close obey the
> java.io.Closeable.close contract.

Well, it changes the behavior of all custom classes which extend
FilterStream (and since this was a base class made to be extended,
there are many). For example if somebody depends on getting an error on
close() from a wrapped stream even when close is called multiple times
(by timeout thread) you will no longer get that error but a clean
return of the second attempt.

It might not be spec compliant to rely on this. But my own experience
is I modified lots of minor details of the FilterOutputStream in
overwritten methods by first inspecting the implementation. And I cant
be the only one.

Gruss
Bernd


From weijun.wang at oracle.com  Fri Dec  5 01:00:27 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Fri, 5 Dec 2014 09:00:27 +0800
Subject: Should some JDK system properties be read only ?
In-Reply-To: <5480992E.1010007@oracle.com>
References: <548080D0.1090506@oracle.com> <5480992E.1010007@oracle.com>
Message-ID: <DAB0DD4E-DB23-4B43-A3B4-F0A0B582D530@oracle.com>

A System.setFinalProperty() method that creates a new property with a final value? Maybe also a System.isFinalProperty() method allowing people to detect if a property is final.

--Max



From ecki at zusammenkunft.net  Fri Dec  5 01:02:45 2014
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Fri, 5 Dec 2014 02:02:45 +0100
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <COL131-W70AF8AFB5ECF1C626BECACCA790@phx.gbl>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>
	<54807258.4040303@oracle.com>
	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>
	<20141205002430.000060c9.ecki@zusammenkunft.net>
	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>
	<COL131-W70AF8AFB5ECF1C626BECACCA790@phx.gbl>
Message-ID: <20141205020245.0000680f.ecki@zusammenkunft.net>

Am Fri, 5 Dec 2014 11:49:26 +1100
schrieb Nathan Clement <nathan.a.clement at hotmail.com>:

> Hi,
> 
> My problem is definitely not related to multi-threaded use.  The test
> shows basically the same code that we have in production that
> experienced the problem.

Of course it can be triggered single threaded. But this does not mean
you should not fix it for concurrent use as well (for the reasons
mentioned).

> I don't see that this change is any more risky than the change that
> introduced this bug.  I'm more than happy to have the bug fixed in a
> different way - this is just the first solution that occurred to me.

Well, the change which introduced the bug (and others in this area) are
risky and did break things. I just want to make sure you are aware of
it. I feel that its not worth fixing, but its not my call.

However your problem is easily solved in an overwritten close() method.
I bet you will not wait for this to hit a production ready Java, anyway.

Gruss
Bernd


From vitalyd at gmail.com  Fri Dec  5 01:18:20 2014
From: vitalyd at gmail.com (Vitaly Davidovich)
Date: Thu, 4 Dec 2014 20:18:20 -0500
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <20141205015827.00007ac6.ecki@zusammenkunft.net>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>
	<54807258.4040303@oracle.com>
	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>
	<20141205002430.000060c9.ecki@zusammenkunft.net>
	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>
	<20141205015827.00007ac6.ecki@zusammenkunft.net>
Message-ID: <CAHjP37HgKZMhjq6_AVZFAdPy4PeZBd7p6JBT0Jt2FqE42eB6Ow@mail.gmail.com>

But where does it say that this class can be used in a concurrent context?
This class is documented as serving a base class role, yes, but it has
state.  It's the user/subclass responsibility to provide threadsafety, as
far as I see.  Attempting to make close() atomic just makes the next reader
confused when the rest of the class isn't and may also penalize single
threaded callers of close().

If someone were using this class in a non threadsafe manner when safety is
needed, it's no different than one using, say, HashMap unsafely and simply
getting lucky all this time.

Sent from my phone
On Dec 4, 2014 7:58 PM, "Bernd Eckenfels" <ecki at zusammenkunft.net> wrote:

> Am Thu, 4 Dec 2014 23:54:10 +0000
> schrieb Pavel Rappo <pavel.rappo at oracle.com>:
>
> > Bernd, as far as I understand we are not talking about
> > concurrent-proof solution for the j.i.FilterOutputStream as this
> > class is sure not even thread-safe.
>
> It is used very much, also in concurrent context. As I explained the
> close() operation is very likely to happen in different threads
> (especially in situation where it is called multiple times in addition
> to the regular close of the using thread). Thats why I think it might
> be a good idea to make this function thread safe.
>
> > I can?t see why this particular change is risky. We're just trying to
> > make the java.io.FilterOutputStream.close obey the
> > java.io.Closeable.close contract.
>
> Well, it changes the behavior of all custom classes which extend
> FilterStream (and since this was a base class made to be extended,
> there are many). For example if somebody depends on getting an error on
> close() from a wrapped stream even when close is called multiple times
> (by timeout thread) you will no longer get that error but a clean
> return of the second attempt.
>
> It might not be spec compliant to rely on this. But my own experience
> is I modified lots of minor details of the FilterOutputStream in
> overwritten methods by first inspecting the implementation. And I cant
> be the only one.
>
> Gruss
> Bernd
>


From david.holmes at oracle.com  Fri Dec  5 01:36:12 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Dec 2014 11:36:12 +1000
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>
	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>
Message-ID: <54810C0C.2080901@oracle.com>

Martin,

On 2/12/2014 6:46 AM, Martin Buchholz wrote:
> David, Paul (i.e. Reviewers) and Doug,
>
> I'd like to commit corrections so we make progress.

Is this finalized then? You can only make one commit per CR.

> I think the current webrev is simple progress with the exception of my
> attempt to translate volatiles into fences, which is marginal (but was
> a good learning exercise for me).

I still find this entire comment block to be misguided and misplaced:

!     // Fences, also known as memory barriers, or membars.
!     // See hotspot sources for more details:
!     // orderAccess.hpp memnode.hpp unsafe.cpp
!     //
!     // One way of implementing Java language-level volatile variables 
using
!     // fences (but there is often a better way without) is by:
!     // translating a volatile store into the sequence:
!     // - storeFence()
!     // - relaxed store
!     // - fullFence()
!     // and translating a volatile load into the sequence:
!     // - if (CPU_NOT_MULTIPLE_COPY_ATOMIC) fullFence()
!     // - relaxed load
!     // - loadFence()
!     // The full fence on volatile stores ensures the memory model 
guarantee of
!     // sequential consistency on most platforms.  On some platforms 
(ppc) we
!     // need an additional full fence between volatile loads as well (see
!     // hotspot's CPU_NOT_MULTIPLE_COPY_ATOMIC).

why do want this description here - it has no relevance to the API 
itself, nor to how volatiles are implemented in the VM. And as I said in 
the bug report CPU_NOT_MULTIPLE_COPY_ATOMIC exists only for platforms 
that want to implement IRIW (none of our platforms are 
multiple-copy-atomic, but only PPC sets this so that it employs IRIW).

David


From david.holmes at oracle.com  Fri Dec  5 01:55:22 2014
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 05 Dec 2014 11:55:22 +1000
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>
	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>
Message-ID: <5481108A.3030605@oracle.com>

On 2/12/2014 6:46 AM, Martin Buchholz wrote:
> David, Paul (i.e. Reviewers) and Doug,
>
> I'd like to commit corrections so we make progress.
>
> I think the current webrev is simple progress with the exception of my
> attempt to translate volatiles into fences, which is marginal (but was
> a good learning exercise for me).

Looking at the actual API changes ...

In general phrasing like: " also known as a LoadLoad plus LoadStore 
barrier ..." is misleading to me as these are not "aliases"- the 
loadFence (in this case) is being specified to have the same semantics 
as the loadload|storeload. It should say "corresponds to a LoadLoad plus 
LoadStore barrier" - as per the "Corresponds to a C11 ...". And 
referring to things like "load-acquire fence" is meaningless without 
some reference to a definition - who defines a load-acquire fence? Is 
there a universal definition? I would be okay with something looser eg:

/**
   * Ensures that loads before the fence will not be reordered with 
loads and
   * stores after the fence. Corresponds to a LoadLoad plus LoadStore 
barrier,
   * and also to the C11 atomic_thread_fence(memory_order_acquire).
   * Sometimes referred to as a "load-acquire fence".
   *

Also I find this comment strange:

!      * A pure StoreStore fence is not provided, since the addition of 
LoadStore
!      * is almost always desired, and most current hardware 
instructions that
!      * provide a StoreStore barrier also provide a LoadStore barrier 
for free.

because inside hotspot we use storeStore barriers a lot, without any 
loadStore at the same point.

David


From joe.darcy at oracle.com  Fri Dec  5 02:23:12 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 04 Dec 2014 18:23:12 -0800
Subject: JDK 9 RFR of JDK-8066641: Suppress deprecation warnings in jdk.naming
	module
Message-ID: <54811710.3040607@oracle.com>

Hello,

Please review the small fix below for

     JDK-8066641: Suppress deprecation warnings in jdk.naming module

Thanks,

-Joe

diff -r ab3ff449ba9a 
src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java
--- 
a/src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java 
Thu Dec 04 15:04:11 2014 -0800
+++ 
b/src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java 
Thu Dec 04 18:22:35 2014 -0800
@@ -1,5 +1,5 @@
  /*
- * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights 
reserved.
+ * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights 
reserved.
   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
   *
   * This code is free software; you can redistribute it and/or modify it
@@ -353,6 +353,7 @@
      /**
       * Wrap a RemoteException inside a NamingException.
       */
+    @SuppressWarnings("deprecation")
      public static NamingException wrapRemoteException(RemoteException 
re) {

          NamingException ne;
@@ -413,6 +414,7 @@
       * Attempts to install a security manager if none is currently in
       * place.
       */
+    @SuppressWarnings("deprecation")
      private static void installSecurityMgr() {

          try {



From lance.andersen at oracle.com  Fri Dec  5 02:29:13 2014
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Thu, 4 Dec 2014 21:29:13 -0500
Subject: JDK 9 RFR of JDK-8066641: Suppress deprecation warnings in
	jdk.naming module
In-Reply-To: <54811710.3040607@oracle.com>
References: <54811710.3040607@oracle.com>
Message-ID: <ADCF11D1-DAF0-4563-BADB-A57D801E6BB2@oracle.com>

+1


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com
Sent from my iPad

> On Dec 4, 2014, at 9:23 PM, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Please review the small fix below for
> 
>    JDK-8066641: Suppress deprecation warnings in jdk.naming module
> 
> Thanks,
> 
> -Joe
> 
> diff -r ab3ff449ba9a src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java
> --- a/src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java Thu Dec 04 15:04:11 2014 -0800
> +++ b/src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java Thu Dec 04 18:22:35 2014 -0800
> @@ -1,5 +1,5 @@
> /*
> - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1999, 2014, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
> @@ -353,6 +353,7 @@
>     /**
>      * Wrap a RemoteException inside a NamingException.
>      */
> +    @SuppressWarnings("deprecation")
>     public static NamingException wrapRemoteException(RemoteException re) {
> 
>         NamingException ne;
> @@ -413,6 +414,7 @@
>      * Attempts to install a security manager if none is currently in
>      * place.
>      */
> +    @SuppressWarnings("deprecation")
>     private static void installSecurityMgr() {
> 
>         try {
> 


From youdwei at linux.vnet.ibm.com  Fri Dec  5 02:39:22 2014
From: youdwei at linux.vnet.ibm.com (deven you)
Date: Fri, 5 Dec 2014 10:39:22 +0800
Subject: FilePermission Canonical path optimization
In-Reply-To: <EBD2F710-DFBB-4C27-86EA-8E6825C86208@oracle.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
	<EBD2F710-DFBB-4C27-86EA-8E6825C86208@oracle.com>
Message-ID: <CADsbJLmkjA=rMAWL1w3VOVm46_2tY9h_wKqKPhUAQRAaVo0xzg@mail.gmail.com>

Hi Weijun,

The original init() methods invoked by FilePermission constructors and
readObject() for deserialization. The constructors will be invoked only
once for each FilePermission Object and the ObjectInputStream will create
new FilePermission for each deserialization so the old init() is fine
without synchronization. This patch however requires there is only one
thread invokes the get_dir_rec() method to construct the cpath so it's true
this method need syncrhonization. I will update the patch later accordingly.

Thanks a lot!


2014-12-01 16:36 GMT+08:00 Wang Weijun <weijun.wang at oracle.com>:

> Do you need some kind of synchronization on the get_dir_rec() method?
>
> --Max
>
> > On Dec 1, 2014, at 16:06, deven you <youdwei at linux.vnet.ibm.com> wrote:
> >
> > Hi All,
> > File.getCanonicalPath() is a very time-consuming method, we observed
> > significant performance degradation from some application's startup stage
> > with java.io.FilePermission. However, lazying load the calls to
> > getCanonicalPath() from java.ioFilePermission is straightforward and
> solve
> > this problem effectively. Openjdk bug[1]  tracks this bug and here is the
> > patch [2]. Could anyone take a look?
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8066211
> > [2] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.00/
>
>


From ydwchina at gmail.com  Fri Dec  5 02:39:27 2014
From: ydwchina at gmail.com (deven you)
Date: Fri, 5 Dec 2014 10:39:27 +0800
Subject: FilePermission Canonical path optimization
In-Reply-To: <547C6432.5050003@oracle.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
	<547C6432.5050003@oracle.com>
Message-ID: <CADsbJLkL_NE0GbT_uB3xwSZc+XYi1dHACabwjCApaXr=h-UkLQ@mail.gmail.com>

Hi Alan,

I am not clear whether canonicalization cache enabled or disabled, however
I think even the cache is enable, it may not help much for the start up
stage especially if the app uses many different files.

The cache should speed up applications for common case especially after
start up and this patch will specifically solve the problem for
FilePermssion.

I will update the patch soon with your suggestion and Wenjian's.

Thanks a lot!



2014-12-01 20:50 GMT+08:00 Alan Bateman <Alan.Bateman at oracle.com>:

> On 01/12/2014 08:06, deven you wrote:
>
>> Hi All,
>>   File.getCanonicalPath() is a very time-consuming method, we observed
>> significant performance degradation from some application's startup stage
>> with java.io.FilePermission. However, lazying load the calls to
>> getCanonicalPath() from java.ioFilePermission is straightforward and solve
>> this problem effectively. Openjdk bug[1]  tracks this bug and here is the
>> patch [2]. Could anyone take a look?
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8066211
>> [2] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.00/
>>
>
> Do you run with canonicalization cache enabled or disabled? While I don't
> agree with this cache, it seem to mostly eliminate complaints in this area
> after it was added (in JDK 1.4 I think).
>
> As regards the patch then it is a bit ugly. Could you use cpath == null
> instead of introducing a flag? If a flag is required then I think it will
> need a better name. Also if init is split then it might be cleaner to have
> initMask and initCanonicalPath.
>
> -Alan
>
>
>


From nathan.a.clement at hotmail.com  Fri Dec  5 02:55:41 2014
From: nathan.a.clement at hotmail.com (Nathan Clement)
Date: Fri, 5 Dec 2014 13:55:41 +1100
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <20141205020245.0000680f.ecki@zusammenkunft.net>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>,
	<54807258.4040303@oracle.com>,
	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>,
	<20141205002430.000060c9.ecki@zusammenkunft.net>,
	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>,
	<COL131-W70AF8AFB5ECF1C626BECACCA790@phx.gbl>,
	<20141205020245.0000680f.ecki@zusammenkunft.net>
Message-ID: <COL131-W43836CCE8D3418B718BFF1CA790@phx.gbl>

Hi Bernd,

> > My problem is definitely not related to multi-threaded use.  The test
> > shows basically the same code that we have in production that
> > experienced the problem.
> 
> Of course it can be triggered single threaded. But this does not mean
> you should not fix it for concurrent use as well (for the reasons
> mentioned).

I agree with the other commenters that since FilterOutputStream is not thread safe, there isn't any need to fix the bug for multi-threaded use.

> > I don't see that this change is any more risky than the change that
> > introduced this bug.  I'm more than happy to have the bug fixed in a
> > different way - this is just the first solution that occurred to me.
> 
> Well, the change which introduced the bug (and others in this area) are
> risky and did break things. I just want to make sure you are aware of
> it. I feel that its not worth fixing, but its not my call.
> 
> However your problem is easily solved in an overwritten close() method.
> I bet you will not wait for this to hit a production ready Java, anyway.

I think that this bug definitely does need to be fixed in the JDK since that's where it was introduced.  We experience the bug when using the BufferedOutputStream, which extends FilterOutputStream.  It is impractical for us to use an overridden close() method as this would involve changing all our code to use this new class rather than BufferedOutputStream.

The fix we have implemented in production is to build a small jar containing only the fixed FilterOutputStream and include this in the bootclasspath: "-Xbootclasspath/p:%APP_HOME%\lib\jdkfix.jar".  I will remove that temporary fix once the bug is fixed in the JDK.

Regards,

Nathan

> Date: Fri, 5 Dec 2014 02:02:45 +0100
> From: ecki at zusammenkunft.net
> To: core-libs-dev at openjdk.java.net
> Subject: Re: [PATCH] JDK-8054565: FilterOutputStream.close may throw	IOException if called twice and underlying flush or close fails
> 
> Am Fri, 5 Dec 2014 11:49:26 +1100
> schrieb Nathan Clement <nathan.a.clement at hotmail.com>:
> 
> > Hi,
> > 
> > My problem is definitely not related to multi-threaded use.  The test
> > shows basically the same code that we have in production that
> > experienced the problem.
> 
> Of course it can be triggered single threaded. But this does not mean
> you should not fix it for concurrent use as well (for the reasons
> mentioned).
> 
> > I don't see that this change is any more risky than the change that
> > introduced this bug.  I'm more than happy to have the bug fixed in a
> > different way - this is just the first solution that occurred to me.
> 
> Well, the change which introduced the bug (and others in this area) are
> risky and did break things. I just want to make sure you are aware of
> it. I feel that its not worth fixing, but its not my call.
> 
> However your problem is easily solved in an overwritten close() method.
> I bet you will not wait for this to hit a production ready Java, anyway.
> 
> Gruss
> Bernd
 		 	   		  

From rob.mckenna at oracle.com  Fri Dec  5 05:17:30 2014
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Fri, 05 Dec 2014 05:17:30 +0000
Subject: RFR: 8065238 - javax.naming.NamingException after upgrade to JDK 8
In-Reply-To: <547F3873.3030606@oracle.com>
References: <547F3873.3030606@oracle.com>
Message-ID: <54813FEA.9020802@oracle.com>

Just updated the test to workaround a seemingly unrelated platform 
specific issue. (that only manifests on older kernels)

http://cr.openjdk.java.net/~robm/8065238/webrev.02/

     -Rob

On 03/12/14 16:21, Rob McKenna wrote:
> Hi folks,
>
> Looking to fix a regression caused by 8042857. Basically the behaviour 
> in 8042857 is incorrect. This fix reverts to the previous behaviour 
> and attempts to beef up the tests a little around Ldap timeouts.
>
> http://cr.openjdk.java.net/~robm/8065238/webrev.01/
>
> The test itself looks quite complex but isn't really. There are two 
> executor pools. (scheduled and fixed) The fixed pool is for running 
> tests concurrently. The scheduled pool is for killing tests that test 
> ldap connects / reads where no timeout is set. (according to the spec 
> these should wait forever)
>
> For these long running timeout tests, we schedule a thread to 
> interrupt the test after waiting for 20s. There are 3 of these long 
> running tests in total, hence the decision to run the tests in parallel.
>
> I'm not averse to breaking this out into separate tests and a library 
> for the helper classes if people think it makes more sense to leave 
> the concurrency up to the test framework.
>
>     -Rob
>



From youdwei at linux.vnet.ibm.com  Fri Dec  5 06:55:08 2014
From: youdwei at linux.vnet.ibm.com (deven you)
Date: Fri, 5 Dec 2014 14:55:08 +0800
Subject: FilePermission Canonical path optimization
In-Reply-To: <CABOR3+xsbTmT-JgiKnstgTQJQBEwTiHqxggm1PYkKBxqyQk=Qw@mail.gmail.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
	<CABOR3+xsbTmT-JgiKnstgTQJQBEwTiHqxggm1PYkKBxqyQk=Qw@mail.gmail.com>
Message-ID: <CADsbJLnmvBg9-tYZKHtHas9O9gzKpsdvzNQfdC7ZrmcwhHpOAQ@mail.gmail.com>

Hi Bernd,


I will update the patch for the underscores. As to security manager I think
in most cases, FilePermission is used with it together.

>From the spec:

Absolute path:    is complete in that no other information is required in
order to locate the file that it denotes

Canonical Path: is both absolute and unique.
The precise definition of canonical form is system-dependent. This method
first converts this pathname to absolute form if necessary, as if by
invoking the getAbsolutePath()
<http://docs.oracle.com/javase/8/docs/api/java/io/File.html#getAbsolutePath-->
 method, and then maps it to its unique form in a system-dependent way.
This typically involves removing redundant names such as "."and ".." from
the pathname, resolving symbolic links (on UNIX platforms), and converting
drive letters to a standard case (on Microsoft Windows platforms).

>From above, we can only use canonical path rather than absolute path
because absolute path may not be unique.

Thanks a lot!


2014-12-01 16:43 GMT+08:00 Bernd <ecki at zusammenkunft.net>:

> Hello,
>
> I thik the underscores in method and field do not match very the other
> names in that file (or the JCL).
>
> If I understand right, this is an optimization for the case a security
> manager is not present? For the other case, maybe having absolute but not
> canonical file names is an option? Or maybe have a special optimization for
> JAVA_HOME prefixed names? Or does it help in that case as well?
>
> Gruss
> Bernd
> Am 01.12.2014 09:18 schrieb "deven you" <youdwei at linux.vnet.ibm.com>:
>
> > Hi All,
> >  File.getCanonicalPath() is a very time-consuming method, we observed
> > significant performance degradation from some application's startup stage
> > with java.io.FilePermission. However, lazying load the calls to
> > getCanonicalPath() from java.ioFilePermission is straightforward and
> solve
> > this problem effectively. Openjdk bug[1]  tracks this bug and here is the
> > patch [2]. Could anyone take a look?
> >
> > [1] https://bugs.openjdk.java.net/browse/JDK-8066211
> > [2] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.00/
> >
>


From ydwchina at gmail.com  Fri Dec  5 07:55:59 2014
From: ydwchina at gmail.com (deven you)
Date: Fri, 5 Dec 2014 15:55:59 +0800
Subject: FilePermission Canonical path optimization
In-Reply-To: <CADsbJLkL_NE0GbT_uB3xwSZc+XYi1dHACabwjCApaXr=h-UkLQ@mail.gmail.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
	<547C6432.5050003@oracle.com>
	<CADsbJLkL_NE0GbT_uB3xwSZc+XYi1dHACabwjCApaXr=h-UkLQ@mail.gmail.com>
Message-ID: <CADsbJL=8k6PB9qD7mAP4GhtpGfC9876N1o8GF-Eq64Ly=FKHtA@mail.gmail.com>

Hi All,

I have updated the patch[3] to reflect all of your suggestions.

[3] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.02/

Thanks a lot!

2014-12-05 10:39 GMT+08:00 deven you <ydwchina at gmail.com>:

> Hi Alan,
>
> I am not clear whether canonicalization cache enabled or disabled, however
> I think even the cache is enable, it may not help much for the start up
> stage especially if the app uses many different files.
>
> The cache should speed up applications for common case especially after
> start up and this patch will specifically solve the problem for
> FilePermssion.
>
> I will update the patch soon with your suggestion and Wenjian's.
>
> Thanks a lot!
>
>
>
> 2014-12-01 20:50 GMT+08:00 Alan Bateman <Alan.Bateman at oracle.com>:
>
>> On 01/12/2014 08:06, deven you wrote:
>>
>>> Hi All,
>>>   File.getCanonicalPath() is a very time-consuming method, we observed
>>> significant performance degradation from some application's startup stage
>>> with java.io.FilePermission. However, lazying load the calls to
>>> getCanonicalPath() from java.ioFilePermission is straightforward and
>>> solve
>>> this problem effectively. Openjdk bug[1]  tracks this bug and here is the
>>> patch [2]. Could anyone take a look?
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8066211
>>> [2] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.00/
>>>
>>
>> Do you run with canonicalization cache enabled or disabled? While I don't
>> agree with this cache, it seem to mostly eliminate complaints in this area
>> after it was added (in JDK 1.4 I think).
>>
>> As regards the patch then it is a bit ugly. Could you use cpath == null
>> instead of introducing a flag? If a flag is required then I think it will
>> need a better name. Also if init is split then it might be cleaner to have
>> initMask and initCanonicalPath.
>>
>> -Alan
>>
>>
>>
>


From sean.coffey at oracle.com  Fri Dec  5 09:16:29 2014
From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=)
Date: Fri, 05 Dec 2014 09:16:29 +0000
Subject: Should some JDK system properties be read only ?
In-Reply-To: <DAB0DD4E-DB23-4B43-A3B4-F0A0B582D530@oracle.com>
References: <548080D0.1090506@oracle.com> <5480992E.1010007@oracle.com>
	<DAB0DD4E-DB23-4B43-A3B4-F0A0B582D530@oracle.com>
Message-ID: <548177ED.8060907@oracle.com>

Yes - that would be a nice API addition also. Not sure if we'd have to 
consider a way of working on system properties set via the command line 
option also. I'm tracking this via 
https://bugs.openjdk.java.net/browse/JDK-8066709

regards,
Sean.

On 05/12/2014 01:00, Wang Weijun wrote:
> A System.setFinalProperty() method that creates a new property with a final value? Maybe also a System.isFinalProperty() method allowing people to detect if a property is final.
>
> --Max
>



From patrick at reini.net  Fri Dec  5 09:16:53 2014
From: patrick at reini.net (Patrick Reinhart)
Date: Fri, 5 Dec 2014 10:16:53 +0100
Subject: Library enhancement proposal for copying data from/to
	Reader/Writer InputStream/OutputStream
In-Reply-To: <DAAE3744-D74C-4528-9498-B7389DC784EF@oracle.com>
References: <566A428C-1A13-4DEE-940B-2EBE375F2A7A@reini.net>
	<546EF98C.40704@oracle.com>
	<B764DE29-57BB-4BD9-B538-7A650723BF2B@reini.net>
	<1D392C1F-E6CC-494D-97F8-C08C5BA36392@oracle.com>
	<E9277204-264A-49A8-971C-6B2FF0B831A4@reini.net>
	<FB33655F-D0D8-47CF-82B0-530C9A212B8E@oracle.com>
	<B10C4D8D-6A57-41FE-8ABC-54E09B4DA14D@reini.net>
	<A3953E4D-018A-44C8-8106-DC9E4663D67C@reini.net>
	<C62A3014-1F54-41E4-B560-198F87305B9E@reini.net>
	<54772C7D.7080209@oracle.com>
	<769E83F8-FD6D-4F8B-B415-DD044C5D08BA@reini.net>
	<D1E803CB-29AF-46AA-9990-77B2A05EFBD4@oracle.com>
	<547757EE.4090205@oracle.com>
	<ED697D7C-F60A-4CD7-B84E-88C10D45B9FB@reini.net>
	<D2DD43D0-5D86-446A-A67A-8D3AEB2541CD@oracle.com>
	<15B58029-95FA-4D9E-AA28-7A6C72D6CB3D@reini.net>
	<13156FAC-6EDC-462B-9BE7-2DFAFB9124FD@oracle.com>
	<20141128201546.000067ce.ecki@zusammenkunft.net>
	<<216A14EF-B62C-4971! -!> <8194-E...>
	<8E1109C5-4C9E-4B7A-924E-9E92B3F93F89@reini.net>
	<150A2C4B-E239-433C-B0C9-39F70E98D837@oracle.com> <5480B9CE.20!
	9060...
Message-ID: <0AB0FE5A-0183-4228-AD48-E15CC2D50C55@reini.net>

> 
>> Should those methods also be on the FilterInput- and OutputStream?
> 
> I'm not sure I'm following you. j.i.FilterInputStream will get the base version
> of InputStream.copyTo method for free as a child though it doesn't define it
> itself. Every class down the hierarchy starting from the j.i.InputStream will
> get InputStream.copyTo version unless it overrides it.
> To override it, it should of course have some rationale behind it. I believe we
> have found it for at least two widely used subclasses.
> 

Sorry,  you are absolutely right, it seems I was somewhere else in my thinking. Just ignore that point :-)


>> I'm not quit sure about the impact on may already existing customer code that had implemented such a method without declaring a IOException for example. In this case the existing code would may break? (as a comment of Alan Bateman earlier before)
> 
> In the case you've mentioned everything should be just fine (technically) as
> overriding method has right to neither throw nor even declare any exceptions
> thrown by the parent method.
> 

This point was not completely clear for me. I thought it, but I was not completely sure about that fact.

> I said *technically* because the sole fact of overriding doesn't guarantee the 
> child's method has the same semantics as the parent's one. 
> 
> It seems to me that it?s not the only possible problematic thing here. We'll see.
> 
> -Pavel

I hope there is a change to get that in the JDK9 at the end. I will do as much as I can do from my side though.

-Patrick

From pavel.rappo at oracle.com  Fri Dec  5 11:38:07 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 5 Dec 2014 11:38:07 +0000
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <CAHjP37HgKZMhjq6_AVZFAdPy4PeZBd7p6JBT0Jt2FqE42eB6Ow@mail.gmail.com>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>
	<54807258.4040303@oracle.com>
	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>
	<20141205002430.000060c9.ecki@zusammenkunft.net>
	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>
	<20141205015827.00007ac6.ecki@zusammenkunft.net>
	<CAHjP37HgKZMhjq6_AVZFAdPy4PeZBd7p6JBT0Jt2FqE42eB6Ow@mail.gmail.com>
Message-ID: <8F896CE2-E268-418F-96CA-0557C1C258B3@oracle.com>

+1, I couldn?t say better

-Pavel

> On 5 Dec 2014, at 01:18, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> 
> Attempting to make close() atomic just makes the next reader
> confused when the rest of the class isn't and may also penalize single
> threaded callers of close().



From peter.levart at gmail.com  Fri Dec  5 13:00:30 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 05 Dec 2014 14:00:30 +0100
Subject: FilePermission Canonical path optimization
In-Reply-To: <CADsbJL=8k6PB9qD7mAP4GhtpGfC9876N1o8GF-Eq64Ly=FKHtA@mail.gmail.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>	<547C6432.5050003@oracle.com>	<CADsbJLkL_NE0GbT_uB3xwSZc+XYi1dHACabwjCApaXr=h-UkLQ@mail.gmail.com>
	<CADsbJL=8k6PB9qD7mAP4GhtpGfC9876N1o8GF-Eq64Ly=FKHtA@mail.gmail.com>
Message-ID: <5481AC6E.9060706@gmail.com>

Hi Deven,

Similar to lazy initialization of initial list of drivers in 
java.sql.DriverManager that was done recently:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/029944.html

It would be nice to replace the following pattern:

if (cpath == null) initCannonicalpath();

... use cpath ...

with:

... use getCpath() ...

where the getCpath() contains lazy initialization logic. Unfortunately 
initCannonicalPath() does not initialize only the 'cpath', but also 
dependent 'directory' and 'recursive' flags, so perhaps you could rename 
it to initCpathDirectoryAndRecursive() ?

Your pattern:

if (cpath == null) initCannonicalpath();

... use cpath ...

also contains data races. The 'cpath', 'directory' and 'recursive' 
instance variables are not volatile. You set them in synchronized 
initCannonicalPath(), but you read them without synchronization. Another 
thread could see the 'cpath' variable already initialized, but still 
read the 'directory' and 'recursive' flags as uninitialized values (in 
equals and impliesIgnoreMask). These data races were present before, 
when those fields were initialized in constructor, but with lazy 
initialization you extend the possibilities of exposing them in 
situations to which they were not subjected before.

One way to fix this would be:

Make 'cpath', 'directory' and 'recursive' fields volatile and carefully 
arrange ininitCpathDirectoryAndRecursive () to be assigned in the 
following order:

- 'directory' and 'recursive' first
- 'cpath' last

The following pattern:

if (cpath == null) initCpathDirectoryAndRecursive();
... use 'cpath' or ''directory' or 'recursive' ...

Is then safe. And you don't need synchronized keyword on 
initCpathDirectoryAndRecursive().


Other than that, I think that the following check:

  191         if (getName() == null)
  192                 throw new NullPointerException("name can't be null");


...does not belong to initMask() method. But it has to be performed 
non-lazily in constructors / deserialization. So I suggest the following:

private static int checkMask(int mask) {
     if ((mask & ALL) != mask || mask == NONE)
         throw new IllegalArgumentException("invalid actions mask");

     return mask;
}

private static String checkPath(String path) {
     if (path == null)
         throw new NullPointerException("path can't be null");

     return path;
}

and use those in both constructors and deserialization as identity 
functions that pass the parameters unchanged, but validate them.


The question is what to do with the remaining data race that was present 
before. The 'mask' field. The best would be to make it final, but 
deserialization needs to set it. If you're willing to introduce ugly 
reflection with doPrivileged() monster block of code just to set the 
field in readObject(), you can do it like that:

// instead of

         this.mask = checkMask(getMask(actions));

// you would have to do do:

         final int mask = checkMask(getMask(actions));
         try {
             AccessController.doPrivileged(new 
PrivilegedExceptionAction<Void>() {
                 @Override
                 public Void run() throws Exception {
                     Field maskField = 
FilePermission.class.getDeclaredField("mask");
                     maskField.setAccessible(true);
                     maskField.set(FilePermission.this, mask);
                     return null;
                 }
             });
         } catch (PrivilegedActionException e) {
             throw new IOException(e.getException());
         }


Regards, Peter

On 12/05/2014 08:55 AM, deven you wrote:
> Hi All,
>
> I have updated the patch[3] to reflect all of your suggestions.
>
> [3] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.02/
>
> Thanks a lot!
>
> 2014-12-05 10:39 GMT+08:00 deven you <ydwchina at gmail.com>:
>
>> Hi Alan,
>>
>> I am not clear whether canonicalization cache enabled or disabled, however
>> I think even the cache is enable, it may not help much for the start up
>> stage especially if the app uses many different files.
>>
>> The cache should speed up applications for common case especially after
>> start up and this patch will specifically solve the problem for
>> FilePermssion.
>>
>> I will update the patch soon with your suggestion and Wenjian's.
>>
>> Thanks a lot!
>>
>>
>>
>> 2014-12-01 20:50 GMT+08:00 Alan Bateman <Alan.Bateman at oracle.com>:
>>
>>> On 01/12/2014 08:06, deven you wrote:
>>>
>>>> Hi All,
>>>>    File.getCanonicalPath() is a very time-consuming method, we observed
>>>> significant performance degradation from some application's startup stage
>>>> with java.io.FilePermission. However, lazying load the calls to
>>>> getCanonicalPath() from java.ioFilePermission is straightforward and
>>>> solve
>>>> this problem effectively. Openjdk bug[1]  tracks this bug and here is the
>>>> patch [2]. Could anyone take a look?
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8066211
>>>> [2] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.00/
>>>>
>>> Do you run with canonicalization cache enabled or disabled? While I don't
>>> agree with this cache, it seem to mostly eliminate complaints in this area
>>> after it was added (in JDK 1.4 I think).
>>>
>>> As regards the patch then it is a bit ugly. Could you use cpath == null
>>> instead of introducing a flag? If a flag is required then I think it will
>>> need a better name. Also if init is split then it might be cleaner to have
>>> initMask and initCanonicalPath.
>>>
>>> -Alan
>>>
>>>
>>>



From chris.hegarty at oracle.com  Fri Dec  5 14:04:28 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 05 Dec 2014 14:04:28 +0000
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <8F896CE2-E268-418F-96CA-0557C1C258B3@oracle.com>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>	<54807258.4040303@oracle.com>	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>	<20141205002430.000060c9.ecki@zusammenkunft.net>	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>	<20141205015827.00007ac6.ecki@zusammenkunft.net>	<CAHjP37HgKZMhjq6_AVZFAdPy4PeZBd7p6JBT0Jt2FqE42eB6Ow@mail.gmail.com>
	<8F896CE2-E268-418F-96CA-0557C1C258B3@oracle.com>
Message-ID: <5481BB6C.1040700@oracle.com>


On 05/12/14 11:38, Pavel Rappo wrote:
> +1, I couldn?t say better

Right. This bug should only try to address the change in behavior that 
was inadvertently introduced by 7015589[1][2].

I don't see any reason to make 'closed' protected ( part of the public 
Java SE API ), something like:

diff --git a/src/java.base/share/classes/java/io/FilterOutputStream.java 
b/src/java.base/share/classes/java/io/FilterOutputStream.java
--- a/src/java.base/share/classes/java/io/FilterOutputStream.java
+++ b/src/java.base/share/classes/java/io/FilterOutputStream.java
@@ -48,6 +48,8 @@
       */
      protected OutputStream out;

+    private boolean closed; // false
+
      /**
       * Creates an output stream filter built on top of the specified
       * underlying output stream.
@@ -154,6 +156,9 @@
       */
      @SuppressWarnings("try")
      public void close() throws IOException {
+        if (closed)
+            return;
+        closed = true;
          try (OutputStream ostream = out) {
              flush();
          }

diff --git a/test/java/io/etc/FailingFlushAndClose.java 
b/test/java/io/etc/FailingFlushAndClose.java
--- a/test/java/io/etc/FailingFlushAndClose.java
+++ b/test/java/io/etc/FailingFlushAndClose.java
@@ -25,7 +25,7 @@

  /**
   * @test
- * @bug 7015589
+ * @bug 7015589 8054565
   * @summary Test that buffering streams are considered closed even 
when the
   *    close or flush from the underlying stream fails.
   */
@@ -165,7 +165,7 @@
          }
      }

-    static void testFailingClose(InputStream in) throws IOException {
+    static InputStream testFailingClose(InputStream in) throws 
IOException {
          System.out.println(in.getClass());
          in.read(new byte[100]);
          try {
@@ -176,9 +176,10 @@
              in.read(new byte[100]);
              fail("read did not fail");
          } catch (IOException expected) { }
+        return in;
      }

-    static void testFailingClose(OutputStream out) throws IOException {
+    static OutputStream testFailingClose(OutputStream out) throws 
IOException {
          System.out.println(out.getClass());
          out.write(1);
          try {
@@ -190,9 +191,10 @@
              if (!(out instanceof BufferedOutputStream))
                  fail("write did not fail");
          } catch (IOException expected) { }
+        return out;
      }

-    static void testFailingFlush(OutputStream out) throws IOException {
+    static OutputStream testFailingFlush(OutputStream out) throws 
IOException {
          System.out.println(out.getClass());
          out.write(1);
          try {
@@ -206,9 +208,27 @@
                  fail("close did not fail");
              } catch (IOException expected) { }
          }
+        return out;
      }

-    static void testFailingClose(Reader r) throws IOException {
+    static void closeAgain(InputStream in) throws IOException {
+        // assert the given stream should already be closed.
+        try {
+            in.close();
+        } catch (IOException expected) {
+            fail("unexpected IOException from subsequent close");
+        }
+    }
+    static void closeAgain(OutputStream out) throws IOException {
+        // assert the given stream should already be closed.
+        try {
+            out.close();
+        } catch (IOException expected) {
+            fail("unexpected IOException from subsequent close");
+        }
+    }
+
+    static Reader testFailingClose(Reader r) throws IOException {
          System.out.println(r.getClass());
          r.read(new char[100]);
          try {
@@ -219,9 +239,10 @@
              r.read(new char[100]);
              fail("read did not fail");
          } catch (IOException expected) { }
+        return r;
      }

-    static void testFailingClose(Writer w) throws IOException {
+    static Writer testFailingClose(Writer w) throws IOException {
          System.out.println(w.getClass());
          w.write("message");
          try {
@@ -232,9 +253,10 @@
              w.write("another message");
              fail("write did not fail");
          } catch (IOException expected) { }
+        return w;
      }

-    static void testFailingFlush(Writer w) throws IOException {
+    static Writer testFailingFlush(Writer w) throws IOException {
          System.out.println(w.getClass());
          w.write("message");
          try {
@@ -249,18 +271,38 @@
                  fail("close did not fail");
              } catch (IOException expected) { }
          }
+        return w;
+    }
+
+    static Reader closeAgain(Reader r) throws IOException {
+        // assert the given stream should already be closed.
+        try {
+            r.close();
+        } catch (IOException expected) {
+            fail("unexpected IOException from subsequent close");
+        }
+        return r;
+    }
+    static Writer closeAgain(Writer w) throws IOException {
+        // assert the given stream should already be closed.
+        try {
+            w.close();
+        } catch (IOException expected) {
+            fail("unexpected IOException from subsequent close");
+        }
+        return w;
      }

      public static void main(String[] args) throws IOException {

-        testFailingClose(new BufferedInputStream(new 
FailingCloseInputStream()));
-        testFailingClose(new BufferedOutputStream(new 
FailingCloseOutputStream()));
+        closeAgain(testFailingClose(new BufferedInputStream(new 
FailingCloseInputStream())));
+        closeAgain(testFailingClose(new BufferedOutputStream(new 
FailingCloseOutputStream())));

-        testFailingClose(new BufferedReader(new FailingCloseReader()));
-        testFailingClose(new BufferedWriter(new FailingCloseWriter()));
+        closeAgain(testFailingClose(new BufferedReader(new 
FailingCloseReader())));
+        closeAgain(testFailingClose(new BufferedWriter(new 
FailingCloseWriter())));

-        testFailingFlush(new BufferedOutputStream(new 
FailingFlushOutputStream()));
-        testFailingFlush(new BufferedWriter(new FailingFlushWriter()));
+        closeAgain(testFailingFlush(new BufferedOutputStream(new 
FailingFlushOutputStream())));
+        closeAgain(testFailingFlush(new BufferedWriter(new 
FailingFlushWriter())));

          if (failed > 0)
              throw new RuntimeException(failed + " test(s) failed - see 
log for details");


-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-7015589
[2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/759aa847dcaf


> -Pavel
>
>> On 5 Dec 2014, at 01:18, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>>
>> Attempting to make close() atomic just makes the next reader
>> confused when the rest of the class isn't and may also penalize single
>> threaded callers of close().
>


From peter.levart at gmail.com  Fri Dec  5 14:40:27 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 05 Dec 2014 15:40:27 +0100
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <5481BB6C.1040700@oracle.com>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>	<54807258.4040303@oracle.com>	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>	<20141205002430.000060c9.ecki@zusammenkunft.net>	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>	<20141205015827.00007ac6.ecki@zusammenkunft.net>	<CAHjP37HgKZMhjq6_AVZFAdPy4PeZBd7p6JBT0Jt2FqE42eB6Ow@mail.gmail.com>	<8F896CE2-E268-418F-96CA-0557C1C258B3@oracle.com>
	<5481BB6C.1040700@oracle.com>
Message-ID: <5481C3DB.70303@gmail.com>

On 12/05/2014 03:04 PM, Chris Hegarty wrote:
>
> On 05/12/14 11:38, Pavel Rappo wrote:
>> +1, I couldn?t say better
>
> Right. This bug should only try to address the change in behavior that 
> was inadvertently introduced by 7015589[1][2].

What about the following:


private boolean closed;

public void close() throws IOException {
     try (OutputStream ostream = out) {
         if (!closed)  flush();
     }
     closed = true;
}


...this way the impact of the change is minimal and still addresses the 
problem of JDK-8054565 <https://bugs.openjdk.java.net/browse/JDK-8054565>.

If either flush() or out.close() throw exception the 1st time close() is 
called, they will both be called also the 2nd time. Only after flush() 
and out.close() return successfully, then further flush() invocations 
are suppressed.

The alternative would be to not suppress flush() invocations, but just 
any exception thrown from flush():


     private boolean closed;

     public void close() throws IOException {
         try (OutputStream ostream = out) {
             try {
                 flush();
             } catch (IOException | RuntimeException | Error e) {
                 if (!closed) throw e;
             }
         }
         closed = true;
     }


But I don't know if this is better or worse. It certainly could still be 
squeezed under the spec which says:

      * The <code>close</code> method of <code>FilterOutputStream</code>
      * calls its <code>flush</code> method, and then calls the
      * <code>close</code> method of its underlying output stream.


Regards, Peter

>
> I don't see any reason to make 'closed' protected ( part of the public 
> Java SE API ), something like:
>
> diff --git 
> a/src/java.base/share/classes/java/io/FilterOutputStream.java 
> b/src/java.base/share/classes/java/io/FilterOutputStream.java
> --- a/src/java.base/share/classes/java/io/FilterOutputStream.java
> +++ b/src/java.base/share/classes/java/io/FilterOutputStream.java
> @@ -48,6 +48,8 @@
>       */
>      protected OutputStream out;
>
> +    private boolean closed; // false
> +
>      /**
>       * Creates an output stream filter built on top of the specified
>       * underlying output stream.
> @@ -154,6 +156,9 @@
>       */
>      @SuppressWarnings("try")
>      public void close() throws IOException {
> +        if (closed)
> +            return;
> +        closed = true;
>          try (OutputStream ostream = out) {
>              flush();
>          }
>
> diff --git a/test/java/io/etc/FailingFlushAndClose.java 
> b/test/java/io/etc/FailingFlushAndClose.java
> --- a/test/java/io/etc/FailingFlushAndClose.java
> +++ b/test/java/io/etc/FailingFlushAndClose.java
> @@ -25,7 +25,7 @@
>
>  /**
>   * @test
> - * @bug 7015589
> + * @bug 7015589 8054565
>   * @summary Test that buffering streams are considered closed even 
> when the
>   *    close or flush from the underlying stream fails.
>   */
> @@ -165,7 +165,7 @@
>          }
>      }
>
> -    static void testFailingClose(InputStream in) throws IOException {
> +    static InputStream testFailingClose(InputStream in) throws 
> IOException {
>          System.out.println(in.getClass());
>          in.read(new byte[100]);
>          try {
> @@ -176,9 +176,10 @@
>              in.read(new byte[100]);
>              fail("read did not fail");
>          } catch (IOException expected) { }
> +        return in;
>      }
>
> -    static void testFailingClose(OutputStream out) throws IOException {
> +    static OutputStream testFailingClose(OutputStream out) throws 
> IOException {
>          System.out.println(out.getClass());
>          out.write(1);
>          try {
> @@ -190,9 +191,10 @@
>              if (!(out instanceof BufferedOutputStream))
>                  fail("write did not fail");
>          } catch (IOException expected) { }
> +        return out;
>      }
>
> -    static void testFailingFlush(OutputStream out) throws IOException {
> +    static OutputStream testFailingFlush(OutputStream out) throws 
> IOException {
>          System.out.println(out.getClass());
>          out.write(1);
>          try {
> @@ -206,9 +208,27 @@
>                  fail("close did not fail");
>              } catch (IOException expected) { }
>          }
> +        return out;
>      }
>
> -    static void testFailingClose(Reader r) throws IOException {
> +    static void closeAgain(InputStream in) throws IOException {
> +        // assert the given stream should already be closed.
> +        try {
> +            in.close();
> +        } catch (IOException expected) {
> +            fail("unexpected IOException from subsequent close");
> +        }
> +    }
> +    static void closeAgain(OutputStream out) throws IOException {
> +        // assert the given stream should already be closed.
> +        try {
> +            out.close();
> +        } catch (IOException expected) {
> +            fail("unexpected IOException from subsequent close");
> +        }
> +    }
> +
> +    static Reader testFailingClose(Reader r) throws IOException {
>          System.out.println(r.getClass());
>          r.read(new char[100]);
>          try {
> @@ -219,9 +239,10 @@
>              r.read(new char[100]);
>              fail("read did not fail");
>          } catch (IOException expected) { }
> +        return r;
>      }
>
> -    static void testFailingClose(Writer w) throws IOException {
> +    static Writer testFailingClose(Writer w) throws IOException {
>          System.out.println(w.getClass());
>          w.write("message");
>          try {
> @@ -232,9 +253,10 @@
>              w.write("another message");
>              fail("write did not fail");
>          } catch (IOException expected) { }
> +        return w;
>      }
>
> -    static void testFailingFlush(Writer w) throws IOException {
> +    static Writer testFailingFlush(Writer w) throws IOException {
>          System.out.println(w.getClass());
>          w.write("message");
>          try {
> @@ -249,18 +271,38 @@
>                  fail("close did not fail");
>              } catch (IOException expected) { }
>          }
> +        return w;
> +    }
> +
> +    static Reader closeAgain(Reader r) throws IOException {
> +        // assert the given stream should already be closed.
> +        try {
> +            r.close();
> +        } catch (IOException expected) {
> +            fail("unexpected IOException from subsequent close");
> +        }
> +        return r;
> +    }
> +    static Writer closeAgain(Writer w) throws IOException {
> +        // assert the given stream should already be closed.
> +        try {
> +            w.close();
> +        } catch (IOException expected) {
> +            fail("unexpected IOException from subsequent close");
> +        }
> +        return w;
>      }
>
>      public static void main(String[] args) throws IOException {
>
> -        testFailingClose(new BufferedInputStream(new 
> FailingCloseInputStream()));
> -        testFailingClose(new BufferedOutputStream(new 
> FailingCloseOutputStream()));
> +        closeAgain(testFailingClose(new BufferedInputStream(new 
> FailingCloseInputStream())));
> +        closeAgain(testFailingClose(new BufferedOutputStream(new 
> FailingCloseOutputStream())));
>
> -        testFailingClose(new BufferedReader(new FailingCloseReader()));
> -        testFailingClose(new BufferedWriter(new FailingCloseWriter()));
> +        closeAgain(testFailingClose(new BufferedReader(new 
> FailingCloseReader())));
> +        closeAgain(testFailingClose(new BufferedWriter(new 
> FailingCloseWriter())));
>
> -        testFailingFlush(new BufferedOutputStream(new 
> FailingFlushOutputStream()));
> -        testFailingFlush(new BufferedWriter(new FailingFlushWriter()));
> +        closeAgain(testFailingFlush(new BufferedOutputStream(new 
> FailingFlushOutputStream())));
> +        closeAgain(testFailingFlush(new BufferedWriter(new 
> FailingFlushWriter())));
>
>          if (failed > 0)
>              throw new RuntimeException(failed + " test(s) failed - 
> see log for details");
>
>
> -Chris.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-7015589
> [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/759aa847dcaf
>
>
>> -Pavel
>>
>>> On 5 Dec 2014, at 01:18, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>>>
>>> Attempting to make close() atomic just makes the next reader
>>> confused when the rest of the class isn't and may also penalize single
>>> threaded callers of close().
>>



From chris.hegarty at oracle.com  Fri Dec  5 15:09:00 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 05 Dec 2014 15:09:00 +0000
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <5481C3DB.70303@gmail.com>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>	<54807258.4040303@oracle.com>	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>	<20141205002430.000060c9.ecki@zusammenkunft.net>	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>	<20141205015827.00007ac6.ecki@zusammenkunft.net>	<CAHjP37HgKZMhjq6_AVZFAdPy4PeZBd7p6JBT0Jt2FqE42eB6Ow@mail.gmail.com>	<8F896CE2-E268-418F-96CA-0557C1C258B3@oracle.com>
	<5481BB6C.1040700@oracle.com> <5481C3DB.70303@gmail.com>
Message-ID: <5481CA8C.7050100@oracle.com>

On 05/12/14 14:40, Peter Levart wrote:
> On 12/05/2014 03:04 PM, Chris Hegarty wrote:
>>
>> On 05/12/14 11:38, Pavel Rappo wrote:
>>> +1, I couldn?t say better
>>
>> Right. This bug should only try to address the change in behavior that
>> was inadvertently introduced by 7015589[1][2].
>
> What about the following:
>
>
> private boolean closed;
>
> public void close() throws IOException {
>      try (OutputStream ostream = out) {
>          if (!closed)  flush();
>      }
>      closed = true;
> }

If flush throws, how is anyone supposed to know that they need to call 
close again, and that it was not the close that actually threw?

close() should be a one-time shot.

I personally think that this was an oversight of the original change in 
7015589, and not a deliberate behavior. My proposed change will restore 
the behavior of close to pre 7015589, though not swallow the IOException 
from flush.

-Chris.

> ...this way the impact of the change is minimal and still addresses the
> problem of JDK-8054565 <https://bugs.openjdk.java.net/browse/JDK-8054565>.
>
> If either flush() or out.close() throw exception the 1st time close() is
> called, they will both be called also the 2nd time. Only after flush()
> and out.close() return successfully, then further flush() invocations
> are suppressed.
>
> The alternative would be to not suppress flush() invocations, but just
> any exception thrown from flush():
>
>
>      private boolean closed;
>
>      public void close() throws IOException {
>          try (OutputStream ostream = out) {
>              try {
>                  flush();
>              } catch (IOException | RuntimeException | Error e) {
>                  if (!closed) throw e;
>              }
>          }
>          closed = true;
>      }
>
>
> But I don't know if this is better or worse. It certainly could still be
> squeezed under the spec which says:
>
>       * The <code>close</code> method of <code>FilterOutputStream</code>
>       * calls its <code>flush</code> method, and then calls the
>       * <code>close</code> method of its underlying output stream.
>
>
> Regards, Peter
>
>>
>> I don't see any reason to make 'closed' protected ( part of the public
>> Java SE API ), something like:
>>
>> diff --git
>> a/src/java.base/share/classes/java/io/FilterOutputStream.java
>> b/src/java.base/share/classes/java/io/FilterOutputStream.java
>> --- a/src/java.base/share/classes/java/io/FilterOutputStream.java
>> +++ b/src/java.base/share/classes/java/io/FilterOutputStream.java
>> @@ -48,6 +48,8 @@
>>       */
>>      protected OutputStream out;
>>
>> +    private boolean closed; // false
>> +
>>      /**
>>       * Creates an output stream filter built on top of the specified
>>       * underlying output stream.
>> @@ -154,6 +156,9 @@
>>       */
>>      @SuppressWarnings("try")
>>      public void close() throws IOException {
>> +        if (closed)
>> +            return;
>> +        closed = true;
>>          try (OutputStream ostream = out) {
>>              flush();
>>          }
>>
>> diff --git a/test/java/io/etc/FailingFlushAndClose.java
>> b/test/java/io/etc/FailingFlushAndClose.java
>> --- a/test/java/io/etc/FailingFlushAndClose.java
>> +++ b/test/java/io/etc/FailingFlushAndClose.java
>> @@ -25,7 +25,7 @@
>>
>>  /**
>>   * @test
>> - * @bug 7015589
>> + * @bug 7015589 8054565
>>   * @summary Test that buffering streams are considered closed even
>> when the
>>   *    close or flush from the underlying stream fails.
>>   */
>> @@ -165,7 +165,7 @@
>>          }
>>      }
>>
>> -    static void testFailingClose(InputStream in) throws IOException {
>> +    static InputStream testFailingClose(InputStream in) throws
>> IOException {
>>          System.out.println(in.getClass());
>>          in.read(new byte[100]);
>>          try {
>> @@ -176,9 +176,10 @@
>>              in.read(new byte[100]);
>>              fail("read did not fail");
>>          } catch (IOException expected) { }
>> +        return in;
>>      }
>>
>> -    static void testFailingClose(OutputStream out) throws IOException {
>> +    static OutputStream testFailingClose(OutputStream out) throws
>> IOException {
>>          System.out.println(out.getClass());
>>          out.write(1);
>>          try {
>> @@ -190,9 +191,10 @@
>>              if (!(out instanceof BufferedOutputStream))
>>                  fail("write did not fail");
>>          } catch (IOException expected) { }
>> +        return out;
>>      }
>>
>> -    static void testFailingFlush(OutputStream out) throws IOException {
>> +    static OutputStream testFailingFlush(OutputStream out) throws
>> IOException {
>>          System.out.println(out.getClass());
>>          out.write(1);
>>          try {
>> @@ -206,9 +208,27 @@
>>                  fail("close did not fail");
>>              } catch (IOException expected) { }
>>          }
>> +        return out;
>>      }
>>
>> -    static void testFailingClose(Reader r) throws IOException {
>> +    static void closeAgain(InputStream in) throws IOException {
>> +        // assert the given stream should already be closed.
>> +        try {
>> +            in.close();
>> +        } catch (IOException expected) {
>> +            fail("unexpected IOException from subsequent close");
>> +        }
>> +    }
>> +    static void closeAgain(OutputStream out) throws IOException {
>> +        // assert the given stream should already be closed.
>> +        try {
>> +            out.close();
>> +        } catch (IOException expected) {
>> +            fail("unexpected IOException from subsequent close");
>> +        }
>> +    }
>> +
>> +    static Reader testFailingClose(Reader r) throws IOException {
>>          System.out.println(r.getClass());
>>          r.read(new char[100]);
>>          try {
>> @@ -219,9 +239,10 @@
>>              r.read(new char[100]);
>>              fail("read did not fail");
>>          } catch (IOException expected) { }
>> +        return r;
>>      }
>>
>> -    static void testFailingClose(Writer w) throws IOException {
>> +    static Writer testFailingClose(Writer w) throws IOException {
>>          System.out.println(w.getClass());
>>          w.write("message");
>>          try {
>> @@ -232,9 +253,10 @@
>>              w.write("another message");
>>              fail("write did not fail");
>>          } catch (IOException expected) { }
>> +        return w;
>>      }
>>
>> -    static void testFailingFlush(Writer w) throws IOException {
>> +    static Writer testFailingFlush(Writer w) throws IOException {
>>          System.out.println(w.getClass());
>>          w.write("message");
>>          try {
>> @@ -249,18 +271,38 @@
>>                  fail("close did not fail");
>>              } catch (IOException expected) { }
>>          }
>> +        return w;
>> +    }
>> +
>> +    static Reader closeAgain(Reader r) throws IOException {
>> +        // assert the given stream should already be closed.
>> +        try {
>> +            r.close();
>> +        } catch (IOException expected) {
>> +            fail("unexpected IOException from subsequent close");
>> +        }
>> +        return r;
>> +    }
>> +    static Writer closeAgain(Writer w) throws IOException {
>> +        // assert the given stream should already be closed.
>> +        try {
>> +            w.close();
>> +        } catch (IOException expected) {
>> +            fail("unexpected IOException from subsequent close");
>> +        }
>> +        return w;
>>      }
>>
>>      public static void main(String[] args) throws IOException {
>>
>> -        testFailingClose(new BufferedInputStream(new
>> FailingCloseInputStream()));
>> -        testFailingClose(new BufferedOutputStream(new
>> FailingCloseOutputStream()));
>> +        closeAgain(testFailingClose(new BufferedInputStream(new
>> FailingCloseInputStream())));
>> +        closeAgain(testFailingClose(new BufferedOutputStream(new
>> FailingCloseOutputStream())));
>>
>> -        testFailingClose(new BufferedReader(new FailingCloseReader()));
>> -        testFailingClose(new BufferedWriter(new FailingCloseWriter()));
>> +        closeAgain(testFailingClose(new BufferedReader(new
>> FailingCloseReader())));
>> +        closeAgain(testFailingClose(new BufferedWriter(new
>> FailingCloseWriter())));
>>
>> -        testFailingFlush(new BufferedOutputStream(new
>> FailingFlushOutputStream()));
>> -        testFailingFlush(new BufferedWriter(new FailingFlushWriter()));
>> +        closeAgain(testFailingFlush(new BufferedOutputStream(new
>> FailingFlushOutputStream())));
>> +        closeAgain(testFailingFlush(new BufferedWriter(new
>> FailingFlushWriter())));
>>
>>          if (failed > 0)
>>              throw new RuntimeException(failed + " test(s) failed -
>> see log for details");
>>
>>
>> -Chris.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-7015589
>> [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/759aa847dcaf
>>
>>
>>> -Pavel
>>>
>>>> On 5 Dec 2014, at 01:18, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>>>>
>>>> Attempting to make close() atomic just makes the next reader
>>>> confused when the rest of the class isn't and may also penalize single
>>>> threaded callers of close().
>>>
>


From peter.levart at gmail.com  Fri Dec  5 15:09:10 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 05 Dec 2014 16:09:10 +0100
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <5481C3DB.70303@gmail.com>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>	<54807258.4040303@oracle.com>	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>	<20141205002430.000060c9.ecki@zusammenkunft.net>	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>	<20141205015827.00007ac6.ecki@zusammenkunft.net>	<CAHjP37HgKZMhjq6_AVZFAdPy4PeZBd7p6JBT0Jt2FqE42eB6Ow@mail.gmail.com>	<8F896CE2-E268-418F-96CA-0557C1C258B3@oracle.com>
	<5481BB6C.1040700@oracle.com> <5481C3DB.70303@gmail.com>
Message-ID: <5481CA96.3070100@gmail.com>

Or, maybe a 3rd, more refined variant:


     private boolean closed;

     public void close() throws IOException {
         Exception exc = null;
         try {
             flush();
         } catch (IOException | RuntimeException e) {
             if (!closed) exc = e;
         }

         try {
             out.close();
             closed = true;
         } catch (IOException | RuntimeException e) {
             if (exc == null) {
                 exc = e;
             } else {
                 exc.addSuppressed(e);
             }
         }

         if (exc != null) {
             if (exc instanceof IOException) {
                 throw (IOException) exc;
             } else {
                 throw (RuntimeException) exc;
             }
         }
     }


The difference being that underlying stream is considered closed (and 
consequently exceptions from further flushes ignored) as soon as 
out.close() returns successfully.


Regards, Peter


On 12/05/2014 03:40 PM, Peter Levart wrote:
> On 12/05/2014 03:04 PM, Chris Hegarty wrote:
>>
>> On 05/12/14 11:38, Pavel Rappo wrote:
>>> +1, I couldn?t say better
>>
>> Right. This bug should only try to address the change in behavior 
>> that was inadvertently introduced by 7015589[1][2].
>
> What about the following:
>
>
> private boolean closed;
>
> public void close() throws IOException {
>     try (OutputStream ostream = out) {
>         if (!closed)  flush();
>     }
>     closed = true;
> }
>
>
> ...this way the impact of the change is minimal and still addresses 
> the problem of JDK-8054565 
> <https://bugs.openjdk.java.net/browse/JDK-8054565>.
>
> If either flush() or out.close() throw exception the 1st time close() 
> is called, they will both be called also the 2nd time. Only after 
> flush() and out.close() return successfully, then further flush() 
> invocations are suppressed.
>
> The alternative would be to not suppress flush() invocations, but just 
> any exception thrown from flush():
>
>
>     private boolean closed;
>
>     public void close() throws IOException {
>         try (OutputStream ostream = out) {
>             try {
>                 flush();
>             } catch (IOException | RuntimeException | Error e) {
>                 if (!closed) throw e;
>             }
>         }
>         closed = true;
>     }
>
>
> But I don't know if this is better or worse. It certainly could still 
> be squeezed under the spec which says:
>
>      * The <code>close</code> method of <code>FilterOutputStream</code>
>      * calls its <code>flush</code> method, and then calls the
>      * <code>close</code> method of its underlying output stream.
>
>
> Regards, Peter
>
>>
>> I don't see any reason to make 'closed' protected ( part of the 
>> public Java SE API ), something like:
>>
>> diff --git 
>> a/src/java.base/share/classes/java/io/FilterOutputStream.java 
>> b/src/java.base/share/classes/java/io/FilterOutputStream.java
>> --- a/src/java.base/share/classes/java/io/FilterOutputStream.java
>> +++ b/src/java.base/share/classes/java/io/FilterOutputStream.java
>> @@ -48,6 +48,8 @@
>>       */
>>      protected OutputStream out;
>>
>> +    private boolean closed; // false
>> +
>>      /**
>>       * Creates an output stream filter built on top of the specified
>>       * underlying output stream.
>> @@ -154,6 +156,9 @@
>>       */
>>      @SuppressWarnings("try")
>>      public void close() throws IOException {
>> +        if (closed)
>> +            return;
>> +        closed = true;
>>          try (OutputStream ostream = out) {
>>              flush();
>>          }
>>
>> diff --git a/test/java/io/etc/FailingFlushAndClose.java 
>> b/test/java/io/etc/FailingFlushAndClose.java
>> --- a/test/java/io/etc/FailingFlushAndClose.java
>> +++ b/test/java/io/etc/FailingFlushAndClose.java
>> @@ -25,7 +25,7 @@
>>
>>  /**
>>   * @test
>> - * @bug 7015589
>> + * @bug 7015589 8054565
>>   * @summary Test that buffering streams are considered closed even 
>> when the
>>   *    close or flush from the underlying stream fails.
>>   */
>> @@ -165,7 +165,7 @@
>>          }
>>      }
>>
>> -    static void testFailingClose(InputStream in) throws IOException {
>> +    static InputStream testFailingClose(InputStream in) throws 
>> IOException {
>>          System.out.println(in.getClass());
>>          in.read(new byte[100]);
>>          try {
>> @@ -176,9 +176,10 @@
>>              in.read(new byte[100]);
>>              fail("read did not fail");
>>          } catch (IOException expected) { }
>> +        return in;
>>      }
>>
>> -    static void testFailingClose(OutputStream out) throws IOException {
>> +    static OutputStream testFailingClose(OutputStream out) throws 
>> IOException {
>>          System.out.println(out.getClass());
>>          out.write(1);
>>          try {
>> @@ -190,9 +191,10 @@
>>              if (!(out instanceof BufferedOutputStream))
>>                  fail("write did not fail");
>>          } catch (IOException expected) { }
>> +        return out;
>>      }
>>
>> -    static void testFailingFlush(OutputStream out) throws IOException {
>> +    static OutputStream testFailingFlush(OutputStream out) throws 
>> IOException {
>>          System.out.println(out.getClass());
>>          out.write(1);
>>          try {
>> @@ -206,9 +208,27 @@
>>                  fail("close did not fail");
>>              } catch (IOException expected) { }
>>          }
>> +        return out;
>>      }
>>
>> -    static void testFailingClose(Reader r) throws IOException {
>> +    static void closeAgain(InputStream in) throws IOException {
>> +        // assert the given stream should already be closed.
>> +        try {
>> +            in.close();
>> +        } catch (IOException expected) {
>> +            fail("unexpected IOException from subsequent close");
>> +        }
>> +    }
>> +    static void closeAgain(OutputStream out) throws IOException {
>> +        // assert the given stream should already be closed.
>> +        try {
>> +            out.close();
>> +        } catch (IOException expected) {
>> +            fail("unexpected IOException from subsequent close");
>> +        }
>> +    }
>> +
>> +    static Reader testFailingClose(Reader r) throws IOException {
>>          System.out.println(r.getClass());
>>          r.read(new char[100]);
>>          try {
>> @@ -219,9 +239,10 @@
>>              r.read(new char[100]);
>>              fail("read did not fail");
>>          } catch (IOException expected) { }
>> +        return r;
>>      }
>>
>> -    static void testFailingClose(Writer w) throws IOException {
>> +    static Writer testFailingClose(Writer w) throws IOException {
>>          System.out.println(w.getClass());
>>          w.write("message");
>>          try {
>> @@ -232,9 +253,10 @@
>>              w.write("another message");
>>              fail("write did not fail");
>>          } catch (IOException expected) { }
>> +        return w;
>>      }
>>
>> -    static void testFailingFlush(Writer w) throws IOException {
>> +    static Writer testFailingFlush(Writer w) throws IOException {
>>          System.out.println(w.getClass());
>>          w.write("message");
>>          try {
>> @@ -249,18 +271,38 @@
>>                  fail("close did not fail");
>>              } catch (IOException expected) { }
>>          }
>> +        return w;
>> +    }
>> +
>> +    static Reader closeAgain(Reader r) throws IOException {
>> +        // assert the given stream should already be closed.
>> +        try {
>> +            r.close();
>> +        } catch (IOException expected) {
>> +            fail("unexpected IOException from subsequent close");
>> +        }
>> +        return r;
>> +    }
>> +    static Writer closeAgain(Writer w) throws IOException {
>> +        // assert the given stream should already be closed.
>> +        try {
>> +            w.close();
>> +        } catch (IOException expected) {
>> +            fail("unexpected IOException from subsequent close");
>> +        }
>> +        return w;
>>      }
>>
>>      public static void main(String[] args) throws IOException {
>>
>> -        testFailingClose(new BufferedInputStream(new 
>> FailingCloseInputStream()));
>> -        testFailingClose(new BufferedOutputStream(new 
>> FailingCloseOutputStream()));
>> +        closeAgain(testFailingClose(new BufferedInputStream(new 
>> FailingCloseInputStream())));
>> +        closeAgain(testFailingClose(new BufferedOutputStream(new 
>> FailingCloseOutputStream())));
>>
>> -        testFailingClose(new BufferedReader(new FailingCloseReader()));
>> -        testFailingClose(new BufferedWriter(new FailingCloseWriter()));
>> +        closeAgain(testFailingClose(new BufferedReader(new 
>> FailingCloseReader())));
>> +        closeAgain(testFailingClose(new BufferedWriter(new 
>> FailingCloseWriter())));
>>
>> -        testFailingFlush(new BufferedOutputStream(new 
>> FailingFlushOutputStream()));
>> -        testFailingFlush(new BufferedWriter(new FailingFlushWriter()));
>> +        closeAgain(testFailingFlush(new BufferedOutputStream(new 
>> FailingFlushOutputStream())));
>> +        closeAgain(testFailingFlush(new BufferedWriter(new 
>> FailingFlushWriter())));
>>
>>          if (failed > 0)
>>              throw new RuntimeException(failed + " test(s) failed - 
>> see log for details");
>>
>>
>> -Chris.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-7015589
>> [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/759aa847dcaf
>>
>>
>>> -Pavel
>>>
>>>> On 5 Dec 2014, at 01:18, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>>>>
>>>> Attempting to make close() atomic just makes the next reader
>>>> confused when the rest of the class isn't and may also penalize single
>>>> threaded callers of close().
>>>
>
>



From kumar.x.srinivasan at oracle.com  Fri Dec  5 15:22:25 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 05 Dec 2014 07:22:25 -0800
Subject: RFR: JDK-8058407: Remove Multiple JRE support in the Java launcher
Message-ID: <5481CDB1.8080208@oracle.com>

Hello,

Please review the fix for JDK-8058407, contributed by Neil Toda, 
described by JEP 231 [1]
the webrev is at: http://cr.openjdk.java.net/~ksrini/8058407/webrev.00/

Please note: The above webrev is identical to the original posted by Neal at
http://cr.openjdk.java.net/~ntoda/8058407/webrev-03/


Thanks
Kumar

[1] http://openjdk.java.net/jeps/231


From Alan.Bateman at oracle.com  Fri Dec  5 15:33:41 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 05 Dec 2014 15:33:41 +0000
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <5481BB6C.1040700@oracle.com>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>	<54807258.4040303@oracle.com>	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>	<20141205002430.000060c9.ecki@zusammenkunft.net>	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>	<20141205015827.00007ac6.ecki@zusammenkunft.net>	<CAHjP37HgKZMhjq6_AVZFAdPy4PeZBd7p6JBT0Jt2FqE42eB6Ow@mail.gmail.com>	<8F896CE2-E268-418F-96CA-0557C1C258B3@oracle.com>
	<5481BB6C.1040700@oracle.com>
Message-ID: <5481D055.3080801@oracle.com>

On 05/12/2014 14:04, Chris Hegarty wrote:
>
> On 05/12/14 11:38, Pavel Rappo wrote:
>> +1, I couldn?t say better
>
> Right. This bug should only try to address the change in behavior that 
> was inadvertently introduced by 7015589[1][2].
>
> I don't see any reason to make 'closed' protected ( part of the public 
> Java SE API ), something like:
>
Right, no need for it to be protected. I think what you have seems right 
but we probably need a small spec clarification so that it reads "When 
not already closed, the close method of FilterOutputStream ...". That 
removes the testable assertion that flush that is always called.

-Alan



From chris.hegarty at oracle.com  Fri Dec  5 15:38:28 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 05 Dec 2014 15:38:28 +0000
Subject: Library enhancement proposal for copying data from/to
	Reader/Writer InputStream/OutputStream
In-Reply-To: <DAAE3744-D74C-4528-9498-B7389DC784EF@oracle.com>
References: <566A428C-1A13-4DEE-940B-2EBE375F2A7A@reini.net>	<1D392C1F-E6CC-494D-97F8-C08C5BA36392@oracle.com>	<E9277204-264A-49A8-971C-6B2FF0B831A4@reini.net>	<FB33655F-D0D8-47CF-82B0-530C9A212B8E@oracle.com>	<B10C4D8D-6A57-41FE-8ABC-54E09B4DA14D@reini.net>	<A3953E4D-018A-44C8-8106-DC9E4663D67C@reini.net>	<C62A3014-1F54-41E4-B560-198F87305B9E@reini.net>	<54772C7D.7080209@oracle.com>	<769E83F8-FD6D-4F8B-B415-DD044C5D08BA@reini.net>	<D1E803CB-29AF-46AA-9990-77B2A05EFBD4@oracle.com>	<547757EE.4090205@oracle.com>	<ED697D7C-F60A-4CD7-B84E-88C10D45B9FB@reini.net>	<D2DD43D0-5D86-446A-A67A-8D3AEB2541CD@oracle.com>	<15B58029-95FA-4D9E-AA28-7A6C72D6CB3D@reini.net>	<13156FAC-6EDC-462B-9BE7-2DFAFB9124FD@oracle.com>	<20141128201546.000067ce.ecki@zusammenkunft.net>	<<216A14EF-B62C-4971!
	-!>
	<8194-E...>	<8E1109C5-4C9E-4B7A-924E-9E92B3F93F89@reini.net>	<150A2C4B-E239-433C-B0C9-39F70E98D837@oracle.com>
	<5480B9CE.20!	90600@reini.net>
	<DAAE3744-D74C-4528-9498-B7389DC784EF@oracle.com>
Message-ID: <5481D174.2030406@oracle.com>

The addition of a copyTo method to java.io.InputStream is binary 
compatible [1], but it may, in some cases, be source incompatible. I 
believe the benefits of this approach out weigh the potential source 
incompatibility, but it will be for the spec gods, the CCC, to have 
final say.

Here is what I propose. Let's take just InputStream.copyTo and bring it, 
by itself, to a conclusion. And then revisit each of the additional 
useful/convenience methods on their own merit.

I think we are mostly in agreement on the latest patch Pavel sent out. 
Cut'n'past here, with some grammatical updates.

/**
  * Reads all remaining bytes from this input stream and writes them to
  * the given output stream.
  * <p>
  * There are no guarantees on the stream's state if an error occurs.
  * Even if this method returns normally you can't rely on previously
  * marked positions, or the contents of any internal buffers. That
  * said, this is a terminal operation. It is strongly recommended
  * that both streams are promptly closed after this method returns:
  * <pre>{@code
  *     try (InputStream is = ...; OutputStream os = ...;) {
  *         is.copyTo(os);
  *     } catch (IOException e) {
  *         ...
  *     }
  * }</pre>
  * <p>
  * This method may block indefinitely reading from the input stream,
  * or writing to the output stream. The behavior for the case that the
  * input and/or output stream is <i>asynchronously closed</i>, or the
  * thread interrupted during the copy, is highly input and output stream
  * specific, and therefore not specified.
  *
  * @param  out         the output stream to write to, non-null
  * @return             the number of bytes copied
  * @throws IOException if an I/O error occurs when reading or writing
  *
  * @since 1.9
  */
public long copyTo(OutputStream out) throws IOException { ... }


-Chris

[1] http://docs.oracle.com/javase/specs/jls/se8/html/jls-13.html


On 04/12/14 23:13, Pavel Rappo wrote:
> Patrick,
>
>> Should those methods also be on the FilterInput- and OutputStream?
>
> I'm not sure I'm following you. j.i.FilterInputStream will get the base version
> of InputStream.copyTo method for free as a child though it doesn't define it
> itself. Every class down the hierarchy starting from the j.i.InputStream will
> get InputStream.copyTo version unless it overrides it.
> To override it, it should of course have some rationale behind it. I believe we
> have found it for at least two widely used subclasses.
>
>> I'm not quit sure about the impact on may already existing customer code that had implemented such a method without declaring a IOException for example. In this case the existing code would may break? (as a comment of Alan Bateman earlier before)
>
> In the case you've mentioned everything should be just fine (technically) as
> overriding method has right to neither throw nor even declare any exceptions
> thrown by the parent method.
>
> I said *technically* because the sole fact of overriding doesn't guarantee the
> child's method has the same semantics as the parent's one.
>
> It seems to me that it?s not the only possible problematic thing here. We'll see.
>
> -Pavel
>


From chris.hegarty at oracle.com  Fri Dec  5 15:43:33 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 05 Dec 2014 15:43:33 +0000
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <5481D055.3080801@oracle.com>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>	<54807258.4040303@oracle.com>	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>	<20141205002430.000060c9.ecki@zusammenkunft.net>	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>	<20141205015827.00007ac6.ecki@zusammenkunft.net>	<CAHjP37HgKZMhjq6_AVZFAdPy4PeZBd7p6JBT0Jt2FqE42eB6Ow@mail.gmail.com>	<8F896CE2-E268-418F-96CA-0557C1C258B3@oracle.com>
	<5481BB6C.1040700@oracle.com> <5481D055.3080801@oracle.com>
Message-ID: <5481D2A5.5060609@oracle.com>



On 05/12/14 15:33, Alan Bateman wrote:
> On 05/12/2014 14:04, Chris Hegarty wrote:
>>  ...
> Right, no need for it to be protected. I think what you have seems right
> but we probably need a small spec clarification so that it reads "When
> not already closed, the close method of FilterOutputStream ...". That
> removes the testable assertion that flush that is always called.

Right. Just to close the loop, the change, excluding testcase, looks like:

diff --git a/src/java.base/share/classes/java/io/FilterOutputStream.java 
b/src/java.base/share/classes/java/io/FilterOutputStream.java
--- a/src/java.base/share/classes/java/io/FilterOutputStream.java
+++ b/src/java.base/share/classes/java/io/FilterOutputStream.java
@@ -48,6 +48,8 @@
       */
      protected OutputStream out;

+    private boolean closed;
+
      /**
       * Creates an output stream filter built on top of the specified
       * underlying output stream.
@@ -144,9 +146,9 @@
       * Closes this output stream and releases any system resources
       * associated with the stream.
       * <p>
-     * The <code>close</code> method of <code>FilterOutputStream</code>
-     * calls its <code>flush</code> method, and then calls the
-     * <code>close</code> method of its underlying output stream.
+     * When not already closed, the {@code close} method of {@code
+     * FilterOutputStream} calls its {@code flush} method, and then
+     * calls the {@code close} method of its underlying output stream.
       *
       * @exception  IOException  if an I/O error occurs.
       * @see        java.io.FilterOutputStream#flush()
@@ -154,6 +156,9 @@
       */
      @SuppressWarnings("try")
      public void close() throws IOException {
+        if (closed)
+            return;
+        closed = true;
          try (OutputStream ostream = out) {
              flush();
          }

-Chris.


From kumar.x.srinivasan at oracle.com  Fri Dec  5 15:49:08 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 05 Dec 2014 07:49:08 -0800
Subject: XXS RFR: JDK-8066745: tools/pack200/Pack200Props.java failed with
	java.lang.OutOfMemoryError: Java heap space
Message-ID: <5481D3F4.6090208@oracle.com>

Hi Alan,

Per your suggestion I have made this othervm.

Thanks
Kumar


diff --git a/test/tools/pack200/Pack200Props.java 
b/test/tools/pack200/Pack200Props.java
--- a/test/tools/pack200/Pack200Props.java
+++ b/test/tools/pack200/Pack200Props.java
@@ -26,7 +26,7 @@
   * @bug 6575373 6969063
   * @summary verify default properties of the packer/unpacker and 
segment limit
   * @compile -XDignore.symbol.file Utils.java Pack200Props.java
- * @run main Pack200Props
+ * @run main/othervm Pack200Props
   * @author ksrini
   */



From Alan.Bateman at oracle.com  Fri Dec  5 15:59:58 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 05 Dec 2014 15:59:58 +0000
Subject: Library enhancement proposal for copying data from/to
	Reader/Writer InputStream/OutputStream
In-Reply-To: <5481D174.2030406@oracle.com>
References: <566A428C-1A13-4DEE-940B-2EBE375F2A7A@reini.net>	<E9277204-264A-49A8-971C-6B2FF0B831A4@reini.net>	<FB33655F-D0D8-47CF-82B0-530C9A212B8E@oracle.com>	<B10C4D8D-6A57-41FE-8ABC-54E09B4DA14D@reini.net>	<A3953E4D-018A-44C8-8106-DC9E4663D67C@reini.net>	<C62A3014-1F54-41E4-B560-198F87305B9E@reini.net>	<54772C7D.7080209@oracle.com>	<769E83F8-FD6D-4F8B-B415-DD044C5D08BA@reini.net>	<D1E803CB-29AF-46AA-9990-77B2A05EFBD4@oracle.com>	<547757EE.4090205@oracle.com>	<ED697D7C-F60A-4CD7-B84E-88C10D45B9FB@reini.net>	<D2DD43D0-5D86-446A-A67A-8D3AEB2541CD@oracle.com>	<15B58029-95FA-4D9E-AA28-7A6C72D6CB3D@reini.net>	<13156FAC-6EDC-462B-9BE7-2DFAFB9124FD@oracle.com>	<20141128201546.000067ce.ecki@zusammenkunft.net>	<<216A14EF-B62C-4971!	-!>	<8194-E...>	<8E1109C5-4C9E-4B7A-924E-9E92B3F93F89@reini.net>	<150A2C4B-E239-433C-B0C9-39F70E98D837@oracle.com>	<5480B9CE.20!	90600@reini.net>	<DAAE3744-D74C-4528-9498-B7389DC784EF@oracle.com>
	<5481D174.2030406@oracle.com>
Message-ID: <5481D67E.9080504@oracle.com>

On 05/12/2014 15:38, Chris Hegarty wrote:
> The addition of a copyTo method to java.io.InputStream is binary 
> compatible [1], but it may, in some cases, be source incompatible. I 
> believe the benefits of this approach out weigh the potential source 
> incompatibility, but it will be for the spec gods, the CCC, to have 
> final say.
>
> Here is what I propose. Let's take just InputStream.copyTo and bring 
> it, by itself, to a conclusion. And then revisit each of the 
> additional useful/convenience methods on their own merit.
I think the approach is good. An alternative name to consider is 
transferTo. For the javadoc then you can make it clear that the 
InputStream is at EOF when the method completes. I don't think the 
javadoc needs to say that the OutputStream should be closed promptly 
(think "cat a b c > d").

-Alan.


From vincent.x.ryan at oracle.com  Fri Dec  5 16:05:01 2014
From: vincent.x.ryan at oracle.com (Vincent Ryan)
Date: Fri, 5 Dec 2014 16:05:01 +0000
Subject: RFR: 8065238 - javax.naming.NamingException after upgrade to JDK 8
In-Reply-To: <54813FEA.9020802@oracle.com>
References: <547F3873.3030606@oracle.com> <54813FEA.9020802@oracle.com>
Message-ID: <468BC2C7-8674-4A23-80CB-D9AA3DDBBBBA@oracle.com>

Changes look fine to me Rob.
Thanks.


On 5 Dec 2014, at 05:17, Rob McKenna <rob.mckenna at oracle.com> wrote:

> Just updated the test to workaround a seemingly unrelated platform specific issue. (that only manifests on older kernels)
> 
> http://cr.openjdk.java.net/~robm/8065238/webrev.02/
> 
>    -Rob
> 
> On 03/12/14 16:21, Rob McKenna wrote:
>> Hi folks,
>> 
>> Looking to fix a regression caused by 8042857. Basically the behaviour in 8042857 is incorrect. This fix reverts to the previous behaviour and attempts to beef up the tests a little around Ldap timeouts.
>> 
>> http://cr.openjdk.java.net/~robm/8065238/webrev.01/
>> 
>> The test itself looks quite complex but isn't really. There are two executor pools. (scheduled and fixed) The fixed pool is for running tests concurrently. The scheduled pool is for killing tests that test ldap connects / reads where no timeout is set. (according to the spec these should wait forever)
>> 
>> For these long running timeout tests, we schedule a thread to interrupt the test after waiting for 20s. There are 3 of these long running tests in total, hence the decision to run the tests in parallel.
>> 
>> I'm not averse to breaking this out into separate tests and a library for the helper classes if people think it makes more sense to leave the concurrency up to the test framework.
>> 
>>    -Rob
>> 
> 



From chris.hegarty at oracle.com  Fri Dec  5 16:36:50 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 05 Dec 2014 16:36:50 +0000
Subject: Library enhancement proposal for copying data from/to
	Reader/Writer InputStream/OutputStream
In-Reply-To: <5481D67E.9080504@oracle.com>
References: <566A428C-1A13-4DEE-940B-2EBE375F2A7A@reini.net>	<E9277204-264A-49A8-971C-6B2FF0B831A4@reini.net>	<FB33655F-D0D8-47CF-82B0-530C9A212B8E@oracle.com>	<B10C4D8D-6A57-41FE-8ABC-54E09B4DA14D@reini.net>	<A3953E4D-018A-44C8-8106-DC9E4663D67C@reini.net>	<C62A3014-1F54-41E4-B560-198F87305B9E@reini.net>	<54772C7D.7080209@oracle.com>	<769E83F8-FD6D-4F8B-B415-DD044C5D08BA@reini.net>	<D1E803CB-29AF-46AA-9990-77B2A05EFBD4@oracle.com>	<547757EE.4090205@oracle.com>	<ED697D7C-F60A-4CD7-B84E-88C10D45B9FB@reini.net>	<D2DD43D0-5D86-446A-A67A-8D3AEB2541CD@oracle.com>	<15B58029-95FA-4D9E-AA28-7A6C72D6CB3D@reini.net>	<13156FAC-6EDC-462B-9BE7-2DFAFB9124FD@oracle.com>	<20141128201546.000067ce.ecki@zusammenkunft.net>	<<216A14EF-B62C-4971!	-!>	<8194-E...>	<8E1109C5-4C9E-4B7A-924E-9E92B3F93F89@reini.net>	<150A2C4B-E239-433C-B0C9-39F70E98D837@oracle.com>	<5480B9CE.20!	90600@reini.net>	<DAAE3744-D74C-4528-9498-B7389DC784EF@oracle.com>
	<5481D174.2030406@oracle.com> <5481D67E.9080504@oracle.com>
Message-ID: <5481DF22.2010809@oracle.com>

On 05/12/14 15:59, Alan Bateman wrote:
> On 05/12/2014 15:38, Chris Hegarty wrote:
>> The addition of a copyTo method to java.io.InputStream is binary
>> compatible [1], but it may, in some cases, be source incompatible. I
>> believe the benefits of this approach out weigh the potential source
>> incompatibility, but it will be for the spec gods, the CCC, to have
>> final say.
>>
>> Here is what I propose. Let's take just InputStream.copyTo and bring
>> it, by itself, to a conclusion. And then revisit each of the
>> additional useful/convenience methods on their own merit.
> I think the approach is good. An alternative name to consider is
> transferTo. For the javadoc then you can make it clear that the
> InputStream is at EOF when the method completes. I don't think the
> javadoc needs to say that the OutputStream should be closed promptly
> (think "cat a b c > d").

Right. Updated spec:

     /**
      * Reads all remaining bytes from this input stream and writes them to
      * the given output stream.  On return, this input stream will be 
at end of
      * stream.
      * <p>
      * This method may block indefinitely reading from the input stream,
      * or writing to the output stream. The behavior for the case that the
      * input and/or output stream is <i>asynchronously closed</i>, or the
      * thread interrupted during the copy, is highly input and output 
stream
      * specific, and therefore not specified.
      * <p>
      * If an I/O error occurs reading from the input stream or writing to
      * the output stream, then it may do so after some bytes have been 
read or
      * written. Consequently the input stream may not be at end of 
stream and
      * may be in an inconsistent state. It is strongly recommended that the
      * input stream be promptly closed if an I/O error occurs.
      *
      * @param  out         the output stream to write to, non-null
      * @return             the number of bytes copied
      * @throws IOException if an I/O error occurs when reading or writing
      * @throws NullPointerException  if {@code out} is {@code null}
      *
      * @since 1.9
      */
     public long transferTo(OutputStream out) throws IOException { ... }

-Chris.


From Alan.Bateman at oracle.com  Fri Dec  5 17:11:42 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 05 Dec 2014 17:11:42 +0000
Subject: XXS RFR: JDK-8066745: tools/pack200/Pack200Props.java failed
	with java.lang.OutOfMemoryError: Java heap space
In-Reply-To: <5481D3F4.6090208@oracle.com>
References: <5481D3F4.6090208@oracle.com>
Message-ID: <5481E74E.9050104@oracle.com>

On 05/12/2014 15:49, Kumar Srinivasan wrote:
> Hi Alan,
>
> Per your suggestion I have made this othervm.
>
> Thanks
> Kumar
Do you want to add -Xshare:off too? Just wondering how tight this is on 
32-bit Windows.

-Alan.


From patrick at reini.net  Fri Dec  5 17:28:39 2014
From: patrick at reini.net (Patrick Reinhart)
Date: Fri, 5 Dec 2014 18:28:39 +0100
Subject: Library enhancement proposal for copying data from/to
	Reader/Writer InputStream/OutputStream
In-Reply-To: <5481DF22.2010809@oracle.com>
References: <566A428C-1A13-4DEE-940B-2EBE375F2A7A@reini.net>
	<E9277204-264A-49A8-971C-6B2FF0B831A4@reini.net>
	<FB33655F-D0D8-47CF-82B0-530C9A212B8E@oracle.com>
	<B10C4D8D-6A57-41FE-8ABC-54E09B4DA14D@reini.net>
	<A3953E4D-018A-44C8-8106-DC9E4663D67C@reini.net>
	<C62A3014-1F54-41E4-B560-198F87305B9E@reini.net>
	<54772C7D.7080209@oracle.com>
	<769E83F8-FD6D-4F8B-B415-DD044C5D08BA@reini.net>
	<D1E803CB-29AF-46AA-9990-77B2A05EFBD4@oracle.com>
	<547757EE.4090205@oracle.com>
	<ED697D7C-F60A-4CD7-B84E-88C10D45B9FB@reini.net>
	<D2DD43D0-5D86-446A-A67A-8D3AEB2541CD@oracle.com>
	<15B58029-95FA-4D9E-AA28-7A6C72D6CB3D@reini.net>
	<13156FAC-6EDC-462B-9BE7-2DFAFB9124FD@oracle.com>
	<20141128201546.000067ce.ecki@zusammenkunft.net>
	<<216A14EF-B62C-4971!	-!> <8194-E...>
	<8E1109C5-4C9E-4B7A-924E-9E92B3F93F89@reini.net>
	<150A2C4B-E239-433C-B0C9-39F70E98D837@oracle.com>
	<5480B9CE.20!	90600@reini.net>
	<DAAE3744-D74C-4528-9498-B7389DC784EF@oracle.com>
	<5481D174.2030406@oracle.com> <5481D67E.9080504@oracle.com> <548...
Message-ID: <72DDE6F7-6B03-47D5-A125-BCA3D5CD624E@reini.net>

Hi Chris,

> Am 05.12.2014 um 17:36 schrieb Chris Hegarty <chris.hegarty at oracle.com>:
> 
> On 05/12/14 15:59, Alan Bateman wrote:
>> On 05/12/2014 15:38, Chris Hegarty wrote:
>>> The addition of a copyTo method to java.io.InputStream is binary
>>> compatible [1], but it may, in some cases, be source incompatible. I
>>> believe the benefits of this approach out weigh the potential source
>>> incompatibility, but it will be for the spec gods, the CCC, to have
>>> final say.
>>> 
>>> Here is what I propose. Let's take just InputStream.copyTo and bring
>>> it, by itself, to a conclusion. And then revisit each of the
>>> additional useful/convenience methods on their own merit.
>> I think the approach is good. An alternative name to consider is
>> transferTo. For the javadoc then you can make it clear that the
>> InputStream is at EOF when the method completes. I don't think the
>> javadoc needs to say that the OutputStream should be closed promptly
>> (think "cat a b c > d").
> 
> Right. Updated spec:
> 
>    /**
>     * Reads all remaining bytes from this input stream and writes them to
>     * the given output stream.  On return, this input stream will be at end of
>     * stream.
>     * <p>
>     * This method may block indefinitely reading from the input stream,
>     * or writing to the output stream. The behavior for the case that the
>     * input and/or output stream is <i>asynchronously closed</i>, or the
>     * thread interrupted during the copy, is highly input and output stream
>     * specific, and therefore not specified.
>     * <p>
>     * If an I/O error occurs reading from the input stream or writing to
>     * the output stream, then it may do so after some bytes have been read or
>     * written. Consequently the input stream may not be at end of stream and
>     * may be in an inconsistent state. It is strongly recommended that the
>     * input stream be promptly closed if an I/O error occurs.
>     *
>     * @param  out         the output stream to write to, non-null
>     * @return             the number of bytes copied
>     * @throws IOException if an I/O error occurs when reading or writing
>     * @throws NullPointerException  if {@code out} is {@code null}
>     *
>     * @since 1.9
>     */
>    public long transferTo(OutputStream out) throws IOException { ... }
> 
> -Chris.


Looks good to me. The only thing I would change is the @return documentation to ?the number of bytes transferred? to be in sync with the method name.

-Patrick



From peter.levart at gmail.com  Fri Dec  5 17:44:33 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 05 Dec 2014 18:44:33 +0100
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <5481CA8C.7050100@oracle.com>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>	<54807258.4040303@oracle.com>	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>	<20141205002430.000060c9.ecki@zusammenkunft.net>	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>	<20141205015827.00007ac6.ecki@zusammenkunft.net>	<CAHjP37HgKZMhjq6_AVZFAdPy4PeZBd7p6JBT0Jt2FqE42eB6Ow@mail.gmail.com>	<8F896CE2-E268-418F-96CA-0557C1C258B3@oracle.com>
	<5481BB6C.1040700@oracle.com> <5481C3DB.70303@gmail.com>
	<5481CA8C.7050100@oracle.com>
Message-ID: <5481EF01.6060009@gmail.com>

On 12/05/2014 04:09 PM, Chris Hegarty wrote:
> On 05/12/14 14:40, Peter Levart wrote:
>> On 12/05/2014 03:04 PM, Chris Hegarty wrote:
>>>
>>> On 05/12/14 11:38, Pavel Rappo wrote:
>>>> +1, I couldn?t say better
>>>
>>> Right. This bug should only try to address the change in behavior that
>>> was inadvertently introduced by 7015589[1][2].
>>
>> What about the following:
>>
>>
>> private boolean closed;
>>
>> public void close() throws IOException {
>>      try (OutputStream ostream = out) {
>>          if (!closed)  flush();
>>      }
>>      closed = true;
>> }
>
> If flush throws, how is anyone supposed to know that they need to call 
> close again, and that it was not the close that actually threw?

If they call close() again because they are used to pre 7015589 
behaviour, there is no harm if they call it as a consequence of flush() 
throwing and out.close() succeeding, since the underlying stream should 
have idempotent "successful" close(). That's the requirement of 
Closeable.close():

/**
* Closes this stream and releases any system resources associated
* with it. If the stream is already closed then invoking this
* method has no effect.
*
* <p> As noted in {@link AutoCloseable#close()}, cases where the
* close may fail require careful attention. It is strongly advised
* to relinquish the underlying resources and to internally
* <em>mark</em> the {@code Closeable} as closed, prior to throwing
* the {@code IOException}.
*
* @throws IOException if an I/O error occurs
*/

The specification does not say if the stream is to be considered 
"closed" when close() throws IOException. The advice does hint that 
though (and was added about 3 years ago).

>
> close() should be a one-time shot.
>
> I personally think that this was an oversight of the original change 
> in 7015589, and not a deliberate behavior. My proposed change will 
> restore the behavior of close to pre 7015589, though not swallow the 
> IOException from flush.

The pre 7015589 behaviour did not suppress multiple close() calls to 
underlying stream.

>
> -Chris.

I just think that a delegating class like FilterOutputStream should be 
as transparent as possible. If the underlying stream respects the 
contract and advice, the wrapped stream should too. If underlying stream 
needs some out-of-advice treatment, then wrapper like FilterOutputStream 
should not prevent that, because there are all kinds of streams out 
there. Or maybe it should - this is the only way to "fix" those streams ;-)

Just do it!

Regards, Peter

>
>> ...this way the impact of the change is minimal and still addresses the
>> problem of JDK-8054565 
>> <https://bugs.openjdk.java.net/browse/JDK-8054565>.
>>
>> If either flush() or out.close() throw exception the 1st time close() is
>> called, they will both be called also the 2nd time. Only after flush()
>> and out.close() return successfully, then further flush() invocations
>> are suppressed.
>>
>> The alternative would be to not suppress flush() invocations, but just
>> any exception thrown from flush():
>>
>>
>>      private boolean closed;
>>
>>      public void close() throws IOException {
>>          try (OutputStream ostream = out) {
>>              try {
>>                  flush();
>>              } catch (IOException | RuntimeException | Error e) {
>>                  if (!closed) throw e;
>>              }
>>          }
>>          closed = true;
>>      }
>>
>>
>> But I don't know if this is better or worse. It certainly could still be
>> squeezed under the spec which says:
>>
>>       * The <code>close</code> method of <code>FilterOutputStream</code>
>>       * calls its <code>flush</code> method, and then calls the
>>       * <code>close</code> method of its underlying output stream.
>>
>>
>> Regards, Peter
>>
>>>
>>> I don't see any reason to make 'closed' protected ( part of the public
>>> Java SE API ), something like:
>>>
>>> diff --git
>>> a/src/java.base/share/classes/java/io/FilterOutputStream.java
>>> b/src/java.base/share/classes/java/io/FilterOutputStream.java
>>> --- a/src/java.base/share/classes/java/io/FilterOutputStream.java
>>> +++ b/src/java.base/share/classes/java/io/FilterOutputStream.java
>>> @@ -48,6 +48,8 @@
>>>       */
>>>      protected OutputStream out;
>>>
>>> +    private boolean closed; // false
>>> +
>>>      /**
>>>       * Creates an output stream filter built on top of the specified
>>>       * underlying output stream.
>>> @@ -154,6 +156,9 @@
>>>       */
>>>      @SuppressWarnings("try")
>>>      public void close() throws IOException {
>>> +        if (closed)
>>> +            return;
>>> +        closed = true;
>>>          try (OutputStream ostream = out) {
>>>              flush();
>>>          }
>>>
>>> diff --git a/test/java/io/etc/FailingFlushAndClose.java
>>> b/test/java/io/etc/FailingFlushAndClose.java
>>> --- a/test/java/io/etc/FailingFlushAndClose.java
>>> +++ b/test/java/io/etc/FailingFlushAndClose.java
>>> @@ -25,7 +25,7 @@
>>>
>>>  /**
>>>   * @test
>>> - * @bug 7015589
>>> + * @bug 7015589 8054565
>>>   * @summary Test that buffering streams are considered closed even
>>> when the
>>>   *    close or flush from the underlying stream fails.
>>>   */
>>> @@ -165,7 +165,7 @@
>>>          }
>>>      }
>>>
>>> -    static void testFailingClose(InputStream in) throws IOException {
>>> +    static InputStream testFailingClose(InputStream in) throws
>>> IOException {
>>>          System.out.println(in.getClass());
>>>          in.read(new byte[100]);
>>>          try {
>>> @@ -176,9 +176,10 @@
>>>              in.read(new byte[100]);
>>>              fail("read did not fail");
>>>          } catch (IOException expected) { }
>>> +        return in;
>>>      }
>>>
>>> -    static void testFailingClose(OutputStream out) throws 
>>> IOException {
>>> +    static OutputStream testFailingClose(OutputStream out) throws
>>> IOException {
>>>          System.out.println(out.getClass());
>>>          out.write(1);
>>>          try {
>>> @@ -190,9 +191,10 @@
>>>              if (!(out instanceof BufferedOutputStream))
>>>                  fail("write did not fail");
>>>          } catch (IOException expected) { }
>>> +        return out;
>>>      }
>>>
>>> -    static void testFailingFlush(OutputStream out) throws 
>>> IOException {
>>> +    static OutputStream testFailingFlush(OutputStream out) throws
>>> IOException {
>>>          System.out.println(out.getClass());
>>>          out.write(1);
>>>          try {
>>> @@ -206,9 +208,27 @@
>>>                  fail("close did not fail");
>>>              } catch (IOException expected) { }
>>>          }
>>> +        return out;
>>>      }
>>>
>>> -    static void testFailingClose(Reader r) throws IOException {
>>> +    static void closeAgain(InputStream in) throws IOException {
>>> +        // assert the given stream should already be closed.
>>> +        try {
>>> +            in.close();
>>> +        } catch (IOException expected) {
>>> +            fail("unexpected IOException from subsequent close");
>>> +        }
>>> +    }
>>> +    static void closeAgain(OutputStream out) throws IOException {
>>> +        // assert the given stream should already be closed.
>>> +        try {
>>> +            out.close();
>>> +        } catch (IOException expected) {
>>> +            fail("unexpected IOException from subsequent close");
>>> +        }
>>> +    }
>>> +
>>> +    static Reader testFailingClose(Reader r) throws IOException {
>>>          System.out.println(r.getClass());
>>>          r.read(new char[100]);
>>>          try {
>>> @@ -219,9 +239,10 @@
>>>              r.read(new char[100]);
>>>              fail("read did not fail");
>>>          } catch (IOException expected) { }
>>> +        return r;
>>>      }
>>>
>>> -    static void testFailingClose(Writer w) throws IOException {
>>> +    static Writer testFailingClose(Writer w) throws IOException {
>>>          System.out.println(w.getClass());
>>>          w.write("message");
>>>          try {
>>> @@ -232,9 +253,10 @@
>>>              w.write("another message");
>>>              fail("write did not fail");
>>>          } catch (IOException expected) { }
>>> +        return w;
>>>      }
>>>
>>> -    static void testFailingFlush(Writer w) throws IOException {
>>> +    static Writer testFailingFlush(Writer w) throws IOException {
>>>          System.out.println(w.getClass());
>>>          w.write("message");
>>>          try {
>>> @@ -249,18 +271,38 @@
>>>                  fail("close did not fail");
>>>              } catch (IOException expected) { }
>>>          }
>>> +        return w;
>>> +    }
>>> +
>>> +    static Reader closeAgain(Reader r) throws IOException {
>>> +        // assert the given stream should already be closed.
>>> +        try {
>>> +            r.close();
>>> +        } catch (IOException expected) {
>>> +            fail("unexpected IOException from subsequent close");
>>> +        }
>>> +        return r;
>>> +    }
>>> +    static Writer closeAgain(Writer w) throws IOException {
>>> +        // assert the given stream should already be closed.
>>> +        try {
>>> +            w.close();
>>> +        } catch (IOException expected) {
>>> +            fail("unexpected IOException from subsequent close");
>>> +        }
>>> +        return w;
>>>      }
>>>
>>>      public static void main(String[] args) throws IOException {
>>>
>>> -        testFailingClose(new BufferedInputStream(new
>>> FailingCloseInputStream()));
>>> -        testFailingClose(new BufferedOutputStream(new
>>> FailingCloseOutputStream()));
>>> +        closeAgain(testFailingClose(new BufferedInputStream(new
>>> FailingCloseInputStream())));
>>> +        closeAgain(testFailingClose(new BufferedOutputStream(new
>>> FailingCloseOutputStream())));
>>>
>>> -        testFailingClose(new BufferedReader(new 
>>> FailingCloseReader()));
>>> -        testFailingClose(new BufferedWriter(new 
>>> FailingCloseWriter()));
>>> +        closeAgain(testFailingClose(new BufferedReader(new
>>> FailingCloseReader())));
>>> +        closeAgain(testFailingClose(new BufferedWriter(new
>>> FailingCloseWriter())));
>>>
>>> -        testFailingFlush(new BufferedOutputStream(new
>>> FailingFlushOutputStream()));
>>> -        testFailingFlush(new BufferedWriter(new 
>>> FailingFlushWriter()));
>>> +        closeAgain(testFailingFlush(new BufferedOutputStream(new
>>> FailingFlushOutputStream())));
>>> +        closeAgain(testFailingFlush(new BufferedWriter(new
>>> FailingFlushWriter())));
>>>
>>>          if (failed > 0)
>>>              throw new RuntimeException(failed + " test(s) failed -
>>> see log for details");
>>>
>>>
>>> -Chris.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-7015589
>>> [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/759aa847dcaf
>>>
>>>
>>>> -Pavel
>>>>
>>>>> On 5 Dec 2014, at 01:18, Vitaly Davidovich <vitalyd at gmail.com> wrote:
>>>>>
>>>>> Attempting to make close() atomic just makes the next reader
>>>>> confused when the rest of the class isn't and may also penalize 
>>>>> single
>>>>> threaded callers of close().
>>>>
>>



From kumar.x.srinivasan at oracle.com  Fri Dec  5 17:47:40 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 05 Dec 2014 09:47:40 -0800
Subject: XXS RFR: JDK-8066745: tools/pack200/Pack200Props.java failed
	with java.lang.OutOfMemoryError: Java heap space
In-Reply-To: <5481E74E.9050104@oracle.com>
References: <5481D3F4.6090208@oracle.com> <5481E74E.9050104@oracle.com>
Message-ID: <5481EFBC.2020209@oracle.com>

Hang on, I have to increase the Heap size to pack200.exe, I will
repost the changes, when I am done testing with JPRT.

Kumar

On 12/5/2014 9:11 AM, Alan Bateman wrote:
> On 05/12/2014 15:49, Kumar Srinivasan wrote:
>> Hi Alan,
>>
>> Per your suggestion I have made this othervm.
>>
>> Thanks
>> Kumar
> Do you want to add -Xshare:off too? Just wondering how tight this is 
> on 32-bit Windows.
>
> -Alan.



From peter.levart at gmail.com  Fri Dec  5 18:16:42 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Fri, 05 Dec 2014 19:16:42 +0100
Subject: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support
	eviction
In-Reply-To: <547C9E37.8080809@oracle.com>
References: <547C9E37.8080809@oracle.com>
Message-ID: <5481F68A.2030201@gmail.com>

On 12/01/2014 05:58 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8057020
>
> There are 2 major LambdaForm caches: LambdaFormEditor-based and 
> MethodTypeForm. The former is per-LambdaForm and the latter is per 
> method type erased to basic types. The problem is that these caches 
> don't support eviction, so they can hold LambdaForms forever.
>
> Usually, it's not a problem since an application has very limited 
> number of unique erased method types (e.g. on Octane/Nashorn it varies 
> 1,5-3k shapes).
>
> The fix is to use SoftReferences to keep LambdaForms alive as long as 
> possible, but avoid throwing OOME until the caches are evicted. I 
> experimented with WeakReferences, but it doesn't hold LambdaForms for 
> long enough: LambdaForm cache hit rate degrades significantly and it 
> negatively affects application startup and warmup, since every 
> instantiated LambdaForm is precompiled to bytecode before usage.
>
> Testing: jdk/java/lang/invoke/LFCache in stress mode + jck 
> (api/java_lang/invoke), jdk/java/lang/invoke, jdk/java/util/streams, 
> octane
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov

Hi Vladimir,

So WeakReferences did not hold LambdaForms long enough even with strong 
back-reference from LambdaForm to the lambda form 'this' was derived 
from? So final derived LambdaForms (leaves) are not kept referenced from 
the code? Or did back-references keep intermediate LambdaForms in cache 
for too long (forever?) and you wanted them to be evicted too?

Regards, Peter



From chris.hegarty at oracle.com  Fri Dec  5 18:29:50 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 5 Dec 2014 18:29:50 +0000
Subject: Library enhancement proposal for copying data from/to
	Reader/Writer InputStream/OutputStream
In-Reply-To: <72DDE6F7-6B03-47D5-A125-BCA3D5CD624E@reini.net>
References: <566A428C-1A13-4DEE-940B-2EBE375F2A7A@reini.net>
	<E9277204-264A-49A8-971C-6B2FF0B831A4@reini.net>
	<FB33655F-D0D8-47CF-82B0-530C9A212B8E@oracle.com>
	<B10C4D8D-6A57-41FE-8ABC-54E09B4DA14D@reini.net>
	<A3953E4D-018A-44C8-8106-DC9E4663D67C@reini.net>
	<C62A3014-1F54-41E4-B560-198F87305B9E@reini.net>
	<54772C7D.7080209@oracle.com>
	<769E83F8-FD6D-4F8B-B415-DD044C5D08BA@reini.net>
	<D1E803CB-29AF-46AA-9990-77B2A05EFBD4@oracle.com>
	<547757EE.4090205@oracle.com>
	<ED697D7C-F60A-4CD7-B84E-88C10D45B9FB@reini.net>
	<D2DD43D0-5D86-446A-A67A-8D3AEB2541CD@oracle.com>
	<15B58029-95FA-4D9E-AA28-7A6C72D6CB3D@reini.net>
	<13156FAC-6EDC-462B-9BE7-2DFAFB9124FD@oracle.com>
	<20141128201546.000067ce.ecki@zusammenkunft.net>
	<<216A14EF-B62C-4971!	-!> <8194-E...>
	<8E1109C5-4C9E-4B7A-924E-9E92B3F93F89@reini.net>
	<150A2C4B-E239-433C-B0C9-39F70E98D837@oracle.com>
	<5480B9CE.20!	90600@reini.net>
	<DAAE3744-D74C-4528-9498-B7389DC784EF@oracle.com>
	<5481D174.2030406@oracle.com> <5481D67E.9080504@oracle.com!
	! > <548... <72DDE6F7-6B03-47D5-A125-BCA3D5CD624E@reini.net>
Message-ID: <AE34D5A9-FEAC-417C-8A10-F4EC96B4B0A8@oracle.com>


On 5 Dec 2014, at 17:28, Patrick Reinhart <patrick at reini.net> wrote:

> Hi Chris,
> 
>> Am 05.12.2014 um 17:36 schrieb Chris Hegarty <chris.hegarty at oracle.com>:
>> 
>> On 05/12/14 15:59, Alan Bateman wrote:
>>> On 05/12/2014 15:38, Chris Hegarty wrote:
>>>> The addition of a copyTo method to java.io.InputStream is binary
>>>> compatible [1], but it may, in some cases, be source incompatible. I
>>>> believe the benefits of this approach out weigh the potential source
>>>> incompatibility, but it will be for the spec gods, the CCC, to have
>>>> final say.
>>>> 
>>>> Here is what I propose. Let's take just InputStream.copyTo and bring
>>>> it, by itself, to a conclusion. And then revisit each of the
>>>> additional useful/convenience methods on their own merit.
>>> I think the approach is good. An alternative name to consider is
>>> transferTo. For the javadoc then you can make it clear that the
>>> InputStream is at EOF when the method completes. I don't think the
>>> javadoc needs to say that the OutputStream should be closed promptly
>>> (think "cat a b c > d").
>> 
>> Right. Updated spec:
>> 
>>    /**
>>     * Reads all remaining bytes from this input stream and writes them to
>>     * the given output stream.  On return, this input stream will be at end of
>>     * stream.
>>     * <p>
>>     * This method may block indefinitely reading from the input stream,
>>     * or writing to the output stream. The behavior for the case that the
>>     * input and/or output stream is <i>asynchronously closed</i>, or the
>>     * thread interrupted during the copy, is highly input and output stream
>>     * specific, and therefore not specified.
>>     * <p>
>>     * If an I/O error occurs reading from the input stream or writing to
>>     * the output stream, then it may do so after some bytes have been read or
>>     * written. Consequently the input stream may not be at end of stream and
>>     * may be in an inconsistent state. It is strongly recommended that the
>>     * input stream be promptly closed if an I/O error occurs.
>>     *
>>     * @param  out         the output stream to write to, non-null
>>     * @return             the number of bytes copied
>>     * @throws IOException if an I/O error occurs when reading or writing
>>     * @throws NullPointerException  if {@code out} is {@code null}
>>     *
>>     * @since 1.9
>>     */
>>    public long transferTo(OutputStream out) throws IOException { ... }
>> 
>> -Chris.
> 
> Looks good to me. The only thing I would change is the @return documentation to ?the number of bytes transferred? to be in sync with the method name.

Agreed. Consider it changed.

-Chris.

> -Patrick
> 



From joe.darcy at oracle.com  Fri Dec  5 19:11:20 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 05 Dec 2014 11:11:20 -0800
Subject: RFR: JDK-8058407: Remove Multiple JRE support in the Java launcher
In-Reply-To: <5481CDB1.8080208@oracle.com>
References: <5481CDB1.8080208@oracle.com>
Message-ID: <54820358.6090701@oracle.com>

Looks good,

-Joe

On 12/5/2014 7:22 AM, Kumar Srinivasan wrote:
> Hello,
>
> Please review the fix for JDK-8058407, contributed by Neil Toda, 
> described by JEP 231 [1]
> the webrev is at: http://cr.openjdk.java.net/~ksrini/8058407/webrev.00/
>
> Please note: The above webrev is identical to the original posted by 
> Neal at
> http://cr.openjdk.java.net/~ntoda/8058407/webrev-03/
>
>
> Thanks
> Kumar
>
> [1] http://openjdk.java.net/jeps/231



From daniel.fuchs at oracle.com  Fri Dec  5 20:06:53 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 05 Dec 2014 21:06:53 +0100
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <5480EFE8.3090809@oracle.com>
References: <547F9302.3060309@oracle.com>
	<547FD6F2.5060400@oracle.com>	<548023D0.4020702@oracle.com>
	<548047C3.8000400@oracle.com>	<54804E4B.2070908@oracle.com>
	<5480529F.1020902@oracle.com> <54805B5D.5020504@oracle.com>
	<54809627.8070103@oracle.com> <5480EFE8.3090809@oracle.com>
Message-ID: <5482105D.40005@oracle.com>

Hi David, all,

@David: You're right David.
         The loader parameter is never used - I have removed it.

@all: I have received a comment from Alan that it would be better to use
       the new jrt:/ FileSystem directly, rather than using private APIs.
       One of the consequence is that the test now loads all the
       classes in the runtime image (not just the ones in the BCL),
       and therefore I have removed the toggle that allowed to test
       the boot classes only.

http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/

best regards,

-- daniel

On 05/12/14 00:36, David Holmes wrote:
> Hi Daniel,
>
> I still find your use of the classloader very confusing. You talk about
> the defining loader but you never check the defining loader against
> anything. In
>
>   146         static void checkFor(Class<?> c, ClassLoader loader) {
>
> the loader variable is never used. And if loader is simply the name of
> the loader passed to forName, then it may not be the defining loader
> anyway - so the whole use of this loader variable seems superfluous at
> best, and confusing/misleading at worst. And you can use the simple
> forName(name) variant rather than passing a loader.
>
> David
>
> On 5/12/2014 3:13 AM, Daniel Fuchs wrote:
>> On 04/12/14 14:02, Se?n Coffey wrote:
>>> Thanks for driving efforts in this area Daniel. I think it's a very
>>> useful test and is bound to help test code coverage. If it's currently
>>> passing on all JPRT platforms, it's a good measure.
>>
>> It seems to :-)
>>
>>> Eventually I think we can bulk up the tests that can be run on the
>>> Iterable returned from your class search.
>>> At moment you just test Field.setAccessible.
>>
>> Yes. If we change it later to test more, we will probably need to
>> change its name. I was already in lack of inspiration:
>> FieldSetAccessibleTest is not really a great name - but hopefully
>> it can do for now.
>>
>>> In the future, I don't see any harm in adding all simple Field method
>>> calls so that any corner cases in custom classes like the original issue
>>> are caught. e.g Field.getDeclaredAnnotations(), Field.getModifiers(),
>>> Field.isEnumConstant() etc., etc. Some methods won't be much value add
>>> but they're not a cost either.
>>
>> Agreed.
>>
>>> Same argument for running through all Class methods, e.g
>>> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a result this
>>> test might eventually become more general in test goal and might live
>>> better one level up in "test/java/lang/Class/" - it can be moved when
>>> the time comes.
>>
>> Agreed as well :-)
>>
>> Here is a new revision of the webrev for 9 in which I have
>> incorporated David's comment:
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/
>>
>> best regards,
>>
>> -- daniel
>>
>>>
>>> regards,
>>> Sean.
>>>
>>> On 04/12/2014 12:25, Daniel Fuchs wrote:
>>>> On 04/12/14 13:06, David Holmes wrote:
>>>>> Hi Daniel,
>>>>>
>>>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> In fact I could use 'null' on JDK 9 as well.
>>>>>> My first version of the JDK 9 test was parsing over all the .jimage
>>>>>> files under <jdk>/lib/modules - which explain why I needed to
>>>>>> use the System class loader.
>>>>>>
>>>>>> Then I switched to only parsing the bootmodules.jimage - because
>>>>>> I noticed that the results where more coherent with what I had
>>>>>> observed on 8 & 7 - but I kept using the System class loader.
>>>>>>
>>>>>> I am not sure whether we want the test for 9 should iterate over
>>>>>> the three .jimage - or continue to test only the boot .jimage.
>>>>>>
>>>>>> I have updated the JDK 9 test (refreshed the webrev in place)
>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/
>>>>>> and added support for possibly running the test in the two modes
>>>>>> (I added a 'test.boot.only' system property, true by default)
>>>>>> as well as additional traces to print the loaded classes by
>>>>>> defining loader at the end (test.list.classes, false by default).
>>>>>
>>>>> A couple of initial comments:
>>>>>
>>>>>   104     static ClassLoader getClassLoaderFor(String classFileName) {
>>>>>   105         if (restrictToBoot) return null; // only bootmodules
>>>>>   106         return ClassLoaders.systemClassLoader;
>>>>>   107     }
>>>>>
>>>>> I'm not clear the intent here. If it is to return a loader for which
>>>>> loadClass could be invoked then you can always just return the system
>>>>> loader - or just Class.forName. If it is meant to the return the
>>>>> expected defining loader then it isn't doing that as the extensions
>>>>> loader is not allowed for.
>>>>
>>>> The intent is to return the class loader that will be passed to
>>>> Class.forName( ). I've been fiddling & experimenting with this
>>>> test over 3 different platforms while trying to minimize the
>>>> differences - so that was my attempt at having a good place to
>>>> experiment with different strategy for loading classes.
>>>>
>>>>> Similarly for:
>>>>>
>>>>>   128         static ClassLoader getFor(String classFileName) {
>>>>>   129             return systemClassLoader;
>>>>>   130         }
>>>>
>>>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..)
>>>> was supposed to simply return ClassLoaders.getFor(...);
>>>> and all the code should be in ClassLoaders.getFor - my bad.
>>>>
>>>>> Minor nit - In:
>>>>>
>>>>> 135                     System.err.println("Unexpected loader for
>>>>> "+c+":
>>>>> "+c.getClassLoader());
>>>>>
>>>>> c.getClassLoader() can be replaced by cl. Also put spaces around the +
>>>>> operator.
>>>>
>>>> Good catch.
>>>>
>>>> Thanks a lot David! Have a good night! (that's quite late - isn't it?)
>>>>
>>>> -- daniel
>>>>
>>>>>
>>>>> David
>>>>> (signing off for the night)
>>>>>
>>>>>> Thanks for your question, it triggered me into looking deeper
>>>>>> into what was happening :-)
>>>>>>
>>>>>> best regards,
>>>>>>
>>>>>> -- daniel
>>>>>>
>>>>>> On 04/12/14 10:05, Daniel Fuchs wrote:
>>>>>>>>> The differences between 8 & 9 are limited to:
>>>>>>>>>
>>>>>>>>>     - ClassLoader:
>>>>>>>>>          - on 8 we use 'null' (BCL)
>>>>>>>>>          - on 9 we use the system class loader.
>>>>>>>>
>>>>>>>> I haven't seen anything in JEP 220, regarding modules, that
>>>>>>>> indicates
>>>>>>>> that classes currently loaded  by the boot-loader will now be
>>>>>>>> loaded
>>>>>>>> by the system classloader ???
>>>>>>>
>>>>>>> In [1] towards the end:
>>>>>>>
>>>>>>> [1] http://openjdk.java.net/jeps/220
>>>>>>>
>>>>>>> "The defining class loader of the types in some existing packages
>>>>>>>   will change. Existing code that makes assumptions about the class
>>>>>>>   loaders of these types might not work correctly."
>>>>>>>   (then there is a list of specific changes).
>>>>>>>
>>>>>>> This test looks up all class names in the image files and attempt
>>>>>>> to load the corresponding class. But as indicated in [1]
>>>>>>> some of these classes are now in the Boot CL, some in the
>>>>>>> Extension CL, and some in the Application CL.
>>>>>>>
>>>>>>> So the test uses the System CL to load each class - which ensures
>>>>>>> that the loading will be delegated to the appropriate ClassLoader.
>>>>>>>
>>>>>>> best regards,
>>>>>>>
>>>>>>> -- daniel
>>>>>>
>>>>
>>>
>>



From martinrb at google.com  Fri Dec  5 21:29:44 2014
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 5 Dec 2014 13:29:44 -0800
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <54810C0C.2080901@oracle.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>
	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>
	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>
	<54810C0C.2080901@oracle.com>
Message-ID: <CA+kOe0_LU1-RUJ0pNdkR9k1rbCb16mRd-x1ebAd8dwpoQneE2g@mail.gmail.com>

On Thu, Dec 4, 2014 at 5:36 PM, David Holmes <david.holmes at oracle.com> wrote:
> Martin,
>
> On 2/12/2014 6:46 AM, Martin Buchholz wrote:

> Is this finalized then? You can only make one commit per CR.

Right.  I'd like to commit and then perhaps do another round of clarifications.

> I still find this entire comment block to be misguided and misplaced:
>
> !     // Fences, also known as memory barriers, or membars.
> !     // See hotspot sources for more details:
> !     // orderAccess.hpp memnode.hpp unsafe.cpp
> !     //
> !     // One way of implementing Java language-level volatile variables
> using
> !     // fences (but there is often a better way without) is by:
> !     // translating a volatile store into the sequence:
> !     // - storeFence()
> !     // - relaxed store
> !     // - fullFence()
> !     // and translating a volatile load into the sequence:
> !     // - if (CPU_NOT_MULTIPLE_COPY_ATOMIC) fullFence()
> !     // - relaxed load
> !     // - loadFence()
> !     // The full fence on volatile stores ensures the memory model
> guarantee of
> !     // sequential consistency on most platforms.  On some platforms (ppc)
> we
> !     // need an additional full fence between volatile loads as well (see
> !     // hotspot's CPU_NOT_MULTIPLE_COPY_ATOMIC).

Even I think this comment is marginal - I will delete it.  But
consider this a plea for better documentation of the hotspot
internals.

> why do want this description here - it has no relevance to the API itself,
> nor to how volatiles are implemented in the VM. And as I said in the bug
> report CPU_NOT_MULTIPLE_COPY_ATOMIC exists only for platforms that want to
> implement IRIW (none of our platforms are multiple-copy-atomic, but only PPC
> sets this so that it employs IRIW).

I believe the comment _does_ reflect hotspot's current implementation
(entirely from exploring the sources).
I believe it's correct to say "all of the platforms are
multiple-copy-atomic except PPC".
I believe hotspot must implement IRIW correctly to fulfil the promise
of sequential consistency for standard Java, so on ppc volatile reads
get a full fence, which leads us back to the ppc pointer chasing
performance problem that started all of this.


From martinrb at google.com  Fri Dec  5 21:49:23 2014
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 5 Dec 2014 13:49:23 -0800
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <5481108A.3030605@oracle.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>
	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>
	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>
	<5481108A.3030605@oracle.com>
Message-ID: <CA+kOe08OC57hEgGR-3CSfsJUMVSk-_mCmZK2Gd=3tpkE9=6j_w@mail.gmail.com>

On Thu, Dec 4, 2014 at 5:55 PM, David Holmes <david.holmes at oracle.com> wrote:

> In general phrasing like: " also known as a LoadLoad plus LoadStore barrier
> ..." is misleading to me as these are not "aliases"- the loadFence (in this
> case) is being specified to have the same semantics as the
> loadload|storeload. It should say "corresponds to a LoadLoad plus LoadStore
> barrier"

+     * Ensures that loads before the fence will not be reordered with loads and
+     * stores after the fence; also known as a LoadLoad plus LoadStore barrier,

I don't understand this.  I believe they _are_ aliases.  The first
clause perfectly describes a "LoadLoad plus LoadStore barrier".

 - as per the "Corresponds to a C11 ...". And referring to things
> like "load-acquire fence" is meaningless without some reference to a
> definition - who defines a load-acquire fence? Is there a universal
> definition? I would be okay with something looser eg:

Well, I'm defining "load-acquire fence" here in the javadoc - I'm
claiming that loadFence is also known via other terminology, including
"load-acquire fence".  Although it's true that "load-acquire fence" is
also used to refer to the corresponding C11 fence, which has subtly
different semantics.

> /**
>   * Ensures that loads before the fence will not be reordered with loads and
>   * stores after the fence. Corresponds to a LoadLoad plus LoadStore
> barrier,
>   * and also to the C11 atomic_thread_fence(memory_order_acquire).
>   * Sometimes referred to as a "load-acquire fence".
>   *
>
> Also I find this comment strange:
>
> !      * A pure StoreStore fence is not provided, since the addition of
> LoadStore
> !      * is almost always desired, and most current hardware instructions
> that
> !      * provide a StoreStore barrier also provide a LoadStore barrier for
> free.
>
> because inside hotspot we use storeStore barriers a lot, without any
> loadStore at the same point.

I believe the use of e.g. OrderAccess::storestore in the hotspot
sources is unfortunate.

The actual implementations of storestore (see below) seem to
universally give you the stronger ::release barrier, and it seems
likely that hotspot engineers are implicitly relying on that, that
some uses of ::storestore in the hotspot sources are bugs (should be
::release instead) and that there is very little potential performance
benefit from using ::storestore instead of ::release, precisely
because the additional loadstore barrier is very close to free on all
current hardware.  Writing correct code using ::storestore is harder
than ::release, which is already difficult enough. C11 doesn't provide
a corresponding fence, which is a strong hint.


./bsd_zero/vm/orderAccess_bsd_zero.inline.hpp:71:inline void
OrderAccess::storestore() { release(); }
./linux_sparc/vm/orderAccess_linux_sparc.inline.hpp:35:inline void
OrderAccess::storestore() { release(); }
./aix_ppc/vm/orderAccess_aix_ppc.inline.hpp:73:inline void
OrderAccess::storestore() { inlasm_lwsync();  }
./linux_zero/vm/orderAccess_linux_zero.inline.hpp:70:inline void
OrderAccess::storestore() { release(); }
./solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp:40:inline void
OrderAccess::storestore() { release(); }
./linux_ppc/vm/orderAccess_linux_ppc.inline.hpp:75:inline void
OrderAccess::storestore() { inlasm_lwsync();  }
./solaris_x86/vm/orderAccess_solaris_x86.inline.hpp:40:inline void
OrderAccess::storestore() { release(); }
./linux_x86/vm/orderAccess_linux_x86.inline.hpp:35:inline void
OrderAccess::storestore() { release(); }
./bsd_x86/vm/orderAccess_bsd_x86.inline.hpp:35:inline void
OrderAccess::storestore() { release(); }
./windows_x86/vm/orderAccess_windows_x86.inline.hpp:35:inline void
OrderAccess::storestore() { release(); }


From chris.hegarty at oracle.com  Fri Dec  5 22:37:04 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 5 Dec 2014 22:37:04 +0000
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <5481EF01.6060009@gmail.com>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>	<54807258.4040303@oracle.com>	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>	<20141205002430.000060c9.ecki@zusammenkunft.net>	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>	<20141205015827.00007ac6.ecki@zusammenkunft.net>	<CAHjP37HgKZMhjq6_AVZFAdPy4PeZBd7p6JBT0Jt2FqE42eB6Ow@mail.gmail.com>	<8F896CE2-E268-418F-96CA-0557C1C258B3@oracle.com>
	<5481BB6C.1040700@oracle.com> <5481C3DB.70303@gmail.com>
	<5481CA8C.7050100@oracle.com> <5481EF01.6060009@gmail.com>
Message-ID: <C517EC9F-7136-4252-BA5B-FFE8C2CBD4B4@oracle.com>


On 5 Dec 2014, at 17:44, Peter Levart <peter.levart at gmail.com> wrote:

> On 12/05/2014 04:09 PM, Chris Hegarty wrote:
>> On 05/12/14 14:40, Peter Levart wrote: 
>>> On 12/05/2014 03:04 PM, Chris Hegarty wrote: 
>>>> 
>>>> On 05/12/14 11:38, Pavel Rappo wrote: 
>>>>> +1, I couldn?t say better 
>>>> 
>>>> Right. This bug should only try to address the change in behavior that 
>>>> was inadvertently introduced by 7015589[1][2]. 
>>> 
>>> What about the following: 
>>> 
>>> 
>>> private boolean closed; 
>>> 
>>> public void close() throws IOException { 
>>>      try (OutputStream ostream = out) { 
>>>          if (!closed)  flush(); 
>>>      } 
>>>      closed = true; 
>>> } 
>> 
>> If flush throws, how is anyone supposed to know that they need to call close again, and that it was not the close that actually threw? 
> 
> If they call close() again because they are used to pre 7015589 behaviour,

I don?t think I have every seen any code that catches the IOException from close() , and tries to close again. But maybe someone does this?

From AutoCloseable:
  ?Cases where the close operation may fail require careful attention by implementers. It is strongly advised to relinquish the underlying resources and to internally mark the resource as closed, prior to throwing the exception. The close method is unlikely to be invoked more than once and so this ensures that the resources are released in a timely manner. Furthermore it reduces problems that could arise when the resource wraps, or is wrapped, by another resource.?

I think the changes I am proposing follows this advise ( as best we can ).

> there is no harm if they call it as a consequence of flush() throwing and out.close() succeeding, since the underlying stream should

Yes, ?should".

> have idempotent "successful" close(). That's the requirement of Closeable.close():
> 
> /**
> * Closes this stream and releases any system resources associated
> * with it. If the stream is already closed then invoking this
> * method has no effect.

FilterOutputStream is Closeable, but what you are suggesting is that subsequent calls to close would have an effect, they may call flush.

> * <p> As noted in {@link AutoCloseable#close()}, cases where the
> * close may fail require careful attention. It is strongly advised
> * to relinquish the underlying resources and to internally
> * <em>mark</em> the {@code Closeable} as closed, prior to throwing
> * the {@code IOException}.
> *
> * @throws IOException if an I/O error occurs
> */
> 
> The specification does not say if the stream is to be considered "closed" when close() throws IOException. The advice does hint that though (and was added about 3 years ago).

Re-reading the advise in AutoCloseable and Closeable, I do not see any problem with the changes I suggested.

-Chris.

>> close() should be a one-time shot. 
>> 
>> I personally think that this was an oversight of the original change in 7015589, and not a deliberate behavior. My proposed change will restore the behavior of close to pre 7015589, though not swallow the IOException from flush. 
> 
> The pre 7015589 behaviour did not suppress multiple close() calls to underlying stream.
> 
>> 
>> -Chris. 
> 
> I just think that a delegating class like FilterOutputStream should be as transparent as possible. If the underlying stream respects the contract and advice, the wrapped stream should too. If underlying stream needs some out-of-advice treatment, then wrapper like FilterOutputStream should not prevent that, because there are all kinds of streams out there. Or maybe it should - this is the only way to "fix" those streams ;-)
> 
> Just do it!
> 
> Regards, Peter
> 
>> 
>>> ...this way the impact of the change is minimal and still addresses the 
>>> problem of JDK-8054565 <https://bugs.openjdk.java.net/browse/JDK-8054565>. 
>>> 
>>> If either flush() or out.close() throw exception the 1st time close() is 
>>> called, they will both be called also the 2nd time. Only after flush() 
>>> and out.close() return successfully, then further flush() invocations 
>>> are suppressed. 
>>> 
>>> The alternative would be to not suppress flush() invocations, but just 
>>> any exception thrown from flush(): 
>>> 
>>> 
>>>      private boolean closed; 
>>> 
>>>      public void close() throws IOException { 
>>>          try (OutputStream ostream = out) { 
>>>              try { 
>>>                  flush(); 
>>>              } catch (IOException | RuntimeException | Error e) { 
>>>                  if (!closed) throw e; 
>>>              } 
>>>          } 
>>>          closed = true; 
>>>      } 
>>> 
>>> 
>>> But I don't know if this is better or worse. It certainly could still be 
>>> squeezed under the spec which says: 
>>> 
>>>       * The <code>close</code> method of <code>FilterOutputStream</code> 
>>>       * calls its <code>flush</code> method, and then calls the 
>>>       * <code>close</code> method of its underlying output stream. 
>>> 
>>> 
>>> Regards, Peter 
>>> 
>>>> 
>>>> I don't see any reason to make 'closed' protected ( part of the public 
>>>> Java SE API ), something like: 
>>>> 
>>>> diff --git 
>>>> a/src/java.base/share/classes/java/io/FilterOutputStream.java 
>>>> b/src/java.base/share/classes/java/io/FilterOutputStream.java 
>>>> --- a/src/java.base/share/classes/java/io/FilterOutputStream.java 
>>>> +++ b/src/java.base/share/classes/java/io/FilterOutputStream.java 
>>>> @@ -48,6 +48,8 @@ 
>>>>       */ 
>>>>      protected OutputStream out; 
>>>> 
>>>> +    private boolean closed; // false 
>>>> + 
>>>>      /** 
>>>>       * Creates an output stream filter built on top of the specified 
>>>>       * underlying output stream. 
>>>> @@ -154,6 +156,9 @@ 
>>>>       */ 
>>>>      @SuppressWarnings("try") 
>>>>      public void close() throws IOException { 
>>>> +        if (closed) 
>>>> +            return; 
>>>> +        closed = true; 
>>>>          try (OutputStream ostream = out) { 
>>>>              flush(); 
>>>>          } 
>>>> 
>>>> diff --git a/test/java/io/etc/FailingFlushAndClose.java 
>>>> b/test/java/io/etc/FailingFlushAndClose.java 
>>>> --- a/test/java/io/etc/FailingFlushAndClose.java 
>>>> +++ b/test/java/io/etc/FailingFlushAndClose.java 
>>>> @@ -25,7 +25,7 @@ 
>>>> 
>>>>  /** 
>>>>   * @test 
>>>> - * @bug 7015589 
>>>> + * @bug 7015589 8054565 
>>>>   * @summary Test that buffering streams are considered closed even 
>>>> when the 
>>>>   *    close or flush from the underlying stream fails. 
>>>>   */ 
>>>> @@ -165,7 +165,7 @@ 
>>>>          } 
>>>>      } 
>>>> 
>>>> -    static void testFailingClose(InputStream in) throws IOException { 
>>>> +    static InputStream testFailingClose(InputStream in) throws 
>>>> IOException { 
>>>>          System.out.println(in.getClass()); 
>>>>          in.read(new byte[100]); 
>>>>          try { 
>>>> @@ -176,9 +176,10 @@ 
>>>>              in.read(new byte[100]); 
>>>>              fail("read did not fail"); 
>>>>          } catch (IOException expected) { } 
>>>> +        return in; 
>>>>      } 
>>>> 
>>>> -    static void testFailingClose(OutputStream out) throws IOException { 
>>>> +    static OutputStream testFailingClose(OutputStream out) throws 
>>>> IOException { 
>>>>          System.out.println(out.getClass()); 
>>>>          out.write(1); 
>>>>          try { 
>>>> @@ -190,9 +191,10 @@ 
>>>>              if (!(out instanceof BufferedOutputStream)) 
>>>>                  fail("write did not fail"); 
>>>>          } catch (IOException expected) { } 
>>>> +        return out; 
>>>>      } 
>>>> 
>>>> -    static void testFailingFlush(OutputStream out) throws IOException { 
>>>> +    static OutputStream testFailingFlush(OutputStream out) throws 
>>>> IOException { 
>>>>          System.out.println(out.getClass()); 
>>>>          out.write(1); 
>>>>          try { 
>>>> @@ -206,9 +208,27 @@ 
>>>>                  fail("close did not fail"); 
>>>>              } catch (IOException expected) { } 
>>>>          } 
>>>> +        return out; 
>>>>      } 
>>>> 
>>>> -    static void testFailingClose(Reader r) throws IOException { 
>>>> +    static void closeAgain(InputStream in) throws IOException { 
>>>> +        // assert the given stream should already be closed. 
>>>> +        try { 
>>>> +            in.close(); 
>>>> +        } catch (IOException expected) { 
>>>> +            fail("unexpected IOException from subsequent close"); 
>>>> +        } 
>>>> +    } 
>>>> +    static void closeAgain(OutputStream out) throws IOException { 
>>>> +        // assert the given stream should already be closed. 
>>>> +        try { 
>>>> +            out.close(); 
>>>> +        } catch (IOException expected) { 
>>>> +            fail("unexpected IOException from subsequent close"); 
>>>> +        } 
>>>> +    } 
>>>> + 
>>>> +    static Reader testFailingClose(Reader r) throws IOException { 
>>>>          System.out.println(r.getClass()); 
>>>>          r.read(new char[100]); 
>>>>          try { 
>>>> @@ -219,9 +239,10 @@ 
>>>>              r.read(new char[100]); 
>>>>              fail("read did not fail"); 
>>>>          } catch (IOException expected) { } 
>>>> +        return r; 
>>>>      } 
>>>> 
>>>> -    static void testFailingClose(Writer w) throws IOException { 
>>>> +    static Writer testFailingClose(Writer w) throws IOException { 
>>>>          System.out.println(w.getClass()); 
>>>>          w.write("message"); 
>>>>          try { 
>>>> @@ -232,9 +253,10 @@ 
>>>>              w.write("another message"); 
>>>>              fail("write did not fail"); 
>>>>          } catch (IOException expected) { } 
>>>> +        return w; 
>>>>      } 
>>>> 
>>>> -    static void testFailingFlush(Writer w) throws IOException { 
>>>> +    static Writer testFailingFlush(Writer w) throws IOException { 
>>>>          System.out.println(w.getClass()); 
>>>>          w.write("message"); 
>>>>          try { 
>>>> @@ -249,18 +271,38 @@ 
>>>>                  fail("close did not fail"); 
>>>>              } catch (IOException expected) { } 
>>>>          } 
>>>> +        return w; 
>>>> +    } 
>>>> + 
>>>> +    static Reader closeAgain(Reader r) throws IOException { 
>>>> +        // assert the given stream should already be closed. 
>>>> +        try { 
>>>> +            r.close(); 
>>>> +        } catch (IOException expected) { 
>>>> +            fail("unexpected IOException from subsequent close"); 
>>>> +        } 
>>>> +        return r; 
>>>> +    } 
>>>> +    static Writer closeAgain(Writer w) throws IOException { 
>>>> +        // assert the given stream should already be closed. 
>>>> +        try { 
>>>> +            w.close(); 
>>>> +        } catch (IOException expected) { 
>>>> +            fail("unexpected IOException from subsequent close"); 
>>>> +        } 
>>>> +        return w; 
>>>>      } 
>>>> 
>>>>      public static void main(String[] args) throws IOException { 
>>>> 
>>>> -        testFailingClose(new BufferedInputStream(new 
>>>> FailingCloseInputStream())); 
>>>> -        testFailingClose(new BufferedOutputStream(new 
>>>> FailingCloseOutputStream())); 
>>>> +        closeAgain(testFailingClose(new BufferedInputStream(new 
>>>> FailingCloseInputStream()))); 
>>>> +        closeAgain(testFailingClose(new BufferedOutputStream(new 
>>>> FailingCloseOutputStream()))); 
>>>> 
>>>> -        testFailingClose(new BufferedReader(new FailingCloseReader())); 
>>>> -        testFailingClose(new BufferedWriter(new FailingCloseWriter())); 
>>>> +        closeAgain(testFailingClose(new BufferedReader(new 
>>>> FailingCloseReader()))); 
>>>> +        closeAgain(testFailingClose(new BufferedWriter(new 
>>>> FailingCloseWriter()))); 
>>>> 
>>>> -        testFailingFlush(new BufferedOutputStream(new 
>>>> FailingFlushOutputStream())); 
>>>> -        testFailingFlush(new BufferedWriter(new FailingFlushWriter())); 
>>>> +        closeAgain(testFailingFlush(new BufferedOutputStream(new 
>>>> FailingFlushOutputStream()))); 
>>>> +        closeAgain(testFailingFlush(new BufferedWriter(new 
>>>> FailingFlushWriter()))); 
>>>> 
>>>>          if (failed > 0) 
>>>>              throw new RuntimeException(failed + " test(s) failed - 
>>>> see log for details"); 
>>>> 
>>>> 
>>>> -Chris. 
>>>> 
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-7015589 
>>>> [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/759aa847dcaf 
>>>> 
>>>> 
>>>>> -Pavel 
>>>>> 
>>>>>> On 5 Dec 2014, at 01:18, Vitaly Davidovich <vitalyd at gmail.com> wrote: 
>>>>>> 
>>>>>> Attempting to make close() atomic just makes the next reader 
>>>>>> confused when the rest of the class isn't and may also penalize single 
>>>>>> threaded callers of close(). 
>>>>> 
>>> 
> 



From kumar.x.srinivasan at oracle.com  Sat Dec  6 01:36:01 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 05 Dec 2014 17:36:01 -0800
Subject: XXS RFR: JDK-8066745: tools/pack200/Pack200Props.java failed
	with java.lang.OutOfMemoryError: Java heap space
In-Reply-To: <5481EFBC.2020209@oracle.com>
References: <5481D3F4.6090208@oracle.com> <5481E74E.9050104@oracle.com>
	<5481EFBC.2020209@oracle.com>
Message-ID: <54825D81.4060501@oracle.com>

Alan,

The heap needs to be increased (1.2GB)  for this test, I think the 
default provided
by the launcher ergonomics is not sufficient on certain platforms. I've
tested the patch with JPRT.

Thanks
Kumar


diff --git a/test/tools/pack200/Pack200Props.java 
b/test/tools/pack200/Pack200Props.java
--- a/test/tools/pack200/Pack200Props.java
+++ b/test/tools/pack200/Pack200Props.java
@@ -62,6 +62,7 @@

          List<String> cmdsList = new ArrayList<>();
          cmdsList.add(Utils.getPack200Cmd());
+        cmdsList.add("-J-Xmx1280m");
          cmdsList.add("--effort=1");
          cmdsList.add("--verbose");
          cmdsList.add("--no-gzip");

On 12/5/2014 9:47 AM, Kumar Srinivasan wrote:
> Hang on, I have to increase the Heap size to pack200.exe, I will
> repost the changes, when I am done testing with JPRT.
>
> Kumar
>
> On 12/5/2014 9:11 AM, Alan Bateman wrote:
>> On 05/12/2014 15:49, Kumar Srinivasan wrote:
>>> Hi Alan,
>>>
>>> Per your suggestion I have made this othervm.
>>>
>>> Thanks
>>> Kumar
>> Do you want to add -Xshare:off too? Just wondering how tight this is 
>> on 32-bit Windows.
>>
>> -Alan.
>



From peter.levart at gmail.com  Sat Dec  6 10:16:28 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 06 Dec 2014 11:16:28 +0100
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <5482105D.40005@oracle.com>
References: <547F9302.3060309@oracle.com>	<547FD6F2.5060400@oracle.com>	<548023D0.4020702@oracle.com>	<548047C3.8000400@oracle.com>	<54804E4B.2070908@oracle.com>	<5480529F.1020902@oracle.com>
	<54805B5D.5020504@oracle.com>	<54809627.8070103@oracle.com>
	<5480EFE8.3090809@oracle.com> <5482105D.40005@oracle.com>
Message-ID: <5482D77C.9030100@gmail.com>


On 12/05/2014 09:06 PM, Daniel Fuchs wrote:
> Hi David, all,
>
> @David: You're right David.
>         The loader parameter is never used - I have removed it.
>
> @all: I have received a comment from Alan that it would be better to use
>       the new jrt:/ FileSystem directly, rather than using private APIs.
>       One of the consequence is that the test now loads all the
>       classes in the runtime image (not just the ones in the BCL),
>       and therefore I have removed the toggle that allowed to test
>       the boot classes only.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/
>
> best regards,
>
> -- daniel

Hi Daniel,

Would it be possible to extract a minimal API for streaming over classes 
and put that into the testlib so that only this part differs between 
JDK8 and JDK9 and the guts of the test is identical for both JDK8 and JDK9 ?

This would ease backport efforts when the test(s) are later "beefed up" 
with other functionality. The API could later be extended with other 
functionality, but just for illustration what might be needed,  here's 
what Martin Buchholz started as a test for finding possible data races 
in reflection and I just re-packed using Streams. From first glance it 
seems the tests need similar common functionality:

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

Regards, Peter

>
> On 05/12/14 00:36, David Holmes wrote:
>> Hi Daniel,
>>
>> I still find your use of the classloader very confusing. You talk about
>> the defining loader but you never check the defining loader against
>> anything. In
>>
>>   146         static void checkFor(Class<?> c, ClassLoader loader) {
>>
>> the loader variable is never used. And if loader is simply the name of
>> the loader passed to forName, then it may not be the defining loader
>> anyway - so the whole use of this loader variable seems superfluous at
>> best, and confusing/misleading at worst. And you can use the simple
>> forName(name) variant rather than passing a loader.
>>
>> David
>>
>> On 5/12/2014 3:13 AM, Daniel Fuchs wrote:
>>> On 04/12/14 14:02, Se?n Coffey wrote:
>>>> Thanks for driving efforts in this area Daniel. I think it's a very
>>>> useful test and is bound to help test code coverage. If it's currently
>>>> passing on all JPRT platforms, it's a good measure.
>>>
>>> It seems to :-)
>>>
>>>> Eventually I think we can bulk up the tests that can be run on the
>>>> Iterable returned from your class search.
>>>> At moment you just test Field.setAccessible.
>>>
>>> Yes. If we change it later to test more, we will probably need to
>>> change its name. I was already in lack of inspiration:
>>> FieldSetAccessibleTest is not really a great name - but hopefully
>>> it can do for now.
>>>
>>>> In the future, I don't see any harm in adding all simple Field method
>>>> calls so that any corner cases in custom classes like the original 
>>>> issue
>>>> are caught. e.g Field.getDeclaredAnnotations(), Field.getModifiers(),
>>>> Field.isEnumConstant() etc., etc. Some methods won't be much value add
>>>> but they're not a cost either.
>>>
>>> Agreed.
>>>
>>>> Same argument for running through all Class methods, e.g
>>>> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a result 
>>>> this
>>>> test might eventually become more general in test goal and might live
>>>> better one level up in "test/java/lang/Class/" - it can be moved when
>>>> the time comes.
>>>
>>> Agreed as well :-)
>>>
>>> Here is a new revision of the webrev for 9 in which I have
>>> incorporated David's comment:
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>>
>>>> regards,
>>>> Sean.
>>>>
>>>> On 04/12/2014 12:25, Daniel Fuchs wrote:
>>>>> On 04/12/14 13:06, David Holmes wrote:
>>>>>> Hi Daniel,
>>>>>>
>>>>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> In fact I could use 'null' on JDK 9 as well.
>>>>>>> My first version of the JDK 9 test was parsing over all the .jimage
>>>>>>> files under <jdk>/lib/modules - which explain why I needed to
>>>>>>> use the System class loader.
>>>>>>>
>>>>>>> Then I switched to only parsing the bootmodules.jimage - because
>>>>>>> I noticed that the results where more coherent with what I had
>>>>>>> observed on 8 & 7 - but I kept using the System class loader.
>>>>>>>
>>>>>>> I am not sure whether we want the test for 9 should iterate over
>>>>>>> the three .jimage - or continue to test only the boot .jimage.
>>>>>>>
>>>>>>> I have updated the JDK 9 test (refreshed the webrev in place)
>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/
>>>>>>> and added support for possibly running the test in the two modes
>>>>>>> (I added a 'test.boot.only' system property, true by default)
>>>>>>> as well as additional traces to print the loaded classes by
>>>>>>> defining loader at the end (test.list.classes, false by default).
>>>>>>
>>>>>> A couple of initial comments:
>>>>>>
>>>>>>   104     static ClassLoader getClassLoaderFor(String 
>>>>>> classFileName) {
>>>>>>   105         if (restrictToBoot) return null; // only bootmodules
>>>>>>   106         return ClassLoaders.systemClassLoader;
>>>>>>   107     }
>>>>>>
>>>>>> I'm not clear the intent here. If it is to return a loader for which
>>>>>> loadClass could be invoked then you can always just return the 
>>>>>> system
>>>>>> loader - or just Class.forName. If it is meant to the return the
>>>>>> expected defining loader then it isn't doing that as the extensions
>>>>>> loader is not allowed for.
>>>>>
>>>>> The intent is to return the class loader that will be passed to
>>>>> Class.forName( ). I've been fiddling & experimenting with this
>>>>> test over 3 different platforms while trying to minimize the
>>>>> differences - so that was my attempt at having a good place to
>>>>> experiment with different strategy for loading classes.
>>>>>
>>>>>> Similarly for:
>>>>>>
>>>>>>   128         static ClassLoader getFor(String classFileName) {
>>>>>>   129             return systemClassLoader;
>>>>>>   130         }
>>>>>
>>>>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..)
>>>>> was supposed to simply return ClassLoaders.getFor(...);
>>>>> and all the code should be in ClassLoaders.getFor - my bad.
>>>>>
>>>>>> Minor nit - In:
>>>>>>
>>>>>> 135                     System.err.println("Unexpected loader for
>>>>>> "+c+":
>>>>>> "+c.getClassLoader());
>>>>>>
>>>>>> c.getClassLoader() can be replaced by cl. Also put spaces around 
>>>>>> the +
>>>>>> operator.
>>>>>
>>>>> Good catch.
>>>>>
>>>>> Thanks a lot David! Have a good night! (that's quite late - isn't 
>>>>> it?)
>>>>>
>>>>> -- daniel
>>>>>
>>>>>>
>>>>>> David
>>>>>> (signing off for the night)
>>>>>>
>>>>>>> Thanks for your question, it triggered me into looking deeper
>>>>>>> into what was happening :-)
>>>>>>>
>>>>>>> best regards,
>>>>>>>
>>>>>>> -- daniel
>>>>>>>
>>>>>>> On 04/12/14 10:05, Daniel Fuchs wrote:
>>>>>>>>>> The differences between 8 & 9 are limited to:
>>>>>>>>>>
>>>>>>>>>>     - ClassLoader:
>>>>>>>>>>          - on 8 we use 'null' (BCL)
>>>>>>>>>>          - on 9 we use the system class loader.
>>>>>>>>>
>>>>>>>>> I haven't seen anything in JEP 220, regarding modules, that
>>>>>>>>> indicates
>>>>>>>>> that classes currently loaded  by the boot-loader will now be
>>>>>>>>> loaded
>>>>>>>>> by the system classloader ???
>>>>>>>>
>>>>>>>> In [1] towards the end:
>>>>>>>>
>>>>>>>> [1] http://openjdk.java.net/jeps/220
>>>>>>>>
>>>>>>>> "The defining class loader of the types in some existing packages
>>>>>>>>   will change. Existing code that makes assumptions about the 
>>>>>>>> class
>>>>>>>>   loaders of these types might not work correctly."
>>>>>>>>   (then there is a list of specific changes).
>>>>>>>>
>>>>>>>> This test looks up all class names in the image files and attempt
>>>>>>>> to load the corresponding class. But as indicated in [1]
>>>>>>>> some of these classes are now in the Boot CL, some in the
>>>>>>>> Extension CL, and some in the Application CL.
>>>>>>>>
>>>>>>>> So the test uses the System CL to load each class - which ensures
>>>>>>>> that the loading will be delegated to the appropriate ClassLoader.
>>>>>>>>
>>>>>>>> best regards,
>>>>>>>>
>>>>>>>> -- daniel
>>>>>>>
>>>>>
>>>>
>>>
>



From Alan.Bateman at oracle.com  Sat Dec  6 10:36:11 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 06 Dec 2014 10:36:11 +0000
Subject: XXS RFR: JDK-8066745: tools/pack200/Pack200Props.java failed
	with java.lang.OutOfMemoryError: Java heap space
In-Reply-To: <54825D81.4060501@oracle.com>
References: <5481D3F4.6090208@oracle.com> <5481E74E.9050104@oracle.com>
	<5481EFBC.2020209@oracle.com> <54825D81.4060501@oracle.com>
Message-ID: <5482DC1B.3020606@oracle.com>

On 06/12/2014 01:36, Kumar Srinivasan wrote:
> Alan,
>
> The heap needs to be increased (1.2GB)  for this test, I think the 
> default provided
> by the launcher ergonomics is not sufficient on certain platforms. I've
> tested the patch with JPRT.
>
> Thanks
> Kumar
>
>
> diff --git a/test/tools/pack200/Pack200Props.java 
> b/test/tools/pack200/Pack200Props.java
> --- a/test/tools/pack200/Pack200Props.java
> +++ b/test/tools/pack200/Pack200Props.java
> @@ -62,6 +62,7 @@
>
>          List<String> cmdsList = new ArrayList<>();
>          cmdsList.add(Utils.getPack200Cmd());
> +        cmdsList.add("-J-Xmx1280m");
>          cmdsList.add("--effort=1");
>          cmdsList.add("--verbose");
>          cmdsList.add("--no-gzip");
This looks okay to me although 1.2GB makes me wonder if you might still 
need -Xshare:off on Windows 32-bit.

-Alan


From Alan.Bateman at oracle.com  Sat Dec  6 10:40:13 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 06 Dec 2014 10:40:13 +0000
Subject: RFR: JDK-8058407: Remove Multiple JRE support in the Java launcher
In-Reply-To: <5481CDB1.8080208@oracle.com>
References: <5481CDB1.8080208@oracle.com>
Message-ID: <5482DD0D.8020003@oracle.com>

On 05/12/2014 15:22, Kumar Srinivasan wrote:
> Hello,
>
> Please review the fix for JDK-8058407, contributed by Neil Toda, 
> described by JEP 231 [1]
> the webrev is at: http://cr.openjdk.java.net/~ksrini/8058407/webrev.00/
>
> Please note: The above webrev is identical to the original posted by 
> Neal at
> http://cr.openjdk.java.net/~ntoda/8058407/webrev-03/
>
This looks good to me although I think in parse_manifest that you can 
removed completely the line that checks for JRE-Restrict-Search as it 
does nothing. A minor nit is the alignment of the calls to 
JLI_ReportErrorMessage(SPC_ERROR2), you might want to check those.

-Alan.


From daniel.fuchs at oracle.com  Sat Dec  6 10:44:47 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Sat, 06 Dec 2014 11:44:47 +0100
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <5482D77C.9030100@gmail.com>
References: <547F9302.3060309@oracle.com>	<547FD6F2.5060400@oracle.com>	<548023D0.4020702@oracle.com>	<548047C3.8000400@oracle.com>	<54804E4B.2070908@oracle.com>	<5480529F.1020902@oracle.com>
	<54805B5D.5020504@oracle.com>	<54809627.8070103@oracle.com>
	<5480EFE8.3090809@oracle.com> <5482105D.40005@oracle.com>
	<5482D77C.9030100@gmail.com>
Message-ID: <5482DE1F.5070906@oracle.com>

Hi Peter,


On 12/6/14 11:16 AM, Peter Levart wrote:
>
> On 12/05/2014 09:06 PM, Daniel Fuchs wrote:
>> Hi David, all,
>>
>> @David: You're right David.
>>         The loader parameter is never used - I have removed it.
>>
>> @all: I have received a comment from Alan that it would be better to use
>>       the new jrt:/ FileSystem directly, rather than using private APIs.
>>       One of the consequence is that the test now loads all the
>>       classes in the runtime image (not just the ones in the BCL),
>>       and therefore I have removed the toggle that allowed to test
>>       the boot classes only.
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/
>>
>> best regards,
>>
>> -- daniel
>
> Hi Daniel,
>
> Would it be possible to extract a minimal API for streaming over 
> classes and put that into the testlib so that only this part differs 
> between JDK8 and JDK9 and the guts of the test is identical for both 
> JDK8 and JDK9 ?
>
> This would ease backport efforts when the test(s) are later "beefed 
> up" with other functionality. The API could later be extended with 
> other functionality, but just for illustration what might be needed,  
> here's what Martin Buchholz started as a test for finding possible 
> data races in reflection and I just re-packed using Streams. From 
> first glance it seems the tests need similar common functionality:
>
> http://cr.openjdk.java.net/~plevart/misc/SunReflectDataRaces/
>
> Regards, Peter

The test is already built like that:

The part that finds the class names is encapsulated in an object which
implements Iterable<String>.

http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ -> 
ClassNameJrtStreamBuilder
http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8-00/ -> 
ClassNameStreamBuilder
http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00/ -> 
ClassNameListBuilder

The bulk of the test should be identical (well, almost identical since I 
only
updated 9 after the reviews, and since 9 is the only one that needs the
System ClassLoader)... I suppose we could extract these 3 classes and define
a library class with something like:

public static class ClassNameFinder {
      public static Iterable<String> findAllClassNames() {
jdk9 impl:            return new ClassNameJrtStreamBuilder();
jdk8 impl:            return new ClassNameStreamBuilder();
jdk7 impl:            return new ClassNameListBuilder();
      }
}

As it stands - this corresponds to the

  static Iterable<String> listAllClassNames()

factory method  in each version of the test.


best regards,

-- daniel

>
>>
>> On 05/12/14 00:36, David Holmes wrote:
>>> Hi Daniel,
>>>
>>> I still find your use of the classloader very confusing. You talk about
>>> the defining loader but you never check the defining loader against
>>> anything. In
>>>
>>>   146         static void checkFor(Class<?> c, ClassLoader loader) {
>>>
>>> the loader variable is never used. And if loader is simply the name of
>>> the loader passed to forName, then it may not be the defining loader
>>> anyway - so the whole use of this loader variable seems superfluous at
>>> best, and confusing/misleading at worst. And you can use the simple
>>> forName(name) variant rather than passing a loader.
>>>
>>> David
>>>
>>> On 5/12/2014 3:13 AM, Daniel Fuchs wrote:
>>>> On 04/12/14 14:02, Se?n Coffey wrote:
>>>>> Thanks for driving efforts in this area Daniel. I think it's a very
>>>>> useful test and is bound to help test code coverage. If it's 
>>>>> currently
>>>>> passing on all JPRT platforms, it's a good measure.
>>>>
>>>> It seems to :-)
>>>>
>>>>> Eventually I think we can bulk up the tests that can be run on the
>>>>> Iterable returned from your class search.
>>>>> At moment you just test Field.setAccessible.
>>>>
>>>> Yes. If we change it later to test more, we will probably need to
>>>> change its name. I was already in lack of inspiration:
>>>> FieldSetAccessibleTest is not really a great name - but hopefully
>>>> it can do for now.
>>>>
>>>>> In the future, I don't see any harm in adding all simple Field method
>>>>> calls so that any corner cases in custom classes like the original 
>>>>> issue
>>>>> are caught. e.g Field.getDeclaredAnnotations(), Field.getModifiers(),
>>>>> Field.isEnumConstant() etc., etc. Some methods won't be much value 
>>>>> add
>>>>> but they're not a cost either.
>>>>
>>>> Agreed.
>>>>
>>>>> Same argument for running through all Class methods, e.g
>>>>> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a 
>>>>> result this
>>>>> test might eventually become more general in test goal and might live
>>>>> better one level up in "test/java/lang/Class/" - it can be moved when
>>>>> the time comes.
>>>>
>>>> Agreed as well :-)
>>>>
>>>> Here is a new revision of the webrev for 9 in which I have
>>>> incorporated David's comment:
>>>>
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>>
>>>>>
>>>>> regards,
>>>>> Sean.
>>>>>
>>>>> On 04/12/2014 12:25, Daniel Fuchs wrote:
>>>>>> On 04/12/14 13:06, David Holmes wrote:
>>>>>>> Hi Daniel,
>>>>>>>
>>>>>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> In fact I could use 'null' on JDK 9 as well.
>>>>>>>> My first version of the JDK 9 test was parsing over all the 
>>>>>>>> .jimage
>>>>>>>> files under <jdk>/lib/modules - which explain why I needed to
>>>>>>>> use the System class loader.
>>>>>>>>
>>>>>>>> Then I switched to only parsing the bootmodules.jimage - because
>>>>>>>> I noticed that the results where more coherent with what I had
>>>>>>>> observed on 8 & 7 - but I kept using the System class loader.
>>>>>>>>
>>>>>>>> I am not sure whether we want the test for 9 should iterate over
>>>>>>>> the three .jimage - or continue to test only the boot .jimage.
>>>>>>>>
>>>>>>>> I have updated the JDK 9 test (refreshed the webrev in place)
>>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/
>>>>>>>> and added support for possibly running the test in the two modes
>>>>>>>> (I added a 'test.boot.only' system property, true by default)
>>>>>>>> as well as additional traces to print the loaded classes by
>>>>>>>> defining loader at the end (test.list.classes, false by default).
>>>>>>>
>>>>>>> A couple of initial comments:
>>>>>>>
>>>>>>>   104     static ClassLoader getClassLoaderFor(String 
>>>>>>> classFileName) {
>>>>>>>   105         if (restrictToBoot) return null; // only bootmodules
>>>>>>>   106         return ClassLoaders.systemClassLoader;
>>>>>>>   107     }
>>>>>>>
>>>>>>> I'm not clear the intent here. If it is to return a loader for 
>>>>>>> which
>>>>>>> loadClass could be invoked then you can always just return the 
>>>>>>> system
>>>>>>> loader - or just Class.forName. If it is meant to the return the
>>>>>>> expected defining loader then it isn't doing that as the extensions
>>>>>>> loader is not allowed for.
>>>>>>
>>>>>> The intent is to return the class loader that will be passed to
>>>>>> Class.forName( ). I've been fiddling & experimenting with this
>>>>>> test over 3 different platforms while trying to minimize the
>>>>>> differences - so that was my attempt at having a good place to
>>>>>> experiment with different strategy for loading classes.
>>>>>>
>>>>>>> Similarly for:
>>>>>>>
>>>>>>>   128         static ClassLoader getFor(String classFileName) {
>>>>>>>   129             return systemClassLoader;
>>>>>>>   130         }
>>>>>>
>>>>>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..)
>>>>>> was supposed to simply return ClassLoaders.getFor(...);
>>>>>> and all the code should be in ClassLoaders.getFor - my bad.
>>>>>>
>>>>>>> Minor nit - In:
>>>>>>>
>>>>>>> 135                     System.err.println("Unexpected loader for
>>>>>>> "+c+":
>>>>>>> "+c.getClassLoader());
>>>>>>>
>>>>>>> c.getClassLoader() can be replaced by cl. Also put spaces around 
>>>>>>> the +
>>>>>>> operator.
>>>>>>
>>>>>> Good catch.
>>>>>>
>>>>>> Thanks a lot David! Have a good night! (that's quite late - isn't 
>>>>>> it?)
>>>>>>
>>>>>> -- daniel
>>>>>>
>>>>>>>
>>>>>>> David
>>>>>>> (signing off for the night)
>>>>>>>
>>>>>>>> Thanks for your question, it triggered me into looking deeper
>>>>>>>> into what was happening :-)
>>>>>>>>
>>>>>>>> best regards,
>>>>>>>>
>>>>>>>> -- daniel
>>>>>>>>
>>>>>>>> On 04/12/14 10:05, Daniel Fuchs wrote:
>>>>>>>>>>> The differences between 8 & 9 are limited to:
>>>>>>>>>>>
>>>>>>>>>>>     - ClassLoader:
>>>>>>>>>>>          - on 8 we use 'null' (BCL)
>>>>>>>>>>>          - on 9 we use the system class loader.
>>>>>>>>>>
>>>>>>>>>> I haven't seen anything in JEP 220, regarding modules, that
>>>>>>>>>> indicates
>>>>>>>>>> that classes currently loaded  by the boot-loader will now be
>>>>>>>>>> loaded
>>>>>>>>>> by the system classloader ???
>>>>>>>>>
>>>>>>>>> In [1] towards the end:
>>>>>>>>>
>>>>>>>>> [1] http://openjdk.java.net/jeps/220
>>>>>>>>>
>>>>>>>>> "The defining class loader of the types in some existing packages
>>>>>>>>>   will change. Existing code that makes assumptions about the 
>>>>>>>>> class
>>>>>>>>>   loaders of these types might not work correctly."
>>>>>>>>>   (then there is a list of specific changes).
>>>>>>>>>
>>>>>>>>> This test looks up all class names in the image files and attempt
>>>>>>>>> to load the corresponding class. But as indicated in [1]
>>>>>>>>> some of these classes are now in the Boot CL, some in the
>>>>>>>>> Extension CL, and some in the Application CL.
>>>>>>>>>
>>>>>>>>> So the test uses the System CL to load each class - which ensures
>>>>>>>>> that the loading will be delegated to the appropriate 
>>>>>>>>> ClassLoader.
>>>>>>>>>
>>>>>>>>> best regards,
>>>>>>>>>
>>>>>>>>> -- daniel
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>
>



From peter.levart at gmail.com  Sat Dec  6 12:30:05 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 06 Dec 2014 13:30:05 +0100
Subject: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support
	eviction
In-Reply-To: <547EF7CF.7070501@oracle.com>
References: <547C9E37.8080809@oracle.com> <547EEFFF.4040409@oracle.com>
	<547EF7CF.7070501@oracle.com>
Message-ID: <5482F6CD.6030600@gmail.com>

(Sorry for a re-send, forgot to include core-libs-dev)...

Hi Vladimir,

First, just a nit. I think that in LambdaFormEditor:

  289     private LambdaForm putInCache(Transform key, LambdaForm form) {
  290         key = key.withResult(form);
  291         for (int pass = 0; ; pass++) {
  292             Object c = lambdaForm.transformCache;
  293             if (c instanceof ConcurrentHashMap) {
  294                 @SuppressWarnings("unchecked")
  295                 ConcurrentHashMap<Transform,Transform> m = (ConcurrentHashMap<Transform,Transform>) c;
  296                 Transform k = m.putIfAbsent(key, key);
  297                 if (k == null) return form;
  298                 LambdaForm result = k.get();
  299                 if (result != null) {
  300                     return result;
  301                 } else {
  302                     if (m.replace(key, k, key)) {
  303                         return form;
  304                     } else {
  305                         continue;
  306                     }
  307                 }
  308             }
  309             assert(pass == 0);
  310             synchronized (lambdaForm) {
  311                 c = lambdaForm.transformCache;
  312                 if (c instanceof ConcurrentHashMap)
  313                     continue;

...

  372                     lambdaForm.transformCache = c = m;
                                                      ^^^ put assignment to 'c' back in
  373                     // The second iteration will update for this query, concurrently.
  374                     continue;


...you could move the assignment to 'c' in line 292 out of for loop and 
put it back in line 372, since once 'c' is instance of CHM, 
lambdaForm.transformCache never changes again and if 'c' is not CHM yet, 
it is re-assigned in lines 311 and 372 before next loop.

Am I right?

Now what scares me (might be that I don't have an intimacy with 
LambdaForm class like you do). There is a situation where you publish 
LambdaForm instances via data race.

One form of LambdaForm.transformCache is an array of Transform objects 
(the other two forms are not problematic). Transform class has all 
fields final except the 'referent' field of SoftReference, which holds a 
LambdaForm instance. In the following line:

377                 ta[idx] = key;


...you publish Transform object to an element of array with relaxed 
write, and in the following lines:

  271         } else {
  272             Transform[] ta = (Transform[])c;
  273             for (int i = 0; i < ta.length; i++) {
  274                 Transform t = ta[i];
  275                 if (t == null)  break;
  276                 if (t.equals(key)) { k = t; break; }
  277             }
  278         }
  279         assert(k == null || key.equals(k));
  280         return (k != null) ? k.get() : null;


...you obtain the element of the array with no synchronization and a 
relaxed read and might return a non-null referent (the LambdaForm) which 
is then returned as an interned instance.

So can LambdaForm instances be published via data races without fear 
that they would appear half-initialized?

That's what I didn't know when I used a lazySet coupled with volatile 
get to access array elements in my version:

http://cr.openjdk.java.net/~plevart/misc/LambdaFormEditor.WeakCache/webrev.01/


Regards, Peter

On 12/03/2014 12:45 PM, Vladimir Ivanov wrote:
> Aleksey, thanks for the review.
>
> I haven't tried -XX:SoftRefLRUPolicyMSPerMB=0, but I did extensive 
> testing on Octane/Nashorn with multiple low -Xmx levels + frequent 
> Full GCs (8060147 [1] was the result of those experiments) and stress 
> tested cache eviction with jdk/java/lang/invoke/LFCache tests in long 
> running mode.
>
> Best regards,
> Vladimir Ivanov
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8060147
>
> On 12/3/14, 3:11 PM, Aleksey Shipilev wrote:
>> On 12/01/2014 07:58 PM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8057020
>>
>> Looks okay, although the cache management logic gives me a headache
>> after the vacation. I thought I spotted a few bugs, but those were only
>> false positives.
>>
>>> The fix is to use SoftReferences to keep LambdaForms alive as long as
>>> possible, but avoid throwing OOME until the caches are evicted. I
>>> experimented with WeakReferences, but it doesn't hold LambdaForms for
>>> long enough: LambdaForm cache hit rate degrades significantly and it
>>> negatively affects application startup and warmup, since every
>>> instantiated LambdaForm is precompiled to bytecode before usage.
>>>
>>> Testing: jdk/java/lang/invoke/LFCache in stress mode + jck
>>> (api/java_lang/invoke), jdk/java/lang/invoke, jdk/java/util/streams, 
>>> octane
>>
>> SoftReferences are tricky in the way they can get suddenly drop the
>> referent, and normal testing would not catch it (e.g. the normal
>> operation would reclaim softrefs under your feet almost never). Does
>> this code survive with -XX:SoftRefLRUPolicyMSPerMB=0?
>>
>> Thanks,
>> -Aleksey.
>>
>>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



From dl at cs.oswego.edu  Sat Dec  6 16:14:49 2014
From: dl at cs.oswego.edu (Doug Lea)
Date: Sat, 06 Dec 2014 11:14:49 -0500
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <5480FAE1.4080909@cs.oswego.edu>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>	<547DEC01.2050501@gmail.com>	<547DF89A.2020809@oracle.com>	<CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>	<547F2BC1.6040904@cs.oswego.edu>	<CA+kOe0_h2EBbY51qh7MSUFpq44FpOspgtBVF6qVWENMwW2O0xA@mail.gmail.com>	<547F4A9D.3060805@cs.oswego.edu>	<CA+kOe08vnvXtDE_Xv+6iqtpBaRR3MpdeRV0OtksqMJ_aJpi9Dg@mail.gmail.com>	<547F8B84.6090301@cs.oswego.edu>	<CA+kOe0_D0yxDEWq4DNQN_DL-yv-+Am3gFx_Foq-G63BDkrSHuQ@mail.gmail.com>	<5480195B.4070800@gmail.com>	<F498D1ED-6C4B-4F5B-8F82-036715009EEC@oracle.com>
	<5480FAE1.4080909@cs.oswego.edu>
Message-ID: <54832B79.7040406@cs.oswego.edu>

On 12/04/2014 07:22 PM, Doug Lea wrote:

> Because Random, SplittableRandom, and ThreadLocalRandom all use the
> same basic approach, they can/should use the same mechanism.

In other words, to establish a common default-constructor-seed
generator internal to the JDK. So we only need one environmental
seed to start it off, and can remove some redundancies.

> Placing the mechanics in TLR seems to work out best.

Well, except that on Windows, we'd still need to create
a .dll just for the sake of calling CryptGenRandom (or
RtlGenRandom?), which seems like a bad move all around.
If we are trying to reduce initialization costs,
it would be better and faster if this were integrated
with other platform-specific JVM startup. (Requiring a
separate .dll also makes it impossible for us to create
standalone j.u.c builds for previews etc.) Which brings
us back to establishing some means of getting from the JVM,
only once, 8 bytes of environmentally-derived bits for a
within-JDK caller. Doing this might be a good opportunity
for exploiting any upcoming modularity support. Or short of
that, placing it in an existing JVM interface class like Unsafe.
Any thoughts?

> (Also, at some point we might reconsider our cowardice about not
> improving the internal java.util.Random algorithm. j.u.Random is
> much more commonly used, and does not fare well on quality tests.
> On the other hand, the more that users instead choose to use
> SR or TLR, the better.)
>

The main problem is code (not just JDK test code) that hardwires
expected Random.next* output under given seeds. Which might be
enough reason to leave it alone.
Do any CCC members have an opinion?

As a lesser but still worthwhile target though, I can't think of
a reason not to change java.lang.Math.random() to use TLR
to get faster and better-quality values. (Because there is no
way to explicitly seed Math.random, there is no hardwiring problem.)
Some existing javadoc for it saying that it creates a new
java.util.Random() should be deleted, although I don't
think it has any user-visible impact.
http://docs.oracle.com/javase/8/docs/api/java/lang/Math.html#random--

-Doug





From kumar.x.srinivasan at oracle.com  Sun Dec  7 16:08:59 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Sun, 07 Dec 2014 08:08:59 -0800
Subject: RFR: JDK-8058407: Remove Multiple JRE support in the Java launcher
In-Reply-To: <5482DD0D.8020003@oracle.com>
References: <5481CDB1.8080208@oracle.com> <5482DD0D.8020003@oracle.com>
Message-ID: <54847B9B.10002@oracle.com>

Alan,

Highlights:
* Fixed the indenting in java.c around JLI_ReportErrorMessage(SPC_ERROR2)

* Fixed parse_manifest.c, removed the redundant check, also added some
    braces to that if/else/elseif block for consistency sake.

* Updated CopyRights as well.

The changes to the last webrev are here:
http://cr.openjdk.java.net/~ksrini/8058407/webrev.01/webrev.delta/index.html

The full webrev is here:
http://cr.openjdk.java.net/~ksrini/8058407/webrev.01/index.html

Thanks
Kumar

> On 05/12/2014 15:22, Kumar Srinivasan wrote:
>> Hello,
>>
>> Please review the fix for JDK-8058407, contributed by Neil Toda, 
>> described by JEP 231 [1]
>> the webrev is at: http://cr.openjdk.java.net/~ksrini/8058407/webrev.00/
>>
>> Please note: The above webrev is identical to the original posted by 
>> Neal at
>> http://cr.openjdk.java.net/~ntoda/8058407/webrev-03/
>>
> This looks good to me although I think in parse_manifest that you can 
> removed completely the line that checks for JRE-Restrict-Search as it 
> does nothing. A minor nit is the alignment of the calls to 
> JLI_ReportErrorMessage(SPC_ERROR2), you might want to check those.
>
> -Alan.



From Alan.Bateman at oracle.com  Sun Dec  7 16:47:43 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 07 Dec 2014 16:47:43 +0000
Subject: RFR: JDK-8058407: Remove Multiple JRE support in the Java launcher
In-Reply-To: <54847B9B.10002@oracle.com>
References: <5481CDB1.8080208@oracle.com> <5482DD0D.8020003@oracle.com>
	<54847B9B.10002@oracle.com>
Message-ID: <548484AF.2030000@oracle.com>

On 07/12/2014 16:08, Kumar Srinivasan wrote:
> Alan,
>
> Highlights:
> * Fixed the indenting in java.c around JLI_ReportErrorMessage(SPC_ERROR2)
>
> * Fixed parse_manifest.c, removed the redundant check, also added some
>    braces to that if/else/elseif block for consistency sake.
>
> * Updated CopyRights as well.
>
> The changes to the last webrev are here:
> http://cr.openjdk.java.net/~ksrini/8058407/webrev.01/webrev.delta/index.html 
>
>
> The full webrev is here:
> http://cr.openjdk.java.net/~ksrini/8058407/webrev.01/index.html
>
The updated webrev looks good to me.

-Alan.


From david.holmes at oracle.com  Sun Dec  7 22:40:41 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 08 Dec 2014 08:40:41 +1000
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <CA+kOe08OC57hEgGR-3CSfsJUMVSk-_mCmZK2Gd=3tpkE9=6j_w@mail.gmail.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>	<5481108A.3030605@oracle.com>
	<CA+kOe08OC57hEgGR-3CSfsJUMVSk-_mCmZK2Gd=3tpkE9=6j_w@mail.gmail.com>
Message-ID: <5484D769.5030609@oracle.com>

On 6/12/2014 7:49 AM, Martin Buchholz wrote:
> On Thu, Dec 4, 2014 at 5:55 PM, David Holmes <david.holmes at oracle.com> wrote:
>
>> In general phrasing like: " also known as a LoadLoad plus LoadStore barrier
>> ..." is misleading to me as these are not "aliases"- the loadFence (in this
>> case) is being specified to have the same semantics as the
>> loadload|storeload. It should say "corresponds to a LoadLoad plus LoadStore
>> barrier"
>
> +     * Ensures that loads before the fence will not be reordered with loads and
> +     * stores after the fence; also known as a LoadLoad plus LoadStore barrier,
>
> I don't understand this.  I believe they _are_ aliases.  The first
> clause perfectly describes a "LoadLoad plus LoadStore barrier".

I find the language use inappropriate - you are defining the first to be 
the second.

>   - as per the "Corresponds to a C11 ...". And referring to things
>> like "load-acquire fence" is meaningless without some reference to a
>> definition - who defines a load-acquire fence? Is there a universal
>> definition? I would be okay with something looser eg:
>
> Well, I'm defining "load-acquire fence" here in the javadoc - I'm
> claiming that loadFence is also known via other terminology, including
> "load-acquire fence".  Although it's true that "load-acquire fence" is
> also used to refer to the corresponding C11 fence, which has subtly
> different semantics.

When you say "also known as XXX" it means that XXX is already defined 
elsewhere. Unless there is a generally accepted definition of XXX then 
this doesn't add much value.

>> /**
>>    * Ensures that loads before the fence will not be reordered with loads and
>>    * stores after the fence. Corresponds to a LoadLoad plus LoadStore
>> barrier,
>>    * and also to the C11 atomic_thread_fence(memory_order_acquire).
>>    * Sometimes referred to as a "load-acquire fence".
>>    *
>>
>> Also I find this comment strange:
>>
>> !      * A pure StoreStore fence is not provided, since the addition of
>> LoadStore
>> !      * is almost always desired, and most current hardware instructions
>> that
>> !      * provide a StoreStore barrier also provide a LoadStore barrier for
>> free.
>>
>> because inside hotspot we use storeStore barriers a lot, without any
>> loadStore at the same point.
>
> I believe the use of e.g. OrderAccess::storestore in the hotspot
> sources is unfortunate.

I don't! Not at all!

> The actual implementations of storestore (see below) seem to
> universally give you the stronger ::release barrier,

Don't conflate hardware barriers and compiler barriers. On TSO systems 
storestore() is a no-op for the hardware but a compiler-barrier is still 
required. The compiler barrier is stronger than storestore but that's 
because we don't have fine-grained compiler barriers. As I've said 
previously there is an open bug to clean up the orderAccess definitions 
because semantically it is very misleading to define things like 
storestore() as release(). However if you look at the implementation of 
things we are not actually adding any additional semantics to the 
storestore(). Eg for x86 (after a recent change top cleanup the 
compiler-barrier:

inline void OrderAccess::release() {
   compiler_barrier();
}

So storestore() is also just a compiler barrier, thought I'd prefer to 
see it expressed as:

inline void OrderAccess::storestore() { compiler_barrier(); }

than the misleading (and very wrong on non-TSO):

inline void OrderAccess::storestore() { release(); }

And of course the non-TSO platforms use the barrier necessary on that 
platform.

> and it seems
> likely that hotspot engineers are implicitly relying on that, that
> some uses of ::storestore in the hotspot sources are bugs (should be
> ::release instead)

That seems a rather baseless speculation on your part. Having been 
involved in a lot of discussions involving memory barrier usage in 
various algorithms in different areas of hotspot I can assure you that 
the use of storestore() has been quite deliberate and does not assume an 
implicit loadstore().

Also as I've said many many times now release() as a stand-alone 
operation is meaningless.

David
-----

and that there is very little potential performance
> benefit from using ::storestore instead of ::release, precisely
> because the additional loadstore barrier is very close to free on all
> current hardware.  Writing correct code using ::storestore is harder
> than ::release, which is already difficult enough. C11 doesn't provide
> a corresponding fence, which is a strong hint.
>
>
> ./bsd_zero/vm/orderAccess_bsd_zero.inline.hpp:71:inline void
> OrderAccess::storestore() { release(); }
> ./linux_sparc/vm/orderAccess_linux_sparc.inline.hpp:35:inline void
> OrderAccess::storestore() { release(); }
> ./aix_ppc/vm/orderAccess_aix_ppc.inline.hpp:73:inline void
> OrderAccess::storestore() { inlasm_lwsync();  }
> ./linux_zero/vm/orderAccess_linux_zero.inline.hpp:70:inline void
> OrderAccess::storestore() { release(); }
> ./solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp:40:inline void
> OrderAccess::storestore() { release(); }
> ./linux_ppc/vm/orderAccess_linux_ppc.inline.hpp:75:inline void
> OrderAccess::storestore() { inlasm_lwsync();  }
> ./solaris_x86/vm/orderAccess_solaris_x86.inline.hpp:40:inline void
> OrderAccess::storestore() { release(); }
> ./linux_x86/vm/orderAccess_linux_x86.inline.hpp:35:inline void
> OrderAccess::storestore() { release(); }
> ./bsd_x86/vm/orderAccess_bsd_x86.inline.hpp:35:inline void
> OrderAccess::storestore() { release(); }
> ./windows_x86/vm/orderAccess_windows_x86.inline.hpp:35:inline void
> OrderAccess::storestore() { release(); }
>


From david.holmes at oracle.com  Sun Dec  7 22:58:06 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 08 Dec 2014 08:58:06 +1000
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <CA+kOe0_LU1-RUJ0pNdkR9k1rbCb16mRd-x1ebAd8dwpoQneE2g@mail.gmail.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>	<54810C0C.2080901@oracle.com>
	<CA+kOe0_LU1-RUJ0pNdkR9k1rbCb16mRd-x1ebAd8dwpoQneE2g@mail.gmail.com>
Message-ID: <5484DB7E.6080505@oracle.com>

On 6/12/2014 7:29 AM, Martin Buchholz wrote:
> On Thu, Dec 4, 2014 at 5:36 PM, David Holmes <david.holmes at oracle.com> wrote:
>> Martin,
>>
>> On 2/12/2014 6:46 AM, Martin Buchholz wrote:
>
>> Is this finalized then? You can only make one commit per CR.
>
> Right.  I'd like to commit and then perhaps do another round of clarifications.
>
>> I still find this entire comment block to be misguided and misplaced:
>>
>> !     // Fences, also known as memory barriers, or membars.
>> !     // See hotspot sources for more details:
>> !     // orderAccess.hpp memnode.hpp unsafe.cpp
>> !     //
>> !     // One way of implementing Java language-level volatile variables
>> using
>> !     // fences (but there is often a better way without) is by:
>> !     // translating a volatile store into the sequence:
>> !     // - storeFence()
>> !     // - relaxed store
>> !     // - fullFence()
>> !     // and translating a volatile load into the sequence:
>> !     // - if (CPU_NOT_MULTIPLE_COPY_ATOMIC) fullFence()
>> !     // - relaxed load
>> !     // - loadFence()
>> !     // The full fence on volatile stores ensures the memory model
>> guarantee of
>> !     // sequential consistency on most platforms.  On some platforms (ppc)
>> we
>> !     // need an additional full fence between volatile loads as well (see
>> !     // hotspot's CPU_NOT_MULTIPLE_COPY_ATOMIC).
>
> Even I think this comment is marginal - I will delete it.  But
> consider this a plea for better documentation of the hotspot
> internals.

Okay, but Unsafe.java is not the place to document anything about hotspot.

>> why do want this description here - it has no relevance to the API itself,
>> nor to how volatiles are implemented in the VM. And as I said in the bug
>> report CPU_NOT_MULTIPLE_COPY_ATOMIC exists only for platforms that want to
>> implement IRIW (none of our platforms are multiple-copy-atomic, but only PPC
>> sets this so that it employs IRIW).
>
> I believe the comment _does_ reflect hotspot's current implementation
> (entirely from exploring the sources).
> I believe it's correct to say "all of the platforms are
> multiple-copy-atomic except PPC".

Here is the definition of multi-copy atomicity from the ARM architecture 
manual:

"In a multiprocessing system, writes to a memory location are multi-copy 
atomic if the following conditions are both true:
? All writes to the same location are serialized, meaning they are 
observed in the same order by all observers, although some observers 
might not observe all of the writes.
? A read of a location does not return the value of a write until all 
observers observe that write."

The first condition is met by Total-Store-Order (TSO) systems like x86 
and sparc; and not by relaxed-memory-order (RMO) systems like ARM and 
PPC. However the second condition is not met simply by having TSO. If 
the local processor can see a write from the local store buffer prior to 
it being visible to other processors, then we do not have multi-copy 
atomicity and I believe that is true for x86 and sparc. Hence none of 
our supported platforms are multi-copy-atomic as far as I can see.

> I believe hotspot must implement IRIW correctly to fulfil the promise
> of sequential consistency for standard Java, so on ppc volatile reads
> get a full fence, which leads us back to the ppc pointer chasing
> performance problem that started all of this.

Note that nothing in the JSR-133 cookbook allows for IRIW, even on x86 
and sparc. The key feature needed for IRIW is a load barrier that forces 
global memory synchronization to ensure that all processors see writes 
at the same time. I'm not even sure we can force that on x86 and sparc! 
Such a load barrier negates the need for some store barriers as defined 
in the cookbook.

My understanding, which could be wrong, is that the JMM implies 
linearizability of volatile accesses, which in turn provides the IRIW 
property. It is also my understanding that linearizability is a 
necessary property for current proof systems to be applicable. However 
absence of proof is not proof of absence, and it doesn't follow that 
code that doesn't rely on IRIW is incorrect if IRIW is not ensured on a 
system. As has been stated many times now, in the literature no 
practical lock-free algorithm seems to rely on IRIW. So I still hope 
that IRIW can somehow be removed because implementing it will impact 
everything related to the JMM in hotspot.

David
-----


From kumar.x.srinivasan at oracle.com  Mon Dec  8 00:56:20 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Sun, 07 Dec 2014 16:56:20 -0800
Subject: XXS RFR: JDK-8066745: tools/pack200/Pack200Props.java failed
	with java.lang.OutOfMemoryError: Java heap space
In-Reply-To: <5482DC1B.3020606@oracle.com>
References: <5481D3F4.6090208@oracle.com> <5481E74E.9050104@oracle.com>
	<5481EFBC.2020209@oracle.com> <54825D81.4060501@oracle.com>
	<5482DC1B.3020606@oracle.com>
Message-ID: <5484F734.8090108@oracle.com>

Alan,

I have adjust both the tests Pack200Props as well as Pack200Test which uses
rt.jar to have increased heaps and -Xshare:off.

http://cr.openjdk.java.net/~ksrini/8066745/webrev.00/

Thanks
Kumar

On 12/6/2014 2:36 AM, Alan Bateman wrote:
> On 06/12/2014 01:36, Kumar Srinivasan wrote:
>> Alan,
>>
>> The heap needs to be increased (1.2GB)  for this test, I think the 
>> default provided
>> by the launcher ergonomics is not sufficient on certain platforms. I've
>> tested the patch with JPRT.
>>
>> Thanks
>> Kumar
>>
>>
>> diff --git a/test/tools/pack200/Pack200Props.java 
>> b/test/tools/pack200/Pack200Props.java
>> --- a/test/tools/pack200/Pack200Props.java
>> +++ b/test/tools/pack200/Pack200Props.java
>> @@ -62,6 +62,7 @@
>>
>>          List<String> cmdsList = new ArrayList<>();
>>          cmdsList.add(Utils.getPack200Cmd());
>> +        cmdsList.add("-J-Xmx1280m");
>>          cmdsList.add("--effort=1");
>>          cmdsList.add("--verbose");
>>          cmdsList.add("--no-gzip");
> This looks okay to me although 1.2GB makes me wonder if you might 
> still need -Xshare:off on Windows 32-bit.
>
> -Alan



From joe.darcy at oracle.com  Mon Dec  8 06:24:07 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Sun, 07 Dec 2014 22:24:07 -0800
Subject: JDK 9 RFR of JDK-8066643: (zipfs) Suppress deprecation warnings in
	jdk.zipfs module
Message-ID: <54854407.6050509@oracle.com>

Hello,

Please review the simple patch below to fix

      JDK-8066643: (zipfs) Suppress deprecation warnings in jdk.zipfs 
module

Thanks,

-Joe

diff -r 913808eaf19a src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java
--- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java    Mon Nov 
10 08:43:27 2014 -0800
+++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java    Sun Dec 
07 22:22:51 2014 -0800
@@ -103,6 +103,7 @@
      /*
       * Converts DOS time to Java time (number of milliseconds since 
epoch).
       */
+    @SuppressWarnings("deprecation")
      public static long dosToJavaTime(long dtime) {
          Date d = new Date((int)(((dtime >> 25) & 0x7f) + 80),
                            (int)(((dtime >> 21) & 0x0f) - 1),
@@ -116,6 +117,7 @@
      /*
       * Converts Java time to DOS time.
       */
+    @SuppressWarnings("deprecation")
      public static long javaToDosTime(long time) {
          Date d = new Date(time);
          int year = d.getYear() + 1900;



From david.holmes at oracle.com  Mon Dec  8 06:56:40 2014
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 08 Dec 2014 16:56:40 +1000
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <5482105D.40005@oracle.com>
References: <547F9302.3060309@oracle.com>
	<547FD6F2.5060400@oracle.com>	<548023D0.4020702@oracle.com>
	<548047C3.8000400@oracle.com>	<54804E4B.2070908@oracle.com>
	<5480529F.1020902@oracle.com> <54805B5D.5020504@oracle.com>
	<54809627.8070103@oracle.com> <5480EFE8.3090809@oracle.com>
	<5482105D.40005@oracle.com>
Message-ID: <54854BA8.60700@oracle.com>

Hi Daniel,

On 6/12/2014 6:06 AM, Daniel Fuchs wrote:
> Hi David, all,
>
> @David: You're right David.
>          The loader parameter is never used - I have removed it.

But you still have extraneous loader related stuff that doesn't actually 
achieve anything. getClassLoaderFor(s) is not needed. Class.forName can 
be called simply as Class.forName(s). And why the indirection around the 
ClassLoaders methods ??

David

> @all: I have received a comment from Alan that it would be better to use
>        the new jrt:/ FileSystem directly, rather than using private APIs.
>        One of the consequence is that the test now loads all the
>        classes in the runtime image (not just the ones in the BCL),
>        and therefore I have removed the toggle that allowed to test
>        the boot classes only.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/
>
> best regards,
>
> -- daniel
>
> On 05/12/14 00:36, David Holmes wrote:
>> Hi Daniel,
>>
>> I still find your use of the classloader very confusing. You talk about
>> the defining loader but you never check the defining loader against
>> anything. In
>>
>>   146         static void checkFor(Class<?> c, ClassLoader loader) {
>>
>> the loader variable is never used. And if loader is simply the name of
>> the loader passed to forName, then it may not be the defining loader
>> anyway - so the whole use of this loader variable seems superfluous at
>> best, and confusing/misleading at worst. And you can use the simple
>> forName(name) variant rather than passing a loader.
>>
>> David
>>
>> On 5/12/2014 3:13 AM, Daniel Fuchs wrote:
>>> On 04/12/14 14:02, Se?n Coffey wrote:
>>>> Thanks for driving efforts in this area Daniel. I think it's a very
>>>> useful test and is bound to help test code coverage. If it's currently
>>>> passing on all JPRT platforms, it's a good measure.
>>>
>>> It seems to :-)
>>>
>>>> Eventually I think we can bulk up the tests that can be run on the
>>>> Iterable returned from your class search.
>>>> At moment you just test Field.setAccessible.
>>>
>>> Yes. If we change it later to test more, we will probably need to
>>> change its name. I was already in lack of inspiration:
>>> FieldSetAccessibleTest is not really a great name - but hopefully
>>> it can do for now.
>>>
>>>> In the future, I don't see any harm in adding all simple Field method
>>>> calls so that any corner cases in custom classes like the original
>>>> issue
>>>> are caught. e.g Field.getDeclaredAnnotations(), Field.getModifiers(),
>>>> Field.isEnumConstant() etc., etc. Some methods won't be much value add
>>>> but they're not a cost either.
>>>
>>> Agreed.
>>>
>>>> Same argument for running through all Class methods, e.g
>>>> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a result
>>>> this
>>>> test might eventually become more general in test goal and might live
>>>> better one level up in "test/java/lang/Class/" - it can be moved when
>>>> the time comes.
>>>
>>> Agreed as well :-)
>>>
>>> Here is a new revision of the webrev for 9 in which I have
>>> incorporated David's comment:
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>>
>>>> regards,
>>>> Sean.
>>>>
>>>> On 04/12/2014 12:25, Daniel Fuchs wrote:
>>>>> On 04/12/14 13:06, David Holmes wrote:
>>>>>> Hi Daniel,
>>>>>>
>>>>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> In fact I could use 'null' on JDK 9 as well.
>>>>>>> My first version of the JDK 9 test was parsing over all the .jimage
>>>>>>> files under <jdk>/lib/modules - which explain why I needed to
>>>>>>> use the System class loader.
>>>>>>>
>>>>>>> Then I switched to only parsing the bootmodules.jimage - because
>>>>>>> I noticed that the results where more coherent with what I had
>>>>>>> observed on 8 & 7 - but I kept using the System class loader.
>>>>>>>
>>>>>>> I am not sure whether we want the test for 9 should iterate over
>>>>>>> the three .jimage - or continue to test only the boot .jimage.
>>>>>>>
>>>>>>> I have updated the JDK 9 test (refreshed the webrev in place)
>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/
>>>>>>> and added support for possibly running the test in the two modes
>>>>>>> (I added a 'test.boot.only' system property, true by default)
>>>>>>> as well as additional traces to print the loaded classes by
>>>>>>> defining loader at the end (test.list.classes, false by default).
>>>>>>
>>>>>> A couple of initial comments:
>>>>>>
>>>>>>   104     static ClassLoader getClassLoaderFor(String
>>>>>> classFileName) {
>>>>>>   105         if (restrictToBoot) return null; // only bootmodules
>>>>>>   106         return ClassLoaders.systemClassLoader;
>>>>>>   107     }
>>>>>>
>>>>>> I'm not clear the intent here. If it is to return a loader for which
>>>>>> loadClass could be invoked then you can always just return the system
>>>>>> loader - or just Class.forName. If it is meant to the return the
>>>>>> expected defining loader then it isn't doing that as the extensions
>>>>>> loader is not allowed for.
>>>>>
>>>>> The intent is to return the class loader that will be passed to
>>>>> Class.forName( ). I've been fiddling & experimenting with this
>>>>> test over 3 different platforms while trying to minimize the
>>>>> differences - so that was my attempt at having a good place to
>>>>> experiment with different strategy for loading classes.
>>>>>
>>>>>> Similarly for:
>>>>>>
>>>>>>   128         static ClassLoader getFor(String classFileName) {
>>>>>>   129             return systemClassLoader;
>>>>>>   130         }
>>>>>
>>>>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..)
>>>>> was supposed to simply return ClassLoaders.getFor(...);
>>>>> and all the code should be in ClassLoaders.getFor - my bad.
>>>>>
>>>>>> Minor nit - In:
>>>>>>
>>>>>> 135                     System.err.println("Unexpected loader for
>>>>>> "+c+":
>>>>>> "+c.getClassLoader());
>>>>>>
>>>>>> c.getClassLoader() can be replaced by cl. Also put spaces around
>>>>>> the +
>>>>>> operator.
>>>>>
>>>>> Good catch.
>>>>>
>>>>> Thanks a lot David! Have a good night! (that's quite late - isn't it?)
>>>>>
>>>>> -- daniel
>>>>>
>>>>>>
>>>>>> David
>>>>>> (signing off for the night)
>>>>>>
>>>>>>> Thanks for your question, it triggered me into looking deeper
>>>>>>> into what was happening :-)
>>>>>>>
>>>>>>> best regards,
>>>>>>>
>>>>>>> -- daniel
>>>>>>>
>>>>>>> On 04/12/14 10:05, Daniel Fuchs wrote:
>>>>>>>>>> The differences between 8 & 9 are limited to:
>>>>>>>>>>
>>>>>>>>>>     - ClassLoader:
>>>>>>>>>>          - on 8 we use 'null' (BCL)
>>>>>>>>>>          - on 9 we use the system class loader.
>>>>>>>>>
>>>>>>>>> I haven't seen anything in JEP 220, regarding modules, that
>>>>>>>>> indicates
>>>>>>>>> that classes currently loaded  by the boot-loader will now be
>>>>>>>>> loaded
>>>>>>>>> by the system classloader ???
>>>>>>>>
>>>>>>>> In [1] towards the end:
>>>>>>>>
>>>>>>>> [1] http://openjdk.java.net/jeps/220
>>>>>>>>
>>>>>>>> "The defining class loader of the types in some existing packages
>>>>>>>>   will change. Existing code that makes assumptions about the class
>>>>>>>>   loaders of these types might not work correctly."
>>>>>>>>   (then there is a list of specific changes).
>>>>>>>>
>>>>>>>> This test looks up all class names in the image files and attempt
>>>>>>>> to load the corresponding class. But as indicated in [1]
>>>>>>>> some of these classes are now in the Boot CL, some in the
>>>>>>>> Extension CL, and some in the Application CL.
>>>>>>>>
>>>>>>>> So the test uses the System CL to load each class - which ensures
>>>>>>>> that the loading will be delegated to the appropriate ClassLoader.
>>>>>>>>
>>>>>>>> best regards,
>>>>>>>>
>>>>>>>> -- daniel
>>>>>>>
>>>>>
>>>>
>>>
>


From Alan.Bateman at oracle.com  Mon Dec  8 08:24:24 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 08 Dec 2014 08:24:24 +0000
Subject: JDK 9 RFR of JDK-8066643: (zipfs) Suppress deprecation warnings
	in jdk.zipfs module
In-Reply-To: <54854407.6050509@oracle.com>
References: <54854407.6050509@oracle.com>
Message-ID: <54856038.2020505@oracle.com>

On 08/12/2014 06:24, joe darcy wrote:
> Hello,
>
> Please review the simple patch below to fix
>
>      JDK-8066643: (zipfs) Suppress deprecation warnings in jdk.zipfs 
> module
This looks for now although it would be nicer to re-implement these two 
methods to do this conversion without using Date.

-Alan


From Alan.Bateman at oracle.com  Mon Dec  8 08:25:25 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 08 Dec 2014 08:25:25 +0000
Subject: XXS RFR: JDK-8066745: tools/pack200/Pack200Props.java failed
	with java.lang.OutOfMemoryError: Java heap space
In-Reply-To: <5484F734.8090108@oracle.com>
References: <5481D3F4.6090208@oracle.com> <5481E74E.9050104@oracle.com>
	<5481EFBC.2020209@oracle.com> <54825D81.4060501@oracle.com>
	<5482DC1B.3020606@oracle.com> <5484F734.8090108@oracle.com>
Message-ID: <54856075.5090009@oracle.com>

On 08/12/2014 00:56, Kumar Srinivasan wrote:
> Alan,
>
> I have adjust both the tests Pack200Props as well as Pack200Test which 
> uses
> rt.jar to have increased heaps and -Xshare:off.
>
> http://cr.openjdk.java.net/~ksrini/8066745/webrev.00/
This looks good to me.

-Alan


From martinrb at google.com  Mon Dec  8 08:42:11 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 8 Dec 2014 00:42:11 -0800
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <5484DB7E.6080505@oracle.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>
	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>
	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>
	<54810C0C.2080901@oracle.com>
	<CA+kOe0_LU1-RUJ0pNdkR9k1rbCb16mRd-x1ebAd8dwpoQneE2g@mail.gmail.com>
	<5484DB7E.6080505@oracle.com>
Message-ID: <CA+kOe0-kaVGdNyaLN2Yo0H4KnM1AU3N=nFryazZP1VbqK9t=Kw@mail.gmail.com>

On Sun, Dec 7, 2014 at 2:58 PM, David Holmes <david.holmes at oracle.com> wrote:

>> I believe the comment _does_ reflect hotspot's current implementation
>> (entirely from exploring the sources).
>> I believe it's correct to say "all of the platforms are
>> multiple-copy-atomic except PPC".

... current hotspot sources don't contain ARM support.

> Here is the definition of multi-copy atomicity from the ARM architecture
> manual:
>
> "In a multiprocessing system, writes to a memory location are multi-copy
> atomic if the following conditions are both true:
> ? All writes to the same location are serialized, meaning they are observed
> in the same order by all observers, although some observers might not
> observe all of the writes.
> ? A read of a location does not return the value of a write until all
> observers observe that write."

The hotspot sources give

"""
// To assure the IRIW property on processors that are not multiple copy
// atomic, sync instructions must be issued between volatile reads to
// assure their ordering, instead of after volatile stores.
// (See "A Tutorial Introduction to the ARM and POWER Relaxed Memory Models"
// by Luc Maranget, Susmit Sarkar and Peter Sewell, INRIA/Cambridge)
#ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
"""

and the referenced paper gives

"""
on POWER and ARM, two threads can observe writes to different
locations in different orders, even in
the absence of any thread-local reordering. In other words, the
architectures are not multiple-copy atomic [Col92].
"""

which strongly suggests that x86 and sparc are OK.

> The first condition is met by Total-Store-Order (TSO) systems like x86 and
> sparc; and not by relaxed-memory-order (RMO) systems like ARM and PPC.
> However the second condition is not met simply by having TSO. If the local
> processor can see a write from the local store buffer prior to it being
> visible to other processors, then we do not have multi-copy atomicity and I
> believe that is true for x86 and sparc. Hence none of our supported
> platforms are multi-copy-atomic as far as I can see.
>
>> I believe hotspot must implement IRIW correctly to fulfil the promise
>> of sequential consistency for standard Java, so on ppc volatile reads
>> get a full fence, which leads us back to the ppc pointer chasing
>> performance problem that started all of this.
>
>
> Note that nothing in the JSR-133 cookbook allows for IRIW, even on x86 and
> sparc. The key feature needed for IRIW is a load barrier that forces global
> memory synchronization to ensure that all processors see writes at the same
> time. I'm not even sure we can force that on x86 and sparc! Such a load
> barrier negates the need for some store barriers as defined in the cookbook.
>
> My understanding, which could be wrong, is that the JMM implies
> linearizability of volatile accesses, which in turn provides the IRIW
> property. It is also my understanding that linearizability is a necessary
> property for current proof systems to be applicable. However absence of
> proof is not proof of absence, and it doesn't follow that code that doesn't
> rely on IRIW is incorrect if IRIW is not ensured on a system. As has been
> stated many times now, in the literature no practical lock-free algorithm
> seems to rely on IRIW. So I still hope that IRIW can somehow be removed
> because implementing it will impact everything related to the JMM in
> hotspot.


From davidcholmes at aapt.net.au  Mon Dec  8 08:46:50 2014
From: davidcholmes at aapt.net.au (David Holmes)
Date: Mon, 8 Dec 2014 18:46:50 +1000
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <CA+kOe0-kaVGdNyaLN2Yo0H4KnM1AU3N=nFryazZP1VbqK9t=Kw@mail.gmail.com>
Message-ID: <NFBBKALFDCPFIDBNKAPCAEJJKLAA.davidcholmes@aapt.net.au>

Martin,

The paper you cite is about ARM and Power architectures - why do you think the lack of mention of x86/sparc implies those architectures are multiple-copy-atomic?

David

> -----Original Message-----
> From: Martin Buchholz [mailto:martinrb at google.com]
> Sent: Monday, 8 December 2014 6:42 PM
> To: David Holmes
> Cc: David Holmes; Vladimir Kozlov; core-libs-dev; concurrency-interest
> Subject: Re: [concurrency-interest] RFR: 8065804: JEP 171:
> Clarifications/corrections for fence intrinsics
> 
> 
> On Sun, Dec 7, 2014 at 2:58 PM, David Holmes 
> <david.holmes at oracle.com> wrote:
> 
> >> I believe the comment _does_ reflect hotspot's current implementation
> >> (entirely from exploring the sources).
> >> I believe it's correct to say "all of the platforms are
> >> multiple-copy-atomic except PPC".
> 
> ... current hotspot sources don't contain ARM support.
> 
> > Here is the definition of multi-copy atomicity from the ARM architecture
> > manual:
> >
> > "In a multiprocessing system, writes to a memory location are multi-copy
> > atomic if the following conditions are both true:
> > ? All writes to the same location are serialized, meaning they 
> are observed
> > in the same order by all observers, although some observers might not
> > observe all of the writes.
> > ? A read of a location does not return the value of a write until all
> > observers observe that write."
> 
> The hotspot sources give
> 
> """
> // To assure the IRIW property on processors that are not multiple copy
> // atomic, sync instructions must be issued between volatile reads to
> // assure their ordering, instead of after volatile stores.
> // (See "A Tutorial Introduction to the ARM and POWER Relaxed 
> Memory Models"
> // by Luc Maranget, Susmit Sarkar and Peter Sewell, INRIA/Cambridge)
> #ifdef CPU_NOT_MULTIPLE_COPY_ATOMIC
> const bool support_IRIW_for_not_multiple_copy_atomic_cpu = true;
> """
> 
> and the referenced paper gives
> 
> """
> on POWER and ARM, two threads can observe writes to different
> locations in different orders, even in
> the absence of any thread-local reordering. In other words, the
> architectures are not multiple-copy atomic [Col92].
> """
> 
> which strongly suggests that x86 and sparc are OK.
> 
> > The first condition is met by Total-Store-Order (TSO) systems 
> like x86 and
> > sparc; and not by relaxed-memory-order (RMO) systems like ARM and PPC.
> > However the second condition is not met simply by having TSO. 
> If the local
> > processor can see a write from the local store buffer prior to it being
> > visible to other processors, then we do not have multi-copy 
> atomicity and I
> > believe that is true for x86 and sparc. Hence none of our supported
> > platforms are multi-copy-atomic as far as I can see.
> >
> >> I believe hotspot must implement IRIW correctly to fulfil the promise
> >> of sequential consistency for standard Java, so on ppc volatile reads
> >> get a full fence, which leads us back to the ppc pointer chasing
> >> performance problem that started all of this.
> >
> >
> > Note that nothing in the JSR-133 cookbook allows for IRIW, even 
> on x86 and
> > sparc. The key feature needed for IRIW is a load barrier that 
> forces global
> > memory synchronization to ensure that all processors see writes 
> at the same
> > time. I'm not even sure we can force that on x86 and sparc! Such a load
> > barrier negates the need for some store barriers as defined in 
> the cookbook.
> >
> > My understanding, which could be wrong, is that the JMM implies
> > linearizability of volatile accesses, which in turn provides the IRIW
> > property. It is also my understanding that linearizability is a 
> necessary
> > property for current proof systems to be applicable. However absence of
> > proof is not proof of absence, and it doesn't follow that code 
> that doesn't
> > rely on IRIW is incorrect if IRIW is not ensured on a system. 
> As has been
> > stated many times now, in the literature no practical lock-free 
> algorithm
> > seems to rely on IRIW. So I still hope that IRIW can somehow be removed
> > because implementing it will impact everything related to the JMM in
> > hotspot.
> 



From peter.levart at gmail.com  Mon Dec  8 10:25:21 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 08 Dec 2014 11:25:21 +0100
Subject: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support
	eviction
In-Reply-To: <5482F6CD.6030600@gmail.com>
References: <547C9E37.8080809@oracle.com> <547EEFFF.4040409@oracle.com>
	<547EF7CF.7070501@oracle.com> <5482F6CD.6030600@gmail.com>
Message-ID: <54857C91.9030709@gmail.com>

Just one more thought...

In lines:

  358                     } else if (stale < 0 && k.get() == null) {
  359                         stale = i; // remember 1st stale entry index
  360                     }


...an index to 1st stale entry is remembered while scanning the array so 
that at the end, instead of always allocating new slot, an existing slot 
can be re-used. This has an inadvertent effect on the lifetime of 
SoftReference(s) that are "touched" in the process (LRU policy of 
cleaning). Here we see that an additional method like 
SoftReference.isPresent() that didn't "touch" the access time, would be 
helpful.

Regards, Peter

On 12/06/2014 01:30 PM, Peter Levart wrote:
> (Sorry for a re-send, forgot to include core-libs-dev)...
>
> Hi Vladimir,
>
> First, just a nit. I think that in LambdaFormEditor:
>
>  289     private LambdaForm putInCache(Transform key, LambdaForm form) {
>  290         key = key.withResult(form);
>  291         for (int pass = 0; ; pass++) {
>  292             Object c = lambdaForm.transformCache;
>  293             if (c instanceof ConcurrentHashMap) {
>  294                 @SuppressWarnings("unchecked")
>  295                 ConcurrentHashMap<Transform,Transform> m = 
> (ConcurrentHashMap<Transform,Transform>) c;
>  296                 Transform k = m.putIfAbsent(key, key);
>  297                 if (k == null) return form;
>  298                 LambdaForm result = k.get();
>  299                 if (result != null) {
>  300                     return result;
>  301                 } else {
>  302                     if (m.replace(key, k, key)) {
>  303                         return form;
>  304                     } else {
>  305                         continue;
>  306                     }
>  307                 }
>  308             }
>  309             assert(pass == 0);
>  310             synchronized (lambdaForm) {
>  311                 c = lambdaForm.transformCache;
>  312                 if (c instanceof ConcurrentHashMap)
>  313                     continue;
>
> ...
>
>  372                     lambdaForm.transformCache = c = m;
>                                                      ^^^ put 
> assignment to 'c' back in
>  373                     // The second iteration will update for this 
> query, concurrently.
>  374                     continue;
>
>
> ...you could move the assignment to 'c' in line 292 out of for loop 
> and put it back in line 372, since once 'c' is instance of CHM, 
> lambdaForm.transformCache never changes again and if 'c' is not CHM 
> yet, it is re-assigned in lines 311 and 372 before next loop.
>
> Am I right?
>
> Now what scares me (might be that I don't have an intimacy with 
> LambdaForm class like you do). There is a situation where you publish 
> LambdaForm instances via data race.
>
> One form of LambdaForm.transformCache is an array of Transform objects 
> (the other two forms are not problematic). Transform class has all 
> fields final except the 'referent' field of SoftReference, which holds 
> a LambdaForm instance. In the following line:
>
> 377                 ta[idx] = key;
>
>
> ...you publish Transform object to an element of array with relaxed 
> write, and in the following lines:
>
>  271         } else {
>  272             Transform[] ta = (Transform[])c;
>  273             for (int i = 0; i < ta.length; i++) {
>  274                 Transform t = ta[i];
>  275                 if (t == null)  break;
>  276                 if (t.equals(key)) { k = t; break; }
>  277             }
>  278         }
>  279         assert(k == null || key.equals(k));
>  280         return (k != null) ? k.get() : null;
>
>
> ...you obtain the element of the array with no synchronization and a 
> relaxed read and might return a non-null referent (the LambdaForm) 
> which is then returned as an interned instance.
>
> So can LambdaForm instances be published via data races without fear 
> that they would appear half-initialized?
>
> That's what I didn't know when I used a lazySet coupled with volatile 
> get to access array elements in my version:
>
> http://cr.openjdk.java.net/~plevart/misc/LambdaFormEditor.WeakCache/webrev.01/ 
>
>
>
> Regards, Peter
>
> On 12/03/2014 12:45 PM, Vladimir Ivanov wrote:
>> Aleksey, thanks for the review.
>>
>> I haven't tried -XX:SoftRefLRUPolicyMSPerMB=0, but I did extensive 
>> testing on Octane/Nashorn with multiple low -Xmx levels + frequent 
>> Full GCs (8060147 [1] was the result of those experiments) and stress 
>> tested cache eviction with jdk/java/lang/invoke/LFCache tests in long 
>> running mode.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8060147
>>
>> On 12/3/14, 3:11 PM, Aleksey Shipilev wrote:
>>> On 12/01/2014 07:58 PM, Vladimir Ivanov wrote:
>>>> http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
>>>> https://bugs.openjdk.java.net/browse/JDK-8057020
>>>
>>> Looks okay, although the cache management logic gives me a headache
>>> after the vacation. I thought I spotted a few bugs, but those were only
>>> false positives.
>>>
>>>> The fix is to use SoftReferences to keep LambdaForms alive as long as
>>>> possible, but avoid throwing OOME until the caches are evicted. I
>>>> experimented with WeakReferences, but it doesn't hold LambdaForms for
>>>> long enough: LambdaForm cache hit rate degrades significantly and it
>>>> negatively affects application startup and warmup, since every
>>>> instantiated LambdaForm is precompiled to bytecode before usage.
>>>>
>>>> Testing: jdk/java/lang/invoke/LFCache in stress mode + jck
>>>> (api/java_lang/invoke), jdk/java/lang/invoke, 
>>>> jdk/java/util/streams, octane
>>>
>>> SoftReferences are tricky in the way they can get suddenly drop the
>>> referent, and normal testing would not catch it (e.g. the normal
>>> operation would reclaim softrefs under your feet almost never). Does
>>> this code survive with -XX:SoftRefLRUPolicyMSPerMB=0?
>>>
>>> Thanks,
>>> -Aleksey.
>>>
>>>
>> _______________________________________________
>> mlvm-dev mailing list
>> mlvm-dev at openjdk.java.net
>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>



From lance.andersen at oracle.com  Mon Dec  8 11:24:05 2014
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Mon, 8 Dec 2014 06:24:05 -0500
Subject: JDK 9 RFR of JDK-8066643: (zipfs) Suppress deprecation warnings
	in jdk.zipfs module
In-Reply-To: <54854407.6050509@oracle.com>
References: <54854407.6050509@oracle.com>
Message-ID: <9E7D0BE0-86F6-4514-9E70-554EF1DA76BD@oracle.com>

+1


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com
Sent from my iPad

> On Dec 8, 2014, at 1:24 AM, joe darcy <joe.darcy at oracle.com> wrote:
> 
> Hello,
> 
> Please review the simple patch below to fix
> 
>     JDK-8066643: (zipfs) Suppress deprecation warnings in jdk.zipfs module
> 
> Thanks,
> 
> -Joe
> 
> diff -r 913808eaf19a src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java
> --- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java    Mon Nov 10 08:43:27 2014 -0800
> +++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java    Sun Dec 07 22:22:51 2014 -0800
> @@ -103,6 +103,7 @@
>     /*
>      * Converts DOS time to Java time (number of milliseconds since epoch).
>      */
> +    @SuppressWarnings("deprecation")
>     public static long dosToJavaTime(long dtime) {
>         Date d = new Date((int)(((dtime >> 25) & 0x7f) + 80),
>                           (int)(((dtime >> 21) & 0x0f) - 1),
> @@ -116,6 +117,7 @@
>     /*
>      * Converts Java time to DOS time.
>      */
> +    @SuppressWarnings("deprecation")
>     public static long javaToDosTime(long time) {
>         Date d = new Date(time);
>         int year = d.getYear() + 1900;
> 


From chris.hegarty at oracle.com  Mon Dec  8 11:48:20 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 08 Dec 2014 11:48:20 +0000
Subject: Library enhancement proposal for copying data from/to
	Reader/Writer InputStream/OutputStream
In-Reply-To: <AE34D5A9-FEAC-417C-8A10-F4EC96B4B0A8@oracle.com>
References: <566A428C-1A13-4DEE-940B-2EBE375F2A7A@reini.net>	<A3953E4D-018A-44C8-8106-DC9E4663D67C@reini.net>	<C62A3014-1F54-41E4-B560-198F87305B9E@reini.net>	<54772C7D.7080209@oracle.com>	<769E83F8-FD6D-4F8B-B415-DD044C5D08BA@reini.net>	<D1E803CB-29AF-46AA-9990-77B2A05EFBD4@oracle.com>	<547757EE.4090205@oracle.com>	<ED697D7C-F60A-4CD7-B84E-88C10D45B9FB@reini.net>	<D2DD43D0-5D86-446A-A67A-8D3AEB2541CD@oracle.com>	<15B58029-95FA-4D9E-AA28-7A6C72D6CB3D@reini.net>	<13156FAC-6EDC-462B-9BE7-2DFAFB9124FD@oracle.com>	<20141128201546.000067ce.ecki@zusammenkunft.net>	<<216A14EF-B62C-4971!	-!>
	<8194-E...>	<8E1109C5-4C9E-4B7A-924E-9E92B3F93F89@reini.net>	<150A2C4B-E239-433C-B0C9-39F70E98D837@oracle.com>	<5480B9CE.20!	90600@reini.net>	<DAAE3744-D74C-4528-9498-B7389DC784EF@oracle.com>	<5481D174.2030406@oracle.com>
	<5481D67E.9080504@oracle.com!	! > <548...
	<72DDE6F7-6B03-47D5-A125-BCA3D5CD624E@reini.net>
	<AE34D5A9-FEAC-417C-8A10-F4EC96B4B0A8@oracle.com>
Message-ID: <54859004.80408@oracle.com>

For completeness, here is the finalized spec that we intend to submit 
for approval. Just some minor rewording and grammaticality amendments 
over the previous.

    /**
      * Reads all bytes from this input stream and writes the bytes to 
the given
      * output stream in the order that they are read.  On return, this 
input
      * stream will be at end of stream.
      * <p>
      * This method may block indefinitely reading from the input stream,
      * or writing to the output stream. The behavior for the case that the
      * input and/or output stream is <i>asynchronously closed</i>, or the
      * thread interrupted during the transfer, is highly input and 
output stream
      * specific, and therefore not specified.
      * <p>
      * If an I/O error occurs reading from the input stream or writing to
      * the output stream, then it may do so after some bytes have been 
read or
      * written. Consequently the input stream may not be at end of 
stream and
      * one, or both, streams may be in an inconsistent state. It is 
strongly
      * recommended that both streams be promptly closed if an I/O error 
occurs.
      *
      * @param  out the output stream, non-null
      * @return the number of bytes transferred
      * @throws IOException if an I/O error occurs when reading or writing
      * @throws NullPointerException  if {@code out} is {@code null}
      *
      * @since 1.9
      */
     public long transferTo(OutputStream out) throws IOException { ... }

-Chris.


On 05/12/14 18:29, Chris Hegarty wrote:
>
> On 5 Dec 2014, at 17:28, Patrick Reinhart <patrick at reini.net> wrote:
>
>> Hi Chris,
>>
>>> Am 05.12.2014 um 17:36 schrieb Chris Hegarty <chris.hegarty at oracle.com>:
>>>
>>> On 05/12/14 15:59, Alan Bateman wrote:
>>>> On 05/12/2014 15:38, Chris Hegarty wrote:
>>>>> The addition of a copyTo method to java.io.InputStream is binary
>>>>> compatible [1], but it may, in some cases, be source incompatible. I
>>>>> believe the benefits of this approach out weigh the potential source
>>>>> incompatibility, but it will be for the spec gods, the CCC, to have
>>>>> final say.
>>>>>
>>>>> Here is what I propose. Let's take just InputStream.copyTo and bring
>>>>> it, by itself, to a conclusion. And then revisit each of the
>>>>> additional useful/convenience methods on their own merit.
>>>> I think the approach is good. An alternative name to consider is
>>>> transferTo. For the javadoc then you can make it clear that the
>>>> InputStream is at EOF when the method completes. I don't think the
>>>> javadoc needs to say that the OutputStream should be closed promptly
>>>> (think "cat a b c > d").
>>>
>>> Right. Updated spec:
>>>
>>>     /**
>>>      * Reads all remaining bytes from this input stream and writes them to
>>>      * the given output stream.  On return, this input stream will be at end of
>>>      * stream.
>>>      * <p>
>>>      * This method may block indefinitely reading from the input stream,
>>>      * or writing to the output stream. The behavior for the case that the
>>>      * input and/or output stream is <i>asynchronously closed</i>, or the
>>>      * thread interrupted during the copy, is highly input and output stream
>>>      * specific, and therefore not specified.
>>>      * <p>
>>>      * If an I/O error occurs reading from the input stream or writing to
>>>      * the output stream, then it may do so after some bytes have been read or
>>>      * written. Consequently the input stream may not be at end of stream and
>>>      * may be in an inconsistent state. It is strongly recommended that the
>>>      * input stream be promptly closed if an I/O error occurs.
>>>      *
>>>      * @param  out         the output stream to write to, non-null
>>>      * @return             the number of bytes copied
>>>      * @throws IOException if an I/O error occurs when reading or writing
>>>      * @throws NullPointerException  if {@code out} is {@code null}
>>>      *
>>>      * @since 1.9
>>>      */
>>>     public long transferTo(OutputStream out) throws IOException { ... }
>>>
>>> -Chris.
>>
>> Looks good to me. The only thing I would change is the @return documentation to ?the number of bytes transferred? to be in sync with the method name.
>
> Agreed. Consider it changed.
>
> -Chris.
>
>> -Patrick
>>
>


From Alan.Bateman at oracle.com  Mon Dec  8 11:52:30 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 08 Dec 2014 11:52:30 +0000
Subject: Library enhancement proposal for copying data from/to
	Reader/Writer InputStream/OutputStream
In-Reply-To: <54859004.80408@oracle.com>
References: <566A428C-1A13-4DEE-940B-2EBE375F2A7A@reini.net>	<A3953E4D-018A-44C8-8106-DC9E4663D67C@reini.net>	<C62A3014-1F54-41E4-B560-198F87305B9E@reini.net>	<54772C7D.7080209@oracle.com>	<769E83F8-FD6D-4F8B-B415-DD044C5D08BA@reini.net>	<D1E803CB-29AF-46AA-9990-77B2A05EFBD4@oracle.com>	<547757EE.4090205@oracle.com>	<ED697D7C-F60A-4CD7-B84E-88C10D45B9FB@reini.net>	<D2DD43D0-5D86-446A-A67A-8D3AEB2541CD@oracle.com>	<15B58029-95FA-4D9E-AA28-7A6C72D6CB3D@reini.net>	<13156FAC-6EDC-462B-9BE7-2DFAFB9124FD@oracle.com>	<20141128201546.000067ce.ecki@zusammenkunft.net>	<<216A14EF-B62C-4971!	-!>	<8194-E...>	<8E1109C5-4C9E-4B7A-924E-9E92B3F93F89@reini.net>	<150A2C4B-E239-433C-B0C9-39F70E98D837@oracle.com>	<5480B9CE.20!	90600@reini.net>	<DAAE3744-D74C-4528-9498-B7389DC784EF@oracle.com>	<5481D174.2030406@oracle.com>	<5481D67E.9080504@oracle.com!	!
	>
	<548...	<72DDE6F7-6B03-47D5-A125-BCA3D5CD624E@reini.net>	<AE34D5A9-FEAC-417C-8A10-F4EC96B4B0A8@oracle.com>
	<54859004.80408@oracle.com>
Message-ID: <548590FE.3050803@oracle.com>

On 08/12/2014 11:48, Chris Hegarty wrote:
> For completeness, here is the finalized spec that we intend to submit 
> for approval. Just some minor rewording and grammaticality amendments 
> over the previous.
>
>    /**
>      * Reads all bytes from this input stream and writes the bytes to 
> the given
>      * output stream in the order that they are read.  On return, this 
> input
>      * stream will be at end of stream.
>      * <p>
>      * This method may block indefinitely reading from the input stream,
>      * or writing to the output stream. The behavior for the case that 
> the
>      * input and/or output stream is <i>asynchronously closed</i>, or the
>      * thread interrupted during the transfer, is highly input and 
> output stream
>      * specific, and therefore not specified.
>      * <p>
>      * If an I/O error occurs reading from the input stream or writing to
>      * the output stream, then it may do so after some bytes have been 
> read or
>      * written. Consequently the input stream may not be at end of 
> stream and
>      * one, or both, streams may be in an inconsistent state. It is 
> strongly
>      * recommended that both streams be promptly closed if an I/O 
> error occurs.
>      *
>      * @param  out the output stream, non-null
>      * @return the number of bytes transferred
>      * @throws IOException if an I/O error occurs when reading or writing
>      * @throws NullPointerException  if {@code out} is {@code null}
>      *
>      * @since 1.9
>      */
>     public long transferTo(OutputStream out) throws IOException { ... }
I'm happy with this updated wording, it's consistent with the wording 
that we already have in Files.copy, and it addresses all the points that 
have come up.

-Alan


From chris.hegarty at oracle.com  Mon Dec  8 14:17:54 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 08 Dec 2014 14:17:54 +0000
Subject: Library enhancement proposal for copying data from/to
	Reader/Writer InputStream/OutputStream
In-Reply-To: <54859004.80408@oracle.com>
References: <566A428C-1A13-4DEE-940B-2EBE375F2A7A@reini.net>	<A3953E4D-018A-44C8-8106-DC9E4663D67C@reini.net>	<C62A3014-1F54-41E4-B560-198F87305B9E@reini.net>	<54772C7D.7080209@oracle.com>	<769E83F8-FD6D-4F8B-B415-DD044C5D08BA@reini.net>	<D1E803CB-29AF-46AA-9990-77B2A05EFBD4@oracle.com>	<547757EE.4090205@oracle.com>	<ED697D7C-F60A-4CD7-B84E-88C10D45B9FB@reini.net>	<D2DD43D0-5D86-446A-A67A-8D3AEB2541CD@oracle.com>	<15B58029-95FA-4D9E-AA28-7A6C72D6CB3D@reini.net>	<13156FAC-6EDC-462B-9BE7-2DFAFB9124FD@oracle.com>	<20141128201546.000067ce.ecki@zusammenkunft.net>	<<216A14EF-B62C-4971!	-!>	<8194-E...>	<8E1109C5-4C9E-4B7A-924E-9E92B3F93F89@reini.net>	<150A2C4B-E239-433C-B0C9-39F70E98D837@oracle.com>	<5480B9CE.20!	90600@reini.net>	<DAAE3744-D74C-4528-9498-B7389DC784EF@oracle.com>	<5481D174.2030406@oracle.com>	<5481D67E.9080504@oracle.com!	!
	>
	<548...	<72DDE6F7-6B03-47D5-A125-BCA3D5CD624E@reini.net>	<AE34D5A9-FEAC-417C-8A10-F4EC96B4B0A8@oracle.com>
	<54859004.80408@oracle.com>
Message-ID: <5485B312.7070709@oracle.com>

Again, just for completeness...

Some feedback from Paul Sandoz, to be explicit about the "openness" of 
the streams on return. "Does not close either stream."

  /**
      * Reads all bytes from this input stream and writes the bytes to 
the given
      * output stream in the order that they are read.  On return, this 
input
      * stream will be at end of stream. Does not close either stream.
      * <p>
      * This method may block indefinitely reading from the input stream, or
      * writing to the output stream. The behavior for the case that the 
input
      * and/or output stream is <i>asynchronously closed</i>, or the thread
      * interrupted during the transfer, is highly input and output stream
      * specific, and therefore not specified.
      * <p>
      * If an I/O error occurs reading from the input stream or writing to
      * the output stream, then it may do so after some bytes have been 
read or
      * written. Consequently the input stream may not be at end of 
stream and
      * one, or both, streams may be in an inconsistent state. It is 
strongly
      * recommended that both streams be promptly closed if an I/O error 
occurs.
      *
      * @param  out the output stream, non-null
      * @return the number of bytes transferred
      * @throws IOException if an I/O error occurs when reading or writing
      * @throws NullPointerException  if {@code out} is {@code null}
      *
      * @since 1.9
      */
     public long transferTo(OutputStream out) throws IOException

-Chris.

On 08/12/14 11:48, Chris Hegarty wrote:
> For completeness, here is the finalized spec that we intend to submit
> for approval. Just some minor rewording and grammaticality amendments
> over the previous.
>
>     /**
>       * Reads all bytes from this input stream and writes the bytes to
> the given
>       * output stream in the order that they are read.  On return, this
> input
>       * stream will be at end of stream.
>       * <p>
>       * This method may block indefinitely reading from the input stream,
>       * or writing to the output stream. The behavior for the case that the
>       * input and/or output stream is <i>asynchronously closed</i>, or the
>       * thread interrupted during the transfer, is highly input and
> output stream
>       * specific, and therefore not specified.
>       * <p>
>       * If an I/O error occurs reading from the input stream or writing to
>       * the output stream, then it may do so after some bytes have been
> read or
>       * written. Consequently the input stream may not be at end of
> stream and
>       * one, or both, streams may be in an inconsistent state. It is
> strongly
>       * recommended that both streams be promptly closed if an I/O error
> occurs.
>       *
>       * @param  out the output stream, non-null
>       * @return the number of bytes transferred
>       * @throws IOException if an I/O error occurs when reading or writing
>       * @throws NullPointerException  if {@code out} is {@code null}
>       *
>       * @since 1.9
>       */
>      public long transferTo(OutputStream out) throws IOException { ... }
>
> -Chris.
>
>
> On 05/12/14 18:29, Chris Hegarty wrote:
>>
>> On 5 Dec 2014, at 17:28, Patrick Reinhart <patrick at reini.net> wrote:
>>
>>> Hi Chris,
>>>
>>>> Am 05.12.2014 um 17:36 schrieb Chris Hegarty
>>>> <chris.hegarty at oracle.com>:
>>>>
>>>> On 05/12/14 15:59, Alan Bateman wrote:
>>>>> On 05/12/2014 15:38, Chris Hegarty wrote:
>>>>>> The addition of a copyTo method to java.io.InputStream is binary
>>>>>> compatible [1], but it may, in some cases, be source incompatible. I
>>>>>> believe the benefits of this approach out weigh the potential source
>>>>>> incompatibility, but it will be for the spec gods, the CCC, to have
>>>>>> final say.
>>>>>>
>>>>>> Here is what I propose. Let's take just InputStream.copyTo and bring
>>>>>> it, by itself, to a conclusion. And then revisit each of the
>>>>>> additional useful/convenience methods on their own merit.
>>>>> I think the approach is good. An alternative name to consider is
>>>>> transferTo. For the javadoc then you can make it clear that the
>>>>> InputStream is at EOF when the method completes. I don't think the
>>>>> javadoc needs to say that the OutputStream should be closed promptly
>>>>> (think "cat a b c > d").
>>>>
>>>> Right. Updated spec:
>>>>
>>>>     /**
>>>>      * Reads all remaining bytes from this input stream and writes
>>>> them to
>>>>      * the given output stream.  On return, this input stream will
>>>> be at end of
>>>>      * stream.
>>>>      * <p>
>>>>      * This method may block indefinitely reading from the input
>>>> stream,
>>>>      * or writing to the output stream. The behavior for the case
>>>> that the
>>>>      * input and/or output stream is <i>asynchronously closed</i>,
>>>> or the
>>>>      * thread interrupted during the copy, is highly input and
>>>> output stream
>>>>      * specific, and therefore not specified.
>>>>      * <p>
>>>>      * If an I/O error occurs reading from the input stream or
>>>> writing to
>>>>      * the output stream, then it may do so after some bytes have
>>>> been read or
>>>>      * written. Consequently the input stream may not be at end of
>>>> stream and
>>>>      * may be in an inconsistent state. It is strongly recommended
>>>> that the
>>>>      * input stream be promptly closed if an I/O error occurs.
>>>>      *
>>>>      * @param  out         the output stream to write to, non-null
>>>>      * @return             the number of bytes copied
>>>>      * @throws IOException if an I/O error occurs when reading or
>>>> writing
>>>>      * @throws NullPointerException  if {@code out} is {@code null}
>>>>      *
>>>>      * @since 1.9
>>>>      */
>>>>     public long transferTo(OutputStream out) throws IOException { ... }
>>>>
>>>> -Chris.
>>>
>>> Looks good to me. The only thing I would change is the @return
>>> documentation to ?the number of bytes transferred? to be in sync with
>>> the method name.
>>
>> Agreed. Consider it changed.
>>
>> -Chris.
>>
>>> -Patrick
>>>
>>


From paul.sandoz at oracle.com  Mon Dec  8 16:19:29 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Mon, 8 Dec 2014 17:19:29 +0100
Subject: [9,
	8u40] RFR (M): 8057020: LambdaForm caches should support eviction
In-Reply-To: <5482F6CD.6030600@gmail.com>
References: <547C9E37.8080809@oracle.com> <547EEFFF.4040409@oracle.com>
	<547EF7CF.7070501@oracle.com> <5482F6CD.6030600@gmail.com>
Message-ID: <21955A74-7A69-4D79-B3AC-5C8835E94173@oracle.com>

On Dec 6, 2014, at 1:30 PM, Peter Levart <peter.levart at gmail.com> wrote:
> Now what scares me (might be that I don't have an intimacy with LambdaForm class like you do). There is a situation where you publish LambdaForm instances via data race.
> 
> One form of LambdaForm.transformCache is an array of Transform objects (the other two forms are not problematic). Transform class has all fields final except the 'referent' field of SoftReference, which holds a LambdaForm instance. In the following line:
> 
> 377                 ta[idx] = key;
> 
> 
> ...you publish Transform object to an element of array with relaxed write, and in the following lines:
> 
> 271         } else {
> 272             Transform[] ta = (Transform[])c;
> 273             for (int i = 0; i < ta.length; i++) {
> 274                 Transform t = ta[i];
> 275                 if (t == null)  break;
> 276                 if (t.equals(key)) { k = t; break; }
> 277             }
> 278         }
> 279         assert(k == null || key.equals(k));
> 280         return (k != null) ? k.get() : null;
> 
> 
> ...you obtain the element of the array with no synchronization and a relaxed read and might return a non-null referent (the LambdaForm) which is then returned as an interned instance.
> 

Transform still has final fields, thus when constructing a Transform using "key.withResult(form))" i don't think hotspot will reorder the store of the referent, or dependent stores, so that they occur after publication of the key element into the Transform[] array.

So i think things are also are ok between putInCache and getInCache.

> So can LambdaForm instances be published via data races without fear that they would appear half-initialized?
> 

AFAICT yes. LambdaForm has final/stable fields and i presume it does not leak in the constructor (even when compiling on construction). See also MethodHandle.updateForm for rare cases where the lambda form of a MethodHandle is updated.

Paul.
 

> That's what I didn't know when I used a lazySet coupled with volatile get to access array elements in my version:
> 
> http://cr.openjdk.java.net/~plevart/misc/LambdaFormEditor.WeakCache/webrev.01/
> 
> 
> Regards, Peter



From xueming.shen at oracle.com  Mon Dec  8 16:50:49 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 08 Dec 2014 08:50:49 -0800
Subject: JDK 9 RFR of JDK-8066643: (zipfs) Suppress deprecation warnings
	in jdk.zipfs module
In-Reply-To: <54854407.6050509@oracle.com>
References: <54854407.6050509@oracle.com>
Message-ID: <5485D6E9.2060206@oracle.com>

looks fine.

On 12/7/14 10:24 PM, joe darcy wrote:
> Hello,
>
> Please review the simple patch below to fix
>
>      JDK-8066643: (zipfs) Suppress deprecation warnings in jdk.zipfs 
> module
>
> Thanks,
>
> -Joe
>
> diff -r 913808eaf19a 
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java
> --- a/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java Mon Nov 
> 10 08:43:27 2014 -0800
> +++ b/src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipUtils.java Sun Dec 
> 07 22:22:51 2014 -0800
> @@ -103,6 +103,7 @@
>      /*
>       * Converts DOS time to Java time (number of milliseconds since 
> epoch).
>       */
> +    @SuppressWarnings("deprecation")
>      public static long dosToJavaTime(long dtime) {
>          Date d = new Date((int)(((dtime >> 25) & 0x7f) + 80),
>                            (int)(((dtime >> 21) & 0x0f) - 1),
> @@ -116,6 +117,7 @@
>      /*
>       * Converts Java time to DOS time.
>       */
> +    @SuppressWarnings("deprecation")
>      public static long javaToDosTime(long time) {
>          Date d = new Date(time);
>          int year = d.getYear() + 1900;
>



From kumar.x.srinivasan at oracle.com  Mon Dec  8 17:06:22 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 08 Dec 2014 09:06:22 -0800
Subject: 8066841: Need to exclude javacpl in tools/launcher/VersionCheck.java
Message-ID: <5485DA8E.5000004@oracle.com>

Hi Alan,

adding javacpl to BLACKLIST_VERSION array.

Thanks
Kumar

diff --git a/test/tools/launcher/VersionCheck.java 
b/test/tools/launcher/VersionCheck.java
--- a/test/tools/launcher/VersionCheck.java
+++ b/test/tools/launcher/VersionCheck.java
@@ -69,6 +69,7 @@
          "java-rmi",
          "java-rmi.cgi",
          "javadoc",
+        "javacpl",
          "javaws",
          "jcmd",
          "jconsole",



From Alan.Bateman at oracle.com  Mon Dec  8 17:11:00 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 08 Dec 2014 17:11:00 +0000
Subject: 8066841: Need to exclude javacpl in
	tools/launcher/VersionCheck.java
In-Reply-To: <5485DA8E.5000004@oracle.com>
References: <5485DA8E.5000004@oracle.com>
Message-ID: <5485DBA4.6040208@oracle.com>

On 08/12/2014 17:06, Kumar Srinivasan wrote:
> Hi Alan,
>
> adding javacpl to BLACKLIST_VERSION array.
>
Looks good and sorry we missed in the JEP 220 changes, it wasn't obvious 
that there was an issue because the test passes.

-Alan


From kumar.x.srinivasan at oracle.com  Mon Dec  8 17:24:15 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 08 Dec 2014 09:24:15 -0800
Subject: 8066841: Need to exclude javacpl in
	tools/launcher/VersionCheck.java
In-Reply-To: <5485DBA4.6040208@oracle.com>
References: <5485DA8E.5000004@oracle.com> <5485DBA4.6040208@oracle.com>
Message-ID: <5485DEBF.4030703@oracle.com>


On 12/8/2014 9:11 AM, Alan Bateman wrote:
> On 08/12/2014 17:06, Kumar Srinivasan wrote:
>> Hi Alan,
>>
>> adding javacpl to BLACKLIST_VERSION array.
>>
> Looks good and sorry we missed in the JEP 220 changes, it wasn't 
> obvious that there was an issue because the test passes.
No apologies needd, in fact I should've caught it, but It didn't occur 
to me as well. ;-)

Kumar

>
> -Alan



From joe.darcy at oracle.com  Mon Dec  8 17:41:23 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Mon, 08 Dec 2014 09:41:23 -0800
Subject: JDK 9 RFR of JDK-8066643: (zipfs) Suppress deprecation warnings
	in jdk.zipfs module
In-Reply-To: <54856038.2020505@oracle.com>
References: <54854407.6050509@oracle.com> <54856038.2020505@oracle.com>
Message-ID: <5485E2C3.9010400@oracle.com>


On 12/8/2014 12:24 AM, Alan Bateman wrote:
> On 08/12/2014 06:24, joe darcy wrote:
>> Hello,
>>
>> Please review the simple patch below to fix
>>
>>      JDK-8066643: (zipfs) Suppress deprecation warnings in jdk.zipfs 
>> module
> This looks for now although it would be nicer to re-implement these 
> two methods to do this conversion without using Date.
>

I fully support the fixing of

         JDK-8066644: Fix deprecation warnings in jdk.zipfs module

Thanks for the review,

-Joe



From stuart.marks at oracle.com  Mon Dec  8 18:54:58 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 08 Dec 2014 10:54:58 -0800
Subject: RFR(s): 8066835: TEST_BUG:
	javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
	fails
Message-ID: <5485F402.6060806@oracle.com>

I broke RMIConnector_NPETest again. This time it was passing a timeout value 
that caused some time calculations to overflow, causing the RMI test library to 
time out prematurely.

Please review this fix, which is to limit timeout values to something reasonable 
and to change the test to use the default timeout instead of specifying 
Long.MAX_VALUE.

Webrev:

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

Bug:

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

Thanks,

s'marks


From lance.andersen at oracle.com  Mon Dec  8 19:00:49 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 8 Dec 2014 14:00:49 -0500
Subject: RFR(s): 8066835: TEST_BUG:
	javax/management/remote/mandatory/connection/RMIConnector_NPETest.java
	fails
In-Reply-To: <5485F402.6060806@oracle.com>
References: <5485F402.6060806@oracle.com>
Message-ID: <695981C5-0392-4494-ADC7-232BD2284015@oracle.com>

+1
On Dec 8, 2014, at 1:54 PM, Stuart Marks <stuart.marks at oracle.com> wrote:

> I broke RMIConnector_NPETest again. This time it was passing a timeout value that caused some time calculations to overflow, causing the RMI test library to time out prematurely.
> 
> Please review this fix, which is to limit timeout values to something reasonable and to change the test to use the default timeout instead of specifying Long.MAX_VALUE.
> 
> Webrev:
> 
> 	http://cr.openjdk.java.net/~smarks/reviews/8066835/webrev.0/
> 
> Bug:
> 
> 	https://bugs.openjdk.java.net/browse/JDK-8066835
> 
> Thanks,
> 
> s'marks



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





From martinrb at google.com  Mon Dec  8 19:17:47 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 8 Dec 2014 11:17:47 -0800
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <NFBBKALFDCPFIDBNKAPCAEJJKLAA.davidcholmes@aapt.net.au>
References: <CA+kOe0-kaVGdNyaLN2Yo0H4KnM1AU3N=nFryazZP1VbqK9t=Kw@mail.gmail.com>
	<NFBBKALFDCPFIDBNKAPCAEJJKLAA.davidcholmes@aapt.net.au>
Message-ID: <CA+kOe09b_3-08pOt171PYedGoT0Bp5X1HOA7B+PHzCSRMkx6wQ@mail.gmail.com>

On Mon, Dec 8, 2014 at 12:46 AM, David Holmes <davidcholmes at aapt.net.au> wrote:
> Martin,
>
> The paper you cite is about ARM and Power architectures - why do you think the lack of mention of x86/sparc implies those architectures are multiple-copy-atomic?

Reading some more in the same paper, I see:

"""Returning to the two properties above, in TSO a thread can see its
own writes before they become visible to other
threads (by reading them from its write buffer), but any write becomes
visible to all other threads simultaneously: TSO
is a multiple-copy atomic model, in the terminology of Collier
[Col92]. One can also see the possibility of reading
from the local write buffer as allowing a specific kind of local
reordering. A program that writes one location x then
reads another location y might execute by adding the write to x to the
thread?s buffer, then reading y from memory,
before finally making the write to x visible to other threads by
flushing it from the buffer. In this case the thread reads
the value of y that was in the memory before the new write of x hits memory."""

So (as you say) with TSO you don't have a total order of stores if you
read your own writes out of your own CPU's write buffer.  However, my
interpretation of "multiple-copy atomic" is that the initial
publishing thread can choose to use an instruction with sufficiently
strong memory barrier attached (e.g. LOCK;XXX on x86) to write to
memory so that the write buffer is flushed and then use plain relaxed
loads everywhere else to read those memory locations and this explains
the situation on x86 and sparc where volatile writes are expensive and
volatile reads are "free" and you get sequential consistency for Java
volatiles.

http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf


From martinrb at google.com  Mon Dec  8 19:25:46 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 8 Dec 2014 11:25:46 -0800
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <5484D769.5030609@oracle.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>
	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>
	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>
	<5481108A.3030605@oracle.com>
	<CA+kOe08OC57hEgGR-3CSfsJUMVSk-_mCmZK2Gd=3tpkE9=6j_w@mail.gmail.com>
	<5484D769.5030609@oracle.com>
Message-ID: <CA+kOe0-UvzsMBC1FVv9C69tUwvbYgt5W4F5YvbzeDBtstQzFXg@mail.gmail.com>

Webrev updated to remove the comparison with volatile loads and stores.

On Sun, Dec 7, 2014 at 2:40 PM, David Holmes <david.holmes at oracle.com> wrote:
> On 6/12/2014 7:49 AM, Martin Buchholz wrote:
>>
>> On Thu, Dec 4, 2014 at 5:55 PM, David Holmes <david.holmes at oracle.com>
>> wrote:
>>
>>> In general phrasing like: " also known as a LoadLoad plus LoadStore
>>> barrier
>>> ..." is misleading to me as these are not "aliases"- the loadFence (in
>>> this
>>> case) is being specified to have the same semantics as the
>>> loadload|storeload. It should say "corresponds to a LoadLoad plus
>>> LoadStore
>>> barrier"
>>
>>
>> +     * Ensures that loads before the fence will not be reordered with
>> loads and
>> +     * stores after the fence; also known as a LoadLoad plus LoadStore
>> barrier,
>>
>> I don't understand this.  I believe they _are_ aliases.  The first
>> clause perfectly describes a "LoadLoad plus LoadStore barrier".
>
>
> I find the language use inappropriate - you are defining the first to be the
> second.

Am I missing something?  Is there something else that "LoadLoad plus
LoadStore barrier" (as used in hotspot sources and elsewhere) could
possibly mean?

>>   - as per the "Corresponds to a C11 ...". And referring to things
>>>
>>> like "load-acquire fence" is meaningless without some reference to a
>>> definition - who defines a load-acquire fence? Is there a universal
>>> definition? I would be okay with something looser eg:
>>
>>
>> Well, I'm defining "load-acquire fence" here in the javadoc - I'm
>> claiming that loadFence is also known via other terminology, including
>> "load-acquire fence".  Although it's true that "load-acquire fence" is
>> also used to refer to the corresponding C11 fence, which has subtly
>> different semantics.
>
>
> When you say "also known as XXX" it means that XXX is already defined
> elsewhere. Unless there is a generally accepted definition of XXX then this
> doesn't add much value.

Everything about this topic is confusing, but I continue to think that
"load-acquire fence" is a common industry term.  One of the reasons I
want to include them in the javadoc is precisely because these
different terms are generally used synonymously.


From vladimir.x.ivanov at oracle.com  Mon Dec  8 19:32:14 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 08 Dec 2014 22:32:14 +0300
Subject: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support
	eviction
In-Reply-To: <5481F68A.2030201@gmail.com>
References: <547C9E37.8080809@oracle.com> <5481F68A.2030201@gmail.com>
Message-ID: <5485FCBE.1060303@oracle.com>

Peter,

Thanks for looking into that and for you initial prototype!

> So WeakReferences did not hold LambdaForms long enough even with strong
> back-reference from LambdaForm to the lambda form 'this' was derived
> from? So final derived LambdaForms (leaves) are not kept referenced from
> the code? Or did back-references keep intermediate LambdaForms in cache
> for too long (forever?) and you wanted them to be evicted too?
Regarding back references, my main concern was footprint. In some corner 
cases, LambdaFormEditor chain can become very long and I wanted to allow 
unloading of unused LambdaForms.

Also, there's another major source of method handles - MethodTypeForm - 
where most of the LambdaFormEditor chains root. It should be cleared as 
well to avoid memory exhaustion.

Regarding WeakReferences, my experiments showed that cache hit rate 
degrades significantly when they are used (30x more instantiated 
LambdaForms- from 1-3k to 30k-60k on Octane/Nashorn).

So, SoftReferences look like a good fit.

Best regards,
Vladimir Ivanov


From vladimir.x.ivanov at oracle.com  Mon Dec  8 20:09:08 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 08 Dec 2014 23:09:08 +0300
Subject: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support
	eviction
In-Reply-To: <54857C91.9030709@gmail.com>
References: <547C9E37.8080809@oracle.com> <547EEFFF.4040409@oracle.com>
	<547EF7CF.7070501@oracle.com> <5482F6CD.6030600@gmail.com>
	<54857C91.9030709@gmail.com>
Message-ID: <54860564.2090501@oracle.com>

Peter,

> Just one more thought...
>
> In lines:
>
>   358                     } else if (stale < 0 && k.get() == null) {
>   359                         stale = i; // remember 1st stale entry index
>   360                     }
>
>
> ...an index to 1st stale entry is remembered while scanning the array so
> that at the end, instead of always allocating new slot, an existing slot
> can be re-used. This has an inadvertent effect on the lifetime of
> SoftReference(s) that are "touched" in the process (LRU policy of
> cleaning). Here we see that an additional method like
> SoftReference.isPresent() that didn't "touch" the access time, would be
> helpful.
Good point!

However, I don't think that cache eviction policy matters for 
LabmdaForms. On average, there are very limited number of LambdaForm (up 
to 8k on Octane/Nashorn in single VM mode). So, in normal situation 
there should be no need to clear the caches. It's there mostly for 
correctness - avoid OOME in some corner cases (e.g. random enumeration 
of method handles).

Best regards,
Vladimir Ivanov

>
> Regards, Peter
>
> On 12/06/2014 01:30 PM, Peter Levart wrote:
>> (Sorry for a re-send, forgot to include core-libs-dev)...
>>
>> Hi Vladimir,
>>
>> First, just a nit. I think that in LambdaFormEditor:
>>
>>  289     private LambdaForm putInCache(Transform key, LambdaForm form) {
>>  290         key = key.withResult(form);
>>  291         for (int pass = 0; ; pass++) {
>>  292             Object c = lambdaForm.transformCache;
>>  293             if (c instanceof ConcurrentHashMap) {
>>  294                 @SuppressWarnings("unchecked")
>>  295                 ConcurrentHashMap<Transform,Transform> m =
>> (ConcurrentHashMap<Transform,Transform>) c;
>>  296                 Transform k = m.putIfAbsent(key, key);
>>  297                 if (k == null) return form;
>>  298                 LambdaForm result = k.get();
>>  299                 if (result != null) {
>>  300                     return result;
>>  301                 } else {
>>  302                     if (m.replace(key, k, key)) {
>>  303                         return form;
>>  304                     } else {
>>  305                         continue;
>>  306                     }
>>  307                 }
>>  308             }
>>  309             assert(pass == 0);
>>  310             synchronized (lambdaForm) {
>>  311                 c = lambdaForm.transformCache;
>>  312                 if (c instanceof ConcurrentHashMap)
>>  313                     continue;
>>
>> ...
>>
>>  372                     lambdaForm.transformCache = c = m;
>>                                                      ^^^ put
>> assignment to 'c' back in
>>  373                     // The second iteration will update for this
>> query, concurrently.
>>  374                     continue;
>>
>>
>> ...you could move the assignment to 'c' in line 292 out of for loop
>> and put it back in line 372, since once 'c' is instance of CHM,
>> lambdaForm.transformCache never changes again and if 'c' is not CHM
>> yet, it is re-assigned in lines 311 and 372 before next loop.
>>
>> Am I right?
>>
>> Now what scares me (might be that I don't have an intimacy with
>> LambdaForm class like you do). There is a situation where you publish
>> LambdaForm instances via data race.
>>
>> One form of LambdaForm.transformCache is an array of Transform objects
>> (the other two forms are not problematic). Transform class has all
>> fields final except the 'referent' field of SoftReference, which holds
>> a LambdaForm instance. In the following line:
>>
>> 377                 ta[idx] = key;
>>
>>
>> ...you publish Transform object to an element of array with relaxed
>> write, and in the following lines:
>>
>>  271         } else {
>>  272             Transform[] ta = (Transform[])c;
>>  273             for (int i = 0; i < ta.length; i++) {
>>  274                 Transform t = ta[i];
>>  275                 if (t == null)  break;
>>  276                 if (t.equals(key)) { k = t; break; }
>>  277             }
>>  278         }
>>  279         assert(k == null || key.equals(k));
>>  280         return (k != null) ? k.get() : null;
>>
>>
>> ...you obtain the element of the array with no synchronization and a
>> relaxed read and might return a non-null referent (the LambdaForm)
>> which is then returned as an interned instance.
>>
>> So can LambdaForm instances be published via data races without fear
>> that they would appear half-initialized?
>>
>> That's what I didn't know when I used a lazySet coupled with volatile
>> get to access array elements in my version:
>>
>> http://cr.openjdk.java.net/~plevart/misc/LambdaFormEditor.WeakCache/webrev.01/
>>
>>
>>
>> Regards, Peter
>>
>> On 12/03/2014 12:45 PM, Vladimir Ivanov wrote:
>>> Aleksey, thanks for the review.
>>>
>>> I haven't tried -XX:SoftRefLRUPolicyMSPerMB=0, but I did extensive
>>> testing on Octane/Nashorn with multiple low -Xmx levels + frequent
>>> Full GCs (8060147 [1] was the result of those experiments) and stress
>>> tested cache eviction with jdk/java/lang/invoke/LFCache tests in long
>>> running mode.
>>>
>>> Best regards,
>>> Vladimir Ivanov
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8060147
>>>
>>> On 12/3/14, 3:11 PM, Aleksey Shipilev wrote:
>>>> On 12/01/2014 07:58 PM, Vladimir Ivanov wrote:
>>>>> http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
>>>>> https://bugs.openjdk.java.net/browse/JDK-8057020
>>>>
>>>> Looks okay, although the cache management logic gives me a headache
>>>> after the vacation. I thought I spotted a few bugs, but those were only
>>>> false positives.
>>>>
>>>>> The fix is to use SoftReferences to keep LambdaForms alive as long as
>>>>> possible, but avoid throwing OOME until the caches are evicted. I
>>>>> experimented with WeakReferences, but it doesn't hold LambdaForms for
>>>>> long enough: LambdaForm cache hit rate degrades significantly and it
>>>>> negatively affects application startup and warmup, since every
>>>>> instantiated LambdaForm is precompiled to bytecode before usage.
>>>>>
>>>>> Testing: jdk/java/lang/invoke/LFCache in stress mode + jck
>>>>> (api/java_lang/invoke), jdk/java/lang/invoke,
>>>>> jdk/java/util/streams, octane
>>>>
>>>> SoftReferences are tricky in the way they can get suddenly drop the
>>>> referent, and normal testing would not catch it (e.g. the normal
>>>> operation would reclaim softrefs under your feet almost never). Does
>>>> this code survive with -XX:SoftRefLRUPolicyMSPerMB=0?
>>>>
>>>> Thanks,
>>>> -Aleksey.
>>>>
>>>>
>>> _______________________________________________
>>> mlvm-dev mailing list
>>> mlvm-dev at openjdk.java.net
>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>
>>
>


From patrick at reini.net  Mon Dec  8 20:12:47 2014
From: patrick at reini.net (Patrick Reinhart)
Date: Mon, 8 Dec 2014 21:12:47 +0100
Subject: Library enhancement proposal for copying data from/to
	Reader/Writer InputStream/OutputStream
In-Reply-To: <5485B312.7070709@oracle.com>
References: <566A428C-1A13-4DEE-940B-2EBE375F2A7A@reini.net>
	<A3953E4D-018A-44C8-8106-DC9E4663D67C@reini.net>
	<C62A3014-1F54-41E4-B560-198F87305B9E@reini.net>
	<54772C7D.7080209@oracle.com>
	<769E83F8-FD6D-4F8B-B415-DD044C5D08BA@reini.net>
	<D1E803CB-29AF-46AA-9990-77B2A05EFBD4@oracle.com>
	<547757EE.4090205@oracle.com>
	<ED697D7C-F60A-4CD7-B84E-88C10D45B9FB@reini.net>
	<D2DD43D0-5D86-446A-A67A-8D3AEB2541CD@oracle.com>
	<15B58029-95FA-4D9E-AA28-7A6C72D6CB3D@reini.net>
	<13156FAC-6EDC-462B-9BE7-2DFAFB9124FD@oracle.com>
	<20141128201546.000067ce.ecki@zusammenkunft.net>
	<<216A14EF-B62C-4971!	-!> <8194-E...>
	<8E1109C5-4C9E-4B7A-924E-9E92B3F93F89@reini.net>
	<150A2C4B-E239-433C-B0C9-39F70E98D837@oracle.com>
	<5480B9CE.20!	90600@reini.net>
	<DAAE3744-D74C-4528-9498-B7389DC784EF@oracle.com>
	<5481D174.2030406@oracle.com> <5481D67E.9080504@oracle.com!	! >
	<548...	<72DDE6F7-6B03-47D5-A125-BCA3D5CD624E@reini.net>
	<AE34D5A9-FEAC-417C-8A10-F4EC96B4B0A8@oracle.com>
	<54859004.80408@oracle.com> <5485B312.707...
Message-ID: <CB9648B3-F1F4-4EAE-B6B2-471868248148@reini.net>

Hi Chris,

> Am 08.12.2014 um 15:17 schrieb Chris Hegarty <chris.hegarty at oracle.com>:
> 
> Again, just for completeness...
> 
> Some feedback from Paul Sandoz, to be explicit about the "openness" of the streams on return. "Does not close either stream."
> 
> /**
>     * Reads all bytes from this input stream and writes the bytes to the given
>     * output stream in the order that they are read.  On return, this input
>     * stream will be at end of stream. Does not close either stream.
>     * <p>
>     * This method may block indefinitely reading from the input stream, or
>     * writing to the output stream. The behavior for the case that the input
>     * and/or output stream is <i>asynchronously closed</i>, or the thread
>     * interrupted during the transfer, is highly input and output stream
>     * specific, and therefore not specified.
>     * <p>
>     * If an I/O error occurs reading from the input stream or writing to
>     * the output stream, then it may do so after some bytes have been read or
>     * written. Consequently the input stream may not be at end of stream and
>     * one, or both, streams may be in an inconsistent state. It is strongly
>     * recommended that both streams be promptly closed if an I/O error occurs.
>     *
>     * @param  out the output stream, non-null
>     * @return the number of bytes transferred
>     * @throws IOException if an I/O error occurs when reading or writing
>     * @throws NullPointerException  if {@code out} is {@code null}
>     *
>     * @since 1.9
>     */
>    public long transferTo(OutputStream out) throws IOException
> 
> -Chris.

Looks good to me, 

I guess if there are no further change requests on that method we could look at the transfer methods for Readable/Appendable. Here we could put a transferTo method as a default method on the Readable interface or what do you think?

-Patrick

From martinrb at google.com  Mon Dec  8 20:31:13 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 8 Dec 2014 12:31:13 -0800
Subject: RFR: 8065172: More core reflection final and volatile annotations
In-Reply-To: <4E57D36E-1D9A-4EB4-9130-B80730C35069@oracle.com>
References: <CA+kOe0_ek6UDjkOXEggp3JYo=ezxRqprLFUJxQb0v3Mnzj41JQ@mail.gmail.com>
	<546E09D6.9040800@gmail.com>
	<6B93C453-C558-4C0E-B7FA-4255507B154D@oracle.com>
	<54735081.5050201@gmail.com>
	<A1B7B5B4-9590-4155-8546-3117D47AD590@oracle.com>
	<CA+kOe0-AEf_1ZJ0rDziKo5cAStQSasdZ-eDeFGs+2Gqss1_uxA@mail.gmail.com>
	<4E57D36E-1D9A-4EB4-9130-B80730C35069@oracle.com>
Message-ID: <CA+kOe0-Yv8ubBJEViJ0xJwm-89HXO1TmgFyiytq0AMjbv9zs8w@mail.gmail.com>

(sorry for missing this message earlier)

On Tue, Dec 2, 2014 at 1:49 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/
>>
>
> I am not convinced about the use of CAS. If we can get away with just volatile fields I think the code is simpler. Are you concerned there are cases of identity and mutability?

Yes, I'm trying to write this code in the safest possible way, never
for example returning distinct but equivalent Type objects to a user,
possibly triggering very obscure bugs in non-jdk code.  If this code
is not performance crititcal (which I believe to be true), doing it
this way seems best.  If it is performance crititcal, we can switch to
Unsafe CAS or even use Unsafe CAS plus risky relaxed reads as Peter
has suggested (which would improve performance on weak-memory-model
platforms as seen on other email threads).

> All other aspects look good.


From peter.levart at gmail.com  Mon Dec  8 21:24:02 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 08 Dec 2014 22:24:02 +0100
Subject: RFR: 8065172: More core reflection final and volatile annotations
In-Reply-To: <CA+kOe0-Yv8ubBJEViJ0xJwm-89HXO1TmgFyiytq0AMjbv9zs8w@mail.gmail.com>
References: <CA+kOe0_ek6UDjkOXEggp3JYo=ezxRqprLFUJxQb0v3Mnzj41JQ@mail.gmail.com>	<546E09D6.9040800@gmail.com>	<6B93C453-C558-4C0E-B7FA-4255507B154D@oracle.com>	<54735081.5050201@gmail.com>	<A1B7B5B4-9590-4155-8546-3117D47AD590@oracle.com>	<CA+kOe0-AEf_1ZJ0rDziKo5cAStQSasdZ-eDeFGs+2Gqss1_uxA@mail.gmail.com>	<4E57D36E-1D9A-4EB4-9130-B80730C35069@oracle.com>
	<CA+kOe0-Yv8ubBJEViJ0xJwm-89HXO1TmgFyiytq0AMjbv9zs8w@mail.gmail.com>
Message-ID: <548616F2.2040803@gmail.com>


On 12/08/2014 09:31 PM, Martin Buchholz wrote:
> (sorry for missing this message earlier)
>
> On Tue, Dec 2, 2014 at 1:49 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>
>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/

Hi Martin,

I see lots of "changes" in javadocs that appear to have same text. Do 
you know why?


>> I am not convinced about the use of CAS. If we can get away with just volatile fields I think the code is simpler. Are you concerned there are cases of identity and mutability?
> Yes, I'm trying to write this code in the safest possible way, never
> for example returning distinct but equivalent Type objects to a user,
> possibly triggering very obscure bugs in non-jdk code.  If this code
> is not performance crititcal (which I believe to be true), doing it
> this way seems best.  If it is performance crititcal, we can switch to
> Unsafe CAS or even use Unsafe CAS plus risky relaxed reads as Peter
> has suggested (which would improve performance on weak-memory-model
> platforms as seen on other email threads).

"Interned" Types can not be guaranteed, since they are rooted on members 
of j.l.Class (Method, Field, Constructor), which can be GC-ed because of 
either:

- class redefinition
- memory pressure (see j.l.Class.reflectionData field, which points to 
SoftReference<ReflectionData>)

...and next time you request them, new instances will be created and new 
instances of Types with them.

Regards, Peter



From peter.levart at gmail.com  Mon Dec  8 21:29:20 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 08 Dec 2014 22:29:20 +0100
Subject: [9, 8u40] RFR (M): 8057020: LambdaForm caches should support
	eviction
In-Reply-To: <54860564.2090501@oracle.com>
References: <547C9E37.8080809@oracle.com> <547EEFFF.4040409@oracle.com>
	<547EF7CF.7070501@oracle.com> <5482F6CD.6030600@gmail.com>
	<54857C91.9030709@gmail.com> <54860564.2090501@oracle.com>
Message-ID: <54861830.6090302@gmail.com>


On 12/08/2014 09:09 PM, Vladimir Ivanov wrote:
> Peter,
>
>> Just one more thought...
>>
>> In lines:
>>
>>   358                     } else if (stale < 0 && k.get() == null) {
>>   359                         stale = i; // remember 1st stale entry 
>> index
>>   360                     }
>>
>>
>> ...an index to 1st stale entry is remembered while scanning the array so
>> that at the end, instead of always allocating new slot, an existing slot
>> can be re-used. This has an inadvertent effect on the lifetime of
>> SoftReference(s) that are "touched" in the process (LRU policy of
>> cleaning). Here we see that an additional method like
>> SoftReference.isPresent() that didn't "touch" the access time, would be
>> helpful.
> Good point!
>
> However, I don't think that cache eviction policy matters for 
> LabmdaForms. On average, there are very limited number of LambdaForm 
> (up to 8k on Octane/Nashorn in single VM mode). So, in normal 
> situation there should be no need to clear the caches. It's there 
> mostly for correctness - avoid OOME in some corner cases (e.g. random 
> enumeration of method handles).

Yes, there's nothing wrong. It's just that some LambdaForms can get 
longer lifetime than they deserve (according to strict LRU policy), but 
the unreferenced ones should all be released before OOME is thrown anyway.

Regards, Peter

>
> Best regards,
> Vladimir Ivanov
>
>>
>> Regards, Peter
>>
>> On 12/06/2014 01:30 PM, Peter Levart wrote:
>>> (Sorry for a re-send, forgot to include core-libs-dev)...
>>>
>>> Hi Vladimir,
>>>
>>> First, just a nit. I think that in LambdaFormEditor:
>>>
>>>  289     private LambdaForm putInCache(Transform key, LambdaForm 
>>> form) {
>>>  290         key = key.withResult(form);
>>>  291         for (int pass = 0; ; pass++) {
>>>  292             Object c = lambdaForm.transformCache;
>>>  293             if (c instanceof ConcurrentHashMap) {
>>>  294                 @SuppressWarnings("unchecked")
>>>  295 ConcurrentHashMap<Transform,Transform> m =
>>> (ConcurrentHashMap<Transform,Transform>) c;
>>>  296                 Transform k = m.putIfAbsent(key, key);
>>>  297                 if (k == null) return form;
>>>  298                 LambdaForm result = k.get();
>>>  299                 if (result != null) {
>>>  300                     return result;
>>>  301                 } else {
>>>  302                     if (m.replace(key, k, key)) {
>>>  303                         return form;
>>>  304                     } else {
>>>  305                         continue;
>>>  306                     }
>>>  307                 }
>>>  308             }
>>>  309             assert(pass == 0);
>>>  310             synchronized (lambdaForm) {
>>>  311                 c = lambdaForm.transformCache;
>>>  312                 if (c instanceof ConcurrentHashMap)
>>>  313                     continue;
>>>
>>> ...
>>>
>>>  372                     lambdaForm.transformCache = c = m;
>>>                                                      ^^^ put
>>> assignment to 'c' back in
>>>  373                     // The second iteration will update for this
>>> query, concurrently.
>>>  374                     continue;
>>>
>>>
>>> ...you could move the assignment to 'c' in line 292 out of for loop
>>> and put it back in line 372, since once 'c' is instance of CHM,
>>> lambdaForm.transformCache never changes again and if 'c' is not CHM
>>> yet, it is re-assigned in lines 311 and 372 before next loop.
>>>
>>> Am I right?
>>>
>>> Now what scares me (might be that I don't have an intimacy with
>>> LambdaForm class like you do). There is a situation where you publish
>>> LambdaForm instances via data race.
>>>
>>> One form of LambdaForm.transformCache is an array of Transform objects
>>> (the other two forms are not problematic). Transform class has all
>>> fields final except the 'referent' field of SoftReference, which holds
>>> a LambdaForm instance. In the following line:
>>>
>>> 377                 ta[idx] = key;
>>>
>>>
>>> ...you publish Transform object to an element of array with relaxed
>>> write, and in the following lines:
>>>
>>>  271         } else {
>>>  272             Transform[] ta = (Transform[])c;
>>>  273             for (int i = 0; i < ta.length; i++) {
>>>  274                 Transform t = ta[i];
>>>  275                 if (t == null)  break;
>>>  276                 if (t.equals(key)) { k = t; break; }
>>>  277             }
>>>  278         }
>>>  279         assert(k == null || key.equals(k));
>>>  280         return (k != null) ? k.get() : null;
>>>
>>>
>>> ...you obtain the element of the array with no synchronization and a
>>> relaxed read and might return a non-null referent (the LambdaForm)
>>> which is then returned as an interned instance.
>>>
>>> So can LambdaForm instances be published via data races without fear
>>> that they would appear half-initialized?
>>>
>>> That's what I didn't know when I used a lazySet coupled with volatile
>>> get to access array elements in my version:
>>>
>>> http://cr.openjdk.java.net/~plevart/misc/LambdaFormEditor.WeakCache/webrev.01/ 
>>>
>>>
>>>
>>>
>>> Regards, Peter
>>>
>>> On 12/03/2014 12:45 PM, Vladimir Ivanov wrote:
>>>> Aleksey, thanks for the review.
>>>>
>>>> I haven't tried -XX:SoftRefLRUPolicyMSPerMB=0, but I did extensive
>>>> testing on Octane/Nashorn with multiple low -Xmx levels + frequent
>>>> Full GCs (8060147 [1] was the result of those experiments) and stress
>>>> tested cache eviction with jdk/java/lang/invoke/LFCache tests in long
>>>> running mode.
>>>>
>>>> Best regards,
>>>> Vladimir Ivanov
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8060147
>>>>
>>>> On 12/3/14, 3:11 PM, Aleksey Shipilev wrote:
>>>>> On 12/01/2014 07:58 PM, Vladimir Ivanov wrote:
>>>>>> http://cr.openjdk.java.net/~vlivanov/8057020/webrev.00/
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8057020
>>>>>
>>>>> Looks okay, although the cache management logic gives me a headache
>>>>> after the vacation. I thought I spotted a few bugs, but those were 
>>>>> only
>>>>> false positives.
>>>>>
>>>>>> The fix is to use SoftReferences to keep LambdaForms alive as 
>>>>>> long as
>>>>>> possible, but avoid throwing OOME until the caches are evicted. I
>>>>>> experimented with WeakReferences, but it doesn't hold LambdaForms 
>>>>>> for
>>>>>> long enough: LambdaForm cache hit rate degrades significantly and it
>>>>>> negatively affects application startup and warmup, since every
>>>>>> instantiated LambdaForm is precompiled to bytecode before usage.
>>>>>>
>>>>>> Testing: jdk/java/lang/invoke/LFCache in stress mode + jck
>>>>>> (api/java_lang/invoke), jdk/java/lang/invoke,
>>>>>> jdk/java/util/streams, octane
>>>>>
>>>>> SoftReferences are tricky in the way they can get suddenly drop the
>>>>> referent, and normal testing would not catch it (e.g. the normal
>>>>> operation would reclaim softrefs under your feet almost never). Does
>>>>> this code survive with -XX:SoftRefLRUPolicyMSPerMB=0?
>>>>>
>>>>> Thanks,
>>>>> -Aleksey.
>>>>>
>>>>>
>>>> _______________________________________________
>>>> mlvm-dev mailing list
>>>> mlvm-dev at openjdk.java.net
>>>> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>>>
>>>
>>



From peter.levart at gmail.com  Mon Dec  8 21:33:09 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 08 Dec 2014 22:33:09 +0100
Subject: RFR: 8065172: More core reflection final and volatile annotations
In-Reply-To: <548616F2.2040803@gmail.com>
References: <CA+kOe0_ek6UDjkOXEggp3JYo=ezxRqprLFUJxQb0v3Mnzj41JQ@mail.gmail.com>	<546E09D6.9040800@gmail.com>	<6B93C453-C558-4C0E-B7FA-4255507B154D@oracle.com>	<54735081.5050201@gmail.com>	<A1B7B5B4-9590-4155-8546-3117D47AD590@oracle.com>	<CA+kOe0-AEf_1ZJ0rDziKo5cAStQSasdZ-eDeFGs+2Gqss1_uxA@mail.gmail.com>	<4E57D36E-1D9A-4EB4-9130-B80730C35069@oracle.com>
	<CA+kOe0-Yv8ubBJEViJ0xJwm-89HXO1TmgFyiytq0AMjbv9zs8w@mail.gmail.com>
	<548616F2.2040803@gmail.com>
Message-ID: <54861915.5020503@gmail.com>


On 12/08/2014 10:24 PM, Peter Levart wrote:
>
> On 12/08/2014 09:31 PM, Martin Buchholz wrote:
>> (sorry for missing this message earlier)
>>
>> On Tue, Dec 2, 2014 at 1:49 AM, Paul Sandoz<paul.sandoz at oracle.com>  wrote:
>>
>>>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/
>
> Hi Martin,
>
> I see lots of "changes" in javadocs that appear to have same text. Do 
> you know why?
>

Sorry Martin,

My eyes didn't see the changes. They are there!

Regards, Peter



From peter.levart at gmail.com  Mon Dec  8 21:52:19 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 08 Dec 2014 22:52:19 +0100
Subject: RFR: 8065172: More core reflection final and volatile annotations
In-Reply-To: <548616F2.2040803@gmail.com>
References: <CA+kOe0_ek6UDjkOXEggp3JYo=ezxRqprLFUJxQb0v3Mnzj41JQ@mail.gmail.com>	<546E09D6.9040800@gmail.com>	<6B93C453-C558-4C0E-B7FA-4255507B154D@oracle.com>	<54735081.5050201@gmail.com>	<A1B7B5B4-9590-4155-8546-3117D47AD590@oracle.com>	<CA+kOe0-AEf_1ZJ0rDziKo5cAStQSasdZ-eDeFGs+2Gqss1_uxA@mail.gmail.com>	<4E57D36E-1D9A-4EB4-9130-B80730C35069@oracle.com>
	<CA+kOe0-Yv8ubBJEViJ0xJwm-89HXO1TmgFyiytq0AMjbv9zs8w@mail.gmail.com>
	<548616F2.2040803@gmail.com>
Message-ID: <54861D93.9080105@gmail.com>


On 12/08/2014 10:24 PM, Peter Levart wrote:
> "Interned" Types can not be guaranteed, since they are rooted on 
> members of j.l.Class (Method, Field, Constructor), which can be GC-ed 
> because of either:
>
> - class redefinition
> - memory pressure (see j.l.Class.reflectionData field, which points to 
> SoftReference<ReflectionData>)
>
> ...and next time you request them, new instances will be created and 
> new instances of Types with them.
>
> Regards, Peter

Even in the absence of above, the Method, Field, Constructor objects 
obtained from j.l.Class methods are always copied from the "root" 
objects (because they are mutable - setAccessible()) and with copying, 
you always get a "fresh" object that has an uninitialized 'genericInfo' 
field.

Even in the absence of all above, by CAS-ing, you don't actually get 
"interning", since two Type objects from different sources (for example 
generic return types of two different methods) can be equal, but they 
will not be same objects. So I can't see a purpose here. We would have 
to implement Type interning in a global pool to achieve that (like it is 
guaranteed for j.l.Class objects).


Regards, Peter



From martinrb at google.com  Mon Dec  8 22:00:25 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 8 Dec 2014 14:00:25 -0800
Subject: RFR: 8065172: More core reflection final and volatile annotations
In-Reply-To: <54861D93.9080105@gmail.com>
References: <CA+kOe0_ek6UDjkOXEggp3JYo=ezxRqprLFUJxQb0v3Mnzj41JQ@mail.gmail.com>
	<546E09D6.9040800@gmail.com>
	<6B93C453-C558-4C0E-B7FA-4255507B154D@oracle.com>
	<54735081.5050201@gmail.com>
	<A1B7B5B4-9590-4155-8546-3117D47AD590@oracle.com>
	<CA+kOe0-AEf_1ZJ0rDziKo5cAStQSasdZ-eDeFGs+2Gqss1_uxA@mail.gmail.com>
	<4E57D36E-1D9A-4EB4-9130-B80730C35069@oracle.com>
	<CA+kOe0-Yv8ubBJEViJ0xJwm-89HXO1TmgFyiytq0AMjbv9zs8w@mail.gmail.com>
	<548616F2.2040803@gmail.com> <54861D93.9080105@gmail.com>
Message-ID: <CA+kOe0_ktK4Ysv8NuaZAKy=5BWF303gBt0LdoTFNqWxA1sqd7Q@mail.gmail.com>

Alright, I'm convinced and will revert to using ordinary volatile
writes instead of CAS.

Y'all have a deeper understanding of the reflection machinery.

Martin

On Mon, Dec 8, 2014 at 1:52 PM, Peter Levart <peter.levart at gmail.com> wrote:
>
> On 12/08/2014 10:24 PM, Peter Levart wrote:
>
> "Interned" Types can not be guaranteed, since they are rooted on members of
> j.l.Class (Method, Field, Constructor), which can be GC-ed because of
> either:
>
> - class redefinition
> - memory pressure (see j.l.Class.reflectionData field, which points to
> SoftReference<ReflectionData>)
>
> ...and next time you request them, new instances will be created and new
> instances of Types with them.
>
> Regards, Peter
>
>
> Even in the absence of above, the Method, Field, Constructor objects
> obtained from j.l.Class methods are always copied from the "root" objects
> (because they are mutable - setAccessible()) and with copying, you always
> get a "fresh" object that has an uninitialized 'genericInfo' field.
>
> Even in the absence of all above, by CAS-ing, you don't actually get
> "interning", since two Type objects from different sources (for example
> generic return types of two different methods) can be equal, but they will
> not be same objects. So I can't see a purpose here. We would have to
> implement Type interning in a global pool to achieve that (like it is
> guaranteed for j.l.Class objects).
>
>
> Regards, Peter
>


From martinrb at google.com  Mon Dec  8 22:47:39 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 8 Dec 2014 14:47:39 -0800
Subject: RFR: 8065172: More core reflection final and volatile annotations
In-Reply-To: <CA+kOe0_ktK4Ysv8NuaZAKy=5BWF303gBt0LdoTFNqWxA1sqd7Q@mail.gmail.com>
References: <CA+kOe0_ek6UDjkOXEggp3JYo=ezxRqprLFUJxQb0v3Mnzj41JQ@mail.gmail.com>
	<546E09D6.9040800@gmail.com>
	<6B93C453-C558-4C0E-B7FA-4255507B154D@oracle.com>
	<54735081.5050201@gmail.com>
	<A1B7B5B4-9590-4155-8546-3117D47AD590@oracle.com>
	<CA+kOe0-AEf_1ZJ0rDziKo5cAStQSasdZ-eDeFGs+2Gqss1_uxA@mail.gmail.com>
	<4E57D36E-1D9A-4EB4-9130-B80730C35069@oracle.com>
	<CA+kOe0-Yv8ubBJEViJ0xJwm-89HXO1TmgFyiytq0AMjbv9zs8w@mail.gmail.com>
	<548616F2.2040803@gmail.com> <54861D93.9080105@gmail.com>
	<CA+kOe0_ktK4Ysv8NuaZAKy=5BWF303gBt0LdoTFNqWxA1sqd7Q@mail.gmail.com>
Message-ID: <CA+kOe09CHFu=usJ9NmXByc_VMvO-_jfc=t_6sgsD5tS=Z96gDg@mail.gmail.com>

Webrev updated.  Field updaters are gone.  I intend to commit soon.

On Mon, Dec 8, 2014 at 2:00 PM, Martin Buchholz <martinrb at google.com> wrote:
> Alright, I'm convinced and will revert to using ordinary volatile
> writes instead of CAS.
>
> Y'all have a deeper understanding of the reflection machinery.
>
> Martin
>
> On Mon, Dec 8, 2014 at 1:52 PM, Peter Levart <peter.levart at gmail.com> wrote:
>>
>> On 12/08/2014 10:24 PM, Peter Levart wrote:
>>
>> "Interned" Types can not be guaranteed, since they are rooted on members of
>> j.l.Class (Method, Field, Constructor), which can be GC-ed because of
>> either:
>>
>> - class redefinition
>> - memory pressure (see j.l.Class.reflectionData field, which points to
>> SoftReference<ReflectionData>)
>>
>> ...and next time you request them, new instances will be created and new
>> instances of Types with them.
>>
>> Regards, Peter
>>
>>
>> Even in the absence of above, the Method, Field, Constructor objects
>> obtained from j.l.Class methods are always copied from the "root" objects
>> (because they are mutable - setAccessible()) and with copying, you always
>> get a "fresh" object that has an uninitialized 'genericInfo' field.
>>
>> Even in the absence of all above, by CAS-ing, you don't actually get
>> "interning", since two Type objects from different sources (for example
>> generic return types of two different methods) can be equal, but they will
>> not be same objects. So I can't see a purpose here. We would have to
>> implement Type interning in a global pool to achieve that (like it is
>> guaranteed for j.l.Class objects).
>>
>>
>> Regards, Peter
>>


From vladimir.x.ivanov at oracle.com  Mon Dec  8 23:47:34 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 09 Dec 2014 02:47:34 +0300
Subject: [9, 8u40] RFR (XXS): 8066746: MHs.explicitCastArguments does incorrect
	type checks for VarargsCollector
Message-ID: <54863896.3010909@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8066746/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8066746

Recent changes (8057656 [1]) broke MHs.explicitCastArguments for 
VarargsCollector case. It introduced an equivalence check between 
MHs.explicitCastArguments and MethodHandle.asType() which doesn't work 
for VarargsCollector case as expected.

VarargsCollector has special asType() implementation, which supports 
collecting any number of trailing positional arguments into an array 
argument. It doesn't play well with MHs.explicitCastArguments, because 
the latter is meant to be a pairwise argument and return type conversion.

The fix is to ensure that adapted method handle has fixed arity.

Testing: regression test, jck (api/java_lang/invoke), jdk/java/lang/invoke

Thanks!

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8057656


From john.r.rose at oracle.com  Tue Dec  9 00:02:26 2014
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 8 Dec 2014 16:02:26 -0800
Subject: [9,
	8u40] RFR (XXS): 8066746: MHs.explicitCastArguments does incorrect
	type checks for VarargsCollector
In-Reply-To: <54863896.3010909@oracle.com>
References: <54863896.3010909@oracle.com>
Message-ID: <0CCA8908-D33E-457D-8A8C-6B3FD968A935@oracle.com>

Reviewed.  ? John

> On Dec 8, 2014, at 3:47 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
> 
> http://cr.openjdk.java.net/~vlivanov/8066746/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8066746
> 
> Recent changes (8057656 [1]) broke MHs.explicitCastArguments for VarargsCollector case. It introduced an equivalence check between MHs.explicitCastArguments and MethodHandle.asType() which doesn't work for VarargsCollector case as expected.
> 
> VarargsCollector has special asType() implementation, which supports collecting any number of trailing positional arguments into an array argument. It doesn't play well with MHs.explicitCastArguments, because the latter is meant to be a pairwise argument and return type conversion.
> 
> The fix is to ensure that adapted method handle has fixed arity.
> 
> Testing: regression test, jck (api/java_lang/invoke), jdk/java/lang/invoke
> 
> Thanks!
> 
> Best regards,
> Vladimir Ivanov
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8057656



From david.holmes at oracle.com  Tue Dec  9 04:35:43 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 09 Dec 2014 14:35:43 +1000
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <CA+kOe09b_3-08pOt171PYedGoT0Bp5X1HOA7B+PHzCSRMkx6wQ@mail.gmail.com>
References: <CA+kOe0-kaVGdNyaLN2Yo0H4KnM1AU3N=nFryazZP1VbqK9t=Kw@mail.gmail.com>	<NFBBKALFDCPFIDBNKAPCAEJJKLAA.davidcholmes@aapt.net.au>
	<CA+kOe09b_3-08pOt171PYedGoT0Bp5X1HOA7B+PHzCSRMkx6wQ@mail.gmail.com>
Message-ID: <54867C1F.1090106@oracle.com>

Hi Martin,

On 9/12/2014 5:17 AM, Martin Buchholz wrote:
> On Mon, Dec 8, 2014 at 12:46 AM, David Holmes <davidcholmes at aapt.net.au> wrote:
>> Martin,
>>
>> The paper you cite is about ARM and Power architectures - why do you think the lack of mention of x86/sparc implies those architectures are multiple-copy-atomic?
>
> Reading some more in the same paper, I see:

Yes - mea culpa - I should have re-read the paper (I wouldn't have had 
to read very far).

> """Returning to the two properties above, in TSO a thread can see its
> own writes before they become visible to other
> threads (by reading them from its write buffer), but any write becomes
> visible to all other threads simultaneously: TSO
> is a multiple-copy atomic model, in the terminology of Collier
> [Col92]. One can also see the possibility of reading
> from the local write buffer as allowing a specific kind of local
> reordering. A program that writes one location x then
> reads another location y might execute by adding the write to x to the
> thread?s buffer, then reading y from memory,
> before finally making the write to x visible to other threads by
> flushing it from the buffer. In this case the thread reads
> the value of y that was in the memory before the new write of x hits memory."""

So I learnt two things from this:

1. The ARM architecture manual definition of "multi-copy atomicity" is 
not the same as that in the paper for "multiple-copy atomicity". The 
distinction being that the paper allows for a thread to read from its 
own store buffer, as long as all other threads must see the store at the 
same time. That is quite an important difference in terms of classifying 
systems.

2. I had thought that the store buffer might be shared - if not across 
cores then at least across different hardware threads on the same core. 
But it seems that is not the case either (based on the paper and my own 
reading of SPARC architecture info - stores attain global visibility at 
the L2 cache.)

So given that, yes I agree that sparc and x86 are multiple-copy atomic 
as defined by the paper.

> So (as you say) with TSO you don't have a total order of stores if you
> read your own writes out of your own CPU's write buffer.  However, my
> interpretation of "multiple-copy atomic" is that the initial
> publishing thread can choose to use an instruction with sufficiently
> strong memory barrier attached (e.g. LOCK;XXX on x86) to write to
> memory so that the write buffer is flushed and then use plain relaxed
> loads everywhere else to read those memory locations and this explains
> the situation on x86 and sparc where volatile writes are expensive and
> volatile reads are "free" and you get sequential consistency for Java
> volatiles.

We don't use lock'd instructions for volatile stores on x86, but the 
trailing mfence achieves the "flushing".

However this still raised some questions for me. Using a mfence on x86 
or equivalent on sparc, is no different to issuing a "DMB SYNC" on ARM, 
or a SYNC on PowerPC. They each ensure TSO for volatile stores with 
global visibility. So when such fences are used the resulting system 
should be multiple-copy atomic - no? (No!**) And there seems to be an 
equivalence between being multiple-copy atomic and providing the IRIW 
property. Yet we know that on ARM/Power, as per the paper, TSO with 
global visibility is not sufficient to achieve IRIW. So what is it that 
x86 and sparc have in addition to TSO that provides for IRIW?

I pondered this for quite a while before realizing that the mfence on 
x86 (or equivalent on sparc) is not in fact playing the same role as the 
DMB/SYNC on ARM/PPC. The key property that x86 and sparc have (and we 
can ignore the store buffers) is that stores become globally visible - 
if any other thread sees a store then all other threads see the same 
store. Whereas on ARM/PPC you can imagine a store casually making its 
way through the system, gradually becoming visible to more and more 
threads - unless there is a DMB/SYNC to force a globally consistent 
memory view. Hence for IRIW placing the DMB/SYNC after the store does 
not suffice because prior to the DMB/SYNC the store may be visible to an 
arbitrary subset of threads. Consequently IRIW requires the DMB/SYNC 
between the loads - to ensure that each thread on their second load, 
must see the value that the other thread saw on its first load (ref 
Section 6.1 of the paper).

** So using DMB/SYNC does not achieve multiple-copy atomicity, because 
until the DMB/SYNC happens different threads can have different views of 
memory.

All of which reinforces to me that IRIW is an undesirable property to 
have to implement. YMMV. (And I also need to re-examine the PPC64 
implementation to see exactly where they add/remove barriers when IRIW 
is enabled.)

Cheers,
David

> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf
>


From david.holmes at oracle.com  Tue Dec  9 04:51:56 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 09 Dec 2014 14:51:56 +1000
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <CA+kOe0-UvzsMBC1FVv9C69tUwvbYgt5W4F5YvbzeDBtstQzFXg@mail.gmail.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>	<5481108A.3030605@oracle.com>	<CA+kOe08OC57hEgGR-3CSfsJUMVSk-_mCmZK2Gd=3tpkE9=6j_w@mail.gmail.com>	<5484D769.5030609@oracle.com>
	<CA+kOe0-UvzsMBC1FVv9C69tUwvbYgt5W4F5YvbzeDBtstQzFXg@mail.gmail.com>
Message-ID: <54867FEC.2020802@oracle.com>

On 9/12/2014 5:25 AM, Martin Buchholz wrote:
> Webrev updated to remove the comparison with volatile loads and stores.

Thanks. More inline ...

> On Sun, Dec 7, 2014 at 2:40 PM, David Holmes <david.holmes at oracle.com> wrote:
>> On 6/12/2014 7:49 AM, Martin Buchholz wrote:
>>>
>>> On Thu, Dec 4, 2014 at 5:55 PM, David Holmes <david.holmes at oracle.com>
>>> wrote:
>>>
>>>> In general phrasing like: " also known as a LoadLoad plus LoadStore
>>>> barrier
>>>> ..." is misleading to me as these are not "aliases"- the loadFence (in
>>>> this
>>>> case) is being specified to have the same semantics as the
>>>> loadload|storeload. It should say "corresponds to a LoadLoad plus
>>>> LoadStore
>>>> barrier"
>>>
>>>
>>> +     * Ensures that loads before the fence will not be reordered with
>>> loads and
>>> +     * stores after the fence; also known as a LoadLoad plus LoadStore
>>> barrier,
>>>
>>> I don't understand this.  I believe they _are_ aliases.  The first
>>> clause perfectly describes a "LoadLoad plus LoadStore barrier".
>>
>>
>> I find the language use inappropriate - you are defining the first to be the
>> second.
>
> Am I missing something?  Is there something else that "LoadLoad plus
> LoadStore barrier" (as used in hotspot sources and elsewhere) could
> possibly mean?

I think we are getting our wires crossed here. My issue is with the wording:

"also known as a LoadLoad plus LoadStore barrier"

because we are explicitly choosing to specify the operation as being a 
LoadLoad plus LoadStore barrier. Hence I would much prefer it to say 
that this "corresponds to a LoadLoad plus LoadStore barrier".

>>>    - as per the "Corresponds to a C11 ...". And referring to things
>>>>
>>>> like "load-acquire fence" is meaningless without some reference to a
>>>> definition - who defines a load-acquire fence? Is there a universal
>>>> definition? I would be okay with something looser eg:
>>>
>>>
>>> Well, I'm defining "load-acquire fence" here in the javadoc - I'm
>>> claiming that loadFence is also known via other terminology, including
>>> "load-acquire fence".  Although it's true that "load-acquire fence" is
>>> also used to refer to the corresponding C11 fence, which has subtly
>>> different semantics.
>>
>>
>> When you say "also known as XXX" it means that XXX is already defined
>> elsewhere. Unless there is a generally accepted definition of XXX then this
>> doesn't add much value.
>
> Everything about this topic is confusing, but I continue to think that
> "load-acquire fence" is a common industry term.

Then please point me to the common industry definition of it because I 
couldn't find anything definitive. And as you state yourself above one 
definition of it - the corresponding C11 fence - does not in fact have 
the same semantics!

> One of the reasons I
> want to include them in the javadoc is precisely because these
> different terms are generally used synonymously.

I would concede "sometimes referred to as ..." as that doesn't imply a 
single standard agreed upon definition, while still making the link. 
Though even then there is a danger of making false assumptions about the 
equivalence of this fence and those going by the name "load-acquire fence".

David


From nathan.a.clement at hotmail.com  Tue Dec  9 05:17:29 2014
From: nathan.a.clement at hotmail.com (Nathan Clement)
Date: Tue, 9 Dec 2014 16:17:29 +1100
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <C517EC9F-7136-4252-BA5B-FFE8C2CBD4B4@oracle.com>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>
	<54807258.4040303@oracle.com>	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>
	<20141205002430.000060c9.ecki@zusammenkunft.net>
	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>
	<20141205015827.00007ac6.ecki@zusammenkunft.net>
	<CAHjP37HgKZMhjq6_AVZFAdPy4PeZBd7p6JBT0Jt2FqE42eB6Ow@mail.gmail.com>
	<8F896CE2-E268-418F-96CA-0557C1C258B3@oracle.com>
	<5481BB6C.1040700@oracle.com> <5481C3DB.70303@gmail.com>
	<5481CA8C.7050100@oracle.com> <5481EF01.6060009@gmail.com>,
	<C517EC9F-7136-4252-BA5B-FFE8C2CBD4B4@oracle.com>
Message-ID: <COL131-W3093E62A5924C2DC984C5FCA650@phx.gbl>

Hi,

I'd be happy with any of the solutions discussed here.  In our case, we're only calling close() multiple times as a result of the way that try-with-resources works with wrapped streams.

Thanks,

Nathan

Subject: Re: [PATCH] JDK-8054565: FilterOutputStream.close may throw IOException if called twice and underlying flush or close fails
From: chris.hegarty at oracle.com
Date: Fri, 5 Dec 2014 22:37:04 +0000
CC: pavel.rappo at oracle.com; nathan.a.clement at hotmail.com; core-libs-dev at openjdk.java.net
To: peter.levart at gmail.com


On 5 Dec 2014, at 17:44, Peter Levart <peter.levart at gmail.com> wrote:
  
    
  
  
    On 12/05/2014 04:09 PM, Chris Hegarty
      wrote:

    
    On
      05/12/14 14:40, Peter Levart wrote:
      

      On 12/05/2014 03:04 PM, Chris Hegarty
        wrote:
        

        
          

          On 05/12/14 11:38, Pavel Rappo wrote:
          

          +1, I couldn?t say better
            

          
          

          Right. This bug should only try to address the change in
          behavior that
          

          was inadvertently introduced by 7015589[1][2].
          

        
        

        What about the following:
        

        

        

        private boolean closed;
        

        

        public void close() throws IOException {
        

             try (OutputStream ostream = out) {
        

                 if (!closed)  flush();
        

             }
        

             closed = true;
        

        }
        

      
      

      If flush throws, how is anyone supposed to know that they need to
      call close again, and that it was not the close that actually
      threw?
      

    
    

    If they call close() again because they are used to pre 7015589
    behaviour,
I don?t think I have every seen any code that catches the IOException from close() , and tries to close again. But maybe someone does this?
>From AutoCloseable:  ?Cases where the close operation may fail require careful attention by implementers. It is strongly advised to relinquish the underlying resources and to internally mark the resource as closed, prior to throwing the exception. The close method is unlikely to be invoked more than once and so this ensures that the resources are released in a timely manner. Furthermore it reduces problems that could arise when the resource wraps, or is wrapped, by another resource.?
I think the changes I am proposing follows this advise ( as best we can ).
 there is no harm if they call it as a consequence of
    flush() throwing and out.close() succeeding, since the underlying
    stream should 
Yes, ?should".
have idempotent "successful" close(). That's the
    requirement of Closeable.close():

    

    
    /**

     * Closes this stream and
      releases any system resources associated

     * with it. If the stream is
      already closed then invoking this

     * method has no effect.

FilterOutputStream is Closeable, but what you are suggesting is that subsequent calls to close would have an effect, they may call flush.

     * <p> As noted in {@link
      AutoCloseable#close()}, cases where the

     * close may fail require
      careful attention. It is strongly advised

     * to relinquish the underlying
      resources and to internally

     * <em>mark</em> the
      {@code Closeable} as closed, prior to throwing

     * the {@code IOException}.

     *

     * @throws IOException if an I/O
      error occurs

     */

    

    The specification does not say if the stream is to be considered
    "closed" when close() throws IOException. The advice does hint that
    though (and was added about 3 years ago).
Re-reading the advise in AutoCloseable and Closeable, I do not see any problem with the changes I suggested.
-Chris.

      close() should be a one-time shot.
      

      

      I personally think that this was an oversight of the original
      change in 7015589, and not a deliberate behavior. My proposed
      change will restore the behavior of close to pre 7015589, though
      not swallow the IOException from flush.
      

    
    

    The pre 7015589 behaviour did not suppress multiple close() calls to
    underlying stream.

    

    
      

      -Chris.
      

    
    

    I just think that a delegating class like FilterOutputStream should
    be as transparent as possible. If the underlying stream respects the
    contract and advice, the wrapped stream should too. If underlying
    stream needs some out-of-advice treatment, then wrapper like
    FilterOutputStream should not prevent that, because there are all
    kinds of streams out there. Or maybe it should - this is the only
    way to "fix" those streams ;-)

    

    Just do it!

    

    Regards, Peter

    

    
      

      ...this way the impact of the change is
        minimal and still addresses the
        

        problem of JDK-8054565
        <https://bugs.openjdk.java.net/browse/JDK-8054565>.
        

        

        If either flush() or out.close() throw exception the 1st time
        close() is
        

        called, they will both be called also the 2nd time. Only after
        flush()
        

        and out.close() return successfully, then further flush()
        invocations
        

        are suppressed.
        

        

        The alternative would be to not suppress flush() invocations,
        but just
        

        any exception thrown from flush():
        

        

        

             private boolean closed;
        

        

             public void close() throws IOException {
        

                 try (OutputStream ostream = out) {
        

                     try {
        

                         flush();
        

                     } catch (IOException | RuntimeException | Error e)
        {
        

                         if (!closed) throw e;
        

                     }
        

                 }
        

                 closed = true;
        

             }
        

        

        

        But I don't know if this is better or worse. It certainly could
        still be
        

        squeezed under the spec which says:
        

        

              * The <code>close</code> method of
        <code>FilterOutputStream</code>
        

              * calls its <code>flush</code> method, and
        then calls the
        

              * <code>close</code> method of its underlying
        output stream.
        

        

        

        Regards, Peter
        

        

        
          

          I don't see any reason to make 'closed' protected ( part of
          the public
          

          Java SE API ), something like:
          

          

          diff --git
          

          a/src/java.base/share/classes/java/io/FilterOutputStream.java
          

          b/src/java.base/share/classes/java/io/FilterOutputStream.java
          

          ---
          a/src/java.base/share/classes/java/io/FilterOutputStream.java
          

          +++
          b/src/java.base/share/classes/java/io/FilterOutputStream.java
          

          @@ -48,6 +48,8 @@
          

                */
          

               protected OutputStream out;
          

          

          +    private boolean closed; // false
          

          +
          

               /**
          

                * Creates an output stream filter built on top of the
          specified
          

                * underlying output stream.
          

          @@ -154,6 +156,9 @@
          

                */
          

               @SuppressWarnings("try")
          

               public void close() throws IOException {
          

          +        if (closed)
          

          +            return;
          

          +        closed = true;
          

                   try (OutputStream ostream = out) {
          

                       flush();
          

                   }
          

          

          diff --git a/test/java/io/etc/FailingFlushAndClose.java
          

          b/test/java/io/etc/FailingFlushAndClose.java
          

          --- a/test/java/io/etc/FailingFlushAndClose.java
          

          +++ b/test/java/io/etc/FailingFlushAndClose.java
          

          @@ -25,7 +25,7 @@
          

          

           /**
          

            * @test
          

          - * @bug 7015589
          

          + * @bug 7015589 8054565
          

            * @summary Test that buffering streams are considered closed
          even
          

          when the
          

            *    close or flush from the underlying stream fails.
          

            */
          

          @@ -165,7 +165,7 @@
          

                   }
          

               }
          

          

          -    static void testFailingClose(InputStream in) throws
          IOException {
          

          +    static InputStream testFailingClose(InputStream in)
          throws
          

          IOException {
          

                   System.out.println(in.getClass());
          

                   in.read(new byte[100]);
          

                   try {
          

          @@ -176,9 +176,10 @@
          

                       in.read(new byte[100]);
          

                       fail("read did not fail");
          

                   } catch (IOException expected) { }
          

          +        return in;
          

               }
          

          

          -    static void testFailingClose(OutputStream out) throws
          IOException {
          

          +    static OutputStream testFailingClose(OutputStream out)
          throws
          

          IOException {
          

                   System.out.println(out.getClass());
          

                   out.write(1);
          

                   try {
          

          @@ -190,9 +191,10 @@
          

                       if (!(out instanceof BufferedOutputStream))
          

                           fail("write did not fail");
          

                   } catch (IOException expected) { }
          

          +        return out;
          

               }
          

          

          -    static void testFailingFlush(OutputStream out) throws
          IOException {
          

          +    static OutputStream testFailingFlush(OutputStream out)
          throws
          

          IOException {
          

                   System.out.println(out.getClass());
          

                   out.write(1);
          

                   try {
          

          @@ -206,9 +208,27 @@
          

                           fail("close did not fail");
          

                       } catch (IOException expected) { }
          

                   }
          

          +        return out;
          

               }
          

          

          -    static void testFailingClose(Reader r) throws IOException
          {
          

          +    static void closeAgain(InputStream in) throws IOException
          {
          

          +        // assert the given stream should already be closed.
          

          +        try {
          

          +            in.close();
          

          +        } catch (IOException expected) {
          

          +            fail("unexpected IOException from subsequent
          close");
          

          +        }
          

          +    }
          

          +    static void closeAgain(OutputStream out) throws
          IOException {
          

          +        // assert the given stream should already be closed.
          

          +        try {
          

          +            out.close();
          

          +        } catch (IOException expected) {
          

          +            fail("unexpected IOException from subsequent
          close");
          

          +        }
          

          +    }
          

          +
          

          +    static Reader testFailingClose(Reader r) throws
          IOException {
          

                   System.out.println(r.getClass());
          

                   r.read(new char[100]);
          

                   try {
          

          @@ -219,9 +239,10 @@
          

                       r.read(new char[100]);
          

                       fail("read did not fail");
          

                   } catch (IOException expected) { }
          

          +        return r;
          

               }
          

          

          -    static void testFailingClose(Writer w) throws IOException
          {
          

          +    static Writer testFailingClose(Writer w) throws
          IOException {
          

                   System.out.println(w.getClass());
          

                   w.write("message");
          

                   try {
          

          @@ -232,9 +253,10 @@
          

                       w.write("another message");
          

                       fail("write did not fail");
          

                   } catch (IOException expected) { }
          

          +        return w;
          

               }
          

          

          -    static void testFailingFlush(Writer w) throws IOException
          {
          

          +    static Writer testFailingFlush(Writer w) throws
          IOException {
          

                   System.out.println(w.getClass());
          

                   w.write("message");
          

                   try {
          

          @@ -249,18 +271,38 @@
          

                           fail("close did not fail");
          

                       } catch (IOException expected) { }
          

                   }
          

          +        return w;
          

          +    }
          

          +
          

          +    static Reader closeAgain(Reader r) throws IOException {
          

          +        // assert the given stream should already be closed.
          

          +        try {
          

          +            r.close();
          

          +        } catch (IOException expected) {
          

          +            fail("unexpected IOException from subsequent
          close");
          

          +        }
          

          +        return r;
          

          +    }
          

          +    static Writer closeAgain(Writer w) throws IOException {
          

          +        // assert the given stream should already be closed.
          

          +        try {
          

          +            w.close();
          

          +        } catch (IOException expected) {
          

          +            fail("unexpected IOException from subsequent
          close");
          

          +        }
          

          +        return w;
          

               }
          

          

               public static void main(String[] args) throws IOException
          {
          

          

          -        testFailingClose(new BufferedInputStream(new
          

          FailingCloseInputStream()));
          

          -        testFailingClose(new BufferedOutputStream(new
          

          FailingCloseOutputStream()));
          

          +        closeAgain(testFailingClose(new
          BufferedInputStream(new
          

          FailingCloseInputStream())));
          

          +        closeAgain(testFailingClose(new
          BufferedOutputStream(new
          

          FailingCloseOutputStream())));
          

          

          -        testFailingClose(new BufferedReader(new
          FailingCloseReader()));
          

          -        testFailingClose(new BufferedWriter(new
          FailingCloseWriter()));
          

          +        closeAgain(testFailingClose(new BufferedReader(new
          

          FailingCloseReader())));
          

          +        closeAgain(testFailingClose(new BufferedWriter(new
          

          FailingCloseWriter())));
          

          

          -        testFailingFlush(new BufferedOutputStream(new
          

          FailingFlushOutputStream()));
          

          -        testFailingFlush(new BufferedWriter(new
          FailingFlushWriter()));
          

          +        closeAgain(testFailingFlush(new
          BufferedOutputStream(new
          

          FailingFlushOutputStream())));
          

          +        closeAgain(testFailingFlush(new BufferedWriter(new
          

          FailingFlushWriter())));
          

          

                   if (failed > 0)
          

                       throw new RuntimeException(failed + " test(s)
          failed -
          

          see log for details");
          

          

          

          -Chris.
          

          

          [1] https://bugs.openjdk.java.net/browse/JDK-7015589
          

          [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/759aa847dcaf
          

          

          

          -Pavel
            

            

            On 5 Dec 2014, at 01:18, Vitaly
              Davidovich <vitalyd at gmail.com> wrote:
              

              

              Attempting to make close() atomic just makes the next
              reader
              

              confused when the rest of the class isn't and may also
              penalize single
              

              threaded callers of close().
              

            
            

          
        
        

      
    
    

  


 		 	   		  

From konstantin.shefov at oracle.com  Tue Dec  9 08:51:40 2014
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Tue, 09 Dec 2014 11:51:40 +0300
Subject: [9] Review request : JDK-8066798: TEST_RFR: Make
	java/lang/invoke/LFCaching
	tests use lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java to
	define their number of iterations
Message-ID: <5486B81B.5050200@oracle.com>

Hello,

Please review the test enhancement 
https://bugs.openjdk.java.net/browse/JDK-8066798
Webrev is http://cr.openjdk.java.net/~kshefov/8066798/webrev.00

Test has been modified to use 
lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java class to define 
its number of iterations depending on the given timeout.
Also @ignore tag has been removed from 
test/java/lang/invoke/LFCaching/LFGarbageCollectedTest.java because 
JDK-8057020 has been fixed in JDK 9.

Thanks

-Konstantin


From igor.ignatyev at oracle.com  Tue Dec  9 09:28:44 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 09 Dec 2014 12:28:44 +0300
Subject: [9] Review request : JDK-8066798: TEST_RFR: Make
	java/lang/invoke/LFCaching
	tests use lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java to
	define their number of iterations
In-Reply-To: <5486B81B.5050200@oracle.com>
References: <5486B81B.5050200@oracle.com>
Message-ID: <5486C0CC.4000908@oracle.com>

Hi Konstantin,

0. I don't like static variables which you introduced. were I you, I'd 
create a class which encapsulates them.
+ it looks like
  - doneIterations is a local for the lambda
  - totalIterations is almost affectively final
  - testCounter/failCounter are just informative variable and can be omitted
so you just need a way to store/get passed value. that can be done via 
mutable box, e.g. new boolean[1], AtomicBoolean.

1. why do you catch Throwable? please catch the most specific exception
2. at lines 174-176, you lose exception information, it's better not to 
print exception's stack trace, but pass the exception to ctor of Error.

Thanks,
Igor

On 12/09/2014 11:51 AM, Konstantin Shefov wrote:
> Hello,
>
> Please review the test enhancement
> https://bugs.openjdk.java.net/browse/JDK-8066798
> Webrev is http://cr.openjdk.java.net/~kshefov/8066798/webrev.00
>
> Test has been modified to use
> lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java class to define
> its number of iterations depending on the given timeout.
> Also @ignore tag has been removed from
> test/java/lang/invoke/LFCaching/LFGarbageCollectedTest.java because
> JDK-8057020 has been fixed in JDK 9.
>
> Thanks
>
> -Konstantin

-- 
Igor


From konstantin.shefov at oracle.com  Tue Dec  9 11:19:37 2014
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Tue, 09 Dec 2014 14:19:37 +0300
Subject: [9] Review request : JDK-8066798: TEST_RFR: Make
	java/lang/invoke/LFCaching
	tests use lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java to
	define their number of iterations
In-Reply-To: <5486C0CC.4000908@oracle.com>
References: <5486B81B.5050200@oracle.com> <5486C0CC.4000908@oracle.com>
Message-ID: <5486DAC9.5050108@oracle.com>

Hi Igor

Thanks for reviewing.
I have made some changes, added a separate class to store the variables. 
"doneIterations" is not local for lambda, it is incremented after each 
lambda execution.
Also I changed to catch Exception.

http://cr.openjdk.java.net/~kshefov/8066798/webrev.01

-Konstantin

On 09.12.2014 12:28, Igor Ignatyev wrote:
> Hi Konstantin,
>
> 0. I don't like static variables which you introduced. were I you, I'd 
> create a class which encapsulates them.
> + it looks like
>  - doneIterations is a local for the lambda
>  - totalIterations is almost affectively final
>  - testCounter/failCounter are just informative variable and can be 
> omitted
> so you just need a way to store/get passed value. that can be done via 
> mutable box, e.g. new boolean[1], AtomicBoolean.
>
> 1. why do you catch Throwable? please catch the most specific exception
> 2. at lines 174-176, you lose exception information, it's better not 
> to print exception's stack trace, but pass the exception to ctor of 
> Error.
>
> Thanks,
> Igor
>
> On 12/09/2014 11:51 AM, Konstantin Shefov wrote:
>> Hello,
>>
>> Please review the test enhancement
>> https://bugs.openjdk.java.net/browse/JDK-8066798
>> Webrev is http://cr.openjdk.java.net/~kshefov/8066798/webrev.00
>>
>> Test has been modified to use
>> lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java class to define
>> its number of iterations depending on the given timeout.
>> Also @ignore tag has been removed from
>> test/java/lang/invoke/LFCaching/LFGarbageCollectedTest.java because
>> JDK-8057020 has been fixed in JDK 9.
>>
>> Thanks
>>
>> -Konstantin
>



From paul.sandoz at oracle.com  Tue Dec  9 11:23:25 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 9 Dec 2014 12:23:25 +0100
Subject: RFR: 8065172: More core reflection final and volatile annotations
In-Reply-To: <CA+kOe09CHFu=usJ9NmXByc_VMvO-_jfc=t_6sgsD5tS=Z96gDg@mail.gmail.com>
References: <CA+kOe0_ek6UDjkOXEggp3JYo=ezxRqprLFUJxQb0v3Mnzj41JQ@mail.gmail.com>
	<546E09D6.9040800@gmail.com>
	<6B93C453-C558-4C0E-B7FA-4255507B154D@oracle.com>
	<54735081.5050201@gmail.com>
	<A1B7B5B4-9590-4155-8546-3117D47AD590@oracle.com>
	<CA+kOe0-AEf_1ZJ0rDziKo5cAStQSasdZ-eDeFGs+2Gqss1_uxA@mail.gmail.com>
	<4E57D36E-1D9A-4EB4-9130-B80730C35069@oracle.com>
	<CA+kOe0-Yv8ubBJEViJ0xJwm-89HXO1TmgFyiytq0AMjbv9zs8w@mail.gmail.com>
	<548616F2.2040803@gmail.com> <54861D93.9080105@gmail.com>
	<CA+kOe0_ktK4Ysv8NuaZAKy=5BWF303gBt0LdoTFNqWxA1sqd7Q@mail.gmail.com>
	<CA+kOe09CHFu=usJ9NmXByc_VMvO-_jfc=t_6sgsD5tS=Z96gDg@mail.gmail.com>
Message-ID: <112EA4F1-358F-4349-A6CC-B6C157996BD9@oracle.com>

On Dec 8, 2014, at 11:47 PM, Martin Buchholz <martinrb at google.com> wrote:
> Webrev updated.

Not quite sure how the webrev was updated:

  http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/

But the patch file 

  http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/core-reflection-more-safety.patch

seems out of sync with the contents for each diff e.g:

http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java.sdiff.html

Do you observe the same?


>  Field updaters are gone.  I intend to commit soon.
> 

I went through the diffs individually and it seems fine but i don't have 100% confidence that the webrev has not been unintentionally mangled.

Paul.


From igor.ignatyev at oracle.com  Tue Dec  9 12:03:00 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 09 Dec 2014 15:03:00 +0300
Subject: [9] Review request : JDK-8066798: TEST_RFR: Make
	java/lang/invoke/LFCaching
	tests use lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java to
	define their number of iterations
In-Reply-To: <5486DAC9.5050108@oracle.com>
References: <5486B81B.5050200@oracle.com> <5486C0CC.4000908@oracle.com>
	<5486DAC9.5050108@oracle.com>
Message-ID: <5486E4F4.4070103@oracle.com>

Konstantin,

well, now I don't see any points to have a lambda. you can simple make 
it a method in TestRunInfo and rename TestRunInfo into TestRun.

>  174                             t.printStackTrace();
>  175                             System.err.println("FAILED");
you don't print exception message.

-- 
Igor

On 12/09/2014 02:19 PM, Konstantin Shefov wrote:
> Hi Igor
>
> Thanks for reviewing.
> I have made some changes, added a separate class to store the variables.
> "doneIterations" is not local for lambda, it is incremented after each
> lambda execution.
> Also I changed to catch Exception.
>
> http://cr.openjdk.java.net/~kshefov/8066798/webrev.01
>
> -Konstantin
>
> On 09.12.2014 12:28, Igor Ignatyev wrote:
>> Hi Konstantin,
>>
>> 0. I don't like static variables which you introduced. were I you, I'd
>> create a class which encapsulates them.
>> + it looks like
>>  - doneIterations is a local for the lambda
>>  - totalIterations is almost affectively final
>>  - testCounter/failCounter are just informative variable and can be
>> omitted
>> so you just need a way to store/get passed value. that can be done via
>> mutable box, e.g. new boolean[1], AtomicBoolean.
>>
>> 1. why do you catch Throwable? please catch the most specific exception
>> 2. at lines 174-176, you lose exception information, it's better not
>> to print exception's stack trace, but pass the exception to ctor of
>> Error.
>>
>> Thanks,
>> Igor
>>
>> On 12/09/2014 11:51 AM, Konstantin Shefov wrote:
>>> Hello,
>>>
>>> Please review the test enhancement
>>> https://bugs.openjdk.java.net/browse/JDK-8066798
>>> Webrev is http://cr.openjdk.java.net/~kshefov/8066798/webrev.00
>>>
>>> Test has been modified to use
>>> lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java class to define
>>> its number of iterations depending on the given timeout.
>>> Also @ignore tag has been removed from
>>> test/java/lang/invoke/LFCaching/LFGarbageCollectedTest.java because
>>> JDK-8057020 has been fixed in JDK 9.
>>>
>>> Thanks
>>>
>>> -Konstantin
>>
>


From paul.sandoz at oracle.com  Tue Dec  9 12:12:45 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 9 Dec 2014 13:12:45 +0100
Subject: [9,
	8u40] RFR (XXS): 8066746: MHs.explicitCastArguments does incorrect
	type checks for VarargsCollector
In-Reply-To: <54863896.3010909@oracle.com>
References: <54863896.3010909@oracle.com>
Message-ID: <9AB96438-4D50-4404-BFE2-6DBD7ECA44A4@oracle.com>


On Dec 9, 2014, at 12:47 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:

> http://cr.openjdk.java.net/~vlivanov/8066746/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8066746
> 

Looks ok.

Curiously, is there a reason why you chose to use MH.invokeWithArguments rather than MH.invoke/invokeExact?

Paul.


> Recent changes (8057656 [1]) broke MHs.explicitCastArguments for VarargsCollector case. It introduced an equivalence check between MHs.explicitCastArguments and MethodHandle.asType() which doesn't work for VarargsCollector case as expected.
> 
> VarargsCollector has special asType() implementation, which supports collecting any number of trailing positional arguments into an array argument. It doesn't play well with MHs.explicitCastArguments, because the latter is meant to be a pairwise argument and return type conversion.
> 
> The fix is to ensure that adapted method handle has fixed arity.
> 
> Testing: regression test, jck (api/java_lang/invoke), jdk/java/lang/invoke
> 
> Thanks!
> 
> Best regards,
> Vladimir Ivanov
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8057656
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev



From vladimir.x.ivanov at oracle.com  Tue Dec  9 12:28:54 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 09 Dec 2014 15:28:54 +0300
Subject: [9, 8u40] RFR (XXS): 8066746: MHs.explicitCastArguments does
	incorrect type checks for VarargsCollector
In-Reply-To: <9AB96438-4D50-4404-BFE2-6DBD7ECA44A4@oracle.com>
References: <54863896.3010909@oracle.com>
	<9AB96438-4D50-4404-BFE2-6DBD7ECA44A4@oracle.com>
Message-ID: <5486EB06.6040404@oracle.com>

John, Paul, thanks for the reviews!

> Looks ok.
>
> Curiously, is there a reason why you chose to use MH.invokeWithArguments rather than MH.invoke/invokeExact?
No particular reason. Just didn't want to want to spend time tuning call 
site for signature polymorphic method.

Best regards,
Vladimir Ivanov


From konstantin.shefov at oracle.com  Tue Dec  9 13:03:25 2014
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Tue, 09 Dec 2014 16:03:25 +0300
Subject: [9] Review request : JDK-8066798: TEST_RFR: Make
	java/lang/invoke/LFCaching
	tests use lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java to
	define their number of iterations
In-Reply-To: <5486E4F4.4070103@oracle.com>
References: <5486B81B.5050200@oracle.com> <5486C0CC.4000908@oracle.com>
	<5486DAC9.5050108@oracle.com> <5486E4F4.4070103@oracle.com>
Message-ID: <5486F31D.6020301@oracle.com>

Igor,

I changed the webrev: http://cr.openjdk.java.net/~kshefov/8066798/webrev.02

-Konstantin

On 09.12.2014 15:03, Igor Ignatyev wrote:
> Konstantin,
>
> well, now I don't see any points to have a lambda. you can simple make 
> it a method in TestRunInfo and rename TestRunInfo into TestRun.
>
>>  174 t.printStackTrace();
>>  175                             System.err.println("FAILED");
> you don't print exception message.
>
> -- 
> Igor
>
> On 12/09/2014 02:19 PM, Konstantin Shefov wrote:
>> Hi Igor
>>
>> Thanks for reviewing.
>> I have made some changes, added a separate class to store the variables.
>> "doneIterations" is not local for lambda, it is incremented after each
>> lambda execution.
>> Also I changed to catch Exception.
>>
>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.01
>>
>> -Konstantin
>>
>> On 09.12.2014 12:28, Igor Ignatyev wrote:
>>> Hi Konstantin,
>>>
>>> 0. I don't like static variables which you introduced. were I you, I'd
>>> create a class which encapsulates them.
>>> + it looks like
>>>  - doneIterations is a local for the lambda
>>>  - totalIterations is almost affectively final
>>>  - testCounter/failCounter are just informative variable and can be
>>> omitted
>>> so you just need a way to store/get passed value. that can be done via
>>> mutable box, e.g. new boolean[1], AtomicBoolean.
>>>
>>> 1. why do you catch Throwable? please catch the most specific exception
>>> 2. at lines 174-176, you lose exception information, it's better not
>>> to print exception's stack trace, but pass the exception to ctor of
>>> Error.
>>>
>>> Thanks,
>>> Igor
>>>
>>> On 12/09/2014 11:51 AM, Konstantin Shefov wrote:
>>>> Hello,
>>>>
>>>> Please review the test enhancement
>>>> https://bugs.openjdk.java.net/browse/JDK-8066798
>>>> Webrev is http://cr.openjdk.java.net/~kshefov/8066798/webrev.00
>>>>
>>>> Test has been modified to use
>>>> lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java class to define
>>>> its number of iterations depending on the given timeout.
>>>> Also @ignore tag has been removed from
>>>> test/java/lang/invoke/LFCaching/LFGarbageCollectedTest.java because
>>>> JDK-8057020 has been fixed in JDK 9.
>>>>
>>>> Thanks
>>>>
>>>> -Konstantin
>>>
>>



From igor.ignatyev at oracle.com  Tue Dec  9 13:50:23 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 09 Dec 2014 16:50:23 +0300
Subject: [9] Review request : JDK-8066798: TEST_RFR: Make
	java/lang/invoke/LFCaching
	tests use lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java to
	define their number of iterations
In-Reply-To: <5486F31D.6020301@oracle.com>
References: <5486B81B.5050200@oracle.com> <5486C0CC.4000908@oracle.com>
	<5486DAC9.5050108@oracle.com> <5486E4F4.4070103@oracle.com>
	<5486F31D.6020301@oracle.com>
Message-ID: <5486FE1F.8050608@oracle.com>

on last thing to think about:
does it make sense to move 'if (!run.passed) { ... } else { ... }' code 
into TestRun class?


On 12/09/2014 04:03 PM, Konstantin Shefov wrote:
> Igor,
>
> I changed the webrev: http://cr.openjdk.java.net/~kshefov/8066798/webrev.02
>
> -Konstantin
>
> On 09.12.2014 15:03, Igor Ignatyev wrote:
>> Konstantin,
>>
>> well, now I don't see any points to have a lambda. you can simple make
>> it a method in TestRunInfo and rename TestRunInfo into TestRun.
>>
>>>  174 t.printStackTrace();
>>>  175                             System.err.println("FAILED");
>> you don't print exception message.
>>
>> --
>> Igor
>>
>> On 12/09/2014 02:19 PM, Konstantin Shefov wrote:
>>> Hi Igor
>>>
>>> Thanks for reviewing.
>>> I have made some changes, added a separate class to store the variables.
>>> "doneIterations" is not local for lambda, it is incremented after each
>>> lambda execution.
>>> Also I changed to catch Exception.
>>>
>>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.01
>>>
>>> -Konstantin
>>>
>>> On 09.12.2014 12:28, Igor Ignatyev wrote:
>>>> Hi Konstantin,
>>>>
>>>> 0. I don't like static variables which you introduced. were I you, I'd
>>>> create a class which encapsulates them.
>>>> + it looks like
>>>>  - doneIterations is a local for the lambda
>>>>  - totalIterations is almost affectively final
>>>>  - testCounter/failCounter are just informative variable and can be
>>>> omitted
>>>> so you just need a way to store/get passed value. that can be done via
>>>> mutable box, e.g. new boolean[1], AtomicBoolean.
>>>>
>>>> 1. why do you catch Throwable? please catch the most specific exception
>>>> 2. at lines 174-176, you lose exception information, it's better not
>>>> to print exception's stack trace, but pass the exception to ctor of
>>>> Error.
>>>>
>>>> Thanks,
>>>> Igor
>>>>
>>>> On 12/09/2014 11:51 AM, Konstantin Shefov wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the test enhancement
>>>>> https://bugs.openjdk.java.net/browse/JDK-8066798
>>>>> Webrev is http://cr.openjdk.java.net/~kshefov/8066798/webrev.00
>>>>>
>>>>> Test has been modified to use
>>>>> lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java class to define
>>>>> its number of iterations depending on the given timeout.
>>>>> Also @ignore tag has been removed from
>>>>> test/java/lang/invoke/LFCaching/LFGarbageCollectedTest.java because
>>>>> JDK-8057020 has been fixed in JDK 9.
>>>>>
>>>>> Thanks
>>>>>
>>>>> -Konstantin
>>>>
>>>
>

-- 
Igor


From peter.levart at gmail.com  Tue Dec  9 15:25:53 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Tue, 09 Dec 2014 16:25:53 +0100
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <54832B79.7040406@cs.oswego.edu>
References: <2373415B-DC02-45FC-A2CD-05206BCE0C3B@oracle.com>	<547DEC01.2050501@gmail.com>	<547DF89A.2020809@oracle.com>	<CA+kOe0_Liet+n5S5aD1-PCZbg6QSmFTMGuCN7djRUVuA2MNJSg@mail.gmail.com>	<547F2BC1.6040904@cs.oswego.edu>	<CA+kOe0_h2EBbY51qh7MSUFpq44FpOspgtBVF6qVWENMwW2O0xA@mail.gmail.com>	<547F4A9D.3060805@cs.oswego.edu>	<CA+kOe08vnvXtDE_Xv+6iqtpBaRR3MpdeRV0OtksqMJ_aJpi9Dg@mail.gmail.com>	<547F8B84.6090301@cs.oswego.edu>	<CA+kOe0_D0yxDEWq4DNQN_DL-yv-+Am3gFx_Foq-G63BDkrSHuQ@mail.gmail.com>	<5480195B.4070800@gmail.com>	<F498D1ED-6C4B-4F5B-8F82-036715009EEC@oracle.com>	<5480FAE1.4080909@cs.oswego.edu>
	<54832B79.7040406@cs.oswego.edu>
Message-ID: <54871481.908@gmail.com>

Hi Doug,

On 12/06/2014 05:14 PM, Doug Lea wrote:
> On 12/04/2014 07:22 PM, Doug Lea wrote:
>
>> Because Random, SplittableRandom, and ThreadLocalRandom all use the
>> same basic approach, they can/should use the same mechanism.
>
> In other words, to establish a common default-constructor-seed
> generator internal to the JDK. So we only need one environmental
> seed to start it off, and can remove some redundancies.

In jdk9 with modules you could move the seed generator into a public 
class in a package that is not exported from java.base module (for 
example: java.util.concurrent.internal). Standalone j.u.c builds can be 
unchanged then.

>
>> Placing the mechanics in TLR seems to work out best.
>
> Well, except that on Windows, we'd still need to create
> a .dll just for the sake of calling CryptGenRandom (or
> RtlGenRandom?), which seems like a bad move all around.
> If we are trying to reduce initialization costs,
> it would be better and faster if this were integrated
> with other platform-specific JVM startup. (Requiring a
> separate .dll also makes it impossible for us to create
> standalone j.u.c builds for previews etc.) Which brings
> us back to establishing some means of getting from the JVM,
> only once, 8 bytes of environmentally-derived bits for a
> within-JDK caller. Doing this might be a good opportunity
> for exploiting any upcoming modularity support. Or short of
> that, placing it in an existing JVM interface class like Unsafe.
> Any thoughts?

What about if we change some existing J2SE API to be more 
resource/initialization-friendly. java.util.UUID currently uses 
SecureRandom. It could be changed to use /dev/urandom or RtlGenRandom 
instead (with a fall-back to non-blocking SecureRandom). Each random 
UUID instance contains 16 cryptographically strong random bytes (minus 6 
bits that are overwritten with UUID variant/version bits).

Regards, Peter

>
>> (Also, at some point we might reconsider our cowardice about not
>> improving the internal java.util.Random algorithm. j.u.Random is
>> much more commonly used, and does not fare well on quality tests.
>> On the other hand, the more that users instead choose to use
>> SR or TLR, the better.)
>>
>
> The main problem is code (not just JDK test code) that hardwires
> expected Random.next* output under given seeds. Which might be
> enough reason to leave it alone.
> Do any CCC members have an opinion?
>
> As a lesser but still worthwhile target though, I can't think of
> a reason not to change java.lang.Math.random() to use TLR
> to get faster and better-quality values. (Because there is no
> way to explicitly seed Math.random, there is no hardwiring problem.)
> Some existing javadoc for it saying that it creates a new
> java.util.Random() should be deleted, although I don't
> think it has any user-visible impact.
> http://docs.oracle.com/javase/8/docs/api/java/lang/Math.html#random--
>
> -Doug
>
>
>



From pavel.rappo at oracle.com  Tue Dec  9 15:47:15 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 9 Dec 2014 15:47:15 +0000
Subject: RFR JDK-8066867: Add InputStream transferTo to transfer content to an
	OutputStream 
In-Reply-To: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com>
References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com>
Message-ID: <ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>

Hi everyone,

Could you please review my change for JDK-8066867?

http://cr.openjdk.java.net/~prappo/8066867/webrev.00/

---------------------------------------------------------------- 
The task originated from discussion:
  http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029650.html

From Alan.Bateman at oracle.com  Tue Dec  9 16:11:13 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 09 Dec 2014 16:11:13 +0000
Subject: RFR JDK-8066867: Add InputStream transferTo to transfer content
	to an OutputStream
In-Reply-To: <ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>
References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com>
	<ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>
Message-ID: <54871F21.10309@oracle.com>

On 09/12/2014 15:47, Pavel Rappo wrote:
> Hi everyone,
>
> Could you please review my change for JDK-8066867?
>
> http://cr.openjdk.java.net/~prappo/8066867/webrev.00/
>
In the transferTo then transferred needs to be a long. I think I would 
re-work the loop to make it a bit more readable but that is a somewhat 
subjective comment.

The test looks reasonable (from a quick skim) but the method names are 
inconsistent (the methods in lower case with embedded underscores).

-Alan.


From mark.reinhold at oracle.com  Tue Dec  9 16:16:23 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Tue, 09 Dec 2014 08:16:23 -0800
Subject: [9] Review request : JDK-8066798: TEST_RFR:
	Make	java/lang/invoke/LFCaching	tests use
	lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java
	to	define their number of iterations
In-Reply-To: <5486B81B.5050200@oracle.com>
References: <5486B81B.5050200@oracle.com>
Message-ID: <20141209081623.936190@eggemoggin.niobe.net>

2014/12/9 12:51 -0800, konstantin.shefov at oracle.com:
> Please review the test enhancement 
> https://bugs.openjdk.java.net/browse/JDK-8066798

The synopsis of this issue begins with "TEST_RFR".

What does that even mean?  Why do we need it?

I'm concerned that the proliferation of "TEST*" prefixes
is just adding noise, rather than useful information.

- Mark


From david.lloyd at redhat.com  Tue Dec  9 16:17:56 2014
From: david.lloyd at redhat.com (David M. Lloyd)
Date: Tue, 09 Dec 2014 10:17:56 -0600
Subject: RFR JDK-8066867: Add InputStream transferTo to transfer content
	to an OutputStream
In-Reply-To: <ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>
References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com>
	<ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>
Message-ID: <548720B4.6090804@redhat.com>

On 12/09/2014 09:47 AM, Pavel Rappo wrote:
> Hi everyone,
>
> Could you please review my change for JDK-8066867?
>
> http://cr.openjdk.java.net/~prappo/8066867/webrev.00/

In the NIO version of this method, it accepts a 'long' parameter which 
indicates how many bytes should be transferred (similar to skip()).  Is 
there a reason not to do that here as well?

-- 
- DML


From patrick at reini.net  Tue Dec  9 16:25:11 2014
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 9 Dec 2014 17:25:11 +0100
Subject: RFR JDK-8066867: Add InputStream transferTo to transfer content
	to an OutputStream 
In-Reply-To: <ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>
References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com>
	<ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>
Message-ID: <25861DCC-C08B-40C3-A761-57413CF6D4C9@reini.net>

Hi Pavel,

1) ?transferred?  should be a long instead of int
2) I would extract the buffer size to a constant as in the NIO Files class

-Patrick

> Hi everyone,
> 
> Could you please review my change for JDK-8066867?
> 
> http://cr.openjdk.java.net/~prappo/8066867/webrev.00/
> 
> ---------------------------------------------------------------- 
> The task originated from discussion:
>  http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-November/029650.html



From chris.hegarty at oracle.com  Tue Dec  9 16:26:09 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 9 Dec 2014 16:26:09 +0000
Subject: RFR JDK-8066867: Add InputStream transferTo to transfer content
	to an OutputStream
In-Reply-To: <548720B4.6090804@redhat.com>
References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com>
	<ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>
	<548720B4.6090804@redhat.com>
Message-ID: <F429CF24-AF3C-410E-9E49-DE8C571EA3B7@oracle.com>

On 9 Dec 2014, at 16:17, David M. Lloyd <david.lloyd at redhat.com> wrote:

> On 12/09/2014 09:47 AM, Pavel Rappo wrote:
>> Hi everyone,
>> 
>> Could you please review my change for JDK-8066867?
>> 
>> http://cr.openjdk.java.net/~prappo/8066867/webrev.00/
> 
> In the NIO version of this method, it accepts a 'long' parameter which indicates how many bytes should be transferred (similar to skip()).  Is there a reason not to do that here as well?

This primary purpose of this method is to replace the boilerplate loop to read to EOF. There was a lengthly thread on this mailing list over the past week, or so, and the consensus has brought us to this API. My preference is to keep the API simple, and I think it covers intended use case.

-Chris. 

From martinrb at google.com  Tue Dec  9 16:49:58 2014
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 9 Dec 2014 08:49:58 -0800
Subject: RFR: 8065172: More core reflection final and volatile annotations
In-Reply-To: <112EA4F1-358F-4349-A6CC-B6C157996BD9@oracle.com>
References: <CA+kOe0_ek6UDjkOXEggp3JYo=ezxRqprLFUJxQb0v3Mnzj41JQ@mail.gmail.com>
	<546E09D6.9040800@gmail.com>
	<6B93C453-C558-4C0E-B7FA-4255507B154D@oracle.com>
	<54735081.5050201@gmail.com>
	<A1B7B5B4-9590-4155-8546-3117D47AD590@oracle.com>
	<CA+kOe0-AEf_1ZJ0rDziKo5cAStQSasdZ-eDeFGs+2Gqss1_uxA@mail.gmail.com>
	<4E57D36E-1D9A-4EB4-9130-B80730C35069@oracle.com>
	<CA+kOe0-Yv8ubBJEViJ0xJwm-89HXO1TmgFyiytq0AMjbv9zs8w@mail.gmail.com>
	<548616F2.2040803@gmail.com> <54861D93.9080105@gmail.com>
	<CA+kOe0_ktK4Ysv8NuaZAKy=5BWF303gBt0LdoTFNqWxA1sqd7Q@mail.gmail.com>
	<CA+kOe09CHFu=usJ9NmXByc_VMvO-_jfc=t_6sgsD5tS=Z96gDg@mail.gmail.com>
	<112EA4F1-358F-4349-A6CC-B6C157996BD9@oracle.com>
Message-ID: <CA+kOe0_E32geW6o68pbaTSwkX0awwWQWQVrgGd0ANejPhjArVg@mail.gmail.com>

Oops sorry - classic mistake of forgetting to hg qrefresh before publishing.

On Tue, Dec 9, 2014 at 3:23 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> On Dec 8, 2014, at 11:47 PM, Martin Buchholz <martinrb at google.com> wrote:
>> Webrev updated.
>
> Not quite sure how the webrev was updated:
>
>   http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/
>
> But the patch file
>
>   http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/core-reflection-more-safety.patch
>
> seems out of sync with the contents for each diff e.g:
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java.sdiff.html
>
> Do you observe the same?
>
>
>>  Field updaters are gone.  I intend to commit soon.
>>
>
> I went through the diffs individually and it seems fine but i don't have 100% confidence that the webrev has not been unintentionally mangled.
>
> Paul.


From martinrb at google.com  Tue Dec  9 17:06:24 2014
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 9 Dec 2014 09:06:24 -0800
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <54867FEC.2020802@oracle.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>
	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>
	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>
	<5481108A.3030605@oracle.com>
	<CA+kOe08OC57hEgGR-3CSfsJUMVSk-_mCmZK2Gd=3tpkE9=6j_w@mail.gmail.com>
	<5484D769.5030609@oracle.com>
	<CA+kOe0-UvzsMBC1FVv9C69tUwvbYgt5W4F5YvbzeDBtstQzFXg@mail.gmail.com>
	<54867FEC.2020802@oracle.com>
Message-ID: <CA+kOe09Pjg3WCziLmbdgcYHnmxv93M1aXKdsZBEL9Hue1pAuqg@mail.gmail.com>

On Mon, Dec 8, 2014 at 8:51 PM, David Holmes <david.holmes at oracle.com> wrote:

> Then please point me to the common industry definition of it because I
> couldn't find anything definitive. And as you state yourself above one
> definition of it - the corresponding C11 fence - does not in fact have the
> same semantics!

I changed to the terminology "acquire fence" and "release fence" as
popularized by preshing
http://preshing.com/20130922/acquire-and-release-fences/

     * Ensures that loads and stores before the fence will not be reordered with
     * stores after the fence; also referred to as a StoreStore plus LoadStore
     * barrier, or as a "release fence".


From martinrb at google.com  Tue Dec  9 18:15:03 2014
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 9 Dec 2014 10:15:03 -0800
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <54867C1F.1090106@oracle.com>
References: <CA+kOe0-kaVGdNyaLN2Yo0H4KnM1AU3N=nFryazZP1VbqK9t=Kw@mail.gmail.com>
	<NFBBKALFDCPFIDBNKAPCAEJJKLAA.davidcholmes@aapt.net.au>
	<CA+kOe09b_3-08pOt171PYedGoT0Bp5X1HOA7B+PHzCSRMkx6wQ@mail.gmail.com>
	<54867C1F.1090106@oracle.com>
Message-ID: <CA+kOe09aURqjRRk_gF8JtCAaJk+Fja8pTYmNY-B=DS7wuWXr1w@mail.gmail.com>

On Mon, Dec 8, 2014 at 8:35 PM, David Holmes <david.holmes at oracle.com> wrote:

>> So (as you say) with TSO you don't have a total order of stores if you
>> read your own writes out of your own CPU's write buffer.  However, my
>> interpretation of "multiple-copy atomic" is that the initial
>> publishing thread can choose to use an instruction with sufficiently
>> strong memory barrier attached (e.g. LOCK;XXX on x86) to write to
>> memory so that the write buffer is flushed and then use plain relaxed
>> loads everywhere else to read those memory locations and this explains
>> the situation on x86 and sparc where volatile writes are expensive and
>> volatile reads are "free" and you get sequential consistency for Java
>> volatiles.
>
>
> We don't use lock'd instructions for volatile stores on x86, but the
> trailing mfence achieves the "flushing".
>
> However this still raised some questions for me. Using a mfence on x86 or
> equivalent on sparc, is no different to issuing a "DMB SYNC" on ARM, or a
> SYNC on PowerPC. They each ensure TSO for volatile stores with global
> visibility. So when such fences are used the resulting system should be
> multiple-copy atomic - no? (No!**) And there seems to be an equivalence
> between being multiple-copy atomic and providing the IRIW property. Yet we
> know that on ARM/Power, as per the paper, TSO with global visibility is not

ARM/Power don't have TSO.

> sufficient to achieve IRIW. So what is it that x86 and sparc have in
> addition to TSO that provides for IRIW?

We have both been learning.... to think in new ways.
 I found the second section of Peter Sewell's tutorial
2 From Sequential Consistency to Relaxed Memory Models
to be most useful, especially the diagrams.

> I pondered this for quite a while before realizing that the mfence on x86
> (or equivalent on sparc) is not in fact playing the same role as the
> DMB/SYNC on ARM/PPC. The key property that x86 and sparc have (and we can
> ignore the store buffers) is that stores become globally visible - if any
> other thread sees a store then all other threads see the same store. Whereas
> on ARM/PPC you can imagine a store casually making its way through the
> system, gradually becoming visible to more and more threads - unless there
> is a DMB/SYNC to force a globally consistent memory view. Hence for IRIW
> placing the DMB/SYNC after the store does not suffice because prior to the
> DMB/SYNC the store may be visible to an arbitrary subset of threads.
> Consequently IRIW requires the DMB/SYNC between the loads - to ensure that
> each thread on their second load, must see the value that the other thread
> saw on its first load (ref Section 6.1 of the paper).
>
> ** So using DMB/SYNC does not achieve multiple-copy atomicity, because until
> the DMB/SYNC happens different threads can have different views of memory.

To me, the most desirable property of x86-style TSO is that barriers
are only necessary on stores to achieve sequential consistency - the
publisher gets to decide.  Volatile reads can then be close to free.

> All of which reinforces to me that IRIW is an undesirable property to have
> to implement. YMMV. (And I also need to re-examine the PPC64 implementation
> to see exactly where they add/remove barriers when IRIW is enabled.)

I believe you get a full sync between volatile reads.

#define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
  oop p = JNIHandles::resolve(obj); \
  if (support_IRIW_for_not_multiple_copy_atomic_cpu) { \
    OrderAccess::fence(); \
  } \


> Cheers,
> David
>
>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf


From joel.franck at oracle.com  Tue Dec  9 18:25:19 2014
From: joel.franck at oracle.com (=?utf-8?Q?Joel_Borggr=C3=A9n-Franck?=)
Date: Tue, 9 Dec 2014 19:25:19 +0100
Subject: RFR: 8065172: More core reflection final and volatile annotations
In-Reply-To: <CA+kOe0_E32geW6o68pbaTSwkX0awwWQWQVrgGd0ANejPhjArVg@mail.gmail.com>
References: <CA+kOe0_ek6UDjkOXEggp3JYo=ezxRqprLFUJxQb0v3Mnzj41JQ@mail.gmail.com>
	<546E09D6.9040800@gmail.com>
	<6B93C453-C558-4C0E-B7FA-4255507B154D@oracle.com>
	<54735081.5050201@gmail.com>
	<A1B7B5B4-9590-4155-8546-3117D47AD590@oracle.com>
	<CA+kOe0-AEf_1ZJ0rDziKo5cAStQSasdZ-eDeFGs+2Gqss1_uxA@mail.gmail.com>
	<4E57D36E-1D9A-4EB4-9130-B80730C35069@oracle.com>
	<CA+kOe0-Yv8ubBJEViJ0xJwm-89HXO1TmgFyiytq0AMjbv9zs8w@mail.gmail.com>
	<548616F2.2040803@gmail.com> <54861D93.9080105@gmail.com>
	<CA+kOe0_ktK4Ysv8NuaZAKy=5BWF303gBt0LdoTFNqWxA1sqd7Q@mail.gmail.com>
	<CA+kOe09CHFu=usJ9NmXByc_VMvO-_jfc=t_6sgsD5tS=Z96gDg@mail.gmail.com>
	<112EA4F1-358F-4349-A6CC-B6C157996BD9@oracle.com>
	<CA+kOe0_E32geW6o68pbaTSwkX0awwWQWQVrgGd0ANejPhjArVg@mail.gmail.com>
Message-ID: <8C077FBA-2D29-4A7A-B8A1-189D45F6CC60@oracle.com>

Hi Martin,

Looks good. I also think the code is easier to read now.

Thanks for switching back to a version with racy but correct initialization. As Peter wrote, there are many cases where we don?t guarantee == on Type instances. I can see why that would be desirable, but that is a separate discussion (and also "very hard" to accomplish given todays design).

Thanks for taking fixing this.

cheers
/Joel

> On 9 dec 2014, at 17:49, Martin Buchholz <martinrb at google.com> wrote:
> 
> Oops sorry - classic mistake of forgetting to hg qrefresh before publishing.
> 
> On Tue, Dec 9, 2014 at 3:23 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>> On Dec 8, 2014, at 11:47 PM, Martin Buchholz <martinrb at google.com> wrote:
>>> Webrev updated.
>> 
>> Not quite sure how the webrev was updated:
>> 
>>  http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/
>> 
>> But the patch file
>> 
>>  http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/core-reflection-more-safety.patch
>> 
>> seems out of sync with the contents for each diff e.g:
>> 
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/core-reflection-more-safety/src/java.base/share/classes/sun/reflect/annotation/AnnotationInvocationHandler.java.sdiff.html
>> 
>> Do you observe the same?
>> 
>> 
>>> Field updaters are gone.  I intend to commit soon.
>>> 
>> 
>> I went through the diffs individually and it seems fine but i don't have 100% confidence that the webrev has not been unintentionally mangled.
>> 
>> Paul.



From oleksandr.otenko at oracle.com  Tue Dec  9 20:04:16 2014
From: oleksandr.otenko at oracle.com (Oleksandr Otenko)
Date: Tue, 09 Dec 2014 20:04:16 +0000
Subject: [concurrency-interest] RFR: 8065804:
	JEP171:Clarifications/corrections for fence intrinsics
In-Reply-To: <CAPUmR1YdWyemKveLA0eHpv_MC=5BjVJtfLkj2RTZAhz_NFivog@mail.gmail.com>
References: <2458774.qkf0xEMZGz@d-allen>	<NFBBKALFDCPFIDBNKAPCAECMKLAA.davidcholmes@aapt.net.au>
	<CAPUmR1YdWyemKveLA0eHpv_MC=5BjVJtfLkj2RTZAhz_NFivog@mail.gmail.com>
Message-ID: <548755C0.5040104@oracle.com>

On 26/11/2014 02:04, Hans Boehm wrote:
> To be concrete here, on Power, loads can normally be ordered by an 
> address dependency or light-weight fence (lwsync).  However, neither 
> is enough to prevent the questionable outcome for IRIW, since it 
> doesn't ensure that the stores in T1 and T2 will be made visible to 
> other threads in a consistent order.  That outcome can be prevented by 
> using heavyweight fences (sync) instructions between the loads instead.

Why would they need fences between loads instead of syncing the order of 
stores?


Alex


> Peter Sewell's group concluded that to enforce correct volatile 
> behavior on Power, you essentially need a a heavyweight fence between 
> every pair of volatile operations on Power.  That cannot be understood 
> based on simple ordering constraints.
>
> As Stephan pointed out, there are similar issues on ARM, but they're 
> less commonly encountered in a Java implementation.  If you're lucky, 
> you can get to the right implementation recipe by looking at only 
> reordering, I think.
>
>
> On Tue, Nov 25, 2014 at 4:36 PM, David Holmes 
> <davidcholmes at aapt.net.au <mailto:davidcholmes at aapt.net.au>> wrote:
>
>     Stephan Diestelhorst writes:
>     >
>     > David Holmes wrote:
>     > > Stephan Diestelhorst writes:
>     > > > Am Dienstag, 25. November 2014, 11:15:36 schrieb Hans Boehm:
>     > > > > I'm no hardware architect, but fundamentally it seems to
>     me that
>     > > > >
>     > > > > load x
>     > > > > acquire_fence
>     > > > >
>     > > > > imposes a much more stringent constraint than
>     > > > >
>     > > > > load_acquire x
>     > > > >
>     > > > > Consider the case in which the load from x is an L1 hit, but a
>     > > > > preceding load (from say y) is a long-latency miss.  If we
>     enforce
>     > > > > ordering by just waiting for completion of prior
>     operation, the
>     > > > > former has to wait for the load from y to complete; while the
>     > > > > latter doesn't.  I find it hard to believe that this
>     doesn't leave
>     > > > > an appreciable amount of performance on the table, at
>     least for
>     > > > > some interesting microarchitectures.
>     > > >
>     > > > I agree, Hans, that this is a reasonable assumption. 
>     Load_acquire x
>     > > > does allow roach motel, whereas the acquire fence does not.
>     > > >
>     > > > >  In addition, for better or worse, fencing requirements on
>     at least
>     > > > >  Power are actually driven as much by store atomicity
>     issues, as by
>     > > > >  the ordering issues discussed in the cookbook.  This was not
>     > > > >  understood in 2005, and unfortunately doesn't seem to be
>     > amenable to
>     > > > >  the kind of straightforward explanation as in Doug's
>     cookbook.
>     > > >
>     > > > Coming from a strongly ordered architecture to a weakly
>     ordered one
>     > > > myself, I also needed some mental adjustment about store
>     (multi-copy)
>     > > > atomicity.  I can imagine others will be unaware of this
>     difference,
>     > > > too, even in 2014.
>     > >
>     > > Sorry I'm missing the connection between fences and multi-copy
>     > atomicity.
>     >
>     > One example is the classic IRIW.  With non-multi copy atomic
>     stores, but
>     > ordered (say through a dependency) loads in the following example:
>     >
>     > Memory: foo = bar = 0
>     > _T1_         _T2_         _T3_         _T4_
>     > st (foo),1   st (bar),1   ld r1, (bar)         ld r3,(foo)
>     >                           <addr dep / local "fence" here> 
>      <addr dep>
>     >                           ld r2, (foo)         ld r4, (bar)
>     >
>     > You may observe r1 = 1, r2 = 0, r3 = 1, r4 = 0 on non-multi-copy
>     atomic
>     > machines.  On TSO boxes, this is not possible. That means that the
>     > memory fence that will prevent such a behaviour (DMB on ARM)
>     needs to
>     > carry some additional oomph in ensuring multi-copy atomicity, or
>     rather
>     > prevent you from seeing it (which is the same thing).
>
>     I take it as given that any code for which you may have ordering
>     constraints, must first have basic atomicity properties for loads and
>     stores. I would not expect any kind of fence to add
>     multi-copy-atomicity
>     where there was none.
>
>     David
>
>     > Stephan
>     >
>     > _______________________________________________
>     > Concurrency-interest mailing list
>     > Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>     _______________________________________________
>     Concurrency-interest mailing list
>     Concurrency-interest at cs.oswego.edu
>     <mailto:Concurrency-interest at cs.oswego.edu>
>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



From martinrb at google.com  Tue Dec  9 20:23:17 2014
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 9 Dec 2014 12:23:17 -0800
Subject: [concurrency-interest] RFR: 8065804:
	JEP171:Clarifications/corrections for fence intrinsics
In-Reply-To: <548755C0.5040104@oracle.com>
References: <2458774.qkf0xEMZGz@d-allen>
	<NFBBKALFDCPFIDBNKAPCAECMKLAA.davidcholmes@aapt.net.au>
	<CAPUmR1YdWyemKveLA0eHpv_MC=5BjVJtfLkj2RTZAhz_NFivog@mail.gmail.com>
	<548755C0.5040104@oracle.com>
Message-ID: <CA+kOe09GDM61sqfyZ6CPmP=ptc1d7siJcxnteinz8_xN2WvDFg@mail.gmail.com>

On Tue, Dec 9, 2014 at 12:04 PM, Oleksandr Otenko
<oleksandr.otenko at oracle.com> wrote:
> On 26/11/2014 02:04, Hans Boehm wrote:
>>
>> To be concrete here, on Power, loads can normally be ordered by an address
>> dependency or light-weight fence (lwsync).  However, neither is enough to
>> prevent the questionable outcome for IRIW, since it doesn't ensure that the
>> stores in T1 and T2 will be made visible to other threads in a consistent
>> order.  That outcome can be prevented by using heavyweight fences (sync)
>> instructions between the loads instead.
>
>
> Why would they need fences between loads instead of syncing the order of
> stores?

Well explained by
http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf


From oleksandr.otenko at oracle.com  Tue Dec  9 20:34:25 2014
From: oleksandr.otenko at oracle.com (Oleksandr Otenko)
Date: Tue, 09 Dec 2014 20:34:25 +0000
Subject: [concurrency-interest] RFR: 8065804:
	JEP171:Clarifications/corrections for fence intrinsics
In-Reply-To: <NFBBKALFDCPFIDBNKAPCIECMKLAA.davidcholmes@aapt.net.au>
References: <NFBBKALFDCPFIDBNKAPCIECMKLAA.davidcholmes@aapt.net.au>
Message-ID: <54875CD1.4010801@oracle.com>

Is the thorn the many allowed outcomes, or the single disallowed 
outcome? (eg order consistency is too strict for stores with no 
synchronizes-with between them?)

Alex


On 26/11/2014 02:10, David Holmes wrote:
> Hi Hans,
> Given IRIW is a thorn in everyone's side and has no known useful 
> benefit, and can hopefully be killed off in the future, lets not get 
> bogged down in IRIW. But none of what you say below relates to 
> multi-copy-atomicity.
> Cheers,
> David
>
>     -----Original Message-----
>     *From:* hjkhboehm at gmail.com [mailto:hjkhboehm at gmail.com]*On Behalf
>     Of *Hans Boehm
>     *Sent:* Wednesday, 26 November 2014 12:04 PM
>     *To:* dholmes at ieee.org
>     *Cc:* Stephan Diestelhorst; concurrency-interest at cs.oswego.edu;
>     core-libs-dev
>     *Subject:* Re: [concurrency-interest] RFR: 8065804:
>     JEP171:Clarifications/corrections for fence intrinsics
>
>     To be concrete here, on Power, loads can normally be ordered by an
>     address dependency or light-weight fence (lwsync).  However,
>     neither is enough to prevent the questionable outcome for IRIW,
>     since it doesn't ensure that the stores in T1 and T2 will be made
>     visible to other threads in a consistent order.  That outcome can
>     be prevented by using heavyweight fences (sync) instructions
>     between the loads instead.  Peter Sewell's group concluded that to
>     enforce correct volatile behavior on Power, you essentially need a
>     a heavyweight fence between every pair of volatile operations on
>     Power.  That cannot be understood based on simple ordering
>     constraints.
>
>     As Stephan pointed out, there are similar issues on ARM, but
>     they're less commonly encountered in a Java implementation.  If
>     you're lucky, you can get to the right implementation recipe by
>     looking at only reordering, I think.
>
>
>     On Tue, Nov 25, 2014 at 4:36 PM, David Holmes
>     <davidcholmes at aapt.net.au <mailto:davidcholmes at aapt.net.au>> wrote:
>
>         Stephan Diestelhorst writes:
>         >
>         > David Holmes wrote:
>         > > Stephan Diestelhorst writes:
>         > > > Am Dienstag, 25. November 2014, 11:15:36 schrieb Hans Boehm:
>         > > > > I'm no hardware architect, but fundamentally it seems
>         to me that
>         > > > >
>         > > > > load x
>         > > > > acquire_fence
>         > > > >
>         > > > > imposes a much more stringent constraint than
>         > > > >
>         > > > > load_acquire x
>         > > > >
>         > > > > Consider the case in which the load from x is an L1
>         hit, but a
>         > > > > preceding load (from say y) is a long-latency miss. 
>         If we enforce
>         > > > > ordering by just waiting for completion of prior
>         operation, the
>         > > > > former has to wait for the load from y to complete;
>         while the
>         > > > > latter doesn't.  I find it hard to believe that this
>         doesn't leave
>         > > > > an appreciable amount of performance on the table, at
>         least for
>         > > > > some interesting microarchitectures.
>         > > >
>         > > > I agree, Hans, that this is a reasonable assumption. 
>         Load_acquire x
>         > > > does allow roach motel, whereas the acquire fence does not.
>         > > >
>         > > > >  In addition, for better or worse, fencing
>         requirements on at least
>         > > > >  Power are actually driven as much by store atomicity
>         issues, as by
>         > > > >  the ordering issues discussed in the cookbook.  This
>         was not
>         > > > >  understood in 2005, and unfortunately doesn't seem to be
>         > amenable to
>         > > > >  the kind of straightforward explanation as in Doug's
>         cookbook.
>         > > >
>         > > > Coming from a strongly ordered architecture to a weakly
>         ordered one
>         > > > myself, I also needed some mental adjustment about store
>         (multi-copy)
>         > > > atomicity.  I can imagine others will be unaware of this
>         difference,
>         > > > too, even in 2014.
>         > >
>         > > Sorry I'm missing the connection between fences and multi-copy
>         > atomicity.
>         >
>         > One example is the classic IRIW.  With non-multi copy atomic
>         stores, but
>         > ordered (say through a dependency) loads in the following
>         example:
>         >
>         > Memory: foo = bar = 0
>         > _T1_         _T2_         _T3_           _T4_
>         > st (foo),1   st (bar),1   ld r1, (bar)           ld r3,(foo)
>         >                           <addr dep / local "fence" here> 
>          <addr dep>
>         >                           ld r2, (foo)           ld r4, (bar)
>         >
>         > You may observe r1 = 1, r2 = 0, r3 = 1, r4 = 0 on
>         non-multi-copy atomic
>         > machines.  On TSO boxes, this is not possible. That means
>         that the
>         > memory fence that will prevent such a behaviour (DMB on ARM)
>         needs to
>         > carry some additional oomph in ensuring multi-copy
>         atomicity, or rather
>         > prevent you from seeing it (which is the same thing).
>
>         I take it as given that any code for which you may have ordering
>         constraints, must first have basic atomicity properties for
>         loads and
>         stores. I would not expect any kind of fence to add
>         multi-copy-atomicity
>         where there was none.
>
>         David
>
>         > Stephan
>         >
>         > _______________________________________________
>         > Concurrency-interest mailing list
>         > Concurrency-interest at cs.oswego.edu
>         <mailto:Concurrency-interest at cs.oswego.edu>
>         > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>         _______________________________________________
>         Concurrency-interest mailing list
>         Concurrency-interest at cs.oswego.edu
>         <mailto:Concurrency-interest at cs.oswego.edu>
>         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



From davidcholmes at aapt.net.au  Tue Dec  9 21:36:30 2014
From: davidcholmes at aapt.net.au (David Holmes)
Date: Wed, 10 Dec 2014 07:36:30 +1000
Subject: [concurrency-interest] RFR: 8065804:
	JEP171:Clarifications/corrections for fence intrinsics
In-Reply-To: <54875CD1.4010801@oracle.com>
Message-ID: <NFBBKALFDCPFIDBNKAPCKEKDKLAA.davidcholmes@aapt.net.au>

The "thorn" is the need for the barriers in the readers not the writers. (or
perhaps as well as the writers in some cases - that is part of the problem.)

David
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Oleksandr
Otenko
  Sent: Wednesday, 10 December 2014 6:34 AM
  To: dholmes at ieee.org; Hans Boehm
  Cc: core-libs-dev; concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] RFR: 8065804:
JEP171:Clarifications/corrections for fence intrinsics


  Is the thorn the many allowed outcomes, or the single disallowed outcome?
(eg order consistency is too strict for stores with no synchronizes-with
between them?)

  Alex



  On 26/11/2014 02:10, David Holmes wrote:

    Hi Hans,
    Given IRIW is a thorn in everyone's side and has no known useful
benefit, and can hopefully be killed off in the future, lets not get bogged
down in IRIW. But none of what you say below relates to
multi-copy-atomicity.

    Cheers,
    David
      -----Original Message-----
      From: hjkhboehm at gmail.com [mailto:hjkhboehm at gmail.com]On Behalf Of
Hans Boehm
      Sent: Wednesday, 26 November 2014 12:04 PM
      To: dholmes at ieee.org
      Cc: Stephan Diestelhorst; concurrency-interest at cs.oswego.edu;
core-libs-dev
      Subject: Re: [concurrency-interest] RFR: 8065804:
JEP171:Clarifications/corrections for fence intrinsics


      To be concrete here, on Power, loads can normally be ordered by an
address dependency or light-weight fence (lwsync).  However, neither is
enough to prevent the questionable outcome for IRIW, since it doesn't ensure
that the stores in T1 and T2 will be made visible to other threads in a
consistent order.  That outcome can be prevented by using heavyweight fences
(sync) instructions between the loads instead.  Peter Sewell's group
concluded that to enforce correct volatile behavior on Power, you
essentially need a a heavyweight fence between every pair of volatile
operations on Power.  That cannot be understood based on simple ordering
constraints.


      As Stephan pointed out, there are similar issues on ARM, but they're
less commonly encountered in a Java implementation.  If you're lucky, you
can get to the right implementation recipe by looking at only reordering, I
think.




      On Tue, Nov 25, 2014 at 4:36 PM, David Holmes
<davidcholmes at aapt.net.au> wrote:

        Stephan Diestelhorst writes:
        >
        > David Holmes wrote:
        > > Stephan Diestelhorst writes:
        > > > Am Dienstag, 25. November 2014, 11:15:36 schrieb Hans Boehm:
        > > > > I'm no hardware architect, but fundamentally it seems to me
that
        > > > >
        > > > > load x
        > > > > acquire_fence
        > > > >
        > > > > imposes a much more stringent constraint than
        > > > >
        > > > > load_acquire x
        > > > >
        > > > > Consider the case in which the load from x is an L1 hit, but
a
        > > > > preceding load (from say y) is a long-latency miss.  If we
enforce
        > > > > ordering by just waiting for completion of prior operation,
the
        > > > > former has to wait for the load from y to complete; while
the
        > > > > latter doesn't.  I find it hard to believe that this doesn't
leave
        > > > > an appreciable amount of performance on the table, at least
for
        > > > > some interesting microarchitectures.
        > > >
        > > > I agree, Hans, that this is a reasonable assumption.
Load_acquire x
        > > > does allow roach motel, whereas the acquire fence does not.
        > > >
        > > > >  In addition, for better or worse, fencing requirements on
at least
        > > > >  Power are actually driven as much by store atomicity
issues, as by
        > > > >  the ordering issues discussed in the cookbook.  This was
not
        > > > >  understood in 2005, and unfortunately doesn't seem to be
        > amenable to
        > > > >  the kind of straightforward explanation as in Doug's
cookbook.
        > > >
        > > > Coming from a strongly ordered architecture to a weakly
ordered one
        > > > myself, I also needed some mental adjustment about store
(multi-copy)
        > > > atomicity.  I can imagine others will be unaware of this
difference,
        > > > too, even in 2014.
        > >
        > > Sorry I'm missing the connection between fences and multi-copy
        > atomicity.
        >
        > One example is the classic IRIW.  With non-multi copy atomic
stores, but
        > ordered (say through a dependency) loads in the following example:
        >
        > Memory: foo = bar = 0
        > _T1_         _T2_         _T3_                              _T4_
        > st (foo),1   st (bar),1   ld r1, (bar)                      ld
r3,(foo)
        >                           <addr dep / local "fence" here>   <addr
dep>
        >                           ld r2, (foo)                      ld r4,
(bar)
        >
        > You may observe r1 = 1, r2 = 0, r3 = 1, r4 = 0 on non-multi-copy
atomic
        > machines.  On TSO boxes, this is not possible.  That means that
the
        > memory fence that will prevent such a behaviour (DMB on ARM) needs
to
        > carry some additional oomph in ensuring multi-copy atomicity, or
rather
        > prevent you from seeing it (which is the same thing).


        I take it as given that any code for which you may have ordering
        constraints, must first have basic atomicity properties for loads
and
        stores. I would not expect any kind of fence to add
multi-copy-atomicity
        where there was none.

        David


        > Stephan
        >
        > _______________________________________________
        > Concurrency-interest mailing list
        > Concurrency-interest at cs.oswego.edu
        > http://cs.oswego.edu/mailman/listinfo/concurrency-interest

        _______________________________________________
        Concurrency-interest mailing list
        Concurrency-interest at cs.oswego.edu
        http://cs.oswego.edu/mailman/listinfo/concurrency-interest






_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



From davidcholmes at aapt.net.au  Tue Dec  9 21:37:55 2014
From: davidcholmes at aapt.net.au (David Holmes)
Date: Wed, 10 Dec 2014 07:37:55 +1000
Subject: [concurrency-interest] RFR: 8065804:
	JEP171:Clarifications/corrections for fence intrinsics
In-Reply-To: <548755C0.5040104@oracle.com>
Message-ID: <NFBBKALFDCPFIDBNKAPCOEKDKLAA.davidcholmes@aapt.net.au>

See my earlier response to Martin. The reader has to force a consistent view
of memory - the writer can't as the write escapes before it can issue the
barrier.

David
  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Oleksandr
Otenko
  Sent: Wednesday, 10 December 2014 6:04 AM
  To: Hans Boehm; dholmes at ieee.org
  Cc: core-libs-dev; concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] RFR: 8065804:
JEP171:Clarifications/corrections for fence intrinsics


  On 26/11/2014 02:04, Hans Boehm wrote:

    To be concrete here, on Power, loads can normally be ordered by an
address dependency or light-weight fence (lwsync).  However, neither is
enough to prevent the questionable outcome for IRIW, since it doesn't ensure
that the stores in T1 and T2 will be made visible to other threads in a
consistent order.  That outcome can be prevented by using heavyweight fences
(sync) instructions between the loads instead.


  Why would they need fences between loads instead of syncing the order of
stores?


  Alex



    Peter Sewell's group concluded that to enforce correct volatile behavior
on Power, you essentially need a a heavyweight fence between every pair of
volatile operations on Power.  That cannot be understood based on simple
ordering constraints.


    As Stephan pointed out, there are similar issues on ARM, but they're
less commonly encountered in a Java implementation.  If you're lucky, you
can get to the right implementation recipe by looking at only reordering, I
think.




    On Tue, Nov 25, 2014 at 4:36 PM, David Holmes <davidcholmes at aapt.net.au>
wrote:

      Stephan Diestelhorst writes:
      >
      > David Holmes wrote:
      > > Stephan Diestelhorst writes:
      > > > Am Dienstag, 25. November 2014, 11:15:36 schrieb Hans Boehm:
      > > > > I'm no hardware architect, but fundamentally it seems to me
that
      > > > >
      > > > > load x
      > > > > acquire_fence
      > > > >
      > > > > imposes a much more stringent constraint than
      > > > >
      > > > > load_acquire x
      > > > >
      > > > > Consider the case in which the load from x is an L1 hit, but a
      > > > > preceding load (from say y) is a long-latency miss.  If we
enforce
      > > > > ordering by just waiting for completion of prior operation,
the
      > > > > former has to wait for the load from y to complete; while the
      > > > > latter doesn't.  I find it hard to believe that this doesn't
leave
      > > > > an appreciable amount of performance on the table, at least
for
      > > > > some interesting microarchitectures.
      > > >
      > > > I agree, Hans, that this is a reasonable assumption.
Load_acquire x
      > > > does allow roach motel, whereas the acquire fence does not.
      > > >
      > > > >  In addition, for better or worse, fencing requirements on at
least
      > > > >  Power are actually driven as much by store atomicity issues,
as by
      > > > >  the ordering issues discussed in the cookbook.  This was not
      > > > >  understood in 2005, and unfortunately doesn't seem to be
      > amenable to
      > > > >  the kind of straightforward explanation as in Doug's
cookbook.
      > > >
      > > > Coming from a strongly ordered architecture to a weakly ordered
one
      > > > myself, I also needed some mental adjustment about store
(multi-copy)
      > > > atomicity.  I can imagine others will be unaware of this
difference,
      > > > too, even in 2014.
      > >
      > > Sorry I'm missing the connection between fences and multi-copy
      > atomicity.
      >
      > One example is the classic IRIW.  With non-multi copy atomic stores,
but
      > ordered (say through a dependency) loads in the following example:
      >
      > Memory: foo = bar = 0
      > _T1_         _T2_         _T3_                              _T4_
      > st (foo),1   st (bar),1   ld r1, (bar)                      ld
r3,(foo)
      >                           <addr dep / local "fence" here>   <addr
dep>
      >                           ld r2, (foo)                      ld r4,
(bar)
      >
      > You may observe r1 = 1, r2 = 0, r3 = 1, r4 = 0 on non-multi-copy
atomic
      > machines.  On TSO boxes, this is not possible.  That means that the
      > memory fence that will prevent such a behaviour (DMB on ARM) needs
to
      > carry some additional oomph in ensuring multi-copy atomicity, or
rather
      > prevent you from seeing it (which is the same thing).


      I take it as given that any code for which you may have ordering
      constraints, must first have basic atomicity properties for loads and
      stores. I would not expect any kind of fence to add
multi-copy-atomicity
      where there was none.

      David


      > Stephan
      >
      > _______________________________________________
      > Concurrency-interest mailing list
      > Concurrency-interest at cs.oswego.edu
      > http://cs.oswego.edu/mailman/listinfo/concurrency-interest

      _______________________________________________
      Concurrency-interest mailing list
      Concurrency-interest at cs.oswego.edu
      http://cs.oswego.edu/mailman/listinfo/concurrency-interest






_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



From oleksandr.otenko at oracle.com  Tue Dec  9 21:53:32 2014
From: oleksandr.otenko at oracle.com (Oleksandr Otenko)
Date: Tue, 09 Dec 2014 21:53:32 +0000
Subject: [concurrency-interest] RFR: 8065804:
	JEP171:Clarifications/corrections for fence intrinsics
In-Reply-To: <NFBBKALFDCPFIDBNKAPCOEKDKLAA.davidcholmes@aapt.net.au>
References: <NFBBKALFDCPFIDBNKAPCOEKDKLAA.davidcholmes@aapt.net.au>
Message-ID: <54876F5C.5070800@oracle.com>

Yes, I do understand the reader needs barriers, too. I guess I was 
wondering more why the reader would need something stronger than what 
dependencies etc could enforce. I guess I'll read what Martin forwarded 
first.

Alex


On 09/12/2014 21:37, David Holmes wrote:
> See my earlier response to Martin. The reader has to force a 
> consistent view of memory - the writer can't as the write escapes 
> before it can issue the barrier.
> David
>
>     -----Original Message-----
>     *From:* concurrency-interest-bounces at cs.oswego.edu
>     [mailto:concurrency-interest-bounces at cs.oswego.edu]*On Behalf Of
>     *Oleksandr Otenko
>     *Sent:* Wednesday, 10 December 2014 6:04 AM
>     *To:* Hans Boehm; dholmes at ieee.org
>     *Cc:* core-libs-dev; concurrency-interest at cs.oswego.edu
>     *Subject:* Re: [concurrency-interest] RFR: 8065804:
>     JEP171:Clarifications/corrections for fence intrinsics
>
>     On 26/11/2014 02:04, Hans Boehm wrote:
>>     To be concrete here, on Power, loads can normally be ordered by
>>     an address dependency or light-weight fence (lwsync).  However,
>>     neither is enough to prevent the questionable outcome for IRIW,
>>     since it doesn't ensure that the stores in T1 and T2 will be made
>>     visible to other threads in a consistent order.  That outcome can
>>     be prevented by using heavyweight fences (sync) instructions
>>     between the loads instead.
>
>     Why would they need fences between loads instead of syncing the
>     order of stores?
>
>
>     Alex
>
>
>>     Peter Sewell's group concluded that to enforce correct volatile
>>     behavior on Power, you essentially need a a heavyweight fence
>>     between every pair of volatile operations on Power.  That cannot
>>     be understood based on simple ordering constraints.
>>
>>     As Stephan pointed out, there are similar issues on ARM, but
>>     they're less commonly encountered in a Java implementation.  If
>>     you're lucky, you can get to the right implementation recipe by
>>     looking at only reordering, I think.
>>
>>
>>     On Tue, Nov 25, 2014 at 4:36 PM, David Holmes
>>     <davidcholmes at aapt.net.au <mailto:davidcholmes at aapt.net.au>> wrote:
>>
>>         Stephan Diestelhorst writes:
>>         >
>>         > David Holmes wrote:
>>         > > Stephan Diestelhorst writes:
>>         > > > Am Dienstag, 25. November 2014, 11:15:36 schrieb Hans
>>         Boehm:
>>         > > > > I'm no hardware architect, but fundamentally it seems
>>         to me that
>>         > > > >
>>         > > > > load x
>>         > > > > acquire_fence
>>         > > > >
>>         > > > > imposes a much more stringent constraint than
>>         > > > >
>>         > > > > load_acquire x
>>         > > > >
>>         > > > > Consider the case in which the load from x is an L1
>>         hit, but a
>>         > > > > preceding load (from say y) is a long-latency miss. 
>>         If we enforce
>>         > > > > ordering by just waiting for completion of prior
>>         operation, the
>>         > > > > former has to wait for the load from y to complete;
>>         while the
>>         > > > > latter doesn't.  I find it hard to believe that this
>>         doesn't leave
>>         > > > > an appreciable amount of performance on the table, at
>>         least for
>>         > > > > some interesting microarchitectures.
>>         > > >
>>         > > > I agree, Hans, that this is a reasonable assumption. 
>>         Load_acquire x
>>         > > > does allow roach motel, whereas the acquire fence does not.
>>         > > >
>>         > > > >  In addition, for better or worse, fencing
>>         requirements on at least
>>         > > > >  Power are actually driven as much by store atomicity
>>         issues, as by
>>         > > > >  the ordering issues discussed in the cookbook.  This
>>         was not
>>         > > > >  understood in 2005, and unfortunately doesn't seem to be
>>         > amenable to
>>         > > > >  the kind of straightforward explanation as in Doug's
>>         cookbook.
>>         > > >
>>         > > > Coming from a strongly ordered architecture to a weakly
>>         ordered one
>>         > > > myself, I also needed some mental adjustment about
>>         store (multi-copy)
>>         > > > atomicity.  I can imagine others will be unaware of
>>         this difference,
>>         > > > too, even in 2014.
>>         > >
>>         > > Sorry I'm missing the connection between fences and
>>         multi-copy
>>         > atomicity.
>>         >
>>         > One example is the classic IRIW.  With non-multi copy
>>         atomic stores, but
>>         > ordered (say through a dependency) loads in the following
>>         example:
>>         >
>>         > Memory: foo = bar = 0
>>         > _T1_         _T2_         _T3_             _T4_
>>         > st (foo),1   st (bar),1   ld r1, (bar)             ld r3,(foo)
>>         >                           <addr dep / local "fence" here> 
>>          <addr dep>
>>         >                           ld r2, (foo)             ld r4, (bar)
>>         >
>>         > You may observe r1 = 1, r2 = 0, r3 = 1, r4 = 0 on
>>         non-multi-copy atomic
>>         > machines.  On TSO boxes, this is not possible. That means
>>         that the
>>         > memory fence that will prevent such a behaviour (DMB on
>>         ARM) needs to
>>         > carry some additional oomph in ensuring multi-copy
>>         atomicity, or rather
>>         > prevent you from seeing it (which is the same thing).
>>
>>         I take it as given that any code for which you may have ordering
>>         constraints, must first have basic atomicity properties for
>>         loads and
>>         stores. I would not expect any kind of fence to add
>>         multi-copy-atomicity
>>         where there was none.
>>
>>         David
>>
>>         > Stephan
>>         >
>>         > _______________________________________________
>>         > Concurrency-interest mailing list
>>         > Concurrency-interest at cs.oswego.edu
>>         <mailto:Concurrency-interest at cs.oswego.edu>
>>         > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>         _______________________________________________
>>         Concurrency-interest mailing list
>>         Concurrency-interest at cs.oswego.edu
>>         <mailto:Concurrency-interest at cs.oswego.edu>
>>         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>>
>>
>>     _______________________________________________
>>     Concurrency-interest mailing list
>>     Concurrency-interest at cs.oswego.edu
>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



From davidcholmes at aapt.net.au  Tue Dec  9 21:59:11 2014
From: davidcholmes at aapt.net.au (David Holmes)
Date: Wed, 10 Dec 2014 07:59:11 +1000
Subject: [concurrency-interest] RFR: 8065804:
	JEP171:Clarifications/corrections for fence intrinsics
In-Reply-To: <54876F5C.5070800@oracle.com>
Message-ID: <NFBBKALFDCPFIDBNKAPCKEKEKLAA.davidcholmes@aapt.net.au>

In this case the issue is not ordering per-se (which is what dependencies
help with) but global visibility. After performing the first read each
thread must ensure that its second read will return what the other thread
saw for the first read - hence a full dmb/sync between the reads; or
generalizing a full dmb/sync after every volatile read.

David
  -----Original Message-----
  From: Oleksandr Otenko [mailto:oleksandr.otenko at oracle.com]
  Sent: Wednesday, 10 December 2014 7:54 AM
  To: dholmes at ieee.org; Hans Boehm
  Cc: core-libs-dev; concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] RFR: 8065804:
JEP171:Clarifications/corrections for fence intrinsics


  Yes, I do understand the reader needs barriers, too. I guess I was
wondering more why the reader would need something stronger than what
dependencies etc could enforce. I guess I'll read what Martin forwarded
first.

  Alex



  On 09/12/2014 21:37, David Holmes wrote:

    See my earlier response to Martin. The reader has to force a consistent
view of memory - the writer can't as the write escapes before it can issue
the barrier.

    David
      -----Original Message-----
      From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Oleksandr
Otenko
      Sent: Wednesday, 10 December 2014 6:04 AM
      To: Hans Boehm; dholmes at ieee.org
      Cc: core-libs-dev; concurrency-interest at cs.oswego.edu
      Subject: Re: [concurrency-interest] RFR: 8065804:
JEP171:Clarifications/corrections for fence intrinsics


      On 26/11/2014 02:04, Hans Boehm wrote:

        To be concrete here, on Power, loads can normally be ordered by an
address dependency or light-weight fence (lwsync).  However, neither is
enough to prevent the questionable outcome for IRIW, since it doesn't ensure
that the stores in T1 and T2 will be made visible to other threads in a
consistent order.  That outcome can be prevented by using heavyweight fences
(sync) instructions between the loads instead.


      Why would they need fences between loads instead of syncing the order
of stores?


      Alex



        Peter Sewell's group concluded that to enforce correct volatile
behavior on Power, you essentially need a a heavyweight fence between every
pair of volatile operations on Power.  That cannot be understood based on
simple ordering constraints.


        As Stephan pointed out, there are similar issues on ARM, but they're
less commonly encountered in a Java implementation.  If you're lucky, you
can get to the right implementation recipe by looking at only reordering, I
think.




        On Tue, Nov 25, 2014 at 4:36 PM, David Holmes
<davidcholmes at aapt.net.au> wrote:

          Stephan Diestelhorst writes:
          >
          > David Holmes wrote:
          > > Stephan Diestelhorst writes:
          > > > Am Dienstag, 25. November 2014, 11:15:36 schrieb Hans Boehm:
          > > > > I'm no hardware architect, but fundamentally it seems to
me that
          > > > >
          > > > > load x
          > > > > acquire_fence
          > > > >
          > > > > imposes a much more stringent constraint than
          > > > >
          > > > > load_acquire x
          > > > >
          > > > > Consider the case in which the load from x is an L1 hit,
but a
          > > > > preceding load (from say y) is a long-latency miss.  If we
enforce
          > > > > ordering by just waiting for completion of prior
operation, the
          > > > > former has to wait for the load from y to complete; while
the
          > > > > latter doesn't.  I find it hard to believe that this
doesn't leave
          > > > > an appreciable amount of performance on the table, at
least for
          > > > > some interesting microarchitectures.
          > > >
          > > > I agree, Hans, that this is a reasonable assumption.
Load_acquire x
          > > > does allow roach motel, whereas the acquire fence does not.
          > > >
          > > > >  In addition, for better or worse, fencing requirements on
at least
          > > > >  Power are actually driven as much by store atomicity
issues, as by
          > > > >  the ordering issues discussed in the cookbook.  This was
not
          > > > >  understood in 2005, and unfortunately doesn't seem to be
          > amenable to
          > > > >  the kind of straightforward explanation as in Doug's
cookbook.
          > > >
          > > > Coming from a strongly ordered architecture to a weakly
ordered one
          > > > myself, I also needed some mental adjustment about store
(multi-copy)
          > > > atomicity.  I can imagine others will be unaware of this
difference,
          > > > too, even in 2014.
          > >
          > > Sorry I'm missing the connection between fences and multi-copy
          > atomicity.
          >
          > One example is the classic IRIW.  With non-multi copy atomic
stores, but
          > ordered (say through a dependency) loads in the following
example:
          >
          > Memory: foo = bar = 0
          > _T1_         _T2_         _T3_                              _T4_
          > st (foo),1   st (bar),1   ld r1, (bar)                      ld
r3,(foo)
          >                           <addr dep / local "fence" here>
<addr dep>
          >                           ld r2, (foo)                      ld
r4, (bar)
          >
          > You may observe r1 = 1, r2 = 0, r3 = 1, r4 = 0 on non-multi-copy
atomic
          > machines.  On TSO boxes, this is not possible.  That means that
the
          > memory fence that will prevent such a behaviour (DMB on ARM)
needs to
          > carry some additional oomph in ensuring multi-copy atomicity, or
rather
          > prevent you from seeing it (which is the same thing).


          I take it as given that any code for which you may have ordering
          constraints, must first have basic atomicity properties for loads
and
          stores. I would not expect any kind of fence to add
multi-copy-atomicity
          where there was none.

          David


          > Stephan
          >
          > _______________________________________________
          > Concurrency-interest mailing list
          > Concurrency-interest at cs.oswego.edu
          > http://cs.oswego.edu/mailman/listinfo/concurrency-interest

          _______________________________________________
          Concurrency-interest mailing list
          Concurrency-interest at cs.oswego.edu
          http://cs.oswego.edu/mailman/listinfo/concurrency-interest






_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest





From oleksandr.otenko at oracle.com  Tue Dec  9 22:21:09 2014
From: oleksandr.otenko at oracle.com (Oleksandr Otenko)
Date: Tue, 09 Dec 2014 22:21:09 +0000
Subject: [concurrency-interest] RFR: 8065804:
	JEP171:Clarifications/corrections for fence intrinsics
In-Reply-To: <NFBBKALFDCPFIDBNKAPCKEKDKLAA.davidcholmes@aapt.net.au>
References: <NFBBKALFDCPFIDBNKAPCKEKDKLAA.davidcholmes@aapt.net.au>
Message-ID: <548775D5.6080809@oracle.com>

In that case I must say I can't see why you mentioned "no known useful 
benefit". The known useful benefit from ordering reads can be seen here:

store in one order:
Thread 1:
x=1
y=1

load in reverse order:
Thread 2:
r1=y;
r2=x;

This is a common pattern, so ordering loads is already useful. Here, 
even though JMM talks about total order of all volatile operations, in 
practice the order of loads is weaker, as long as this weakening cannot 
be observed - eg on x86 enforcing order of loads among themselves is an 
entirely local matter.

IRIW extends the store part to many threads, thus guaranteeing total 
store order for volatiles. I thought the total ordering of stores would 
be a more contentious point (but I agree with the point Hans makes about 
easier reasoning).

Alex

On 09/12/2014 21:36, David Holmes wrote:
> The "thorn" is the need for the barriers in the readers not the 
> writers. (or perhaps as well as the writers in some cases - that is 
> part of the problem.)
> David
>
>     -----Original Message-----
>     *From:* concurrency-interest-bounces at cs.oswego.edu
>     [mailto:concurrency-interest-bounces at cs.oswego.edu]*On Behalf Of
>     *Oleksandr Otenko
>     *Sent:* Wednesday, 10 December 2014 6:34 AM
>     *To:* dholmes at ieee.org; Hans Boehm
>     *Cc:* core-libs-dev; concurrency-interest at cs.oswego.edu
>     *Subject:* Re: [concurrency-interest] RFR: 8065804:
>     JEP171:Clarifications/corrections for fence intrinsics
>
>     Is the thorn the many allowed outcomes, or the single disallowed
>     outcome? (eg order consistency is too strict for stores with no
>     synchronizes-with between them?)
>
>     Alex
>
>
>     On 26/11/2014 02:10, David Holmes wrote:
>>     Hi Hans,
>>     Given IRIW is a thorn in everyone's side and has no known useful
>>     benefit, and can hopefully be killed off in the future, lets not
>>     get bogged down in IRIW. But none of what you say below relates
>>     to multi-copy-atomicity.
>>     Cheers,
>>     David
>>
>>         -----Original Message-----
>>         *From:* hjkhboehm at gmail.com [mailto:hjkhboehm at gmail.com]*On
>>         Behalf Of *Hans Boehm
>>         *Sent:* Wednesday, 26 November 2014 12:04 PM
>>         *To:* dholmes at ieee.org
>>         *Cc:* Stephan Diestelhorst;
>>         concurrency-interest at cs.oswego.edu; core-libs-dev
>>         *Subject:* Re: [concurrency-interest] RFR: 8065804:
>>         JEP171:Clarifications/corrections for fence intrinsics
>>
>>         To be concrete here, on Power, loads can normally be ordered
>>         by an address dependency or light-weight fence (lwsync). 
>>         However, neither is enough to prevent the questionable
>>         outcome for IRIW, since it doesn't ensure that the stores in
>>         T1 and T2 will be made visible to other threads in a
>>         consistent order.  That outcome can be prevented by using
>>         heavyweight fences (sync) instructions between the loads
>>         instead.  Peter Sewell's group concluded that to enforce
>>         correct volatile behavior on Power, you essentially need a a
>>         heavyweight fence between every pair of volatile operations
>>         on Power. That cannot be understood based on simple ordering
>>         constraints.
>>
>>         As Stephan pointed out, there are similar issues on ARM, but
>>         they're less commonly encountered in a Java implementation. 
>>         If you're lucky, you can get to the right implementation
>>         recipe by looking at only reordering, I think.
>>
>>
>>         On Tue, Nov 25, 2014 at 4:36 PM, David Holmes
>>         <davidcholmes at aapt.net.au <mailto:davidcholmes at aapt.net.au>>
>>         wrote:
>>
>>             Stephan Diestelhorst writes:
>>             >
>>             > David Holmes wrote:
>>             > > Stephan Diestelhorst writes:
>>             > > > Am Dienstag, 25. November 2014, 11:15:36 schrieb
>>             Hans Boehm:
>>             > > > > I'm no hardware architect, but fundamentally it
>>             seems to me that
>>             > > > >
>>             > > > > load x
>>             > > > > acquire_fence
>>             > > > >
>>             > > > > imposes a much more stringent constraint than
>>             > > > >
>>             > > > > load_acquire x
>>             > > > >
>>             > > > > Consider the case in which the load from x is an
>>             L1 hit, but a
>>             > > > > preceding load (from say y) is a long-latency
>>             miss.  If we enforce
>>             > > > > ordering by just waiting for completion of prior
>>             operation, the
>>             > > > > former has to wait for the load from y to
>>             complete; while the
>>             > > > > latter doesn't.  I find it hard to believe that
>>             this doesn't leave
>>             > > > > an appreciable amount of performance on the
>>             table, at least for
>>             > > > > some interesting microarchitectures.
>>             > > >
>>             > > > I agree, Hans, that this is a reasonable
>>             assumption.  Load_acquire x
>>             > > > does allow roach motel, whereas the acquire fence
>>             does not.
>>             > > >
>>             > > > >  In addition, for better or worse, fencing
>>             requirements on at least
>>             > > > >  Power are actually driven as much by store
>>             atomicity issues, as by
>>             > > > >  the ordering issues discussed in the cookbook. 
>>             This was not
>>             > > > >  understood in 2005, and unfortunately doesn't
>>             seem to be
>>             > amenable to
>>             > > > >  the kind of straightforward explanation as in
>>             Doug's cookbook.
>>             > > >
>>             > > > Coming from a strongly ordered architecture to a
>>             weakly ordered one
>>             > > > myself, I also needed some mental adjustment about
>>             store (multi-copy)
>>             > > > atomicity.  I can imagine others will be unaware of
>>             this difference,
>>             > > > too, even in 2014.
>>             > >
>>             > > Sorry I'm missing the connection between fences and
>>             multi-copy
>>             > atomicity.
>>             >
>>             > One example is the classic IRIW.  With non-multi copy
>>             atomic stores, but
>>             > ordered (say through a dependency) loads in the
>>             following example:
>>             >
>>             > Memory: foo = bar = 0
>>             > _T1_         _T2_         _T3_               _T4_
>>             > st (foo),1   st (bar),1   ld r1, (bar)               ld
>>             r3,(foo)
>>             >                           <addr dep / local "fence"
>>             here>   <addr dep>
>>             >                           ld r2, (foo)               ld
>>             r4, (bar)
>>             >
>>             > You may observe r1 = 1, r2 = 0, r3 = 1, r4 = 0 on
>>             non-multi-copy atomic
>>             > machines.  On TSO boxes, this is not possible.  That
>>             means that the
>>             > memory fence that will prevent such a behaviour (DMB on
>>             ARM) needs to
>>             > carry some additional oomph in ensuring multi-copy
>>             atomicity, or rather
>>             > prevent you from seeing it (which is the same thing).
>>
>>             I take it as given that any code for which you may have
>>             ordering
>>             constraints, must first have basic atomicity properties
>>             for loads and
>>             stores. I would not expect any kind of fence to add
>>             multi-copy-atomicity
>>             where there was none.
>>
>>             David
>>
>>             > Stephan
>>             >
>>             > _______________________________________________
>>             > Concurrency-interest mailing list
>>             > Concurrency-interest at cs.oswego.edu
>>             <mailto:Concurrency-interest at cs.oswego.edu>
>>             > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>             _______________________________________________
>>             Concurrency-interest mailing list
>>             Concurrency-interest at cs.oswego.edu
>>             <mailto:Concurrency-interest at cs.oswego.edu>
>>             http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>>
>>
>>     _______________________________________________
>>     Concurrency-interest mailing list
>>     Concurrency-interest at cs.oswego.edu
>>     http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



From pavel.rappo at oracle.com  Tue Dec  9 22:24:56 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 9 Dec 2014 22:24:56 +0000
Subject: RFR JDK-8066867: Add InputStream transferTo to transfer content
	to an OutputStream
In-Reply-To: <25861DCC-C08B-40C3-A761-57413CF6D4C9@reini.net>
References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com>
	<ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>
	<25861DCC-C08B-40C3-A761-57413CF6D4C9@reini.net>
Message-ID: <A839D7A2-0362-4185-90F8-D007BF12C03C@oracle.com>


> 2) I would extract the buffer size to a constant as in the NIO Files class

Patrick, we've discussed it already. Correct me if I wrong, but we came to the
conclusion that there's not enough evidence to support the need for this method.

-Pavel



From pavel.rappo at oracle.com  Tue Dec  9 22:35:17 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 9 Dec 2014 22:35:17 +0000
Subject: RFR JDK-8066867: Add InputStream transferTo to transfer content
	to an OutputStream
In-Reply-To: <54871F21.10309@oracle.com>
References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com>
	<ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>
	<54871F21.10309@oracle.com>
Message-ID: <F1194DB1-429D-4DD2-B9F0-638D3FDCCCFC@oracle.com>

> In the transferTo then transferred needs to be a long.

> ?transferred?  should be a long instead of int

Good catch, guys!

> ...the method names are inconsistent (the methods in lower case with embedded underscores)

Fixed. Updated webrev: http://cr.openjdk.java.net/~prappo/8066867/webrev.01/

-Pavel



From patrick at reini.net  Tue Dec  9 22:54:01 2014
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 9 Dec 2014 23:54:01 +0100
Subject: RFR JDK-8066867: Add InputStream transferTo to transfer content
	to an OutputStream
In-Reply-To: <A839D7A2-0362-4185-90F8-D007BF12C03C@oracle.com>
References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com>
	<ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>
	<25861DCC-C08B-40C3-A761-57413CF6D4C9@reini.net>
	<A839D7A2-0362-4185-90F8-D007BF12C03C@oracle.com>
Message-ID: <44B8EB63-DDC4-4656-A01A-62F74FA8385C@reini.net>

Hi Pavel,

>> 2) I would extract the buffer size to a constant as in the NIO Files class
> 

I may expressed myself not clear in my comment. I just wanted to point out, if the buffer size may should be extracted to a private static constant. The java.nio.file.Files class was meant to be an example.


> Patrick, we've discussed it already. Correct me if I wrong, but we came to the
> conclusion that there?s not enough evidence to support the need for this method.

What method besides ?transferTo? do you mean? Sorry, seem you lost me there?


> -Pavel
> 


-Patrick

From chris.hegarty at oracle.com  Tue Dec  9 22:58:40 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 9 Dec 2014 22:58:40 +0000
Subject: RFR JDK-8066867: Add InputStream transferTo to transfer content
	to an OutputStream
In-Reply-To: <A839D7A2-0362-4185-90F8-D007BF12C03C@oracle.com>
References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com>
	<ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>
	<25861DCC-C08B-40C3-A761-57413CF6D4C9@reini.net>
	<A839D7A2-0362-4185-90F8-D007BF12C03C@oracle.com>
Message-ID: <52A53698-369F-49DF-BF5D-EFA550DAE4D0@oracle.com>


> On 9 Dec 2014, at 22:24, Pavel Rappo <pavel.rappo at oracle.com> wrote:
> 
> 
>> 2) I would extract the buffer size to a constant as in the NIO Files class
> 
> Patrick, we've discussed it already. Correct me if I wrong, but we came to the
> conclusion that there's not enough evidence to support the need for this method.

I assume this is just a comment on an implementation detail
    private static final int BUFFER_SIZE ...

   , which I agree with.

-Chris

From oleksandr.otenko at oracle.com  Tue Dec  9 22:58:40 2014
From: oleksandr.otenko at oracle.com (Oleksandr Otenko)
Date: Tue, 09 Dec 2014 22:58:40 +0000
Subject: [concurrency-interest] RFR: 8065804:
	JEP171:Clarifications/corrections for fence intrinsics
In-Reply-To: <NFBBKALFDCPFIDBNKAPCKEKEKLAA.davidcholmes@aapt.net.au>
References: <NFBBKALFDCPFIDBNKAPCKEKEKLAA.davidcholmes@aapt.net.au>
Message-ID: <54877EA0.9010306@oracle.com>

I see it differently. The issue is ordering - the inability of non-TSO 
platforms enforce total order of independent stores. The first loads are 
also independent and their ordering can neither be enforced, nor 
detected. But the following load can detect the lack of total ordering 
of stores and loads, so it is enforced through a heavyweight barrier.

But I understood now why other barriers won't work. Thank you.

Alex


On 09/12/2014 21:59, David Holmes wrote:
> In this case the issue is not ordering per-se (which is what 
> dependencies help with) but global visibility. After performing the 
> first read each thread must ensure that its second read will return 
> what the other thread saw for the first read - hence a full dmb/sync 
> between the reads; or generalizing a full dmb/sync after every 
> volatile read.
> David
>
>     -----Original Message-----
>     *From:* Oleksandr Otenko [mailto:oleksandr.otenko at oracle.com]
>     *Sent:* Wednesday, 10 December 2014 7:54 AM
>     *To:* dholmes at ieee.org; Hans Boehm
>     *Cc:* core-libs-dev; concurrency-interest at cs.oswego.edu
>     *Subject:* Re: [concurrency-interest] RFR: 8065804:
>     JEP171:Clarifications/corrections for fence intrinsics
>
>     Yes, I do understand the reader needs barriers, too. I guess I was
>     wondering more why the reader would need something stronger than
>     what dependencies etc could enforce. I guess I'll read what Martin
>     forwarded first.
>
>     Alex
>
>
>     On 09/12/2014 21:37, David Holmes wrote:
>>     See my earlier response to Martin. The reader has to force a
>>     consistent view of memory - the writer can't as the write escapes
>>     before it can issue the barrier.
>>     David
>>
>>         -----Original Message-----
>>         *From:* concurrency-interest-bounces at cs.oswego.edu
>>         [mailto:concurrency-interest-bounces at cs.oswego.edu]*On Behalf
>>         Of *Oleksandr Otenko
>>         *Sent:* Wednesday, 10 December 2014 6:04 AM
>>         *To:* Hans Boehm; dholmes at ieee.org
>>         *Cc:* core-libs-dev; concurrency-interest at cs.oswego.edu
>>         *Subject:* Re: [concurrency-interest] RFR: 8065804:
>>         JEP171:Clarifications/corrections for fence intrinsics
>>
>>         On 26/11/2014 02:04, Hans Boehm wrote:
>>>         To be concrete here, on Power, loads can normally be ordered
>>>         by an address dependency or light-weight fence (lwsync). 
>>>         However, neither is enough to prevent the questionable
>>>         outcome for IRIW, since it doesn't ensure that the stores in
>>>         T1 and T2 will be made visible to other threads in a
>>>         consistent order.  That outcome can be prevented by using
>>>         heavyweight fences (sync) instructions between the loads
>>>         instead.
>>
>>         Why would they need fences between loads instead of syncing
>>         the order of stores?
>>
>>
>>         Alex
>>
>>
>>>         Peter Sewell's group concluded that to enforce correct
>>>         volatile behavior on Power, you essentially need a a
>>>         heavyweight fence between every pair of volatile operations
>>>         on Power.  That cannot be understood based on simple
>>>         ordering constraints.
>>>
>>>         As Stephan pointed out, there are similar issues on ARM, but
>>>         they're less commonly encountered in a Java implementation. 
>>>         If you're lucky, you can get to the right implementation
>>>         recipe by looking at only reordering, I think.
>>>
>>>
>>>         On Tue, Nov 25, 2014 at 4:36 PM, David Holmes
>>>         <davidcholmes at aapt.net.au <mailto:davidcholmes at aapt.net.au>>
>>>         wrote:
>>>
>>>             Stephan Diestelhorst writes:
>>>             >
>>>             > David Holmes wrote:
>>>             > > Stephan Diestelhorst writes:
>>>             > > > Am Dienstag, 25. November 2014, 11:15:36 schrieb
>>>             Hans Boehm:
>>>             > > > > I'm no hardware architect, but fundamentally it
>>>             seems to me that
>>>             > > > >
>>>             > > > > load x
>>>             > > > > acquire_fence
>>>             > > > >
>>>             > > > > imposes a much more stringent constraint than
>>>             > > > >
>>>             > > > > load_acquire x
>>>             > > > >
>>>             > > > > Consider the case in which the load from x is an
>>>             L1 hit, but a
>>>             > > > > preceding load (from say y) is a long-latency
>>>             miss.  If we enforce
>>>             > > > > ordering by just waiting for completion of prior
>>>             operation, the
>>>             > > > > former has to wait for the load from y to
>>>             complete; while the
>>>             > > > > latter doesn't.  I find it hard to believe that
>>>             this doesn't leave
>>>             > > > > an appreciable amount of performance on the
>>>             table, at least for
>>>             > > > > some interesting microarchitectures.
>>>             > > >
>>>             > > > I agree, Hans, that this is a reasonable
>>>             assumption.  Load_acquire x
>>>             > > > does allow roach motel, whereas the acquire fence
>>>             does not.
>>>             > > >
>>>             > > > >  In addition, for better or worse, fencing
>>>             requirements on at least
>>>             > > > >  Power are actually driven as much by store
>>>             atomicity issues, as by
>>>             > > > >  the ordering issues discussed in the cookbook. 
>>>             This was not
>>>             > > > >  understood in 2005, and unfortunately doesn't
>>>             seem to be
>>>             > amenable to
>>>             > > > >  the kind of straightforward explanation as in
>>>             Doug's cookbook.
>>>             > > >
>>>             > > > Coming from a strongly ordered architecture to a
>>>             weakly ordered one
>>>             > > > myself, I also needed some mental adjustment about
>>>             store (multi-copy)
>>>             > > > atomicity.  I can imagine others will be unaware
>>>             of this difference,
>>>             > > > too, even in 2014.
>>>             > >
>>>             > > Sorry I'm missing the connection between fences and
>>>             multi-copy
>>>             > atomicity.
>>>             >
>>>             > One example is the classic IRIW.  With non-multi copy
>>>             atomic stores, but
>>>             > ordered (say through a dependency) loads in the
>>>             following example:
>>>             >
>>>             > Memory: foo = bar = 0
>>>             > _T1_         _T2_         _T3_                 _T4_
>>>             > st (foo),1   st (bar),1   ld r1, (bar)                
>>>             ld r3,(foo)
>>>             >                           <addr dep / local "fence"
>>>             here>   <addr dep>
>>>             >                           ld r2, (foo)                
>>>             ld r4, (bar)
>>>             >
>>>             > You may observe r1 = 1, r2 = 0, r3 = 1, r4 = 0 on
>>>             non-multi-copy atomic
>>>             > machines.  On TSO boxes, this is not possible.  That
>>>             means that the
>>>             > memory fence that will prevent such a behaviour (DMB
>>>             on ARM) needs to
>>>             > carry some additional oomph in ensuring multi-copy
>>>             atomicity, or rather
>>>             > prevent you from seeing it (which is the same thing).
>>>
>>>             I take it as given that any code for which you may have
>>>             ordering
>>>             constraints, must first have basic atomicity properties
>>>             for loads and
>>>             stores. I would not expect any kind of fence to add
>>>             multi-copy-atomicity
>>>             where there was none.
>>>
>>>             David
>>>
>>>             > Stephan
>>>             >
>>>             > _______________________________________________
>>>             > Concurrency-interest mailing list
>>>             > Concurrency-interest at cs.oswego.edu
>>>             <mailto:Concurrency-interest at cs.oswego.edu>
>>>             > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>>             _______________________________________________
>>>             Concurrency-interest mailing list
>>>             Concurrency-interest at cs.oswego.edu
>>>             <mailto:Concurrency-interest at cs.oswego.edu>
>>>             http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         Concurrency-interest mailing list
>>>         Concurrency-interest at cs.oswego.edu
>>>         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>



From patrick at reini.net  Tue Dec  9 23:05:23 2014
From: patrick at reini.net (Patrick Reinhart)
Date: Wed, 10 Dec 2014 00:05:23 +0100
Subject: RFR JDK-8066867: Add InputStream transferTo to transfer content
	to an OutputStream
In-Reply-To: <52A53698-369F-49DF-BF5D-EFA550DAE4D0@oracle.com>
References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com>
	<ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>
	<25861DCC-C08B-40C3-A761-57413CF6D4C9@reini.net>
	<A839D7A2-0362-4185-90F8-D007BF12C03C@oracle.com>
	<52A53698-369F-49DF-BF5D-EFA550DAE4D0@oracle.com>
Message-ID: <BF13BECA-1755-4944-B019-14B17536D694@reini.net>

Hi Chris,
> Am 09.12.2014 um 23:58 schrieb Chris Hegarty <chris.hegarty at oracle.com>:
> 
> 
>> On 9 Dec 2014, at 22:24, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>> 
>> 
>>> 2) I would extract the buffer size to a constant as in the NIO Files class
>> 
>> Patrick, we've discussed it already. Correct me if I wrong, but we came to the
>> conclusion that there's not enough evidence to support the need for this method.
> 
> I assume this is just a comment on an implementation detail
>    private static final int BUFFER_SIZE ...
> 
>   , which I agree with.
> 
> -Chris

You got exactly my point :-)  I will try to improve my english and express myself more clearly the next time ;-)

-Patrick

From davidcholmes at aapt.net.au  Tue Dec  9 23:08:32 2014
From: davidcholmes at aapt.net.au (David Holmes)
Date: Wed, 10 Dec 2014 09:08:32 +1000
Subject: [concurrency-interest] RFR: 8065804:
	JEP171:Clarifications/corrections for fence intrinsics
In-Reply-To: <54877EA0.9010306@oracle.com>
Message-ID: <NFBBKALFDCPFIDBNKAPCMEKFKLAA.davidcholmes@aapt.net.au>

Yes you are right - forcing global visibility does ensure ordering.

David
  -----Original Message-----
  From: Oleksandr Otenko [mailto:oleksandr.otenko at oracle.com]
  Sent: Wednesday, 10 December 2014 8:59 AM
  To: dholmes at ieee.org; Hans Boehm
  Cc: core-libs-dev; concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] RFR: 8065804:
JEP171:Clarifications/corrections for fence intrinsics


  I see it differently. The issue is ordering - the inability of non-TSO
platforms enforce total order of independent stores. The first loads are
also independent and their ordering can neither be enforced, nor detected.
But the following load can detect the lack of total ordering of stores and
loads, so it is enforced through a heavyweight barrier.

  But I understood now why other barriers won't work. Thank you.

  Alex



  On 09/12/2014 21:59, David Holmes wrote:

    In this case the issue is not ordering per-se (which is what
dependencies help with) but global visibility. After performing the first
read each thread must ensure that its second read will return what the other
thread saw for the first read - hence a full dmb/sync between the reads; or
generalizing a full dmb/sync after every volatile read.

    David
      -----Original Message-----
      From: Oleksandr Otenko [mailto:oleksandr.otenko at oracle.com]
      Sent: Wednesday, 10 December 2014 7:54 AM
      To: dholmes at ieee.org; Hans Boehm
      Cc: core-libs-dev; concurrency-interest at cs.oswego.edu
      Subject: Re: [concurrency-interest] RFR: 8065804:
JEP171:Clarifications/corrections for fence intrinsics


      Yes, I do understand the reader needs barriers, too. I guess I was
wondering more why the reader would need something stronger than what
dependencies etc could enforce. I guess I'll read what Martin forwarded
first.

      Alex



      On 09/12/2014 21:37, David Holmes wrote:

        See my earlier response to Martin. The reader has to force a
consistent view of memory - the writer can't as the write escapes before it
can issue the barrier.

        David
          -----Original Message-----
          From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Oleksandr
Otenko
          Sent: Wednesday, 10 December 2014 6:04 AM
          To: Hans Boehm; dholmes at ieee.org
          Cc: core-libs-dev; concurrency-interest at cs.oswego.edu
          Subject: Re: [concurrency-interest] RFR: 8065804:
JEP171:Clarifications/corrections for fence intrinsics


          On 26/11/2014 02:04, Hans Boehm wrote:

            To be concrete here, on Power, loads can normally be ordered by
an address dependency or light-weight fence (lwsync).  However, neither is
enough to prevent the questionable outcome for IRIW, since it doesn't ensure
that the stores in T1 and T2 will be made visible to other threads in a
consistent order.  That outcome can be prevented by using heavyweight fences
(sync) instructions between the loads instead.


          Why would they need fences between loads instead of syncing the
order of stores?


          Alex



            Peter Sewell's group concluded that to enforce correct volatile
behavior on Power, you essentially need a a heavyweight fence between every
pair of volatile operations on Power.  That cannot be understood based on
simple ordering constraints.


            As Stephan pointed out, there are similar issues on ARM, but
they're less commonly encountered in a Java implementation.  If you're
lucky, you can get to the right implementation recipe by looking at only
reordering, I think.




            On Tue, Nov 25, 2014 at 4:36 PM, David Holmes
<davidcholmes at aapt.net.au> wrote:

              Stephan Diestelhorst writes:
              >
              > David Holmes wrote:
              > > Stephan Diestelhorst writes:
              > > > Am Dienstag, 25. November 2014, 11:15:36 schrieb Hans
Boehm:
              > > > > I'm no hardware architect, but fundamentally it seems
to me that
              > > > >
              > > > > load x
              > > > > acquire_fence
              > > > >
              > > > > imposes a much more stringent constraint than
              > > > >
              > > > > load_acquire x
              > > > >
              > > > > Consider the case in which the load from x is an L1
hit, but a
              > > > > preceding load (from say y) is a long-latency miss.
If we enforce
              > > > > ordering by just waiting for completion of prior
operation, the
              > > > > former has to wait for the load from y to complete;
while the
              > > > > latter doesn't.  I find it hard to believe that this
doesn't leave
              > > > > an appreciable amount of performance on the table, at
least for
              > > > > some interesting microarchitectures.
              > > >
              > > > I agree, Hans, that this is a reasonable assumption.
Load_acquire x
              > > > does allow roach motel, whereas the acquire fence does
not.
              > > >
              > > > >  In addition, for better or worse, fencing
requirements on at least
              > > > >  Power are actually driven as much by store atomicity
issues, as by
              > > > >  the ordering issues discussed in the cookbook.  This
was not
              > > > >  understood in 2005, and unfortunately doesn't seem to
be
              > amenable to
              > > > >  the kind of straightforward explanation as in Doug's
cookbook.
              > > >
              > > > Coming from a strongly ordered architecture to a weakly
ordered one
              > > > myself, I also needed some mental adjustment about store
(multi-copy)
              > > > atomicity.  I can imagine others will be unaware of this
difference,
              > > > too, even in 2014.
              > >
              > > Sorry I'm missing the connection between fences and
multi-copy
              > atomicity.
              >
              > One example is the classic IRIW.  With non-multi copy atomic
stores, but
              > ordered (say through a dependency) loads in the following
example:
              >
              > Memory: foo = bar = 0
              > _T1_         _T2_         _T3_
_T4_
              > st (foo),1   st (bar),1   ld r1, (bar)
ld r3,(foo)
              >                           <addr dep / local "fence" here>
<addr dep>
              >                           ld r2, (foo)
ld r4, (bar)
              >
              > You may observe r1 = 1, r2 = 0, r3 = 1, r4 = 0 on
non-multi-copy atomic
              > machines.  On TSO boxes, this is not possible.  That means
that the
              > memory fence that will prevent such a behaviour (DMB on ARM)
needs to
              > carry some additional oomph in ensuring multi-copy
atomicity, or rather
              > prevent you from seeing it (which is the same thing).


              I take it as given that any code for which you may have
ordering
              constraints, must first have basic atomicity properties for
loads and
              stores. I would not expect any kind of fence to add
multi-copy-atomicity
              where there was none.

              David


              > Stephan
              >
              > _______________________________________________
              > Concurrency-interest mailing list
              > Concurrency-interest at cs.oswego.edu
              > http://cs.oswego.edu/mailman/listinfo/concurrency-interest

              _______________________________________________
              Concurrency-interest mailing list
              Concurrency-interest at cs.oswego.edu
              http://cs.oswego.edu/mailman/listinfo/concurrency-interest






_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest







From pavel.rappo at oracle.com  Tue Dec  9 23:20:33 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 9 Dec 2014 23:20:33 +0000
Subject: RFR JDK-8066867: Add InputStream transferTo to transfer content
	to an OutputStream
In-Reply-To: <BF13BECA-1755-4944-B019-14B17536D694@reini.net>
References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com>
	<ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>
	<25861DCC-C08B-40C3-A761-57413CF6D4C9@reini.net>
	<A839D7A2-0362-4185-90F8-D007BF12C03C@oracle.com>
	<52A53698-369F-49DF-BF5D-EFA550DAE4D0@oracle.com>
	<BF13BECA-1755-4944-B019-14B17536D694@reini.net>
Message-ID: <1267B1BD-A304-46F1-A014-556B5567DE6B@oracle.com>

Apologies Patrick, that's me who misread you. I assume I had a mix of your
reply, our recent conversation and David's question in my head.

About your actual reply. That's probably a matter of taste, since nowhere else
except for this particular method this thing is not used (in java.nio.file.Files
BUFFER_SIZE const is referenced 3 times).
It's more like java.io.InputStream#MAX_SKIP_BUFFER_SIZE, which is more of an
explanatory purpose than anything else, I suppose.
 
-Pavel

> On 9 Dec 2014, at 23:05, Patrick Reinhart <patrick at reini.net> wrote:
> 
> You got exactly my point :-)  I will try to improve my english and express myself more clearly the next time ;-)



From davidcholmes at aapt.net.au  Wed Dec 10 00:00:14 2014
From: davidcholmes at aapt.net.au (David Holmes)
Date: Wed, 10 Dec 2014 10:00:14 +1000
Subject: [concurrency-interest] RFR: 8065804:
	JEP171:Clarifications/corrections for fence intrinsics
In-Reply-To: <548775D5.6080809@oracle.com>
Message-ID: <NFBBKALFDCPFIDBNKAPCCEKHKLAA.davidcholmes@aapt.net.au>

The "no known useful benefit" is based on the paper which states "we are not
aware of any cases where IRIW arises as a natural programming idiom".

I think your example would be written:

Thread 1:
x =1; storestore; y=1;

Thread 2:
r1 = y; r2 =x.

Or more clearly, the most common pattern would be:

Thread1:
data = 1; storestore; dataReady = true;

Thread 2:
if dataReady
  r2 = data

The above does not require IRIW. Conversely if you have IRIW you don't need
the storestore.

David

  -----Original Message-----
  From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Oleksandr
Otenko
  Sent: Wednesday, 10 December 2014 8:21 AM
  Cc: concurrency-interest at cs.oswego.edu; core-libs-dev
  Subject: Re: [concurrency-interest] RFR: 8065804:
JEP171:Clarifications/corrections for fence intrinsics


  In that case I must say I can't see why you mentioned "no known useful
benefit". The known useful benefit from ordering reads can be seen here:

  store in one order:
  Thread 1:
  x=1
  y=1

  load in reverse order:
  Thread 2:
  r1=y;
  r2=x;

  This is a common pattern, so ordering loads is already useful. Here, even
though JMM talks about total order of all volatile operations, in practice
the order of loads is weaker, as long as this weakening cannot be observed -
eg on x86 enforcing order of loads among themselves is an entirely local
matter.

  IRIW extends the store part to many threads, thus guaranteeing total store
order for volatiles. I thought the total ordering of stores would be a more
contentious point (but I agree with the point Hans makes about easier
reasoning).

  Alex


  On 09/12/2014 21:36, David Holmes wrote:

    The "thorn" is the need for the barriers in the readers not the writers.
(or perhaps as well as the writers in some cases - that is part of the
problem.)

    David
      -----Original Message-----
      From: concurrency-interest-bounces at cs.oswego.edu
[mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Oleksandr
Otenko
      Sent: Wednesday, 10 December 2014 6:34 AM
      To: dholmes at ieee.org; Hans Boehm
      Cc: core-libs-dev; concurrency-interest at cs.oswego.edu
      Subject: Re: [concurrency-interest] RFR: 8065804:
JEP171:Clarifications/corrections for fence intrinsics


      Is the thorn the many allowed outcomes, or the single disallowed
outcome? (eg order consistency is too strict for stores with no
synchronizes-with between them?)

      Alex



      On 26/11/2014 02:10, David Holmes wrote:

        Hi Hans,
        Given IRIW is a thorn in everyone's side and has no known useful
benefit, and can hopefully be killed off in the future, lets not get bogged
down in IRIW. But none of what you say below relates to
multi-copy-atomicity.

        Cheers,
        David
          -----Original Message-----
          From: hjkhboehm at gmail.com [mailto:hjkhboehm at gmail.com]On Behalf Of
Hans Boehm
          Sent: Wednesday, 26 November 2014 12:04 PM
          To: dholmes at ieee.org
          Cc: Stephan Diestelhorst; concurrency-interest at cs.oswego.edu;
core-libs-dev
          Subject: Re: [concurrency-interest] RFR: 8065804:
JEP171:Clarifications/corrections for fence intrinsics


          To be concrete here, on Power, loads can normally be ordered by an
address dependency or light-weight fence (lwsync).  However, neither is
enough to prevent the questionable outcome for IRIW, since it doesn't ensure
that the stores in T1 and T2 will be made visible to other threads in a
consistent order.  That outcome can be prevented by using heavyweight fences
(sync) instructions between the loads instead.  Peter Sewell's group
concluded that to enforce correct volatile behavior on Power, you
essentially need a a heavyweight fence between every pair of volatile
operations on Power.  That cannot be understood based on simple ordering
constraints.


          As Stephan pointed out, there are similar issues on ARM, but
they're less commonly encountered in a Java implementation.  If you're
lucky, you can get to the right implementation recipe by looking at only
reordering, I think.




          On Tue, Nov 25, 2014 at 4:36 PM, David Holmes
<davidcholmes at aapt.net.au> wrote:

            Stephan Diestelhorst writes:
            >
            > David Holmes wrote:
            > > Stephan Diestelhorst writes:
            > > > Am Dienstag, 25. November 2014, 11:15:36 schrieb Hans
Boehm:
            > > > > I'm no hardware architect, but fundamentally it seems to
me that
            > > > >
            > > > > load x
            > > > > acquire_fence
            > > > >
            > > > > imposes a much more stringent constraint than
            > > > >
            > > > > load_acquire x
            > > > >
            > > > > Consider the case in which the load from x is an L1 hit,
but a
            > > > > preceding load (from say y) is a long-latency miss.  If
we enforce
            > > > > ordering by just waiting for completion of prior
operation, the
            > > > > former has to wait for the load from y to complete;
while the
            > > > > latter doesn't.  I find it hard to believe that this
doesn't leave
            > > > > an appreciable amount of performance on the table, at
least for
            > > > > some interesting microarchitectures.
            > > >
            > > > I agree, Hans, that this is a reasonable assumption.
Load_acquire x
            > > > does allow roach motel, whereas the acquire fence does
not.
            > > >
            > > > >  In addition, for better or worse, fencing requirements
on at least
            > > > >  Power are actually driven as much by store atomicity
issues, as by
            > > > >  the ordering issues discussed in the cookbook.  This
was not
            > > > >  understood in 2005, and unfortunately doesn't seem to
be
            > amenable to
            > > > >  the kind of straightforward explanation as in Doug's
cookbook.
            > > >
            > > > Coming from a strongly ordered architecture to a weakly
ordered one
            > > > myself, I also needed some mental adjustment about store
(multi-copy)
            > > > atomicity.  I can imagine others will be unaware of this
difference,
            > > > too, even in 2014.
            > >
            > > Sorry I'm missing the connection between fences and
multi-copy
            > atomicity.
            >
            > One example is the classic IRIW.  With non-multi copy atomic
stores, but
            > ordered (say through a dependency) loads in the following
example:
            >
            > Memory: foo = bar = 0
            > _T1_         _T2_         _T3_
_T4_
            > st (foo),1   st (bar),1   ld r1, (bar)                      ld
r3,(foo)
            >                           <addr dep / local "fence" here>
<addr dep>
            >                           ld r2, (foo)                      ld
r4, (bar)
            >
            > You may observe r1 = 1, r2 = 0, r3 = 1, r4 = 0 on
non-multi-copy atomic
            > machines.  On TSO boxes, this is not possible.  That means
that the
            > memory fence that will prevent such a behaviour (DMB on ARM)
needs to
            > carry some additional oomph in ensuring multi-copy atomicity,
or rather
            > prevent you from seeing it (which is the same thing).


            I take it as given that any code for which you may have ordering
            constraints, must first have basic atomicity properties for
loads and
            stores. I would not expect any kind of fence to add
multi-copy-atomicity
            where there was none.

            David


            > Stephan
            >
            > _______________________________________________
            > Concurrency-interest mailing list
            > Concurrency-interest at cs.oswego.edu
            > http://cs.oswego.edu/mailman/listinfo/concurrency-interest

            _______________________________________________
            Concurrency-interest mailing list
            Concurrency-interest at cs.oswego.edu
            http://cs.oswego.edu/mailman/listinfo/concurrency-interest






_______________________________________________
Concurrency-interest mailing list
Concurrency-interest at cs.oswego.edu
http://cs.oswego.edu/mailman/listinfo/concurrency-interest





From oleksandr.otenko at oracle.com  Wed Dec 10 00:24:40 2014
From: oleksandr.otenko at oracle.com (Oleksandr Otenko)
Date: Wed, 10 Dec 2014 00:24:40 +0000
Subject: [concurrency-interest] RFR: 8065804:
	JEP171:Clarifications/corrections for fence intrinsics
In-Reply-To: <NFBBKALFDCPFIDBNKAPCCEKHKLAA.davidcholmes@aapt.net.au>
References: <NFBBKALFDCPFIDBNKAPCCEKHKLAA.davidcholmes@aapt.net.au>
Message-ID: <548792C8.6060202@oracle.com>

Yes, I read the part of that paper about IRIW.

My thinking that the ordering of stores would be the more contentious 
point also appears about the same thing.

In IRIW we have two parts of chain that's reasonable to expect to work:

x=1 <-- sw -- r1=x <-- po -- r2=y
y=1 <-- sw -- r3=y <-- po -- r4=x

Suppose r2==0. Then to show the outcome with r4==0 is forbidden need to 
show an edge from r4=x to x=1. Total ordering of stores provides such an 
edge: x=1 <-- so -- y=1 (if chosen otherwise, then we can prove r2!=0).

It looked like enforcing sw and po is reasonable and cheap. But total 
ordering of stores isn't justified in the spec - it just is there, hence 
I was wondering.

On a non-TSO there is no edge between the stores. So to construct the 
proof the outcome r4==0 is forbidden they had to enforce a ordering 
between other instructions, where r2==0 implies the preceding barrier 
also precedes r3=y, which observed r3==1; then it follows that r1=x <-- 
so -- r4=x, and a contradiction shows r4==0 is forbidden.

The effort (and the need) to order the reads is tremendous, and doesn't 
seem right, so I see why it is raising questions.

Alex

On 10/12/2014 00:00, David Holmes wrote:
> The "no known useful benefit" is based on the paper which states "we 
> are not aware of any cases where IRIW arises as a natural programming 
> idiom".
> I think your example would be written:
> Thread 1:
> x =1; storestore; y=1;
> Thread 2:
> r1 = y; r2 =x.
> Or more clearly, the most common pattern would be:
> Thread1:
> data = 1; storestore; dataReady = true;
> Thread 2:
> if dataReady
>   r2 = data
> The above does not require IRIW. Conversely if you have IRIW you don't 
> need the storestore.
> David
>
>     -----Original Message-----
>     *From:* concurrency-interest-bounces at cs.oswego.edu
>     [mailto:concurrency-interest-bounces at cs.oswego.edu]*On Behalf Of
>     *Oleksandr Otenko
>     *Sent:* Wednesday, 10 December 2014 8:21 AM
>     *Cc:* concurrency-interest at cs.oswego.edu; core-libs-dev
>     *Subject:* Re: [concurrency-interest] RFR: 8065804:
>     JEP171:Clarifications/corrections for fence intrinsics
>
>     In that case I must say I can't see why you mentioned "no known
>     useful benefit". The known useful benefit from ordering reads can
>     be seen here:
>
>     store in one order:
>     Thread 1:
>     x=1
>     y=1
>
>     load in reverse order:
>     Thread 2:
>     r1=y;
>     r2=x;
>
>     This is a common pattern, so ordering loads is already useful.
>     Here, even though JMM talks about total order of all volatile
>     operations, in practice the order of loads is weaker, as long as
>     this weakening cannot be observed - eg on x86 enforcing order of
>     loads among themselves is an entirely local matter.
>
>     IRIW extends the store part to many threads, thus guaranteeing
>     total store order for volatiles. I thought the total ordering of
>     stores would be a more contentious point (but I agree with the
>     point Hans makes about easier reasoning).
>
>     Alex
>
>     On 09/12/2014 21:36, David Holmes wrote:
>>     The "thorn" is the need for the barriers in the readers not the
>>     writers. (or perhaps as well as the writers in some cases - that
>>     is part of the problem.)
>>     David
>>
>>         -----Original Message-----
>>         *From:* concurrency-interest-bounces at cs.oswego.edu
>>         [mailto:concurrency-interest-bounces at cs.oswego.edu]*On Behalf
>>         Of *Oleksandr Otenko
>>         *Sent:* Wednesday, 10 December 2014 6:34 AM
>>         *To:* dholmes at ieee.org; Hans Boehm
>>         *Cc:* core-libs-dev; concurrency-interest at cs.oswego.edu
>>         *Subject:* Re: [concurrency-interest] RFR: 8065804:
>>         JEP171:Clarifications/corrections for fence intrinsics
>>
>>         Is the thorn the many allowed outcomes, or the single
>>         disallowed outcome? (eg order consistency is too strict for
>>         stores with no synchronizes-with between them?)
>>
>>         Alex
>>
>>
>>         On 26/11/2014 02:10, David Holmes wrote:
>>>         Hi Hans,
>>>         Given IRIW is a thorn in everyone's side and has no known
>>>         useful benefit, and can hopefully be killed off in the
>>>         future, lets not get bogged down in IRIW. But none of what
>>>         you say below relates to multi-copy-atomicity.
>>>         Cheers,
>>>         David
>>>
>>>             -----Original Message-----
>>>             *From:* hjkhboehm at gmail.com
>>>             [mailto:hjkhboehm at gmail.com]*On Behalf Of *Hans Boehm
>>>             *Sent:* Wednesday, 26 November 2014 12:04 PM
>>>             *To:* dholmes at ieee.org
>>>             *Cc:* Stephan Diestelhorst;
>>>             concurrency-interest at cs.oswego.edu; core-libs-dev
>>>             *Subject:* Re: [concurrency-interest] RFR: 8065804:
>>>             JEP171:Clarifications/corrections for fence intrinsics
>>>
>>>             To be concrete here, on Power, loads can normally be
>>>             ordered by an address dependency or light-weight fence
>>>             (lwsync).  However, neither is enough to prevent the
>>>             questionable outcome for IRIW, since it doesn't ensure
>>>             that the stores in T1 and T2 will be made visible to
>>>             other threads in a consistent order.  That outcome can
>>>             be prevented by using heavyweight fences (sync)
>>>             instructions between the loads instead.  Peter Sewell's
>>>             group concluded that to enforce correct volatile
>>>             behavior on Power, you essentially need a a heavyweight
>>>             fence between every pair of volatile operations on
>>>             Power.  That cannot be understood based on simple
>>>             ordering constraints.
>>>
>>>             As Stephan pointed out, there are similar issues on ARM,
>>>             but they're less commonly encountered in a Java
>>>             implementation.  If you're lucky, you can get to the
>>>             right implementation recipe by looking at only
>>>             reordering, I think.
>>>
>>>
>>>             On Tue, Nov 25, 2014 at 4:36 PM, David Holmes
>>>             <davidcholmes at aapt.net.au
>>>             <mailto:davidcholmes at aapt.net.au>> wrote:
>>>
>>>                 Stephan Diestelhorst writes:
>>>                 >
>>>                 > David Holmes wrote:
>>>                 > > Stephan Diestelhorst writes:
>>>                 > > > Am Dienstag, 25. November 2014, 11:15:36
>>>                 schrieb Hans Boehm:
>>>                 > > > > I'm no hardware architect, but fundamentally
>>>                 it seems to me that
>>>                 > > > >
>>>                 > > > > load x
>>>                 > > > > acquire_fence
>>>                 > > > >
>>>                 > > > > imposes a much more stringent constraint than
>>>                 > > > >
>>>                 > > > > load_acquire x
>>>                 > > > >
>>>                 > > > > Consider the case in which the load from x
>>>                 is an L1 hit, but a
>>>                 > > > > preceding load (from say y) is a
>>>                 long-latency miss.  If we enforce
>>>                 > > > > ordering by just waiting for completion of
>>>                 prior operation, the
>>>                 > > > > former has to wait for the load from y to
>>>                 complete; while the
>>>                 > > > > latter doesn't.  I find it hard to believe
>>>                 that this doesn't leave
>>>                 > > > > an appreciable amount of performance on the
>>>                 table, at least for
>>>                 > > > > some interesting microarchitectures.
>>>                 > > >
>>>                 > > > I agree, Hans, that this is a reasonable
>>>                 assumption.  Load_acquire x
>>>                 > > > does allow roach motel, whereas the acquire
>>>                 fence does not.
>>>                 > > >
>>>                 > > > >  In addition, for better or worse, fencing
>>>                 requirements on at least
>>>                 > > > >  Power are actually driven as much by store
>>>                 atomicity issues, as by
>>>                 > > > >  the ordering issues discussed in the
>>>                 cookbook.  This was not
>>>                 > > > >  understood in 2005, and unfortunately
>>>                 doesn't seem to be
>>>                 > amenable to
>>>                 > > > >  the kind of straightforward explanation as
>>>                 in Doug's cookbook.
>>>                 > > >
>>>                 > > > Coming from a strongly ordered architecture to
>>>                 a weakly ordered one
>>>                 > > > myself, I also needed some mental adjustment
>>>                 about store (multi-copy)
>>>                 > > > atomicity.  I can imagine others will be
>>>                 unaware of this difference,
>>>                 > > > too, even in 2014.
>>>                 > >
>>>                 > > Sorry I'm missing the connection between fences
>>>                 and multi-copy
>>>                 > atomicity.
>>>                 >
>>>                 > One example is the classic IRIW.  With non-multi
>>>                 copy atomic stores, but
>>>                 > ordered (say through a dependency) loads in the
>>>                 following example:
>>>                 >
>>>                 > Memory: foo = bar = 0
>>>                 > _T1_         _T2_         _T3_                   _T4_
>>>                 > st (foo),1   st (bar),1   ld r1, (bar)            
>>>                       ld r3,(foo)
>>>                 >                           <addr dep / local
>>>                 "fence" here>   <addr dep>
>>>                 >                           ld r2, (foo)            
>>>                       ld r4, (bar)
>>>                 >
>>>                 > You may observe r1 = 1, r2 = 0, r3 = 1, r4 = 0 on
>>>                 non-multi-copy atomic
>>>                 > machines.  On TSO boxes, this is not possible. 
>>>                 That means that the
>>>                 > memory fence that will prevent such a behaviour
>>>                 (DMB on ARM) needs to
>>>                 > carry some additional oomph in ensuring multi-copy
>>>                 atomicity, or rather
>>>                 > prevent you from seeing it (which is the same thing).
>>>
>>>                 I take it as given that any code for which you may
>>>                 have ordering
>>>                 constraints, must first have basic atomicity
>>>                 properties for loads and
>>>                 stores. I would not expect any kind of fence to add
>>>                 multi-copy-atomicity
>>>                 where there was none.
>>>
>>>                 David
>>>
>>>                 > Stephan
>>>                 >
>>>                 > _______________________________________________
>>>                 > Concurrency-interest mailing list
>>>                 > Concurrency-interest at cs.oswego.edu
>>>                 <mailto:Concurrency-interest at cs.oswego.edu>
>>>                 >
>>>                 http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>>                 _______________________________________________
>>>                 Concurrency-interest mailing list
>>>                 Concurrency-interest at cs.oswego.edu
>>>                 <mailto:Concurrency-interest at cs.oswego.edu>
>>>                 http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         Concurrency-interest mailing list
>>>         Concurrency-interest at cs.oswego.edu
>>>         http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>



From david.holmes at oracle.com  Wed Dec 10 06:01:22 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 10 Dec 2014 16:01:22 +1000
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <CA+kOe09aURqjRRk_gF8JtCAaJk+Fja8pTYmNY-B=DS7wuWXr1w@mail.gmail.com>
References: <CA+kOe0-kaVGdNyaLN2Yo0H4KnM1AU3N=nFryazZP1VbqK9t=Kw@mail.gmail.com>	<NFBBKALFDCPFIDBNKAPCAEJJKLAA.davidcholmes@aapt.net.au>	<CA+kOe09b_3-08pOt171PYedGoT0Bp5X1HOA7B+PHzCSRMkx6wQ@mail.gmail.com>	<54867C1F.1090106@oracle.com>
	<CA+kOe09aURqjRRk_gF8JtCAaJk+Fja8pTYmNY-B=DS7wuWXr1w@mail.gmail.com>
Message-ID: <5487E1B2.6050409@oracle.com>

On 10/12/2014 4:15 AM, Martin Buchholz wrote:
> On Mon, Dec 8, 2014 at 8:35 PM, David Holmes <david.holmes at oracle.com> wrote:
>
>>> So (as you say) with TSO you don't have a total order of stores if you
>>> read your own writes out of your own CPU's write buffer.  However, my
>>> interpretation of "multiple-copy atomic" is that the initial
>>> publishing thread can choose to use an instruction with sufficiently
>>> strong memory barrier attached (e.g. LOCK;XXX on x86) to write to
>>> memory so that the write buffer is flushed and then use plain relaxed
>>> loads everywhere else to read those memory locations and this explains
>>> the situation on x86 and sparc where volatile writes are expensive and
>>> volatile reads are "free" and you get sequential consistency for Java
>>> volatiles.
>>
>>
>> We don't use lock'd instructions for volatile stores on x86, but the
>> trailing mfence achieves the "flushing".
>>
>> However this still raised some questions for me. Using a mfence on x86 or
>> equivalent on sparc, is no different to issuing a "DMB SYNC" on ARM, or a
>> SYNC on PowerPC. They each ensure TSO for volatile stores with global
>> visibility. So when such fences are used the resulting system should be
>> multiple-copy atomic - no? (No!**) And there seems to be an equivalence
>> between being multiple-copy atomic and providing the IRIW property. Yet we
>> know that on ARM/Power, as per the paper, TSO with global visibility is not
>
> ARM/Power don't have TSO.

Yes we all know that. Please re-read what I wrote.

>> sufficient to achieve IRIW. So what is it that x86 and sparc have in
>> addition to TSO that provides for IRIW?
>
> We have both been learning.... to think in new ways.
>   I found the second section of Peter Sewell's tutorial
> 2 From Sequential Consistency to Relaxed Memory Models
> to be most useful, especially the diagrams.
>
>> I pondered this for quite a while before realizing that the mfence on x86
>> (or equivalent on sparc) is not in fact playing the same role as the
>> DMB/SYNC on ARM/PPC. The key property that x86 and sparc have (and we can
>> ignore the store buffers) is that stores become globally visible - if any
>> other thread sees a store then all other threads see the same store. Whereas
>> on ARM/PPC you can imagine a store casually making its way through the
>> system, gradually becoming visible to more and more threads - unless there
>> is a DMB/SYNC to force a globally consistent memory view. Hence for IRIW
>> placing the DMB/SYNC after the store does not suffice because prior to the
>> DMB/SYNC the store may be visible to an arbitrary subset of threads.
>> Consequently IRIW requires the DMB/SYNC between the loads - to ensure that
>> each thread on their second load, must see the value that the other thread
>> saw on its first load (ref Section 6.1 of the paper).
>>
>> ** So using DMB/SYNC does not achieve multiple-copy atomicity, because until
>> the DMB/SYNC happens different threads can have different views of memory.
>
> To me, the most desirable property of x86-style TSO is that barriers
> are only necessary on stores to achieve sequential consistency - the
> publisher gets to decide.  Volatile reads can then be close to free.

TSO doesn't need store barriers for sequential consistency.

It is somewhat amusing I think that the free-ness of volatile reads on 
TSO comes from the fact that all writes cause global memory 
synchronization. But because we can't turn that off we can't actually 
measure the cost we pay for those synchronizing writes. In contrast on 
non-TSO we have to explicitly cause synchronizing writes and so 
potentially require synchronizing reads - and then complain because the 
"hidden costs" are no longer hidden :)

>> All of which reinforces to me that IRIW is an undesirable property to have
>> to implement. YMMV. (And I also need to re-examine the PPC64 implementation
>> to see exactly where they add/remove barriers when IRIW is enabled.)
>
> I believe you get a full sync between volatile reads.
>
> #define GET_FIELD_VOLATILE(obj, offset, type_name, v) \
>    oop p = JNIHandles::resolve(obj); \
>    if (support_IRIW_for_not_multiple_copy_atomic_cpu) { \
>      OrderAccess::fence(); \
>    } \

Yes, it was more the "remove" part that I was unsure of the details - I 
think they simply remove the trailing fence (ie PPC SYNC) from the 
volatile writes.

Thanks,
David

>
>> Cheers,
>> David
>>
>>> http://www.cl.cam.ac.uk/~pes20/ppc-supplemental/test7.pdf


From paul.sandoz at oracle.com  Wed Dec 10 08:32:12 2014
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 10 Dec 2014 09:32:12 +0100
Subject: RFR: 8065172: More core reflection final and volatile annotations
In-Reply-To: <CA+kOe0_E32geW6o68pbaTSwkX0awwWQWQVrgGd0ANejPhjArVg@mail.gmail.com>
References: <CA+kOe0_ek6UDjkOXEggp3JYo=ezxRqprLFUJxQb0v3Mnzj41JQ@mail.gmail.com>
	<546E09D6.9040800@gmail.com>
	<6B93C453-C558-4C0E-B7FA-4255507B154D@oracle.com>
	<54735081.5050201@gmail.com>
	<A1B7B5B4-9590-4155-8546-3117D47AD590@oracle.com>
	<CA+kOe0-AEf_1ZJ0rDziKo5cAStQSasdZ-eDeFGs+2Gqss1_uxA@mail.gmail.com>
	<4E57D36E-1D9A-4EB4-9130-B80730C35069@oracle.com>
	<CA+kOe0-Yv8ubBJEViJ0xJwm-89HXO1TmgFyiytq0AMjbv9zs8w@mail.gmail.com>
	<548616F2.2040803@gmail.com> <54861D93.9080105@gmail.com>
	<CA+kOe0_ktK4Ysv8NuaZAKy=5BWF303gBt0LdoTFNqWxA1sqd7Q@mail.gmail.com>
	<CA+kOe09CHFu=usJ9NmXByc_VMvO-_jfc=t_6sgsD5tS=Z96gDg@mail.gmail.com>
	<112EA4F1-358F-4349-A6CC-B6C157996BD9@oracle.com>
	<CA+kOe0_E32geW6o68pbaTSwkX0awwWQWQVrgGd0ANejPhjArVg@mail.gmail.com>
Message-ID: <63B625B8-1210-4F78-82B2-5F38D1FD658D@oracle.com>


On Dec 9, 2014, at 5:49 PM, Martin Buchholz <martinrb at google.com> wrote:

> Oops sorry - classic mistake of forgetting to hg qrefresh before publishing.
> 

It's in sync now, thanks.

+1

Paul.


From amy.lu at oracle.com  Wed Dec 10 10:15:07 2014
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 10 Dec 2014 18:15:07 +0800
Subject: RFR 8067112: Update jdk/test/java/util/Collections/EmptyIterator.java
	to eliminate dependency on sun.tools.java
Message-ID: <54881D2B.5040107@oracle.com>

Please review the fix for removing internal JDK API dependency from test 
java/util/Collections/EmptyIterator.java

This test has dependency on sun.tools.java from one of it?s test case, 
this fixed by using public API for the same testing purpose.

bug: https://bugs.openjdk.java.net/browse/JDK-8067112
webrev: http://cr.openjdk.java.net/~weijun/8067112/webrev.00/

Thanks,
Amy


From chris.hegarty at oracle.com  Wed Dec 10 10:26:29 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 10 Dec 2014 10:26:29 +0000
Subject: RFR 8067112: Update
	jdk/test/java/util/Collections/EmptyIterator.java
	to eliminate dependency on sun.tools.java
In-Reply-To: <54881D2B.5040107@oracle.com>
References: <54881D2B.5040107@oracle.com>
Message-ID: <54881FD5.2040003@oracle.com>

This looks good to me Amy. Do you need a sponsor ?

-Chris.

On 10/12/14 10:15, Amy Lu wrote:
> Please review the fix for removing internal JDK API dependency from test
> java/util/Collections/EmptyIterator.java
>
> This test has dependency on sun.tools.java from one of it?s test case,
> this fixed by using public API for the same testing purpose.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8067112
> webrev: http://cr.openjdk.java.net/~weijun/8067112/webrev.00/
>
> Thanks,
> Amy


From pavel.rappo at oracle.com  Wed Dec 10 11:47:05 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 10 Dec 2014 11:47:05 +0000
Subject: RFR 8067112: Update
	jdk/test/java/util/Collections/EmptyIterator.java to eliminate
	dependency on sun.tools.java
In-Reply-To: <54881FD5.2040003@oracle.com>
References: <54881D2B.5040107@oracle.com> <54881FD5.2040003@oracle.com>
Message-ID: <F1B9F22E-3A13-4968-9F84-36BCEAA188CF@oracle.com>

A quick question: can we piggyback on this particular issue and
remove some generics here? (see javac warnings):

diff -r cb475099ceac test/java/util/Collections/EmptyIterator.java
--- a/test/java/util/Collections/EmptyIterator.java	Tue Dec 09 09:22:07 2014 -0800
+++ b/test/java/util/Collections/EmptyIterator.java	Wed Dec 10 11:42:35 2014 +0000
@@ -33,12 +33,12 @@
 public class EmptyIterator {
 
     void test(String[] args) throws Throwable {
-        testEmptyCollection(Collections.<Object>emptyList());
-        testEmptyCollection(Collections.<Object>emptySet());
+        testEmptyCollection(Collections.emptyList());
+        testEmptyCollection(Collections.emptySet());
 
-        testEmptyMap(Collections.<Object, Object>emptyMap());
+        testEmptyMap(Collections.emptyMap());
 
-        Hashtable<Object, Object> emptyTable = new Hashtable<Object, Object>();
+        Hashtable<?, ?> emptyTable = new Hashtable<>();
         testEmptyEnumeration(emptyTable.keys());
         testEmptyEnumeration(emptyTable.elements());
         testEmptyIterator(emptyTable.keySet().iterator());
@@ -49,24 +49,21 @@
             Collections.emptyEnumeration();
         testEmptyEnumeration(finalEmptyTyped);
 
-        final Enumeration finalEmptyAbstract =
+        final Enumeration<?> finalEmptyAbstract =
             Collections.emptyEnumeration();
         testEmptyEnumeration(finalEmptyAbstract);
 
-        @SuppressWarnings("unchecked") Iterator<?> x =
-            new sun.tools.java.MethodSet()
-            .lookupName(sun.tools.java.Identifier.lookup(""));
-        testEmptyIterator(x);
+        testEmptyIterator(Collections.emptyIterator());
     }
 
-    <T> void testEmptyEnumeration(final Enumeration<T> e) {
+    void testEmptyEnumeration(final Enumeration<?> e) {
         check(e == emptyEnumeration());
         check(! e.hasMoreElements());
         THROWS(NoSuchElementException.class,
                new F(){void f(){ e.nextElement(); }});
     }
 
-    <T> void testEmptyIterator(final Iterator<T> it) {
+    void testEmptyIterator(final Iterator<?> it) {
         check(it == emptyIterator());
         check(! it.hasNext());
         THROWS(NoSuchElementException.class,
@@ -75,10 +72,10 @@
                new F(){void f(){ it.remove(); }});
     }
 
-    void testEmptyMap(Map<Object, Object> m) {
+    void testEmptyMap(Map<?, ?> m) {
         check(m == emptyMap());
-        check(m.entrySet().iterator() ==
-              Collections.<Map.Entry<Object,Object>>emptyIterator());
+        Iterator<? extends Map.Entry<?, ?>> iterator = m.entrySet().iterator();
+        check(iterator == Collections.<Map.Entry<?,?>>emptyIterator());
         check(m.values().iterator() == emptyIterator());
         check(m.keySet().iterator() == emptyIterator());
         equal(m, unmodifiableMap(m));
@@ -88,12 +85,12 @@
         testEmptyCollection(m.values());
     }
 
-    <E> void testToArray(final Collection<E> c) {
+    void testToArray(final Collection<?> c) {
         Object[] a = c.toArray();
         equal(a.length, 0);
         equal(a.getClass().getComponentType(), Object.class);
         THROWS(NullPointerException.class,
-               new F(){void f(){ c.toArray((Object[])null); }});
+               new F(){void f(){ c.toArray(null); }});
 
         {
             String[] t = new String[0];
@@ -109,7 +106,7 @@
         }
     }
 
-    <E> void testEmptyCollection(final Collection<E> c) {
+    void testEmptyCollection(final Collection<?> c) {
         testEmptyIterator(c.iterator());
 
         check(c.iterator() == emptyIterator());

-Pavel

> On 10 Dec 2014, at 10:26, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> This looks good to me Amy. Do you need a sponsor ?
> 
> -Chris.
> 
> On 10/12/14 10:15, Amy Lu wrote:
>> Please review the fix for removing internal JDK API dependency from test
>> java/util/Collections/EmptyIterator.java
>> 
>> This test has dependency on sun.tools.java from one of it?s test case,
>> this fixed by using public API for the same testing purpose.
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8067112
>> webrev: http://cr.openjdk.java.net/~weijun/8067112/webrev.00/
>> 
>> Thanks,
>> Amy



From konstantin.shefov at oracle.com  Wed Dec 10 12:25:21 2014
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Wed, 10 Dec 2014 15:25:21 +0300
Subject: [9] Review request : JDK-8066798: [TEST] Make
	java/lang/invoke/LFCaching
	tests use lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java to
	define their number of iterations
In-Reply-To: <5486FE1F.8050608@oracle.com>
References: <5486B81B.5050200@oracle.com> <5486C0CC.4000908@oracle.com>
	<5486DAC9.5050108@oracle.com> <5486E4F4.4070103@oracle.com>
	<5486F31D.6020301@oracle.com> <5486FE1F.8050608@oracle.com>
Message-ID: <54883BB1.4060504@oracle.com>


On 09.12.2014 16:50, Igor Ignatyev wrote:
> on last thing to think about:
> does it make sense to move 'if (!run.passed) { ... } else { ... }' 
> code into TestRun class?
Yes, here is a webrev: http://cr.openjdk.java.net/~kshefov/8066798/webrev.03
>
>
> On 12/09/2014 04:03 PM, Konstantin Shefov wrote:
>> Igor,
>>
>> I changed the webrev: 
>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.02
>>
>> -Konstantin
>>
>> On 09.12.2014 15:03, Igor Ignatyev wrote:
>>> Konstantin,
>>>
>>> well, now I don't see any points to have a lambda. you can simple make
>>> it a method in TestRunInfo and rename TestRunInfo into TestRun.
>>>
>>>>  174 t.printStackTrace();
>>>>  175 System.err.println("FAILED");
>>> you don't print exception message.
>>>
>>> -- 
>>> Igor
>>>
>>> On 12/09/2014 02:19 PM, Konstantin Shefov wrote:
>>>> Hi Igor
>>>>
>>>> Thanks for reviewing.
>>>> I have made some changes, added a separate class to store the 
>>>> variables.
>>>> "doneIterations" is not local for lambda, it is incremented after each
>>>> lambda execution.
>>>> Also I changed to catch Exception.
>>>>
>>>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.01
>>>>
>>>> -Konstantin
>>>>
>>>> On 09.12.2014 12:28, Igor Ignatyev wrote:
>>>>> Hi Konstantin,
>>>>>
>>>>> 0. I don't like static variables which you introduced. were I you, 
>>>>> I'd
>>>>> create a class which encapsulates them.
>>>>> + it looks like
>>>>>  - doneIterations is a local for the lambda
>>>>>  - totalIterations is almost affectively final
>>>>>  - testCounter/failCounter are just informative variable and can be
>>>>> omitted
>>>>> so you just need a way to store/get passed value. that can be done 
>>>>> via
>>>>> mutable box, e.g. new boolean[1], AtomicBoolean.
>>>>>
>>>>> 1. why do you catch Throwable? please catch the most specific 
>>>>> exception
>>>>> 2. at lines 174-176, you lose exception information, it's better not
>>>>> to print exception's stack trace, but pass the exception to ctor of
>>>>> Error.
>>>>>
>>>>> Thanks,
>>>>> Igor
>>>>>
>>>>> On 12/09/2014 11:51 AM, Konstantin Shefov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the test enhancement
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066798
>>>>>> Webrev is http://cr.openjdk.java.net/~kshefov/8066798/webrev.00
>>>>>>
>>>>>> Test has been modified to use
>>>>>> lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java class to 
>>>>>> define
>>>>>> its number of iterations depending on the given timeout.
>>>>>> Also @ignore tag has been removed from
>>>>>> test/java/lang/invoke/LFCaching/LFGarbageCollectedTest.java because
>>>>>> JDK-8057020 has been fixed in JDK 9.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -Konstantin
>>>>>
>>>>
>>
>



From patrick at reini.net  Wed Dec 10 12:43:20 2014
From: patrick at reini.net (Patrick Reinhart)
Date: Wed, 10 Dec 2014 13:43:20 +0100
Subject: RFR JDK-8066867: Add InputStream transferTo to transfer content
	to an OutputStream
In-Reply-To: <1267B1BD-A304-46F1-A014-556B5567DE6B@oracle.com>
References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com>
	<ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>
	<25861DCC-C08B-40C3-A761-57413CF6D4C9@reini.net>
	<A839D7A2-0362-4185-90F8-D007BF12C03C@oracle.com>
	<52A53698-369F-49DF-BF5D-EFA550DAE4D0@oracle.com>
	<BF13BECA-1755-4944-B019-14B17536D694@reini.net>
	<1267B1BD-A304-46F1-A014-556B5567DE6B@oracle.com>
Message-ID: <09ACCC9A-33B2-42C5-B843-FF3308109AF4@reini.net>


> Apologies Patrick, that's me who misread you. I assume I had a mix of your
> reply, our recent conversation and David?s question in my head.

No problem


> About your actual reply. That's probably a matter of taste, since nowhere else
> except for this particular method this thing is not used (in java.nio.file.Files
> BUFFER_SIZE const is referenced 3 times).
> It's more like java.io.InputStream#MAX_SKIP_BUFFER_SIZE, which is more of an
> explanatory purpose than anything else, I suppose.
> 

You?re right, I would have added such a constant, as it could be used at least twice:

[..]
byte[] buffer = new byte[BUFFER_SIZE];
for (int read; (read = this.read(buffer, 0, BUFFER_SIZE)) > -1;
[..]

> -Pavel
> 
>> On 9 Dec 2014, at 23:05, Patrick Reinhart <patrick at reini.net> wrote:
>> 
>> You got exactly my point :-)  I will try to improve my english and express myself more clearly the next time ;-)
> 


-Patrick

From igor.ignatyev at oracle.com  Wed Dec 10 13:39:03 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 10 Dec 2014 16:39:03 +0300
Subject: [9] Review request : JDK-8066798: [TEST] Make
	java/lang/invoke/LFCaching
	tests use lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java to
	define their number of iterations
In-Reply-To: <54883BB1.4060504@oracle.com>
References: <5486B81B.5050200@oracle.com> <5486C0CC.4000908@oracle.com>
	<5486DAC9.5050108@oracle.com> <5486E4F4.4070103@oracle.com>
	<5486F31D.6020301@oracle.com> <5486FE1F.8050608@oracle.com>
	<54883BB1.4060504@oracle.com>
Message-ID: <54884CF7.60905@oracle.com>

>  147                     testCounter++;
>  148                 }

>  155             throw new Error(String.format("%d of %d test cases FAILED! %n"
>  156                     + "Rerun the test with the same \"-Dseed=\" option as in the log file!",
>  157                     failCounter, testCounter));
incorrect indent

>  System.err.println(String.format("All %d test cases PASSED!", testCounter));
PrintStream::printf

otherwise LGTM

Thanks,
Igor

On 12/10/2014 03:25 PM, Konstantin Shefov wrote:
>
> On 09.12.2014 16:50, Igor Ignatyev wrote:
>> on last thing to think about:
>> does it make sense to move 'if (!run.passed) { ... } else { ... }'
>> code into TestRun class?
> Yes, here is a webrev:
> http://cr.openjdk.java.net/~kshefov/8066798/webrev.03
>>
>>
>> On 12/09/2014 04:03 PM, Konstantin Shefov wrote:
>>> Igor,
>>>
>>> I changed the webrev:
>>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.02
>>>
>>> -Konstantin
>>>
>>> On 09.12.2014 15:03, Igor Ignatyev wrote:
>>>> Konstantin,
>>>>
>>>> well, now I don't see any points to have a lambda. you can simple make
>>>> it a method in TestRunInfo and rename TestRunInfo into TestRun.
>>>>
>>>>>  174 t.printStackTrace();
>>>>>  175 System.err.println("FAILED");
>>>> you don't print exception message.
>>>>
>>>> --
>>>> Igor
>>>>
>>>> On 12/09/2014 02:19 PM, Konstantin Shefov wrote:
>>>>> Hi Igor
>>>>>
>>>>> Thanks for reviewing.
>>>>> I have made some changes, added a separate class to store the
>>>>> variables.
>>>>> "doneIterations" is not local for lambda, it is incremented after each
>>>>> lambda execution.
>>>>> Also I changed to catch Exception.
>>>>>
>>>>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.01
>>>>>
>>>>> -Konstantin
>>>>>
>>>>> On 09.12.2014 12:28, Igor Ignatyev wrote:
>>>>>> Hi Konstantin,
>>>>>>
>>>>>> 0. I don't like static variables which you introduced. were I you,
>>>>>> I'd
>>>>>> create a class which encapsulates them.
>>>>>> + it looks like
>>>>>>  - doneIterations is a local for the lambda
>>>>>>  - totalIterations is almost affectively final
>>>>>>  - testCounter/failCounter are just informative variable and can be
>>>>>> omitted
>>>>>> so you just need a way to store/get passed value. that can be done
>>>>>> via
>>>>>> mutable box, e.g. new boolean[1], AtomicBoolean.
>>>>>>
>>>>>> 1. why do you catch Throwable? please catch the most specific
>>>>>> exception
>>>>>> 2. at lines 174-176, you lose exception information, it's better not
>>>>>> to print exception's stack trace, but pass the exception to ctor of
>>>>>> Error.
>>>>>>
>>>>>> Thanks,
>>>>>> Igor
>>>>>>
>>>>>> On 12/09/2014 11:51 AM, Konstantin Shefov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review the test enhancement
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066798
>>>>>>> Webrev is http://cr.openjdk.java.net/~kshefov/8066798/webrev.00
>>>>>>>
>>>>>>> Test has been modified to use
>>>>>>> lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java class to
>>>>>>> define
>>>>>>> its number of iterations depending on the given timeout.
>>>>>>> Also @ignore tag has been removed from
>>>>>>> test/java/lang/invoke/LFCaching/LFGarbageCollectedTest.java because
>>>>>>> JDK-8057020 has been fixed in JDK 9.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> -Konstantin
>>>>>>
>>>>>
>>>
>>
>


From amy.lu at oracle.com  Wed Dec 10 13:47:52 2014
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 10 Dec 2014 21:47:52 +0800
Subject: RFR 8067112: Update
	jdk/test/java/util/Collections/EmptyIterator.java
	to eliminate dependency on sun.tools.java
In-Reply-To: <54881FD5.2040003@oracle.com>
References: <54881D2B.5040107@oracle.com> <54881FD5.2040003@oracle.com>
Message-ID: <54884F08.2080301@oracle.com>

On 12/10/14 6:26 PM, Chris Hegarty wrote:
> This looks good to me Amy. Do you need a sponsor ?

Thank you Chris for your review.

Yes, please sponsor it.

Thanks,
Amy

>
> -Chris.
>
> On 10/12/14 10:15, Amy Lu wrote:
>> Please review the fix for removing internal JDK API dependency from test
>> java/util/Collections/EmptyIterator.java
>>
>> This test has dependency on sun.tools.java from one of it?s test case,
>> this fixed by using public API for the same testing purpose.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8067112
>> webrev: http://cr.openjdk.java.net/~weijun/8067112/webrev.00/
>>
>> Thanks,
>> Amy



From pavel.rappo at oracle.com  Wed Dec 10 14:38:55 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 10 Dec 2014 14:38:55 +0000
Subject: RFR JDK-8067127: Tags cleanup
Message-ID: <DB5303C0-D590-4A68-B22C-9C703DD2D0AB@oracle.com>

Hi everyone,

Could you please review my change for JDK-8067127?

http://cr.openjdk.java.net/~prappo/8067127/webrev.00/
http://cr.openjdk.java.net/~prappo/8067127/specdiff.00/java/io/package-summary.html

--------------------------------------------------------------------------
The purpose of this cleanup will be appreciated by people who mostly reads
javadoc in-place (in the file) and find this: 

* <p> The first byte read is stored into element {@code b[off]}, the next
* one into {@code b[off+1]}, and so on. The number of bytes read is, at
* most, equal to {@code len}. Let {@code k} be the number of bytes actually
* read; these bytes will be stored in elements {@code b[off]} through
* {@code b[off+k-1]}, leaving elements {@code b[off+k]} through {@code
* b[off+len-1]} unaffected.

a lot more preferable, than this (current version):

* <p> The first byte read is stored into element <code>b[off]</code>, the
* next one into <code>b[off+1]</code>, and so on. The number of bytes read
* is, at most, equal to <code>len</code>. Let <i>k</i> be the number of
* bytes actually read; these bytes will be stored in elements
* <code>b[off]</code> through <code>b[off+</code><i>k</i><code>-1]</code>,
* leaving elements <code>b[off+</code><i>k</i><code>]</code> through
* <code>b[off+len-1]</code> unaffected.

The overall goal of the parent task (JDK-8067126) though is to make it even less
wordy and more readable where possible:

* <p> The first byte read is stored into {@code b[0]}, the next
* one into {@code b[1]}, and so on. The number of bytes read is {@code <=
* b.length}. Let {@code k} be the number of bytes actually read; these
* bytes will be stored in elements {@code b[0]..b[k-1]}, leaving elements 
* {@code b[k]..b[b.length-1]} unaffected.

-Pavel



From konstantin.shefov at oracle.com  Wed Dec 10 15:01:32 2014
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Wed, 10 Dec 2014 18:01:32 +0300
Subject: [9] Review request : JDK-8066798: [TEST] Make
	java/lang/invoke/LFCaching
	tests use lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java to
	define their number of iterations
In-Reply-To: <54884CF7.60905@oracle.com>
References: <5486B81B.5050200@oracle.com> <5486C0CC.4000908@oracle.com>
	<5486DAC9.5050108@oracle.com> <5486E4F4.4070103@oracle.com>
	<5486F31D.6020301@oracle.com> <5486FE1F.8050608@oracle.com>
	<54883BB1.4060504@oracle.com> <54884CF7.60905@oracle.com>
Message-ID: <5488604C.8050901@oracle.com>

Igor, I changed to printf and indent:

http://cr.openjdk.java.net/~kshefov/8066798/webrev.04

-Konstantin

On 10.12.2014 16:39, Igor Ignatyev wrote:
>>  147                     testCounter++;
>>  148                 }
>
>>  155             throw new Error(String.format("%d of %d test cases 
>> FAILED! %n"
>>  156                     + "Rerun the test with the same \"-Dseed=\" 
>> option as in the log file!",
>>  157                     failCounter, testCounter));
> incorrect indent
>
>>  System.err.println(String.format("All %d test cases PASSED!", 
>> testCounter));
> PrintStream::printf
>
> otherwise LGTM
>
> Thanks,
> Igor
>
> On 12/10/2014 03:25 PM, Konstantin Shefov wrote:
>>
>> On 09.12.2014 16:50, Igor Ignatyev wrote:
>>> on last thing to think about:
>>> does it make sense to move 'if (!run.passed) { ... } else { ... }'
>>> code into TestRun class?
>> Yes, here is a webrev:
>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.03
>>>
>>>
>>> On 12/09/2014 04:03 PM, Konstantin Shefov wrote:
>>>> Igor,
>>>>
>>>> I changed the webrev:
>>>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.02
>>>>
>>>> -Konstantin
>>>>
>>>> On 09.12.2014 15:03, Igor Ignatyev wrote:
>>>>> Konstantin,
>>>>>
>>>>> well, now I don't see any points to have a lambda. you can simple 
>>>>> make
>>>>> it a method in TestRunInfo and rename TestRunInfo into TestRun.
>>>>>
>>>>>>  174 t.printStackTrace();
>>>>>>  175 System.err.println("FAILED");
>>>>> you don't print exception message.
>>>>>
>>>>> -- 
>>>>> Igor
>>>>>
>>>>> On 12/09/2014 02:19 PM, Konstantin Shefov wrote:
>>>>>> Hi Igor
>>>>>>
>>>>>> Thanks for reviewing.
>>>>>> I have made some changes, added a separate class to store the
>>>>>> variables.
>>>>>> "doneIterations" is not local for lambda, it is incremented after 
>>>>>> each
>>>>>> lambda execution.
>>>>>> Also I changed to catch Exception.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.01
>>>>>>
>>>>>> -Konstantin
>>>>>>
>>>>>> On 09.12.2014 12:28, Igor Ignatyev wrote:
>>>>>>> Hi Konstantin,
>>>>>>>
>>>>>>> 0. I don't like static variables which you introduced. were I you,
>>>>>>> I'd
>>>>>>> create a class which encapsulates them.
>>>>>>> + it looks like
>>>>>>>  - doneIterations is a local for the lambda
>>>>>>>  - totalIterations is almost affectively final
>>>>>>>  - testCounter/failCounter are just informative variable and can be
>>>>>>> omitted
>>>>>>> so you just need a way to store/get passed value. that can be done
>>>>>>> via
>>>>>>> mutable box, e.g. new boolean[1], AtomicBoolean.
>>>>>>>
>>>>>>> 1. why do you catch Throwable? please catch the most specific
>>>>>>> exception
>>>>>>> 2. at lines 174-176, you lose exception information, it's better 
>>>>>>> not
>>>>>>> to print exception's stack trace, but pass the exception to ctor of
>>>>>>> Error.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Igor
>>>>>>>
>>>>>>> On 12/09/2014 11:51 AM, Konstantin Shefov wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review the test enhancement
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066798
>>>>>>>> Webrev is http://cr.openjdk.java.net/~kshefov/8066798/webrev.00
>>>>>>>>
>>>>>>>> Test has been modified to use
>>>>>>>> lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java class to
>>>>>>>> define
>>>>>>>> its number of iterations depending on the given timeout.
>>>>>>>> Also @ignore tag has been removed from
>>>>>>>> test/java/lang/invoke/LFCaching/LFGarbageCollectedTest.java 
>>>>>>>> because
>>>>>>>> JDK-8057020 has been fixed in JDK 9.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> -Konstantin
>>>>>>>
>>>>>>
>>>>
>>>
>>



From igor.ignatyev at oracle.com  Wed Dec 10 15:05:35 2014
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 10 Dec 2014 18:05:35 +0300
Subject: [9] Review request : JDK-8066798: [TEST] Make
	java/lang/invoke/LFCaching
	tests use lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java to
	define their number of iterations
In-Reply-To: <5488604C.8050901@oracle.com>
References: <5486B81B.5050200@oracle.com> <5486C0CC.4000908@oracle.com>
	<5486DAC9.5050108@oracle.com> <5486E4F4.4070103@oracle.com>
	<5486F31D.6020301@oracle.com> <5486FE1F.8050608@oracle.com>
	<54883BB1.4060504@oracle.com> <54884CF7.60905@oracle.com>
	<5488604C.8050901@oracle.com>
Message-ID: <5488613F.50402@oracle.com>

cool. reviewed.

-- 
Igor
On 12/10/2014 06:01 PM, Konstantin Shefov wrote:
> Igor, I changed to printf and indent:
>
> http://cr.openjdk.java.net/~kshefov/8066798/webrev.04
>
> -Konstantin
>
> On 10.12.2014 16:39, Igor Ignatyev wrote:
>>>  147                     testCounter++;
>>>  148                 }
>>
>>>  155             throw new Error(String.format("%d of %d test cases
>>> FAILED! %n"
>>>  156                     + "Rerun the test with the same \"-Dseed=\"
>>> option as in the log file!",
>>>  157                     failCounter, testCounter));
>> incorrect indent
>>
>>>  System.err.println(String.format("All %d test cases PASSED!",
>>> testCounter));
>> PrintStream::printf
>>
>> otherwise LGTM
>>
>> Thanks,
>> Igor
>>
>> On 12/10/2014 03:25 PM, Konstantin Shefov wrote:
>>>
>>> On 09.12.2014 16:50, Igor Ignatyev wrote:
>>>> on last thing to think about:
>>>> does it make sense to move 'if (!run.passed) { ... } else { ... }'
>>>> code into TestRun class?
>>> Yes, here is a webrev:
>>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.03
>>>>
>>>>
>>>> On 12/09/2014 04:03 PM, Konstantin Shefov wrote:
>>>>> Igor,
>>>>>
>>>>> I changed the webrev:
>>>>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.02
>>>>>
>>>>> -Konstantin
>>>>>
>>>>> On 09.12.2014 15:03, Igor Ignatyev wrote:
>>>>>> Konstantin,
>>>>>>
>>>>>> well, now I don't see any points to have a lambda. you can simple
>>>>>> make
>>>>>> it a method in TestRunInfo and rename TestRunInfo into TestRun.
>>>>>>
>>>>>>>  174 t.printStackTrace();
>>>>>>>  175 System.err.println("FAILED");
>>>>>> you don't print exception message.
>>>>>>
>>>>>> --
>>>>>> Igor
>>>>>>
>>>>>> On 12/09/2014 02:19 PM, Konstantin Shefov wrote:
>>>>>>> Hi Igor
>>>>>>>
>>>>>>> Thanks for reviewing.
>>>>>>> I have made some changes, added a separate class to store the
>>>>>>> variables.
>>>>>>> "doneIterations" is not local for lambda, it is incremented after
>>>>>>> each
>>>>>>> lambda execution.
>>>>>>> Also I changed to catch Exception.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.01
>>>>>>>
>>>>>>> -Konstantin
>>>>>>>
>>>>>>> On 09.12.2014 12:28, Igor Ignatyev wrote:
>>>>>>>> Hi Konstantin,
>>>>>>>>
>>>>>>>> 0. I don't like static variables which you introduced. were I you,
>>>>>>>> I'd
>>>>>>>> create a class which encapsulates them.
>>>>>>>> + it looks like
>>>>>>>>  - doneIterations is a local for the lambda
>>>>>>>>  - totalIterations is almost affectively final
>>>>>>>>  - testCounter/failCounter are just informative variable and can be
>>>>>>>> omitted
>>>>>>>> so you just need a way to store/get passed value. that can be done
>>>>>>>> via
>>>>>>>> mutable box, e.g. new boolean[1], AtomicBoolean.
>>>>>>>>
>>>>>>>> 1. why do you catch Throwable? please catch the most specific
>>>>>>>> exception
>>>>>>>> 2. at lines 174-176, you lose exception information, it's better
>>>>>>>> not
>>>>>>>> to print exception's stack trace, but pass the exception to ctor of
>>>>>>>> Error.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Igor
>>>>>>>>
>>>>>>>> On 12/09/2014 11:51 AM, Konstantin Shefov wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review the test enhancement
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066798
>>>>>>>>> Webrev is http://cr.openjdk.java.net/~kshefov/8066798/webrev.00
>>>>>>>>>
>>>>>>>>> Test has been modified to use
>>>>>>>>> lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java class to
>>>>>>>>> define
>>>>>>>>> its number of iterations depending on the given timeout.
>>>>>>>>> Also @ignore tag has been removed from
>>>>>>>>> test/java/lang/invoke/LFCaching/LFGarbageCollectedTest.java
>>>>>>>>> because
>>>>>>>>> JDK-8057020 has been fixed in JDK 9.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> -Konstantin
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>


From mark.reinhold at oracle.com  Wed Dec 10 16:16:02 2014
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 10 Dec 2014 08:16:02 -0800
Subject: RFR JDK-8067127: Tags cleanup
In-Reply-To: <DB5303C0-D590-4A68-B22C-9C703DD2D0AB@oracle.com>
References: <DB5303C0-D590-4A68-B22C-9C703DD2D0AB@oracle.com>
Message-ID: <20141210081602.813543@eggemoggin.niobe.net>

2014/12/10 6:38 -0800, pavel.rappo at oracle.com:
> ...
> 
> The overall goal of the parent task (JDK-8067126) though is to make it even less
> wordy and more readable where possible:
> 
> * <p> The first byte read is stored into {@code b[0]}, the next
> * one into {@code b[1]}, and so on. The number of bytes read is {@code <=
> * b.length}. Let {@code k} be the number of bytes actually read; these
> * bytes will be stored in elements {@code b[0]..b[k-1]}, leaving elements 
> * {@code b[k]..b[b.length-1]} unaffected.

I'm all for brevity, but I don't see how this last version is an
improvement.  The phrase "the number of bytes read is <= b.length", in
particular, is jarring since it switches abruptly from prose to symbols;
the original "the number of bytes read is, at most, equal to len" is far
preferable.

You've also changed the meaning of the specification, since b.length
might not be equal to len.

The javadoc for JCP-standard API elements is not just documentation,
it's a specification, and so it must be treated with great care.  It's
the basis of the conformance tests, and hence a foundation of Java's
overall compatibility story.  We must not change its meaning by mistake.

- Mark


From pavel.rappo at oracle.com  Wed Dec 10 17:07:54 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Wed, 10 Dec 2014 17:07:54 +0000
Subject: RFR JDK-8067127: Tags cleanup
In-Reply-To: <20141210081602.813543@eggemoggin.niobe.net>
References: <DB5303C0-D590-4A68-B22C-9C703DD2D0AB@oracle.com>
	<20141210081602.813543@eggemoggin.niobe.net>
Message-ID: <CB7F09A7-DB24-4C97-B522-F67ACE9D78B9@oracle.com>


> ...I don't see how this last version is an
> improvement.  The phrase "the number of bytes read is <= b.length", in
> particular, is jarring since it switches abruptly from prose to symbols;
> the original "the number of bytes read is, at most, equal to len" is far
> preferable.

Agreed. And yet sometimes javadocs in this area are very wordy:

"...If <code>len</code> is not zero..."

or

"...This value should always be nonnegative and not larger than the value of
<code>count</code>..."

or

"...If the value of the <tt>len</tt> parameter is negative then no characters
are written..."

etc.

> You've also changed the meaning of the specification, since b.length
> might not be equal to len.

Thanks for pointing this out! My mistake. This example was not reviewed as 
carefully as the webrev, so yes, it's a mistake. And no, it's not in the webrev.
It was taken from the second read that takes byte[] as a sole argument (without
offset and length).

> The javadoc for JCP-standard API elements is not just documentation,
> it's a specification, and so it must be treated with great care.  It's
> the basis of the conformance tests, and hence a foundation of Java's
> overall compatibility story.  We must not change its meaning by mistake.

Yes, that's why we have code reviews and other processes. In the webrev though
there are only markup changes. I believe they are not a part of the spec.

-Pavel



From roger.riggs at oracle.com  Wed Dec 10 17:20:59 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Wed, 10 Dec 2014 12:20:59 -0500
Subject: RFR JDK-8067127: Tags cleanup
In-Reply-To: <CB7F09A7-DB24-4C97-B522-F67ACE9D78B9@oracle.com>
References: <DB5303C0-D590-4A68-B22C-9C703DD2D0AB@oracle.com>	<20141210081602.813543@eggemoggin.niobe.net>
	<CB7F09A7-DB24-4C97-B522-F67ACE9D78B9@oracle.com>
Message-ID: <548880FB.7030004@oracle.com>

Hi Pavel,

I'd stick to just fixing the html formatting; leave the language alone.
If the wording is changed even slightly, it makes the review more difficult
and usually does not make a significant improvement.

BTW, some of the JCK test tools are keyed off the exact wording (think 
checksum)
and changing the wording means a manual review of the tests in question.
It might also trigger the need for a CCC.

Roger

On 12/10/2014 12:07 PM, Pavel Rappo wrote:
>> ...I don't see how this last version is an
>> improvement.  The phrase "the number of bytes read is <= b.length", in
>> particular, is jarring since it switches abruptly from prose to symbols;
>> the original "the number of bytes read is, at most, equal to len" is far
>> preferable.
> Agreed. And yet sometimes javadocs in this area are very wordy:
>
> "...If <code>len</code> is not zero..."
>
> or
>
> "...This value should always be nonnegative and not larger than the value of
> <code>count</code>..."
>
> or
>
> "...If the value of the <tt>len</tt> parameter is negative then no characters
> are written..."
>
> etc.
>
>> You've also changed the meaning of the specification, since b.length
>> might not be equal to len.
> Thanks for pointing this out! My mistake. This example was not reviewed as
> carefully as the webrev, so yes, it's a mistake. And no, it's not in the webrev.
> It was taken from the second read that takes byte[] as a sole argument (without
> offset and length).
>
>> The javadoc for JCP-standard API elements is not just documentation,
>> it's a specification, and so it must be treated with great care.  It's
>> the basis of the conformance tests, and hence a foundation of Java's
>> overall compatibility story.  We must not change its meaning by mistake.
> Yes, that's why we have code reviews and other processes. In the webrev though
> there are only markup changes. I believe they are not a part of the spec.
>
> -Pavel
>



From martinrb at google.com  Wed Dec 10 17:31:42 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 10 Dec 2014 09:31:42 -0800
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <5487E1B2.6050409@oracle.com>
References: <CA+kOe0-kaVGdNyaLN2Yo0H4KnM1AU3N=nFryazZP1VbqK9t=Kw@mail.gmail.com>
	<NFBBKALFDCPFIDBNKAPCAEJJKLAA.davidcholmes@aapt.net.au>
	<CA+kOe09b_3-08pOt171PYedGoT0Bp5X1HOA7B+PHzCSRMkx6wQ@mail.gmail.com>
	<54867C1F.1090106@oracle.com>
	<CA+kOe09aURqjRRk_gF8JtCAaJk+Fja8pTYmNY-B=DS7wuWXr1w@mail.gmail.com>
	<5487E1B2.6050409@oracle.com>
Message-ID: <CA+kOe0-4ar_QmcaO=Ac_n3yHPjG+yA=AzSZSsyTuRxPehQQffg@mail.gmail.com>

Today I Leaned
that "release fence" and "acquire fence" are technical terms defined
in the C/C++ 11 standards.

So my latest version reads instead:

     * Ensures that loads and stores before the fence will not be reordered with
     * stores after the fence; a "StoreStore plus LoadStore barrier".
     *
     * Corresponds to C11 atomic_thread_fence(memory_order_release)
     * (a "release fence").


From xueming.shen at oracle.com  Wed Dec 10 19:05:11 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 10 Dec 2014 11:05:11 -0800
Subject: RFR JDK-8046219: (str spec) String(byte[], int, int, Charset) should
	be clearer when IndexOutOfBoundsException is thrown
Message-ID: <54889967.3010102@oracle.com>

Hi

Please help review this doc only change, in which the rewording precisely specifies
when the IndexOutOfBoundsException should be thrown, while be compatible with
the long standing behavior.

issue: https://bugs.openjdk.java.net/browse/JDK-8046219
webrev: http://cr.openjdk.java.net/~sherman/8046219

Thanks!
-Sherman


From lance.andersen at oracle.com  Wed Dec 10 19:07:25 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 10 Dec 2014 14:07:25 -0500
Subject: RFR JDK-8046219: (str spec) String(byte[], int, int,
	Charset) should be clearer when IndexOutOfBoundsException is thrown
In-Reply-To: <54889967.3010102@oracle.com>
References: <54889967.3010102@oracle.com>
Message-ID: <9675FA7F-82A2-4F6E-8A78-AE75E33DA2CC@oracle.com>

The wording changes seem clear Sherman


On Dec 10, 2014, at 2:05 PM, Xueming Shen <xueming.shen at oracle.com> wrote:

> Hi
> 
> Please help review this doc only change, in which the rewording precisely specifies
> when the IndexOutOfBoundsException should be thrown, while be compatible with
> the long standing behavior.
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8046219
> webrev: http://cr.openjdk.java.net/~sherman/8046219
> 
> Thanks!
> -Sherman



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





From tristan.yan at oracle.com  Wed Dec 10 20:42:31 2014
From: tristan.yan at oracle.com (Tristan Yan)
Date: Wed, 10 Dec 2014 12:42:31 -0800
Subject: RFR 8067183: TEST_BUG:File locked when processing the cleanup on test
	jaxp/test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerFactoryTest.java
Message-ID: <7862D882-8B4A-43AC-B896-A5BA8D721A1D@oracle.com>

Hi All

Could you please review a small fix for JAXP test bug. We found this one in JPRT running. It?s caused by resource isn?t released correctly.

webrev: http://cr.openjdk.java.net/~tyan/8067183/webrev.01/ <http://cr.openjdk.java.net/~tyan/8067183/webrev.01/>
bug: https://bugs.openjdk.java.net/browse/JDK-8067183 <https://bugs.openjdk.java.net/browse/JDK-8067183>

Thank you
Tristan

From aph at redhat.com  Wed Dec 10 21:02:39 2014
From: aph at redhat.com (Andrew Haley)
Date: Wed, 10 Dec 2014 21:02:39 +0000
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <CA+kOe08OC57hEgGR-3CSfsJUMVSk-_mCmZK2Gd=3tpkE9=6j_w@mail.gmail.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>	<5481108A.3030605@oracle.com>
	<CA+kOe08OC57hEgGR-3CSfsJUMVSk-_mCmZK2Gd=3tpkE9=6j_w@mail.gmail.com>
Message-ID: <5488B4EF.6060103@redhat.com>

On 12/05/2014 09:49 PM, Martin Buchholz wrote:
> The actual implementations of storestore (see below) seem to
> universally give you the stronger ::release barrier, and it seems
> likely that hotspot engineers are implicitly relying on that, that
> some uses of ::storestore in the hotspot sources are bugs (should be
> ::release instead) and that there is very little potential performance
> benefit from using ::storestore instead of ::release, precisely
> because the additional loadstore barrier is very close to free on all
> current hardware.

That's not really true for ARM, where the additional loadstore requires
a full barrier.  There is a good use for a storestore, which is when
zeroing a newly-created object.

Andrew.



From huizhe.wang at oracle.com  Wed Dec 10 21:49:53 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 10 Dec 2014 13:49:53 -0800
Subject: RFR 8067183: TEST_BUG:File locked when processing the cleanup
	on test
	jaxp/test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerFactoryTest.java
In-Reply-To: <7862D882-8B4A-43AC-B896-A5BA8D721A1D@oracle.com>
References: <7862D882-8B4A-43AC-B896-A5BA8D721A1D@oracle.com>
Message-ID: <5488C001.2050304@oracle.com>

Hi Tristan,

Thanks for the fix, looks good.  I also agree that we do further 
improvement/clean-up (such as failUnexpected as Lance pointed out) 
across all tests migrated.

Thanks,
Joe

On 12/10/2014 12:42 PM, Tristan Yan wrote:
> Hi All
>
> Could you please review a small fix for JAXP test bug. We found this 
> one in JPRT running. It?s caused by resource isn?t released correctly.
>
> webrev: http://cr.openjdk.java.net/~tyan/8067183/webrev.01/ 
> <http://cr.openjdk.java.net/%7Etyan/8067183/webrev.01/>
> bug: https://bugs.openjdk.java.net/browse/JDK-8067183
>
> Thank you
> Tristan



From lance.andersen at oracle.com  Wed Dec 10 21:52:10 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 10 Dec 2014 16:52:10 -0500
Subject: RFR 8067183: TEST_BUG:File locked when processing the cleanup on
	test
	jaxp/test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerFactoryTest.java
In-Reply-To: <7862D882-8B4A-43AC-B896-A5BA8D721A1D@oracle.com>
References: <7862D882-8B4A-43AC-B896-A5BA8D721A1D@oracle.com>
Message-ID: <3FE49C7E-B55E-4FC7-9B64-208C6E5ADF98@oracle.com>

looks ok tristan

best
lance
On Dec 10, 2014, at 3:42 PM, Tristan Yan <tristan.yan at oracle.com> wrote:

> Hi All
> 
> Could you please review a small fix for JAXP test bug. We found this one in JPRT running. It?s caused by resource isn?t released correctly.
> 
> webrev: http://cr.openjdk.java.net/~tyan/8067183/webrev.01/ <http://cr.openjdk.java.net/~tyan/8067183/webrev.01/>
> bug: https://bugs.openjdk.java.net/browse/JDK-8067183 <https://bugs.openjdk.java.net/browse/JDK-8067183>
> 
> Thank you
> Tristan



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





From tristan.yan at oracle.com  Wed Dec 10 22:02:53 2014
From: tristan.yan at oracle.com (tristan yan)
Date: Wed, 10 Dec 2014 14:02:53 -0800
Subject: RFR 8067183: TEST_BUG:File locked when processing the cleanup
	on test
	jaxp/test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerFactoryTest.java
In-Reply-To: <5488C001.2050304@oracle.com>
References: <7862D882-8B4A-43AC-B896-A5BA8D721A1D@oracle.com>
	<5488C001.2050304@oracle.com>
Message-ID: <5488C30D.3060206@oracle.com>

Thank you. Could you sponsor this for me.
Tristan

On 12/10/2014 1:49 PM, huizhe wang wrote:
> Hi Tristan,
>
> Thanks for the fix, looks good.  I also agree that we do further 
> improvement/clean-up (such as failUnexpected as Lance pointed out) 
> across all tests migrated.
>
> Thanks,
> Joe
>
> On 12/10/2014 12:42 PM, Tristan Yan wrote:
>> Hi All
>>
>> Could you please review a small fix for JAXP test bug. We found this 
>> one in JPRT running. It?s caused by resource isn?t released correctly.
>>
>> webrev: http://cr.openjdk.java.net/~tyan/8067183/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Etyan/8067183/webrev.01/>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8067183
>>
>> Thank you
>> Tristan
>



From oleksandr.otenko at oracle.com  Wed Dec 10 22:58:33 2014
From: oleksandr.otenko at oracle.com (Oleksandr Otenko)
Date: Wed, 10 Dec 2014 22:58:33 +0000
Subject: [concurrency-interest] RFR:
	8065804:JEP171:Clarifications/corrections for fence intrinsics
In-Reply-To: <1417028404335.73215@devexperts.com>
References: <c806b219426c4c8aa9e5bfa79fc9901d@exchmb02.office.devexperts.com>	<NFBBKALFDCPFIDBNKAPCIECNKLAA.davidcholmes@aapt.net.au>	<74ff42b06c314fc9998d512725bae69a@exchmb02.office.devexperts.com>,
	<54760CD7.9070704@flyingtroika.com>
	<1417028404335.73215@devexperts.com>
Message-ID: <5488D019.2020200@oracle.com>

This surely does not mean that on non-TSO architectures it is not 
possible to implement linearizable algorithms.

Nor does it mean that the algorithm will contain /independent/ writes.

Count the proofs that rely on synchronization order. That's the measure 
of how common IRIW pattern is. And yet, even then there is hope.

Suppose, a<b means a happens before b. There are only a few axioms 
coming from memory model:

order consistency: a<b -> b<a -> _|_    -- if you can prove a happens 
before b and b happens before a, it implies absurd

(semi-formally)
read consistency: (r v x) -> (exists (w v x) such that (w v x) < (r v x) 
&& ((w v y) -> (w v y) < (w v x) || (r v x) < (w v y)))  -- for every 
read r of variable v with value x there is a write w of value x such 
that the write happens before the read and all other writes either 
happen before this write, or happen after the read.

That's about it.

Then totality of order axiom is:
total order : a -> b -> ((a < b || b < a) && (a < b -> _|_) -> b < a && 
(b < a -> _|_) -> a < b)   -- for any two volatile operations, they are 
ordered in some way, and if you can prove a happens before b is absurd, 
then b happens before a, and converse. (the latter two things follow 
from order consistency, but stated here explicitly for comparison with 
the following)

DMB barrier on non-TSO is a different axiom:
dmb : a -> b -> c -> (a `po` b) -> ((a < c || c < b) && (c < b -> _|_) 
-> a < c && (a < c -> _|_) -> c < b)  -- for any two operations a and b 
with program order between them, a dmb barrier for any other operation c 
either proves a happens before c, or c happens before b, and if you can 
prove c happens before b is absurd, then it implies a happens before c, 
and the converse. Slight difference in reasoning from total order is 
that proving a<c does not exclude the possibility that in some other way 
c<b.

You can see many similarities between total order and DMB. The 
difficulty with IRIW case is only that there is just one write in each 
thread, so DMB has to enforce ordering between reads instead. And the 
difficulty with DMB is that, unlike volatile stores, there is no 
language-level idiom for it - you need to consider more than one entity 
to understand the effect, and more than one place in code. Total order, 
of course, is far easier to reason about - any two operations are 
ordered, and their ordering is exclusive, so you only need to look in 
one place.


Alex


On 26/11/2014 19:00, Roman Elizarov wrote:
>
> I'd suggest to start with the original paper by Herlihy who had come 
> up with the concept of Linearizability in 1990:
>
> Linearizability: A Correctness Condition for Concurrent Objects
>
> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.142.5315
>
>
> There were lot of reasearch about linearizability since then (there 
> are almost a thouthand citations for this arcticle) expanding and 
> improving proof techniquies and applying it. There were no 
> breakthroughs of the comparable magnitude since then. All 
> "thread-safe" objects that you enconter in the modern word are 
> linearizable. It is a defacto "golden standard" correctness condition 
> for concurrent objects.
>
>
> This position is well deserved, because having lineariazable objects 
> as your building blocks makes it super-easy to formally reason about 
> correctness of your code. You will rarely encouter concurrent 
> algorithms that provide weaker guarantees (like quescient 
> consistency), because they all too hard to reason about -- they are 
> either not composable or not local. But when all your 
> concurrent objects are linearizable, then you can ditch 
> happens-before, forget that everything is actually parallel and 
> simply reason about your code in terms of interleaving of "atomic" 
> operations that happen in some global order. That is the beauty of 
> linearizability.
>
>
> But Linearizability is indeed a pretty strong requirement. 
> Linearizability of your shared memory requires that Independent Reads 
> of Independent Writes (IRIW) are consistent. Can you get away with 
> some weaker requirement and still get all the same goodies as 
> linearizability gets you? I have not seen anything promising in this 
> direction. Whoever makes this breakthrough will surely reap the 
> world's recognition and respect.
>
>
> /Roman
>
>
> ------------------------------------------------------------------------
> *??:* DT <dt at flyingtroika.com>
> *??????????:* 26 ?????? 2014 ?. 20:24
> *????:* Roman Elizarov; dholmes at ieee.org; Hans Boehm
> *?????:* core-libs-dev; concurrency-interest at cs.oswego.edu
> *????:* Re: [concurrency-interest] RFR: 
> 8065804:JEP171:Clarifications/corrections for fence intrinsics
> Roman,
> Can you point to any specific article providing the concurrency 
> problem statement with a further proof using linearizability to reason 
> about solution.
>
> Thanks,
> DT
>
> On 11/26/2014 2:59 AM, Roman Elizarov wrote:
>>
>> Whether IRIW has any _/practical/_ uses is definitely subject to 
>> debate. However, there is no tractable way for formal reasoning about 
>> properties of large concurrent systems, but via linearizability. 
>> Linearizability is the only property that is both local and 
>> hierarchical. It lets you build more complex linearizable algorithms 
>> from simpler ones, having quite succinct and compelling proofs at 
>> each step.
>>
>> In other words, if you want to be able to construct a formal proof 
>> that your [large] concurrent system if correct, then you must have 
>> IRIW consistency. Do you need a formal proof of correctness? Maybe 
>> not. In many applications hand-waving is enough,  but there are many 
>> other applications where hand-waving does not count as a proof. It 
>> may be possible to construct formal correctness proofs for some very 
>> simple algorithms even on a system that does not provide IRIW, but 
>> this is beyond the state of the art of formal verification for 
>> anything sufficiently complex.
>>
>> /Roman
>>
>> *From:*David Holmes [mailto:davidcholmes at aapt.net.au]
>> *Sent:* Wednesday, November 26, 2014 11:54 AM
>> *To:* Roman Elizarov; Hans Boehm
>> *Cc:* concurrency-interest at cs.oswego.edu; core-libs-dev
>> *Subject:* RE: [concurrency-interest] RFR: 
>> 8065804:JEP171:Clarifications/corrections for fence intrinsics
>>
>> Can you expand on that please. All previous discussion of IRIW I have 
>> seen indicated that the property, while a consequence of existing JMM 
>> rules, had no practical use.
>>
>> Thanks,
>>
>> David
>>
>>     -----Original Message-----
>>     *From:* Roman Elizarov [mailto:elizarov at devexperts.com]
>>     *Sent:* Wednesday, 26 November 2014 6:49 PM
>>     *To:* dholmes at ieee.org <mailto:dholmes at ieee.org>; Hans Boehm
>>     *Cc:* concurrency-interest at cs.oswego.edu
>>     <mailto:concurrency-interest at cs.oswego.edu>; core-libs-dev
>>     *Subject:* RE: [concurrency-interest] RFR:
>>     8065804:JEP171:Clarifications/corrections for fence intrinsics
>>
>>     There is no conceivable way to kill IRIW consistency requirement
>>     while retaining ability to prove correctness of large software
>>     systems. If IRIW of volatile variables are not consistent, then
>>     volatile reads and writes are not linearizable, which breaks
>>     linearizabiliy of all higher-level primitives build on top of
>>     them and makes formal reasoning about behavior of concurrent
>>     systems practically impossible. There are many fields where this
>>     is not acceptable.
>>
>>     /Roman
>>
>>     *From:*concurrency-interest-bounces at cs.oswego.edu
>>     <mailto:concurrency-interest-bounces at cs.oswego.edu>
>>     [mailto:concurrency-interest-bounces at cs.oswego.edu] *On Behalf Of
>>     *David Holmes
>>     *Sent:* Wednesday, November 26, 2014 5:11 AM
>>     *To:* Hans Boehm
>>     *Cc:* concurrency-interest at cs.oswego.edu
>>     <mailto:concurrency-interest at cs.oswego.edu>; core-libs-dev
>>     *Subject:* Re: [concurrency-interest] RFR: 8065804:
>>     JEP171:Clarifications/corrections for fence intrinsics
>>
>>     Hi Hans,
>>
>>     Given IRIW is a thorn in everyone's side and has no known useful
>>     benefit, and can hopefully be killed off in the future, lets not
>>     get bogged down in IRIW. But none of what you say below relates
>>     to multi-copy-atomicity.
>>
>>     Cheers,
>>
>>     David
>>
>>         -----Original Message-----
>>         *From:* hjkhboehm at gmail.com
>>         <mailto:hjkhboehm at gmail.com>[mailto:hjkhboehm at gmail.com]*On
>>         Behalf Of *Hans Boehm
>>         *Sent:* Wednesday, 26 November 2014 12:04 PM
>>         *To:* dholmes at ieee.org <mailto:dholmes at ieee.org>
>>         *Cc:* Stephan Diestelhorst;
>>         concurrency-interest at cs.oswego.edu
>>         <mailto:concurrency-interest at cs.oswego.edu>; core-libs-dev
>>         *Subject:* Re: [concurrency-interest] RFR: 8065804:
>>         JEP171:Clarifications/corrections for fence intrinsics
>>
>>         To be concrete here, on Power, loads can normally be ordered
>>         by an address dependency or light-weight fence (lwsync).
>>         However, neither is enough to prevent the questionable
>>         outcome for IRIW, since it doesn't ensure that the stores in
>>         T1 and T2 will be made visible to other threads in a
>>         consistent order. That outcome can be prevented by using
>>         heavyweight fences (sync) instructions between the loads
>>         instead.  Peter Sewell's group concluded that to enforce
>>         correct volatile behavior on Power, you essentially need a a
>>         heavyweight fence between every pair of volatile operations
>>         on Power.  That cannot be understood based on simple ordering
>>         constraints.
>>
>>         As Stephan pointed out, there are similar issues on ARM, but
>>         they're less commonly encountered in a Java implementation.
>>         If you're lucky, you can get to the right implementation
>>         recipe by looking at only reordering, I think.
>>
>>         On Tue, Nov 25, 2014 at 4:36 PM, David Holmes
>>         <davidcholmes at aapt.net.au <mailto:davidcholmes at aapt.net.au>>
>>         wrote:
>>
>>             Stephan Diestelhorst writes:
>>             >
>>             > David Holmes wrote:
>>             > > Stephan Diestelhorst writes:
>>             > > > Am Dienstag, 25. November 2014, 11:15:36 schrieb
>>             Hans Boehm:
>>             > > > > I'm no hardware architect, but fundamentally it
>>             seems to me that
>>             > > > >
>>             > > > > load x
>>             > > > > acquire_fence
>>             > > > >
>>             > > > > imposes a much more stringent constraint than
>>             > > > >
>>             > > > > load_acquire x
>>             > > > >
>>             > > > > Consider the case in which the load from x is an
>>             L1 hit, but a
>>             > > > > preceding load (from say y) is a long-latency
>>             miss.  If we enforce
>>             > > > > ordering by just waiting for completion of prior
>>             operation, the
>>             > > > > former has to wait for the load from y to
>>             complete; while the
>>             > > > > latter doesn't.  I find it hard to believe that
>>             this doesn't leave
>>             > > > > an appreciable amount of performance on the
>>             table, at least for
>>             > > > > some interesting microarchitectures.
>>             > > >
>>             > > > I agree, Hans, that this is a reasonable
>>             assumption.  Load_acquire x
>>             > > > does allow roach motel, whereas the acquire fence
>>             does not.
>>             > > >
>>             > > > >  In addition, for better or worse, fencing
>>             requirements on at least
>>             > > > >  Power are actually driven as much by store
>>             atomicity issues, as by
>>             > > > >  the ordering issues discussed in the cookbook. 
>>             This was not
>>             > > > >  understood in 2005, and unfortunately doesn't
>>             seem to be
>>             > amenable to
>>             > > > >  the kind of straightforward explanation as in
>>             Doug's cookbook.
>>             > > >
>>             > > > Coming from a strongly ordered architecture to a
>>             weakly ordered one
>>             > > > myself, I also needed some mental adjustment about
>>             store (multi-copy)
>>             > > > atomicity.  I can imagine others will be unaware of
>>             this difference,
>>             > > > too, even in 2014.
>>             > >
>>             > > Sorry I'm missing the connection between fences and
>>             multi-copy
>>             > atomicity.
>>             >
>>             > One example is the classic IRIW. With non-multi copy
>>             atomic stores, but
>>             > ordered (say through a dependency) loads in the
>>             following example:
>>             >
>>             > Memory: foo = bar = 0
>>             > _T1_         _T2_         _T3_                       _T4_
>>             > st (foo),1   st (bar),1   ld r1, (bar)                 
>>                 ld r3,(foo)
>>             >                           <addr dep / local "fence"
>>             here>   <addr dep>
>>             >                           ld r2, (foo)                 
>>                 ld r4, (bar)
>>             >
>>             > You may observe r1 = 1, r2 = 0, r3 = 1, r4 = 0 on
>>             non-multi-copy atomic
>>             > machines.  On TSO boxes, this is not possible.  That
>>             means that the
>>             > memory fence that will prevent such a behaviour (DMB on
>>             ARM) needs to
>>             > carry some additional oomph in ensuring multi-copy
>>             atomicity, or rather
>>             > prevent you from seeing it (which is the same thing).
>>
>>             I take it as given that any code for which you may have
>>             ordering
>>             constraints, must first have basic atomicity properties
>>             for loads and
>>             stores. I would not expect any kind of fence to add
>>             multi-copy-atomicity
>>             where there was none.
>>
>>             David
>>
>>
>>             > Stephan
>>             >
>>             > _______________________________________________
>>             > Concurrency-interest mailing list
>>             > Concurrency-interest at cs.oswego.edu
>>             <mailto:Concurrency-interest at cs.oswego.edu>
>>             > http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>             _______________________________________________
>>             Concurrency-interest mailing list
>>             Concurrency-interest at cs.oswego.edu
>>             <mailto:Concurrency-interest at cs.oswego.edu>
>>             http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



From huizhe.wang at oracle.com  Thu Dec 11 00:38:35 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Wed, 10 Dec 2014 16:38:35 -0800
Subject: RFR 8067183: TEST_BUG:File locked when processing the cleanup
	on test
	jaxp/test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerFactoryTest.java
In-Reply-To: <5488C30D.3060206@oracle.com>
References: <7862D882-8B4A-43AC-B896-A5BA8D721A1D@oracle.com>
	<5488C001.2050304@oracle.com> <5488C30D.3060206@oracle.com>
Message-ID: <5488E78B.20603@oracle.com>

Done.

Joe

On 12/10/2014 2:02 PM, tristan yan wrote:
> Thank you. Could you sponsor this for me.
> Tristan
>
> On 12/10/2014 1:49 PM, huizhe wang wrote:
>> Hi Tristan,
>>
>> Thanks for the fix, looks good.  I also agree that we do further 
>> improvement/clean-up (such as failUnexpected as Lance pointed out) 
>> across all tests migrated.
>>
>> Thanks,
>> Joe
>>
>> On 12/10/2014 12:42 PM, Tristan Yan wrote:
>>> Hi All
>>>
>>> Could you please review a small fix for JAXP test bug. We found this 
>>> one in JPRT running. It?s caused by resource isn?t released correctly.
>>>
>>> webrev: http://cr.openjdk.java.net/~tyan/8067183/webrev.01/ 
>>> <http://cr.openjdk.java.net/%7Etyan/8067183/webrev.01/>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8067183
>>>
>>> Thank you
>>> Tristan
>>
>



From david.holmes at oracle.com  Thu Dec 11 00:52:02 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 11 Dec 2014 10:52:02 +1000
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <CA+kOe0-4ar_QmcaO=Ac_n3yHPjG+yA=AzSZSsyTuRxPehQQffg@mail.gmail.com>
References: <CA+kOe0-kaVGdNyaLN2Yo0H4KnM1AU3N=nFryazZP1VbqK9t=Kw@mail.gmail.com>	<NFBBKALFDCPFIDBNKAPCAEJJKLAA.davidcholmes@aapt.net.au>	<CA+kOe09b_3-08pOt171PYedGoT0Bp5X1HOA7B+PHzCSRMkx6wQ@mail.gmail.com>	<54867C1F.1090106@oracle.com>	<CA+kOe09aURqjRRk_gF8JtCAaJk+Fja8pTYmNY-B=DS7wuWXr1w@mail.gmail.com>	<5487E1B2.6050409@oracle.com>
	<CA+kOe0-4ar_QmcaO=Ac_n3yHPjG+yA=AzSZSsyTuRxPehQQffg@mail.gmail.com>
Message-ID: <5488EAB2.9030502@oracle.com>

On 11/12/2014 3:31 AM, Martin Buchholz wrote:
> Today I Leaned
> that "release fence" and "acquire fence" are technical terms defined
> in the C/C++ 11 standards.
>
> So my latest version reads instead:
>
>       * Ensures that loads and stores before the fence will not be reordered with
>       * stores after the fence; a "StoreStore plus LoadStore barrier".
>       *
>       * Corresponds to C11 atomic_thread_fence(memory_order_release)
>       * (a "release fence").

Thank you Martin - I find the updated wording much more appropriate.

For the email record, as I have written in the bug report, I think the 
"correction" of the semantics for storeFence have resulted in 
problematic naming where storeFence and loadFence have opposite 
directionality constraints but the names suggest the same directionality 
constraints. Had the original API suggested these names with the revised 
semantics I would have argued against them. This area is confusing 
enough without adding to that confusion with names that don't suggest 
the action.

David



From david.holmes at oracle.com  Thu Dec 11 00:53:29 2014
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 11 Dec 2014 10:53:29 +1000
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <5488B4EF.6060103@redhat.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>	<5481108A.3030605@oracle.com>
	<CA+kOe08OC57hEgGR-3CSfsJUMVSk-_mCmZK2Gd=3tpkE9=6j_w@mail.gmail.com>
	<5488B4EF.6060103@redhat.com>
Message-ID: <5488EB09.9000501@oracle.com>

On 11/12/2014 7:02 AM, Andrew Haley wrote:
> On 12/05/2014 09:49 PM, Martin Buchholz wrote:
>> The actual implementations of storestore (see below) seem to
>> universally give you the stronger ::release barrier, and it seems
>> likely that hotspot engineers are implicitly relying on that, that
>> some uses of ::storestore in the hotspot sources are bugs (should be
>> ::release instead) and that there is very little potential performance
>> benefit from using ::storestore instead of ::release, precisely
>> because the additional loadstore barrier is very close to free on all
>> current hardware.
>
> That's not really true for ARM, where the additional loadstore requires
> a full barrier.  There is a good use for a storestore, which is when
> zeroing a newly-created object.

There are many good uses of storestore in the various lock-free 
algorithms inside hotspot.

David

> Andrew.
>


From martinrb at google.com  Thu Dec 11 03:07:52 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 10 Dec 2014 19:07:52 -0800
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <5488EAB2.9030502@oracle.com>
References: <CA+kOe0-kaVGdNyaLN2Yo0H4KnM1AU3N=nFryazZP1VbqK9t=Kw@mail.gmail.com>
	<NFBBKALFDCPFIDBNKAPCAEJJKLAA.davidcholmes@aapt.net.au>
	<CA+kOe09b_3-08pOt171PYedGoT0Bp5X1HOA7B+PHzCSRMkx6wQ@mail.gmail.com>
	<54867C1F.1090106@oracle.com>
	<CA+kOe09aURqjRRk_gF8JtCAaJk+Fja8pTYmNY-B=DS7wuWXr1w@mail.gmail.com>
	<5487E1B2.6050409@oracle.com>
	<CA+kOe0-4ar_QmcaO=Ac_n3yHPjG+yA=AzSZSsyTuRxPehQQffg@mail.gmail.com>
	<5488EAB2.9030502@oracle.com>
Message-ID: <CA+kOe08hoqBjoDxJCyydemPed1icSQs_ix754V8hs2Pz1WeMQw@mail.gmail.com>

On Wed, Dec 10, 2014 at 4:52 PM, David Holmes <david.holmes at oracle.com> wrote:

> For the email record, as I have written in the bug report, I think the
> "correction" of the semantics for storeFence have resulted in problematic
> naming where storeFence and loadFence have opposite directionality
> constraints but the names suggest the same directionality constraints. Had
> the original API suggested these names with the revised semantics I would
> have argued against them. This area is confusing enough without adding to
> that confusion with names that don't suggest the action.

I also dislike the names of the "atomic" methods in Unsafe and would
like to align them as much as possible with C/C++ 11 atomics
nomenclature.


From martinrb at google.com  Thu Dec 11 03:28:07 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 10 Dec 2014 19:28:07 -0800
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <5488B4EF.6060103@redhat.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>
	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>
	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>
	<5481108A.3030605@oracle.com>
	<CA+kOe08OC57hEgGR-3CSfsJUMVSk-_mCmZK2Gd=3tpkE9=6j_w@mail.gmail.com>
	<5488B4EF.6060103@redhat.com>
Message-ID: <CA+kOe0-88aotGAJiZynp2EhcHmh-7FKhvJWzdwijHEMEk63spg@mail.gmail.com>

On Wed, Dec 10, 2014 at 1:02 PM, Andrew Haley <aph at redhat.com> wrote:
> On 12/05/2014 09:49 PM, Martin Buchholz wrote:
>> The actual implementations of storestore (see below) seem to
>> universally give you the stronger ::release barrier, and it seems
>> likely that hotspot engineers are implicitly relying on that, that
>> some uses of ::storestore in the hotspot sources are bugs (should be
>> ::release instead) and that there is very little potential performance
>> benefit from using ::storestore instead of ::release, precisely
>> because the additional loadstore barrier is very close to free on all
>> current hardware.
>
> That's not really true for ARM, where the additional loadstore requires
> a full barrier.  There is a good use for a storestore, which is when
> zeroing a newly-created object.

Andrew and David,

I agree that given ARM's decision to provide the choice of StoreStore
and full fences, hotspot is right to use them in a few carefully
chosen places, like object initializers.

But ARM's decision seems poor to me. No mainstream language (like
C/C++ or Java) is likely to support those in any way accessible to
user programs (not even via Java Unsafe).  Making their StoreStore
barrier also do LoadStore would dramatically increase the
applicability of their instruction with low cost.  Maybe it's not too
late for ARM to do so.


From aph at redhat.com  Thu Dec 11 09:08:11 2014
From: aph at redhat.com (Andrew Haley)
Date: Thu, 11 Dec 2014 09:08:11 +0000
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <5488EB09.9000501@oracle.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>	<5481108A.3030605@oracle.com>
	<CA+kOe08OC57hEgGR-3CSfsJUMVSk-_mCmZK2Gd=3tpkE9=6j_w@mail.gmail.com>
	<5488B4EF.6060103@redhat.com> <5488EB09.9000501@oracle.com>
Message-ID: <54895EFB.3060204@redhat.com>

On 11/12/14 00:53, David Holmes wrote:
> On 11/12/2014 7:02 AM, Andrew Haley wrote:
>> On 12/05/2014 09:49 PM, Martin Buchholz wrote:
>>> The actual implementations of storestore (see below) seem to
>>> universally give you the stronger ::release barrier, and it seems
>>> likely that hotspot engineers are implicitly relying on that, that
>>> some uses of ::storestore in the hotspot sources are bugs (should be
>>> ::release instead) and that there is very little potential performance
>>> benefit from using ::storestore instead of ::release, precisely
>>> because the additional loadstore barrier is very close to free on all
>>> current hardware.
>>
>> That's not really true for ARM, where the additional loadstore requires
>> a full barrier.  There is a good use for a storestore, which is when
>> zeroing a newly-created object.
> 
> There are many good uses of storestore in the various lock-free 
> algorithms inside hotspot.

There may be many uses, but I am extremely suspicious of how good
they are.  I wonder if we went through all the uses of storestore in
hotspot how many bugs we'd find.  As far as I can see (in the absence
of other barriers) the only things you can write before a storestore
are constants.

Andrew.


From konstantin.shefov at oracle.com  Thu Dec 11 11:07:32 2014
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Thu, 11 Dec 2014 14:07:32 +0300
Subject: [9] Review request : JDK-8066798: [TEST] Make
	java/lang/invoke/LFCaching
	tests use lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java to
	define their number of iterations
In-Reply-To: <5488613F.50402@oracle.com>
References: <5486B81B.5050200@oracle.com> <5486C0CC.4000908@oracle.com>
	<5486DAC9.5050108@oracle.com> <5486E4F4.4070103@oracle.com>
	<5486F31D.6020301@oracle.com> <5486FE1F.8050608@oracle.com>
	<54883BB1.4060504@oracle.com> <54884CF7.60905@oracle.com>
	<5488604C.8050901@oracle.com> <5488613F.50402@oracle.com>
Message-ID: <54897AF4.1060302@oracle.com>

Vladimir, Paul,

Please, look at this fix 
http://cr.openjdk.java.net/~kshefov/8066798/webrev.04

Thanks
-Konstantin

On 10.12.2014 18:05, Igor Ignatyev wrote:
> cool. reviewed.
>
> -- 
> Igor
> On 12/10/2014 06:01 PM, Konstantin Shefov wrote:
>> Igor, I changed to printf and indent:
>>
>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.04
>>
>> -Konstantin
>>
>> On 10.12.2014 16:39, Igor Ignatyev wrote:
>>>>  147 testCounter++;
>>>>  148                 }
>>>
>>>>  155 throw new Error(String.format("%d of %d test cases
>>>> FAILED! %n"
>>>>  156                     + "Rerun the test with the same \"-Dseed=\"
>>>> option as in the log file!",
>>>>  157                     failCounter, testCounter));
>>> incorrect indent
>>>
>>>>  System.err.println(String.format("All %d test cases PASSED!",
>>>> testCounter));
>>> PrintStream::printf
>>>
>>> otherwise LGTM
>>>
>>> Thanks,
>>> Igor
>>>
>>> On 12/10/2014 03:25 PM, Konstantin Shefov wrote:
>>>>
>>>> On 09.12.2014 16:50, Igor Ignatyev wrote:
>>>>> on last thing to think about:
>>>>> does it make sense to move 'if (!run.passed) { ... } else { ... }'
>>>>> code into TestRun class?
>>>> Yes, here is a webrev:
>>>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.03
>>>>>
>>>>>
>>>>> On 12/09/2014 04:03 PM, Konstantin Shefov wrote:
>>>>>> Igor,
>>>>>>
>>>>>> I changed the webrev:
>>>>>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.02
>>>>>>
>>>>>> -Konstantin
>>>>>>
>>>>>> On 09.12.2014 15:03, Igor Ignatyev wrote:
>>>>>>> Konstantin,
>>>>>>>
>>>>>>> well, now I don't see any points to have a lambda. you can simple
>>>>>>> make
>>>>>>> it a method in TestRunInfo and rename TestRunInfo into TestRun.
>>>>>>>
>>>>>>>>  174 t.printStackTrace();
>>>>>>>>  175 System.err.println("FAILED");
>>>>>>> you don't print exception message.
>>>>>>>
>>>>>>> -- 
>>>>>>> Igor
>>>>>>>
>>>>>>> On 12/09/2014 02:19 PM, Konstantin Shefov wrote:
>>>>>>>> Hi Igor
>>>>>>>>
>>>>>>>> Thanks for reviewing.
>>>>>>>> I have made some changes, added a separate class to store the
>>>>>>>> variables.
>>>>>>>> "doneIterations" is not local for lambda, it is incremented after
>>>>>>>> each
>>>>>>>> lambda execution.
>>>>>>>> Also I changed to catch Exception.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.01
>>>>>>>>
>>>>>>>> -Konstantin
>>>>>>>>
>>>>>>>> On 09.12.2014 12:28, Igor Ignatyev wrote:
>>>>>>>>> Hi Konstantin,
>>>>>>>>>
>>>>>>>>> 0. I don't like static variables which you introduced. were I 
>>>>>>>>> you,
>>>>>>>>> I'd
>>>>>>>>> create a class which encapsulates them.
>>>>>>>>> + it looks like
>>>>>>>>>  - doneIterations is a local for the lambda
>>>>>>>>>  - totalIterations is almost affectively final
>>>>>>>>>  - testCounter/failCounter are just informative variable and 
>>>>>>>>> can be
>>>>>>>>> omitted
>>>>>>>>> so you just need a way to store/get passed value. that can be 
>>>>>>>>> done
>>>>>>>>> via
>>>>>>>>> mutable box, e.g. new boolean[1], AtomicBoolean.
>>>>>>>>>
>>>>>>>>> 1. why do you catch Throwable? please catch the most specific
>>>>>>>>> exception
>>>>>>>>> 2. at lines 174-176, you lose exception information, it's better
>>>>>>>>> not
>>>>>>>>> to print exception's stack trace, but pass the exception to 
>>>>>>>>> ctor of
>>>>>>>>> Error.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Igor
>>>>>>>>>
>>>>>>>>> On 12/09/2014 11:51 AM, Konstantin Shefov wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Please review the test enhancement
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066798
>>>>>>>>>> Webrev is http://cr.openjdk.java.net/~kshefov/8066798/webrev.00
>>>>>>>>>>
>>>>>>>>>> Test has been modified to use
>>>>>>>>>> lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java class to
>>>>>>>>>> define
>>>>>>>>>> its number of iterations depending on the given timeout.
>>>>>>>>>> Also @ignore tag has been removed from
>>>>>>>>>> test/java/lang/invoke/LFCaching/LFGarbageCollectedTest.java
>>>>>>>>>> because
>>>>>>>>>> JDK-8057020 has been fixed in JDK 9.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> -Konstantin
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>



From konstantin.shefov at oracle.com  Thu Dec 11 11:09:23 2014
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Thu, 11 Dec 2014 14:09:23 +0300
Subject: [9] Review request : JDK-6933879: URISyntaxException when
	non-alphanumeric characters are present in scope_id
In-Reply-To: <54886510.1010704@oracle.com>
References: <54886510.1010704@oracle.com>
Message-ID: <54897B63.30801@oracle.com>

CC'ed core-libs-dev at openjdk.java.net

On 10.12.2014 18:21, Konstantin Shefov wrote:
> Hello,
>
> Please, review the bug fix: 
> https://bugs.openjdk.java.net/browse/JDK-6933879
> Webrev: http://cr.openjdk.java.net/~kshefov/6933879/webrev.00
>
> It is suggested to add some more symbols allowed for scope id in IPv6 
> URI, namely "_", "." and ":", because these symbols may be included in 
> network interface names. Now only alphanumeric characters are allowed 
> to be in a scope id.
>
> Thanks
> -Konstantin



From vladimir.x.ivanov at oracle.com  Thu Dec 11 11:14:41 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 11 Dec 2014 14:14:41 +0300
Subject: [9] Review request : JDK-8066798: [TEST] Make
	java/lang/invoke/LFCaching
	tests use lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java to
	define their number of iterations
In-Reply-To: <54897AF4.1060302@oracle.com>
References: <5486B81B.5050200@oracle.com> <5486C0CC.4000908@oracle.com>
	<5486DAC9.5050108@oracle.com> <5486E4F4.4070103@oracle.com>
	<5486F31D.6020301@oracle.com> <5486FE1F.8050608@oracle.com>
	<54883BB1.4060504@oracle.com> <54884CF7.60905@oracle.com>
	<5488604C.8050901@oracle.com> <5488613F.50402@oracle.com>
	<54897AF4.1060302@oracle.com>
Message-ID: <54897CA1.8020206@oracle.com>

Looks good.

Best regards,
Vladimir Ivanov

On 12/11/14, 2:07 PM, Konstantin Shefov wrote:
> Vladimir, Paul,
>
> Please, look at this fix
> http://cr.openjdk.java.net/~kshefov/8066798/webrev.04
>
> Thanks
> -Konstantin
>
> On 10.12.2014 18:05, Igor Ignatyev wrote:
>> cool. reviewed.
>>
>> --
>> Igor
>> On 12/10/2014 06:01 PM, Konstantin Shefov wrote:
>>> Igor, I changed to printf and indent:
>>>
>>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.04
>>>
>>> -Konstantin
>>>
>>> On 10.12.2014 16:39, Igor Ignatyev wrote:
>>>>>  147 testCounter++;
>>>>>  148                 }
>>>>
>>>>>  155 throw new Error(String.format("%d of %d test cases
>>>>> FAILED! %n"
>>>>>  156                     + "Rerun the test with the same \"-Dseed=\"
>>>>> option as in the log file!",
>>>>>  157                     failCounter, testCounter));
>>>> incorrect indent
>>>>
>>>>>  System.err.println(String.format("All %d test cases PASSED!",
>>>>> testCounter));
>>>> PrintStream::printf
>>>>
>>>> otherwise LGTM
>>>>
>>>> Thanks,
>>>> Igor
>>>>
>>>> On 12/10/2014 03:25 PM, Konstantin Shefov wrote:
>>>>>
>>>>> On 09.12.2014 16:50, Igor Ignatyev wrote:
>>>>>> on last thing to think about:
>>>>>> does it make sense to move 'if (!run.passed) { ... } else { ... }'
>>>>>> code into TestRun class?
>>>>> Yes, here is a webrev:
>>>>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.03
>>>>>>
>>>>>>
>>>>>> On 12/09/2014 04:03 PM, Konstantin Shefov wrote:
>>>>>>> Igor,
>>>>>>>
>>>>>>> I changed the webrev:
>>>>>>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.02
>>>>>>>
>>>>>>> -Konstantin
>>>>>>>
>>>>>>> On 09.12.2014 15:03, Igor Ignatyev wrote:
>>>>>>>> Konstantin,
>>>>>>>>
>>>>>>>> well, now I don't see any points to have a lambda. you can simple
>>>>>>>> make
>>>>>>>> it a method in TestRunInfo and rename TestRunInfo into TestRun.
>>>>>>>>
>>>>>>>>>  174 t.printStackTrace();
>>>>>>>>>  175 System.err.println("FAILED");
>>>>>>>> you don't print exception message.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Igor
>>>>>>>>
>>>>>>>> On 12/09/2014 02:19 PM, Konstantin Shefov wrote:
>>>>>>>>> Hi Igor
>>>>>>>>>
>>>>>>>>> Thanks for reviewing.
>>>>>>>>> I have made some changes, added a separate class to store the
>>>>>>>>> variables.
>>>>>>>>> "doneIterations" is not local for lambda, it is incremented after
>>>>>>>>> each
>>>>>>>>> lambda execution.
>>>>>>>>> Also I changed to catch Exception.
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~kshefov/8066798/webrev.01
>>>>>>>>>
>>>>>>>>> -Konstantin
>>>>>>>>>
>>>>>>>>> On 09.12.2014 12:28, Igor Ignatyev wrote:
>>>>>>>>>> Hi Konstantin,
>>>>>>>>>>
>>>>>>>>>> 0. I don't like static variables which you introduced. were I
>>>>>>>>>> you,
>>>>>>>>>> I'd
>>>>>>>>>> create a class which encapsulates them.
>>>>>>>>>> + it looks like
>>>>>>>>>>  - doneIterations is a local for the lambda
>>>>>>>>>>  - totalIterations is almost affectively final
>>>>>>>>>>  - testCounter/failCounter are just informative variable and
>>>>>>>>>> can be
>>>>>>>>>> omitted
>>>>>>>>>> so you just need a way to store/get passed value. that can be
>>>>>>>>>> done
>>>>>>>>>> via
>>>>>>>>>> mutable box, e.g. new boolean[1], AtomicBoolean.
>>>>>>>>>>
>>>>>>>>>> 1. why do you catch Throwable? please catch the most specific
>>>>>>>>>> exception
>>>>>>>>>> 2. at lines 174-176, you lose exception information, it's better
>>>>>>>>>> not
>>>>>>>>>> to print exception's stack trace, but pass the exception to
>>>>>>>>>> ctor of
>>>>>>>>>> Error.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Igor
>>>>>>>>>>
>>>>>>>>>> On 12/09/2014 11:51 AM, Konstantin Shefov wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> Please review the test enhancement
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8066798
>>>>>>>>>>> Webrev is http://cr.openjdk.java.net/~kshefov/8066798/webrev.00
>>>>>>>>>>>
>>>>>>>>>>> Test has been modified to use
>>>>>>>>>>> lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java class to
>>>>>>>>>>> define
>>>>>>>>>>> its number of iterations depending on the given timeout.
>>>>>>>>>>> Also @ignore tag has been removed from
>>>>>>>>>>> test/java/lang/invoke/LFCaching/LFGarbageCollectedTest.java
>>>>>>>>>>> because
>>>>>>>>>>> JDK-8057020 has been fixed in JDK 9.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>> -Konstantin
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>


From tristan.yan at oracle.com  Thu Dec 11 14:38:48 2014
From: tristan.yan at oracle.com (Tristan Yan)
Date: Thu, 11 Dec 2014 06:38:48 -0800
Subject: RFR: JDK-8065673: Makefile enable JAXP tests running
Message-ID: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com>

Hi everyone

Could you please to review this small makefile change for JAXP tests

http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.00/ <http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.00/>
http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/ <http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/>

corresponding bug is https://bugs.openjdk.java.net/browse/JDK-8065673 <https://bugs.openjdk.java.net/browse/JDK-8065673>

Here is the background for this change.
As you may know we?ve pushed some new jaxp tests into openjdk. Since these tests have been put into different repo with current idk tests. We need a makefile to support these tests running in jprt system and nightly. In the future, we may put these tests back to idk repo, we have to maintain a consistent makefile with current idk tests. So I steal the makefile from idk test repo and make minimal change as possible. 
For supporting running tests in jprt system one new target(jaxp_test) has been added in top level makefile and jaxp_test will be considered as part of core testset.

Thank you very much.
Tristan

From Alan.Bateman at oracle.com  Thu Dec 11 15:07:53 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Dec 2014 15:07:53 +0000
Subject: RFR: JDK-8065673: Makefile enable JAXP tests running
In-Reply-To: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com>
References: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com>
Message-ID: <5489B349.6040009@oracle.com>

On 11/12/2014 14:38, Tristan Yan wrote:
> Hi everyone
>
> Could you please to review this small makefile change for JAXP tests
>
> http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.00/ <http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.00/>
> http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/ <http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/>
>
> corresponding bug is https://bugs.openjdk.java.net/browse/JDK-8065673 <https://bugs.openjdk.java.net/browse/JDK-8065673>
>
> Here is the background for this change.
> As you may know we?ve pushed some new jaxp tests into openjdk. Since these tests have been put into different repo with current idk tests. We need a makefile to support these tests running in jprt system and nightly. In the future, we may put these tests back to idk repo, we have to maintain a consistent makefile with current idk tests. So I steal the makefile from idk test repo and make minimal change as possible.
> For supporting running tests in jprt system one new target(jaxp_test) has been added in top level makefile and jaxp_test will be considered as part of core testset.
>
The alternative to adding this to the "core" testset is to create a new 
testset ("jaxp" or "xml" for example). You could then include this in 
the "pit" testset so that it runs langtools, core, svc, and jaxp.

-Alan


From chris.hegarty at oracle.com  Thu Dec 11 15:29:40 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 11 Dec 2014 15:29:40 +0000
Subject: [9] Review request : JDK-6933879: URISyntaxException when
	non-alphanumeric characters are present in scope_id
In-Reply-To: <54897B63.30801@oracle.com>
References: <54886510.1010704@oracle.com> <54897B63.30801@oracle.com>
Message-ID: <19036153-CA73-435C-B1EA-7335D632927E@oracle.com>

On 11 Dec 2014, at 11:09, Konstantin Shefov <konstantin.shefov at oracle.com> wrote:

> CC'ed core-libs-dev at openjdk.java.net
> 
> On 10.12.2014 18:21, Konstantin Shefov wrote:
>> Hello,
>> 
>> Please, review the bug fix: https://bugs.openjdk.java.net/browse/JDK-6933879
>> Webrev: http://cr.openjdk.java.net/~kshefov/6933879/webrev.00
>> 
>> It is suggested to add some more symbols allowed for scope id in IPv6 URI, namely "_", "." and ":", because these symbols may be included in network interface names. Now only alphanumeric characters are allowed to be in a scope id.

From Inet6Address, "Textual representation of IPv6 scoped addresses? [1] :

  ??
   As a string. This must be the exact string that is returned by
   NetworkInterface.getName() for the particular interface in
   question. When an Inet6Address is created in this way, the
   numeric scope-id is determined at the time the object is
   created by querying the relevant NetworkInterface."

Have you seen NetworkInterface.getName() return names with ?_?, ?.?, or ?:?  ,or is this theoretical ?

-Chris.

[1] http://docs.oracle.com/javase/8/docs/api/java/net/Inet6Address.html#scoped


>> Thanks
>> -Konstantin
> 



From huizhe.wang at oracle.com  Thu Dec 11 17:46:13 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 11 Dec 2014 09:46:13 -0800
Subject: RFR: JDK-8065673: Makefile enable JAXP tests running
In-Reply-To: <5489B349.6040009@oracle.com>
References: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com>
	<5489B349.6040009@oracle.com>
Message-ID: <5489D865.2060705@oracle.com>


On 12/11/2014 7:07 AM, Alan Bateman wrote:
> On 11/12/2014 14:38, Tristan Yan wrote:
>> Hi everyone
>>
>> Could you please to review this small makefile change for JAXP tests
>>
>> http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.00/ 
>> <http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.00/>
>> http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/ 
>> <http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/>
>>
>> corresponding bug is https://bugs.openjdk.java.net/browse/JDK-8065673 
>> <https://bugs.openjdk.java.net/browse/JDK-8065673>
>>
>> Here is the background for this change.
>> As you may know we?ve pushed some new jaxp tests into openjdk. Since 
>> these tests have been put into different repo with current idk tests. 
>> We need a makefile to support these tests running in jprt system and 
>> nightly. In the future, we may put these tests back to idk repo, we 
>> have to maintain a consistent makefile with current idk tests. So I 
>> steal the makefile from idk test repo and make minimal change as 
>> possible.
>> For supporting running tests in jprt system one new target(jaxp_test) 
>> has been added in top level makefile and jaxp_test will be considered 
>> as part of core testset.
>>
> The alternative to adding this to the "core" testset is to create a 
> new testset ("jaxp" or "xml" for example). You could then include this 
> in the "pit" testset so that it runs langtools, core, svc, and jaxp.

Ok, we'll add a new testset "jaxp".

-Joe

>
> -Alan



From staffan.friberg at oracle.com  Thu Dec 11 19:19:14 2014
From: staffan.friberg at oracle.com (Staffan Friberg)
Date: Thu, 11 Dec 2014 11:19:14 -0800
Subject: JDK 9 RFR of JDK-8067289 (XS): Fix deprecation warnings in java.base
	module - CRC32C
Message-ID: <5489EE32.3070507@oracle.com>

Hi,

Here is a small fix that avoids calling deprecated sun.misc.Unsafe 
methods, which allows the @SuppressWarnings to be removed.

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

Regards,
Staffan


From joe.darcy at oracle.com  Thu Dec 11 19:23:35 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 11 Dec 2014 11:23:35 -0800
Subject: JDK 9 RFR of JDK-8067289 (XS): Fix deprecation warnings in
	java.base module - CRC32C
In-Reply-To: <5489EE32.3070507@oracle.com>
References: <5489EE32.3070507@oracle.com>
Message-ID: <5489EF37.20405@oracle.com>

Hi Staffan,

I haven't examined the code for possible integer overflow cases, but it 
would be fundamentally safer if the values were promoted to long 
*before* the arithmetic rather than after. In other words, instead of

     (long)(Unsafe.ARRAY_BYTE_BASE_OFFSET + off) // Overflow 
theoretically possible

use

     (long)Unsafe.ARRAY_BYTE_BASE_OFFSET + off // No overflow worries 
with int inputs

-Joe

On 12/11/2014 11:19 AM, Staffan Friberg wrote:
> Hi,
>
> Here is a small fix that avoids calling deprecated sun.misc.Unsafe 
> methods, which allows the @SuppressWarnings to be removed.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8067289
> Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8067289/webrev.00
>
> Regards,
> Staffan



From forax at univ-mlv.fr  Thu Dec 11 20:09:51 2014
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 11 Dec 2014 21:09:51 +0100
Subject: JDK 9 RFR of JDK-8067289 (XS): Fix deprecation warnings in
	java.base module - CRC32C
In-Reply-To: <5489EF37.20405@oracle.com>
References: <5489EE32.3070507@oracle.com> <5489EF37.20405@oracle.com>
Message-ID: <5489FA0F.9040909@univ-mlv.fr>

At the same time, if you have an overflow here, it means that you are 
able to create an int array (a int[]) with a size which is greater than 
2G (minus the offset).

R?mi

On 12/11/2014 08:23 PM, joe darcy wrote:
> Hi Staffan,
>
> I haven't examined the code for possible integer overflow cases, but 
> it would be fundamentally safer if the values were promoted to long 
> *before* the arithmetic rather than after. In other words, instead of
>
>     (long)(Unsafe.ARRAY_BYTE_BASE_OFFSET + off) // Overflow 
> theoretically possible
>
> use
>
>     (long)Unsafe.ARRAY_BYTE_BASE_OFFSET + off // No overflow worries 
> with int inputs
>
> -Joe
>
> On 12/11/2014 11:19 AM, Staffan Friberg wrote:
>> Hi,
>>
>> Here is a small fix that avoids calling deprecated sun.misc.Unsafe 
>> methods, which allows the @SuppressWarnings to be removed.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067289
>> Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8067289/webrev.00
>>
>> Regards,
>> Staffan
>



From tristan.yan at oracle.com  Thu Dec 11 21:10:03 2014
From: tristan.yan at oracle.com (Tristan Yan)
Date: Thu, 11 Dec 2014 13:10:03 -0800
Subject: RFR: JDK-8065673: Makefile enable JAXP tests running
In-Reply-To: <5489D865.2060705@oracle.com>
References: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com>
	<5489B349.6040009@oracle.com> <5489D865.2060705@oracle.com>
Message-ID: <35DC236D-FD79-4D93-AA8C-70390402BE1C@oracle.com>

Thanks Alan and Joe
I added jaxp testset, now jaxp_tests is under jaxp testset only. Also I have added jaxp testset to pit.

http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.01/ <http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.01/>
http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/ <http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/>

Thanks


> On Dec 11, 2014, at 9:46 AM, huizhe wang <huizhe.wang at oracle.com> wrote:
> 
> 
> On 12/11/2014 7:07 AM, Alan Bateman wrote:
>> On 11/12/2014 14:38, Tristan Yan wrote:
>>> Hi everyone
>>> 
>>> Could you please to review this small makefile change for JAXP tests
>>> 
>>> http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.00/ <http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.00/>
>>> http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/ <http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/>
>>> 
>>> corresponding bug is https://bugs.openjdk.java.net/browse/JDK-8065673 <https://bugs.openjdk.java.net/browse/JDK-8065673>
>>> 
>>> Here is the background for this change.
>>> As you may know we?ve pushed some new jaxp tests into openjdk. Since these tests have been put into different repo with current idk tests. We need a makefile to support these tests running in jprt system and nightly. In the future, we may put these tests back to idk repo, we have to maintain a consistent makefile with current idk tests. So I steal the makefile from idk test repo and make minimal change as possible.
>>> For supporting running tests in jprt system one new target(jaxp_test) has been added in top level makefile and jaxp_test will be considered as part of core testset.
>>> 
>> The alternative to adding this to the "core" testset is to create a new testset ("jaxp" or "xml" for example). You could then include this in the "pit" testset so that it runs langtools, core, svc, and jaxp.
> 
> Ok, we'll add a new testset "jaxp".
> 
> -Joe
> 
>> 
>> -Alan
> 



From staffan.friberg at oracle.com  Fri Dec 12 01:25:24 2014
From: staffan.friberg at oracle.com (Staffan Friberg)
Date: Thu, 11 Dec 2014 17:25:24 -0800
Subject: JDK 9 RFR of JDK-8067289 (XS): Fix deprecation warnings in
	java.base module - CRC32C
In-Reply-To: <5489EF37.20405@oracle.com>
References: <5489EE32.3070507@oracle.com> <5489EF37.20405@oracle.com>
Message-ID: <548A4404.7000905@oracle.com>

Hi Joe,

Good point. Updated webrev, 
http://cr.openjdk.java.net/~sfriberg/JDK-8067289/webrev.01

Regards,
Staffan

On 12/11/2014 11:23 AM, joe darcy wrote:
> Hi Staffan,
>
> I haven't examined the code for possible integer overflow cases, but 
> it would be fundamentally safer if the values were promoted to long 
> *before* the arithmetic rather than after. In other words, instead of
>
>     (long)(Unsafe.ARRAY_BYTE_BASE_OFFSET + off) // Overflow 
> theoretically possible
>
> use
>
>     (long)Unsafe.ARRAY_BYTE_BASE_OFFSET + off // No overflow worries 
> with int inputs
>
> -Joe
>
> On 12/11/2014 11:19 AM, Staffan Friberg wrote:
>> Hi,
>>
>> Here is a small fix that avoids calling deprecated sun.misc.Unsafe 
>> methods, which allows the @SuppressWarnings to be removed.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067289
>> Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8067289/webrev.00
>>
>> Regards,
>> Staffan
>



From stuart.marks at oracle.com  Fri Dec 12 01:56:35 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 11 Dec 2014 17:56:35 -0800
Subject: RFR(xs): 8066633: Fix deprecation warnings in java.rmi module
Message-ID: <548A4B53.3010902@oracle.com>

Hi all,

Please review this tiny fix to remove the source of a deprecation warning and to 
remove the now-unnecessary suppression of deprecation warnings from its context.

There are other deprecated usages mentioned in this bug report but for a variety 
of reasons they either cannot be removed or aren't worth removing. This instance 
is the only one left.

Patch appended below.

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

Thanks,

s'marks


# HG changeset patch
# User smarks
# Date 1418349197 28800
#      Thu Dec 11 17:53:17 2014 -0800
# Node ID 04cfafe160978b6f99f9609f0ad559d4f70829af
# Parent  420a1b6caaf4114e082c55faf63c67b20337528c
8066633: Fix deprecation warnings in java.rmi module
Reviewed-by: XXX

diff -r 420a1b6caaf4 -r 04cfafe16097 
src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java
--- a/src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java	Thu Dec 11 
17:09:46 2014 -0800
+++ b/src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java	Thu Dec 11 
17:53:17 2014 -0800
@@ -336,13 +336,12 @@
       * Main program to start a registry. <br>
       * The port number can be specified on the command line.
       */
-    @SuppressWarnings("deprecation")
      public static void main(String args[])
      {
          // Create and install the security manager if one is not installed
          // already.
          if (System.getSecurityManager() == null) {
-            System.setSecurityManager(new RMISecurityManager());
+            System.setSecurityManager(new SecurityManager());
          }

          try {


From joe.darcy at oracle.com  Fri Dec 12 01:57:09 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 11 Dec 2014 17:57:09 -0800
Subject: RFR(xs): 8066633: Fix deprecation warnings in java.rmi module
In-Reply-To: <548A4B53.3010902@oracle.com>
References: <548A4B53.3010902@oracle.com>
Message-ID: <548A4B75.9020409@oracle.com>

Hi Stuart,

Looks good!

Thanks for fixing this,

-Joe

On 12/11/2014 5:56 PM, Stuart Marks wrote:
> Hi all,
>
> Please review this tiny fix to remove the source of a deprecation 
> warning and to remove the now-unnecessary suppression of deprecation 
> warnings from its context.
>
> There are other deprecated usages mentioned in this bug report but for 
> a variety of reasons they either cannot be removed or aren't worth 
> removing. This instance is the only one left.
>
> Patch appended below.
>
> Bug:
>     https://bugs.openjdk.java.net/browse/JDK-8066633
>
> Thanks,
>
> s'marks
>
>
> # HG changeset patch
> # User smarks
> # Date 1418349197 28800
> #      Thu Dec 11 17:53:17 2014 -0800
> # Node ID 04cfafe160978b6f99f9609f0ad559d4f70829af
> # Parent  420a1b6caaf4114e082c55faf63c67b20337528c
> 8066633: Fix deprecation warnings in java.rmi module
> Reviewed-by: XXX
>
> diff -r 420a1b6caaf4 -r 04cfafe16097 
> src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java
> --- a/src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java 
> Thu Dec 11 17:09:46 2014 -0800
> +++ b/src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java 
> Thu Dec 11 17:53:17 2014 -0800
> @@ -336,13 +336,12 @@
>       * Main program to start a registry. <br>
>       * The port number can be specified on the command line.
>       */
> -    @SuppressWarnings("deprecation")
>      public static void main(String args[])
>      {
>          // Create and install the security manager if one is not 
> installed
>          // already.
>          if (System.getSecurityManager() == null) {
> -            System.setSecurityManager(new RMISecurityManager());
> +            System.setSecurityManager(new SecurityManager());
>          }
>
>          try {



From lance.andersen at oracle.com  Fri Dec 12 02:15:41 2014
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Thu, 11 Dec 2014 21:15:41 -0500
Subject: RFR(xs): 8066633: Fix deprecation warnings in java.rmi module
In-Reply-To: <548A4B53.3010902@oracle.com>
References: <548A4B53.3010902@oracle.com>
Message-ID: <601F8E3C-189B-40E7-B7F7-2C9A6D31A5DC@oracle.com>

+1


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com
Sent from my iPad

> On Dec 11, 2014, at 8:56 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> Hi all,
> 
> Please review this tiny fix to remove the source of a deprecation warning and to remove the now-unnecessary suppression of deprecation warnings from its context.
> 
> There are other deprecated usages mentioned in this bug report but for a variety of reasons they either cannot be removed or aren't worth removing. This instance is the only one left.
> 
> Patch appended below.
> 
> Bug:
>    https://bugs.openjdk.java.net/browse/JDK-8066633
> 
> Thanks,
> 
> s'marks
> 
> 
> # HG changeset patch
> # User smarks
> # Date 1418349197 28800
> #      Thu Dec 11 17:53:17 2014 -0800
> # Node ID 04cfafe160978b6f99f9609f0ad559d4f70829af
> # Parent  420a1b6caaf4114e082c55faf63c67b20337528c
> 8066633: Fix deprecation warnings in java.rmi module
> Reviewed-by: XXX
> 
> diff -r 420a1b6caaf4 -r 04cfafe16097 src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java
> --- a/src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java    Thu Dec 11 17:09:46 2014 -0800
> +++ b/src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.java    Thu Dec 11 17:53:17 2014 -0800
> @@ -336,13 +336,12 @@
>      * Main program to start a registry. <br>
>      * The port number can be specified on the command line.
>      */
> -    @SuppressWarnings("deprecation")
>     public static void main(String args[])
>     {
>         // Create and install the security manager if one is not installed
>         // already.
>         if (System.getSecurityManager() == null) {
> -            System.setSecurityManager(new RMISecurityManager());
> +            System.setSecurityManager(new SecurityManager());
>         }
> 
>         try {


From joe.darcy at oracle.com  Fri Dec 12 03:10:34 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 11 Dec 2014 19:10:34 -0800
Subject: JDK 9 RFR of JDK-8067289 (XS): Fix deprecation warnings in
	java.base module - CRC32C
In-Reply-To: <548A4404.7000905@oracle.com>
References: <5489EE32.3070507@oracle.com> <5489EF37.20405@oracle.com>
	<548A4404.7000905@oracle.com>
Message-ID: <548A5CAA.8010206@oracle.com>

Hi Staffan,

The new version looks good to me; thanks,

-Joe

On 12/11/2014 5:25 PM, Staffan Friberg wrote:
> Hi Joe,
>
> Good point. Updated webrev, 
> http://cr.openjdk.java.net/~sfriberg/JDK-8067289/webrev.01
>
> Regards,
> Staffan
>
> On 12/11/2014 11:23 AM, joe darcy wrote:
>> Hi Staffan,
>>
>> I haven't examined the code for possible integer overflow cases, but 
>> it would be fundamentally safer if the values were promoted to long 
>> *before* the arithmetic rather than after. In other words, instead of
>>
>>     (long)(Unsafe.ARRAY_BYTE_BASE_OFFSET + off) // Overflow 
>> theoretically possible
>>
>> use
>>
>>     (long)Unsafe.ARRAY_BYTE_BASE_OFFSET + off // No overflow worries 
>> with int inputs
>>
>> -Joe
>>
>> On 12/11/2014 11:19 AM, Staffan Friberg wrote:
>>> Hi,
>>>
>>> Here is a small fix that avoids calling deprecated sun.misc.Unsafe 
>>> methods, which allows the @SuppressWarnings to be removed.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067289
>>> Webrev: http://cr.openjdk.java.net/~sfriberg/JDK-8067289/webrev.00
>>>
>>> Regards,
>>> Staffan
>>
>



From felix.yang at oracle.com  Fri Dec 12 04:41:11 2014
From: felix.yang at oracle.com (FELIX YANG)
Date: Fri, 12 Dec 2014 12:41:11 +0800
Subject: RFR 8066085: Need a sanity test for rmic -iiop
Message-ID: <548A71E7.8000209@oracle.com>

Hi all,
     please review the fix to add a sanity checking for rmic -iiop 
compiling.

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

Webrev:
        http://cr.openjdk.java.net/~xiaofeya/8066085/webrev.00/

Thanks,
Felix


From felix.yang at oracle.com  Fri Dec 12 06:12:49 2014
From: felix.yang at oracle.com (FELIX YANG)
Date: Fri, 12 Dec 2014 14:12:49 +0800
Subject: RFR 8061442: Update jdk/tools tests to remove check for the "jre"
	directory
In-Reply-To: <548A71E7.8000209@oracle.com>
References: <548A71E7.8000209@oracle.com>
Message-ID: <548A8761.4040802@oracle.com>

Hi all,
     please review the fix for jdk/test/tools. It cleans up checking for 'jre' directory, which has been removed during Jigsaw M2.

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

Webrev:
     http://cr.openjdk.java.net/~xiaofeya/8061442/webrev.00/

Thanks,
Felix





From stuart.marks at oracle.com  Fri Dec 12 08:08:22 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 12 Dec 2014 00:08:22 -0800
Subject: RFR 8066085: Need a sanity test for rmic -iiop
In-Reply-To: <548A71E7.8000209@oracle.com>
References: <548A71E7.8000209@oracle.com>
Message-ID: <548AA276.7080701@oracle.com>

On 12/11/14 8:41 PM, FELIX YANG wrote:
> Hi all,
>      please review the fix to add a sanity checking for rmic -iiop compiling.
>
> Bug:
>         https://bugs.openjdk.java.net/browse/JDK-8066085
>
> Webrev:
>         http://cr.openjdk.java.net/~xiaofeya/8066085/webrev.00/

Hi Felix,

Thanks for picking up the writing of this test. I have several comments.

1. Usually we try to avoid naming tests after bug IDs. There are such tests in 
the suite but most tests have more descriptive names. I'd suggest something like 
"iiopSanityTest".

2. There are other rmic tests in jdk/test/sun/rmi/rmic; the test should be moved 
there (and the path to the TestLibrary updated correspondingly).

3. The test summary should be a bit more explicit. Instead of "a sanity test for 
rmic -iiop compiling" I'd suggest something like "Compiles a 
PortableRemoteObject with rmic -iiop and ensures that stub and tie classes are 
generated."

4. When invoking rmic, you need to make sure to pass the -iiop option.

5. Add check for the _Tie class as well as the _Stub class. Not that it really 
matters, since we know these classes are in the unnamed package, but the stub 
and tie class files would end up in directories corresponding to their package 
names -- if they were in a named package.

6. In doTest(), the try/catch of InterruptedException and IOException and call 
to TestLibrary.bomb() is mostly unnecessary. (Yes, other RMI tests do this, and 
I've been removing it where appropriate. In the RMI test library, the bomb() 
call merely wraps and rethrows the exception, and doesn't really add any value. 
It's like calling fail() in a test-ng test.) In general an uncaught exception 
will cause a jtreg test to fail, so you might as well just declare the method 
with "throws Exception" and let them propagate. This helps reduce clutter.

7. Similarly I'm not sure it's necessary to check the classname argument for 
null; the failure should be apparent enough if classname is null. But if you 
think it's worth it, a concise way to null-check an argument is to use 
Objects.requireNonNull().

8. The "rmiComplie" method is misnamed (or typo'd); I'd suggest something like 
"runRmic".

9. Changing the directory of the rmic subprocess is confusing, because it makes 
different parts of the program deal with different paths to the same files. In 
addition, switching directories to the test.classes directory will leave the 
stub/tie classes there, which could possibly confuse future test runs, since 
that directory isn't necessarily cleared between test runs.

The default working directory of jtreg tests is the "scratch" directory, which 
is cleared before each test run. Leaving the current directory as-is when 
running the subprocesses will write the generated stub/tie classes to the 
scratch directory, which is the right thing.

This implies that you'll need to add the -classpath argument and a path to the 
test.classes directory to the rmic command line.

Thanks,

s'marks




From Alan.Bateman at oracle.com  Fri Dec 12 10:45:16 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Dec 2014 10:45:16 +0000
Subject: RFR: JDK-8065673: Makefile enable JAXP tests running
In-Reply-To: <35DC236D-FD79-4D93-AA8C-70390402BE1C@oracle.com>
References: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com>
	<5489B349.6040009@oracle.com> <5489D865.2060705@oracle.com>
	<35DC236D-FD79-4D93-AA8C-70390402BE1C@oracle.com>
Message-ID: <548AC73C.2050805@oracle.com>

On 11/12/2014 21:10, Tristan Yan wrote:
> Thanks Alan and Joe
> I added jaxp testset, now jaxp_tests is under jaxp testset only. Also 
> I have added jaxp testset to pit.
>
> http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.01/ 
> <http://cr.openjdk.java.net/%7Etyan/JDK-8065673/webrev.01/>
> http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/ 
> <http://cr.openjdk.java.net/%7Etyan/JDK-8065673/jaxp/webrev.00/>
>
> Thanks
>
I think this looks much better. A suggestion for the test group name is 
"jaxp_all" rather than "jaxp_test". A minor comment on jprt.properties 
is that the comments should probably use "JAXP" rather than "Jaxp".

A side question: Are there plans to move the JAXP tests from the 
jdk/test directory to the jaxp repo so that they can be with their 
friends? I think that would make this new testset more useful.

-Alan.



From Alan.Bateman at oracle.com  Fri Dec 12 10:47:19 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Dec 2014 10:47:19 +0000
Subject: RFR 8061442: Update jdk/tools tests to remove check for the "jre"
	directory
In-Reply-To: <548A8761.4040802@oracle.com>
References: <548A71E7.8000209@oracle.com> <548A8761.4040802@oracle.com>
Message-ID: <548AC7B7.1060203@oracle.com>

On 12/12/2014 06:12, FELIX YANG wrote:
> Hi all,
>     please review the fix for jdk/test/tools. It cleans up checking 
> for 'jre' directory, which has been removed during Jigsaw M2.
>
> Bug:
>     https://bugs.openjdk.java.net/browse/JDK-8061442
>
> Webrev:
>     http://cr.openjdk.java.net/~xiaofeya/8061442/webrev.00/
This looks okay to me.

-Alan


From pavel.rappo at oracle.com  Fri Dec 12 15:40:13 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 12 Dec 2014 15:40:13 +0000
Subject: RFR JDK-8066642: Fix deprecation warnings in jdk.naming module
Message-ID: <588275F7-18D3-43E7-A55D-120D38D4AEFA@oracle.com>

Hi everyone,

Could you please review my change for JDK-8066642?

http://cr.openjdk.java.net/~prappo/8066642/webrev.00/

-Pavel



From lance.andersen at oracle.com  Fri Dec 12 15:43:14 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 12 Dec 2014 10:43:14 -0500
Subject: RFR JDK-8066642: Fix deprecation warnings in jdk.naming module
In-Reply-To: <588275F7-18D3-43E7-A55D-120D38D4AEFA@oracle.com>
References: <588275F7-18D3-43E7-A55D-120D38D4AEFA@oracle.com>
Message-ID: <D5773A5F-E7E3-4CA7-B6A2-AFBFA7EFFD07@oracle.com>

+1
On Dec 12, 2014, at 10:40 AM, Pavel Rappo <pavel.rappo at oracle.com> wrote:

> Hi everyone,
> 
> Could you please review my change for JDK-8066642?
> 
> http://cr.openjdk.java.net/~prappo/8066642/webrev.00/
> 
> -Pavel
> 



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





From Alan.Bateman at oracle.com  Fri Dec 12 15:51:20 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Dec 2014 15:51:20 +0000
Subject: RFR JDK-8066642: Fix deprecation warnings in jdk.naming module
In-Reply-To: <588275F7-18D3-43E7-A55D-120D38D4AEFA@oracle.com>
References: <588275F7-18D3-43E7-A55D-120D38D4AEFA@oracle.com>
Message-ID: <548B0EF8.105@oracle.com>

On 12/12/2014 15:40, Pavel Rappo wrote:
> Hi everyone,
>
> Could you please review my change for JDK-8066642?
>
> http://cr.openjdk.java.net/~prappo/8066642/webrev.00/
>
> -Pavel
>
This looks okay but I just wonder if we have any tests that check the 
for specific NamingExceptions that would help tell us if there is any 
behavior change.

-Alan.


From chris.hegarty at oracle.com  Fri Dec 12 15:54:29 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 12 Dec 2014 15:54:29 +0000
Subject: RFR JDK-8066642: Fix deprecation warnings in jdk.naming module
In-Reply-To: <588275F7-18D3-43E7-A55D-120D38D4AEFA@oracle.com>
References: <588275F7-18D3-43E7-A55D-120D38D4AEFA@oracle.com>
Message-ID: <548B0FB5.7020900@oracle.com>

On 12/12/14 15:40, Pavel Rappo wrote:
> Hi everyone,
>
> Could you please review my change for JDK-8066642?
>
> http://cr.openjdk.java.net/~prappo/8066642/webrev.00/

The first change, to remove SocketSecurityException seems benign. 
SocketSecurityException is a subclass of ExportException, so 
CommunicationException will continue to be thrown.

The second change, to replace RMISecurityManager with SecurityManager, 
will provide equivalent behavior, RMISecurityManager extends 
SecurityManager but does not add any state or behavior, but the runtime 
type of the security will be changed.

I've taken a quick look through the JDK source and cannot find any 
places where the type of the security manager is checked to see if it is 
an instance of RMISecurityManager. I also quickly looked in GrepCode, 
and could not find any either. Given this, I think the change should be ok.

-Chris.

> -Pavel
>


From roger.riggs at oracle.com  Fri Dec 12 17:14:17 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Fri, 12 Dec 2014 12:14:17 -0500
Subject: RFR 9: 8044841 java/lang/Runtime/exec/SleepyCat.java Exception: Read
	from closed pipe hangs
Message-ID: <548B2269.5060907@oracle.com>

Please review this addition of diagnostic output to an intermittently 
failing Runtime.exec test.

The Solaris implementation of ProcessBuilder.start uses posix_spawn and 
a trampoline
technique that invokes a small spawnhelper executable which in turn 
forks the new executable.
The test has been intermittently failing on Solaris and is not reproducible.
The diagnostic output is only triggered if the test is failing and is 
conditional
since the programs are only available on Solaris.

Other suggestions for diagnostics or the solution are welcome.

[The test fix will be pushed using a different bug number since it does 
not attempt to fix the issue.]

Webrev:
    http://cr.openjdk.java.net/~rriggs/webrev-sleepycat-8044841/

Thanks, Roger





From chris.hegarty at oracle.com  Fri Dec 12 17:43:51 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 12 Dec 2014 17:43:51 +0000
Subject: RFR JDK-8066642: Fix deprecation warnings in jdk.naming module
In-Reply-To: <548B0EF8.105@oracle.com>
References: <588275F7-18D3-43E7-A55D-120D38D4AEFA@oracle.com>
	<548B0EF8.105@oracle.com>
Message-ID: <A9D83868-8459-478F-85DB-BD750F73AF07@oracle.com>


> On 12 Dec 2014, at 15:51, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
>> On 12/12/2014 15:40, Pavel Rappo wrote:
>> Hi everyone,
>> 
>> Could you please review my change for JDK-8066642?
>> 
>> http://cr.openjdk.java.net/~prappo/8066642/webrev.00/
>> 
>> -Pavel
> This looks okay but I just wonder if we have any tests that check the for specific NamingExceptions that would help tell us if there is any behavior change.

I could be reading the code incorrectly but I don't see that there will b any change in behaviour, with respect to the exception been thrown.

-Chris.

> -Alan.


From huizhe.wang at oracle.com  Fri Dec 12 17:45:56 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Fri, 12 Dec 2014 09:45:56 -0800
Subject: RFR: JDK-8065673: Makefile enable JAXP tests running
In-Reply-To: <548AC73C.2050805@oracle.com>
References: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com>
	<5489B349.6040009@oracle.com> <5489D865.2060705@oracle.com>
	<35DC236D-FD79-4D93-AA8C-70390402BE1C@oracle.com>
	<548AC73C.2050805@oracle.com>
Message-ID: <548B29D4.6050301@oracle.com>


On 12/12/2014 2:45 AM, Alan Bateman wrote:
> On 11/12/2014 21:10, Tristan Yan wrote:
>> Thanks Alan and Joe
>> I added jaxp testset, now jaxp_tests is under jaxp testset only. Also 
>> I have added jaxp testset to pit.
>>
>> http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Etyan/JDK-8065673/webrev.01/>
>> http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/ 
>> <http://cr.openjdk.java.net/%7Etyan/JDK-8065673/jaxp/webrev.00/>
>>
>> Thanks
>>
> I think this looks much better. A suggestion for the test group name 
> is "jaxp_all" rather than "jaxp_test". A minor comment on 
> jprt.properties is that the comments should probably use "JAXP" rather 
> than "Jaxp".
>
> A side question: Are there plans to move the JAXP tests from the 
> jdk/test directory to the jaxp repo so that they can be with their 
> friends? I think that would make this new testset more useful.

Yes, it's in our plan to move jaxp tests from jdk/test to jaxp/test.

-Joe

>
> -Alan.
>



From tristan.yan at oracle.com  Fri Dec 12 18:10:13 2014
From: tristan.yan at oracle.com (Tristan Yan)
Date: Fri, 12 Dec 2014 10:10:13 -0800
Subject: RFR: JDK-8065673: Makefile enable JAXP tests running
In-Reply-To: <548B29D4.6050301@oracle.com>
References: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com>
	<5489B349.6040009@oracle.com> <5489D865.2060705@oracle.com>
	<35DC236D-FD79-4D93-AA8C-70390402BE1C@oracle.com>
	<548AC73C.2050805@oracle.com> <548B29D4.6050301@oracle.com>
Message-ID: <50BF092B-2F81-42E4-B4F1-64CEC19087A7@oracle.com>

Thanks Joe answering this.
Updated webrev by changing jaxp_test to jaxp_all, Also correct ?Jaxp" as ?JAXP?.

http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.01/ <http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.01/>
http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.02/ <http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.02/>

Tristan

> On Dec 12, 2014, at 9:45 AM, huizhe wang <huizhe.wang at oracle.com> wrote:
> 
> 
> On 12/12/2014 2:45 AM, Alan Bateman wrote:
>> On 11/12/2014 21:10, Tristan Yan wrote:
>>> Thanks Alan and Joe
>>> I added jaxp testset, now jaxp_tests is under jaxp testset only. Also I have added jaxp testset to pit.
>>> 
>>> http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.01/ <http://cr.openjdk.java.net/%7Etyan/JDK-8065673/webrev.01/>
>>> http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.00/ <http://cr.openjdk.java.net/%7Etyan/JDK-8065673/jaxp/webrev.00/>
>>> 
>>> Thanks
>>> 
>> I think this looks much better. A suggestion for the test group name is "jaxp_all" rather than "jaxp_test". A minor comment on jprt.properties is that the comments should probably use "JAXP" rather than "Jaxp".
>> 
>> A side question: Are there plans to move the JAXP tests from the jdk/test directory to the jaxp repo so that they can be with their friends? I think that would make this new testset more useful.
> 
> Yes, it's in our plan to move jaxp tests from jdk/test to jaxp/test.
> 
> -Joe
> 
>> 
>> -Alan.
>> 
> 



From mandy.chung at oracle.com  Fri Dec 12 18:25:52 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 12 Dec 2014 10:25:52 -0800
Subject: Review request: JDK-8067360: verify-modules target was dropped in
	jdk9 b41
Message-ID: <548B3330.3050104@oracle.com>

Webrev:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8067360/webrev.00/

This patch adds back the verify-modules target to the dependences of the 
images target that got dropped in the merge and hides a bug in jdeps 
-Xverify:access.

Erik - I notice make/Javadoc.gmk that sets -bootclasspath 
$(JDK_OUTPUTDIR)/classes that does not exist.  I include a patch to 
make/Javadoc.gmk in the webrev.  Do you prefer to separate it and file a 
new bug for it?

Mandy




From roger.riggs at oracle.com  Fri Dec 12 19:53:49 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Fri, 12 Dec 2014 14:53:49 -0500
Subject: RFR 9: 8056238: (process) ProcessBuilder.redirectError spec has a
	broken link
Message-ID: <548B47CD.80503@oracle.com>

Please review this fix for bad link in javadoc:

jdk/src/java.base/share/classes/java/lang/ProcessBuilder.java
@@ -748,11 +748,11 @@
       * Process#getErrorStream()}.
       * If the destination is set to any other value, then
       * {@link Process#getErrorStream()} will return a
       * <a href="#redirect-output">null input stream</a>.
       *
-     * <p>If the {@link #redirectErrorStream redirectErrorStream}
+     * <p>If the {@link #redirectErrorStream() redirectErrorStream}
       * attribute has been set {@code true}, then the redirection set
       * by this method has no effect.
       *
       * @param  destination the new standard error destination
       * @return this process builder

Issue:
     8056238: (process) ProcessBuilder.redirectError spec has a broken link

The built javadoc has the link working.

Thanks, Roger



From lance.andersen at oracle.com  Fri Dec 12 20:00:10 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 12 Dec 2014 15:00:10 -0500
Subject: RFR 9: 8056238: (process) ProcessBuilder.redirectError spec has a
	broken link
In-Reply-To: <548B47CD.80503@oracle.com>
References: <548B47CD.80503@oracle.com>
Message-ID: <CE5E9366-2DE5-476E-98F4-85F1A1DFEC52@oracle.com>

looks ok Roger
On Dec 12, 2014, at 2:53 PM, roger riggs <roger.riggs at oracle.com> wrote:

> Please review this fix for bad link in javadoc:
> 
> jdk/src/java.base/share/classes/java/lang/ProcessBuilder.java
> @@ -748,11 +748,11 @@
>      * Process#getErrorStream()}.
>      * If the destination is set to any other value, then
>      * {@link Process#getErrorStream()} will return a
>      * <a href="#redirect-output">null input stream</a>.
>      *
> -     * <p>If the {@link #redirectErrorStream redirectErrorStream}
> +     * <p>If the {@link #redirectErrorStream() redirectErrorStream}
>      * attribute has been set {@code true}, then the redirection set
>      * by this method has no effect.
>      *
>      * @param  destination the new standard error destination
>      * @return this process builder
> 
> Issue:
>    8056238: (process) ProcessBuilder.redirectError spec has a broken link
> 
> The built javadoc has the link working.
> 
> Thanks, Roger
> 



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





From stuart.marks at oracle.com  Fri Dec 12 20:05:47 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 12 Dec 2014 12:05:47 -0800
Subject: RFR(s): 8035117: TEST_BUG:
	java/rmi/server/RemoteObject/notExtending/NotExtending.java
	can fail with timeout
Message-ID: <548B4A9B.5020406@oracle.com>

Hi all,

Please review this small fix and cleanup to this test. The old version would 
force garbage collection of an unreferenced RMI object by allocating lots and 
lots of memory until OOME is received, which takes a long time and could cause a 
timeout. The better approach is simply to unexport the object.

I also did additional cleanups, such as not leaking the reference to 'this' from 
within the constructor, making comments and messages more concise, etc.

Webrev:

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

Bug:

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

Thanks,

s'marks


From coleen.phillimore at oracle.com  Fri Dec 12 20:59:01 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Fri, 12 Dec 2014 15:59:01 -0500
Subject: RFR: 8042418: Remove JVM_FindClassFromClassLoader
Message-ID: <548B5715.90402@oracle.com>

Summary: The function has been replaced so is no longer used.

This function was replaced with a better FindClassFromCaller function.   
The compatibility request (CCC) was approved.

open webrev at http://cr.openjdk.java.net/~coleenp/8042418_jdk/
open webrev at http://cr.openjdk.java.net/~coleenp/8042418_hs
bug link https://bugs.openjdk.java.net/browse/JDK-8042418

Tested with jdk_core jtreg tests on linux/x64.

Thanks,
Coleen


From martinrb at google.com  Fri Dec 12 21:07:08 2014
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 12 Dec 2014 13:07:08 -0800
Subject: RFR 9: 8056238: (process) ProcessBuilder.redirectError spec has a
	broken link
In-Reply-To: <548B47CD.80503@oracle.com>
References: <548B47CD.80503@oracle.com>
Message-ID: <CA+kOe093Y3b0dBc-ay=Kz2_D7AQZ7rJCs-TywEai13T3SWc7vw@mail.gmail.com>

+1
(how did this not get fixed in previous cleanups!?)

On Fri, Dec 12, 2014 at 11:53 AM, roger riggs <roger.riggs at oracle.com> wrote:
> Please review this fix for bad link in javadoc:
>
> jdk/src/java.base/share/classes/java/lang/ProcessBuilder.java
> @@ -748,11 +748,11 @@
>       * Process#getErrorStream()}.
>       * If the destination is set to any other value, then
>       * {@link Process#getErrorStream()} will return a
>       * <a href="#redirect-output">null input stream</a>.
>       *
> -     * <p>If the {@link #redirectErrorStream redirectErrorStream}
> +     * <p>If the {@link #redirectErrorStream() redirectErrorStream}
>       * attribute has been set {@code true}, then the redirection set
>       * by this method has no effect.
>       *
>       * @param  destination the new standard error destination
>       * @return this process builder
>
> Issue:
>     8056238: (process) ProcessBuilder.redirectError spec has a broken link
>
> The built javadoc has the link working.
>
> Thanks, Roger
>


From roger.riggs at oracle.com  Fri Dec 12 21:16:06 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Fri, 12 Dec 2014 16:16:06 -0500
Subject: RFR 9: 8056238: (process) ProcessBuilder.redirectError spec has
	a broken link
In-Reply-To: <CA+kOe093Y3b0dBc-ay=Kz2_D7AQZ7rJCs-TywEai13T3SWc7vw@mail.gmail.com>
References: <548B47CD.80503@oracle.com>
	<CA+kOe093Y3b0dBc-ay=Kz2_D7AQZ7rJCs-TywEai13T3SWc7vw@mail.gmail.com>
Message-ID: <548B5B16.9060309@oracle.com>

Hi,

Not sure, but it used to be ok to refer to a method without the ().
Now the name on the html target has a '--' suffix so a bare link 
reference does not work.

Roger

On 12/12/2014 4:07 PM, Martin Buchholz wrote:
> +1
> (how did this not get fixed in previous cleanups!?)
>
> On Fri, Dec 12, 2014 at 11:53 AM, roger riggs <roger.riggs at oracle.com> wrote:
>> Please review this fix for bad link in javadoc:
>>
>> jdk/src/java.base/share/classes/java/lang/ProcessBuilder.java
>> @@ -748,11 +748,11 @@
>>        * Process#getErrorStream()}.
>>        * If the destination is set to any other value, then
>>        * {@link Process#getErrorStream()} will return a
>>        * <a href="#redirect-output">null input stream</a>.
>>        *
>> -     * <p>If the {@link #redirectErrorStream redirectErrorStream}
>> +     * <p>If the {@link #redirectErrorStream() redirectErrorStream}
>>        * attribute has been set {@code true}, then the redirection set
>>        * by this method has no effect.
>>        *
>>        * @param  destination the new standard error destination
>>        * @return this process builder
>>
>> Issue:
>>      8056238: (process) ProcessBuilder.redirectError spec has a broken link
>>
>> The built javadoc has the link working.
>>
>> Thanks, Roger
>>



From martinrb at google.com  Fri Dec 12 21:26:54 2014
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 12 Dec 2014 13:26:54 -0800
Subject: RFR 9: 8056238: (process) ProcessBuilder.redirectError spec has a
	broken link
In-Reply-To: <548B5B16.9060309@oracle.com>
References: <548B47CD.80503@oracle.com>
	<CA+kOe093Y3b0dBc-ay=Kz2_D7AQZ7rJCs-TywEai13T3SWc7vw@mail.gmail.com>
	<548B5B16.9060309@oracle.com>
Message-ID: <CA+kOe0-fNOPMtq3_ZEvPhGzkfBaBqDrwcUEWLhrC4DwmvDSXcg@mail.gmail.com>

Oh I think I know.  #redirectErrorStream is ambiguous, because the
method name is overloaded.  In the distant past, it would choose one
of the methods to target, probably the first, but now you need to be
explicit?

It might be very slightly better to refer to the setter

* <p>If the {@link #redirectErrorStream(boolean) redirectErrorStream}

On Fri, Dec 12, 2014 at 1:16 PM, roger riggs <roger.riggs at oracle.com> wrote:
> Hi,
>
> Not sure, but it used to be ok to refer to a method without the ().
> Now the name on the html target has a '--' suffix so a bare link reference
> does not work.
>
> Roger
>
>
> On 12/12/2014 4:07 PM, Martin Buchholz wrote:
>>
>> +1
>> (how did this not get fixed in previous cleanups!?)
>>
>> On Fri, Dec 12, 2014 at 11:53 AM, roger riggs <roger.riggs at oracle.com>
>> wrote:
>>>
>>> Please review this fix for bad link in javadoc:
>>>
>>> jdk/src/java.base/share/classes/java/lang/ProcessBuilder.java
>>> @@ -748,11 +748,11 @@
>>>        * Process#getErrorStream()}.
>>>        * If the destination is set to any other value, then
>>>        * {@link Process#getErrorStream()} will return a
>>>        * <a href="#redirect-output">null input stream</a>.
>>>        *
>>> -     * <p>If the {@link #redirectErrorStream redirectErrorStream}
>>> +     * <p>If the {@link #redirectErrorStream() redirectErrorStream}
>>>        * attribute has been set {@code true}, then the redirection set
>>>        * by this method has no effect.
>>>        *
>>>        * @param  destination the new standard error destination
>>>        * @return this process builder
>>>
>>> Issue:
>>>      8056238: (process) ProcessBuilder.redirectError spec has a broken
>>> link
>>>
>>> The built javadoc has the link working.
>>>
>>> Thanks, Roger
>>>
>


From martinrb at google.com  Fri Dec 12 21:34:11 2014
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 12 Dec 2014 13:34:11 -0800
Subject: RFR: 8067377: My hobby: caning, then then canning, the the can-can
Message-ID: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>

Hi Joe, Lance, Roger,

Fix ALL the stutters!

https://bugs.openjdk.java.net/browse/JDK-8067377
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/double-trouble/


From mandy.chung at oracle.com  Fri Dec 12 21:54:58 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 12 Dec 2014 13:54:58 -0800
Subject: RFR: 8067377: My hobby: caning, then then canning, the the can-can
In-Reply-To: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>
References: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>
Message-ID: <548B6432.40000@oracle.com>

On 12/12/14 1:34 PM, Martin Buchholz wrote:
> Hi Joe, Lance, Roger,
>
> Fix ALL the stutters!
>
> https://bugs.openjdk.java.net/browse/JDK-8067377
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/double-trouble/

Looks fine with me.  My eyes were getting very tired half way through
spotting the "double troubles".  The top one should be "the the".

Mandy



From roger.riggs at oracle.com  Fri Dec 12 21:57:12 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Fri, 12 Dec 2014 16:57:12 -0500
Subject: RFR: 8067377: My hobby: caning, then then canning, the the can-can
In-Reply-To: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>
References: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>
Message-ID: <548B64B8.8010606@oracle.com>

Hi Martin,

Thanks for the sharp eyes and speech lesson.
Looks fine to me.

Roger

On 12/12/2014 4:34 PM, Martin Buchholz wrote:
> Hi Joe, Lance, Roger,
>
> Fix ALL the stutters!
>
> https://bugs.openjdk.java.net/browse/JDK-8067377
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/double-trouble/



From Lance.Andersen at oracle.com  Sat Dec 13 00:26:08 2014
From: Lance.Andersen at oracle.com (Lance Andersen)
Date: Fri, 12 Dec 2014 19:26:08 -0500
Subject: RFR: 8067377: My hobby: caning, then then canning, the the can-can
In-Reply-To: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>
References: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>
Message-ID: <B82F89FB-DC01-4A6B-97B2-75241A957C3C@oracle.com>

looks good Martin...
On Dec 12, 2014, at 4:34 PM, Martin Buchholz <martinrb at google.com> wrote:

> Hi Joe, Lance, Roger,
> 
> Fix ALL the stutters!
> 
> https://bugs.openjdk.java.net/browse/JDK-8067377
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/double-trouble/



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





From huizhe.wang at oracle.com  Sat Dec 13 00:57:26 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Fri, 12 Dec 2014 16:57:26 -0800
Subject: RFR: 8067377: My hobby: caning, then then canning, the the can-can
In-Reply-To: <B82F89FB-DC01-4A6B-97B2-75241A957C3C@oracle.com>
References: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>
	<B82F89FB-DC01-4A6B-97B2-75241A957C3C@oracle.com>
Message-ID: <548B8EF6.8040207@oracle.com>

wow, looks like "the the"'s quite popular. I found 37 in jaxp as well :-)

Joe

On 12/12/2014 4:26 PM, Lance Andersen wrote:
> looks good Martin...
> On Dec 12, 2014, at 4:34 PM, Martin Buchholz <martinrb at google.com> wrote:
>
>> Hi Joe, Lance, Roger,
>>
>> Fix ALL the stutters!
>>
>> https://bugs.openjdk.java.net/browse/JDK-8067377
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/double-trouble/
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>



From Alan.Bateman at oracle.com  Sat Dec 13 10:21:50 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 13 Dec 2014 10:21:50 +0000
Subject: RFR JDK-8066642: Fix deprecation warnings in jdk.naming module
In-Reply-To: <A9D83868-8459-478F-85DB-BD750F73AF07@oracle.com>
References: <588275F7-18D3-43E7-A55D-120D38D4AEFA@oracle.com>
	<548B0EF8.105@oracle.com>
	<A9D83868-8459-478F-85DB-BD750F73AF07@oracle.com>
Message-ID: <548C133E.8060304@oracle.com>

On 12/12/2014 17:43, Chris Hegarty wrote:
>> On 12 Dec 2014, at 15:51, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>
>>> On 12/12/2014 15:40, Pavel Rappo wrote:
>>> Hi everyone,
>>>
>>> Could you please review my change for JDK-8066642?
>>>
>>> http://cr.openjdk.java.net/~prappo/8066642/webrev.00/
>>>
>>> -Pavel
>> This looks okay but I just wonder if we have any tests that check the for specific NamingExceptions that would help tell us if there is any behavior change.
> I could be reading the code incorrectly but I don't see that there will b any change in behaviour, with respect to the exception been thrown.
You may be right but I just wonder if switching from RMISecurityManager 
requires any additional handling in wrapRemoteException, maybe 
SecurityException. I don't know if there are tests that exercise all of 
these scenarios and my comment was mostly just to see if such tests exists.

-Alan.


From Alan.Bateman at oracle.com  Sat Dec 13 10:23:13 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 13 Dec 2014 10:23:13 +0000
Subject: RFR: JDK-8065673: Makefile enable JAXP tests running
In-Reply-To: <50BF092B-2F81-42E4-B4F1-64CEC19087A7@oracle.com>
References: <6AEB2B37-6026-4C17-94E9-2228321E020F@oracle.com>
	<5489B349.6040009@oracle.com> <5489D865.2060705@oracle.com>
	<35DC236D-FD79-4D93-AA8C-70390402BE1C@oracle.com>
	<548AC73C.2050805@oracle.com> <548B29D4.6050301@oracle.com>
	<50BF092B-2F81-42E4-B4F1-64CEC19087A7@oracle.com>
Message-ID: <548C1391.9030008@oracle.com>

On 12/12/2014 18:10, Tristan Yan wrote:
> Thanks Joe answering this.
> Updated webrev by changing jaxp_test to jaxp_all, Also correct ?Jaxp" 
> as ?JAXP?.
>
> http://cr.openjdk.java.net/~tyan/JDK-8065673/jaxp/webrev.01/ 
> <http://cr.openjdk.java.net/%7Etyan/JDK-8065673/jaxp/webrev.01/>
> http://cr.openjdk.java.net/~tyan/JDK-8065673/webrev.02/ 
> <http://cr.openjdk.java.net/%7Etyan/JDK-8065673/webrev.02/>
>
>
Given Joe's comment about moving the JAXP tests in the jdk repo then the 
updated changes look good to me.

-Alan.


From Alan.Bateman at oracle.com  Sat Dec 13 10:25:02 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 13 Dec 2014 10:25:02 +0000
Subject: Review request: JDK-8067360: verify-modules target was dropped
	in jdk9 b41
In-Reply-To: <548B3330.3050104@oracle.com>
References: <548B3330.3050104@oracle.com>
Message-ID: <548C13FE.7080808@oracle.com>

On 12/12/2014 18:25, Mandy Chung wrote:
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8067360/webrev.00/
>
> This patch adds back the verify-modules target to the dependences of 
> the images target that got dropped in the merge and hides a bug in 
> jdeps -Xverify:access.
>
> Erik - I notice make/Javadoc.gmk that sets -bootclasspath 
> $(JDK_OUTPUTDIR)/classes that does not exist.  I include a patch to 
> make/Javadoc.gmk in the webrev.  Do you prefer to separate it and file 
> a new bug for it?
The fix to jdeps and the re-enabling of verify-modules looks good to me. 
I'll leave it to Erik and the build folks to comment on the removing of 
-bootclasspath, it might be clearer to track that separately.

-Alan


From Alan.Bateman at oracle.com  Sat Dec 13 10:25:56 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 13 Dec 2014 10:25:56 +0000
Subject: RFR 9: 8056238: (process) ProcessBuilder.redirectError spec has
	a broken link
In-Reply-To: <548B47CD.80503@oracle.com>
References: <548B47CD.80503@oracle.com>
Message-ID: <548C1434.3090900@oracle.com>

On 12/12/2014 19:53, roger riggs wrote:
> Please review this fix for bad link in javadoc:
>
> jdk/src/java.base/share/classes/java/lang/ProcessBuilder.java
> @@ -748,11 +748,11 @@
>       * Process#getErrorStream()}.
>       * If the destination is set to any other value, then
>       * {@link Process#getErrorStream()} will return a
>       * <a href="#redirect-output">null input stream</a>.
>       *
> -     * <p>If the {@link #redirectErrorStream redirectErrorStream}
> +     * <p>If the {@link #redirectErrorStream() redirectErrorStream}
>       * attribute has been set {@code true}, then the redirection set
>       * by this method has no effect.
>       *
>       * @param  destination the new standard error destination
>       * @return this process builder
This looks good to me, it always amazes me that we continue to find 
broken links.

-Alan


From Alan.Bateman at oracle.com  Sat Dec 13 10:27:55 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 13 Dec 2014 10:27:55 +0000
Subject: RFR: 8067377: My hobby: caning, then then canning, the the can-can
In-Reply-To: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>
References: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>
Message-ID: <548C14AB.4000301@oracle.com>

On 12/12/2014 21:34, Martin Buchholz wrote:
> Hi Joe, Lance, Roger,
>
> Fix ALL the stutters!
>
> https://bugs.openjdk.java.net/browse/JDK-8067377
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/double-trouble/
I skimmed through the patch and looks good to me too.

It's probably best to put put a clearer synopsis on the issue before you 
push this.

-Alan.


From daniel.fuchs at oracle.com  Sat Dec 13 12:27:55 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Sat, 13 Dec 2014 13:27:55 +0100
Subject: RFR: 8067377: My hobby: caning, then then canning, the the can-can
In-Reply-To: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>
References: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>
Message-ID: <548C30CB.5010906@oracle.com>

On 12/12/14 10:34 PM, Martin Buchholz wrote:
> Hi Joe, Lance, Roger,
>
> Fix ALL the stutters!
>
> https://bugs.openjdk.java.net/browse/JDK-8067377
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/double-trouble/

Hi Martin,

Impressive!  There may still be a typo in the one below:

diff --git a/src/java.naming/share/classes/com/sun/jndi/ldap/LdapReferralException.java b/src/java.naming/share/classes/com/sun/jndi/ldap/LdapReferralException.java
--- a/src/java.naming/share/classes/com/sun/jndi/ldap/LdapReferralException.java
+++ b/src/java.naming/share/classes/com/sun/jndi/ldap/LdapReferralException.java
@@ -59,7 +59,7 @@
    * objects.
    * <p>
    * If an exception was recorded while processing a chain of
-  * <tt>LdapReferralException</tt> objects then is is throw once
+  * <tt>LdapReferralException</tt> objects then it is throw once
    * processing has completed.


Shouldn't this be:

-  * <tt>LdapReferralException</tt> objects then is is throw once
+  * <tt>LdapReferralException</tt> objects then it is thrown once

(throw -> thrown)

best regards,

-- daniel



From lance.andersen at oracle.com  Sat Dec 13 12:34:19 2014
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Sat, 13 Dec 2014 07:34:19 -0500
Subject: RFR: 8067377: My hobby: caning, then then canning, the the can-can
In-Reply-To: <548C30CB.5010906@oracle.com>
References: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>
	<548C30CB.5010906@oracle.com>
Message-ID: <EAEE562E-F76B-4574-9565-EF24C6DC1958@oracle.com>

Good eyes Daniel!


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com
Sent from my iPad

> On Dec 13, 2014, at 7:27 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
>> On 12/12/14 10:34 PM, Martin Buchholz wrote:
>> Hi Joe, Lance, Roger,
>> 
>> Fix ALL the stutters!
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8067377
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/double-trouble/
> 
> Hi Martin,
> 
> Impressive!  There may still be a typo in the one below:
> 
> diff --git a/src/java.naming/share/classes/com/sun/jndi/ldap/LdapReferralException.java b/src/java.naming/share/classes/com/sun/jndi/ldap/LdapReferralException.java
> --- a/src/java.naming/share/classes/com/sun/jndi/ldap/LdapReferralException.java
> +++ b/src/java.naming/share/classes/com/sun/jndi/ldap/LdapReferralException.java
> @@ -59,7 +59,7 @@
>   * objects.
>   * <p>
>   * If an exception was recorded while processing a chain of
> -  * <tt>LdapReferralException</tt> objects then is is throw once
> +  * <tt>LdapReferralException</tt> objects then it is throw once
>   * processing has completed.
> 
> 
> Shouldn't this be:
> 
> -  * <tt>LdapReferralException</tt> objects then is is throw once
> +  * <tt>LdapReferralException</tt> objects then it is thrown once
> 
> (throw -> thrown)
> 
> best regards,
> 
> -- daniel
> 


From ivan.gerasimov at oracle.com  Sat Dec 13 12:38:10 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Sat, 13 Dec 2014 15:38:10 +0300
Subject: RFR: 8067377: My hobby: caning, then then canning, the the can-can
In-Reply-To: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>
References: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>
Message-ID: <548C3332.4010902@oracle.com>

Hi Martin!

Grep found a few more possible candidates to be fixed:

jdk/src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/AdviceAdapter.java: 
* Called at the beginning of the method or after super *class class* call in
jdk/src/java.base/share/classes/java/lang/Class.java:     * *Class 
Class* is special cased within the Serialization Stream Protocol.
jdk/src/java.base/share/classes/java/text/AttributedString.java: // add 
the *attribute attribute*/value to all runs where beginRunIndex <= 
runIndex < endRunIndex
jdk/src/java.base/share/classes/javax/security/auth/callback/ConfirmationCallback.java: 
* YES/NO/CANCEL *confirmation confirmation* option.
jdk/src/java.base/share/classes/javax/security/auth/callback/ConfirmationCallback.java: 
* OK/CANCEL *confirmation confirmation* option.
jdk/src/java.base/share/classes/sun/misc/SharedSecrets.java: // Ensure 
JarFile is initialized; we know *that that* class
jdk/src/java.base/share/classes/sun/misc/PerformanceLogger.java: * slot 
*that that* time was stored in.
jdk/src/java.base/share/classes/sun/misc/PerformanceLogger.java: * slot 
*that that* time was stored in.
jdk/src/java.base/share/classes/sun/net/www/MimeEntry.java: // REMIND: 
What *do do* here?
jdk/src/java.base/share/classes/sun/net/idn/StringPrep.java: // load the 
rest of the *data data* and initialize the data members
jdk/src/java.base/share/classes/sun/security/provider/certpath/PolicyNodeImpl.java: 
* Add all nodes at *depth depth* to set and return the Set.
jdk/src/java.base/share/classes/sun/security/x509/PrivateKeyUsageExtension.java: 
* Verify*that that* the current time is within the validity period.
jdk/src/java.base/share/classes/sun/security/x509/PrivateKeyUsageExtension.java: 
* Verify *that that* the passed time is within the validity period.
jdk/src/java.base/share/classes/sun/text/normalizer/NormalizerImpl.java: 
// load the rest of the *data data* and initialize the data members
jdk/src/java.base/share/classes/sun/reflect/generics/reflectiveObjects/ParameterizedTypeImpl.java: 
* This class can be instantiated with*a a* raw type that does not
jdk/src/java.base/share/native/libzip/zlib-1.2.8/zlib.h:   In the 
success case, the application may save the *current current* value of
jdk/src/java.base/share/native/libzip/zlib-1.2.8/infback.c: /* get 
length and distance *code code* lengths */
jdk/src/java.base/share/native/libzip/zlib-1.2.8/inftrees.h: *returns 
returns* 852, and "enough 30 6 15" for distance codes returns 592.
jdk/src/java.base/share/native/libzip/zlib-1.2.8/deflate.c: * IN 
assertion: all calls*to to* UPDATE_HASH are made with consecutive
jdk/src/java.base/share/native/libzip/zlib-1.2.8/deflate.c: * IN 
assertion: all calls *to to* INSERT_STRING are made with consecutive

Sincerely yours,
Ivan


On 13.12.2014 0:34, Martin Buchholz wrote:
> Hi Joe, Lance, Roger,
>
> Fix ALL the stutters!
>
> https://bugs.openjdk.java.net/browse/JDK-8067377
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/double-trouble/
>
>



From Alan.Bateman at oracle.com  Sat Dec 13 14:38:21 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 13 Dec 2014 14:38:21 +0000
Subject: RFR: 8067377: My hobby: caning, then then canning, the the can-can
In-Reply-To: <548C3332.4010902@oracle.com>
References: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>
	<548C3332.4010902@oracle.com>
Message-ID: <548C4F5D.7060705@oracle.com>

On 13/12/2014 12:38, Ivan Gerasimov wrote:
> :
> jdk/src/java.base/share/native/libzip/zlib-1.2.8/zlib.h:   In the 
> success case, the application may save the *current current* value of
> jdk/src/java.base/share/native/libzip/zlib-1.2.8/infback.c: /* get 
> length and distance *code code* lengths */
> jdk/src/java.base/share/native/libzip/zlib-1.2.8/inftrees.h: *returns 
> returns* 852, and "enough 30 6 15" for distance codes returns 592.
> jdk/src/java.base/share/native/libzip/zlib-1.2.8/deflate.c: * IN 
> assertion: all calls*to to* UPDATE_HASH are made with consecutive
> jdk/src/java.base/share/native/libzip/zlib-1.2.8/deflate.c: * IN 
> assertion: all calls *to to* INSERT_STRING are made with consecutive
>
It's probably best if these get fixed upstream (we try to avoid changing 
the zlib code if we can).

-Alan


From forax at univ-mlv.fr  Sat Dec 13 15:20:50 2014
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 13 Dec 2014 16:20:50 +0100
Subject: RFR: 8067377: My hobby: caning, then then canning, the the can-can
In-Reply-To: <548C3332.4010902@oracle.com>
References: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>
	<548C3332.4010902@oracle.com>
Message-ID: <548C5952.1070405@univ-mlv.fr>


On 12/13/2014 01:38 PM, Ivan Gerasimov wrote:
> Hi Martin!
>
> Grep found a few more possible candidates to be fixed:
>
> jdk/src/java.base/share/classes/jdk/internal/org/objectweb/asm/commons/AdviceAdapter.java: 
> * Called at the beginning of the method or after super *class class* 
> call in

fixed upstream :)

R?mi



From martinrb at google.com  Sat Dec 13 17:12:41 2014
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 13 Dec 2014 09:12:41 -0800
Subject: RFR: 8067377: My hobby: caning, then then canning, the the can-can
In-Reply-To: <548C14AB.4000301@oracle.com>
References: <CA+kOe09_d7b8P24G-ZVvsFvLmo4+OA2sDbGwHAc_B3ZTU7H1_Q@mail.gmail.com>
	<548C14AB.4000301@oracle.com>
Message-ID: <CA+kOe0-u=wF3wSr8a-tw5aAN2kv+CW2B210_3VDpRvcNru6Cog@mail.gmail.com>

On Sat, Dec 13, 2014 at 2:27 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> It's probably best to put put a clearer synopsis on the issue before you
> push this.

Too late! I submitted before the the eagle eyes showed up.

On Sat, Dec 13, 2014 at 4:38 AM, Ivan Gerasimov
<ivan.gerasimov at oracle.com> wrote:
> jdk/src/java.base/share/classes/java/lang/Class.java:     * Class Class is
> special cased within the Serialization Stream Protocol.

I actually used the phrase "class class" in in conversation yesterday!

As Alan says, zlib bugs should be fixed upstream.


On Sat, Dec 13, 2014 at 4:27 AM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> -  * <tt>LdapReferralException</tt> objects then is is throw once
> +  * <tt>LdapReferralException</tt> objects then it is throw once

I didn't want to have ALL the fun myself!  Feel free to fix remaining
typos in a a followup.

---

Some stutters were left unfixed because it it was not immediately
obvious what the author's intent was.


From martinrb at google.com  Sat Dec 13 17:39:07 2014
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 13 Dec 2014 09:39:07 -0800
Subject: RFR 9: 8056238: (process) ProcessBuilder.redirectError spec has a
	broken link
In-Reply-To: <548C1434.3090900@oracle.com>
References: <548B47CD.80503@oracle.com>
	<548C1434.3090900@oracle.com>
Message-ID: <CA+kOe09ReL1zB=yM-SkVka-NgCgQpQ+bKC1_vxzPL7AeY8Lkqw@mail.gmail.com>

On Sat, Dec 13, 2014 at 2:25 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> On 12/12/2014 19:53, roger riggs wrote:
>>
>> Please review this fix for bad link in javadoc:
>>
>> jdk/src/java.base/share/classes/java/lang/ProcessBuilder.java
>> @@ -748,11 +748,11 @@
>>       * Process#getErrorStream()}.
>>       * If the destination is set to any other value, then
>>       * {@link Process#getErrorStream()} will return a
>>       * <a href="#redirect-output">null input stream</a>.
>>       *
>> -     * <p>If the {@link #redirectErrorStream redirectErrorStream}
>> +     * <p>If the {@link #redirectErrorStream() redirectErrorStream}
>>       * attribute has been set {@code true}, then the redirection set
>>       * by this method has no effect.
>>       *
>>       * @param  destination the new standard error destination
>>       * @return this process builder
>
> This looks good to me, it always amazes me that we continue to find broken
> links.

In this particular case I'm pretty sure I intentionally relied on the
historic behavior of javadoc which generated a link to one of the
overloads (poor judgment on my part - I, for one, welcome our new
overload-choice-refusing javadoc).

It always amazes me that we cannot get procedures in place so that
docs are guaranteed dead-link-clean.


From david.holmes at oracle.com  Sat Dec 13 22:47:20 2014
From: david.holmes at oracle.com (David Holmes)
Date: Sun, 14 Dec 2014 08:47:20 +1000
Subject: RFR: 8042418: Remove JVM_FindClassFromClassLoader
In-Reply-To: <548B5715.90402@oracle.com>
References: <548B5715.90402@oracle.com>
Message-ID: <548CC1F8.3040800@oracle.com>

Looks okay to me Coleen.

Thanks,
David

On 13/12/2014 6:59 AM, Coleen Phillimore wrote:
> Summary: The function has been replaced so is no longer used.
>
> This function was replaced with a better FindClassFromCaller function.
> The compatibility request (CCC) was approved.
>
> open webrev at http://cr.openjdk.java.net/~coleenp/8042418_jdk/
> open webrev at http://cr.openjdk.java.net/~coleenp/8042418_hs
> bug link https://bugs.openjdk.java.net/browse/JDK-8042418
>
> Tested with jdk_core jtreg tests on linux/x64.
>
> Thanks,
> Coleen


From coleen.phillimore at oracle.com  Sun Dec 14 21:06:21 2014
From: coleen.phillimore at oracle.com (Coleen Phillimore)
Date: Sun, 14 Dec 2014 16:06:21 -0500
Subject: RFR: 8042418: Remove JVM_FindClassFromClassLoader
In-Reply-To: <548CC1F8.3040800@oracle.com>
References: <548B5715.90402@oracle.com> <548CC1F8.3040800@oracle.com>
Message-ID: <548DFBCD.4020409@oracle.com>


Thanks, David.
Coleen

On 12/13/14, 5:47 PM, David Holmes wrote:
> Looks okay to me Coleen.
>
> Thanks,
> David
>
> On 13/12/2014 6:59 AM, Coleen Phillimore wrote:
>> Summary: The function has been replaced so is no longer used.
>>
>> This function was replaced with a better FindClassFromCaller function.
>> The compatibility request (CCC) was approved.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/8042418_jdk/
>> open webrev at http://cr.openjdk.java.net/~coleenp/8042418_hs
>> bug link https://bugs.openjdk.java.net/browse/JDK-8042418
>>
>> Tested with jdk_core jtreg tests on linux/x64.
>>
>> Thanks,
>> Coleen



From weijun.wang at oracle.com  Mon Dec 15 03:43:23 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Mon, 15 Dec 2014 11:43:23 +0800
Subject: Copy a ZipEntry into another zip file
Message-ID: <1D0C24E2-14DD-43C6-B88B-7E0A378D4405@oracle.com>

Hi Sherman

The jarsigner tool contains these 2 methods to copy a ZipEntry into the signer jar:

private void writeEntry(ZipFile zf, ZipOutputStream os, ZipEntry ze)
throws IOException
{
    ZipEntry ze2 = new ZipEntry(ze.getName());
    ze2.setMethod(ze.getMethod());
    ze2.setTime(ze.getTime());
    ze2.setComment(ze.getComment());
    ze2.setExtra(ze.getExtra());
    if (ze.getMethod() == ZipEntry.STORED) {
        ze2.setSize(ze.getSize());
        ze2.setCrc(ze.getCrc());
    }
    os.putNextEntry(ze2);
    writeBytes(zf, ze, os);
}

/**
 * Writes all the bytes for a given entry to the specified output stream.
 */
private synchronized void writeBytes
    (ZipFile zf, ZipEntry ze, ZipOutputStream os) throws IOException {
    int n;

    InputStream is = null;
    try {
        is = zf.getInputStream(ze);
        long left = ze.getSize();

        while((left > 0) && (n = is.read(buffer, 0, buffer.length)) != -1) {
            os.write(buffer, 0, n);
            left -= n;
        }
    } finally {
        if (is != null) {
            is.close();
        }
    }
}

Several questions:

1. Why cannot I just call os.putNextEntry(ze) or at least os.putNextEntry(new ZipEntry(ze))? Maybe some fields (say, compressed size) should not be copied over? If ze2 must be this way, shall I also copy the flag field?

2. In writeBytes(), why does the getSize() return value need to be used? Shouldn't we just transfer all bytes from is to os?

Thanks
Max



From nathan.a.clement at hotmail.com  Mon Dec 15 05:21:35 2014
From: nathan.a.clement at hotmail.com (Nathan Clement)
Date: Mon, 15 Dec 2014 16:21:35 +1100
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <COL131-W3093E62A5924C2DC984C5FCA650@phx.gbl>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>,
	<54807258.4040303@oracle.com>
	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>,
	<20141205002430.000060c9.ecki@zusammenkunft.net>,
	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>,
	<20141205015827.00007ac6.ecki@zusammenkunft.net>,
	<CAHjP37HgKZMhjq6_AVZFAdPy4PeZBd7p6JBT0Jt2FqE42eB6Ow@mail.gmail.com>,
	<8F896CE2-E268-418F-96CA-0557C1C258B3@oracle.com>,
	<5481BB6C.1040700@oracle.com>
	<5481C3DB.70303@gmail.com>,<5481CA8C.7050100@oracle.com>
	<5481EF01.6060009@gmail.com>, ,
	<C517EC9F-7136-4252-BA5B-FFE8C2CBD4B4@oracle.com>,
	<COL131-W3093E62A5924C2DC984C5FCA650@phx.gbl>
Message-ID: <COL131-W843B7101077FF11EC708FBCA6F0@phx.gbl>

Hi,

What's the process for finalizing a decision and getting this bug fixed?

Apologies if I'm violating a social norm by asking this - I'm new to this process and I'm not sure exactly how decisions are made.

Thanks,

Nathan

> From: nathan.a.clement at hotmail.com
> To: chris.hegarty at oracle.com; peter.levart at gmail.com
> Subject: RE: [PATCH] JDK-8054565: FilterOutputStream.close may throw	IOException if called twice and underlying flush or close fails
> Date: Tue, 9 Dec 2014 16:17:29 +1100
> CC: core-libs-dev at openjdk.java.net
> 
> Hi,
> 
> I'd be happy with any of the solutions discussed here.  In our case, we're only calling close() multiple times as a result of the way that try-with-resources works with wrapped streams.
> 
> Thanks,
> 
> Nathan
> 
> Subject: Re: [PATCH] JDK-8054565: FilterOutputStream.close may throw IOException if called twice and underlying flush or close fails
> From: chris.hegarty at oracle.com
> Date: Fri, 5 Dec 2014 22:37:04 +0000
> CC: pavel.rappo at oracle.com; nathan.a.clement at hotmail.com; core-libs-dev at openjdk.java.net
> To: peter.levart at gmail.com
> 
> 
> On 5 Dec 2014, at 17:44, Peter Levart <peter.levart at gmail.com> wrote:
>   
>     
>   
>   
>     On 12/05/2014 04:09 PM, Chris Hegarty
>       wrote:
> 
>     
>     On
>       05/12/14 14:40, Peter Levart wrote:
>       
> 
>       On 12/05/2014 03:04 PM, Chris Hegarty
>         wrote:
>         
> 
>         
>           
> 
>           On 05/12/14 11:38, Pavel Rappo wrote:
>           
> 
>           +1, I couldn?t say better
>             
> 
>           
>           
> 
>           Right. This bug should only try to address the change in
>           behavior that
>           
> 
>           was inadvertently introduced by 7015589[1][2].
>           
> 
>         
>         
> 
>         What about the following:
>         
> 
>         
> 
>         
> 
>         private boolean closed;
>         
> 
>         
> 
>         public void close() throws IOException {
>         
> 
>              try (OutputStream ostream = out) {
>         
> 
>                  if (!closed)  flush();
>         
> 
>              }
>         
> 
>              closed = true;
>         
> 
>         }
>         
> 
>       
>       
> 
>       If flush throws, how is anyone supposed to know that they need to
>       call close again, and that it was not the close that actually
>       threw?
>       
> 
>     
>     
> 
>     If they call close() again because they are used to pre 7015589
>     behaviour,
> I don?t think I have every seen any code that catches the IOException from close() , and tries to close again. But maybe someone does this?
> From AutoCloseable:  ?Cases where the close operation may fail require careful attention by implementers. It is strongly advised to relinquish the underlying resources and to internally mark the resource as closed, prior to throwing the exception. The close method is unlikely to be invoked more than once and so this ensures that the resources are released in a timely manner. Furthermore it reduces problems that could arise when the resource wraps, or is wrapped, by another resource.?
> I think the changes I am proposing follows this advise ( as best we can ).
>  there is no harm if they call it as a consequence of
>     flush() throwing and out.close() succeeding, since the underlying
>     stream should 
> Yes, ?should".
> have idempotent "successful" close(). That's the
>     requirement of Closeable.close():
> 
>     
> 
>     
>     /**
> 
>      * Closes this stream and
>       releases any system resources associated
> 
>      * with it. If the stream is
>       already closed then invoking this
> 
>      * method has no effect.
> 
> FilterOutputStream is Closeable, but what you are suggesting is that subsequent calls to close would have an effect, they may call flush.
> 
>      * <p> As noted in {@link
>       AutoCloseable#close()}, cases where the
> 
>      * close may fail require
>       careful attention. It is strongly advised
> 
>      * to relinquish the underlying
>       resources and to internally
> 
>      * <em>mark</em> the
>       {@code Closeable} as closed, prior to throwing
> 
>      * the {@code IOException}.
> 
>      *
> 
>      * @throws IOException if an I/O
>       error occurs
> 
>      */
> 
>     
> 
>     The specification does not say if the stream is to be considered
>     "closed" when close() throws IOException. The advice does hint that
>     though (and was added about 3 years ago).
> Re-reading the advise in AutoCloseable and Closeable, I do not see any problem with the changes I suggested.
> -Chris.
> 
>       close() should be a one-time shot.
>       
> 
>       
> 
>       I personally think that this was an oversight of the original
>       change in 7015589, and not a deliberate behavior. My proposed
>       change will restore the behavior of close to pre 7015589, though
>       not swallow the IOException from flush.
>       
> 
>     
>     
> 
>     The pre 7015589 behaviour did not suppress multiple close() calls to
>     underlying stream.
> 
>     
> 
>     
>       
> 
>       -Chris.
>       
> 
>     
>     
> 
>     I just think that a delegating class like FilterOutputStream should
>     be as transparent as possible. If the underlying stream respects the
>     contract and advice, the wrapped stream should too. If underlying
>     stream needs some out-of-advice treatment, then wrapper like
>     FilterOutputStream should not prevent that, because there are all
>     kinds of streams out there. Or maybe it should - this is the only
>     way to "fix" those streams ;-)
> 
>     
> 
>     Just do it!
> 
>     
> 
>     Regards, Peter
> 
>     
> 
>     
>       
> 
>       ...this way the impact of the change is
>         minimal and still addresses the
>         
> 
>         problem of JDK-8054565
>         <https://bugs.openjdk.java.net/browse/JDK-8054565>.
>         
> 
>         
> 
>         If either flush() or out.close() throw exception the 1st time
>         close() is
>         
> 
>         called, they will both be called also the 2nd time. Only after
>         flush()
>         
> 
>         and out.close() return successfully, then further flush()
>         invocations
>         
> 
>         are suppressed.
>         
> 
>         
> 
>         The alternative would be to not suppress flush() invocations,
>         but just
>         
> 
>         any exception thrown from flush():
>         
> 
>         
> 
>         
> 
>              private boolean closed;
>         
> 
>         
> 
>              public void close() throws IOException {
>         
> 
>                  try (OutputStream ostream = out) {
>         
> 
>                      try {
>         
> 
>                          flush();
>         
> 
>                      } catch (IOException | RuntimeException | Error e)
>         {
>         
> 
>                          if (!closed) throw e;
>         
> 
>                      }
>         
> 
>                  }
>         
> 
>                  closed = true;
>         
> 
>              }
>         
> 
>         
> 
>         
> 
>         But I don't know if this is better or worse. It certainly could
>         still be
>         
> 
>         squeezed under the spec which says:
>         
> 
>         
> 
>               * The <code>close</code> method of
>         <code>FilterOutputStream</code>
>         
> 
>               * calls its <code>flush</code> method, and
>         then calls the
>         
> 
>               * <code>close</code> method of its underlying
>         output stream.
>         
> 
>         
> 
>         
> 
>         Regards, Peter
>         
> 
>         
> 
>         
>           
> 
>           I don't see any reason to make 'closed' protected ( part of
>           the public
>           
> 
>           Java SE API ), something like:
>           
> 
>           
> 
>           diff --git
>           
> 
>           a/src/java.base/share/classes/java/io/FilterOutputStream.java
>           
> 
>           b/src/java.base/share/classes/java/io/FilterOutputStream.java
>           
> 
>           ---
>           a/src/java.base/share/classes/java/io/FilterOutputStream.java
>           
> 
>           +++
>           b/src/java.base/share/classes/java/io/FilterOutputStream.java
>           
> 
>           @@ -48,6 +48,8 @@
>           
> 
>                 */
>           
> 
>                protected OutputStream out;
>           
> 
>           
> 
>           +    private boolean closed; // false
>           
> 
>           +
>           
> 
>                /**
>           
> 
>                 * Creates an output stream filter built on top of the
>           specified
>           
> 
>                 * underlying output stream.
>           
> 
>           @@ -154,6 +156,9 @@
>           
> 
>                 */
>           
> 
>                @SuppressWarnings("try")
>           
> 
>                public void close() throws IOException {
>           
> 
>           +        if (closed)
>           
> 
>           +            return;
>           
> 
>           +        closed = true;
>           
> 
>                    try (OutputStream ostream = out) {
>           
> 
>                        flush();
>           
> 
>                    }
>           
> 
>           
> 
>           diff --git a/test/java/io/etc/FailingFlushAndClose.java
>           
> 
>           b/test/java/io/etc/FailingFlushAndClose.java
>           
> 
>           --- a/test/java/io/etc/FailingFlushAndClose.java
>           
> 
>           +++ b/test/java/io/etc/FailingFlushAndClose.java
>           
> 
>           @@ -25,7 +25,7 @@
>           
> 
>           
> 
>            /**
>           
> 
>             * @test
>           
> 
>           - * @bug 7015589
>           
> 
>           + * @bug 7015589 8054565
>           
> 
>             * @summary Test that buffering streams are considered closed
>           even
>           
> 
>           when the
>           
> 
>             *    close or flush from the underlying stream fails.
>           
> 
>             */
>           
> 
>           @@ -165,7 +165,7 @@
>           
> 
>                    }
>           
> 
>                }
>           
> 
>           
> 
>           -    static void testFailingClose(InputStream in) throws
>           IOException {
>           
> 
>           +    static InputStream testFailingClose(InputStream in)
>           throws
>           
> 
>           IOException {
>           
> 
>                    System.out.println(in.getClass());
>           
> 
>                    in.read(new byte[100]);
>           
> 
>                    try {
>           
> 
>           @@ -176,9 +176,10 @@
>           
> 
>                        in.read(new byte[100]);
>           
> 
>                        fail("read did not fail");
>           
> 
>                    } catch (IOException expected) { }
>           
> 
>           +        return in;
>           
> 
>                }
>           
> 
>           
> 
>           -    static void testFailingClose(OutputStream out) throws
>           IOException {
>           
> 
>           +    static OutputStream testFailingClose(OutputStream out)
>           throws
>           
> 
>           IOException {
>           
> 
>                    System.out.println(out.getClass());
>           
> 
>                    out.write(1);
>           
> 
>                    try {
>           
> 
>           @@ -190,9 +191,10 @@
>           
> 
>                        if (!(out instanceof BufferedOutputStream))
>           
> 
>                            fail("write did not fail");
>           
> 
>                    } catch (IOException expected) { }
>           
> 
>           +        return out;
>           
> 
>                }
>           
> 
>           
> 
>           -    static void testFailingFlush(OutputStream out) throws
>           IOException {
>           
> 
>           +    static OutputStream testFailingFlush(OutputStream out)
>           throws
>           
> 
>           IOException {
>           
> 
>                    System.out.println(out.getClass());
>           
> 
>                    out.write(1);
>           
> 
>                    try {
>           
> 
>           @@ -206,9 +208,27 @@
>           
> 
>                            fail("close did not fail");
>           
> 
>                        } catch (IOException expected) { }
>           
> 
>                    }
>           
> 
>           +        return out;
>           
> 
>                }
>           
> 
>           
> 
>           -    static void testFailingClose(Reader r) throws IOException
>           {
>           
> 
>           +    static void closeAgain(InputStream in) throws IOException
>           {
>           
> 
>           +        // assert the given stream should already be closed.
>           
> 
>           +        try {
>           
> 
>           +            in.close();
>           
> 
>           +        } catch (IOException expected) {
>           
> 
>           +            fail("unexpected IOException from subsequent
>           close");
>           
> 
>           +        }
>           
> 
>           +    }
>           
> 
>           +    static void closeAgain(OutputStream out) throws
>           IOException {
>           
> 
>           +        // assert the given stream should already be closed.
>           
> 
>           +        try {
>           
> 
>           +            out.close();
>           
> 
>           +        } catch (IOException expected) {
>           
> 
>           +            fail("unexpected IOException from subsequent
>           close");
>           
> 
>           +        }
>           
> 
>           +    }
>           
> 
>           +
>           
> 
>           +    static Reader testFailingClose(Reader r) throws
>           IOException {
>           
> 
>                    System.out.println(r.getClass());
>           
> 
>                    r.read(new char[100]);
>           
> 
>                    try {
>           
> 
>           @@ -219,9 +239,10 @@
>           
> 
>                        r.read(new char[100]);
>           
> 
>                        fail("read did not fail");
>           
> 
>                    } catch (IOException expected) { }
>           
> 
>           +        return r;
>           
> 
>                }
>           
> 
>           
> 
>           -    static void testFailingClose(Writer w) throws IOException
>           {
>           
> 
>           +    static Writer testFailingClose(Writer w) throws
>           IOException {
>           
> 
>                    System.out.println(w.getClass());
>           
> 
>                    w.write("message");
>           
> 
>                    try {
>           
> 
>           @@ -232,9 +253,10 @@
>           
> 
>                        w.write("another message");
>           
> 
>                        fail("write did not fail");
>           
> 
>                    } catch (IOException expected) { }
>           
> 
>           +        return w;
>           
> 
>                }
>           
> 
>           
> 
>           -    static void testFailingFlush(Writer w) throws IOException
>           {
>           
> 
>           +    static Writer testFailingFlush(Writer w) throws
>           IOException {
>           
> 
>                    System.out.println(w.getClass());
>           
> 
>                    w.write("message");
>           
> 
>                    try {
>           
> 
>           @@ -249,18 +271,38 @@
>           
> 
>                            fail("close did not fail");
>           
> 
>                        } catch (IOException expected) { }
>           
> 
>                    }
>           
> 
>           +        return w;
>           
> 
>           +    }
>           
> 
>           +
>           
> 
>           +    static Reader closeAgain(Reader r) throws IOException {
>           
> 
>           +        // assert the given stream should already be closed.
>           
> 
>           +        try {
>           
> 
>           +            r.close();
>           
> 
>           +        } catch (IOException expected) {
>           
> 
>           +            fail("unexpected IOException from subsequent
>           close");
>           
> 
>           +        }
>           
> 
>           +        return r;
>           
> 
>           +    }
>           
> 
>           +    static Writer closeAgain(Writer w) throws IOException {
>           
> 
>           +        // assert the given stream should already be closed.
>           
> 
>           +        try {
>           
> 
>           +            w.close();
>           
> 
>           +        } catch (IOException expected) {
>           
> 
>           +            fail("unexpected IOException from subsequent
>           close");
>           
> 
>           +        }
>           
> 
>           +        return w;
>           
> 
>                }
>           
> 
>           
> 
>                public static void main(String[] args) throws IOException
>           {
>           
> 
>           
> 
>           -        testFailingClose(new BufferedInputStream(new
>           
> 
>           FailingCloseInputStream()));
>           
> 
>           -        testFailingClose(new BufferedOutputStream(new
>           
> 
>           FailingCloseOutputStream()));
>           
> 
>           +        closeAgain(testFailingClose(new
>           BufferedInputStream(new
>           
> 
>           FailingCloseInputStream())));
>           
> 
>           +        closeAgain(testFailingClose(new
>           BufferedOutputStream(new
>           
> 
>           FailingCloseOutputStream())));
>           
> 
>           
> 
>           -        testFailingClose(new BufferedReader(new
>           FailingCloseReader()));
>           
> 
>           -        testFailingClose(new BufferedWriter(new
>           FailingCloseWriter()));
>           
> 
>           +        closeAgain(testFailingClose(new BufferedReader(new
>           
> 
>           FailingCloseReader())));
>           
> 
>           +        closeAgain(testFailingClose(new BufferedWriter(new
>           
> 
>           FailingCloseWriter())));
>           
> 
>           
> 
>           -        testFailingFlush(new BufferedOutputStream(new
>           
> 
>           FailingFlushOutputStream()));
>           
> 
>           -        testFailingFlush(new BufferedWriter(new
>           FailingFlushWriter()));
>           
> 
>           +        closeAgain(testFailingFlush(new
>           BufferedOutputStream(new
>           
> 
>           FailingFlushOutputStream())));
>           
> 
>           +        closeAgain(testFailingFlush(new BufferedWriter(new
>           
> 
>           FailingFlushWriter())));
>           
> 
>           
> 
>                    if (failed > 0)
>           
> 
>                        throw new RuntimeException(failed + " test(s)
>           failed -
>           
> 
>           see log for details");
>           
> 
>           
> 
>           
> 
>           -Chris.
>           
> 
>           
> 
>           [1] https://bugs.openjdk.java.net/browse/JDK-7015589
>           
> 
>           [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/759aa847dcaf
>           
> 
>           
> 
>           
> 
>           -Pavel
>             
> 
>             
> 
>             On 5 Dec 2014, at 01:18, Vitaly
>               Davidovich <vitalyd at gmail.com> wrote:
>               
> 
>               
> 
>               Attempting to make close() atomic just makes the next
>               reader
>               
> 
>               confused when the rest of the class isn't and may also
>               penalize single
>               
> 
>               threaded callers of close().
>               
> 
>             
>             
> 
>           
>         
>         
> 
>       
>     
>     
> 
>   
> 
> 
>  		 	   		  
 		 	   		  

From erik.joelsson at oracle.com  Mon Dec 15 08:56:11 2014
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 15 Dec 2014 09:56:11 +0100
Subject: Review request: JDK-8067360: verify-modules target was dropped
	in jdk9 b41
In-Reply-To: <548B3330.3050104@oracle.com>
References: <548B3330.3050104@oracle.com>
Message-ID: <548EA22B.309@oracle.com>

Looks good to me. I don't mind if you fix javadoc in the same change. 
It's such a small issue I rather not go through the hassle of creating a 
bug and a new review.

Thanks!
/Erik

On 2014-12-12 19:25, Mandy Chung wrote:
> Webrev:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8067360/webrev.00/
>
> This patch adds back the verify-modules target to the dependences of 
> the images target that got dropped in the merge and hides a bug in 
> jdeps -Xverify:access.
>
> Erik - I notice make/Javadoc.gmk that sets -bootclasspath 
> $(JDK_OUTPUTDIR)/classes that does not exist.  I include a patch to 
> make/Javadoc.gmk in the webrev.  Do you prefer to separate it and file 
> a new bug for it?
>
> Mandy
>
>



From chris.hegarty at oracle.com  Mon Dec 15 09:56:35 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 15 Dec 2014 09:56:35 +0000
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <COL131-W843B7101077FF11EC708FBCA6F0@phx.gbl>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>,
	<54807258.4040303@oracle.com>	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>,
	<20141205002430.000060c9.ecki@zusammenkunft.net>,
	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>,
	<20141205015827.00007ac6.ecki@zusammenkunft.net>,
	<CAHjP37HgKZMhjq6_AVZFAdPy4PeZBd7p6JBT0Jt2FqE42eB6Ow@mail.gmail.com>,
	<8F896CE2-E268-418F-96CA-0557C1C258B3@oracle.com>,
	<5481BB6C.1040700@oracle.com> <5481C3DB.70303@gmail.com>,
	<5481CA8C.7050100@oracle.com> <5481EF01.6060009@gmail.com>, ,
	<C517EC9F-7136-4252-BA5B-FFE8C2CBD4B4@oracle.com>,
	<COL131-W3093E62A5924C2DC984C5FCA650@phx.gbl>
	<COL131-W843B7101077FF11EC708FBCA6F0@phx.gbl>
Message-ID: <548EB053.2040908@oracle.com>

On 15/12/14 05:21, Nathan Clement wrote:
> Hi,
>
> What's the process for finalizing a decision and getting this bug fixed?
>
> Apologies if I'm violating a social norm by asking this - I'm new to
> this process and I'm not sure exactly how decisions are made.

You are not violating anything, and it is quite reasonable to expect a 
timely outcome in this situation.

I was asked, privately, to hold off pushing the change for this until 
someone, who was involved in the original change that caused the 
behavior change, had time to review. I will ping that individual again, 
and move this forward.

-Chris.

> Thanks,
>
> Nathan
>
>  > From: nathan.a.clement at hotmail.com
>  > To: chris.hegarty at oracle.com; peter.levart at gmail.com
>  > Subject: RE: [PATCH] JDK-8054565: FilterOutputStream.close may throw
> IOException if called twice and underlying flush or close fails
>  > Date: Tue, 9 Dec 2014 16:17:29 +1100
>  > CC: core-libs-dev at openjdk.java.net
>  >
>  > Hi,
>  >
>  > I'd be happy with any of the solutions discussed here. In our case,
> we're only calling close() multiple times as a result of the way that
> try-with-resources works with wrapped streams.
>  >
>  > Thanks,
>  >
>  > Nathan
>  >
>  > Subject: Re: [PATCH] JDK-8054565: FilterOutputStream.close may throw
> IOException if called twice and underlying flush or close fails
>  > From: chris.hegarty at oracle.com
>  > Date: Fri, 5 Dec 2014 22:37:04 +0000
>  > CC: pavel.rappo at oracle.com; nathan.a.clement at hotmail.com;
> core-libs-dev at openjdk.java.net
>  > To: peter.levart at gmail.com
>  >
>  >
>  > On 5 Dec 2014, at 17:44, Peter Levart <peter.levart at gmail.com> wrote:
>  >
>  >
>  >
>  >
>  > On 12/05/2014 04:09 PM, Chris Hegarty
>  > wrote:
>  >
>  >
>  > On
>  > 05/12/14 14:40, Peter Levart wrote:
>  >
>  >
>  > On 12/05/2014 03:04 PM, Chris Hegarty
>  > wrote:
>  >
>  >
>  >
>  >
>  >
>  > On 05/12/14 11:38, Pavel Rappo wrote:
>  >
>  >
>  > +1, I couldn?t say better
>  >
>  >
>  >
>  >
>  >
>  > Right. This bug should only try to address the change in
>  > behavior that
>  >
>  >
>  > was inadvertently introduced by 7015589[1][2].
>  >
>  >
>  >
>  >
>  >
>  > What about the following:
>  >
>  >
>  >
>  >
>  >
>  >
>  > private boolean closed;
>  >
>  >
>  >
>  >
>  > public void close() throws IOException {
>  >
>  >
>  > try (OutputStream ostream = out) {
>  >
>  >
>  > if (!closed) flush();
>  >
>  >
>  > }
>  >
>  >
>  > closed = true;
>  >
>  >
>  > }
>  >
>  >
>  >
>  >
>  >
>  > If flush throws, how is anyone supposed to know that they need to
>  > call close again, and that it was not the close that actually
>  > threw?
>  >
>  >
>  >
>  >
>  >
>  > If they call close() again because they are used to pre 7015589
>  > behaviour,
>  > I don?t think I have every seen any code that catches the IOException
> from close() , and tries to close again. But maybe someone does this?
>  > From AutoCloseable: ?Cases where the close operation may fail require
> careful attention by implementers. It is strongly advised to relinquish
> the underlying resources and to internally mark the resource as closed,
> prior to throwing the exception. The close method is unlikely to be
> invoked more than once and so this ensures that the resources are
> released in a timely manner. Furthermore it reduces problems that could
> arise when the resource wraps, or is wrapped, by another resource.?
>  > I think the changes I am proposing follows this advise ( as best we
> can ).
>  > there is no harm if they call it as a consequence of
>  > flush() throwing and out.close() succeeding, since the underlying
>  > stream should
>  > Yes, ?should".
>  > have idempotent "successful" close(). That's the
>  > requirement of Closeable.close():
>  >
>  >
>  >
>  >
>  > /**
>  >
>  > * Closes this stream and
>  > releases any system resources associated
>  >
>  > * with it. If the stream is
>  > already closed then invoking this
>  >
>  > * method has no effect.
>  >
>  > FilterOutputStream is Closeable, but what you are suggesting is that
> subsequent calls to close would have an effect, they may call flush.
>  >
>  > * <p> As noted in {@link
>  > AutoCloseable#close()}, cases where the
>  >
>  > * close may fail require
>  > careful attention. It is strongly advised
>  >
>  > * to relinquish the underlying
>  > resources and to internally
>  >
>  > * <em>mark</em> the
>  > {@code Closeable} as closed, prior to throwing
>  >
>  > * the {@code IOException}.
>  >
>  > *
>  >
>  > * @throws IOException if an I/O
>  > error occurs
>  >
>  > */
>  >
>  >
>  >
>  > The specification does not say if the stream is to be considered
>  > "closed" when close() throws IOException. The advice does hint that
>  > though (and was added about 3 years ago).
>  > Re-reading the advise in AutoCloseable and Closeable, I do not see
> any problem with the changes I suggested.
>  > -Chris.
>  >
>  > close() should be a one-time shot.
>  >
>  >
>  >
>  >
>  > I personally think that this was an oversight of the original
>  > change in 7015589, and not a deliberate behavior. My proposed
>  > change will restore the behavior of close to pre 7015589, though
>  > not swallow the IOException from flush.
>  >
>  >
>  >
>  >
>  >
>  > The pre 7015589 behaviour did not suppress multiple close() calls to
>  > underlying stream.
>  >
>  >
>  >
>  >
>  >
>  >
>  > -Chris.
>  >
>  >
>  >
>  >
>  >
>  > I just think that a delegating class like FilterOutputStream should
>  > be as transparent as possible. If the underlying stream respects the
>  > contract and advice, the wrapped stream should too. If underlying
>  > stream needs some out-of-advice treatment, then wrapper like
>  > FilterOutputStream should not prevent that, because there are all
>  > kinds of streams out there. Or maybe it should - this is the only
>  > way to "fix" those streams ;-)
>  >
>  >
>  >
>  > Just do it!
>  >
>  >
>  >
>  > Regards, Peter
>  >
>  >
>  >
>  >
>  >
>  >
>  > ...this way the impact of the change is
>  > minimal and still addresses the
>  >
>  >
>  > problem of JDK-8054565
>  > <https://bugs.openjdk.java.net/browse/JDK-8054565>.
>  >
>  >
>  >
>  >
>  > If either flush() or out.close() throw exception the 1st time
>  > close() is
>  >
>  >
>  > called, they will both be called also the 2nd time. Only after
>  > flush()
>  >
>  >
>  > and out.close() return successfully, then further flush()
>  > invocations
>  >
>  >
>  > are suppressed.
>  >
>  >
>  >
>  >
>  > The alternative would be to not suppress flush() invocations,
>  > but just
>  >
>  >
>  > any exception thrown from flush():
>  >
>  >
>  >
>  >
>  >
>  >
>  > private boolean closed;
>  >
>  >
>  >
>  >
>  > public void close() throws IOException {
>  >
>  >
>  > try (OutputStream ostream = out) {
>  >
>  >
>  > try {
>  >
>  >
>  > flush();
>  >
>  >
>  > } catch (IOException | RuntimeException | Error e)
>  > {
>  >
>  >
>  > if (!closed) throw e;
>  >
>  >
>  > }
>  >
>  >
>  > }
>  >
>  >
>  > closed = true;
>  >
>  >
>  > }
>  >
>  >
>  >
>  >
>  >
>  >
>  > But I don't know if this is better or worse. It certainly could
>  > still be
>  >
>  >
>  > squeezed under the spec which says:
>  >
>  >
>  >
>  >
>  > * The <code>close</code> method of
>  > <code>FilterOutputStream</code>
>  >
>  >
>  > * calls its <code>flush</code> method, and
>  > then calls the
>  >
>  >
>  > * <code>close</code> method of its underlying
>  > output stream.
>  >
>  >
>  >
>  >
>  >
>  >
>  > Regards, Peter
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  > I don't see any reason to make 'closed' protected ( part of
>  > the public
>  >
>  >
>  > Java SE API ), something like:
>  >
>  >
>  >
>  >
>  > diff --git
>  >
>  >
>  > a/src/java.base/share/classes/java/io/FilterOutputStream.java
>  >
>  >
>  > b/src/java.base/share/classes/java/io/FilterOutputStream.java
>  >
>  >
>  > ---
>  > a/src/java.base/share/classes/java/io/FilterOutputStream.java
>  >
>  >
>  > +++
>  > b/src/java.base/share/classes/java/io/FilterOutputStream.java
>  >
>  >
>  > @@ -48,6 +48,8 @@
>  >
>  >
>  > */
>  >
>  >
>  > protected OutputStream out;
>  >
>  >
>  >
>  >
>  > + private boolean closed; // false
>  >
>  >
>  > +
>  >
>  >
>  > /**
>  >
>  >
>  > * Creates an output stream filter built on top of the
>  > specified
>  >
>  >
>  > * underlying output stream.
>  >
>  >
>  > @@ -154,6 +156,9 @@
>  >
>  >
>  > */
>  >
>  >
>  > @SuppressWarnings("try")
>  >
>  >
>  > public void close() throws IOException {
>  >
>  >
>  > + if (closed)
>  >
>  >
>  > + return;
>  >
>  >
>  > + closed = true;
>  >
>  >
>  > try (OutputStream ostream = out) {
>  >
>  >
>  > flush();
>  >
>  >
>  > }
>  >
>  >
>  >
>  >
>  > diff --git a/test/java/io/etc/FailingFlushAndClose.java
>  >
>  >
>  > b/test/java/io/etc/FailingFlushAndClose.java
>  >
>  >
>  > --- a/test/java/io/etc/FailingFlushAndClose.java
>  >
>  >
>  > +++ b/test/java/io/etc/FailingFlushAndClose.java
>  >
>  >
>  > @@ -25,7 +25,7 @@
>  >
>  >
>  >
>  >
>  > /**
>  >
>  >
>  > * @test
>  >
>  >
>  > - * @bug 7015589
>  >
>  >
>  > + * @bug 7015589 8054565
>  >
>  >
>  > * @summary Test that buffering streams are considered closed
>  > even
>  >
>  >
>  > when the
>  >
>  >
>  > * close or flush from the underlying stream fails.
>  >
>  >
>  > */
>  >
>  >
>  > @@ -165,7 +165,7 @@
>  >
>  >
>  > }
>  >
>  >
>  > }
>  >
>  >
>  >
>  >
>  > - static void testFailingClose(InputStream in) throws
>  > IOException {
>  >
>  >
>  > + static InputStream testFailingClose(InputStream in)
>  > throws
>  >
>  >
>  > IOException {
>  >
>  >
>  > System.out.println(in.getClass());
>  >
>  >
>  > in.read(new byte[100]);
>  >
>  >
>  > try {
>  >
>  >
>  > @@ -176,9 +176,10 @@
>  >
>  >
>  > in.read(new byte[100]);
>  >
>  >
>  > fail("read did not fail");
>  >
>  >
>  > } catch (IOException expected) { }
>  >
>  >
>  > + return in;
>  >
>  >
>  > }
>  >
>  >
>  >
>  >
>  > - static void testFailingClose(OutputStream out) throws
>  > IOException {
>  >
>  >
>  > + static OutputStream testFailingClose(OutputStream out)
>  > throws
>  >
>  >
>  > IOException {
>  >
>  >
>  > System.out.println(out.getClass());
>  >
>  >
>  > out.write(1);
>  >
>  >
>  > try {
>  >
>  >
>  > @@ -190,9 +191,10 @@
>  >
>  >
>  > if (!(out instanceof BufferedOutputStream))
>  >
>  >
>  > fail("write did not fail");
>  >
>  >
>  > } catch (IOException expected) { }
>  >
>  >
>  > + return out;
>  >
>  >
>  > }
>  >
>  >
>  >
>  >
>  > - static void testFailingFlush(OutputStream out) throws
>  > IOException {
>  >
>  >
>  > + static OutputStream testFailingFlush(OutputStream out)
>  > throws
>  >
>  >
>  > IOException {
>  >
>  >
>  > System.out.println(out.getClass());
>  >
>  >
>  > out.write(1);
>  >
>  >
>  > try {
>  >
>  >
>  > @@ -206,9 +208,27 @@
>  >
>  >
>  > fail("close did not fail");
>  >
>  >
>  > } catch (IOException expected) { }
>  >
>  >
>  > }
>  >
>  >
>  > + return out;
>  >
>  >
>  > }
>  >
>  >
>  >
>  >
>  > - static void testFailingClose(Reader r) throws IOException
>  > {
>  >
>  >
>  > + static void closeAgain(InputStream in) throws IOException
>  > {
>  >
>  >
>  > + // assert the given stream should already be closed.
>  >
>  >
>  > + try {
>  >
>  >
>  > + in.close();
>  >
>  >
>  > + } catch (IOException expected) {
>  >
>  >
>  > + fail("unexpected IOException from subsequent
>  > close");
>  >
>  >
>  > + }
>  >
>  >
>  > + }
>  >
>  >
>  > + static void closeAgain(OutputStream out) throws
>  > IOException {
>  >
>  >
>  > + // assert the given stream should already be closed.
>  >
>  >
>  > + try {
>  >
>  >
>  > + out.close();
>  >
>  >
>  > + } catch (IOException expected) {
>  >
>  >
>  > + fail("unexpected IOException from subsequent
>  > close");
>  >
>  >
>  > + }
>  >
>  >
>  > + }
>  >
>  >
>  > +
>  >
>  >
>  > + static Reader testFailingClose(Reader r) throws
>  > IOException {
>  >
>  >
>  > System.out.println(r.getClass());
>  >
>  >
>  > r.read(new char[100]);
>  >
>  >
>  > try {
>  >
>  >
>  > @@ -219,9 +239,10 @@
>  >
>  >
>  > r.read(new char[100]);
>  >
>  >
>  > fail("read did not fail");
>  >
>  >
>  > } catch (IOException expected) { }
>  >
>  >
>  > + return r;
>  >
>  >
>  > }
>  >
>  >
>  >
>  >
>  > - static void testFailingClose(Writer w) throws IOException
>  > {
>  >
>  >
>  > + static Writer testFailingClose(Writer w) throws
>  > IOException {
>  >
>  >
>  > System.out.println(w.getClass());
>  >
>  >
>  > w.write("message");
>  >
>  >
>  > try {
>  >
>  >
>  > @@ -232,9 +253,10 @@
>  >
>  >
>  > w.write("another message");
>  >
>  >
>  > fail("write did not fail");
>  >
>  >
>  > } catch (IOException expected) { }
>  >
>  >
>  > + return w;
>  >
>  >
>  > }
>  >
>  >
>  >
>  >
>  > - static void testFailingFlush(Writer w) throws IOException
>  > {
>  >
>  >
>  > + static Writer testFailingFlush(Writer w) throws
>  > IOException {
>  >
>  >
>  > System.out.println(w.getClass());
>  >
>  >
>  > w.write("message");
>  >
>  >
>  > try {
>  >
>  >
>  > @@ -249,18 +271,38 @@
>  >
>  >
>  > fail("close did not fail");
>  >
>  >
>  > } catch (IOException expected) { }
>  >
>  >
>  > }
>  >
>  >
>  > + return w;
>  >
>  >
>  > + }
>  >
>  >
>  > +
>  >
>  >
>  > + static Reader closeAgain(Reader r) throws IOException {
>  >
>  >
>  > + // assert the given stream should already be closed.
>  >
>  >
>  > + try {
>  >
>  >
>  > + r.close();
>  >
>  >
>  > + } catch (IOException expected) {
>  >
>  >
>  > + fail("unexpected IOException from subsequent
>  > close");
>  >
>  >
>  > + }
>  >
>  >
>  > + return r;
>  >
>  >
>  > + }
>  >
>  >
>  > + static Writer closeAgain(Writer w) throws IOException {
>  >
>  >
>  > + // assert the given stream should already be closed.
>  >
>  >
>  > + try {
>  >
>  >
>  > + w.close();
>  >
>  >
>  > + } catch (IOException expected) {
>  >
>  >
>  > + fail("unexpected IOException from subsequent
>  > close");
>  >
>  >
>  > + }
>  >
>  >
>  > + return w;
>  >
>  >
>  > }
>  >
>  >
>  >
>  >
>  > public static void main(String[] args) throws IOException
>  > {
>  >
>  >
>  >
>  >
>  > - testFailingClose(new BufferedInputStream(new
>  >
>  >
>  > FailingCloseInputStream()));
>  >
>  >
>  > - testFailingClose(new BufferedOutputStream(new
>  >
>  >
>  > FailingCloseOutputStream()));
>  >
>  >
>  > + closeAgain(testFailingClose(new
>  > BufferedInputStream(new
>  >
>  >
>  > FailingCloseInputStream())));
>  >
>  >
>  > + closeAgain(testFailingClose(new
>  > BufferedOutputStream(new
>  >
>  >
>  > FailingCloseOutputStream())));
>  >
>  >
>  >
>  >
>  > - testFailingClose(new BufferedReader(new
>  > FailingCloseReader()));
>  >
>  >
>  > - testFailingClose(new BufferedWriter(new
>  > FailingCloseWriter()));
>  >
>  >
>  > + closeAgain(testFailingClose(new BufferedReader(new
>  >
>  >
>  > FailingCloseReader())));
>  >
>  >
>  > + closeAgain(testFailingClose(new BufferedWriter(new
>  >
>  >
>  > FailingCloseWriter())));
>  >
>  >
>  >
>  >
>  > - testFailingFlush(new BufferedOutputStream(new
>  >
>  >
>  > FailingFlushOutputStream()));
>  >
>  >
>  > - testFailingFlush(new BufferedWriter(new
>  > FailingFlushWriter()));
>  >
>  >
>  > + closeAgain(testFailingFlush(new
>  > BufferedOutputStream(new
>  >
>  >
>  > FailingFlushOutputStream())));
>  >
>  >
>  > + closeAgain(testFailingFlush(new BufferedWriter(new
>  >
>  >
>  > FailingFlushWriter())));
>  >
>  >
>  >
>  >
>  > if (failed > 0)
>  >
>  >
>  > throw new RuntimeException(failed + " test(s)
>  > failed -
>  >
>  >
>  > see log for details");
>  >
>  >
>  >
>  >
>  >
>  >
>  > -Chris.
>  >
>  >
>  >
>  >
>  > [1] https://bugs.openjdk.java.net/browse/JDK-7015589
>  >
>  >
>  > [2] http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/759aa847dcaf
>  >
>  >
>  >
>  >
>  >
>  >
>  > -Pavel
>  >
>  >
>  >
>  >
>  > On 5 Dec 2014, at 01:18, Vitaly
>  > Davidovich <vitalyd at gmail.com> wrote:
>  >
>  >
>  >
>  >
>  > Attempting to make close() atomic just makes the next
>  > reader
>  >
>  >
>  > confused when the rest of the class isn't and may also
>  > penalize single
>  >
>  >
>  > threaded callers of close().
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >


From ivan.gerasimov at oracle.com  Mon Dec 15 10:53:08 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 15 Dec 2014 13:53:08 +0300
Subject: Java implementation of Alpha-numeric comparator
Message-ID: <548EBD94.1070804@oracle.com>

Hello everyone!

In certain situations the preferred way of sorting strings is a 
combination of char-comparing sorting with numeric sorting, where 
applicable.
List of strings sorted this way often look more natural to the human eyes:
{ "alpha",
   "java1",
   "java2",
   "java10",
   "zero" }

Here's presented a sample implementation of the comparator, which 
supports this way of sorting.
I placed it under src/sample directory.

http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/0/webrev/


MSDN provides the function StrCmpLogicalW(), which can be used for 
similar sort order.
http://msdn.microsoft.com/en-us/library/windows/desktop/bb759947%28v=vs.85%29.aspx

The differences are:
  - case-sensitivity (StrCmpLogicalW is case-insensitive);
  - treating leading zeroes;
  - more accurate handling of strings with big numbers, which cannot be 
converted to int/long.

I guess this comparator may become particularly useful when we'll have 
'java10' and update releases/build numbers > 99 in the lists :)

I want to ask the community about how useful this comparator may be to you?

Sincerely yours,
Ivan



From konstantin.shefov at oracle.com  Mon Dec 15 11:15:35 2014
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Mon, 15 Dec 2014 14:15:35 +0300
Subject: [9] Review request : JDK-6933879: URISyntaxException when
	non-alphanumeric characters are present in scope_id
In-Reply-To: <54897B63.30801@oracle.com>
References: <54886510.1010704@oracle.com> <54897B63.30801@oracle.com>
Message-ID: <548EC2D7.6000604@oracle.com>

Gently reminder. Please review.

-Konstantin

On 11.12.2014 14:09, Konstantin Shefov wrote:
> CC'ed core-libs-dev at openjdk.java.net
>
> On 10.12.2014 18:21, Konstantin Shefov wrote:
>> Hello,
>>
>> Please, review the bug fix: 
>> https://bugs.openjdk.java.net/browse/JDK-6933879
>> Webrev: http://cr.openjdk.java.net/~kshefov/6933879/webrev.00
>>
>> It is suggested to add some more symbols allowed for scope id in IPv6 
>> URI, namely "_", "." and ":", because these symbols may be included 
>> in network interface names. Now only alphanumeric characters are 
>> allowed to be in a scope id.
>>
>> Thanks
>> -Konstantin
>



From chris.hegarty at oracle.com  Mon Dec 15 11:25:40 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 15 Dec 2014 11:25:40 +0000
Subject: [9] Review request : JDK-6933879: URISyntaxException when
	non-alphanumeric characters are present in scope_id
In-Reply-To: <548EC2D7.6000604@oracle.com>
References: <54886510.1010704@oracle.com> <54897B63.30801@oracle.com>
	<548EC2D7.6000604@oracle.com>
Message-ID: <548EC534.2090803@oracle.com>

Konstantin,

I did reply to this RFR [1], with a question, that is still unanswered.

-Chris.

[1] http://mail.openjdk.java.net/pipermail/net-dev/2014-December/008782.html

On 15/12/14 11:15, Konstantin Shefov wrote:
> Gently reminder. Please review.
>
> -Konstantin
>
> On 11.12.2014 14:09, Konstantin Shefov wrote:
>> CC'ed core-libs-dev at openjdk.java.net
>>
>> On 10.12.2014 18:21, Konstantin Shefov wrote:
>>> Hello,
>>>
>>> Please, review the bug fix:
>>> https://bugs.openjdk.java.net/browse/JDK-6933879
>>> Webrev: http://cr.openjdk.java.net/~kshefov/6933879/webrev.00
>>>
>>> It is suggested to add some more symbols allowed for scope id in IPv6
>>> URI, namely "_", "." and ":", because these symbols may be included
>>> in network interface names. Now only alphanumeric characters are
>>> allowed to be in a scope id.
>>>
>>> Thanks
>>> -Konstantin
>>
>


From konstantin.shefov at oracle.com  Mon Dec 15 11:31:37 2014
From: konstantin.shefov at oracle.com (Konstantin Shefov)
Date: Mon, 15 Dec 2014 14:31:37 +0300
Subject: [9] Review request : JDK-6933879: URISyntaxException when
	non-alphanumeric characters are present in scope_id
In-Reply-To: <548EC534.2090803@oracle.com>
References: <54886510.1010704@oracle.com> <54897B63.30801@oracle.com>
	<548EC2D7.6000604@oracle.com> <548EC534.2090803@oracle.com>
Message-ID: <548EC699.8060907@oracle.com>

Chris, thank you. I see your answer now.

I will try to reproduce NetworkInterface.getName() returning interface 
name with the chars in question.
As far as I understood the bug, customers needed URI with scope id 
containing "." symbol, and now they use URL class instead of URI for that.

-Konstantin

On 15.12.2014 14:25, Chris Hegarty wrote:
> Konstantin,
>
> I did reply to this RFR [1], with a question, that is still unanswered.
>
> -Chris.
>
> [1] 
> http://mail.openjdk.java.net/pipermail/net-dev/2014-December/008782.html
>
> On 15/12/14 11:15, Konstantin Shefov wrote:
>> Gently reminder. Please review.
>>
>> -Konstantin
>>
>> On 11.12.2014 14:09, Konstantin Shefov wrote:
>>> CC'ed core-libs-dev at openjdk.java.net
>>>
>>> On 10.12.2014 18:21, Konstantin Shefov wrote:
>>>> Hello,
>>>>
>>>> Please, review the bug fix:
>>>> https://bugs.openjdk.java.net/browse/JDK-6933879
>>>> Webrev: http://cr.openjdk.java.net/~kshefov/6933879/webrev.00
>>>>
>>>> It is suggested to add some more symbols allowed for scope id in IPv6
>>>> URI, namely "_", "." and ":", because these symbols may be included
>>>> in network interface names. Now only alphanumeric characters are
>>>> allowed to be in a scope id.
>>>>
>>>> Thanks
>>>> -Konstantin
>>>
>>



From Alan.Bateman at oracle.com  Mon Dec 15 12:01:40 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 15 Dec 2014 12:01:40 +0000
Subject: [9] Review request : JDK-6933879: URISyntaxException when
	non-alphanumeric characters are present in scope_id
In-Reply-To: <548EC534.2090803@oracle.com>
References: <54886510.1010704@oracle.com> <54897B63.30801@oracle.com>
	<548EC2D7.6000604@oracle.com> <548EC534.2090803@oracle.com>
Message-ID: <548ECDA4.9070002@oracle.com>

On 15/12/2014 11:25, Chris Hegarty wrote:
> Konstantin,
>
> I did reply to this RFR [1], with a question, that is still unanswered.
>
> -Chris.
>
> [1] 
> http://mail.openjdk.java.net/pipermail/net-dev/2014-December/008782.html
>
I can think of configurations where the scenario could arise. It make me 
wonder if this will require a spec clarification as scope_id is defined 
in Inet6Address to allow any String and so raises the question as to the 
characters permitted in the host component.

-Alan


From aleksej.efimov at oracle.com  Mon Dec 15 16:06:57 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Mon, 15 Dec 2014 19:06:57 +0300
Subject: RFR: 8051641: Africa/Casablanca transitions is incorrectly calculated
	starting from 2027
Message-ID: <548F0721.7080500@oracle.com>

Hello Sherman, Masayoshi and other experts,

Can I ask for a JDK9 review for the 
sun/util/calendar/zi/TestZoneInfo310.java test failure [1] that was 
caused by incorrect handling of last rules for Africa/Casablanca time 
zone. This timzone has two last rules and three instant rules in a range 
of these last rules that causes incorrect instant transitions table 
generation. The proposed fix [2] solves this problem. Also there is a 
modification to test class that solves the issue with not optimized 
instant transitions with the same offset/saving values that are the last 
two in instant transitions table. And TestZoneInfo310.java is removed 
from problems list.

Testing:
All tz related test were executed with no failures.
JPRT build/testing successfull for all platforms.

Best Regards,
Aleksej

[1] https://bugs.openjdk.java.net/browse/JDK-8051641
[2] http://cr.openjdk.java.net/~aefimov/8051641/9/webrev.00/



From xueming.shen at oracle.com  Mon Dec 15 16:17:08 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 15 Dec 2014 08:17:08 -0800
Subject: RFR: 8051641: Africa/Casablanca transitions is incorrectly
	calculated starting from 2027
In-Reply-To: <548F0721.7080500@oracle.com>
References: <548F0721.7080500@oracle.com>
Message-ID: <548F0984.9000507@oracle.com>

On 12/15/14 8:06 AM, Aleksej Efimov wrote:
> Hello Sherman, Masayoshi and other experts,
>
> Can I ask for a JDK9 review for the 
> sun/util/calendar/zi/TestZoneInfo310.java test failure [1] that was 
> caused by incorrect handling of last rules for Africa/Casablanca time 
> zone. This timzone has two last rules and three instant rules in a 
> range of these last rules that causes incorrect instant transitions 
> table generation. The proposed fix [2] solves this problem. Also there 
> is a modification to test class that solves the issue with not 
> optimized instant transitions with the same offset/saving values that 
> are the last two in instant transitions table. And 
> TestZoneInfo310.java is removed from problems list.
>
> Testing:
> All tz related test were executed with no failures.
> JPRT build/testing successfull for all platforms.
>
> Best Regards,
> Aleksej
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8051641
> [2] http://cr.openjdk.java.net/~aefimov/8051641/9/webrev.00/
>
Hi Aleksej,

The fix itself is good. The lines in Rules.java need adjust the space 
and blank
line at #736 at provider.java need to be removed as well (my fault).

Thanks!
-Sherman


From aleksej.efimov at oracle.com  Mon Dec 15 16:22:44 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Mon, 15 Dec 2014 19:22:44 +0300
Subject: RFR: 8051641: Africa/Casablanca transitions is incorrectly
	calculated starting from 2027
In-Reply-To: <548F0984.9000507@oracle.com>
References: <548F0721.7080500@oracle.com> <548F0984.9000507@oracle.com>
Message-ID: <548F0AD4.6000100@oracle.com>

Sherman, thank you for looking into this problem and helping solve it. I 
will change the formatting before the push.

-Aleksej

On 12/15/2014 07:17 PM, Xueming Shen wrote:
> On 12/15/14 8:06 AM, Aleksej Efimov wrote:
>> Hello Sherman, Masayoshi and other experts,
>>
>> Can I ask for a JDK9 review for the 
>> sun/util/calendar/zi/TestZoneInfo310.java test failure [1] that was 
>> caused by incorrect handling of last rules for Africa/Casablanca time 
>> zone. This timzone has two last rules and three instant rules in a 
>> range of these last rules that causes incorrect instant transitions 
>> table generation. The proposed fix [2] solves this problem. Also 
>> there is a modification to test class that solves the issue with not 
>> optimized instant transitions with the same offset/saving values that 
>> are the last two in instant transitions table. And 
>> TestZoneInfo310.java is removed from problems list.
>>
>> Testing:
>> All tz related test were executed with no failures.
>> JPRT build/testing successfull for all platforms.
>>
>> Best Regards,
>> Aleksej
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8051641
>> [2] http://cr.openjdk.java.net/~aefimov/8051641/9/webrev.00/
>>
> Hi Aleksej,
>
> The fix itself is good. The lines in Rules.java need adjust the space 
> and blank
> line at #736 at provider.java need to be removed as well (my fault).
>
> Thanks!
> -Sherman



From xueming.shen at oracle.com  Mon Dec 15 16:59:47 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Mon, 15 Dec 2014 08:59:47 -0800
Subject: Copy a ZipEntry into another zip file
In-Reply-To: <1D0C24E2-14DD-43C6-B88B-7E0A378D4405@oracle.com>
References: <1D0C24E2-14DD-43C6-B88B-7E0A378D4405@oracle.com>
Message-ID: <548F1383.6000403@oracle.com>

On 12/14/14 7:43 PM, Wang Weijun wrote:
> Several questions:
>
> 1. Why cannot I just call os.putNextEntry(ze) or at least os.putNextEntry(new ZipEntry(ze))? Maybe some fields (say, compressed size) should not be copied over? If ze2 must be this way, shall I also copy the flag field?

It's the choice of jarsigner. My take on this is (1) it is a defensive 
copy. The ZOS uses the input
ze directly without making a defensive copy, so some of its fields get 
updated during writing,
for example the "flag" field. (2) The "flag" field is more a 
implementation detail of the ZOS
implementation, as well as the csize and the crc32 fields when 
deflating. It'd better to leave the
ZOS decide what to do with them instead of passing in a 'known value".
That said, you actually can just pass in a ze with all fields filled 
(without creating a new entry
and copying the fields, maybe for a better performance), in that case, 
the ZOS will verify the
size, csize and crc32 with the real bytes written out, exception will be 
thrown if the input values
and the real values don't match. It's a choice of jar


> 2. In writeBytes(), why does the getSize() return value need to be used? Shouldn't we just transfer all bytes from is to os?

In theory, yes you can just try to read all bytes from the input stream 
from the ZipeFile entry.
The stream should returns -1 when it reaches the byte numbers of 
entry.getSize(). This is
what the jar does when extracting.

-Sherman

> Thanks
> Max
>



From daniel.fuchs at oracle.com  Mon Dec 15 17:48:36 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 15 Dec 2014 18:48:36 +0100
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <5482DE1F.5070906@oracle.com>
References: <547F9302.3060309@oracle.com>	<547FD6F2.5060400@oracle.com>	<548023D0.4020702@oracle.com>	<548047C3.8000400@oracle.com>	<54804E4B.2070908@oracle.com>	<5480529F.1020902@oracle.com>
	<54805B5D.5020504@oracle.com>	<54809627.8070103@oracle.com>
	<5480EFE8.3090809@oracle.com> <5482105D.40005@oracle.com>
	<5482D77C.9030100@gmail.com> <5482DE1F.5070906@oracle.com>
Message-ID: <548F1EF4.1040007@oracle.com>

Hi guys,

Do I have approval to push the latest version of the test for JDK 9:
http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/
or are there still some objections?

best regards,

-- daniel


On 06/12/14 11:44, Daniel Fuchs wrote:
> Hi Peter,
>
>
> On 12/6/14 11:16 AM, Peter Levart wrote:
>>
>> On 12/05/2014 09:06 PM, Daniel Fuchs wrote:
>>> Hi David, all,
>>>
>>> @David: You're right David.
>>>         The loader parameter is never used - I have removed it.
>>>
>>> @all: I have received a comment from Alan that it would be better to use
>>>       the new jrt:/ FileSystem directly, rather than using private APIs.
>>>       One of the consequence is that the test now loads all the
>>>       classes in the runtime image (not just the ones in the BCL),
>>>       and therefore I have removed the toggle that allowed to test
>>>       the boot classes only.
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/
>>>
>>> best regards,
>>>
>>> -- daniel
>>
>> Hi Daniel,
>>
>> Would it be possible to extract a minimal API for streaming over
>> classes and put that into the testlib so that only this part differs
>> between JDK8 and JDK9 and the guts of the test is identical for both
>> JDK8 and JDK9 ?
>>
>> This would ease backport efforts when the test(s) are later "beefed
>> up" with other functionality. The API could later be extended with
>> other functionality, but just for illustration what might be needed,
>> here's what Martin Buchholz started as a test for finding possible
>> data races in reflection and I just re-packed using Streams. From
>> first glance it seems the tests need similar common functionality:
>>
>> http://cr.openjdk.java.net/~plevart/misc/SunReflectDataRaces/
>>
>> Regards, Peter
>
> The test is already built like that:
>
> The part that finds the class names is encapsulated in an object which
> implements Iterable<String>.
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ ->
> ClassNameJrtStreamBuilder
> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8-00/ ->
> ClassNameStreamBuilder
> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00/ ->
> ClassNameListBuilder
>
> The bulk of the test should be identical (well, almost identical since I
> only
> updated 9 after the reviews, and since 9 is the only one that needs the
> System ClassLoader)... I suppose we could extract these 3 classes and define
> a library class with something like:
>
> public static class ClassNameFinder {
>       public static Iterable<String> findAllClassNames() {
> jdk9 impl:            return new ClassNameJrtStreamBuilder();
> jdk8 impl:            return new ClassNameStreamBuilder();
> jdk7 impl:            return new ClassNameListBuilder();
>       }
> }
>
> As it stands - this corresponds to the
>
>   static Iterable<String> listAllClassNames()
>
> factory method  in each version of the test.
>
>
> best regards,
>
> -- daniel
>
>>
>>>
>>> On 05/12/14 00:36, David Holmes wrote:
>>>> Hi Daniel,
>>>>
>>>> I still find your use of the classloader very confusing. You talk about
>>>> the defining loader but you never check the defining loader against
>>>> anything. In
>>>>
>>>>   146         static void checkFor(Class<?> c, ClassLoader loader) {
>>>>
>>>> the loader variable is never used. And if loader is simply the name of
>>>> the loader passed to forName, then it may not be the defining loader
>>>> anyway - so the whole use of this loader variable seems superfluous at
>>>> best, and confusing/misleading at worst. And you can use the simple
>>>> forName(name) variant rather than passing a loader.
>>>>
>>>> David
>>>>
>>>> On 5/12/2014 3:13 AM, Daniel Fuchs wrote:
>>>>> On 04/12/14 14:02, Se?n Coffey wrote:
>>>>>> Thanks for driving efforts in this area Daniel. I think it's a very
>>>>>> useful test and is bound to help test code coverage. If it's
>>>>>> currently
>>>>>> passing on all JPRT platforms, it's a good measure.
>>>>>
>>>>> It seems to :-)
>>>>>
>>>>>> Eventually I think we can bulk up the tests that can be run on the
>>>>>> Iterable returned from your class search.
>>>>>> At moment you just test Field.setAccessible.
>>>>>
>>>>> Yes. If we change it later to test more, we will probably need to
>>>>> change its name. I was already in lack of inspiration:
>>>>> FieldSetAccessibleTest is not really a great name - but hopefully
>>>>> it can do for now.
>>>>>
>>>>>> In the future, I don't see any harm in adding all simple Field method
>>>>>> calls so that any corner cases in custom classes like the original
>>>>>> issue
>>>>>> are caught. e.g Field.getDeclaredAnnotations(), Field.getModifiers(),
>>>>>> Field.isEnumConstant() etc., etc. Some methods won't be much value
>>>>>> add
>>>>>> but they're not a cost either.
>>>>>
>>>>> Agreed.
>>>>>
>>>>>> Same argument for running through all Class methods, e.g
>>>>>> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a
>>>>>> result this
>>>>>> test might eventually become more general in test goal and might live
>>>>>> better one level up in "test/java/lang/Class/" - it can be moved when
>>>>>> the time comes.
>>>>>
>>>>> Agreed as well :-)
>>>>>
>>>>> Here is a new revision of the webrev for 9 in which I have
>>>>> incorporated David's comment:
>>>>>
>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>>
>>>>>>
>>>>>> regards,
>>>>>> Sean.
>>>>>>
>>>>>> On 04/12/2014 12:25, Daniel Fuchs wrote:
>>>>>>> On 04/12/14 13:06, David Holmes wrote:
>>>>>>>> Hi Daniel,
>>>>>>>>
>>>>>>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> In fact I could use 'null' on JDK 9 as well.
>>>>>>>>> My first version of the JDK 9 test was parsing over all the
>>>>>>>>> .jimage
>>>>>>>>> files under <jdk>/lib/modules - which explain why I needed to
>>>>>>>>> use the System class loader.
>>>>>>>>>
>>>>>>>>> Then I switched to only parsing the bootmodules.jimage - because
>>>>>>>>> I noticed that the results where more coherent with what I had
>>>>>>>>> observed on 8 & 7 - but I kept using the System class loader.
>>>>>>>>>
>>>>>>>>> I am not sure whether we want the test for 9 should iterate over
>>>>>>>>> the three .jimage - or continue to test only the boot .jimage.
>>>>>>>>>
>>>>>>>>> I have updated the JDK 9 test (refreshed the webrev in place)
>>>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/
>>>>>>>>> and added support for possibly running the test in the two modes
>>>>>>>>> (I added a 'test.boot.only' system property, true by default)
>>>>>>>>> as well as additional traces to print the loaded classes by
>>>>>>>>> defining loader at the end (test.list.classes, false by default).
>>>>>>>>
>>>>>>>> A couple of initial comments:
>>>>>>>>
>>>>>>>>   104     static ClassLoader getClassLoaderFor(String
>>>>>>>> classFileName) {
>>>>>>>>   105         if (restrictToBoot) return null; // only bootmodules
>>>>>>>>   106         return ClassLoaders.systemClassLoader;
>>>>>>>>   107     }
>>>>>>>>
>>>>>>>> I'm not clear the intent here. If it is to return a loader for
>>>>>>>> which
>>>>>>>> loadClass could be invoked then you can always just return the
>>>>>>>> system
>>>>>>>> loader - or just Class.forName. If it is meant to the return the
>>>>>>>> expected defining loader then it isn't doing that as the extensions
>>>>>>>> loader is not allowed for.
>>>>>>>
>>>>>>> The intent is to return the class loader that will be passed to
>>>>>>> Class.forName( ). I've been fiddling & experimenting with this
>>>>>>> test over 3 different platforms while trying to minimize the
>>>>>>> differences - so that was my attempt at having a good place to
>>>>>>> experiment with different strategy for loading classes.
>>>>>>>
>>>>>>>> Similarly for:
>>>>>>>>
>>>>>>>>   128         static ClassLoader getFor(String classFileName) {
>>>>>>>>   129             return systemClassLoader;
>>>>>>>>   130         }
>>>>>>>
>>>>>>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..)
>>>>>>> was supposed to simply return ClassLoaders.getFor(...);
>>>>>>> and all the code should be in ClassLoaders.getFor - my bad.
>>>>>>>
>>>>>>>> Minor nit - In:
>>>>>>>>
>>>>>>>> 135                     System.err.println("Unexpected loader for
>>>>>>>> "+c+":
>>>>>>>> "+c.getClassLoader());
>>>>>>>>
>>>>>>>> c.getClassLoader() can be replaced by cl. Also put spaces around
>>>>>>>> the +
>>>>>>>> operator.
>>>>>>>
>>>>>>> Good catch.
>>>>>>>
>>>>>>> Thanks a lot David! Have a good night! (that's quite late - isn't
>>>>>>> it?)
>>>>>>>
>>>>>>> -- daniel
>>>>>>>
>>>>>>>>
>>>>>>>> David
>>>>>>>> (signing off for the night)
>>>>>>>>
>>>>>>>>> Thanks for your question, it triggered me into looking deeper
>>>>>>>>> into what was happening :-)
>>>>>>>>>
>>>>>>>>> best regards,
>>>>>>>>>
>>>>>>>>> -- daniel
>>>>>>>>>
>>>>>>>>> On 04/12/14 10:05, Daniel Fuchs wrote:
>>>>>>>>>>>> The differences between 8 & 9 are limited to:
>>>>>>>>>>>>
>>>>>>>>>>>>     - ClassLoader:
>>>>>>>>>>>>          - on 8 we use 'null' (BCL)
>>>>>>>>>>>>          - on 9 we use the system class loader.
>>>>>>>>>>>
>>>>>>>>>>> I haven't seen anything in JEP 220, regarding modules, that
>>>>>>>>>>> indicates
>>>>>>>>>>> that classes currently loaded  by the boot-loader will now be
>>>>>>>>>>> loaded
>>>>>>>>>>> by the system classloader ???
>>>>>>>>>>
>>>>>>>>>> In [1] towards the end:
>>>>>>>>>>
>>>>>>>>>> [1] http://openjdk.java.net/jeps/220
>>>>>>>>>>
>>>>>>>>>> "The defining class loader of the types in some existing packages
>>>>>>>>>>   will change. Existing code that makes assumptions about the
>>>>>>>>>> class
>>>>>>>>>>   loaders of these types might not work correctly."
>>>>>>>>>>   (then there is a list of specific changes).
>>>>>>>>>>
>>>>>>>>>> This test looks up all class names in the image files and attempt
>>>>>>>>>> to load the corresponding class. But as indicated in [1]
>>>>>>>>>> some of these classes are now in the Boot CL, some in the
>>>>>>>>>> Extension CL, and some in the Application CL.
>>>>>>>>>>
>>>>>>>>>> So the test uses the System CL to load each class - which ensures
>>>>>>>>>> that the loading will be delegated to the appropriate
>>>>>>>>>> ClassLoader.
>>>>>>>>>>
>>>>>>>>>> best regards,
>>>>>>>>>>
>>>>>>>>>> -- daniel
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>>
>



From mandy.chung at oracle.com  Mon Dec 15 18:38:44 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 15 Dec 2014 10:38:44 -0800
Subject: Review request: JDK-8067360: verify-modules target was dropped
	in jdk9 b41
In-Reply-To: <548EA22B.309@oracle.com>
References: <548B3330.3050104@oracle.com> <548EA22B.309@oracle.com>
Message-ID: <548F2AB4.10507@oracle.com>

Thanks for the review.  I don't mind filing a bug for javadoc change and 
it's easy as it's a separate issue and cleaner to separate them.   I'm 
happy this saves me the hassle of a separate review, thanks!

Mandy

On 12/15/14 12:56 AM, Erik Joelsson wrote:
> Looks good to me. I don't mind if you fix javadoc in the same change. 
> It's such a small issue I rather not go through the hassle of creating 
> a bug and a new review.
>
> Thanks!
> /Erik
>
> On 2014-12-12 19:25, Mandy Chung wrote:
>> Webrev:
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8067360/webrev.00/
>>
>> This patch adds back the verify-modules target to the dependences of 
>> the images target that got dropped in the merge and hides a bug in 
>> jdeps -Xverify:access.
>>
>> Erik - I notice make/Javadoc.gmk that sets -bootclasspath 
>> $(JDK_OUTPUTDIR)/classes that does not exist.  I include a patch to 
>> make/Javadoc.gmk in the webrev.  Do you prefer to separate it and 
>> file a new bug for it?
>>
>> Mandy
>>
>>
>



From sean.coffey at oracle.com  Mon Dec 15 19:31:22 2014
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Mon, 15 Dec 2014 19:31:22 +0000
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <548F1EF4.1040007@oracle.com>
References: <547F9302.3060309@oracle.com>	<547FD6F2.5060400@oracle.com>	<548023D0.4020702@oracle.com>	<548047C3.8000400@oracle.com>	<54804E4B.2070908@oracle.com>	<5480529F.1020902@oracle.com>
	<54805B5D.5020504@oracle.com>	<54809627.8070103@oracle.com>
	<5480EFE8.3090809@oracle.com> <5482105D.40005@oracle.com>
	<5482D77C.9030100@gmail.com> <5482DE1F.5070906@oracle.com>
	<548F1EF4.1040007@oracle.com>
Message-ID: <548F370A.8040609@oracle.com>


On 15/12/2014 17:48, Daniel Fuchs wrote:
> Hi guys,
>
> Do I have approval to push the latest version of the test for JDK 9:
> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/
> or are there still some objections?
I'm fine with the test Daniel (as before) - it's a long-life test that 
can be tweaked and improved upon each iteration.

regards,
Sean.
>
> best regards,
>
> -- daniel
>
>
> On 06/12/14 11:44, Daniel Fuchs wrote:
>> Hi Peter,
>>
>>
>> On 12/6/14 11:16 AM, Peter Levart wrote:
>>>
>>> On 12/05/2014 09:06 PM, Daniel Fuchs wrote:
>>>> Hi David, all,
>>>>
>>>> @David: You're right David.
>>>>         The loader parameter is never used - I have removed it.
>>>>
>>>> @all: I have received a comment from Alan that it would be better 
>>>> to use
>>>>       the new jrt:/ FileSystem directly, rather than using private 
>>>> APIs.
>>>>       One of the consequence is that the test now loads all the
>>>>       classes in the runtime image (not just the ones in the BCL),
>>>>       and therefore I have removed the toggle that allowed to test
>>>>       the boot classes only.
>>>>
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>
>>> Hi Daniel,
>>>
>>> Would it be possible to extract a minimal API for streaming over
>>> classes and put that into the testlib so that only this part differs
>>> between JDK8 and JDK9 and the guts of the test is identical for both
>>> JDK8 and JDK9 ?
>>>
>>> This would ease backport efforts when the test(s) are later "beefed
>>> up" with other functionality. The API could later be extended with
>>> other functionality, but just for illustration what might be needed,
>>> here's what Martin Buchholz started as a test for finding possible
>>> data races in reflection and I just re-packed using Streams. From
>>> first glance it seems the tests need similar common functionality:
>>>
>>> http://cr.openjdk.java.net/~plevart/misc/SunReflectDataRaces/
>>>
>>> Regards, Peter
>>
>> The test is already built like that:
>>
>> The part that finds the class names is encapsulated in an object which
>> implements Iterable<String>.
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ ->
>> ClassNameJrtStreamBuilder
>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8-00/ ->
>> ClassNameStreamBuilder
>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00/ ->
>> ClassNameListBuilder
>>
>> The bulk of the test should be identical (well, almost identical since I
>> only
>> updated 9 after the reviews, and since 9 is the only one that needs the
>> System ClassLoader)... I suppose we could extract these 3 classes and 
>> define
>> a library class with something like:
>>
>> public static class ClassNameFinder {
>>       public static Iterable<String> findAllClassNames() {
>> jdk9 impl:            return new ClassNameJrtStreamBuilder();
>> jdk8 impl:            return new ClassNameStreamBuilder();
>> jdk7 impl:            return new ClassNameListBuilder();
>>       }
>> }
>>
>> As it stands - this corresponds to the
>>
>>   static Iterable<String> listAllClassNames()
>>
>> factory method  in each version of the test.
>>
>>
>> best regards,
>>
>> -- daniel
>>
>>>
>>>>
>>>> On 05/12/14 00:36, David Holmes wrote:
>>>>> Hi Daniel,
>>>>>
>>>>> I still find your use of the classloader very confusing. You talk 
>>>>> about
>>>>> the defining loader but you never check the defining loader against
>>>>> anything. In
>>>>>
>>>>>   146         static void checkFor(Class<?> c, ClassLoader loader) {
>>>>>
>>>>> the loader variable is never used. And if loader is simply the 
>>>>> name of
>>>>> the loader passed to forName, then it may not be the defining loader
>>>>> anyway - so the whole use of this loader variable seems 
>>>>> superfluous at
>>>>> best, and confusing/misleading at worst. And you can use the simple
>>>>> forName(name) variant rather than passing a loader.
>>>>>
>>>>> David
>>>>>
>>>>> On 5/12/2014 3:13 AM, Daniel Fuchs wrote:
>>>>>> On 04/12/14 14:02, Se?n Coffey wrote:
>>>>>>> Thanks for driving efforts in this area Daniel. I think it's a very
>>>>>>> useful test and is bound to help test code coverage. If it's
>>>>>>> currently
>>>>>>> passing on all JPRT platforms, it's a good measure.
>>>>>>
>>>>>> It seems to :-)
>>>>>>
>>>>>>> Eventually I think we can bulk up the tests that can be run on the
>>>>>>> Iterable returned from your class search.
>>>>>>> At moment you just test Field.setAccessible.
>>>>>>
>>>>>> Yes. If we change it later to test more, we will probably need to
>>>>>> change its name. I was already in lack of inspiration:
>>>>>> FieldSetAccessibleTest is not really a great name - but hopefully
>>>>>> it can do for now.
>>>>>>
>>>>>>> In the future, I don't see any harm in adding all simple Field 
>>>>>>> method
>>>>>>> calls so that any corner cases in custom classes like the original
>>>>>>> issue
>>>>>>> are caught. e.g Field.getDeclaredAnnotations(), 
>>>>>>> Field.getModifiers(),
>>>>>>> Field.isEnumConstant() etc., etc. Some methods won't be much value
>>>>>>> add
>>>>>>> but they're not a cost either.
>>>>>>
>>>>>> Agreed.
>>>>>>
>>>>>>> Same argument for running through all Class methods, e.g
>>>>>>> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a
>>>>>>> result this
>>>>>>> test might eventually become more general in test goal and might 
>>>>>>> live
>>>>>>> better one level up in "test/java/lang/Class/" - it can be moved 
>>>>>>> when
>>>>>>> the time comes.
>>>>>>
>>>>>> Agreed as well :-)
>>>>>>
>>>>>> Here is a new revision of the webrev for 9 in which I have
>>>>>> incorporated David's comment:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/
>>>>>>
>>>>>> best regards,
>>>>>>
>>>>>> -- daniel
>>>>>>
>>>>>>>
>>>>>>> regards,
>>>>>>> Sean.
>>>>>>>
>>>>>>> On 04/12/2014 12:25, Daniel Fuchs wrote:
>>>>>>>> On 04/12/14 13:06, David Holmes wrote:
>>>>>>>>> Hi Daniel,
>>>>>>>>>
>>>>>>>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> In fact I could use 'null' on JDK 9 as well.
>>>>>>>>>> My first version of the JDK 9 test was parsing over all the
>>>>>>>>>> .jimage
>>>>>>>>>> files under <jdk>/lib/modules - which explain why I needed to
>>>>>>>>>> use the System class loader.
>>>>>>>>>>
>>>>>>>>>> Then I switched to only parsing the bootmodules.jimage - because
>>>>>>>>>> I noticed that the results where more coherent with what I had
>>>>>>>>>> observed on 8 & 7 - but I kept using the System class loader.
>>>>>>>>>>
>>>>>>>>>> I am not sure whether we want the test for 9 should iterate over
>>>>>>>>>> the three .jimage - or continue to test only the boot .jimage.
>>>>>>>>>>
>>>>>>>>>> I have updated the JDK 9 test (refreshed the webrev in place)
>>>>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ 
>>>>>>>>>>
>>>>>>>>>> and added support for possibly running the test in the two modes
>>>>>>>>>> (I added a 'test.boot.only' system property, true by default)
>>>>>>>>>> as well as additional traces to print the loaded classes by
>>>>>>>>>> defining loader at the end (test.list.classes, false by 
>>>>>>>>>> default).
>>>>>>>>>
>>>>>>>>> A couple of initial comments:
>>>>>>>>>
>>>>>>>>>   104     static ClassLoader getClassLoaderFor(String
>>>>>>>>> classFileName) {
>>>>>>>>>   105         if (restrictToBoot) return null; // only 
>>>>>>>>> bootmodules
>>>>>>>>>   106         return ClassLoaders.systemClassLoader;
>>>>>>>>>   107     }
>>>>>>>>>
>>>>>>>>> I'm not clear the intent here. If it is to return a loader for
>>>>>>>>> which
>>>>>>>>> loadClass could be invoked then you can always just return the
>>>>>>>>> system
>>>>>>>>> loader - or just Class.forName. If it is meant to the return the
>>>>>>>>> expected defining loader then it isn't doing that as the 
>>>>>>>>> extensions
>>>>>>>>> loader is not allowed for.
>>>>>>>>
>>>>>>>> The intent is to return the class loader that will be passed to
>>>>>>>> Class.forName( ). I've been fiddling & experimenting with this
>>>>>>>> test over 3 different platforms while trying to minimize the
>>>>>>>> differences - so that was my attempt at having a good place to
>>>>>>>> experiment with different strategy for loading classes.
>>>>>>>>
>>>>>>>>> Similarly for:
>>>>>>>>>
>>>>>>>>>   128         static ClassLoader getFor(String classFileName) {
>>>>>>>>>   129             return systemClassLoader;
>>>>>>>>>   130         }
>>>>>>>>
>>>>>>>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..)
>>>>>>>> was supposed to simply return ClassLoaders.getFor(...);
>>>>>>>> and all the code should be in ClassLoaders.getFor - my bad.
>>>>>>>>
>>>>>>>>> Minor nit - In:
>>>>>>>>>
>>>>>>>>> 135 System.err.println("Unexpected loader for
>>>>>>>>> "+c+":
>>>>>>>>> "+c.getClassLoader());
>>>>>>>>>
>>>>>>>>> c.getClassLoader() can be replaced by cl. Also put spaces around
>>>>>>>>> the +
>>>>>>>>> operator.
>>>>>>>>
>>>>>>>> Good catch.
>>>>>>>>
>>>>>>>> Thanks a lot David! Have a good night! (that's quite late - isn't
>>>>>>>> it?)
>>>>>>>>
>>>>>>>> -- daniel
>>>>>>>>
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>> (signing off for the night)
>>>>>>>>>
>>>>>>>>>> Thanks for your question, it triggered me into looking deeper
>>>>>>>>>> into what was happening :-)
>>>>>>>>>>
>>>>>>>>>> best regards,
>>>>>>>>>>
>>>>>>>>>> -- daniel
>>>>>>>>>>
>>>>>>>>>> On 04/12/14 10:05, Daniel Fuchs wrote:
>>>>>>>>>>>>> The differences between 8 & 9 are limited to:
>>>>>>>>>>>>>
>>>>>>>>>>>>>     - ClassLoader:
>>>>>>>>>>>>>          - on 8 we use 'null' (BCL)
>>>>>>>>>>>>>          - on 9 we use the system class loader.
>>>>>>>>>>>>
>>>>>>>>>>>> I haven't seen anything in JEP 220, regarding modules, that
>>>>>>>>>>>> indicates
>>>>>>>>>>>> that classes currently loaded  by the boot-loader will now be
>>>>>>>>>>>> loaded
>>>>>>>>>>>> by the system classloader ???
>>>>>>>>>>>
>>>>>>>>>>> In [1] towards the end:
>>>>>>>>>>>
>>>>>>>>>>> [1] http://openjdk.java.net/jeps/220
>>>>>>>>>>>
>>>>>>>>>>> "The defining class loader of the types in some existing 
>>>>>>>>>>> packages
>>>>>>>>>>>   will change. Existing code that makes assumptions about the
>>>>>>>>>>> class
>>>>>>>>>>>   loaders of these types might not work correctly."
>>>>>>>>>>>   (then there is a list of specific changes).
>>>>>>>>>>>
>>>>>>>>>>> This test looks up all class names in the image files and 
>>>>>>>>>>> attempt
>>>>>>>>>>> to load the corresponding class. But as indicated in [1]
>>>>>>>>>>> some of these classes are now in the Boot CL, some in the
>>>>>>>>>>> Extension CL, and some in the Application CL.
>>>>>>>>>>>
>>>>>>>>>>> So the test uses the System CL to load each class - which 
>>>>>>>>>>> ensures
>>>>>>>>>>> that the loading will be delegated to the appropriate
>>>>>>>>>>> ClassLoader.
>>>>>>>>>>>
>>>>>>>>>>> best regards,
>>>>>>>>>>>
>>>>>>>>>>> -- daniel
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>



From patrick at reini.net  Mon Dec 15 21:39:13 2014
From: patrick at reini.net (Patrick Reinhart)
Date: Mon, 15 Dec 2014 22:39:13 +0100
Subject: RFR JDK-8066867: Add InputStream transferTo to transfer content
	to an OutputStream
In-Reply-To: <F1194DB1-429D-4DD2-B9F0-638D3FDCCCFC@oracle.com>
References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com>
	<ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>
	<54871F21.10309@oracle.com>
	<F1194DB1-429D-4DD2-B9F0-638D3FDCCCFC@oracle.com>
Message-ID: <1C8225A1-E4E6-4C40-9F0D-75EF5A181CD0@reini.net>


Have there been any further review being done jet?

> Good catch, guys!
> 
>> ...the method names are inconsistent (the methods in lower case with embedded underscores)
> 
> Fixed. Updated webrev: http://cr.openjdk.java.net/~prappo/8066867/webrev.01/

-Patrick

From roger.riggs at oracle.com  Mon Dec 15 21:54:04 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Mon, 15 Dec 2014 16:54:04 -0500
Subject: RFR 9: 8044841 java/lang/Runtime/exec/SleepyCat.java Exception: Read
	from closed pipe hangs
In-Reply-To: <548B2269.5060907@oracle.com>
References: <548B2269.5060907@oracle.com>
Message-ID: <548F587C.6070305@oracle.com>

Ping...

On 12/12/2014 12:14 PM, roger riggs wrote:
> Please review this addition of diagnostic output to an intermittently 
> failing Runtime.exec test.
>
> The Solaris implementation of ProcessBuilder.start uses posix_spawn 
> and a trampoline
> technique that invokes a small spawnhelper executable which in turn 
> forks the new executable.
> The test has been intermittently failing on Solaris and is not 
> reproducible.
> The diagnostic output is only triggered if the test is failing and is 
> conditional
> since the programs are only available on Solaris.
>
> Other suggestions for diagnostics or the solution are welcome.
>
> [The test fix will be pushed using a different bug number since it 
> does not attempt to fix the issue.]
>
> Webrev:
>    http://cr.openjdk.java.net/~rriggs/webrev-sleepycat-8044841/
>
> Thanks, Roger
>
>
>



From lance.andersen at oracle.com  Mon Dec 15 21:56:45 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 15 Dec 2014 16:56:45 -0500
Subject: RFR 9: 8044841 java/lang/Runtime/exec/SleepyCat.java Exception:
	Read from closed pipe hangs
In-Reply-To: <548F587C.6070305@oracle.com>
References: <548B2269.5060907@oracle.com> <548F587C.6070305@oracle.com>
Message-ID: <0CE1C24C-6236-4B62-AA01-17EA577153FC@oracle.com>

Hi Roger,

I had looked at it last week and seems fine to help get more info and did not have another bright solution off the top of my head

Best
Lance
On Dec 15, 2014, at 4:54 PM, roger riggs <roger.riggs at oracle.com> wrote:

> Ping...
> 
> On 12/12/2014 12:14 PM, roger riggs wrote:
>> Please review this addition of diagnostic output to an intermittently failing Runtime.exec test.
>> 
>> The Solaris implementation of ProcessBuilder.start uses posix_spawn and a trampoline
>> technique that invokes a small spawnhelper executable which in turn forks the new executable.
>> The test has been intermittently failing on Solaris and is not reproducible.
>> The diagnostic output is only triggered if the test is failing and is conditional
>> since the programs are only available on Solaris.
>> 
>> Other suggestions for diagnostics or the solution are welcome.
>> 
>> [The test fix will be pushed using a different bug number since it does not attempt to fix the issue.]
>> 
>> Webrev:
>>   http://cr.openjdk.java.net/~rriggs/webrev-sleepycat-8044841/
>> 
>> Thanks, Roger
>> 
>> 
>> 
> 



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





From roger.riggs at oracle.com  Mon Dec 15 21:58:13 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Mon, 15 Dec 2014 16:58:13 -0500
Subject: RFR 9: 8044841 java/lang/Runtime/exec/SleepyCat.java Exception:
	Read from closed pipe hangs
In-Reply-To: <0CE1C24C-6236-4B62-AA01-17EA577153FC@oracle.com>
References: <548B2269.5060907@oracle.com> <548F587C.6070305@oracle.com>
	<0CE1C24C-6236-4B62-AA01-17EA577153FC@oracle.com>
Message-ID: <548F5975.2070308@oracle.com>

Thanks Lance

On 12/15/2014 4:56 PM, Lance Andersen wrote:
> Hi Roger,
>
> I had looked at it last week and seems fine to help get more info and 
> did not have another bright solution off the top of my head
>
> Best
> Lance
> On Dec 15, 2014, at 4:54 PM, roger riggs <roger.riggs at oracle.com 
> <mailto:roger.riggs at oracle.com>> wrote:
>
>> Ping...
>>
>> On 12/12/2014 12:14 PM, roger riggs wrote:
>>> Please review this addition of diagnostic output to an 
>>> intermittently failing Runtime.exec test.
>>>
>>> The Solaris implementation of ProcessBuilder.start uses posix_spawn 
>>> and a trampoline
>>> technique that invokes a small spawnhelper executable which in turn 
>>> forks the new executable.
>>> The test has been intermittently failing on Solaris and is not 
>>> reproducible.
>>> The diagnostic output is only triggered if the test is failing and 
>>> is conditional
>>> since the programs are only available on Solaris.
>>>
>>> Other suggestions for diagnostics or the solution are welcome.
>>>
>>> [The test fix will be pushed using a different bug number since it 
>>> does not attempt to fix the issue.]
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-sleepycat-8044841/ 
>>> <http://cr.openjdk.java.net/%7Erriggs/webrev-sleepycat-8044841/>
>>>
>>> Thanks, Roger
>>>
>>>
>>>
>>
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>



From kumar.x.srinivasan at oracle.com  Mon Dec 15 21:56:49 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 15 Dec 2014 13:56:49 -0800
Subject: RFR: -8067421: java -help contains information about "-version:",
	'-jre-restrict-search', '-no-jre-restrict-search'.....
Message-ID: <548F5921.8070809@oracle.com>

Hello ,

Please review webrev to fix the following minor issues:
1. JDK-8067421:  java -help contains information about 
"-version:",'-jre-restrict-search', '-no-jre-restrict-search', but they 
are removed
2. JDK-8067411:  tools/launcher/MultipleJRE.sh requires adjustments to 
work with module boundaries
3. JDK-8067290: missing bugid in test

http://cr.openjdk.java.net/~ksrini/8067421/webrev.0/

Thanks
Kumar




From roger.riggs at oracle.com  Mon Dec 15 22:31:33 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Mon, 15 Dec 2014 17:31:33 -0500
Subject: Java implementation of Alpha-numeric comparator
In-Reply-To: <548EBD94.1070804@oracle.com>
References: <548EBD94.1070804@oracle.com>
Message-ID: <548F6145.1060207@oracle.com>

Hi Ivan,

It does seem like a useful function, though I would have started with 
the API,
not the implementation.

Can it apply to CharSequence not only String and maybe skip the
separate char[] version, a char[] array can be wrapped to become a 
CharSequence via CharBuffer.
Or a via a new static method to define a CharSequence from a char array.

$.02, Roger

On 12/15/2014 5:53 AM, Ivan Gerasimov wrote:
> Hello everyone!
>
> In certain situations the preferred way of sorting strings is a 
> combination of char-comparing sorting with numeric sorting, where 
> applicable.
> List of strings sorted this way often look more natural to the human 
> eyes:
> { "alpha",
>   "java1",
>   "java2",
>   "java10",
>   "zero" }
>
> Here's presented a sample implementation of the comparator, which 
> supports this way of sorting.
> I placed it under src/sample directory.
>
> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/0/webrev/
>
>
> MSDN provides the function StrCmpLogicalW(), which can be used for 
> similar sort order.
> http://msdn.microsoft.com/en-us/library/windows/desktop/bb759947%28v=vs.85%29.aspx 
>
>
> The differences are:
>  - case-sensitivity (StrCmpLogicalW is case-insensitive);
>  - treating leading zeroes;
>  - more accurate handling of strings with big numbers, which cannot be 
> converted to int/long.
>
> I guess this comparator may become particularly useful when we'll have 
> 'java10' and update releases/build numbers > 99 in the lists :)
>
> I want to ask the community about how useful this comparator may be to 
> you?
>
> Sincerely yours,
> Ivan
>



From naoto.sato at oracle.com  Mon Dec 15 23:24:24 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 15 Dec 2014 15:24:24 -0800
Subject: Java implementation of Alpha-numeric comparator
In-Reply-To: <548F6145.1060207@oracle.com>
References: <548EBD94.1070804@oracle.com> <548F6145.1060207@oracle.com>
Message-ID: <548F6DA8.8060707@oracle.com>

Hello,

It seems useful to me too, but it should also take digits other than '0' 
to '9' into account, for example, ??????????.

Naoto

On 12/15/14, 2:31 PM, roger riggs wrote:
> Hi Ivan,
>
> It does seem like a useful function, though I would have started with
> the API,
> not the implementation.
>
> Can it apply to CharSequence not only String and maybe skip the
> separate char[] version, a char[] array can be wrapped to become a
> CharSequence via CharBuffer.
> Or a via a new static method to define a CharSequence from a char array.
>
> $.02, Roger
>
> On 12/15/2014 5:53 AM, Ivan Gerasimov wrote:
>> Hello everyone!
>>
>> In certain situations the preferred way of sorting strings is a
>> combination of char-comparing sorting with numeric sorting, where
>> applicable.
>> List of strings sorted this way often look more natural to the human
>> eyes:
>> { "alpha",
>>   "java1",
>>   "java2",
>>   "java10",
>>   "zero" }
>>
>> Here's presented a sample implementation of the comparator, which
>> supports this way of sorting.
>> I placed it under src/sample directory.
>>
>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/0/webrev/
>>
>>
>> MSDN provides the function StrCmpLogicalW(), which can be used for
>> similar sort order.
>> http://msdn.microsoft.com/en-us/library/windows/desktop/bb759947%28v=vs.85%29.aspx
>>
>>
>> The differences are:
>>  - case-sensitivity (StrCmpLogicalW is case-insensitive);
>>  - treating leading zeroes;
>>  - more accurate handling of strings with big numbers, which cannot be
>> converted to int/long.
>>
>> I guess this comparator may become particularly useful when we'll have
>> 'java10' and update releases/build numbers > 99 in the lists :)
>>
>> I want to ask the community about how useful this comparator may be to
>> you?
>>
>> Sincerely yours,
>> Ivan
>>
>


From forax at univ-mlv.fr  Mon Dec 15 23:39:12 2014
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 16 Dec 2014 00:39:12 +0100
Subject: Java implementation of Alpha-numeric comparator
In-Reply-To: <548F6145.1060207@oracle.com>
References: <548EBD94.1070804@oracle.com> <548F6145.1060207@oracle.com>
Message-ID: <548F7120.9040400@univ-mlv.fr>

Hi Ivan, hi Roger,

Roger, the API already exists it's the interface Comparator.

I agree with Roger that a comparator that use a CharSequence is better 
that the one that use a char array.

The thing that worry me is the Comparator<Character> taken as parameter, 
it means that
each time the method compare() is called on this comparator, the two 
arguments are boxed.

Minor comment, to be included, I think that these comparators should be 
serializable
and in my opinion the best way to do that is to use a lambda instead of 
a class.

R?mi

On 12/15/2014 11:31 PM, roger riggs wrote:
> Hi Ivan,
>
> It does seem like a useful function, though I would have started with 
> the API,
> not the implementation.
>
> Can it apply to CharSequence not only String and maybe skip the
> separate char[] version, a char[] array can be wrapped to become a 
> CharSequence via CharBuffer.
> Or a via a new static method to define a CharSequence from a char array.
>
> $.02, Roger
>
> On 12/15/2014 5:53 AM, Ivan Gerasimov wrote:
>> Hello everyone!
>>
>> In certain situations the preferred way of sorting strings is a 
>> combination of char-comparing sorting with numeric sorting, where 
>> applicable.
>> List of strings sorted this way often look more natural to the human 
>> eyes:
>> { "alpha",
>>   "java1",
>>   "java2",
>>   "java10",
>>   "zero" }
>>
>> Here's presented a sample implementation of the comparator, which 
>> supports this way of sorting.
>> I placed it under src/sample directory.
>>
>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/0/webrev/
>>
>>
>> MSDN provides the function StrCmpLogicalW(), which can be used for 
>> similar sort order.
>> http://msdn.microsoft.com/en-us/library/windows/desktop/bb759947%28v=vs.85%29.aspx 
>>
>>
>> The differences are:
>>  - case-sensitivity (StrCmpLogicalW is case-insensitive);
>>  - treating leading zeroes;
>>  - more accurate handling of strings with big numbers, which cannot 
>> be converted to int/long.
>>
>> I guess this comparator may become particularly useful when we'll 
>> have 'java10' and update releases/build numbers > 99 in the lists :)
>>
>> I want to ask the community about how useful this comparator may be 
>> to you?
>>
>> Sincerely yours,
>> Ivan
>>
>



From stuart.marks at oracle.com  Tue Dec 16 00:19:23 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 15 Dec 2014 16:19:23 -0800
Subject: RFR JDK-8066642: Fix deprecation warnings in jdk.naming module
In-Reply-To: <548B0FB5.7020900@oracle.com>
References: <588275F7-18D3-43E7-A55D-120D38D4AEFA@oracle.com>
	<548B0FB5.7020900@oracle.com>
Message-ID: <548F7A8B.4020304@oracle.com>



On 12/12/14 7:54 AM, Chris Hegarty wrote:
> On 12/12/14 15:40, Pavel Rappo wrote:
>> Could you please review my change for JDK-8066642?
>>
>> http://cr.openjdk.java.net/~prappo/8066642/webrev.00/
>
> The first change, to remove SocketSecurityException seems benign.
> SocketSecurityException is a subclass of ExportException, so
> CommunicationException will continue to be thrown.
>
> The second change, to replace RMISecurityManager with SecurityManager, will
> provide equivalent behavior, RMISecurityManager extends SecurityManager but does
> not add any state or behavior, but the runtime type of the security will be
> changed.
>
> I've taken a quick look through the JDK source and cannot find any places where
> the type of the security manager is checked to see if it is an instance of
> RMISecurityManager. I also quickly looked in GrepCode, and could not find any
> either. Given this, I think the change should be ok.

Regarding RMISecurityManager, yes, there should be no problem replacing it with 
an ordinary SecurityManager. There should be no functional difference introduced 
by doing so. If anyone runs across code or behavior that differs between 
SecurityManager and RMISecurityManager, please let me know; it is most likely an 
error!

s'marks



From joe.darcy at oracle.com  Tue Dec 16 01:28:43 2014
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 15 Dec 2014 17:28:43 -0800
Subject: RFR: -8067421: java -help contains information about "-version:",
	'-jre-restrict-search', '-no-jre-restrict-search'.....
In-Reply-To: <548F5921.8070809@oracle.com>
References: <548F5921.8070809@oracle.com>
Message-ID: <548F8ACB.8030107@oracle.com>

Looks fine Kumar; thanks,

-Joe

On 12/15/2014 01:56 PM, Kumar Srinivasan wrote:
> Hello ,
>
> Please review webrev to fix the following minor issues:
> 1. JDK-8067421:  java -help contains information about 
> "-version:",'-jre-restrict-search', '-no-jre-restrict-search', but 
> they are removed
> 2. JDK-8067411:  tools/launcher/MultipleJRE.sh requires adjustments to 
> work with module boundaries
> 3. JDK-8067290: missing bugid in test
>
> http://cr.openjdk.java.net/~ksrini/8067421/webrev.0/
>
> Thanks
> Kumar
>
>



From david.holmes at oracle.com  Tue Dec 16 05:20:55 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 Dec 2014 15:20:55 +1000
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <548F1EF4.1040007@oracle.com>
References: <547F9302.3060309@oracle.com>	<547FD6F2.5060400@oracle.com>	<548023D0.4020702@oracle.com>	<548047C3.8000400@oracle.com>	<54804E4B.2070908@oracle.com>	<5480529F.1020902@oracle.com>
	<54805B5D.5020504@oracle.com>	<54809627.8070103@oracle.com>
	<5480EFE8.3090809@oracle.com> <5482105D.40005@oracle.com>
	<5482D77C.9030100@gmail.com> <5482DE1F.5070906@oracle.com>
	<548F1EF4.1040007@oracle.com>
Message-ID: <548FC137.1080209@oracle.com>

On 16/12/2014 3:48 AM, Daniel Fuchs wrote:
> Hi guys,
>
> Do I have approval to push the latest version of the test for JDK 9:
> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/
> or are there still some objections?

My objections stand - the classloader aspect of the test is overly 
complicated and not achieving anything.

David

> best regards,
>
> -- daniel
>
>
> On 06/12/14 11:44, Daniel Fuchs wrote:
>> Hi Peter,
>>
>>
>> On 12/6/14 11:16 AM, Peter Levart wrote:
>>>
>>> On 12/05/2014 09:06 PM, Daniel Fuchs wrote:
>>>> Hi David, all,
>>>>
>>>> @David: You're right David.
>>>>         The loader parameter is never used - I have removed it.
>>>>
>>>> @all: I have received a comment from Alan that it would be better to
>>>> use
>>>>       the new jrt:/ FileSystem directly, rather than using private
>>>> APIs.
>>>>       One of the consequence is that the test now loads all the
>>>>       classes in the runtime image (not just the ones in the BCL),
>>>>       and therefore I have removed the toggle that allowed to test
>>>>       the boot classes only.
>>>>
>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>
>>> Hi Daniel,
>>>
>>> Would it be possible to extract a minimal API for streaming over
>>> classes and put that into the testlib so that only this part differs
>>> between JDK8 and JDK9 and the guts of the test is identical for both
>>> JDK8 and JDK9 ?
>>>
>>> This would ease backport efforts when the test(s) are later "beefed
>>> up" with other functionality. The API could later be extended with
>>> other functionality, but just for illustration what might be needed,
>>> here's what Martin Buchholz started as a test for finding possible
>>> data races in reflection and I just re-packed using Streams. From
>>> first glance it seems the tests need similar common functionality:
>>>
>>> http://cr.openjdk.java.net/~plevart/misc/SunReflectDataRaces/
>>>
>>> Regards, Peter
>>
>> The test is already built like that:
>>
>> The part that finds the class names is encapsulated in an object which
>> implements Iterable<String>.
>>
>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ ->
>> ClassNameJrtStreamBuilder
>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8-00/ ->
>> ClassNameStreamBuilder
>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00/ ->
>> ClassNameListBuilder
>>
>> The bulk of the test should be identical (well, almost identical since I
>> only
>> updated 9 after the reviews, and since 9 is the only one that needs the
>> System ClassLoader)... I suppose we could extract these 3 classes and
>> define
>> a library class with something like:
>>
>> public static class ClassNameFinder {
>>       public static Iterable<String> findAllClassNames() {
>> jdk9 impl:            return new ClassNameJrtStreamBuilder();
>> jdk8 impl:            return new ClassNameStreamBuilder();
>> jdk7 impl:            return new ClassNameListBuilder();
>>       }
>> }
>>
>> As it stands - this corresponds to the
>>
>>   static Iterable<String> listAllClassNames()
>>
>> factory method  in each version of the test.
>>
>>
>> best regards,
>>
>> -- daniel
>>
>>>
>>>>
>>>> On 05/12/14 00:36, David Holmes wrote:
>>>>> Hi Daniel,
>>>>>
>>>>> I still find your use of the classloader very confusing. You talk
>>>>> about
>>>>> the defining loader but you never check the defining loader against
>>>>> anything. In
>>>>>
>>>>>   146         static void checkFor(Class<?> c, ClassLoader loader) {
>>>>>
>>>>> the loader variable is never used. And if loader is simply the name of
>>>>> the loader passed to forName, then it may not be the defining loader
>>>>> anyway - so the whole use of this loader variable seems superfluous at
>>>>> best, and confusing/misleading at worst. And you can use the simple
>>>>> forName(name) variant rather than passing a loader.
>>>>>
>>>>> David
>>>>>
>>>>> On 5/12/2014 3:13 AM, Daniel Fuchs wrote:
>>>>>> On 04/12/14 14:02, Se?n Coffey wrote:
>>>>>>> Thanks for driving efforts in this area Daniel. I think it's a very
>>>>>>> useful test and is bound to help test code coverage. If it's
>>>>>>> currently
>>>>>>> passing on all JPRT platforms, it's a good measure.
>>>>>>
>>>>>> It seems to :-)
>>>>>>
>>>>>>> Eventually I think we can bulk up the tests that can be run on the
>>>>>>> Iterable returned from your class search.
>>>>>>> At moment you just test Field.setAccessible.
>>>>>>
>>>>>> Yes. If we change it later to test more, we will probably need to
>>>>>> change its name. I was already in lack of inspiration:
>>>>>> FieldSetAccessibleTest is not really a great name - but hopefully
>>>>>> it can do for now.
>>>>>>
>>>>>>> In the future, I don't see any harm in adding all simple Field
>>>>>>> method
>>>>>>> calls so that any corner cases in custom classes like the original
>>>>>>> issue
>>>>>>> are caught. e.g Field.getDeclaredAnnotations(),
>>>>>>> Field.getModifiers(),
>>>>>>> Field.isEnumConstant() etc., etc. Some methods won't be much value
>>>>>>> add
>>>>>>> but they're not a cost either.
>>>>>>
>>>>>> Agreed.
>>>>>>
>>>>>>> Same argument for running through all Class methods, e.g
>>>>>>> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a
>>>>>>> result this
>>>>>>> test might eventually become more general in test goal and might
>>>>>>> live
>>>>>>> better one level up in "test/java/lang/Class/" - it can be moved
>>>>>>> when
>>>>>>> the time comes.
>>>>>>
>>>>>> Agreed as well :-)
>>>>>>
>>>>>> Here is a new revision of the webrev for 9 in which I have
>>>>>> incorporated David's comment:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/
>>>>>>
>>>>>> best regards,
>>>>>>
>>>>>> -- daniel
>>>>>>
>>>>>>>
>>>>>>> regards,
>>>>>>> Sean.
>>>>>>>
>>>>>>> On 04/12/2014 12:25, Daniel Fuchs wrote:
>>>>>>>> On 04/12/14 13:06, David Holmes wrote:
>>>>>>>>> Hi Daniel,
>>>>>>>>>
>>>>>>>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> In fact I could use 'null' on JDK 9 as well.
>>>>>>>>>> My first version of the JDK 9 test was parsing over all the
>>>>>>>>>> .jimage
>>>>>>>>>> files under <jdk>/lib/modules - which explain why I needed to
>>>>>>>>>> use the System class loader.
>>>>>>>>>>
>>>>>>>>>> Then I switched to only parsing the bootmodules.jimage - because
>>>>>>>>>> I noticed that the results where more coherent with what I had
>>>>>>>>>> observed on 8 & 7 - but I kept using the System class loader.
>>>>>>>>>>
>>>>>>>>>> I am not sure whether we want the test for 9 should iterate over
>>>>>>>>>> the three .jimage - or continue to test only the boot .jimage.
>>>>>>>>>>
>>>>>>>>>> I have updated the JDK 9 test (refreshed the webrev in place)
>>>>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/
>>>>>>>>>> and added support for possibly running the test in the two modes
>>>>>>>>>> (I added a 'test.boot.only' system property, true by default)
>>>>>>>>>> as well as additional traces to print the loaded classes by
>>>>>>>>>> defining loader at the end (test.list.classes, false by default).
>>>>>>>>>
>>>>>>>>> A couple of initial comments:
>>>>>>>>>
>>>>>>>>>   104     static ClassLoader getClassLoaderFor(String
>>>>>>>>> classFileName) {
>>>>>>>>>   105         if (restrictToBoot) return null; // only bootmodules
>>>>>>>>>   106         return ClassLoaders.systemClassLoader;
>>>>>>>>>   107     }
>>>>>>>>>
>>>>>>>>> I'm not clear the intent here. If it is to return a loader for
>>>>>>>>> which
>>>>>>>>> loadClass could be invoked then you can always just return the
>>>>>>>>> system
>>>>>>>>> loader - or just Class.forName. If it is meant to the return the
>>>>>>>>> expected defining loader then it isn't doing that as the
>>>>>>>>> extensions
>>>>>>>>> loader is not allowed for.
>>>>>>>>
>>>>>>>> The intent is to return the class loader that will be passed to
>>>>>>>> Class.forName( ). I've been fiddling & experimenting with this
>>>>>>>> test over 3 different platforms while trying to minimize the
>>>>>>>> differences - so that was my attempt at having a good place to
>>>>>>>> experiment with different strategy for loading classes.
>>>>>>>>
>>>>>>>>> Similarly for:
>>>>>>>>>
>>>>>>>>>   128         static ClassLoader getFor(String classFileName) {
>>>>>>>>>   129             return systemClassLoader;
>>>>>>>>>   130         }
>>>>>>>>
>>>>>>>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..)
>>>>>>>> was supposed to simply return ClassLoaders.getFor(...);
>>>>>>>> and all the code should be in ClassLoaders.getFor - my bad.
>>>>>>>>
>>>>>>>>> Minor nit - In:
>>>>>>>>>
>>>>>>>>> 135                     System.err.println("Unexpected loader for
>>>>>>>>> "+c+":
>>>>>>>>> "+c.getClassLoader());
>>>>>>>>>
>>>>>>>>> c.getClassLoader() can be replaced by cl. Also put spaces around
>>>>>>>>> the +
>>>>>>>>> operator.
>>>>>>>>
>>>>>>>> Good catch.
>>>>>>>>
>>>>>>>> Thanks a lot David! Have a good night! (that's quite late - isn't
>>>>>>>> it?)
>>>>>>>>
>>>>>>>> -- daniel
>>>>>>>>
>>>>>>>>>
>>>>>>>>> David
>>>>>>>>> (signing off for the night)
>>>>>>>>>
>>>>>>>>>> Thanks for your question, it triggered me into looking deeper
>>>>>>>>>> into what was happening :-)
>>>>>>>>>>
>>>>>>>>>> best regards,
>>>>>>>>>>
>>>>>>>>>> -- daniel
>>>>>>>>>>
>>>>>>>>>> On 04/12/14 10:05, Daniel Fuchs wrote:
>>>>>>>>>>>>> The differences between 8 & 9 are limited to:
>>>>>>>>>>>>>
>>>>>>>>>>>>>     - ClassLoader:
>>>>>>>>>>>>>          - on 8 we use 'null' (BCL)
>>>>>>>>>>>>>          - on 9 we use the system class loader.
>>>>>>>>>>>>
>>>>>>>>>>>> I haven't seen anything in JEP 220, regarding modules, that
>>>>>>>>>>>> indicates
>>>>>>>>>>>> that classes currently loaded  by the boot-loader will now be
>>>>>>>>>>>> loaded
>>>>>>>>>>>> by the system classloader ???
>>>>>>>>>>>
>>>>>>>>>>> In [1] towards the end:
>>>>>>>>>>>
>>>>>>>>>>> [1] http://openjdk.java.net/jeps/220
>>>>>>>>>>>
>>>>>>>>>>> "The defining class loader of the types in some existing
>>>>>>>>>>> packages
>>>>>>>>>>>   will change. Existing code that makes assumptions about the
>>>>>>>>>>> class
>>>>>>>>>>>   loaders of these types might not work correctly."
>>>>>>>>>>>   (then there is a list of specific changes).
>>>>>>>>>>>
>>>>>>>>>>> This test looks up all class names in the image files and
>>>>>>>>>>> attempt
>>>>>>>>>>> to load the corresponding class. But as indicated in [1]
>>>>>>>>>>> some of these classes are now in the Boot CL, some in the
>>>>>>>>>>> Extension CL, and some in the Application CL.
>>>>>>>>>>>
>>>>>>>>>>> So the test uses the System CL to load each class - which
>>>>>>>>>>> ensures
>>>>>>>>>>> that the loading will be delegated to the appropriate
>>>>>>>>>>> ClassLoader.
>>>>>>>>>>>
>>>>>>>>>>> best regards,
>>>>>>>>>>>
>>>>>>>>>>> -- daniel
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>


From ivan.gerasimov at oracle.com  Tue Dec 16 07:57:05 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 16 Dec 2014 10:57:05 +0300
Subject: Java implementation of Alpha-numeric comparator
In-Reply-To: <548F6145.1060207@oracle.com>
References: <548EBD94.1070804@oracle.com> <548F6145.1060207@oracle.com>
Message-ID: <548FE5D1.9040603@oracle.com>

Thanks Roger!

Yes, I agree that a CharSequence variant should be enough.

The function is wrapped into a Comparator, so it can easily be plugged 
into an application.
If many people find it useful, I guess it can later be moved from 
samples to jdk.

Here's the updated webrev:
http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/1/webrev/

Sincerely yours,
Ivan

On 16.12.2014 1:31, roger riggs wrote:
> Hi Ivan,
>
> It does seem like a useful function, though I would have started with 
> the API,
> not the implementation.
>
> Can it apply to CharSequence not only String and maybe skip the
> separate char[] version, a char[] array can be wrapped to become a 
> CharSequence via CharBuffer.
> Or a via a new static method to define a CharSequence from a char array.
>
> $.02, Roger
>
> On 12/15/2014 5:53 AM, Ivan Gerasimov wrote:
>> Hello everyone!
>>
>> In certain situations the preferred way of sorting strings is a 
>> combination of char-comparing sorting with numeric sorting, where 
>> applicable.
>> List of strings sorted this way often look more natural to the human 
>> eyes:
>> { "alpha",
>>   "java1",
>>   "java2",
>>   "java10",
>>   "zero" }
>>
>> Here's presented a sample implementation of the comparator, which 
>> supports this way of sorting.
>> I placed it under src/sample directory.
>>
>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/0/webrev/
>>
>>
>> MSDN provides the function StrCmpLogicalW(), which can be used for 
>> similar sort order.
>> http://msdn.microsoft.com/en-us/library/windows/desktop/bb759947%28v=vs.85%29.aspx 
>>
>>
>> The differences are:
>>  - case-sensitivity (StrCmpLogicalW is case-insensitive);
>>  - treating leading zeroes;
>>  - more accurate handling of strings with big numbers, which cannot 
>> be converted to int/long.
>>
>> I guess this comparator may become particularly useful when we'll 
>> have 'java10' and update releases/build numbers > 99 in the lists :)
>>
>> I want to ask the community about how useful this comparator may be 
>> to you?
>>
>> Sincerely yours,
>> Ivan
>>
>
>
>



From ivan.gerasimov at oracle.com  Tue Dec 16 08:00:52 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 16 Dec 2014 11:00:52 +0300
Subject: Java implementation of Alpha-numeric comparator
In-Reply-To: <548F6DA8.8060707@oracle.com>
References: <548EBD94.1070804@oracle.com> <548F6145.1060207@oracle.com>
	<548F6DA8.8060707@oracle.com>
Message-ID: <548FE6B4.5030504@oracle.com>

Thanks Naoto, good point!

Since Character.isDigit is used to determine the numeric part of a 
string, the full width digits are already taken into account.
I only had to modify handling of leading zeros: instead of comparing the 
character with '0', it's now checking if Character.digit(ch, 10) equals 
to zero.

The updated webrev is here:
http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/1/webrev/

Sincerely yours,
Ivan

On 16.12.2014 2:24, Naoto Sato wrote:
> Hello,
>
> It seems useful to me too, but it should also take digits other than 
> '0' to '9' into account, for example, ??????????.
>
> Naoto
>
> On 12/15/14, 2:31 PM, roger riggs wrote:
>> Hi Ivan,
>>
>> It does seem like a useful function, though I would have started with
>> the API,
>> not the implementation.
>>
>> Can it apply to CharSequence not only String and maybe skip the
>> separate char[] version, a char[] array can be wrapped to become a
>> CharSequence via CharBuffer.
>> Or a via a new static method to define a CharSequence from a char array.
>>
>> $.02, Roger
>>
>> On 12/15/2014 5:53 AM, Ivan Gerasimov wrote:
>>> Hello everyone!
>>>
>>> In certain situations the preferred way of sorting strings is a
>>> combination of char-comparing sorting with numeric sorting, where
>>> applicable.
>>> List of strings sorted this way often look more natural to the human
>>> eyes:
>>> { "alpha",
>>>   "java1",
>>>   "java2",
>>>   "java10",
>>>   "zero" }
>>>
>>> Here's presented a sample implementation of the comparator, which
>>> supports this way of sorting.
>>> I placed it under src/sample directory.
>>>
>>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/0/webrev/
>>>
>>>
>>> MSDN provides the function StrCmpLogicalW(), which can be used for
>>> similar sort order.
>>> http://msdn.microsoft.com/en-us/library/windows/desktop/bb759947%28v=vs.85%29.aspx 
>>>
>>>
>>>
>>> The differences are:
>>>  - case-sensitivity (StrCmpLogicalW is case-insensitive);
>>>  - treating leading zeroes;
>>>  - more accurate handling of strings with big numbers, which cannot be
>>> converted to int/long.
>>>
>>> I guess this comparator may become particularly useful when we'll have
>>> 'java10' and update releases/build numbers > 99 in the lists :)
>>>
>>> I want to ask the community about how useful this comparator may be to
>>> you?
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>
>
>



From ivan.gerasimov at oracle.com  Tue Dec 16 08:13:47 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 16 Dec 2014 11:13:47 +0300
Subject: Java implementation of Alpha-numeric comparator
In-Reply-To: <548F7120.9040400@univ-mlv.fr>
References: <548EBD94.1070804@oracle.com> <548F6145.1060207@oracle.com>
	<548F7120.9040400@univ-mlv.fr>
Message-ID: <548FE9BB.7040005@oracle.com>

Thanks Remi for the comments!

As you and Roger suggested I only left a CharSequence variant of the 
comparator.

I also removed the custom Comparator<Character> altogether for now, for 
the sake of simplicity.
I guess for the purpose of a sample Character.compare(ch1, ch2) should 
be good enough.

Here's the updated webrev:
http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/1/webrev/

I'm not certain, why the comparator should be serializable.
Could you please elaborate on this?

Sincerely yours,
Ivan

On 16.12.2014 2:39, Remi Forax wrote:
> Hi Ivan, hi Roger,
>
> Roger, the API already exists it's the interface Comparator.
>
> I agree with Roger that a comparator that use a CharSequence is better 
> that the one that use a char array.
>
> The thing that worry me is the Comparator<Character> taken as 
> parameter, it means that
> each time the method compare() is called on this comparator, the two 
> arguments are boxed.
>
> Minor comment, to be included, I think that these comparators should 
> be serializable
> and in my opinion the best way to do that is to use a lambda instead 
> of a class.
>
> R?mi
>
> On 12/15/2014 11:31 PM, roger riggs wrote:
>> Hi Ivan,
>>
>> It does seem like a useful function, though I would have started with 
>> the API,
>> not the implementation.
>>
>> Can it apply to CharSequence not only String and maybe skip the
>> separate char[] version, a char[] array can be wrapped to become a 
>> CharSequence via CharBuffer.
>> Or a via a new static method to define a CharSequence from a char array.
>>
>> $.02, Roger
>>
>> On 12/15/2014 5:53 AM, Ivan Gerasimov wrote:
>>> Hello everyone!
>>>
>>> In certain situations the preferred way of sorting strings is a 
>>> combination of char-comparing sorting with numeric sorting, where 
>>> applicable.
>>> List of strings sorted this way often look more natural to the human 
>>> eyes:
>>> { "alpha",
>>>   "java1",
>>>   "java2",
>>>   "java10",
>>>   "zero" }
>>>
>>> Here's presented a sample implementation of the comparator, which 
>>> supports this way of sorting.
>>> I placed it under src/sample directory.
>>>
>>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/0/webrev/
>>>
>>>
>>> MSDN provides the function StrCmpLogicalW(), which can be used for 
>>> similar sort order.
>>> http://msdn.microsoft.com/en-us/library/windows/desktop/bb759947%28v=vs.85%29.aspx 
>>>
>>>
>>> The differences are:
>>>  - case-sensitivity (StrCmpLogicalW is case-insensitive);
>>>  - treating leading zeroes;
>>>  - more accurate handling of strings with big numbers, which cannot 
>>> be converted to int/long.
>>>
>>> I guess this comparator may become particularly useful when we'll 
>>> have 'java10' and update releases/build numbers > 99 in the lists :)
>>>
>>> I want to ask the community about how useful this comparator may be 
>>> to you?
>>>
>>> Sincerely yours,
>>> Ivan
>>>
>>
>
>
>



From forax at univ-mlv.fr  Tue Dec 16 08:23:56 2014
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 16 Dec 2014 09:23:56 +0100
Subject: Java implementation of Alpha-numeric comparator
In-Reply-To: <548FE9BB.7040005@oracle.com>
References: <548EBD94.1070804@oracle.com> <548F6145.1060207@oracle.com>
	<548F7120.9040400@univ-mlv.fr> <548FE9BB.7040005@oracle.com>
Message-ID: <548FEC1C.2070300@univ-mlv.fr>


On 12/16/2014 09:13 AM, Ivan Gerasimov wrote:
> Thanks Remi for the comments!
>
> As you and Roger suggested I only left a CharSequence variant of the 
> comparator.
>
> I also removed the custom Comparator<Character> altogether for now, 
> for the sake of simplicity.
> I guess for the purpose of a sample Character.compare(ch1, ch2) should 
> be good enough.
>
> Here's the updated webrev:
> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/1/webrev/
>
> I'm not certain, why the comparator should be serializable.
> Could you please elaborate on this?

Yes, all public comparators in the JDK are serializable because 
otherwise people will not be able to serialize collections like TreeSet 
or ConcurrentSkipListSet that implement Serializable and take a 
comparator as an optional argument.


>
> Sincerely yours,
> Ivan

cheers,
R?mi

>
> On 16.12.2014 2:39, Remi Forax wrote:
>> Hi Ivan, hi Roger,
>>
>> Roger, the API already exists it's the interface Comparator.
>>
>> I agree with Roger that a comparator that use a CharSequence is 
>> better that the one that use a char array.
>>
>> The thing that worry me is the Comparator<Character> taken as 
>> parameter, it means that
>> each time the method compare() is called on this comparator, the two 
>> arguments are boxed.
>>
>> Minor comment, to be included, I think that these comparators should 
>> be serializable
>> and in my opinion the best way to do that is to use a lambda instead 
>> of a class.
>>
>> R?mi
>>
>> On 12/15/2014 11:31 PM, roger riggs wrote:
>>> Hi Ivan,
>>>
>>> It does seem like a useful function, though I would have started 
>>> with the API,
>>> not the implementation.
>>>
>>> Can it apply to CharSequence not only String and maybe skip the
>>> separate char[] version, a char[] array can be wrapped to become a 
>>> CharSequence via CharBuffer.
>>> Or a via a new static method to define a CharSequence from a char 
>>> array.
>>>
>>> $.02, Roger
>>>
>>> On 12/15/2014 5:53 AM, Ivan Gerasimov wrote:
>>>> Hello everyone!
>>>>
>>>> In certain situations the preferred way of sorting strings is a 
>>>> combination of char-comparing sorting with numeric sorting, where 
>>>> applicable.
>>>> List of strings sorted this way often look more natural to the 
>>>> human eyes:
>>>> { "alpha",
>>>>   "java1",
>>>>   "java2",
>>>>   "java10",
>>>>   "zero" }
>>>>
>>>> Here's presented a sample implementation of the comparator, which 
>>>> supports this way of sorting.
>>>> I placed it under src/sample directory.
>>>>
>>>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/0/webrev/
>>>>
>>>>
>>>> MSDN provides the function StrCmpLogicalW(), which can be used for 
>>>> similar sort order.
>>>> http://msdn.microsoft.com/en-us/library/windows/desktop/bb759947%28v=vs.85%29.aspx 
>>>>
>>>>
>>>> The differences are:
>>>>  - case-sensitivity (StrCmpLogicalW is case-insensitive);
>>>>  - treating leading zeroes;
>>>>  - more accurate handling of strings with big numbers, which cannot 
>>>> be converted to int/long.
>>>>
>>>> I guess this comparator may become particularly useful when we'll 
>>>> have 'java10' and update releases/build numbers > 99 in the lists :)
>>>>
>>>> I want to ask the community about how useful this comparator may be 
>>>> to you?
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>>
>>>
>>
>>
>>
>



From ivan.gerasimov at oracle.com  Tue Dec 16 08:57:42 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 16 Dec 2014 11:57:42 +0300
Subject: Java implementation of Alpha-numeric comparator
In-Reply-To: <548FEC1C.2070300@univ-mlv.fr>
References: <548EBD94.1070804@oracle.com> <548F6145.1060207@oracle.com>
	<548F7120.9040400@univ-mlv.fr> <548FE9BB.7040005@oracle.com>
	<548FEC1C.2070300@univ-mlv.fr>
Message-ID: <548FF406.2060108@oracle.com>

Got it, thanks!

Please find the updated webrev at the same location:
http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/1/webrev/

Sincerely yours,
Ivan

On 16.12.2014 11:23, Remi Forax wrote:
>
> On 12/16/2014 09:13 AM, Ivan Gerasimov wrote:
>> Thanks Remi for the comments!
>>
>> As you and Roger suggested I only left a CharSequence variant of the 
>> comparator.
>>
>> I also removed the custom Comparator<Character> altogether for now, 
>> for the sake of simplicity.
>> I guess for the purpose of a sample Character.compare(ch1, ch2) 
>> should be good enough.
>>
>> Here's the updated webrev:
>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/1/webrev/
>>
>> I'm not certain, why the comparator should be serializable.
>> Could you please elaborate on this?
>
> Yes, all public comparators in the JDK are serializable because 
> otherwise people will not be able to serialize collections like 
> TreeSet or ConcurrentSkipListSet that implement Serializable and take 
> a comparator as an optional argument.
>
>
>>
>> Sincerely yours,
>> Ivan
>
> cheers,
> R?mi
>
>>
>> On 16.12.2014 2:39, Remi Forax wrote:
>>> Hi Ivan, hi Roger,
>>>
>>> Roger, the API already exists it's the interface Comparator.
>>>
>>> I agree with Roger that a comparator that use a CharSequence is 
>>> better that the one that use a char array.
>>>
>>> The thing that worry me is the Comparator<Character> taken as 
>>> parameter, it means that
>>> each time the method compare() is called on this comparator, the two 
>>> arguments are boxed.
>>>
>>> Minor comment, to be included, I think that these comparators should 
>>> be serializable
>>> and in my opinion the best way to do that is to use a lambda instead 
>>> of a class.
>>>
>>> R?mi
>>>
>>> On 12/15/2014 11:31 PM, roger riggs wrote:
>>>> Hi Ivan,
>>>>
>>>> It does seem like a useful function, though I would have started 
>>>> with the API,
>>>> not the implementation.
>>>>
>>>> Can it apply to CharSequence not only String and maybe skip the
>>>> separate char[] version, a char[] array can be wrapped to become a 
>>>> CharSequence via CharBuffer.
>>>> Or a via a new static method to define a CharSequence from a char 
>>>> array.
>>>>
>>>> $.02, Roger
>>>>
>>>> On 12/15/2014 5:53 AM, Ivan Gerasimov wrote:
>>>>> Hello everyone!
>>>>>
>>>>> In certain situations the preferred way of sorting strings is a 
>>>>> combination of char-comparing sorting with numeric sorting, where 
>>>>> applicable.
>>>>> List of strings sorted this way often look more natural to the 
>>>>> human eyes:
>>>>> { "alpha",
>>>>>   "java1",
>>>>>   "java2",
>>>>>   "java10",
>>>>>   "zero" }
>>>>>
>>>>> Here's presented a sample implementation of the comparator, which 
>>>>> supports this way of sorting.
>>>>> I placed it under src/sample directory.
>>>>>
>>>>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/0/webrev/
>>>>>
>>>>>
>>>>> MSDN provides the function StrCmpLogicalW(), which can be used for 
>>>>> similar sort order.
>>>>> http://msdn.microsoft.com/en-us/library/windows/desktop/bb759947%28v=vs.85%29.aspx 
>>>>>
>>>>>
>>>>> The differences are:
>>>>>  - case-sensitivity (StrCmpLogicalW is case-insensitive);
>>>>>  - treating leading zeroes;
>>>>>  - more accurate handling of strings with big numbers, which 
>>>>> cannot be converted to int/long.
>>>>>
>>>>> I guess this comparator may become particularly useful when we'll 
>>>>> have 'java10' and update releases/build numbers > 99 in the lists :)
>>>>>
>>>>> I want to ask the community about how useful this comparator may 
>>>>> be to you?
>>>>>
>>>>> Sincerely yours,
>>>>> Ivan
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>



From daniel.fuchs at oracle.com  Tue Dec 16 10:34:43 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 16 Dec 2014 11:34:43 +0100
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <548FC137.1080209@oracle.com>
References: <547F9302.3060309@oracle.com>	<547FD6F2.5060400@oracle.com>	<548023D0.4020702@oracle.com>	<548047C3.8000400@oracle.com>	<54804E4B.2070908@oracle.com>	<5480529F.1020902@oracle.com>
	<54805B5D.5020504@oracle.com>	<54809627.8070103@oracle.com>
	<5480EFE8.3090809@oracle.com> <5482105D.40005@oracle.com>
	<5482D77C.9030100@gmail.com> <5482DE1F.5070906@oracle.com>
	<548F1EF4.1040007@oracle.com> <548FC137.1080209@oracle.com>
Message-ID: <54900AC3.4060208@oracle.com>

Hi David,

On 12/16/14 6:20 AM, David Holmes wrote:
> On 16/12/2014 3:48 AM, Daniel Fuchs wrote:
>> Hi guys,
>>
>> Do I have approval to push the latest version of the test for JDK 9:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/
>> or are there still some objections?
>
> My objections stand - the classloader aspect of the test is overly 
> complicated and not achieving anything.

I see. Sorry for misunderstanding. See below:

On 12/5/14 12:36 AM, David Holmes wrote:
> the loader variable is never used. And if loader is simply the name of 
> the loader passed to forName, then it may not be the defining loader 
> anyway - so the whole use of this loader variable seems superfluous at 
> best, and confusing/misleading at worst. And you can use the simple 
> forName(name) variant rather than passing a loader.

  - I thought your objection was only with the loader argument in 
checkClassLoaderFor,
     which I removed in webrev-jdk9.02. I have prepared a new webrev.
  - Using the simple Class.forName(name) is not an option because it 
forces the
     static initializers to run at class loading. I don't think we want 
that in this test.

Here is a new version where I have removed all the 'ClassLoaders' stuff. 
After all
it was not instrumental to the test. Is that good to go?

best regards,

-- daniel

>
> David
>
>> best regards,
>>
>> -- daniel
>>
>>
>> On 06/12/14 11:44, Daniel Fuchs wrote:
>>> Hi Peter,
>>>
>>>
>>> On 12/6/14 11:16 AM, Peter Levart wrote:
>>>>
>>>> On 12/05/2014 09:06 PM, Daniel Fuchs wrote:
>>>>> Hi David, all,
>>>>>
>>>>> @David: You're right David.
>>>>>         The loader parameter is never used - I have removed it.
>>>>>
>>>>> @all: I have received a comment from Alan that it would be better to
>>>>> use
>>>>>       the new jrt:/ FileSystem directly, rather than using private
>>>>> APIs.
>>>>>       One of the consequence is that the test now loads all the
>>>>>       classes in the runtime image (not just the ones in the BCL),
>>>>>       and therefore I have removed the toggle that allowed to test
>>>>>       the boot classes only.
>>>>>
>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/
>>>>>
>>>>> best regards,
>>>>>
>>>>> -- daniel
>>>>
>>>> Hi Daniel,
>>>>
>>>> Would it be possible to extract a minimal API for streaming over
>>>> classes and put that into the testlib so that only this part differs
>>>> between JDK8 and JDK9 and the guts of the test is identical for both
>>>> JDK8 and JDK9 ?
>>>>
>>>> This would ease backport efforts when the test(s) are later "beefed
>>>> up" with other functionality. The API could later be extended with
>>>> other functionality, but just for illustration what might be needed,
>>>> here's what Martin Buchholz started as a test for finding possible
>>>> data races in reflection and I just re-packed using Streams. From
>>>> first glance it seems the tests need similar common functionality:
>>>>
>>>> http://cr.openjdk.java.net/~plevart/misc/SunReflectDataRaces/
>>>>
>>>> Regards, Peter
>>>
>>> The test is already built like that:
>>>
>>> The part that finds the class names is encapsulated in an object which
>>> implements Iterable<String>.
>>>
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.02/ ->
>>> ClassNameJrtStreamBuilder
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk8-00/ ->
>>> ClassNameStreamBuilder
>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk7.00/ ->
>>> ClassNameListBuilder
>>>
>>> The bulk of the test should be identical (well, almost identical 
>>> since I
>>> only
>>> updated 9 after the reviews, and since 9 is the only one that needs the
>>> System ClassLoader)... I suppose we could extract these 3 classes and
>>> define
>>> a library class with something like:
>>>
>>> public static class ClassNameFinder {
>>>       public static Iterable<String> findAllClassNames() {
>>> jdk9 impl:            return new ClassNameJrtStreamBuilder();
>>> jdk8 impl:            return new ClassNameStreamBuilder();
>>> jdk7 impl:            return new ClassNameListBuilder();
>>>       }
>>> }
>>>
>>> As it stands - this corresponds to the
>>>
>>>   static Iterable<String> listAllClassNames()
>>>
>>> factory method  in each version of the test.
>>>
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>>
>>>>>
>>>>> On 05/12/14 00:36, David Holmes wrote:
>>>>>> Hi Daniel,
>>>>>>
>>>>>> I still find your use of the classloader very confusing. You talk
>>>>>> about
>>>>>> the defining loader but you never check the defining loader against
>>>>>> anything. In
>>>>>>
>>>>>>   146         static void checkFor(Class<?> c, ClassLoader loader) {
>>>>>>
>>>>>> the loader variable is never used. And if loader is simply the 
>>>>>> name of
>>>>>> the loader passed to forName, then it may not be the defining loader
>>>>>> anyway - so the whole use of this loader variable seems 
>>>>>> superfluous at
>>>>>> best, and confusing/misleading at worst. And you can use the simple
>>>>>> forName(name) variant rather than passing a loader.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 5/12/2014 3:13 AM, Daniel Fuchs wrote:
>>>>>>> On 04/12/14 14:02, Se?n Coffey wrote:
>>>>>>>> Thanks for driving efforts in this area Daniel. I think it's a 
>>>>>>>> very
>>>>>>>> useful test and is bound to help test code coverage. If it's
>>>>>>>> currently
>>>>>>>> passing on all JPRT platforms, it's a good measure.
>>>>>>>
>>>>>>> It seems to :-)
>>>>>>>
>>>>>>>> Eventually I think we can bulk up the tests that can be run on the
>>>>>>>> Iterable returned from your class search.
>>>>>>>> At moment you just test Field.setAccessible.
>>>>>>>
>>>>>>> Yes. If we change it later to test more, we will probably need to
>>>>>>> change its name. I was already in lack of inspiration:
>>>>>>> FieldSetAccessibleTest is not really a great name - but hopefully
>>>>>>> it can do for now.
>>>>>>>
>>>>>>>> In the future, I don't see any harm in adding all simple Field
>>>>>>>> method
>>>>>>>> calls so that any corner cases in custom classes like the original
>>>>>>>> issue
>>>>>>>> are caught. e.g Field.getDeclaredAnnotations(),
>>>>>>>> Field.getModifiers(),
>>>>>>>> Field.isEnumConstant() etc., etc. Some methods won't be much value
>>>>>>>> add
>>>>>>>> but they're not a cost either.
>>>>>>>
>>>>>>> Agreed.
>>>>>>>
>>>>>>>> Same argument for running through all Class methods, e.g
>>>>>>>> Class.getDeclaredClasses(), Class.getDeclaredMethods(). As a
>>>>>>>> result this
>>>>>>>> test might eventually become more general in test goal and might
>>>>>>>> live
>>>>>>>> better one level up in "test/java/lang/Class/" - it can be moved
>>>>>>>> when
>>>>>>>> the time comes.
>>>>>>>
>>>>>>> Agreed as well :-)
>>>>>>>
>>>>>>> Here is a new revision of the webrev for 9 in which I have
>>>>>>> incorporated David's comment:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.01/
>>>>>>>
>>>>>>> best regards,
>>>>>>>
>>>>>>> -- daniel
>>>>>>>
>>>>>>>>
>>>>>>>> regards,
>>>>>>>> Sean.
>>>>>>>>
>>>>>>>> On 04/12/2014 12:25, Daniel Fuchs wrote:
>>>>>>>>> On 04/12/14 13:06, David Holmes wrote:
>>>>>>>>>> Hi Daniel,
>>>>>>>>>>
>>>>>>>>>> On 4/12/2014 9:38 PM, Daniel Fuchs wrote:
>>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>> In fact I could use 'null' on JDK 9 as well.
>>>>>>>>>>> My first version of the JDK 9 test was parsing over all the
>>>>>>>>>>> .jimage
>>>>>>>>>>> files under <jdk>/lib/modules - which explain why I needed to
>>>>>>>>>>> use the System class loader.
>>>>>>>>>>>
>>>>>>>>>>> Then I switched to only parsing the bootmodules.jimage - 
>>>>>>>>>>> because
>>>>>>>>>>> I noticed that the results where more coherent with what I had
>>>>>>>>>>> observed on 8 & 7 - but I kept using the System class loader.
>>>>>>>>>>>
>>>>>>>>>>> I am not sure whether we want the test for 9 should iterate 
>>>>>>>>>>> over
>>>>>>>>>>> the three .jimage - or continue to test only the boot .jimage.
>>>>>>>>>>>
>>>>>>>>>>> I have updated the JDK 9 test (refreshed the webrev in place)
>>>>>>>>>>> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.00/ 
>>>>>>>>>>>
>>>>>>>>>>> and added support for possibly running the test in the two 
>>>>>>>>>>> modes
>>>>>>>>>>> (I added a 'test.boot.only' system property, true by default)
>>>>>>>>>>> as well as additional traces to print the loaded classes by
>>>>>>>>>>> defining loader at the end (test.list.classes, false by 
>>>>>>>>>>> default).
>>>>>>>>>>
>>>>>>>>>> A couple of initial comments:
>>>>>>>>>>
>>>>>>>>>>   104     static ClassLoader getClassLoaderFor(String
>>>>>>>>>> classFileName) {
>>>>>>>>>>   105         if (restrictToBoot) return null; // only 
>>>>>>>>>> bootmodules
>>>>>>>>>>   106         return ClassLoaders.systemClassLoader;
>>>>>>>>>>   107     }
>>>>>>>>>>
>>>>>>>>>> I'm not clear the intent here. If it is to return a loader for
>>>>>>>>>> which
>>>>>>>>>> loadClass could be invoked then you can always just return the
>>>>>>>>>> system
>>>>>>>>>> loader - or just Class.forName. If it is meant to the return the
>>>>>>>>>> expected defining loader then it isn't doing that as the
>>>>>>>>>> extensions
>>>>>>>>>> loader is not allowed for.
>>>>>>>>>
>>>>>>>>> The intent is to return the class loader that will be passed to
>>>>>>>>> Class.forName( ). I've been fiddling & experimenting with this
>>>>>>>>> test over 3 different platforms while trying to minimize the
>>>>>>>>> differences - so that was my attempt at having a good place to
>>>>>>>>> experiment with different strategy for loading classes.
>>>>>>>>>
>>>>>>>>>> Similarly for:
>>>>>>>>>>
>>>>>>>>>>   128         static ClassLoader getFor(String classFileName) {
>>>>>>>>>>   129             return systemClassLoader;
>>>>>>>>>>   130         }
>>>>>>>>>
>>>>>>>>> Oh - that's my mistake. In fact ClassLoader getClassLoaderFor(..)
>>>>>>>>> was supposed to simply return ClassLoaders.getFor(...);
>>>>>>>>> and all the code should be in ClassLoaders.getFor - my bad.
>>>>>>>>>
>>>>>>>>>> Minor nit - In:
>>>>>>>>>>
>>>>>>>>>> 135 System.err.println("Unexpected loader for
>>>>>>>>>> "+c+":
>>>>>>>>>> "+c.getClassLoader());
>>>>>>>>>>
>>>>>>>>>> c.getClassLoader() can be replaced by cl. Also put spaces around
>>>>>>>>>> the +
>>>>>>>>>> operator.
>>>>>>>>>
>>>>>>>>> Good catch.
>>>>>>>>>
>>>>>>>>> Thanks a lot David! Have a good night! (that's quite late - isn't
>>>>>>>>> it?)
>>>>>>>>>
>>>>>>>>> -- daniel
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> David
>>>>>>>>>> (signing off for the night)
>>>>>>>>>>
>>>>>>>>>>> Thanks for your question, it triggered me into looking deeper
>>>>>>>>>>> into what was happening :-)
>>>>>>>>>>>
>>>>>>>>>>> best regards,
>>>>>>>>>>>
>>>>>>>>>>> -- daniel
>>>>>>>>>>>
>>>>>>>>>>> On 04/12/14 10:05, Daniel Fuchs wrote:
>>>>>>>>>>>>>> The differences between 8 & 9 are limited to:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     - ClassLoader:
>>>>>>>>>>>>>>          - on 8 we use 'null' (BCL)
>>>>>>>>>>>>>>          - on 9 we use the system class loader.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I haven't seen anything in JEP 220, regarding modules, that
>>>>>>>>>>>>> indicates
>>>>>>>>>>>>> that classes currently loaded  by the boot-loader will now be
>>>>>>>>>>>>> loaded
>>>>>>>>>>>>> by the system classloader ???
>>>>>>>>>>>>
>>>>>>>>>>>> In [1] towards the end:
>>>>>>>>>>>>
>>>>>>>>>>>> [1] http://openjdk.java.net/jeps/220
>>>>>>>>>>>>
>>>>>>>>>>>> "The defining class loader of the types in some existing
>>>>>>>>>>>> packages
>>>>>>>>>>>>   will change. Existing code that makes assumptions about the
>>>>>>>>>>>> class
>>>>>>>>>>>>   loaders of these types might not work correctly."
>>>>>>>>>>>>   (then there is a list of specific changes).
>>>>>>>>>>>>
>>>>>>>>>>>> This test looks up all class names in the image files and
>>>>>>>>>>>> attempt
>>>>>>>>>>>> to load the corresponding class. But as indicated in [1]
>>>>>>>>>>>> some of these classes are now in the Boot CL, some in the
>>>>>>>>>>>> Extension CL, and some in the Application CL.
>>>>>>>>>>>>
>>>>>>>>>>>> So the test uses the System CL to load each class - which
>>>>>>>>>>>> ensures
>>>>>>>>>>>> that the loading will be delegated to the appropriate
>>>>>>>>>>>> ClassLoader.
>>>>>>>>>>>>
>>>>>>>>>>>> best regards,
>>>>>>>>>>>>
>>>>>>>>>>>> -- daniel
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>



From daniel.fuchs at oracle.com  Tue Dec 16 10:36:42 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 16 Dec 2014 11:36:42 +0100
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <54900AC3.4060208@oracle.com>
References: <547F9302.3060309@oracle.com>	<547FD6F2.5060400@oracle.com>	<548023D0.4020702@oracle.com>	<548047C3.8000400@oracle.com>	<54804E4B.2070908@oracle.com>	<5480529F.1020902@oracle.com>	<54805B5D.5020504@oracle.com>	<54809627.8070103@oracle.com>	<5480EFE8.3090809@oracle.com>
	<5482105D.40005@oracle.com>	<5482D77C.9030100@gmail.com>
	<5482DE1F.5070906@oracle.com>	<548F1EF4.1040007@oracle.com>
	<548FC137.1080209@oracle.com> <54900AC3.4060208@oracle.com>
Message-ID: <54900B3A.7070703@oracle.com>

On 16/12/14 11:34, Daniel Fuchs wrote:
> Here is a new version where I have removed all the 'ClassLoaders' stuff.
> After all
> it was not instrumental to the test. Is that good to go?

Forgot the link:

http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.03/

sorry for the noise.

-- daniel



From pavel.rappo at oracle.com  Tue Dec 16 11:35:17 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 16 Dec 2014 11:35:17 +0000
Subject: RFR JDK-8066867: Add InputStream transferTo to transfer content
	to an OutputStream
In-Reply-To: <1C8225A1-E4E6-4C40-9F0D-75EF5A181CD0@reini.net>
References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com>
	<ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>
	<54871F21.10309@oracle.com>
	<F1194DB1-429D-4DD2-B9F0-638D3FDCCCFC@oracle.com>
	<1C8225A1-E4E6-4C40-9F0D-75EF5A181CD0@reini.net>
Message-ID: <8BD65235-B55C-4342-8D4E-1D9F91415C73@oracle.com>

The latest webrev summing up all what we've talked so far:

	http://cr.openjdk.java.net/~prappo/8066867/webrev.02/

-Pavel

> On 15 Dec 2014, at 21:39, Patrick Reinhart <patrick at reini.net> wrote:
> 
> 
> Have there been any further review being done jet?
> 
>> Good catch, guys!
>> 
>>> ...the method names are inconsistent (the methods in lower case with embedded underscores)
>> 
>> Fixed. Updated webrev: http://cr.openjdk.java.net/~prappo/8066867/webrev.01/
> 
> -Patrick



From david.holmes at oracle.com  Tue Dec 16 12:01:11 2014
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 Dec 2014 22:01:11 +1000
Subject: [9 + 8u] RFR - 8066612: Add a test that will call
	getDeclaredFields() on all classes and try to set them accessible.
In-Reply-To: <54900B3A.7070703@oracle.com>
References: <547F9302.3060309@oracle.com>	<547FD6F2.5060400@oracle.com>	<548023D0.4020702@oracle.com>	<548047C3.8000400@oracle.com>	<54804E4B.2070908@oracle.com>	<5480529F.1020902@oracle.com>	<54805B5D.5020504@oracle.com>	<54809627.8070103@oracle.com>	<5480EFE8.3090809@oracle.com>
	<5482105D.40005@oracle.com>	<5482D77C.9030100@gmail.com>
	<5482DE1F.5070906@oracle.com>	<548F1EF4.1040007@oracle.com>
	<548FC137.1080209@oracle.com> <54900AC3.4060208@oracle.com>
	<54900B3A.7070703@oracle.com>
Message-ID: <54901F07.5010301@oracle.com>

Hi Daniel,

Thumbs up from me!

Thanks,
David

On 16/12/2014 8:36 PM, Daniel Fuchs wrote:
> On 16/12/14 11:34, Daniel Fuchs wrote:
>> Here is a new version where I have removed all the 'ClassLoaders' stuff.
>> After all
>> it was not instrumental to the test. Is that good to go?
>
> Forgot the link:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8066612/webrev-jdk9.03/
>
> sorry for the noise.
>
> -- daniel
>


From chris.hegarty at oracle.com  Tue Dec 16 12:40:22 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 16 Dec 2014 12:40:22 +0000
Subject: RFR JDK-8066867: Add InputStream transferTo to transfer content
	to an OutputStream
In-Reply-To: <8BD65235-B55C-4342-8D4E-1D9F91415C73@oracle.com>
References: <1F65F028-5F02-4608-9221-EF10498CF8A7@oracle.com>
	<ED8C6343-95B8-4633-8991-4785A8BE9AA6@oracle.com>
	<54871F21.10309@oracle.com>
	<F1194DB1-429D-4DD2-B9F0-638D3FDCCCFC@oracle.com>
	<1C8225A1-E4E6-4C40-9F0D-75EF5A181CD0@reini.net>
	<8BD65235-B55C-4342-8D4E-1D9F91415C73@oracle.com>
Message-ID: <A2E165A7-FBE1-44AD-8927-085B29A8C2E2@oracle.com>


On 16 Dec 2014, at 11:35, Pavel Rappo <pavel.rappo at oracle.com> wrote:

> The latest webrev summing up all what we've talked so far:
> 
> 	http://cr.openjdk.java.net/~prappo/8066867/webrev.02/

This looks good to me. Reviewed.

Just a note on the attribution. I think it should include at least the following:

  Contributed-by: Alan Bateman <alan.bateman at oracle.com>, Chris Hegarty <chris.hegarty at oracle.com>, Patrick Reinhart <patrick at reini.net>, Pavel Rappo <pavel.rappo at oracle.com>

Now this is complete ( modulo any additional review comments ), I think we can move on to Readable.transferTo, and other such goodies.  I think we should follow the same model, focus on a single new API, or small logical group, and try to discuss/review/debate it on it?s own merit.

Note: I filed https://bugs.openjdk.java.net/browse/JDK-8067661 to track adding more efficient transferTo implementations to other input streams.

-Chris.


> -Pavel
> 
>> On 15 Dec 2014, at 21:39, Patrick Reinhart <patrick at reini.net> wrote:
>> 
>> 
>> Have there been any further review being done jet?
>> 
>>> Good catch, guys!
>>> 
>>>> ...the method names are inconsistent (the methods in lower case with embedded underscores)
>>> 
>>> Fixed. Updated webrev: http://cr.openjdk.java.net/~prappo/8066867/webrev.01/
>> 
>> -Patrick
> 



From andreas.lundblad at oracle.com  Tue Dec 16 12:55:09 2014
From: andreas.lundblad at oracle.com (Andreas Lundblad)
Date: Tue, 16 Dec 2014 13:55:09 +0100
Subject: Documentation of methods in java.lang.Number
Message-ID: <20141216125508.GC4911@e6430>

I've noticed that the documentation of Number.longValue says:

> Returns the value of the specified number as a long, which may involve rounding or truncation.

BigInteger and BigDecimal does not seem to honor this contract since they implement this method by masking out the lower bits of the number (and I've found no definition of "rounding" or "truncation" that encompass this behavuor). The documentation of these classes even state that "[...] this conversion can lose information about the overall magnitude of the BigInteger value as well as return a result with the opposite sign."

I suggest the documentation of Number.byteValue/shortValue/intValue/longValue should be updated to give room for this type of implementation.

(I filed an issue on this and got a confirmation email with the following link: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7000825 Since then this page has gone missing. Where did the bug report go, and why didn't I get any notification about the removal?)

-- Andreas Lundblad


From sean.coffey at oracle.com  Tue Dec 16 14:26:59 2014
From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=)
Date: Tue, 16 Dec 2014 14:26:59 +0000
Subject: Documentation of methods in java.lang.Number
In-Reply-To: <20141216125508.GC4911@e6430>
References: <20141216125508.GC4911@e6430>
Message-ID: <54904133.3040402@oracle.com>

Andreas,

this didn't get attention in the past. You can now find your report at 
https://bugs.openjdk.java.net/browse/JDK-8067669
I'll leave it up to maths engineers to determine if the Number API needs 
improving.

regards,
Sean.

On 16/12/2014 12:55, Andreas Lundblad wrote:
> I've noticed that the documentation of Number.longValue says:
>
>> Returns the value of the specified number as a long, which may involve rounding or truncation.
> BigInteger and BigDecimal does not seem to honor this contract since they implement this method by masking out the lower bits of the number (and I've found no definition of "rounding" or "truncation" that encompass this behavuor). The documentation of these classes even state that "[...] this conversion can lose information about the overall magnitude of the BigInteger value as well as return a result with the opposite sign."
>
> I suggest the documentation of Number.byteValue/shortValue/intValue/longValue should be updated to give room for this type of implementation.
>
> (I filed an issue on this and got a confirmation email with the following link: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7000825 Since then this page has gone missing. Where did the bug report go, and why didn't I get any notification about the removal?)
>
> -- Andreas Lundblad



From roger.riggs at oracle.com  Tue Dec 16 14:58:05 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Tue, 16 Dec 2014 09:58:05 -0500
Subject: Java implementation of Alpha-numeric comparator
In-Reply-To: <548FF406.2060108@oracle.com>
References: <548EBD94.1070804@oracle.com>
	<548F6145.1060207@oracle.com>	<548F7120.9040400@univ-mlv.fr>
	<548FE9BB.7040005@oracle.com>	<548FEC1C.2070300@univ-mlv.fr>
	<548FF406.2060108@oracle.com>
Message-ID: <5490487D.5060402@oracle.com>

Hi Ivan,

In which package/class do you propose to add the API to get the comparator?

In java.time, comparators are returned from static methods in an interface.
This allows lambda to be used for the implementation.
For example, ChronoZonedDateTime.timeLineOrder 
<https://docs.oracle.com/javase/8/docs/api/java/time/chrono/ChronoZonedDateTime.html#timeLineOrder-->()[1]

For example a static method could be added to CharSequence:
public static int Comparator<CharSequence> alphaNumericComparator() ...

In use it would be CharSequence.alphaNumericComparator().compare("012", 
"234");

2)  Should there be any provision for number strings internal to the 
string with leading zeros.
   Should "abc-0123-def" be equal to "abc-123-def"?

Roger



[1] 
https://docs.oracle.com/javase/8/docs/api/java/time/chrono/ChronoZonedDateTime.html#timeLineOrder--

On 12/16/2014 3:57 AM, Ivan Gerasimov wrote:
> Got it, thanks!
>
> Please find the updated webrev at the same location:
> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/1/webrev/
>
> Sincerely yours,
> Ivan
>
> On 16.12.2014 11:23, Remi Forax wrote:
>>
>> On 12/16/2014 09:13 AM, Ivan Gerasimov wrote:
>>> Thanks Remi for the comments!
>>>
>>> As you and Roger suggested I only left a CharSequence variant of the 
>>> comparator.
>>>
>>> I also removed the custom Comparator<Character> altogether for now, 
>>> for the sake of simplicity.
>>> I guess for the purpose of a sample Character.compare(ch1, ch2) 
>>> should be good enough.
>>>
>>> Here's the updated webrev:
>>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/1/webrev/
>>>
>>> I'm not certain, why the comparator should be serializable.
>>> Could you please elaborate on this?
>>
>> Yes, all public comparators in the JDK are serializable because 
>> otherwise people will not be able to serialize collections like 
>> TreeSet or ConcurrentSkipListSet that implement Serializable and take 
>> a comparator as an optional argument.
>>
>>
>>>
>>> Sincerely yours,
>>> Ivan
>>
>> cheers,
>> R?mi
>>
>>>
>>> On 16.12.2014 2:39, Remi Forax wrote:
>>>> Hi Ivan, hi Roger,
>>>>
>>>> Roger, the API already exists it's the interface Comparator.
>>>>
>>>> I agree with Roger that a comparator that use a CharSequence is 
>>>> better that the one that use a char array.
>>>>
>>>> The thing that worry me is the Comparator<Character> taken as 
>>>> parameter, it means that
>>>> each time the method compare() is called on this comparator, the 
>>>> two arguments are boxed.
>>>>
>>>> Minor comment, to be included, I think that these comparators 
>>>> should be serializable
>>>> and in my opinion the best way to do that is to use a lambda 
>>>> instead of a class.
>>>>
>>>> R?mi
>>>>
>>>> On 12/15/2014 11:31 PM, roger riggs wrote:
>>>>> Hi Ivan,
>>>>>
>>>>> It does seem like a useful function, though I would have started 
>>>>> with the API,
>>>>> not the implementation.
>>>>>
>>>>> Can it apply to CharSequence not only String and maybe skip the
>>>>> separate char[] version, a char[] array can be wrapped to become a 
>>>>> CharSequence via CharBuffer.
>>>>> Or a via a new static method to define a CharSequence from a char 
>>>>> array.
>>>>>
>>>>> $.02, Roger
>>>>>
>>>>> On 12/15/2014 5:53 AM, Ivan Gerasimov wrote:
>>>>>> Hello everyone!
>>>>>>
>>>>>> In certain situations the preferred way of sorting strings is a 
>>>>>> combination of char-comparing sorting with numeric sorting, where 
>>>>>> applicable.
>>>>>> List of strings sorted this way often look more natural to the 
>>>>>> human eyes:
>>>>>> { "alpha",
>>>>>>   "java1",
>>>>>>   "java2",
>>>>>>   "java10",
>>>>>>   "zero" }
>>>>>>
>>>>>> Here's presented a sample implementation of the comparator, which 
>>>>>> supports this way of sorting.
>>>>>> I placed it under src/sample directory.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/0/webrev/
>>>>>>
>>>>>>
>>>>>> MSDN provides the function StrCmpLogicalW(), which can be used 
>>>>>> for similar sort order.
>>>>>> http://msdn.microsoft.com/en-us/library/windows/desktop/bb759947%28v=vs.85%29.aspx 
>>>>>>
>>>>>>
>>>>>> The differences are:
>>>>>>  - case-sensitivity (StrCmpLogicalW is case-insensitive);
>>>>>>  - treating leading zeroes;
>>>>>>  - more accurate handling of strings with big numbers, which 
>>>>>> cannot be converted to int/long.
>>>>>>
>>>>>> I guess this comparator may become particularly useful when we'll 
>>>>>> have 'java10' and update releases/build numbers > 99 in the lists :)
>>>>>>
>>>>>> I want to ask the community about how useful this comparator may 
>>>>>> be to you?
>>>>>>
>>>>>> Sincerely yours,
>>>>>> Ivan
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>



From roger.riggs at oracle.com  Tue Dec 16 15:13:28 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Tue, 16 Dec 2014 10:13:28 -0500
Subject: Java implementation of Alpha-numeric comparator
In-Reply-To: <5490487D.5060402@oracle.com>
References: <548EBD94.1070804@oracle.com>	<548F6145.1060207@oracle.com>	<548F7120.9040400@univ-mlv.fr>	<548FE9BB.7040005@oracle.com>	<548FEC1C.2070300@univ-mlv.fr>	<548FF406.2060108@oracle.com>
	<5490487D.5060402@oracle.com>
Message-ID: <54904C18.3050008@oracle.com>

Corrected the internal string example below to reflect the case intended.

On 12/16/2014 9:58 AM, roger riggs wrote:
> Hi Ivan,
>
> In which package/class do you propose to add the API to get the 
> comparator?
>
> In java.time, comparators are returned from static methods in an 
> interface.
> This allows lambda to be used for the implementation.
> For example, ChronoZonedDateTime.timeLineOrder 
> <https://docs.oracle.com/javase/8/docs/api/java/time/chrono/ChronoZonedDateTime.html#timeLineOrder-->()[1]
>
> For example a static method could be added to CharSequence:
> public static int Comparator<CharSequence> alphaNumericComparator() ...
>
> In use it would be 
> CharSequence.alphaNumericComparator().compare("012", "234");
>
> 2)  Should there be any provision for number strings internal to the 
> string with leading zeros.
>   Should "123-abc-123-def-789" be equal to "0123-abc-0123-def-0789"?
>
> Roger
>
>
>
> [1] 
> https://docs.oracle.com/javase/8/docs/api/java/time/chrono/ChronoZonedDateTime.html#timeLineOrder--
>
> On 12/16/2014 3:57 AM, Ivan Gerasimov wrote:
>> Got it, thanks!
>>
>> Please find the updated webrev at the same location:
>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/1/webrev/
>>
>> Sincerely yours,
>> Ivan
>>
>> On 16.12.2014 11:23, Remi Forax wrote:
>>>
>>> On 12/16/2014 09:13 AM, Ivan Gerasimov wrote:
>>>> Thanks Remi for the comments!
>>>>
>>>> As you and Roger suggested I only left a CharSequence variant of 
>>>> the comparator.
>>>>
>>>> I also removed the custom Comparator<Character> altogether for now, 
>>>> for the sake of simplicity.
>>>> I guess for the purpose of a sample Character.compare(ch1, ch2) 
>>>> should be good enough.
>>>>
>>>> Here's the updated webrev:
>>>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/1/webrev/
>>>>
>>>> I'm not certain, why the comparator should be serializable.
>>>> Could you please elaborate on this?
>>>
>>> Yes, all public comparators in the JDK are serializable because 
>>> otherwise people will not be able to serialize collections like 
>>> TreeSet or ConcurrentSkipListSet that implement Serializable and 
>>> take a comparator as an optional argument.
>>>
>>>
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>
>>> cheers,
>>> R?mi
>>>
>>>>
>>>> On 16.12.2014 2:39, Remi Forax wrote:
>>>>> Hi Ivan, hi Roger,
>>>>>
>>>>> Roger, the API already exists it's the interface Comparator.
>>>>>
>>>>> I agree with Roger that a comparator that use a CharSequence is 
>>>>> better that the one that use a char array.
>>>>>
>>>>> The thing that worry me is the Comparator<Character> taken as 
>>>>> parameter, it means that
>>>>> each time the method compare() is called on this comparator, the 
>>>>> two arguments are boxed.
>>>>>
>>>>> Minor comment, to be included, I think that these comparators 
>>>>> should be serializable
>>>>> and in my opinion the best way to do that is to use a lambda 
>>>>> instead of a class.
>>>>>
>>>>> R?mi
>>>>>
>>>>> On 12/15/2014 11:31 PM, roger riggs wrote:
>>>>>> Hi Ivan,
>>>>>>
>>>>>> It does seem like a useful function, though I would have started 
>>>>>> with the API,
>>>>>> not the implementation.
>>>>>>
>>>>>> Can it apply to CharSequence not only String and maybe skip the
>>>>>> separate char[] version, a char[] array can be wrapped to become 
>>>>>> a CharSequence via CharBuffer.
>>>>>> Or a via a new static method to define a CharSequence from a char 
>>>>>> array.
>>>>>>
>>>>>> $.02, Roger
>>>>>>
>>>>>> On 12/15/2014 5:53 AM, Ivan Gerasimov wrote:
>>>>>>> Hello everyone!
>>>>>>>
>>>>>>> In certain situations the preferred way of sorting strings is a 
>>>>>>> combination of char-comparing sorting with numeric sorting, 
>>>>>>> where applicable.
>>>>>>> List of strings sorted this way often look more natural to the 
>>>>>>> human eyes:
>>>>>>> { "alpha",
>>>>>>>   "java1",
>>>>>>>   "java2",
>>>>>>>   "java10",
>>>>>>>   "zero" }
>>>>>>>
>>>>>>> Here's presented a sample implementation of the comparator, 
>>>>>>> which supports this way of sorting.
>>>>>>> I placed it under src/sample directory.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/0/webrev/
>>>>>>>
>>>>>>>
>>>>>>> MSDN provides the function StrCmpLogicalW(), which can be used 
>>>>>>> for similar sort order.
>>>>>>> http://msdn.microsoft.com/en-us/library/windows/desktop/bb759947%28v=vs.85%29.aspx 
>>>>>>>
>>>>>>>
>>>>>>> The differences are:
>>>>>>>  - case-sensitivity (StrCmpLogicalW is case-insensitive);
>>>>>>>  - treating leading zeroes;
>>>>>>>  - more accurate handling of strings with big numbers, which 
>>>>>>> cannot be converted to int/long.
>>>>>>>
>>>>>>> I guess this comparator may become particularly useful when 
>>>>>>> we'll have 'java10' and update releases/build numbers > 99 in 
>>>>>>> the lists :)
>>>>>>>
>>>>>>> I want to ask the community about how useful this comparator may 
>>>>>>> be to you?
>>>>>>>
>>>>>>> Sincerely yours,
>>>>>>> Ivan
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>



From jaroslav.bachorik at oracle.com  Tue Dec 16 16:41:50 2014
From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik)
Date: Tue, 16 Dec 2014 17:41:50 +0100
Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find
	app's Java pid
In-Reply-To: <5490564F.2010907@oracle.com>
References: <5490564F.2010907@oracle.com>
Message-ID: <549060CE.5080505@oracle.com>

Hi Katja,

This request should probably go to core-libs as well.

Other than that I have just a few nits:

test/java/util/logging/TestLoggerWeakRefLeak.java

L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ?
L127: // in LogManager.loggers that *arebeing* properly managed -> *are 
being*

callLoggerAndCount() and callAnonymousLoggerAndCount() are using the 
'count' variable to always return 100. Could they be made to return a 
constant instead?


Cheers,

-JB-


On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote:
> Hi,
>
> Could I please have a review of this fix.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-6977426
> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/
>
> java/util/logging/LoggerWeakRefLeak.sh and
> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and rewritten in
> java. sun/tools/common/CommonTests.sh is removed because it doesn't test
> the product but sun/tool/common library functionality.
>
> Thanks,
> Katja



From stuart.marks at oracle.com  Tue Dec 16 17:40:51 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 16 Dec 2014 09:40:51 -0800
Subject: RFR(s): 8035117: TEST_BUG:
	java/rmi/server/RemoteObject/notExtending/NotExtending.java
	can fail with timeout
In-Reply-To: <548B4A9B.5020406@oracle.com>
References: <548B4A9B.5020406@oracle.com>
Message-ID: <54906EA3.6070400@oracle.com>

Hi, any reviewers for this changeset?

Thanks,

s'marks

On 12/12/14 12:05 PM, Stuart Marks wrote:
> Hi all,
>
> Please review this small fix and cleanup to this test. The old version would
> force garbage collection of an unreferenced RMI object by allocating lots and
> lots of memory until OOME is received, which takes a long time and could cause a
> timeout. The better approach is simply to unexport the object.
>
> I also did additional cleanups, such as not leaking the reference to 'this' from
> within the constructor, making comments and messages more concise, etc.
>
> Webrev:
>
>      http://cr.openjdk.java.net/~smarks/reviews/8035117/webrev.0/
>
> Bug:
>
>      https://bugs.openjdk.java.net/browse/JDK-8035117
>
> Thanks,
>
> s'marks


From lance.andersen at oracle.com  Tue Dec 16 17:42:48 2014
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 16 Dec 2014 12:42:48 -0500
Subject: RFR(s): 8035117: TEST_BUG:
	java/rmi/server/RemoteObject/notExtending/NotExtending.java can
	fail with timeout
In-Reply-To: <54906EA3.6070400@oracle.com>
References: <548B4A9B.5020406@oracle.com> <54906EA3.6070400@oracle.com>
Message-ID: <90C6DD9D-E5E1-49D1-A367-E12999DA7902@oracle.com>

Looks OK stuart.  Another test I looked at last week but forgot to reply

On Dec 16, 2014, at 12:40 PM, Stuart Marks <stuart.marks at oracle.com> wrote:

> Hi, any reviewers for this changeset?
> 
> Thanks,
> 
> s'marks
> 
> On 12/12/14 12:05 PM, Stuart Marks wrote:
>> Hi all,
>> 
>> Please review this small fix and cleanup to this test. The old version would
>> force garbage collection of an unreferenced RMI object by allocating lots and
>> lots of memory until OOME is received, which takes a long time and could cause a
>> timeout. The better approach is simply to unexport the object.
>> 
>> I also did additional cleanups, such as not leaking the reference to 'this' from
>> within the constructor, making comments and messages more concise, etc.
>> 
>> Webrev:
>> 
>>     http://cr.openjdk.java.net/~smarks/reviews/8035117/webrev.0/
>> 
>> Bug:
>> 
>>     https://bugs.openjdk.java.net/browse/JDK-8035117
>> 
>> Thanks,
>> 
>> s'marks



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





From ivan.gerasimov at oracle.com  Tue Dec 16 18:44:35 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 16 Dec 2014 21:44:35 +0300
Subject: Java implementation of Alpha-numeric comparator
In-Reply-To: <5490487D.5060402@oracle.com>
References: <548EBD94.1070804@oracle.com>	<548F6145.1060207@oracle.com>	<548F7120.9040400@univ-mlv.fr>	<548FE9BB.7040005@oracle.com>	<548FEC1C.2070300@univ-mlv.fr>	<548FF406.2060108@oracle.com>
	<5490487D.5060402@oracle.com>
Message-ID: <54907D93.7060706@oracle.com>


On 16.12.2014 17:58, roger riggs wrote:
> Hi Ivan,
>
> In which package/class do you propose to add the API to get the 
> comparator?
>
I was thinking of java.text package, though I don't see a specific class 
in which the static method could be naturally included.
This kind of Comparator doesn't seem to be common enough to include in 
such a base interface as CharSequence.

> In java.time, comparators are returned from static methods in an 
> interface.
> This allows lambda to be used for the implementation.
> For example, ChronoZonedDateTime.timeLineOrder 
> <https://docs.oracle.com/javase/8/docs/api/java/time/chrono/ChronoZonedDateTime.html#timeLineOrder-->()[1]
>
> For example a static method could be added to CharSequence:
> public static int Comparator<CharSequence> alphaNumericComparator() ...
>
> In use it would be 
> CharSequence.alphaNumericComparator().compare("012", "234");
>
> 2)  Should there be any provision for number strings internal to the 
> string with leading zeros.
>   Should "abc-0123-def" be equal to "abc-123-def"?
>
The strings will be ordered as:

abc-122-def
abc-0122-def
abc-123-def
abc-0123-def
abc-00123-def
abc-0000123-def
abc-124-def

I.e. the strings with the same numeric value will be grouped together, 
but the strings with more leading zeros will be put in the order further.
To my eyes the strings with more leading zeros look bigger, that's why I 
did it this way :)

By the way, the Microsoft's StrCmpLogicalW() does it in the opposite 
direction, i.e. strings with more leading zeros come earlier.
If people find it useful, we can make it configurable.

Sincerely yours,
Ivan


> Roger
>
>
>
> [1] 
> https://docs.oracle.com/javase/8/docs/api/java/time/chrono/ChronoZonedDateTime.html#timeLineOrder--
>
> On 12/16/2014 3:57 AM, Ivan Gerasimov wrote:
>> Got it, thanks!
>>
>> Please find the updated webrev at the same location:
>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/1/webrev/
>>
>> Sincerely yours,
>> Ivan
>>
>> On 16.12.2014 11:23, Remi Forax wrote:
>>>
>>> On 12/16/2014 09:13 AM, Ivan Gerasimov wrote:
>>>> Thanks Remi for the comments!
>>>>
>>>> As you and Roger suggested I only left a CharSequence variant of 
>>>> the comparator.
>>>>
>>>> I also removed the custom Comparator<Character> altogether for now, 
>>>> for the sake of simplicity.
>>>> I guess for the purpose of a sample Character.compare(ch1, ch2) 
>>>> should be good enough.
>>>>
>>>> Here's the updated webrev:
>>>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/1/webrev/
>>>>
>>>> I'm not certain, why the comparator should be serializable.
>>>> Could you please elaborate on this?
>>>
>>> Yes, all public comparators in the JDK are serializable because 
>>> otherwise people will not be able to serialize collections like 
>>> TreeSet or ConcurrentSkipListSet that implement Serializable and 
>>> take a comparator as an optional argument.
>>>
>>>
>>>>
>>>> Sincerely yours,
>>>> Ivan
>>>
>>> cheers,
>>> R?mi
>>>
>>>>
>>>> On 16.12.2014 2:39, Remi Forax wrote:
>>>>> Hi Ivan, hi Roger,
>>>>>
>>>>> Roger, the API already exists it's the interface Comparator.
>>>>>
>>>>> I agree with Roger that a comparator that use a CharSequence is 
>>>>> better that the one that use a char array.
>>>>>
>>>>> The thing that worry me is the Comparator<Character> taken as 
>>>>> parameter, it means that
>>>>> each time the method compare() is called on this comparator, the 
>>>>> two arguments are boxed.
>>>>>
>>>>> Minor comment, to be included, I think that these comparators 
>>>>> should be serializable
>>>>> and in my opinion the best way to do that is to use a lambda 
>>>>> instead of a class.
>>>>>
>>>>> R?mi
>>>>>
>>>>> On 12/15/2014 11:31 PM, roger riggs wrote:
>>>>>> Hi Ivan,
>>>>>>
>>>>>> It does seem like a useful function, though I would have started 
>>>>>> with the API,
>>>>>> not the implementation.
>>>>>>
>>>>>> Can it apply to CharSequence not only String and maybe skip the
>>>>>> separate char[] version, a char[] array can be wrapped to become 
>>>>>> a CharSequence via CharBuffer.
>>>>>> Or a via a new static method to define a CharSequence from a char 
>>>>>> array.
>>>>>>
>>>>>> $.02, Roger
>>>>>>
>>>>>> On 12/15/2014 5:53 AM, Ivan Gerasimov wrote:
>>>>>>> Hello everyone!
>>>>>>>
>>>>>>> In certain situations the preferred way of sorting strings is a 
>>>>>>> combination of char-comparing sorting with numeric sorting, 
>>>>>>> where applicable.
>>>>>>> List of strings sorted this way often look more natural to the 
>>>>>>> human eyes:
>>>>>>> { "alpha",
>>>>>>>   "java1",
>>>>>>>   "java2",
>>>>>>>   "java10",
>>>>>>>   "zero" }
>>>>>>>
>>>>>>> Here's presented a sample implementation of the comparator, 
>>>>>>> which supports this way of sorting.
>>>>>>> I placed it under src/sample directory.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/0/webrev/
>>>>>>>
>>>>>>>
>>>>>>> MSDN provides the function StrCmpLogicalW(), which can be used 
>>>>>>> for similar sort order.
>>>>>>> http://msdn.microsoft.com/en-us/library/windows/desktop/bb759947%28v=vs.85%29.aspx 
>>>>>>>
>>>>>>>
>>>>>>> The differences are:
>>>>>>>  - case-sensitivity (StrCmpLogicalW is case-insensitive);
>>>>>>>  - treating leading zeroes;
>>>>>>>  - more accurate handling of strings with big numbers, which 
>>>>>>> cannot be converted to int/long.
>>>>>>>
>>>>>>> I guess this comparator may become particularly useful when 
>>>>>>> we'll have 'java10' and update releases/build numbers > 99 in 
>>>>>>> the lists :)
>>>>>>>
>>>>>>> I want to ask the community about how useful this comparator may 
>>>>>>> be to you?
>>>>>>>
>>>>>>> Sincerely yours,
>>>>>>> Ivan
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>



From xueming.shen at oracle.com  Tue Dec 16 19:04:02 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 16 Dec 2014 11:04:02 -0800
Subject: Java implementation of Alpha-numeric comparator
In-Reply-To: <5490487D.5060402@oracle.com>
References: <548EBD94.1070804@oracle.com>	<548F6145.1060207@oracle.com>	<548F7120.9040400@univ-mlv.fr>	<548FE9BB.7040005@oracle.com>	<548FEC1C.2070300@univ-mlv.fr>	<548FF406.2060108@oracle.com>
	<5490487D.5060402@oracle.com>
Message-ID: <54908222.7080907@oracle.com>

On 12/16/2014 06:58 AM, roger riggs wrote:
> Hi Ivan,
>
> In which package/class do you propose to add the API to get the comparator?
>
> In java.time, comparators are returned from static methods in an interface.
> This allows lambda to be used for the implementation.
> For example, ChronoZonedDateTime.timeLineOrder <https://docs.oracle.com/javase/8/docs/api/java/time/chrono/ChronoZonedDateTime.html#timeLineOrder-->()[1]
>
> For example a static method could be added to CharSequence:
> public static int Comparator<CharSequence> alphaNumericComparator() ...
>
> In use it would be CharSequence.alphaNumericComparator().compare("012", "234");
>

This is more like a special case of j.t.Collator. I'm not sure it's a good idea to put this "special"
comparator into CharSequence, without careful planning. I will assume there are more useful
utility comparators people would like to see here. To use the original example, while the
it's good to have this comparator to compare "jdk 10" and "jdk9", how about "jdk-10" and
"jdk 9"? Yes, it is more like a collator:-)

-Sherman


From xueming.shen at oracle.com  Tue Dec 16 19:32:39 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 16 Dec 2014 11:32:39 -0800
Subject: Java implementation of Alpha-numeric comparator
In-Reply-To: <54907D93.7060706@oracle.com>
References: <548EBD94.1070804@oracle.com>	<548F6145.1060207@oracle.com>	<548F7120.9040400@univ-mlv.fr>	<548FE9BB.7040005@oracle.com>	<548FEC1C.2070300@univ-mlv.fr>	<548FF406.2060108@oracle.com>	<5490487D.5060402@oracle.com>
	<54907D93.7060706@oracle.com>
Message-ID: <549088D7.7040102@oracle.com>

On 12/16/2014 10:44 AM, Ivan Gerasimov wrote:
>
> On 16.12.2014 17:58, roger riggs wrote:
>> Hi Ivan,
>>
>> In which package/class do you propose to add the API to get the comparator?
>>
> I was thinking of java.text package, though I don't see a specific class in which the static method could be naturally included.
> This kind of Comparator doesn't seem to be common enough to include in such a base interface as CharSequence.
>
>> In java.time, comparators are returned from static methods in an interface.
>> This allows lambda to be used for the implementation.
>> For example, ChronoZonedDateTime.timeLineOrder <https://docs.oracle.com/javase/8/docs/api/java/time/chrono/ChronoZonedDateTime.html#timeLineOrder-->()[1]
>>
>> For example a static method could be added to CharSequence:
>> public static int Comparator<CharSequence> alphaNumericComparator() ...
>>
>> In use it would be CharSequence.alphaNumericComparator().compare("012", "234");
>>
>> 2)  Should there be any provision for number strings internal to the string with leading zeros.
>>   Should "abc-0123-def" be equal to "abc-123-def"?
>>
> The strings will be ordered as:
>
> abc-122-def
> abc-0122-def
> abc-123-def
> abc-0123-def
> abc-00123-def
> abc-0000123-def
> abc-124-def
>
> I.e. the strings with the same numeric value will be grouped together, but the strings with more leading zeros will be put in the order further.
> To my eyes the strings with more leading zeros look bigger, that's why I did it this way :)
>
> By the way, the Microsoft's StrCmpLogicalW() does it in the opposite direction, i.e. strings with more leading zeros come earlier.
> If people find it useful, we can make it configurable.
>

It's always desired to have a "customizable" approach for numeric order collation:-)

-Sherman


From naoto.sato at oracle.com  Tue Dec 16 19:32:33 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 16 Dec 2014 11:32:33 -0800
Subject: Java implementation of Alpha-numeric comparator
In-Reply-To: <54908222.7080907@oracle.com>
References: <548EBD94.1070804@oracle.com>	<548F6145.1060207@oracle.com>	<548F7120.9040400@univ-mlv.fr>	<548FE9BB.7040005@oracle.com>	<548FEC1C.2070300@univ-mlv.fr>	<548FF406.2060108@oracle.com>	<5490487D.5060402@oracle.com>
	<54908222.7080907@oracle.com>
Message-ID: <549088D1.8030809@oracle.com>

j.t.Collator is basically for locale sensitive sorting, and I think this 
use case is locale independent. Aside from how significant to have it in 
the library, I am not sure j.t.Collator is the right place.

Naoto

On 12/16/14 11:04 AM, Xueming Shen wrote:
> On 12/16/2014 06:58 AM, roger riggs wrote:
>> Hi Ivan,
>>
>> In which package/class do you propose to add the API to get the
>> comparator?
>>
>> In java.time, comparators are returned from static methods in an
>> interface.
>> This allows lambda to be used for the implementation.
>> For example, ChronoZonedDateTime.timeLineOrder
>> <https://docs.oracle.com/javase/8/docs/api/java/time/chrono/ChronoZonedDateTime.html#timeLineOrder-->()[1]
>>
>>
>> For example a static method could be added to CharSequence:
>> public static int Comparator<CharSequence> alphaNumericComparator() ...
>>
>> In use it would be
>> CharSequence.alphaNumericComparator().compare("012", "234");
>>
>
> This is more like a special case of j.t.Collator. I'm not sure it's a
> good idea to put this "special"
> comparator into CharSequence, without careful planning. I will assume
> there are more useful
> utility comparators people would like to see here. To use the original
> example, while the
> it's good to have this comparator to compare "jdk 10" and "jdk9", how
> about "jdk-10" and
> "jdk 9"? Yes, it is more like a collator:-)
>
> -Sherman


From xueming.shen at oracle.com  Tue Dec 16 19:51:09 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 16 Dec 2014 11:51:09 -0800
Subject: Java implementation of Alpha-numeric comparator
In-Reply-To: <549088D1.8030809@oracle.com>
References: <548EBD94.1070804@oracle.com>	<548F6145.1060207@oracle.com>	<548F7120.9040400@univ-mlv.fr>	<548FE9BB.7040005@oracle.com>	<548FEC1C.2070300@univ-mlv.fr>	<548FF406.2060108@oracle.com>	<5490487D.5060402@oracle.com>
	<54908222.7080907@oracle.com> <549088D1.8030809@oracle.com>
Message-ID: <54908D2D.9000702@oracle.com>

Maybe it can be considered as a special "tailoring" of UCA. It's "alphabetic" + "numeric", the
"alphabetic" part got to be "locale sensitive". The "non-locale-sensitive-alphabetic-order" is
a special case of locale sensitive sorting. It might be true most people don't care about it
here, but sooner or later a "locale-based" variant will be asked :-)

-Sherman

On 12/16/2014 11:32 AM, Naoto Sato wrote:
> j.t.Collator is basically for locale sensitive sorting, and I think this use case is locale independent. Aside from how significant to have it in the library, I am not sure j.t.Collator is the right place.
>
> Naoto
>
> On 12/16/14 11:04 AM, Xueming Shen wrote:
>> On 12/16/2014 06:58 AM, roger riggs wrote:
>>> Hi Ivan,
>>>
>>> In which package/class do you propose to add the API to get the
>>> comparator?
>>>
>>> In java.time, comparators are returned from static methods in an
>>> interface.
>>> This allows lambda to be used for the implementation.
>>> For example, ChronoZonedDateTime.timeLineOrder
>>> <https://docs.oracle.com/javase/8/docs/api/java/time/chrono/ChronoZonedDateTime.html#timeLineOrder-->()[1]
>>>
>>>
>>> For example a static method could be added to CharSequence:
>>> public static int Comparator<CharSequence> alphaNumericComparator() ...
>>>
>>> In use it would be
>>> CharSequence.alphaNumericComparator().compare("012", "234");
>>>
>>
>> This is more like a special case of j.t.Collator. I'm not sure it's a
>> good idea to put this "special"
>> comparator into CharSequence, without careful planning. I will assume
>> there are more useful
>> utility comparators people would like to see here. To use the original
>> example, while the
>> it's good to have this comparator to compare "jdk 10" and "jdk9", how
>> about "jdk-10" and
>> "jdk 9"? Yes, it is more like a collator:-)
>>
>> -Sherman



From stuart.marks at oracle.com  Tue Dec 16 21:42:11 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 16 Dec 2014 13:42:11 -0800
Subject: RFR(s): 8035117: TEST_BUG:
	java/rmi/server/RemoteObject/notExtending/NotExtending.java
	can fail with timeout
In-Reply-To: <90C6DD9D-E5E1-49D1-A367-E12999DA7902@oracle.com>
References: <548B4A9B.5020406@oracle.com> <54906EA3.6070400@oracle.com>
	<90C6DD9D-E5E1-49D1-A367-E12999DA7902@oracle.com>
Message-ID: <5490A733.6090907@oracle.com>

Thanks Lance, I appreciate it. That's what I get for posting a code review on a 
Friday afternoon during the holiday season. :-)

s'marks

On 12/16/14 9:42 AM, Lance Andersen wrote:
> Looks OK stuart.  Another test I looked at last week but forgot to reply
>
> On Dec 16, 2014, at 12:40 PM, Stuart Marks <stuart.marks at oracle.com 
> <mailto:stuart.marks at oracle.com>> wrote:
>
>> Hi, any reviewers for this changeset?
>>
>> Thanks,
>>
>> s'marks
>>
>> On 12/12/14 12:05 PM, Stuart Marks wrote:
>>> Hi all,
>>>
>>> Please review this small fix and cleanup to this test. The old version would
>>> force garbage collection of an unreferenced RMI object by allocating lots and
>>> lots of memory until OOME is received, which takes a long time and could cause a
>>> timeout. The better approach is simply to unexport the object.
>>>
>>> I also did additional cleanups, such as not leaking the reference to 'this' from
>>> within the constructor, making comments and messages more concise, etc.
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~smarks/reviews/8035117/webrev.0/ 
>>> <http://cr.openjdk.java.net/%7Esmarks/reviews/8035117/webrev.0/>
>>>
>>> Bug:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8035117
>>>
>>> Thanks,
>>>
>>> s'marks
>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| 
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>



From patrick at reini.net  Tue Dec 16 22:13:46 2014
From: patrick at reini.net (Patrick Reinhart)
Date: Tue, 16 Dec 2014 23:13:46 +0100
Subject: JDK-8067661: transferTo proposal for Appendable
Message-ID: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>

Hi Chris & Pavel,

Based on the transferTo Method on the InputStream I would propose to introduce a default method on the Readable interface. In that way the method can be used for all existing implementations of Readable and still be implemented in a special way by a individual implementer.

    /**
     * Reads all characters from this readable and writes the characters to
     * the given appendable in the order that they are read. On return, this
     * readable will be at end its data.
     * <p>
     * This method may block indefinitely reading from the readable, or
     * writing to the appendable. The behavior for the case where the readable
     * and/or appendable is <i>asynchronously closed</i>, or the thread
     * interrupted during the transfer, is highly readable and appendable
     * specific, and therefore not specified.
     * <p>
     * If an I/O error occurs reading from the readable or writing to the
     * appendable, then it may do so after some characters have been read or
     * written. Consequently the readable may not be at end of its data and
     * one, or both participants may be in an inconsistent state. It is strongly
     * recommended that both readable and appendable be promptly closed 
     * if needed and an I/O error occurs.
     *
     * @param  out the appendable, non-null
     * @return the number of characters transferred
     * @throws IOException if an I/O error occurs when reading or writing
     * @throws NullPointerException if {@code out} is {@code null}
     *
     * @since 1.9
     */
    default long transferTo(Appendable out) throws IOException {
    ....
    }


-Patrick




From pavel.rappo at oracle.com  Tue Dec 16 22:54:27 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 16 Dec 2014 22:54:27 +0000
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
Message-ID: <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>

Hi Patrick, nice to hear from you again! I agree we should consider adding this
method. Unfortunately, from the spec point of view I suppose this one will
require a lot more chewing. For instance there's nothing that can be closed
either in Readable or Appendable (in general case), since neither of them is
java.io.Closeable or even java.lang.AutoCloseable. In my opinion, all mentions
of 'close' operations should go. You're fine to elaborate spec down the
hierarchy though:

    /**
     *
     ... some specifics for Readers ...
     *
     */
    @Override
    public long transferTo(Appendable out) throws IOException {
        return Readable.super.transferTo(out);
    }

But at the same time this one, you added, is crucial:

    * one, or both participants may be in an inconsistent state
    
So you give implementors the freedom to use "if anything bad happens all bets
are off".
It's also not fully clear what it means for an instance of Readable to be
"at end of its data". This have a well-defined meaning for java.io.Reader though.

-Pavel

> On 16 Dec 2014, at 22:13, Patrick Reinhart <patrick at reini.net> wrote:
> 
> Hi Chris & Pavel,
> 
> Based on the transferTo Method on the InputStream I would propose to introduce a default method on the Readable interface. In that way the method can be used for all existing implementations of Readable and still be implemented in a special way by a individual implementer.
> 
>    /**
>     * Reads all characters from this readable and writes the characters to
>     * the given appendable in the order that they are read. On return, this
>     * readable will be at end its data.
>     * <p>
>     * This method may block indefinitely reading from the readable, or
>     * writing to the appendable. The behavior for the case where the readable
>     * and/or appendable is <i>asynchronously closed</i>, or the thread
>     * interrupted during the transfer, is highly readable and appendable
>     * specific, and therefore not specified.
>     * <p>
>     * If an I/O error occurs reading from the readable or writing to the
>     * appendable, then it may do so after some characters have been read or
>     * written. Consequently the readable may not be at end of its data and
>     * one, or both participants may be in an inconsistent state. It is strongly
>     * recommended that both readable and appendable be promptly closed 
>     * if needed and an I/O error occurs.
>     *
>     * @param  out the appendable, non-null
>     * @return the number of characters transferred
>     * @throws IOException if an I/O error occurs when reading or writing
>     * @throws NullPointerException if {@code out} is {@code null}
>     *
>     * @since 1.9
>     */
>    default long transferTo(Appendable out) throws IOException {
>    ....
>    }
> 
> 
> -Patrick
> 
> 



From brian.burkhalter at oracle.com  Tue Dec 16 23:18:49 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 16 Dec 2014 15:18:49 -0800
Subject: Documentation of methods in java.lang.Number
In-Reply-To: <20141216125508.GC4911@e6430>
References: <20141216125508.GC4911@e6430>
Message-ID: <9D55A146-D76D-4E91-B02D-2BC646451CE2@oracle.com>

Andreas,

Doesn?t the class documentation of Number [1] provide sufficient clarity, to wit:

" The specific semantics of the conversion from the numeric value of a particular Number implementation to a given primitive type is defined by the Number implementation in question.?

and

?[?] conversions may lose information about the overall magnitude of a numeric value, may lose precision, and may even return a result of a different sign than the input. See the documentation of a given Number implementation for conversion details.?

That said, it might not however hurt slightly to modify the descriptions of {float,double,int,long}Value() to read something like, for longValue() for example:

"Returns the value of the specified number as a {@code long}, which may
 involve rounding, truncation, or some other narrowing conversion."

Brian

[1] http://docs.oracle.com/javase/8/docs/api/java/lang/Number.html

On Dec 16, 2014, at 4:55 AM, Andreas Lundblad <andreas.lundblad at oracle.com> wrote:

> I've noticed that the documentation of Number.longValue says:
> 
>> Returns the value of the specified number as a long, which may involve rounding or truncation.
> 
> BigInteger and BigDecimal does not seem to honor this contract since they implement this method by masking out the lower bits of the number (and I've found no definition of "rounding" or "truncation" that encompass this behavuor). The documentation of these classes even state that "[...] this conversion can lose information about the overall magnitude of the BigInteger value as well as return a result with the opposite sign."
> 
> I suggest the documentation of Number.byteValue/shortValue/intValue/longValue should be updated to give room for this type of implementation.
> 
> (I filed an issue on this and got a confirmation email with the following link: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7000825 Since then this page has gone missing. Where did the bug report go, and why didn't I get any notification about the removal?)



From martinrb at google.com  Wed Dec 17 00:06:58 2014
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 16 Dec 2014 16:06:58 -0800
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <54895EFB.3060204@redhat.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>
	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>
	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>
	<5481108A.3030605@oracle.com>
	<CA+kOe08OC57hEgGR-3CSfsJUMVSk-_mCmZK2Gd=3tpkE9=6j_w@mail.gmail.com>
	<5488B4EF.6060103@redhat.com> <5488EB09.9000501@oracle.com>
	<54895EFB.3060204@redhat.com>
Message-ID: <CA+kOe0_QOXi=mvLdXvYn4EF4J54HKDJVo=S4VBDUjujtpzgYzw@mail.gmail.com>

On Thu, Dec 11, 2014 at 1:08 AM, Andrew Haley <aph at redhat.com> wrote:
> On 11/12/14 00:53, David Holmes wrote:
>> There are many good uses of storestore in the various lock-free
>> algorithms inside hotspot.
>
> There may be many uses, but I am extremely suspicious of how good
> they are.  I wonder if we went through all the uses of storestore in
> hotspot how many bugs we'd find.  As far as I can see (in the absence
> of other barriers) the only things you can write before a storestore
> are constants.

Hans has provided us with the canonical writeup opposing store-store
and load-load barriers, here:
http://www.hboehm.info/c++mm/no_write_fences.html
Few programmers will be able to deal confidently with causality
defying time paradoxes, especially loads from "the future".


From mark.sheppard at oracle.com  Wed Dec 17 00:48:38 2014
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 17 Dec 2014 00:48:38 +0000
Subject: RFR: JDK-8067151 - [TESTBUG] com/sun/corba/5036554/TestCorbaBug.sh
Message-ID: <5490D2E6.10108@oracle.com>

Hi
    please oblige and review the follow changes
http://cr.openjdk.java.net/~msheppar/8067151/webrev/

to address the issue
https://bugs.openjdk.java.net/browse/JDK-8067151

which sees a test failure for JRE only in an embedded environment.

the test scripts now use the env variable COMPILEJAVA rather than TESTJAVA

regards
Mark


From bradford.wetmore at oracle.com  Wed Dec 17 01:36:08 2014
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Tue, 16 Dec 2014 17:36:08 -0800
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <mailman.31295.1417882498.10816.core-libs-dev@openjdk.java.net>
References: <mailman.31295.1417882498.10816.core-libs-dev@openjdk.java.net>
Message-ID: <5490DE08.708@oracle.com>

Various comments for this thread from June/July/November/December.

Some of the comments I'm responding to may already be better understood 
than when they were originally written.

Peter wrote in response to a suggestion to use /dev/random:

>> Although the approach would cause some more classes to load, no
>> arbitrary providers should be initialized.
>
> I think this is waht you get when you set
> "java.util.secureRandomSeed" system property to "true". TLR uses
> java.security.SecureRandom.getSeed(8) in this case.

For the "no arbitrary provider" part, that may not be quite correct. 
getSeed() creates/pulls from the default SecureRandom impl (i.e. new 
SecureRandom().generateSeed()), so it pulls in the Security Provider 
mechanism to determine the most preferred implementation, which could 
initialize additional higher-priority providers until an instance of 
SecureRandom is found.  For example, ucrypto on Solaris doesn't have a 
SecureRandom impl, so it would then fall back to PKCS11.

As has been pointed out, the various Oracle SecureRandom implementations 
and their preference order are a twisty maze of passages, somewhat but 
not exactly alike.  (With apologies to the "Colossal Cave.")  The 
default preference order is:

Solaris (sparc/sparcv9/x86/x64)
     "PKCS11" - "SunPKCS11"
     "NativePRNG" - "Sun"
     "SHA1PRNG" - "Sun"
     "NativePRNGBlocking" - "Sun"
     "NativePRNGNonBlocking" - "Sun"

Linux (x86/x64)/MacOS
     "NativePRNG" - "Sun"
     "SHA1PRNG" - "Sun"
     "NativePRNGBlocking" - "Sun"
     "NativePRNGNonBlocking" - "Sun"

Windows (x86/x64)
     "SHA1PRNG" - "Sun"
     "Windows-PRNG" - "SunMSCAPI"

Here's a few impl details for seeding calls.

PKCS11:
-------
generateSeed() routes to engineNextBytes(), which goes to the underlying 
PKCS11.

NativePRNG:  (Unix-only)
-----------
generateSeed() by default routes to /dev/random, unless the System 
Entropy Gathering Device (EGD) (set via a Security/System property) 
routes to something else.  (FYI: nextBytes() uses /dev/urandom.)

NativePRNG$BLOCKING:  (Unix-only)
--------------------
generateSeed() always routes to /dev/random.  (FYI: nextBytes() uses 
/dev/random.)

NativePRNG$NONBLOCKING:  (Unix-only)
-----------------------
generateSeed() always routes to /dev/urandom.  (FYI: nextBytes() uses 
/dev/urandom.)


SHA1PRNG:
---------
generateSeed() depends on the value of the EGD:

default EGD is:  "/dev/random"

     Note: if string "/dev/urandom" is set, urandom is used instead.

     Unix:  generateSeed() routes to /dev/random
            (NativeSeedGenerator: pure java)

     Win:   generateSeed() routes to CryptGenRandom
            (NativeSeedGenerator + libjava native)

non-default (not "/dev/random"/"/dev/urandom"):  "URL" is specified
     UNIX/Win:  routes to URL

If both above fail:
     falls back to ThreadedSeedGenerator (Pure Java)


Windows-PRNG
------------
generateSeed() routes to mscapi.PRNG/CryptGenRandom
     Note uses libmscapi, not libjava.


Peter wrote:
> The most problematic one is the default on Windows platform (the
> platform that does not have the "/dev/urandom" special file and would
> be used as a fall-back by your proposal) -
> sun.security.provider.SecureRandom. This one seeds itself by
> constructing an instance of itself with the result returned from
> SeedGenerator.getSystemEntropy() method. This method, among other
> things, uses networking code to gather system entropy:

SeedGenerator.getSystemEntropy() that includes the Network interfaces is 
only called when you need to seed the SHA1PRNG internal seeder in order 
to generate nextBytes().  generateSeed() doesn't trigger that internal 
seeder initialization.

So as you can see above, SecureRandom.generateSeed(int) is really 
variable in what you might end up with, and how much cruft comes with 
it.  For sure, the provider mechanism will be dragged in which is fairly 
substantial.


Peter wrote:
------------
> So by default yes, plain NativePRNG (the default on
> UNIX-es) is using /dev/urandom for nextBytes(), but this can be
> changed by defining java.security.egd or securerandom.source system
> property.

EGD really only affects where Seed byes are obtained from, IIRC, 
nextBytes() is not generally affected by this value.  It does tweak 
which implementation is most preferred within the Sun provider, but the 
majority of the effect is in Native/SHA1PRNG choice of generateSeed.

The original suggestion back in June:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027389.html
http://cr.openjdk.java.net/~plevart/jdk9-dev/TLR_SR_SeedGenerator/webrev.01/

for directly calling into NativeSeedGenerator makes more sense if you 
want to avoid duplicating existing code and creating a new native 
libraries as in the current proposal (webrev.03).  Your data shows that 
this approach pulls in a much smaller subset of classes than using the 
full SecureRandom.getInstance().generateSeed() API.  I've gone through 
the threads a couple times now:  somehow I've missed the rationale for 
why you're moving away from this (.01) for webrev.03.

To the actual proposal:

     http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.03/

Overall, I'm ok with what's proposed.  This is more straightforward to 
parse/understand than trying to adjust NativeSeedGenerator to 
create/call directly (e.g. UNIX:  new 
NativeSeedGenerator("/dev/urandom") or Windows:  new 
NativeSeedGenerator()).  But I'd still like to understand why you moved 
away from this.

One concern is that you're duplicating native libraries in java.base, 
and it would be the third JDK library overall with this type of call. 
There's one in libjava (for java.base/WinCAPISeedGenerator for 
sun.security.provider.NativeSeedGenerator) and sunmscapi (for 
jdk.crypto.mscapi/SunMSCAPI/sun.security.mscapi).  Would it work to 
tweak the WinCAPISeedGenerator so you don't have to create a new dll for 
java.base?

What are the fallbacks for SystemRandomImpl if /dev/urandom or the 
rtlGenRandomFN/CryptGenRandom aren't available?  Is that something 
you'll bake into TLR or will you do it here?

Having TLR seed the other clients is ok with me, the APIs make it clear 
that this isn't a strongly secure mechanism.

>> (Also, at some point we might reconsider our cowardice about not
>> improving the internal java.util.Random algorithm. j.u.Random is
>> much more commonly used, and does not fare well on quality tests.
>> On the other hand, the more that users instead choose to use
>> SR or TLR, the better.)
>
> The main problem is code (not just JDK test code) that hardwires
> expected Random.next* output under given seeds. Which might be
> enough reason to leave it alone.
> Do any CCC members have an opinion?

I'm *NOT* a CCC member (IANACCCM?).  However, the current javadocs are 
very specific on several points.  The big ones for me:  "If two 
instances of Random are created with the same seed...<deleted>...they 
will generate and return identical sequences of numbers".  It doesn't 
specify whether these are two instances are in the same VM or are across 
VMs/vendors, but the wording:  "Java implementations must use all the 
algorithms shown here for the class Random, for the sake of absolute 
portability of Java code" which makes me think it's the latter.  That 
is, you should not change the algorithm.  That's my $0.02.

The following is just one last thing to keep in mind.  If you call 
generateSeed() on Linux (e.g. in the current code for 
TLR/SplittableRandom: java.util.secureRandomSeed calls to getSeed()), 
you could block.  We still receive "hang" reports because apps/libraries 
insist on SHA1PRNG which uses 20 bytes of /dev/random to seed the 
seeder.  We especially see this on systems that simultaneously start 
multiple VMs and drain the /dev/random pool quickly.  Another 8 bytes of 
TLR/SplittableRandom could have further impact.

Martin wrote:

> https://bugs.openjdk.java.net/browse/JDK-8047769

If you've been following this bug, I've figured why the NativePRNG$* 
classes are initing and thus opening the /dev/random,urandom.  This 
definitely needs some adjustment.

Brad


From david.holmes at oracle.com  Wed Dec 17 02:28:25 2014
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Dec 2014 12:28:25 +1000
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <CA+kOe0_QOXi=mvLdXvYn4EF4J54HKDJVo=S4VBDUjujtpzgYzw@mail.gmail.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>	<5481108A.3030605@oracle.com>	<CA+kOe08OC57hEgGR-3CSfsJUMVSk-_mCmZK2Gd=3tpkE9=6j_w@mail.gmail.com>	<5488B4EF.6060103@redhat.com>	<5488EB09.9000501@oracle.com>	<54895EFB.3060204@redhat.com>
	<CA+kOe0_QOXi=mvLdXvYn4EF4J54HKDJVo=S4VBDUjujtpzgYzw@mail.gmail.com>
Message-ID: <5490EA49.2050406@oracle.com>

On 17/12/2014 10:06 AM, Martin Buchholz wrote:
> On Thu, Dec 11, 2014 at 1:08 AM, Andrew Haley <aph at redhat.com> wrote:
>> On 11/12/14 00:53, David Holmes wrote:
>>> There are many good uses of storestore in the various lock-free
>>> algorithms inside hotspot.
>>
>> There may be many uses, but I am extremely suspicious of how good
>> they are.  I wonder if we went through all the uses of storestore in
>> hotspot how many bugs we'd find.  As far as I can see (in the absence
>> of other barriers) the only things you can write before a storestore
>> are constants.
>
> Hans has provided us with the canonical writeup opposing store-store
> and load-load barriers, here:
> http://www.hboehm.info/c++mm/no_write_fences.html
> Few programmers will be able to deal confidently with causality
> defying time paradoxes, especially loads from "the future".

Well I take that with a grain of salt - Hans dismisses ordering based on 
dependencies which puts us into the realm of those "causality defying 
time paradoxes" in my opinion. Given:

x.a = 0;
x.a++
storestore
x_init = true

Hans allows for the nonsensical, in my view, possibility that the load 
of x.a can happen after the x_init=true store and yet somehow be subject 
to the ++ and the ensuing store that has to come before the x_init = true.

David
-----



From chris.hegarty at oracle.com  Wed Dec 17 09:01:40 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 17 Dec 2014 09:01:40 +0000
Subject: RFR: JDK-8067151 - [TESTBUG] com/sun/corba/5036554/TestCorbaBug.sh
In-Reply-To: <5490D2E6.10108@oracle.com>
References: <5490D2E6.10108@oracle.com>
Message-ID: <CCAEE545-2FA9-421B-920D-5A1BA436B682@oracle.com>

Mark,

The changes in test/com/sun/corba/5036554/TestCorbaBug.shlook fine to me. I don?t understand the reason for the ones in test/com/sun/corba/cachedSocket/7056731.sh.

-Chris.

On 17 Dec 2014, at 00:48, Mark Sheppard <mark.sheppard at oracle.com> wrote:

> Hi
>   please oblige and review the follow changes
> http://cr.openjdk.java.net/~msheppar/8067151/webrev/
> 
> to address the issue
> https://bugs.openjdk.java.net/browse/JDK-8067151
> 
> which sees a test failure for JRE only in an embedded environment.
> 
> the test scripts now use the env variable COMPILEJAVA rather than TESTJAVA
> 
> regards
> Mark



From yekaterina.kantserova at oracle.com  Wed Dec 17 09:10:47 2014
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Wed, 17 Dec 2014 10:10:47 +0100
Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find
	app's Java pid
In-Reply-To: <549060CE.5080505@oracle.com>
References: <5490564F.2010907@oracle.com> <549060CE.5080505@oracle.com>
Message-ID: <54914897.2050006@oracle.com>

Hi,

Thanks for all reviews!

The new webrev can be found here: 
http://cr.openjdk.java.net/~ykantser/6977426/webrev.01/

// Katja



On 12/16/2014 05:41 PM, Jaroslav Bachorik wrote:
> Hi Katja,
>
> This request should probably go to core-libs as well.
>
> Other than that I have just a few nits:
>
> test/java/util/logging/TestLoggerWeakRefLeak.java
>
> L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ?
> L127: // in LogManager.loggers that *arebeing* properly managed -> 
> *are being*
>
> callLoggerAndCount() and callAnonymousLoggerAndCount() are using the 
> 'count' variable to always return 100. Could they be made to return a 
> constant instead?
>
>
> Cheers,
>
> -JB-
>
>
> On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote:
>> Hi,
>>
>> Could I please have a review of this fix.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-6977426
>> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/
>>
>> java/util/logging/LoggerWeakRefLeak.sh and
>> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and rewritten in
>> java. sun/tools/common/CommonTests.sh is removed because it doesn't test
>> the product but sun/tool/common library functionality.
>>
>> Thanks,
>> Katja
>



From yekaterina.kantserova at oracle.com  Wed Dec 17 09:15:45 2014
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Wed, 17 Dec 2014 10:15:45 +0100
Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find
	app's Java pid
In-Reply-To: <54914897.2050006@oracle.com>
References: <5490564F.2010907@oracle.com> <549060CE.5080505@oracle.com>
	<54914897.2050006@oracle.com>
Message-ID: <549149C1.4050205@oracle.com>

Adding Erik.

On 12/17/2014 10:10 AM, Yekaterina Kantserova wrote:
> Hi,
>
> Thanks for all reviews!
>
> The new webrev can be found here: 
> http://cr.openjdk.java.net/~ykantser/6977426/webrev.01/
>
> // Katja
>
>
>
> On 12/16/2014 05:41 PM, Jaroslav Bachorik wrote:
>> Hi Katja,
>>
>> This request should probably go to core-libs as well.
>>
>> Other than that I have just a few nits:
>>
>> test/java/util/logging/TestLoggerWeakRefLeak.java
>>
>> L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ?
>> L127: // in LogManager.loggers that *arebeing* properly managed -> 
>> *are being*
>>
>> callLoggerAndCount() and callAnonymousLoggerAndCount() are using the 
>> 'count' variable to always return 100. Could they be made to return a 
>> constant instead?
>>
>>
>> Cheers,
>>
>> -JB-
>>
>>
>> On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote:
>>> Hi,
>>>
>>> Could I please have a review of this fix.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-6977426
>>> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/
>>>
>>> java/util/logging/LoggerWeakRefLeak.sh and
>>> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and rewritten in
>>> java. sun/tools/common/CommonTests.sh is removed because it doesn't 
>>> test
>>> the product but sun/tool/common library functionality.
>>>
>>> Thanks,
>>> Katja
>>
>



From peter.levart at gmail.com  Wed Dec 17 09:28:30 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 17 Dec 2014 10:28:30 +0100
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <5490EA49.2050406@oracle.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>	<5481108A.3030605@oracle.com>	<CA+kOe08OC57hEgGR-3CSfsJUMVSk-_mCmZK2Gd=3tpkE9=6j_w@mail.gmail.com>	<5488B4EF.6060103@redhat.com>	<5488EB09.9000501@oracle.com>	<54895EFB.3060204@redhat.com>	<CA+kOe0_QOXi=mvLdXvYn4EF4J54HKDJVo=S4VBDUjujtpzgYzw@mail.gmail.com>
	<5490EA49.2050406@oracle.com>
Message-ID: <54914CBE.2000201@gmail.com>

On 12/17/2014 03:28 AM, David Holmes wrote:
> On 17/12/2014 10:06 AM, Martin Buchholz wrote:
>> On Thu, Dec 11, 2014 at 1:08 AM, Andrew Haley <aph at redhat.com> wrote:
>>> On 11/12/14 00:53, David Holmes wrote:
>>>> There are many good uses of storestore in the various lock-free
>>>> algorithms inside hotspot.
>>>
>>> There may be many uses, but I am extremely suspicious of how good
>>> they are.  I wonder if we went through all the uses of storestore in
>>> hotspot how many bugs we'd find.  As far as I can see (in the absence
>>> of other barriers) the only things you can write before a storestore
>>> are constants.
>>
>> Hans has provided us with the canonical writeup opposing store-store
>> and load-load barriers, here:
>> http://www.hboehm.info/c++mm/no_write_fences.html
>> Few programmers will be able to deal confidently with causality
>> defying time paradoxes, especially loads from "the future".
>
> Well I take that with a grain of salt - Hans dismisses ordering based 
> on dependencies which puts us into the realm of those "causality 
> defying time paradoxes" in my opinion. Given:
>
> x.a = 0;
> x.a++
> storestore
> x_init = true
>
> Hans allows for the nonsensical, in my view, possibility that the load 
> of x.a can happen after the x_init=true store and yet somehow be 
> subject to the ++ and the ensuing store that has to come before the 
> x_init = true.
>
> David
> -----
>

Perhaps, he is speaking about why it is dangerous to replace BOTH 
release with just store-store AND acquire with just load-load?

The example would then become:

T1:

store x.a <- 0
load r <- x.a
store x.a <- r+1
; store-store
store x_init <- true

T2:

load r <- x.a
; load-load
if (r)
     store x.a <- 42


Suppose a "store" on some hypothetical architecture is actually a 
two-phase execution: prepare-store, commit-store

With prepare-store imagined as speculative posting of store to the write 
buffer and commit-store just marking it in the write buffer as commited, 
so that is is written to main memory on write buffer flush. Non commited 
stores are not written to main memory, but are allowed to be visible to 
loads in some threads (executing on same core?) which are not ordered by 
load-store before the speculative prepare-store. A load-load does not 
prevent the T2 to be executed as following:

T2:

prepare-store x.a <- 42
load r <- x.a
; load-load
if (r)
     commit-store x.a <- 42

Now this speculative prepare-store can (in real time) happen long before 
T1 instructions are executed. The loads in T1 are then allowed to "see" 
this speculative prepare-store from T2, because just store-store does 
not logically order them in any way - only load-store would.


Does this make sense?

Regards, Peter



From peter.levart at gmail.com  Wed Dec 17 09:30:48 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 17 Dec 2014 10:30:48 +0100
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <54914CBE.2000201@gmail.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>	<5481108A.3030605@oracle.com>	<CA+kOe08OC57hEgGR-3CSfsJUMVSk-_mCmZK2Gd=3tpkE9=6j_w@mail.gmail.com>	<5488B4EF.6060103@redhat.com>	<5488EB09.9000501@oracle.com>	<54895EFB.3060204@redhat.com>	<CA+kOe0_QOXi=mvLdXvYn4EF4J54HKDJVo=S4VBDUjujtpzgYzw@mail.gmail.com>
	<5490EA49.2050406@oracle.com> <54914CBE.2000201@gmail.com>
Message-ID: <54914D48.6040309@gmail.com>

On 12/17/2014 10:28 AM, Peter Levart wrote:
> The example would then become:
>
> T1:
>
> store x.a <- 0
> load r <- x.a
> store x.a <- r+1
> ; store-store
> store x_init <- true
>
> T2:
>
> load r <- x.a
> ; load-load
> if (r)
>     store x.a <- 42

Sorry the above has an error. I meant:

T2:

load r <- x_init
; load-load
if (r)
     store x.a <- 42


Peter


From daniel.fuchs at oracle.com  Wed Dec 17 09:55:16 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 17 Dec 2014 10:55:16 +0100
Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find
	app's Java pid
In-Reply-To: <54914897.2050006@oracle.com>
References: <5490564F.2010907@oracle.com> <549060CE.5080505@oracle.com>
	<54914897.2050006@oracle.com>
Message-ID: <54915304.4080503@oracle.com>

Hi Katja,

Sorry for not thinking of that when I replied earlier.
Your new test is so much more readable than the old shell
script :-)

These are minor  suggestions but they might help analysis
if the test fails:

On 17/12/14 10:10, Yekaterina Kantserova wrote:
> Hi,
>
> Thanks for all reviews!
>
> The new webrev can be found here:
> http://cr.openjdk.java.net/~ykantser/6977426/webrev.01/

Not that I believe it's very likely to happen, but I wonder
if the condition to exit the while loop:

   79         while (now < (startTime + (LOOP_TIME_SEC * 1000))) {

should also make sure that count > 1000 - and continue if not.
(Thinking of passed timeout related issues when tests where run
  with -Xcomp on fastdebug builds during integration nightlies)

Possibly printing the value of 'count' before the assert
at line 103 could help with debugging too, if the test actually
fails (even though the combination of increasingCount
+ decreasingCount would give us a hint)

best regards,

-- daniel

>
> // Katja
>
>
>
> On 12/16/2014 05:41 PM, Jaroslav Bachorik wrote:
>> Hi Katja,
>>
>> This request should probably go to core-libs as well.
>>
>> Other than that I have just a few nits:
>>
>> test/java/util/logging/TestLoggerWeakRefLeak.java
>>
>> L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ?
>> L127: // in LogManager.loggers that *arebeing* properly managed ->
>> *are being*
>>
>> callLoggerAndCount() and callAnonymousLoggerAndCount() are using the
>> 'count' variable to always return 100. Could they be made to return a
>> constant instead?
>>
>>
>> Cheers,
>>
>> -JB-
>>
>>
>> On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote:
>>> Hi,
>>>
>>> Could I please have a review of this fix.
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-6977426
>>> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/
>>>
>>> java/util/logging/LoggerWeakRefLeak.sh and
>>> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and rewritten in
>>> java. sun/tools/common/CommonTests.sh is removed because it doesn't test
>>> the product but sun/tool/common library functionality.
>>>
>>> Thanks,
>>> Katja
>>
>



From lev.priima at oracle.com  Wed Dec 17 10:22:12 2014
From: lev.priima at oracle.com (Lev Priima)
Date: Wed, 17 Dec 2014 13:22:12 +0300
Subject: RFR(S): 8067471: Use private static final char[0] for empty Strings
Message-ID: <54915954.6090804@oracle.com>

Hi,

Please review space optimization in no args String constructor. 
Originally, it was already rejected once by suggestion in 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010300.html w/o 
formal justification of pros and contras.  And enhancement was requested 
again by Nathan Reynolds.

Issue: https://bugs.openjdk.java.net/browse/JDK-8067471
Patch: http://cr.openjdk.java.net/~lpriima/8067471/webrev.00/

-- 
Best Regards,
Lev



From andreas.lundblad at oracle.com  Wed Dec 17 10:26:12 2014
From: andreas.lundblad at oracle.com (Andreas Lundblad)
Date: Wed, 17 Dec 2014 11:26:12 +0100
Subject: Documentation of methods in java.lang.Number
In-Reply-To: <9D55A146-D76D-4E91-B02D-2BC646451CE2@oracle.com>
References: <20141216125508.GC4911@e6430>
	<9D55A146-D76D-4E91-B02D-2BC646451CE2@oracle.com>
Message-ID: <20141217102612.GE4911@e6430>

On Tue, Dec 16, 2014 at 03:18:49PM -0800, Brian Burkhalter wrote:
> Andreas,
> 
> Doesn?t the class documentation of Number [1] provide sufficient clarity, to wit:
> 
> "The specific semantics of the conversion from the numeric value of a particular Number implementation to a given primitive type is defined by the Number implementation in question.?
> 
> and
> 
> ?[?] conversions may lose information about the overall magnitude of a numeric value, may lose precision, and may even return a result of a different sign than the input. See the documentation of a given Number implementation for conversion details.?

Agree. I see no way of improving the class level documentation.

> That said, it might not however hurt slightly to modify the descriptions of {float,double,int,long}Value() to read something like, for longValue() for example:
> 
> "Returns the value of the specified number as a {@code long}, which may
>  involve rounding, truncation, or some other narrowing conversion."

Right. As it stands now the class level description says "the semantics of the conversion is defined by the Number implementation in question", and then the documentation of longValue narrows this down to "rounding or truncation". By adding "or some other narrowing conversion" we make room for the BigDecimal/BigInteger implementations, but I would argue that it's still more constrained than the class level description.

Another suggestion would be:

"Returns the value of the specified number as a {@code long}. The specific semantics of the conversion is defined by the subclass in question."

-- Andreas


From mark.sheppard at oracle.com  Wed Dec 17 10:42:15 2014
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 17 Dec 2014 10:42:15 +0000
Subject: RFR: JDK-8067151 - [TESTBUG] com/sun/corba/5036554/TestCorbaBug.sh
In-Reply-To: <CCAEE545-2FA9-421B-920D-5A1BA436B682@oracle.com>
References: <5490D2E6.10108@oracle.com>
	<CCAEE545-2FA9-421B-920D-5A1BA436B682@oracle.com>
Message-ID: <54915E07.9060908@oracle.com>

Hi Chris,
    thanks for the reply. The bug refers to TestCorbaBug.sh, but I added 
the same change to 7056731.sh as a "pre-emptive measure".
If the first is failing then the second will also (at some point). I 
looked through the various shell script tests, while some use TESTJAVA, 
the majority are using COMPILEJAVA
as the env variable with the path to the jdk tools. So while making the 
first change, I thought it convenient to make the second change as well.

I can remove it in this case, if it is thought to be unnecessary at this 
juncture.

regards
Mark

On 17/12/2014 09:01, Chris Hegarty wrote:
> Mark,
>
> The changes in *test/com/sun/corba/5036554/TestCorbaBug.sh*look fine 
> to me. I don?t understand the reason for the ones in 
> *test/com/sun/corba/cachedSocket/7056731.sh.*
>
> -Chris.
>
> On 17 Dec 2014, at 00:48, Mark Sheppard <mark.sheppard at oracle.com 
> <mailto:mark.sheppard at oracle.com>> wrote:
>
>> Hi
>>   please oblige and review the follow changes
>> http://cr.openjdk.java.net/~msheppar/8067151/webrev/ 
>> <http://cr.openjdk.java.net/%7Emsheppar/8067151/webrev/>
>>
>> to address the issue
>> https://bugs.openjdk.java.net/browse/JDK-8067151
>>
>> which sees a test failure for JRE only in an embedded environment.
>>
>> the test scripts now use the env variable COMPILEJAVA rather than 
>> TESTJAVA
>>
>> regards
>> Mark
>



From yekaterina.kantserova at oracle.com  Wed Dec 17 11:05:53 2014
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Wed, 17 Dec 2014 12:05:53 +0100
Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find
	app's Java pid
In-Reply-To: <54915304.4080503@oracle.com>
References: <5490564F.2010907@oracle.com> <549060CE.5080505@oracle.com>
	<54914897.2050006@oracle.com> <54915304.4080503@oracle.com>
Message-ID: <54916391.9010307@oracle.com>

Daniel,

It's really funny to get such a feedback!

(1) The output from test right now looks like:

----------System.out:(7/183)----------
call count = 1000
instance count: 1001
call count = 2000
instance count: 1001
Finishing early due to non-increasing instance count
increasing count: 1
decreasing or the same count: 1

so printing the value of 'count' is already in there: 'call count ='.

(2) In the case we want to have an extra condition I think it should be 
'count > 2000'. Otherwise if the end time is passed the 'count > 1000' 
will result in having just one iteration (we will left the loop on 1100) 
and test will fail on assert.

The test timeout value should be increased as well. Right now it's 120 + 
30 sec.

  * @run main/timeout=150 TestLoggerWeakRefLeak Logger

If the test will not be completed in 120 s the extra 30 s will not make 
the trick and JTreg will interrupt it. What do you think will be enough?

// Katja



On 12/17/2014 10:55 AM, Daniel Fuchs wrote:
> Hi Katja,
>
> Sorry for not thinking of that when I replied earlier.
> Your new test is so much more readable than the old shell
> script :-)
>
> These are minor  suggestions but they might help analysis
> if the test fails:
>
> On 17/12/14 10:10, Yekaterina Kantserova wrote:
>> Hi,
>>
>> Thanks for all reviews!
>>
>> The new webrev can be found here:
>> http://cr.openjdk.java.net/~ykantser/6977426/webrev.01/
>
> Not that I believe it's very likely to happen, but I wonder
> if the condition to exit the while loop:
>
>   79         while (now < (startTime + (LOOP_TIME_SEC * 1000))) {
>
> should also make sure that count > 1000 - and continue if not.
> (Thinking of passed timeout related issues when tests where run
>  with -Xcomp on fastdebug builds during integration nightlies)
>
> Possibly printing the value of 'count' before the assert
> at line 103 could help with debugging too, if the test actually
> fails (even though the combination of increasingCount
> + decreasingCount would give us a hint)
>
> best regards,
>
> -- daniel
>
>>
>> // Katja
>>
>>
>>
>> On 12/16/2014 05:41 PM, Jaroslav Bachorik wrote:
>>> Hi Katja,
>>>
>>> This request should probably go to core-libs as well.
>>>
>>> Other than that I have just a few nits:
>>>
>>> test/java/util/logging/TestLoggerWeakRefLeak.java
>>>
>>> L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ?
>>> L127: // in LogManager.loggers that *arebeing* properly managed ->
>>> *are being*
>>>
>>> callLoggerAndCount() and callAnonymousLoggerAndCount() are using the
>>> 'count' variable to always return 100. Could they be made to return a
>>> constant instead?
>>>
>>>
>>> Cheers,
>>>
>>> -JB-
>>>
>>>
>>> On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote:
>>>> Hi,
>>>>
>>>> Could I please have a review of this fix.
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6977426
>>>> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/
>>>>
>>>> java/util/logging/LoggerWeakRefLeak.sh and
>>>> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and rewritten in
>>>> java. sun/tools/common/CommonTests.sh is removed because it doesn't 
>>>> test
>>>> the product but sun/tool/common library functionality.
>>>>
>>>> Thanks,
>>>> Katja
>>>
>>
>



From ivan.gerasimov at oracle.com  Wed Dec 17 11:11:00 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 17 Dec 2014 14:11:00 +0300
Subject: Java implementation of Alpha-numeric comparator
In-Reply-To: <549088D7.7040102@oracle.com>
References: <548EBD94.1070804@oracle.com>	<548F6145.1060207@oracle.com>	<548F7120.9040400@univ-mlv.fr>	<548FE9BB.7040005@oracle.com>	<548FEC1C.2070300@univ-mlv.fr>	<548FF406.2060108@oracle.com>	<5490487D.5060402@oracle.com>	<54907D93.7060706@oracle.com>
	<549088D7.7040102@oracle.com>
Message-ID: <549164C4.1020006@oracle.com>

Thanks Sherman for the comments!

>> By the way, the Microsoft's StrCmpLogicalW() does it in the opposite 
>> direction, i.e. strings with more leading zeros come earlier.
>> If people find it useful, we can make it configurable.
>>
>
> It's always desired to have a "customizable" approach for numeric 
> order collation:-)

Agreed.
Given it's almost trivial to add this customization, I've added it.
I've also done a minor optimization pass over the code.

Here's the updated webrev:
http://cr.openjdk.java.net/~igerasim/XXXXXXX-AlphaNumeric/2/webrev/

Sincerely yours,
Ivan


From daniel.fuchs at oracle.com  Wed Dec 17 11:33:30 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 17 Dec 2014 12:33:30 +0100
Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find
	app's Java pid
In-Reply-To: <54916391.9010307@oracle.com>
References: <5490564F.2010907@oracle.com> <549060CE.5080505@oracle.com>
	<54914897.2050006@oracle.com> <54915304.4080503@oracle.com>
	<54916391.9010307@oracle.com>
Message-ID: <54916A0A.6080508@oracle.com>

On 17/12/14 12:05, Yekaterina Kantserova wrote:
> Daniel,
>
> It's really funny to get such a feedback!
>
> (1) The output from test right now looks like:
>
> ----------System.out:(7/183)----------
> call count = 1000
> instance count: 1001
> call count = 2000
> instance count: 1001
> Finishing early due to non-increasing instance count
> increasing count: 1
> decreasing or the same count: 1
>
> so printing the value of 'count' is already in there: 'call count ='.

I meant to print the final value for count - but OK - having the
'call count' printed every 1000 count should be enough :-)


> (2) In the case we want to have an extra condition I think it should be
> 'count > 2000'. Otherwise if the end time is passed the 'count > 1000'
> will result in having just one iteration (we will left the loop on 1100)
> and test will fail on assert.

right. my mistake. you need at least two histograms.

> The test timeout value should be increased as well. Right now it's 120 +
> 30 sec.
>
>   * @run main/timeout=150 TestLoggerWeakRefLeak Logger
>
> If the test will not be completed in 120 s the extra 30 s will not make
> the trick and JTreg will interrupt it. What do you think will be enough?

I am not sure - but I guess what you have now should be good enough
for starter. In the problematic configurations there often is
an additional timeout factor - so in such case the real jtreg timeout
would I believe be something like 150*4 anyway - which should hopefully
leave time enough for the while loop to take two histograms. Simply
adding the extra condition to keep looping until we have at least two
should do the trick.

best regards, and thanks again for taking care of 6977426!

-- daniel

>
> // Katja
>
>
>
> On 12/17/2014 10:55 AM, Daniel Fuchs wrote:
>> Hi Katja,
>>
>> Sorry for not thinking of that when I replied earlier.
>> Your new test is so much more readable than the old shell
>> script :-)
>>
>> These are minor  suggestions but they might help analysis
>> if the test fails:
>>
>> On 17/12/14 10:10, Yekaterina Kantserova wrote:
>>> Hi,
>>>
>>> Thanks for all reviews!
>>>
>>> The new webrev can be found here:
>>> http://cr.openjdk.java.net/~ykantser/6977426/webrev.01/
>>
>> Not that I believe it's very likely to happen, but I wonder
>> if the condition to exit the while loop:
>>
>>   79         while (now < (startTime + (LOOP_TIME_SEC * 1000))) {
>>
>> should also make sure that count > 1000 - and continue if not.
>> (Thinking of passed timeout related issues when tests where run
>>  with -Xcomp on fastdebug builds during integration nightlies)
>>
>> Possibly printing the value of 'count' before the assert
>> at line 103 could help with debugging too, if the test actually
>> fails (even though the combination of increasingCount
>> + decreasingCount would give us a hint)
>>
>> best regards,
>>
>> -- daniel
>>
>>>
>>> // Katja
>>>
>>>
>>>
>>> On 12/16/2014 05:41 PM, Jaroslav Bachorik wrote:
>>>> Hi Katja,
>>>>
>>>> This request should probably go to core-libs as well.
>>>>
>>>> Other than that I have just a few nits:
>>>>
>>>> test/java/util/logging/TestLoggerWeakRefLeak.java
>>>>
>>>> L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ?
>>>> L127: // in LogManager.loggers that *arebeing* properly managed ->
>>>> *are being*
>>>>
>>>> callLoggerAndCount() and callAnonymousLoggerAndCount() are using the
>>>> 'count' variable to always return 100. Could they be made to return a
>>>> constant instead?
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> -JB-
>>>>
>>>>
>>>> On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote:
>>>>> Hi,
>>>>>
>>>>> Could I please have a review of this fix.
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6977426
>>>>> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/
>>>>>
>>>>> java/util/logging/LoggerWeakRefLeak.sh and
>>>>> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and rewritten in
>>>>> java. sun/tools/common/CommonTests.sh is removed because it doesn't
>>>>> test
>>>>> the product but sun/tool/common library functionality.
>>>>>
>>>>> Thanks,
>>>>> Katja
>>>>
>>>
>>
>



From chris.hegarty at oracle.com  Wed Dec 17 12:09:46 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 17 Dec 2014 12:09:46 +0000
Subject: RFR: JDK-8067151 - [TESTBUG] com/sun/corba/5036554/TestCorbaBug.sh
In-Reply-To: <54915E07.9060908@oracle.com>
References: <5490D2E6.10108@oracle.com>
	<CCAEE545-2FA9-421B-920D-5A1BA436B682@oracle.com>
	<54915E07.9060908@oracle.com>
Message-ID: <5491728A.6000407@oracle.com>

D'oh, I see it now. Reviewed.

When I first looked at the webrev I couldn't see the chages as the sdiff 
was off the screen! Anyway, user error.

-Chris.

On 17/12/14 10:42, Mark Sheppard wrote:
> Hi Chris,
>     thanks for the reply. The bug refers to TestCorbaBug.sh, but I added
> the same change to 7056731.sh as a "pre-emptive measure".
> If the first is failing then the second will also (at some point). I
> looked through the various shell script tests, while some use TESTJAVA,
> the majority are using COMPILEJAVA
> as the env variable with the path to the jdk tools. So while making the
> first change, I thought it convenient to make the second change as well.
>
> I can remove it in this case, if it is thought to be unnecessary at this
> juncture.
>
> regards
> Mark
>
> On 17/12/2014 09:01, Chris Hegarty wrote:
>> Mark,
>>
>> The changes in *test/com/sun/corba/5036554/TestCorbaBug.sh*look fine
>> to me. I don?t understand the reason for the ones in
>> *test/com/sun/corba/cachedSocket/7056731.sh.*
>>
>> -Chris.
>>
>> On 17 Dec 2014, at 00:48, Mark Sheppard <mark.sheppard at oracle.com
>> <mailto:mark.sheppard at oracle.com>> wrote:
>>
>>> Hi
>>>   please oblige and review the follow changes
>>> http://cr.openjdk.java.net/~msheppar/8067151/webrev/
>>> <http://cr.openjdk.java.net/%7Emsheppar/8067151/webrev/>
>>>
>>> to address the issue
>>> https://bugs.openjdk.java.net/browse/JDK-8067151
>>>
>>> which sees a test failure for JRE only in an embedded environment.
>>>
>>> the test scripts now use the env variable COMPILEJAVA rather than
>>> TESTJAVA
>>>
>>> regards
>>> Mark
>>
>


From yekaterina.kantserova at oracle.com  Wed Dec 17 13:11:43 2014
From: yekaterina.kantserova at oracle.com (Yekaterina Kantserova)
Date: Wed, 17 Dec 2014 14:11:43 +0100
Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find
	app's Java pid
In-Reply-To: <54916A0A.6080508@oracle.com>
References: <5490564F.2010907@oracle.com> <549060CE.5080505@oracle.com>
	<54914897.2050006@oracle.com> <54915304.4080503@oracle.com>
	<54916391.9010307@oracle.com> <54916A0A.6080508@oracle.com>
Message-ID: <5491810F.6030900@oracle.com>


Hopefully the last version :)

Erik has recommended to skip the whole timeout concept. Instead the test 
will loop until a decreasing count is found. Otherwise the test will 
timeout. The default JTreg time out is 5 minutes so it would be enough 
even for slower configurations.

The new webrev can be found here: 
http://cr.openjdk.java.net/~ykantser/6977426/webrev.02/

// Katja



On 12/17/2014 12:33 PM, Daniel Fuchs wrote:
> On 17/12/14 12:05, Yekaterina Kantserova wrote:
>> Daniel,
>>
>> It's really funny to get such a feedback!
>>
>> (1) The output from test right now looks like:
>>
>> ----------System.out:(7/183)----------
>> call count = 1000
>> instance count: 1001
>> call count = 2000
>> instance count: 1001
>> Finishing early due to non-increasing instance count
>> increasing count: 1
>> decreasing or the same count: 1
>>
>> so printing the value of 'count' is already in there: 'call count ='.
>
> I meant to print the final value for count - but OK - having the
> 'call count' printed every 1000 count should be enough :-)
>
>
>> (2) In the case we want to have an extra condition I think it should be
>> 'count > 2000'. Otherwise if the end time is passed the 'count > 1000'
>> will result in having just one iteration (we will left the loop on 1100)
>> and test will fail on assert.
>
> right. my mistake. you need at least two histograms.
>
>> The test timeout value should be increased as well. Right now it's 120 +
>> 30 sec.
>>
>>   * @run main/timeout=150 TestLoggerWeakRefLeak Logger
>>
>> If the test will not be completed in 120 s the extra 30 s will not make
>> the trick and JTreg will interrupt it. What do you think will be enough?
>
> I am not sure - but I guess what you have now should be good enough
> for starter. In the problematic configurations there often is
> an additional timeout factor - so in such case the real jtreg timeout
> would I believe be something like 150*4 anyway - which should hopefully
> leave time enough for the while loop to take two histograms. Simply
> adding the extra condition to keep looping until we have at least two
> should do the trick.
>
> best regards, and thanks again for taking care of 6977426!
>
> -- daniel
>
>>
>> // Katja
>>
>>
>>
>> On 12/17/2014 10:55 AM, Daniel Fuchs wrote:
>>> Hi Katja,
>>>
>>> Sorry for not thinking of that when I replied earlier.
>>> Your new test is so much more readable than the old shell
>>> script :-)
>>>
>>> These are minor  suggestions but they might help analysis
>>> if the test fails:
>>>
>>> On 17/12/14 10:10, Yekaterina Kantserova wrote:
>>>> Hi,
>>>>
>>>> Thanks for all reviews!
>>>>
>>>> The new webrev can be found here:
>>>> http://cr.openjdk.java.net/~ykantser/6977426/webrev.01/
>>>
>>> Not that I believe it's very likely to happen, but I wonder
>>> if the condition to exit the while loop:
>>>
>>>   79         while (now < (startTime + (LOOP_TIME_SEC * 1000))) {
>>>
>>> should also make sure that count > 1000 - and continue if not.
>>> (Thinking of passed timeout related issues when tests where run
>>>  with -Xcomp on fastdebug builds during integration nightlies)
>>>
>>> Possibly printing the value of 'count' before the assert
>>> at line 103 could help with debugging too, if the test actually
>>> fails (even though the combination of increasingCount
>>> + decreasingCount would give us a hint)
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>>
>>>> // Katja
>>>>
>>>>
>>>>
>>>> On 12/16/2014 05:41 PM, Jaroslav Bachorik wrote:
>>>>> Hi Katja,
>>>>>
>>>>> This request should probably go to core-libs as well.
>>>>>
>>>>> Other than that I have just a few nits:
>>>>>
>>>>> test/java/util/logging/TestLoggerWeakRefLeak.java
>>>>>
>>>>> L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ?
>>>>> L127: // in LogManager.loggers that *arebeing* properly managed ->
>>>>> *are being*
>>>>>
>>>>> callLoggerAndCount() and callAnonymousLoggerAndCount() are using the
>>>>> 'count' variable to always return 100. Could they be made to return a
>>>>> constant instead?
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>> -JB-
>>>>>
>>>>>
>>>>> On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Could I please have a review of this fix.
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6977426
>>>>>> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/
>>>>>>
>>>>>> java/util/logging/LoggerWeakRefLeak.sh and
>>>>>> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and 
>>>>>> rewritten in
>>>>>> java. sun/tools/common/CommonTests.sh is removed because it doesn't
>>>>>> test
>>>>>> the product but sun/tool/common library functionality.
>>>>>>
>>>>>> Thanks,
>>>>>> Katja
>>>>>
>>>>
>>>
>>
>



From daniel.fuchs at oracle.com  Wed Dec 17 13:36:51 2014
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 17 Dec 2014 14:36:51 +0100
Subject: RFR(S): 6977426: sun/tools tests can intermittently fail to find
	app's Java pid
In-Reply-To: <5491810F.6030900@oracle.com>
References: <5490564F.2010907@oracle.com> <549060CE.5080505@oracle.com>
	<54914897.2050006@oracle.com> <54915304.4080503@oracle.com>
	<54916391.9010307@oracle.com> <54916A0A.6080508@oracle.com>
	<5491810F.6030900@oracle.com>
Message-ID: <549186F3.5070608@oracle.com>

Hi Katja,

On 17/12/14 14:11, Yekaterina Kantserova wrote:
>
> Hopefully the last version :)
>
> Erik has recommended to skip the whole timeout concept. Instead the test
> will loop until a decreasing count is found. Otherwise the test will
> timeout. The default JTreg time out is 5 minutes so it would be enough
> even for slower configurations.

Good suggestion. I should have thought of that :-)

> The new webrev can be found here:
> http://cr.openjdk.java.net/~ykantser/6977426/webrev.02/

Thumbs up from me!

cheers,

-- daniel

>
> // Katja
>
>
>
> On 12/17/2014 12:33 PM, Daniel Fuchs wrote:
>> On 17/12/14 12:05, Yekaterina Kantserova wrote:
>>> Daniel,
>>>
>>> It's really funny to get such a feedback!
>>>
>>> (1) The output from test right now looks like:
>>>
>>> ----------System.out:(7/183)----------
>>> call count = 1000
>>> instance count: 1001
>>> call count = 2000
>>> instance count: 1001
>>> Finishing early due to non-increasing instance count
>>> increasing count: 1
>>> decreasing or the same count: 1
>>>
>>> so printing the value of 'count' is already in there: 'call count ='.
>>
>> I meant to print the final value for count - but OK - having the
>> 'call count' printed every 1000 count should be enough :-)
>>
>>
>>> (2) In the case we want to have an extra condition I think it should be
>>> 'count > 2000'. Otherwise if the end time is passed the 'count > 1000'
>>> will result in having just one iteration (we will left the loop on 1100)
>>> and test will fail on assert.
>>
>> right. my mistake. you need at least two histograms.
>>
>>> The test timeout value should be increased as well. Right now it's 120 +
>>> 30 sec.
>>>
>>>   * @run main/timeout=150 TestLoggerWeakRefLeak Logger
>>>
>>> If the test will not be completed in 120 s the extra 30 s will not make
>>> the trick and JTreg will interrupt it. What do you think will be enough?
>>
>> I am not sure - but I guess what you have now should be good enough
>> for starter. In the problematic configurations there often is
>> an additional timeout factor - so in such case the real jtreg timeout
>> would I believe be something like 150*4 anyway - which should hopefully
>> leave time enough for the while loop to take two histograms. Simply
>> adding the extra condition to keep looping until we have at least two
>> should do the trick.
>>
>> best regards, and thanks again for taking care of 6977426!
>>
>> -- daniel
>>
>>>
>>> // Katja
>>>
>>>
>>>
>>> On 12/17/2014 10:55 AM, Daniel Fuchs wrote:
>>>> Hi Katja,
>>>>
>>>> Sorry for not thinking of that when I replied earlier.
>>>> Your new test is so much more readable than the old shell
>>>> script :-)
>>>>
>>>> These are minor  suggestions but they might help analysis
>>>> if the test fails:
>>>>
>>>> On 17/12/14 10:10, Yekaterina Kantserova wrote:
>>>>> Hi,
>>>>>
>>>>> Thanks for all reviews!
>>>>>
>>>>> The new webrev can be found here:
>>>>> http://cr.openjdk.java.net/~ykantser/6977426/webrev.01/
>>>>
>>>> Not that I believe it's very likely to happen, but I wonder
>>>> if the condition to exit the while loop:
>>>>
>>>>   79         while (now < (startTime + (LOOP_TIME_SEC * 1000))) {
>>>>
>>>> should also make sure that count > 1000 - and continue if not.
>>>> (Thinking of passed timeout related issues when tests where run
>>>>  with -Xcomp on fastdebug builds during integration nightlies)
>>>>
>>>> Possibly printing the value of 'count' before the assert
>>>> at line 103 could help with debugging too, if the test actually
>>>> fails (even though the combination of increasingCount
>>>> + decreasingCount would give us a hint)
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>>
>>>>>
>>>>> // Katja
>>>>>
>>>>>
>>>>>
>>>>> On 12/16/2014 05:41 PM, Jaroslav Bachorik wrote:
>>>>>> Hi Katja,
>>>>>>
>>>>>> This request should probably go to core-libs as well.
>>>>>>
>>>>>> Other than that I have just a few nits:
>>>>>>
>>>>>> test/java/util/logging/TestLoggerWeakRefLeak.java
>>>>>>
>>>>>> L57: if ("Logger".contains(args[0])) -> "Logger".equals(args[0]) ?
>>>>>> L127: // in LogManager.loggers that *arebeing* properly managed ->
>>>>>> *are being*
>>>>>>
>>>>>> callLoggerAndCount() and callAnonymousLoggerAndCount() are using the
>>>>>> 'count' variable to always return 100. Could they be made to return a
>>>>>> constant instead?
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> -JB-
>>>>>>
>>>>>>
>>>>>> On 12/16/2014 04:57 PM, Yekaterina Kantserova wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Could I please have a review of this fix.
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-6977426
>>>>>>> webrev: http://cr.openjdk.java.net/~ykantser/6977426/webrev.00/
>>>>>>>
>>>>>>> java/util/logging/LoggerWeakRefLeak.sh and
>>>>>>> java/util/logging/AnonLoggerWeakRefLeak.sh are merged and
>>>>>>> rewritten in
>>>>>>> java. sun/tools/common/CommonTests.sh is removed because it doesn't
>>>>>>> test
>>>>>>> the product but sun/tool/common library functionality.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Katja
>>>>>>
>>>>>
>>>>
>>>
>>
>



From patrick at reini.net  Wed Dec 17 14:37:31 2014
From: patrick at reini.net (Patrick Reinhart)
Date: Wed, 17 Dec 2014 15:37:31 +0100
Subject: JDK-8067661: transferTo proposal for Appendable
In-Reply-To: <C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
References: <390C50B0-BA07-4114-9B6F-285F111AA54A@reini.net>
	<C8090994-27E5-4BB9-9784-0070D0A63FC7@oracle.com>
Message-ID: <9EAA4F5B-83DA-4459-A565-511C6E052413@reini.net>

Hi Pavel,

> Hi Patrick, nice to hear from you again! I agree we should consider adding this
> method. Unfortunately, from the spec point of view I suppose this one will
> require a lot more chewing. For instance there's nothing that can be closed
> either in Readable or Appendable (in general case), since neither of them is
> java.io.Closeable or even java.lang.AutoCloseable. In my opinion, all mentions
> of 'close' operations should go. You're fine to elaborate spec down the
> hierarchy though:
> 
>    /**
>     *
>     ... some specifics for Readers ...
>     *
>     */
>    @Override
>    public long transferTo(Appendable out) throws IOException {
>        return Readable.super.transferTo(out);
>    }

You?re right. I also saw that neither Readable nor Appendable extend any of those *Closable interfaces.
I was not sure if that should belong to the Readable itself. To move those more specific parts down to
the Reader implementation is absolutely fine for me and seems to be a better fit.

> 
> But at the same time this one, you added, is crucial:
> 
>    * one, or both participants may be in an inconsistent state
> 
> So you give implementors the freedom to use "if anything bad happens all bets
> are off".
> It's also not fully clear what it means for an instance of Readable to be
> "at end of its data". This have a well-defined meaning for java.io.Reader though.
> 

I got your point here. I was not sure, what parts from the InputStream.transferTo() spec can be reused.

-Patrick

> 
>> On 16 Dec 2014, at 22:13, Patrick Reinhart <patrick at reini.net> wrote:
>> 
>> Hi Chris & Pavel,
>> 
>> Based on the transferTo Method on the InputStream I would propose to introduce a default method on the Readable interface. In that way the method can be used for all existing implementations of Readable and still be implemented in a special way by a individual implementer.
>> 
>>   /**
>>    * Reads all characters from this readable and writes the characters to
>>    * the given appendable in the order that they are read. On return, this
>>    * readable will be at end its data.
>>    * <p>
>>    * This method may block indefinitely reading from the readable, or
>>    * writing to the appendable. The behavior for the case where the readable
>>    * and/or appendable is <i>asynchronously closed</i>, or the thread
>>    * interrupted during the transfer, is highly readable and appendable
>>    * specific, and therefore not specified.
>>    * <p>
>>    * If an I/O error occurs reading from the readable or writing to the
>>    * appendable, then it may do so after some characters have been read or
>>    * written. Consequently the readable may not be at end of its data and
>>    * one, or both participants may be in an inconsistent state. It is strongly
>>    * recommended that both readable and appendable be promptly closed 
>>    * if needed and an I/O error occurs.
>>    *
>>    * @param  out the appendable, non-null
>>    * @return the number of characters transferred
>>    * @throws IOException if an I/O error occurs when reading or writing
>>    * @throws NullPointerException if {@code out} is {@code null}
>>    *
>>    * @since 1.9
>>    */
>>   default long transferTo(Appendable out) throws IOException {
>>   ....
>>   }
>> 
>> 
>> -Patrick
>> 
>> 
> 



From claes.redestad at oracle.com  Wed Dec 17 15:58:15 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 17 Dec 2014 16:58:15 +0100
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <54915954.6090804@oracle.com>
References: <54915954.6090804@oracle.com>
Message-ID: <5491A817.7040607@oracle.com>

On 2014-12-17 11:22, Lev Priima wrote:
> Hi,
>
> Please review space optimization in no args String constructor. 
> Originally, it was already rejected once by suggestion in 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010300.html 
> w/o formal justification of pros and contras.  And enhancement was 
> requested again by Nathan Reynolds.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8067471
> Patch: http://cr.openjdk.java.net/~lpriima/8067471/webrev.00/
>

Could this have some obscure security implications, such as the ability 
to lock up some subsystem via retrieving and synchronizing on the shared 
new String().value? I guess not, for practical purposes.

I guess it could also be written:

     public String() {
         this.value = "".value;
     }

... which would saves some byte code and should avoid having to allocate 
a distinct object for this.

/Claes


From michael.mcmahon at oracle.com  Mon Dec 15 14:41:55 2014
From: michael.mcmahon at oracle.com (Michael Mcmahon)
Date: Mon, 15 Dec 2014 06:41:55 -0800 (PST)
Subject: [9] Review request : JDK-6933879: URISyntaxException when
	non-alphanumeric characters are present in scope_id
In-Reply-To: <548EC2D7.6000604@oracle.com>
References: <54886510.1010704@oracle.com> <54897B63.30801@oracle.com>
	<548EC2D7.6000604@oracle.com>
Message-ID: <56b25502-e01e-4e1e-9d6d-c00ba6e1e616@default>

Hi,

I'm afraid you have the wrong Michael McMahon.

-----Original Message-----
From: Konstantin Shefov 
Sent: Monday, December 15, 2014 6:16 AM
To: Ivan Gerasimov; net-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Alan Bateman; Chris Hegarty; MICHAEL.MCMAHON
Subject: Re: [9] Review request : JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id

Gently reminder. Please review.

-Konstantin

On 11.12.2014 14:09, Konstantin Shefov wrote:
> CC'ed core-libs-dev at openjdk.java.net
>
> On 10.12.2014 18:21, Konstantin Shefov wrote:
>> Hello,
>>
>> Please, review the bug fix: 
>> https://bugs.openjdk.java.net/browse/JDK-6933879
>> Webrev: http://cr.openjdk.java.net/~kshefov/6933879/webrev.00
>>
>> It is suggested to add some more symbols allowed for scope id in IPv6 
>> URI, namely "_", "." and ":", because these symbols may be included 
>> in network interface names. Now only alphanumeric characters are 
>> allowed to be in a scope id.
>>
>> Thanks
>> -Konstantin
>



From peter.levart at gmail.com  Wed Dec 17 17:37:43 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 17 Dec 2014 18:37:43 +0100
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <5490DE08.708@oracle.com>
References: <mailman.31295.1417882498.10816.core-libs-dev@openjdk.java.net>
	<5490DE08.708@oracle.com>
Message-ID: <5491BF67.6070000@gmail.com>

Hi Brad,

I am glad that you came across all the threads on this topic. I agree 
with your evaluation of my comments from an early thread. I have gone 
through security providers infrastructure multiple times since then and 
I can see where my comments were incorrect. The confusion was mostly 
based around mixing SecureRandom.generateSeed () with 
SecureRandom.nextBytes () and their underlying implementations for 
different providers.

Now to answer inline...

On 12/17/2014 02:36 AM, Bradford Wetmore wrote:
> Various comments for this thread from June/July/November/December.
>
> Some of the comments I'm responding to may already be better 
> understood than when they were originally written.
>
> Peter wrote in response to a suggestion to use /dev/random:
>
>>> Although the approach would cause some more classes to load, no
>>> arbitrary providers should be initialized.
>>
>> I think this is waht you get when you set
>> "java.util.secureRandomSeed" system property to "true". TLR uses
>> java.security.SecureRandom.getSeed(8) in this case.
>
> For the "no arbitrary provider" part, that may not be quite correct. 
> getSeed() creates/pulls from the default SecureRandom impl (i.e. new 
> SecureRandom().generateSeed()), so it pulls in the Security Provider 
> mechanism to determine the most preferred implementation, which could 
> initialize additional higher-priority providers until an instance of 
> SecureRandom is found.  For example, ucrypto on Solaris doesn't have a 
> SecureRandom impl, so it would then fall back to PKCS11.
>
> As has been pointed out, the various Oracle SecureRandom 
> implementations and their preference order are a twisty maze of 
> passages, somewhat but not exactly alike.  (With apologies to the 
> "Colossal Cave.")  The default preference order is:
>
> Solaris (sparc/sparcv9/x86/x64)
>     "PKCS11" - "SunPKCS11"
>     "NativePRNG" - "Sun"
>     "SHA1PRNG" - "Sun"
>     "NativePRNGBlocking" - "Sun"
>     "NativePRNGNonBlocking" - "Sun"
>
> Linux (x86/x64)/MacOS
>     "NativePRNG" - "Sun"
>     "SHA1PRNG" - "Sun"
>     "NativePRNGBlocking" - "Sun"
>     "NativePRNGNonBlocking" - "Sun"
>
> Windows (x86/x64)
>     "SHA1PRNG" - "Sun"
>     "Windows-PRNG" - "SunMSCAPI"
>
> Here's a few impl details for seeding calls.
>
> PKCS11:
> -------
> generateSeed() routes to engineNextBytes(), which goes to the 
> underlying PKCS11.
>
> NativePRNG:  (Unix-only)
> -----------
> generateSeed() by default routes to /dev/random, unless the System 
> Entropy Gathering Device (EGD) (set via a Security/System property) 
> routes to something else.  (FYI: nextBytes() uses /dev/urandom.)
>
> NativePRNG$BLOCKING:  (Unix-only)
> --------------------
> generateSeed() always routes to /dev/random.  (FYI: nextBytes() uses 
> /dev/random.)
>
> NativePRNG$NONBLOCKING:  (Unix-only)
> -----------------------
> generateSeed() always routes to /dev/urandom.  (FYI: nextBytes() uses 
> /dev/urandom.)
>
>
> SHA1PRNG:
> ---------
> generateSeed() depends on the value of the EGD:
>
> default EGD is:  "/dev/random"
>
>     Note: if string "/dev/urandom" is set, urandom is used instead.
>
>     Unix:  generateSeed() routes to /dev/random
>            (NativeSeedGenerator: pure java)
>
>     Win:   generateSeed() routes to CryptGenRandom
>            (NativeSeedGenerator + libjava native)
>
> non-default (not "/dev/random"/"/dev/urandom"):  "URL" is specified
>     UNIX/Win:  routes to URL
>
> If both above fail:
>     falls back to ThreadedSeedGenerator (Pure Java)
>
>
> Windows-PRNG
> ------------
> generateSeed() routes to mscapi.PRNG/CryptGenRandom
>     Note uses libmscapi, not libjava.

That's right. Different defaults on different platforms and a 
possibility to configure preferential custom providers makes the choices 
for implementation of SecureRandom.getSeed() static method (which uses 
1st SecureRandom provider in the providers list) quite diverse. The 
problem I see here is different default behaviour depending on platform. 
A user can make a choice which SecureRandom algorithm the application 
code uses by explicitly requesting it (with 
SecureRandom.getInstance(algorithm)), but she can't choose the algorithm 
when she decides to use SecureRandom for initial seeding of 
TLR/SplittableRandom. By default on Unix you get a /dev/random kind of 
implementation for generateSeed() which is blocking on Linux. On Linux 
one would probably want to use NativePRNGNonBlocking which uses 
/dev/urandom for generateSeed().

One way to solve this is to extend the meaning of 
java.util.secureRandomSeed system property - besides "true" which would 
choose the 1st provider, one could specify the algorithm name. For 
example, on Unix one would choose: 
java.util.secureRandomSeed=NativePRNGNonBlocking to get a /dev/urandom 
based initial seed for TLR/SplittableRandom.

There's also a possibility to hard-code an explicit lookup for 
particular algorithms and use the one with highest preference that is 
available with a fall-back on 1st (default) provider. For initial 
seeding of TLR/SplittableRandom, security is not important, but 
initialization latency is, so the preference order for choosing 
SecureRandom algorithm is different for TLR/SplittableRandom seeding 
than for general application needs.

Considering SecureRandom as an option for seeding TLR/SplittableRandom 
is a consequence of having no other good alternatives in JDK for initial 
seeding of non-secure PRNGs. Current mechanism which only uses 
System.nanoTime() and System.currentTimeMillis() might not be 
good-enough in certain situations (like spawning lots of VMs at the same 
time). We need some more entropy.

>
>
> Peter wrote:
>> The most problematic one is the default on Windows platform (the
>> platform that does not have the "/dev/urandom" special file and would
>> be used as a fall-back by your proposal) -
>> sun.security.provider.SecureRandom. This one seeds itself by
>> constructing an instance of itself with the result returned from
>> SeedGenerator.getSystemEntropy() method. This method, among other
>> things, uses networking code to gather system entropy:
>
> SeedGenerator.getSystemEntropy() that includes the Network interfaces 
> is only called when you need to seed the SHA1PRNG internal seeder in 
> order to generate nextBytes().  generateSeed() doesn't trigger that 
> internal seeder initialization.

That's right. My mistake in reading the code.

>
> So as you can see above, SecureRandom.generateSeed(int) is really 
> variable in what you might end up with, and how much cruft comes with 
> it.  For sure, the provider mechanism will be dragged in which is 
> fairly substantial.
>
>
> Peter wrote:
> ------------
>> So by default yes, plain NativePRNG (the default on
>> UNIX-es) is using /dev/urandom for nextBytes(), but this can be
>> changed by defining java.security.egd or securerandom.source system
>> property.
>
> EGD really only affects where Seed byes are obtained from, IIRC, 
> nextBytes() is not generally affected by this value.  It does tweak 
> which implementation is most preferred within the Sun provider, but 
> the majority of the effect is in Native/SHA1PRNG choice of generateSeed.

True.

>
> The original suggestion back in June:
>
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-June/027389.html 
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/TLR_SR_SeedGenerator/webrev.01/ 
>
>
> for directly calling into NativeSeedGenerator makes more sense if you 
> want to avoid duplicating existing code and creating a new native 
> libraries as in the current proposal (webrev.03).  Your data shows 
> that this approach pulls in a much smaller subset of classes than 
> using the full SecureRandom.getInstance().generateSeed() API.  I've 
> gone through the threads a couple times now:  somehow I've missed the 
> rationale for why you're moving away from this (.01) for webrev.03.

There are several reasons:

- I got an impression that hacking on and publicly exposing 
package-private SeedGenerator API is not a desirable approach from 
viewpoint of further maintainability and inter-dependencies, especially 
now that modules are coming to JDK9.
- As said, the preference for TLR/SplittableRandom initial seeding is 
non-blocking and small initialization latency, not security - the 
default SeedGenerator is blocking on Linux, so I had to expose a special 
method just to return a temporary non-blocking instance which is not 
used by sun.security.provider internally, just by TLR/SplittableRandom.
- As sun.security.provider and TLR/SplittableRandom are using different 
types of SeedGenerator, I thought why not making a separate internal API 
just for TLR/SplittableRandom use.
- There is a desire to access this functionality also from external user 
code (for example from stand-alone builds of java.util.concurrent 
utilities). This could be provided given this API is moved to a globally 
exported package (see below).

Separate API also allowed me to use ADVAPI32!RtlGenRandom function 
instead of Crypto API's CryptGenRandom on Windows which further reduces 
initialization latency and footprint (I think this could be used for 
NativeSeedGenerator too as other functions of SUN provider don't use 
Crypto API).

>
> To the actual proposal:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/SystemRandom/webrev.03/
>
> Overall, I'm ok with what's proposed.  This is more straightforward to 
> parse/understand than trying to adjust NativeSeedGenerator to 
> create/call directly (e.g. UNIX:  new 
> NativeSeedGenerator("/dev/urandom") or Windows:  new 
> NativeSeedGenerator()).  But I'd still like to understand why you 
> moved away from this.
>
> One concern is that you're duplicating native libraries in java.base, 
> and it would be the third JDK library overall with this type of call. 
> There's one in libjava (for java.base/WinCAPISeedGenerator for 
> sun.security.provider.NativeSeedGenerator) and sunmscapi (for 
> jdk.crypto.mscapi/SunMSCAPI/sun.security.mscapi).  Would it work to 
> tweak the WinCAPISeedGenerator so you don't have to create a new dll 
> for java.base?

The SystemRandom JNI bindings for Windows are located in:

     java.base/windows/native/libjava/SystemRandomImpl_md.c

...so as I understand they are also part of libjava. No new DLL here. Is 
this going to change with modules? Is libjava going to split? In any 
case the bindings could be included in some existing DLL in the module 
where they are deployed (most probably java.base).

>
> What are the fallbacks for SystemRandomImpl if /dev/urandom or the 
> rtlGenRandomFN/CryptGenRandom aren't available?  Is that something 
> you'll bake into TLR or will you do it here?

I think it's better to leave it to consumers (TLR/SplittableRandom) as 
they know what's good-enough for them. The API allows for arbitrary 
number of bytes to be generated and I don't have an easy means of 
generating more than 8 "random" bytes just from System.nanoTime() and 
System.currentTimeMillis() short of using SecureRandom as a fall-back.

The problem is also how to make access to this functionality for 
different consumers that are located in different packages (java.util, 
java.util.concurrent) and make it somehow usable also for external 
access. There is a desire to use this also from stand-alone builds of 
java.util.concurrent utilities. That's why my initial approach for 
SystemRandom used a public API in java.util.

The approach used with sun.misc.Unsafe is probably not going to work for 
user code in JDK9 with modules, as sun.misc will not be globally 
exported. Are any non J2SE packages going to be globally exported? I see 
jdk and jdk.net are already mentioned as such globally exported packages 
in modules.xml...

>
> Having TLR seed the other clients is ok with me, the APIs make it 
> clear that this isn't a strongly secure mechanism.
>
>>> (Also, at some point we might reconsider our cowardice about not
>>> improving the internal java.util.Random algorithm. j.u.Random is
>>> much more commonly used, and does not fare well on quality tests.
>>> On the other hand, the more that users instead choose to use
>>> SR or TLR, the better.)
>>
>> The main problem is code (not just JDK test code) that hardwires
>> expected Random.next* output under given seeds. Which might be
>> enough reason to leave it alone.
>> Do any CCC members have an opinion?
>
> I'm *NOT* a CCC member (IANACCCM?).  However, the current javadocs are 
> very specific on several points.  The big ones for me:  "If two 
> instances of Random are created with the same seed...<deleted>...they 
> will generate and return identical sequences of numbers".  It doesn't 
> specify whether these are two instances are in the same VM or are 
> across VMs/vendors, but the wording:  "Java implementations must use 
> all the algorithms shown here for the class Random, for the sake of 
> absolute portability of Java code" which makes me think it's the 
> latter.  That is, you should not change the algorithm.  That's my $0.02.
>
> The following is just one last thing to keep in mind.  If you call 
> generateSeed() on Linux (e.g. in the current code for 
> TLR/SplittableRandom: java.util.secureRandomSeed calls to getSeed()), 
> you could block.  We still receive "hang" reports because 
> apps/libraries insist on SHA1PRNG which uses 20 bytes of /dev/random 
> to seed the seeder.  We especially see this on systems that 
> simultaneously start multiple VMs and drain the /dev/random pool 
> quickly.  Another 8 bytes of TLR/SplittableRandom could have further 
> impact.
>
> Martin wrote:
>
>> https://bugs.openjdk.java.net/browse/JDK-8047769
>
> If you've been following this bug, I've figured why the NativePRNG$* 
> classes are initing and thus opening the /dev/random,urandom.  This 
> definitely needs some adjustment.

Something like the following could be used in NativePRNG and 
URLSeedGenerator:

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


Regards, Peter

>
> Brad



From peter.levart at gmail.com  Wed Dec 17 17:53:42 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 17 Dec 2014 18:53:42 +0100
Subject: RFR 8066397 Remove network-related seed initialization code in
	ThreadLocal/SplittableRandom
In-Reply-To: <5491BF67.6070000@gmail.com>
References: <mailman.31295.1417882498.10816.core-libs-dev@openjdk.java.net>
	<5490DE08.708@oracle.com> <5491BF67.6070000@gmail.com>
Message-ID: <5491C326.9010002@gmail.com>

On 12/17/2014 06:37 PM, Peter Levart wrote:
>> Martin wrote:
>>
>>> https://bugs.openjdk.java.net/browse/JDK-8047769
>>
>> If you've been following this bug, I've figured why the NativePRNG$* 
>> classes are initing and thus opening the /dev/random,urandom.  This 
>> definitely needs some adjustment.
>
> Something like the following could be used in NativePRNG and 
> URLSeedGenerator:
>
> http://cr.openjdk.java.net/~plevart/misc/FileInputStreamPool/FileInputStreamPool.java 
>


Note that this code has a nasty bug - don't use it. I'll post a fixed 
source later...

Peter



From brian.burkhalter at oracle.com  Wed Dec 17 17:56:58 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 17 Dec 2014 09:56:58 -0800
Subject: Documentation of methods in java.lang.Number
In-Reply-To: <20141217102612.GE4911@e6430>
References: <20141216125508.GC4911@e6430>
	<9D55A146-D76D-4E91-B02D-2BC646451CE2@oracle.com>
	<20141217102612.GE4911@e6430>
Message-ID: <AD833072-0C6F-4D65-BA04-A9BF81083678@oracle.com>


On Dec 17, 2014, at 2:26 AM, Andreas Lundblad <andreas.lundblad at oracle.com> wrote:

> Right. As it stands now the class level description says "the semantics of the conversion is defined by the Number implementation in question", and then the documentation of longValue narrows this down to "rounding or truncation". By adding "or some other narrowing conversion" we make room for the BigDecimal/BigInteger implementations, but I would argue that it's still more constrained than the class level description.
> 
> Another suggestion would be:
> 
> "Returns the value of the specified number as a {@code long}. The specific semantics of the conversion is defined by the subclass in question."

This seems reasonable to me. I?ll put together a patch to this effect unless there are other suggestions.

Thanks,

Brian

From aleksey.shipilev at oracle.com  Wed Dec 17 18:10:34 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Wed, 17 Dec 2014 21:10:34 +0300
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <5491A817.7040607@oracle.com>
References: <54915954.6090804@oracle.com> <5491A817.7040607@oracle.com>
Message-ID: <5491C71A.5040107@oracle.com>

On 17.12.2014 18:58, Claes Redestad wrote:
> On 2014-12-17 11:22, Lev Priima wrote:
>> Please review space optimization in no args String constructor.
>> Originally, it was already rejected once by suggestion in
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010300.html
>> w/o formal justification of pros and contras.  And enhancement was
>> requested again by Nathan Reynolds.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8067471
>> Patch: http://cr.openjdk.java.net/~lpriima/8067471/webrev.00/

I am OK with this change pending we understand the performance impact a
little better. Please do benchmarks.


> Could this have some obscure security implications, such as the ability
> to lock up some subsystem via retrieving and synchronizing on the shared
> new String().value? I guess not, for practical purposes.

This would be an issue if we published String.value directly, but we don't.

> I guess it could also be written:
> 
>     public String() {
>         this.value = "".value;
>     }
> 
> ... which would saves some byte code and should avoid having to allocate
> a distinct object for this.

Oh, I like this trick, given "" is probably already in constant pool for
some other reason. However, there is an additional dereference. We need
a targeted nanobenchmark to properly quantify the costs for either variant.

-Aleksey.




From sean.mullan at oracle.com  Wed Dec 17 18:35:12 2014
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 17 Dec 2014 13:35:12 -0500
Subject: FilePermission Canonical path optimization
In-Reply-To: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>
Message-ID: <5491CCE0.5050501@oracle.com>

Hi,

Can you elaborate more on the performance degradation that you are 
seeing at startup? Are you seeing this when you are running with or 
without a SecurityManager? If without a SecurityManager, can you provide 
some code paths/examples? As far as I can see, with the proposed fix you 
are moving the performance hit to runtime, and it will be triggered the 
first time a FilePermission check is made, and at worst case it may need 
to canonicalize all the FilePermissions in the FilePermissionCollection. 
Also, with the latest proposed fix you are potentially making 
performance worse by introducing synchronized blocks (which as Peter 
noted, still have some race conditions). I can understand why you want 
to improve application startup, but I want to make sure I understand the 
use case(s) a little better first.

Thanks,
Sean

On 12/01/2014 03:06 AM, deven you wrote:
> Hi All,
>   File.getCanonicalPath() is a very time-consuming method, we observed
> significant performance degradation from some application's startup stage
> with java.io.FilePermission. However, lazying load the calls to
> getCanonicalPath() from java.ioFilePermission is straightforward and solve
> this problem effectively. Openjdk bug[1]  tracks this bug and here is the
> patch [2]. Could anyone take a look?
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8066211
> [2] http://cr.openjdk.java.net/~youdwei/ojdk-912/webrev.00/
>


From sean.mullan at oracle.com  Wed Dec 17 18:36:27 2014
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 17 Dec 2014 13:36:27 -0500
Subject: FilePermission Canonical path optimization
In-Reply-To: <5481AC6E.9060706@gmail.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>	<547C6432.5050003@oracle.com>	<CADsbJLkL_NE0GbT_uB3xwSZc+XYi1dHACabwjCApaXr=h-UkLQ@mail.gmail.com>	<CADsbJL=8k6PB9qD7mAP4GhtpGfC9876N1o8GF-Eq64Ly=FKHtA@mail.gmail.com>
	<5481AC6E.9060706@gmail.com>
Message-ID: <5491CD2B.5090807@oracle.com>

On 12/05/2014 08:00 AM, Peter Levart wrote:
> The question is what to do with the remaining data race that was present
> before. The 'mask' field. The best would be to make it final, but
> deserialization needs to set it.

I don't see the pre-existing race condition on the mask field, but I'm 
probably missing something subtle. Can you provide more details?

Thanks,
Sean


From forax at univ-mlv.fr  Wed Dec 17 18:49:20 2014
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 17 Dec 2014 19:49:20 +0100
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <54915954.6090804@oracle.com>
References: <54915954.6090804@oracle.com>
Message-ID: <5491D030.2010307@univ-mlv.fr>


On 12/17/2014 11:22 AM, Lev Priima wrote:
> Hi,
>
> Please review space optimization in no args String constructor. 
> Originally, it was already rejected once by suggestion in 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010300.html 
> w/o formal justification of pros and contras.  And enhancement was 
> requested again by Nathan Reynolds.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8067471
> Patch: http://cr.openjdk.java.net/~lpriima/8067471/webrev.00/
>

Hi Lev,
new String() is usually used by beginners that forget or doesn't know 
that you they can use "" instead.
There is only one legit usage when you want a NullObject for a String 
*and* you don't want to have a shared reference (something visible by 
everybody).

You find 4 occurences of new String() in the JDK,
 > jdk.httpserver/share/classes/sun/net/httpserver/Request.java:200: v = 
new String();
 > java.base/share/classes/sun/net/www/MessageHeader.java:508: v = new 
String();
 > 
java.base/share/classes/java/lang/invoke/MethodHandles.java:829:MethodType 
MT_newString = methodType(void.class); //()V for new String()
 > 
jdk.runtime/share/classes/sun/security/tools/policytool/PolicyTool.java:947: 
String stringEntry = new String();

For the first two, the code is very similar and "" can be used instead 
of new String().
The third occurence is just a comment.
The last occurence is typically a code written by a beginner, the code 
use String.concat, do a kind of defensive copy on String (line 967). 
Again, "" can be used instead of new String().

so my suggestion is to wait to have more information from Nathan 
Reynolds before trying to fix something,
new String() is not the only way to have a String with an empty char array.

cheers,
R?mi





From martinrb at google.com  Wed Dec 17 18:54:26 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 17 Dec 2014 10:54:26 -0800
Subject: [concurrency-interest] RFR: 8065804: JEP 171:
	Clarifications/corrections for fence intrinsics
In-Reply-To: <54914CBE.2000201@gmail.com>
References: <CA+kOe0-Gjmipv7kuWEs-Q5pEMeDZ7mEof=py_3c2Lp+QjX57oQ@mail.gmail.com>
	<NFBBKALFDCPFIDBNKAPCIEDMKLAA.davidcholmes@aapt.net.au>
	<CA+kOe08CtsoDNzcMEyRo91XR1DO+CqDggwha4gW1VR0LhsAaKQ@mail.gmail.com>
	<5481108A.3030605@oracle.com>
	<CA+kOe08OC57hEgGR-3CSfsJUMVSk-_mCmZK2Gd=3tpkE9=6j_w@mail.gmail.com>
	<5488B4EF.6060103@redhat.com> <5488EB09.9000501@oracle.com>
	<54895EFB.3060204@redhat.com>
	<CA+kOe0_QOXi=mvLdXvYn4EF4J54HKDJVo=S4VBDUjujtpzgYzw@mail.gmail.com>
	<5490EA49.2050406@oracle.com> <54914CBE.2000201@gmail.com>
Message-ID: <CA+kOe0-+78XNH84MMXvxUex6kRu6JhENd2WVGXbSktUj_MGd8w@mail.gmail.com>

On Wed, Dec 17, 2014 at 1:28 AM, Peter Levart <peter.levart at gmail.com> wrote:
> On 12/17/2014 03:28 AM, David Holmes wrote:
>>
>> On 17/12/2014 10:06 AM, Martin Buchholz wrote:
>> Hans allows for the nonsensical, in my view, possibility that the load of
>> x.a can happen after the x_init=true store and yet somehow be subject to the
>> ++ and the ensuing store that has to come before the x_init = true.
>
> Perhaps, he is speaking about why it is dangerous to replace BOTH release
> with just store-store AND acquire with just load-load?

I'm pretty sure he's talking about weakening EITHER.

"""Clearly, and unsurprisingly, it is unsafe to replace the
load_acquire with a version that restricts only load ordering in this
case. That would allow the store to x in thread 2 to become visible
before the initialization of x by thread 1 is complete, possibly
losing the update, or corrupting the state of x during initialization.

More interestingly, it is also generally unsafe to restrict the
release ordering constraint in thread 1 to only stores."""

(What's "clear and unsurprising" to Hans may not be to the rest of us)


From peter.levart at gmail.com  Thu Dec 18 08:26:17 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 18 Dec 2014 09:26:17 +0100
Subject: FilePermission Canonical path optimization
In-Reply-To: <5491CD2B.5090807@oracle.com>
References: <CADsbJLkcWYNgduuibYQbNG7-0f9jxG_QqoO30jtcqsrE6BHAxA@mail.gmail.com>	<547C6432.5050003@oracle.com>	<CADsbJLkL_NE0GbT_uB3xwSZc+XYi1dHACabwjCApaXr=h-UkLQ@mail.gmail.com>	<CADsbJL=8k6PB9qD7mAP4GhtpGfC9876N1o8GF-Eq64Ly=FKHtA@mail.gmail.com>	<5481AC6E.9060706@gmail.com>
	<5491CD2B.5090807@oracle.com>
Message-ID: <54928FA9.1060202@gmail.com>

On 12/17/2014 07:36 PM, Sean Mullan wrote:
> On 12/05/2014 08:00 AM, Peter Levart wrote:
>> The question is what to do with the remaining data race that was present
>> before. The 'mask' field. The best would be to make it final, but
>> deserialization needs to set it.
>
> I don't see the pre-existing race condition on the mask field, but I'm 
> probably missing something subtle. Can you provide more details?
>
> Thanks,
> Sean

Hi Sean,

When an object initializes it's non-final fields in constructor and is 
then published unsafely (via data race) to other threads, it can be 
observed not fully initialized in other threads (because of reordering 
of stores and loads by compiler and/or architecture). The blame is 
usually on the code that unsafely publishes references to such objects, 
but if a class is part of security infrastructure then such unsafe 
publication can be intentional and used to compromise security. If other 
code makes use of unsafely published FilePermission objects not 
possible, then this is just theoretical. On the other hand, who can make 
sure that such use will not be possible in the future?

Regards, Peter



From peter.levart at gmail.com  Thu Dec 18 13:23:35 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 18 Dec 2014 14:23:35 +0100
Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file
	descriptors
Message-ID: <5492D557.2000807@gmail.com>

Hi,

I propose a patch for the following issue:

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

Here's the webrev:

http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.01/

The patch uses a package-private FileInputStreamPool class that caches 
open FileInputStream(s) so that at most one file descriptor is open for 
a particular file. Reading from shared unbuffered FileInputStream in 
multiple threads should be safe, right? If not, some synchronization on 
Java side will be necessary. This should not impact concurrent 
performance much since we are using the streams to read from /dev/random 
or /dev/urandom which are secure random generators with shared state and 
must therefore have their own internal synchronization.

52 jtreg tests in sun/security/provider pass with or without this patch, 
3 tests that fail are:

sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.java: 
Make sure that when no system policy and user policy files exist, the 
built-in default policy will be used, which - amongst other things - 
grants standard extensions the AllPermission.
sun/security/provider/PolicyParser/ExtDirsChange.java: standard 
extensions path is hard-coded in default system policy file
sun/security/provider/PolicyParser/PrincipalExpansionError.java: parser 
incorrectly ignores a principal if the principal name expands to nothing.

...they are unrelated to this patch - seems to be caused by recent 
layout changes for modular runtime images.


Regards, Peter



From pavel.rappo at oracle.com  Thu Dec 18 13:32:23 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 18 Dec 2014 13:32:23 +0000
Subject: RFR JDK-8067870: Fix java.io.ObjectInputStream.PeekInputStream#skip 
Message-ID: <698EC617-8F58-4193-A60F-190DC33C034F@oracle.com>

Hi everyone,

Could you please review my change for JDK-8067870?

http://cr.openjdk.java.net/~prappo/8067870/webrev.00/

-------------------------------------------------------------------------------
I suppose it's the first time this method gets executed. Ever :) There's no need
for a test to be included with the change but for those who want to see the
error with their own eyes, you can run this:

import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.lang.reflect.Constructor;

public class PeekInputStreamTest {

    public static void main(String[] args) throws ReflectiveOperationException, IOException {

        Class<? extends InputStream> clazz =
                Class.forName("java.io.ObjectInputStream$PeekInputStream")
                        .asSubclass(InputStream.class);

        Constructor<? extends InputStream> ctr =
                clazz.getDeclaredConstructor(InputStream.class);

        ctr.setAccessible(true);

        ByteArrayInputStream in = new ByteArrayInputStream(new byte[4]);

        InputStream peek = ctr.newInstance(in);

        peek.skip(1);
    }
}

This should produce StackOverflowError.
To be sure that the fix worked as intended, you can run this:

import java.io.ByteArrayInputStream;
import java.io.IOException;
import java.io.InputStream;
import java.lang.reflect.Constructor;
import java.lang.reflect.Method;

public class PeekInputStreamTest {

    public static void main(String[] args) throws ReflectiveOperationException,
            IOException {

        InputStream pin = createPeekInputStream(
                new ByteArrayInputStream(new byte[]{1, 2, 3, 4}));
        peek(pin);
        if (pin.skip(1) != 1 || pin.read() != 2)
            throw new AssertionError();

        InputStream pin1 = createPeekInputStream(
                new ByteArrayInputStream(new byte[]{1, 2, 3, 4}));
        if (pin1.skip(1) != 1 || pin1.read() != 2)
            throw new AssertionError();

        InputStream pin2 = createPeekInputStream(
                new ByteArrayInputStream(new byte[]{1, 2, 3, 4}));
        if (pin2.skip(0) != 0 || pin2.read() != 1)
            throw new AssertionError();

        InputStream pin3 = createPeekInputStream(
                new ByteArrayInputStream(new byte[]{1, 2, 3, 4}));
        if (pin3.skip(2) != 2 || pin3.read() != 3)
            throw new AssertionError();

        InputStream pin4 = createPeekInputStream(
                new ByteArrayInputStream(new byte[]{1, 2, 3, 4}));
        if (pin4.skip(3) != 3 || pin4.read() != 4)
            throw new AssertionError();

        InputStream pin5 = createPeekInputStream(
                new ByteArrayInputStream(new byte[]{1, 2, 3, 4}));
        if (pin5.skip(16) != 4 || pin5.read() != -1)
            throw new AssertionError();
    }

    private static InputStream createPeekInputStream(InputStream underlying)
            throws ReflectiveOperationException {
        Class<? extends InputStream> clazz =
                Class.forName("java.io.ObjectInputStream$PeekInputStream")
                        .asSubclass(InputStream.class);

        Constructor<? extends InputStream> ctr =
                clazz.getDeclaredConstructor(InputStream.class);
        ctr.setAccessible(true);
        return ctr.newInstance(underlying);
    }

    private static void peek(InputStream pin)
            throws ReflectiveOperationException {
        Method p = pin.getClass().getDeclaredMethod("peek");
        p.setAccessible(true);
        p.invoke(pin);
    }
}

The output should be clean.

-Pavel


From roger.riggs at oracle.com  Thu Dec 18 14:21:10 2014
From: roger.riggs at oracle.com (roger riggs)
Date: Thu, 18 Dec 2014 09:21:10 -0500
Subject: RFR JDK-8067870: Fix
	java.io.ObjectInputStream.PeekInputStream#skip
In-Reply-To: <698EC617-8F58-4193-A60F-190DC33C034F@oracle.com>
References: <698EC617-8F58-4193-A60F-190DC33C034F@oracle.com>
Message-ID: <5492E2D6.6030305@oracle.com>

Hi Pavel,

The change looks ok.

But since you're written the test and used it to demonstrate it works, 
it is useful and
with the application of the normal test coding conventions should be 
added as the
regression test for the issue.

Thanks, Roger

On 12/18/2014 8:32 AM, Pavel Rappo wrote:
> Hi everyone,
>
> Could you please review my change for JDK-8067870?
>
> http://cr.openjdk.java.net/~prappo/8067870/webrev.00/
>
> -------------------------------------------------------------------------------
> I suppose it's the first time this method gets executed. Ever :) There's no need
> for a test to be included with the change but for those who want to see the
> error with their own eyes, you can run this:
>
> import java.io.ByteArrayInputStream;
> import java.io.IOException;
> import java.io.InputStream;
> import java.lang.reflect.Constructor;
>
> public class PeekInputStreamTest {
>
>      public static void main(String[] args) throws ReflectiveOperationException, IOException {
>
>          Class<? extends InputStream> clazz =
>                  Class.forName("java.io.ObjectInputStream$PeekInputStream")
>                          .asSubclass(InputStream.class);
>
>          Constructor<? extends InputStream> ctr =
>                  clazz.getDeclaredConstructor(InputStream.class);
>
>          ctr.setAccessible(true);
>
>          ByteArrayInputStream in = new ByteArrayInputStream(new byte[4]);
>
>          InputStream peek = ctr.newInstance(in);
>
>          peek.skip(1);
>      }
> }
>
> This should produce StackOverflowError.
> To be sure that the fix worked as intended, you can run this:
>
> import java.io.ByteArrayInputStream;
> import java.io.IOException;
> import java.io.InputStream;
> import java.lang.reflect.Constructor;
> import java.lang.reflect.Method;
>
> public class PeekInputStreamTest {
>
>      public static void main(String[] args) throws ReflectiveOperationException,
>              IOException {
>
>          InputStream pin = createPeekInputStream(
>                  new ByteArrayInputStream(new byte[]{1, 2, 3, 4}));
>          peek(pin);
>          if (pin.skip(1) != 1 || pin.read() != 2)
>              throw new AssertionError();
>
>          InputStream pin1 = createPeekInputStream(
>                  new ByteArrayInputStream(new byte[]{1, 2, 3, 4}));
>          if (pin1.skip(1) != 1 || pin1.read() != 2)
>              throw new AssertionError();
>
>          InputStream pin2 = createPeekInputStream(
>                  new ByteArrayInputStream(new byte[]{1, 2, 3, 4}));
>          if (pin2.skip(0) != 0 || pin2.read() != 1)
>              throw new AssertionError();
>
>          InputStream pin3 = createPeekInputStream(
>                  new ByteArrayInputStream(new byte[]{1, 2, 3, 4}));
>          if (pin3.skip(2) != 2 || pin3.read() != 3)
>              throw new AssertionError();
>
>          InputStream pin4 = createPeekInputStream(
>                  new ByteArrayInputStream(new byte[]{1, 2, 3, 4}));
>          if (pin4.skip(3) != 3 || pin4.read() != 4)
>              throw new AssertionError();
>
>          InputStream pin5 = createPeekInputStream(
>                  new ByteArrayInputStream(new byte[]{1, 2, 3, 4}));
>          if (pin5.skip(16) != 4 || pin5.read() != -1)
>              throw new AssertionError();
>      }
>
>      private static InputStream createPeekInputStream(InputStream underlying)
>              throws ReflectiveOperationException {
>          Class<? extends InputStream> clazz =
>                  Class.forName("java.io.ObjectInputStream$PeekInputStream")
>                          .asSubclass(InputStream.class);
>
>          Constructor<? extends InputStream> ctr =
>                  clazz.getDeclaredConstructor(InputStream.class);
>          ctr.setAccessible(true);
>          return ctr.newInstance(underlying);
>      }
>
>      private static void peek(InputStream pin)
>              throws ReflectiveOperationException {
>          Method p = pin.getClass().getDeclaredMethod("peek");
>          p.setAccessible(true);
>          p.invoke(pin);
>      }
> }
>
> The output should be clean.
>
> -Pavel



From Alan.Bateman at oracle.com  Thu Dec 18 14:25:19 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 18 Dec 2014 14:25:19 +0000
Subject: RFR JDK-8067870: Fix
	java.io.ObjectInputStream.PeekInputStream#skip
In-Reply-To: <698EC617-8F58-4193-A60F-190DC33C034F@oracle.com>
References: <698EC617-8F58-4193-A60F-190DC33C034F@oracle.com>
Message-ID: <5492E3CF.1090404@oracle.com>

On 18/12/2014 13:32, Pavel Rappo wrote:
> Hi everyone,
>
> Could you please review my change for JDK-8067870?
>
> http://cr.openjdk.java.net/~prappo/8067870/webrev.00/
>
> -------------------------------------------------------------------------------
> I suppose it's the first time this method gets executed. Ever :)
Probably just not interesting to do on a serialized stream.

Your change looks good (and well spotted). I agree with Roger about 
converting what you have into a test to push with the fix.

-Alan


From pavel.rappo at oracle.com  Thu Dec 18 15:06:18 2014
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 18 Dec 2014 15:06:18 +0000
Subject: RFR JDK-8067870: Fix
	java.io.ObjectInputStream.PeekInputStream#skip
In-Reply-To: <5492E3CF.1090404@oracle.com>
References: <698EC617-8F58-4193-A60F-190DC33C034F@oracle.com>
	<5492E3CF.1090404@oracle.com>
Message-ID: <59EDBCFB-0CBB-49C1-A29E-D39F162103C8@oracle.com>

Updated webrev: http://cr.openjdk.java.net/~prappo/8067870/webrev.01/
Will push as soon as I see test results.

P.S. The thing was lurking there since 28-NOV-2000, ver. 1.106

-Pavel

> On 18 Dec 2014, at 14:25, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> On 18/12/2014 13:32, Pavel Rappo wrote:
>> Hi everyone,
>> 
>> Could you please review my change for JDK-8067870?
>> 
>> http://cr.openjdk.java.net/~prappo/8067870/webrev.00/
>> 
>> -------------------------------------------------------------------------------
>> I suppose it's the first time this method gets executed. Ever :)
> Probably just not interesting to do on a serialized stream.
> 
> Your change looks good (and well spotted). I agree with Roger about converting what you have into a test to push with the fix.
> 
> -Alan



From huizhe.wang at oracle.com  Thu Dec 18 21:24:17 2014
From: huizhe.wang at oracle.com (huizhe wang)
Date: Thu, 18 Dec 2014 13:24:17 -0800
Subject: RFR (JAXP): 8054196: XPath: support any type
Message-ID: <54934601.4010104@oracle.com>

Hi,

This is to add support for any type and improvement with new features 
reflected in the new evaluateExpression methods, XPathEvaluationResult 
and XPathNodes.

https://bugs.openjdk.java.net/browse/JDK-8054196
http://cr.openjdk.java.net/~joehw/jdk9/8054196/webrev/

Thanks,
Joe


From bradford.wetmore at oracle.com  Thu Dec 18 22:03:07 2014
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Thu, 18 Dec 2014 14:03:07 -0800
Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file
	descriptors
In-Reply-To: <5492D557.2000807@gmail.com>
References: <5492D557.2000807@gmail.com>
Message-ID: <54934F1B.6060900@oracle.com>

Peter,

Thanks for looking into this.

I'll in the middle of reviewing your change (and TLR/SplittableRandom 
reply), but have several appointments over the next few days.

But did want to respond to:

> sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.java:
> Make sure that when no system policy and user policy files exist, the
> built-in default policy will be used, which - amongst other things -
> grants standard extensions the AllPermission.
> sun/security/provider/PolicyParser/ExtDirsChange.java: standard
> extensions path is hard-coded in default system policy file
> sun/security/provider/PolicyParser/PrincipalExpansionError.java: parser
> incorrectly ignores a principal if the principal name expands to nothing.
>
> ...they are unrelated to this patch - seems to be caused by recent
> layout changes for modular runtime images.

They've been failing for a while:

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

These tests are all "/manual" so they don't show up in our regular runs 
of JPRT/jtreg, which include -a.

     -a | -automatic | -automagic
                 Any test with /manual will not be run

Thanks,

Brad




From lev.priima at oracle.com  Fri Dec 19 00:41:30 2014
From: lev.priima at oracle.com (Lev Priima)
Date: Fri, 19 Dec 2014 03:41:30 +0300
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <5491C71A.5040107@oracle.com>
References: <54915954.6090804@oracle.com> <5491A817.7040607@oracle.com>
	<5491C71A.5040107@oracle.com>
Message-ID: <5493743A.60904@oracle.com>

Claes,
Thanks for cool suggestion: 
http://cr.openjdk.java.net/~lpriima/8067471/webrev.01/:
   public java.lang.String();
     Signature: ()V
     flags: ACC_PUBLIC
     LineNumberTable:
       line 137: 0
       line 138: 4
       line 139: 13
     Code:
       stack=2, locals=1, args_size=1
          0: aload_0
          1: invokespecial #1                  // Method 
java/lang/Object."<init>":()V
          4: aload_0
          5: ldc           #2                  // String
          7: getfield      #3                  // Field value:[C
         10: putfield      #3                  // Field value:[C
         13: return
       LineNumberTable:
         line 137: 0
         line 138: 4


Aleksey ,
By naive glance, new constructor thrpt is  bigger(jdk9/dev vs 9b42 in 
attach) on:
     @Benchmark
     public String getNewString() {
         return new String();
     }
Please suggest things to compare . Do we have bigapps-like benchmarks 
which may show regression on this?

On 17.12.2014 21:10, Aleksey Shipilev wrote:
> On 17.12.2014 18:58, Claes Redestad wrote:
>> On 2014-12-17 11:22, Lev Priima wrote:
>>> Please review space optimization in no args String constructor.
>>> Originally, it was already rejected once by suggestion in
>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010300.html
>>> w/o formal justification of pros and contras.  And enhancement was
>>> requested again by Nathan Reynolds.
>>>
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8067471
>>> Patch: http://cr.openjdk.java.net/~lpriima/8067471/webrev.00/
> I am OK with this change pending we understand the performance impact a
> little better. Please do benchmarks.
>
>
>> Could this have some obscure security implications, such as the ability
>> to lock up some subsystem via retrieving and synchronizing on the shared
>> new String().value? I guess not, for practical purposes.
> This would be an issue if we published String.value directly, but we don't.
>
>> I guess it could also be written:
>>
>>      public String() {
>>          this.value = "".value;
>>      }
>>
>> ... which would saves some byte code and should avoid having to allocate
>> a distinct object for this.
> Oh, I like this trick, given "" is probably already in constant pool for
> some other reason. However, there is an additional dereference. We need
> a targeted nanobenchmark to properly quantify the costs for either variant.
>
> -Aleksey.
>
>

-- 
Best Regards,
Lev

-------------- next part --------------
# JMH 1.3.4 (released 8 days ago)
# VM invoker: /home/lev/Downloads/9b42/bin/java
# VM options: <none>
# Warmup: 10 iterations, 1 s each
# Measurement: 10 iterations, 1 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: org.sample.MyBenchmark.getEmptyString

# Run progress: 0.00% complete, ETA 00:00:40
# Fork: 1 of 1
# Warmup Iteration   1: 253275307.131 ops/s
# Warmup Iteration   2: 254095116.567 ops/s
# Warmup Iteration   3: 322126895.612 ops/s
# Warmup Iteration   4: 321922181.662 ops/s
# Warmup Iteration   5: 321528859.382 ops/s
# Warmup Iteration   6: 322129274.055 ops/s
# Warmup Iteration   7: 322634217.486 ops/s
# Warmup Iteration   8: 322257029.256 ops/s
# Warmup Iteration   9: 320773906.394 ops/s
# Warmup Iteration  10: 321561537.863 ops/s
Iteration   1: 322106297.965 ops/s
Iteration   2: 322681896.656 ops/s
Iteration   3: 322132279.365 ops/s
Iteration   4: 322677597.123 ops/s
Iteration   5: 322491471.806 ops/s
Iteration   6: 322040955.231 ops/s
Iteration   7: 322462065.350 ops/s
Iteration   8: 322754257.802 ops/s
Iteration   9: 319050435.010 ops/s
Iteration  10: 322166417.156 ops/s


Result: 322056367.347 ??(99.9%) 1646498.649 ops/s [Average]
  Statistics: (min, avg, max) = (319050435.010, 322056367.347, 322754257.802), stdev = 1089056.912
  Confidence interval (99.9%): [320409868.698, 323702865.996]


# JMH 1.3.4 (released 8 days ago)
# VM invoker: /home/lev/Downloads/9b42/bin/java
# VM options: <none>
# Warmup: 10 iterations, 1 s each
# Measurement: 10 iterations, 1 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: org.sample.MyBenchmark.getNewString

# Run progress: 50.00% complete, ETA 00:00:20
# Fork: 1 of 1
# Warmup Iteration   1: 74291443.424 ops/s
# Warmup Iteration   2: 83802467.412 ops/s
# Warmup Iteration   3: 103104138.874 ops/s
# Warmup Iteration   4: 103470664.957 ops/s
# Warmup Iteration   5: 102706809.334 ops/s
# Warmup Iteration   6: 103457900.107 ops/s
# Warmup Iteration   7: 103136090.913 ops/s
# Warmup Iteration   8: 101818117.306 ops/s
# Warmup Iteration   9: 103204890.949 ops/s
# Warmup Iteration  10: 101892885.248 ops/s
Iteration   1: 103815433.249 ops/s
Iteration   2: 102628103.785 ops/s
Iteration   3: 104256153.246 ops/s
Iteration   4: 103840204.572 ops/s
Iteration   5: 104059242.583 ops/s
Iteration   6: 103445534.153 ops/s
Iteration   7: 101184072.111 ops/s
Iteration   8: 102174758.595 ops/s
Iteration   9: 101998940.515 ops/s
Iteration  10: 101669182.081 ops/s


Result: 102907162.489 ??(99.9%) 1676975.032 ops/s [Average]
  Statistics: (min, avg, max) = (101184072.111, 102907162.489, 104256153.246), stdev = 1109215.152
  Confidence interval (99.9%): [101230187.457, 104584137.521]


# Run complete. Total time: 00:00:40

Benchmark                          Mode  Samples          Score         Error  Units
o.s.MyBenchmark.getEmptyString    thrpt       10  322056367.347 ?? 1646498.649  ops/s
o.s.MyBenchmark.getNewString      thrpt       10  102907162.489 ?? 1676975.032  ops/s
-------------- next part --------------
# JMH 1.3.4 (released 8 days ago)
# VM invoker: /home/lev/code/jdk9/dev/build/linux-x86_64-normal-server-release/jdk/bin/java
# VM options: <none>
# Warmup: 10 iterations, 1 s each
# Measurement: 10 iterations, 1 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: org.sample.MyBenchmark.getEmptyString

# Run progress: 0.00% complete, ETA 00:00:40
# Fork: 1 of 1
# Warmup Iteration   1: 252880622.163 ops/s
# Warmup Iteration   2: 253543197.037 ops/s
# Warmup Iteration   3: 322030995.381 ops/s
# Warmup Iteration   4: 322037676.959 ops/s
# Warmup Iteration   5: 322019513.020 ops/s
# Warmup Iteration   6: 321444240.836 ops/s
# Warmup Iteration   7: 322124903.148 ops/s
# Warmup Iteration   8: 322300309.941 ops/s
# Warmup Iteration   9: 322207740.544 ops/s
# Warmup Iteration  10: 322228120.576 ops/s
Iteration   1: 322157282.432 ops/s
Iteration   2: 322760503.442 ops/s
Iteration   3: 322138077.016 ops/s
Iteration   4: 322033221.327 ops/s
Iteration   5: 322614522.040 ops/s
Iteration   6: 321949673.639 ops/s
Iteration   7: 322208486.679 ops/s
Iteration   8: 322728645.401 ops/s
Iteration   9: 322701742.545 ops/s
Iteration  10: 319860751.531 ops/s


Result: 322115290.605 ??(99.9%) 1286188.946 ops/s [Average]
  Statistics: (min, avg, max) = (319860751.531, 322115290.605, 322760503.442), stdev = 850734.352
  Confidence interval (99.9%): [320829101.659, 323401479.551]


# JMH 1.3.4 (released 8 days ago)
# VM invoker: /home/lev/code/jdk9/dev/build/linux-x86_64-normal-server-release/jdk/bin/java
# VM options: <none>
# Warmup: 10 iterations, 1 s each
# Measurement: 10 iterations, 1 s each
# Timeout: 10 min per iteration
# Threads: 1 thread, will synchronize iterations
# Benchmark mode: Throughput, ops/time
# Benchmark: org.sample.MyBenchmark.getNewString

# Run progress: 50.00% complete, ETA 00:00:20
# Fork: 1 of 1
# Warmup Iteration   1: 95384786.922 ops/s
# Warmup Iteration   2: 114919375.499 ops/s
# Warmup Iteration   3: 156152523.678 ops/s
# Warmup Iteration   4: 156669076.485 ops/s
# Warmup Iteration   5: 154457001.474 ops/s
# Warmup Iteration   6: 155779532.552 ops/s
# Warmup Iteration   7: 155481156.649 ops/s
# Warmup Iteration   8: 156513950.903 ops/s
# Warmup Iteration   9: 157269815.082 ops/s
# Warmup Iteration  10: 155383469.586 ops/s
Iteration   1: 155354136.440 ops/s
Iteration   2: 157690383.417 ops/s
Iteration   3: 156088525.012 ops/s
Iteration   4: 155434125.275 ops/s
Iteration   5: 155756683.197 ops/s
Iteration   6: 156746735.419 ops/s
Iteration   7: 172867452.406 ops/s
Iteration   8: 175637166.777 ops/s
Iteration   9: 176995419.709 ops/s
Iteration  10: 175064276.835 ops/s


Result: 163763490.449 ??(99.9%) 14914652.052 ops/s [Average]
  Statistics: (min, avg, max) = (155354136.440, 163763490.449, 176995419.709), stdev = 9865118.875
  Confidence interval (99.9%): [148848838.397, 178678142.500]


# Run complete. Total time: 00:00:40

Benchmark                          Mode  Samples          Score          Error  Units
o.s.MyBenchmark.getEmptyString    thrpt       10  322115290.605 ??  1286188.946  ops/s
o.s.MyBenchmark.getNewString      thrpt       10  163763490.449 ?? 14914652.052  ops/s

From lev.priima at oracle.com  Fri Dec 19 01:42:33 2014
From: lev.priima at oracle.com (Lev Priima)
Date: Fri, 19 Dec 2014 04:42:33 +0300
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <5491D030.2010307@univ-mlv.fr>
References: <54915954.6090804@oracle.com> <5491D030.2010307@univ-mlv.fr>
Message-ID: <54938289.9050805@oracle.com>

Hi R?mi,

Sure this examples will not be affected, but we have to concern about 
other applications which are probably using this constructor. Could you 
suggest such applications?

On 17.12.2014 21:49, Remi Forax wrote:
>
> On 12/17/2014 11:22 AM, Lev Priima wrote:
>> Hi,
>>
>> Please review space optimization in no args String constructor. 
>> Originally, it was already rejected once by suggestion in 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010300.html 
>> w/o formal justification of pros and contras.  And enhancement was 
>> requested again by Nathan Reynolds.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8067471
>> Patch: http://cr.openjdk.java.net/~lpriima/8067471/webrev.00/
>>
>
> Hi Lev,
> new String() is usually used by beginners that forget or doesn't know 
> that you they can use "" instead.
>
> There is only one legit usage when you want a NullObject for a String 
> *and* you don't want to have a shared reference (something visible by 
> everybody).
One legit usage of which code?
> You find 4 occurences of new String() in the JDK,
> > jdk.httpserver/share/classes/sun/net/httpserver/Request.java:200: v 
> = new String();
> > java.base/share/classes/sun/net/www/MessageHeader.java:508: v = new 
> String();
> > 
> java.base/share/classes/java/lang/invoke/MethodHandles.java:829:MethodType 
> MT_newString = methodType(void.class); //()V for new String()
> > 
> jdk.runtime/share/classes/sun/security/tools/policytool/PolicyTool.java:947: 
> String stringEntry = new String();
>
> For the first two, the code is very similar and "" can be used instead 
> of new String().
> The third occurence is just a comment.
just comment to review all MH libs (e.g. nashorn) for such kind of code:
import static java.lang.invoke.MethodHandles.*;
import static java.lang.invoke.MethodType.*;
publicLookup().findConstructor(String.class, methodType(void.class) 
).invokeExact();
and more implicit variations.
> The last occurence is typically a code written by a beginner, the code 
> use String.concat, do a kind of defensive copy on String (line 967). 
> Again, "" can be used instead of new String().
>
> so my suggestion is to wait to have more information from Nathan 
> Reynolds before trying to fix something,
> new String() is not the only way to have a String with an empty char 
> array.
>
> cheers,
> R?mi
>
>
>

-- 
Best Regards,
Lev



From felix.yang at oracle.com  Fri Dec 19 09:56:13 2014
From: felix.yang at oracle.com (FELIX YANG)
Date: Fri, 19 Dec 2014 17:56:13 +0800
Subject: RFR 8066085: Need a sanity test for rmic -iiop
In-Reply-To: <548AA276.7080701@oracle.com>
References: <548A71E7.8000209@oracle.com> <548AA276.7080701@oracle.com>
Message-ID: <5493F63D.6030702@oracle.com>

Hi Stuart,
     please review the updated webrev:
http://cr.openjdk.java.net/~xiaofeya/8066085/webrev.01/

Thanks,
-Felix
On 12/12/2014 4:08 PM, Stuart Marks wrote:
> On 12/11/14 8:41 PM, FELIX YANG wrote:
>> Hi all,
>>      please review the fix to add a sanity checking for rmic -iiop 
>> compiling.
>>
>> Bug:
>>         https://bugs.openjdk.java.net/browse/JDK-8066085
>>
>> Webrev:
>>         http://cr.openjdk.java.net/~xiaofeya/8066085/webrev.00/
>
> Hi Felix,
>
> Thanks for picking up the writing of this test. I have several comments.
>
> 1. Usually we try to avoid naming tests after bug IDs. There are such 
> tests in the suite but most tests have more descriptive names. I'd 
> suggest something like "iiopSanityTest".
>
> 2. There are other rmic tests in jdk/test/sun/rmi/rmic; the test 
> should be moved there (and the path to the TestLibrary updated 
> correspondingly).
>
> 3. The test summary should be a bit more explicit. Instead of "a 
> sanity test for rmic -iiop compiling" I'd suggest something like 
> "Compiles a PortableRemoteObject with rmic -iiop and ensures that stub 
> and tie classes are generated."
>
> 4. When invoking rmic, you need to make sure to pass the -iiop option.
>
> 5. Add check for the _Tie class as well as the _Stub class. Not that 
> it really matters, since we know these classes are in the unnamed 
> package, but the stub and tie class files would end up in directories 
> corresponding to their package names -- if they were in a named package.
>
> 6. In doTest(), the try/catch of InterruptedException and IOException 
> and call to TestLibrary.bomb() is mostly unnecessary. (Yes, other RMI 
> tests do this, and I've been removing it where appropriate. In the RMI 
> test library, the bomb() call merely wraps and rethrows the exception, 
> and doesn't really add any value. It's like calling fail() in a 
> test-ng test.) In general an uncaught exception will cause a jtreg 
> test to fail, so you might as well just declare the method with 
> "throws Exception" and let them propagate. This helps reduce clutter.
>
> 7. Similarly I'm not sure it's necessary to check the classname 
> argument for null; the failure should be apparent enough if classname 
> is null. But if you think it's worth it, a concise way to null-check 
> an argument is to use Objects.requireNonNull().
>
> 8. The "rmiComplie" method is misnamed (or typo'd); I'd suggest 
> something like "runRmic".
>
> 9. Changing the directory of the rmic subprocess is confusing, because 
> it makes different parts of the program deal with different paths to 
> the same files. In addition, switching directories to the test.classes 
> directory will leave the stub/tie classes there, which could possibly 
> confuse future test runs, since that directory isn't necessarily 
> cleared between test runs.
>
> The default working directory of jtreg tests is the "scratch" 
> directory, which is cleared before each test run. Leaving the current 
> directory as-is when running the subprocesses will write the generated 
> stub/tie classes to the scratch directory, which is the right thing.
>
> This implies that you'll need to add the -classpath argument and a 
> path to the test.classes directory to the rmic command line.
>
> Thanks,
>
> s'marks
>
>



From aleksey.shipilev at oracle.com  Fri Dec 19 13:11:51 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 19 Dec 2014 16:11:51 +0300
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <5493743A.60904@oracle.com>
References: <54915954.6090804@oracle.com>
	<5491A817.7040607@oracle.com>	<5491C71A.5040107@oracle.com>
	<5493743A.60904@oracle.com>
Message-ID: <54942417.2080905@oracle.com>

On 12/19/2014 03:41 AM, Lev Priima wrote:
> By naive glance, new constructor thrpt is  bigger(jdk9/dev vs 9b42
> in attach) on:
>     @Benchmark
>     public String getNewString() {
>         return new String();
>     }

This is how you do it:
 http://cr.openjdk.java.net/~shade/8067471/
 http://cr.openjdk.java.net/~shade/8067471/performance.txt

In short, I don't see any show-stoppers here.

> Please suggest things to compare . Do we have bigapps-like benchmarks
> which may show regression on this?

Not sure if there is such a benchmark in our pool. You may run
SPECjbb2005 and SPECjvm2008 to double-check.

Thanks,
-Aleksey.



From claes.redestad at oracle.com  Fri Dec 19 14:25:39 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 19 Dec 2014 15:25:39 +0100
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <5493743A.60904@oracle.com>
References: <54915954.6090804@oracle.com>
	<5491A817.7040607@oracle.com>	<5491C71A.5040107@oracle.com>
	<5493743A.60904@oracle.com>
Message-ID: <54943563.2070706@oracle.com>

Hi again,

I just had a nagging thought. For applications reporting some or a lot 
of different empty String objects,
this might be due not to use of this constructor, but due to things like 
an empty StringBuilder.toString() ending
up calling java.lang.String(char[] value, int offset, int count) with a 
count of 0.

My feeling is that this would be a more probable/reasonable source of 
distinct empty strings in an application,
and would not be helped much by the current patch.

For completeness the java.lang.String(char/int[], int, int) constructors 
could have a check for count == 0 in
which case it assigns value to "".value, see 
http://cr.openjdk.java.net/~redestad/8067471/webrev.01/

Running a few simple microbenchmarks on this (sorry, Aleksey!)[1] yields 
a bit of speedup, at no discernible
cost for a quick sanity check of an actually copying path:

baseline:
Benchmark                            Mode  Samples    Score Error   Units
o.s.SimpleBench.emptySBBench        thrpt        5   48.213 ? 3.509  ops/us
o.s.SimpleBench.emptyString         thrpt        5  103.900 ? 4.869  ops/us
o.s.SimpleBench.emptyStringCount    thrpt        5  105.802 ? 3.355  ops/us
o.s.SimpleBench.emptyStringCountCP  thrpt        5  104.464 ? 8.251  ops/us
o.s.SimpleBench.singleStringCount   thrpt        5   76.379 ? 4.139  ops/us
o.s.SimpleBench.singleStringCountCP thrpt        5   88.202 ? 4.945  ops/us

experiment:
Benchmark                            Mode  Samples    Score Error   Units
o.s.SimpleBench.emptySBBench        thrpt        5  153.822 ? 7.900  
ops/us 3x
o.s.SimpleBench.emptyString         thrpt        5  183.588 ? 4.429  
ops/us 1.75x
o.s.SimpleBench.emptyStringCount    thrpt        5  166.457 ? 9.202  
ops/us 1.6x
o.s.SimpleBench.emptyStringCountCP  thrpt        5  168.089 ? 4.676  
ops/us 1.6x
o.s.SimpleBench.singleStringCount   thrpt        5   75.780 ? 8.490  
ops/us 1x
o.s.SimpleBench.singleStringCountCP thrpt        5   89.202 ? 3.714  
ops/us 1x

I guess we'd need to check that compiled code don't get messed up for a 
mix of inputs where count can be both
zero and non-zero with some probability.

/Claes

[1] public char[] emptyCharArray = new char[0];
     public int[] emptyIntArray = new int[0];

     public char[] singleCharArray = new char[] { 'x' };
     public int[] singleIntArray = new int[] { 102 };
     public StringBuilder emptySB = new StringBuilder();

     @Benchmark
     public String emptySBBench() {
         return emptySB.toString();
     }

     @Benchmark
     public String emptyString() {
         return new String();
     }

     @Benchmark
     public String emptyStringCount() {
         return new String(emptyCharArray, 0, 0);
     }

     @Benchmark
     public String emptyStringCountCP() {
         return new String(emptyIntArray, 0, 0);
     }

     @Benchmark
     public String singleStringCount() {
         return new String(singleCharArray, 0, 1);
     }

     @Benchmark
     public String singleStringCountCP() {
         return new String(singleIntArray, 0, 1);
     }


On 2014-12-19 01:41, Lev Priima wrote:
> Claes,
> Thanks for cool suggestion: 
> http://cr.openjdk.java.net/~lpriima/8067471/webrev.01/:
>   public java.lang.String();
>     Signature: ()V
>     flags: ACC_PUBLIC
>     LineNumberTable:
>       line 137: 0
>       line 138: 4
>       line 139: 13
>     Code:
>       stack=2, locals=1, args_size=1
>          0: aload_0
>          1: invokespecial #1                  // Method 
> java/lang/Object."<init>":()V
>          4: aload_0
>          5: ldc           #2                  // String
>          7: getfield      #3                  // Field value:[C
>         10: putfield      #3                  // Field value:[C
>         13: return
>       LineNumberTable:
>         line 137: 0
>         line 138: 4
>
>
> Aleksey ,
> By naive glance, new constructor thrpt is  bigger(jdk9/dev vs 9b42 in 
> attach) on:
>     @Benchmark
>     public String getNewString() {
>         return new String();
>     }
> Please suggest things to compare . Do we have bigapps-like benchmarks 
> which may show regression on this?
>
> On 17.12.2014 21:10, Aleksey Shipilev wrote:
>> On 17.12.2014 18:58, Claes Redestad wrote:
>>> On 2014-12-17 11:22, Lev Priima wrote:
>>>> Please review space optimization in no args String constructor.
>>>> Originally, it was already rejected once by suggestion in
>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010300.html 
>>>>
>>>> w/o formal justification of pros and contras.  And enhancement was
>>>> requested again by Nathan Reynolds.
>>>>
>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8067471
>>>> Patch: http://cr.openjdk.java.net/~lpriima/8067471/webrev.00/
>> I am OK with this change pending we understand the performance impact a
>> little better. Please do benchmarks.
>>
>>
>>> Could this have some obscure security implications, such as the ability
>>> to lock up some subsystem via retrieving and synchronizing on the 
>>> shared
>>> new String().value? I guess not, for practical purposes.
>> This would be an issue if we published String.value directly, but we 
>> don't.
>>
>>> I guess it could also be written:
>>>
>>>      public String() {
>>>          this.value = "".value;
>>>      }
>>>
>>> ... which would saves some byte code and should avoid having to 
>>> allocate
>>> a distinct object for this.
>> Oh, I like this trick, given "" is probably already in constant pool for
>> some other reason. However, there is an additional dereference. We need
>> a targeted nanobenchmark to properly quantify the costs for either 
>> variant.
>>
>> -Aleksey.
>>
>>
>



From lev.priima at oracle.com  Sun Dec 21 15:37:35 2014
From: lev.priima at oracle.com (Lev Priima)
Date: Sun, 21 Dec 2014 18:37:35 +0300
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <54942417.2080905@oracle.com>
References: <54915954.6090804@oracle.com>
	<5491A817.7040607@oracle.com>	<5491C71A.5040107@oracle.com>
	<5493743A.60904@oracle.com> <54942417.2080905@oracle.com>
Message-ID: <5496E93F.803@oracle.com>

Aleksey,

Thanks for exhaustive research. Looks formal enough to claim that both 
variants of change bring only perf advantages, but, as I understand, 
which one is better is not so straightforward.

On 12/19/2014 04:11 PM, Aleksey Shipilev wrote:
> On 12/19/2014 03:41 AM, Lev Priima wrote:
>> By naive glance, new constructor thrpt is  bigger(jdk9/dev vs 9b42
>> in attach) on:
>>      @Benchmark
>>      public String getNewString() {
>>          return new String();
>>      }
> This is how you do it:
>   http://cr.openjdk.java.net/~shade/8067471/
>   http://cr.openjdk.java.net/~shade/8067471/performance.txt
>
> In short, I don't see any show-stoppers here.
>
>> Please suggest things to compare . Do we have bigapps-like benchmarks
>> which may show regression on this?
> Not sure if there is such a benchmark in our pool. You may run
> SPECjbb2005 and SPECjvm2008 to double-check.
>
> Thanks,
> -Aleksey.
>

-- 
Best Regards,
Lev



From ivan.gerasimov at oracle.com  Fri Dec 19 15:36:05 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 19 Dec 2014 18:36:05 +0300
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <54943563.2070706@oracle.com>
References: <54915954.6090804@oracle.com>	<5491A817.7040607@oracle.com>	<5491C71A.5040107@oracle.com>	<5493743A.60904@oracle.com>
	<54943563.2070706@oracle.com>
Message-ID: <549445E5.902@oracle.com>

Hi everyone!

I guess something like the following might be used to avoid slowing down 
the common route:

  194         if (count <= 0) {
                  if (count == 0) {
                      this.value = "".value;
                  }
  195             throw new StringIndexOutOfBoundsException(count);
  196         }


Sincerely yours,
Ivan


On 19.12.2014 17:25, Claes Redestad wrote:
> Hi again,
>
> I just had a nagging thought. For applications reporting some or a lot 
> of different empty String objects,
> this might be due not to use of this constructor, but due to things 
> like an empty StringBuilder.toString() ending
> up calling java.lang.String(char[] value, int offset, int count) with 
> a count of 0.
>
> My feeling is that this would be a more probable/reasonable source of 
> distinct empty strings in an application,
> and would not be helped much by the current patch.
>
> For completeness the java.lang.String(char/int[], int, int) 
> constructors could have a check for count == 0 in
> which case it assigns value to "".value, see 
> http://cr.openjdk.java.net/~redestad/8067471/webrev.01/
>
> Running a few simple microbenchmarks on this (sorry, Aleksey!)[1] 
> yields a bit of speedup, at no discernible
> cost for a quick sanity check of an actually copying path:
>
> baseline:
> Benchmark                            Mode  Samples    Score Error   Units
> o.s.SimpleBench.emptySBBench        thrpt        5   48.213 ? 3.509  
> ops/us
> o.s.SimpleBench.emptyString         thrpt        5  103.900 ? 4.869  
> ops/us
> o.s.SimpleBench.emptyStringCount    thrpt        5  105.802 ? 3.355  
> ops/us
> o.s.SimpleBench.emptyStringCountCP  thrpt        5  104.464 ? 8.251  
> ops/us
> o.s.SimpleBench.singleStringCount   thrpt        5   76.379 ? 4.139  
> ops/us
> o.s.SimpleBench.singleStringCountCP thrpt        5   88.202 ? 4.945  
> ops/us
>
> experiment:
> Benchmark                            Mode  Samples    Score Error   Units
> o.s.SimpleBench.emptySBBench        thrpt        5  153.822 ? 7.900  
> ops/us 3x
> o.s.SimpleBench.emptyString         thrpt        5  183.588 ? 4.429  
> ops/us 1.75x
> o.s.SimpleBench.emptyStringCount    thrpt        5  166.457 ? 9.202  
> ops/us 1.6x
> o.s.SimpleBench.emptyStringCountCP  thrpt        5  168.089 ? 4.676  
> ops/us 1.6x
> o.s.SimpleBench.singleStringCount   thrpt        5   75.780 ? 8.490  
> ops/us 1x
> o.s.SimpleBench.singleStringCountCP thrpt        5   89.202 ? 3.714  
> ops/us 1x
>
> I guess we'd need to check that compiled code don't get messed up for 
> a mix of inputs where count can be both
> zero and non-zero with some probability.
>
> /Claes
>
> [1] public char[] emptyCharArray = new char[0];
>     public int[] emptyIntArray = new int[0];
>
>     public char[] singleCharArray = new char[] { 'x' };
>     public int[] singleIntArray = new int[] { 102 };
>     public StringBuilder emptySB = new StringBuilder();
>
>     @Benchmark
>     public String emptySBBench() {
>         return emptySB.toString();
>     }
>
>     @Benchmark
>     public String emptyString() {
>         return new String();
>     }
>
>     @Benchmark
>     public String emptyStringCount() {
>         return new String(emptyCharArray, 0, 0);
>     }
>
>     @Benchmark
>     public String emptyStringCountCP() {
>         return new String(emptyIntArray, 0, 0);
>     }
>
>     @Benchmark
>     public String singleStringCount() {
>         return new String(singleCharArray, 0, 1);
>     }
>
>     @Benchmark
>     public String singleStringCountCP() {
>         return new String(singleIntArray, 0, 1);
>     }
>
>
> On 2014-12-19 01:41, Lev Priima wrote:
>> Claes,
>> Thanks for cool suggestion: 
>> http://cr.openjdk.java.net/~lpriima/8067471/webrev.01/:
>>   public java.lang.String();
>>     Signature: ()V
>>     flags: ACC_PUBLIC
>>     LineNumberTable:
>>       line 137: 0
>>       line 138: 4
>>       line 139: 13
>>     Code:
>>       stack=2, locals=1, args_size=1
>>          0: aload_0
>>          1: invokespecial #1                  // Method 
>> java/lang/Object."<init>":()V
>>          4: aload_0
>>          5: ldc           #2                  // String
>>          7: getfield      #3                  // Field value:[C
>>         10: putfield      #3                  // Field value:[C
>>         13: return
>>       LineNumberTable:
>>         line 137: 0
>>         line 138: 4
>>
>>
>> Aleksey ,
>> By naive glance, new constructor thrpt is  bigger(jdk9/dev vs 9b42 in 
>> attach) on:
>>     @Benchmark
>>     public String getNewString() {
>>         return new String();
>>     }
>> Please suggest things to compare . Do we have bigapps-like benchmarks 
>> which may show regression on this?
>>
>> On 17.12.2014 21:10, Aleksey Shipilev wrote:
>>> On 17.12.2014 18:58, Claes Redestad wrote:
>>>> On 2014-12-17 11:22, Lev Priima wrote:
>>>>> Please review space optimization in no args String constructor.
>>>>> Originally, it was already rejected once by suggestion in
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010300.html 
>>>>>
>>>>> w/o formal justification of pros and contras.  And enhancement was
>>>>> requested again by Nathan Reynolds.
>>>>>
>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8067471
>>>>> Patch: http://cr.openjdk.java.net/~lpriima/8067471/webrev.00/
>>> I am OK with this change pending we understand the performance impact a
>>> little better. Please do benchmarks.
>>>
>>>
>>>> Could this have some obscure security implications, such as the 
>>>> ability
>>>> to lock up some subsystem via retrieving and synchronizing on the 
>>>> shared
>>>> new String().value? I guess not, for practical purposes.
>>> This would be an issue if we published String.value directly, but we 
>>> don't.
>>>
>>>> I guess it could also be written:
>>>>
>>>>      public String() {
>>>>          this.value = "".value;
>>>>      }
>>>>
>>>> ... which would saves some byte code and should avoid having to 
>>>> allocate
>>>> a distinct object for this.
>>> Oh, I like this trick, given "" is probably already in constant pool 
>>> for
>>> some other reason. However, there is an additional dereference. We need
>>> a targeted nanobenchmark to properly quantify the costs for either 
>>> variant.
>>>
>>> -Aleksey.
>>>
>>>
>>
>
>
>



From lev.priima at oracle.com  Sun Dec 21 16:08:26 2014
From: lev.priima at oracle.com (Lev Priima)
Date: Sun, 21 Dec 2014 19:08:26 +0300
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <54943563.2070706@oracle.com>
References: <54915954.6090804@oracle.com>
	<5491A817.7040607@oracle.com>	<5491C71A.5040107@oracle.com>
	<5493743A.60904@oracle.com> <54943563.2070706@oracle.com>
Message-ID: <5496F07A.5010500@oracle.com>

Claes,

Is the source of arrays in these benchmarks unpredictable enough to 
avoid branch checks elimination in compiled code?

On 12/19/2014 05:25 PM, Claes Redestad wrote:
> Hi again,
>
> I just had a nagging thought. For applications reporting some or a lot 
> of different empty String objects,
> this might be due not to use of this constructor, but due to things 
> like an empty StringBuilder.toString() ending
> up calling java.lang.String(char[] value, int offset, int count) with 
> a count of 0.
>
> My feeling is that this would be a more probable/reasonable source of 
> distinct empty strings in an application,
> and would not be helped much by the current patch.
>
> For completeness the java.lang.String(char/int[], int, int) 
> constructors could have a check for count == 0 in
> which case it assigns value to "".value, see 
> http://cr.openjdk.java.net/~redestad/8067471/webrev.01/
>
> Running a few simple microbenchmarks on this (sorry, Aleksey!)[1] 
> yields a bit of speedup, at no discernible
> cost for a quick sanity check of an actually copying path:
>
> baseline:
> Benchmark                            Mode  Samples    Score Error   Units
> o.s.SimpleBench.emptySBBench        thrpt        5   48.213 ? 3.509  
> ops/us
> o.s.SimpleBench.emptyString         thrpt        5  103.900 ? 4.869  
> ops/us
> o.s.SimpleBench.emptyStringCount    thrpt        5  105.802 ? 3.355  
> ops/us
> o.s.SimpleBench.emptyStringCountCP  thrpt        5  104.464 ? 8.251  
> ops/us
> o.s.SimpleBench.singleStringCount   thrpt        5   76.379 ? 4.139  
> ops/us
> o.s.SimpleBench.singleStringCountCP thrpt        5   88.202 ? 4.945  
> ops/us
>
> experiment:
> Benchmark                            Mode  Samples    Score Error   Units
> o.s.SimpleBench.emptySBBench        thrpt        5  153.822 ? 7.900  
> ops/us 3x
> o.s.SimpleBench.emptyString         thrpt        5  183.588 ? 4.429  
> ops/us 1.75x
> o.s.SimpleBench.emptyStringCount    thrpt        5  166.457 ? 9.202  
> ops/us 1.6x
> o.s.SimpleBench.emptyStringCountCP  thrpt        5  168.089 ? 4.676  
> ops/us 1.6x
> o.s.SimpleBench.singleStringCount   thrpt        5   75.780 ? 8.490  
> ops/us 1x
> o.s.SimpleBench.singleStringCountCP thrpt        5   89.202 ? 3.714  
> ops/us 1x
>
> I guess we'd need to check that compiled code don't get messed up for 
> a mix of inputs where count can be both
> zero and non-zero with some probability.
Do we have such benchmarks examples?
>
> /Claes
>
> [1] public char[] emptyCharArray = new char[0];
>     public int[] emptyIntArray = new int[0];
>
>     public char[] singleCharArray = new char[] { 'x' };
>     public int[] singleIntArray = new int[] { 102 };
>     public StringBuilder emptySB = new StringBuilder();
>
>     @Benchmark
>     public String emptySBBench() {
>         return emptySB.toString();
>     }
>
>     @Benchmark
>     public String emptyString() {
>         return new String();
>     }
>
>     @Benchmark
>     public String emptyStringCount() {
>         return new String(emptyCharArray, 0, 0);
>     }
>
>     @Benchmark
>     public String emptyStringCountCP() {
>         return new String(emptyIntArray, 0, 0);
>     }
>
>     @Benchmark
>     public String singleStringCount() {
>         return new String(singleCharArray, 0, 1);
>     }
>
>     @Benchmark
>     public String singleStringCountCP() {
>         return new String(singleIntArray, 0, 1);
>     }
>
>
> On 2014-12-19 01:41, Lev Priima wrote:
>> Claes,
>> Thanks for cool suggestion: 
>> http://cr.openjdk.java.net/~lpriima/8067471/webrev.01/:
>>   public java.lang.String();
>>     Signature: ()V
>>     flags: ACC_PUBLIC
>>     LineNumberTable:
>>       line 137: 0
>>       line 138: 4
>>       line 139: 13
>>     Code:
>>       stack=2, locals=1, args_size=1
>>          0: aload_0
>>          1: invokespecial #1                  // Method 
>> java/lang/Object."<init>":()V
>>          4: aload_0
>>          5: ldc           #2                  // String
>>          7: getfield      #3                  // Field value:[C
>>         10: putfield      #3                  // Field value:[C
>>         13: return
>>       LineNumberTable:
>>         line 137: 0
>>         line 138: 4
>>
>>
>> Aleksey ,
>> By naive glance, new constructor thrpt is  bigger(jdk9/dev vs 9b42 in 
>> attach) on:
>>     @Benchmark
>>     public String getNewString() {
>>         return new String();
>>     }
>> Please suggest things to compare . Do we have bigapps-like benchmarks 
>> which may show regression on this?
>>
>> On 17.12.2014 21:10, Aleksey Shipilev wrote:
>>> On 17.12.2014 18:58, Claes Redestad wrote:
>>>> On 2014-12-17 11:22, Lev Priima wrote:
>>>>> Please review space optimization in no args String constructor.
>>>>> Originally, it was already rejected once by suggestion in
>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010300.html 
>>>>>
>>>>> w/o formal justification of pros and contras.  And enhancement was
>>>>> requested again by Nathan Reynolds.
>>>>>
>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8067471
>>>>> Patch: http://cr.openjdk.java.net/~lpriima/8067471/webrev.00/
>>> I am OK with this change pending we understand the performance impact a
>>> little better. Please do benchmarks.
>>>
>>>
>>>> Could this have some obscure security implications, such as the 
>>>> ability
>>>> to lock up some subsystem via retrieving and synchronizing on the 
>>>> shared
>>>> new String().value? I guess not, for practical purposes.
>>> This would be an issue if we published String.value directly, but we 
>>> don't.
>>>
>>>> I guess it could also be written:
>>>>
>>>>      public String() {
>>>>          this.value = "".value;
>>>>      }
>>>>
>>>> ... which would saves some byte code and should avoid having to 
>>>> allocate
>>>> a distinct object for this.
>>> Oh, I like this trick, given "" is probably already in constant pool 
>>> for
>>> some other reason. However, there is an additional dereference. We need
>>> a targeted nanobenchmark to properly quantify the costs for either 
>>> variant.
>>>
>>> -Aleksey.
>>>
>>>
>>
>

-- 
Best Regards,
Lev



From kumar.x.srinivasan at oracle.com  Fri Dec 19 17:44:36 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 19 Dec 2014 09:44:36 -0800
Subject: RFR: 8067889: 4 pack200 tests fail on mac since jdk became modular
Message-ID: <54946404.6040006@oracle.com>

Hello,

Please review a simplification of the JAR locator service, with the 
modular JDK there
is no need to search for JARs in the jdk, the golden.jar exists in a 
well known place
simply use this location.

http://cr.openjdk.java.net/~ksrini/8067889/webrev.0/

Thanks
Kumar



From aleksey.shipilev at oracle.com  Fri Dec 19 17:52:49 2014
From: aleksey.shipilev at oracle.com (Aleksey Shipilev)
Date: Fri, 19 Dec 2014 20:52:49 +0300
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <5496E93F.803@oracle.com>
References: <54915954.6090804@oracle.com>
	<5491A817.7040607@oracle.com>	<5491C71A.5040107@oracle.com>
	<5493743A.60904@oracle.com> <54942417.2080905@oracle.com>
	<5496E93F.803@oracle.com>
Message-ID: <549465F1.6020901@oracle.com>

On 21.12.2014 18:37, Lev Priima wrote:
> Thanks for exhaustive research. Looks formal enough to claim that both
> variants of change bring only perf advantages, but, as I understand,
> which one is better is not so straightforward.

Both are sound performance-wise, and you can see that they produce
almost the similar assembly (I would guess static finals and constant
pool entires really share the same memory arena).

So the choice is the actual style. I like the cuteness of "".value().

-Aleksey.




From Alan.Bateman at oracle.com  Fri Dec 19 17:57:15 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 19 Dec 2014 17:57:15 +0000
Subject: RFR: 8067889: 4 pack200 tests fail on mac since jdk became modular
In-Reply-To: <54946404.6040006@oracle.com>
References: <54946404.6040006@oracle.com>
Message-ID: <549466FB.5000700@oracle.com>

On 19/12/2014 17:44, Kumar Srinivasan wrote:
> Hello,
>
> Please review a simplification of the JAR locator service, with the 
> modular JDK there
> is no need to search for JARs in the jdk, the golden.jar exists in a 
> well known place
> simply use this location.
>
> http://cr.openjdk.java.net/~ksrini/8067889/webrev.0/
This looks okay to me although it seems more like a clean-up (not clear 
why it might have failed on Mac).

-Alan


From lev.priima at oracle.com  Fri Dec 19 18:34:01 2014
From: lev.priima at oracle.com (Lev Priima)
Date: Fri, 19 Dec 2014 21:34:01 +0300
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <549465F1.6020901@oracle.com>
References: <54915954.6090804@oracle.com>
	<5491A817.7040607@oracle.com>	<5491C71A.5040107@oracle.com>
	<5493743A.60904@oracle.com> <54942417.2080905@oracle.com>
	<5496E93F.803@oracle.com> <549465F1.6020901@oracle.com>
Message-ID: <54946F99.3030709@oracle.com>

Agree, but it's not just style. More formal, Implementation of same 
requirements(both performance and functional) in less code, is an src 
quality metric.

On 12/19/2014 08:52 PM, Aleksey Shipilev wrote:
> On 21.12.2014 18:37, Lev Priima wrote:
>> Thanks for exhaustive research. Looks formal enough to claim that both
>> variants of change bring only perf advantages, but, as I understand,
>> which one is better is not so straightforward.
> Both are sound performance-wise, and you can see that they produce
> almost the similar assembly (I would guess static finals and constant
> pool entires really share the same memory arena).
>
> So the choice is the actual style. I like the cuteness of "".value().
"".value
>
> -Aleksey.
>
>

-- 
Best Regards,
Lev



From claes.redestad at oracle.com  Fri Dec 19 19:13:36 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 19 Dec 2014 20:13:36 +0100
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <5496F07A.5010500@oracle.com>
References: <54915954.6090804@oracle.com>
	<5491A817.7040607@oracle.com>	<5491C71A.5040107@oracle.com>
	<5493743A.60904@oracle.com> <54943563.2070706@oracle.com>
	<5496F07A.5010500@oracle.com>
Message-ID: <549478E0.2080407@oracle.com>

No, as mentioned, I didn't check for mixed inputs, which is probably 
necessary to ensure we don't slow down the typical case due
to adding an extra branch, so I went about and made an attempt to write 
a microbenchmark to capture this[1] by making the count
parameter unpredictable without inducing much overhead (no randomness in 
the benchmark code itself), which should make
it sufficiently hard for the compiler to prune the branch checks. I 
don't think generating different char[]s would change things,
but feel free to improve upon this and generate random char[]s to verify 
that.

Doing this, I added Ivan Gerasimov's idea to fold the rare count == 0 
check into the count < 0 clause, which seemed like a
reasonable way to avoid adding the extra branch to the normal path[2], 
although it makes the code a little weirder. I'll denote
this version as experiment2, and my original code as experiment.

Results grouped on maxCount parameter, then ordered internally from 
baseline, experiment, experiment2. Probability of getting
count == 0 is roughly 1/maxCount, and the cost per operation (average) 
increases as maxCount goes up as we're copying more
data on average, the interesting metric is whether or not this 
optimization breaks the normal flow when we're only rarely
hitting the non-allocating branch, which would show up as the experiment 
underperforming versus the baseline as we increase
maxCount:

Benchmark                                  (maxCount) (numCount)   Mode  
Samples   Score   Error   Units
o.s.SimpleBench.mixedNewStringFromCount             2 1000000  
thrpt       50  46.114 ? 0.391  ops/us
o.s.SimpleBench.mixedNewStringFromCount             2 1000000  
thrpt       50  64.320 ? 0.569  ops/us
o.s.SimpleBench.mixedNewStringFromCount             2 1000000  
thrpt       50  64.874 ? 1.095  ops/us

o.s.SimpleBench.mixedNewStringFromCount            10 1000000  
thrpt       50  48.609 ? 0.921  ops/us
o.s.SimpleBench.mixedNewStringFromCount            10     1000000 
thrpt       50  50.562 ? 0.598  ops/us
o.s.SimpleBench.mixedNewStringFromCount            10     1000000 
thrpt       50  50.724 ? 0.535  ops/us

o.s.SimpleBench.mixedNewStringFromCount           100     1000000 
thrpt       50  31.422 ? 0.553  ops/us
o.s.SimpleBench.mixedNewStringFromCount           100     1000000 
thrpt       50  31.416 ? 0.512  ops/us
o.s.SimpleBench.mixedNewStringFromCount           100     1000000 
thrpt       50  31.852 ? 0.441  ops/us

o.s.SimpleBench.mixedNewStringFromCount          1000     1000000 
thrpt       50  5.528  ? 0.053  ops/us
o.s.SimpleBench.mixedNewStringFromCount          1000     1000000 
thrpt       50  5.531  ? 0.039  ops/us
o.s.SimpleBench.mixedNewStringFromCount          1000     1000000 
thrpt       50  5.550  ? 0.033  ops/us

To me it looks like the micro-optimization can be applied either way 
without much risk that it'll slow down the normal flow.
There's some indication that Ivan's suggestion is a slight improvement 
across the board.

/Claes

[1]
package org.sample;

import org.openjdk.jmh.annotations.*;
import java.util.concurrent.ThreadLocalRandom;

@State(Scope.Thread)
public class SimpleBench {

     @Param("1000000")
     public int numCount;

     @Param("10")
     public int maxCount;

     public int[] counts;

     public char[] data;

     public int index = 0;

     @Setup
     public void buildCounts() {
         counts = new int[numCount];
         data = new char[maxCount];
         ThreadLocalRandom r = ThreadLocalRandom.current();
         for (int i = 0; i < numCount; i++) {
             counts[i] = r.nextInt(0, maxCount);
         }
         for (int i = 0; i < maxCount; i++) {
             data[i] = 'a';
         }
     }

     @Benchmark
     public String mixedNewStringFromCount() {
         if (index >= numCount) {
             index = 0;
         }
         return new String(data, 0, counts[index++]);
     }
}

[2] http://cr.openjdk.java.net/~redestad/8067471/webrev.03/

On 2014-12-21 17:08, Lev Priima wrote:
> Claes,
>
> Is the source of arrays in these benchmarks unpredictable enough to 
> avoid branch checks elimination in compiled code?
>
> On 12/19/2014 05:25 PM, Claes Redestad wrote:
>> Hi again,
>>
>> I just had a nagging thought. For applications reporting some or a 
>> lot of different empty String objects,
>> this might be due not to use of this constructor, but due to things 
>> like an empty StringBuilder.toString() ending
>> up calling java.lang.String(char[] value, int offset, int count) with 
>> a count of 0.
>>
>> My feeling is that this would be a more probable/reasonable source of 
>> distinct empty strings in an application,
>> and would not be helped much by the current patch.
>>
>> For completeness the java.lang.String(char/int[], int, int) 
>> constructors could have a check for count == 0 in
>> which case it assigns value to "".value, see 
>> http://cr.openjdk.java.net/~redestad/8067471/webrev.01/
>>
>> Running a few simple microbenchmarks on this (sorry, Aleksey!)[1] 
>> yields a bit of speedup, at no discernible
>> cost for a quick sanity check of an actually copying path:
>>
>> baseline:
>> Benchmark                            Mode  Samples    Score Error   
>> Units
>> o.s.SimpleBench.emptySBBench        thrpt        5   48.213 ? 3.509  
>> ops/us
>> o.s.SimpleBench.emptyString         thrpt        5  103.900 ? 4.869  
>> ops/us
>> o.s.SimpleBench.emptyStringCount    thrpt        5  105.802 ? 3.355  
>> ops/us
>> o.s.SimpleBench.emptyStringCountCP  thrpt        5  104.464 ? 8.251  
>> ops/us
>> o.s.SimpleBench.singleStringCount   thrpt        5   76.379 ? 4.139  
>> ops/us
>> o.s.SimpleBench.singleStringCountCP thrpt        5   88.202 ? 4.945  
>> ops/us
>>
>> experiment:
>> Benchmark                            Mode  Samples    Score Error   
>> Units
>> o.s.SimpleBench.emptySBBench        thrpt        5  153.822 ? 7.900  
>> ops/us 3x
>> o.s.SimpleBench.emptyString         thrpt        5  183.588 ? 4.429  
>> ops/us 1.75x
>> o.s.SimpleBench.emptyStringCount    thrpt        5  166.457 ? 9.202  
>> ops/us 1.6x
>> o.s.SimpleBench.emptyStringCountCP  thrpt        5  168.089 ? 4.676  
>> ops/us 1.6x
>> o.s.SimpleBench.singleStringCount   thrpt        5   75.780 ? 8.490  
>> ops/us 1x
>> o.s.SimpleBench.singleStringCountCP thrpt        5   89.202 ? 3.714  
>> ops/us 1x
>>
>> I guess we'd need to check that compiled code don't get messed up for 
>> a mix of inputs where count can be both
>> zero and non-zero with some probability.
> Do we have such benchmarks examples?
>>
>> /Claes
>>
>> [1] public char[] emptyCharArray = new char[0];
>>     public int[] emptyIntArray = new int[0];
>>
>>     public char[] singleCharArray = new char[] { 'x' };
>>     public int[] singleIntArray = new int[] { 102 };
>>     public StringBuilder emptySB = new StringBuilder();
>>
>>     @Benchmark
>>     public String emptySBBench() {
>>         return emptySB.toString();
>>     }
>>
>>     @Benchmark
>>     public String emptyString() {
>>         return new String();
>>     }
>>
>>     @Benchmark
>>     public String emptyStringCount() {
>>         return new String(emptyCharArray, 0, 0);
>>     }
>>
>>     @Benchmark
>>     public String emptyStringCountCP() {
>>         return new String(emptyIntArray, 0, 0);
>>     }
>>
>>     @Benchmark
>>     public String singleStringCount() {
>>         return new String(singleCharArray, 0, 1);
>>     }
>>
>>     @Benchmark
>>     public String singleStringCountCP() {
>>         return new String(singleIntArray, 0, 1);
>>     }
>>
>>
>> On 2014-12-19 01:41, Lev Priima wrote:
>>> Claes,
>>> Thanks for cool suggestion: 
>>> http://cr.openjdk.java.net/~lpriima/8067471/webrev.01/:
>>>   public java.lang.String();
>>>     Signature: ()V
>>>     flags: ACC_PUBLIC
>>>     LineNumberTable:
>>>       line 137: 0
>>>       line 138: 4
>>>       line 139: 13
>>>     Code:
>>>       stack=2, locals=1, args_size=1
>>>          0: aload_0
>>>          1: invokespecial #1                  // Method 
>>> java/lang/Object."<init>":()V
>>>          4: aload_0
>>>          5: ldc           #2                  // String
>>>          7: getfield      #3                  // Field value:[C
>>>         10: putfield      #3                  // Field value:[C
>>>         13: return
>>>       LineNumberTable:
>>>         line 137: 0
>>>         line 138: 4
>>>
>>>
>>> Aleksey ,
>>> By naive glance, new constructor thrpt is  bigger(jdk9/dev vs 9b42 
>>> in attach) on:
>>>     @Benchmark
>>>     public String getNewString() {
>>>         return new String();
>>>     }
>>> Please suggest things to compare . Do we have bigapps-like 
>>> benchmarks which may show regression on this?
>>>
>>> On 17.12.2014 21:10, Aleksey Shipilev wrote:
>>>> On 17.12.2014 18:58, Claes Redestad wrote:
>>>>> On 2014-12-17 11:22, Lev Priima wrote:
>>>>>> Please review space optimization in no args String constructor.
>>>>>> Originally, it was already rejected once by suggestion in
>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010300.html 
>>>>>>
>>>>>> w/o formal justification of pros and contras.  And enhancement was
>>>>>> requested again by Nathan Reynolds.
>>>>>>
>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8067471
>>>>>> Patch: http://cr.openjdk.java.net/~lpriima/8067471/webrev.00/
>>>> I am OK with this change pending we understand the performance 
>>>> impact a
>>>> little better. Please do benchmarks.
>>>>
>>>>
>>>>> Could this have some obscure security implications, such as the 
>>>>> ability
>>>>> to lock up some subsystem via retrieving and synchronizing on the 
>>>>> shared
>>>>> new String().value? I guess not, for practical purposes.
>>>> This would be an issue if we published String.value directly, but 
>>>> we don't.
>>>>
>>>>> I guess it could also be written:
>>>>>
>>>>>      public String() {
>>>>>          this.value = "".value;
>>>>>      }
>>>>>
>>>>> ... which would saves some byte code and should avoid having to 
>>>>> allocate
>>>>> a distinct object for this.
>>>> Oh, I like this trick, given "" is probably already in constant 
>>>> pool for
>>>> some other reason. However, there is an additional dereference. We 
>>>> need
>>>> a targeted nanobenchmark to properly quantify the costs for either 
>>>> variant.
>>>>
>>>> -Aleksey.
>>>>
>>>>
>>>
>>
>



From ivan.gerasimov at oracle.com  Fri Dec 19 19:14:30 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 19 Dec 2014 22:14:30 +0300
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <549445E5.902@oracle.com>
References: <54915954.6090804@oracle.com>	<5491A817.7040607@oracle.com>	<5491C71A.5040107@oracle.com>	<5493743A.60904@oracle.com>	<54943563.2070706@oracle.com>
	<549445E5.902@oracle.com>
Message-ID: <54947916.3090009@oracle.com>


On 19.12.2014 18:36, Ivan Gerasimov wrote:
> Hi everyone!
>
> I guess something like the following might be used to avoid slowing 
> down the common route:
>

Sorry, it was meant to be:

              if (count <= 0) {
                  if (count < 0) {
                      throw new StringIndexOutOfBoundsException(count);
                  }
                  if (offset <= value.length) {
                      this.value = "".value;
                      return;
                  }
              }
              // Note: offset or count might be near -1>>>1.
              if (offset > value.length - count) {
                  throw new StringIndexOutOfBoundsException(offset + count);
              }
              this.value = Arrays.copyOfRange(value, offset, offset + count);
  


Otherwise, the behavior would have changed.

Sincerely yours,
Ivan



> Sincerely yours,
> Ivan
>
>
> On 19.12.2014 17:25, Claes Redestad wrote:
>> Hi again,
>>
>> I just had a nagging thought. For applications reporting some or a 
>> lot of different empty String objects,
>> this might be due not to use of this constructor, but due to things 
>> like an empty StringBuilder.toString() ending
>> up calling java.lang.String(char[] value, int offset, int count) with 
>> a count of 0.
>>
>> My feeling is that this would be a more probable/reasonable source of 
>> distinct empty strings in an application,
>> and would not be helped much by the current patch.
>>
>> For completeness the java.lang.String(char/int[], int, int) 
>> constructors could have a check for count == 0 in
>> which case it assigns value to "".value, see 
>> http://cr.openjdk.java.net/~redestad/8067471/webrev.01/
>>
>> Running a few simple microbenchmarks on this (sorry, Aleksey!)[1] 
>> yields a bit of speedup, at no discernible
>> cost for a quick sanity check of an actually copying path:
>>
>> baseline:
>> Benchmark                            Mode  Samples    Score Error   
>> Units
>> o.s.SimpleBench.emptySBBench        thrpt        5   48.213 ? 3.509  
>> ops/us
>> o.s.SimpleBench.emptyString         thrpt        5  103.900 ? 4.869  
>> ops/us
>> o.s.SimpleBench.emptyStringCount    thrpt        5  105.802 ? 3.355  
>> ops/us
>> o.s.SimpleBench.emptyStringCountCP  thrpt        5  104.464 ? 8.251  
>> ops/us
>> o.s.SimpleBench.singleStringCount   thrpt        5   76.379 ? 4.139  
>> ops/us
>> o.s.SimpleBench.singleStringCountCP thrpt        5   88.202 ? 4.945  
>> ops/us
>>
>> experiment:
>> Benchmark                            Mode  Samples    Score Error   
>> Units
>> o.s.SimpleBench.emptySBBench        thrpt        5  153.822 ? 7.900  
>> ops/us 3x
>> o.s.SimpleBench.emptyString         thrpt        5  183.588 ? 4.429  
>> ops/us 1.75x
>> o.s.SimpleBench.emptyStringCount    thrpt        5  166.457 ? 9.202  
>> ops/us 1.6x
>> o.s.SimpleBench.emptyStringCountCP  thrpt        5  168.089 ? 4.676  
>> ops/us 1.6x
>> o.s.SimpleBench.singleStringCount   thrpt        5   75.780 ? 8.490  
>> ops/us 1x
>> o.s.SimpleBench.singleStringCountCP thrpt        5   89.202 ? 3.714  
>> ops/us 1x
>>
>> I guess we'd need to check that compiled code don't get messed up for 
>> a mix of inputs where count can be both
>> zero and non-zero with some probability.
>>
>> /Claes
>>
>> [1] public char[] emptyCharArray = new char[0];
>>     public int[] emptyIntArray = new int[0];
>>
>>     public char[] singleCharArray = new char[] { 'x' };
>>     public int[] singleIntArray = new int[] { 102 };
>>     public StringBuilder emptySB = new StringBuilder();
>>
>>     @Benchmark
>>     public String emptySBBench() {
>>         return emptySB.toString();
>>     }
>>
>>     @Benchmark
>>     public String emptyString() {
>>         return new String();
>>     }
>>
>>     @Benchmark
>>     public String emptyStringCount() {
>>         return new String(emptyCharArray, 0, 0);
>>     }
>>
>>     @Benchmark
>>     public String emptyStringCountCP() {
>>         return new String(emptyIntArray, 0, 0);
>>     }
>>
>>     @Benchmark
>>     public String singleStringCount() {
>>         return new String(singleCharArray, 0, 1);
>>     }
>>
>>     @Benchmark
>>     public String singleStringCountCP() {
>>         return new String(singleIntArray, 0, 1);
>>     }
>>
>>
>> On 2014-12-19 01:41, Lev Priima wrote:
>>> Claes,
>>> Thanks for cool suggestion: 
>>> http://cr.openjdk.java.net/~lpriima/8067471/webrev.01/:
>>>   public java.lang.String();
>>>     Signature: ()V
>>>     flags: ACC_PUBLIC
>>>     LineNumberTable:
>>>       line 137: 0
>>>       line 138: 4
>>>       line 139: 13
>>>     Code:
>>>       stack=2, locals=1, args_size=1
>>>          0: aload_0
>>>          1: invokespecial #1                  // Method 
>>> java/lang/Object."<init>":()V
>>>          4: aload_0
>>>          5: ldc           #2                  // String
>>>          7: getfield      #3                  // Field value:[C
>>>         10: putfield      #3                  // Field value:[C
>>>         13: return
>>>       LineNumberTable:
>>>         line 137: 0
>>>         line 138: 4
>>>
>>>
>>> Aleksey ,
>>> By naive glance, new constructor thrpt is  bigger(jdk9/dev vs 9b42 
>>> in attach) on:
>>>     @Benchmark
>>>     public String getNewString() {
>>>         return new String();
>>>     }
>>> Please suggest things to compare . Do we have bigapps-like 
>>> benchmarks which may show regression on this?
>>>
>>> On 17.12.2014 21:10, Aleksey Shipilev wrote:
>>>> On 17.12.2014 18:58, Claes Redestad wrote:
>>>>> On 2014-12-17 11:22, Lev Priima wrote:
>>>>>> Please review space optimization in no args String constructor.
>>>>>> Originally, it was already rejected once by suggestion in
>>>>>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010300.html 
>>>>>>
>>>>>> w/o formal justification of pros and contras.  And enhancement was
>>>>>> requested again by Nathan Reynolds.
>>>>>>
>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8067471
>>>>>> Patch: http://cr.openjdk.java.net/~lpriima/8067471/webrev.00/
>>>> I am OK with this change pending we understand the performance 
>>>> impact a
>>>> little better. Please do benchmarks.
>>>>
>>>>
>>>>> Could this have some obscure security implications, such as the 
>>>>> ability
>>>>> to lock up some subsystem via retrieving and synchronizing on the 
>>>>> shared
>>>>> new String().value? I guess not, for practical purposes.
>>>> This would be an issue if we published String.value directly, but 
>>>> we don't.
>>>>
>>>>> I guess it could also be written:
>>>>>
>>>>>      public String() {
>>>>>          this.value = "".value;
>>>>>      }
>>>>>
>>>>> ... which would saves some byte code and should avoid having to 
>>>>> allocate
>>>>> a distinct object for this.
>>>> Oh, I like this trick, given "" is probably already in constant 
>>>> pool for
>>>> some other reason. However, there is an additional dereference. We 
>>>> need
>>>> a targeted nanobenchmark to properly quantify the costs for either 
>>>> variant.
>>>>
>>>> -Aleksey.
>>>>
>>>>
>>>
>>
>>
>>
>
>
>



From martinrb at google.com  Fri Dec 19 19:34:55 2014
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 19 Dec 2014 11:34:55 -0800
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <54947916.3090009@oracle.com>
References: <54915954.6090804@oracle.com> <5491A817.7040607@oracle.com>
	<5491C71A.5040107@oracle.com> <5493743A.60904@oracle.com>
	<54943563.2070706@oracle.com> <549445E5.902@oracle.com>
	<54947916.3090009@oracle.com>
Message-ID: <CA+kOe08fst763YA6=TsaegZc7G6g74-TNVYfV4U+ZiB=6N1e=A@mail.gmail.com>

On Fri, Dec 19, 2014 at 11:14 AM, Ivan Gerasimov
<ivan.gerasimov at oracle.com> wrote:
> Sorry, it was meant to be:
>
>              if (count <= 0) {
>                  if (count < 0) {
>                      throw new StringIndexOutOfBoundsException(count);
>                  }
>                  if (offset <= value.length) {
>                      this.value = "".value;
>                      return;
>                  }
>              }

I support Ivan's idea of coalescing the rare branches into a slowpath.


From daniel.smith at oracle.com  Fri Dec 19 21:19:08 2014
From: daniel.smith at oracle.com (Dan Smith)
Date: Fri, 19 Dec 2014 14:19:08 -0700
Subject: Stream optimization suggestions
Message-ID: <F4C6EFFA-EA93-491E-A712-AAFFD6679287@oracle.com>

I've submitted a couple of RFEs to support some simple optimizations on Streams.  I noticed both issues while writing some code that forced me to choose between cluttering up my straightforward, uniform Stream logic and eating the cost of linear operations that should be O(1).

JDK-8067969 Optimize Stream.count for SIZED Streams
JDK-8067971 Support optimizations for always-true and always-false Predicates

Certainly not high-priority, but would be nice for somebody working with java.util.stream to address someday.

?Dan

From daniel.smith at oracle.com  Fri Dec 19 21:39:43 2014
From: daniel.smith at oracle.com (Dan Smith)
Date: Fri, 19 Dec 2014 14:39:43 -0700
Subject: Lambda-fied pattern matching
In-Reply-To: <546D234F.1090004@univ-mlv.fr>
References: <2F21F150-F3D1-4F7A-A2EB-38F26DE28169@oracle.com>
	<546D234F.1090004@univ-mlv.fr>
Message-ID: <7D1BD1E0-1CB9-4F10-85DC-E45D0F62C5C8@oracle.com>

> On Nov 19, 2014, at 4:10 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> and yes, please log a RFE.

RFE is here: https://bugs.openjdk.java.net/browse/JDK-8067973


From brian.burkhalter at oracle.com  Fri Dec 19 22:39:25 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 19 Dec 2014 14:39:25 -0800
Subject: Documentation of methods in java.lang.Number
In-Reply-To: <20141217102612.GE4911@e6430>
References: <20141216125508.GC4911@e6430>
	<9D55A146-D76D-4E91-B02D-2BC646451CE2@oracle.com>
	<20141217102612.GE4911@e6430>
Message-ID: <14D2CBF9-D637-43C2-A703-DEE439D567C4@oracle.com>


On Dec 17, 2014, at 2:26 AM, Andreas Lundblad <andreas.lundblad at oracle.com> wrote:

> Another suggestion would be:
> 
> "Returns the value of the specified number as a {@code long}. The specific semantics of the conversion is defined by the subclass in question."

Does something like the following seem reasonable?

Brian

--- a/src/java.base/share/classes/java/lang/Number.java
+++ b/src/java.base/share/classes/java/lang/Number.java
@@ -54,8 +54,10 @@
  */
 public abstract class Number implements java.io.Serializable {
     /**
-     * Returns the value of the specified number as an {@code int},
-     * which may involve rounding or truncation.
+     * Returns the value of the specified number as an {@code int}.  The
+     * specific semantics of the conversion is defined by the subclass in
+     * question, and may involve a narrowing conversion such as rounding or
+     * truncation.
      *
      * @return  the numeric value represented by this object after conversion
      *          to type {@code int}.
@@ -63,8 +65,10 @@
     public abstract int intValue();
 
     /**
-     * Returns the value of the specified number as a {@code long},
-     * which may involve rounding or truncation.
+     * Returns the value of the specified number as a {@code long}.  The
+     * specific semantics of the conversion is defined by the subclass in
+     * question, and may involve a narrowing conversion such as rounding or
+     * truncation.
      *
      * @return  the numeric value represented by this object after conversion
      *          to type {@code long}.
@@ -72,8 +76,9 @@
     public abstract long longValue();
 
     /**
-     * Returns the value of the specified number as a {@code float},
-     * which may involve rounding.
+     * Returns the value of the specified number as a {@code float}.  The
+     * specific semantics of the conversion is defined by the subclass in
+     * question, and may involve a narrowing conversion such as rounding.
      *
      * @return  the numeric value represented by this object after conversion
      *          to type {@code float}.
@@ -81,8 +86,9 @@
     public abstract float floatValue();
 
     /**
-     * Returns the value of the specified number as a {@code double},
-     * which may involve rounding.
+     * Returns the value of the specified number as a {@code double}.  The
+     * specific semantics of the conversion is defined by the subclass in
+     * question, and may involve a narrowing conversion such as rounding.
      *
      * @return  the numeric value represented by this object after conversion
      *          to type {@code double}.

From joe.darcy at oracle.com  Fri Dec 19 23:26:19 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 19 Dec 2014 15:26:19 -0800
Subject: Documentation of methods in java.lang.Number
In-Reply-To: <14D2CBF9-D637-43C2-A703-DEE439D567C4@oracle.com>
References: <20141216125508.GC4911@e6430>	<9D55A146-D76D-4E91-B02D-2BC646451CE2@oracle.com>	<20141217102612.GE4911@e6430>
	<14D2CBF9-D637-43C2-A703-DEE439D567C4@oracle.com>
Message-ID: <5494B41B.8060003@oracle.com>

Hello,

On 12/19/2014 2:39 PM, Brian Burkhalter wrote:
> On Dec 17, 2014, at 2:26 AM, Andreas Lundblad <andreas.lundblad at oracle.com> wrote:
>
>> Another suggestion would be:
>>
>> "Returns the value of the specified number as a {@code long}. The specific semantics of the conversion is defined by the subclass in question."
> Does something like the following seem reasonable?
>
> Brian
>
> --- a/src/java.base/share/classes/java/lang/Number.java
> +++ b/src/java.base/share/classes/java/lang/Number.java
> @@ -54,8 +54,10 @@
>    */
>   public abstract class Number implements java.io.Serializable {
>       /**
> -     * Returns the value of the specified number as an {@code int},
> -     * which may involve rounding or truncation.
> +     * Returns the value of the specified number as an {@code int}.  The
> +     * specific semantics of the conversion is defined by the subclass in
> +     * question, and may involve a narrowing conversion such as rounding or
> +     * truncation.
>        *
>        * @return  the numeric value represented by this object after conversion
>        *          to type {@code int}.

I don't really think the current text is problematic; however, if it is 
to be changed, I recommending including a citation to the "Narrowing 
primitive conversion" section of the Java Language Specification. This 
can be accomplished using the @jls javadoc tag; the syntax is something like

     * @jls 5.1.3. Narrowing Primitive Conversion

Examples of the use of @jls can be found elsewhere in the core libraries.

For the exact wording how about

... The particular semantics of the conversion operation from the 
specified number to a {@code long} are defined  in subclasses. The 
operation may involve a narrowing conversion, rounding, or truncation.

Cheers,

-Joe

> @@ -63,8 +65,10 @@
>       public abstract int intValue();
>   
>       /**
> -     * Returns the value of the specified number as a {@code long},
> -     * which may involve rounding or truncation.
> +     * Returns the value of the specified number as a {@code long}.  The
> +     * specific semantics of the conversion is defined by the subclass in
> +     * question, and may involve a narrowing conversion such as rounding or
> +     * truncation.
>        *
>        * @return  the numeric value represented by this object after conversion
>        *          to type {@code long}.
> @@ -72,8 +76,9 @@
>       public abstract long longValue();
>   
>       /**
> -     * Returns the value of the specified number as a {@code float},
> -     * which may involve rounding.
> +     * Returns the value of the specified number as a {@code float}.  The
> +     * specific semantics of the conversion is defined by the subclass in
> +     * question, and may involve a narrowing conversion such as rounding.
>        *
>        * @return  the numeric value represented by this object after conversion
>        *          to type {@code float}.
> @@ -81,8 +86,9 @@
>       public abstract float floatValue();
>   
>       /**
> -     * Returns the value of the specified number as a {@code double},
> -     * which may involve rounding.
> +     * Returns the value of the specified number as a {@code double}.  The
> +     * specific semantics of the conversion is defined by the subclass in
> +     * question, and may involve a narrowing conversion such as rounding.
>        *
>        * @return  the numeric value represented by this object after conversion
>        *          to type {@code double}.



From brian.burkhalter at oracle.com  Fri Dec 19 23:34:49 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 19 Dec 2014 15:34:49 -0800
Subject: Documentation of methods in java.lang.Number
In-Reply-To: <5494B41B.8060003@oracle.com>
References: <20141216125508.GC4911@e6430>	<9D55A146-D76D-4E91-B02D-2BC646451CE2@oracle.com>	<20141217102612.GE4911@e6430>
	<14D2CBF9-D637-43C2-A703-DEE439D567C4@oracle.com>
	<5494B41B.8060003@oracle.com>
Message-ID: <0130FA9E-0891-4627-BE4F-28A794D3D2C6@oracle.com>


On Dec 19, 2014, at 3:26 PM, joe darcy <joe.darcy at oracle.com> wrote:

> I don't really think the current text is problematic; however, if it is to be changed, I recommending including a citation to the "Narrowing primitive conversion" section of the Java Language Specification. This can be accomplished using the @jls javadoc tag; the syntax is something like
> 
>    * @jls 5.1.3. Narrowing Primitive Conversion
> 
> Examples of the use of @jls can be found elsewhere in the core libraries.

This is already in the class level documentation which is why I left it out. No harm adding it to the method docs however.

> For the exact wording how about
> 
> ... The particular semantics of the conversion operation from the specified number to a {@code long} are defined  in subclasses. The operation may involve a narrowing conversion, rounding, or truncation.

Seems reasonable to me.

Thanks,

Brian

From chris.hegarty at oracle.com  Mon Dec 22 14:13:18 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 22 Dec 2014 14:13:18 +0000
Subject: [PATCH] JDK-8054565: FilterOutputStream.close may throw
	IOException if called twice and underlying flush or close fails
In-Reply-To: <548EB053.2040908@oracle.com>
References: <COL131-W7702CC152AA3DCD1C3F6CECA780@phx.gbl>,
	<54807258.4040303@oracle.com>	<COL131-W5314F71E11C72DDA3D5804CA780@phx.gbl>,
	<20141205002430.000060c9.ecki@zusammenkunft.net>,
	<2C4F3368-64DC-4F8B-9923-0C08999C8C5B@oracle.com>,
	<20141205015827.00007ac6.ecki@zusammenkunft.net>,
	<CAHjP37HgKZMhjq6_AVZFAdPy4PeZBd7p6JBT0Jt2FqE42eB6Ow@mail.gmail.com>,
	<8F896CE2-E268-418F-96CA-0557C1C258B3@oracle.com>,
	<5481BB6C.1040700@oracle.com> <5481C3DB.70303@gmail.com>,
	<5481CA8C.7050100@oracle.com> <5481EF01.6060009@gmail.com>, ,
	<C517EC9F-7136-4252-BA5B-FFE8C2CBD4B4@oracle.com>,
	<COL131-W3093E62A5924C2DC984C5FCA650@phx.gbl>	<COL131-W843B7101077FF11EC708FBCA6F0@phx.gbl>
	<548EB053.2040908@oracle.com>
Message-ID: <549826FE.1060600@oracle.com>

To close the loop; find below the complete reviewed changes.

   http://cr.openjdk.java.net/~chegar/8054565/webrev.00/webrev/

Since there is a minor spec change, I will submit a CCC to cover it. 
Unless any unforeseen issues arise from the CCC, you can assume that 
this is final.

-Chris.


From brian.burkhalter at oracle.com  Mon Dec 22 18:46:34 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 22 Dec 2014 10:46:34 -0800
Subject: JDK 9 RFR of 8067669: Documentation for methods in Number incomplete
	regarding too large values. 
In-Reply-To: <0130FA9E-0891-4627-BE4F-28A794D3D2C6@oracle.com>
References: <20141216125508.GC4911@e6430>	<9D55A146-D76D-4E91-B02D-2BC646451CE2@oracle.com>	<20141217102612.GE4911@e6430>
	<14D2CBF9-D637-43C2-A703-DEE439D567C4@oracle.com>
	<5494B41B.8060003@oracle.com>
	<0130FA9E-0891-4627-BE4F-28A794D3D2C6@oracle.com>
Message-ID: <3978CBCB-2BBC-4CB3-8ECF-8A2D29A233E6@oracle.com>

Please review at your convenience:

Issue:	https://bugs.openjdk.java.net/browse/JDK-8067669
Patch:	http://cr.openjdk.java.net/~bpb/8067669/webrev.00/

Summary:

Add some verbiage.

I would advocate either changing the verbiage either to the content in the patch or something better, or resolving the issue as ?Not an Issue.?

Thanks,

Brian

On Dec 19, 2014, at 3:34 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

> On Dec 19, 2014, at 3:26 PM, joe darcy <joe.darcy at oracle.com> wrote:
> 
>> I don't really think the current text is problematic; however, if it is to be changed, I recommending including a citation to the "Narrowing primitive conversion" section of the Java Language Specification. This can be accomplished using the @jls javadoc tag; the syntax is something like
>> 
>>    * @jls 5.1.3. Narrowing Primitive Conversion
>> 
>> Examples of the use of @jls can be found elsewhere in the core libraries.
> 
> This is already in the class level documentation which is why I left it out. No harm adding it to the method docs however.
> 
>> For the exact wording how about
>> 
>> ... The particular semantics of the conversion operation from the specified number to a {@code long} are defined  in subclasses. The operation may involve a narrowing conversion, rounding, or truncation.
> 
> Seems reasonable to me.



From vladimir.x.ivanov at oracle.com  Mon Dec 22 20:53:59 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Mon, 22 Dec 2014 23:53:59 +0300
Subject: [9] RFR (M): 8067344: Adjust
	java/lang/invoke/LFCaching/LFGarbageCollectedTest.java
	for recent changes in java.lang.invoke
Message-ID: <549884E7.8040204@oracle.com>

http://cr.openjdk.java.net/~vlivanov/8067344/webrev.00/
https://bugs.openjdk.java.net/browse/JDK-8067344

LFGarbageCollectedTest should be adjusted after JDK-8057020.

There are a couple of problems with the test.

(1) Existing logic to test that LambdaForm instance is collected isn't 
stable enough. Consequent System.GCs can hinder reference enqueueing.
To speed up the test, I added -XX:SoftRefLRUPolicyMSPerMB=0 and limited 
the heap by -Xmx64m.

(2) MethodType-based invoker caches are deliberately left strongly 
reachable. So, they should be skipped in the test.

(3) Added additional diagnostic output to simplify failure analysis 
(test case details, method handle type and LambdaForm, heap dump 
(optional, -DHEAP_DUMP=true)).

Testing: failing test.

Thanks!

Best regards,
Vladimir Ivanov


From brian.burkhalter at oracle.com  Mon Dec 22 21:13:51 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 22 Dec 2014 13:13:51 -0800
Subject: JDK 9 RFR of 8064463: BigDecimal should populate
	NumberFormatException message
Message-ID: <081B9550-613C-4210-80C7-7F4171FCAD6B@oracle.com>

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8064463
Patch:	http://cr.openjdk.java.net/~bpb/8064463/webrev.00/

Summary:

Ensure that the message strings of all NumberFormatExceptions are populated with appropriate content, excluding where the NFE merely wraps another exception in its cause.

It was suggested in the issue description to include the contents of the supplied character array in the exception message. This is not done in this patch for the reason that the resulting string could be quite large. If it seems reasonable to include the characters the patch can be so amended.

Thanks,

Brian

From bradford.wetmore at oracle.com  Tue Dec 23 01:30:08 2014
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Mon, 22 Dec 2014 17:30:08 -0800
Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file
	descriptors
In-Reply-To: <5492D557.2000807@gmail.com>
References: <5492D557.2000807@gmail.com>
Message-ID: <5498C5A0.50104@oracle.com>


Hi Peter,

Looks like you have a committer status, will you be pushing this?

On 12/18/2014 5:23 AM, Peter Levart wrote:
> Hi,
>
> I propose a patch for the following issue:
>
>      https://bugs.openjdk.java.net/browse/JDK-8047769
>
> Here's the webrev:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.01/

Looks good.  A few minor comments.

In a couple places, there are a few lines > 80 chars.  (It's a pet peeve 
of mine, this makes side-by-side reviews difficult without a wide 
monitor.  I realize not everyone shares this view, but they're probably 
not working on a laptop screen regularly.)

Do you need to close the InputStream when last holder is GC'd, or do we 
just let the FileInputStream's finalizer take care of that?

Both of these current calls are contained within a 
AccessContrller.doPriviledged, the checkRead() seems redundant.

In your test case, if assertions are not enabled, the tests at 46/50/51 
are noops, e.g. when run by hand.  Generally should directly throw 
Exceptions.

> The patch uses a package-private FileInputStreamPool class that caches
> open FileInputStream(s) so that at most one file descriptor is open for
> a particular file. Reading from shared unbuffered FileInputStream in
> multiple threads should be safe, right?

I would think (hope?) so, but I am not 100% sure.  I tracked it down 
into libjava native code:

io_util.c
=========
     fd = GET_FD(this, fid);
     if (fd == -1) {
         JNU_ThrowIOException(env, "Stream Closed");
         nread = -1;
     } else {
         nread = IO_Read(fd, buf, len);

which is then defined to handleRead, which calls something called 
RESTARTABLE in io_util_md.c.  Assuming I'm looking at the right code.

Core-libs folks?

> sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.java:
> Make sure that when no system policy and user policy files exist, the
> built-in default policy will be used, which - amongst other things -
> grants standard extensions the AllPermission.
> sun/security/provider/PolicyParser/ExtDirsChange.java: standard
> extensions path is hard-coded in default system policy file
> sun/security/provider/PolicyParser/PrincipalExpansionError.java: parser
> incorrectly ignores a principal if the principal name expands to nothing.
>
> ...they are unrelated to this patch - seems to be caused by recent
> layout changes for modular runtime images.

Hopefully you saw my previous response.  Repeating:

---begin---
They've been failing for a while:

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

These tests are all "/manual" so they don't show up in our regular runs 
of JPRT/jtreg, which include -a.

     -a | -automatic | -automagic
                 Any test with /manual will not be run
---end---

Thanks,

Brad




From otaviojava at java.net  Tue Dec 23 09:46:40 2014
From: otaviojava at java.net (=?UTF-8?Q?Ot=C3=A1vio_Gon=C3=A7alves_de_Santana?=)
Date: Tue, 23 Dec 2014 07:46:40 -0200
Subject: Using StringBuilder instead StringBuffer[JAXP]
Message-ID: <CAPc8kR2FgvWJ2oZHhCU-_uWEOR91_mMh960qxCiAEcx=ZBnP_A@mail.gmail.com>

*Motivation:* StringBuffer is synchronized while StringBuilder is not which
makes StringBuilder faster than StringBuffer[1]. The strategy was removed
the StringBuffer when it is not necessary.


WebRev:
https://dl.dropboxusercontent.com/u/16109193/open_jdk/jaxp/buffer2builder/index.html


[1]

@State(Scope.Thread)
@OutputTimeUnit(TimeUnit.SECONDS)
public class StringBufferBenchmark {


    private List<String> texts;
    @Param("10000000")
    private int param;

    @Setup
    public void setup() {
        texts = new LinkedList<>();
        Random random = new Random();
        for (int index = 0; index < param; index++) {
            char a = (char) random.nextInt();
            texts.add(String.valueOf(a));
        }
    }

    @GenerateMicroBenchmark
    public void stringBuffer(BlackHole bh) {
        StringBuffer sb = new StringBuffer();
        texts.stream().forEach(sb::append);
        bh.consume(sb.toString());
    }

    @GenerateMicroBenchmark
    public void stringBuilder(BlackHole bh) {
        StringBuilder sb = new StringBuilder();
        texts.stream().forEach(sb::append);
        bh.consume(sb.toString());
    }
 }


java -jar target/microbenchmarks.jar ".*StringBufferBenchmark*." -wi 20 -i
20 -f 1

Benchmark                                (param)   Mode   Samples
Mean   Mean error    Units
m.StringBufferBenchmark.stringBuffer    10000000  thrpt        20
 3.208        0.406    ops/s
m.StringBufferBenchmark.stringBuilder   10000000  thrpt        20
 4.795        0.037    ops/s
-- 

Ot?vio Gon?alves de Santana

twitter: http://twitter.com/otaviojava
site:     *http://about.me/otaviojava <http://about.me/otaviojava>*
55 (11) 98255-3513
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 814_updated.patch
Type: text/x-patch
Size: 195975 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/core-libs-dev/attachments/20141223/88127a46/814_updated.patch>

From andrey.x.nazarov at oracle.com  Tue Dec 23 10:47:42 2014
From: andrey.x.nazarov at oracle.com (Andrey Nazarov)
Date: Tue, 23 Dec 2014 13:47:42 +0300
Subject: RFR 8067437: New tests for mJRE feature removal.
Message-ID: <5499484E.70101@oracle.com>

Please review new tests for the java launcher.

New tests in MultipleJRE.java includes:
1. java -help must not contain information about obsolete flags

"-version:", "-jre-restrict-search", "-jre-no-restrict-search"

2. java should emit error if obsolete flag is specified (combo test)

3. java should ignore manifest attributes: "JRE-Version","JRE-Restrict-Search"

Removed tests:

1. Tests covered by MultipleJRE.java are removed in shell script MultipleJRE.sh. Script can be ported to Java by another changeset.

2. Removed tests that check java argument parsing through re-exec when another java version specified through flag -version:<id>

Do we have tests for argument parsing in java launcher except Arrrghs.java?

Webrev: http://cr.openjdk.java.net/~anazarov/8067437/webrev.00/




--Thanks, Andrey


From vladimir.x.ivanov at oracle.com  Tue Dec 23 12:40:36 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Tue, 23 Dec 2014 15:40:36 +0300
Subject: [9] RFR (M): 8067344: Adjust
	java/lang/invoke/LFCaching/LFGarbageCollectedTest.java
	for recent changes in java.lang.invoke
In-Reply-To: <549884E7.8040204@oracle.com>
References: <549884E7.8040204@oracle.com>
Message-ID: <549962C4.2040301@oracle.com>

Spotted some more problems:
   - need to skip identity operations (identity_* LambdaForms) in the 
test, since corresponding LambdaForms reside in a permanent cache;

   - need to keep original test data for diagnostic purposes, since 
getTestCaseData() produces new instance.

Updated version:
http://cr.openjdk.java.net/~vlivanov/8067344/webrev.01/

Best regards,
Vladimir Ivanov

On 12/22/14 11:53 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8067344/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8067344
>
> LFGarbageCollectedTest should be adjusted after JDK-8057020.
>
> There are a couple of problems with the test.
>
> (1) Existing logic to test that LambdaForm instance is collected isn't
> stable enough. Consequent System.GCs can hinder reference enqueueing.
> To speed up the test, I added -XX:SoftRefLRUPolicyMSPerMB=0 and limited
> the heap by -Xmx64m.
>
> (2) MethodType-based invoker caches are deliberately left strongly
> reachable. So, they should be skipped in the test.
>
> (3) Added additional diagnostic output to simplify failure analysis
> (test case details, method handle type and LambdaForm, heap dump
> (optional, -DHEAP_DUMP=true)).
>
> Testing: failing test.
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov


From ivan.gerasimov at oracle.com  Tue Dec 23 13:31:34 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 23 Dec 2014 16:31:34 +0300
Subject: RFR: 8067951: System.loadLibrary cannot find library when path
	contains quoted entry
Message-ID: <54996EB6.9080908@oracle.com>

Hello!

Content of the environment variable PATH is appended to java.library.path.
When ClassLoader.loadLibrary() is called, these paths are used to search 
for the library file.
However, if the entry were quoted, the file locating fails.

According to this blog entry [1], quoted entries are allowed in PATH 
under Windows, so we should deal with them somehow.

On the other hand, a valid path on Unix can contain quotes, so the 
proposed patch can change the behavior for those rare environments that 
have entries in PATH starting and ending with a quote.
However, we already have ambiguity in processing the paths, as they can 
contain colon or semicolon...

Here's the proposed fix. It doesn't try to resolve all the ambiguities, 
but only adds handling entirely quoted entries.

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8067951
WEBREV: http://cr.openjdk.java.net/~igerasim/8067951/0/webrev/

Would you please help review this fix?

[1] http://blogs.msdn.com/b/oldnewthing/archive/2006/09/29/776926.aspx

Sincerely yours,
Ivan



From kumar.x.srinivasan at oracle.com  Tue Dec 23 15:26:57 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 23 Dec 2014 07:26:57 -0800
Subject: RFR 8067437: New tests for mJRE feature removal.
In-Reply-To: <5499484E.70101@oracle.com>
References: <5499484E.70101@oracle.com>
Message-ID: <549989C1.5060506@oracle.com>

Neil,

Since you contributed  the dev work, appreciate if you can provide some
feedback on the cleanup and new tests.

Andrey,
Please see embedded comments below:

> Please review new tests for the java launcher.
>
> New tests in MultipleJRE.java includes:
> 1. java -help must not contain information about obsolete flags
>
> "-version:", "-jre-restrict-search", "-jre-no-restrict-search"
>
> 2. java should emit error if obsolete flag is specified (combo test)
>
> 3. java should ignore manifest attributes: 
> "JRE-Version","JRE-Restrict-Search"

MultipleJRE.java
Prefer to see braces for "for-while-loops"  lines 71, 72, its ok if you 
skip braces for
one-liner if-then-else clauses.

I would also suggest dumping the TestResult separately upon failure to 
assist in debugging,
because it will be likely be "yours truly" who will triage  future bugs.

  112         if (!tr.testStatus) {
- 113             throw new RuntimeException("test case: failed\n" + tr.toString());
+                 System.out.println(tr);
+                 throw new RuntimeException("test case: failed\n" + cmd);
  114         }



>
> Removed tests:
>
> 1. Tests covered by MultipleJRE.java are removed in shell script 
> MultipleJRE.sh. Script can be ported to Java by another changeset.

Amen, I want to see MultipleJRE.sh be whittled away and finally removed.

>
> 2. Removed tests that check java argument parsing through re-exec when 
> another java version specified through flag -version:<id>
>
> Do we have tests for argument parsing in java launcher except 
> Arrrghs.java?

Besides Arrrghs.java, there are tests in langtools
http://hg.openjdk.java.net/jdk9/dev/langtools/file/20475c78a0a6/test/tools/javac/Paths/wcMineField.sh
http://hg.openjdk.java.net/jdk9/dev/langtools/file/20475c78a0a6/test/tools/javac/Paths/MineField.sh

So why is the BugId added to this test ? This test no longer tests any 
mJRE features ?

Thanks for doing this!.

Kumar

>
> Webrev: http://cr.openjdk.java.net/~anazarov/8067437/webrev.00/
>
>
>
>
> --Thanks, Andrey



From kumar.x.srinivasan at oracle.com  Tue Dec 23 15:28:08 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Tue, 23 Dec 2014 07:28:08 -0800
Subject: RFR 8067437: New tests for mJRE feature removal.
In-Reply-To: <549989C1.5060506@oracle.com>
References: <5499484E.70101@oracle.com> <549989C1.5060506@oracle.com>
Message-ID: <54998A08.5060303@oracle.com>

Missed clarifying this, I will be sponsoring this patch.

Kumar

On 12/23/2014 7:26 AM, Kumar Srinivasan wrote:
> Neil,
>
> Since you contributed  the dev work, appreciate if you can provide some
> feedback on the cleanup and new tests.
>
> Andrey,
> Please see embedded comments below:
>
>> Please review new tests for the java launcher.
>>
>> New tests in MultipleJRE.java includes:
>> 1. java -help must not contain information about obsolete flags
>>
>> "-version:", "-jre-restrict-search", "-jre-no-restrict-search"
>>
>> 2. java should emit error if obsolete flag is specified (combo test)
>>
>> 3. java should ignore manifest attributes: 
>> "JRE-Version","JRE-Restrict-Search"
>
> MultipleJRE.java
> Prefer to see braces for "for-while-loops"  lines 71, 72, its ok if 
> you skip braces for
> one-liner if-then-else clauses.
>
> I would also suggest dumping the TestResult separately upon failure to 
> assist in debugging,
> because it will be likely be "yours truly" who will triage  future bugs.
>
>  112         if (!tr.testStatus) {
> - 113             throw new RuntimeException("test case: failed\n" + 
> tr.toString());
> +                 System.out.println(tr);
> +                 throw new RuntimeException("test case: failed\n" + 
> cmd);
>  114         }
>
>
>
>>
>> Removed tests:
>>
>> 1. Tests covered by MultipleJRE.java are removed in shell script 
>> MultipleJRE.sh. Script can be ported to Java by another changeset.
>
> Amen, I want to see MultipleJRE.sh be whittled away and finally removed.
>
>>
>> 2. Removed tests that check java argument parsing through re-exec 
>> when another java version specified through flag -version:<id>
>>
>> Do we have tests for argument parsing in java launcher except 
>> Arrrghs.java?
>
> Besides Arrrghs.java, there are tests in langtools
> http://hg.openjdk.java.net/jdk9/dev/langtools/file/20475c78a0a6/test/tools/javac/Paths/wcMineField.sh 
>
> http://hg.openjdk.java.net/jdk9/dev/langtools/file/20475c78a0a6/test/tools/javac/Paths/MineField.sh 
>
>
> So why is the BugId added to this test ? This test no longer tests any 
> mJRE features ?
>
> Thanks for doing this!.
>
> Kumar
>
>>
>> Webrev: http://cr.openjdk.java.net/~anazarov/8067437/webrev.00/
>>
>>
>>
>>
>> --Thanks, Andrey
>



From brian.burkhalter at oracle.com  Tue Dec 23 18:32:21 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 23 Dec 2014 10:32:21 -0800
Subject: JDK 9 RFR of 8067964: Native2ascii doesn't close one of the streams
	it opens 
Message-ID: <6A24C741-8A49-4D0C-B2A4-98D0FD6F374A@oracle.com>

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8067964
Patch:	http://cr.openjdk.java.net/~bpb/8067964/webrev.00/

Summary:

Use try-with-resources statements to manage AutoCloseables in sun.tools.native2ascii.Main.convert(). Also clean up code formatting of the method and remove unneeded import statements.

Thanks,

Brian

From chris.hegarty at oracle.com  Tue Dec 23 19:16:39 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 23 Dec 2014 19:16:39 +0000
Subject: JDK 9 RFR of 8067964: Native2ascii doesn't close one of the
	streams it opens
In-Reply-To: <6A24C741-8A49-4D0C-B2A4-98D0FD6F374A@oracle.com>
References: <6A24C741-8A49-4D0C-B2A4-98D0FD6F374A@oracle.com>
Message-ID: <20C4C711-DFC2-42A4-BC69-22987C45AA9F@oracle.com>

Looks ok to me Brian.

Does the test really verify this? Or just  exercise the code?

-Chris

> On 23 Dec 2014, at 18:32, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Please review at your convenience.
> 
> Issue:    https://bugs.openjdk.java.net/browse/JDK-8067964
> Patch:    http://cr.openjdk.java.net/~bpb/8067964/webrev.00/
> 
> Summary:
> 
> Use try-with-resources statements to manage AutoCloseables in sun.tools.native2ascii.Main.convert(). Also clean up code formatting of the method and remove unneeded import statements.
> 
> Thanks,
> 
> Brian


From brian.burkhalter at oracle.com  Tue Dec 23 19:22:29 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 23 Dec 2014 11:22:29 -0800
Subject: JDK 9 RFR of 8067964: Native2ascii doesn't close one of the
	streams it opens
In-Reply-To: <20C4C711-DFC2-42A4-BC69-22987C45AA9F@oracle.com>
References: <6A24C741-8A49-4D0C-B2A4-98D0FD6F374A@oracle.com>
	<20C4C711-DFC2-42A4-BC69-22987C45AA9F@oracle.com>
Message-ID: <AFC400C9-3D0C-40AB-8283-68DDD3CCA8B3@oracle.com>

Hi Chris,

On Dec 23, 2014, at 11:16 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> Looks ok to me Brian.
> 
> Does the test really verify this? Or just  exercise the code?

Exercise the code. Do you think this is sufficient? I?ve no idea how to verify it.

Thanks,

Brian

From chris.hegarty at oracle.com  Tue Dec 23 20:31:31 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 23 Dec 2014 20:31:31 +0000
Subject: JDK 9 RFR of 8067964: Native2ascii doesn't close one of the
	streams it opens
In-Reply-To: <AFC400C9-3D0C-40AB-8283-68DDD3CCA8B3@oracle.com>
References: <6A24C741-8A49-4D0C-B2A4-98D0FD6F374A@oracle.com>
	<20C4C711-DFC2-42A4-BC69-22987C45AA9F@oracle.com>
	<AFC400C9-3D0C-40AB-8283-68DDD3CCA8B3@oracle.com>
Message-ID: <ACFE0B1D-6319-4035-8E84-52C101FC4520@oracle.com>


> On 23 Dec 2014, at 19:22, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:
> 
> Hi Chris,
> 
>> On Dec 23, 2014, at 11:16 AM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>> 
>> Looks ok to me Brian.
>> 
>> Does the test really verify this? Or just  exercise the code?
> 
> Exercise the code. Do you think this is sufficient? I?ve no idea how to verify it.

I think this should be fine, just checking.

-Chris.

> Thanks,
> 
> Brian


From brian.burkhalter at oracle.com  Tue Dec 23 20:34:38 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 23 Dec 2014 12:34:38 -0800
Subject: JDK 9 RFR of 8067964: Native2ascii doesn't close one of the
	streams it opens
In-Reply-To: <ACFE0B1D-6319-4035-8E84-52C101FC4520@oracle.com>
References: <6A24C741-8A49-4D0C-B2A4-98D0FD6F374A@oracle.com>
	<20C4C711-DFC2-42A4-BC69-22987C45AA9F@oracle.com>
	<AFC400C9-3D0C-40AB-8283-68DDD3CCA8B3@oracle.com>
	<ACFE0B1D-6319-4035-8E84-52C101FC4520@oracle.com>
Message-ID: <5EE00592-78F9-42EB-B070-6F094E89E457@oracle.com>


On Dec 23, 2014, at 12:31 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:

>> Exercise the code. Do you think this is sufficient? I?ve no idea how to verify it.
> 
> I think this should be fine, just checking.

OK - thanks.

Brian

From brian.burkhalter at oracle.com  Tue Dec 23 23:27:14 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 23 Dec 2014 15:27:14 -0800
Subject: JDK 9 RFR of 8059175: Zero BigDecimal with negative scale prints
	leading zeroes in String.format
Message-ID: <684C24A3-8B54-421F-B38B-41CB2A63FCC5@oracle.com>

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8059175
Patch:	http://cr.openjdk.java.net/~bpb/8059175/webrev.00/

In java.util.Formatter.BigDecimalLayout.layout() trailing zeroes are erroneously appended when the unscaled value of the BigDecimal is zero and the scale is negative. Some other minor changes are included to make the logic in the method clearer.

Thanks,

Brian

From weijun.wang at oracle.com  Wed Dec 24 00:51:30 2014
From: weijun.wang at oracle.com (Wang Weijun)
Date: Wed, 24 Dec 2014 08:51:30 +0800
Subject: RFR: 8067951: System.loadLibrary cannot find library when path
	contains quoted entry
In-Reply-To: <54996EB6.9080908@oracle.com>
References: <54996EB6.9080908@oracle.com>
Message-ID: <29A1F964-41A3-497D-8FB7-4574EF2CFBF3@oracle.com>


> On Dec 23, 2014, at 21:31, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
> 
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8067951
> WEBREV: http://cr.openjdk.java.net/~igerasim/8067951/0/webrev/

I am not sure why you want to rewrite the loop entirely. Isn't it OK to just add that long if check before the old line 1770? I always find myself confusing when a for line contains "," inside. :-)

And how about a white box test with getDeclaredMethod("initializePath").setAccessible(true)? I think you can even add a few non-supported case (say, "A:B":C) and comment them out at the moment.

Thanks
Max




From stuart.marks at oracle.com  Wed Dec 24 01:24:15 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 23 Dec 2014 17:24:15 -0800
Subject: RFR(m): 8067316: update RMI test library with better
	test.timeout.factor handling
Message-ID: <549A15BF.2000704@oracle.com>

Hi all,

Please review this change, which adds handling of the test.timeout.factor 
property to the RMI tests. These tests have a fair number of internal timeouts; 
this change multiplies the timeout values by test.timeout.factor so that 
timeouts will be less likely on slow systems, where a timeout factor has been 
applied.

In order read this property, a bunch of the tests' security policy files needed 
to be updated. This mainly impacted the policy files for the rmid activation 
group JVMs. I took the opportunity to clean up these policy files as well so 
that they're all fairly consistent among themselves.

The change updates a couple dozen policy files in a fairly stylized fashion. The 
actual code changes are concentrated in the files ActivationLibrary.java, 
JavaVM.java, RMID.java, and TestLibrary.java, which all appear at the end of the 
webrev.

Webrev:

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

Bug:

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

Sandbox changeset:

     http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/419205f6b2d9

Thanks,

s'marks


From stuart.marks at oracle.com  Wed Dec 24 05:01:44 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 23 Dec 2014 21:01:44 -0800
Subject: RFR 8066085: Need a sanity test for rmic -iiop
In-Reply-To: <5493F63D.6030702@oracle.com>
References: <548A71E7.8000209@oracle.com> <548AA276.7080701@oracle.com>
	<5493F63D.6030702@oracle.com>
Message-ID: <549A48B8.7080205@oracle.com>

Hi Felix,

Good improvements. I think this is pretty close; I have just a few minor comments.

* The test is named IIOPSanityTest but it's in a directory named 
iiopCompilation. I don't think we need different names. There are many test 
classes named "Foo" that reside in a directory named "foo"; I think we should do 
the same here. I think keeping the directory name "iiopCompilation" and renaming 
the class to "IIOPCompilation" makes things a bit more descriptive.

* Declaring string constants like RMIC_PROGRAM, IIOP_OPTION, and CP_OPTION 
doesn't really help things, since they're each used exactly once, the string 
values are unlikely to change, and the symbolic names are just derived from the 
string vaues. You might as well use string literals directly in each place 
they're needed.

* Printing the command that's about to be executed is a good idea, but the 
printf statement that prints the command has to be kept in synch with the array 
containing the command and args. If the command were to change, it'd be easy to 
forget to update the printf statement or to get it wrong.

* I'll also observe that there is an overload of the ProcessBuilder constructor 
that takes a List<String> instead of a String[]. Lists are often easier to work 
with than arrays, and they have a toString() method that can be used implicitly 
by print statements. This suggests an alternative for constructing the rmic 
command line, something like the following:

     List<String> command = Arrays.asList(
         rmicProgramStr, "-iiop", "-classpath", testClasses, classname);
     System.out.println("Running command: " + command);

After you fix these up I think this will be ready to go in.

I can sponsor this changeset for you if you need a sponsor.

Thanks,

s'marks




On 12/19/14 1:56 AM, FELIX YANG wrote:
> Hi Stuart,
>      please review the updated webrev:
> http://cr.openjdk.java.net/~xiaofeya/8066085/webrev.01/
>
> Thanks,
> -Felix
> On 12/12/2014 4:08 PM, Stuart Marks wrote:
>> On 12/11/14 8:41 PM, FELIX YANG wrote:
>>> Hi all,
>>>      please review the fix to add a sanity checking for rmic -iiop compiling.
>>>
>>> Bug:
>>>         https://bugs.openjdk.java.net/browse/JDK-8066085
>>>
>>> Webrev:
>>>         http://cr.openjdk.java.net/~xiaofeya/8066085/webrev.00/
>>
>> Hi Felix,
>>
>> Thanks for picking up the writing of this test. I have several comments.
>>
>> 1. Usually we try to avoid naming tests after bug IDs. There are such tests in
>> the suite but most tests have more descriptive names. I'd suggest something
>> like "iiopSanityTest".
>>
>> 2. There are other rmic tests in jdk/test/sun/rmi/rmic; the test should be
>> moved there (and the path to the TestLibrary updated correspondingly).
>>
>> 3. The test summary should be a bit more explicit. Instead of "a sanity test
>> for rmic -iiop compiling" I'd suggest something like "Compiles a
>> PortableRemoteObject with rmic -iiop and ensures that stub and tie classes are
>> generated."
>>
>> 4. When invoking rmic, you need to make sure to pass the -iiop option.
>>
>> 5. Add check for the _Tie class as well as the _Stub class. Not that it really
>> matters, since we know these classes are in the unnamed package, but the stub
>> and tie class files would end up in directories corresponding to their package
>> names -- if they were in a named package.
>>
>> 6. In doTest(), the try/catch of InterruptedException and IOException and call
>> to TestLibrary.bomb() is mostly unnecessary. (Yes, other RMI tests do this,
>> and I've been removing it where appropriate. In the RMI test library, the
>> bomb() call merely wraps and rethrows the exception, and doesn't really add
>> any value. It's like calling fail() in a test-ng test.) In general an uncaught
>> exception will cause a jtreg test to fail, so you might as well just declare
>> the method with "throws Exception" and let them propagate. This helps reduce
>> clutter.
>>
>> 7. Similarly I'm not sure it's necessary to check the classname argument for
>> null; the failure should be apparent enough if classname is null. But if you
>> think it's worth it, a concise way to null-check an argument is to use
>> Objects.requireNonNull().
>>
>> 8. The "rmiComplie" method is misnamed (or typo'd); I'd suggest something like
>> "runRmic".
>>
>> 9. Changing the directory of the rmic subprocess is confusing, because it
>> makes different parts of the program deal with different paths to the same
>> files. In addition, switching directories to the test.classes directory will
>> leave the stub/tie classes there, which could possibly confuse future test
>> runs, since that directory isn't necessarily cleared between test runs.
>>
>> The default working directory of jtreg tests is the "scratch" directory, which
>> is cleared before each test run. Leaving the current directory as-is when
>> running the subprocesses will write the generated stub/tie classes to the
>> scratch directory, which is the right thing.
>>
>> This implies that you'll need to add the -classpath argument and a path to the
>> test.classes directory to the rmic command line.
>>
>> Thanks,
>>
>> s'marks
>>
>>
>


From ivan.gerasimov at oracle.com  Wed Dec 24 10:45:03 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Wed, 24 Dec 2014 13:45:03 +0300
Subject: RFR: 8067951: System.loadLibrary cannot find library when path
	contains quoted entry
In-Reply-To: <29A1F964-41A3-497D-8FB7-4574EF2CFBF3@oracle.com>
References: <54996EB6.9080908@oracle.com>
	<29A1F964-41A3-497D-8FB7-4574EF2CFBF3@oracle.com>
Message-ID: <549A992F.7030307@oracle.com>

Thank you Max!

On 24.12.2014 3:51, Wang Weijun wrote:
>> On Dec 23, 2014, at 21:31, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8067951
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8067951/0/webrev/
> I am not sure why you want to rewrite the loop entirely. Isn't it OK to just add that long if check before the old line 1770?
>
Unfortunately no.
First, it would miss a quoted entry if it was last in the list.
Second, the loop, as it is currently implemented, doesn't correctly 
handle empty entries:  if an empty entry was at the beginning of the 
list, it is replaced with a dot, but if it was at the end, it produces 
an empty string in the result.  Not a big deal, given how the function 
is used, but still better have if fixed.

>   I always find myself confusing when a for line contains "," inside. :-)

Okay, I reformatted it a bit, no more commas.

> And how about a white box test with getDeclaredMethod("initializePath").setAccessible(true)? I think you can even add a few non-supported case (say, "A:B":C) and comment them out at the moment.

Good idea! Please take a look at the updated webrev.
I've also added some checks for correct handling of empty entries.

Here's the updated webrev:
http://cr.openjdk.java.net/~igerasim/8067951/1/webrev/

Tested with JPRT on all available platforms with jdk_lang subset of 
tests. No failures.

Sincerely yours,
Ivan


> Thanks
> Max
>
>
>
>



From peter.levart at gmail.com  Wed Dec 24 11:37:23 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 24 Dec 2014 12:37:23 +0100
Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file
	descriptors
In-Reply-To: <5498C5A0.50104@oracle.com>
References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com>
Message-ID: <549AA573.2060801@gmail.com>

Hi Brad,

Thanks for looking into this. Here's updated webrev:

http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.02/

...and answers are inline...

On 12/23/2014 02:30 AM, Bradford Wetmore wrote:
>
> Hi Peter,
>
> Looks like you have a committer status, will you be pushing this?

I can, yes. As soon as we clear-out the remaining questions, right?

>
> On 12/18/2014 5:23 AM, Peter Levart wrote:
>> Hi,
>>
>> I propose a patch for the following issue:
>>
>>      https://bugs.openjdk.java.net/browse/JDK-8047769
>>
>> Here's the webrev:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.01/ 
>>
>
> Looks good.  A few minor comments.
>
> In a couple places, there are a few lines > 80 chars.  (It's a pet 
> peeve of mine, this makes side-by-side reviews difficult without a 
> wide monitor.  I realize not everyone shares this view, but they're 
> probably not working on a laptop screen regularly.)

I have wrapped the lines to contain them inside the 80 column margin.

>
> Do you need to close the InputStream when last holder is GC'd, or do 
> we just let the FileInputStream's finalizer take care of that?

WeakReference<UncloseableInputStream> is enqueued when it is cleared, so 
at that time we have no access to the referent (UncloseableInputStream) 
any more. We could, in addition, "strongly" reference the underlying 
FileInputStream in the WeakReference subclass itself, but that would 
just prolong the life of FileInputStream (possibly forever if no further 
calls to FileInputStreamPool are made that expunge the references from 
the queue). So yes, we rely on FileInputStream's finalizer, but I don't 
see any other way that would be better than that. NativePRNG and 
URLSeedGenerator don't have a means of closing underlying resources 
either, so this is not making things any worse.

>
> Both of these current calls are contained within a 
> AccessContrller.doPriviledged, the checkRead() seems redundant.

That's right, but from encapsulation, uniformity, security and future 
maintainability standpoint, I would keep this logic in. It doesn't hurt. 
Another possibility is to move doPriviliged call to FileInputStreamPool 
itself and declare it's API exposing security capability (of reading any 
file).

>
> In your test case, if assertions are not enabled, the tests at 
> 46/50/51 are noops, e.g. when run by hand.  Generally should directly 
> throw Exceptions.

I modified the test to use jdk.testlibrary.Asserts class. Is this ok 
from "run by hand" perspective or should the test be self-contained?

>
>> The patch uses a package-private FileInputStreamPool class that caches
>> open FileInputStream(s) so that at most one file descriptor is open for
>> a particular file. Reading from shared unbuffered FileInputStream in
>> multiple threads should be safe, right?
>
> I would think (hope?) so, but I am not 100% sure.  I tracked it down 
> into libjava native code:
>
> io_util.c
> =========
>     fd = GET_FD(this, fid);
>     if (fd == -1) {
>         JNU_ThrowIOException(env, "Stream Closed");
>         nread = -1;
>     } else {
>         nread = IO_Read(fd, buf, len);
>
> which is then defined to handleRead, which calls something called 
> RESTARTABLE in io_util_md.c.  Assuming I'm looking at the right code.
>
> Core-libs folks?

The documentation doesn't mention threads anywhere in InputStream or 
FileInputStream except in this piece of javadoc for available() method:

      * Returns an estimate of the number of remaining bytes that can be 
read (or
      * skipped over) from this input stream without blocking by the next
      * invocation of a method for this input stream. Returns 0 when the 
file
      * position is beyond EOF. The next invocation might be the same 
*thread*
      * or another *thread*. A single read or skip of this many bytes 
will not
      * block, but may read or skip fewer bytes.


...which indicates that multiple threads may be used to read from 
FileInputStream(s)...

Anyway it works correctly and not redundantly synchronizing in Java 
seems to increase the mutithreaded throughput a bit (or more acurately, 
does not decrease it compared to single-threaded case). For example, the 
following JMH benchmark:


@State(Scope.Thread)
public class DevUrandomTest {

     private static final Object sharedLock = new Object();
     private static final InputStream sharedRndStream;

     static {
         try {
             sharedRndStream = new FileInputStream("/dev/urandom");
         } catch (FileNotFoundException e) {
             throw new RuntimeException(e);
         }
     }

     // per-thread instance
     private final byte[] buff = new byte[32];

     @Benchmark
     @BenchmarkMode(Mode.Throughput)
     @Fork(value = 1, warmups = 0)
     @Warmup(iterations = 5)
     @Measurement(iterations = 10)
     public byte testReadUnsynchronized() {
         try {
             sharedRndStream.read(buff);
         } catch (IOException e) {
             throw new RuntimeException(e);
         }
         return buff[0];
     }

     @Benchmark
     @BenchmarkMode(Mode.Throughput)
     @Fork(value = 1, warmups = 0)
     @Warmup(iterations = 5)
     @Measurement(iterations = 10)
     public byte testReadSynchronized() {
         try {
             synchronized (sharedLock) {
                 sharedRndStream.read(buff);
             }
         } catch (IOException e) {
             throw new RuntimeException(e);
         }
         return buff[0];
     }
}


when run on:

1 thread:

Benchmark                                     Mode  Samples Score      
Error  Units
j.t.DevUrandomTest.testReadSynchronized      thrpt       10 553331.718 
?  309.350  ops/s
j.t.DevUrandomTest.testReadUnsynchronized    thrpt       10 556654.281 ? 
1703.320  ops/s

2 threads:

Benchmark                                     Mode  Samples Score       
Error  Units
j.t.DevUrandomTest.testReadSynchronized      thrpt       10 346127.591 ? 
73537.596  ops/s
j.t.DevUrandomTest.testReadUnsynchronized    thrpt       10 570414.143 ? 
25134.664  ops/s

4 threads:

Benchmark                                     Mode  Samples Score       
Error  Units
j.t.DevUrandomTest.testReadSynchronized      thrpt       10 392531.196 ? 
67848.064  ops/s
j.t.DevUrandomTest.testReadUnsynchronized    thrpt       10 500111.743 ? 
62730.048  ops/s


>
>> sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.java:
>> Make sure that when no system policy and user policy files exist, the
>> built-in default policy will be used, which - amongst other things -
>> grants standard extensions the AllPermission.
>> sun/security/provider/PolicyParser/ExtDirsChange.java: standard
>> extensions path is hard-coded in default system policy file
>> sun/security/provider/PolicyParser/PrincipalExpansionError.java: parser
>> incorrectly ignores a principal if the principal name expands to 
>> nothing.
>>
>> ...they are unrelated to this patch - seems to be caused by recent
>> layout changes for modular runtime images.
>
> Hopefully you saw my previous response.  Repeating:
>
> ---begin---
> They've been failing for a while:
>
>     https://bugs.openjdk.java.net/browse/JDK-8039280
>
> These tests are all "/manual" so they don't show up in our regular 
> runs of JPRT/jtreg, which include -a.
>
>     -a | -automatic | -automagic
>                 Any test with /manual will not be run
> ---end---
>
> Thanks,
>
> Brad

Yes, I saw that. Thanks.

Regards, Peter




From peter.levart at gmail.com  Wed Dec 24 12:20:56 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 24 Dec 2014 13:20:56 +0100
Subject: [9] RFR (M): 8067344: Adjust
	java/lang/invoke/LFCaching/LFGarbageCollectedTest.java
	for recent changes in java.lang.invoke
In-Reply-To: <549962C4.2040301@oracle.com>
References: <549884E7.8040204@oracle.com> <549962C4.2040301@oracle.com>
Message-ID: <549AAFA8.40505@gmail.com>

Hi Vladimir,

I just wanted to ask about the reason you used PhantomReference to 
detect that a referent is not softly reachable any more. You could use 
another SoftReference or a WeakReference for the same effect, since it 
is guaranteed that all SoftReferences for same referent are cleared 
atomically and WeakReferences are cleared when referent is not softly 
reachable any more. Using Weak or PhantomReference in test can 
theoretically give false failures, since the object can still be weakly 
of phantom reachable, but not softly reachable any more.

I think that it is enough for test to check that the referent is not 
softly reachable any more, since cache is using SoftReferences. 
Therefore it would be most appropriate to use a SoftReference in test too.

What do you think?

Regards, Peter

On 12/23/2014 01:40 PM, Vladimir Ivanov wrote:
> Spotted some more problems:
>   - need to skip identity operations (identity_* LambdaForms) in the 
> test, since corresponding LambdaForms reside in a permanent cache;
>
>   - need to keep original test data for diagnostic purposes, since 
> getTestCaseData() produces new instance.
>
> Updated version:
> http://cr.openjdk.java.net/~vlivanov/8067344/webrev.01/
>
> Best regards,
> Vladimir Ivanov
>
> On 12/22/14 11:53 PM, Vladimir Ivanov wrote:
>> http://cr.openjdk.java.net/~vlivanov/8067344/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8067344
>>
>> LFGarbageCollectedTest should be adjusted after JDK-8057020.
>>
>> There are a couple of problems with the test.
>>
>> (1) Existing logic to test that LambdaForm instance is collected isn't
>> stable enough. Consequent System.GCs can hinder reference enqueueing.
>> To speed up the test, I added -XX:SoftRefLRUPolicyMSPerMB=0 and limited
>> the heap by -Xmx64m.
>>
>> (2) MethodType-based invoker caches are deliberately left strongly
>> reachable. So, they should be skipped in the test.
>>
>> (3) Added additional diagnostic output to simplify failure analysis
>> (test case details, method handle type and LambdaForm, heap dump
>> (optional, -DHEAP_DUMP=true)).
>>
>> Testing: failing test.
>>
>> Thanks!
>>
>> Best regards,
>> Vladimir Ivanov



From felix.yang at oracle.com  Wed Dec 24 15:27:54 2014
From: felix.yang at oracle.com (FELIX YANG)
Date: Wed, 24 Dec 2014 23:27:54 +0800
Subject: RFR 8066085: Need a sanity test for rmic -iiop
In-Reply-To: <549A48B8.7080205@oracle.com>
References: <548A71E7.8000209@oracle.com> <548AA276.7080701@oracle.com>
	<5493F63D.6030702@oracle.com> <549A48B8.7080205@oracle.com>
Message-ID: <549ADB7A.1040900@oracle.com>

Hi Stuart,
      this is the updated webrev: 
http://cr.openjdk.java.net/~xiaofeya/8066085/webrev.02/. Please sponsor 
this changeset for me.

Thank you very much,
-Felix
On 12/24/2014 1:01 PM, Stuart Marks wrote:
> Hi Felix,
>
> Good improvements. I think this is pretty close; I have just a few 
> minor comments.
>
> * The test is named IIOPSanityTest but it's in a directory named 
> iiopCompilation. I don't think we need different names. There are many 
> test classes named "Foo" that reside in a directory named "foo"; I 
> think we should do the same here. I think keeping the directory name 
> "iiopCompilation" and renaming the class to "IIOPCompilation" makes 
> things a bit more descriptive.
>
> * Declaring string constants like RMIC_PROGRAM, IIOP_OPTION, and 
> CP_OPTION doesn't really help things, since they're each used exactly 
> once, the string values are unlikely to change, and the symbolic names 
> are just derived from the string vaues. You might as well use string 
> literals directly in each place they're needed.
>
> * Printing the command that's about to be executed is a good idea, but 
> the printf statement that prints the command has to be kept in synch 
> with the array containing the command and args. If the command were to 
> change, it'd be easy to forget to update the printf statement or to 
> get it wrong.
>
> * I'll also observe that there is an overload of the ProcessBuilder 
> constructor that takes a List<String> instead of a String[]. Lists are 
> often easier to work with than arrays, and they have a toString() 
> method that can be used implicitly by print statements. This suggests 
> an alternative for constructing the rmic command line, something like 
> the following:
>
>     List<String> command = Arrays.asList(
>         rmicProgramStr, "-iiop", "-classpath", testClasses, classname);
>     System.out.println("Running command: " + command);
>
> After you fix these up I think this will be ready to go in.
>
> I can sponsor this changeset for you if you need a sponsor.
>
> Thanks,
>
> s'marks
>
>
>
>
> On 12/19/14 1:56 AM, FELIX YANG wrote:
>> Hi Stuart,
>>      please review the updated webrev:
>> http://cr.openjdk.java.net/~xiaofeya/8066085/webrev.01/
>>
>> Thanks,
>> -Felix
>> On 12/12/2014 4:08 PM, Stuart Marks wrote:
>>> On 12/11/14 8:41 PM, FELIX YANG wrote:
>>>> Hi all,
>>>>      please review the fix to add a sanity checking for rmic -iiop 
>>>> compiling.
>>>>
>>>> Bug:
>>>>         https://bugs.openjdk.java.net/browse/JDK-8066085
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~xiaofeya/8066085/webrev.00/
>>>
>>> Hi Felix,
>>>
>>> Thanks for picking up the writing of this test. I have several 
>>> comments.
>>>
>>> 1. Usually we try to avoid naming tests after bug IDs. There are 
>>> such tests in
>>> the suite but most tests have more descriptive names. I'd suggest 
>>> something
>>> like "iiopSanityTest".
>>>
>>> 2. There are other rmic tests in jdk/test/sun/rmi/rmic; the test 
>>> should be
>>> moved there (and the path to the TestLibrary updated correspondingly).
>>>
>>> 3. The test summary should be a bit more explicit. Instead of "a 
>>> sanity test
>>> for rmic -iiop compiling" I'd suggest something like "Compiles a
>>> PortableRemoteObject with rmic -iiop and ensures that stub and tie 
>>> classes are
>>> generated."
>>>
>>> 4. When invoking rmic, you need to make sure to pass the -iiop option.
>>>
>>> 5. Add check for the _Tie class as well as the _Stub class. Not that 
>>> it really
>>> matters, since we know these classes are in the unnamed package, but 
>>> the stub
>>> and tie class files would end up in directories corresponding to 
>>> their package
>>> names -- if they were in a named package.
>>>
>>> 6. In doTest(), the try/catch of InterruptedException and 
>>> IOException and call
>>> to TestLibrary.bomb() is mostly unnecessary. (Yes, other RMI tests 
>>> do this,
>>> and I've been removing it where appropriate. In the RMI test 
>>> library, the
>>> bomb() call merely wraps and rethrows the exception, and doesn't 
>>> really add
>>> any value. It's like calling fail() in a test-ng test.) In general 
>>> an uncaught
>>> exception will cause a jtreg test to fail, so you might as well just 
>>> declare
>>> the method with "throws Exception" and let them propagate. This 
>>> helps reduce
>>> clutter.
>>>
>>> 7. Similarly I'm not sure it's necessary to check the classname 
>>> argument for
>>> null; the failure should be apparent enough if classname is null. 
>>> But if you
>>> think it's worth it, a concise way to null-check an argument is to use
>>> Objects.requireNonNull().
>>>
>>> 8. The "rmiComplie" method is misnamed (or typo'd); I'd suggest 
>>> something like
>>> "runRmic".
>>>
>>> 9. Changing the directory of the rmic subprocess is confusing, 
>>> because it
>>> makes different parts of the program deal with different paths to 
>>> the same
>>> files. In addition, switching directories to the test.classes 
>>> directory will
>>> leave the stub/tie classes there, which could possibly confuse 
>>> future test
>>> runs, since that directory isn't necessarily cleared between test runs.
>>>
>>> The default working directory of jtreg tests is the "scratch" 
>>> directory, which
>>> is cleared before each test run. Leaving the current directory as-is 
>>> when
>>> running the subprocesses will write the generated stub/tie classes 
>>> to the
>>> scratch directory, which is the right thing.
>>>
>>> This implies that you'll need to add the -classpath argument and a 
>>> path to the
>>> test.classes directory to the rmic command line.
>>>
>>> Thanks,
>>>
>>> s'marks
>>>
>>>
>>



From kumar.x.srinivasan at oracle.com  Wed Dec 24 18:56:17 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 24 Dec 2014 10:56:17 -0800
Subject: RFR: 8066834: tools/pack200/CommandLineTests.java does not conform
	ProblemList.txt style
Message-ID: <549B0C51.7090107@oracle.com>

Hello,

Please review this simple fix, enclosed.
Thanks in advance.

Kumar

diff --git a/test/ProblemList.txt b/test/ProblemList.txt
--- a/test/ProblemList.txt
+++ b/test/ProblemList.txt
@@ -267,7 +267,7 @@

  # Tests take too long, on sparcs see 7143279
  # also see 8059906
-tools/pack200/CommandLineTests.java
+tools/pack200/CommandLineTests.java generic-all
  tools/pack200/Pack200Test.java solaris-all,macosx-all



From stuart.marks at oracle.com  Wed Dec 24 19:33:18 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 24 Dec 2014 11:33:18 -0800
Subject: RFR: 8067951: System.loadLibrary cannot find library when path
	contains quoted entry
In-Reply-To: <549A992F.7030307@oracle.com>
References: <54996EB6.9080908@oracle.com>	<29A1F964-41A3-497D-8FB7-4574EF2CFBF3@oracle.com>
	<549A992F.7030307@oracle.com>
Message-ID: <549B14FE.7070800@oracle.com>

Hi Ivan,

It's not clear to me that quoting should be applied at this level. On Unix, 
quotes are stripped by the shell at the time the command line is split into 
arguments, so the values should be treated literally without further quote 
processing.

The referenced blog post at MSDN talks about Windows, which passes the entire 
command string to the program, which then is responsible for splitting it into 
arguments or otherwise parsing it. This seems to occur in the file

     jdk/src/java.base/windows/native/libjli/cmdtoargs.c

If the logic in that file is mishandling quotes, it seems like the fix ought to 
be applied there.

In addition, this change simply strips quotes that happen to occur at the 
boundaries of substrings between path separators. It doesn't do any actual 
quoting, that is, protecting the path separator character so that it can be used 
as part of an actual path instead of as a separator. (But I'm not sure that's 
actually a supported case anyway.) Simply stripping quotes seems wrong.

Unfortunately there are no details in the bug report JDK-8067951, so I can't 
tell what the real problem is.

s'marks


On 12/24/14 2:45 AM, Ivan Gerasimov wrote:
> Thank you Max!
>
> On 24.12.2014 3:51, Wang Weijun wrote:
>>> On Dec 23, 2014, at 21:31, Ivan Gerasimov <ivan.gerasimov at oracle.com> wrote:
>>>
>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8067951
>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8067951/0/webrev/
>> I am not sure why you want to rewrite the loop entirely. Isn't it OK to just
>> add that long if check before the old line 1770?
>>
> Unfortunately no.
> First, it would miss a quoted entry if it was last in the list.
> Second, the loop, as it is currently implemented, doesn't correctly handle empty
> entries:  if an empty entry was at the beginning of the list, it is replaced
> with a dot, but if it was at the end, it produces an empty string in the
> result.  Not a big deal, given how the function is used, but still better have
> if fixed.
>
>>   I always find myself confusing when a for line contains "," inside. :-)
>
> Okay, I reformatted it a bit, no more commas.
>
>> And how about a white box test with
>> getDeclaredMethod("initializePath").setAccessible(true)? I think you can even
>> add a few non-supported case (say, "A:B":C) and comment them out at the moment.
>
> Good idea! Please take a look at the updated webrev.
> I've also added some checks for correct handling of empty entries.
>
> Here's the updated webrev:
> http://cr.openjdk.java.net/~igerasim/8067951/1/webrev/
>
> Tested with JPRT on all available platforms with jdk_lang subset of tests. No
> failures.
>
> Sincerely yours,
> Ivan
>
>
>> Thanks
>> Max
>>
>>
>>
>>
>


From kumar.x.srinivasan at oracle.com  Wed Dec 24 23:04:56 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Wed, 24 Dec 2014 15:04:56 -0800
Subject: RFR(XXS): 8066834: tools/pack200/CommandLineTests.java does not
	conform ProblemList.txt style
In-Reply-To: <549B0C51.7090107@oracle.com>
References: <549B0C51.7090107@oracle.com>
Message-ID: <549B4698.7020108@oracle.com>


On 12/24/2014 10:56 AM, Kumar Srinivasan wrote:
> Hello,
>
> Please review this simple fix, enclosed.
> Thanks in advance.
>
> Kumar
>
> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
> --- a/test/ProblemList.txt
> +++ b/test/ProblemList.txt
> @@ -267,7 +267,7 @@
>
>  # Tests take too long, on sparcs see 7143279
>  # also see 8059906
> -tools/pack200/CommandLineTests.java
> +tools/pack200/CommandLineTests.java generic-all
>  tools/pack200/Pack200Test.java solaris-all,macosx-all
>



From ivan.gerasimov at oracle.com  Thu Dec 25 14:46:25 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 25 Dec 2014 17:46:25 +0300
Subject: RFR: 8067951: System.loadLibrary cannot find library when path
	contains quoted entry
In-Reply-To: <549B14FE.7070800@oracle.com>
References: <54996EB6.9080908@oracle.com>	<29A1F964-41A3-497D-8FB7-4574EF2CFBF3@oracle.com>
	<549A992F.7030307@oracle.com> <549B14FE.7070800@oracle.com>
Message-ID: <549C2341.6010807@oracle.com>

Hi Stuart!

On 24.12.2014 22:33, Stuart Marks wrote:
> Hi Ivan,
>
> It's not clear to me that quoting should be applied at this level. On 
> Unix, quotes are stripped by the shell at the time the command line is 
> split into arguments, so the values should be treated literally 
> without further quote processing.
>
That's correct.
At least bash does not recognize quoted entries in PATH.
Thus, we only need to deal with quotes on Windows, so I updated the webrev.

> The referenced blog post at MSDN talks about Windows, which passes the 
> entire command string to the program, which then is responsible for 
> splitting it into arguments or otherwise parsing it. This seems to 
> occur in the file
>
>     jdk/src/java.base/windows/native/libjli/cmdtoargs.c
>
> If the logic in that file is mishandling quotes, it seems like the fix 
> ought to be applied there.
>

java.library.path variable is set from the PATH env variable, among 
other sources.
It can be redefined through command line argument, but it's a different 
story.
In this particular case it's not related to cmdtoargs.c.

On Windows PATH may contain quoted entries.
They don't have to be quoted (unless they really contain a semicolon), 
but sometimes they are.
I guess, people may enclose the path in quotes for no particular reason, 
just because it doesn't hurt.

> In addition, this change simply strips quotes that happen to occur at 
> the boundaries of substrings between path separators. It doesn't do 
> any actual quoting, that is, protecting the path separator character 
> so that it can be used as part of an actual path instead of as a 
> separator. (But I'm not sure that's actually a supported case anyway.) 
> Simply stripping quotes seems wrong.

Yes.
I propose only a partial solution for the only edge case -- when an 
entry of PATH is entirely quoted.
Later, we may want to implement more complex logic, which deals with 
semicolons in paths and with partially quoted string.
But in that case the full logic should be well documented somewhere.

> Unfortunately there are no details in the bug report JDK-8067951, so I 
> can't tell what the real problem is.
>
Basically, the complain was about skipping quoted paths from PATH when 
looking for dll's.

Here's the updated webrev:
http://cr.openjdk.java.net/~igerasim/8067951/2/webrev/

Sincerely yours,
Ivan



From vladimir.x.ivanov at oracle.com  Thu Dec 25 15:53:36 2014
From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov)
Date: Thu, 25 Dec 2014 18:53:36 +0300
Subject: [9] RFR (M): 8067344: Adjust
	java/lang/invoke/LFCaching/LFGarbageCollectedTest.java
	for recent changes in java.lang.invoke
In-Reply-To: <549AAFA8.40505@gmail.com>
References: <549884E7.8040204@oracle.com> <549962C4.2040301@oracle.com>
	<549AAFA8.40505@gmail.com>
Message-ID: <549C3300.3000501@oracle.com>

Peter,

Thanks for the feedback!

Your idea to use SoftReferences and check the referent sounds interesting.

However, I'm in favor of PhantomReferences here. Though SoftRefs have 
some benefits w.r.t. current LF cache implementation, they unnecessarily 
leak implementation details into the test.

PhantomRefs clearly state the intention of the test - get a notification 
once an object can be garbage collected.

Also, it makes the test more accurate. If we were to switch from 
SoftRefs to WeakRefs in the LF cache implementation, we wouldn't need to 
update the test.

Best regards,
Vladimir Ivanov

On 12/24/14 3:20 PM, Peter Levart wrote:
> Hi Vladimir,
>
> I just wanted to ask about the reason you used PhantomReference to
> detect that a referent is not softly reachable any more. You could use
> another SoftReference or a WeakReference for the same effect, since it
> is guaranteed that all SoftReferences for same referent are cleared
> atomically and WeakReferences are cleared when referent is not softly
> reachable any more. Using Weak or PhantomReference in test can
> theoretically give false failures, since the object can still be weakly
> of phantom reachable, but not softly reachable any more.
>
> I think that it is enough for test to check that the referent is not
> softly reachable any more, since cache is using SoftReferences.
> Therefore it would be most appropriate to use a SoftReference in test too.
>
> What do you think?
>
> Regards, Peter
>
> On 12/23/2014 01:40 PM, Vladimir Ivanov wrote:
>> Spotted some more problems:
>>   - need to skip identity operations (identity_* LambdaForms) in the
>> test, since corresponding LambdaForms reside in a permanent cache;
>>
>>   - need to keep original test data for diagnostic purposes, since
>> getTestCaseData() produces new instance.
>>
>> Updated version:
>> http://cr.openjdk.java.net/~vlivanov/8067344/webrev.01/
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> On 12/22/14 11:53 PM, Vladimir Ivanov wrote:
>>> http://cr.openjdk.java.net/~vlivanov/8067344/webrev.00/
>>> https://bugs.openjdk.java.net/browse/JDK-8067344
>>>
>>> LFGarbageCollectedTest should be adjusted after JDK-8057020.
>>>
>>> There are a couple of problems with the test.
>>>
>>> (1) Existing logic to test that LambdaForm instance is collected isn't
>>> stable enough. Consequent System.GCs can hinder reference enqueueing.
>>> To speed up the test, I added -XX:SoftRefLRUPolicyMSPerMB=0 and limited
>>> the heap by -Xmx64m.
>>>
>>> (2) MethodType-based invoker caches are deliberately left strongly
>>> reachable. So, they should be skipped in the test.
>>>
>>> (3) Added additional diagnostic output to simplify failure analysis
>>> (test case details, method handle type and LambdaForm, heap dump
>>> (optional, -DHEAP_DUMP=true)).
>>>
>>> Testing: failing test.
>>>
>>> Thanks!
>>>
>>> Best regards,
>>> Vladimir Ivanov
>


From ivan.gerasimov at oracle.com  Fri Dec 26 08:58:51 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 26 Dec 2014 11:58:51 +0300
Subject: RFR: 8068230: java.util.zip.Deflater.init throws InternalError
Message-ID: <549D234B.4090600@oracle.com>

Hello!

Some zlib-related tests fail on Solaris hosts, throwing InternalError 
with no detailed message.
This might be due to incompatible version of zlib library installed on 
the host.

To have a better diagnostics, it is proposed to specifically check for 
Z_VERSION_ERROR error code and issue a specific message in that case.

Would you please help review the fix?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8068230
WEBREV: http://cr.openjdk.java.net/~igerasim/8068230/0/webrev/

Sincerely yours,
Ivan


From ivan.gerasimov at oracle.com  Fri Dec 26 10:02:45 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Fri, 26 Dec 2014 13:02:45 +0300
Subject: RFR: 8067951: System.loadLibrary cannot find library when path
	contains quoted entry
In-Reply-To: <549C2341.6010807@oracle.com>
References: <54996EB6.9080908@oracle.com>	<29A1F964-41A3-497D-8FB7-4574EF2CFBF3@oracle.com>	<549A992F.7030307@oracle.com>
	<549B14FE.7070800@oracle.com> <549C2341.6010807@oracle.com>
Message-ID: <549D3245.8070508@oracle.com>

Hi!

I changed my mind about handling only entirely quoted entries in PATH.
The webrev was updated.

Now, on Windows paths with quoted parts are supported.
If the quoted fragment of the path contains the delimiter -- ';', it 
will be preserved as a part of the path.

This is consistent with how Windows command prompt resolves PATH.

The regression test was extended to cover new functionality.

The webrev was updated in place:
http://cr.openjdk.java.net/~igerasim/8067951/2/webrev/

Sincerely yours,
Ivan


On 25.12.2014 17:46, Ivan Gerasimov wrote:
> Hi Stuart!
>
> On 24.12.2014 22:33, Stuart Marks wrote:
>> Hi Ivan,
>>
>> It's not clear to me that quoting should be applied at this level. On 
>> Unix, quotes are stripped by the shell at the time the command line 
>> is split into arguments, so the values should be treated literally 
>> without further quote processing.
>>
> That's correct.
> At least bash does not recognize quoted entries in PATH.
> Thus, we only need to deal with quotes on Windows, so I updated the 
> webrev.
>
>> The referenced blog post at MSDN talks about Windows, which passes 
>> the entire command string to the program, which then is responsible 
>> for splitting it into arguments or otherwise parsing it. This seems 
>> to occur in the file
>>
>>     jdk/src/java.base/windows/native/libjli/cmdtoargs.c
>>
>> If the logic in that file is mishandling quotes, it seems like the 
>> fix ought to be applied there.
>>
>
> java.library.path variable is set from the PATH env variable, among 
> other sources.
> It can be redefined through command line argument, but it's a 
> different story.
> In this particular case it's not related to cmdtoargs.c.
>
> On Windows PATH may contain quoted entries.
> They don't have to be quoted (unless they really contain a semicolon), 
> but sometimes they are.
> I guess, people may enclose the path in quotes for no particular 
> reason, just because it doesn't hurt.
>
>> In addition, this change simply strips quotes that happen to occur at 
>> the boundaries of substrings between path separators. It doesn't do 
>> any actual quoting, that is, protecting the path separator character 
>> so that it can be used as part of an actual path instead of as a 
>> separator. (But I'm not sure that's actually a supported case 
>> anyway.) Simply stripping quotes seems wrong.
>
> Yes.
> I propose only a partial solution for the only edge case -- when an 
> entry of PATH is entirely quoted.
> Later, we may want to implement more complex logic, which deals with 
> semicolons in paths and with partially quoted string.
> But in that case the full logic should be well documented somewhere.
>
>> Unfortunately there are no details in the bug report JDK-8067951, so 
>> I can't tell what the real problem is.
>>
> Basically, the complain was about skipping quoted paths from PATH when 
> looking for dll's.
>
> Here's the updated webrev:
> http://cr.openjdk.java.net/~igerasim/8067951/2/webrev/
>
> Sincerely yours,
> Ivan
>
>
>



From kumar.x.srinivasan at oracle.com  Fri Dec 26 17:42:42 2014
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 26 Dec 2014 09:42:42 -0800
Subject: RFR: 8067889: 4 pack200 tests fail on mac since jdk became modular
In-Reply-To: <54946404.6040006@oracle.com>
References: <54946404.6040006@oracle.com>
Message-ID: <549D9E12.8060800@oracle.com>

New webrev uploaded with comment suggested by Amy Lu.

The revised patch is here:
http://cr.openjdk.java.net/~ksrini/8067889/webrev.1/webrev.delta/index.html

The full patch:
http://cr.openjdk.java.net/~ksrini/8067889/webrev.1

Thanks
Kumar

On 12/19/2014 9:44 AM, Kumar Srinivasan wrote:
> Hello,
>
> Please review a simplification of the JAR locator service, with the 
> modular JDK there
> is no need to search for JARs in the jdk, the golden.jar exists in a 
> well known place
> simply use this location.
>
> http://cr.openjdk.java.net/~ksrini/8067889/webrev.0/
>
> Thanks
> Kumar
>



From xueming.shen at oracle.com  Fri Dec 26 17:58:42 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 26 Dec 2014 09:58:42 -0800
Subject: RFR: 8068230: java.util.zip.Deflater.init throws InternalError
In-Reply-To: <549D234B.4090600@oracle.com>
References: <549D234B.4090600@oracle.com>
Message-ID: <549DA1D2.3050408@oracle.com>

On 12/26/14 12:58 AM, Ivan Gerasimov wrote:
> Hello!
>
> Some zlib-related tests fail on Solaris hosts, throwing InternalError 
> with no detailed message.
> This might be due to incompatible version of zlib library installed on 
> the host.
>
> To have a better diagnostics, it is proposed to specifically check for 
> Z_VERSION_ERROR error code and issue a specific message in that case.
>
> Would you please help review the fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8068230
> WEBREV: http://cr.openjdk.java.net/~igerasim/8068230/0/webrev/
>
> Sincerely yours,
> Ivan
Hi Ivan,

I'm not sure if it is related to JDK-8008759 which has been fixed in 8. 
That one is also related
to the fastdebug binaries, though the issue is more like other native 
code calls into jdk zlib code.

As far as I'm aware of those versions of Solaris jdk/jre should be 
statically linked with our own
zlib library, it is hard to image that it starts to call a native 
platform zlib.

Have you run the test version of jdk/jre with your patch in the similar 
testing environment?
Though the patch looks harmless.

-sherman



From chris.hegarty at oracle.com  Sat Dec 27 09:52:17 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Sat, 27 Dec 2014 09:52:17 +0000
Subject: RFR: 8067889: 4 pack200 tests fail on mac since jdk became modular
In-Reply-To: <549D9E12.8060800@oracle.com>
References: <54946404.6040006@oracle.com> <549D9E12.8060800@oracle.com>
Message-ID: <868E3B82-6BA8-41A0-B8CD-D9AD98550A20@oracle.com>

The original change, and the additional cleanup, look good to me Kumar.

-Chris.



> On 26 Dec 2014, at 17:42, Kumar Srinivasan <kumar.x.srinivasan at oracle.com> wrote:
> 
> New webrev uploaded with comment suggested by Amy Lu.
> 
> The revised patch is here:
> http://cr.openjdk.java.net/~ksrini/8067889/webrev.1/webrev.delta/index.html
> 
> The full patch:
> http://cr.openjdk.java.net/~ksrini/8067889/webrev.1
> 
> Thanks
> Kumar
> 
>> On 12/19/2014 9:44 AM, Kumar Srinivasan wrote:
>> Hello,
>> 
>> Please review a simplification of the JAR locator service, with the modular JDK there
>> is no need to search for JARs in the jdk, the golden.jar exists in a well known place
>> simply use this location.
>> 
>> http://cr.openjdk.java.net/~ksrini/8067889/webrev.0/
>> 
>> Thanks
>> Kumar
> 


From doychin at dsoft-bg.com  Sat Dec 27 15:41:48 2014
From: doychin at dsoft-bg.com (Doychin Bondzhev)
Date: Sat, 27 Dec 2014 17:41:48 +0200
Subject: java.net.NetworkInterfaces and Linux with multiple addresses on single
	interface
Message-ID: <549ED33C.8000409@dsoft-bg.com>

Hi,

I want to report for a problem that I see when I have more then one IP 
addresses assigned to same interface.

Here is an output from ip addr command on my linux box:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
     inet 127.0.0.1/8 scope host lo
     inet6 ::1/128 scope host
        valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
state UP qlen 1000
     link/ether 08:00:27:fc:25:9f brd ff:ff:ff:ff:ff:ff
     inet 192.168.1.4/24 brd 192.168.1.255 scope global eth0
     inet6 fe80::a00:27ff:fefc:259f/64 scope link
        valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast 
state UP qlen 1000
     link/ether 08:00:27:b1:42:d0 brd ff:ff:ff:ff:ff:ff
     inet 192.168.240.1/24 brd 192.168.240.255 scope global eth1
     inet 192.168.241.1/24 brd 192.168.241.255 scope global eth1
     inet 192.168.239.1/24 brd 192.168.239.255 scope global eth1
     inet 10.0.0.1/22 brd 10.0.3.255 scope global eth1
     inet6 fe80::a00:27ff:feb1:42d0/64 scope link
        valid_lft forever preferred_lft forever

And this is the output of a test java program that uses 
NetworkInterfaces class to display all IP addresses and their 
corresponding settings:

eth1:10.0.0.1/24 broadcast:192.168.240.255
eth1:192.168.239.1/24 broadcast:192.168.240.255
eth1:192.168.241.1/24 broadcast:192.168.240.255
eth1:192.168.240.1/24 broadcast:192.168.240.255
eth0:192.168.1.4/24 broadcast:192.168.1.255
lo:127.0.0.1/8

As you can see there are 2 problems visible here:

1. On all eth1 lines same broadcast is displayed. The value is the 
broadcast of the first IP address set on that interface

2. All addresses are with prefix length of 24 which is not correct. We 
have 10.0.0.1/22  in the "ip addr" output.

So the problem is in NetworkInterfaces native code for Unix.

For IPv4 addresses that code uses 2 functions (getBordacast and 
getSubnet and these 2 functions use ioctl with SIOCGIFNETMASK and 
SIOCGIFBRDADDR. Both of these requests receive as parameter interface 
name. They are not prepared to work in environments where you can 
specify more then one IP on the same interface without using virtual 
interfaces.

So using virutal interfaces is the only workaround of this problem for 
the moment.

I propose another method of reading ip address information for 
interfaces that will use getifaddrs/freeifaddrs.

getifaddrs knows how to handle this case properly. It returns all the 
necessary information in an array of "struct ifaddrs"

Any toughs on this proposition?

-- 
Doychin Bondzhev
dSoft-Bulgaria Ltd.
PowerPro - billing & provisioning solution for Service providers
PowerStor - Warehouse & POS
http://www.dsoft-bg.com/
Mobile: +359888243116


From peter.firmstone at zeus.net.au  Sun Dec 28 01:03:22 2014
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sun, 28 Dec 2014 11:03:22 +1000
Subject: Explicit Serialization API and Security
Message-ID: <549F56DA.7040004@zeus.net.au>

Is there any interest in developing an explicit API for Serialization?:

   1. Use a public constructor signature with a single argument,
      ReadSerialParameters (read only, writable only by the
      serialization framework) to recreate objects, subclasses (when
      permitted) call this first from their own constructor, they have
      an identical constructor signature.  ReadSerialParameters that are
      null may contain a circular reference and will be available after
      construction, see #3 below.
   2. Use a factory method (defined by an interface) with one parameter,
      WriteSerialParameters (write only, readable only by the
      serialization framework), this method can be overridden by
      subclasses (when permitted)
   3. For circular links, a public method (defined by an interface) that
      accepts one argument, ReadSerialParameters, this method is called
      after the constructor completes, subclasses overriding this should
      call the superclass method.  If this method is not called, an
      implementation, if known to possibly contain circular links,
      should check it has been fully initialized in each object method
      called.
   4. Retains compatibility with current serialization stream format.
   5. Each serial field has a name, calling class and object reference,
      similar to explicitly declaring "private static final
      ObjectStreamField[] serialPersistentFields ".

Benefits:

   1. An object's internal form is not publicised.
   2. Each class in an object's heirarchy can use a static method to
      check invarients and throw an exception, prior to
      java.lang.Object's constructor being called, preventing
      construction and avoiding finalizer attacks.
   3. Final field friendly.
   4. Compatible with existing serial form.
   5. Flexible serial form evolution.
   6. All methods are public and explicitly defined.
   7. All class ProtectionDomain's exist in the current execution
      context, allowing an object to throw a SecurityException before
      construction.
   8. Less susceptible to deserialization attacks.

Problems:

   1. Implementations cannot be package private or private.  Implicit
      serialization publicises internal form, any thoughts?

Recommendations:

   1. Create a security check in the serialization framework for
      implicit serialization, allowing administrators to reduce their
      deserialization attack surface.
   2. For improved security, disallow classes implementing explicit
      serialization from having static state and static initializer
      blocks, only allow static methods, this would require complier and
      verifier changes.
   3. Alternative to #2, allow final static fields, but don't allow
      static initializer blocks or mutable static fields, similar to
      interfaces.

Penny for your thoughts?

Regards,

Peter Firmstone.


From Alan.Bateman at oracle.com  Sun Dec 28 15:04:19 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 28 Dec 2014 15:04:19 +0000
Subject: RFR: 8068230: java.util.zip.Deflater.init throws InternalError
In-Reply-To: <549D234B.4090600@oracle.com>
References: <549D234B.4090600@oracle.com>
Message-ID: <54A01BF3.5010804@oracle.com>

On 26/12/2014 08:58, Ivan Gerasimov wrote:
> Hello!
>
> Some zlib-related tests fail on Solaris hosts, throwing InternalError 
> with no detailed message.
> This might be due to incompatible version of zlib library installed on 
> the host.
>
> To have a better diagnostics, it is proposed to specifically check for 
> Z_VERSION_ERROR error code and issue a specific message in that case.
>
> Would you please help review the fix?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8068230
> WEBREV: http://cr.openjdk.java.net/~igerasim/8068230/0/webrev/

There isn't sufficient information in the bug report but since it is a 
fastdebug build then it would be good to get JDK-8008759 back-ported to 
7uX and see if the issue duplicates.

As regards the proposed change to improve then exception when an 
incompatible zlib is encountered then it probably should be moved to 
another issue. One suggestion is to keep it as an internal error and use 
the same exception message as is already done in Inflater.init.

-Alan.


From Alan.Bateman at oracle.com  Mon Dec 29 08:46:21 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Dec 2014 08:46:21 +0000
Subject: JDK 9 RFR of 8064463: BigDecimal should populate
	NumberFormatException message
In-Reply-To: <081B9550-613C-4210-80C7-7F4171FCAD6B@oracle.com>
References: <081B9550-613C-4210-80C7-7F4171FCAD6B@oracle.com>
Message-ID: <54A114DD.6060807@oracle.com>

On 22/12/2014 21:13, Brian Burkhalter wrote:
> Please review at your convenience.
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8064463
> Patch:	http://cr.openjdk.java.net/~bpb/8064463/webrev.00/
>
> Summary:
>
> Ensure that the message strings of all NumberFormatExceptions are populated with appropriate content, excluding where the NFE merely wraps another exception in its cause.
>
> It was suggested in the issue description to include the contents of the supplied character array in the exception message. This is not done in this patch for the reason that the resulting string could be quite large. If it seems reasonable to include the characters the patch can be so amended.
>
>
This looks okay to me. A minor inconsistency is that one of the 
"Exponent overflow " cases has a trailing dot, the other doesn't.

-Alan


From Alan.Bateman at oracle.com  Mon Dec 29 09:08:15 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Dec 2014 09:08:15 +0000
Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file
	descriptors
In-Reply-To: <549AA573.2060801@gmail.com>
References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com>
	<549AA573.2060801@gmail.com>
Message-ID: <54A119FF.4060103@oracle.com>

On 24/12/2014 11:37, Peter Levart wrote:
> Hi Brad,
>
> Thanks for looking into this. Here's updated webrev:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.02/ 
>
>
This mostly looks good to me too, except the permission checking. As I 
read it, getInputStream uses getCanonicalFile and thus the permission 
check will be happen early and so it makes me wonder if checkRead is 
needed. Additionally, both of the uses are in privileged blocks so it 
looks like checkRead will always be called with a stack that has 
AllPermission anyway.

-Alan.


From Alan.Bateman at oracle.com  Mon Dec 29 09:12:45 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Dec 2014 09:12:45 +0000
Subject: RFR: 8066834: tools/pack200/CommandLineTests.java does not conform
	ProblemList.txt style
In-Reply-To: <549B0C51.7090107@oracle.com>
References: <549B0C51.7090107@oracle.com>
Message-ID: <54A11B0D.2010500@oracle.com>

On 24/12/2014 18:56, Kumar Srinivasan wrote:
> Hello,
>
> Please review this simple fix, enclosed.
> Thanks in advance.
>
> Kumar
>
> diff --git a/test/ProblemList.txt b/test/ProblemList.txt
> --- a/test/ProblemList.txt
> +++ b/test/ProblemList.txt
> @@ -267,7 +267,7 @@
>
>  # Tests take too long, on sparcs see 7143279
>  # also see 8059906
> -tools/pack200/CommandLineTests.java
> +tools/pack200/CommandLineTests.java generic-all
>  tools/pack200/Pack200Test.java solaris-all,macosx-all
>
I don't know this slipped in but the change looks okay to me.

-Alan.


From Alan.Bateman at oracle.com  Mon Dec 29 09:14:33 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Dec 2014 09:14:33 +0000
Subject: RFR: 8067889: 4 pack200 tests fail on mac since jdk became modular
In-Reply-To: <549D9E12.8060800@oracle.com>
References: <54946404.6040006@oracle.com> <549D9E12.8060800@oracle.com>
Message-ID: <54A11B79.4080701@oracle.com>

On 26/12/2014 17:42, Kumar Srinivasan wrote:
> New webrev uploaded with comment suggested by Amy Lu.
>
> The revised patch is here:
> http://cr.openjdk.java.net/~ksrini/8067889/webrev.1/webrev.delta/index.html 
>
>
> The full patch:
> http://cr.openjdk.java.net/~ksrini/8067889/webrev.1
>
Updated patch looks good to me.

-Alan.



From peter.levart at gmail.com  Mon Dec 29 09:45:14 2014
From: peter.levart at gmail.com (Peter Levart)
Date: Mon, 29 Dec 2014 10:45:14 +0100
Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file
	descriptors
In-Reply-To: <54A119FF.4060103@oracle.com>
References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com>
	<549AA573.2060801@gmail.com> <54A119FF.4060103@oracle.com>
Message-ID: <54A122AA.3010004@gmail.com>

On 12/29/2014 10:08 AM, Alan Bateman wrote:
> On 24/12/2014 11:37, Peter Levart wrote:
>> Hi Brad,
>>
>> Thanks for looking into this. Here's updated webrev:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.02/ 
>>
>>
> This mostly looks good to me too, except the permission checking. As I 
> read it, getInputStream uses getCanonicalFile and thus the permission 
> check will be happen early and so it makes me wonder if checkRead is 
> needed. Additionally, both of the uses are in privileged blocks so it 
> looks like checkRead will always be called with a stack that has 
> AllPermission anyway.
>
> -Alan.

Thanks for looking at this, Alan.

You're right about File.getCanonicalFile(). It already checks read 
permission for a file. The additional explicit check is superfluous. I 
have removed it.

With explicit check I wanted the API to behave uniformly regardless of 
whether the returned stream is opened by getInputStream() call or an 
already opened stream is just returned. getCannonicalFile() already 
takes care of it. Here's the updated webrev:

http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.03/


Regards, Peter



From ivan.gerasimov at oracle.com  Mon Dec 29 11:31:34 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 29 Dec 2014 14:31:34 +0300
Subject: RFR: 8068230: java.util.zip.Deflater.init throws InternalError
In-Reply-To: <54A01BF3.5010804@oracle.com>
References: <549D234B.4090600@oracle.com> <54A01BF3.5010804@oracle.com>
Message-ID: <54A13B96.2020900@oracle.com>

Thanks Sherman and Alan for the reference to JDK-8008759!

It does seem to be the root cause of this issue also.
I've just requested an approval to backport that fix into jdk 7u.

To improve the error message of Deflater.init, I've created another 
issue: JDK-8068338.

Sincerely yours,
Ivan

On 28.12.2014 18:04, Alan Bateman wrote:
> On 26/12/2014 08:58, Ivan Gerasimov wrote:
>> Hello!
>>
>> Some zlib-related tests fail on Solaris hosts, throwing InternalError 
>> with no detailed message.
>> This might be due to incompatible version of zlib library installed 
>> on the host.
>>
>> To have a better diagnostics, it is proposed to specifically check 
>> for Z_VERSION_ERROR error code and issue a specific message in that 
>> case.
>>
>> Would you please help review the fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8068230
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8068230/0/webrev/
>
> There isn't sufficient information in the bug report but since it is a 
> fastdebug build then it would be good to get JDK-8008759 back-ported 
> to 7uX and see if the issue duplicates.
>
> As regards the proposed change to improve then exception when an 
> incompatible zlib is encountered then it probably should be moved to 
> another issue. One suggestion is to keep it as an internal error and 
> use the same exception message as is already done in Inflater.init.
>
> -Alan.
>
>



From ivan.gerasimov at oracle.com  Mon Dec 29 11:40:32 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 29 Dec 2014 14:40:32 +0300
Subject: RFR: 8068338: Better message about incompatible zlib in Deflater.init
Message-ID: <54A13DB0.6020809@oracle.com>

Hello!

It it proposed to enhance the error message in the manner it was done in 
JDK-8008759.

Would you please help review this simple change?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8068338
WEBREV: http://cr.openjdk.java.net/~igerasim/8068338/0/webrev/

Sincerely yours,
Ivan


From Alan.Bateman at oracle.com  Mon Dec 29 15:51:53 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Dec 2014 15:51:53 +0000
Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file
	descriptors
In-Reply-To: <54A122AA.3010004@gmail.com>
References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com>
	<549AA573.2060801@gmail.com> <54A119FF.4060103@oracle.com>
	<54A122AA.3010004@gmail.com>
Message-ID: <54A17899.4060304@oracle.com>

On 29/12/2014 09:45, Peter Levart wrote:
>
> Thanks for looking at this, Alan.
>
> You're right about File.getCanonicalFile(). It already checks read 
> permission for a file. The additional explicit check is superfluous. I 
> have removed it.
>
> With explicit check I wanted the API to behave uniformly regardless of 
> whether the returned stream is opened by getInputStream() call or an 
> already opened stream is just returned. getCannonicalFile() already 
> takes care of it. Here's the updated webrev:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.03/ 
>
Updated patch looks good to me.

-Alan.


From Alan.Bateman at oracle.com  Mon Dec 29 15:53:20 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 29 Dec 2014 15:53:20 +0000
Subject: RFR: 8068338: Better message about incompatible zlib in
	Deflater.init
In-Reply-To: <54A13DB0.6020809@oracle.com>
References: <54A13DB0.6020809@oracle.com>
Message-ID: <54A178F0.704@oracle.com>

On 29/12/2014 11:40, Ivan Gerasimov wrote:
> Hello!
>
> It it proposed to enhance the error message in the manner it was done 
> in JDK-8008759.
>
> Would you please help review this simple change?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8068338
> WEBREV: http://cr.openjdk.java.net/~igerasim/8068338/0/webrev/
This looks okay to me.

I assume that JDK-8068230 will be closed once it is verified that 
JDK-8008759 is the real issue.

-Alan.


From brian.burkhalter at oracle.com  Mon Dec 29 16:39:31 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 29 Dec 2014 08:39:31 -0800
Subject: JDK 9 RFR of 8064463: BigDecimal should populate
	NumberFormatException message
In-Reply-To: <54A114DD.6060807@oracle.com>
References: <081B9550-613C-4210-80C7-7F4171FCAD6B@oracle.com>
	<54A114DD.6060807@oracle.com>
Message-ID: <28051825-859D-43D8-AD51-95A3588A04AC@oracle.com>


On Dec 29, 2014, at 12:46 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:

>> Patch:	http://cr.openjdk.java.net/~bpb/8064463/webrev.00/
>> 
>> [?]
>> 
>> 
> This looks okay to me. A minor inconsistency is that one of the "Exponent overflow " cases has a trailing dot, the other doesn't.

Thanks. I?ll add a dot at line 559 before pushing.

Brian

From brian.goetz at oracle.com  Mon Dec 29 19:08:44 2014
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 29 Dec 2014 14:08:44 -0500
Subject: Explicit Serialization API and Security
In-Reply-To: <549F56DA.7040004@zeus.net.au>
References: <549F56DA.7040004@zeus.net.au>
Message-ID: <54A1A6BC.6070109@oracle.com>

So, if I understand this correctly, the way this would get used is:

class BaseFoo implements Serializable {
     private final int x;

     public BaseFoo(ReadSerial rs) {
         this(rs.getInt("x"));
     }

     public BaseFoo(int x) {
         this.x = x;
     }
}

Right?

What happens with subclasses?  I think then I need an extra RS arg in my 
constructors:

class SubFoo extends BaseFoo {
     private final int y;

     public SubFoo(ReadSerial rs) {
         this(rs.getInt("y"));
     }

     public BaseFoo(ReadSerial rs, int y) {
         super(rs);
         this.y = y;
     }
}

Is this what you envision?





On 12/27/2014 8:03 PM, Peter Firmstone wrote:
> Is there any interest in developing an explicit API for Serialization?:
>
>    1. Use a public constructor signature with a single argument,
>       ReadSerialParameters (read only, writable only by the
>       serialization framework) to recreate objects, subclasses (when
>       permitted) call this first from their own constructor, they have
>       an identical constructor signature.  ReadSerialParameters that are
>       null may contain a circular reference and will be available after
>       construction, see #3 below.
>    2. Use a factory method (defined by an interface) with one parameter,
>       WriteSerialParameters (write only, readable only by the
>       serialization framework), this method can be overridden by
>       subclasses (when permitted)
>    3. For circular links, a public method (defined by an interface) that
>       accepts one argument, ReadSerialParameters, this method is called
>       after the constructor completes, subclasses overriding this should
>       call the superclass method.  If this method is not called, an
>       implementation, if known to possibly contain circular links,
>       should check it has been fully initialized in each object method
>       called.
>    4. Retains compatibility with current serialization stream format.
>    5. Each serial field has a name, calling class and object reference,
>       similar to explicitly declaring "private static final
>       ObjectStreamField[] serialPersistentFields ".
>
> Benefits:
>
>    1. An object's internal form is not publicised.
>    2. Each class in an object's heirarchy can use a static method to
>       check invarients and throw an exception, prior to
>       java.lang.Object's constructor being called, preventing
>       construction and avoiding finalizer attacks.
>    3. Final field friendly.
>    4. Compatible with existing serial form.
>    5. Flexible serial form evolution.
>    6. All methods are public and explicitly defined.
>    7. All class ProtectionDomain's exist in the current execution
>       context, allowing an object to throw a SecurityException before
>       construction.
>    8. Less susceptible to deserialization attacks.
>
> Problems:
>
>    1. Implementations cannot be package private or private.  Implicit
>       serialization publicises internal form, any thoughts?
>
> Recommendations:
>
>    1. Create a security check in the serialization framework for
>       implicit serialization, allowing administrators to reduce their
>       deserialization attack surface.
>    2. For improved security, disallow classes implementing explicit
>       serialization from having static state and static initializer
>       blocks, only allow static methods, this would require complier and
>       verifier changes.
>    3. Alternative to #2, allow final static fields, but don't allow
>       static initializer blocks or mutable static fields, similar to
>       interfaces.
>
> Penny for your thoughts?
>
> Regards,
>
> Peter Firmstone.


From brent.christian at oracle.com  Mon Dec 29 21:43:37 2014
From: brent.christian at oracle.com (Brent Christian)
Date: Mon, 29 Dec 2014 13:43:37 -0800
Subject: RFR: 8068347: Add java/lang/ClassLoader/deadlock/GetResource.java
	to ProblemList.txt
Message-ID: <54A1CB09.2060204@oracle.com>

Hi,

The
   java/lang/ClassLoader/deadlock/GetResource.java
test has started causing problems for Hotspot nightly testing.  A "real" 
fix is being worked on under [1], but in the meantime, this test should 
be added to the ProblemList.

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

The diff ('jdk' repo) is:

--- a/test/ProblemList.txt	Mon Dec 29 09:10:15 2014 -0800
+++ b/test/ProblemList.txt	Mon Dec 29 13:32:41 2014 -0800
@@ -120,6 +120,10 @@

  # jdk_lang

+# 8029891
+java/lang/ClassLoader/deadlock/GetResource.java                 generic-all
+
+
 
############################################################################

Thanks,
-Brent

1. https://bugs.openjdk.java.net/browse/JDK-8029891


From stuart.marks at oracle.com  Mon Dec 29 23:34:25 2014
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 29 Dec 2014 15:34:25 -0800
Subject: RFR 8066085: Need a sanity test for rmic -iiop
In-Reply-To: <549ADB7A.1040900@oracle.com>
References: <548A71E7.8000209@oracle.com> <548AA276.7080701@oracle.com>
	<5493F63D.6030702@oracle.com> <549A48B8.7080205@oracle.com>
	<549ADB7A.1040900@oracle.com>
Message-ID: <54A1E501.9000804@oracle.com>

Hi Felix,

Thanks for the updates. I've pushed the changeset. [1] Sorry for the delay; 
holidays, you know.

s'marks

[1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/af229cf4a61a

On 12/24/14 7:27 AM, FELIX YANG wrote:
> Hi Stuart,
>       this is the updated webrev:
> http://cr.openjdk.java.net/~xiaofeya/8066085/webrev.02/. Please sponsor this
> changeset for me.
>
> Thank you very much,
> -Felix
> On 12/24/2014 1:01 PM, Stuart Marks wrote:
>> Hi Felix,
>>
>> Good improvements. I think this is pretty close; I have just a few minor
>> comments.
>>
>> * The test is named IIOPSanityTest but it's in a directory named
>> iiopCompilation. I don't think we need different names. There are many test
>> classes named "Foo" that reside in a directory named "foo"; I think we should
>> do the same here. I think keeping the directory name "iiopCompilation" and
>> renaming the class to "IIOPCompilation" makes things a bit more descriptive.
>>
>> * Declaring string constants like RMIC_PROGRAM, IIOP_OPTION, and CP_OPTION
>> doesn't really help things, since they're each used exactly once, the string
>> values are unlikely to change, and the symbolic names are just derived from
>> the string vaues. You might as well use string literals directly in each place
>> they're needed.
>>
>> * Printing the command that's about to be executed is a good idea, but the
>> printf statement that prints the command has to be kept in synch with the
>> array containing the command and args. If the command were to change, it'd be
>> easy to forget to update the printf statement or to get it wrong.
>>
>> * I'll also observe that there is an overload of the ProcessBuilder
>> constructor that takes a List<String> instead of a String[]. Lists are often
>> easier to work with than arrays, and they have a toString() method that can be
>> used implicitly by print statements. This suggests an alternative for
>> constructing the rmic command line, something like the following:
>>
>>     List<String> command = Arrays.asList(
>>         rmicProgramStr, "-iiop", "-classpath", testClasses, classname);
>>     System.out.println("Running command: " + command);
>>
>> After you fix these up I think this will be ready to go in.
>>
>> I can sponsor this changeset for you if you need a sponsor.
>>
>> Thanks,
>>
>> s'marks
>>
>>
>>
>>
>> On 12/19/14 1:56 AM, FELIX YANG wrote:
>>> Hi Stuart,
>>>      please review the updated webrev:
>>> http://cr.openjdk.java.net/~xiaofeya/8066085/webrev.01/
>>>
>>> Thanks,
>>> -Felix
>>> On 12/12/2014 4:08 PM, Stuart Marks wrote:
>>>> On 12/11/14 8:41 PM, FELIX YANG wrote:
>>>>> Hi all,
>>>>>      please review the fix to add a sanity checking for rmic -iiop compiling.
>>>>>
>>>>> Bug:
>>>>>         https://bugs.openjdk.java.net/browse/JDK-8066085
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~xiaofeya/8066085/webrev.00/
>>>>
>>>> Hi Felix,
>>>>
>>>> Thanks for picking up the writing of this test. I have several comments.
>>>>
>>>> 1. Usually we try to avoid naming tests after bug IDs. There are such tests in
>>>> the suite but most tests have more descriptive names. I'd suggest something
>>>> like "iiopSanityTest".
>>>>
>>>> 2. There are other rmic tests in jdk/test/sun/rmi/rmic; the test should be
>>>> moved there (and the path to the TestLibrary updated correspondingly).
>>>>
>>>> 3. The test summary should be a bit more explicit. Instead of "a sanity test
>>>> for rmic -iiop compiling" I'd suggest something like "Compiles a
>>>> PortableRemoteObject with rmic -iiop and ensures that stub and tie classes are
>>>> generated."
>>>>
>>>> 4. When invoking rmic, you need to make sure to pass the -iiop option.
>>>>
>>>> 5. Add check for the _Tie class as well as the _Stub class. Not that it really
>>>> matters, since we know these classes are in the unnamed package, but the stub
>>>> and tie class files would end up in directories corresponding to their package
>>>> names -- if they were in a named package.
>>>>
>>>> 6. In doTest(), the try/catch of InterruptedException and IOException and call
>>>> to TestLibrary.bomb() is mostly unnecessary. (Yes, other RMI tests do this,
>>>> and I've been removing it where appropriate. In the RMI test library, the
>>>> bomb() call merely wraps and rethrows the exception, and doesn't really add
>>>> any value. It's like calling fail() in a test-ng test.) In general an uncaught
>>>> exception will cause a jtreg test to fail, so you might as well just declare
>>>> the method with "throws Exception" and let them propagate. This helps reduce
>>>> clutter.
>>>>
>>>> 7. Similarly I'm not sure it's necessary to check the classname argument for
>>>> null; the failure should be apparent enough if classname is null. But if you
>>>> think it's worth it, a concise way to null-check an argument is to use
>>>> Objects.requireNonNull().
>>>>
>>>> 8. The "rmiComplie" method is misnamed (or typo'd); I'd suggest something like
>>>> "runRmic".
>>>>
>>>> 9. Changing the directory of the rmic subprocess is confusing, because it
>>>> makes different parts of the program deal with different paths to the same
>>>> files. In addition, switching directories to the test.classes directory will
>>>> leave the stub/tie classes there, which could possibly confuse future test
>>>> runs, since that directory isn't necessarily cleared between test runs.
>>>>
>>>> The default working directory of jtreg tests is the "scratch" directory, which
>>>> is cleared before each test run. Leaving the current directory as-is when
>>>> running the subprocesses will write the generated stub/tie classes to the
>>>> scratch directory, which is the right thing.
>>>>
>>>> This implies that you'll need to add the -classpath argument and a path to the
>>>> test.classes directory to the rmic command line.
>>>>
>>>> Thanks,
>>>>
>>>> s'marks
>>>>
>>>>
>>>
>


From brian.burkhalter at oracle.com  Tue Dec 30 01:18:13 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 29 Dec 2014 17:18:13 -0800
Subject: JDK 9 RFR of 4026465: Provide more byte array constructors for
	BigInteger 
Message-ID: <48844110-12EF-48E2-B536-FF690C319CDE@oracle.com>

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-4026465
Patch:	http://cr.openjdk.java.net/~bpb/4026465/webrev.00/

Should this issue not look to be worth addressing after all, then I propose that it should be resolved as ?Won?t Fix? rather than be left dangling. If on the other hand the change appears reasonable, then a CCC request will be in order.

Thanks,

Brian

From bradford.wetmore at oracle.com  Tue Dec 30 01:48:37 2014
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Mon, 29 Dec 2014 17:48:37 -0800
Subject: RFR: JDK-8047769 SecureRandom should be more frugal with file
	descriptors
In-Reply-To: <549AA573.2060801@gmail.com>
References: <5492D557.2000807@gmail.com> <5498C5A0.50104@oracle.com>
	<549AA573.2060801@gmail.com>
Message-ID: <54A20475.3040206@oracle.com>

I'm looking at this version of the webrev.

http://cr.openjdk.java.net/~plevart/jdk9-dev/FileInputStreamPool.8047769/webrev.03/ 


I just assigned 8047769 to you.  My username is wetmore, Alan is alanb.

On 12/24/2014 3:37 AM, Peter Levart wrote:

>> Looks like you have a committer status, will you be pushing this?
>
> I can, yes. As soon as we clear-out the remaining questions, right?

Yes.  The comments below are minor and shouldn't need another review 
cycle.  I have started a JPRT job for you, I'll run it through "core" 
target which will give us:

jdk_lang, jdk_math, jdk_util, jdk_io, jdk_net, jdk_nio, jdk_security*, 
jdk_rmi, jdk_text, jdk_time, jdk_other, core_tools.

Anything else?  I'm off tomorrow, I should have full results Wed.

Here are the preliminary results for the jobs that have finished. 
jdk.testlibrary.Asserts is causing compilation errors, additional 
comments below:

/opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:33: 
error: package jdk.testlibrary does not exist
import static jdk.testlibrary.Asserts.*;
                              ^
/opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:52: 
error: cannot find symbol
         assertEquals(bytes.length, nread, "short read");
         ^
   symbol:   method assertEquals(int,int,String)
   location: class FileInputStreamPoolTest
/opt/jprt/T/P1/003505.brwetmor/s/jdk/test/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java:53: 
error: cannot find symbol
         assertTrue(Arrays.equals(readBytes, bytes),
         ^
   symbol:   method assertTrue(boolean,String)
   location: class FileInputStreamPoolTest
3 errors

TEST RESULT: Failed. Compilation failed: Compilation failed

I'm also getting failures in the following test.  I unfortunately have 
to leave now, so don't have time to look at this.  But it did mention 
"seed" so I'm mentioning it here.

TEST: java/lang/invoke/LFCaching/LFGarbageCollectedTest.java

ACTION: main -- Failed. Execution failed: `main' threw exception: 
java.lang.Error: 36 of 39 test cases FAILED! Rerun the test with the 
same "-Dseed=" option as in the log file!
REASON: User specified action: run main/othervm LFGarbageCollectedTest
TIME:   213.406 seconds
messages:
command: main LFGarbageCollectedTest
reason: User specified action: run main/othervm LFGarbageCollectedTest
elapsed time (seconds): 213.406
STDOUT:
-Dseed=6102311124531075592
-DtestLimit=2000
Number of iterations according to -DtestLimit is 153 (1989 cases)
Code cache size is 251658240 bytes
Non-profiled code cache size is 123058253 bytes
Number of iterations limited by code cache size is 84 (1092 cases)
Number of iterations limited by non-profiled code cache size is 41 (533 
cases)
Number of iterations is set to 41 (533 cases)
Not enough time to continue execution. Interrupted.
STDERR:
Iteration 0:
Tested LF caching feature with MethodHandles.foldArguments method.
java.lang.AssertionError: Error: Lambda form is not garbage collected
         at LFGarbageCollectedTest.doTest(LFGarbageCollectedTest.java:81)
         at 
LambdaFormTestCase$TestRun.doIteration(LambdaFormTestCase.java:139)
         at LambdaFormTestCase$$Lambda$2/5042013.call(Unknown Source)
         at 
jdk.testlibrary.TimeLimitedRunner.call(TimeLimitedRunner.java:71)
         at LambdaFormTestCase.runTests(LambdaFormTestCase.java:201)
         at LFGarbageCollectedTest.main(LFGarbageCollectedTest.java:105)
         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

>> In a couple places, there are a few lines > 80 chars.  (It's a pet
>> peeve of mine, this makes side-by-side reviews difficult without a
>> wide monitor.  I realize not everyone shares this view, but they're
>> probably not working on a laptop screen regularly.)
>
> I have wrapped the lines to contain them inside the 80 column margin.

I and my scrubber/slider thank you.  :)

Two minor nits?   SeedGenerator.java:  Lines 507/518

>> Do you need to close the InputStream when last holder is GC'd, or do
>> we just let the FileInputStream's finalizer take care of that?
>
> WeakReference<UncloseableInputStream> is enqueued when it is cleared, so
> at that time we have no access to the referent (UncloseableInputStream)
> any more. We could, in addition, "strongly" reference the underlying
> FileInputStream in the WeakReference subclass itself, but that would
> just prolong the life of FileInputStream (possibly forever if no further
> calls to FileInputStreamPool are made that expunge the references from
> the queue). So yes, we rely on FileInputStream's finalizer, but I don't
> see any other way that would be better than that.

Makes sense, thanks.

> NativePRNG and
> URLSeedGenerator don't have a means of closing underlying resources
> either, so this is not making things any worse.

Yes.

>> Both of these current calls are contained within a
>> AccessContrller.doPriviledged, the checkRead() seems redundant.
>
> That's right, but from encapsulation, uniformity, security and future
> maintainability standpoint, I would keep this logic in. It doesn't hurt.
> Another possibility is to move doPriviliged call to FileInputStreamPool
> itself and declare it's API exposing security capability (of reading any
> file).

I see this was addressed later via Alan's review.

>> In your test case, if assertions are not enabled, the tests at
>> 46/50/51 are noops, e.g. when run by hand.  Generally should directly
>> throw Exceptions.
>
> I modified the test to use jdk.testlibrary.Asserts class. Is this ok
> from "run by hand" perspective or should the test be self-contained?

I've not used this Asserts library yet.  Is this part of TestNG, or 
something new in jtreg or jprt?  If Core-libs is ok with this style of 
doing it, I'm ok.  I'm kind of old-school and tests should be mostly 
self-contained and can be tested via:

     % javac Clazz.java
     % java Clazz

without extra classpaths needed.  I understand this model doesn't work 
with @library and such, so I'm not strongly tied to it.  I can be taught 
new tricks.


>> Core-libs folks?
>
> The documentation doesn't mention threads anywhere in InputStream or
> FileInputStream except in this piece of javadoc for available() method:
...snip...

Ok.

A few minor nits below:

FileInputStreamPool.java
========================
* This method opens an underlying {@link java.io.FileInputStream} for
->
* This method opens an underlying {@link java.io.FileInputStream} for a

* among multiple readers of same {@code file} and ignores
->
* among multiple readers of the same {@code file} and ignores

FileInputStreamPoolTest.java
============================
Generally JTREG labels are immediately following the copyright and 
before the imports.

While what you have is allowed by the JTREG syntax, @test is usually by 
itself, or followed by old SCCS or filename info.

@summary is usually the bug description.  Suggest:

     @summary SecureRandom should be more frugal with file descriptors

48:  This is still using assert.

Maybe issue multiple reads to exercise in1 and in2?  e.g. 2 bytes of 
in1, 4 bytes of in2, then 2 bytes of in1?

IIRC, when I ran this under NetBeans last week, the second testCaching 
didn't clear the WeakReference.

Thanks,

Brad


From chris.hegarty at oracle.com  Tue Dec 30 08:52:39 2014
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 30 Dec 2014 08:52:39 +0000
Subject: RFR: 8068347: Add java/lang/ClassLoader/deadlock/GetResource.java
	to ProblemList.txt
In-Reply-To: <54A1CB09.2060204@oracle.com>
References: <54A1CB09.2060204@oracle.com>
Message-ID: <533639CB-F6DF-4AFA-A321-9196DCDA4FD2@oracle.com>

I?m ok with this Brent.

-Chris.

On 29 Dec 2014, at 21:43, Brent Christian <brent.christian at oracle.com> wrote:

> Hi,
> 
> The
>  java/lang/ClassLoader/deadlock/GetResource.java
> test has started causing problems for Hotspot nightly testing.  A "real" fix is being worked on under [1], but in the meantime, this test should be added to the ProblemList.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8068347
> 
> The diff ('jdk' repo) is:
> 
> --- a/test/ProblemList.txt	Mon Dec 29 09:10:15 2014 -0800
> +++ b/test/ProblemList.txt	Mon Dec 29 13:32:41 2014 -0800
> @@ -120,6 +120,10 @@
> 
> # jdk_lang
> 
> +# 8029891
> +java/lang/ClassLoader/deadlock/GetResource.java                 generic-all
> +
> +
> ############################################################################
> 
> Thanks,
> -Brent
> 
> 1. https://bugs.openjdk.java.net/browse/JDK-8029891



From scolebourne at joda.org  Tue Dec 30 10:33:14 2014
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 30 Dec 2014 10:33:14 +0000
Subject: JDK 9 RFR of 4026465: Provide more byte array constructors for
	BigInteger
In-Reply-To: <48844110-12EF-48E2-B536-FF690C319CDE@oracle.com>
References: <48844110-12EF-48E2-B536-FF690C319CDE@oracle.com>
Message-ID: <CACzrW9CMaKdExmvkMmBEZ86GF-U9qUhKPe2xSLgOvSz6e96U1w@mail.gmail.com>

Just to note that an IndexOutOfBoundsException is mentioned in the
text (line 274, 350) but there is no matching @throws clause. The
IndexOutOfBoundsException could have a message added.

In general, I would expect an offset/length overload for most methods
that take an array, so this seems like a sensible request.

Stephen




On 30 December 2014 at 01:18, Brian Burkhalter
<brian.burkhalter at oracle.com> wrote:
> Please review at your convenience.
>
> Issue:  https://bugs.openjdk.java.net/browse/JDK-4026465
> Patch:  http://cr.openjdk.java.net/~bpb/4026465/webrev.00/
>
> Should this issue not look to be worth addressing after all, then I propose that it should be resolved as ?Won?t Fix? rather than be left dangling. If on the other hand the change appears reasonable, then a CCC request will be in order.
>
> Thanks,
>
> Brian


From ivan.gerasimov at oracle.com  Tue Dec 30 13:20:38 2014
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Tue, 30 Dec 2014 16:20:38 +0300
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <54915954.6090804@oracle.com>
References: <54915954.6090804@oracle.com>
Message-ID: <54A2A6A6.9060303@oracle.com>

Hi Lev!

When you'll be preparing the final webrev, can you please also include a 
typo fix in it?

s/dstbegin/dstBegin/g

This typo is found in a couple of places in String.java.

Sincerely yours,
Ivan


From scolebourne at joda.org  Tue Dec 30 14:24:46 2014
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 30 Dec 2014 14:24:46 +0000
Subject: JEP 187: Serialization 2.0
In-Reply-To: <52FCA6E1.8030908@redhat.com>
References: <20140114002659.6AC0BD7C2@eggemoggin.niobe.net>
	<52DFCE40.4010108@redhat.com> <52DFDA07.2020307@oracle.com>
	<52DFE05A.40901@redhat.com>
	<9CBDDD37-0DA1-4B9B-BA2F-0391E568227A@oracle.com>
	<52FCA6E1.8030908@redhat.com>
Message-ID: <CACzrW9B+i-Y7DZO5yZj5RKJGug2Y7fwp8M9cmg3KRBSkwUBXrg@mail.gmail.com>

I've checked the bug database [1], JEPs list [2] and Google but this
JEP appears to have disappeared. Can this be confirmed?
Stephen

[1] https://bugs.openjdk.java.net/issues/?jql=issuetype%20%3D%20JEP
[2] http://openjdk.java.net/jeps/0

On 13 February 2014 at 11:05, Florian Weimer <fweimer at redhat.com> wrote:
> On 01/23/2014 03:30 PM, Chris Hegarty wrote:
>>
>> On 22 Jan 2014, at 15:14, Florian Weimer <fweimer at redhat.com> wrote:
>>
>>> On 01/22/2014 03:47 PM, Chris Hegarty wrote:
>>>>
>>>> On 22/01/14 13:57, Florian Weimer wrote:
>>>>>
>>>>> On 01/14/2014 01:26 AM, mark.reinhold at oracle.com wrote:
>>>>>>
>>>>>> Posted: http://openjdk.java.net/jeps/187
>>>>>
>>>>>
>>>>> There's another aspect of the current approach to serialization that is
>>>>> not mentioned: the type information does not come from the calling
>>>>> context, but exclusively from the input stream.
>>>>
>>>>
>>>> Have you overlooked resolveClass [1], or are you looking for additional
>>>> context?
>>>
>>>
>>> I mean something slightly different, so here's a concrete example: Assume
>>> we are deserializing an instance of a class with a String field.  The
>>> current framework deserializes whatever is in the input stream, and will
>>> bail out with a ClassCastException if the deserialized object turns out
>>> unusable.  Contrast this with an alternative approach that uses the
>>> knowledge that the field String and will refuse to read anything else from
>>> the input stream.
>>
>>
>> Sorry, but I may still be missing your point. From my reading of the code,
>> CCE will only be thrown if the object being deserialized contains a field
>> with a type that does not match the type of the similarly named field in the
>> class loaded by the deserializing context.
>
>
> This is from the method
> ObjectStreamClass.FieldReflector::setObjFieldValues(Object, Object[]),
> called indirectly from ObjectInputStream::readObject0(boolean):
>
>                 Object val = vals[offsets[i]];
>                 if (val != null &&
>                     !types[i - numPrimFields].isInstance(val))
>                 {
>                     Field f = fields[i].getField();
>                     throw new ClassCastException(
>                         "cannot assign instance of " +
>                         val.getClass().getName() + " to field " +
>                         f.getDeclaringClass().getName() + "." +
>                         f.getName() + " of type " +
>                         f.getType().getName() + " in instance of " +
>                           obj.getClass().getName());
>                 }
>
> So the exception is thrown after the object val has been read from the
> stream, which involves its construction and deserialization.  This means
> that you always expose the full serialization functionality, no matter with
> which types you start.
>
>> Are you thinking specifically about corrupt/malicious streams, or evolving
>> serializable types? Or a performance optimisation?
>
>
> Mostly the former.  Sorry, I should have said so.
>
> There are serialization frameworks which restrict the types of
> deserializable objects based on the type of the top-level object being
> requested.  Or in Java serialization terms, they won't load and instantiate
> arbitrary classes even if the programmer did not provide a customer,
> restrictive resolveClass() implementation.  I get that type-erased generics
> make it complicated to achieve this in current Java.  (But so is writing a
> correct resolveClass() because it breaks encapsulation.)
>
> Knowing in advance which types to expect in the stream would allow for a
> performance optimization, but something like that could be added to the
> current framework as well.
>
>
> --
> Florian Weimer / Red Hat Product Security Team


From scolebourne at joda.org  Tue Dec 30 14:31:21 2014
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 30 Dec 2014 14:31:21 +0000
Subject: Explicit Serialization API and Security
In-Reply-To: <549F56DA.7040004@zeus.net.au>
References: <549F56DA.7040004@zeus.net.au>
Message-ID: <CACzrW9CdLg5oXHkMP7LnyoV-1CL3UKrCOTM964+-Rxt_cpapBg@mail.gmail.com>

Just to note that there is some overlap between improving
serialization and the meta-model for Java (Beans v2.0) work I'm
looking at [1][2]. The key tool that a meta-model provides is to
enable class authors to select which pieces of their state form the
published properties. In most cases, the properties are the same data
as that needed for effective serialization. The Joda-Beans project [3]
does this and provides XML, JSON and binary serialization via
properties.

thanks
Stephen

[1] https://groups.google.com/forum/#!forum/beans-2-meta-model
[2] https://github.com/jodastephen/property-alliance
[3] http://www.joda.org/joda-beans/



On 28 December 2014 at 01:03, Peter Firmstone
<peter.firmstone at zeus.net.au> wrote:
> Is there any interest in developing an explicit API for Serialization?:
>
>   1. Use a public constructor signature with a single argument,
>      ReadSerialParameters (read only, writable only by the
>      serialization framework) to recreate objects, subclasses (when
>      permitted) call this first from their own constructor, they have
>      an identical constructor signature.  ReadSerialParameters that are
>      null may contain a circular reference and will be available after
>      construction, see #3 below.
>   2. Use a factory method (defined by an interface) with one parameter,
>      WriteSerialParameters (write only, readable only by the
>      serialization framework), this method can be overridden by
>      subclasses (when permitted)
>   3. For circular links, a public method (defined by an interface) that
>      accepts one argument, ReadSerialParameters, this method is called
>      after the constructor completes, subclasses overriding this should
>      call the superclass method.  If this method is not called, an
>      implementation, if known to possibly contain circular links,
>      should check it has been fully initialized in each object method
>      called.
>   4. Retains compatibility with current serialization stream format.
>   5. Each serial field has a name, calling class and object reference,
>      similar to explicitly declaring "private static final
>      ObjectStreamField[] serialPersistentFields ".
>
> Benefits:
>
>   1. An object's internal form is not publicised.
>   2. Each class in an object's heirarchy can use a static method to
>      check invarients and throw an exception, prior to
>      java.lang.Object's constructor being called, preventing
>      construction and avoiding finalizer attacks.
>   3. Final field friendly.
>   4. Compatible with existing serial form.
>   5. Flexible serial form evolution.
>   6. All methods are public and explicitly defined.
>   7. All class ProtectionDomain's exist in the current execution
>      context, allowing an object to throw a SecurityException before
>      construction.
>   8. Less susceptible to deserialization attacks.
>
> Problems:
>
>   1. Implementations cannot be package private or private.  Implicit
>      serialization publicises internal form, any thoughts?
>
> Recommendations:
>
>   1. Create a security check in the serialization framework for
>      implicit serialization, allowing administrators to reduce their
>      deserialization attack surface.
>   2. For improved security, disallow classes implementing explicit
>      serialization from having static state and static initializer
>      blocks, only allow static methods, this would require complier and
>      verifier changes.
>   3. Alternative to #2, allow final static fields, but don't allow
>      static initializer blocks or mutable static fields, similar to
>      interfaces.
>
> Penny for your thoughts?
>
> Regards,
>
> Peter Firmstone.


From lev.priima at oracle.com  Tue Dec 30 16:01:48 2014
From: lev.priima at oracle.com (Lev Priima)
Date: Tue, 30 Dec 2014 19:01:48 +0300
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <54A2A6A6.9060303@oracle.com>
References: <54915954.6090804@oracle.com> <54A2A6A6.9060303@oracle.com>
Message-ID: <54A2CC6B.7080002@oracle.com>

Thanks Ivan,

As I understood dstbegin typo was only in comments. I've changed it to 
camelCase as in code.
I've also applied benchmarked by Claes patch from 
http://cr.openjdk.java.net/~redestad/8067471/webrev.03/

Please review latest changeset: 
http://cr.openjdk.java.net/~lpriima/8067471/webrev.04/

Best Regards,
Lev

On 30.12.2014 16:20, Ivan Gerasimov wrote:
> Hi Lev!
>
> When you'll be preparing the final webrev, can you please also include 
> a typo fix in it?
>
> s/dstbegin/dstBegin/g
>
> This typo is found in a couple of places in String.java.
>
> Sincerely yours,
> Ivan



From brian.burkhalter at oracle.com  Tue Dec 30 16:33:03 2014
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 30 Dec 2014 08:33:03 -0800
Subject: JDK 9 RFR of 4026465: Provide more byte array constructors for
	BigInteger 
In-Reply-To: <CACzrW9CMaKdExmvkMmBEZ86GF-U9qUhKPe2xSLgOvSz6e96U1w@mail.gmail.com>
References: <48844110-12EF-48E2-B536-FF690C319CDE@oracle.com>
	<CACzrW9CMaKdExmvkMmBEZ86GF-U9qUhKPe2xSLgOvSz6e96U1w@mail.gmail.com>
Message-ID: <851F1C62-D645-4ACA-833B-D890E26FBEA0@oracle.com>

I?ve added the suggested @throws tags here:

http://cr.openjdk.java.net/~bpb/4026465/webrev.01/

Thanks,

Brian

On Dec 30, 2014, at 2:33 AM, Stephen Colebourne <scolebourne at joda.org> wrote:

> Just to note that an IndexOutOfBoundsException is mentioned in the
> text (line 274, 350) but there is no matching @throws clause. The
> IndexOutOfBoundsException could have a message added.
> 
> In general, I would expect an offset/length overload for most methods
> that take an array, so this seems like a sensible request.



From brent.christian at oracle.com  Tue Dec 30 19:11:07 2014
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 30 Dec 2014 11:11:07 -0800
Subject: RFR: 8068347: Add java/lang/ClassLoader/deadlock/GetResource.java
	to ProblemList.txt
In-Reply-To: <533639CB-F6DF-4AFA-A321-9196DCDA4FD2@oracle.com>
References: <54A1CB09.2060204@oracle.com>
	<533639CB-F6DF-4AFA-A321-9196DCDA4FD2@oracle.com>
Message-ID: <54A2F8CB.5080208@oracle.com>

Thanks, Chris.

On 12/30/14 12:52 AM, Chris Hegarty wrote:
> I?m ok with this Brent.
>
> -Chris.
>
> On 29 Dec 2014, at 21:43, Brent Christian <brent.christian at oracle.com> wrote:
>
>> Hi,
>>
>> The
>>   java/lang/ClassLoader/deadlock/GetResource.java
>> test has started causing problems for Hotspot nightly testing.  A "real" fix is being worked on under [1], but in the meantime, this test should be added to the ProblemList.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8068347
>>
>> The diff ('jdk' repo) is:
>>
>> --- a/test/ProblemList.txt	Mon Dec 29 09:10:15 2014 -0800
>> +++ b/test/ProblemList.txt	Mon Dec 29 13:32:41 2014 -0800
>> @@ -120,6 +120,10 @@
>>
>> # jdk_lang
>>
>> +# 8029891
>> +java/lang/ClassLoader/deadlock/GetResource.java                 generic-all
>> +
>> +
>> ############################################################################
>>
>> Thanks,
>> -Brent
>>
>> 1. https://bugs.openjdk.java.net/browse/JDK-8029891
>


From tristan.yan at oracle.com  Tue Dec 30 22:28:32 2014
From: tristan.yan at oracle.com (Tristan Yan)
Date: Tue, 30 Dec 2014 14:28:32 -0800
Subject: RFR: JDK-8051563: Convert JAXP function tests in xslt components: :
	org.apache.qetest.dtm package,
	org.apache.qetest.trax package to openjdk
Message-ID: <0B695EBE-5E9C-4B2A-B166-0BFF8644A8A0@oracle.com>

Hi All

Can I get your review on this change.
 
http://cr.openjdk.java.net/~tyan/8051563/webrev.00/ <http://cr.openjdk.java.net/~tyan/8051563/webrev.00/>

These fixes originally come from bug https://bugs.openjdk.java.net/browse/JDK-8051563 <https://bugs.openjdk.java.net/browse/JDK-8051563> as part of our XML test colocation work. ThIS change-set mainly covers tests for package org.apache.qetest.dtm and org.apache.qetest.trax.

In the meantime I took steps at fixing some of our existed test code on below issues:

1. Add a base test class for all functional tests that enable security manager running. A limited minimal permissions set have been set for every test.
2. Remove all unnecessary exception capture for functional tests that we?re using testng to handle all the exceptions.
3. Use try-resource block to solve all possible resource leaks (including InputStream, OutputStream, Writer, Reader). 

Thanks a lot.
Tristan

From lance.andersen at oracle.com  Tue Dec 30 23:07:19 2014
From: lance.andersen at oracle.com (Lance @ Oracle)
Date: Tue, 30 Dec 2014 18:07:19 -0500
Subject: RFR: JDK-8051563: Convert JAXP function tests in xslt components:
	: org.apache.qetest.dtm package,
	org.apache.qetest.trax package to openjdk
In-Reply-To: <0B695EBE-5E9C-4B2A-B166-0BFF8644A8A0@oracle.com>
References: <0B695EBE-5E9C-4B2A-B166-0BFF8644A8A0@oracle.com>
Message-ID: <C65B1371-7B75-4E18-8C89-E3908CD9E22B@oracle.com>

Hi Tristan,

I will look at this but doubt I will get to this tomorrow 


Best,
Lance


Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com
Sent from my iPad

> On Dec 30, 2014, at 5:28 PM, Tristan Yan <tristan.yan at oracle.com> wrote:
> 
> Hi All
> 
> Can I get your review on this change.
> 
> http://cr.openjdk.java.net/~tyan/8051563/webrev.00/ <http://cr.openjdk.java.net/~tyan/8051563/webrev.00/>
> 
> These fixes originally come from bug https://bugs.openjdk.java.net/browse/JDK-8051563 <https://bugs.openjdk.java.net/browse/JDK-8051563> as part of our XML test colocation work. ThIS change-set mainly covers tests for package org.apache.qetest.dtm and org.apache.qetest.trax.
> 
> In the meantime I took steps at fixing some of our existed test code on below issues:
> 
> 1. Add a base test class for all functional tests that enable security manager running. A limited minimal permissions set have been set for every test.
> 2. Remove all unnecessary exception capture for functional tests that we?re using testng to handle all the exceptions.
> 3. Use try-resource block to solve all possible resource leaks (including InputStream, OutputStream, Writer, Reader). 
> 
> Thanks a lot.
> Tristan


From richard.warburton at gmail.com  Tue Dec 30 23:25:41 2014
From: richard.warburton at gmail.com (Richard Warburton)
Date: Tue, 30 Dec 2014 23:25:41 +0000
Subject: Lower overhead String encoding/decoding
In-Reply-To: <CAMaYbvL1j+-6M_ZrAPjcTZo7FSYb6a+eOA_OFmT5_6J6PNCQtg@mail.gmail.com>
References: <CAMaYbvKQhUiQef06Av36m4U1DTWaDBoOyUe9SajnHJr0jHU=NA@mail.gmail.com>
	<54200F07.4070604@oracle.com>
	<CAMaYbv+Jc_98x7P2gGVEHJLsQq8kiSOx5EmmMjucwMhgKfNV7Q@mail.gmail.com>
	<542441BB.600@oracle.com>
	<CAMaYbvLhyVo7y_d7CFA6Vmg5vxUzCRyaKN2sNm2VRax=pd_1EA@mail.gmail.com>
	<5444BB17.8080708@oracle.com>
	<CAMaYbvJ63xVobqsywsafi+_dRzCVXtYDX9SCO5FAYbAGD_xz6Q@mail.gmail.com>
	<544FADA5.7000403@oracle.com> <544FB0F7.8080909@univ-mlv.fr>
	<CAMaYbvKcoX1renaBynPkdSRXCV9UT0CpE_opu6bbQyOoPOnaQQ@mail.gmail.com>
	<CAMaYbvKbAsFH3x6bHfngXzgLbj-y9sHgJiYy7h3i2NDAUcM-Kw@mail.gmail.com>
	<54737BC3.9010508@oracle.com> <5473A167.5040703@oracle.com>
	<CAMaYbvL1j+-6M_ZrAPjcTZo7FSYb6a+eOA_OFmT5_6J6PNCQtg@mail.gmail.com>
Message-ID: <CAMaYbvLiJr32LsGMNG+CcTMQsu6N2sE1e5O5C_XnowQOfV5iuQ@mail.gmail.com>

Hi,

Thanks for looking at this patch and agreeing to sponsor - I've pushed
> fixes for these issues at:
>
> http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-10/
>

Hope everyone has had a happy holiday period. Just following up on this
issue to make sure that you have all the information needed and I've not
been blocking the RFE process. Got a bit concerned due to radio silence.

regards,

  Richard Warburton

  http://insightfullogic.com
  @RichardWarburto <http://twitter.com/richardwarburto>


From joe.darcy at oracle.com  Wed Dec 31 02:15:50 2014
From: joe.darcy at oracle.com (joe darcy)
Date: Tue, 30 Dec 2014 18:15:50 -0800
Subject: JDK 9 RFR of 4026465: Provide more byte array constructors for
	BigInteger
In-Reply-To: <851F1C62-D645-4ACA-833B-D890E26FBEA0@oracle.com>
References: <48844110-12EF-48E2-B536-FF690C319CDE@oracle.com>	<CACzrW9CMaKdExmvkMmBEZ86GF-U9qUhKPe2xSLgOvSz6e96U1w@mail.gmail.com>
	<851F1C62-D645-4ACA-833B-D890E26FBEA0@oracle.com>
Message-ID: <54A35C56.3040908@oracle.com>

Hi Brian,

The new changes generally look good. A few comments, for the new code like

  291         } else if ((off < 0) || (off > val.length) || (len < 0) ||
  292                    ((off + len) > val.length) || ((off + len) < 0)) {
  293             throw new IndexOutOfBoundsException();

it is not immediately clear that the arithmetic on line 292 won't have 
some inappropriate overflow behavior. A comment stating why "off + len" 
will behave appropriately (assuming it does behave appropriately ;-) 
would help. (By line 292, both off and len are non-negative so that 
should limit the case analysis.)

It might be worthwhile for all the BigInteger constructors which take 
array arguments to state something about the thread-safely behavior 
("arrays are assumed to be unchanged for the duration of the constructor 
call...").

Do have have any code coverage information for the new code by the 
regression test? It would be good to know whether or not all the guard 
conditions are properly being executed.

Thanks,

-Joe


On 12/30/2014 8:33 AM, Brian Burkhalter wrote:
> I?ve added the suggested @throws tags here:
>
> http://cr.openjdk.java.net/~bpb/4026465/webrev.01/
>
> Thanks,
>
> Brian
>
> On Dec 30, 2014, at 2:33 AM, Stephen Colebourne <scolebourne at joda.org> wrote:
>
>> Just to note that an IndexOutOfBoundsException is mentioned in the
>> text (line 274, 350) but there is no matching @throws clause. The
>> IndexOutOfBoundsException could have a message added.
>>
>> In general, I would expect an offset/length overload for most methods
>> that take an array, so this seems like a sensible request.



From pbenedict at apache.org  Wed Dec 31 02:42:41 2014
From: pbenedict at apache.org (Paul Benedict)
Date: Tue, 30 Dec 2014 20:42:41 -0600
Subject: JDK 9 RFR of 4026465: Provide more byte array constructors for
	BigInteger
In-Reply-To: <54A35C56.3040908@oracle.com>
References: <48844110-12EF-48E2-B536-FF690C319CDE@oracle.com>
	<CACzrW9CMaKdExmvkMmBEZ86GF-U9qUhKPe2xSLgOvSz6e96U1w@mail.gmail.com>
	<851F1C62-D645-4ACA-833B-D890E26FBEA0@oracle.com>
	<54A35C56.3040908@oracle.com>
Message-ID: <CABLGb9y0JzLU=6MSRnXqEmobcdHajxb_GuVQ8pfg41GmGbNOgQ@mail.gmail.com>

Please add @since 1.9 to the new constructors.


Cheers,
Paul

On Tue, Dec 30, 2014 at 8:15 PM, joe darcy <joe.darcy at oracle.com> wrote:

> Hi Brian,
>
> The new changes generally look good. A few comments, for the new code like
>
>  291         } else if ((off < 0) || (off > val.length) || (len < 0) ||
>  292                    ((off + len) > val.length) || ((off + len) < 0)) {
>  293             throw new IndexOutOfBoundsException();
>
> it is not immediately clear that the arithmetic on line 292 won't have
> some inappropriate overflow behavior. A comment stating why "off + len"
> will behave appropriately (assuming it does behave appropriately ;-) would
> help. (By line 292, both off and len are non-negative so that should limit
> the case analysis.)
>
> It might be worthwhile for all the BigInteger constructors which take
> array arguments to state something about the thread-safely behavior
> ("arrays are assumed to be unchanged for the duration of the constructor
> call...").
>
> Do have have any code coverage information for the new code by the
> regression test? It would be good to know whether or not all the guard
> conditions are properly being executed.
>
> Thanks,
>
> -Joe
>
>
> On 12/30/2014 8:33 AM, Brian Burkhalter wrote:
>
>> I?ve added the suggested @throws tags here:
>>
>> http://cr.openjdk.java.net/~bpb/4026465/webrev.01/
>>
>> Thanks,
>>
>> Brian
>>
>> On Dec 30, 2014, at 2:33 AM, Stephen Colebourne <scolebourne at joda.org>
>> wrote:
>>
>>  Just to note that an IndexOutOfBoundsException is mentioned in the
>>> text (line 274, 350) but there is no matching @throws clause. The
>>> IndexOutOfBoundsException could have a message added.
>>>
>>> In general, I would expect an offset/length overload for most methods
>>> that take an array, so this seems like a sensible request.
>>>
>>
>


From ivan.st.ivanov at gmail.com  Wed Dec 31 10:51:36 2014
From: ivan.st.ivanov at gmail.com (Ivan St. Ivanov)
Date: Wed, 31 Dec 2014 12:51:36 +0200
Subject: RFR: 5050783: Throwable convenience method: String
	getStackTraceString()
Message-ID: <CACYLA9Fnm6YEMh6+awNRcFsf9AFrNMkZbN4=K6tkyD3Es4gL8w@mail.gmail.com>

Hello,

I am Ivan from the Bulgarian Java User Group. As part of our Adopt OpenJDK
efforts, we organized hackathon beginning of this month in Sofia. There we
worked on the following JIRA issue:

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

Unfortunately none of us has author privileges, so the issue is still
unassigned. But, nevertheless, our JUG has already signed JSPA and some of
our members (including myself) have signed OCA. And we informed in a
special email this mailing list about our plans prior to the meeting.

Our hackathon was already documented by our JUG member Mihail Stoynov:

http://mihail.stoynov.com/2014/12/12/building-openjdk-and-submitting-a-solution-on-a-feature-request-with-the-bulgarian-java-user-group/

We used the days after the meeting for offline polishing our contribution
and adding some more unit tests. Here is the result of our work:

http://dmitryalexandrov.net/~bgjug/5050783/webrev.00/

We would be very happy if you are able to review it, share your feedback
and guide us through the contribution process as this is our first attempt.

Thanks and have a very successful year!
Ivan


From lev.priima at oracle.com  Wed Dec 31 13:26:29 2014
From: lev.priima at oracle.com (Lev Priima)
Date: Wed, 31 Dec 2014 16:26:29 +0300
Subject: RFR(S): 8067471: Use private static final char[0] for empty
	Strings
In-Reply-To: <54A2D14C.5020303@oracle.com>
References: <54915954.6090804@oracle.com> <54A2A6A6.9060303@oracle.com>
	<54A2CC6B.7080002@oracle.com> <54A2D14C.5020303@oracle.com>
Message-ID: <54A3F985.1080405@oracle.com>

Thanks Ivan!

I've updated: http://cr.openjdk.java.net/~lpriima/8067471/webrev.05/.

Best Regards,
Lev



From claes.redestad at oracle.com  Wed Dec 31 13:32:27 2014
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 31 Dec 2014 14:32:27 +0100
Subject: RFR: 5050783: Throwable convenience method: String
	getStackTraceString()
In-Reply-To: <CACYLA9Fnm6YEMh6+awNRcFsf9AFrNMkZbN4=K6tkyD3Es4gL8w@mail.gmail.com>
References: <CACYLA9Fnm6YEMh6+awNRcFsf9AFrNMkZbN4=K6tkyD3Es4gL8w@mail.gmail.com>
Message-ID: <54A3FAEB.7010709@oracle.com>

Hi,

seems like a reasonable convenience method. :-)

Process stuff: OCA/JSPA signing aside, the patch needs to be submitted 
in its
entirety to some part of the OpenJDK infrastructure before it can be 
accepted.
Attaching the patch in an e-mail to this mailing list is acceptable for 
a small
patch like this when lacking upload privileges to cr.openjdk.java.net. A 
sponsor
could help you with the uploading etc.

This request adds a new public method, which means some internal approval
will be necessary. This is something you'll need help with from an Oracle
sponsor. I could volunteer to initiate the requests internally.

Code feedback:

The test relies on the message generated when provoking a division by
zero. I'm not sure this is a good idea nor the place to enforce this
message format with a test. Perhaps just throwing a RuntimeException
with some specified message and test for that?

May I suggest to also add a test to ensure the method behaves well for an
exception with fillInStackTrace overridden to produce stackless exceptions?

Just a thought... I noticed PrintWriter, PrintStream and StringBuilder all
inherit from Appendable, so the PrintStreamOrWriter/StackTracePrinter 
classes
could be replaced with a single StackTraceAppendable taking an 
Appendable. One
static class instead of 1 abstract and 3 concrete static inner classes 
could work
out to be a good deal, but there's some odd mechanics in 
BufferedWriter/PrintWriter
to use the value of the line.separator property at object creation time 
which
would be hard to support without exposing the lineSeparator fields to 
Throwable.
Perhaps a future consideration.

Performance characteristics might change ever so slightly either way, so it
would be nice with some microbenchmarks to quantify.

/Claes

On 2014-12-31 11:51, Ivan St. Ivanov wrote:
> Hello,
>
> I am Ivan from the Bulgarian Java User Group. As part of our Adopt OpenJDK
> efforts, we organized hackathon beginning of this month in Sofia. There we
> worked on the following JIRA issue:
>
> https://bugs.openjdk.java.net/browse/JDK-5050783
>
> Unfortunately none of us has author privileges, so the issue is still
> unassigned. But, nevertheless, our JUG has already signed JSPA and some of
> our members (including myself) have signed OCA. And we informed in a
> special email this mailing list about our plans prior to the meeting.
>
> Our hackathon was already documented by our JUG member Mihail Stoynov:
>
> http://mihail.stoynov.com/2014/12/12/building-openjdk-and-submitting-a-solution-on-a-feature-request-with-the-bulgarian-java-user-group/
>
> We used the days after the meeting for offline polishing our contribution
> and adding some more unit tests. Here is the result of our work:
>
> http://dmitryalexandrov.net/~bgjug/5050783/webrev.00/
>
> We would be very happy if you are able to review it, share your feedback
> and guide us through the contribution process as this is our first attempt.
>
> Thanks and have a very successful year!
> Ivan



From xueming.shen at oracle.com  Wed Dec 31 20:13:18 2014
From: xueming.shen at oracle.com (Xueming Shen)
Date: Wed, 31 Dec 2014 12:13:18 -0800
Subject: Lower overhead String encoding/decoding
In-Reply-To: <CAMaYbvLiJr32LsGMNG+CcTMQsu6N2sE1e5O5C_XnowQOfV5iuQ@mail.gmail.com>
References: <CAMaYbvKQhUiQef06Av36m4U1DTWaDBoOyUe9SajnHJr0jHU=NA@mail.gmail.com>	<54200F07.4070604@oracle.com>	<CAMaYbv+Jc_98x7P2gGVEHJLsQq8kiSOx5EmmMjucwMhgKfNV7Q@mail.gmail.com>	<542441BB.600@oracle.com>	<CAMaYbvLhyVo7y_d7CFA6Vmg5vxUzCRyaKN2sNm2VRax=pd_1EA@mail.gmail.com>	<5444BB17.8080708@oracle.com>	<CAMaYbvJ63xVobqsywsafi+_dRzCVXtYDX9SCO5FAYbAGD_xz6Q@mail.gmail.com>	<544FADA5.7000403@oracle.com>	<544FB0F7.8080909@univ-mlv.fr>	<CAMaYbvKcoX1renaBynPkdSRXCV9UT0CpE_opu6bbQyOoPOnaQQ@mail.gmail.com>	<CAMaYbvKbAsFH3x6bHfngXzgLbj-y9sHgJiYy7h3i2NDAUcM-Kw@mail.gmail.com>	<54737BC3.9010508@oracle.com>	<5473A167.5040703@oracle.com>	<CAMaYbvL1j+-6M_ZrAPjcTZo7FSYb6a+eOA_OFmT5_6J6PNCQtg@mail.gmail.com>
	<CAMaYbvLiJr32LsGMNG+CcTMQsu6N2sE1e5O5C_XnowQOfV5iuQ@mail.gmail.com>
Message-ID: <54A458DE.1010204@oracle.com>

On 12/30/14 3:25 PM, Richard Warburton wrote:
> Hi,
>
>     Thanks for looking at this patch and agreeing to sponsor - I've
>     pushed fixes for these issues at:
>
>     http://cr.openjdk.java.net/~rwarburton/string-patch-webrev-10/
>     <http://cr.openjdk.java.net/%7Erwarburton/string-patch-webrev-10/>
>
>
> Hope everyone has had a happy holiday period. Just following up on 
> this issue to make sure that you have all the information needed and 
> I've not been blocking the RFE process. Got a bit concerned due to 
> radio silence.
>
> regards,
>
>   Richard Warburton
>
> http://insightfullogic.com
> @RichardWarburto <http://twitter.com/richardwarburto>
Hi Richard,

My apology for the delay, things are little slow during this period of 
the year:-)
I will sponsor the rfe and prepare for the CCC (internally). We may need 
go through
the api and the implementation one more time.

Regards,
-Sherman


From amit.baxi at agnity.com  Mon Dec 29 14:51:55 2014
From: amit.baxi at agnity.com (Amit Baxi)
Date: Mon, 29 Dec 2014 23:51:55 +0900
Subject: RFR: 5049299 - (process) Use,posix_spawn, not fork, on S10 to avoid
	swap,exhaustion (jdk7u-dev)
Message-ID: <54A16A8B.3090407@agnity.com>

Hi Folks,

We are facing issue with process builder on JRockit JVM with solaris 
5.10 machine. That is realted to following bug:

            http://bugs.java.com/view_bug.do?bug_id=5049299



Currently we are using JRockit JDK 1.6.0_37-R28.2.5-4.1.0 version. 
Please let me know  following :

  * Which version of JRockit this bug is fixed ? (as it is fixed in JAVA
    8u 15)
  * If yes then  is it also fixed for solaris 5.10 or In solaris process
    builder still uses fork() call ?


As per this page link below Mr. Rob wrote that for solaris it still 
using fork which is confusing weather fixed for solaris or not:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-November/022909.html

Please confirm for this fix and thanks in advance.

Waiting for your response,

Thanks!
*Amit Baxi



*