|
From: Philippe W. <phi...@sk...> - 2016-10-06 19:58:39
|
I am a little bit lost in the documentation and/or semantic of the recently added meta mempool feature. First, valgrind.h tells: ... When the VALGRIND_MEMPOOL_AUTO_FREE is passed, a MEMPOOL_DELETE will auto-free all chunks (so not reported as leaks) for allocators that assume that destroying a pool destroys all objects in the pool. ... But this operation MEMPOOL_DELETE does not exist. This looks to be rather VALGRIND_MEMPOOL_FREE. In the manual, the description is somewhat different. Second thing confusing me: The user manual tells for META mempool first describe the auto free flag: ... This indicates that items allocated from this memory pool are automatically freed when VALGRIND_MEMPOOL_FREE is used on a block. ... But of course, when calling VALGRIND_MEMPOOL_FREE, by definition, the addr given as argument is supposed to be a chunk of the pool, and is released. So, this flag is by itself useless, unless it is combined with VALGRIND_MEMPOOL_METAPOOL. Do I miss something ? Assuming I did not miss something, then we now have a new macro VALGRIND_CREATE_META_MEMPOOL(pool, rzB, is_zeroed, flags) which in its names indicates it is a meta pool. So, it is unclear why we ask the user to specify VALGRIND_MEMPOOL_METAPOOL and/or allows the user to specify VALGRIND_MEMPOOL_AUTO_FREE, as this will be useless unless the pool is a real meta pool. (checking the code, effectively, the only thing an AUTO_FREE pool does is to release automatically the '2nd level smaller blocks' when a 'first level pool bigger block' is released with VALGRIND_MEMPOOL_FREE The second flag documented is also somewhat confusingly described: ... This indicates that memory that has been marked as being allocated with VALGRIND_MALLOCLIKE_BLOCK is used by a custom allocator to pass out memory to an application (again marked with VALGRIND_MALLOCLIKE_BLOCK). ... I do not see anything in tests and/or code that would implement something like a double level of VALGRIND_MALLOCLIKE_BLOCK. As I understand, we have a first level of blocks which are described with VALGRIND_MEMPOOL_ALLOC Then, such first level blocks can be split and allocated using VALGRIND_MALLOCLIKE_BLOCK. I think it would be better to clarify the documentation and maybe remove this (useless for the user) VALGRIND_MEMPOOL_METAPOOL : The underlying (internal) client request might effectively be the same (and so have an 'internal' flag VALGRIND_MEMPOOL_METAPOOL but it looks to me that describing this flag to the user is just confusing. Philippe |
|
From: Philippe W. <phi...@sk...> - 2016-10-06 20:36:49
|
On Thu, 2016-10-06 at 21:59 +0200, Philippe Waroquiers wrote: > But of course, when calling VALGRIND_MEMPOOL_FREE, by definition, the > addr > given as argument is supposed to be a chunk of the pool, and is > released. > So, this flag is by itself useless, unless it is combined with > VALGRIND_MEMPOOL_METAPOOL. I just confirmed using the test leak-autofreepool 3 that if you do a leak search before you have cleaned up the pool, then you get again an internal assertion in valgrind due to overlapping blocks. So, effectively, using only the flag VALGRIND_MEMPOOL_AUTO_FREE is not very useful, as any leak search done with such a not released pool will crash. Philippe |
|
From: Julian S. <js...@ac...> - 2016-10-07 05:28:21
|
Philippe, thanks for looking at this more. I think this needs to be clarified with the original author of the feature, and I am not sure he (Ruurd) is on the mailing list. Cc-ing therefore. For reference, the tracking bug is https://bugs.kde.org/show_bug.cgi?id=367995 J On 06/10/16 21:59, Philippe Waroquiers wrote: > I am a little bit lost in the documentation and/or semantic > of the recently added meta mempool feature. > > First, valgrind.h tells: > ... When the VALGRIND_MEMPOOL_AUTO_FREE > is passed, a MEMPOOL_DELETE will auto-free all chunks (so not reported as > leaks) for allocators that assume that destroying a pool destroys all > objects in the pool. > ... > > But this operation MEMPOOL_DELETE does not exist. > This looks to be rather VALGRIND_MEMPOOL_FREE. > In the manual, the description is somewhat different. > > > Second thing confusing me: > The user manual tells for META mempool first describe the auto free flag: > ... > This indicates that items allocated from this memory pool are automatically > freed when VALGRIND_MEMPOOL_FREE is used on a block. > ... > > But of course, when calling VALGRIND_MEMPOOL_FREE, by definition, the addr > given as argument is supposed to be a chunk of the pool, and is released. > So, this flag is by itself useless, unless it is combined with > VALGRIND_MEMPOOL_METAPOOL. > Do I miss something ? > > Assuming I did not miss something, then we now have a new macro > VALGRIND_CREATE_META_MEMPOOL(pool, rzB, is_zeroed, flags) > which in its names indicates it is a meta pool. > So, it is unclear why we ask the user to specify VALGRIND_MEMPOOL_METAPOOL > and/or allows the user to specify VALGRIND_MEMPOOL_AUTO_FREE, > as this will be useless unless the pool is a real meta pool. > (checking the code, effectively, the only thing an AUTO_FREE pool does > is to release automatically the '2nd level smaller blocks' when a 'first level > pool bigger block' is released with VALGRIND_MEMPOOL_FREE > > > The second flag documented is also somewhat confusingly described: > ... > This indicates that memory that has been marked as being allocated with > VALGRIND_MALLOCLIKE_BLOCK is used by a custom allocator to pass out memory > to an application (again marked with VALGRIND_MALLOCLIKE_BLOCK). > ... > > I do not see anything in tests and/or code that would implement something > like a double level of VALGRIND_MALLOCLIKE_BLOCK. > As I understand, we have a first level of blocks which are described > with VALGRIND_MEMPOOL_ALLOC > Then, such first level blocks can be split and allocated > using VALGRIND_MALLOCLIKE_BLOCK. > > > I think it would be better to clarify the documentation and maybe > remove this (useless for the user) VALGRIND_MEMPOOL_METAPOOL : > The underlying (internal) client request might effectively be > the same (and so have an 'internal' flag VALGRIND_MEMPOOL_METAPOOL > but it looks to me that describing this flag to the user is just > confusing. > > Philippe > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Philippe W. <phi...@sk...> - 2016-10-13 19:43:50
|
Thinking more at the interface to create a meta pool:
Either we keep the current name and we ensure (in the macro
expansion) that the meta flag is set
or alternatively, we change the name to be more general
maybe VALGRIND_CREATE_FLAGGED_MEMPOOL
or VALGRIND_CREATE_MEMPOOL_WITH_FLAGS
or VALGRIND_CREATE_GENERAL_MEMPOOL
or (using the linux naming convention when they forgot the flags arg)
VALGRIND_CREATE_MEMPOOL2 (if the digit tells this is macro nr 2)
or VALGRIND_CREATE_MEMPOOL4 (if the digit indicates the nr of args?)
We also indicate that using the AUTO_FREE flag without the
META flag is an error (at least today).
The more general name allows to re-use the same macro for
other kinds of pools (in case we would need new kinds in
the future) just by adding new flags.
Philippe
On Fri, 2016-10-07 at 07:28 +0200, Julian Seward wrote:
> Philippe, thanks for looking at this more. I think this needs to
> be clarified with the original author of the feature, and I am not
> sure he (Ruurd) is on the mailing list. Cc-ing therefore.
>
> For reference, the tracking bug is
> https://bugs.kde.org/show_bug.cgi?id=367995
>
> J
>
> On 06/10/16 21:59, Philippe Waroquiers wrote:
> > I am a little bit lost in the documentation and/or semantic
> > of the recently added meta mempool feature.
> >
> > First, valgrind.h tells:
> > ... When the VALGRIND_MEMPOOL_AUTO_FREE
> > is passed, a MEMPOOL_DELETE will auto-free all chunks (so not reported as
> > leaks) for allocators that assume that destroying a pool destroys all
> > objects in the pool.
> > ...
> >
> > But this operation MEMPOOL_DELETE does not exist.
> > This looks to be rather VALGRIND_MEMPOOL_FREE.
> > In the manual, the description is somewhat different.
> >
> >
> > Second thing confusing me:
> > The user manual tells for META mempool first describe the auto free flag:
> > ...
> > This indicates that items allocated from this memory pool are automatically
> > freed when VALGRIND_MEMPOOL_FREE is used on a block.
> > ...
> >
> > But of course, when calling VALGRIND_MEMPOOL_FREE, by definition, the addr
> > given as argument is supposed to be a chunk of the pool, and is released.
> > So, this flag is by itself useless, unless it is combined with
> > VALGRIND_MEMPOOL_METAPOOL.
> > Do I miss something ?
> >
> > Assuming I did not miss something, then we now have a new macro
> > VALGRIND_CREATE_META_MEMPOOL(pool, rzB, is_zeroed, flags)
> > which in its names indicates it is a meta pool.
> > So, it is unclear why we ask the user to specify VALGRIND_MEMPOOL_METAPOOL
> > and/or allows the user to specify VALGRIND_MEMPOOL_AUTO_FREE,
> > as this will be useless unless the pool is a real meta pool.
> > (checking the code, effectively, the only thing an AUTO_FREE pool does
> > is to release automatically the '2nd level smaller blocks' when a 'first level
> > pool bigger block' is released with VALGRIND_MEMPOOL_FREE
> >
> >
> > The second flag documented is also somewhat confusingly described:
> > ...
> > This indicates that memory that has been marked as being allocated with
> > VALGRIND_MALLOCLIKE_BLOCK is used by a custom allocator to pass out memory
> > to an application (again marked with VALGRIND_MALLOCLIKE_BLOCK).
> > ...
> >
> > I do not see anything in tests and/or code that would implement something
> > like a double level of VALGRIND_MALLOCLIKE_BLOCK.
> > As I understand, we have a first level of blocks which are described
> > with VALGRIND_MEMPOOL_ALLOC
> > Then, such first level blocks can be split and allocated
> > using VALGRIND_MALLOCLIKE_BLOCK.
> >
> >
> > I think it would be better to clarify the documentation and maybe
> > remove this (useless for the user) VALGRIND_MEMPOOL_METAPOOL :
> > The underlying (internal) client request might effectively be
> > the same (and so have an 'internal' flag VALGRIND_MEMPOOL_METAPOOL
> > but it looks to me that describing this flag to the user is just
> > confusing.
> >
> > Philippe
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Valgrind-developers mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-developers
> >
>
|
|
From: Ruurd B. <Ruu...@in...> - 2016-10-14 07:45:36
|
Hi, Sorry about the delay… 1. The MEMPOOL_DELETE was, indeed, a bad comment. Has to be VALGRIND_MEMPOOL_FREE. The documentation (memcheck/docs/mc-manual.xml) did use the correct name. 2. I see where the confusion comes from. Apologies. In my first attempts to get valgrind to understand our custom allocator, I saw a need to have a special attributes for a memory pool. - A flag to indicate that items in a pool-block are to be freed when VALGRIND_MEMPOOL_FREE is used on such a block. - A flag to indicate that a pool block is allocated (with VALGRIND_MALLOCLIKE_BLOCK) which is then used as a pool to allocate smaller VALGRIND_MALLOCLIKE_BLOCKs from. Without the first attribute, I got thousands of leaks reported that were not really leaks. Without the 2nd attribute, valgrind would crash with an assert, complaining about overlapping blocks. So: Without these fixes, valgrind is not usable in our environment. My first implementation of this broke compatibility in valgrind.h by altering the signature of VALGRIND_CREATE_MEMPOOL. I managed to get it to work in our environment that way and we found and fixed several issues in our large code base. Yippee! Then I tried to get the fixes in valgrind reworked so they could become part of the standard distribution, because our code is multi-platform, and we continuously support new hardware and OS-releases. I do not want to have to re-fix every future version of valgrind. The naming of the reworked version is, I must admit, badly chosen. The attribute names reflect the implementation, not the functionality. There is no point in having an AUTO_FREE pool which is not a METAPOOL. The name of the macro already tells you that, and AUTO_FREE only makes sense when chunks are contained in other chunks (i.e. META). A METAPOOL that is not AUTO_FREE is more logical, I can envision a custom allocator that. So a VALGRIND_CREATE_META_MEMPOOL that only accepts an AUTO_FREE flag is better. Or a name like VALGRIND_CREATE_MEMPOOL_EXT or some other convention that allows future expansion. So I agree with the renaming: The VALGRIND_MEMPOOL_METAPOOL flag can go and is implied in the call. The documentation of that flag (which only confuses things) can be removed. There is a test which tests the double-level stuff. The memcheck/tests/leak-autofreepool.c test creates a pool with blocks, the allocates (with VALGRIND_MALLOCLIKE_BLOCK, like our custom allocator does. In test case 5, it demonstrates that valgrind asserts and aborts if the METAPOOL flags is not passed. Again, the documentation is confusing: the blocks overlap, but one is of type MEMPOOL_ALLOC and the second of MALLOCLIKE_BLOCK type. Apologies for that: my focus was more on “getting it working here and for us now” than on a clean, complete & spotless valgrind patch. I’m glad the vetting process is so thorough, though ☺ Who is going to polish up this stuff? I can do it, but if one of the valgrind veterans does it I’ll be happy, too (and if I do it, it might again take a few tries before it is deemed satisfactory). The change to our custom allocator will be tiny (use the new macro and names) and as long as it works, I’m happy. Regards, Ruurd Beerstra From: Ivo Raisr [mailto:iv...@iv...] Sent: Thursday, October 06, 2016 22:02 To: Ruurd Beerstra <Ruu...@in...> Subject: Fwd: [Valgrind-developers] Confusion in recent meta mempool doc and/or usage FYI if you are not on valgrind-developers ---------- Forwarded message ---------- From: Philippe Waroquiers <phi...@sk...<mailto:phi...@sk...>> Date: 2016-10-06 21:59 GMT+02:00 Subject: [Valgrind-developers] Confusion in recent meta mempool doc and/or usage To: valgrind-developers <val...@li...<mailto:val...@li...>> I am a little bit lost in the documentation and/or semantic of the recently added meta mempool feature. First, valgrind.h tells: ... When the VALGRIND_MEMPOOL_AUTO_FREE is passed, a MEMPOOL_DELETE will auto-free all chunks (so not reported as leaks) for allocators that assume that destroying a pool destroys all objects in the pool. ... But this operation MEMPOOL_DELETE does not exist. This looks to be rather VALGRIND_MEMPOOL_FREE. In the manual, the description is somewhat different. Second thing confusing me: The user manual tells for META mempool first describe the auto free flag: ... This indicates that items allocated from this memory pool are automatically freed when VALGRIND_MEMPOOL_FREE is used on a block. ... But of course, when calling VALGRIND_MEMPOOL_FREE, by definition, the addr given as argument is supposed to be a chunk of the pool, and is released. So, this flag is by itself useless, unless it is combined with VALGRIND_MEMPOOL_METAPOOL. Do I miss something ? Assuming I did not miss something, then we now have a new macro VALGRIND_CREATE_META_MEMPOOL(pool, rzB, is_zeroed, flags) which in its names indicates it is a meta pool. So, it is unclear why we ask the user to specify VALGRIND_MEMPOOL_METAPOOL and/or allows the user to specify VALGRIND_MEMPOOL_AUTO_FREE, as this will be useless unless the pool is a real meta pool. (checking the code, effectively, the only thing an AUTO_FREE pool does is to release automatically the '2nd level smaller blocks' when a 'first level pool bigger block' is released with VALGRIND_MEMPOOL_FREE The second flag documented is also somewhat confusingly described: ... This indicates that memory that has been marked as being allocated with VALGRIND_MALLOCLIKE_BLOCK is used by a custom allocator to pass out memory to an application (again marked with VALGRIND_MALLOCLIKE_BLOCK). ... I do not see anything in tests and/or code that would implement something like a double level of VALGRIND_MALLOCLIKE_BLOCK. As I understand, we have a first level of blocks which are described with VALGRIND_MEMPOOL_ALLOC Then, such first level blocks can be split and allocated using VALGRIND_MALLOCLIKE_BLOCK. I think it would be better to clarify the documentation and maybe remove this (useless for the user) VALGRIND_MEMPOOL_METAPOOL : The underlying (internal) client request might effectively be the same (and so have an 'internal' flag VALGRIND_MEMPOOL_METAPOOL but it looks to me that describing this flag to the user is just confusing. Philippe ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Valgrind-developers mailing list Val...@li...<mailto:Val...@li...> https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Philippe W. <phi...@sk...> - 2016-10-15 13:00:57
|
Quadratic aspect of meta pool fixed in r16041 Renamed macro and clarified documentation in r16042. Thanks Philippe On Fri, 2016-10-14 at 07:45 +0000, Ruurd Beerstra wrote: > Hi, > > > > Sorry about the delay… > > > > 1. The MEMPOOL_DELETE was, indeed, a bad comment. Has to be > VALGRIND_MEMPOOL_FREE. > The documentation (memcheck/docs/mc-manual.xml) did use the correct > name. > > 2. I see where the confusion comes from. Apologies. > In my first attempts to get valgrind to understand our custom > allocator, I saw a need to have a special attributes for a memory > pool. > - A flag to indicate that items in a pool-block are to be freed when > VALGRIND_MEMPOOL_FREE is used on such a block. > - A flag to indicate that a pool block is allocated (with > VALGRIND_MALLOCLIKE_BLOCK) which is then used as a pool to allocate > smaller VALGRIND_MALLOCLIKE_BLOCKs from. > > Without the first attribute, I got thousands of leaks reported that > were not really leaks. > Without the 2nd attribute, valgrind would crash with an assert, > complaining about overlapping blocks. > So: Without these fixes, valgrind is not usable in our environment. > My first implementation of this broke compatibility in valgrind.h by > altering the signature of VALGRIND_CREATE_MEMPOOL. > I managed to get it to work in our environment that way and we found > and fixed several issues in our large code base. Yippee! > Then I tried to get the fixes in valgrind reworked so they could > become part of the standard distribution, because our code is > multi-platform, and we continuously support new hardware and > OS-releases. I do not want to have to re-fix every future version of > valgrind. > The naming of the reworked version is, I must admit, badly chosen. The > attribute names reflect the implementation, not the functionality. > There is no point in having an AUTO_FREE pool which is not a METAPOOL. > The name of the macro already tells you that, and AUTO_FREE only makes > sense when chunks are contained in other chunks (i.e. META). > A METAPOOL that is not AUTO_FREE is more logical, I can envision a > custom allocator that. > So a VALGRIND_CREATE_META_MEMPOOL that only accepts an AUTO_FREE flag > is better. > Or a name like VALGRIND_CREATE_MEMPOOL_EXT or some other convention > that allows future expansion. > > > > So I agree with the renaming: The VALGRIND_MEMPOOL_METAPOOL flag can > go and is implied in the call. > > The documentation of that flag (which only confuses things) can be > removed. > > There is a test which tests the double-level stuff. > > The memcheck/tests/leak-autofreepool.c test creates a pool with > blocks, the allocates (with VALGRIND_MALLOCLIKE_BLOCK, like our custom > allocator does. > > In test case 5, it demonstrates that valgrind asserts and aborts if > the METAPOOL flags is not passed. > > Again, the documentation is confusing: the blocks overlap, but one is > of type MEMPOOL_ALLOC and the second of MALLOCLIKE_BLOCK type. > > > > Apologies for that: my focus was more on “getting it working here and > for us now” than on a clean, complete & spotless valgrind patch. > > I’m glad the vetting process is so thorough, thoughJ > > > > Who is going to polish up this stuff? > > I can do it, but if one of the valgrind veterans does it I’ll be > happy, too (and if I do it, it might again take a few tries before it > is deemed satisfactory). > > The change to our custom allocator will be tiny (use the new macro and > names) and as long as it works, I’m happy. > > > > Regards, > > Ruurd Beerstra > > > > > > From: Ivo Raisr [mailto:iv...@iv...] > Sent: Thursday, October 06, 2016 22:02 > To: Ruurd Beerstra <Ruu...@in...> > Subject: Fwd: [Valgrind-developers] Confusion in recent meta mempool > doc and/or usage > > > > FYI if you are not on valgrind-developers > > > > > ---------- Forwarded message ---------- > From: Philippe Waroquiers <phi...@sk...> > Date: 2016-10-06 21:59 GMT+02:00 > Subject: [Valgrind-developers] Confusion in recent meta mempool doc > and/or usage > To: valgrind-developers <val...@li...> > > > I am a little bit lost in the documentation and/or semantic > of the recently added meta mempool feature. > > First, valgrind.h tells: > ... When the VALGRIND_MEMPOOL_AUTO_FREE > is passed, a MEMPOOL_DELETE will auto-free all chunks (so not > reported as > leaks) for allocators that assume that destroying a pool destroys > all > objects in the pool. > ... > > But this operation MEMPOOL_DELETE does not exist. > This looks to be rather VALGRIND_MEMPOOL_FREE. > In the manual, the description is somewhat different. > > > Second thing confusing me: > The user manual tells for META mempool first describe the auto free > flag: > ... > This indicates that items allocated from this memory pool are > automatically > freed when VALGRIND_MEMPOOL_FREE is used on a block. > ... > > But of course, when calling VALGRIND_MEMPOOL_FREE, by definition, the > addr > given as argument is supposed to be a chunk of the pool, and is > released. > So, this flag is by itself useless, unless it is combined with > VALGRIND_MEMPOOL_METAPOOL. > Do I miss something ? > > Assuming I did not miss something, then we now have a new macro > VALGRIND_CREATE_META_MEMPOOL(pool, rzB, is_zeroed, flags) > which in its names indicates it is a meta pool. > So, it is unclear why we ask the user to specify > VALGRIND_MEMPOOL_METAPOOL > and/or allows the user to specify VALGRIND_MEMPOOL_AUTO_FREE, > as this will be useless unless the pool is a real meta pool. > (checking the code, effectively, the only thing an AUTO_FREE pool does > is to release automatically the '2nd level smaller blocks' when a > 'first level > pool bigger block' is released with VALGRIND_MEMPOOL_FREE > > > The second flag documented is also somewhat confusingly described: > ... > This indicates that memory that has been marked as being allocated > with > VALGRIND_MALLOCLIKE_BLOCK is used by a custom allocator to pass out > memory > to an application (again marked with VALGRIND_MALLOCLIKE_BLOCK). > ... > > I do not see anything in tests and/or code that would implement > something > like a double level of VALGRIND_MALLOCLIKE_BLOCK. > As I understand, we have a first level of blocks which are described > with VALGRIND_MEMPOOL_ALLOC > Then, such first level blocks can be split and allocated > using VALGRIND_MALLOCLIKE_BLOCK. > > > I think it would be better to clarify the documentation and maybe > remove this (useless for the user) VALGRIND_MEMPOOL_METAPOOL : > The underlying (internal) client request might effectively be > the same (and so have an 'internal' flag VALGRIND_MEMPOOL_METAPOOL > but it looks to me that describing this flag to the user is just > confusing. > > Philippe > > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > > |
|
From: Ivo R. <iv...@iv...> - 2016-10-15 15:36:48
|
2016-10-15 15:01 GMT+02:00 Philippe Waroquiers < phi...@sk...>: > Quadratic aspect of meta pool fixed in r16041 > Renamed macro and clarified documentation in r16042. > Philippe, Thank you very much for providing such nice explanation about implicit relation between first and second level blocks in a metapool when various flags are in effect. Now the documentation clearly describes what the implementation does. I. |
|
From: Julian S. <js...@ac...> - 2016-10-18 05:55:14
|
On 15/10/16 17:36, Ivo Raisr wrote: > 2016-10-15 15:01 GMT+02:00 Philippe Waroquiers < > phi...@sk...>: > >> Quadratic aspect of meta pool fixed in r16041 >> Renamed macro and clarified documentation in r16042. And merged into the branch, 16067/8/9. > Thank you very much for providing such nice explanation about implicit > relation between first and second level blocks in a metapool when various > flags are in effect. Now the documentation clearly describes what the > implementation does. Yes, indeed! J |