RFR: Eliminate string dedup cleanup phase and correct UR closure
Aleksey Shipilev
shade at redhat.com
Thu Oct 19 16:11:58 UTC 2017
On 10/19/2017 06:07 PM, Zhengyu Gu wrote:
> On 10/19/2017 11:31 AM, Aleksey Shipilev wrote:
>> On 10/19/2017 03:45 PM, Zhengyu Gu wrote:
>> *) It looks like using ShenandoahIsAliveCompleteClosure that polls the complete bitmap during init
>> mark call parallel_update_or_unlink() blows Roman's single bitmap rework. At init mark, the next
>> bitmap is already cleared, and we cannot use it. This is not necessarily your problem, but maybe
>> there is a more neutral solution to avoid referencing complete bitmap this early? For example,
>> piggybacking String dedup work on actual mark, so we visit alive objects only?
> Oops, pushed before seeing this.
>
> I thought eliminating second bitmap still undecided, no?
>
> or we can pre-evacuate it?
The elimination of second bitmap is undecided, but we need to understand if it is absolutely
required for String dedup to work at init mark and have complete bitmap ready, or we can untie this
dependency.
-Aleksey
More information about the shenandoah-dev
mailing list