Looks good. Updating the map could race with the sweeper thread. Shouldn't
the
barrier check the state of incremental marker?
https://codereview.chromium.org/893073006/diff/1/src/hydrogen-instructions.h
File src/hydrogen-instructions.h (right):
https://codereview.chromium.org/893073006/diff/1/src/hydrogen-instructions.h#newcode6220
src/hydrogen-instructions.h:6220: static HObjectAccess
ForWeakCellValue() {
On 2015/02/03 17:42:53, Erik Corry Chromium.org wrote:
I suspect some or perhaps all of the uses of this are for checks and
should not
trigger the read barrier.
Yesterday I landed a change in StoreGlobal hydrogen stub that loads and
uses weak value.
https://codereview.chromium.org/893073006/diff/1/src/ia32/lithium-codegen-ia32.cc
File src/ia32/lithium-codegen-ia32.cc (right):
https://codereview.chromium.org/893073006/diff/1/src/ia32/lithium-codegen-ia32.cc#newcode2995
src/ia32/lithium-codegen-ia32.cc:2995: __ mov(result,
FieldOperand(object, HeapObject::kMapOffset));
__ mov(FieldOperand(object, HeapObject::kMapOffset), result);
https://codereview.chromium.org/893073006/diff/1/src/ia32/macro-assembler-ia32.cc
File src/ia32/macro-assembler-ia32.cc (right):
https://codereview.chromium.org/893073006/diff/1/src/ia32/macro-assembler-ia32.cc#newcode2432
src/ia32/macro-assembler-ia32.cc:2432: mov(scratch, FieldOperand(value,
HeapObject::kMapOffset));
mov(FieldOperand(value, HeapObject::kMapOffset), scratch); ?
https://codereview.chromium.org/893073006/diff/1/src/ic/ia32/ic-compiler-ia32.cc
File src/ic/ia32/ic-compiler-ia32.cc (right):
https://codereview.chromium.org/893073006/diff/1/src/ic/ia32/ic-compiler-ia32.cc#newcode117
src/ic/ia32/ic-compiler-ia32.cc:117: Handle<WeakCell> cell =
Map::WeakCellForMap(transitioned_maps->at(i));
On 2015/02/03 17:42:53, Erik Corry Chromium.org wrote:
I think perhaps here we should trigger the read barrier on the first
cell (yeah
there are two variables called cell in this function!) to show that it
is in use
and should not be cleared on GC. What do you think?
Do you mean read barrier on receiver_map? I think we don't need it. If
the compare succeeds than we already have the receiver map in register,
so it must be alive. If the compare fails, then we have no information
and we didn't "use" the map.
https://codereview.chromium.org/893073006/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
