Re: Long.bitCount micro-optimization

[Martin Buchholz]

Being able to do better here is very impressive.

I took a quick look and found two things that a paranoid benchmarker like
myself would not have done:
- write the benchmark in scala instead of boring java
- use jdk8 instead of "head" (i.e. jdk10)

I would also have benchmarked against the intrinsified version to see how
it did.

On Mon, May 8, 2017 at 5:42 PM, Isaac Levy  wrote:

> jmh:run -t1 -f 1 -wi 5 -i 10 BitCountTest
>
> bitCountInt  avgt   10  44550.630 ± 2670.294  ns/op
> bitCountIntNew   avgt   10  33904.058 ± 1108.438  ns/op
>
> bitCountLong avgt   10  58638.138 ± 3736.014  ns/op
> bitCountLongNew  avgt   10  38700.601 ±  526.648  ns/op
>
> JDK 1.8.0_131, 2.3ghz Core i7, each run counting numbers 0 to 2^14
>
> https://gist.github.com/isaacl/338a3f88e7d18a0c64bf9aed6e4a816b
>
> Isaac
>
>
> On Mon, May 8, 2017 at 8:11 PM, Brian Burkhalter
>  wrote:
> >
> > On May 8, 2017, at 5:07 PM, Joseph D. Darcy 
> wrote:
> >
> >> This is a case of "jmh results or it isn't faster." [1]
> >>
> >> It is challenging to evaluate such changes as being universally faster
> without benchmark results, especially for small methods like this. Without
> compelling performance support, my preference would be to leave the current
> Java implementation as-is, especially when there are VM intrinsics on many
> platforms.
> >
> > I concur.
> >
> > Brian
>

JDK 9 RFR of 8179662: OutputStreamWriter javadocs states that you can set the buffer size but there is no way to do that

[Brian Burkhalter]

Please review this doc-only change [2] for [1] at your convenience with 
reference to [3].

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8179662
[2] diff

--- a/src/java.base/share/classes/java/io/OutputStreamWriter.java
+++ b/src/java.base/share/classes/java/io/OutputStreamWriter.java
@@ -40,10 +40,8 @@
  *
  *  Each invocation of a write() method causes the encoding converter to be
  * invoked on the given character(s).  The resulting bytes are accumulated in a
- * buffer before being written to the underlying output stream.  The size of
- * this buffer may be specified, but by default it is large enough for most
- * purposes.  Note that the characters passed to the write() methods are not
- * buffered.
+ * buffer before being written to the underlying output stream.  Note that the
+ * characters passed to the write() methods are not buffered.
  *
  *  For top efficiency, consider wrapping an OutputStreamWriter within a
  * BufferedWriter so as to avoid frequent converter invocations.  For example:

[3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047526.html

Re: JDK 9 RFR of JDK-8085814: Move stream test library to the jdk test library area

[Amy Lu]

On 5/9/17 4:56 AM, David Holmes wrote:
If the bootlib files were simply moved then no update to their 
copyright year is needed.


Cheers,
David 


Got it. Thank you David!

Thanks,
Amy

Re: JDK 9 RFR of JDK-8085814: Move stream test library to the jdk test library area

[Amy Lu]

On 5/9/17 1:33 AM, Paul Sandoz wrote:

The changes look good.

Would you mind re-basing this fix for JDK 10 instead? At this point we should 
be more conservative with such changes (even for tests).

Sure, I'll re-base and push this to JDK 10.

Thank you for reviewing.

Thanks,
Amy

Re: RFC on 8179662: OutputStreamWriter javadocs states that you can set the buffer size but there is no way to do that

[Brian Burkhalter]

I agree. I would opt for (A) and be done with it.

On May 8, 2017, at 6:38 PM, Brian Goetz  wrote:

> Given that this went unnoticed for 18 years, the urgency seems low.  Either 
> (a) or (b) sound fine to me.  (c) sounds like a recipe for spending more time 
> talking about the bug than actually fixing it.  
> 
> 
> 
>> On May 8, 2017, at 5:24 PM, Brian Burkhalter  
>> wrote:
>> 
>> This issue [1] does in fact appear to be a bug. It could be fixed in one of 
>> three ways:
>> 
>> A) Remove the fallacious sentence "The size of this buffer may be specified, 
>> but by default it is large enough for most purposes.” from the second 
>> paragraph of the class documentation. This would at least make the 
>> specification consistent with the behavior without removing any 
>> functionality and could be done for JDK 9.
>> 
>> B) Add constructors (and the supporting methods in sun.nio.cs.CtreamEncoder) 
>> which would permit specifying the buffer size. This would make the behavior 
>> consistent with the specification but would have to be targeted to JDK 10.
>> 
>> C) Do option A for JDK 9 and (possibly) file an enhancement issue for option 
>> B for JDK 10.
>> 
>> Any opinions as to which option would be preferable?
>> 
>> Another possibility would be to have some kind of “setBufferSize()” 
>> capability which I think would add less API but ultimately more code.
>> 
>> Thanks,
>> 
>> Brian
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8179662
> 

Re: RFC on 8179662: OutputStreamWriter javadocs states that you can set the buffer size but there is no way to do that

[Brian Goetz]

Given that this went unnoticed for 18 years, the urgency seems low.  Either (a) 
or (b) sound fine to me.  (c) sounds like a recipe for spending more time 
talking about the bug than actually fixing it.  



> On May 8, 2017, at 5:24 PM, Brian Burkhalter  
> wrote:
> 
> This issue [1] does in fact appear to be a bug. It could be fixed in one of 
> three ways:
> 
> A) Remove the fallacious sentence "The size of this buffer may be specified, 
> but by default it is large enough for most purposes.” from the second 
> paragraph of the class documentation. This would at least make the 
> specification consistent with the behavior without removing any functionality 
> and could be done for JDK 9.
> 
> B) Add constructors (and the supporting methods in sun.nio.cs.CtreamEncoder) 
> which would permit specifying the buffer size. This would make the behavior 
> consistent with the specification but would have to be targeted to JDK 10.
> 
> C) Do option A for JDK 9 and (possibly) file an enhancement issue for option 
> B for JDK 10.
> 
> Any opinions as to which option would be preferable?
> 
> Another possibility would be to have some kind of “setBufferSize()” 
> capability which I think would add less API but ultimately more code.
> 
> Thanks,
> 
> Brian
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8179662

Re: Long.bitCount micro-optimization

[Brian Burkhalter]

Thanks for running the numbers.

On May 8, 2017, at 5:42 PM, Isaac Levy  wrote:

> bitCountInt  avgt   10  44550.630 ± 2670.294  ns/op

[41880, 47221]

> bitCountIntNew   avgt   10  33904.058 ± 1108.438  ns/op

[32796, 35012]

> bitCountLong avgt   10  58638.138 ± 3736.014  ns/op

[54902, 62374]

> bitCountLongNew  avgt   10  38700.601 ±  526.648  ns/op

[38174, 39227]

So the ranges don’t overlap which is important.

> JDK 1.8.0_131, 2.3ghz Core i7, each run counting numbers 0 to 2^14


Thing is one needs to run the benchmark on a variety of hardware. I went 
through a lot of this sort of thing myself when evaluating among other things 
for example the crossover thresholds for the Karatsuba and Toom-Cook 
multiplication algorithms in BigInteger multiplication. There was a lot of 
variation.

Thanks,

Brian

Re: Accessing module internals from bytecode rewriting agent

[Martin Buchholz]

