On 5/24/05, Steve Blackburn <[EMAIL PROTECTED]> wrote:
> Dmitry Serebrennikov wrote:
>
>
> > * The meat of the VM seems to be in the "spokes" that connect to the
> > "VM core-hub". It seems that this is where it would make the most
> > sense to mix components written in C with those written in Java, to
> > see which one can do a better job. If all spokes were in C, it would
> > make little sense to have the hub be in Java... On the other hand if
> > spokes are all Java, it makes little sense to have the hub be in C.
> >
> > Steve, if the spokes were in Java but the hub in C, would we then lose
> > all of the aggressive inlining benefits that Java-in-Java solution can
> > provide?
>
> I don't know. These are really interesting questions and ones I think
> we need to hear lots of informed opinion on. My experience with mixing
> C & Java inside the VM is limited to the interface to the MM. The
> inlining issue is key there because of the fine grain at which those
> interactions occur.
The inlining issue keeps coming up. It needs to be discussed. The
way I see it, the issue breaks down into a) inlining app code inside
of app code, b) inlining inside one VM module, c) inlining between two
VM modules and d) inlining VM code in the app code.
a)
Inlining app code inside of app code is basically orthogonal to the
language used to write a JIT. Heck, a JIT could be written in
assembly or Visual Basic that inlines the app code it compiles.
b)
A GC written in C++ can inline stuff inside the GC module without
problems. Also, a JIT written in Java/C# can inline parts of itself
with no problems.
c)
It probably does not make a lot of sense to worry about inlining
between two VM modules until we get the initial Harmony VM up and we
can conduct performance analysis. For example, inlining the
classloader into the JIT may not provide any performance gains. The
downside of over aggressive inlining is code bloat which can impact
instruction cache performance and startup times.
d)
I suspect that inlining GC write barriers and allocation sequences in
the binary image emitted by the JIT is basically orthogonal to the
languages chosen to implement the JIT and GC modules. Regardless what
language is used for developing the GC, an inlinable "bump the
pointer" allocation sequence can always quickly be written in Java
source code, Java byte code or even the JIT's IR (internal
representation). The same applies to the write barrier.
I would like to see a list of between module inlining candiates that
are known to cause a performance problems. In ORP we routinely loaded
the JIT and GC as *.dll/so. I don't recall observing compelling
dll-to-dll inlining opportunities. Otherwise we would have trashed
the dll/so and gone back to static linking the entire VM.
Thanks
Weldon
Scheduling, compilation and classloading are very
> much coarser grained, so those issues are much less critical there...
>
> Cheers,
>
> --Steve
>
