Thanks all. I'm not using DoubleSummaryStatistics or any JNI.
One thing I noticed when I was logging my calcs, trying to compare the
differences between Java and JavaScript, I would sometimes get -0.0 for a
double.
Turns out there is a difference between 0.0 and -0.0, but (I think) only
when using Double, not double (which I have in a few places). Ie:
*In Java:*
Double a = 0.0;
Double b = -0.0;
if (a == b) System.out.println("yes");
else System.out.println("no");
Prints "no".
*While in GWT:*
Double a = 0.0;
Double b = -0.0;
if (a == b) GWT.log("yes");
else GWT.log("no");
Prints "yes".
I'll now remove all "Double"s from my code and see if that fixes it.
Fingers crossed!
On Tuesday, 13 May 2025 at 5:13:31 am UTC+10 Colin Alworth wrote:
> 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/86394de3-ad5c-4aa0-b20d-c46f7f803b35n%40googlegroups.com.
