Re: Avoid function call with JVMPI enabled

[Bryce McKinlay <mckinlay at redhat dot com>]

OK, I wasn't aware that JVMPI had been deprecated. In that case, and if 
there arn't any good tools for it anyway, then we should probably just 
rip the current implementation out. Anyone have objections to this?

So, as a general policy, if these profilling/debug features are useful, 
particularly to applications/users, then we should allow them to be 
switched on at runtime. If they arn't useful and arn't likely to be 
useful then we should just rip them out in order to reduce the 
maintainance burden.

Considering the BC-ABI, it would complicate things to have the compiler 
pass a size argument to the allocation function, because that size may 
change at runtime. Another issue is that the circumstances where the 
compiler can call AllocObjectNoFinalizer are fewer, because a finalizer 
could be added at runtime. I think the GC could implement the allocation 
functions directly, but it would have to at least #include some headers 
from libjava so that it can load this info from the class object that it 
gets passed.

Regarding the cost of indirect calls to the allocator - in my experience 
from benchmarking indirect-dispatch, in the presence of PIC, an indirect 
call where the table containing the function pointer is a static local 
actually turns out to be significantly cheaper than an ordinary call to 
a public function, because the PLT indirection can be avoided. The PLT 
jump seems to disrupt modern processors far more than the indirect load. 
So, for the shared library case, at least, there might actually be a win 
to indirect the calls even if the compiler doesn't call into the GC 
directly. This would certainly simplify the implementation.

Regards

Bryce


Boehm, Hans wrote:

> [Moved from the java-patches list.]
>
> In principal, I agree with the goal of allowing profiling and debugging to
> be enabled dynamically.  And I certainly also agree
> that we should stop calling the java.lang.Object constructor.
>
> I agree that the JVMPI support should stay in the source.  But I'm
> still not sure that having it enabled by default is important, unless there are
> more/better clients than I know about.
>
> In particular:
>
> - Sun always considered it "experimental".
>
> - In my opinion, at least the allocation part of it wasn't that well designed.
> Sun appears to also have run into trouble with it on HotSpot.
>
> - It's deprecated in 1.5, and slated to disappear in 1.6 (http://java.sun.com/developer/technicalArticles/Programming/jvmpitransition/)
> (Whether it's reasonable for us to implement JVMTI, the replacement, is unclear.
> This is also an area where it's not clear to me whether our emphasis should
> be on following Java standards here, or to make standard Linux tools work
> well with Java.)
>  
>
> - Having it there costs us performance, and possibly hides some other
> optimization possibilities.
>
> Having said all of that, it may still make sense to redesign the
> performance critical part of the allocation interface so that we always make
> an indirect call, but that call normally goes directly to a GC routine.
> That might often be faster than what we do now.  If we go this route,
> it may not hurt to keep JVMPI enabled, since the overhead disappears.
> And it would get us closer to being able to turn on GC_DEBUG
> functionality dynamically.
>
> This would require passing a vtable pointer and size to the new
> version of _Jv_AllocObjectNoFinalizer instead of a class pointer,
> so that it could be implemented directly by GC_gcj_malloc.  This would also
> expose the size and vtable loads to the optimizer, where they
> could often be moved out of loops or replaced by constants.
>
> Should we move in this direction?
>
> Hans
>
>  
>
> > -----Original Message-----
> > From: Bryce McKinlay [mailto:mckinlay@redhat.com]
> > Sent: Monday, August 23, 2004 7:20 PM
> > To: Boehm, Hans
> > Cc: 'java-patches@gcc.gnu.org'
> > Subject: Re: Avoid function call with JVMPI enabled
> >
> >
> > I agree that disabling the GC here looks pretty bogus, 
> > perhaps we could 
> > just have the allocation code aquire its own lock in the JVMPI case.
> >
> > JVMPI is probably only marginally useful right now. I'd like 
> > to keep the 
> > code around, though, hopefully someone might improve it in 
> > the future. 
> > Conceptually speaking, I'd like to have profiling and debug features 
> > compiled in by default, so that they can be enabled by 
> > runtime flags. In 
> > the long run, any any extra overhead of having them compiled in by 
> > default ought to be amortized by improvements that can be 
> > made elsewhere 
> > in the runtime (and applications) thanks to having easier access to 
> > these features.
> >
> > On the subject of improving allocation performance, I noticed 
> > that the 
> > compiler always emits code to call the (empty) java.lang.Object 
> > constructor. Thats probably always going to be redundant, since the 
> > allocation functions themselves can do Object initialization. So, we 
> > should be able to avoid another call here with a small change to the 
> > compiler.
> >