This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch for Review: JvGetStringUTF and JvTempCString


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/





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]