Skip to content

Conversation

@jianchun
Copy link

@jianchun jianchun commented Oct 25, 2016

BaseDictionary Key or Value can be of GC pointer type, potentially needs
write barrier on each entry item.

Use macro and template type traits to replace underlying entry Key/Value
type with WriteBarrierPtr when Key or Value is pointer type and used with
recycler allocators.

BaseDictionary methods still use original Key/Value types. Only the
underlying EntryType may contain swapped type. Most methods are not
affected. However, when WriteBarrierPtr is used, only immutable
TryGetReference should be used. (We cannot get a mutable reference and
possibly change the pointer underneath WriteBarrierPtr.)

Allow WriteBarrierPtr to take immutable address to support TryGetReference
(used a lot). Fixed a bunch of incorrect const usage.

Update: Apply template traits to field types to simplify write barrier field
annotations. Now most annotations are Field or FieldNoBarrier (for pointers
known not needing write barrier).

BaseDictionary Key or Value can be of GC pointer type, potentially needs
write barrier on each entry item.

Use macro and template type traits to replace underlying entry Key/Value
type with WriteBarrierPtr when Key or Value is pointer type and used with
recycler allocators.

BaseDictionary methods still use original Key/Value types. Only the
underlying EntryType may contain swapped type. Most methods are not
affected. However, when WriteBarrierPtr is used, only immutable
TryGetReference should be used. (We cannot get a mutable reference and
possibly change the pointer underneath WriteBarrierPtr.)

Allow WriteBarrierPtr to take immutable address to support TryGetReference
(used a lot). Fixed a bunch of incorrect `const` usage.
@jianchun
Copy link
Author

@dotnet-bot test Linux tests please

@jianchun
Copy link
Author

@leirocks @digitalinfinity @curtisman Please help CR, thanks!

Apply template traits to field types to simplify write barrier field
annotations. Now most annotations are Field or FieldNoBarrier (for pointers
known not needing write barrier).

Replaced `WB_ITEM_TYPE` with `Field`.
return &ptr;
}
T** operator&()
// Taking immutable address is ok
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Taking immutable address is ok [](start = 7, length = 30)

we might need const_cast check in our tool? if so please add a TODO here

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Talked offline. @leirocks's idea is to examine and baseline our usage of const_cast to prevent future incorrect use related to this code. That is doable. Will add a note here.

@leirocks
Copy link
Contributor

:shipit:

@jianchun
Copy link
Author

Thanks @leirocks !

@jianchun jianchun merged commit 3a170fb into chakra-core:swb Oct 26, 2016
jianchun pushed a commit that referenced this pull request Oct 26, 2016
Merge pull request #1819 from jianchun:wbdict

BaseDictionary Key or Value can be of GC pointer type, potentially needs
write barrier on each entry item.

Use macro and template type traits to replace underlying entry Key/Value
type with WriteBarrierPtr when Key or Value is pointer type and used with
recycler allocators.

BaseDictionary methods still use original Key/Value types. Only the
underlying EntryType may contain swapped type. Most methods are not
affected. However, when WriteBarrierPtr is used, only immutable
TryGetReference should be used. (We cannot get a mutable reference and
possibly change the pointer underneath WriteBarrierPtr.)

Allow WriteBarrierPtr to take immutable address to support TryGetReference
(used a lot). Fixed a bunch of incorrect `const` usage.

Update: Apply template traits to field types to simplify write barrier field
annotations. Now most annotations are Field or FieldNoBarrier (for pointers
known not needing write barrier).
@jianchun jianchun deleted the wbdict branch October 26, 2016 21:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants