Some issues with boxed stuff (e.g. edges) kept in globals or heap...
4 views
Skip to first unread message
Basile Starynkevitch
Aug 29, 2014, 12:29:55 PM8/29/14
to gcc-...@googlegroups.com
Hello All,
This is to explain an issue (which I already met in the past and cannot avoid today) related to boxed stuff kept in MELT globals on in the heap
(e.g. kept indirectly accessible from the :ggcpass_data field of some of our passes).
I tried to explain the same issue from the GCC point of view in https://gcc.gnu.org/ml/gcc/2014-08/msg00313.html but I am explaining it again
from a MELT point of view here.
The sad fact is that current GCC compilers (e.g. 4.7, 4.8, 4.9 and perhaps future 5.0) are -unfortunately- forcibly deleting some GTY-ed stuff. In other words, the low-level ggc_free routine
can be and is actually called outside of ggc_collect (i.e. outside of MELT and GCC garbage collection). My biased opinion is that the GCC compiler is wrong in forcibly deleting data handled by its garbage collector (IMHO, their deletion should only happen inside ggc_collect; if that was the case we won't have any issues!).
This inpacts MELT (and any other GCC plugins having their own GTY-ed static data), because some "badly coded" MELT extensions could sometimes crash the GCC compiler (with a SIGSEGV).
If your MELT heap (or, for other GCC plugins, if their GTY-ed data - perhaps even the Python plugin for GCC) indirectly points to some stuff (like edge-s, tree-s, etc...) and if that data
outlive many GCC passes (e.g. because it is indirectly accessible from some global data, inside a closure registered with at_exit_first or from some registered MELT pass of a subclass of CLASS_GCC_PASS, ...) then you could crash the GCC compiler.
The scenario is the following. You have some MELT pass which traverses GCC internal representations and put some of their stuff (e.g. some basic_block, edge, gimple, etc....), perhaps
by boxing them into a value (using e.g. the box or constant_box MELT macro) or putting them in some MELT hash-map (e.g. just
having some edge-map made with make_mapedge MELT primitive, which is quite natural to use). That stuff data stays "alive"
because it is reachable from MELT values (e.g. closures) or "global" variables (which you declared using defvar in MELT). But the GCC infrastructure has several cleanup functions and passes
(e.g. from cleanup_cfg or cleanup_tree_cfg inside GCC code) which would forcibly delete (calling ggc_free on them) your stuff kept in MELT.
In some cases, the workaround is surprisingly simple. For example, in my justcountipa MELT pass, in file melt/xtramelt-ana-simple.melt functions justcountipa_exec and justcountipa_docmd etc, near line 840, which is an IPA pass coded in MELT to count gimples and edges etc... all the sensitive stuff is indirectly in my singleton class_justcountipa_data and I have just one instance of it which is the gccpass_data slot of my current MELT pass. The workaround was surprisingly simple: add
(put_fields pass :gccpass_data ())
near the end of my justcountipa_exec function, which is the execute function of my new pass named "melt_justcountipa"; then the garbage collectors would have dismissed the reference to the deleted stuff.
There is no better solution for now (i.e. for MELT 1.1 plugin for GCC 4.9). Any more robust solution would require me to make some accepted significant patch inside GCC itself, and my feeling is that
most people in the GCC community want to get rid of ggc_collect (which IMHO would be a mistake, but I am in the minority believing that). So even in the best case future improvements would only be for GCC 5.0 and MELT plugin 1.2 or 1.3
Feel free to ask more if you need more information.
Regards.
PS. I hope to release MELT 1.1.2 (a bug-fixing release) in a few days
This is to explain an issue (which I already met in the past and cannot avoid today) related to boxed stuff kept in MELT globals on in the heap
(e.g. kept indirectly accessible from the :ggcpass_data field of some of our passes).
I tried to explain the same issue from the GCC point of view in https://gcc.gnu.org/ml/gcc/2014-08/msg00313.html but I am explaining it again
from a MELT point of view here.
The sad fact is that current GCC compilers (e.g. 4.7, 4.8, 4.9 and perhaps future 5.0) are -unfortunately- forcibly deleting some GTY-ed stuff. In other words, the low-level ggc_free routine
can be and is actually called outside of ggc_collect (i.e. outside of MELT and GCC garbage collection). My biased opinion is that the GCC compiler is wrong in forcibly deleting data handled by its garbage collector (IMHO, their deletion should only happen inside ggc_collect; if that was the case we won't have any issues!).
This inpacts MELT (and any other GCC plugins having their own GTY-ed static data), because some "badly coded" MELT extensions could sometimes crash the GCC compiler (with a SIGSEGV).
If your MELT heap (or, for other GCC plugins, if their GTY-ed data - perhaps even the Python plugin for GCC) indirectly points to some stuff (like edge-s, tree-s, etc...) and if that data
outlive many GCC passes (e.g. because it is indirectly accessible from some global data, inside a closure registered with at_exit_first or from some registered MELT pass of a subclass of CLASS_GCC_PASS, ...) then you could crash the GCC compiler.
The scenario is the following. You have some MELT pass which traverses GCC internal representations and put some of their stuff (e.g. some basic_block, edge, gimple, etc....), perhaps
by boxing them into a value (using e.g. the box or constant_box MELT macro) or putting them in some MELT hash-map (e.g. just
having some edge-map made with make_mapedge MELT primitive, which is quite natural to use). That stuff data stays "alive"
because it is reachable from MELT values (e.g. closures) or "global" variables (which you declared using defvar in MELT). But the GCC infrastructure has several cleanup functions and passes
(e.g. from cleanup_cfg or cleanup_tree_cfg inside GCC code) which would forcibly delete (calling ggc_free on them) your stuff kept in MELT.
In some cases, the workaround is surprisingly simple. For example, in my justcountipa MELT pass, in file melt/xtramelt-ana-simple.melt functions justcountipa_exec and justcountipa_docmd etc, near line 840, which is an IPA pass coded in MELT to count gimples and edges etc... all the sensitive stuff is indirectly in my singleton class_justcountipa_data and I have just one instance of it which is the gccpass_data slot of my current MELT pass. The workaround was surprisingly simple: add
(put_fields pass :gccpass_data ())
near the end of my justcountipa_exec function, which is the execute function of my new pass named "melt_justcountipa"; then the garbage collectors would have dismissed the reference to the deleted stuff.
There is no better solution for now (i.e. for MELT 1.1 plugin for GCC 4.9). Any more robust solution would require me to make some accepted significant patch inside GCC itself, and my feeling is that
most people in the GCC community want to get rid of ggc_collect (which IMHO would be a mistake, but I am in the minority believing that). So even in the best case future improvements would only be for GCC 5.0 and MELT plugin 1.2 or 1.3
Feel free to ask more if you need more information.
Regards.
PS. I hope to release MELT 1.1.2 (a bug-fixing release) in a few days
-- 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} *** |
Reply all
Reply to author
Forward
0 new messages