RESOLVED FIXED 146425
[Content Extensions] Add 3 byte jump size
https://bugs.webkit.org/show_bug.cgi?id=146425
Summary [Content Extensions] Add 3 byte jump size
Alex Christensen
Reported 2015-06-29 14:05:31 PDT
Many jumps can be represented with 3 bytes, and adding an Int24 jump type significantly reduces byte code size.
Attachments
Patch (6.61 KB, patch)
2015-06-29 14:09 PDT, Alex Christensen
no flags
Patch (6.61 KB, patch)
2015-06-29 14:18 PDT, Alex Christensen
no flags
Patch (6.66 KB, patch)
2015-07-01 16:23 PDT, Alex Christensen
no flags
Patch (6.70 KB, patch)
2015-07-01 19:10 PDT, Alex Christensen
darin: review+
Alex Christensen
Comment 1 2015-06-29 14:09:37 PDT
Alex Christensen
Comment 2 2015-06-29 14:14:25 PDT
This reduced total byte code size in a large test from 14970936 bytes to 13207142 bytes.
Alex Christensen
Comment 3 2015-06-29 14:18:59 PDT
Benjamin Poulain
Comment 4 2015-06-29 15:12:25 PDT
Comment on attachment 255777 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=255777&action=review > Source/WebCore/contentextensions/DFABytecode.h:96 > + if (longestPossibleJump < 256 * 256 * 256 && longestPossibleJump >= -256 * 256 * 256) It would prefer if "256 * 256 * 256 - 1" and "256 * 256 * 256" had names (Int24Min and Int24Max) > Source/WebCore/contentextensions/DFABytecodeCompiler.cpp:374 > + RELEASE_ASSERT(distance >= -256 * 256 * 256 && distance < 256 * 256 * 256); Ditto. > Source/WebCore/contentextensions/DFABytecodeInterpreter.cpp:90 > + return getBits<uint16_t>(bytecode, bytecodeLength, index, pagesUsed) & static_cast<int32_t>(getBits<int8_t>(bytecode, bytecodeLength, index + sizeof(uint16_t), pagesUsed)) << 16; "Binary and" between the two parts?
Alex Christensen
Comment 5 2015-07-01 16:23:13 PDT
Alex Christensen
Comment 6 2015-07-01 19:10:13 PDT
Darin Adler
Comment 7 2015-07-08 12:30:47 PDT
Comment on attachment 255981 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=255981&action=review I’m saying review+ but I think this change without testing is really risky. > Source/WebCore/contentextensions/DFABytecode.h:90 > +const int32_t Int24Max = 256 * 256 * 256 - 1; > +const int32_t Int24Min = -256 * 256 * 256; I believe these are incorrect. It should be 128 * 256 * 256. And that means that we need to figure out some way to test this. It shouldn’t just be guesswork on my part! I think these would be easier to read in hex like this: const int32_t Int24Max = 0x007FFFFFF; const int32_t Int24Max = 0xFF800000; Or: const int32_t Int24Max = 0x007FFFFFF; const int32_t Int24Max = -0x00800000; Or with shifting like this: const int32_t Int24Max = (1 << 23) - 1; const int32_t Int24Min = -(1 << 23); > Source/WebCore/contentextensions/DFABytecodeCompiler.cpp:375 > + setBits<uint16_t>(m_bytecode, linkRecord.jumpLocation, static_cast<uint16_t>(distance)); Does this do the right thing for negative numbers?
Alex Christensen
Comment 8 2015-07-08 12:36:43 PDT
(In reply to comment #7) > Comment on attachment 255981 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=255981&action=review > > I’m saying review+ but I think this change without testing is really risky. I agree, and adding a test big enough to test large jumps like this would timeout while compiling. I'll look into writing a test before landing. > > Source/WebCore/contentextensions/DFABytecodeCompiler.cpp:375 > > + setBits<uint16_t>(m_bytecode, linkRecord.jumpLocation, static_cast<uint16_t>(distance)); > > Does this do the right thing for negative numbers? Yes. The sign is in the high bits, which I store as an int8_t.
Alex Christensen
Comment 9 2015-07-08 17:02:23 PDT
(In reply to comment #7) > Comment on attachment 255981 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=255981&action=review > > I’m saying review+ but I think this change without testing is really risky. > > > Source/WebCore/contentextensions/DFABytecode.h:90 > > +const int32_t Int24Max = 256 * 256 * 256 - 1; > > +const int32_t Int24Min = -256 * 256 * 256; > > I believe these are incorrect. It should be 128 * 256 * 256. And that means > that we need to figure out some way to test this. It shouldn’t just be > guesswork on my part! Those are indeed incorrect.
Alex Christensen
Comment 10 2015-07-09 16:34:51 PDT
Alex Christensen
Comment 11 2015-07-10 14:30:13 PDT
http://trac.webkit.org/changeset/186681 added some tests for this. Those tests would fail if either the | were incorrect or the Int24Max were incorrect.
Note You need to log in before you can comment on or make changes to this bug.