Avoid function call with JVMPI enabled

Boehm, Hans hans.boehm@hp.com
Tue Aug 24 17:54:00 GMT 2004


[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.
> 
> Regards
> 
> Bryce
> 
> 
> Boehm, Hans wrote:
> 
> >Doesn't it make sense to turn this off by default?  Even checking
> >a global flag here adds overhead.  And the JVMPI implementation,
> >at least for allocation, is currently pretty bogus.
> >
> >I looked at the JVMPI spec again.  It does require that GC 
> be disabled
> >during the call-back for an allocation.  But I think its notion of 
> >having the GC disabled really corresponds to acquiring and holding
> >the allocation lock, not causing the collector to expand the heap
> >when it would otherwise collect.  We currently do the latter, which
> >is bound to result in unbounded heap growth eventually.  (The spec
> >seems unclear about this, though it's an important distinction.
> >It's not clear either solution is acceptable, but they fail very
> >differently.)
> >
> >Even if this were all fixed, it seems to me that the JVMPI allocation
> >interface has enough inherent overhead that I wouldn't trust 
> a profiled
> >app to behave anything like the original, especially since we just
> >added a heavily contended lock.  Maybe this won't affect allocation
> >behavior for most apps.  But that's not at all clear.  It can
> >certainly slow things down tremendously.
> >
> >Hans
> >
> >  
> >
> >>-----Original Message-----
> >>From: java-patches-owner@gcc.gnu.org
> >>[mailto:java-patches-owner@gcc.gnu.org]On Behalf Of Bryce McKinlay
> >>Sent: Monday, August 23, 2004 2:31 PM
> >>To: Boehm, Hans
> >>Cc: 'java-patches@gcc.gnu.org'
> >>Subject: FYI: Avoid function call with JVMPI enabled
> >>
> >>
> >>Boehm, Hans wrote:
> >>    
> >>
> >>>I always build with JVMPI disabled, since it does bad things
> >>>to the allocation sequence.  (It adds a third (!) function call
> >>>to every allocation call.  Unless of course you actually turn
> >>>it on, in which case it's MUCH worse.)
> >>> 
> >>>
> >>>      
> >>>
> >>I hadn't noticed this previously. It turns out that the test 
> >>to check if 
> >>JVMPI is enabled was not being inlined before calling 
> >>jvmpi_notify_alloc. This patch fixes this by doing the test 
> >>in a macro. 
> >>The macro ensures that the jvmpi_notify_alloc call is not 
> made unless 
> >>JVMPI is actually enabled.
> >>I'm checking this in.
> >>Bryce
> >>
> >>    
> >>
> 



More information about the Java mailing list