That option results some changes in the floating point math (see http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options...) which Java is unable to set, but which may be okay for limited domain the DSP filter works in.
Java has an absolutely horrible floating point support. See http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf
Java code can thus never (in the current language spec) take advantage of vector instructions etc. While in raw integer performance Java might come near native code whenever you use floats Java is going to always lose.
The sad part here is that the decisions made on Java do not even save the programmer from the evils of floating point math. They just cripple the language.
As for the horrible floating point support, are there other factors than lack of signaling NaNs, being unable to set rounding mode and exception policy, floats using floats for intermediate results?
For many purposes such flaws don't seem that bad.
Why is Java code unable to use vector instructions? I guess there's something in the Java spec that prevent compilers from using them, but what is it? I think that the 80-bit floats the Intel FPU offers are used in Java by default unless a method is defined as strictfp, but this a different issue.
The second is that the a decent JVM i.e. not Dalvik do generate vector instruction streams.
I actually think that java code in the next 4 years will start to be much faster than equivalent C code, due to HSAIL and Graals potential to involve GPUs and specialized floating point hardware in an otherwise normal program.