Hi!

Looks like some of these values are redundant:

src/rt/lifetime.d
31:        PAGESIZE = 4096,

src/gc/pooltable.d
181:    enum PAGESIZE = 4096;

src/gc/impl/conservative/gc.d
1133:{   PAGESIZE =    4096,

This is correct? Which ones are related to each other? Which ones can be freely changed so that nothing (silently) breaks?

On a small system these values ​​seems too high.

On Saturday, 31 October 2020 at 19:06:33 UTC, Denis Feklushkin wrote:
> Hi!
>
> Looks like some of these values are redundant:
>
> src/rt/lifetime.d
> 31:        PAGESIZE = 4096,
>
> src/gc/pooltable.d
> 181:    enum PAGESIZE = 4096;
>
> src/gc/impl/conservative/gc.d
> 1133:{   PAGESIZE =    4096,
>
> This is correct? Which ones are related to each other? Which ones can be freely changed so that nothing (silently) breaks?
>
> On a small system these values ​​seems too high.

Yes, this is particular bad and also this should OS configurable (there might be an OS that suddenly bumps the page size to let's say 16KB) and not part of the D memory management code but part of the OS specific configuration.

Another problem for small systems is that the GC seems to assume page aligned memory, typically received from mmap or VirtualAlloc, however on small system and using the malloc fallback this doesn't work well. This waste memory on small system.

This should be fixed.

On Saturday, 31 October 2020 at 19:18:08 UTC, IGotD- wrote:
> On Saturday, 31 October 2020 at 19:06:33 UTC, Denis Feklushkin wrote:
>> [...]
>
> Yes, this is particular bad and also this should OS configurable (there might be an OS that suddenly bumps the page size to let's say 16KB) and not part of the D memory management code but part of the OS specific configuration.

SPARC has 8K pages. Ok SPARC is almost dead but still.
iOS also went full on bigger pages (16K afaicr).

>
> Another problem for small systems is that the GC seems to assume page aligned memory, typically received from mmap or VirtualAlloc, however on small system and using the malloc fallback this doesn't work well. This waste memory on small system.
>
> This should be fixed.

Yes.

On Saturday, 31 October 2020 at 19:06:33 UTC, Denis Feklushkin wrote:
> Hi!
>
> Looks like some of these values are redundant:
>
> src/rt/lifetime.d
> 31:        PAGESIZE = 4096,
>
> src/gc/pooltable.d
> 181:    enum PAGESIZE = 4096;
>
> src/gc/impl/conservative/gc.d
> 1133:{   PAGESIZE =    4096,
>
> This is correct? Which ones are related to each other? Which ones can be freely changed so that nothing (silently) breaks?
>
> On a small system these values ​​seems too high.

I should probably come back and finalize https://github.com/dlang/druntime/pull/3074 then :)

On 2020-10-31 20:06, Denis Feklushkin wrote:

> Looks like some of these values are redundant:
> 
> src/rt/lifetime.d
> 31:        PAGESIZE = 4096,
> 
> src/gc/pooltable.d
> 181:    enum PAGESIZE = 4096;
> 
> src/gc/impl/conservative/gc.d
> 1133:{   PAGESIZE =    4096,
> 
> This is correct? Which ones are related to each other? Which ones can be freely changed so that nothing (silently) breaks?

These are not correct. When I ported D to iOS I had to deal with this. The page size on iOS (and derived platforms) is 16K. It did change it in a few places where it broke the unit tests (or otherwise failed). I added two new symbols to `pageSize` and `minimumPageSize` [1]. The difference is that `minimumPageSize` is a compile time known value and might not be correct. `pageSize` is a runtime value which is initialized early in the startup phase. It's always correct since it gets the page size from the OS. `minimumPageSize` is discouraged, we might remove it.

I did a search through druntime and Phobos for the value `4096` and it appears quite a lot. I don't know how many of these values have to match the page size (i.e. for correctness) how many of these should ideally match the page size (i.e. for performance) or how many of these refer to something else (or it won't matter for performance or correctness).

I fixed all the places that was required to get the unit tests in druntime and Phobos to pass. If that means we're all good (at least for correctness) or that we don't have enough unit test coverage, I don't know.

[1] https://github.com/dlang/druntime/blob/4d68a910d74b3156b350701c08a97cf587da887a/src/core/memory.d#L181-L250

-- 
/Jacob Carlborg

On 2020-10-31 20:54, Patrick Schluter wrote:

> iOS also went full on bigger pages (16K afaicr).

Yes, see my other reply.

-- 
/Jacob Carlborg