Re: RFR: 8302214: Typo in javadoc of Arrays.compare and Arrays.mismatch
On Thu, 9 Feb 2023 10:13:03 GMT, Eirik Bjorsnos wrote:
> The Javadocs of Arrays.compare and Arrays.mismatch uses the incorrect
> capitalization `atoIndex` and `btoIndex` when referencing the corresponding
> `aToIndex` and `bToIndex` parameters.
>
> Sample:
>
>
> * specified ranges [{@code aFromIndex}, {@code atoIndex}) and
> * [{@code bFromIndex}, {@code btoIndex}) respectively:
>
>
> This PR changes the capitalization to `aToIndex` and `bToIndex`. This change
> was performed using case-sensitive search / replace in an IDE.
The changes look fine to me.
-
Marked as reviewed by jpai (Reviewer).
PR: https://git.openjdk.org/jdk/pull/12488
Re: RFR: 8302204: Optimize BigDecimal.divide
On Mon, 13 Feb 2023 03:54:07 GMT, Sergey Kuksenko wrote: > As for TPC-DS [AUTO-RESULT] QueryTotal=1968s vs [AUTO-RESULT] > QueryTotal=1934s that gives ~1.7% of performance difference. Are you sure > that this small diff is a real diff, but not run-to-run variance? These queries are separate and independent. We can even config TPC-DS to run query4 alone and the result is 100s vs 71s. The other queries don't have much to do with decimals. So if you look at the total time, yes there is just a slight diff, because only query4 is impacted by our optimization. But if you just look at query4, the acceleration is shown consistently, we have seen data like 102s->68s, 100s->71s. - PR: https://git.openjdk.org/jdk/pull/12509
Re: RFR: 8302204: Optimize BigDecimal.divide
Could you do that benchmark with e.g. JMH rather than taking the difference
of System.currentTimeMillis? That would probably make it easier to read
and trust the results.
On Sun, Feb 12, 2023, 7:56 PM Sergey Kuksenko wrote:
> On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu wrote:
>
> > [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has
> uncovered the poor performance of BigDecimal.divide under certain
> circumstance.
> >
> > We confront similar situations when benchmarking Spark3 on TPC-DS test
> kit. According to the flame-graph below, it is StripZeros that spends most
> of the time of BigDecimal.divide. Hence we propose this patch to optimize
> stripping zeros.
> > 
> >
> > Currently, createAndStripZerosToMatchScale() is performed linearly. That
> is, the target value is parsed from back to front, each time stripping out
> single ‘0’. To optimize, we can adopt the method of binary search. That is,
> each time we try to strip out ${scale/2} ‘0’s.
> >
> > The performance looks good. Therotically, time complexity of our method
> is O(log n), while the current one is O(n). In practice, benchmarks on
> Spark3 show that 1/3 less time (102s->68s) is spent on TPC-DS query4. We
> also runs Jtreg and JCK to check correctness, and it seems fine.
> >
> > More about environment:
> > we run Spark3.3.0 on Openjdk11, but it seems jdk version doesn’t have
> much impact on BigDecimal. Spark cluster consists of a main node and 2 core
> nodes, each has 4cores, 16g memory and 4x500GB storage.
>
> As for TPC-DS
> [AUTO-RESULT] QueryTotal=1968s vs [AUTO-RESULT] QueryTotal=1934s
> that gives ~1.7% of performance difference.
> Are you sure that this small diff is a real diff, but not run-to-run
> variance?
>
> -
>
> PR: https://git.openjdk.org/jdk/pull/12509
>
Re: RFR: 8302204: Optimize BigDecimal.divide
On Fri, 10 Feb 2023 10:00:05 GMT, Xiaowei Lu wrote:
> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the
> poor performance of BigDecimal.divide under certain circumstance.
>
> We confront similar situations when benchmarking Spark3 on TPC-DS test kit.
> According to the flame-graph below, it is StripZeros that spends most of the
> time of BigDecimal.divide. Hence we propose this patch to optimize stripping
> zeros.
> 
>
> Currently, createAndStripZerosToMatchScale() is performed linearly. That is,
> the target value is parsed from back to front, each time stripping out single
> ‘0’. To optimize, we can adopt the method of binary search. That is, each
> time we try to strip out ${scale/2} ‘0’s.
>
> The performance looks good. Therotically, time complexity of our method is
> O(log n), while the current one is O(n). In practice, benchmarks on Spark3
> show that 1/3 less time (102s->68s) is spent on TPC-DS query4. We also runs
> Jtreg and JCK to check correctness, and it seems fine.
>
> More about environment:
> we run Spark3.3.0 on Openjdk11, but it seems jdk version doesn’t have much
> impact on BigDecimal. Spark cluster consists of a main node and 2 core nodes,
> each has 4cores, 16g memory and 4x500GB storage.
As for TPC-DS
[AUTO-RESULT] QueryTotal=1968s vs [AUTO-RESULT] QueryTotal=1934s
that gives ~1.7% of performance difference.
Are you sure that this small diff is a real diff, but not run-to-run variance?
-
PR: https://git.openjdk.org/jdk/pull/12509
Re: RFR: 8302204: Optimize BigDecimal.divide
On Sat, 11 Feb 2023 16:03:24 GMT, Sergey Kuksenko wrote: > "The performance looks good." - Could you support this statement with some > benchmark results? Thank you. Hi, here is a detailed result 1. I have run the benchmark in [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667), which calculates 1/2, 1/3 ... to 1/100. From the result, we can see nearly 3x faster when the remainder is zero, and no obvious difference when it's not zero. This is consistent with our estimation, since stripping zeros is needed only when the remainder is zero. before optimization 2 3423ms 3149ms 4 3794ms 5 3931ms 6175ms 7160ms 8 3814ms 9159ms 10 3669ms 11198ms 12183ms 13195ms 14215ms 15197ms 16 4064ms 17184ms 18198ms 19199ms 20 4500ms 21203ms 22188ms 23205ms 24218ms 25 4337ms 26187ms 27189ms 28208ms 29193ms 30194ms 31201ms 32 4029ms 33192ms 34205ms 35204ms 36201ms 37188ms 38188ms 39201ms 40 4179ms 41200ms 42199ms 43187ms 44240ms 45184ms 46199ms 47187ms 48187ms 49196ms 50 4257ms 51187ms 52187ms 53184ms 54196ms 55187ms 56199ms 57198ms 58184ms 59197ms 60200ms 61187ms 62187ms 63196ms 64 3874ms 65187ms 66184ms 67189ms 68200ms 69200ms 70187ms 71197ms 72197ms 73187ms 74200ms 75186ms 76185ms 77197ms 78199ms 79187ms 80 4063ms 81188ms 82199ms 83197ms 84202ms 85188ms 86188ms 87184ms 88185ms 89188ms 90188ms 91202ms 92185ms 93185ms 94202ms 95201ms 96200ms 97197ms 98198ms 99189ms 100 4472ms after optimization 2 1308ms 3146ms 4 1117ms 5 1249ms 6174ms 7160ms 8 1014ms 9165ms 10 1394ms 11199ms 12191ms 13204ms 14192ms 15198ms 16 1261ms 17172ms 18185ms 19185ms 20 1223ms 21184ms 22172ms 23184ms 24189ms 25 1227ms 26178ms 27177ms 28188ms 29177ms 30177ms 31189ms 32961ms 33176ms 34185ms 35185ms 36184ms 37172ms 38172ms 39185ms 40 1127ms 41189ms 42189ms 43175ms 44188ms 45176ms 46190ms 47177ms 48175ms 49189ms 50 1222ms 51176ms 52176ms 53173ms 54185ms 55175ms 56185ms 57186ms 58172ms 59185ms 60185ms 61176ms 62176ms 63189ms 64 1339ms 65175ms 66176ms 67176ms 68188ms 69189ms 70175ms 71188ms 72189ms 73172ms 74184ms 75172ms 76172ms 77184ms 78184ms 79172ms 80 1275ms 81172ms 82190ms 83189ms 84189ms 85176ms 86177ms 87176ms 88177ms 89177ms 90172ms 91185ms 92173ms 93171ms 94185ms 95185ms 96185ms 97183ms 98189ms 99233ms 100 1200ms 2. Also the benchmark TPC-DS has been run on Spark3. TPC-DS has 99 SQL queries, the 4th of which spends a lot of time calculating decimals. We have collected time assumptions in each query and found out 1/3 less time spent on query4, with other queries nearly the same. before optimization [AUTO-RESULT] query1=14s [AUTO-RESULT] query2=21s [AUTO-RESULT] query3=6s **[AUTO-RESULT] query4=102s** [AUTO-RESULT] query5=32s [AUTO-RESULT] query6=7s [AUTO-RESULT] query7=7s [AUTO-RESULT] query8=7s [AUTO-RESULT] query9=28s [AUTO-RESULT] query10=15s [AUTO-RESULT] query11=35s [AUTO-RESULT] query12=6s [AUTO-RESULT] query13=8s
Re: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions to Java [v9]
> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to
> refactor the regression tests a bit to reduce duplication, but the actual
> ports should be ready for review.
>
> Diff'ing the ports as before, original vs transliteration port:
>
>
> $ diff -w Hyperbolic.c Hyperbolic.translit.java
> 1c1
> < /* __ieee754_sinh(x)
> ---
>> /**
> 17a18,19
>> static class Sinh {
>> private static final double one = 1.0, shuge = 1.0e307;
> 19,33c21
> < #include "fdlibm.h"
> <
> < #ifdef __STDC__
> < static const double one = 1.0, shuge = 1.0e307;
> < #else
> < static double one = 1.0, shuge = 1.0e307;
> < #endif
> <
> < #ifdef __STDC__
> < double __ieee754_sinh(double x)
> < #else
> < double __ieee754_sinh(x)
> < double x;
> < #endif
> < {
> ---
>> private static double compute(double x) {
> 36c24
> < unsigned lx;
> ---
>> /* unsigned */ int lx;
> 51c39
> < t = expm1(fabs(x));
> ---
>> t = FdlibmTranslit.expm1(Math.abs(x));
> 57c45
> < if (ix < 0x40862E42) return h*__ieee754_exp(fabs(x));
> ---
>> if (ix < 0x40862E42) return h*StrictMath.exp(Math.abs(x)); //
>> TODO switch to translit
> 60,62c48,52
> < lx = *( (((*(unsigned*))>>29)) + (unsigned*));
> < if (ix<0x408633CE ||
> ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> < w = __ieee754_exp(0.5*fabs(x));
> ---
>> // lx = *( (((*(unsigned*))>>29)) + (unsigned*));
>> // lx = (((*(unsigned*))>>29)) + (unsigned*) ;
>> lx = __LO(x);
>> if (ix<0x408633CE ||
>> ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>> w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to
>> translit
> 70c60,62
> < /* __ieee754_cosh(x)
> ---
>> }
>>
>> /**
> 90,105c82,84
> <
> < #include "fdlibm.h"
> <
> < #ifdef __STDC__
> < static const double one = 1.0, half=0.5, huge = 1.0e300;
> < #else
> < static double one = 1.0, half=0.5, huge = 1.0e300;
> < #endif
> <
> < #ifdef __STDC__
> < double __ieee754_cosh(double x)
> < #else
> < double __ieee754_cosh(x)
> < double x;
> < #endif
> < {
> ---
>> static class Cosh {
>> private static final double one = 1.0, half=0.5, huge = 1.0e300;
>> private static double compute(double x) {
> 108c87
> < unsigned lx;
> ---
>> /*unsigned*/ int lx;
> 119c98
> < t = expm1(fabs(x));
> ---
>> t = expm1(Math.abs(x));
> 127c106
> < t = __ieee754_exp(fabs(x));
> ---
>> t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 132c111
> < if (ix < 0x40862E42) return half*__ieee754_exp(fabs(x));
> ---
>> if (ix < 0x40862E42) return half*StrictMath.exp(Math.abs(x));
>> // TODO switch to translit
> 135c114
> < lx = *( (((*(unsigned*))>>29)) + (unsigned*));
> ---
>> lx = __LO(x);
> 137,138c116,117
> < ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> < w = __ieee754_exp(half*fabs(x));
> ---
>> ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d)
>> <= 0))) {
>> w = StrictMath.exp(half*Math.abs(x)); // TODO switch to
>> translit
> 146c125,127
> < /* Tanh(x)
> ---
>> }
>>
>> /**
> 169,184c150,152
> <
> < #include "fdlibm.h"
> <
> < #ifdef __STDC__
> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
> < #else
> < static double one=1.0, two=2.0, tiny = 1.0e-300;
> < #endif
> <
> < #ifdef __STDC__
> < double tanh(double x)
> < #else
> < double tanh(x)
> < double x;
> < #endif
> < {
> ---
>> static class Tanh {
>> private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>> static double compute(double x) {
> 203c171
> < t = expm1(two*fabs(x));
> ---
>> t = expm1(two*Math.abs(x));
> 206c174
> < t = expm1(-two*fabs(x));
> ---
>> t = expm1(-two*Math.abs(x));
> 214a183
>> }
>
>
> Note that the original has a in-line version of the "__LO" macro rather than
> using the macro.
>
>
> And transliteration vs more idiomatic:
>
>
> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java
> 21c21
> < private static double compute(double x) {
> ---
>> static double compute(double x) {
> 26c26
> < /* High word of |x|. */
> ---
>> // High word of |x|
> 28c28
> < ix = jx&0x7fff;
> ---
>> ix = jx & 0x7fff_;
> 30,31c30,33
> < /* x is INF or NaN */
> < if(ix>=0x7ff0) return x+x;
> ---
>> // x is INF or NaN
>> if ( ix >= 0x7ff0_) {
>> return x + x;
>> }
> 34,40c36,48
> < if (jx<0) h = -h;
> < /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
> < if (ix <
Re: RFR: JDK-8301444: Port fdlibm hyperbolic transcendental functions to Java [v8]
> Initial pass of porting FDLIBM sinh/cosh/tanh to Java. I do intend to
> refactor the regression tests a bit to reduce duplication, but the actual
> ports should be ready for review.
>
> Diff'ing the ports as before, original vs transliteration port:
>
>
> $ diff -w Hyperbolic.c Hyperbolic.translit.java
> 1c1
> < /* __ieee754_sinh(x)
> ---
>> /**
> 17a18,19
>> static class Sinh {
>> private static final double one = 1.0, shuge = 1.0e307;
> 19,33c21
> < #include "fdlibm.h"
> <
> < #ifdef __STDC__
> < static const double one = 1.0, shuge = 1.0e307;
> < #else
> < static double one = 1.0, shuge = 1.0e307;
> < #endif
> <
> < #ifdef __STDC__
> < double __ieee754_sinh(double x)
> < #else
> < double __ieee754_sinh(x)
> < double x;
> < #endif
> < {
> ---
>> private static double compute(double x) {
> 36c24
> < unsigned lx;
> ---
>> /* unsigned */ int lx;
> 51c39
> < t = expm1(fabs(x));
> ---
>> t = FdlibmTranslit.expm1(Math.abs(x));
> 57c45
> < if (ix < 0x40862E42) return h*__ieee754_exp(fabs(x));
> ---
>> if (ix < 0x40862E42) return h*StrictMath.exp(Math.abs(x)); //
>> TODO switch to translit
> 60,62c48,52
> < lx = *( (((*(unsigned*))>>29)) + (unsigned*));
> < if (ix<0x408633CE ||
> ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> < w = __ieee754_exp(0.5*fabs(x));
> ---
>> // lx = *( (((*(unsigned*))>>29)) + (unsigned*));
>> // lx = (((*(unsigned*))>>29)) + (unsigned*) ;
>> lx = __LO(x);
>> if (ix<0x408633CE ||
>> ((ix==0x408633ce)&&(Long.compareUnsigned(lx, 0x8fb9f87d) <= 0 ))) {
>> w = StrictMath.exp(0.5*Math.abs(x)); // TODO switch to
>> translit
> 70c60,62
> < /* __ieee754_cosh(x)
> ---
>> }
>>
>> /**
> 90,105c82,84
> <
> < #include "fdlibm.h"
> <
> < #ifdef __STDC__
> < static const double one = 1.0, half=0.5, huge = 1.0e300;
> < #else
> < static double one = 1.0, half=0.5, huge = 1.0e300;
> < #endif
> <
> < #ifdef __STDC__
> < double __ieee754_cosh(double x)
> < #else
> < double __ieee754_cosh(x)
> < double x;
> < #endif
> < {
> ---
>> static class Cosh {
>> private static final double one = 1.0, half=0.5, huge = 1.0e300;
>> private static double compute(double x) {
> 108c87
> < unsigned lx;
> ---
>> /*unsigned*/ int lx;
> 119c98
> < t = expm1(fabs(x));
> ---
>> t = expm1(Math.abs(x));
> 127c106
> < t = __ieee754_exp(fabs(x));
> ---
>> t = StrictMath.exp(Math.abs(x)); // TODO switch to translit
> 132c111
> < if (ix < 0x40862E42) return half*__ieee754_exp(fabs(x));
> ---
>> if (ix < 0x40862E42) return half*StrictMath.exp(Math.abs(x));
>> // TODO switch to translit
> 135c114
> < lx = *( (((*(unsigned*))>>29)) + (unsigned*));
> ---
>> lx = __LO(x);
> 137,138c116,117
> < ((ix==0x408633ce)&&(lx<=(unsigned)0x8fb9f87d))) {
> < w = __ieee754_exp(half*fabs(x));
> ---
>> ((ix==0x408633ce)&&(Integer.compareUnsigned(lx, 0x8fb9f87d)
>> <= 0))) {
>> w = StrictMath.exp(half*Math.abs(x)); // TODO switch to
>> translit
> 146c125,127
> < /* Tanh(x)
> ---
>> }
>>
>> /**
> 169,184c150,152
> <
> < #include "fdlibm.h"
> <
> < #ifdef __STDC__
> < static const double one=1.0, two=2.0, tiny = 1.0e-300;
> < #else
> < static double one=1.0, two=2.0, tiny = 1.0e-300;
> < #endif
> <
> < #ifdef __STDC__
> < double tanh(double x)
> < #else
> < double tanh(x)
> < double x;
> < #endif
> < {
> ---
>> static class Tanh {
>> private static final double one=1.0, two=2.0, tiny = 1.0e-300;
>> static double compute(double x) {
> 203c171
> < t = expm1(two*fabs(x));
> ---
>> t = expm1(two*Math.abs(x));
> 206c174
> < t = expm1(-two*fabs(x));
> ---
>> t = expm1(-two*Math.abs(x));
> 214a183
>> }
>
>
> Note that the original has a in-line version of the "__LO" macro rather than
> using the macro.
>
>
> And transliteration vs more idiomatic:
>
>
> $ diff -w Hyperbolic.translit.java Hyperbolic.fdlibm.java
> 21c21
> < private static double compute(double x) {
> ---
>> static double compute(double x) {
> 26c26
> < /* High word of |x|. */
> ---
>> // High word of |x|
> 28c28
> < ix = jx&0x7fff;
> ---
>> ix = jx & 0x7fff_;
> 30,31c30,33
> < /* x is INF or NaN */
> < if(ix>=0x7ff0) return x+x;
> ---
>> // x is INF or NaN
>> if ( ix >= 0x7ff0_) {
>> return x + x;
>> }
> 34,40c36,48
> < if (jx<0) h = -h;
> < /* |x| in [0,22], return sign(x)*0.5*(E+E/(E+1))) */
> < if (ix <
Re: RFR: 8301627: System.exit and Runtime.exit debug logging
On Fri, 10 Feb 2023 20:33:39 GMT, Roger Riggs wrote: > It can be difficult to find the cause of calls to > `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java > runtime exits. > The status value and stack trace are logged using the System Logger named > `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`. test/jdk/java/lang/runtime/RuntimeExitLogTest.java line 89: > 87: } > 88: cmd.add(this.getClass().getName()); > 89: cmd.add(Integer.toString(status)); Another possibility for testing this is to launch with ` --limit-modules java.base -Djdk.system.logger.level=DEBUG` to use the simple console implementation that is in java.base and avoid needing properties files for j.u.logging. Just mentioning is an option to make it simple. - PR: https://git.openjdk.org/jdk/pull/12517
Re: RFR: 8301627: System.exit and Runtime.exit debug logging
On Fri, 10 Feb 2023 20:33:39 GMT, Roger Riggs wrote:
> It can be difficult to find the cause of calls to
> `java.lang.System.exit(status)` and `Runtime.exit(status)` because the Java
> runtime exits.
> The status value and stack trace are logged using the System Logger named
> `java.lang.Runtime` with message level `System.Logger.Level.DEBUG`.
src/java.base/share/classes/java/lang/Shutdown.java line 162:
> 160: * If the system logger {@code java.lang.Runtime} is enabled for
> logging level DEBUG/FINE
> 161: * the stack trace of the call to {@code Runtime.exit()} or {@code
> System.exit()}
> 162: * is logged.
Shutdown is not a public class so this impNote won't appear in the APIs docs.
Should it move to Runtime.exit and System.exit? If it moved to a public API
then "system logger" could link to System.Logger. Also would it be more correct
to say "a system logger named "java.lang.Runtime" is enabled for logging levels
DEBUG or FINE"?
-
PR: https://git.openjdk.org/jdk/pull/12517
Integrated: JDK-8301833: Add wide-ranging tests for FDLIBM porting
On Mon, 6 Feb 2023 01:50:55 GMT, Joe Darcy wrote: > To help add assurances that the main-line port of FDLIBM to Java is working > correctly, added some long-running manual tests to probe that the > transliteration port and the corresponding StrictMath method are in agreement > on a large number of argument, say, all float values. > > To test the transliteration port, this test can be run against a build where > the JDK has *not* had the FDLIBM code used for StrictMath ported to Java. This pull request has now been integrated. Changeset: 8049e59a Author:Joe Darcy URL: https://git.openjdk.org/jdk/commit/8049e59a5c5ab5bd2055face6df02445859335ca Stats: 169 lines in 1 file changed: 169 ins; 0 del; 0 mod 8301833: Add wide-ranging tests for FDLIBM porting Reviewed-by: bpb, alanb - PR: https://git.openjdk.org/jdk/pull/12430
Re: RFR: 8298619: java/io/File/GetXSpace.java is failing
On Fri, 10 Feb 2023 17:10:46 GMT, Brian Burkhalter wrote: > Another possibility would be to add a native method to the test itself to > invoke > [GetDiskSpaceInformationW](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-getdiskspaceinformationw) > to obtain the value of `CallerTotalAllocationUnits` (in bytes) from the > [DISK_SPACE_INFORMATION](https://learn.microsoft.com/en-us/windows/win32/api/fileapi/ns-fileapi-disk_space_information) > structure. That would be more reliable than parsing the output of `fsutil volume` so worth trying. You might have to dig into which of these win32 works with quotas as that seems to be part of the issue. The JDK uses GetDiskFreeSpaceExW. Also this test might have to do a few iterations so that it captures free space info while the system is in quiescence - I suspect some of the reliability issues has been concurrent activity that changes the volume space usage significantly while this test is running. - PR: https://git.openjdk.org/jdk/pull/12397
Re: RFR: 8300819: -Dfile.encoding=Cp943C option does not work as expected since jdk18 [v2]
On Sun, 22 Jan 2023 23:17:10 GMT, Ichiroh Takiguchi
wrote:
>> On jdk17, following testcase works fine on Linux platform.
>>
>> Testcase
>>
>> $ cat cstest1.java
>> import java.nio.charset.*;
>>
>> public class cstest1 {
>> public static void main(String[] args) throws Exception {
>> Charset cs = Charset.defaultCharset();
>> System.out.println(cs + ", " + cs.getClass() + ", " +
>> cs.getClass().getModule());
>> }
>> }
>>
>>
>> $ ~/jdk-17.0.6+10/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "17.0.6" 2023-01-17
>> OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10)
>> OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode,
>> sharing)
>> x-IBM943C, class sun.nio.cs.ext.IBM943C, module jdk.charsets
>>
>>
>> But it does not work as expected on jdk18 and jdk21b06
>>
>> $ ~/jdk-18.0.2.1+1/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "18.0.2.1" 2022-08-18
>> OpenJDK Runtime Environment Temurin-18.0.2.1+1 (build 18.0.2.1+1)
>> OpenJDK 64-Bit Server VM Temurin-18.0.2.1+1 (build 18.0.2.1+1, mixed mode,
>> sharing)
>> UTF-8, class sun.nio.cs.UTF_8, module java.base
>> $ ~/jdk-21/bin/java -Dfile.encoding=Cp943C -showversion cstest1
>> openjdk version "21-ea" 2023-09-19
>> OpenJDK Runtime Environment (build 21-ea+6-365)
>> OpenJDK 64-Bit Server VM (build 21-ea+6-365, mixed mode, sharing)
>> UTF-8, class sun.nio.cs.UTF_8, module java.base
>>
>>
>> Fixed result is as follows:
>>
>> $ java -Dfile.encoding=Cp943C -showversion PrintDefaultCharset
>> openjdk version "21-internal" 2023-09-19
>> OpenJDK Runtime Environment (build 21-internal-adhoc.jdktest.jdk)
>> OpenJDK 64-Bit Server VM (build 21-internal-adhoc.jdktest.jdk, mixed mode,
>> sharing)
>> x-IBM943C
>
> Ichiroh Takiguchi has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8300819: -Dfile.encoding=Cp943C option does not work as expected since jdk18
I think this PR can be closed as the default charset must be in java.base.
-
PR: https://git.openjdk.org/jdk/pull/12132
Re: RFR: JDK-8301833: Add wide-ranging tests for FDLIBM porting [v3]
On Sat, 11 Feb 2023 03:04:51 GMT, Joe Darcy wrote: >> To help add assurances that the main-line port of FDLIBM to Java is working >> correctly, added some long-running manual tests to probe that the >> transliteration port and the corresponding StrictMath method are in >> agreement on a large number of argument, say, all float values. >> >> To test the transliteration port, this test can be run against a build where >> the JDK has *not* had the FDLIBM code used for StrictMath ported to Java. > > Joe Darcy has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains six additional commits since > the last revision: > > - Include log testing. > - Merge branch 'master' into JDK-8301833 > - Update test. > - Merge branch 'master' into JDK-8301833 > - Added trailing line terminator. > - JDK-8301833: Add manual tests for FDLIBM porting The move to make this an automated tests and test every 1024th float is good. - Marked as reviewed by alanb (Reviewer). PR: https://git.openjdk.org/jdk/pull/12430
