problem when mapping malloc to GC_malloc.
abhishek desai
abhi00@gmail.com
Thu Jun 18 18:18:00 GMT 2009
On Thu, Jun 18, 2009 at 10:09 PM, Hans Boehm<Hans.Boehm@hp.com> wrote:
>
>
> On Thu, 18 Jun 2009, abhishek desai wrote:
>
>> Hi,
>>
>> My JNI code includes redefinitions to the malloc, free and realloc
>> functions (shown below). These functions call GC_malloc, GC_free and
>> GC_realloc respectively. This is done so that any calls to the malloc
>> get allocated through the garbage collector. However this is failing
>> with segfault. Any clues why this does not work ?
>> I am using this code along with the libgcj library linked dynamically
>> with my application.
>>
>> void *malloc(size_t size)
>> {
>> return GC_malloc(size);
>> }
>>
>> void *realloc(void *ptr, size_t size)
>> {
>> return GC_realloc(ptr, size);
>> }
>>
>> void free(void *ptr)
>> {
>> GC_free(ptr);
>> }
>>
>>
>> regards
>> abhishek
>>
> The collector itself supports a REDIRECT_MALLOC option that might get you
> closer. In general, this is very hard.
>
> There are other functions (calloc, memalign, etc.) that you would also have
> to replace, so that their clients don't end up using the original malloc
> with GC_free. This is the easy part.
>
> The hard part is that if you replace malloc, low level parts of the system
> will also end up using GC_malloc, and sometimes squirrel away pointers to
> the results in places the GC doesn't really know about. Recent versions of
> the GC (7.1+) contains some hacks to try to handle this on Linux. But the
> multithreaded versions still are sometimes not 100% robust. Gcj's version
> is unlikely to work in this mode, except possibly in single-threaded mode.
>
> A real fix here would probably require some new hooks in glibc and the
> startup and libpthread code.
>
> Hans
>
>if you replace malloc, low level parts of the system
> will also end up using GC_malloc
This is what I am trying to achieve but this is turning out to be a tough task.
Some more background here. I am using the gcc version 3.4.6 and the
libgcj associated with it. I know its ancient but the project demands
it. Cant help it. I am compiling for a mipsel architecture using
uclibc. There are a lot of calls to malloc through the libgcj library
or possibly in the other libraries used by libgcj. The calls to malloc
happen even before the main function begins.
uclibc implementation of memory management (malloc, realloc) relies on
mmap and sbrk to get memory which is also used by the gc for the same
purpose. So is not possible to use the gc instead of the uclibc memory
manager ? Which areas could be causing the problem ? Even if low level
parts of the system make calls to GC_malloc how does it affect the
over all behavior ?
--Abhishek
More information about the Java
mailing list