It's a bit dangerous to answer a question like this too specifically. It's going to depend on what kind of problem you're solving, what algorithms you use, how much effort you put into optimizing it, etc. My understanding is that modern LISP compilers can perform close to native code speeds, as can the JVM. Clojure compiles to Java bytecode, even when used dynamically (without compiling to disk ahead of time), so in most circumstances can match Java performance for the same algorithms. Clojure 1.3 alphas have improvements that make it easier to match Java speeds when dealing with primitive data types like longs and doubles. And of course if Clojure's concurrency constructs mean you can take advantage of multiple cores in situations where you couldn't (or wouldn't) in other languages, this can sometimes be a big win.
I think the simplest answer is that if Java would "fast enough" for a given task, Clojure can also be made "fast enough" for that task.
Sorry that doesn't answer your exact question, but I hope it helps.
Java 7 (if I'm not wrong) supports InvokeDynamic JSR.
How this will help Clojure to gain performance boost? and how?
JRuby team says that JRuby gets about 30% performance boost by running it on the next OpenJDK.
Does InvokeDynamic JSR allows to perform Tail call optimization?
My understanding is that InvokeDynamic won't help Clojure much if at all. Function calls and sufficiently hinted Java interop forms already compile to regular Java calls, so should already be faster than InvokeDynamic calls.
There is a separate proposal for tail call optimization which I believe is not currently planned for Java 7. Although TCO is common in LISPs and required by Scheme, Clojure isn't in desperate need of the feature as it has solutions for an overwhelming majority of situations where it might be required in other LISPs. The recur form, lazy seqs, trampoline and regular stack-consuming recursion together address nearly every practical recursion need. Still, it would be nice if the JVM were to fully solve the problem.