RFR: Bitmap slices commit/uncommit
Roman Kennke
rkennke at redhat.com
Thu Oct 5 13:07:42 UTC 2017
Am 05.10.2017 um 14:20 schrieb Aleksey Shipilev:
> http://cr.openjdk.java.net/~shade/shenandoah/bitmaps-uncommit/webrev.01/
>
> Following the better commit/uncommit memory management for heap memory under the regions, we can
> also extend the same policy to the slices of our marking bitmaps. This saves significant chunk of
> committed memory when idle, for example idle app with -Xmx100g:
>
> === Before:
>
> Total: reserved=108444839KB, committed=3360035KB
> Java Heap (reserved=104857600KB, committed=16384KB)
> (mmap: reserved=104857600KB, committed=16384KB)
>
> GC (reserved=3292058KB, committed=3292058KB)
> (malloc=15258KB #12920)
> (mmap: reserved=3276800KB, committed=3276800KB)
>
> === After
>
> Total: reserved=108445029KB, committed=83937KB
> Java Heap (reserved=104857600KB, committed=16384KB)
> (mmap: reserved=104857600KB, committed=16384KB)
>
> GC (reserved=3292158KB, committed=15870KB)
> (malloc=15358KB #12921)
> (mmap: reserved=3276800KB, committed=512KB)
>
>
> The caveat is pages handling for bitmaps. We should enforce bitmap slices to be granular to page
> size. 4K pages mean at least 4K*64 = 256K region size, which is exactly our lower boundary, but this
> is asserted anyway. We also potentially give up large pages for bitmap allocations.
>
> Testing: hotspot_gc_shenandoah, some footprint benchmarks
>
> Thanks,
> -Aleksey
>
Looks ok to me
More information about the shenandoah-dev
mailing list