From: abhishek desai <abhi00@gmail.com>
To: Hans Boehm <Hans.Boehm@hp.com>
Cc: "java@gcc.gnu.org" <java@gcc.gnu.org>
Subject: Re: problem when mapping malloc to GC_malloc.
Date: Thu, 18 Jun 2009 18:18:00 -0000 [thread overview]
Message-ID: <898285d30906181118q9f35066i209e0d58c26f65c5@mail.gmail.com> (raw)
In-Reply-To: <alpine.LNX.1.10.0906180927340.1207@192.168.2.2>
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
next prev parent reply other threads:[~2009-06-18 18:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-18 15:00 abhishek desai
2009-06-18 15:14 ` Christian Nolte
2009-06-18 16:30 ` Hans Boehm
2009-06-18 18:18 ` abhishek desai [this message]
2009-06-18 19:01 ` BGB
2009-06-18 18:07 ` BGB
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=898285d30906181118q9f35066i209e0d58c26f65c5@mail.gmail.com \
--to=abhi00@gmail.com \
--cc=Hans.Boehm@hp.com \
--cc=java@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).