If we want a singleton object to have, or not have, some property then we shouldn't deoptimize just because some other unrelated property was added (or removed).
Attachment 256789[details] did not pass style-queue:
ERROR: Source/JavaScriptCore/dfg/DFGGraph.h:694: The parameter name "structure" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.h:64: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.h:65: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.h:66: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.h:67: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.h:131: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.h:132: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
Total errors found: 7 in 11 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Here's the plan for what I'll do: This work will replace StructureChain with the concept of an ObjectPropertyConditionSet. Each of the ObjectPropertyConditions in the set can either be validated using a structure check, or they can be turned into a transition watchpoint. The transition watchpoint can then revalidate the ObjectPropertyCondition when it fires, to see if a new transition watchpoint could be set.
This will eliminate StructureChain and the "normalizeStructureChain" code, and replace it with new code that reasons about ObjectPropertyConditions. It's not a small change. But I realized when running simple tests that we need our inline caches to also use adaptive watchpoints, or else the profiling feedback to the DFG/FTL will be bogus.
Attachment 257068[details] did not pass style-queue:
ERROR: Source/JavaScriptCore/dfg/DFGCommonData.h:32: Alphabetical sorting problem. [build/include_order] [4]
ERROR: Source/JavaScriptCore/bytecode/PutByIdVariant.h:63: The parameter name "structure" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:30: Missing spaces around / [whitespace/operators] [3]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:91: The parameter name "object" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:155: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:157: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:159: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:163: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:163: The parameter name "globalObject" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:45: The parameter name "codeBlock" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.h:53: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.h:54: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/StructureStubInfo.cpp:83: Multi line control clauses should use braces. [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/bytecode/StructureStubInfo.cpp:84: When wrapping a line, only indent 4 spaces. [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/bytecode/PolymorphicGetByIdList.cpp:44: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:38: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:39: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.cpp:38: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.cpp:39: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/GetByIdVariant.cpp:40: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/GetByIdVariant.cpp:49: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.h:40: The parameter name "codeBlock" adds no information, so it should be removed. [readability/parameter_name] [5]
Total errors found: 22 in 40 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Created attachment 257713[details]
OMG it's a 58x speed-up
It's a 58x speed-up on this test:
function foo(o) {
var result = 0;
for (var i = 0; i < 100; ++i)
result += o.f;
return result;
}
noInline(foo);
var p = {f:42};
var o = Object.create(p);
for (var i = 0; i < 10000; ++i) {
//print("test: i = " + i);
//print("Adding property.");
p["i" + i] = i;
//print("Calling foo().");
var result = foo(o);
if (result != 42 * 100)
throw "Error: bad result: " + result;
}
Attachment 257713[details] did not pass style-queue:
ERROR: Source/JavaScriptCore/dfg/DFGCommonData.h:32: Alphabetical sorting problem. [build/include_order] [4]
ERROR: Source/JavaScriptCore/bytecode/PutByIdVariant.h:63: The parameter name "structure" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:91: The parameter name "object" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:156: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:158: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:160: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:164: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:164: The parameter name "globalObject" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:45: The parameter name "codeBlock" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.h:53: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.h:54: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/StructureStubInfo.cpp:83: Multi line control clauses should use braces. [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/bytecode/StructureStubInfo.cpp:84: When wrapping a line, only indent 4 spaces. [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/bytecode/PolymorphicGetByIdList.cpp:43: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:38: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:39: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.cpp:38: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.cpp:39: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/GetByIdVariant.cpp:40: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/GetByIdVariant.cpp:49: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.h:40: The parameter name "codeBlock" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/dfg/DFGByteCodeParser.cpp:212: The parameter name "variant" adds no information, so it should be removed. [readability/parameter_name] [5]
Total errors found: 22 in 49 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Created attachment 257715[details]
Archive of layout-test-results from ews103 for mac-mavericks
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103 Port: mac-mavericks Platform: Mac OS X 10.9.5
Created attachment 257717[details]
Archive of layout-test-results from ews105 for mac-mavericks-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews105 Port: mac-mavericks-wk2 Platform: Mac OS X 10.9.5
Looks like this change breaks custom setter/getter caching. Should be easy to fix that. Basically, a "hit" on a custom setter/getter actually requires a structure check, rather than an object property condition. I think we just want an ObjectPropertyCondition that says "ExactStructure".
Attachment 257913[details] did not pass style-queue:
ERROR: Source/JavaScriptCore/dfg/DFGCommonData.h:32: Alphabetical sorting problem. [build/include_order] [4]
ERROR: Source/JavaScriptCore/bytecode/PutByIdVariant.h:63: The parameter name "structure" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:91: The parameter name "object" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:157: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:159: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:161: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:164: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:168: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:168: The parameter name "globalObject" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:45: The parameter name "codeBlock" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.h:53: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.h:54: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/StructureStubInfo.cpp:83: Multi line control clauses should use braces. [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/bytecode/StructureStubInfo.cpp:84: When wrapping a line, only indent 4 spaces. [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/bytecode/PolymorphicGetByIdList.cpp:43: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:38: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:39: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.cpp:38: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.cpp:39: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/GetByIdVariant.cpp:40: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/GetByIdVariant.cpp:49: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.h:40: The parameter name "codeBlock" adds no information, so it should be removed. [readability/parameter_name] [5]
Total errors found: 22 in 65 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Attachment 257941[details] did not pass style-queue:
ERROR: Source/JavaScriptCore/dfg/DFGCommonData.h:32: Alphabetical sorting problem. [build/include_order] [4]
ERROR: Source/JavaScriptCore/bytecode/PutByIdVariant.h:63: The parameter name "structure" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/PropertyCondition.h:286: The parameter name "value" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:91: The parameter name "object" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:157: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:159: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:161: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:164: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:168: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:168: The parameter name "globalObject" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:45: The parameter name "codeBlock" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.h:53: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.h:54: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/StructureStubInfo.cpp:83: Multi line control clauses should use braces. [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/bytecode/StructureStubInfo.cpp:84: When wrapping a line, only indent 4 spaces. [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/bytecode/PolymorphicGetByIdList.cpp:43: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:38: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:39: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.cpp:38: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.cpp:39: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/GetByIdVariant.cpp:40: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/GetByIdVariant.cpp:49: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.h:40: The parameter name "codeBlock" adds no information, so it should be removed. [readability/parameter_name] [5]
Total errors found: 23 in 69 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Attachment 257943[details] did not pass style-queue:
ERROR: Source/JavaScriptCore/dfg/DFGCommonData.h:32: Alphabetical sorting problem. [build/include_order] [4]
ERROR: Source/JavaScriptCore/bytecode/PutByIdVariant.h:63: The parameter name "structure" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/PropertyCondition.h:286: The parameter name "value" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:91: The parameter name "object" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:157: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:159: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:161: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:164: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:168: The parameter name "vm" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:168: The parameter name "globalObject" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:45: The parameter name "codeBlock" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.h:53: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.h:54: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/StructureStubInfo.cpp:83: Multi line control clauses should use braces. [whitespace/braces] [4]
ERROR: Source/JavaScriptCore/bytecode/StructureStubInfo.cpp:84: When wrapping a line, only indent 4 spaces. [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/bytecode/PolymorphicGetByIdList.cpp:43: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:38: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:39: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.cpp:38: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.cpp:39: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/GetByIdVariant.cpp:40: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/GetByIdVariant.cpp:49: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.h:40: The parameter name "codeBlock" adds no information, so it should be removed. [readability/parameter_name] [5]
Total errors found: 23 in 69 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Attachment 257960[details] did not pass style-queue:
ERROR: Source/JavaScriptCore/bytecode/PropertyCondition.h:286: The parameter name "value" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.h:53: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.h:54: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/PolymorphicGetByIdList.cpp:43: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:38: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:39: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.cpp:38: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.cpp:39: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/GetByIdVariant.cpp:40: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/GetByIdVariant.cpp:49: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3]
Total errors found: 10 in 70 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 257943[details]
more fixes
View in context: https://bugs.webkit.org/attachment.cgi?id=257943&action=review
I got halfway.
> Source/JavaScriptCore/bytecode/CodeBlockJettisoningWatchpoint.cpp:-43
> - if (isOnList())
> - remove();
Why don't we need this anymore? Who will remove us from the list?
> Source/JavaScriptCore/bytecode/GetByIdVariant.h:59
> + // The presence of a condition set means that this is a prototype load.
> + const ObjectPropertyConditionSet& conditionSet() const { return m_conditionSet; }
I guess you mean if the condition set is not empty? It is always present, since it is a reference.
> Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.cpp:63
> +bool ObjectPropertyConditionSet::hasOneSlotBaseCondition() const
Shouldn't this be called "hasOnePresenceCondition"? What did you mean by "slot base" here?
> Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.cpp:68
> +ObjectPropertyCondition ObjectPropertyConditionSet::slotBaseCondition() const
Same here.
> Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:42
> +// Empty: There are no special conditions that need to be met.
> +// Invalid: The heap access is never valid.
> +// Non-empty: There are some ObjectPropertyConditions that need to be valid.
Empty: The heap access is always valid.
Invalid: The heap access is never valid.
Non-empty: The heap access is valid if all the ObjectPropertyConditions in the set are valid.
> Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:58
> + static ObjectPropertyConditionSet nonEmpty(const Vector<ObjectPropertyCondition>& vector)
> + {
> + if (vector.isEmpty())
> + return ObjectPropertyConditionSet();
It's kind of weird that nonEmpty() can return an empty set. I would either assert here or call this valid() or create().
> Source/JavaScriptCore/bytecode/PolymorphicGetByIdList.h:94
> + ObjectPropertyConditionSet m_conditionSet; // FIXME what about barriers?
Can has fix for this? Seems like somebody needs to mark this condition set since it points to some JSObjects.
> Source/JavaScriptCore/bytecode/PolymorphicPutByIdList.cpp:66
> bool PutByIdAccess::visitWeak(RepatchBuffer& repatchBuffer) const
Do we need to mark m_conditionSet here, since it points to JSObjects?
(In reply to comment #52)
> Comment on attachment 257943[details]
> more fixes
>
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=257943&action=review
>
> I got halfway.
>
> > Source/JavaScriptCore/bytecode/CodeBlockJettisoningWatchpoint.cpp:-43
> > - if (isOnList())
> > - remove();
>
> Why don't we need this anymore? Who will remove us from the list?
The WatchpointSet will remove us before calling fire(). That change already landed in trunk.
>
> > Source/JavaScriptCore/bytecode/GetByIdVariant.h:59
> > + // The presence of a condition set means that this is a prototype load.
> > + const ObjectPropertyConditionSet& conditionSet() const { return m_conditionSet; }
>
> I guess you mean if the condition set is not empty? It is always present,
> since it is a reference.
Right. Non-empty.
>
> > Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.cpp:63
> > +bool ObjectPropertyConditionSet::hasOneSlotBaseCondition() const
>
> Shouldn't this be called "hasOnePresenceCondition"? What did you mean by
> "slot base" here?
The convention for condition sets used by prototype accesses is that the "slot base" of the prototype access is the one and only presence in the set. So, "slot base" and "presence" mean the same thing here. I believe that "slot base" is accepted lingo within our inline caches (PropertySlot::slotBase() for example)
>
> > Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.cpp:68
> > +ObjectPropertyCondition ObjectPropertyConditionSet::slotBaseCondition() const
>
> Same here.
>
> > Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:42
> > +// Empty: There are no special conditions that need to be met.
> > +// Invalid: The heap access is never valid.
> > +// Non-empty: There are some ObjectPropertyConditions that need to be valid.
>
> Empty: The heap access is always valid.
> Invalid: The heap access is never valid.
> Non-empty: The heap access is valid if all the ObjectPropertyConditions in
> the set are valid.
OK.
>
> > Source/JavaScriptCore/bytecode/ObjectPropertyConditionSet.h:58
> > + static ObjectPropertyConditionSet nonEmpty(const Vector<ObjectPropertyCondition>& vector)
> > + {
> > + if (vector.isEmpty())
> > + return ObjectPropertyConditionSet();
>
> It's kind of weird that nonEmpty() can return an empty set. I would either
> assert here or call this valid() or create().
I'll call it create().
>
> > Source/JavaScriptCore/bytecode/PolymorphicGetByIdList.h:94
> > + ObjectPropertyConditionSet m_conditionSet; // FIXME what about barriers?
>
> Can has fix for this? Seems like somebody needs to mark this condition set
> since it points to some JSObjects.
Ooops, should have removed the FIXME. PropertyCondition, ObjectPropertyCondition, and ObjectPropertyConditionSet do barriers properly and support weak semantics through isStillLive() and areStillLive(). When creating a condition in Repatch.cpp, we use methods like PropertyCondition::presence(vm, owner, ...) which triggers a barrier on owner. In the case of PolymorphicGetByIdList, it has a visitWeak method that does:
if (!m_conditionSet.areStillLive())
return false;
>
> > Source/JavaScriptCore/bytecode/PolymorphicPutByIdList.cpp:66
> > bool PutByIdAccess::visitWeak(RepatchBuffer& repatchBuffer) const
>
> Do we need to mark m_conditionSet here, since it points to JSObjects?
No, because:
if (!m_conditionSet.areStillLive())
return false;
That's right at the top of PutByIdAccess::visitWeak(). It will blow away the inline cache if any of the objects in the condition set are dead.
Attachment 257998[details] did not pass style-queue:
ERROR: Source/JavaScriptCore/bytecode/PropertyCondition.h:286: The parameter name "value" adds no information, so it should be removed. [readability/parameter_name] [5]
ERROR: Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.h:53: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/StructureStubClearingWatchpoint.h:54: Wrong number of spaces before statement. (expected: 12) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/PolymorphicGetByIdList.cpp:43: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:38: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:39: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.cpp:38: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/dfg/DFGAdaptiveStructureWatchpoint.cpp:39: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/GetByIdVariant.cpp:40: Wrong number of spaces before statement. (expected: 8) [whitespace/indent] [4]
ERROR: Source/JavaScriptCore/bytecode/GetByIdVariant.cpp:49: Weird number of spaces at line-start. Are you using a 4-space indent? [whitespace/indent] [3]
Total errors found: 10 in 71 files
If any of these errors are false positives, please file a bug against check-webkit-style.
Comment on attachment 257998[details]
revised patch
View in context: https://bugs.webkit.org/attachment.cgi?id=257998&action=review
r=me
> Source/JavaScriptCore/bytecode/GetByIdVariant.h:59
> + // A non-empty condition set means that this is a prototype load.
> + const ObjectPropertyConditionSet& conditionSet() const { return m_conditionSet; }
What guarantees that GetByIdVariant will not use a condition set to test for a constant (in a non-prototype load)?
> Source/JavaScriptCore/bytecode/ObjectPropertyCondition.h:147
> + return WTF::PtrHash<JSObject*>::hash(m_object) + m_condition.hash();
I think that XOR is a better way to mix bits in a hash than ADD, since ADD will tend to make low bits zero. Another option is to WTF::pairIntHash the two hash codes.
> Source/JavaScriptCore/bytecode/PropertyCondition.cpp:204
> + switch (m_kind) {
> + case Presence:
> + case Absence:
> + case Equivalence:
> + return structure->needImpurePropertyWatchpoint();
> + default:
> + return false;
> + }
I think what you're saying here is that objects that have impure getOwnPropertySlot implementations may start returning new properties and may stop returning old properties but must not start returning new setters (without a change in structure). Is that right?
As an empirical matter, I believe this observation is true.
Still, I think it's unnecessarily risky to turn this observation into an API. Is it a clear speedup to do this? "My property accesses are impure" is a pretty strong warning. I would forgive a programmer for not knowing that the warning did not cover (absence of) setters.
> Source/JavaScriptCore/bytecode/PropertyCondition.cpp:214
> + // Currently we assume that an impure property can cause a property to appear, and can also
> + // "shadow" an existing JS property on the same object. Hence it affects both presence and
> + // absence. It doesn't affect AbsenceOfSetter because impure properties aren't ever setters.
Aha, yeah, I guess you say that here.
I think we should either remove this behavior or, if it's a necessary speedup, document it in JSTypeInfo.h next to the definition of HasImpureGetOwnPropertySlot.
> Source/JavaScriptCore/bytecode/PropertyCondition.h:179
> + unsigned result = WTF::PtrHash<UniquedStringImpl*>::hash(m_uid) + static_cast<unsigned>(m_kind);
> + switch (m_kind) {
> + case Presence:
> + result += u.presence.offset;
> + result += u.presence.attributes;
> + break;
> + case Absence:
> + case AbsenceOfSetter:
> + result += WTF::PtrHash<JSObject*>::hash(u.absence.prototype);
> + break;
> + case Equivalence:
> + result += EncodedJSValueHash::hash(u.equivalence.value);
> + break;
> + }
I think that XOR is a better way to mix bits in a hash than ADD, since ADD will tend to make low bits zero. Another option is to WTF::pairIntHash the two hash codes.
(In reply to comment #56)
> Comment on attachment 257998[details]
> revised patch
>
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=257998&action=review
>
> r=me
>
> > Source/JavaScriptCore/bytecode/GetByIdVariant.h:59
> > + // A non-empty condition set means that this is a prototype load.
> > + const ObjectPropertyConditionSet& conditionSet() const { return m_conditionSet; }
>
> What guarantees that GetByIdVariant will not use a condition set to test for
> a constant (in a non-prototype load)?
Just the fact that Repatch does not such optimization. We effectively assert as much because of our use of slotBaseCondition() all over the place.
>
> > Source/JavaScriptCore/bytecode/ObjectPropertyCondition.h:147
> > + return WTF::PtrHash<JSObject*>::hash(m_object) + m_condition.hash();
>
> I think that XOR is a better way to mix bits in a hash than ADD, since ADD
> will tend to make low bits zero.
Really? The effect on the lowest bit of ADD is identical to XOR:
0 + 0 = 0 0 ^ 0 = 0
0 + 1 = 1 0 ^ 1 = 1
1 + 0 = 1 1 ^ 0 = 1
1 + 1 = 0 1 ^ 1 = 0
> Another option is to WTF::pairIntHash the
> two hash codes.
I changed it to XOR. I don't currently have evidence that this hashtable needs to be very optimized.
>
> > Source/JavaScriptCore/bytecode/PropertyCondition.cpp:204
> > + switch (m_kind) {
> > + case Presence:
> > + case Absence:
> > + case Equivalence:
> > + return structure->needImpurePropertyWatchpoint();
> > + default:
> > + return false;
> > + }
>
> I think what you're saying here is that objects that have impure
> getOwnPropertySlot implementations may start returning new properties and
> may stop returning old properties but must not start returning new setters
> (without a change in structure). Is that right?
Yes.
>
> As an empirical matter, I believe this observation is true.
>
> Still, I think it's unnecessarily risky to turn this observation into an
> API. Is it a clear speedup to do this? "My property accesses are impure" is
> a pretty strong warning. I would forgive a programmer for not knowing that
> the warning did not cover (absence of) setters.
This code is just preserving what our old prototype chain normalization did for put_by_id transitions.
AbsenceOfSetter comes into play for the prototype chain during a put_by_id transition. A getOwnPropertySlot on a prototype cannot intercept the put_by_id - only an actual JS setter can. Hence why AbsenceOfSetter behaves this way. More on this below...
>
> > Source/JavaScriptCore/bytecode/PropertyCondition.cpp:214
> > + // Currently we assume that an impure property can cause a property to appear, and can also
> > + // "shadow" an existing JS property on the same object. Hence it affects both presence and
> > + // absence. It doesn't affect AbsenceOfSetter because impure properties aren't ever setters.
>
> Aha, yeah, I guess you say that here.
>
> I think we should either remove this behavior or, if it's a necessary
> speedup, document it in JSTypeInfo.h next to the definition of
> HasImpureGetOwnPropertySlot.
This isn't new behavior, we've always done it this way. In a way, I'm just preserving what we used to do for put_by_id transitions.
But it's more than that. The getOwnPropertySlot API cannot cause a setter to appear, because the way to add a property to an object is you do JSValue::put(), and that method doesn't call getOwnPropertySlot - it directly consults the structures of the prototype chain to find setters. Hence, there is nothing you could do in getOwnPropertySlot to cause a setter to appear on a prototype. Therefore, this has nothing to do with HasImpureGetOwnPropertySlot because no matter how impure you made your getOwnPropertySlot, it still wouldn't affect setters.
I realize that this is a somewhat surprising behavior of our system, but it doesn't have anything to do with our patch, and it also doesn't have anything to do with the HasImpureGetOwnPropertySlot flag.
>
> > Source/JavaScriptCore/bytecode/PropertyCondition.h:179
> > + unsigned result = WTF::PtrHash<UniquedStringImpl*>::hash(m_uid) + static_cast<unsigned>(m_kind);
> > + switch (m_kind) {
> > + case Presence:
> > + result += u.presence.offset;
> > + result += u.presence.attributes;
> > + break;
> > + case Absence:
> > + case AbsenceOfSetter:
> > + result += WTF::PtrHash<JSObject*>::hash(u.absence.prototype);
> > + break;
> > + case Equivalence:
> > + result += EncodedJSValueHash::hash(u.equivalence.value);
> > + break;
> > + }
>
> I think that XOR is a better way to mix bits in a hash than ADD, since ADD
> will tend to make low bits zero. Another option is to WTF::pairIntHash the
> two hash codes.
Changed to XOR, though I'm curious what you mean by the low bits becoming zero.
(In reply to comment #57)
> (In reply to comment #56)
> > Comment on attachment 257998[details]
> > revised patch
> >
> > View in context:
> > https://bugs.webkit.org/attachment.cgi?id=257998&action=review
> >
> > r=me
> >
> > > Source/JavaScriptCore/bytecode/GetByIdVariant.h:59
> > > + // A non-empty condition set means that this is a prototype load.
> > > + const ObjectPropertyConditionSet& conditionSet() const { return m_conditionSet; }
> >
> > What guarantees that GetByIdVariant will not use a condition set to test for
> > a constant (in a non-prototype load)?
>
> Just the fact that Repatch does not such optimization. We effectively
> assert as much because of our use of slotBaseCondition() all over the place.
>
> >
> > > Source/JavaScriptCore/bytecode/ObjectPropertyCondition.h:147
> > > + return WTF::PtrHash<JSObject*>::hash(m_object) + m_condition.hash();
> >
> > I think that XOR is a better way to mix bits in a hash than ADD, since ADD
> > will tend to make low bits zero.
>
> Really? The effect on the lowest bit of ADD is identical to XOR:
>
> 0 + 0 = 0 0 ^ 0 = 0
> 0 + 1 = 1 0 ^ 1 = 1
> 1 + 0 = 1 1 ^ 0 = 1
> 1 + 1 = 0 1 ^ 1 = 0
>
Presumably talking about more than the last bit? Last n bits become biased towards containing a 0 bit (with n > 1)
(In reply to comment #58)
> (In reply to comment #57)
> > (In reply to comment #56)
> > > Comment on attachment 257998[details]
> > > revised patch
> > >
> > > View in context:
> > > https://bugs.webkit.org/attachment.cgi?id=257998&action=review
> > >
> > > r=me
> > >
> > > > Source/JavaScriptCore/bytecode/GetByIdVariant.h:59
> > > > + // A non-empty condition set means that this is a prototype load.
> > > > + const ObjectPropertyConditionSet& conditionSet() const { return m_conditionSet; }
> > >
> > > What guarantees that GetByIdVariant will not use a condition set to test for
> > > a constant (in a non-prototype load)?
> >
> > Just the fact that Repatch does not such optimization. We effectively
> > assert as much because of our use of slotBaseCondition() all over the place.
> >
> > >
> > > > Source/JavaScriptCore/bytecode/ObjectPropertyCondition.h:147
> > > > + return WTF::PtrHash<JSObject*>::hash(m_object) + m_condition.hash();
> > >
> > > I think that XOR is a better way to mix bits in a hash than ADD, since ADD
> > > will tend to make low bits zero.
> >
> > Really? The effect on the lowest bit of ADD is identical to XOR:
> >
> > 0 + 0 = 0 0 ^ 0 = 0
> > 0 + 1 = 1 0 ^ 1 = 1
> > 1 + 0 = 1 1 ^ 0 = 1
> > 1 + 1 = 0 1 ^ 1 = 0
> >
> Presumably talking about more than the last bit? Last n bits become biased
> towards containing a 0 bit (with n > 1)
Ignore me, it's for the best, i was thinking in terms of actual addition (too much manual adder implementation lately)
> > As an empirical matter, I believe this observation is true.
> >
> > Still, I think it's unnecessarily risky to turn this observation into an
> > API. Is it a clear speedup to do this? "My property accesses are impure" is
> > a pretty strong warning. I would forgive a programmer for not knowing that
> > the warning did not cover (absence of) setters.
>
> This code is just preserving what our old prototype chain normalization did
> for put_by_id transitions.
Oops. I forgot that setters are only relevant on the put path.
(In reply to comment #59)
> (In reply to comment #58)
> > (In reply to comment #57)
> > > (In reply to comment #56)
> > > > Comment on attachment 257998[details]
> > > > revised patch
> > > >
> > > > View in context:
> > > > https://bugs.webkit.org/attachment.cgi?id=257998&action=review
> > > >
> > > > r=me
> > > >
> > > > > Source/JavaScriptCore/bytecode/GetByIdVariant.h:59
> > > > > + // A non-empty condition set means that this is a prototype load.
> > > > > + const ObjectPropertyConditionSet& conditionSet() const { return m_conditionSet; }
> > > >
> > > > What guarantees that GetByIdVariant will not use a condition set to test for
> > > > a constant (in a non-prototype load)?
> > >
> > > Just the fact that Repatch does not such optimization. We effectively
> > > assert as much because of our use of slotBaseCondition() all over the place.
> > >
> > > >
> > > > > Source/JavaScriptCore/bytecode/ObjectPropertyCondition.h:147
> > > > > + return WTF::PtrHash<JSObject*>::hash(m_object) + m_condition.hash();
> > > >
> > > > I think that XOR is a better way to mix bits in a hash than ADD, since ADD
> > > > will tend to make low bits zero.
> > >
> > > Really? The effect on the lowest bit of ADD is identical to XOR:
> > >
> > > 0 + 0 = 0 0 ^ 0 = 0
> > > 0 + 1 = 1 0 ^ 1 = 1
> > > 1 + 0 = 1 1 ^ 0 = 1
> > > 1 + 1 = 0 1 ^ 1 = 0
> > >
> > Presumably talking about more than the last bit? Last n bits become biased
> > towards containing a 0 bit (with n > 1)
>
>
> Ignore me, it's for the best, i was thinking in terms of actual addition
> (too much manual adder implementation lately)
Can you explain, for my edification?
I often use + instead of ^ when constructing a hash function that is a combination of other hash functions, under the assumption that it just doesn't matter. At the instruction set level, + is every-so-slightly cheaper since you can do a three-operand + on x86 but ^ only comes in two-operand forms. Heck, you can even do a four-operand + on x86: a = b + c + d so long as d is an immediate. If it's the case that ^ is fundamentally better, I'd like to know!
Not that it matters in practice for a data structure such as this one. We already have a bunch of data structures like this that combine the hash codes of the various fields using something naive like +, and we don't really have good evidence that improving those hash functions would improve the bottom line.
> Can you explain, for my edification?
My thinking was simply that XOR has uniform distribution over all the bits, while ADD biases toward the top of the number line due to carry, therefore reducing uniformity. I think this might be extra true in the Presence hash, which adds raw integers (and not integer hashes). I think this might also be extra important in small tables, since we mask off the high bits of the hash code, making bias in the low bits more harmful.
For example, if it were common for attributes to be 0b11, the ADD hash would collide 100% of the time in a table with capacity four.
A bit of googling suggests that WTF::pairIntHash, which uses a multiplication method, best avoids the pitfalls of both ADD and XOR. But you have to pay for the multiplication.
I haven't done a lot of research on this. Perhaps I am mistaken.
2015-07-13 23:28 PDT, Filip Pizlo
2015-07-14 13:23 PDT, Filip Pizlo
2015-07-15 16:04 PDT, Filip Pizlo
2015-07-15 16:20 PDT, Filip Pizlo
2015-07-15 20:16 PDT, Filip Pizlo
2015-07-15 21:28 PDT, Filip Pizlo
2015-07-16 00:47 PDT, Filip Pizlo
2015-07-16 13:37 PDT, Filip Pizlo
2015-07-16 19:54 PDT, Filip Pizlo
2015-07-17 23:33 PDT, Filip Pizlo
2015-07-18 13:40 PDT, Filip Pizlo
2015-07-18 21:02 PDT, Filip Pizlo
2015-07-19 16:14 PDT, Filip Pizlo
2015-07-23 14:10 PDT, Filip Pizlo
2015-07-23 15:43 PDT, Filip Pizlo
2015-07-23 19:34 PDT, Filip Pizlo
2015-07-23 21:27 PDT, Filip Pizlo
2015-07-24 13:13 PDT, Filip Pizlo
2015-07-24 15:16 PDT, Filip Pizlo
2015-07-27 14:46 PDT, Filip Pizlo
2015-07-27 22:56 PDT, Filip Pizlo
2015-07-28 15:30 PDT, Filip Pizlo
2015-07-28 17:32 PDT, Filip Pizlo
2015-07-28 18:23 PDT, Build Bot
2015-07-28 18:35 PDT, Build Bot
2015-07-29 14:26 PDT, Filip Pizlo
2015-07-29 15:37 PDT, Filip Pizlo
2015-07-29 16:15 PDT, Filip Pizlo
2015-07-29 21:30 PDT, Filip Pizlo
2015-07-30 14:07 PDT, Filip Pizlo
2015-07-30 23:03 PDT, Filip Pizlo
2015-07-31 00:41 PDT, Filip Pizlo
2015-07-31 12:16 PDT, Filip Pizlo
2015-07-31 12:25 PDT, Filip Pizlo
2015-07-31 12:32 PDT, Filip Pizlo
2015-07-31 14:23 PDT, Filip Pizlo
2015-07-31 23:12 PDT, Filip Pizlo