Is it possible to set a block of code as non-JIT area?

[jacksu]

For the rest of the code, I would like the JIT to do the magic, but
for certain portion of the java code, I would make it untouched by the
JIT.

I am using IBM websphere 5.0.2, with JDK1.3.1_08

Thanks

 

[John C. Bollinger]

For the rest of the code, I would like the JIT to do the magic, but
for certain portion of the java code, I would make it untouched by the
JIT.

Why?

The answer is academic, I think, because although there might be a way
to disable JIT globally, there is no way to disable it only for specific
sections of code. JIT is outside the scope of the Java and bytecode
languages -- they have no way to express instructions about it. So what
is the goal underlying your inquiry?


John Bollinger
(e-mail address removed)

 

[Tor Iver Wilhelmsen]

For the rest of the code, I would like the JIT to do the magic, but
for certain portion of the java code, I would make it untouched by the
JIT.

Translation: I know (better than the makers of Hotspot) what portions
of my code should be machine-translated and which should be
interpreted.

The only way to do this is to write your own JVM implementation.
Presumably you need a compiler extension as well, e.g.

public void foo() {

{ /** @pragma interpreted */
int i = 42;
System.out.println(i);
}
}

 

[Chris Uppal]

For the rest of the code, I would like the JIT to do the magic, but
for certain portion of the java code, I would make it untouched by the
JIT.

Since there's no mention of the JITer in either the Java standard or the JVM
standard (i.e. the use of a JIT, or any alternative technology is purely an
implementation detail) there can be no standard way of doing that. Any such
feature would be provided by the /specific/ implementation of the JVM that you
are using. Perhaps as a runtime -XX option that specified a file containing a
list of methods that should/should not be optimised.

It's not an inherently silly thing to want, but I don't know of any JVM
implementation that provides it -- probably because there's little need for it
in general.

If you really /need/ to avoid the space/time costs of compiling some chunks of
bytecode (and don't want to implement your own JVM) then you could always write
a small interpreter (in Java) and embed that, plus the stuff you want it to
interpret, into your program. If you go that route then I'd advise against
using the JVM bytecode set as the target for your interpreter -- it is
complicated and not particularly compact.

-- chris

 

[jacksu]

Why?

The answer is academic, I think, because although there might be a way
to disable JIT globally, there is no way to disable it only for specific
sections of code. JIT is outside the scope of the Java and bytecode
languages -- they have no way to express instructions about it. So what
is the goal underlying your inquiry?


John Bollinger
(e-mail address removed)

Actually our application crashes at one point, and that point has been
obsuficated. We think disable JIT on that portion of code may help.

 

[jacksu]

Translation: I know (better than the makers of Hotspot) what portions
of my code should be machine-translated and which should be
interpreted.

The only way to do this is to write your own JVM implementation.
Presumably you need a compiler extension as well, e.g.

public void foo() {

{ /** @pragma interpreted */
int i = 42;
System.out.println(i);
}
}

Thanks for reply. That sounds challenging. Do you have any tutorial to do that?

Thanks again

 

[jacksu]

Since there's no mention of the JITer in either the Java standard or the JVM
standard (i.e. the use of a JIT, or any alternative technology is purely an
implementation detail) there can be no standard way of doing that. Any such
feature would be provided by the /specific/ implementation of the JVM that you
are using. Perhaps as a runtime -XX option that specified a file containing a
list of methods that should/should not be optimised.

It's not an inherently silly thing to want, but I don't know of any JVM
implementation that provides it -- probably because there's little need for it
in general.

If you really /need/ to avoid the space/time costs of compiling some chunks of
bytecode (and don't want to implement your own JVM) then you could always write
a small interpreter (in Java) and embed that, plus the stuff you want it to
interpret, into your program. If you go that route then I'd advise against
using the JVM bytecode set as the target for your interpreter -- it is
complicated and not particularly compact.

-- chris

Thanks, do you have some example on that?

 

[John C. Bollinger]

Actually our application crashes at one point, and that point has been
obsuficated. We think disable JIT on that portion of code may help.

Although it is conceivable that you have hit a JIT bug, it is far more
likely that your code is buggy (perhaps made so by the obfuscator). If
the obfuscated and non-obfuscated codes produce different behavior then
your obfuscator is broken, in which case the solution is to either
abandon obfuscation or get a better obfuscator. If they produce the
same behavior then the obfuscation is not relevant.


John Bollinger
(e-mail address removed)

 

[Samuel Penn]

Standard Sun JVM does this. We had a problem in 1.3 with hotspot
causing an infinite loop in one class, and Sun recommended disabling
hotspot on that class. There's a file you can stick directives in
to tell hotspot how to behave. I can't remember how we did it, but
a google of "prevent hotspot compiling of class" finds the following:

http://jguru.com/faq/view.jsp?EID=710838

Which sounds similar to what we did.

 

[Chris Uppal]

Standard Sun JVM does this. We had a problem in 1.3 with hotspot
causing an infinite loop in one class, and Sun recommended disabling
hotspot on that class.

Ah! That's the first I'd heard of that. Thank you for the pointer.

Googling for "hotspot_compiler" turns up more information.

-- chris