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


On Tuesday, Aug 12, 2003, at 11:26 Pacific/Auckland, Mohan Embar wrote:

Hi Tom & Bryce,

So maybe Mohan's class isn't needed after all...

Like I said here:


http://gcc.gnu.org/ml/java-patches/2003-q3/msg00311.html

These three lines of code:

char *buf = (char *) __builtin_alloca (JvGetStringUTFLength (path) + 1);
jsize total = JvGetStringUTFRegion (path, 0, path->length(), buf);
buf[total] = '\0';


...are like fingernails on a blackboard for me, and they're not
limited to just natFile*.cc. I like the idea of encapsulating this
by a class and doing any necessary cleanup in the destructor.

I totally agree that we have a problem here, I just wonder if this is the right solution. Two things that would make me like this better:


1. Can it be made to allocate only the space that it needs on the stack? Always allocating 500 bytes seems a bit wasteful. I wonder about large stack allocations since they will reduce the locality of the stack - increasing the chance of cache misses etc.

2. Can we use _Jv_AllocBytes rather than _Jv_Malloc/_Jv_Free in the need-to-allocate case? The former is *faster* given thread local allocation, possibly so even after accounting for the GC's marking overhead.

Regards

Bryce.



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