Apfloat versions 1.1 to 1.6 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
or vote for bug
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
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.
Bug reports, questions and comments should be sent to the author.