This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Lost patch / performance improvement
- From: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- To: "Boehm, Hans" <hans_boehm at hp dot com>
- Cc: "'java-patches at gcc dot gnu dot org'" <java-patches at gcc dot gnu dot org>, "'tromey at redhat dot com'" <tromey at redhat dot com>
- Date: Sun, 18 Nov 2001 23:16:57 +1300
- Subject: Re: Lost patch / performance improvement
- References: <40700B4C02ABD5119F000090278766443BECFA@hplex1.hpl.hp.com>
Boehm, Hans wrote:
>This piece of the parallel GC patch for the trunk appears to have gotten
>lost, probably because I forgot to send it to Tom earlier. Without this
>patch, not many things are likely to take advantage of thread local
>allocation buffers. Thus I suspect it makes a significant performance
>difference, especially on multiprocessors. I have been running with this in
>a modified tree for a long time. If someone could verify that this works in
>the current unmodified tree (on a Linux platform where THREAD_LOCAL_ALLOC is
>set), and approve it, I can check it in.
>
>(I won't claim it's beautiful. If someone can think of a way to clean this
>up while preserving inlining, I'd be very interested.)
>
Is there a reason why we shouldn't enable thread local alloc by default?
Also, wouldn't it make sense for the GC to define GC_gcj_malloc etc to
mean GC_gcj_local_malloc automatically if THREAD_LOCAL_ALLOC is
supported/defined?
regards
Bryce.