ngx_palloc.c may save more memory

[lwppwl@…]

in nginx-1.12.2 version

the ngx_reset_pool() function in ngx_palloc.c may change better:

when reset the point of the p->d.last, should consider the p whether or not the pool,
when the p is not the pool, should offset sizeof(ngx_pool_data_t) not sizeof(ngx_pool_t),

every small block can save sizeof(ngx_pool_t) - sizeof(ngx_pool_data_t) bytes.

---

Original code:

void ngx_reset_pool(ngx_pool_t *pool)
{
    ...
    for (p = pool; p; p = p->d.next)
    {
        p->d.last = (u_char *) p + sizeof(ngx_pool_t);
        p->d.failed = 0;
    }
    ...
}

Suggested code:

void ngx_reset_pool(ngx_pool_t *pool)
{
    ...
    for (p = pool; p; p = p->d.next)
    {
        if (p == pool)
        {
            p->d.last = (u_char *) p + sizeof(ngx_pool_t);
            p->d.failed = 0;
        }
        else
        {
            p->d.last = (u_char *) p + sizeof(ngx_pool_data_t);
            p->d.failed = 0;
        }
    }
    ...
}

[Valentin V. Bartenev]

The suggested code looks very strange. You don't need this branching inside the "for" loop. You don't need it outside the loop either.

Here's an equivalent code:

src/core/ngx_palloc.c

@@ -108 +108 @@
         }
     }
 
-    for (p = pool; p; p = p->d.next) {
-        p->d.last = (u_char *) p + sizeof(ngx_pool_t);
+    pool->d.last = (u_char *) pool + sizeof(ngx_pool_t);
+    pool->d.failed = 0;
+
+    for (p = pool->d.next; p; p = p->d.next) {
+        p->d.last = (u_char *) p + sizeof(ngx_pool_data_t);
         p->d.failed = 0;
     }
 

[Maxim Dounin]

Quoting ​http://mailman.nginx.org/pipermail/nginx/2016-July/051280.html:

A previous attempt to "fix" this can be found here, it looks
slightly better from my point of view:

​http://mailman.nginx.org/pipermail/nginx-devel/2010-June/000351.html

Though we are quite happy with the current code, while it is not
optimal - it is simple and good enough from practical point of
view.

I don't think anything changed since then.

[Maxim Dounin]

See also #1658.

[Maxim Dounin]

See also #1779.