Any chance you're using any JNI libraries in your JVM implementation? I recently became aware that gcc-compiled libraries with -ffast-math and friends can result in subnormal values doing unexpected things, causing inconsistent/incorrect results for some well defined operations. Unfortunately that flag can cause gcc to emit x86 assembly that makes global changes to how a process interacts with these numbers.
https://moyix.blogspot.com/2022/09/someones-been-messing-with-my-subnormals.html It appears that Java 22+ has mitigation for this, by testing in at least some cases if these features have been used and then attempting to restore the expected state for Java: https://github.com/openjdk/jdk/commit/df599dbb9b0f0ee96d1ec767ac8821f164ab075d https://bugs.openjdk.org/browse/JDK-8295159 My read is that this is technically incomplete, since it only happens at loadLibrary() time, and technically any call into JNI could re-set these flags. On Monday, May 12, 2025 at 10:50:08 AM UTC-5 Jens wrote: > It is really weird that your results do not match. Prior Java 17 the > "strictfp" keyword could be used to force the JVM to not cheat a little. > But since Java 17 it is the default and the keyword does nothing anymore ( > https://openjdk.org/jeps/306). So the results should be portable now. > > In case you are using DoubleSummaryStatistics in your code, GWT emulation > uses Kahan summation to compensate for rounding errors but I think Java > uses the same algorithm. However JavaDoc of > DoubleSummaryStatistics.getSum() leaves room to have different > implementations and error compensations. It explicitly says that the output > may vary for the same input. > > -- J. > > Craig Mitchell schrieb am Montag, 12. Mai 2025 um 15:45:15 UTC+2: > >> The results from GWTTestCase match JavaScript! >> >> It's rather slow though. Running the same test in these envs: >> >> - Java: 184ms. >> - JavaScript (Chrome): 3.5 seconds. >> - GWTTestCase: 5.8 minutes. >> >> >> On Wednesday, 30 April 2025 at 3:39:57 pm UTC+10 Craig Mitchell wrote: >> >>> > *I meant that IntelliJ run configuration for JUnit has an option >>> forkmode and I am pretty sure the maven plugin also has an option for JVM >>> forking. For example you can configure that every test method should run in >>> a forked VM in IntelliJ. By default it doesn't do that. * >>> >>> Ah, cool, thanks. I see that option now. >>> >>> [image: download.png] >>> >>> With it on, I get different results again. Different to maven, >>> different to no fork, and different to JavaScript. >>> >>> And if I run it through Maven with "mvn test -DforkCount=1 >>> -DreuseForks=false", I get results that are completely different again. >>> >>> They are still consistent though. Ie: Running it multiple times, always >>> gets the same results. >>> >>> On Tuesday, 29 April 2025 at 8:34:25 pm UTC+10 Jens wrote: >>> >>>> *> Maybe the result slightly changes if JVM decides to optimize a hot >>>> code path in case the JVM is reused. You might want to check how maven and >>>> your intellij run configuration are configured in terms of JVM forking.* >>>> >>>> IntelliJ seems to add the options: >>>> -Dkotlinx.coroutines.debug.enable.creation.stack.trace=false >>>> -Ddebugger.agent.enable.coroutines=true >>>> -Dkotlinx.coroutines.debug.enable.flows.stack.trace=true >>>> -Dkotlinx.coroutines.debug.enable.mutable.state.flows.stack.trace=true >>>> -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 >>>> -Dsun.stderr.encoding=UTF-8 >>>> >>>> So I added those to MAVEN_OPTS, but it didn't seem to make any >>>> difference. I also tried adding @NotThreadSafe to my test suite, >>>> again no difference. >>>> >>>> >>>> I meant that IntelliJ run configuration for JUnit has an option >>>> forkmode and I am pretty sure the maven plugin also has an option for JVM >>>> forking. For example you can configure that every test method should run >>>> in >>>> a forked VM in IntelliJ. By default it doesn't do that. >>>> >>>> -- J. >>>> >>> -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/google-web-toolkit/131b4a25-7bb4-4d7e-864e-d390a4fab153n%40googlegroups.com.
