This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch for Review: JvGetStringUTF and JvTempCString
- From: Mohan Embar <gnustuff at thisiscool dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: Bryce McKinlay <bryce at mckinlay dot net dot nz>, tromey at redhat dot com, java-patches at gcc dot gnu dot org
- Date: Tue, 12 Aug 2003 12:49:41 -0500
- Subject: Re: Patch for Review: JvGetStringUTF and JvTempCString
- Reply-to: gnustuff at thisiscool dot com
Hi Andrew,
> > 1. So are we okay with the approach where:
> >
> > - the helper class allocates 256 bytes on the stack and tries to cram
> > the string in there if it fits
>
>Up to 256 bytes; don't allocate memory that you won't use.
How would I parameterize the 256 in this class? (I'm sure you wouldn't
want to make this a template class....)
------------------------------8<----------------------------------------
class _Jv_TempUTFString
{
public:
_Jv_TempUTFString(jstring jstr);
~_Jv_TempUTFString();
// Accessors
operator const char*() const
{
return buf_;
}
const char* buf() const
{
return buf_;
}
char* buf()
{
return buf_;
}
private:
char* buf_;
char stackbuf_[256];
};
------------------------------8<----------------------------------------
> > 2. Shall I try to run some crude timings so see whether _Jv_Malloc() or
> > _Jv_AllocBytes() is a faster?
>
>It might be interesting, but it isn't very important.
My gut feeling is to avoid _Jv_AllocBytes() in order to avoid the
extra GC bookkeeping. Bryce brought up the issues about thread-local
allocation, but this might be less critical because the stack-allocated
buffer will presumably handle the majority of cases in the library
code where this class is intended to be used.
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/