Zero/ARM

[Gary Benson]

Edward Nevill wrote:
> > I finally got a chance to look at this today.  I don't have ARM
> > hardware so I can't try it, but I've been looking at the sources
> > to see how it all hooks in.
> 
> If you need some ARM hardware I am going on holiday from Weds of
> next week so could lend you one of my boards for 3 weeks.
> 
> Alternatively, I could make arrangements for you to access the
> boards on my desk remotely - but that won'cput help you if you
> need to reset them.

Thanks for the offer, but I'll decline.  If you say it works then
I believe you.  I see too many people saying how hard it is to
build on ARM, and I don't fancy sharing the pain ;)

> > I have to say I'm a little confused by how it relates to Zero.
> > I see that you have asm method entries for everything that Zero
> > has a method entry for, and looking at the symbols the assembly
> > code references it doesn't seem to call back into any Zero code.
> > So it seems that the only bit of Zero it uses is the call stub.
> > Am I right?
> 
> Hmmm. Yes, possibly. I hadn't realised how little of Zero it still
> depends on. It started depending on a lot more when I only optimised
> bytecodeInterpreter.cpp, but as I moved to optimising the entry
> points (normal_entry and then native_entry) it grew less and less.
> 
> Here are the pieces of Zero I believe it still uses.
> 
> - It uses the Zero stack.

You're probably taking a performance hit for that.  I presume your
assembly is setting up native frames for the methods?  You could
extend that to allocate things that you need in the native frames.
You'd have to rewrite the stack walker though, and you'd use the
ability to use Shark.

BTW, Shark, you're using the same calling convention as Zero right?
ie methods have three arguments: methodOop, base_pc, thread?  If so,
then Shark should work unmodified assuming your interpreter counts
method calls.  You'd probably have to tweak the deoptimization code
to jump to your normal entry rather than the C++ interpreter's, but
that's all.

> - It uses Zero in all the cases it cannot support IE
> 	UseCompiler == true
> 	TaggedStackInterpreter == true
> 	JvmtiExport::can_post_interpreter_events == true

Zero doesn't support TaggedStackInterpreter either.

> - It uses 'ffi' to do native calls, so relies on stuff in
> interpreterRT_zero.cpp to do the signature parsing.

You're probably taking a performance hit on this too, especially
for GUI code (which has a lot of native calls back to GTK or whatever
else is implementing it all).  The original signature parser is
supposed to return a block of native code that converts the arguments
from the Java calling convention (ie the top of the Zero stack) to
the native one.  Have a look at the x86 and SPARC ones to see what
they do.

Cheers,
Gary

-- 
http://gbenson.net/