Last night I landed a patch that replaces the old recursive marking functions with a new iterative model that uses an explicit mark stack. This means that any custom mark methods that you need to write now need to be slightly different from what they were previously, i'll attempt to summarise here. The most obvious change is that an object is no longer responsible for marking itself instead the recursive mark methods have been replaced by a new virtual markChildren(MarkStack&) which is responsible for appending an objects children to the stack. The MarkStack is a very simple class, and the only method you really need to know about is MarkStack::append which adds a new object to the stack. The changes to how your custom marking functions are implemented are trivial, but here's a simple example void MyAwesomeObject::mark() { Base::mark(); if (!m_child.marked()) m_child.mark(); } Becomes void MyAwesomeObject::markChildren(MarkStack& markStack) { Base::markChildren(markStack); markStack.append(m_child); } And that's it, you're done. It's important to note that you will never be in a position where you call markChildren yourself, if you are that is an error. --Oliver
Hi Oliver, it seems on ARM using WTF_USE_JSVALUE32, the internal value of a date object is sometimes freed by the garbage collector. More specifically: The double (millisecond) representation of a date object (returned by a "new Date" expression) is stored in JSWrapperObject: m_internalValue. This m_internalValue points to a JSNumberCell, which stores the double value. Although this JSNumberCell is referenced by m_internalValue, the GC still collects its memory space. How can I fix this bug with the new mark() model? Zoltan
Last night I landed a patch that replaces the old recursive marking functions with a new iterative model that uses an explicit mark stack. This means that any custom mark methods that you need to write now need to be slightly different from what they were previously, i'll attempt to summarise here.
The most obvious change is that an object is no longer responsible for marking itself instead the recursive mark methods have been replaced by a new virtual markChildren(MarkStack&) which is responsible for appending an objects children to the stack.
The MarkStack is a very simple class, and the only method you really need to know about is MarkStack::append which adds a new object to the stack.
The changes to how your custom marking functions are implemented are trivial, but here's a simple example void MyAwesomeObject::mark() { Base::mark(); if (!m_child.marked()) m_child.mark(); }
Becomes void MyAwesomeObject::markChildren(MarkStack& markStack) { Base::markChildren(markStack); markStack.append(m_child); }
And that's it, you're done.
It's important to note that you will never be in a position where you call markChildren yourself, if you are that is an error.
--Oliver
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Hi Zoltan. JSWrapperObject::markChildren is responsible for marking the internalValue of a DateInstance. Is that function not being called? Geoff On Sep 1, 2009, at 6:16 AM, Zoltan Herczeg wrote:
Hi Oliver,
it seems on ARM using WTF_USE_JSVALUE32, the internal value of a date object is sometimes freed by the garbage collector.
More specifically: The double (millisecond) representation of a date object (returned by a "new Date" expression) is stored in JSWrapperObject: m_internalValue. This m_internalValue points to a JSNumberCell, which stores the double value. Although this JSNumberCell is referenced by m_internalValue, the GC still collects its memory space.
How can I fix this bug with the new mark() model?
Zoltan
Last night I landed a patch that replaces the old recursive marking functions with a new iterative model that uses an explicit mark stack. This means that any custom mark methods that you need to write now need to be slightly different from what they were previously, i'll attempt to summarise here.
The most obvious change is that an object is no longer responsible for marking itself instead the recursive mark methods have been replaced by a new virtual markChildren(MarkStack&) which is responsible for appending an objects children to the stack.
The MarkStack is a very simple class, and the only method you really need to know about is MarkStack::append which adds a new object to the stack.
The changes to how your custom marking functions are implemented are trivial, but here's a simple example void MyAwesomeObject::mark() { Base::mark(); if (!m_child.marked()) m_child.mark(); }
Becomes void MyAwesomeObject::markChildren(MarkStack& markStack) { Base::markChildren(markStack); markStack.append(m_child); }
And that's it, you're done.
It's important to note that you will never be in a position where you call markChildren yourself, if you are that is an error.
--Oliver
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Hi Geoff, That function is not called. I have opened a bug report for this issue (a simple failed example included) https://bugs.webkit.org/show_bug.cgi?id=28909 Zoltan
Hi Zoltan.
JSWrapperObject::markChildren is responsible for marking the internalValue of a DateInstance. Is that function not being called?
Geoff
On Sep 1, 2009, at 6:16 AM, Zoltan Herczeg wrote:
Hi Oliver,
it seems on ARM using WTF_USE_JSVALUE32, the internal value of a date object is sometimes freed by the garbage collector.
More specifically: The double (millisecond) representation of a date object (returned by a "new Date" expression) is stored in JSWrapperObject: m_internalValue. This m_internalValue points to a JSNumberCell, which stores the double value. Although this JSNumberCell is referenced by m_internalValue, the GC still collects its memory space.
How can I fix this bug with the new mark() model?
Zoltan
Last night I landed a patch that replaces the old recursive marking functions with a new iterative model that uses an explicit mark stack. This means that any custom mark methods that you need to write now need to be slightly different from what they were previously, i'll attempt to summarise here.
The most obvious change is that an object is no longer responsible for marking itself instead the recursive mark methods have been replaced by a new virtual markChildren(MarkStack&) which is responsible for appending an objects children to the stack.
The MarkStack is a very simple class, and the only method you really need to know about is MarkStack::append which adds a new object to the stack.
The changes to how your custom marking functions are implemented are trivial, but here's a simple example void MyAwesomeObject::mark() { Base::mark(); if (!m_child.marked()) m_child.mark(); }
Becomes void MyAwesomeObject::markChildren(MarkStack& markStack) { Base::markChildren(markStack); markStack.append(m_child); }
And that's it, you're done.
It's important to note that you will never be in a position where you call markChildren yourself, if you are that is an error.
--Oliver
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
In WTF_USE_JSVALUE32 DateInstance needs to override createStrucutre to remove the HasDefaultMark bit --Oliver On Sep 2, 2009, at 6:54 AM, Zoltan Herczeg wrote:
Hi Geoff,
That function is not called.
I have opened a bug report for this issue (a simple failed example included) https://bugs.webkit.org/show_bug.cgi?id=28909
Zoltan
Hi Zoltan.
JSWrapperObject::markChildren is responsible for marking the internalValue of a DateInstance. Is that function not being called?
Geoff
On Sep 1, 2009, at 6:16 AM, Zoltan Herczeg wrote:
Hi Oliver,
it seems on ARM using WTF_USE_JSVALUE32, the internal value of a date object is sometimes freed by the garbage collector.
More specifically: The double (millisecond) representation of a date object (returned by a "new Date" expression) is stored in JSWrapperObject: m_internalValue. This m_internalValue points to a JSNumberCell, which stores the double value. Although this JSNumberCell is referenced by m_internalValue, the GC still collects its memory space.
How can I fix this bug with the new mark() model?
Zoltan
Last night I landed a patch that replaces the old recursive marking functions with a new iterative model that uses an explicit mark stack. This means that any custom mark methods that you need to write now need to be slightly different from what they were previously, i'll attempt to summarise here.
The most obvious change is that an object is no longer responsible for marking itself instead the recursive mark methods have been replaced by a new virtual markChildren(MarkStack&) which is responsible for appending an objects children to the stack.
The MarkStack is a very simple class, and the only method you really need to know about is MarkStack::append which adds a new object to the stack.
The changes to how your custom marking functions are implemented are trivial, but here's a simple example void MyAwesomeObject::mark() { Base::mark(); if (!m_child.marked()) m_child.mark(); }
Becomes void MyAwesomeObject::markChildren(MarkStack& markStack) { Base::markChildren(markStack); markStack.append(m_child); }
And that's it, you're done.
It's important to note that you will never be in a position where you call markChildren yourself, if you are that is an error.
--Oliver
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Darin has already submitted a big patch to the bug report, which hopefully solve all of these issues. Zoltan
In WTF_USE_JSVALUE32 DateInstance needs to override createStrucutre to remove the HasDefaultMark bit
--Oliver
On Sep 2, 2009, at 6:54 AM, Zoltan Herczeg wrote:
Hi Geoff,
That function is not called.
I have opened a bug report for this issue (a simple failed example included) https://bugs.webkit.org/show_bug.cgi?id=28909
Zoltan
Hi Zoltan.
JSWrapperObject::markChildren is responsible for marking the internalValue of a DateInstance. Is that function not being called?
Geoff
On Sep 1, 2009, at 6:16 AM, Zoltan Herczeg wrote:
Hi Oliver,
it seems on ARM using WTF_USE_JSVALUE32, the internal value of a date object is sometimes freed by the garbage collector.
More specifically: The double (millisecond) representation of a date object (returned by a "new Date" expression) is stored in JSWrapperObject: m_internalValue. This m_internalValue points to a JSNumberCell, which stores the double value. Although this JSNumberCell is referenced by m_internalValue, the GC still collects its memory space.
How can I fix this bug with the new mark() model?
Zoltan
Last night I landed a patch that replaces the old recursive marking functions with a new iterative model that uses an explicit mark stack. This means that any custom mark methods that you need to write now need to be slightly different from what they were previously, i'll attempt to summarise here.
The most obvious change is that an object is no longer responsible for marking itself instead the recursive mark methods have been replaced by a new virtual markChildren(MarkStack&) which is responsible for appending an objects children to the stack.
The MarkStack is a very simple class, and the only method you really need to know about is MarkStack::append which adds a new object to the stack.
The changes to how your custom marking functions are implemented are trivial, but here's a simple example void MyAwesomeObject::mark() { Base::mark(); if (!m_child.marked()) m_child.mark(); }
Becomes void MyAwesomeObject::markChildren(MarkStack& markStack) { Base::markChildren(markStack); markStack.append(m_child); }
And that's it, you're done.
It's important to note that you will never be in a position where you call markChildren yourself, if you are that is an error.
--Oliver
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
participants (3)
-
Geoffrey Garen
-
Oliver Hunt
-
Zoltan Herczeg