<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="markdown-here-wrapper" data-md-url="Thunderbird"
style="">
<p style="margin: 0px 0px 1.2em !important;">Number 2 of 100 in a
series of “What we learned in Phase I of Project Valhalla.” This
one focuses on the challenges of evolving a class to be
any-generic, while interacting with existing erased code. No
solutions here, just recaps of problems and challenges.<br>
</p>
<p style="margin: 0px 0px 1.2em !important;">Let’s imagine a class
today:</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;">interface Boxy<T> {
T get();
void set(T t);
}
class Foo<T> implements Boxy<T> {
public T t;
public T[] tArray;
public Foo(T t) { set(t); }
public static<T> Foo<T> of(T t) { return new Foo(t); }
T get() { return t; }
void set(T t) {
this.t = t;
this.tArray = (T[]) new Object[1] { t };
}
}
</code></pre>
<p style="margin: 0px 0px 1.2em !important;">and client code</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;">Foo<String> fs = new Foo<>("boo");
println(fs.t);
println(fs.tArray);
println(fs.get());
Foo<?> wc = fs;
if (wc instanceof Foo) { ... }
</code></pre>
<p style="margin: 0px 0px 1.2em !important;">When we compile this
code, we’ll encounter <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;">LFoo;</code>
or <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;">Constant_class[Foo]</code>
or just plain <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;">Foo</code>
in the following contexts:</p>
<ul style="margin: 1.2em 0px;padding-left: 2em;">
<li style="margin: 0.5em 0px;">Foo extends Bar</li>
<li style="margin: 0.5em 0px;">instanceof/checkcast Foo</li>
<li style="margin: 0.5em 0px;">new Foo</li>
<li style="margin: 0.5em 0px;">anewarray Foo[]</li>
<li style="margin: 0.5em 0px;">getfield Foo.t:Object</li>
<li style="margin: 0.5em 0px;">invokevirtual Foo.get():Object</li>
<li style="margin: 0.5em 0px;">Method descriptors of <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;">Foo::of</code></li>
</ul>
<p style="margin: 0px 0px 1.2em !important;">We translate raw <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;">Foo</code>,
<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;">Foo<String></code>,
and <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;">Foo<?></code>
all the same way today — <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;">LFoo</code>.
</p>
<h4
id="tentative-simplification-reference-instantiations-are-always-erased"
style="margin: 1.3em 0px 1em; padding: 0px; font-weight:

bold;font-size: 1.2em;">Tentative simplification: reference
instantiations are always erased</h4>
<p style="margin: 0px 0px 1.2em !important;">The specialization
transform takes a template class and a set of type parameters
and produces a specialized class. This can cause member (and
supertype) signatures to change; for example, if we have</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;">T get()
</code></pre>
<p style="margin: 0px 0px 1.2em !important;">which erases to</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;">Object get()
</code></pre>
<p style="margin: 0px 0px 1.2em !important;">when we specialize
with T=int, we’ll have</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;">int get()
</code></pre>
<p style="margin: 0px 0px 1.2em !important;">In theory, there’s
nothing to stop us from specializing List<t> with T=String.
However, in the earlier exploration, we settled on the
tentative simplification of always erasing reference
instantiations, and only specializing value instantiations.
This is a tradeoff; we’re still throwing away potentially
useful type information (erasure haters will be disappointed),
in exchange for much greater sharing, and avoiding some
compatibility issues (existing generic code is rife with
tricks like “casting through wildcards” to coerce a <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;">Foo<A></code>
to <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;">Foo<B></code>,
which only works as long as we erase; dirty tricks like this
are often necessary as there are some things that are hard to
express in the generic type system, even though the programmer
knows them.) </t></p>
<p style="margin: 0px 0px 1.2em !important;">Ignoring multiple
type parameters for the moment, when <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;">Foo</code>
becomes specializable, our model is that it will have an <em>erased</em>
species — call it <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;">Foo<erased></code>.
(If you ask it what its type parameters are, it will say
“erased”. That is, we reify the fact that it is erased…) While
migrating from erased to specialized generics requires source
changes and recompilation at the generic class declaration, it
should not require any changes or recompilation for clients.
That means that legacy client classfiles that talk about <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;">Foo</code>
must be considered to be talking about <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;">Foo<erased></code>.
(Hierarchies can be specialized from the top down, so it is OK
to specialize <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;">Bar</code>
before <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;">Foo</code>,
but not the other way around.)</p>
<p style="margin: 0px 0px 1.2em !important;">While the generic
specialization machinery will have no problem with specializing
to L-types, I think its a simplification we should hold on to,
that we treat all L type parameters as “erased” for purposes of
specialization. </p>
<h4
id="additional-simplification-let-s-not-worry-about-primitives"
style="margin: 1.3em 0px 1em; padding: 0px; font-weight:

bold;font-size: 1.2em;">Additional simplification: let’s not
worry about primitives</h4>
<p style="margin: 0px 0px 1.2em !important;">In Burlington, we
concluded that as long as there’s a Pox class for each
primitive, we can convert primitives to/from poxes through
source compiler transforms, and not worry about specializing
over primitives. Instead, when the user wants to specialize List<int>,
we instead specialize for int’s pox. Except for those pesky
arrays … more on that later. </int></p>
<h4 id="assumption-wild-means-wild" style="margin: 1.3em 0px
1em;
 padding: 0px; font-weight: bold;font-size: 1.2em;">Assumption:
