This is the mail archive of the
mailing list for the Java project.
RE: Hash synchronization (PR 16662) patch
- From: "Boehm, Hans" <hans dot boehm at hp dot com>
- To: "'Bryce McKinlay'" <mckinlay at redhat dot com>,"Boehm, Hans" <hans dot boehm at hp dot com>
- Cc: "'java-patches at gcc dot gnu dot org'" <java-patches at gcc dot gnu dot org>
- Date: Thu, 12 Aug 2004 16:35:43 -0700
- Subject: RE: Hash synchronization (PR 16662) patch
Thanks for your comments. Responses are below.
> From: Bryce McKinlay [mailto:email@example.com]
> Boehm, Hans wrote:
> >I checked the patch from
> http://gcc.gnu.org/ml/java/2004-08/msg00047.html into the trunk.
> >As part of this effort, I resurrected the Heap profiling
> patch from http://gcc.gnu.org/ml/java/2004-03/msg00222.html
> which is still in my tree. After some earlier discussion,
> I'm still confused as to whether I need permission to check
> this in. Could someone resolve the ambiguity by approving that patch?
> This looks pretty cool. However, I think it would be nice to
> avoid the
> #ifdefs - ie instead of choosing the allocation function at
> compile time
> with LIBGCJ_GC_DEBUG, it would be nicer to provide a runtime argument
> that switches between the normal & debug allocation
> functions. Perhaps
> _Jv_InitGC could set up a table of the allocation functions
> depending on
> what value is set during runtime startup. Is this practical?
I agree that it would be MUCH nicer. And I'm still thinking about it.
But there are a couple of issues standing in the way:
1) I don't know how to do it without adding an indirect call to
every allocation, even in the non-debug case. I think I'm not willing
to pay that price. (Its cost is highly micro-architecture specific,
largely depending on whether you have a sufficiently large
branch target buffer. The details depend on what, if anything,
we do about calling the GC allocation routines directly If an
indirection ends up being part of that solution, perhaps this
problem will disappear.)
2) The generic GC source uses different calling conventions for
debug and regular allocation, so that it can pass the call location
to the debug version for platforms without proper stack unwind
support. This probably isn't a big issue for gcj, and I'm debating
whether to make it disappear in GC 7.0, so that
you could at least just replace GC libraries. (There are
already debug allocation calls that fake the extra arguments.)
Assuming we stick with the compile-time flag for now, is
--enable-full-debug the right way to turn this on? That was inherited
from the GC configury.
> Also, regarding the duplication of _Jv_AllocObj etc - I
> presume there is
> some hairy reason why we can't just include gc_gcj.h in libjava's
I don't fully remember the reasoning. But including gc_gcj.h
includes gc.h, which redefines some pthread_ calls etc. And I think
the renamed boehm-gc.h is effectively included all over the place.
Thus I suspect it would probably cause problems, and probably did
when I first decided to do it this way. The current solution keeps
gc.h out of nearly all of the libgcj source files, which has something
going for it.
> By the way, I'm planning to import the GC 6.3 distribution shortly.
That's interesting news. If that's going to happen shortly enough,
I should postpone this check-in. I believe all of the GC changes are
already in 6.3.
I'm currently a bit behind on contributed GC patches (still recovering
from my vacation), but I don't recall seeing anything disastrous for 6.3.
The bottom line is that I would still like to check this for now,
although I agree that we should work towards a runtime flag, if the