<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <div class="markdown-here-wrapper" data-md-url="" style="" markdown-here-wrapper-content-modified="true">
      <p style="margin: 0px 0px 1.2em !important;">Hi,<br>
        I believe there’s two main ways in which allocation can be
        improved, but they are relatively orthogonal.</p>
      <ul style="margin: 1.2em 0px;padding-left: 2em;">
        <li style="margin: 0.5em 0px;">
          <p style="margin: 0px 0px 1.2em !important;margin: 0.5em 0px !important;">the
            pooling allocator you proposed, which I agree is useful,
            seems perfect for cases where you want the same pool to be
            reused by multiple threads. In that sense, the pool acts as
            a sort of more general, full-blown allocator (e.g. like
            malloc). I believe the main use case here is I/O.</p>
        </li>
        <li style="margin: 0.5em 0px;">
          <p style="margin: 0px 0px 1.2em !important;margin: 0.5em 0px !important;">in
            some specialized cases, you want good thread-local allocator
            - possibily one that is able to recycle memory between
            repeated calls to the same functions. This comes up with the
            Linker, with errno, and all those cases where a Java method
            wants to allocate a segment, pass the segment to a native
            call, only to then destroy the segment.</p>
        </li>
      </ul>
      <p style="margin: 0px 0px 1.2em !important;">I’m very skeptical
        that there exist <em>one good allocator</em> that is equaly
        proficient in both use cases. For instance, a shared memory pool
        will unavoidably requires synchronization (CAS and the likes) to
        make sure that different threads cannot acquire the same region
        of memory. All these problems simply do not exist with a
        thread-local allocator. Moreover, because of the more
        “structured” (stack-confined) way in which thread-local
        allocators are used, they are typically much simpler to
        implement: typically a bump allocator that can be recyled (e.g.
        by resetting the start pointer) is enough, as there’s no
        contention.</p>
      <p style="margin: 0px 0px 1.2em !important;">This is an example on
        how to implement something like what I described above (we’ve
        been toying with it for quite some time):</p>
      <p style="margin: 0px 0px 1.2em !important;"><a href="https://github.com/openjdk/jdk/compare/master...mcimadamore:jdk:stack_allocator?expand=1" class="moz-txt-link-freetext">https://github.com/openjdk/jdk/compare/master...mcimadamore:jdk:stack_allocator?expand=1</a></p>
      <p style="margin: 0px 0px 1.2em !important;">For instance, with
        the stack pool implenented in this class, we can do strlen as
        follows:</p>
      <pre style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;font-size: 1em; line-height: 1.2em;margin: 1.2em 0px;"><code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;white-space: pre; overflow: auto; border-radius: 3px; border: 1px solid rgb(204, 204, 204); padding: 0.5em 0.7em; display: block !important;">Stack stack = Stack.newStack();

...

int strlen(String s) {
        try (Arena arena = stack.push()) {
            return (int) STRLEN.invokeExact(arena.allocateFrom(s));
        }

}
</code></pre>
      <p style="margin: 0px 0px 1.2em !important;">This seems to work
        extremely well. The above branch has a new benchmark added to
        StrLenTest - here’s how it compares with the based version
        (which uses a vanilla confined arena):</p>
      <pre style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;font-size: 1em; line-height: 1.2em;margin: 1.2em 0px;"><code style="font-size: 0.85em; font-family: Consolas, Inconsolata, Courier, monospace;margin: 0px 0.15em; padding: 0px 0.3em; white-space: pre-wrap; border: 1px solid rgb(234, 234, 234); background-color: rgb(248, 248, 248); border-radius: 3px; display: inline;white-space: pre; overflow: auto; border-radius: 3px; border: 1px solid rgb(204, 204, 204); padding: 0.5em 0.7em; display: block !important;">Benchmark                        (size)  Mode  Cnt   Score   Error  Units
