Fw: core-libs-dev Digest, Vol 131, Issue 19

[A Z]

To who it may concern,


'There was a JSR to add a new mode'

Citation about problems with Java floating point:

https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf



I suppose I would be asking for that change on float and double, that being the 
case,

as well as an extra mathematics class for BigDecimal.


People absolutely need decimal accuracy, and not floating point approximations, 
within their

ranges.


Double a = 0.1D;


Double b = 0.1D;


Double output = a*b;


out.println(output == 0.01D);  //false, should be true.


//and,


Float a = 0.1F;


Float b = 0.1F;


Float output = a*b;


out.println(output == 0.01F);  //false, should be true.



Despite all the time since 1.1, these are necessary changes,

since having to use BigDecimal for all accurate arithmetic begins

to waste memory, instructions, and the presently unavoidable

translation betwee get/set (float or double) and compute (BigDecimal)

and convert to (float or double).


The other thing is that whenever asking for a .distance()

method in Java2D, Java3D, AWT, Swing, JavaFX, JavaFX2,

if I even temporarily want to proceed with decimal distances,

these methods are all possibly able to return underflow or underflow results.


These are in fact not opinions, but very great needs that the Software

community has needed from java for a very long time now,

despite statements in the Java Language Specification, which in fact do not

entirely, unilaterally implement the IEEE 754 standard.


And can people please check out, sitting on the Oracle Java Bugs Database:


JDK-8190947
JDK-8197995
JDK-8190991
JDK-8190946

Re: RFR 8198970: jnu_util.c compilation error on Solaris

[Kim Barrett]

> On Mar 2, 2018, at 10:36 PM, David Holmes  wrote:
> 
> On 3/03/2018 8:56 AM, Roger Riggs wrote:
>> Please review a correction to the jni_util.c native code that does not 
>> compile on Solaris.
>> Declarations must precede assignments.
> 
> Wow! I didn't think Solaris Studio compiler was subject to such anachronisms! 
> We must be compiling in a really old mode. I'm pretty darn certain we're not 
> limited this way when compiling hotspot ..

This is C, not C++, and is apparently being compiled in C89 mode.  (Mixing 
declarations and statements in compound statements was added in C99.)

