public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: law@redhat.com
To: Andrew MacLeod <amacleod@redhat.com>
Cc: gcc mailing list <gcc@gcc.gnu.org>
Subject: Re: [tree-ssa][ GC, Virtual operands, and GCing between passes
Date: Thu, 11 Dec 2003 19:30:00 -0000	[thread overview]
Message-ID: <200312111926.hBBJQTZR024715@speedy.slc.redhat.com> (raw)
In-Reply-To: Your message of "09 Dec 2003 14:35:22 EST." <1070998524.17667.2860.camel@p4>

In message <1070998524.17667.2860.camel@p4>, Andrew MacLeod writes:
 >
 >
 >Are we sure we want to GC between passes? :-|
Yes :-)


 >since VDEFs and VUSEs are tree nodes, I can't allocate the structure
 >which holds them anywhere except GC'd memory can I?
Huh?  Presumably turning them into tree nodes (they aren't currently
tree nodes) buys you something?

Certainly if they are tree nodes, then they need to be allocated by the
GC system and be reachable from GC roots.


 >struct v_operands_d *vops;
 >
 >struct v_operands_d {
 >  unsigned int num
 >  tree *vec;
 >}
 >
 >so I dont want the memory associated with either  'vops' or 'vec'
 >garbage collected, but I do want to keep around anything that
 >vec[0]..vec[num-1] points to.
 >
 >Thats not really going to work too well is it? At least I haven't been
 >able to do it.  So I'll have to keep ggcing the memory for the vops
 >structure?.
I don't think it's going to work.  I'd probably suggest you GC the whole
thing and if necessary, keep a free list of objects you can recycle.

In that kind of scheme, you'd expose the freelist of the GC system as well.

I guess what I really don't understand is why you're trying to not expose
stuff to the GC system.  Is it because we don't have a ggc_free?  Or is
it something else?

Jeff


  parent reply	other threads:[~2003-12-11 19:26 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-09 20:26 Andrew MacLeod
2003-12-09 23:43 ` Geoff Keating
2003-12-10  4:46   ` Andrew MacLeod
2003-12-11 17:01     ` Geoff Keating
2003-12-11 17:17       ` Andrew MacLeod
2003-12-11 21:15         ` Geoff Keating
2003-12-11 23:31           ` Andrew MacLeod
2003-12-15 22:05             ` Richard Henderson
2003-12-15 22:46               ` Andrew MacLeod
2003-12-11 19:30     ` law
2003-12-11 23:13       ` Andrew MacLeod
2003-12-12  0:21         ` law
2003-12-12  3:29           ` Andrew MacLeod
2003-12-12  5:24             ` law
2003-12-12 13:38               ` Andrew MacLeod
2003-12-13  6:52                 ` law
2003-12-11 14:17   ` Andrew MacLeod
2003-12-10  0:03 ` Jan Hubicka
2003-12-10  0:18   ` Andrew MacLeod
2003-12-10  0:38     ` Jan Hubicka
2003-12-11 19:30 ` law [this message]
2003-12-11 14:27 S. Bosscher
2003-12-11 14:34 ` Andrew MacLeod
2003-12-11 15:01   ` Andrew MacLeod

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=200312111926.hBBJQTZR024715@speedy.slc.redhat.com \
    --to=law@redhat.com \
    --cc=amacleod@redhat.com \
    --cc=gcc@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).