Another way to think about transition to a new JDK is to treat the new
release JDK N as a "better JDK N-1".  You still target JDK N-1 at build
time but get performance and quality improvements from the JDK N runtime,
running along with JDK N-1 for years.  Then every small incompatibility is
a big nuisance.  It's an interesting thought experiment whether using two
releases to get to strong encapsulation might have been an easier
transition for users (but of course too late now and would have made jigsaw
implementers' lives tougher).

Re: Accessing module internals from bytecode rewriting agent

[Martin Buchholz]

On Tue, May 2, 2017 at 2:40 AM, Andrew Dinn  wrote:

>
> Just wanted to post a heads-up that this fall-back behaviour has now
> been implemented in Byteman release 4.0.0-BETA5.


Thanks - I can confirm 4.0.0-BETA5 works for me.

Re: Long.bitCount micro-optimization

[Isaac Levy]

jmh:run -t1 -f 1 -wi 5 -i 10 BitCountTest

bitCountInt  avgt   10  44550.630 ± 2670.294  ns/op
bitCountIntNew   avgt   10  33904.058 ± 1108.438  ns/op

bitCountLong avgt   10  58638.138 ± 3736.014  ns/op
bitCountLongNew  avgt   10  38700.601 ±  526.648  ns/op

JDK 1.8.0_131, 2.3ghz Core i7, each run counting numbers 0 to 2^14

https://gist.github.com/isaacl/338a3f88e7d18a0c64bf9aed6e4a816b

Isaac


On Mon, May 8, 2017 at 8:11 PM, Brian Burkhalter
 wrote:
>
> On May 8, 2017, at 5:07 PM, Joseph D. Darcy  wrote:
>
>> This is a case of "jmh results or it isn't faster." [1]
>>
>> It is challenging to evaluate such changes as being universally faster 
>> without benchmark results, especially for small methods like this. Without 
>> compelling performance support, my preference would be to leave the current 
>> Java implementation as-is, especially when there are VM intrinsics on many 
>> platforms.
>
> I concur.
>
> Brian

Re: Add support for Unicode versions of JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs on Windows platforms

[John Platts]

Reasons to add UTF-16 versions of the JNI_CreateJavaVM and 
JNI_GetDefaultJavaVMInitArgs APIs include the following:

* The arguments passed into the wmain and wWinMain functions use UTF-16-encoded 
strings instead of UTF-8 strings.
* The arguments passed into the main and WinMain functions on Windows-platforms 
are in the ANSI character encoding instead of the UTF-8 character encoding.
* The arguments passed into the wmain and wWinMain functions would need to be 
converted to UTF-8 or modified UTF-8 encoding unless a UTF-16 version of 
JNI_CreateJavaVM is added.
* The NewString and GetStringChars APIs in the JNI already use UTF-16-encoded 
strings.
* Unicode APIs on Windows normally use UTF-16-encoded strings.
* The C11 and C++11 standards support UTF-16 strings through the char16_t type 
and support for UTF-16 literals with a u prefix.
* Windows platforms have long supported UTF-16 strings in C and C++ through the 
wchar_t type and support for UTF-16 literals with a L prefix.
* A UTF-16 version of JNI_CreateJavaVM would allow command line arguments to be 
passed into the JVM without having to perform the platform-dependent encoding 
to UTF-16 conversion that currently has to be done in the JVM.
* A UTF-16 version of JNI_CreateJavaVM would improve consistency across 
different locales on Windows-based platforms since the command-line arguments 
can be passed into the JVM in a locale-independent manner on Windows-based 
platforms.

From: David Holmes 
Sent: Sunday, May 7, 2017 7:47 PM
To: John Platts
Cc: hotspot-dev developers; core-libs-dev Libs
Subject: Re: Add support for Unicode versions of JNI_CreateJavaVM and 
JNI_GetDefaultJavaVMInitArgs on Windows platforms

Added back jdk10-dev as a bcc.

Added hotspot-dev and core-libs-dev (for launcher) for follow up
discussions.

Hi John,

On 8/05/2017 10:33 AM, John Platts wrote:
> I actually did a search through the code that implements
> JNI_CreateJavaVM, and I found that the conversion of the strings is done
> using java_lang_String::create_from_platform_dependent_str, which
> converts from the platform-default encoding to Unicode. In the case of
> Windows-based platforms, the conversion is done based on the ANSI
> character encoding instead of UTF-8 or Modified UTF-8.
>
>
> The platform encoding detection logic on Windows is implemented
> java_props_md.c, which can be found at
> jdk/src/windows/native/java/lang/java_props_md.c in releases prior to
> JDK 9 and at src/java.base/windows/native/libjava/java_props_md.c in JDK
> 9 and later. The encoding used for command-line arguments passed into
> the JNI invocation API is Cp1252 for English locales on Windows
> platforms, and not Modified UTF-8 or UTF-8.
>
>
> The documentation found
> at 
> http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html
>  also
The Invocation API - 
Oracle
docs.oracle.com
The Invocation API allows software vendors to load the Java VM into an 
arbitrary native application. Vendors can deliver Java-enabled applications 
without having to ...



> states that the strings passed into JNI_CreateJavaVM are in the
> platform-default encoding.

Thanks for the additional details. I assume you are referring to:

typedef struct JavaVMOption {
 char *optionString;  /* the option as a string in the default
platform encoding */

that comment should not form part of the specification as it is
non-normative text. If the intent is truly to use the platform default
encoding and not UTF-8 then that should be very clearly spelt out in the
spec!

That said, the implementation is following this so it is a limitation. I
suspect this is historical.

> A version of JNI_CreateJavaVM that takes UTF-16-encoded strings should
> be added to the JNI Invocation API. The java.exe launchers and javaw.exe
> launchers should also be updated to use the UTF-16 version of the
> JNI_CreateJavaVM function on Windows platforms and to use wmain and
> wWinMain instead of main and WinMain.

Why versions for UTF-16 instead of the missing UTF-8 variants? As I said
the whole spec is intended to be based around UTF-8 so we would not want
to throw in just a couple of UTF-16 based usages.

Thanks,
David

>
> A few files in HotSpot would need to be changed in order to implement
> the UTF-16 version of JNI_CreateJavaVM, but the change would improve
> consistency across different locales on Windows platforms and allow
> arguments that contain Unicode characters that are not available in the
> platform-default encoding to be passed into the JVM on the command line.
>
>
> The UTF-16-based version of JNI_CreateJavaVM also makes it easier to
> allocate string objects that contain non-ASCII characters as the strings
> are already in UTF-16 format, at least in cases where the strings
> contain Unicode characters that are not in Latin-1 or on VMs that do not
> support compact 

Re: Long.bitCount micro-optimization

[Brian Burkhalter]

On May 8, 2017, at 5:07 PM, Joseph D. Darcy  wrote:

> This is a case of "jmh results or it isn't faster." [1]
> 
> It is challenging to evaluate such changes as being universally faster 
> without benchmark results, especially for small methods like this. Without 
> compelling performance support, my preference would be to leave the current 
> Java implementation as-is, especially when there are VM intrinsics on many 
> platforms.

I concur.

Brian

Re: Long.bitCount micro-optimization

[Isaac Levy]

AMD started shipping popcnt instruction in 2007, and intel in 2008.
Does the OpenJDK runtime include a bitCount intrinsic? I can't speak
much to relevance in this regard.


But in terms of performance,
http://dalkescientific.com/writings/diary/archive/2011/11/02/faster_popcount_update.html
gives a 45% speedup from current jdk algorithm (called "Wikipedia #2")
to the propsed one ("Wikipedia #3").  Benchmark source:
http://dalkescientific.com/writings/diary/popcnt.cpp

The multiply is also the suggested algorithm in the linked PDF (page
195 of http://support.amd.com/techdocs/25112.pdf), an official AMD
optimization guide.



Isaac


On Mon, May 8, 2017 at 4:29 PM, Doug Lea  wrote:
> On 05/08/2017 02:14 PM, Isaac Levy wrote:
>>
>> Original message below:
>>
>> The JDK impl of bitCount can be improved -- though most users will get
>> the hotspot intrinsic. The best source I could find for the suggestion
>> below is page 195: http://support.amd.com/techdocs/25112.pdf
>>
>
> The int version differs from current implementation in that it uses
> one multiply instead of two shift+adds. (Similarly for long.)
>
> I wonder if there is any processor that does not already have a
> bit-count instruction for which this is actually faster?
> Some evidence either way would be helpful.
>
> -Doug
>
>
>
>
>> Cheers,
>> Isaac Levy
>>
>>
>> Proposed Long.bitCount and Integer.bitCount:
>>
>>
>> public static int bitCount(long i)
>> {
>> i -= (i >>> 1) & 0xL;
>> i = (i & 0xL) + ((i >>> 2) & 0xL);
>> i = (i + (i >>> 4)) & 0x0f0f0f0f0f0f0f0fL;
>> return (i * 0x0101010101010101L) >>> 56;
>> }
>>
>>
>> public static int bitCount(int i) {
>> i -= (i >>> 1) & 0x;
>> i = (i & 0x) + ((i >>> 2) & 0x);
>> i = (i + (i >>> 4)) & 0x0f0f0f0f;
>> return (i * 0x01010101) >>> 24;
>> }
>>
>

Re: Long.bitCount micro-optimization

[Joseph D. Darcy]

On 5/8/2017 1:29 PM, Doug Lea wrote:

On 05/08/2017 02:14 PM, Isaac Levy wrote:

Original message below:

The JDK impl of bitCount can be improved -- though most users will get
the hotspot intrinsic. The best source I could find for the suggestion
below is page 195: http://support.amd.com/techdocs/25112.pdf



The int version differs from current implementation in that it uses
one multiply instead of two shift+adds. (Similarly for long.)

I wonder if there is any processor that does not already have a
bit-count instruction for which this is actually faster?
Some evidence either way would be helpful.



This is a case of "jmh results or it isn't faster." [1]

It is challenging to evaluate such changes as being universally faster 
without benchmark results, especially for small methods like this. 
Without compelling performance support, my preference would be to leave 
the current Java implementation as-is, especially when there are VM 
intrinsics on many platforms.


Thanks,

-Joe

[1] http://openjdk.java.net/projects/code-tools/jmh/

Re: Add support for Unicode versions of JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs on Windows platforms

[David Holmes]

Hi John,

Responding back on the mailing lists. There are people on the mailing 
lists who are in a better position to evaluate the merits of the 
proposal. I searched the bug database and could not see this issue being 
raised in the past.


On 9/05/2017 8:46 AM, John Platts wrote:

The real reasons to add UTF-16 versions of these APIs is the following:

* The arguments passed into the wmain and wWinMain functions use
UTF-16-encoded strings instead of UTF-8 strings
* The arguments passed into the main and WinMain functions on
Windows-platforms are in the ANSI character encoding instead of the
UTF-8 character encoding
* The NewString and GetStringChars APIs in the JNI already use
UTF-16-encoded strings


Yes you are right the String functions already support UTF-16 as that is 
the format for char[] and so java.lang.String.



* Unicode APIs on Windows normally use UTF-16-encoded strings
* The C11 and C++11 standards support UTF-16 strings through the
char16_t type and support for UTF-16 character literals with a u prefix


Thanks for the additional input.

David




*From:* David Holmes 
*Sent:* Sunday, May 7, 2017 7:47 PM
*To:* John Platts
*Cc:* hotspot-dev developers; core-libs-dev Libs
*Subject:* Re: Add support for Unicode versions of JNI_CreateJavaVM and
JNI_GetDefaultJavaVMInitArgs on Windows platforms

Added back jdk10-dev as a bcc.

Added hotspot-dev and core-libs-dev (for launcher) for follow up
discussions.

Hi John,

On 8/05/2017 10:33 AM, John Platts wrote:

I actually did a search through the code that implements
JNI_CreateJavaVM, and I found that the conversion of the strings is done
using java_lang_String::create_from_platform_dependent_str, which
converts from the platform-default encoding to Unicode. In the case of
Windows-based platforms, the conversion is done based on the ANSI
character encoding instead of UTF-8 or Modified UTF-8.


The platform encoding detection logic on Windows is implemented
java_props_md.c, which can be found at
jdk/src/windows/native/java/lang/java_props_md.c in releases prior to
JDK 9 and at src/java.base/windows/native/libjava/java_props_md.c in JDK
9 and later. The encoding used for command-line arguments passed into
the JNI invocation API is Cp1252 for English locales on Windows
platforms, and not Modified UTF-8 or UTF-8.


The documentation found
at 
http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html

also
The Invocation API - Oracle

docs.oracle.com
The Invocation API allows software vendors to load the Java VM into an
arbitrary native application. Vendors can deliver Java-enabled
applications without having to ...




states that the strings passed into JNI_CreateJavaVM are in the
platform-default encoding.


Thanks for the additional details. I assume you are referring to:

typedef struct JavaVMOption {
 char *optionString;  /* the option as a string in the default
platform encoding */

that comment should not form part of the specification as it is
non-normative text. If the intent is truly to use the platform default
encoding and not UTF-8 then that should be very clearly spelt out in the
spec!

That said, the implementation is following this so it is a limitation. I
suspect this is historical.


A version of JNI_CreateJavaVM that takes UTF-16-encoded strings should
be added to the JNI Invocation API. The java.exe launchers and javaw.exe
launchers should also be updated to use the UTF-16 version of the
JNI_CreateJavaVM function on Windows platforms and to use wmain and
wWinMain instead of main and WinMain.


Why versions for UTF-16 instead of the missing UTF-8 variants? As I said
the whole spec is intended to be based around UTF-8 so we would not want
to throw in just a couple of UTF-16 based usages.

Thanks,
David



A few files in HotSpot would need to be changed in order to implement
the UTF-16 version of JNI_CreateJavaVM, but the change would improve
consistency across different locales on Windows platforms and allow
arguments that contain Unicode characters that are not available in the
platform-default encoding to be passed into the JVM on the command line.


The UTF-16-based version of JNI_CreateJavaVM also makes it easier to
allocate string objects that contain non-ASCII characters as the strings
are already in UTF-16 format, at least in cases where the strings
contain Unicode characters that are not in Latin-1 or on VMs that do not
support compact Latin-1 strings.


The UTF-16-based version of JNI_CreateJavaVM should probably be
implemented as a separate function so that the solution could be
backported to JDK 8 and JDK 9 updates and so that backwards
compatibility with the current JNI_CreateJavaVM implementation is
maintained.


Here is what the new UTF-16-based API might look like:

typedef struct JavaVMInitArgs_UTF16 {
jint 

Proposal: javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder()

[Andrew Guibert]

Hi all,

I've been cleaning up code that I work on to be Java 9 compatible, but have
ran into a blocker due to limitations of the Naming API.  I could work
around the blocker with an --add-opens, but I'd rather find a proper
solution.

*** Background
Currently the javax.naming.spi.NamingManager allows for setting a JVM-wide
InitialContextFactoryBuilder (ICFB) once and only once by using the static
NamingManager.setInitialContextFactoryBuilder() method [1].  The javadoc
clearly states:
> Once installed, the builder cannot be replaced.
If the set ICFB method is called after a ICFB is set, it will throw an
IllegalStateException.

This seems to be an overly-aggressive restriction of the API.  Currently my
product has code that reflects into the NamingManager class in order to
clear out the ICFB field using reflection.  To be Java 9 compliant, we
would like to remove this usage of deep reflection, but there are no clear
alternatives for doing so.

*** Use case
We have a JNDI server that may be started/stopped by other java code in the
same JVM.  If users stop the JNDI server we clear out the ICFB (using
reflection) when the JNDI server OSGi bundle deactivates, so that if a user
decides to start the JNDI server again in the same JVM, they may do so and
we simply set the ICFB when the JNDI server bundle activates.

*** Proposed Solution:
I could add a layer of indirection by creating an ICFB wrapper that
supports re-setting what ICFB it wraps.  However, this would cause the ICFB
wrapper and all other classes loaded using that bundle's classloader to be
leaked (since it can't be fully deactivated and garbage collected).  To
sort of work around this classloader leak, we would need to load the ICFB
wrapper using its own classloader.  Although the wrapper classloader would
still be leaked, it would have minimal impact because only the one wrapper
class would be leaked.

I am not sure why the "no resetting" restriction is on the NamingManager
API in the first place.  Is anyone aware why the API has this restriction?
In any case, the solution outlined above seems rather messy (as it only
solves the problem by mitigating a classloader leak), so I would like to
propose the following addition to the NamingManager API:

/**
 * Clears the InitialContextFactoryBuilder that was previously installed,
if any, so that a different one may be set at a later time.
 * @throws SecurityException - the builder cannot be cleared for security
reasons.
 * @see SecurityManager.checkSetFactory()
 */
public static void clearInitialContextFactoryBuilder()


Additionally, I think it would make sense to permit clearing the
NamingManager's ObjectFactoryBuilder using a similar mechanism.  Although I
don't have any immediate need or use case for this API, I can imagine
others may need the same.

[1]
http://download.java.net/java/jdk9/docs/api/javax/naming/spi/NamingManager.html#setInitialContextFactoryBuilder-javax.naming.spi.InitialContextFactoryBuilder-

- Andy

RFC on 8179662: OutputStreamWriter javadocs states that you can set the buffer size but there is no way to do that

[Brian Burkhalter]

This issue [1] does in fact appear to be a bug. It could be fixed in one of 
three ways:

A) Remove the fallacious sentence "The size of this buffer may be specified, 
but by default it is large enough for most purposes.” from the second paragraph 
of the class documentation. This would at least make the specification 
consistent with the behavior without removing any functionality and could be 
done for JDK 9.

B) Add constructors (and the supporting methods in sun.nio.cs.CtreamEncoder) 
which would permit specifying the buffer size. This would make the behavior 
consistent with the specification but would have to be targeted to JDK 10.

C) Do option A for JDK 9 and (possibly) file an enhancement issue for option B 
for JDK 10.

Any opinions as to which option would be preferable?

Another possibility would be to have some kind of “setBufferSize()” capability 
which I think would add less API but ultimately more code.

Thanks,

Brian

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

Re: RFR: [Updated] Update tables in java.base to be HTML5-friendly.

[Jonathan Gibbons]

Kumar,

The nature of CSS is such that there is generally no one single definition.

The descriptive comments are just before the shared/common parts of the 
definitions.
If I grouped the comment and class definition, someone else would point 
out that I could be

sharing common properties.

The better long term solution is a separate document, with examples.

-- Jon

On 05/08/2017 03:12 PM, Kumar Srinivasan wrote:


Hi Jon,

I looked at the stylesheet can the descriptive comments for each of the
classes be moved closer to the class itself, ie. just before the 
definition  ?


Kumar

This is an updated review for the changes to improve tables in 
java.base.


The changes incorporate earlier review feedback, and also address a 
problem that was discovered with nested tables.


The summary of the set of changes since the previous round is:

* A new style class is added for borderless tables, to be used in 
preference to a table tag with no class.


* The style classes are now named:
borderless
plain
striped
The longer form using a suffix `-table` was considered, but 
generally, there should not be so many style classes that such a 
level of discrimination is needed. The names `borderless` and 
`striped` are most likely to only apply to tables anyway, and `plain` 
could reasonably be used for other elements without conflict.


* Comments are added to the stylesheet regarding these new classes, 
as a placeholder until a better specification for the styles in these 
stylesheets is created.


* Within java.base, all uses of the `altrows` class have been updated 
to use `striped`, and tables with no class attribute have been 
changed to explicitly use `borderless`.



Webrevs:

langtools (the stylesheet):
http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev.01/

jdk (changes to java.base):
http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev.01/

API showing the combined effect of these cahnges:
http://cr.openjdk.java.net/~jjg/8179479-8179592/api.01/java.base-summary.html 




-- Jon




On 05/03/2017 03:06 PM, Jonathan Gibbons wrote:

This is a review request for two co-dependent fixes.

JDK-8179592: Update tables in java.base to be HTML 5-friendly.
JDK-8179479: Add new styles to enable HTML 5 tables

In doc comments, some of the HTML 4.01 attributes for tables are no 
longer available in HTML 5, and CSS should be used instead.
To this end, some updates have been made to the main/default 
stylesheet used by javadoc, to define two new CSS classes for tables.


The new classes are:

Just puts plain borders around each cell, with no background 
coloring.



Horizontal borders are not used between cells in the table body; 
instead, alternating backgrounds are used to help distinguish the 
separate rows.


In addition, there is still the default

No borders.

These styles are in the langtools webrev, here:
http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev/

The changes to the doc comments in java.base are in the jdk webrev, 
here:

http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev/

summary vs. 

   The ARIA recommendations are to use the summary attribute or 
 tag ... but the summary attribute is no longer allowed in 
HTML 5.  In general, the text that has been provided for a summary 
is not suitable for direct use as a caption. The temporary 
workaround is to use a caption that is not displayed. In time, the 
appropriate API owners should update the use of these undisplayed 
table captions, to modify the text of the caption and make the 
caption displayed (by removing style="display:none").


Doc comments were changed in files in the following packages:

java.io
java.lang
java.lang.invoke
java.lang.reflect
java.math
java.net
java.nio.channels
java.nio.charset
java.nio.file
java.nio.file.attribute
java.nio.file.spi
java.security
java.security.cert
java.text
java.time.chrono
java.time.format
java.time.temporal
java.util
java.util.concurrent
java.util.regex
java.util.spi
javax.net.ssl

The intent is that the only changes in this webrev are to the HTML 5 
markup. There should be no significant changes to the text in any 
doc comment.


The decision to add the styles to the default stylesheet at this 
late stage in the release is not taken lightly, and is seen as a 
temporary measure. JDK-8177283 is a wishlist enhancement for updates 
to javadoc support of stylesheets, which includes the desire to move 
JDK-specific styles to a JDK-specific stylesheet.


This review is primarily about continuing the ongoing effort to make 
our docs be HTML 5 compliant. I would prefer not to get into 
extended discussions about which style class to use for each table, 
and what the exact definition of the styleclasses should be at this 
time.  But appropriate review feedback is obviously welcome.


-- Jon

Re: RFR: [Updated] Update tables in java.base to be HTML5-friendly.

[Kumar Srinivasan]

Hi Jon,

I looked at the stylesheet can the descriptive comments for each of the
classes be moved closer to the class itself, ie. just before the 
definition  ?


Kumar


This is an updated review for the changes to improve tables in java.base.

The changes incorporate earlier review feedback, and also address a 
problem that was discovered with nested tables.


The summary of the set of changes since the previous round is:

* A new style class is added for borderless tables, to be used in 
preference to a table tag with no class.


* The style classes are now named:
borderless
plain
striped
The longer form using a suffix `-table` was considered, but 
generally, there should not be so many style classes that such a level 
of discrimination is needed. The names `borderless` and `striped` are 
most likely to only apply to tables anyway, and `plain` could 
reasonably be used for other elements without conflict.


* Comments are added to the stylesheet regarding these new classes, as 
a placeholder until a better specification for the styles in these 
stylesheets is created.


* Within java.base, all uses of the `altrows` class have been updated 
to use `striped`, and tables with no class attribute have been changed 
to explicitly use `borderless`.



Webrevs:

langtools (the stylesheet):
http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev.01/

jdk (changes to java.base):
http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev.01/

API showing the combined effect of these cahnges:
http://cr.openjdk.java.net/~jjg/8179479-8179592/api.01/java.base-summary.html 




-- Jon




On 05/03/2017 03:06 PM, Jonathan Gibbons wrote:

This is a review request for two co-dependent fixes.

JDK-8179592: Update tables in java.base to be HTML 5-friendly.
JDK-8179479: Add new styles to enable HTML 5 tables

In doc comments, some of the HTML 4.01 attributes for tables are no 
longer available in HTML 5, and CSS should be used instead.
To this end, some updates have been made to the main/default 
stylesheet used by javadoc, to define two new CSS classes for tables.


The new classes are:

Just puts plain borders around each cell, with no background 
coloring.



Horizontal borders are not used between cells in the table body; 
instead, alternating backgrounds are used to help distinguish the 
separate rows.


In addition, there is still the default

No borders.

These styles are in the langtools webrev, here:
http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev/

The changes to the doc comments in java.base are in the jdk webrev, 
here:

http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev/

summary vs. 

   The ARIA recommendations are to use the summary attribute or 
 tag ... but the summary attribute is no longer allowed in 
HTML 5.  In general, the text that has been provided for a summary is 
not suitable for direct use as a caption. The temporary workaround is 
to use a caption that is not displayed. In time, the appropriate API 
owners should update the use of these undisplayed table captions, to 
modify the text of the caption and make the caption displayed (by 
removing style="display:none").


Doc comments were changed in files in the following packages:

java.io
java.lang
java.lang.invoke
java.lang.reflect
java.math
java.net
java.nio.channels
java.nio.charset
java.nio.file
java.nio.file.attribute
java.nio.file.spi
java.security
java.security.cert
java.text
java.time.chrono
java.time.format
java.time.temporal
java.util
java.util.concurrent
java.util.regex
java.util.spi
javax.net.ssl

The intent is that the only changes in this webrev are to the HTML 5 
markup. There should be no significant changes to the text in any doc 
comment.


The decision to add the styles to the default stylesheet at this late 
stage in the release is not taken lightly, and is seen as a temporary 
measure. JDK-8177283 is a wishlist enhancement for updates to javadoc 
support of stylesheets, which includes the desire to move 
JDK-specific styles to a JDK-specific stylesheet.


This review is primarily about continuing the ongoing effort to make 
our docs be HTML 5 compliant. I would prefer not to get into extended 
discussions about which style class to use for each table, and what 
the exact definition of the styleclasses should be at this time.  But 
appropriate review feedback is obviously welcome.


-- Jon

Re: RFR 10 JDK-8159995: Rename internal Unsafe.compare methods

[Paul Sandoz]

> On 7 May 2017, at 22:30, David Holmes  wrote:
> 
> Hi Ron,
> 
> On 6/05/2017 5:27 AM, Ron Pressler wrote:
>> Hi,
>> Please review the following core/hotspot change:
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159995
>> core webrev:
>> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8159995-unsafe-compare-and-swap-to-set-jdk/webrev/
>> 
>> hotspot webrev:
>> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8159995-unsafe-compare-and-swap-to-set-hotspot/webrev/
>> 
>> 
>> This change is covered by existing tests.
>> 
>> The following renaming was applied:
>> 
>> - compareAndExchange*Volatile -> compareAndExchange*
>> - compareAndSwap* -> compareAndSet*
> 
> So to clarify this for others, there was confusion surrounding the use of 
> "swap" versus "exchange" when both words mean the same thing effectively, but 
> the "swap" functions return a boolean, while the "exchange" functions return 
> the old value. So we changed "swap" to "set" across the APIs - _except_ for 
> the old /jdk.unsupported/share/classes/sun/misc/Unsafe.java because we can't 
> change its exported API for compatibility reasons.
> 
> Given any "swap(exp, new)" function can be implemented as "exchange(exp, new) 
> == exp" I'm not sure why we have two complete sets of functions all the way 
> through. But I guess that is a different issue. :)
> 

Yes, it might be possible after some careful performance analysis (we might run 
into some subtle issues).


>> - weakCompareAndSwap* -> weakCompareAndSet*Plain
>> - weakCompareAndSwap*Volatile -> weakCompareAndSet*
>> 
>> At this stage, only method and hotspot intrinsic names were changed;
>> node names were left as-is, and may be handled in a separate issue.
> 
> Overall looks good for libs and hotspot changes.
> 
> One nit I spotted:
> 
> src/java.base/share/classes/java/util/concurrent/atomic/AtomicLong.java
> 
> + * compareAndSwap for longs. While the intrinsic compareAndSetLong
> 
> compareAndSwap should be compareAndSet
> 
> ---
> 
> All hotspot files need their copyright years updated to 2017 (if not already).
> 
> As there are hotspot changes this must be pushed using JPRT and "-testset 
> hotspot" (but your sponsor should know that :) ).
> 

I do :-)

Paul.

Re: RFR: jdk10: 8169646: Remove launcher's -d32/-d64 option

[David Holmes]

Hi Kumar,

On 9/05/2017 12:27 AM, Kumar Srinivasan wrote:


Hi David,


Hi Kumar,

On 7/05/2017 1:21 AM, Kumar Srinivasan wrote:

Hello,

Please review the changes to remove the java launcher's data model
options  -d32/-d64, these options existed to support Solaris dual-mode
operation, however for uniformity, these options were accepted by other
platforms as well.  These options are  now obsolete, and deprecated in
jdk9,and are now being removed.

Webrev: http://cr.openjdk.java.net/~ksrini/8169646/webrev.0
Issue: https://bugs.openjdk.java.net/browse/JDK-8169646


This seems okay in itself, though I'm curious why you made the
launcher/jli responsible for treating -d32/-d64 as invalid options
instead of just passing them through to the VM to let it reject them
as it does any other non-existent option eg:


I mulled over this for sometime, and felt that since the launcher
supported these options before, it should give a better/reasonable
error message than the VM does. I am undecided. What do you think ?


I think all invalid options should be treated the same. We had the 
deprecation phase for providing custom feedback - now we're just 
rejecting them outright.


Cheers,
David



 > java -foo -version
Unrecognized option: -foo
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

I also see some pre-existing messiness you might want to tidy up while
you're in the area :)


OMG Pre-existing conditions. ;)