> David
> 
>> Issue: 8198970 jnu_util.c compilation error on Solaris 
>> 
>> diff --git a/src/java.base/share/native/libjava/jni_util.c 
>> b/src/java.base/share/native/libjava/jni_util.c
>> --- a/src/java.base/share/native/libjava/jni_util.c
>> +++ b/src/java.base/share/native/libjava/jni_util.c
>> @@ -803,10 +803,10 @@ InitializeEncoding(JNIEnv *env, const ch
>>  (strcmp(encname, "ISO-8859-1") == 0)) {
>>  fastEncoding = FAST_8859_1;
>>  } else if (strcmp(encname, "UTF-8") == 0) {
>> -fastEncoding = FAST_UTF_8;
>>  jstring enc = (*env)->NewStringUTF(env, encname);
>>  if (enc == NULL)
>>  return;
>> +fastEncoding = FAST_UTF_8;
>>  jnuEncoding = (jstring)(*env)->NewGlobalRef(env, enc);
>>  (*env)->DeleteLocalRef(env, enc);
>>  } else if (strcmp(encname, "ISO646-US") == 0) {
>> @@ -818,10 +818,10 @@ InitializeEncoding(JNIEnv *env, const ch
>>  strcmp(encname, "utf-16le") == 0) {
>>  fastEncoding = FAST_CP1252;
>>  } else {
>> -fastEncoding = NO_FAST_ENCODING;
>>  jstring enc = (*env)->NewStringUTF(env, encname);
>>  if (enc == NULL)
>>  return;
>> +fastEncoding = NO_FAST_ENCODING;
>>  jnuEncoding = (jstring)(*env)->NewGlobalRef(env, enc);
>>  (*env)->DeleteLocalRef(env, enc);
>>  }
>> Thanks, Roger

Re: GetPrimitiveArrayCritical vs GetByteArrayRegion: 140x slow-down using -Xcheck:jni and java.util.zip.DeflaterOutputStream

[David Holmes]

Hi Ian,

Do you run with -Xcheck:jni in production mode because you load unknown 
native code libraries? It's mainly intended as a diagnostic option to 
turn on if you encounter a possible JNI problem.


I'll leave the debate on your actual patch proposal to others more 
familiar with the library code.


Thanks,
David

On 5/03/2018 5:24 AM, Ian Rogers wrote:

Hi,

we've been encountering poor performance with -Xcheck:jni, for the
following example the performance is 140x to 510x slower with the flag
enabled:




import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.util.Random;
import java.util.zip.DeflaterOutputStream;

public final class CheckJniTest {
  static void deflateBytesPerformance() throws IOException {
byte[] inflated = new byte[1 << 23];
new Random(71917367).nextBytes(inflated);
ByteArrayOutputStream deflated = new ByteArrayOutputStream();
try (DeflaterOutputStream dout = new DeflaterOutputStream(deflated)) {
  dout.write(inflated, 0, inflated.length);
}
if (8391174 != deflated.size()) {
  throw new AssertionError();
}
  }

  public static void main(String args[]) throws IOException {
int n = 5;
if (args.length > 0) {
  n = Integer.parseInt(args[0]);
}
for (int i = 0; i < n; i++) {
  long startTime = System.currentTimeMillis();
  deflateBytesPerformance();
  long endTime = System.currentTimeMillis();
  System.out.println("Round " + i + " took " + (endTime - startTime) +
 "ms");
}
  }
}


The issue is in the libzip Deflater.c JNI code:
http://hg.openjdk.java.net/jdk/jdk/file/c5eb27eed365/src/java.base/share/native/libzip/Deflater.c#l131

The test has an 8MB array to deflate/compress. The DeflaterOutputStream has
an buffer of size 512 bytes:
http://hg.openjdk.java.net/jdk/jdk/file/c5eb27eed365/src/java.base/share/classes/java/util/zip/DeflaterOutputStream.java#l128

To compress the array, 16,384 native calls are made that use the 8MB input
array and the 512 byte output array. These arrays are accessed using
GetPrimitiveArrayCritical that with -Xcheck:jni copies the array:
http://hg.openjdk.java.net/jdk/jdk/file/c5eb27eed365/src/hotspot/share/prims/jniCheck.cpp#l1862
The copying of the arrays leads to 128GB of copying which dominates
execution time.

One approach to fix the problem is to rewrite libzip in Java. GNU Classpath
has such an implementation:
http://cvs.savannah.gnu.org/viewvc/classpath/classpath/java/util/zip/Deflater.java?view=markup#l417

A different approach is to use Get/SetByteArrayRegion (using
Get/SetByteArrayElements would be no different than the current approach
accept potentially causing more copies). I've included a patch and
performance data for this approach below where regions of the arrays are
copied onto a 512 byte buffer on the stack. The non -Xcheck:jni performance
is roughly equivalent before and after the patch, the -Xcheck:jni
performance is now similar to the non -Xcheck:jni performance.

The choice to go from a using GetPrimitiveArrayCritical to
GetByteArrayRegion is a controversial one, as engineers have many different
expectations about what critical means and does. GetPrimitiveArrayCritical
may have similar overhead to GetByteArrayElements if primitive arrays
(possibly of a certain size) are known to be non-moving. There may be a
cost to pin critical arrays or regions they exist within. There may be a
global or region lock that is in play that can cause interactions with the
garbage collector - such interactions may cause tail latency issues in
production environments. GetByteArrayRegion loses compared to
GetPrimitiveArrayCritical as it must always copy a region of the array for
access. Given these issues it is hard to develop a benchmark of
GetPrimitiveArrayCritical
vs GetByteArrayRegion that can take into account the GC interactions. Most
benchmarks will see that avoiding a copy can be good for performance.

For more background, Aleksey has a good post on GetPrimitiveArrayCritical
here:
https://shipilev.net/jvm-anatomy-park/9-jni-critical-gclocker/

A different solution to the performance problem presented here is to change
the check JNI implementation to do less copying of arrays. This would be
motivated if GetPrimitiveArrayCritical were expected to be used more widely
than GetByteArrayRegion in performance sensitive, commonly used code. Given
the range of problems possible with GetPrimitiveArrayCritical I'd
personally prefer GetByteArrayRegion to be more commonly used, as I'm yet
to see a performance problem that made GetPrimitiveArrayCritical so
compelling. For example, ObjectOutputStream has burnt me previously:
http://hg.openjdk.java.net/jdk/jdk/file/c5eb27eed365/src/java.base/share/native/libjava/ObjectOutputStream.c#l69
and these trivial copy operations, should really be a call to fix the
JIT/AOT compilers.

Next steps: it'd be great to get this turned in to a bug although its not
clear to me whether this is a JDK issue 

Re: RFR 8198931: remove java.xml.bind module dependency for com/sun/jndi tests

[Chris Yin]

Thank you, Lance

Regards,
Chris

> On 5 Mar 2018, at 9:38 AM, Lance Andersen  wrote:
> 
> +1
> 
> --
>  
> 
>  Lance Andersen| 
> Principal Member of Technical Staff | +1.781.442.2037 
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803 
> lance.ander...@oracle.com 
> 
> Sent from my iPhone
> 
> On Mar 4, 2018, at 8:26 PM, Chris Yin  > wrote:
> 
>> Please review the minor changes to remove java.xml.bind module dependency 
>> for com/sun/jndi tests, thanks
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8198931 
>>  
>> > >
>> webrev: http://cr.openjdk.java.net/~xiaofeya/8198931/webrev.00/ 
>>  
>> > >
>> 
>> Regards,
>> Chris

Re: RFR 8198931: remove java.xml.bind module dependency for com/sun/jndi tests

[Lance Andersen]

+1

--

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

Sent from my iPhone

> On Mar 4, 2018, at 8:26 PM, Chris Yin  wrote:
> 
> Please review the minor changes to remove java.xml.bind module dependency for 
> com/sun/jndi tests, thanks
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8198931 
> 
> webrev: http://cr.openjdk.java.net/~xiaofeya/8198931/webrev.00/ 
> 
> 
> Regards,
> Chris

RFR 8198931: remove java.xml.bind module dependency for com/sun/jndi tests

[Chris Yin]

Please review the minor changes to remove java.xml.bind module dependency for 
com/sun/jndi tests, thanks

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

webrev: http://cr.openjdk.java.net/~xiaofeya/8198931/webrev.00/ 


Regards,
Chris

Re: core-libs-dev Digest, Vol 131, Issue 19

[Jonathan Bluett-Duncan]

 Okay. Do you have any citations that we can refer to to confirm for
ourselves that this is indeed a recognised need?

Cheers,
Jonathan


On 4 March 2018 at 05:24, A Z  wrote:

> To who it may concern,
>
>
> 'There was a JSR to add a new mode'
>
>
> then I suppose I would be asking for that change on float and double, that
> being the case,
>
>
> as well as an extra mathematics class for BigDecimal.
>
>
> Despite all the time since 1.1, these are necessary changes,
>
>
> since having to use BigDecimal for all accurate arithmetic begins
>
>
> to waste memory, instructions, and the presently unavoidable
>
>
> translation betwee get/set (float or double) and compute (BigDecimal)
>
>
> and convert to (float or double).
>
>
> These are in fact not opinions, but very great needs that the Software
>
>
> community has needed from java for a very long time now,
>
>
> despite statement in the Java Language Specification.
>
> . . .