RFR (S): Avoid scanning primitive arrays
Roman Kennke
rkennke at redhat.com
Wed Feb 8 13:27:56 UTC 2017
This is a good idea!
Couldn't we also avoid pushing such arrays to the workqueue to begin
with? Not sure if that's possible though (livedata counting, etc).
As already discussed offline, I'd love to see this taken further and
handle non-arrays without oop refs too. It should be possible at the
allocation site to figure out whether an object has oop refs or not.
This should be possible to encode in the layout-helper. Then we can
determine whether to scan or not (and push to the work queue, etc) an
object at all. According to your tests, this makes up ~40% of all
objects, so should be significant.
I've also more uses of such an oopDesc::has_oop_refs() helper, e.g. in
the connection-matrix/partial marking stuff I'm working on now.
Roman
Am Mittwoch, den 08.02.2017, 14:07 +0100 schrieb Aleksey Shipilev:
> Hi,
>
> In many workloads, there are significant number of primitive arrays.
> We can save
> the concurrent mark time by avoiding traversing their oop contents.
> Which there
> are none, but the downcall to oop_oop_iterate_nv still happens.
>
> Patch:
> http://cr.openjdk.java.net/~shade/shenandoah/mark-primitive-arrays/
> webrev.01/
>
>
> Improves mark times:
>
> baseline:
> Concurrent Marking = 48.32 s (a = 549133 us) (n = 88)
> (lvls, us = 287109, 505859, 546875, 593750, 755718)
>
> patched:
> Concurrent Marking = 46.95 s (a = 533516 us) (n = 88)
> (lvls, us = 283203, 494141, 523438, 572266, 744296)
>
> Testing: hotspot_gc_shenandoah
>
> Thanks,
> -Aleksey
>
>
More information about the shenandoah-dev
mailing list