src/java.base/macosx/native/libjli/java_md_macosx.c

378 JLI_Snprintf(jvmcfg, so_jvmcfg, "%s%slib%s%s%sjvm.cfg",
379  jrepath, FILESEP, FILESEP,  "", "");

The last two %s should just be removed instead of passing empty strings.

 422 } else {
 423 /*
 424  * macosx client library is built thin, i386 only.
 425  * 64 bit client requests must load server library
 426  */
 427 const char *jvmtypeUsed = "server";
 428 JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/%s/" JVM_DLL,
jrepath, jvmtypeUsed);
 429 }

I don't think we have ever had 32-bit client on OSX! So this whole
clause seems strange. That aside you can just hardwire %s/lib/server
instead of using the jvmTypeUsed variable.


+1, I think we did support 32-bit for sometime, in the early days of
MacOSX.




---

src/java.base/unix/native/libjli/java_md_solinux.c

 323 JLI_Snprintf(jvmcfg, so_jvmcfg, "%s%slib%s%sjvm.cfg",
 324 jrepath, FILESEP, FILESEP, FILESEP);

Another strange version of this code - only 4 %s this time, but
adjacent FILESEP. :) I'm assuming this is from when  was removed.

Urk.

Ok I will revisit the above, good catches!, and prepare
another changeset.

