Known bugs and issues

Known bugs

• Apfloat versions 1.1 to 1.5 are supported only on Java 5 and later.
• Apfloat versions 1.0.x are supported only on Java 1.4.2 and later.
• Apfloat has been tested with Sun's JVM, Oracle JRockit JVM and IBM's JVM. Other vendors' (HP, Alpha, Mac, ...) JVMs have not been tested. They should work, however historically JVMs have been known to have bugs that may prevent some programs from running.

Other known issues

• If there are temporary files (*.ap) left on your disk after running an apfloat program, it may be because they can't be deleted in garbage collection. Some JVMs have specific options that must be specified so that a "full" GC is really done when you call System.gc(), for example with JRockit this flag is -XXfullsystemgc and with IBM's VM it's -Xcompactexplicitgc. If you're using Sun's VM you may want to send Sun some feedback regarding bug 4715154 or vote for bug 4171239 or RFE 4724038.
• If you have more than 1.5 GB of memory and you're running 32-bit Microsoft Windows, you may run into all kinds of strange problems trying to perform calculations with extreme precision.
  • First, you can't have a heap bigger than about 1.5 GB.
  • If you set your heap to 1 GB (use -Xmx1G) or more, running out of address space may cause further problems. Disk I/O requires mapping files to logical memory addresses. If the maximum heap size plus the maximum apfloat temporary file size exceeds 1.5 GB you may get a java.io.IOException: Not enough storage is available to process this command.
  • 32-bit Linux may have similar problems.
  • The only good solution is probably to get a 64-bit processor and 64-bit operating system.
• If you set your heap to e.g. 1280MB and try to do a 1 GB calculation, it may fail with an OutOfMemoryError when the number should be stored in memory. This can happen because of the heap memory arrangement. The details depend on the garbage collection algorithm used but often the heap is divided to two "generations" (new and old) and a memory array can only be allocated from one of these. If the "new generation" is big you won't be able to actually allocate the whole heap for a single memory array. The solution is to specify a smaller "new generation" size, e.g. with -Xmn8M or use a different garbage collection algorithm e.g. with -Xincgc.
• Apfloat can't autodetect CPU cache sizes. To have this feature added to Java, you can try to send Sun some feedback on RFE 4942707.
• Apfloat versions 1.0 and 1.0.1 perform slightly better than later versions when using the 32-bit integer version and certain CPUs, such as Intel Pentium 3, AMD Athlon and AMD Athlon 64. With these CPUs, you can get up to a 10% performance increase by putting this intpatch.jar file in the classpath before apfloat.jar. Note that later versions of apfloat perform slightly better with other CPUs like Intel Pentium 4, without this patch.