Yes, JIT mode and interpreter mode are different in class resolution strategy.
Here how it works: With interpreter class resolution is initiated when the class is actually needed: object of the class is created, a static field or a static method is invoked. This is the same as SUN behaviour. (AFAIK they use interpreter too) With JIT we have eager resolution today: all classes referred in a method (and all inlined methods!) are resolved during compilation time. AFAIK BEA works this way too. At least, I can write tests that demonstrate it. If a method has multiple references to a class and its resolution fails JIT asks again an again to resolve it. Moreover, if exception happened in classloader - it can be lost. Now I'm working on Lazy Resolution task and going to submit it to JIRA right after JavaOne is finished (there are a lot of changes and regressions are possible). After it's done JIT will be able to work in either eager or lazy mode. And I hope most of the resolution related bugs will gone after it. BTW did you tried the same scenario with BEA? On 4/21/07, Ivan Popov <[EMAIL PROTECTED]> wrote:
Yes, in interpreter mode step works fine. I don't see second attempt to load class in classloader trace while step is performed. Is it possible that in JIT mode first invocation of a method of already loaded class may lead to compilation and attempt to load this class second time? Thanks. Ivan On 4/20/07, Eugene Ostrovsky <[EMAIL PROTECTED]> wrote: > BTW everything works fine with harmony VM in interpreter mode (-Xint option) > > On 4/20/07, Tim Ellison <[EMAIL PROTECTED]> wrote: > > > > Ivan Popov wrote: > > > Thanks, Mikhail, It might be useful, but I dont know how to specify > > > options for VM running Scrapbook code, it is started automatically. > > > > Select the jpage page file and choose the properties option from the > > context menu (Alt+Enter), in there you can find a 'Scrapbook Runtime' > > page where you can specify the VM and options etc it will use. > > > > Tim > > > > >
-- Mikhail Fursov
