Re: Avoid function call with JVMPI enabled

[Bryce McKinlay <mckinlay at redhat dot com>]

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
> >
> >