RESOLVED FIXED 204760
[JSC] Remove BytecodeCacheVersion.h 
https://bugs.webkit.org/show_bug.cgi?id=204760
Summary [JSC] Remove BytecodeCacheVersion.h
Tadeu Zagallo
Reported 2019-12-02 11:33:10 PST
...
Attachments
Patch (4.86 KB, patch)
2019-12-02 13:21 PST, Tadeu Zagallo 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Tadeu Zagallo
Comment 1 2019-12-02 13:21:46 PST
Created attachment 384651 [details] Patch
Mark Lam
Comment 2 2019-12-02 13:32:01 PST
Comment on attachment 384651 [details] Patch Are we guaranteed that the 2 places that "call" jscBytecodeCacheVersion() will produce the same value? Is there any chance that the time stamp changed by a small fraction between those 2?
Tadeu Zagallo
Comment 3 2019-12-02 13:49:30 PST
(In reply to Mark Lam from comment #2) > Comment on attachment 384651 [details] > Patch > > Are we guaranteed that the 2 places that "call" jscBytecodeCacheVersion() > will produce the same value? Is there any chance that the time stamp > changed by a small fraction between those 2? There are two calls to the function, but since __TIMESTAMP__ is a preprocessor macro[1] it will be replaced by a constant string before the parser runs, so it should always produce the same value. [1]: https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
Mark Lam
Comment 4 2019-12-02 13:52:17 PST
Comment on attachment 384651 [details] Patch r=me
WebKit Commit Bot
Comment 5 2019-12-02 14:45:32 PST
Comment on attachment 384651 [details] Patch Clearing flags on attachment: 384651 Committed r253010: <https://trac.webkit.org/changeset/253010>
WebKit Commit Bot
Comment 6 2019-12-02 14:45:34 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 7 2019-12-02 14:46:28 PST
<rdar://problem/57571599>
Saam Barati
Comment 8 2019-12-02 15:21:13 PST
Why is this correct? What about collisions?
Saam Barati
Comment 9 2019-12-02 15:23:48 PST
(In reply to Saam Barati from comment #8) > Why is this correct? What about collisions? This patch looks wrong. Before, we had a monotonically increasing number. Now, we’re using a hash function which is bound to have collisions.
Mark Lam
Comment 10 2019-12-02 15:24:49 PST
(In reply to Saam Barati from comment #9) > (In reply to Saam Barati from comment #8) > > Why is this correct? What about collisions? > > This patch looks wrong. Before, we had a monotonically increasing number. > Now, we’re using a hash function which is bound to have collisions. Hmmm, I agree. I should have thought of that.
Note You need to log in before you can comment on or make changes to this bug.