RFR: 8079315: UseCondCardMark broken in conjunction with CMS precleaning

[Aleksey Shipilev]

On 12.05.2015 22:25, Aleksey Shipilev wrote:
> On 12.05.2015 22:03, Andrew Haley wrote:
>> On 05/12/2015 07:54 PM, Aleksey Shipilev wrote:
>>> On 12.05.2015 20:23, Erik Österlund wrote:
>>>> Out of curiosity I patched the thing and my fix can be found here: http://cr.openjdk.java.net/~eosterlund/8079315/webrev.v1/ <http://cr.openjdk.java.net/%7Eeosterlund/8079315/webrev.v1/>
>>>
>>> Wait, how does it work? I presumed you need to poll the serialization page (and then handle the possible trap) in mutator, between storing the reference and reading the card mark. Just mprotect-ing a page does not smell like a serializing event, if you don't actually access the page.
>>
>> I think it is, because the kernel has to interrupt every CPU in that
>> process to flush its write buffer and TLB.  I can't think of any other
>> way of making munmap() work.
> 
> If you have a platform with a software-filled TLB, can't you accurately
> track what CPUs should perform the TLB shootdowns? Or if there is some
> other way for a CPU to communicate the TLB contents back to OS. If that
> is in place, then mprotect can only affect the cores that actually
> accessed the serialization page. I feel that relying on the premise that
> page mapping changes are globally synchronized is dangerous.

Err... They *are* globally synchronized in the sense that all CPUs have
a consistent view on the mappings. Should be: "relying on page mapping
changes acting as the global serialization events is dangerous".

-Aleksey.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150512/149030ca/signature.asc>