This is the mail archive of the java@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: Two quick GC questions [was Re: [REVIVED: PATCH PR42811,4.5 regression] java.lang.ExceptionInInitializerError in ecj1]


On 18/02/2010 22:05, Boehm, Hans wrote:
>> From: Dave Korn

>> Well, it turns out to be fairly straightforward: there is no code to
>> register the .data and .bss sections of the main executable as static
>> data regions with the GC, so it has no idea there's a live pointer to an
>> object(*) in there, and happily frees it up.

>> 1- There's no call to GC_INIT anywhere under libjava/, and I can't find
>> anything in boehm.cc that even looks suitable for the purpose.  Does
>> anyone know how the main exe's data/bss sections are supposed to get
>> registered on a posixy system?

> The GC normally does that internally, whether or not GC_INIT is called.
> GC_init_inner() does not need to get called, but the collector tries to do
> that automatically when it can, though IIRC gcj should call
> GC_init()directly, possibly not through the GC_INIT() macro.
> 
> In the simplest case, GC_init_inner calls GC_register_data_segments.  In
> other cases, GC_register_dynamic_libraries does it, and
> GC_register_main_static_data() returns false, avoiding the call the
> GC_register_data_segments.

  Thanks Hans, I think I've got it now.  The cygwin target ends up using the
generic GC_register_data_segments() implementation, which registers the minmax
range of the data and bss segments.  That did the job when cygwin was only
able to use libjava statically linked and everything was ending up in one
monolithic executable, but now we can build a shared libjava it only registers
the static data areas in the libgcj DLL, naturally.

  There's no definition for GC_register_dynamic_libraries at all, either, it
uses the empty definition that defines GC_no_dynamic_loading.  I could either
adapt the "parse /proc/self/maps file" strategy, or try making the win32 stuff
work; either way, it'll have to take care of registering the main exe's data
sections - which I guess is how things probably end up working on *nix hosts
too, when they parse the maps file.

>> 2- Libgcj statically links its own personal private copy of boehm-gc,
>> rather than using a shared library; does anyone know why it was designed
>> this way?
> Way back when, it needed a custon GC configuration.  But those options have
> generally become runtime configurable, so I suspect that's no longer true,
> though it may need to make some initialization calls to get the right
> configuration.

  Ah.  Well, when I'm building libjava as two separate sublibraries, I now
have the problem that each gets its own separate copy of the GC; that's
obviously liable to be disastrous.

  One solution would be to build a single shared GC library for them both to
reference, but I don't know what I'd have to do to get the runtime config correct.

  Another alternative would be to export the GC functions from the main libgcj
dll, for the benefit of the libgcj-noncore dll.  That's a little ugly because
we don't really want to expose those APIs to the user, but they shouldn't be
linking anything against them anyway, so we could just call it a private
interface between the two dlls and not worry about breaking binary
compatibility (or even removing altogether it in favour of an external shared
lib gc) in future.  This would probably be a safer change this close to the
release of 4.5.0, so unless any of the java maintainers have a fundamental
objection or can see a serious flaw in the suggestion, I'll go ahead and
prepare a patch that resolves the clash that way.

    cheers,
      DaveK


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