Kumar




Thanks,
David


Thanks
Kumar

PS: Thanks to David Holmes and Igor Ignatyev the -d32/-d64 flags have
been
purged from internal test suites.

Re: JDK 9 RFR of JDK-8085814: Move stream test library to the jdk test library area

[David Holmes]

Hi Amy,

Not a review ...

On 8/05/2017 7:00 PM, Amy Lu wrote:

Please review this test-only change to move the test library
jdk/test/java/util/stream/bootlib
to
jdk/test/lib/testlibrary/bootlib
to make it formally easier for tests to depend on.

There is no change to the functionality of the tests.

This patch also removed NullArgsTestCase.java which is an abstract class
designed to be extended reused with a data provider. It provides no test
itself but be wrongly put in the directory of TestNG.dirs thus be run as
a test. In fact it is not even used and can be removed.

bug:
https://bugs.openjdk.java.net/browse/JDK-8085814
https://bugs.openjdk.java.net/browse/JDK-8173414

webrev:
http://cr.openjdk.java.net/~amlu/8085814/webrev.00/
(I did not update the year in the Copyright header for bootlib files, to


If the bootlib files were simply moved then no update to their copyright 
year is needed.


Cheers,
David


make the review easier. I can do bulk update for those files on the
header before push, if that is necessary.)

