On Thu, 10 Feb 2011 15:32:39 +0100 Dodji Seketeli <do...@redhat.com> wrote:
> Joern Rennecke <joern.renne...@embecosm.com> writes: > > > Quoting Tom Tromey <tro...@redhat.com>: > > > >>>>>>> "Basile" == Basile Starynkevitch <bas...@starynkevitch.net> writes: > >> > >> Basile> So I need to understand who is writing the 0x101 in that field. > > > > > >> One thing to watch out for is that the memory can be recycled. I've > >> been very confused whenever I've forgotten this. I have a hack for the > >> GC (appended -- ancient enough that it probably won't apply) that makes > >> it easy to notice when an object you are interested in is collected. > >> IIRC I apply this before the first run, call ggc_watch_object for the > >> thing I am interested in, and then see in what GC cycle the real one is > >> allocated. > > > > If what you are looking for survives such a change, postponing garbage > > collection so it won't happen till the crash can make things simpler. > > For the sake of archiving these tricks how do you postpone garbage > collection in practise? > BTW, postponing garbage collection is completely inpossible for me (at the most, I could disable it in the gdb debugger, but not in real MELT runs), since the GC (I mean the ggc_collect() routine) is called at arbitrary moments by the MELT runtime (it is called from the MELT garbage collector, routine melt_garbcoll(), which takes the appropriate measures -together with the MELT translator- to do that safely.) Thanks for all the help. I did find out what was wrong: it was my (incorrect) understanding of get_loop_body. I thought (incorrectly) that it returned a GTY-ed pointer. In my opinion, that function has a bizarre property: it returns a calloc-ed array of basic_block-s, which are themselves GTY-ed (that is managed by the Ggc collector with the help of GTY annotations for gengtype). What I find bizarre, is that get_loop_body returns a manually managed memory data chunk (an array, actually) of Ggc-ed pointers (as every one guess, I do like the idea of a garbage collector, and my insane wish is that GCC would have much more GTY-ed data. I do know that this mine position is against the majority). I would find much more logical (or at least more elegant to my eyes) if get_loop_body returned (for instance) a GTY-ed vector [or any other GTY ((variable)) thing] of loop-s pointers. Strangely, it doesn't! In MELT parlance, I cannot simply make a MELT primitive which invokes get_loop_body. It has to be interfaced by a MELT function which builds a MELT tuple of MELT boxed basic_block-s. Now, this function needs support from the MELT runtime to permit mutation of MELT boxed basic_block-s. So I had to generate the meltgc_basicblock_updatebox in file gcc/meltrunsup.h [that file is MELT generated. MELT is now able to generate all the boxing, upboxing, hashmapping... of any GTY-ed ctypes]. So I had to improve the MELT generator (file melt/warmelt-outobj.melt) to do that generation of updatebox routines. Once the generated code was better, I could commit it (using git) to the MELT branch. Now, I have to merge the latest trunk into the MELT branch, but since I switched to git, I am very scared to do that, and I am not sure to understand the reliable procedure to do so. (I was able to merge once the trunk into MELT using git, but that was with the kind help of Andreas Schwab and Dodji Seketeli, and I am not sure to have understood all..). Some of my uses of git (on GCC & MELT) gives me bizarre (hence scary) messages. I am really ashamed to be a git newbie. I am sort of able to use it on some (own, non GCC) code, but I am very scared of messing GCC with git and I use it on GCC MELT with fear. Regards. -- Basile STARYNKEVITCH http://starynkevitch.net/Basile/ email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 8, rue de la Faiencerie, 92340 Bourg La Reine, France *** opinions {are only mine, sont seulement les miennes} ***
