ResourceHandles passed around by NetworkProxy are sometimes null #5
Assignees
Labels
Comments
ghost
assigned 
|
Closing until repro found. |
burg
pushed a commit
that referenced
this issue
Oct 20, 2012
https://bugs.webkit.org/show_bug.cgi?id=98997 Reviewed by Oliver Hunt. Somewhat incidentally, the introduction of butterflies led to each indexing type being represented by a unique bit. This is superficially nice since it allows you to test if a structure corresponds to a particular indexing type by saying !!(structure->indexingType() & TheType). But the downside is that given the 8 bits we have for the m_indexingType field, that leaves only a small number of possible indexing types if we have one per bit. This changeset changes the indexing type to be: Bit #1: Tells you if you're an array. Bits #2 - #5: 16 possible indexing types, including the blank type for objects that don't have indexed properties. Bits #6-8: Auxiliary bits that we could use for other things. Currently we just use one of those bits, for MayHaveIndexedAccessors. This is performance-neutral, and is primarily intended to give us more breathing room for introducing new inferred array modes. * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::JumpList::jumps): * assembler/MacroAssembler.h: (MacroAssembler): (JSC::MacroAssembler::patchableBranch32): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::patchableBranch32): (MacroAssemblerARMv7): * dfg/DFGArrayMode.cpp: (JSC::DFG::modeAlreadyChecked): * dfg/DFGRepatch.cpp: (JSC::DFG::tryCacheGetByID): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculationCheck): (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): (DFG): (JSC::DFG::SpeculativeJIT::checkArray): (JSC::DFG::SpeculativeJIT::arrayify): * dfg/DFGSpeculativeJIT.h: (SpeculativeJIT): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/JITInlineMethods.h: (JSC::JIT::emitAllocateJSArray): (JSC::JIT::chooseArrayMode): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitContiguousGetByVal): (JSC::JIT::emitArrayStorageGetByVal): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::privateCompilePatchGetArrayLength): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitContiguousGetByVal): (JSC::JIT::emitArrayStorageGetByVal): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::privateCompilePatchGetArrayLength): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/IndexingType.h: (JSC): (JSC::hasIndexedProperties): (JSC::hasContiguous): (JSC::hasFastArrayStorage): (JSC::hasArrayStorage): (JSC::shouldUseSlowPut): * runtime/JSGlobalObject.cpp: (JSC): * runtime/StructureTransitionTable.h: (JSC::newIndexingType): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131276 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
pushed a commit
that referenced
this issue
Oct 27, 2012
https://bugs.webkit.org/show_bug.cgi?id=99899 Reviewed by Ryosuke Niwa. We cannot provide an elegant way to measure the memory consumption of the PageLoad tests, but we can turn them into simple performance tests and measure their memory footprint and performance that way. This change moves and renames the related files to their new location and adds html/js wrappers for them. This is the #5 commit of the whole patch. * PageLoad/svg/files/Harvey_Rayner.svg: Removed. * PageLoad/svg/files/Sierpinski_carpet_6.svg: Removed. * PageLoad/svg/files/mtsthelens.svg: Removed. * PageLoad/svg/files/mtsthelens0.jpg: Removed. * SVG/HarveyRayner.html: Added. * SVG/MtSaintHelens.html: Added. * SVG/SierpinskiCarpet.html: Added. * SVG/resources/HarveyRayner.svg: Copied from PerformanceTests/PageLoad/svg/files/Harvey_Rayner.svg. * SVG/resources/MtSaintHelens.svg: Copied from PerformanceTests/PageLoad/svg/files/mtsthelens.svg. * SVG/resources/SierpinskiCarpet.svg: Copied from PerformanceTests/PageLoad/svg/files/Sierpinski_carpet_6.svg. * SVG/resources/mtsthelens0.jpg: Copied from PerformanceTests/PageLoad/svg/files/mtsthelens0.jpg. * Skipped: Rename the files on the skipped list also. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@132670 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
referenced
this issue
Feb 14, 2013
https://bugs.webkit.org/show_bug.cgi?id=72856 Reviewed by Adam Barth. Source/WebCore: This patch makes WebGLContextEvent constructable. The spec: http://www.khronos.org/registry/webgl/specs/latest/#5.14 Test: fast/events/constructors/webgl-context-event-constructor.html * html/canvas/WebGLContextEvent.cpp: Added an implementation of the WebGLContextEvent constructor. (WebCore::WebGLContextEventInit::WebGLContextEventInit): (WebCore::WebGLContextEvent::WebGLContextEvent): * html/canvas/WebGLContextEvent.h: Added a definition of WebGLContextEventInit. (WebCore::WebGLContextEvent::create): * html/canvas/WebGLContextEvent.idl: Added [ConstructorTemplate=Event] IDL. LayoutTests: webgl-context-event-constructor.html checks the behavior of the WebGLContextEvent constructor. * fast/dom/constructed-objects-prototypes-expected.txt: Added window.WebGLContextEvent. * fast/events/constructors/webgl-context-event-constructor-expected.txt: Added. * fast/events/constructors/webgl-context-event-constructor.html: Added. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@101183 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
pushed a commit
that referenced
this issue
Feb 14, 2013
https://bugs.webkit.org/show_bug.cgi?id=78454 Unreviewed. Rebaseline #5 of N * platform/chromium-linux/fast/images/gray-scale-jpeg-with-color-profile-expected.png: * platform/chromium-mac-snowleopard/fast/images/gray-scale-jpeg-with-color-profile-expected.png: Added. * platform/chromium-mac-snowleopard/fast/images/image-css3-content-data-expected.png: Added. * platform/chromium-mac-snowleopard/fast/images/ycbcr-with-cmyk-color-profile-expected.png: * platform/chromium-win/fast/images/gray-scale-jpeg-with-color-profile-expected.png: * platform/chromium-win/fast/images/image-css3-content-data-expected.png: Renamed from LayoutTests/platform/chromium/fast/images/image-css3-content-data-expected.png. * platform/chromium-win/fast/images/ycbcr-with-cmyk-color-profile-expected.png: * platform/chromium/fast/images/gray-scale-jpeg-with-color-profile-expected.png: Removed. * platform/chromium/test_expectations.txt: * platform/mac-snowleopard/fast/images/ycbcr-with-cmyk-color-profile-expected.png: Removed. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@107675 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
pushed a commit
that referenced
this issue
Feb 14, 2013
https://bugs.webkit.org/show_bug.cgi?id=98997 Reviewed by Oliver Hunt. Somewhat incidentally, the introduction of butterflies led to each indexing type being represented by a unique bit. This is superficially nice since it allows you to test if a structure corresponds to a particular indexing type by saying !!(structure->indexingType() & TheType). But the downside is that given the 8 bits we have for the m_indexingType field, that leaves only a small number of possible indexing types if we have one per bit. This changeset changes the indexing type to be: Bit #1: Tells you if you're an array. Bits #2 - #5: 16 possible indexing types, including the blank type for objects that don't have indexed properties. Bits #6-8: Auxiliary bits that we could use for other things. Currently we just use one of those bits, for MayHaveIndexedAccessors. This is performance-neutral, and is primarily intended to give us more breathing room for introducing new inferred array modes. * assembler/AbstractMacroAssembler.h: (JSC::AbstractMacroAssembler::JumpList::jumps): * assembler/MacroAssembler.h: (MacroAssembler): (JSC::MacroAssembler::patchableBranch32): * assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::patchableBranch32): (MacroAssemblerARMv7): * dfg/DFGArrayMode.cpp: (JSC::DFG::modeAlreadyChecked): * dfg/DFGRepatch.cpp: (JSC::DFG::tryCacheGetByID): * dfg/DFGSpeculativeJIT.cpp: (JSC::DFG::SpeculativeJIT::speculationCheck): (JSC::DFG::SpeculativeJIT::forwardSpeculationCheck): (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode): (DFG): (JSC::DFG::SpeculativeJIT::checkArray): (JSC::DFG::SpeculativeJIT::arrayify): * dfg/DFGSpeculativeJIT.h: (SpeculativeJIT): * dfg/DFGSpeculativeJIT32_64.cpp: (JSC::DFG::SpeculativeJIT::compile): * dfg/DFGSpeculativeJIT64.cpp: (JSC::DFG::SpeculativeJIT::compile): * jit/JITInlineMethods.h: (JSC::JIT::emitAllocateJSArray): (JSC::JIT::chooseArrayMode): * jit/JITPropertyAccess.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitContiguousGetByVal): (JSC::JIT::emitArrayStorageGetByVal): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::privateCompilePatchGetArrayLength): * jit/JITPropertyAccess32_64.cpp: (JSC::JIT::emit_op_get_by_val): (JSC::JIT::emitContiguousGetByVal): (JSC::JIT::emitArrayStorageGetByVal): (JSC::JIT::emit_op_put_by_val): (JSC::JIT::emitContiguousPutByVal): (JSC::JIT::emitArrayStoragePutByVal): (JSC::JIT::privateCompilePatchGetArrayLength): * llint/LowLevelInterpreter.asm: * llint/LowLevelInterpreter32_64.asm: * llint/LowLevelInterpreter64.asm: * runtime/IndexingType.h: (JSC): (JSC::hasIndexedProperties): (JSC::hasContiguous): (JSC::hasFastArrayStorage): (JSC::hasArrayStorage): (JSC::shouldUseSlowPut): * runtime/JSGlobalObject.cpp: (JSC): * runtime/StructureTransitionTable.h: (JSC::newIndexingType): git-svn-id: http://svn.webkit.org/repository/webkit/trunk@131276 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
pushed a commit
that referenced
this issue
Feb 14, 2013
https://bugs.webkit.org/show_bug.cgi?id=99899 Reviewed by Ryosuke Niwa. We cannot provide an elegant way to measure the memory consumption of the PageLoad tests, but we can turn them into simple performance tests and measure their memory footprint and performance that way. This change moves and renames the related files to their new location and adds html/js wrappers for them. This is the #5 commit of the whole patch. * PageLoad/svg/files/Harvey_Rayner.svg: Removed. * PageLoad/svg/files/Sierpinski_carpet_6.svg: Removed. * PageLoad/svg/files/mtsthelens.svg: Removed. * PageLoad/svg/files/mtsthelens0.jpg: Removed. * SVG/HarveyRayner.html: Added. * SVG/MtSaintHelens.html: Added. * SVG/SierpinskiCarpet.html: Added. * SVG/resources/HarveyRayner.svg: Copied from PerformanceTests/PageLoad/svg/files/Harvey_Rayner.svg. * SVG/resources/MtSaintHelens.svg: Copied from PerformanceTests/PageLoad/svg/files/mtsthelens.svg. * SVG/resources/SierpinskiCarpet.svg: Copied from PerformanceTests/PageLoad/svg/files/Sierpinski_carpet_6.svg. * SVG/resources/mtsthelens0.jpg: Copied from PerformanceTests/PageLoad/svg/files/mtsthelens0.jpg. * Skipped: Rename the files on the skipped list also. git-svn-id: http://svn.webkit.org/repository/webkit/trunk@132670 268f45cc-cd09-0410-ab3c-d52691b4dbfc
burg
pushed a commit
that referenced
this issue
Oct 14, 2013
…hread (causing scroll bars not to appear/update quickly in some cases) https://bugs.webkit.org/show_bug.cgi?id=122585 -and corresponding- <rdar://problem/10710775> Reviewed by Simon Fraser. Source/WebCore: This patch does a few things in order to allow scrollbars to be updated on the scrolling thread: 1. This patch adds the ability to know if the lower-level APIs necessary to get this to work right are available, AND if the content is actually capable of taking advantage of this feature. This is currently implemented as Scrollbar::supportsUpdateOnSecondaryThread() which makes use of a new ScrollableArea function called updatesScrollLayerPositionOnMainThread() 2. To update on the scrolling thread, the scrolling tree needs to know about the ScrollbarPainters. 3. Once it knows about them, it should update the presentation value whenever the layer position changes. 4. Presentation value is basically the same thing as double value. There is a bit of code we maintain currently to compute that. This patch moves that code to a static function on ScrollableArea that can be called from both the main thread and the scrolling thread. 5. ScrollbarPainter API needs to know about the layers we have created for the vertical and horizontal scrollbars, then they will use those layers and the presentation value that we set on the scrolling thread to move the layers around. This is part of #1 above. * page/FrameView.cpp: (WebCore::FrameView::updatesScrollLayerPositionOnMainThread): * page/FrameView.h: This is part of #2. ScrollingStateScrollingNodes now have vertical and horizontal ScrollbarPainters for Mac only. * page/scrolling/ScrollingStateScrollingNode.cpp: (WebCore::ScrollingStateScrollingNode::ScrollingStateScrollingNode): * page/scrolling/ScrollingStateScrollingNode.h: (WebCore::ScrollingStateScrollingNode::verticalScrollbarPainter): (WebCore::ScrollingStateScrollingNode::horizontalScrollbarPainter): Also part of #2. Make sure to set the ScrollbarPainters for scrolling nodes when appropriate. * page/scrolling/mac/ScrollingCoordinatorMac.h: * page/scrolling/mac/ScrollingCoordinatorMac.mm: (WebCore::ScrollingCoordinatorMac::frameViewLayoutUpdated): Implement this function that was just stubbed out before. This is part of #5 in that is will allow the ScrollbarPainter API to know about any layer changes. (WebCore::ScrollingCoordinatorMac::scrollableAreaScrollbarLayerDidChange): Back to #2, making sure we properly set the ScrollbarPainters to send over to the scrolling thread. (WebCore::ScrollingCoordinatorMac::setScrollbarPaintersForNode): * page/scrolling/mac/ScrollingStateScrollingNodeMac.mm: (WebCore::ScrollingStateScrollingNode::setScrollbarPainters): This code achieves #3. It uses new ScrollbarPainter API to adjust the position of the scrollbars from the scrolling thread. * page/scrolling/mac/ScrollingTreeScrollingNodeMac.h: * page/scrolling/mac/ScrollingTreeScrollingNodeMac.mm: (WebCore::ScrollingTreeScrollingNodeMac::ScrollingTreeScrollingNodeMac): (WebCore::ScrollingTreeScrollingNodeMac::updateBeforeChildren): (WebCore::ScrollingTreeScrollingNodeMac::setScrollLayerPosition): This is for #5. ScrollbarPainter needs to know about our scrollbar layers. * platform/ScrollAnimator.h: (WebCore::ScrollAnimator::verticalScrollbarLayerDidChange): (WebCore::ScrollAnimator::horizontalScrollbarLayerDidChange): * platform/ScrollableArea.cpp: (WebCore::ScrollableArea::verticalScrollbarLayerDidChange): (WebCore::ScrollableArea::horizontalScrollbarLayerDidChange): This is for #4. This code computes the scrollbar’s value and current overhang amount. (WebCore::ScrollableArea::computeScrollbarValueAndOverhang): * platform/ScrollableArea.h: (WebCore::ScrollableArea::layerForHorizontalScrollbar): (WebCore::ScrollableArea::layerForVerticalScrollbar): (WebCore::ScrollableArea::layerForScrolling): This is for #1. We need to know if we have the ability to update scrollbars on a different thread. We can do that only on certain versions of the OS, only when threaded scrolling is enabled, and only when the current page is actually using the scrolling thread to scroll. * platform/Scrollbar.cpp: (WebCore::Scrollbar::supportsUpdateOnSecondaryThread): * platform/Scrollbar.h: * platform/ScrollbarThemeClient.h: New ScrollbarPainter APIs. * platform/mac/NSScrollerImpDetails.h: This is for #5, letting the ScrollbarPainter API know about the layers. * platform/mac/ScrollAnimatorMac.h: * platform/mac/ScrollAnimatorMac.mm: (-[WebScrollbarPainterDelegate layer]): (-[WebScrollbarPainterDelegate convertRectToLayer:]): (-[WebScrollbarPainterDelegate shouldUseLayerPerPartForScrollerImp:]): Before we kick off a scroll animation, set the current painting characteristics so they are up-to-date in case we are scrolling on the scrolling thread. (-[WebScrollbarPainterDelegate setUpAlphaAnimation:scrollerPainter:part:WebCore::animateAlphaTo:duration:]): (-[WebScrollbarPainterDelegate scrollerImp:animateKnobAlphaTo:duration:]): (-[WebScrollbarPainterDelegate scrollerImp:animateTrackAlphaTo:duration:]): (WebCore::ScrollAnimatorMac::didAddVerticalScrollbar): (WebCore::ScrollAnimatorMac::didAddHorizontalScrollbar): (WebCore::ScrollAnimatorMac::verticalScrollbarLayerDidChange): (WebCore::ScrollAnimatorMac::horizontalScrollbarLayerDidChange): Only paint the scrollbars through ScrollbarThemeMac if they are NOT being updated by the scrolling thread. * platform/mac/ScrollbarThemeMac.h: * platform/mac/ScrollbarThemeMac.mm: (WebCore::ScrollbarThemeMac::setCurrentPaintCharacteristics): (WebCore::scrollbarPainterPaint): (WebCore::ScrollbarThemeMac::paint): Back to #1. * rendering/RenderLayer.cpp: (WebCore::RenderLayer::updatesScrollLayerPositionOnMainThread): * rendering/RenderLayer.h: * rendering/RenderLayerCompositor.cpp: (WebCore::RenderLayerCompositor::updateOverflowControlsLayers): * rendering/RenderListBox.h: Source/WebKit2: New pure virtual function. * WebProcess/Plugins/PDF/PDFPlugin.h: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157253 268f45cc-cd09-0410-ab3c-d52691b4dbfc
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I don't have a repro for this.
The text was updated successfully, but these errors were encountered: