public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
From: "BGB" <cr88192@hotmail.com>
To: "abhishek desai" <abhi00@gmail.com>, 	<java@gcc.gnu.org>
Subject: Re: problem when mapping malloc to GC_malloc.
Date: Thu, 18 Jun 2009 18:07:00 -0000	[thread overview]
Message-ID: <BLU0-SMTP3080FB7F0F4F7A0EF27D2CE43D0@phx.gbl> (raw)
In-Reply-To: <898285d30906180800q3b5bd3b2h1d4a11d6a8245e34@mail.gmail.com>


----- Original Message ----- 
From: "abhishek desai" <abhi00@gmail.com>
To: <java@gcc.gnu.org>
Sent: Thursday, June 18, 2009 8:00 AM
Subject: problem when mapping malloc to GC_malloc.


> 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);
> }
>

IMO, this is a very bad way to try to use a GC, and that it is blowing up 
when something like this is tried is no real surprise...

(very likely you will end up with code calling GC_malloc in some places, and 
the real malloc in others, and in-all creating a horrible mess...).


a much better (although IMO still not very good) way to do this would be to 
instead use macros to rename your functions:
#define malloc(x) GC_malloc(x)
...

which will apply locally to whatever code is in question (and, if used with 
caution, should resist blowing up...).


however, my personal recommendation is to NOT use a GC implicitly in this 
way, rather one should make use of the GC explicit (AKA: actually go and 
rename their function calls, and keep track of how they use pointers so that 
GC memory and malloc memory don't get mixed up, ...).


>
> regards
> abhishek
> 

      parent reply	other threads:[~2009-06-18 18:07 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
2009-06-18 19:01     ` BGB
2009-06-18 18:07 ` BGB [this message]

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=BLU0-SMTP3080FB7F0F4F7A0EF27D2CE43D0@phx.gbl \
    --to=cr88192@hotmail.com \
    --cc=abhi00@gmail.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).