WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
196409
Cache bytecode for jsc.cpp helpers and fix CachedStringImpl
https://bugs.webkit.org/show_bug.cgi?id=196409
Summary
Cache bytecode for jsc.cpp helpers and fix CachedStringImpl
Tadeu Zagallo
Reported
2019-03-29 15:09:06 PDT
...
Attachments
Patch
(9.92 KB, patch)
2019-03-29 15:11 PDT
,
Tadeu Zagallo
no flags
Details
Formatted Diff
Diff
Patch
(12.32 KB, patch)
2019-03-30 01:22 PDT
,
Tadeu Zagallo
no flags
Details
Formatted Diff
Diff
Patch for landing
(12.59 KB, patch)
2019-04-04 08:01 PDT
,
Tadeu Zagallo
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
Tadeu Zagallo
Comment 1
2019-03-29 15:11:38 PDT
Created
attachment 366309
[details]
Patch
Saam Barati
Comment 2
2019-03-29 15:57:13 PDT
Comment on
attachment 366309
[details]
Patch This needs a test.
Saam Barati
Comment 3
2019-03-29 16:00:44 PDT
Comment on
attachment 366309
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=366309&action=review
> Source/JavaScriptCore/ChangeLog:18 > + had different shapes. That was a problem if a StringImpl* was originally cached as a > + CachedPtr<CachedStringImpl>, and later if we tried to cache it as CachedPtr<CachedUniquedStringImpl> > + we would find a cache entry and store the offset of the already cached CachedStringImpl. > + We keep the same behavior, but make CachedStringImpl and CachedUniquedStringImpl share the same shape.
I don't understand your explanation here. What exactly were we storing that was the problem?
Tadeu Zagallo
Comment 4
2019-03-30 01:02:47 PDT
Comment on
attachment 366309
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=366309&action=review
>> Source/JavaScriptCore/ChangeLog:18 >> + We keep the same behavior, but make CachedStringImpl and CachedUniquedStringImpl share the same shape. > > I don't understand your explanation here. What exactly were we storing that was the problem?
Yeah, this explanation got really confusing, I think I'll just list it as a sequence of steps. The problem is that the encoder keeps a map of pointers to offsets of already cached objects, in order to avoid caching the same object twice. If we have the same pointer being cached as two different cached types, that's an issue. I'll update this.
Tadeu Zagallo
Comment 5
2019-03-30 01:22:19 PDT
Created
attachment 366362
[details]
Patch
Saam Barati
Comment 6
2019-04-03 17:17:36 PDT
Comment on
attachment 366362
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=366362&action=review
> Source/JavaScriptCore/ChangeLog:30 > + which has a different shape and we crash.
Thanks for this explanation. It makes sense. You should also write a sentence on what the fix is. I wonder though if this shows us a more general bug in our encoding/decoding. I wonder if we should have a more general solution of type matters when encoding. So even if you have the same pointer twice, then you should encode it twice? Maybe this leads to other issues. It probably does, like if you encode a CodeBlock twice based on its type, that's probably bad. But the issue we have now is a base class needs to be aware of its subclasses, which ain't nice.
Tadeu Zagallo
Comment 7
2019-04-04 07:57:10 PDT
Comment on
attachment 366362
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=366362&action=review
>> Source/JavaScriptCore/ChangeLog:30 >> + which has a different shape and we crash. > > Thanks for this explanation. It makes sense. > > You should also write a sentence on what the fix is. > > I wonder though if this shows us a more general bug in our encoding/decoding. > > I wonder if we should have a more general solution of type matters when encoding. So even if you have the same pointer twice, then you should encode it twice? Maybe this leads to other issues. It probably does, like if you encode a CodeBlock twice based on its type, that's probably bad. > > But the issue we have now is a base class needs to be aware of its subclasses, which ain't nice.
I'll add a line about the fix. I think there are a couple things that should be fixed: 1) we can make UnlinkedStringJumpTable use UniquedStringImpl, this way we don't have to worry about this specific problem anymore, since that is the only place that uses CachedStringImpl. 2) You are right about the subclasses issue, but I think if we fix 1 there's no other place where we intentionally rely on that. e.g. I don't think we encode the same code block as both UnlinkedCodeBlock and as its subclass. In fact, we don't handle that properly, so I think it'd be interesting to add some validation. I'll land this with the update to the ChangeLog and work on these 2 follow-ups.
Tadeu Zagallo
Comment 8
2019-04-04 08:01:20 PDT
Created
attachment 366712
[details]
Patch for landing
WebKit Commit Bot
Comment 9
2019-04-04 08:41:13 PDT
Comment on
attachment 366712
[details]
Patch for landing Clearing flags on attachment: 366712 Committed
r243869
: <
https://trac.webkit.org/changeset/243869
>
WebKit Commit Bot
Comment 10
2019-04-04 08:41:15 PDT
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 11
2019-04-04 08:42:20 PDT
<
rdar://problem/49608083
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug