<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in unsafe_send_sync.rs</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>18fabd77 - bench-api: Allow multiple instantiations per compilation</title>
        <link>http://172.16.0.5:8080/history/wasmtime-44.0.1/crates/bench-api/src/unsafe_send_sync.rs#18fabd77</link>
        <description>bench-api: Allow multiple instantiations per compilationWe used to allow at most one instantiation per compilation, but there is nofundamental reason why that should be the case. Allowing multiple instantiationsper compilation allows us to, for example, benchmark repeated instantiationwithin Wasmtime&apos;s pooling allocator.This additionally switches to using host functions for WASI and for`bench_{start,end}` rather than defining them on the linker, this way we can usea new store for every instantiation and don&apos;t need to keep other instances alivewhen instantiating new instances.Finally, we switch all timing to be done through callback functions, rather thanhaving the bench API caller implicitly start/end timers around bench APIcalls. This allows us to more precisely measure phases and exclude things likefile I/O performed when creating a WASI context.

            List of files:
            /wasmtime-44.0.1/crates/bench-api/src/unsafe_send_sync.rs</description>
        <pubDate>Mon, 24 May 2021 23:00:15 +0000</pubDate>
        <dc:creator>Nick Fitzgerald &lt;fitzgen@gmail.com&gt;</dc:creator>
    </item>
</channel>
</rss>