StrLenTest.panama_strlen_alloc      100  avgt   30  37.338 ± 0.777  ns/op
StrLenTest.panama_strlen_stack      100  avgt   30  18.206 ± 0.138  ns/op
</code></pre>
      <p style="margin: 0px 0px 1.2em !important;">Using the stack pool
        is 2x faster, and there’s no GC activity (allocation of
        intermediate arenas are fully escape-analyzed away):</p>
      <p style="margin: 0px 0px 1.2em !important;">IMHO, an allocator
        like this would be ideal for something like the Linker. So, why
        isn't something like this in the JDK already?</p>
      <p style="margin: 0px 0px 1.2em !important;">The remaining problem
        we need to face is how to connect this allocator to a given
        thread. Ideally, each thread should have one such pool, which
        clients can obtain and use at will. While there's several ways
        of doing this, none feels "right":</p>
      <ul style="margin: 1.2em 0px;padding-left: 2em;">
        <li style="margin: 0.5em 0px;">
          <p style="margin: 0px 0px 1.2em !important;margin: 0.5em 0px !important;">using
            a ThreadLocal can be wasteful if each thread allocates a lot
            of memory, especially if (a) a thread allocates a lot of
            memory from the pool and (b) there is a large number of
            virtual threads.</p>
        </li>
        <li style="margin: 0.5em 0px;">
          <p style="margin: 0px 0px 1.2em !important;margin: 0.5em 0px !important;">ThreadLocal
            doesn’t allow for resources to be cleaned up — meaning that
            when a thread eventually exits, its pool will remain alive.
            Again, this could pose issues. (And, allowing custom cleanup
            on <em>all</em> thread locals is a much bigger discussion)</p>
        </li>
        <li style="margin: 0.5em 0px;">
          <p style="margin: 0px 0px 1.2em !important;margin: 0.5em 0px !important;">A
            “carrier” ThreadLocal seems a better fit for the job,
            because the pool is associated to a carrier thread, not a
            virtual thread. And, carrier ThreadLocals allow for custom
            clean up policies. But, there is still the potential for two
            virtual threads to stomp on each other (e.g. thread 1
            acquires an arena from the stack, then is unmounted, then
            thread 2 acquires and arena from same stack). So you end up
            back with some synchronization requirements (unless you can
            "pin" the virtual thread for the duration of the allocation
            activity).<br>
          </p>
        </li>
        <li style="margin: 0.5em 0px;">
          <p style="margin: 0px 0px 1.2em !important;margin: 0.5em 0px !important;">A
            scope local is also a possibility, but it requires more
            radical changes to the code base. E.g. the scope local stack
            needs to be set up early in the application initialization,
            so that other clients can take advantage of it.</p>
        </li>
      </ul>
      <p style="margin: 0px 0px 1.2em !important;">So, while I think we
        essentially solved the “allocation performance” side of the
        equation, I believe some work still needs to be done on the “how
        do we attach allocators to threads” side of the equation. My
        feeling is that we will probably end up combining the class I
        showed above with some of the functionalities of (platform?)
        ThreadLocal, to allow for efficient reuse.</p>
      <p style="margin: 0px 0px 1.2em !important;">I expect that
        experiments like the one Per mentioned on errno, or the
        discussion in this thread re. how do we make Linker allocation
        faster will, I think, help us tremendously in figuring out how
        to best associate allocators with threads.</p>
      <p style="margin: 0px 0px 1.2em !important;">Cheers<br>
        Maurizio</p>
      <p style="margin: 0px 0px 1.2em !important;">On 17/01/2025 09:11,
        <a class="moz-txt-link-abbreviated" href="mailto:rsmogura@icloud.com">rsmogura@icloud.com</a> wrote:</p>
      <p style="margin: 0px 0px 1.2em !important;"></p>
      <div class="markdown-here-exclude">
        <p></p>
        <blockquote type="cite" cite="mid:58F805C2-1279-4A67-9448-CC1FD6EE25E8@icloud.com">
          
          Hi all,
          <div><br>
          </div>
          <div>Let me jump in here. During incubator phase of Panam, I
            proposed and it was discussed the polling allocator [1]
            & [2], which later was decided to not include it into
            code base of Panama / JDK.</div>
          <div><br>
          </div>
          <div>I wonder if it’s maybe a good time to think about it
            again, as it has properties mentioned by Jorn (tracking
            allocation), and Matthias (fast allocation and
            deallocation).</div>
          <div><br>
          </div>
          <div>The code it self was not updated for long time, but it
            used the double Arena approach where one arena was used as
            allocator and poll, and 2nd temporary arena was only used
            for returning segments back to poll.</div>
          <div><br>
          </div>
          <div>[1] <a href="https://mail.openjdk.org/pipermail/panama-dev/2021-April/013512.html" moz-do-not-send="true" class="moz-txt-link-freetext">https://mail.openjdk.org/pipermail/panama-dev/2021-April/013512.html</a></div>
          <div>[2] <a href="https://github.com/openjdk/panama-foreign/pull/509" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/panama-foreign/pull/509</a></div>
          <div><br>
          </div>
          <div>Best regards,</div>
          <div>Radosław Smogura<br id="lineBreakAtBeginningOfMessage">
            <div><br>
              <blockquote type="cite">
                <div>Wiadomość napisana przez Matthias Ernst
                  <a class="moz-txt-link-rfc2396E" href="mailto:matthias@mernst.org"><matthias@mernst.org></a> w dniu 17 sty 2025, o
                  godz. 01:09:</div>
                <br class="Apple-interchange-newline">
                <div>
                  <div dir="ltr">Thanks very much for the feedback,
                    Jorn!
                    <div>I've incorporated the two-element cache, and
                      avoid using a shared session now (Unsafe instead).</div>
                    <div><br>
                    </div>
                    <div>I'm not sure about using non-carrier
                      ThreadLocals, I think a defining quality is that
                      you can only have as many (root) foreign function
                      invocations as you have carrier threads, so it is
                      fitting. With virtual threads you might allocate
                      xxxx such buffers for nought.</div>
                    <div><br>
                    </div>
                    <div>As to the confined session: it fits nicely into
                      the implementation, but I observe that it destroys
                      one very nice property of the patch: without it,
                      at least my test downcall seems to become
                      allocation-free (I see zero GC activity in the
                      benchmark), i.e. the "BoundedArea" and the buffer
                      slices seem to get completely scalar-replaced. As
                      soon as I add a per-call Arena.ofConfined() into
                      the picture, I see plenty of GC activity and the
                      call-overhead goes up (but still way less than
                      with malloc involved). I haven't looked in detail
                      into why that might be (I'm not very good with the
                      EA logs). I could argue this either way, but an
                      allocation free foreign call seems like a nice
                      property, whereas I'm reasonably sure these tmp
                      buffers cannot escape the call? Is that maybe
                      something that could be enabled only with a debug
                      flag?</div>
                    <div><br>
                    </div>
                    <div>Matthias</div>
                    <div><br>
                    </div>
                  </div>
                  <br>
                  <div class="gmail_quote gmail_quote_container">
                    <div dir="ltr" class="gmail_attr">On Thu, Jan 16,
                      2025 at 6:26 PM Jorn Vernee <<a href="mailto:jorn.vernee@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">jorn.vernee@oracle.com</a>>
                      wrote:<br>
                    </div>
                    <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
                      <div>
                        <p>Hello Matthias,</p>
                        <p>We've been exploring this direction
                          internally as well. As you've found, downcall
                          handles/upcall stubs sometimes need to
                          allocate memory. The return buffer case that
                          you've run into is one such case, others are:
                          when a struct that does not fit into a single
                          register is passed by value on Windows, we
                          need to create a copy. When a struct is passed
                          by value to an upcall stub, we need to
                          allocate memory to hold the value.</p>
                        <p>I took a look at your patch. One of the
                          problems I see with a one-element cache is
                          that some upcall stubs might never benefit
                          from it, since a preceding downcall already
                          claimed the cache. Though, I believe a chain
                          of downcalls and upcalls is comparatively
                          rare. A two element cache might be better.
                          That way a sequence of downcall -> upcall,
                          that both use by-value structs, will be able
                          to benefit from the cache.</p>
                        <p>Having a cache per carrier thread is probably
                          a good idea. A cache per thread is also
                          possibly an option, if the overhead seems
                          acceptable (the cache is only initialized for
                          threads that actually call native code after
                          all). This would also be a little faster, I
                          think.<br>
                        </p>
                        <p>One thing that's unfortunate is the use of a
                          shared arena, even in the fallback case, since
                          closing that is very slow. Another problem <span><span>is
                              that with your current implementation, we
                              are no longer tracking the lifetime of the
                              memory correctly, and it is possible to
                              access memory that was already returned to
                              the cache. Using a proper lifetime (i.e.
                              creating/closing a new arena per call) has
                              helped to catch bugs in the past. If we
                              want to keep doing that, we'd have to
                              re-wrap the memory of the cache with a new
                              arena (using MemorySegment::reinterpret),
                              which we then close after a downcall, to
                              return elements to the cache. I suggest
                              restructuring the code so that it always
                              creates  a new confined arena, as today,
                              but then either: 1) grabs a memory segment
                              from the cache, and attaches that to the
                              new confined arena (using
                              MS::reintrepret), or 2) in the case of a
                              cache miss, just allocates a new segment
                              from the confined arena we created.</span></span></p>
                        <p><span><span>WDYT?<br>
                            </span></span></p>
                        <p><span><span>Jorn<br>
                            </span></span></p>
                        <div>On 16-1-2025 11:00, Matthias Ernst wrote:<br>
                        </div>
                        <blockquote type="cite">
                          <div dir="ltr">
                            <div dir="ltr">Hi, I noticed a source of
                              overhead when calling foreign functions
                              with small aggregate return values.<br>
                              <br>
                              <div>For example, a function returning a <font face="monospace">struct Vector2D {
                                  double x; double y }</font> will cause
                                a malloc/free inside the downcall handle
                                on every call. On my machine, this
                                accounts for about 80% of the call
                                overhead.</div>
                              <div><br>
                              </div>
                              <div>Choice stack:</div>
                              <div>
                                <pre style="box-sizing:border-box;font-size:11.9px;margin-top:0px;overflow:auto;line-height:1.45;color:rgb(31,35,40);border-radius:6px"><code style="box-sizing:border-box;padding:0px;margin:0px;background:transparent;border-radius:6px;word-break:normal;border:0px;display:inline;overflow:visible;line-height:inherit">   java.lang.Thread.State: RUNNABLE
<b>       at jdk.internal.misc.Unsafe.allocateMemory0(java.base@25-ea/Native Method)
</b>...
<b>       at jdk.internal.foreign.abi.SharedUtils.newBoundedArena(<a href="mailto:java.base@25-ea/SharedUtils.java:386" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">java.base@25-ea/SharedUtils.java:386</a>)
</b>      at jdk.internal.foreign.abi.DowncallStub/0x000001f001084c00.invoke(java.base@25-ea/Unknown Source)
        at java.lang.invoke.DirectMethodHandle$Holder.invokeStatic(java.base@25-ea/DirectMethodHandle$Holder)
</code></pre>
                              </div>
                              <div>While it might be difficult to
                                eliminate these intermediate buffers, I
                                would propose to try reusing them.</div>
                              <div><br>
                              </div>
                              <div>
                                <div>
                                  <div>What's happening here:</div>
                                </div>
                              </div>
                              <div>* the ARM64 ABI returns such a struct
                                in two 128 bit registers v0/v1 [0]</div>
                              <div>* the VM stub calling convention
                                around this expects an output buffer to
                                copy v0/v1 into:  [1]</div>
                              <div><font face="monospace">stub(out) {
                                  ... out[0..16) = v0; out[16..32) = v1;
                                  }</font></div>
                              <div>* the FFM downcall calling convention
                                OTOH expects a user-provided
                                SegmentAllocator to allocate a 16 byte
                                StructLayout(JAVA_DOUBLE, JAVA_DOUBLE).
                                The generated method handle to adapt to
                                the stub looks roughly like this [2]:</div>
                              <div> ffm(allocator) {</div>
                              <div><b>  tmp = malloc(32)</b></div>
                              <div>  stub(tmp)</div>
                              <div>  result = allocator.allocate(16)</div>
                              <div>  result[0..8) = tmp[0..8)</div>
                              <div>  result[8..16) = tmp[16..24)</div>
                              <b>  free(tmp)</b></div>
                            <div dir="ltr">  return result<br>
                              <div>}</div>
                              <div><br>
                              </div>
                              <div>Now there's an easy way around this
                                for the user by using a different native
                                signature:</div>
                              <div>
                                <div><font face="monospace">void
                                    g(Vector2D *out) { *out = f(); }</font></div>
                                <div>This eliminates the intermediate
                                  buffer altogether.</div>
                                <div><br>
                                </div>
                                <div>
                                  <div>However, if we wanted to optimize
                                    the return-by-value path, I can
                                    think of three options:</div>
                                  <div>* enhance the stub calling
                                    conventions to directly copy only
                                    the narrowed output registers into
                                    the result buffer.  This looks
                                    rather involved.</div>
                                  <div>* allocate the tmp buffer using
                                    the user's allocator as well (e.g.
                                    in conjunction with the result +
                                    slicing). The Linker api is somewhat
                                    lenient about how `allocator` will
                                    be exactly invoked: "used by the
                                    linker runtime to allocate the
                                    memory region associated with the
                                    struct returned by the downcall
                                    method handle".  However, this may
                                    be surprising to the caller.</div>
                                  <div>* keep the tmp buffer allocation
                                    internal, but optimize it. This is
                                    what I'm proposing here.</div>
                                  <div><br>
                                  </div>
                                </div>
                                <div>A possible counter-argument could
                                  be "this is just one allocation out of
                                  two". However, the user has control
                                  over `allocator`, and may re-use the
                                  same segment across calls, but they
                                  have no control over the tmp
                                  allocation.</div>
                                <div><br>
                                </div>
                              </div>
                              <div>
                                <div>I've worked on a patch that takes
                                  this last route, using a one-element
                                  thread-local cache: <a href="https://github.com/openjdk/jdk/pull/23142" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/jdk/pull/23142</a>,
                                  it reduces call time from 36->8ns /
                                  op on my machine and I observe no more
                                  GC's.</div>
                              </div>
                              <div><br>
                              </div>
                              <div>Would there be interest in pursuing
                                this?</div>
                              <div><br>
                              </div>
                              <div>Thx</div>
                              <div>Matthias</div>
                              <div><br>
                              </div>
                              <div><br>
                              </div>
                              <div>[0] <a href="https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#return-values" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#return-values</a></div>
                              <div>[1] <a href="https://github.com/openjdk/jdk/blob/9c430c92257739730155df05f340fe144fd24098/src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.java#L97" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/jdk/blob/9c430c92257739730155df05f340fe144fd24098/src/java.base/share/classes/jdk/internal/foreign/abi/CallingSequenceBuilder.java#L97</a></div>
                              <div>[2] "binding context": <a href="https://github.com/openjdk/jdk/blob/9c430c92257739730155df05f340fe144fd24098/src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java#L296" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/jdk/blob/9c430c92257739730155df05f340fe144fd24098/src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java#L296</a></div>
                            </div>
                          </div>
                        </blockquote>
                      </div>
                    </blockquote>
                  </div>
                </div>
              </blockquote>
            </div>
            <br>
          </div>
        </blockquote>
        <p></p>
      </div>
      <p style="margin: 0px 0px 1.2em !important;"></p>
      <div title="MDH:PHA+SGksPGJyPkkgYmVsaWV2ZSB0aGVyZSdzIHR3byBtYWluIHdheXMgaW4gd2hpY2ggYWxsb2Nh
