+
+ /* At this stage we know that majority of GGC memory is reachable.
+ Growing the limits prevents unnecesary invocation of GGC. */
+ ggc_grow ();
ggc_collect ();
Isn't the collect here pointless? I see not in ENABLE_CHECKING, but
shouldn't this be abstracted
On April 17, 2014 6:03:13 PM CEST, Jan Hubicka hubi...@ucw.cz wrote:
+
+ /* At this stage we know that majority of GGC memory is
reachable.
+ Growing the limits prevents unnecesary invocation of GGC.
*/
+ ggc_grow ();
ggc_collect ();
Isn't the collect here
On April 17, 2014 6:03:13 PM CEST, Jan Hubicka hubi...@ucw.cz wrote:
+
+ /* At this stage we know that majority of GGC memory is
reachable.
+ Growing the limits prevents unnecesary invocation of GGC.
*/
+ ggc_grow ();
ggc_collect ();
Isn't the collect here
On April 17, 2014 7:18:05 PM CEST, Jan Hubicka hubi...@ucw.cz wrote:
On April 17, 2014 6:03:13 PM CEST, Jan Hubicka hubi...@ucw.cz
wrote:
+
+ /* At this stage we know that majority of GGC memory is
reachable.
+ Growing the limits prevents unnecesary invocation of
GGC.
*/
On Fri, 11 Apr 2014, Jan Hubicka wrote:
Hi,
while looking into -ftime-report, I noticed that ggc can take up to 10% of
WPA memory
while it does almost nothing: it is run just after streaming that explicitly
frees memory that becomes unreachable. The first GGC run usually saves at
most
On 04/11/2014 08:07 AM, Jan Hubicka wrote:
Hi,
while looking into -ftime-report, I noticed that ggc can take up to 10% of WPA
memory
while it does almost nothing: it is run just after streaming that explicitly
frees memory that becomes unreachable. The first GGC run usually saves at
most 1% of
+
+ /* At this stage we know that majority of GGC memory is reachable.
+ Growing the limits prevents unnecesary invocation of GGC. */
+ ggc_grow ();
ggc_collect ();
Isn't the collect here pointless? I see not in ENABLE_CHECKING, but
shouldn't this be abstracted away,