Thanks,
Amy

Re: RFR: 8176508 Update JAX-WS RI integration to latest version

[Lance Andersen]

Hi Roman,

I made a pass through the webrev and have the following feedback:


src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StaxLazySourceBridge.java
 and several files  - which follow in the webrev, have formatting issues with 
the newly added @override and existing @overrides and should probably be 
cleaned up

src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyElementImpl.java
 - can 960 -962 be deleted

src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/version.properties - 
The copyright was reverted.  Also what happens to the svn info in this file 
with the move to github?

src/java.xml.ws/share/classes/javax/xml/soap/package-info.java -  I would use 
 for TM

src/java.xml.ws/share/classes/javax/xml/ws/Service.java - See comments starting 
at 230 seem off

src/java.xml.ws/share/classes/javax/xml/ws/WebServiceRef.java -  I would make 
the comments starting at 139 be consistent with the other comments 

src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/*.properties - the 
copyright date was reverted

src/jdk.xml.bind/share/classes/module-info.java  should already be updated in 
the workspace

src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/processor/ProcessorException.java
 - The copyright should be updated to 2017

src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/util/WSDLParseException.java
 -  the copyright was reverted

src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ParseException.java
 - the copyright was reverted 

src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ValidationException.java
 - the copyright was reverted

src/jdk.xml.ws/share/classes/module-info.java - this was already updated in the 
workspace

src/java.xml.bind/share/classes/javax/xml/bind/ModuleUtil.java - the copyright 
should only be 2017

src/java.xml.ws/share/classes/com/sun/xml/internal/ws/policy/sourcemodel/attach/ContextClassloaderLocalMessages.java.
 - the copyright should only be 2017

src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/NewmessagesMessages.java
 - the copyright should only be 2017

src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/newmessages.properties
 - this is in the workspace already



> On May 3, 2017, at 12:49 PM, Roman Grigoriadi  
> wrote:
> 
> Hi,
> 
> you can find new web rev here:
> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/01/ 
> 
> 
> Previous review comments are addressed. 
> 
>> The change to version.properties reminds me to ask if there is anything in 
>> the jaxws repo to indicate the version of the JAX-* components? It's often 
>> difficult to determine what bits are in the JDK vs. the upstream project.
> 
> 
> Version as in our Maven project is 2.3.0-SNAPSHOT for JAX-WS at the time we 
> are syncing. Subcomponents (SAAJ, JAXB mainly) are promoted, for example 
> in 
> jdk/jaxws/src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties
> There is:
> # for JDK integration - include version in source zip
> jaxb.jdk.version=2.3.0-b170412.1723
> 
> We can add another version.properties file with versions of all JAX-* 
> components. We may also change version from 2.3.0-SNAPSHOT to something 
> unique like 2.3.0-bXX. before sync and put it to maven promoted repo.
> 
> Roman
> 
> 
>> On 12 Mar 2017, at 16:14, Alan Bateman  wrote:
>> 
>> 
>> 
>> On 12/03/2017 14:39, Roman Grigoriadi wrote:
>>> Hi,
>>> 
>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>> 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176508
>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/
>>> 
>> I skimmed the changes and have a few comments (I'm sure Lance or someone 
>> else will do a more detailed review).
>> 
>> In JAXBContext then "must be open to the java.xml.bind module" should be 
>> "must be open to at least the java.xml.bind module" so as to cover the case 
>> that the package is opened unconditionally or to java.xml.bind and other 
>> modules. In addition, include "at least" makes it consistent with other 
>> wording that we have agreed for other areas.
>> 
>> In MailcapCommandMap then the following doesn't seem right for the class 
>> description:
>> 
>> 59  * (Where java.home is the value of the "java.home" System property
>> 60  * and conf is the directory named "conf" if it exists,
>> 61  * otherwise the directory named "lib"; the "conf" directory was
>> 62  * introduced in JDK 1.9.)
>> 
>> It might be simpler to just have javadoc specify that it attepts to locate 
>> the `mailcap` file in the Java run-time image and then add an @implNote with 
>> the details as to where it looks for specific runtime releases.
>> 
>> I see the new source file ModuleUtil is using java.util.StringTokenizer. 
>> It's use in new code has been 

Re: Long.bitCount micro-optimization

[Doug Lea]

On 05/08/2017 02:14 PM, Isaac Levy wrote:

Original message below:

The JDK impl of bitCount can be improved -- though most users will get
the hotspot intrinsic. The best source I could find for the suggestion
below is page 195: http://support.amd.com/techdocs/25112.pdf



The int version differs from current implementation in that it uses
one multiply instead of two shift+adds. (Similarly for long.)

I wonder if there is any processor that does not already have a
bit-count instruction for which this is actually faster?
Some evidence either way would be helpful.

-Doug




Cheers,
Isaac Levy


Proposed Long.bitCount and Integer.bitCount:


public static int bitCount(long i)
{
i -= (i >>> 1) & 0xL;
i = (i & 0xL) + ((i >>> 2) & 0xL);
i = (i + (i >>> 4)) & 0x0f0f0f0f0f0f0f0fL;
return (i * 0x0101010101010101L) >>> 56;
}


public static int bitCount(int i) {
i -= (i >>> 1) & 0x;
i = (i & 0x) + ((i >>> 2) & 0x);
i = (i + (i >>> 4)) & 0x0f0f0f0f;
return (i * 0x01010101) >>> 24;
}

Re: Accessing UNIX FileDescriptor id without reflection

[Enrico Olivelli]

Il lun 8 mag 2017, 18:38 Remi Forax  ha scritto:

>
>
> - Mail original -
> > De: "Roger Riggs" 
> > À: core-libs-dev@openjdk.java.net
> > Envoyé: Lundi 8 Mai 2017 17:45:25
> > Objet: Re: Accessing UNIX FileDescriptor id without reflection
>
> > Hi,
> >
> > I would be very cautious about giving out fds for arbitrary
> FileDescriptors.
> > With concurrency and threading, how do you make sure that it does not
> > not get closed
> > and someone's code still has the fd and uses it later?  Or worse yet,
> > the fd gets re-used
> > and then it is possible to operate on the wrong file.
> > Quite a bit of implementation code assumes it has complete control over
> > the lifecycle of
> > the FileDescriptor.  Exposing the raw FD breaks the encapsulation.
> >
> > As Rémi suggests, passing the FileDescriptor to native will at least
> > maintain the current
> > encapsulation.
>

I like this option. I will give it a try.
Thank you all very much

Enrico


> s/Rémi/Peter
> Peter is right, i'm wrong :)
>
> >
> > Roger
>
> Rémi
>
> >
> >
> > On 5/8/2017 10:14 AM, Remi Forax wrote:
> >> I agree that a method getFd should be great, we will need this kind of
> value if
> >> we want to use Panama.
> >>
> >> Did you try to serializing the FileDescriptor in memory and extract the
> int
> >> corresponding to the file descriptor ?
> >>
> >> cheers,
> >> Rémi
> >>
> >> - Mail original -
> >>> De: "Enrico Olivelli" 
> >>> À: core-libs-dev@openjdk.java.net
> >>> Envoyé: Lundi 8 Mai 2017 15:16:24
> >>> Objet: Accessing UNIX FileDescriptor id without reflection
> >>> Hi,
> >>> I am trying to port a project (Apache BookKeeper) to Java9, actually
> >>> this code uses reflection in order to access the 'fd' field of the
> >>> FileDescriptor class.
> >>>
> >>> We have to access that ID in order to call low level native functions
> >>>
> >>> See
> >>>
> https://github.com/apache/bookkeeper/blob/master/bookkeeper-server/src/main/java/org/apache/bookkeeper/util/NativeIO.java
> >>> # getSysFileDescriptor
> >>>
> >>> Is there any way to access the FD handle without using reflection ?
> >>> If not, is it possibile to enhance the FileDescriptor API in order to
> >>> given access to the internal "fd" field ?
> >>>
> >>> Thank you
> >>>
> > >> Enrico Olivelli
>
-- 


-- Enrico Olivelli

Re: RFR (JAXP) 8150256: removing xerces-related dead code

[Lance Andersen]

+1
> On May 8, 2017, at 2:17 PM, huizhe wang  wrote:
> 
> Hi,
> 
> Please review removing three unused classes from the jaxp repo.
> JBS: https://bugs.openjdk.java.net/browse/JDK-8150256
> Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8150256/webrev/
> Tests: passed
> 
> Refer to the jaxp change history [1], the following changes in particular:
> 
> - - protected XPointerFramework fXPointerFramework = null; - protected 
> XPointerSchema [] fXPointerSchema; -
> 
> The references to these classes were removed during the early JDK 6 
> development.
> 
> 
> [1] 
> https://java.net/projects/jaxp-sources/sources/svn/diff/trunk/xml-xerces/java/src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java?rev1=509=510
> 
> Thanks,
> Joe
> 

 
  

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

RFR (JAXP) 8150256: removing xerces-related dead code

[huizhe wang]

Hi,

Please review removing three unused classes from the jaxp repo.
JBS: https://bugs.openjdk.java.net/browse/JDK-8150256
Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8150256/webrev/
Tests: passed

Refer to the jaxp change history [1], the following changes in particular:

- - protected XPointerFramework fXPointerFramework = null; - protected 
XPointerSchema [] fXPointerSchema; -


The references to these classes were removed during the early JDK 6 
development.



[1] 
https://java.net/projects/jaxp-sources/sources/svn/diff/trunk/xml-xerces/java/src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java?rev1=509=510


Thanks,
Joe

Re: Long.bitCount micro-optimization

[Isaac Levy]

Original message below:

The JDK impl of bitCount can be improved -- though most users will get
the hotspot intrinsic. The best source I could find for the suggestion
below is page 195: http://support.amd.com/techdocs/25112.pdf

Cheers,
Isaac Levy


Proposed Long.bitCount and Integer.bitCount:


public static int bitCount(long i)
{
i -= (i >>> 1) & 0xL;
i = (i & 0xL) + ((i >>> 2) & 0xL);
i = (i + (i >>> 4)) & 0x0f0f0f0f0f0f0f0fL;
return (i * 0x0101010101010101L) >>> 56;
}


public static int bitCount(int i) {
i -= (i >>> 1) & 0x;
i = (i & 0x) + ((i >>> 2) & 0x);
i = (i + (i >>> 4)) & 0x0f0f0f0f;
return (i * 0x01010101) >>> 24;
}

Re: Long.bitCount micro-optimization

[Brian Burkhalter]

Thanks for the patch. The correct forum is core-libs-dev@openjdk.java.net, 
which I have CCed.

Brian

On May 7, 2017, at 5:16 PM, Isaac Levy  wrote:

> Apologies if this is the wrong forum, I'm new to the OpenJDK project.

Re: JDK 9 RFR of JDK-8085814: Move stream test library to the jdk test library area

[Paul Sandoz]

Hi Amy,

The changes look good.

Would you mind re-basing this fix for JDK 10 instead? At this point we should 
be more conservative with such changes (even for tests).

Thanks,
Paul.

> On 8 May 2017, at 02:00, Amy Lu  wrote:
> 
> Please review this test-only change to move the test library
> jdk/test/java/util/stream/bootlib
> to
> jdk/test/lib/testlibrary/bootlib
> to make it formally easier for tests to depend on.
> 
> There is no change to the functionality of the tests.
> 
> This patch also removed NullArgsTestCase.java which is an abstract class 
> designed to be extended reused with a data provider. It provides no test 
> itself but be wrongly put in the directory of TestNG.dirs thus be run as a 
> test. In fact it is not even used and can be removed.
> 
> bug:
> https://bugs.openjdk.java.net/browse/JDK-8085814
> https://bugs.openjdk.java.net/browse/JDK-8173414
> 
> webrev:
> http://cr.openjdk.java.net/~amlu/8085814/webrev.00/
> (I did not update the year in the Copyright header for bootlib files, to make 
> the review easier. I can do bulk update for those files on the header before 
> push, if that is necessary.)
> 
> Thanks,
> Amy
> 
> 

Re: Accessing UNIX FileDescriptor id without reflection

[Remi Forax]

- Mail original -
> De: "Roger Riggs" 
> À: core-libs-dev@openjdk.java.net
> Envoyé: Lundi 8 Mai 2017 17:45:25
> Objet: Re: Accessing UNIX FileDescriptor id without reflection

> Hi,
> 
> I would be very cautious about giving out fds for arbitrary FileDescriptors.
> With concurrency and threading, how do you make sure that it does not
> not get closed
> and someone's code still has the fd and uses it later?  Or worse yet,
> the fd gets re-used
> and then it is possible to operate on the wrong file.
> Quite a bit of implementation code assumes it has complete control over
> the lifecycle of
> the FileDescriptor.  Exposing the raw FD breaks the encapsulation.
> 
> As Rémi suggests, passing the FileDescriptor to native will at least
> maintain the current
> encapsulation.

s/Rémi/Peter
Peter is right, i'm wrong :)

> 
> Roger

Rémi

> 
> 
> On 5/8/2017 10:14 AM, Remi Forax wrote:
>> I agree that a method getFd should be great, we will need this kind of value 
>> if
>> we want to use Panama.
>>
>> Did you try to serializing the FileDescriptor in memory and extract the int
>> corresponding to the file descriptor ?
>>
>> cheers,
>> Rémi
>>
>> - Mail original -
>>> De: "Enrico Olivelli" 
>>> À: core-libs-dev@openjdk.java.net
>>> Envoyé: Lundi 8 Mai 2017 15:16:24
>>> Objet: Accessing UNIX FileDescriptor id without reflection
>>> Hi,
>>> I am trying to port a project (Apache BookKeeper) to Java9, actually
>>> this code uses reflection in order to access the 'fd' field of the
>>> FileDescriptor class.
>>>
>>> We have to access that ID in order to call low level native functions
>>>
>>> See
>>> https://github.com/apache/bookkeeper/blob/master/bookkeeper-server/src/main/java/org/apache/bookkeeper/util/NativeIO.java
>>> # getSysFileDescriptor
>>>
>>> Is there any way to access the FD handle without using reflection ?
>>> If not, is it possibile to enhance the FileDescriptor API in order to
>>> given access to the internal "fd" field ?
>>>
>>> Thank you
>>>
> >> Enrico Olivelli

Re: Accessing UNIX FileDescriptor id without reflection

[Roger Riggs]

Hi,

I would be very cautious about giving out fds for arbitrary FileDescriptors.
With concurrency and threading, how do you make sure that it does not 
not get closed
and someone's code still has the fd and uses it later?  Or worse yet, 
the fd gets re-used

and then it is possible to operate on the wrong file.
Quite a bit of implementation code assumes it has complete control over 
the lifecycle of

the FileDescriptor.  Exposing the raw FD breaks the encapsulation.

As Rémi suggests, passing the FileDescriptor to native will at least 
maintain the current

encapsulation.

Roger


On 5/8/2017 10:14 AM, Remi Forax wrote:

I agree that a method getFd should be great, we will need this kind of value if 
we want to use Panama.

Did you try to serializing the FileDescriptor in memory and extract the int 
corresponding to the file descriptor ?

cheers,
Rémi

- Mail original -

De: "Enrico Olivelli" 
À: core-libs-dev@openjdk.java.net
Envoyé: Lundi 8 Mai 2017 15:16:24
Objet: Accessing UNIX FileDescriptor id without reflection
Hi,
I am trying to port a project (Apache BookKeeper) to Java9, actually
this code uses reflection in order to access the 'fd' field of the
FileDescriptor class.

We have to access that ID in order to call low level native functions

See
https://github.com/apache/bookkeeper/blob/master/bookkeeper-server/src/main/java/org/apache/bookkeeper/util/NativeIO.java
# getSysFileDescriptor

Is there any way to access the FD handle without using reflection ?
If not, is it possibile to enhance the FileDescriptor API in order to
given access to the internal "fd" field ?

Thank you

Enrico Olivelli

Re: Accessing UNIX FileDescriptor id without reflection

[Peter Levart]

Hi Enrico,

java.io.FileDescriptor is a public class, part of public API. There's 
one version for JVMs running on UNIX-based OSes and another for JVMs 
running on Windows. Both contain int field 'fd'. But you already know 
that if you access this field using reflection. Now instead of doing 
this in Java and then passing the numberic 'fd' down to native code, you 
could pass the whole FileDescriptor object to native code and access the 
field using JNI. There's no restriction imposed by Jigsaw in JNI.


Regards, Peter


On 05/08/2017 03:16 PM, Enrico Olivelli wrote:

Hi,
I am trying to port a project (Apache BookKeeper) to Java9, actually
this code uses reflection in order to access the 'fd' field of the
FileDescriptor class.

We have to access that ID in order to call low level native functions

See
https://github.com/apache/bookkeeper/blob/master/bookkeeper-server/src/main/java/org/apache/bookkeeper/util/NativeIO.java
# getSysFileDescriptor

Is there any way to access the FD handle without using reflecttion ?
If not, is it possibile to enhance the FileDescriptor API in order to
given access to the internal "fd" field ?

Thank you

Enrico Olivelli

Re: Accessing UNIX FileDescriptor id without reflection

[Remi Forax]

I agree that a method getFd should be great, we will need this kind of value if 
we want to use Panama.

Did you try to serializing the FileDescriptor in memory and extract the int 
corresponding to the file descriptor ?

cheers,
Rémi

- Mail original -
> De: "Enrico Olivelli" 
> À: core-libs-dev@openjdk.java.net
> Envoyé: Lundi 8 Mai 2017 15:16:24
> Objet: Accessing UNIX FileDescriptor id without reflection

> Hi,
> I am trying to port a project (Apache BookKeeper) to Java9, actually
> this code uses reflection in order to access the 'fd' field of the
> FileDescriptor class.
> 
> We have to access that ID in order to call low level native functions
> 
> See
> https://github.com/apache/bookkeeper/blob/master/bookkeeper-server/src/main/java/org/apache/bookkeeper/util/NativeIO.java
> # getSysFileDescriptor
> 
> Is there any way to access the FD handle without using reflecttion ?
> If not, is it possibile to enhance the FileDescriptor API in order to
> given access to the internal "fd" field ?
> 
> Thank you
> 
> Enrico Olivelli

Re: Accessing module internals from bytecode rewriting agent

[dalibor topic]

On 05.05.2017 08:39, Jeremy Manson wrote:

Mostly, I'm telling you all because I think it makes an interesting case
study - a large Java installation and the issues it faces trying to roll
out JDK 9.


Indeed - thank you for providing valuable insight into your concerns and 
experiences.



If other installations do the kinds of things that we do, the path to a
JDK 9 without lots of add-exports and kill switch options is likely to
be slow and laborious for them.  We're comparatively well situated to do
it - we have our own JDK build and a staffed team to do / help with the
migration, and are likely to roll it out to everyone with the kill
switch turned on by default so that our awful hacks can stay put until
we finish fixing them.


I think part of responsibly relying on awful hacks leveraging 
unsupported behavior is to budget for their removal/rewrite as the 
assumptions behind them get invalidated over time.


Sometimes, it might be well known where the awful hacks are buried, in 
particular with one's own code. Other times, in particular with third 
party code, it might not be quite as obvious. That's where the jdeps & 
jdeprscan tools come in to help get a sense of the scope & intensity of 
such problems at compile time.


The kill switch complements that at runtime.

cheers,
dalibor topic
--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

Re: IBM RSA-II "virtual drive" feature does not work with OpenJDK

[Martin T]

On Mon, May 8, 2017 at 3:07 PM, Mario Torre
 wrote:
> 2017-05-08 13:45 GMT+02:00 dalibor topic :
>> Hi Martin,
>>
>> we don't provide OpenJDK binaries in Linux distributions.
>>
>> I'd suggest reporting it to the provider of your binaries directly (Debian
>> in this case), as we don't provide a browser plugin implementation, either.
>> Alternatively, you may want to give the distro-pkg-dev mailing list a try,
>> where the developers of the IcedTea-Web plugin and/or Debian packages may be
>> found.
>>
>> cheers,
>> dalibor topic
>
> This is probably something to report to IBM first, I suspect some use
> of some weird hidden internal code. Jigsaw is long overdue...
>
> Cheers,
> Mario
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/

Mario,

when I start the applet, then it downloads libibmxrdisk.so.1.0.3
binary which I guess is a native library(Java Native Interface) for
Linux operating system:

# file /root/IBM/10.10.10.65/libibmxrdisk.so.1.0.3
/root/IBM/10.10.10.65/libibmxrdisk.so.1.0.3: ELF 32-bit LSB shared
object, Intel 80386, version 1 (SYSV), dynamically linked, not
stripped
#
# strings /root/IBM/10.10.10.65/libibmxrdisk.so.1.0.3  | grep
GetSupportedDevices
Java_VirtualDrive_PassThroughCommand_GetSupportedDevices
GetSupportedDevices
Java_VirtualDrive_PassThroughCommand_GetSupportedDevices
#

I also guess that this is provided by IBM and it's probably broken?
Under Windows operating system it seems to download a dll file
according to Java Console:

ClientInterface::downloadLib: downloaded C:\Documents and
Settings\user\IBM\10.10.10.65\remotedrive3d.dll in 1 attempts.


So I guess either the libibmxrdisk.so.1.0.3 is broken or my Linux
version is not compatible with this native library..?


thanks,
Martin

Re: IBM RSA-II "virtual drive" feature does not work with OpenJDK

[Mario Torre]

2017-05-08 13:45 GMT+02:00 dalibor topic :
> Hi Martin,
>
> we don't provide OpenJDK binaries in Linux distributions.
>
> I'd suggest reporting it to the provider of your binaries directly (Debian
> in this case), as we don't provide a browser plugin implementation, either.
> Alternatively, you may want to give the distro-pkg-dev mailing list a try,
> where the developers of the IcedTea-Web plugin and/or Debian packages may be
> found.
>
> cheers,
> dalibor topic

This is probably something to report to IBM first, I suspect some use
of some weird hidden internal code. Jigsaw is long overdue...

Cheers,
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

Re: IBM RSA-II "virtual drive" feature does not work with OpenJDK

[dalibor topic]

Hi Martin,

we don't provide OpenJDK binaries in Linux distributions.

I'd suggest reporting it to the provider of your binaries directly 
(Debian in this case), as we don't provide a browser plugin 
implementation, either. Alternatively, you may want to give the 
distro-pkg-dev mailing list a try, where the developers of the 
IcedTea-Web plugin and/or Debian packages may be found.


cheers,
dalibor topic

On 08.05.2017 13:00, Martin T wrote:

Hi,

first of all, I hope that this is a correct mailing list.

I have an IBM server with Remote Supervisor Adapter II out-of-band
card which provides a remote console function using an Java applet. It
works fine with Java version 1.7.0_121 provided by
openjdk-7-jre-headless package under Debian and IcedTea-Web plugin
version 1.5.3 except one can not use "virtual drive" function:
http://i.imgur.com/qDqlFPR.png However, this "virtual drive" feature
works fine under Windows(IE 7.0.5730.13, Java SE 1.6.0.05):
http://i.imgur.com/a8H7lXn.jpg


If I start my browser(Firefox 45.9.0) from the terminal and launch the
applet, then it logs following error:

java.lang.UnsatisfiedLinkError:
VirtualDrive.PassThroughCommand.GetSupportedDevices()LVirtualDrive/SupportedDevices;
at VirtualDrive.PassThroughCommand.GetSupportedDevices(Native Method)
at com.ibm.asm.remotedisk.RemoteDisk.buildDriveList(Unknown Source)
at com.ibm.asm.remotedisk.RemoteDisk.start(Unknown Source)
at sun.applet.AppletPanel.run(AppletPanel.java:476)
at 
sun.applet.AppletViewerPanelAccess.run(AppletViewerPanelAccess.java:90)
at java.lang.Thread.run(Thread.java:745)

I also tried with OpenJDK version 1.8.0_121, but the error message was
almost exactly the same:

java.lang.UnsatisfiedLinkError:
VirtualDrive.PassThroughCommand.GetSupportedDevices()LVirtualDrive/SupportedDevices;
at VirtualDrive.PassThroughCommand.GetSupportedDevices(Native Method)
at com.ibm.asm.remotedisk.RemoteDisk.buildDriveList(Unknown Source)
at com.ibm.asm.remotedisk.RemoteDisk.start(Unknown Source)
at sun.applet.AppletPanel.run(AppletPanel.java:476)
at 
sun.applet.AppletViewerPanelAccess.run(AppletViewerPanelAccess.java:84)
at java.lang.Thread.run(Thread.java:745)


Is this feature not supported by OpenJDK? Please let me know if I can
provide any additional information for troubleshooting.


thanks,
Martin



--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

IBM RSA-II "virtual drive" feature does not work with OpenJDK

[Martin T]

Hi,

first of all, I hope that this is a correct mailing list.

I have an IBM server with Remote Supervisor Adapter II out-of-band
card which provides a remote console function using an Java applet. It
works fine with Java version 1.7.0_121 provided by
openjdk-7-jre-headless package under Debian and IcedTea-Web plugin
version 1.5.3 except one can not use "virtual drive" function:
http://i.imgur.com/qDqlFPR.png However, this "virtual drive" feature
works fine under Windows(IE 7.0.5730.13, Java SE 1.6.0.05):
http://i.imgur.com/a8H7lXn.jpg


If I start my browser(Firefox 45.9.0) from the terminal and launch the
applet, then it logs following error:

java.lang.UnsatisfiedLinkError:
VirtualDrive.PassThroughCommand.GetSupportedDevices()LVirtualDrive/SupportedDevices;
at VirtualDrive.PassThroughCommand.GetSupportedDevices(Native Method)
at com.ibm.asm.remotedisk.RemoteDisk.buildDriveList(Unknown Source)
at com.ibm.asm.remotedisk.RemoteDisk.start(Unknown Source)
at sun.applet.AppletPanel.run(AppletPanel.java:476)
at 
sun.applet.AppletViewerPanelAccess.run(AppletViewerPanelAccess.java:90)
at java.lang.Thread.run(Thread.java:745)

I also tried with OpenJDK version 1.8.0_121, but the error message was
almost exactly the same:

java.lang.UnsatisfiedLinkError:
VirtualDrive.PassThroughCommand.GetSupportedDevices()LVirtualDrive/SupportedDevices;
at VirtualDrive.PassThroughCommand.GetSupportedDevices(Native Method)
at com.ibm.asm.remotedisk.RemoteDisk.buildDriveList(Unknown Source)
at com.ibm.asm.remotedisk.RemoteDisk.start(Unknown Source)
at sun.applet.AppletPanel.run(AppletPanel.java:476)
at 
sun.applet.AppletViewerPanelAccess.run(AppletViewerPanelAccess.java:84)
at java.lang.Thread.run(Thread.java:745)


Is this feature not supported by OpenJDK? Please let me know if I can
provide any additional information for troubleshooting.


thanks,
Martin

JDK 9 RFR of JDK-8085814: Move stream test library to the jdk test library area

[Amy Lu]

Please review this test-only change to move the test library
jdk/test/java/util/stream/bootlib
to
jdk/test/lib/testlibrary/bootlib
to make it formally easier for tests to depend on.

There is no change to the functionality of the tests.

This patch also removed NullArgsTestCase.java which is an abstract class 
designed to be extended reused with a data provider. It provides no test 
itself but be wrongly put in the directory of TestNG.dirs thus be run as 
a test. In fact it is not even used and can be removed.


bug:
https://bugs.openjdk.java.net/browse/JDK-8085814
https://bugs.openjdk.java.net/browse/JDK-8173414

webrev:
http://cr.openjdk.java.net/~amlu/8085814/webrev.00/
(I did not update the year in the Copyright header for bootlib files, to 
make the review easier. I can do bulk update for those files on the 
header before push, if that is necessary.)


Thanks,
Amy