This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch for Review: _Jv_TempUTFString + JV_TEMP_UTF_STRING
- From: Mohan Embar <gnustuff at thisiscool dot com>
- To: Tom Tromey <tromey at redhat dot com>, Andrew Haley <aph at redhat dot com>
- Cc: Bryce McKinlay <bryce at mckinlay dot net dot nz>, GCJ Patches <java-patches at gcc dot gnu dot org>
- Date: Mon, 18 Aug 2003 05:06:27 -0500
- Subject: Re: Patch for Review: _Jv_TempUTFString + JV_TEMP_UTF_STRING
- Reply-to: gnustuff at thisiscool dot com
Hi People,
>I disagree, because the gain of not using the garbage collector is
>fairly small, and it's quite possible that if we work on the gc the
>difference will be even smaller.
>
>But yes, this thing isn't worth arguing about right now.
Sorry to cause trouble again.
I agree that this isn't worth splitting hairs about, but may I ask
one last thing before we put this thing to bed?
Given that:
- my crude tests indicate that using the garbage collector for these cases
appears slower on both platforms (~17% slower on Windows):
http://gcc.gnu.org/ml/java-patches/2003-q3/msg00392.html
- the kind of allocations done by this class / macro have no
need for the GC
- this is all nicely encapsulated by a class + macro anyway
- people like have hinted at unsubstantiated GC problems
on Win32 that additional allocations could exacerbate
...what would be the harm in committing my _Jv_Malloc() version
as-is and then switching to a _Jv_AllocBytes() version later on?
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/