wild means wild</h4>
<p style="margin: 0px 0px 1.2em !important;">On the other hand,
one of the non-simplifying assumptions we want to make is that a
wildcard type — <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;">Foo<?></code>
— should describe any instantiation of <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;">Foo</code>,
even when the wildcard-using code doesn’t know about
specialization. (Same with raw usages of <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;">Foo</code>.)
For example, if the user has written a method:</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;">takeFoo(Foo<?> anyFoo) { anyFoo.m(); }
</code></pre>
<p style="margin: 0px 0px 1.2em !important;">in legacy (erased)
code, we should be able to call <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;">takeFoo()</code>
with both erased and specialized instances of <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;">Foo</code>.
As we’ll see, this complicates member access, and really
complicates arrays. </p>
<p style="margin: 0px 0px 1.2em !important;">We will find
utterances like</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;">invokevirtual Foo.get()Object
getfield Foo.m:Object
</code></pre>
<p style="margin: 0px 0px 1.2em !important;">in legacy code; we
want these to work against any specialization of <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;">Foo</code>.
</p>
<p style="margin: 0px 0px 1.2em !important;">In the case where the
instance is erased, things obviously have a decent chance of
lining up properly, as the erased members will not have been
specialized away. If our receiver is a specialized <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;">Foo</code>,
it gets harder, as the member signatures will have changed due
to specialization. </p>
<p style="margin: 0px 0px 1.2em !important;">Starting in Model 2,
we handled this with bridge methods; for each specialized
method, we also had an erased bridge. This is possible because
there’s an easy coercion from <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;">QPoint</code>
to <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;">LObject</code>.
(There are other ways to get there besides bridges.) </p>
<p style="margin: 0px 0px 1.2em !important;">Where this completely
runs out of gas is in field access; there’s no such thing as a
“bridge field”. So legacy code that does <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;">getfield Foo.t:Object</code>
will fall over at link time, since the type of field <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;">t</code>
in a specialized <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;">Foo</code>
might not be <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;">Object</code>.
</p>
<p style="margin: 0px 0px 1.2em !important;">Another place this
falls short is when a signature has <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;">T[]</code>
in it. Even with bridge methods, without either array covariance
(this is what I meant when I said it might come back) or a
willingness to copy, a legacy client that invokes a method that
returns a <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;">T[]</code>
will invoke it expecting an <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;">Object[]</code>,
but without array covariance, a <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;">Point.Val[]</code>
is not an <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;">Object[]</code>.
(Note that relatively few methods actually expose <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;">T[]</code>
parameters, so its possible there are other dodges here.)</p>
<h4 id="wildcards" style="margin: 1.3em 0px 1em; padding:
0px;
 font-weight: bold;font-size: 1.2em;">Wildcards</h4>
<p style="margin: 0px 0px 1.2em !important;">One of the central
challenges of pushing specialization into the VM is how we’re
going to handle wildcards. Given a generic class <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;">Foo</code>,
the wildcard type <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;">Foo<?></code>
is a supertype of any instantiation <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;">Foo<X></code>
of <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;">Foo</code>.
The wildcard type also erases to <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;">LFoo</code>.
</p>
<p style="margin: 0px 0px 1.2em !important;">In Model 2, we
modeled wildcards as interfaces, with lots and lots of bridges,
but this still fell short in a number of ways: no support for
non-public methods or for fields, and we had to deal with fields
by hoisting them into virtual bridges on the interface.</p>
<p style="margin: 0px 0px 1.2em !important;">Note that the
wildcard subtyping also matters to the verifier, in addition to
handling bytecodes; the verifier must know that any
specialization of <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;">Foo</code>
is a subtype of the wildcard <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;">LFoo</code>.
</p>
<h4 id="but-what-does-lfoo-mean-" style="margin: 1.3em 0px
1em;
 padding: 0px; font-weight: bold;font-size: 1.2em;">But
what does <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;">LFoo</code>
mean?</h4>
<p style="margin: 0px 0px 1.2em !important;">Careful readers will
notice that we’ve been playing fast and loose with the meaning
of <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;">Foo</code>;
sometimes it means the class, sometimes the wildcard, and
sometimes the erased species. </p>
<p style="margin: 0px 0px 1.2em !important;">The best intuition
we’ve been able to come up with is:</p>
<ul style="margin: 1.2em 0px;padding-left: 2em;">
<li style="margin: 0.5em 0px;">There are <em>classes</em> and <em>crasses</em>.
</li>
<li style="margin: 0.5em 0px;">A crass describes a single
runtime type; it has a layout, methods, constructors, etc. </li>
<li style="margin: 0.5em 0px;">A (template) class describes a
family of runtime types. </li>
<li style="margin: 0.5em 0px;">A (template) class is like an
abstract type; it has members and subtypes, but can’t be
instantiated directly. </li>
<li style="margin: 0.5em 0px;">All the crasses derived from a
class are subtypes of the class. </li>
<li style="margin: 0.5em 0px;">For purposes of instantiation, we
interpret <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;">new Foo</code>
as creating an instance of the erased species, and a similar
game with <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;"><init></code>
methods. </li>
</ul>
<h2 id="model-3-classfile-extensions" style="margin: 1.3em
0px
 1em; padding: 0px; font-weight: bold;font-size:
1.4em;
 border-bottom: 1px solid rgb(238, 238, 238);">Model
3 classfile extensions</h2>
<p style="margin: 0px 0px 1.2em !important;">In Model 3, we
extended the constant pool with some new entries:</p>
<p style="margin: 0px 0px 1.2em !important;"><strong>TypeVar[n,
erasure].</strong> This is a use of a type variable,
identified by its index <em>n</em>. (There was a
table-of-contents attribute listing all the type variables
declared in a generic class or method, including those declared
in enclosing generic classes or methods.) Since the erasure of a
type variable is not merely a property of the type variable, but
in fact a property of how it is used, each use of a type
variable carries around its own erasure. For field whose type is
<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;">T</code>,
the <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;">NameAndType</code>
points not to <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;">Object</code>,
but to <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;">TypeVar[0, Object]</code>.
</p>
<p style="margin: 0px 0px 1.2em !important;">When specializing a
type variable to <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;">erased</code>,
any uses of that type variable are replaced with the erasure in
the <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;">TypeVar</code>
entry. </p>
<p style="margin: 0px 0px 1.2em !important;"><strong>MethodType[D,T…].</strong>
This is largely a syntactic mechanism, allowing us to represent
method descriptors with holes (but also had the benefit of
compressing the constant pool somewhat.) The parameter <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;">D</code>
was a method type descriptor, except that in addition to the
existing types, one could specify <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;">#</code>
to indicate a hole; the <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;">T...</code>
parameters are CP indexes to other types (which could be UTF8
strings, or <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;">TypeVar</code>,
or the other type CP entries listed below.) </p>
<p style="margin: 0px 0px 1.2em !important;">For example, a method</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;">int size(T t)
</code></pre>
<p style="margin: 0px 0px 1.2em !important;">would have a
signature</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;">#1 = TypeVar[0, Object]
#2 = MethodType[(#)I, #1]
</code></pre>
<p style="margin: 0px 0px 1.2em !important;">When specializing a <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;">MethodType</code>,
its parameters are recursively specialized, and then the
resulting strings concatenated. </p>
<p style="margin: 0px 0px 1.2em !important;"><strong>ParamType[C,T…].</strong>
This represents a parameterized type, where <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;">C</code>
is a class name, and <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;">T...</code>
are the type parameters. So <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;">List<int></code>
would be represented as <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;">ParamType[List,I]</code>,
and <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;">List<T></code>
would be represented as <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;">ParamType[List,TypeVar[0,e]]</code>.<br>
When specializing a <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;">ParamType</code>,
its parameters are recursively specialized, and then the
resulting instantiation is computed. </p>
<p style="margin: 0px 0px 1.2em !important;"><strong>ArrayType[T,rank].</strong>
This represents an array of given rank. </p>
<p style="margin: 0px 0px 1.2em !important;">The type parameters
of a <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;">ParamType</code>,
<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;">ArrayType</code>,
or <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;">MethodType</code>
can themselves be a <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;">TypeVar</code>,
<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;">ParamType</code>,
or <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;">ArrayType</code>,
as well as a UTF8. </p>
<p style="margin: 0px 0px 1.2em !important;">We found that as a
template language, these types allowed exactly the sort of
expressiveness needed, and specialized efficiently down to
concrete descriptors (though in the M3 prototype, we had
concrete descriptors of the form <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;">List$0=I</code>
to describe <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;">List<int></code>,
obviously we don’t want that here.) But these designs captured
all the complexity we needed (especially that of erasure), and
allowed a mechanical translation int Java 8 classfiles. </p>
<div
title="MDH:PHR0Pk51bWJlciAyIG9mIDEwMCBpbiBhIHNlcmllcyBvZiAiV2hhdCB3ZSBsZWFybmVkIGluIFBo
YXNlIEkgb2YgUHJvamVjdCBWYWxoYWxsYS4iJm5ic3A7IFRoaXMgb25lIGZvY3VzZXMgb24gdGhl
IGNoYWxsZW5nZXMgb2YgZXZvbHZpbmcgYSBjbGFzcyB0byBiZSBhbnktZ2VuZXJpYywgd2hpbGUg
aW50ZXJhY3Rpbmcgd2l0aCBleGlzdGluZyBlcmFzZWQgY29kZS4gPGJyPjxicj5MZXQncyBpbWFn
aW5lIGEgY2xhc3MgdG9kYXk6PGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsgaW50ZXJmYWNlIEJv
eHkmbHQ7VCZndDsgezxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgVCBnZXQoKTs8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHZvaWQgc2V0KFQgdCk7PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyB9PGJyPjxicj4mbmJzcDsmbmJz
cDsmbmJzcDsgY2xhc3MgRm9vJmx0O1QmZ3Q7IGltcGxlbWVudHMgQm94eSZsdDtUJmd0OyB7PGJy
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwdWJsaWMgVCB0Ozxi
cj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHVibGljIFRbXSB0
QXJyYXk7PGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
cHVibGljIEZvbyhUIHQpIHsgc2V0KHQpOyB9PGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgcHVibGljIHN0YXRpYyZsdDtUJmd0OyBGb28mbHQ7VCZndDsg
b2YoVCB0KSB7IHJldHVybiBuZXcgRm9vKHQpOyB9PGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVCBnZXQoKSB7IHJldHVybiB0OyB9PGJyPjxicj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdm9pZCBzZXQoVCB0KSB7PGJy
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyB0aGlzLnQgPSB0Ozxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhpcy50QXJyYXkgPSAoVFtdKSBu
ZXcgT2JqZWN0WzFdIHsgdCB9Ozxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgfTxicj4mbmJzcDsmbmJzcDsmbmJzcDsgfTxicj48YnI+YW5kIGNsaWVudCBjb2Rl
PGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsgRm9vJmx0O1N0cmluZyZndDsgZnMgPSBuZXcgRm9v
Jmx0OyZndDsoImJvbyIpOzxicj4mbmJzcDsmbmJzcDsmbmJzcDsgcHJpbnRsbihmcy50KTs8YnI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7IHByaW50bG4oZnMudEFycmF5KTs8YnI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7IHByaW50bG4oZnMuZ2V0KCkpOzxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZvbyZsdDs/
Jmd0OyB3YyA9IGZzOzxicj4mbmJzcDsmbmJzcDsmbmJzcDsgaWYgKHdjIGluc3RhbmNlb2YgRm9v
KSB7IC4uLiB9PGJyPjxicj5XaGVuIHdlIGNvbXBpbGUgdGhpcyBjb2RlLCB3ZSdsbCBlbmNvdW50
ZXIgYExGb287YCBvciBgQ29uc3RhbnRfY2xhc3NbRm9vXWAgb3IganVzdCBwbGFpbiBgRm9vYCBp
biB0aGUgZm9sbG93aW5nIGNvbnRleHRzOjxicj48YnI+Jm5ic3A7LSBGb28gZXh0ZW5kcyBCYXI8
YnI+Jm5ic3A7LSBpbnN0YW5jZW9mL2NoZWNrY2FzdCBGb288YnI+Jm5ic3A7LSBuZXcgRm9vPGJy
PiZuYnNwOy0gYW5ld2FycmF5IEZvb1tdPGJyPiZuYnNwOy0gZ2V0ZmllbGQgRm9vLnQ6T2JqZWN0
PGJyPiZuYnNwOy0gaW52b2tldmlydHVhbCBGb28uZ2V0KCk6T2JqZWN0PGJyPiZuYnNwOy0gTWV0
aG9kIGRlc2NyaXB0b3JzIG9mIGBGb286Om9mYDxicj48YnI+V2UgdHJhbnNsYXRlIHJhdyBgRm9v
YCwgYEZvbyZsdDtTdHJpbmcmZ3Q7YCwgYW5kIGBGb28mbHQ7PyZndDtgIGFsbCB0aGUgc2FtZSB3
YXkgdG9kYXkgLS0gYExGb29gLiA8YnI+PGJyPiMjIyMgVGVudGF0aXZlIHNpbXBsaWZpY2F0aW9u
OiByZWZlcmVuY2UgaW5zdGFudGlhdGlvbnMgYXJlIGFsd2F5cyBlcmFzZWQ8YnI+PGJyPlRoZSBz
cGVjaWFsaXphdGlvbiB0cmFuc2Zvcm0gdGFrZXMgYSB0ZW1wbGF0ZSBjbGFzcyBhbmQgYSBzZXQg
b2YgdHlwZSBwYXJhbWV0ZXJzIGFuZCBwcm9kdWNlcyBhIHNwZWNpYWxpemVkIGNsYXNzLiZuYnNw
OyBUaGlzIGNhbiBjYXVzZSBtZW1iZXIgKGFuZCBzdXBlcnR5cGUpIHNpZ25hdHVyZXMgdG8gY2hh
bmdlOyBmb3IgZXhhbXBsZSwgaWYgd2UgaGF2ZTxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IFQg
Z2V0KCk8YnI+PGJyPndoaWNoIGVyYXNlcyB0bzxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IE9i
amVjdCBnZXQoKTxicj48YnI+d2hlbiB3ZSBzcGVjaWFsaXplIHdpdGggVD1pbnQsIHdlJ2xsIGhh
dmU8YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyBpbnQgZ2V0KCk8YnI+PGJyPkluIHRoZW9yeSwg
dGhlcmUncyBub3RoaW5nIHRvIHN0b3AgdXMgZnJvbSBzcGVjaWFsaXppbmcgTGlzdCZsdDtUJmd0
OyB3aXRoIFQ9U3RyaW5nLiZuYnNwOyBIb3dldmVyLCBpbiB0aGUgZWFybGllciBleHBsb3JhdGlv
biwgd2Ugc2V0dGxlZCBvbiB0aGUgdGVudGF0aXZlIHNpbXBsaWZpY2F0aW9uIG9mIGFsd2F5cyBl
cmFzaW5nIHJlZmVyZW5jZSBpbnN0YW50aWF0aW9ucywgYW5kIG9ubHkgc3BlY2lhbGl6aW5nIHZh
bHVlIGluc3RhbnRpYXRpb25zLiZuYnNwOyBUaGlzIGlzIGEgdHJhZGVvZmY7IHdlJ3JlIHN0aWxs
IHRocm93aW5nIGF3YXkgcG90ZW50aWFsbHkgdXNlZnVsIHR5cGUgaW5mb3JtYXRpb24gKGVyYXN1
cmUgaGF0ZXJzIHdpbGwgYmUgZGlzYXBwb2ludGVkKSwgaW4gZXhjaGFuZ2UgZm9yIG11Y2ggZ3Jl
YXRlciBzaGFyaW5nLCBhbmQgYXZvaWRpbmcgc29tZSBjb21wYXRpYmlsaXR5IGlzc3VlcyAoZXhp
c3RpbmcgZ2VuZXJpYyBjb2RlIGlzIHJpZmUgd2l0aCB0cmlja3MgbGlrZSAiY2FzdGluZyB0aHJv
dWdoIHdpbGRjYXJkcyIgdG8gY29lcmNlIGEgYEZvbyZsdDtBJmd0O2AgdG8gYEZvbyZsdDtCJmd0
O2AsIHdoaWNoIG9ubHkgd29ya3MgYXMgbG9uZyBhcyB3ZSBlcmFzZTsgZGlydHkgdHJpY2tzIGxp
a2UgdGhpcyBhcmUgb2Z0ZW4gbmVjZXNzYXJ5IGFzIHRoZXJlIGFyZSBzb21lIHRoaW5ncyB0aGF0
IGFyZSBoYXJkIHRvIGV4cHJlc3MgaW4gdGhlIGdlbmVyaWMgdHlwZSBzeXN0ZW0sIGV2ZW4gdGhv
dWdoIHRoZSBwcm9ncmFtbWVyIGtub3dzIHRoZW0uKSA8YnI+PGJyPklnbm9yaW5nIG11bHRpcGxl
IHR5cGUgcGFyYW1ldGVycyBmb3IgdGhlIG1vbWVudCwgd2hlbiBgRm9vYCBiZWNvbWVzIHNwZWNp
YWxpemFibGUsIG91ciBtb2RlbCBpcyB0aGF0IGl0IHdpbGwgaGF2ZSBhbiBfZXJhc2VkXyBzcGVj
aWVzIC0tIGNhbGwgaXQgYEZvbyZsdDtlcmFzZWQmZ3Q7YC4mbmJzcDsgKElmIHlvdSBhc2sgaXQg
d2hhdCBpdHMgdHlwZSBwYXJhbWV0ZXJzIGFyZSwgaXQgd2lsbCBzYXkgImVyYXNlZCIuJm5ic3A7
IFRoYXQgaXMsIHdlIHJlaWZ5IHRoZSBmYWN0IHRoYXQgaXQgaXMgZXJhc2VkLi4uKSZuYnNwOyBX
aGlsZSBtaWdyYXRpbmcgZnJvbSBlcmFzZWQgdG8gc3BlY2lhbGl6ZWQgZ2VuZXJpY3MgcmVxdWly
ZXMgc291cmNlIGNoYW5nZXMgYW5kIHJlY29tcGlsYXRpb24gYXQgdGhlIGdlbmVyaWMgY2xhc3Mg
ZGVjbGFyYXRpb24sIGl0IHNob3VsZCBub3QgcmVxdWlyZSBhbnkgY2hhbmdlcyBvciByZWNvbXBp
bGF0aW9uIGZvciBjbGllbnRzLiZuYnNwOyBUaGF0IG1lYW5zIHRoYXQgbGVnYWN5IGNsaWVudCBj
bGFzc2ZpbGVzIHRoYXQgdGFsayBhYm91dCBgRm9vYCBtdXN0IGJlIGNvbnNpZGVyZWQgdG8gYmUg
dGFsa2luZyBhYm91dCBgRm9vJmx0O2VyYXNlZCZndDtgLiZuYnNwOyAoSGllcmFyY2hpZXMgY2Fu
IGJlIHNwZWNpYWxpemVkIGZyb20gdGhlIHRvcCBkb3duLCBzbyBpdCBpcyBPSyB0byBzcGVjaWFs
aXplIGBCYXJgIGJlZm9yZSBgRm9vYCwgYnV0IG5vdCB0aGUgb3RoZXIgd2F5IGFyb3VuZC4pPGJy
Pjxicj5XaGlsZSB0aGUgZ2VuZXJpYyBzcGVjaWFsaXphdGlvbiBtYWNoaW5lcnkgd2lsbCBoYXZl
IG5vIHByb2JsZW0gd2l0aCBzcGVjaWFsaXppbmcgdG8gTC10eXBlcywgSSB0aGluayBpdHMgYSBz
aW1wbGlmaWNhdGlvbiB3ZSBzaG91bGQgaG9sZCBvbiB0bywgdGhhdCB3ZSB0cmVhdCBhbGwgTCB0
eXBlIHBhcmFtZXRlcnMgYXMgImVyYXNlZCIgZm9yIHB1cnBvc2VzIG9mIHNwZWNpYWxpemF0aW9u
LiA8YnI+PGJyPiMjIyMgQWRkaXRpb25hbCBzaW1wbGlmaWNhdGlvbjogbGV0J3Mgbm90IHdvcnJ5
IGFib3V0IHByaW1pdGl2ZXM8YnI+PGJyPkluIEJ1cmxpbmd0b24sIHdlIGNvbmNsdWRlZCB0aGF0
IGFzIGxvbmcgYXMgdGhlcmUncyBhIFBveCBjbGFzcyBmb3IgZWFjaCBwcmltaXRpdmUsIHdlIGNh
biBjb252ZXJ0IHByaW1pdGl2ZXMgdG8vZnJvbSBwb3hlcyB0aHJvdWdoIHNvdXJjZSBjb21waWxl
ciB0cmFuc2Zvcm1zLCBhbmQgbm90IHdvcnJ5IGFib3V0IHNwZWNpYWxpemluZyBvdmVyIHByaW1p
dGl2ZXMuJm5ic3A7IEluc3RlYWQsIHdoZW4gdGhlIHVzZXIgd2FudHMgdG8gc3BlY2lhbGl6ZSBM
aXN0Jmx0O2ludCZndDssIHdlIGluc3RlYWQgc3BlY2lhbGl6ZSBmb3IgaW50J3MgcG94LiZuYnNw
OyBFeGNlcHQgZm9yIHRob3NlIHBlc2t5IGFycmF5cyAuLi4gbW9yZSBvbiB0aGF0IGxhdGVyLiA8
YnI+PGJyPiMjIyMgQXNzdW1wdGlvbjogd2lsZCBtZWFucyB3aWxkPGJyPjxicj5PbiB0aGUgb3Ro
ZXIgaGFuZCwgb25lIG9mIHRoZSBub24tc2ltcGxpZnlpbmcgYXNzdW1wdGlvbnMgd2Ugd2FudCB0
byBtYWtlIGlzIHRoYXQgYSB3aWxkY2FyZCB0eXBlIC0tIGBGb28mbHQ7PyZndDtgIC0tIHNob3Vs
ZCBkZXNjcmliZSBhbnkgaW5zdGFudGlhdGlvbiBvZiBgRm9vYCwgZXZlbiB3aGVuIHRoZSB3aWxk
Y2FyZC11c2luZyBjb2RlIGRvZXNuJ3Qga25vdyBhYm91dCBzcGVjaWFsaXphdGlvbi4mbmJzcDsg
KFNhbWUgd2l0aCByYXcgdXNhZ2VzIG9mIGBGb29gLikmbmJzcDsgRm9yIGV4YW1wbGUsIGlmIHRo
ZSB1c2VyIGhhcyB3cml0dGVuIGEgbWV0aG9kOjxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRh
a2VGb28oRm9vJmx0Oz8mZ3Q7IGFueUZvbykgeyBhbnlGb28ubSgpOyB9PGJyPjxicj5pbiBsZWdh
Y3kgKGVyYXNlZCkgY29kZSwgd2Ugc2hvdWxkIGJlIGFibGUgdG8gY2FsbCBgdGFrZUZvbygpYCB3
aXRoIGJvdGggZXJhc2VkIGFuZCBzcGVjaWFsaXplZCBpbnN0YW5jZXMgb2YgYEZvb2AuJm5ic3A7
IEFzIHdlJ2xsIHNlZSwgdGhpcyBjb21wbGljYXRlcyBtZW1iZXIgYWNjZXNzLCBhbmQgcmVhbGx5
IGNvbXBsaWNhdGVzIGFycmF5cy4gPGJyPjxicj5XZSB3aWxsIGZpbmQgdXR0ZXJhbmNlcyBsaWtl
PGJyPjxicj4mbmJzcDsmbmJzcDsmbmJzcDsgaW52b2tldmlydHVhbCBGb28uZ2V0KClPYmplY3Q8
YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGdldGZpZWxkIEZvby5tOk9iamVjdDxicj48YnI+aW4gbGVn
YWN5IGNvZGU7IHdlIHdhbnQgdGhlc2UgdG8gd29yayBhZ2FpbnN0IGFueSBzcGVjaWFsaXphdGlv
biBvZiBgRm9vYC4gPGJyPjxicj5JbiB0aGUgY2FzZSB3aGVyZSB0aGUgaW5zdGFuY2UgaXMgZXJh
c2VkLCB0aGluZ3Mgb2J2aW91c2x5IGhhdmUgYSBkZWNlbnQgY2hhbmNlIG9mIGxpbmluZyB1cCBw
cm9wZXJseSwgYXMgdGhlIGVyYXNlZCBtZW1iZXJzIHdpbGwgbm90IGhhdmUgYmVlbiBzcGVjaWFs
aXplZCBhd2F5LiZuYnNwOyBJZiBvdXIgcmVjZWl2ZXIgaXMgYSBzcGVjaWFsaXplZCBgRm9vYCwg
aXQgZ2V0cyBoYXJkZXIsIGFzIHRoZSBtZW1iZXIgc2lnbmF0dXJlcyB3aWxsIGhhdmUgY2hhbmdl
ZCBkdWUgdG8gc3BlY2lhbGl6YXRpb24uIDxicj48YnI+U3RhcnRpbmcgaW4gTW9kZWwgMiwgd2Ug
aGFuZGxlZCB0aGlzIHdpdGggYnJpZGdlIG1ldGhvZHM7IGZvciBlYWNoIHNwZWNpYWxpemVkIG1l
dGhvZCwgd2UgYWxzbyBoYWQgYW4gZXJhc2VkIGJyaWRnZS4mbmJzcDsgVGhpcyBpcyBwb3NzaWJs
ZSBiZWNhdXNlIHRoZXJlJ3MgYW4gZWFzeSBjb2VyY2lvbiBmcm9tIGBRUG9pbnRgIHRvIGBMT2Jq
ZWN0YC4mbmJzcDsgKFRoZXJlIGFyZSBvdGhlciB3YXlzIHRvIGdldCB0aGVyZSBiZXNpZGVzIGJy
aWRnZXMuKSA8YnI+PGJyPldoZXJlIHRoaXMgY29tcGxldGVseSBydW5zIG91dCBvZiBnYXMgaXMg
aW4gZmllbGQgYWNjZXNzOyB0aGVyZSdzIG5vIHN1Y2ggdGhpbmcgYXMgYSAiYnJpZGdlIGZpZWxk
Ii4mbmJzcDsgU28gbGVnYWN5IGNvZGUgdGhhdCBkb2VzIGBnZXRmaWVsZCBGb28udDpPYmplY3Rg
IHdpbGwgZmFsbCBvdmVyIGF0IGxpbmsgdGltZSwgc2luY2UgdGhlIHR5cGUgb2YgZmllbGQgYHRg
IGluIGEgc3BlY2lhbGl6ZWQgYEZvb2AgbWlnaHQgbm90IGJlIGBPYmplY3RgLiA8YnI+PGJyPkFu
b3RoZXIgcGxhY2UgdGhpcyBmYWxscyBzaG9ydCBpcyB3aGVuIGEgc2lnbmF0dXJlIGhhcyBgVFtd
YCBpbiBpdC4mbmJzcDsgRXZlbiB3aXRoIGJyaWRnZSBtZXRob2RzLCB3aXRob3V0IGVpdGhlciBh
cnJheSBjb3ZhcmlhbmNlICh0aGlzIGlzIHdoYXQgSSBtZWFudCB3aGVuIEkgc2FpZCBpdCBtaWdo
dCBjb21lIGJhY2spIG9yIGEgd2lsbGluZ25lc3MgdG8gY29weSwgYSBsZWdhY3kgY2xpZW50IHRo
YXQgaW52b2tlcyBhIG1ldGhvZCB0aGF0IHJldHVybnMgYSBgVFtdYCB3aWxsIGludm9rZSBpdCBl
eHBlY3RpbmcgYW4gYE9iamVjdFtdYCwgYnV0IHdpdGhvdXQgYXJyYXkgY292YXJpYW5jZSwgYSBg
UG9pbnQuVmFsW11gIGlzIG5vdCBhbiBgT2JqZWN0W11gLiZuYnNwOyAoTm90ZSB0aGF0IHJlbGF0
aXZlbHkgZmV3IG1ldGhvZHMgYWN0dWFsbHkgZXhwb3NlIGBUW11gIHBhcmFtZXRlcnMsIHNvIGl0
cyBwb3NzaWJsZSB0aGVyZSBhcmUgb3RoZXIgZG9kZ2VzIGhlcmUuKTxicj48YnI+IyMjIyBXaWxk
Y2FyZHM8YnI+PGJyPk9uZSBvZiB0aGUgY2VudHJhbCBjaGFsbGVuZ2VzIG9mIHB1c2hpbmcgc3Bl
Y2lhbGl6YXRpb24gaW50byB0aGUgVk0gaXMgaG93IHdlJ3JlIGdvaW5nIHRvIGhhbmRsZSB3aWxk
Y2FyZHMuJm5ic3A7IEdpdmVuIGEgZ2VuZXJpYyBjbGFzcyBgRm9vYCwgdGhlIHdpbGRjYXJkIHR5
cGUgYEZvbyZsdDs/Jmd0O2AgaXMgYSBzdXBlcnR5cGUgb2YgYW55IGluc3RhbnRpYXRpb24gYEZv
byZsdDtYJmd0O2Agb2YgYEZvb2AuJm5ic3A7IFRoZSB3aWxkY2FyZCB0eXBlIGFsc28gZXJhc2Vz
IHRvIGBMRm9vYC4gPGJyPjxicj5JbiBNb2RlbCAyLCB3ZSBtb2RlbGVkIHdpbGRjYXJkcyBhcyBp
bnRlcmZhY2VzLCB3aXRoIGxvdHMgYW5kIGxvdHMgb2YgYnJpZGdlcywgYnV0IHRoaXMgc3RpbGwg
ZmVsbCBzaG9ydCBpbiBhIG51bWJlciBvZiB3YXlzOiBubyBzdXBwb3J0IGZvciBub24tcHVibGlj
IG1ldGhvZHMgb3IgZm9yIGZpZWxkcywgYW5kIHdlIGhhZCB0byBkZWFsIHdpdGggZmllbGRzIGJ5
IGhvaXN0aW5nIHRoZW0gaW50byB2aXJ0dWFsIGJyaWRnZXMgb24gdGhlIGludGVyZmFjZS48YnI+
PGJyPk5vdGUgdGhhdCB0aGUgd2lsZGNhcmQgc3VidHlwaW5nIGFsc28gbWF0dGVycyB0byB0aGUg
dmVyaWZpZXIsIGluIGFkZGl0aW9uIHRvIGhhbmRsaW5nIGJ5dGVjb2RlczsgdGhlIHZlcmlmaWVy
IG11c3Qga25vdyB0aGF0IGFueSBzcGVjaWFsaXphdGlvbiBvZiBgRm9vYCBpcyBhIHN1YnR5cGUg
b2YgdGhlIHdpbGRjYXJkIGBMRm9vYC4gPGJyPjxicj4jIyMjIEJ1dCB3aGF0IGRvZXMgYExGb29g
IG1lYW4/PGJyPjxicj5DYXJlZnVsIHJlYWRlcnMgd2lsbCBub3RpY2UgdGhhdCB3ZSd2ZSBiZWVu
IHBsYXlpbmcgZmFzdCBhbmQgbG9vc2Ugd2l0aCB0aGUgbWVhbmluZyBvZiBgRm9vYDsgc29tZXRp
bWVzIGl0IG1lYW5zIHRoZSBjbGFzcywgc29tZXRpbWVzIHRoZSB3aWxkY2FyZCwgYW5kIHNvbWV0
aW1lcyB0aGUgZXJhc2VkIHNwZWNpZXMuIDxicj48YnI+VGhlIGJlc3QgaW50dWl0aW9uIHdlJ3Zl
IGJlZW4gYWJsZSB0byBjb21lIHVwIHdpdGggaXM6PGJyPiZuYnNwOy0gVGhlcmUgYXJlIF9jbGFz
c2VzXyBhbmQgX2NyYXNzZXNfLiA8YnI+Jm5ic3A7LSBBIGNyYXNzIGRlc2NyaWJlcyBhIHNpbmds
ZSBydW50aW1lIHR5cGU7IGl0IGhhcyBhIGxheW91dCwgbWV0aG9kcywgY29uc3RydWN0b3JzLCBl
dGMuIDxicj4mbmJzcDstIEEgKHRlbXBsYXRlKSBjbGFzcyBkZXNjcmliZXMgYSBmYW1pbHkgb2Yg
cnVudGltZSB0eXBlcy4gPGJyPiZuYnNwOy0gQSAodGVtcGxhdGUpIGNsYXNzIGlzIGxpa2UgYW4g
YWJzdHJhY3QgdHlwZTsgaXQgaGFzIG1lbWJlcnMgYW5kIHN1YnR5cGVzLCBidXQgY2FuJ3QgYmUg
aW5zdGFudGlhdGVkIGRpcmVjdGx5LiA8YnI+Jm5ic3A7LSBBbGwgdGhlIGNyYXNzZXMgZGVyaXZl
ZCBmcm9tIGEgY2xhc3MgYXJlIHN1YnR5cGVzIG9mIHRoZSBjbGFzcy4gPGJyPiZuYnNwOy0gRm9y
IHB1cnBvc2VzIG9mIGluc3RhbnRpYXRpb24sIHdlIGludGVycHJldCBgbmV3IEZvb2AgYXMgY3Jl
YXRpbmcgYW4gaW5zdGFuY2Ugb2YgdGhlIGVyYXNlZCBzcGVjaWVzLCBhbmQgYSBzaW1pbGFyIGdh
bWUgd2l0aCBgJmx0O2luaXQmZ3Q7YCBtZXRob2RzLiA8YnI+PGJyPiMjIE1vZGVsIDMgY2xhc3Nm
aWxlIGV4dGVuc2lvbnM8YnI+PGJyPkluIE1vZGVsIDMsIHdlIGV4dGVuZGVkIHRoZSBjb25zdGFu
dCBwb29sIHdpdGggc29tZSBuZXcgZW50cmllczo8YnI+PGJyPioqVHlwZVZhcltuLCBlcmFzdXJl
XS4qKiZuYnNwOyBUaGlzIGlzIGEgdXNlIG9mIGEgdHlwZSB2YXJpYWJsZSwgaWRlbnRpZmllZCBi
eSBpdHMgaW5kZXggX25fLiZuYnNwOyAoVGhlcmUgd2FzIGEgdGFibGUtb2YtY29udGVudHMgYXR0
cmlidXRlIGxpc3RpbmcgYWxsIHRoZSB0eXBlIHZhcmlhYmxlcyBkZWNsYXJlZCBpbiBhIGdlbmVy
aWMgY2xhc3Mgb3IgbWV0aG9kLCBpbmNsdWRpbmcgdGhvc2UgZGVjbGFyZWQgaW4gZW5jbG9zaW5n
IGdlbmVyaWMgY2xhc3NlcyBvciBtZXRob2RzLikmbmJzcDsgU2luY2UgdGhlIGVyYXN1cmUgb2Yg
YSB0eXBlIHZhcmlhYmxlIGlzIG5vdCBtZXJlbHkgYSBwcm9wZXJ0eSBvZiB0aGUgdHlwZSB2YXJp
YWJsZSwgYnV0IGluIGZhY3QgYSBwcm9wZXJ0eSBvZiBob3cgaXQgaXMgdXNlZCwgZWFjaCB1c2Ug
b2YgYSB0eXBlIHZhcmlhYmxlIGNhcnJpZXMgYXJvdW5kIGl0cyBvd24gZXJhc3VyZS4mbmJzcDsg
Rm9yIGZpZWxkIHdob3NlIHR5cGUgaXMgYFRgLCB0aGUgYE5hbWVBbmRUeXBlYCBwb2ludHMgbm90
IHRvIGBPYmplY3RgLCBidXQgdG8gYFR5cGVWYXJbMCwgT2JqZWN0XWAuIDxicj48YnI+V2hlbiBz
cGVjaWFsaXppbmcgYSB0eXBlIHZhcmlhYmxlIHRvIGBlcmFzZWRgLCBhbnkgdXNlcyBvZiB0aGF0
IHR5cGUgdmFyaWFibGUgYXJlIHJlcGxhY2VkIHdpdGggdGhlIGVyYXN1cmUgaW4gdGhlIGBUeXBl
VmFyYCBlbnRyeS4gPGJyPjxicj4qKk1ldGhvZFR5cGVbRCxULi4uXS4qKiZuYnNwOyBUaGlzIGlz
IGxhcmdlbHkgYSBzeW50YWN0aWMgbWVjaGFuaXNtLCBhbGxvd2luZyB1cyB0byByZXByZXNlbnQg
bWV0aG9kIGRlc2NyaXB0b3JzIHdpdGggaG9sZXMgKGJ1dCBhbHNvIGhhZCB0aGUgYmVuZWZpdCBv
ZiBjb21wcmVzc2luZyB0aGUgY29uc3RhbnQgcG9vbCBzb21ld2hhdC4pJm5ic3A7IFRoZSBwYXJh
bWV0ZXIgYERgIHdhcyBhIG1ldGhvZCB0eXBlIGRlc2NyaXB0b3IsIGV4Y2VwdCB0aGF0IGluIGFk
ZGl0aW9uIHRvIHRoZSBleGlzdGluZyB0eXBlcywgb25lIGNvdWxkIHNwZWNpZnkgYCNgIHRvIGlu
ZGljYXRlIGEgaG9sZTsgdGhlIGBULi4uYCBwYXJhbWV0ZXJzIGFyZSBDUCBpbmRleGVzIHRvIG90
aGVyIHR5cGVzICh3aGljaCBjb3VsZCBiZSBVVEY4IHN0cmluZ3MsIG9yIGBUeXBlVmFyYCwgb3Ig
dGhlIG90aGVyIHR5cGUgQ1AgZW50cmllcyBsaXN0ZWQgYmVsb3cuKSA8YnI+PGJyPkZvciBleGFt
cGxlLCBhIG1ldGhvZDxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludCBzaXplKFQgdCk8YnI+
PGJyPndvdWxkIGhhdmUgYSBzaWduYXR1cmU8YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyAjMSA9
IFR5cGVWYXJbMCwgT2JqZWN0XTxicj4mbmJzcDsmbmJzcDsmbmJzcDsgIzIgPSBNZXRob2RUeXBl
WygjKUksICMxXTxicj48YnI+V2hlbiBzcGVjaWFsaXppbmcgYSBgTWV0aG9kVHlwZWAsIGl0cyBw
YXJhbWV0ZXJzIGFyZSByZWN1cnNpdmVseSBzcGVjaWFsaXplZCwgYW5kIHRoZW4gdGhlIHJlc3Vs
dGluZyBzdHJpbmdzIGNvbmNhdGVuYXRlZC4gPGJyPjxicj4qKlBhcmFtVHlwZVtDLFQuLi5dLioq
Jm5ic3A7IFRoaXMgcmVwcmVzZW50cyBhIHBhcmFtZXRlcml6ZWQgdHlwZSwgd2hlcmUgYENgIGlz
IGEgY2xhc3MgbmFtZSwgYW5kIGBULi4uYCBhcmUgdGhlIHR5cGUgcGFyYW1ldGVycy4mbmJzcDsg
U28gYExpc3QmbHQ7aW50Jmd0O2Agd291bGQgYmUgcmVwcmVzZW50ZWQgYXMgYFBhcmFtVHlwZVtM
aXN0LEldYCwgYW5kIGBMaXN0Jmx0O1QmZ3Q7YCB3b3VsZCBiZSByZXByZXNlbnRlZCBhcyBgUGFy
YW1UeXBlW0xpc3QsVHlwZVZhclswLGVdXWAuIDxicj5XaGVuIHNwZWNpYWxpemluZyBhIGBQYXJh
bVR5cGVgLCBpdHMgcGFyYW1ldGVycyBhcmUgcmVjdXJzaXZlbHkgc3BlY2lhbGl6ZWQsIGFuZCB0
aGVuIHRoZSByZXN1bHRpbmcgaW5zdGFudGlhdGlvbiBpcyBjb21wdXRlZC4gPGJyPjxicj4qKkFy
cmF5VHlwZVtULHJhbmtdLioqJm5ic3A7IFRoaXMgcmVwcmVzZW50cyBhbiBhcnJheSBvZiBnaXZl
biByYW5rLiA8YnI+PGJyPlRoZSB0eXBlIHBhcmFtZXRlcnMgb2YgYSBgUGFyYW1UeXBlYCwgYEFy
cmF5VHlwZWAsIG9yIGBNZXRob2RUeXBlYCBjYW4gdGhlbXNlbHZlcyBiZSBhIGBUeXBlVmFyYCwg
YFBhcmFtVHlwZWAsIG9yIGBBcnJheVR5cGVgLCBhcyB3ZWxsIGFzIGEgVVRGOC4gPGJyPjxicj5X
ZSBmb3VuZCB0aGF0IGFzIGEgdGVtcGxhdGUgbGFuZ3VhZ2UsIHRoZXNlIHR5cGVzIGFsbG93ZWQg
ZXhhY3RseSB0aGUgc29ydCBvZiBleHByZXNzaXZlbmVzcyBuZWVkZWQsIGFuZCBzcGVjaWFsaXpl
ZCBlZmZpY2llbnRseSBkb3duIHRvIGNvbmNyZXRlIGRlc2NyaXB0b3JzICh0aG91Z2ggaW4gdGhl
IE0zIHByb3RvdHlwZSwgd2UgaGFkIGNvbmNyZXRlIGRlc2NyaXB0b3JzIG9mIHRoZSBmb3JtIGBM
aXN0JDA9SWAgdG8gZGVzY3JpYmUgYExpc3QmbHQ7aW50Jmd0O2AsIG9idmlvdXNseSB3ZSBkb24n
dCB3YW50IHRoYXQgaGVyZS4pJm5ic3A7IEJ1dCB0aGVzZSBkZXNpZ25zIGNhcHR1cmVkIGFsbCB0
aGUgY29tcGxleGl0eSB3ZSBuZWVkZWQgKGVzcGVjaWFsbHkgdGhhdCBvZiBlcmFzdXJlKSwgYW5k
IGFsbG93ZWQgYSBtZWNoYW5pY2FsIHRyYW5zbGF0aW9uIGludCBKYXZhIDggY2xhc3NmaWxlcy4g
PGJyPjxicj48YnI+PC90dD48YnI+"
style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0;"></div>
</div>
</body>
</html>