Eugene Kuleshov wrote:
In my subjective tests, the StackMap calculation overhead is much
higher then performance gain you'll get from the new verifier. This is
actually by design of the new verifier, so pre-verification step when
StackMap is generated runs off line and can take long, but
Rémi Forax wrote:
I use ASM that is able to generate StackMap using flag |COMPUTE_FRAMES|
when creating a ClassWriter.
The algorithme used by ASM is described here:
http://asm.objectweb.org/doc/developer-guide.html#controlflow
Unlike JRuby, I don't generate code at runtime so
I have no
On Sep 3, 5:11 am, Rémi Forax [EMAIL PROTECTED] wrote:
Eugene, even if you generate StackMap 'by hand', there is a problem if
there is a resizing (GOTO = GOTO_W),
because StackMap attribute can't be updated incrementally.
In that case, ASM reparse the whole byte-code with COMPUTE_FRAMES
On Sep 3, 3:21 am, Charles Oliver Nutter [EMAIL PROTECTED]
wrote:
So if I follow you correctly, COMPUTE_FRAMES should not be used for
runtime code unless we're willing to swallow it being much more costly
than just allowing the normal verification process to handle that code
at runtime.
Eugene Kuleshov wrote:
Correct. However it is just my observation and it may also depend on
what methods are being analyzed. I've been testing computation of
StackMap when transforming all classes from rt.jar, and on my machine,
with Java 6, it takes ~2.5 extra seconds to compute frames for
Charles Oliver Nutter a écrit :
Eugene Kuleshov wrote:
In my subjective tests, the StackMap calculation overhead is much
higher then performance gain you'll get from the new verifier. This is
actually by design of the new verifier, so pre-verification step when
StackMap is generated
Charles Oliver Nutter a écrit :
Rémi Forax wrote:
I have seen an impressive boost by generating StackMap infos,
particularly when generated codes use overlaped exception handlers.
Can you describe how to do that and exactly what it is? I'm not familiar
with it.
Java 1.6
