java - Do C++ objects in Android JNI native code invoke garbage collection? -

so, i've got conceptual question. i've been working jni on android purposes of doing low-level audio "stuff." i've done plenty of audio coding in c/c++, figured not of problem. decided use c++ in "native" code (because doesn't love oop?). issue i've encountered seems (to me) strange one: when create object processing audio in c++ code, , never pass object java (nor other way around), calling methods on object seems invoke garbage collection quite often. since happening inside audio callbacks, result stuttering audio, , frequent messages along lines of:

wait_for_concurrent_gc blocked 23ms 

however, when perform same operations creating static functions (rather invoking member methods on memeber object) performance of app seems fine, , no longer see above log message.

basically, there reason calling static function should have better performance calling member methods on member object in native code? more specifically, member objects, or limited scope variables live entirely inside native code of jni project involved in garbage collection? c++ call stack involved in gc? there insight can give me on how c++ memory management meets java memory management when comes jni programming? is, in case i'm not passing data between java , c++, way write c++ code affect java memory management (gc or otherwise)?

allow me try give example. bear me, 'cause it's freaking long, , if think have insight you're welcome stop reading here.

i have couple of objects. 1 responsible creating audio engine, initializing output, etc. called helloaudiojni (sorry not putting compile-able examples, there's lot of code).

class chelloaudiojni {      ... omitted members ...      //member object pointers     coscillator *osc;     cwaveshaper *waveshaper;      ... etc ...  public:     //some methods     void init(float fs, int buffersize, int channels);      ... blah blah blah ... 

it follows have couple more classes. waveshaper class looks this:

class cwaveshaper : public caudiofilter { protected:     double *coeffs;     unsigned int order;//order public:     cwaveshaper(const double samplerate, const unsigned int numchannels,                 double *coefficients, const unsigned int order);      double processsample(double input, unsigned int channel);     void reset(); }; 

let's not worry caudiofilter class now, since example quite long. waveshaper .cpp file looks this:

cwaveshaper::cwaveshaper(const double samplerate,                          const unsigned int numchannels,                          double *coefficients,                          const unsigned int numcoeffs) :     caudiofilter(samplerate,numchannels), coeffs(coefficients), order(numcoeffs) {}  double cwaveshaper::processsample(double input, unsigned int channel) {     double output = 0;     double pow = input;      //zeroth order polynomial:     output = pow * coeffs[0];      //each additional iteration     for(int iteration = 1; iteration < order; iteration++){         pow *= input;         output += pow * coeffs[iteration];     }      return output; }  void cwaveshaper::reset() {} 

and there's helloaudiojni.cpp. meat of issue. create member objects properly, using new inside init function, thusly:

void chelloaudiojni::init(float samplerate, int buffersize, int channels) {     ... omitted initialization code ...          //wave shaper numero uno     double coefficients[2] = {1.0/2.0, 3.0/2.0};     waveshaper = new cwaveshaper(fs,outchannels,coefficients,2);      ... more omitted code ... } 

ok seems fine far. inside audio callback call member methods on member object so:

void chelloaudiojni::processoutputbuffer() {     //compute audio using coscillator object     for(int index = 0; index < outputbuffer.bufferlen; index++){         for(int channel = 0; channel < outputbuffer.numchannels; channel++){             double sample;              //synthesize             sample = osc->computesample(channel);             //wave-shape             sample = waveshaper->processsample(sample,channel);              //convert fxp , save output buffer             short int outputsample = amplitude * sample * float_to_short;             outputbuffer.buffer[interleaveindex(index,channel)] = outputsample;         }     } } 

this produces frequent audio interruptions , lots of messages garbage collection. however, if copy cwaveshaper::processsample() function helloaudiojni.cpp above callback , call directly instead of member function:

sample = waveshape(sample, coeff, 2); 

then beautiful beautiful audio coming out of android device , not such frequent messages garbage collection. once again questions are, are member objects, or limited scope variables live entirely inside native code of jni project involved in garbage collection? c++ call stack involved in gc? there insight can give me on how c++ memory management meets java memory management when comes jni programming? is, in case i'm not passing data between java , c++, way write c++ code affect java memory management (gc or otherwise)?

there no relationship between c++ objects , dalvik's garbage collection. dalvik has no interest in contents of native heap, other own internal storage. objects created java sources live on "managed" heap, garbage collection takes place.

the dalvik gc not examine native stack; each thread known vm has separate stack interpreter use.

the way c++ , managed objects related if choose create relationship pairing objects in way (e.g. creating new managed object c++ constructor, or deleting native object java finalizer).

you can use "allocation tracker" feature of ddms / adt see most-recently created objects on managed heap, , being allocated. if run during gc flurry should able tell what's causing it.

also, logcat messages show process , thread ids (from command line use, adb logcat -v threadtime), should check make sure messages coming app, , see thread gc activity occurring on. can see thread names in "threads" tab in ddms / adt.