Re: Memory Problems with String
[email protected] Fri, 06 Oct 2006 16:46:47 -0400
| Newsgroups | gmane.comp.mozilla.jrex |
|---|---|
| Message-ID | <[email protected]> |
This seems like a good change, but it's not yet in CVS. Is Medappa still out there? --Chris Henry Chan wrote: > This issue is caused by the following files: > JRex/src/native/JRexHeaderVisitorImpl.cpp > JRex/src/native/JRexStreamListener.cpp > JRex/src/native/JRex_JNI_ProgressEvent.cpp > > Originally, > Find NewStringUTF in those files > > For example, the code in JRexHeaderVisitorImpl like > > env->CallObjectMethod(mHashTableObj,JRexHeaderVisitor::hashTablePutMID, > env->NewStringUTF(headerChar),env->NewStringUTF(valueChar)); > > Change it to > > jstring key = env->NewStringUTF(headerChar); > jstring value = env->NewStringUTF(valueChar); > env->CallObjectMethod(mHashTableObj,JRexHeaderVisitor::hashTablePutMID,key,value); > env->DeleteLocalRef(key); > env->DeleteLocalRef(value); > > The string needs to be deleted the local reference, so the JVM can remove > reference properly. > > > > "Ken" <[email protected]> wrote in message > news:loom.20060907T173927-344-eS7Uydv5nfiQYT8SWwsb6uG/[email protected] >> Hello all, >> >> I notice a large number of string objects are accumulated when JRex >> navigating >> to different pages. My profiling information points to >> xpcomInitImpl$1.run() >> as the source of the allocations. >> >> The uncollected strings seem to be http headers information. They have >> values >> including, "Content-Length", "text/html", and etc. >> >> Has anyone encounters this similar problem? >> >> Could it possible there are caching options I need to set in JRex? Or >> something I am not using correctly in JRex? >> >> I used one of the sample testers in the existing postings. It is included >> at >> the end of this post. After each page is loaded, the number of string >> objects >> will increase from xpcomInitImpl$1.run() without garbage collected, until >> the >> tester is terminated. >> >> Thanks for taking your times reading my questions. Please let me know if >> there is more information I can provide. >> >> Thanks, >> Ken >>