[webkit-dev] Why using structure address for inline caching in LLInt?

[Filip Pizlo]

It's an oversight, and it should be fixed.  LLInt should use the structure ID.  We used to just have a Structure* into the JSCell header, and so it made sense to compare to that directly.  The refactoring that brought structure IDs started by replacing all loads of the Structure* from the JSCell header with a load via the structure table, so that the logic could stay the same.  Then we optimized the most important paths (like the Baseline JIT inline caching) to use structure ID instead.  We should have also optimized the LLInt in this way, but apparently we forgot.

This would be a useful change to make, if you want to submit a patch. :-)

It's worth noting that most users of JSC that are interested in performance have the JIT enabled.  LLInt throughput doesn't matter that much in those cases.

-Filip


> On Mar 11, 2015, at 9:25 PM, Jiho Choi <jray319 at gmail.com> wrote:
> 
> Hi,
> 
> I was wondering why structure address is compared instead of structure ID for inline caching in LLInt. I thought about the case when structure table entry is garbage-collected, but it shouldn't be collected if there is bytecode instruction pointing to the entry. In addition, Baseline JIT is using structure ID.
> 
> Thanks,
> Jiho
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev