Re: Patch for Review: JvGetStringUTF and JvTempCString

[Bryce McKinlay <bryce at mckinlay dot net dot nz>]

On Sunday, Aug 10, 2003, at 16:16 Pacific/Auckland, Mohan Embar wrote:

> Hi Bryce,
>
> Thanks for looking at this.
>
> > Sorry if I missed earlier discussion on this. What is the rationale 
> > for
> > adding these?
>
> Check out java/io/natFilePosix.cc. Incessantly repeated lines like 
> this:
>
>   char *buf = (char *) __builtin_alloca (JvGetStringUTFLength (path) + 
> 1);
>   jsize total = JvGetStringUTFRegion (path, 0, path->length(), buf);
>   buf[total] = '\0';
>
> ...which were also present in the Win32 implementation, were driving
> me nuts.

OK, point taken.

In this case (natFile*), I think there is a better approach. Since the 
path of a given File object never changes, we can cache the path in UTF 
format when each File object is constructed. This way if there are 
multiple calls to the same file object (presumably a common case), we 
don't keep converting over and over. See attached patch (setUtfpath 
could just as well be implemented in Java code, though the native 
version is probably a little more efficient).

I do agree that we need a string-conversion solution for CNI that is 
simpler to use than what we have now. But we need to think carefully 
about what is the most simple and useful way to do it - once people 
start to use these functions there is no going back! Its also worth 
remembering that the stack-allocation tricks we use in libgcj are a 
special case because in these places we are willing to sacrifice a 
little simplicity for efficiency - but realistically, most people want 
ease of use more than absolute efficiency, so might be happy with a 
function returning, say, a malloc() or GC allocated, null-terminated 
char *.

> It's also worth noting that not everyone knows about 
> __builtin_alloca() and its
> proper usage. Do a search on _Jv_Free in nat*.cc and see what you get.

I'm afraid I might have been partially responsible for that mess. In 
hindsight, most (if not all) of the code using _Jv_Malloc/_Jv_Free 
should really be using GC allocation (eg JvAllocBytes).

Regards

Bryce.

Attachment: File.patch.txt
Description: Text document