<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - JS engine completely broken on ia64"
href="https://bugs.webkit.org/show_bug.cgi?id=129992#c6">Comment # 6</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - JS engine completely broken on ia64"
href="https://bugs.webkit.org/show_bug.cgi?id=129992">bug 129992</a>
from <span class="vcard"><a class="email" href="mailto:emeric.maschino@gmail.com" title="Émeric MASCHINO <emeric.maschino@gmail.com>"> <span class="fn">Émeric MASCHINO</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=129992#c4">comment #4</a>)
Thank you for taking the time to look at this.
<span class="quote">> You're going to have a really bad time with JSVALUE64W, particularly since
> it will always be an obscure configuration that nobody uses. This is
> especially true since ia64 is effectively dead - it's hard to get help
> implementing and maintaining a port for unused architectures. I recommend
> trying to address this problem with a less invasive approach that is less
> work to implement and less work to maintain.</span >
Thank you for guidance here.
<span class="quote">> I suggest teaching our GC to allocate pages in a low memory range where the
> top 16 address bits are zero. I think that's what Mozilla did. </span >
You're probably referring to [1], aren't you?
Mozilla's approach is thus to pass mmap an "addr" parameter that equals 0x0000070000000000 to ensure that all allocated pointers have their high 17 bits clear.
Would the same mmap trick work for WebKit's GC, adapting it to have the high 16 bits clear (rather than 17)?
<span class="quote">> If this is true then you'll need to make lots of other changes in WebKit.
> WebKit assumes that the memory model is never weaker than what ARM would do. </span >
I can't be sure there, I'm not a kernel developer.
Isn't there no other architecture in WebKit's codebase with a memory model as weak as ia64 that I can have a look at to discover how they deal with cache/memory coherency? I can see a lot of arches in CMakeLists.txt and Source/JavaScriptCore/CMakeLists.txt, but are they actually working properly or are in the same bad shape than ia64 currently?
<span class="quote">> I doubt that this is an issue anymore. I know we run with different page
> sizes on different platforms now.</span >
Are you referring to [2] there? From what I understand, choice of 4K and 16K page sizes are supported, but what about other values, such as 8K and 64K for Linux ia64?
Fortunately enough, most (all?) ia64 Linux distributions came configured by default with CONFIG_IA64_PAGE_SIZE_16KB=y back at the time, so are on a supported case w.r.t. <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - FastMalloc.cpp should use system defined page size instead of literal constant"
href="show_bug.cgi?id=115502">bug #115502</a>.
Émeric
[1] <a href="http://hg.mozilla.org/mozilla-central/rev/9c15d0fb3e25">http://hg.mozilla.org/mozilla-central/rev/9c15d0fb3e25</a>
[2] <a href="http://trac.webkit.org/changeset/149472">http://trac.webkit.org/changeset/149472</a></pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>