dGlvbiBjYW4gYmUgaW1wcm92ZWQsIGJ1dCB0aGV5IGFyZSByZWxhdGl2ZWx5IG9ydGhvZ29uYWwu
PC9wPjxwPiogdGhlIHBvb2xpbmcgYWxsb2NhdG9yIHlvdSBwcm9wb3NlZCwgd2hpY2ggSSBhZ3Jl
ZSBpcyB1c2VmdWwsIHNlZW1zIHBlcmZlY3QgZm9yIGNhc2VzIHdoZXJlIHlvdSB3YW50IHRoZSBz
YW1lIHBvb2wgdG8gYmUgcmV1c2VkIGJ5IG11bHRpcGxlIHRocmVhZHMuIEluIHRoYXQgc2Vuc2Us
IHRoZSBwb29sIGFjdHMgYXMgYSBzb3J0IG9mIG1vcmUgZ2VuZXJhbCwgZnVsbC1ibG93biBhbGxv
Y2F0b3IgKGUuZy4gbGlrZSBtYWxsb2MpLiBJIGJlbGlldmUgdGhlIG1haW4gdXNlIGNhc2UgaGVy
ZSBpcyBJL08uPGJyPjxicj4qIGluIHNvbWUgc3BlY2lhbGl6ZWQgY2FzZXMsIHlvdSB3YW50IGdv
b2QgdGhyZWFkLWxvY2FsIGFsbG9jYXRvciAtIHBvc3NpYmlseSBvbmUgdGhhdCBpcyBhYmxlIHRv
IHJlY3ljbGUgbWVtb3J5IGJldHdlZW4gcmVwZWF0ZWQgY2FsbHMgdG8gdGhlIHNhbWUgZnVuY3Rp
b25zLiBUaGlzIGNvbWVzIHVwIHdpdGggdGhlIExpbmtlciwgd2l0aCBlcnJubywgYW5kIGFsbCB0
aG9zZSBjYXNlcyB3aGVyZSBhIEphdmEgbWV0aG9kIHdhbnRzIHRvIGFsbG9jYXRlIGEgc2VnbWVu
dCwgcGFzcyB0aGUgc2VnbWVudCB0byBhIG5hdGl2ZSBjYWxsLCBvbmx5IHRvIHRoZW4gZGVzdHJv
eSB0aGUgc2VnbWVudC48L3A+PHA+SSdtIHZlcnkgc2tlcHRpY2FsIHRoYXQgdGhlcmUgZXhpc3Qg
X29uZSBnb29kIGFsbG9jYXRvcl8gdGhhdCBpcyBlcXVhbHkgcHJvZmljaWVudCBpbiBib3RoIHVz
ZSBjYXNlcy4gRm9yIGluc3RhbmNlLCBhIHNoYXJlZCBtZW1vcnkgcG9vbCB3aWxsIHVuYXZvaWRh
Ymx5IHJlcXVpcmVzIHN5bmNocm9uaXphdGlvbiAoQ0FTIGFuZCB0aGUgbGlrZXMpIHRvIG1ha2Ug
c3VyZSB0aGF0IGRpZmZlcmVudCB0aHJlYWRzIGNhbm5vdCBhY3F1aXJlIHRoZSBzYW1lIHJlZ2lv
biBvZiBtZW1vcnkuIEFsbCB0aGVzZSBwcm9ibGVtcyBzaW1wbHkgZG8gbm90IGV4aXN0IHdpdGgg
YSB0aHJlYWQtbG9jYWwgYWxsb2NhdG9yLiBNb3Jlb3ZlciwgYmVjYXVzZSBvZiB0aGUgbW9yZSAi
c3RydWN0dXJlZCIgKHN0YWNrLWNvbmZpbmVkKSB3YXkgaW4gd2hpY2ggdGhyZWFkLWxvY2FsIGFs
bG9jYXRvcnMgYXJlIHVzZWQsIHRoZXkgYXJlIHR5cGljYWxseSBtdWNoIHNpbXBsZXIgdG8gaW1w
bGVtZW50OiB0eXBpY2FsbHkgYSBidW1wIGFsbG9jYXRvciB0aGF0IGNhbiBiZSByZWN5bGVkIChl
LmcuIGJ5IHJlc2V0dGluZyB0aGUgc3RhcnQgcG9pbnRlcikgaXMgZW5vdWdoLCBhcyB0aGVyZSdz
IG5vIGNvbnRlbnRpb24uPC9wPjxwPlRoaXMgaXMgYW4gZXhhbXBsZSBvbiBob3cgdG8gaW1wbGVt
ZW50IHNvbWV0aGluZyBsaWtlIHdoYXQgSSBkZXNjcmliZWQgYWJvdmUuIFdlJ3ZlIGJlZW4gdG95
aW5nIHdpdGggaXQgZm9yIHF1aXRlIHNvbWUgdGltZSwgYW5kIHRoZSBudW1iZXJzIHdlIGdldCBh
cmUgcmVhbGx5IGdvb2QuIEZvciBpbnN0YW5jZSwgYXQgbGVhc3QgaW4gc3ludGhldGljIGJlbmNo
bWFya3MsIHRoZXJlJ3Mgbm8gYWxsb2NhdGlvbiBjb3N0IChhbGxvY2F0aW9uIG9mIGludGVybWVk
aWF0ZSBhcmVuYXMgYXJlIGZ1bGx5IGVzY2FwZS1hbmFseXplZCBhd2F5KTo8L3A+PHA+aHR0cHM6
Ly9naXRodWIuY29tL29wZW5qZGsvamRrL2NvbXBhcmUvbWFzdGVyLi4ubWNpbWFkYW1vcmU6amRr
OnN0YWNrX2FsbG9jYXRvcj9leHBhbmQ9MTwvcD48cD5Gb3IgaW5zdGFuY2UsIHdpdGggdGhlIHN0
YWNrIHBvb2wgaW1wbGVuZW50ZWQgaW4gdGhpcyBjbGFzcywgd2UgY2FuIGRvIHN0cmxlbiBhcyBm
b2xsb3dzOjwvcD48cD5gYGA8YnI+U3RhY2sgc3RhY2sgPSBTdGFjay5uZXdTdGFjaygpOzxicj48
YnI+Li4uPGJyPjxicj5pbnQgc3RybGVuKFN0cmluZyBzKSB7PGJyPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0cnkgKEFyZW5hIGFyZW5hID0gc3RhY2sucHVzaCgp
KSB7PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyByZXR1cm4gKGludCkgU1RSTEVOLmludm9rZUV4YWN0KGFyZW5hLmFs
bG9jYXRlRnJvbShzKSk7PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyB9PC9wPjxwPn08YnI+YGBgPC9wPjxwPlRoaXMgc2VlbXMgdG8gd29yayBleHRyZW1lbHkg
d2VsbC4gVGhlIGFib3ZlIGJyYW5jaCBoYXMgYSBuZXcgYmVuY2htYXJrIGFkZGVkIHRvIFN0ckxl
blRlc3QgLSBoZXJlJ3MgaG93IGl0IGNvbXBhcmVzIHdpdGggdGhlIGJhc2VkIHZlcnNpb24gKHdo
aWNoIHVzZXMgYSB2YW5pbGxhIGNvbmZpbmVkIGFyZW5hKTo8YnI+PC9wPjxwPmBgYDxicj5CZW5j
aG1hcmsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKHNpemUpJm5ic3A7IE1vZGUmbmJzcDsgQ250
Jm5ic3A7Jm5ic3A7IFNjb3JlJm5ic3A7Jm5ic3A7IEVycm9yJm5ic3A7IFVuaXRzPGJyPlN0ckxl
blRlc3QucGFuYW1hX3N0cmxlbl9hbGxvYyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAx
MDAmbmJzcDsgYXZndCZuYnNwOyZuYnNwOyAzMCZuYnNwOyAzNy4zMzggwrEgMC43NzcmbmJzcDsg
bnMvb3A8YnI+U3RyTGVuVGVzdC5wYW5hbWFfc3RybGVuX3N0YWNrJm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IDEwMCZuYnNwOyBhdmd0Jm5ic3A7Jm5ic3A7IDMwJm5ic3A7IDE4LjIwNiDC
sSAwLjEzOCZuYnNwOyBucy9vcDxicj5gYGA8YnI+PC9wPjxwPlVzaW5nIHRoZSBzdGFjayBwb29s
IGlzIDJ4IGZhc3RlciwgYW5kIHRoZXJlJ3Mgbm8gR0MgYWN0aXZpdHkuPC9wPjxwPklNSE8sIGFu
IGFsbG9jYXRvciBsaWtlIHRoaXMgd291bGQgYmUgaWRlYWwgZm9yIHNvbWV0aGluZyBsaWtlIHRo
ZSBMaW5rZXIuIFRoZSByZW1haW5pbmcgcHJvYmxlbSB3ZSBuZWVkIHRvIGZhY2UgaXMgaG93IHRv
IGNvbm5lY3QgdGhpcyBhbGxvY2F0b3IgdG8gYSBnaXZlbiB0aHJlYWQuIElkZWFsbHksIGVhY2gg
dGhyZWFkIHNob3VsZCBoYXZlIG9uZSBzdWNoIHBvb2wsIHdoaWNoIGNsaWVudHMgY2FuIG9idGFp
biBhbmQgdXNlIGF0IHdpbGwuIEhvd2V2ZXIsIGRvaW5nIHNvIGlzIG5vdCBzdHJhaWdodGZvcndh
cmQ6PC9wPjxwPiogdXNpbmcgYSBUaHJlYWRMb2NhbCBjYW4gYmUgd2FzdGVmdWwgaWYgZWFjaCB0
aHJlYWQgYWxsb2NhdGVzIGEgbG90IG9mIG1lbW9yeSwgZXNwZWNpYWxseSBpZiAoYSkgYSB0aHJl
YWQgYWxsb2NhdGVzIGEgbG90IG9mIG1lbW9yeSBmcm9tIHRoZSBwb29sIGFuZCAoYikgdGhlcmUg
aXMgYSBsYXJnZSBudW1iZXIgb2YgdmlydHVhbCB0aHJlYWRzLjwvcD48cD4qIFRocmVhZExvY2Fs
IGRvZXNuJ3QgYWxsb3cgZm9yIHJlc291cmNlcyB0byBiZSBjbGVhbmVkIHVwIC0tIG1lYW5pbmcg
dGhhdCB3aGVuIGEgdGhyZWFkIGV2ZW50dWFsbHkgZXhpdHMsIGl0cyBwb29sIHdpbGwgcmVtYWlu
IGFsaXZlLiBBZ2FpbiwgdGhpcyBjb3VsZCBwb3NlIGlzc3Vlcy4gKGFuZCwgYWxsb3dpbmcgY3Vz
dG9tIGNsZWFudXAgb24gX2FsbF8gdGhyZWFkIGxvY2FscyBpcyBhIG11Y2ggYmlnZ2VyIGRpc2N1
c3Npb24pPGJyPjwvcD48cD4qIEEgImNhcnJpZXIiIFRocmVhZExvY2FsIHNlZW1zIGEgYmV0dGVy
IGZpdCBmb3IgdGhlIGpvYiwgYmVjYXVzZSB0aGUgcG9vbCBpcyBhc3NvY2lhdGVkIHRvIGEgY2Fy
cmllciB0aHJlYWQsIG5vdCBhIHZpcnR1YWwgdGhyZWFkLiBBbmQsIGNhcnJpZXIgVGhyZWFkTG9j
YWxzIGFsbG93IGZvciBjdXN0b20gY2xlYW4gdXAgcG9saWNpZXMuIEJ1dCwgdGhlcmUgaXMgc3Rp
bGwgdGhlIHBvdGVudGlhbCBmb3IgdHdvIHZpcnR1YWwgdGhyZWFkcyB0byBzdG9tcCBvbiBlYWNo
IG90aGVyIChlLmcuIHRocmVhZCAxIGFjcXVpcmVzIGFuIGFyZW5hIGZyb20gdGhlIHN0YWNrLCB0
aGVuIGlzIHVubW91bnRlZCwgdGhlbiB0aHJlYWQgMiBhY3F1aXJlcyBhbmQgYXJlbmEgZnJvbSBz
YW1lIHN0YWNrKTwvcD48cD4qIEEgc2NvcGUgbG9jYWwgaXMgYWxzbyBhIHBvc3NpYmlsaXR5LCBi
dXQgaXQgcmVxdWlyZXMgbW9yZSByYWRpY2FsIGNoYW5nZXMgdG8gdGhlIGNvZGUgYmFzZS4gRS5n
LiB0aGUgc2NvcGUgbG9jYWwgc3RhY2sgbmVlZHMgdG8gYmUgc2V0IHVwIGVhcmx5IGluIHRoZSBh
cHBsaWNhdGlvbiBpbml0aWFsaXphdGlvbiwgc28gdGhhdCBvdGhlciBjbGllbnRzIGNhbiB0YWtl
IGFkdmFudGFnZSBvZiBpdC48YnI+PC9wPjxwPlNvLCB3aGlsZSBJIHRoaW5rIHdlIGVzc2VudGlh
bGx5IHNvbHZlZCB0aGUgImFsbG9jYXRpb24gcGVyZm9ybWFuY2UiIHNpZGUgb2YgdGhlIGVxdWF0
aW9uLCBJIGJlbGlldmUgc29tZSB3b3JrIHN0aWxsIG5lZWRzIHRvIGJlIGRvbmUgb24gdGhlICJo
b3cgZG8gd2UgYXR0YWNoIGFsbG9jYXRvcnMgdG8gdGhyZWFkcyIgc2lkZSBvZiB0aGUgZXF1YXRp
b24uIE15IGZlZWxpbmcgaXMgdGhhdCB3ZSB3aWxsIHByb2JhYmx5IGVuZCB1cCBjb21iaW5pbmcg
dGhlIGNsYXNzIEkgc2hvd2VkIGFib3ZlIHdpdGggc29tZSBvZiB0aGUgZnVuY3Rpb25hbGl0aWVz
IG9mIChwbGF0Zm9ybT8pIFRocmVhZExvY2FsLCB0byBhbGxvdyBmb3IgZWZmaWNpZW50IHJldXNl
LjwvcD48cD5JIGV4cGVjdCB0aGF0IGV4cGVyaW1lbnRzIGxpa2UgdGhlIG9uZSBQZXIgbWVudGlv
bmVkIG9uIGVycm5vLCBvciB0aGUgZGlzY3Vzc2lvbiBpbiB0aGlzIHRocmVhZCByZS4gaG93IGRv
IHdlIG1ha2UgTGlua2VyIGFsbG9jYXRpb24gZmFzdGVyIHdpbGwsIEkgdGhpbmssIGhlbHAgdXMg
dHJlbWVuZG91c2x5IGluIGZpZ3VyaW5nIG91dCBob3cgdG8gYmVzdCBhc3NvY2lhdGUgYWxsb2Nh
dG9ycyB3aXRoIHRocmVhZHMuPC9wPjxwPkNoZWVyczxicj5NYXVyaXppbzxicj48L3A+PGRpdiBj
bGFzcz0ibW96LWNpdGUtcHJlZml4Ij5PbiAxNy8wMS8yMDI1IDA5OjExLCByc21vZ3VyYUBpY2xv
dWQuY29tIHdyb3RlOjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6
NThGODA1QzItMTI3OS00QTY3LTk0NDgtQ0MxRkQ2RUUyNUU4QGljbG91ZC5jb20iPgo8bWV0YSBo
dHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgIj5IaSBhbGwsPGRp
dj48YnI+PC9kaXY+PGRpdj5MZXQgbWUganVtcCBpbiBoZXJlLiBEdXJpbmcgaW5jdWJhdG9yIHBo
YXNlIG9mIFBhbmFtLCBJIHByb3Bvc2VkIGFuZCBpdCB3YXMgZGlzY3Vzc2VkIHRoZSBwb2xsaW5n
IGFsbG9jYXRvciBbMV0gJmFtcDsgWzJdLCB3aGljaCBsYXRlciB3YXMgZGVjaWRlZCB0byBub3Qg
aW5jbHVkZSBpdCBpbnRvIGNvZGUgYmFzZSBvZiBQYW5hbWEgLyBKREsuPC9kaXY+PGRpdj48YnI+
PC9kaXY+PGRpdj5JIHdvbmRlciBpZiBpdOKAmXMgbWF5YmUgYSBnb29kIHRpbWUgdG8gdGhpbmsg
YWJvdXQgaXQgYWdhaW4sIGFzIGl0IGhhcyBwcm9wZXJ0aWVzIG1lbnRpb25lZCBieSBKb3JuICh0
cmFja2luZyBhbGxvY2F0aW9uKSwgYW5kIE1hdHRoaWFzIChmYXN0IGFsbG9jYXRpb24gYW5kIGRl
YWxsb2NhdGlvbikuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgY29kZSBpdCBzZWxmIHdh
cyBub3QgdXBkYXRlZCBmb3IgbG9uZyB0aW1lLCBidXQgaXQgdXNlZCB0aGUgZG91YmxlIEFyZW5h
IGFwcHJvYWNoIHdoZXJlIG9uZSBhcmVuYSB3YXMgdXNlZCBhcyBhbGxvY2F0b3IgYW5kIHBvbGws
IGFuZCAybmQgdGVtcG9yYXJ5IGFyZW5hIHdhcyBvbmx5IHVzZWQgZm9yIHJldHVybmluZyBzZWdt
ZW50cyBiYWNrIHRvIHBvbGwuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5bMV0mbmJzcDs8YSBo
cmVmPSJodHRwczovL21haWwub3Blbmpkay5vcmcvcGlwZXJtYWlsL3BhbmFtYS1kZXYvMjAyMS1B
cHJpbC8wMTM1MTIuaHRtbCIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1s
aW5rLWZyZWV0ZXh0Ij5odHRwczovL21haWwub3Blbmpkay5vcmcvcGlwZXJtYWlsL3BhbmFtYS1k
ZXYvMjAyMS1BcHJpbC8wMTM1MTIuaHRtbDwvYT48L2Rpdj48ZGl2PlsyXSZuYnNwOzxhIGhyZWY9
Imh0dHBzOi8vZ2l0aHViLmNvbS9vcGVuamRrL3BhbmFtYS1mb3JlaWduL3B1bGwvNTA5IiBtb3ot
ZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiPmh0dHBzOi8v
Z2l0aHViLmNvbS9vcGVuamRrL3BhbmFtYS1mb3JlaWduL3B1bGwvNTA5PC9hPjwvZGl2PjxkaXY+
PGJyPjwvZGl2PjxkaXY+QmVzdCByZWdhcmRzLDwvZGl2PjxkaXY+UmFkb3PFgmF3IFNtb2d1cmE8
YnIgaWQ9ImxpbmVCcmVha0F0QmVnaW5uaW5nT2ZNZXNzYWdlIj48ZGl2Pjxicj48YmxvY2txdW90
ZSB0eXBlPSJjaXRlIj48ZGl2PldpYWRvbW/Fm8SHIG5hcGlzYW5hIHByemV6IE1hdHRoaWFzIEVy
bnN0ICZsdDttYXR0aGlhc0BtZXJuc3Qub3JnJmd0OyB3IGRuaXUgMTcgc3R5IDIwMjUsIG8gZ29k
ei4gMDE6MDk6PC9kaXY+PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj48ZGl2
PjxkaXYgZGlyPSJsdHIiPlRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHRoZSBmZWVkYmFjaywgSm9ybiE8
ZGl2PkkndmUgaW5jb3Jwb3JhdGVkIHRoZSB0d28tZWxlbWVudCBjYWNoZSwgYW5kIGF2b2lkIHVz
aW5nIGEgc2hhcmVkIHNlc3Npb24mbmJzcDtub3cgKFVuc2FmZSBpbnN0ZWFkKS48L2Rpdj48ZGl2
Pjxicj48L2Rpdj48ZGl2PkknbSBub3Qgc3VyZSBhYm91dCB1c2luZyBub24tY2FycmllciBUaHJl
YWRMb2NhbHMsIEkgdGhpbmsgYSBkZWZpbmluZyBxdWFsaXR5IGlzIHRoYXQgeW91IGNhbiBvbmx5
IGhhdmUgYXMgbWFueSAocm9vdCkgZm9yZWlnbiBmdW5jdGlvbiBpbnZvY2F0aW9ucyBhcyB5b3Ug
aGF2ZSZuYnNwO2NhcnJpZXIgdGhyZWFkcywgc28gaXQgaXMgZml0dGluZy4gV2l0aCB2aXJ0dWFs
IHRocmVhZHMgeW91IG1pZ2h0IGFsbG9jYXRlIHh4eHggc3VjaCBidWZmZXJzIGZvciBub3VnaHQu
PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5BcyB0byB0aGUgY29uZmluZWQgc2Vzc2lvbjogaXQg
Zml0cyBuaWNlbHkgaW50byB0aGUgaW1wbGVtZW50YXRpb24sIGJ1dCBJIG9ic2VydmUgdGhhdCBp
dCBkZXN0cm95cyBvbmUgdmVyeSBuaWNlIHByb3BlcnR5IG9mIHRoZSBwYXRjaDogd2l0aG91dCBp
dCwgYXQgbGVhc3QgbXkgdGVzdCBkb3duY2FsbCBzZWVtcyB0byBiZWNvbWUgYWxsb2NhdGlvbi1m
cmVlIChJIHNlZSB6ZXJvIEdDIGFjdGl2aXR5IGluIHRoZSBiZW5jaG1hcmspLCBpLmUuIHRoZSAi
Qm91bmRlZEFyZWEiIGFuZCB0aGUgYnVmZmVyIHNsaWNlcyBzZWVtIHRvIGdldCBjb21wbGV0ZWx5
IHNjYWxhci1yZXBsYWNlZC4gQXMgc29vbiBhcyBJIGFkZCBhIHBlci1jYWxsIEFyZW5hLm9mQ29u
ZmluZWQoKSBpbnRvIHRoZSBwaWN0dXJlLCBJIHNlZSBwbGVudHkgb2YgR0MgYWN0aXZpdHkgYW5k
IHRoZSBjYWxsLW92ZXJoZWFkIGdvZXMgdXAgKGJ1dCBzdGlsbCB3YXkgbGVzcyB0aGFuIHdpdGgg
bWFsbG9jIGludm9sdmVkKS4gSSBoYXZlbid0IGxvb2tlZCBpbiBkZXRhaWwgaW50byB3aHkgdGhh
dCBtaWdodCBiZSAoSSdtIG5vdCB2ZXJ5IGdvb2Qgd2l0aCB0aGUgRUEgbG9ncykuIEkgY291bGQg
YXJndWUgdGhpcyBlaXRoZXIgd2F5LCBidXQgYW4gYWxsb2NhdGlvbiBmcmVlIGZvcmVpZ24gY2Fs
bCBzZWVtcyBsaWtlIGEgbmljZSBwcm9wZXJ0eSwgd2hlcmVhcyBJJ20gcmVhc29uYWJseSBzdXJl
IHRoZXNlIHRtcCBidWZmZXJzIGNhbm5vdCBlc2NhcGUgdGhlIGNhbGw/IElzIHRoYXQgbWF5YmUg
c29tZXRoaW5nIHRoYXQgY291bGQgYmUgZW5hYmxlZCBvbmx5IHdpdGggYSBkZWJ1ZyBmbGFnPzwv
ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+TWF0dGhpYXM8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rp
dj48YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUgZ21haWxfcXVvdGVfY29udGFpbmVyIj48ZGl2
IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gVGh1LCBKYW4gMTYsIDIwMjUgYXQgNjoy
NuKAr1BNIEpvcm4gVmVybmVlICZsdDs8YSBocmVmPSJtYWlsdG86am9ybi52ZXJuZWVAb3JhY2xl
LmNvbSIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0
Ij5qb3JuLnZlcm5lZUBvcmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PGJyPjwvZGl2PjxibG9ja3F1
b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDti
b3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4K
CiAgCiAgPGRpdj48cD5IZWxsbyBNYXR0aGlhcyw8L3A+PHA+V2UndmUgYmVlbiBleHBsb3Jpbmcg
dGhpcyBkaXJlY3Rpb24gaW50ZXJuYWxseSBhcyB3ZWxsLiBBcyB5b3UndmUKICAgICAgZm91bmQs
IGRvd25jYWxsIGhhbmRsZXMvdXBjYWxsIHN0dWJzIHNvbWV0aW1lcyBuZWVkIHRvIGFsbG9jYXRl
CiAgICAgIG1lbW9yeS4gVGhlIHJldHVybiBidWZmZXIgY2FzZSB0aGF0IHlvdSd2ZSBydW4gaW50
byBpcyBvbmUgc3VjaAogICAgICBjYXNlLCBvdGhlcnMgYXJlOiB3aGVuIGEgc3RydWN0IHRoYXQg
ZG9lcyBub3QgZml0IGludG8gYSBzaW5nbGUKICAgICAgcmVnaXN0ZXIgaXMgcGFzc2VkIGJ5IHZh
bHVlIG9uIFdpbmRvd3MsIHdlIG5lZWQgdG8gY3JlYXRlIGEgY29weS4KICAgICAgV2hlbiBhIHN0
cnVjdCBpcyBwYXNzZWQgYnkgdmFsdWUgdG8gYW4gdXBjYWxsIHN0dWIsIHdlIG5lZWQgdG8KICAg
ICAgYWxsb2NhdGUgbWVtb3J5IHRvIGhvbGQgdGhlIHZhbHVlLjwvcD48cD5JIHRvb2sgYSBsb29r
IGF0IHlvdXIgcGF0Y2guIE9uZSBvZiB0aGUgcHJvYmxlbXMgSSBzZWUgd2l0aCBhCiAgICAgIG9u
ZS1lbGVtZW50IGNhY2hlIGlzIHRoYXQgc29tZSB1cGNhbGwgc3R1YnMgbWlnaHQgbmV2ZXIgYmVu
ZWZpdAogICAgICBmcm9tIGl0LCBzaW5jZSBhIHByZWNlZGluZyBkb3duY2FsbCBhbHJlYWR5IGNs
YWltZWQgdGhlIGNhY2hlLgogICAgICBUaG91Z2gsIEkgYmVsaWV2ZSBhIGNoYWluIG9mIGRvd25j
YWxscyBhbmQgdXBjYWxscyBpcwogICAgICBjb21wYXJhdGl2ZWx5IHJhcmUuIEEgdHdvIGVsZW1l
bnQgY2FjaGUgbWlnaHQgYmUgYmV0dGVyLiBUaGF0IHdheQogICAgICBhIHNlcXVlbmNlIG9mIGRv
d25jYWxsIC0mZ3Q7IHVwY2FsbCwgdGhhdCBib3RoIHVzZSBieS12YWx1ZQogICAgICBzdHJ1Y3Rz
LCB3aWxsIGJlIGFibGUgdG8gYmVuZWZpdCBmcm9tIHRoZSBjYWNoZS48L3A+PHA+SGF2aW5nIGEg
Y2FjaGUgcGVyIGNhcnJpZXIgdGhyZWFkIGlzIHByb2JhYmx5IGEgZ29vZCBpZGVhLiBBCiAgICAg
IGNhY2hlIHBlciB0aHJlYWQgaXMgYWxzbyBwb3NzaWJseSBhbiBvcHRpb24sIGlmIHRoZSBvdmVy
aGVhZCBzZWVtcwogICAgICBhY2NlcHRhYmxlICh0aGUgY2FjaGUgaXMgb25seSBpbml0aWFsaXpl
ZCBmb3IgdGhyZWFkcyB0aGF0CiAgICAgIGFjdHVhbGx5IGNhbGwgbmF0aXZlIGNvZGUgYWZ0ZXIg
YWxsKS4gVGhpcyB3b3VsZCBhbHNvIGJlIGEgbGl0dGxlCiAgICAgIGZhc3RlciwgSSB0aGluay48
YnI+CiAgICA8L3A+PHA+T25lIHRoaW5nIHRoYXQncyB1bmZvcnR1bmF0ZSBpcyB0aGUgdXNlIG9m
IGEgc2hhcmVkIGFyZW5hLCBldmVuCiAgICAgIGluIHRoZSBmYWxsYmFjayBjYXNlLCBzaW5jZSBj
bG9zaW5nIHRoYXQgaXMgdmVyeSBzbG93LiBBbm90aGVyCiAgICAgIHByb2JsZW0gPHNwYW4+PHNw
YW4+aXMgdGhhdCB3aXRoIHlvdXIKICAgICAgICAgIGN1cnJlbnQgaW1wbGVtZW50YXRpb24sIHdl
IGFyZSBubyBsb25nZXIgdHJhY2tpbmcgdGhlIGxpZmV0aW1lCiAgICAgICAgICBvZiB0aGUgbWVt
b3J5IGNvcnJlY3RseSwgYW5kIGl0IGlzIHBvc3NpYmxlIHRvIGFjY2VzcyBtZW1vcnkKICAgICAg
ICAgIHRoYXQgd2FzIGFscmVhZHkgcmV0dXJuZWQgdG8gdGhlIGNhY2hlLiBVc2luZyBhIHByb3Bl
cgogICAgICAgICAgbGlmZXRpbWUgKGkuZS4gY3JlYXRpbmcvY2xvc2luZyBhIG5ldyBhcmVuYSBw
ZXIgY2FsbCkgaGFzCiAgICAgICAgICBoZWxwZWQgdG8gY2F0Y2ggYnVncyBpbiB0aGUgcGFzdC4g
SWYgd2Ugd2FudCB0byBrZWVwIGRvaW5nCiAgICAgICAgICB0aGF0LCB3ZSdkIGhhdmUgdG8gcmUt
d3JhcCB0aGUgbWVtb3J5IG9mIHRoZSBjYWNoZSB3aXRoIGEgbmV3CiAgICAgICAgICBhcmVuYSAo
dXNpbmcgTWVtb3J5U2VnbWVudDo6cmVpbnRlcnByZXQpLCB3aGljaCB3ZSB0aGVuIGNsb3NlCiAg
ICAgICAgICBhZnRlciBhIGRvd25jYWxsLCB0byByZXR1cm4gZWxlbWVudHMgdG8gdGhlIGNhY2hl
LiBJIHN1Z2dlc3QKICAgICAgICAgIHJlc3RydWN0dXJpbmcgdGhlIGNvZGUgc28gdGhhdCBpdCBh
bHdheXMgY3JlYXRlcyZuYnNwOyBhIG5ldwogICAgICAgICAgY29uZmluZWQgYXJlbmEsIGFzIHRv
ZGF5LCBidXQgdGhlbiBlaXRoZXI6IDEpIGdyYWJzIGEgbWVtb3J5CiAgICAgICAgICBzZWdtZW50
IGZyb20gdGhlIGNhY2hlLCBhbmQgYXR0YWNoZXMgdGhhdCB0byB0aGUgbmV3IGNvbmZpbmVkCiAg
ICAgICAgICBhcmVuYSAodXNpbmcgTVM6OnJlaW50cmVwcmV0KSwgb3IgMikgaW4gdGhlIGNhc2Ug
b2YgYSBjYWNoZQogICAgICAgICAgbWlzcywganVzdCBhbGxvY2F0ZXMgYSBuZXcgc2VnbWVudCBm
cm9tIHRoZSBjb25maW5lZCBhcmVuYSB3ZQogICAgICAgICAgY3JlYXRlZC48L3NwYW4+PC9zcGFu
PjwvcD48cD48c3Bhbj48c3Bhbj5XRFlUPzxicj4KICAgICAgICA8L3NwYW4+PC9zcGFuPjwvcD48
cD48c3Bhbj48c3Bhbj5Kb3JuPGJyPgogICAgICAgIDwvc3Bhbj48L3NwYW4+PC9wPgogICAgPGRp
dj5PbiAxNi0xLTIwMjUgMTE6MDAsIE1hdHRoaWFzIEVybnN0CiAgICAgIHdyb3RlOjxicj4KICAg
IDwvZGl2PgogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+CiAgICAgIAogICAgICA8ZGl2IGRp
cj0ibHRyIj4KICAgICAgICA8ZGl2IGRpcj0ibHRyIj5IaSwgSSBub3RpY2VkIGEgc291cmNlIG9m
IG92ZXJoZWFkIHdoZW4gY2FsbGluZwogICAgICAgICAgZm9yZWlnbiBmdW5jdGlvbnMgd2l0aCBz
bWFsbCBhZ2dyZWdhdGUgcmV0dXJuIHZhbHVlcy48YnI+CiAgICAgICAgICA8YnI+CiAgICAgICAg
ICA8ZGl2PkZvciBleGFtcGxlLCBhIGZ1bmN0aW9uIHJldHVybmluZyBhIDxmb250IGZhY2U9Im1v
bm9zcGFjZSI+c3RydWN0IFZlY3RvcjJEIHsgZG91YmxlIHg7IGRvdWJsZSB5IH08L2ZvbnQ+CiAg
ICAgICAgICAgIHdpbGwgY2F1c2UgYSBtYWxsb2MvZnJlZSBpbnNpZGUgdGhlIGRvd25jYWxsIGhh
bmRsZSBvbiBldmVyeQogICAgICAgICAgICBjYWxsLiBPbiBteSBtYWNoaW5lLCB0aGlzIGFjY291
bnRzIGZvciBhYm91dCA4MCUgb2YgdGhlIGNhbGwKICAgICAgICAgICAgb3ZlcmhlYWQuPC9kaXY+
CiAgICAgICAgICA8ZGl2Pjxicj4KICAgICAgICAgIDwvZGl2PgogICAgICAgICAgPGRpdj5DaG9p
Y2Ugc3RhY2s6PC9kaXY+CiAgICAgICAgICA8ZGl2PgogICAgICAgICAgICA8cHJlIHN0eWxlPSJi
b3gtc2l6aW5nOmJvcmRlci1ib3g7Zm9udC1zaXplOjExLjlweDttYXJnaW4tdG9wOjBweDtvdmVy
ZmxvdzphdXRvO2xpbmUtaGVpZ2h0OjEuNDU7Y29sb3I6cmdiKDMxLDM1LDQwKTtib3JkZXItcmFk
aXVzOjZweCI+PGNvZGUgc3R5bGU9ImJveC1zaXppbmc6Ym9yZGVyLWJveDtwYWRkaW5nOjBweDtt
YXJnaW46MHB4O2JhY2tncm91bmQ6dHJhbnNwYXJlbnQ7Ym9yZGVyLXJhZGl1czo2cHg7d29yZC1i
cmVhazpub3JtYWw7Ym9yZGVyOjBweDtkaXNwbGF5OmlubGluZTtvdmVyZmxvdzp2aXNpYmxlO2xp
bmUtaGVpZ2h0OmluaGVyaXQiPiAgIGphdmEubGFuZy5UaHJlYWQuU3RhdGU6IFJVTk5BQkxFCjxi
PglhdCBqZGsuaW50ZXJuYWwubWlzYy5VbnNhZmUuYWxsb2NhdGVNZW1vcnkwKGphdmEuYmFzZUAy
NS1lYS9OYXRpdmUgTWV0aG9kKQo8L2I+Li4uCjxiPglhdCBqZGsuaW50ZXJuYWwuZm9yZWlnbi5h
YmkuU2hhcmVkVXRpbHMubmV3Qm91bmRlZEFyZW5hKDxhIGhyZWY9Im1haWx0bzpqYXZhLmJhc2VA
MjUtZWEvU2hhcmVkVXRpbHMuamF2YTozODYiIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNl
bmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiPmphdmEuYmFzZUAyNS1lYS9T
aGFyZWRVdGlscy5qYXZhOjM4NjwvYT4pCjwvYj4JYXQgamRrLmludGVybmFsLmZvcmVpZ24uYWJp
LkRvd25jYWxsU3R1Yi8weDAwMDAwMWYwMDEwODRjMDAuaW52b2tlKGphdmEuYmFzZUAyNS1lYS9V
bmtub3duIFNvdXJjZSkKCWF0IGphdmEubGFuZy5pbnZva2UuRGlyZWN0TWV0aG9kSGFuZGxlJEhv
bGRlci5pbnZva2VTdGF0aWMoamF2YS5iYXNlQDI1LWVhL0RpcmVjdE1ldGhvZEhhbmRsZSRIb2xk
ZXIpCjwvY29kZT48L3ByZT4KICAgICAgICAgIDwvZGl2PgogICAgICAgICAgPGRpdj5XaGlsZSBp
dCBtaWdodCBiZSBkaWZmaWN1bHQgdG8gZWxpbWluYXRlIHRoZXNlCiAgICAgICAgICAgIGludGVy
bWVkaWF0ZSBidWZmZXJzLCBJIHdvdWxkIHByb3Bvc2UgdG8gdHJ5IHJldXNpbmcgdGhlbS48L2Rp
dj4KICAgICAgICAgIDxkaXY+PGJyPgogICAgICAgICAgPC9kaXY+CiAgICAgICAgICA8ZGl2Pgog
ICAgICAgICAgICA8ZGl2PgogICAgICAgICAgICAgIDxkaXY+V2hhdCdzIGhhcHBlbmluZyBoZXJl
OjwvZGl2PgogICAgICAgICAgICA8L2Rpdj4KICAgICAgICAgIDwvZGl2PgogICAgICAgICAgPGRp
dj4qIHRoZSBBUk02NCBBQkkgcmV0dXJucyBzdWNoIGEgc3RydWN0IGluIHR3byAxMjggYml0CiAg
ICAgICAgICAgIHJlZ2lzdGVycyB2MC92MSBbMF08L2Rpdj4KICAgICAgICAgIDxkaXY+KiB0aGUg
Vk0gc3R1YiBjYWxsaW5nIGNvbnZlbnRpb24gYXJvdW5kIHRoaXMgZXhwZWN0cyBhbgogICAgICAg
ICAgICBvdXRwdXQgYnVmZmVyIHRvIGNvcHkgdjAvdjEgaW50bzombmJzcDsgWzFdPC9kaXY+CiAg
ICAgICAgICA8ZGl2Pjxmb250IGZhY2U9Im1vbm9zcGFjZSI+c3R1YihvdXQpIHsgLi4uIG91dFsw
Li4xNikgPSB2MDsKICAgICAgICAgICAgICBvdXRbMTYuLjMyKSA9IHYxOyB9PC9mb250PjwvZGl2
PgogICAgICAgICAgPGRpdj4qIHRoZSBGRk0gZG93bmNhbGwgY2FsbGluZyBjb252ZW50aW9uIE9U
T0ggZXhwZWN0cyBhCiAgICAgICAgICAgIHVzZXItcHJvdmlkZWQgU2VnbWVudEFsbG9jYXRvciB0
byBhbGxvY2F0ZSBhIDE2IGJ5dGUKICAgICAgICAgICAgU3RydWN0TGF5b3V0KEpBVkFfRE9VQkxF
LCBKQVZBX0RPVUJMRSkuIFRoZSBnZW5lcmF0ZWQgbWV0aG9kCiAgICAgICAgICAgIGhhbmRsZSB0
byBhZGFwdCB0byB0aGUgc3R1YiBsb29rcyByb3VnaGx5IGxpa2UgdGhpcyBbMl06PC9kaXY+CiAg
ICAgICAgICA8ZGl2PiZuYnNwO2ZmbShhbGxvY2F0b3IpIHs8L2Rpdj4KICAgICAgICAgIDxkaXY+
PGI+Jm5ic3A7IHRtcCA9IG1hbGxvYygzMik8L2I+PC9kaXY+CiAgICAgICAgICA8ZGl2PiZuYnNw
OyBzdHViKHRtcCk8L2Rpdj4KICAgICAgICAgIDxkaXY+Jm5ic3A7IHJlc3VsdCA9IGFsbG9jYXRv
ci5hbGxvY2F0ZSgxNik8L2Rpdj4KICAgICAgICAgIDxkaXY+Jm5ic3A7IHJlc3VsdFswLi44KSA9
IHRtcFswLi44KTwvZGl2PgogICAgICAgICAgPGRpdj4mbmJzcDsgcmVzdWx0WzguLjE2KSA9IHRt
cFsxNi4uMjQpPC9kaXY+CiAgICAgICAgICA8Yj4mbmJzcDsgZnJlZSh0bXApPC9iPjwvZGl2Pgog
ICAgICAgIDxkaXYgZGlyPSJsdHIiPiZuYnNwOyByZXR1cm4gcmVzdWx0PGJyPgogICAgICAgICAg
PGRpdj59PC9kaXY+CiAgICAgICAgICA8ZGl2Pjxicj4KICAgICAgICAgIDwvZGl2PgogICAgICAg
ICAgPGRpdj5Ob3cgdGhlcmUncyBhbiBlYXN5IHdheSBhcm91bmQgdGhpcyBmb3IgdGhlIHVzZXIg
YnkgdXNpbmcKICAgICAgICAgICAgYSBkaWZmZXJlbnQgbmF0aXZlIHNpZ25hdHVyZTo8L2Rpdj4K
ICAgICAgICAgIDxkaXY+CiAgICAgICAgICAgIDxkaXY+PGZvbnQgZmFjZT0ibW9ub3NwYWNlIj52
b2lkIGcoVmVjdG9yMkQgKm91dCkgeyAqb3V0ID0KICAgICAgICAgICAgICAgIGYoKTsgfTwvZm9u
dD48L2Rpdj4KICAgICAgICAgICAgPGRpdj5UaGlzIGVsaW1pbmF0ZXMgdGhlIGludGVybWVkaWF0
ZSBidWZmZXIgYWx0b2dldGhlci48L2Rpdj4KICAgICAgICAgICAgPGRpdj48YnI+CiAgICAgICAg
ICAgIDwvZGl2PgogICAgICAgICAgICA8ZGl2PgogICAgICAgICAgICAgIDxkaXY+SG93ZXZlciwg
aWYgd2Ugd2FudGVkIHRvIG9wdGltaXplIHRoZSByZXR1cm4tYnktdmFsdWUKICAgICAgICAgICAg
ICAgIHBhdGgsIEkgY2FuIHRoaW5rIG9mIHRocmVlIG9wdGlvbnM6PC9kaXY+CiAgICAgICAgICAg
ICAgPGRpdj4qIGVuaGFuY2UgdGhlIHN0dWIgY2FsbGluZyBjb252ZW50aW9ucyB0byBkaXJlY3Rs
eQogICAgICAgICAgICAgICAgY29weSBvbmx5IHRoZSBuYXJyb3dlZCBvdXRwdXQgcmVnaXN0ZXJz
IGludG8gdGhlIHJlc3VsdAogICAgICAgICAgICAgICAgYnVmZmVyLiZuYnNwOyBUaGlzIGxvb2tz
IHJhdGhlciBpbnZvbHZlZC48L2Rpdj4KICAgICAgICAgICAgICA8ZGl2PiogYWxsb2NhdGUgdGhl
IHRtcCBidWZmZXIgdXNpbmcgdGhlIHVzZXIncyBhbGxvY2F0b3IKICAgICAgICAgICAgICAgIGFz
IHdlbGwgKGUuZy4gaW4gY29uanVuY3Rpb24mbmJzcDt3aXRoIHRoZSByZXN1bHQgKyBzbGljaW5n
KS4KICAgICAgICAgICAgICAgIFRoZSBMaW5rZXIgYXBpIGlzIHNvbWV3aGF0IGxlbmllbnQgYWJv
dXQgaG93IGBhbGxvY2F0b3JgCiAgICAgICAgICAgICAgICB3aWxsIGJlIGV4YWN0bHkgaW52b2tl
ZDogInVzZWQgYnkgdGhlIGxpbmtlciBydW50aW1lIHRvCiAgICAgICAgICAgICAgICBhbGxvY2F0
ZSB0aGUgbWVtb3J5IHJlZ2lvbiBhc3NvY2lhdGVkIHdpdGggdGhlIHN0cnVjdAogICAgICAgICAg
ICAgICAgcmV0dXJuZWQgYnkgdGhlIGRvd25jYWxsIG1ldGhvZCBoYW5kbGUiLiZuYnNwOyBIb3dl
dmVyLCB0aGlzCiAgICAgICAgICAgICAgICBtYXkgYmUgc3VycHJpc2luZyB0byB0aGUgY2FsbGVy
LjwvZGl2PgogICAgICAgICAgICAgIDxkaXY+KiBrZWVwIHRoZSB0bXAgYnVmZmVyIGFsbG9jYXRp
b24gaW50ZXJuYWwsIGJ1dAogICAgICAgICAgICAgICAgb3B0aW1pemUgaXQuIFRoaXMgaXMgd2hh
dCBJJ20gcHJvcG9zaW5nIGhlcmUuPC9kaXY+CiAgICAgICAgICAgICAgPGRpdj48YnI+CiAgICAg
ICAgICAgICAgPC9kaXY+CiAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgICA8ZGl2PkEmbmJz
cDtwb3NzaWJsZSBjb3VudGVyLWFyZ3VtZW50IGNvdWxkIGJlICJ0aGlzIGlzIGp1c3Qgb25lCiAg
ICAgICAgICAgICAgYWxsb2NhdGlvbiZuYnNwO291dCBvZiB0d28iLiBIb3dldmVyLCB0aGUgdXNl
ciBoYXMgY29udHJvbCBvdmVyCiAgICAgICAgICAgICAgYGFsbG9jYXRvcmAsIGFuZCBtYXkgcmUt
dXNlIHRoZSBzYW1lIHNlZ21lbnQgYWNyb3NzIGNhbGxzLAogICAgICAgICAgICAgIGJ1dCB0aGV5
IGhhdmUgbm8gY29udHJvbCBvdmVyIHRoZSB0bXAgYWxsb2NhdGlvbi48L2Rpdj4KICAgICAgICAg
ICAgPGRpdj48YnI+CiAgICAgICAgICAgIDwvZGl2PgogICAgICAgICAgPC9kaXY+CiAgICAgICAg
ICA8ZGl2PgogICAgICAgICAgICA8ZGl2PkkndmUgd29ya2VkIG9uIGEgcGF0Y2ggdGhhdCB0YWtl
cyB0aGlzIGxhc3Qgcm91dGUsCiAgICAgICAgICAgICAgdXNpbmcgYSBvbmUtZWxlbWVudCB0aHJl
YWQtbG9jYWwgY2FjaGU6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL29wZW5qZGsv
amRrL3B1bGwvMjMxNDIiIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNs
YXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiPmh0dHBzOi8vZ2l0aHViLmNvbS9vcGVuamRrL2pk
ay9wdWxsLzIzMTQyPC9hPiwKICAgICAgICAgICAgICBpdCByZWR1Y2VzIGNhbGwgdGltZSBmcm9t
IDM2LSZndDs4bnMgLyBvcCBvbiBteSBtYWNoaW5lCiAgICAgICAgICAgICAgYW5kIEkgb2JzZXJ2
ZSBubyBtb3JlIEdDJ3MuPC9kaXY+CiAgICAgICAgICA8L2Rpdj4KICAgICAgICAgIDxkaXY+PGJy
PgogICAgICAgICAgPC9kaXY+CiAgICAgICAgICA8ZGl2PldvdWxkIHRoZXJlIGJlIGludGVyZXN0
IGluIHB1cnN1aW5nIHRoaXM/PC9kaXY+CiAgICAgICAgICA8ZGl2Pjxicj4KICAgICAgICAgIDwv
ZGl2PgogICAgICAgICAgPGRpdj5UaHg8L2Rpdj4KICAgICAgICAgIDxkaXY+TWF0dGhpYXM8L2Rp
dj4KICAgICAgICAgIDxkaXY+PGJyPgogICAgICAgICAgPC9kaXY+CiAgICAgICAgICA8ZGl2Pjxi
cj4KICAgICAgICAgIDwvZGl2PgogICAgICAgICAgPGRpdj5bMF0mbmJzcDs8YSBocmVmPSJodHRw
czovL2xlYXJuLm1pY3Jvc29mdC5jb20vZW4tdXMvY3BwL2J1aWxkL2FybTY0LXdpbmRvd3MtYWJp
LWNvbnZlbnRpb25zP3ZpZXc9bXN2Yy0xNzAjcmV0dXJuLXZhbHVlcyIgdGFyZ2V0PSJfYmxhbmsi
IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCI+aHR0
cHM6Ly9sZWFybi5taWNyb3NvZnQuY29tL2VuLXVzL2NwcC9idWlsZC9hcm02NC13aW5kb3dzLWFi
aS1jb252ZW50aW9ucz92aWV3PW1zdmMtMTcwI3JldHVybi12YWx1ZXM8L2E+PC9kaXY+CiAgICAg
ICAgICA8ZGl2PlsxXSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9vcGVuamRrL2pk
ay9ibG9iLzljNDMwYzkyMjU3NzM5NzMwMTU1ZGYwNWYzNDBmZTE0NGZkMjQwOTgvc3JjL2phdmEu
YmFzZS9zaGFyZS9jbGFzc2VzL2pkay9pbnRlcm5hbC9mb3JlaWduL2FiaS9DYWxsaW5nU2VxdWVu
Y2VCdWlsZGVyLmphdmEjTDk3IiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVl
IiBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0Ij5odHRwczovL2dpdGh1Yi5jb20vb3Blbmpk
ay9qZGsvYmxvYi85YzQzMGM5MjI1NzczOTczMDE1NWRmMDVmMzQwZmUxNDRmZDI0MDk4L3NyYy9q
YXZhLmJhc2Uvc2hhcmUvY2xhc3Nlcy9qZGsvaW50ZXJuYWwvZm9yZWlnbi9hYmkvQ2FsbGluZ1Nl
cXVlbmNlQnVpbGRlci5qYXZhI0w5NzwvYT48L2Rpdj4KICAgICAgICAgIDxkaXY+WzJdICJiaW5k
aW5nIGNvbnRleHQiOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9vcGVuamRrL2pk
ay9ibG9iLzljNDMwYzkyMjU3NzM5NzMwMTU1ZGYwNWYzNDBmZTE0NGZkMjQwOTgvc3JjL2phdmEu
YmFzZS9zaGFyZS9jbGFzc2VzL2pkay9pbnRlcm5hbC9mb3JlaWduL2FiaS9CaW5kaW5nU3BlY2lh
bGl6ZXIuamF2YSNMMjk2IiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBj
bGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0Ij5odHRwczovL2dpdGh1Yi5jb20vb3Blbmpkay9q
ZGsvYmxvYi85YzQzMGM5MjI1NzczOTczMDE1NWRmMDVmMzQwZmUxNDRmZDI0MDk4L3NyYy9qYXZh
LmJhc2Uvc2hhcmUvY2xhc3Nlcy9qZGsvaW50ZXJuYWwvZm9yZWlnbi9hYmkvQmluZGluZ1NwZWNp
YWxpemVyLmphdmEjTDI5NjwvYT48L2Rpdj4KICAgICAgICA8L2Rpdj4KICAgICAgPC9kaXY+CiAg
ICA8L2Jsb2NrcXVvdGU+CiAgPC9kaXY+Cgo8L2Jsb2NrcXVvdGU+PC9kaXY+CjwvZGl2PjwvYmxv
Y2txdW90ZT48L2Rpdj48YnI+PC9kaXY+CjwvYmxvY2txdW90ZT4=" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0;">​</div>
    </div>
  </body>
</html>