RFR: Eliminating string dedup dependency on the second bitmap

[Zhengyu Gu]

>> necessary here.
>>
> It is possible that I get it wrong. But let me outline what I think:
> The StringDedupTable is a sort of GC root. In other words, it is a 
> pointers to heap oops from outside the heap. As such, it should be 
> treated and work like all other GC roots. Which does not involved 
> write-barriers on setting the pointer.

I would say, it more like weak roots.

> 
> It is possible and perfectly legal to write a from-space ref to a GC 
> root reference. What happens in this case is that later update-roots 
> pass after evacuation updates them to point to to-space. (that would be 
> either before marking or before the separate update_refs phase.) Until 
> that happens, all *access* to those oops, e.g. actual writes to the char 
> arrays in this case, need to go through a barrier.

Well, it does not work with piggyback UR without the second bitmap 
(which is this patch trying to address). If we are willing to add 
additional pause to update the table, then yes.

> 
> Whenever you insert a new barrier that doesn't involve any actual 
> directly subsequent heap access, it's a strong indication that you 
> should stop, step back, and check if it's already covered by some other 
> mechanism. It's almost always wrong to do a barrier after which there is 
> no actual access.
> 
> Are the StringDedupTable roots covered by ShenandoahRootProcessor? Is it 
> covered by the update-roots passes before marking or before update refs?

As mentioned above, it is *weak root*. Their reachabilities depend on 
dedup'ed strings, we should not explicitly mark them, otherwise, this 
table will be full of garbage


> 
> Are you getting any actual failures if you leave out those barriers?

Yes! it contains oops in just recycled cset.

Thanks,

-Zhengyu


> 
> Roman
>