<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 12 (filtered medium)"><base href="x-msg://6392/"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><div><p class=MsoNormal><span style='color:#1F497D'>Hi,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p></div><div><div><p class=MsoNormal><span style='color:#1F497D'>|</span>The fact that we want to do cache/page management ourselves is a consequence of us having our own memory manager and our own JITs. The fact that we will continue to handle cache/page invalidation ourselves is a consequence of us wanting to kee<span style='color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>|</span> our memory manager even as we use LLVM for our top-tier JIT, because we believe that it is better-suited to our needs than the memory managers that the LLVM provides.<span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='color:#1F497D'>| </span>I can give you a more detailed answer on why we would like to keep this memory manager - but I figured I'd ask for clarification before writing that up.<o:p></o:p></p></div></div><div><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>So it sounds like you're saying: the LLVM code co-exists with a wider set of software and to work best across all of these a different memory manager to LLVM's. That makes sense. I was worried that there was some reason why the LLVM stuff was fundamentally misdesigned for JITing, which would suggest that misdesign ought to be considered.<o:p></o:p></span></p></div><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>One of my worries about delegating cache management is that it can be a source of very intermittent bugs: if you don't cache invalidate on the transition from data to code on ARM, 99% of the time everything works... </span><o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='color:#1F497D'>| </span>We've had JITs in WebKit for X86 (32 and 64), ARM (traditional and thumb2), and other architectures for years. I'm pretty sure we know how to do this.<o:p></o:p></p></div><div><p class=MsoNormal><span style='color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Sorry, I tried to phrase the (as I said, genuine) question as non-confrontationally as I could; I wasn't in any way implying that "serious JIT developers" (such as the WebKit guys yourselves) know exactly when you need to do cache invalidation. I'm thinking more in terms of smaller projects which just want to use LLVM rather than become JIT experts, such as languages using LLVM to JIT code in a REPL (which IMO is one of the most exciting things LLVM has enabled): I _think_ I understand what needs to be done when for ARM, but I couldn't tell you what needs to be done when on a MIPs or PPC CPU. But it sounds like we've been talking at cross-purposes: I was worried if it became the clients responsibility to implement code that did cache management, but from Amara's responses it sounds like it's just a route you can use if you want to, but there will be an official part of LLVM that understands what to do when on all the supported architectures. So my worry is groundless. (Also in case I'm being a bit unclear: I can see that it's a modularity issue to have teh ExectuionEngine doing so much stuff for other objects in LLVM and refactoring it so something else deals with these issues would be a good thing, I'd just really like there to be some piece of rock-solid reliable piece of LLVM code that clients can use that knows what to do when for every supported target.)<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Cheers,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Dave<o:p></o:p></span></p></div></div></div></body></html>