►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
thank
you.
Everyone
for
joining
us
welcome
to
today's
cncf
live
webinar,
growl,
vm
native
image,
low
footprint
java
in
the
cloud
I'm
livi
schultz
and
I'll
be
moderating.
Today's
webinar
I'm
going
to
read
our
code
of
conduct
and
then
hand
over
to
chris
foster
principal
product
manager
at
oracle
and
eli
shilling,
head
of
developer
relations,
content
at
oracle,
a
few
housekeeping
items
before
we
get
started
during
the
webinar
you're,
not
able
to
speak
as
an
attendee
there's
a
chat
box
on
the
right
hand.
A
Side
of
your
screen,
please
feel
free
to
drop
your
questions
there
and
we'll
get
to
as
many
as
we
can.
At
the
end.
This
is
an
official
webinar
of
the
cncf
and,
as
such
is
subject
to
the
cncf
code
of
conduct.
Please
do
not
add
anything
to
the
chat
or
questions
that
would
be
in
violation
of
that
code
of
conduct
and
please
be
respectful
of
all
of
your
fellow
participants
and
presenters.
A
Please
also
note
that
the
recording
and
slides
will
be
posted
later
today
to
the
cncf
online
programs,
page
at
community.cncf.io
under
online
programs.
They
are
also
available
via
your
registration
link.
You
use
today
and
the
recording
is
available
on
our
online
programs
youtube
playlist
with
that.
I
will
hand
it
over
to
chris
and
eli
to
kick
things
off
and
take
us
through.
B
Yeah,
thank
you
very
much
hi.
My
name
is
chris
foster.
I
work
at
oracle
labs
for
the
gra
vm
team.
I
work
in
product
management,
so
I
create
a
lot
of
content
and
do
a
lot
of
talks
about
gravim
native
image.
It's
a
technology.
Some
of
you
may
have
heard
of
I
guess,
but
hopefully,
in
this
session,
we'll
go
into
what
gravim
native
image
is
and
what
some
of
its
benefits
are.
Okay,
so
what
is
graviem,
and
why
should
I
care
this
is
going
to
be
a
mix
of
slides
and
some
live
stuff?
B
Some
live
coding
and
some
deploying
things
to
the
cloud.
So
I'm
hoping
there
won't
be
too
many
mess-ups
along
the
way,
but
bear
with
me
if
there
are
so
what
is
graviem
it's
a
number
of
things.
It's
a
java
runtime.
So
we
have
jdk
11,
jdk
17..
You
could
just
think
of
it
as
a
drop
in
replacement
for
whatever
java
runtime
you're
using
at
the
moment,
and
the
benefit
of
it.
Certainly
in
the
enterprise
edition
is
that
we
have
a
new,
an
entirely
new
jit
compiler.
B
So
it's
entirely
written
in
java,
it's
very
fast,
very
efficient,
and
it's
got
you
know
it.
It
can
make
your
application
significantly
faster
if
you're,
using
the
paid
enterprise
version.
We're
not
going
to
talk
about
that
today.
Another
feature
which
is
the
one
you
may
have
heard
the
most
about
is
native
image.
B
This
is
where
we
take
an
application,
your
application
and
generate
a
native
executable
from
it,
and
by
native
executable
I
mean
a
binary
that
will
run
natively
on
whatever
platform
you're
building
on
so,
if
you're,
using
a
mac,
you
end
up
with
a
mac
x,
binary
executable
file,
a
single
file
that
you
run
and
has
no
dependencies
on
the
jvm.
So
it's
very
easy
to
distribute
it's
ideal
for
containers.
B
So,
if
you're
building
on
linux-
and
you
you
package
this
binary
up
in
a
container,
you
can
get
a
very
small
docker
container,
for
instance,
with
your
application
in
it.
So
that's
going
to
be
the
main
focus
of
this
talk,
but
we'll
talk
about
some
of
the
other
things
that
graviem
is
before
we
move
on
to
that.
So
it's
multi-language
we've
added
an
api
to
the
the
java
runtime
towards
the
jdk
that
lets.
You
run
many
languages
on
top
of
the
the
grail
java
runtime,
so
you
can
run
currently
python.
B
You
can
run
node.js
and
javascript.
You
can
run
r
c
c,
plus
plus
lots
of
different
languages.
You
can
run
them
natively,
there's
no
sort
of
cross
compilations,
so
you
don't
end
up
basically
using
some
kind
of
compiler
that
generates
bytecode.
That
then
runs
you
have
an
interpreter
for
the
language
that
you
can
install
into
the
jvm
very
interesting,
but
we
won't
talk
about
that
today
and
finally,
it's
it's
an
open
source
project,
so
we
have
a
free,
totally
free
community
edition
and
we
have
a
enterprise
edition
which
is
pay
for
support.
B
The
best
way
to
do
it
to
explain
this
really
is.
If
I
try
and
show
you
some
examples,
so
we're
going
to
sort
of
iteratively
build
up
some
applications
and
then
look
at
how
we
turn
them
into
native
images,
how
we
deploy
them
and
kind
of
compare
and
contrast
the
kind
of
the
performance
we
get
from
our.
B
And
our
native
executable,
so
we
need
we
need
a
basic
app
like
a
model
play
thing
to
demonstrate
these
ideas.
So
I've
got
a
java
application
that
uses
something
called
a
markov
model
to
generate
random
text,
so
I've
taken
the
jabberwocky
poem
and
I've
wrapped
it
up
in
a
java
class
and
I'm
using
a
library
which
we'll
see
in
a
minute
when
we
look
at
the
code,
write
data
that
lets.
You
generate
random
text
from
an
original
piece
of
text.
B
So
it's
it's
a
relatively
simple
application,
but
it's
kind
of
fun
and
it
has
you
know
various
moving
parts
which
are
great
we're
going
to
build
it
into
a
spring
application
with
a
rest
api
that
will
allow
us
to
call
a
url
and
get
back
on
nonsense,
verse
that
resembles
the
jabberwocky
poem
and,
as
I
said,
we're
going
to
build
initially
a
java
version
of
the
application
and
we're
going
to
look
at
that.
Now.
B
Sorry,
it
calls
those
urls,
there's
actually
green
scrapes
like
the
information
from
them
and
stores
them
in
time
series
and
then,
at
the
very
end
of
that,
I'm
using
grafana
to
pull
this
data
together
to
make
nice
visual
dashboards,
which
we'll
see
in
a
second.
B
B
We
have
a
utility
class
jabberwocky.java,
which
contains
the
the
main
logic
of
our
application.
B
Here's
the
text
for
the
poem
the
jabberwocky
I
mentioned:
we
build
this
markov
model.
This
is
basically
just
a
model
of
the
text
and
then
we
store
it
in
this
utility
object.
This
object
is
created
as
a
singleton,
so
there
should
only
be
one
of
them
running
inside
our
application
and
whenever
we
want
some
nonsense,
first,
we're
going
to
hit
some
methods
in
this
class
generate
or
generate
with
a
number
of
lines.
B
A
B
That
basically
serve
the
content
for
that.
So
if
we
just
call
slash
jibber,
we
we
gen,
we
get
our
model
and
we
generate
some
text
and
return
that,
but
we
can
also
optionally.
You
know:
ask
for
a
number
of
lines
of
text:
10,
100,
200
whatever,
so
that's
our
java
application
very
simple:
we
can
build
it
from
the
command
line,
so
I'm
in
my
terminal
on
my
server.
So
if
I
do
maven
clean
package.
B
And
you'll
notice
in
a
second
that
it
also
builds
a
docker
container
with
the
application
in
it.
I'm
using
the
the
spotify
docker
maven
plugin
to
automatically
generate
a
docker
container
for
me,
a
docker
image
from
a
docker
file.
So
anyway,
we've
built
our
application.
We've
built
our
container
and
if
we
look
in
our
target
directory
surprise
surprise,
we've
got
a
jar
file.
So
let's
run
this
and
we're
going
to
put
it
into
the
background
and
we'll
call
the
url
and
from
that
benchmark.
B
So
the
application's
starting
up,
you
can
see
the
stack
of
spring
output
and
yeah.
It
started
up
in
about
two
seconds
so
now
I've
I've
got
my
application
running.
I
can
use
curl
to
hit
the
to
hit
the
end
point
and
with
any
luck
I
should,
if
I
could
type,
I
should
get
some
nonsense.
First,
back
brilliant,
so
we
saw
some
logging
there
from
spring,
but
here
we
have
some
text
that
was
generated
by
our
custom
application
and
if
I
call
it
again,
I
get
slightly
different
text
back.
B
Beware:
the
jab
walking
this
time
it
starts
with
what
does
it
start
with?
Actually
no
it
starts
with
and
as
if
and
before
it
was
starting
with.
Where
was
my
car
yeah
and
hast
thou?
So
every
time
I
call
my
url
endpoint,
I
get
a
new
like
non
piece
of
nonsense.
First,
that's
modeled
on
the
jabberwocky
poem,
so
my
application's
running
we've
got
an
idea
of
what
it
does
and
we
can
see
that
it
generates
the
text
that
we
want
to.
B
B
That
will
also
do
exactly
the
same
thing,
but
let's
run
the
container
just
to
show
that
the
the
app
is
now
successfully
packaged
into
my
my
docker
image.
B
So
I've
got
to
map
some
ports
to
make
it
available
locally.
I'm
just
going
to
copy
the
name
of
the
repository.
It's
got
a
very
long
repository
name.
The
reason
for
that
will
become
clear
in
a
second
and
then
I've
tagged
tagged
it
to
describe
which
version
of
the
app
it
is
as
we
go
through
this
we're
going
to
build
different
versions
of
the
application.
A
B
B
Okay,
so
we've
built
our
application,
we've
tested
it
from
the
command
line.
We
can
run
our
jar
using
java
and
we
see
it
starts
in
about
two
seconds
returns
us
our
text,
we've
seen
that
it's
packaged
up
in
a
docker
container
perfect,
and
we
can
also
we
can
also
quickly
look
at
the
size
of
the
jar
etc.
So
this
is
a
little
script.
I've
written
that
generates
a
bar
chart.
That
shows
you
how
big
the
jar
is
and
how
big
the
jdk
container
is.
B
So
my
jar's
21
meg
in
size,
but
my
docker
container,
containing
my
java
runtime
and
my
jar
and
everything
else
that
java
needs
is
about
600
meg
in
size.
So
that's
not
that's
not
very
slimmed
down.
Yet
we
could
make
that
smaller,
using
a
slimmer
container
and
using
j-link
to
build
a
slim
down
jvm.
But
to
my
eye,
that's
you
know:
there's
not
a
ridiculous
size
container
for
a
like
an
application
packaged
a
java
application
package.
B
B
So
we
we
talked
about
some
of
the
benefits
of
like
native
image
and
these
native
executables
previously.
But
just
to
recap
on
that
I
mean
why
do
we
want
to
do
this?
We
want
to
do
it
because
we
want
our
applications
to
start
faster
in
the
containers
and
we
want
them
also
to
have
a
smaller
footprint
by
smaller
footprint.
We
can
mean
a
number
of
different
things.
One
would
be
the
container
size,
so
the
less
in
the
container.
A
B
The
better
you
have
to
store
these
right,
the
less
that's
in
the
container.
Also,
arguably
like
the
more
secure
the
container
would
be
faster,
starting
means
that
you
know
you're
more
likely
you,
you
may
be
able
to
scale
to
zero
and
then
bring
instances
up
in
to
to
handle
calls
to
request,
but
it
means
it's
easier
to
scale
the
application
dynamically.
B
Another
area
of
another
area
we
can
talk
about
the
footprint
as
well
is
the
memory
consumption
of
the
application.
Obviously,
in
the
cloud
you
pay
for
everything,
so
if
you're
using
more
memory,
you
know
you're
to
run
your
an
instance
of
your
application,
the
more
memory
you
use,
the
more
expensive
it's
going
to
be.
So
if
you
can
use
less
memory
for
the
same
for
the
same
throughput,
the
same
performance
or
very
similar
performance,
then
that
might
be
interesting.
B
B
You
might
package
them
up
in
a
docker,
container,
etc,
but
at
some
point,
you're
going
to
say
java
class
part
this
or
jar
this
and
and
actually
call
the
the
main
entry
point
for
that
application,
and
that's
what
we
would
call
like
the
jit
way
of
running
your
java
code.
You
take
a
java,
runtime,
your
class
files
and
you
run
the
class
files
on
the
java
runtime.
B
What
we're
looking
at
here
is
ahead
of
time,
compilation,
which
adds
another
build
phase
in
so
we
take
the
class
files,
we
run
a
tool
called
native
image
against
them
and
that
generates
our
single
native
executable,
our
single
binary,
so
that's
aot
or
ahead
of
time
compilation.
You
can
do
this
by
hand.
You
know
you
can
use
the
native
image
tool
directly
from
the
command
line,
but
you
don't
need
to
support
for
that
is
now
you
know
it
has
been
available
in
inside
maven
and
gradle
for
quite
some
time
now.
B
The
gravim
team
has
a
native
build
tools,
project
that
provides
support
for
maven
and
gradle,
there's
plugins
for
maven,
for
instance,
which
we
will
look
at
today,
and
these
help
you
automate
the
the
process
of
building
your
native
image.
So
you
don't
need
to
think
about
that.
You
add
some
configuration
to
your
maven
pom
file
and
from
that
you
can
then
automatically
generate
a
native
executable
of
your
java
application.
So
two
things
to
think
about
you've
got
the
jit
approach
to
running
your
application.
B
You're
gonna
have
java
in
a
container
and
your
class
files,
and
then
we
have
this
extra
build
step
for
ahead
of
time,
compilation
where
we
build
a
native
binary,
and
then
that
is
the
thing
that
we
deploy.
We
run
we
package,
so
I'm
using
a
spring
app.
So
it's
probably
important
to
talk
about
the
spring
native
projects
now
so
the
spring
native
is
an
experimental
project,
that's
working
to
make
using
spring
apps
and
turning
them
into
native
executables,
very
easy
so
that
you
don't
have
to
do
anything.
B
So
if
you've
got
a
spring
app
sorry,
you
can
add
this
dependency.
Add
the
aot
plugin
to
your
pom
file
and
these
plugins
and
this
dependency
will
automatically
solve
all
of
the
the
any
issues
result
related
to
making
the
application
the
spring
parts
of
the
application
work
with
gravim
native
image.
So
for
every
spring
component
you
use
the
aot
plugin
is
going
to
generate
required
config
and
a
few
other
things
to
make
that
seamlessly
work
with
gravim
native
image.
B
This
is
going
to
be
part
of
spring
boot
3
very
soon
I
haven't
updated
my
application
to
work
with
that.
Yet,
but
you
know
when
it's
when
spring
boot
3
is
released,
you
won't
need
to
add
these
at
all.
I
don't
believe
I
think
you
can
just
have
a
spring
boot
3
application
and
you
will
be
able
to
like
ask
for
the
application
to
be
packaged.
As
a
native
executable,
I
think
I
think,
certainly
in
maven
using
profiles.
B
So
we've
looked
at
what
native
images
we're
going
to
jump
back
to
the
code,
we're
going
to
have
a
look
at
how
we
take
that
same
application
that
we
just
wrote
and
turn
it
into
a
native
executable.
I'm
not
going
to
need
to
change
the
application
in
any
way.
My
java
application
is
going
to
stay
the
same,
but
I'm
just
going
to
change
how
we
build
it
and
deploy
it.
So
if
I
switch
back
to
my
code,
editor
we'll
look
at
the
pom.xml,
I'm
just
going
to
resize
this
window.
B
So
I've
added
a
profile
to
the
pom.xml
and
maven
profiles
allow
you
to
have
specific
configurations
for
build.
So
in
this
case,
when
I
type
maven
package,
I
want
it
to
build
my
jar
file
and
I
want
to
package
that
as
a
docker
container
with
java
in
it.
But
if
I,
if
I
call
the
native
profile,
I
want
it
to
package
my
application
as
a
binary
executable
for
linux,
and
I
want
to
package
that
binary
executable
into
a
docker
container.
So
if
we
take
a
quick
look
at
this
maven
profile,
we've.
A
B
New
plugin
here
this
is
the
native
maven
plugin
that
I
talked
about.
This
simplifies
using
native
image
from
inside
maven.
There's
a
gradle
plug-in
as
well.
It's
very
easy
to
fit
in.
You
can
pass
some
configurations
so,
for
instance,
I'm
using
a
property
in
my
maven
file
to
say
what
the
output
executable
name
should
be,
and
we
can
also.
This
is
quite
important,
passing
extra
flags
to
native
image,
with
this
build
art
parameter,
for
instance,
I'm
asking
it.
B
You
know
to
give
full
exception,
stack
traces
if
anything
goes
wrong,
always
a
handy
thing
when
you're
trying
to
debug
something-
and
I'm
also
passing
in
a
flag
to
tell
it
to
create
a
mostly
statically
linked
executable
because
we're
generating
a
binary
executable.
We
have
the
ability
to
statically
link
it.
What
does
that
mean?
It
means
that
any
system,
libraries
or
any
libraries,
basically
that
the
application
needs
outside
of
the
javascript
can
be
statically
linked
into
the
executable
they
can
become
part
of
the
executable.
B
B
Distros
glibc
is
the
standard
c
library
it
isn't
suited
to
being,
not
to
being
sorry,
it
isn't
suited
to
being
statically
linked.
Certain
parts
of
it
rely
on
being
rely
on
it
being
dynamically
linked
into
the
application.
There
are
some
bugs
open
on
glibc
relating
to
this.
So
if
you
use
the
mostly
statically
linked
executable,
you
get
the
a
lot
of
the
benefits
most
of
the
libraries
are
baked
in,
and
that
also
means
that
you
can
use
a
very
small
container
image.
B
So
in
my
in
my
docker
file,
I'm
going
to
base
that
on
distributor.
So
I'm
going
to
use
a
distrolus
container
to
package
my
native
executable,
basically
because
distrolus
contains
glibc,
but
not
a
lot
else.
You
know
some
configuration
etc,
but
it's
a
very,
very
minimalist
container,
the
less
in
the
container,
the
smaller.
Arguably
the
more
secure
it
is,
and
you
know
the
fewer
things
you
have
in
there
that
can
be
hacked.
B
So
that's
the
first
thing
we're
using
the
native
maven
plug-in
to
to
make
building
the
binary
executable
easy
and
again,
I'm
using
this
spotify
plug-in
to
package
that
up
as
a
native
executable
package
that
up
as
a
docker
container
sorry
so
I've
written
a
script
to
do
this.
But
really
all
this
is
doing
is
just
calling
maven
saying
correctly:
yeah
calling
maven
passing
in
a
a
profile
and
a
few
properties.
I
want
to
tag
my
image
differently.
I
want
this
one
to
be
called
tagged
with.
B
So
I
know
this
is
my
native
container,
that's
useful.
So
when
I
push
the
kubernetes,
I
can
start
up
an
instance
of
the
app
that
contains
the
native
executable
and
another
instance
of
the
app
that's
based
on
the
java
container,
and
I
can
have
them
running
concurrently
in
my
cluster
and
you
know,
hit
them
with
requests,
hit
them
with
requests
and
then
query
them
to
see
how
they're
performing
and
I'm
also
able
to
specify
a
docker
file.
So
it's
worth
having
a
quick
look.
B
B
My
native
dockerfile
is
very
simple:
I'm
basing
it
on
distrelus
bass.
I've
got
an
argument
that
lets
me
pass
in
the
name
of
the
executable
I
want
to
load,
expose
a
port
and
then
I
just
copy
that
into
copy
and
rename
basically
that
into
the
root.
And
then
my
entry
point
is
slash
app,
so
I
could
use
this
docker
file,
for
you
know
running
almost
any
binary
application
that
I
want
to
pass
in.
So
we're
just
creating
the
image
now
native
image
is
creating
the
image
below
it's
finished.
B
B
Such
a
bad
typer
there
we
go
so
it
is
just
a
binary
application.
There's
not
it's!
It
has
no
dependency
on
the
jvm
at
all.
So
let's
run
that
just
to
see
how
it
performs
just
to
show
that
it
can
be
run.
So
I'm
going
to
run
that
binary
executable
put
it
into
the
background,
so
it
starts
really
fast,
0.04
seconds,
okay.
So
it's
finished,
I'm
starting
up
in
0.04
seconds
and
I
can
just
hit
the
end
points
again.
B
Yeah,
so
we've
got
our
application
running
as
a
native
executable
and
returning
gibberish
text,
which
is
what
we
want,
so
it
also
wasn't
very
difficult.
We
needed
to
change
some
things,
we'll
basically
add
some
configuration
to
our
pom
file
and,
through
the
you
know,
adding
the
spring
native
plugins
and
the
gravie
m
plugins
to
our
our
pawn
file
very
easily.
We
were
able
to
take
this
spring
spring
boot
application
and
turn
it
into
a
native
executable.
B
So
last
time
when
we
built
the
java
application,
we
took
a
look
at
the
size
of
the
the
jar
versus
the
size
of
the
container
and
we
can
do
the
same
now
with
our
native
executable.
So
this
script
returns
the
size
of
the
jar
21
meg,
the
native
executable
size,
which
is
82
meg
the
size
of
our
container
with
the
native
executable
and
that's
the
third
row
down,
which
is
106
meg
and
the
size
of
our
jdk
container.
So
we
can
see
our
native
container
is
significantly
already
significantly
smaller.
B
B
Okay,
so
we're
going
to
switch
back
to
the
slides,
I
hope
you're,
all
following
along
no
one's
getting
seasick.
With
this
switching
from
the
editor
to
the
slides,
I
thought
it's
probably
worth
having
a
bit
of
a
recap.
Again,
we've
built
a
java
application,
we've
containerized
it
that
was
easy
native,
app
and
containerized
that
that
actually
wasn't
that
much
more
difficult.
B
So
now
we're
going
to
think
about.
You
know
how
we
might
deploy
this
it's
kind
of
interesting
to
deploy
it
to
kubernetes
so
that
we
can
look
at
these
metrics
that
I
talked
about
at
the
start,
and
so
we
can
have
a
dashboard
that,
like
compares
and
contrasts
the
application's
performance,
so
we
can
see
if
you
know
using
a
native
xp
executable
instead
of
the
java
runtime
to
run
our
application
is
a
sensible
choice.
So
if
we
look
at
this
diagram
over
on
the
left,
you
know
we've
got
two
streams.
B
Basically,
the
top
we've
got
our
native
executable.
We
can
see
the
diagram
shows
that
that's
turned
into
a
container
and
then
underneath
that
we've
got
our
class
files
and
we
turn
that
into
a
container,
and
then
we
push
those
to
a
container
registry.
So
I'm
using
a
container
registry
in
oci
in
the
oracle
cloud.
B
I've
also
pre-set
up
an
oracle
container
engine
cluster.
So
an
okay
cluster,
that's
just
kubernetes
cluster,
so
that
kubernetes
cluster
is
going
to
pull
my
containers
from
my
container
registry
and
I've
pre-deployed
to
this.
Excuse
me
this
kubernetes
cluster,
prometheus
and
grafana,
and
I've
wired
them
all
up
correctly,
so
that
we're
able
to
go
to
the
dashboard
and
those
dashboards
know
how
to
you
know,
extract
information,
reporting,
information
from
the
applications
deployed
to
the
kubernetes
cluster
and
then.
Finally,
on
the
right
hand,
side
we've
got
an
api.
B
That's
fronted
like
a
service,
that's
fronting
the
the
native
version
of
the
rest
application.
So
we
can
call
that
and
we
can
get
our
nonsense
text
returned
from
the
native
version
of
the
containerized
application
and
the
same
for
the
java
and
into
that
cluster.
I'm
going
to
deploy
some
stress,
testing,
cron
jobs
that
are
going
to
hit
both
of
those
endpoints
continuously
so
that
the
applications
will
be
running
under
load
and
when
they're
running
under
load.
B
That's
going
to
help
us
look
at
the
the
metrics
that
we
get
on
graph
on
our
grafana
dashboard
at
the
end,
and
that
will
help
us
understand.
You
know
what
the
trade-offs
are,
whether
it
makes
sense
to
run
the
application
as
a
native
application
or
as
a
java
runtime
or
talk
for
java
runtime.
There's
a
quick
note
on
the
stress
test
in
the
apps
when
stress
testing
the
apps,
it's
important
to
try
and
keep
things
fair.
B
So
the
java
application
in
my
kubernetes
description
for
deploying
the
application,
I'm
fixing
the
memory
I'm
giving
it
256
meg,
but
I'm
allowing
it
to
creep
up
to
512.
the
native
application.
I'm
fixing
its
memory
at
128
meg
and
not
allowing
it
to
increase
and
I'm
giving
the
java
application
and
the
native
application
two
cores
to
work
with.
B
So
I'm
trying
to
keep
things
fair,
I'm
giving
the
native
application
a
handicap
and
giving
it
much
less
memory,
but
I
kind
of
want
to
to
like
you
know
the
native
image
can
run
with
a
smaller
memory
footprint
and
finally,
I'm
using
a
tool
called
hey
to
do
the
stress
testing
of
both
of
the
applications.
B
B
B
So
the
way
I've
written
this
application
in
the
queue
I
wanted,
people
to
be
able
to
clone
it
and
use
their
own
repository.
So
the
solution
I've
I've
used
is
to
put
a
template
in
for
the
the
container
registry
repo
name,
so
that
allows
you
to
set
this
environment
variable
and
you
know
for
your
own
container
registry.
B
So
your
container
registry
isn't
going
to
be
the
same
as
mine
if
you're
deploying
it
to
cloudx,
you
know
oracle
cloud
aws
whatever
and
then
I've
used
and
the
msubs
command
to
replace
those
templated
repository
names
with
the
real
name
which
exists
as
an
environment
variable
and
then
pipe
that
into
cubecontrol.
B
So
let
me
just
check
before
I
run
this,
that
my
repo
path
variable
exists:
yeah,
okay,
cool,
so
I
can
deploy
my
application
to
the
cloud
now.
This
is
going
to
deploy
the
java
application,
so
first
it's
creating
a
namespace
to
deploy
everything
to
that
already
exists.
It's
then
deploying
the
java
version,
along
with
the
service
to
frontier
the
native
version,
and
the
same
for
that,
and
in
my
kubernetes
description
I
can
quickly
show
you
these
that
there's
nothing.
You
know
very
exciting
in
here.
B
The
memory
like
we
talked
about,
I'm
opening
up
a
port
and
then
I'm
also
opening
up
the
the
endpoint,
the
8080
endpoint
to
the
outside
world
and
I'm
using
the
annotations
from
oci
the
load
balancer
annotations
to
automatically
open
up
a
to
automatically
sorry
spin
up
the
load
balancer
for
me,
which
will
handle
incoming
traffic
and
I've
done
the
same
for
exactly
the
same
for
the
native
image.
The
only
difference
here
is
that
I've
constrained
the
memory.
Sorry.
B
B
This
namespace
contains
just
the
versions
of
my
applications,
so
my
java
application
and
my
native
image
application.
You
can
see
that
there's
three
rows
there,
rather
than
the
two
I've
been
talking
about,
because
I've
already
deployed
an
enterprise,
gravium
enterprise
version
of
the
application.
If
I
was
going
to
talk
about,
you
know
the
jit
performance.
That
would
be
interesting,
but
I'm
not
so.
Let's,
let's
hit
that
end
point
for
the
native
version,
the
public
endpoint
for
the
native
version.
B
So
I'm
going
to
take
the
ip
address
for
my
load.
Balancer,
that's
fronting
out
the
the
native
executable
and
I
can
call
it
and
I
get
some
text
back
and
I
can
do
the
same
as
well
for
the
java
version,
except
I've
got
rid
of
my
ip
addresses.
B
B
Kubernetes,
sorry
in
kubernetes,
I'd
already
pre-configured,
prometheus
and
grafana,
so
that
I
would
have
a
way
of
grabbing
information
about
the
running
applications
and
displaying
it
in
a
dashboard.
So
I've
got
my
my
url
here
for
my
grafana
instance
and
if
I
jump
to
the
web
browser
up,
I've
already
got
it
open.
So
let's
run
it
and
take
a
look
at
this
dashboard.
B
So
there
are
three
components
to
this
dashboard
and
I
should
explain
what
they
do
so.
The
first
one
is
measuring
the
throughput
and
it's
measuring
the
throughput
of
the
the
native
executable
running
inside
a
container
that
we
deployed
to
my
kubernetes
cluster
and
also
the
performance
of
the
java
version
of
the
application.
The
throughput,
I
should
say
the
java
application
running
in
a
container,
so
I've
got
two
containers,
my
native
one
and
my
java
version
of
the
application
and
I'm
hitting
both
of
those
concurrently
with
a
stress
test
request.
B
So
I'm
hitting
the
url
for
the
jibber
app
jibber
endpoint
and
asking
for
nonsense.
First
continuously,
so
both
apps
are
under
load
and
we
can
see
that
basically
they've
got
very
similar
performance.
The
yellow
line
on
the
top
graph,
the
throughput
graph,
which
is
in
numbers
of
requests
per
second,
is
the
native
images
throughput.
So
the
native
executable
is
slightly
on
average,
slightly
better
than
the
version
of
the
application
running
on
open
jdk,
but
we're
guessing.
It
looks
to
me
roughly
about
770.
B
Your
mileage
may
vary
with
this.
Obviously
you
know
your
performance
will
depend
on
what
the
application
is
doing.
Some
applications
native
image
may,
the
native
executable
will
perform
exactly
the
same
some
applications
it
might
perform
slightly
better
other
applications.
It
might
perform
slightly
worse,
but
we're
aiming
to
get
the
performance
of
the
native
executable,
that's
generated
with
native
image,
up
to
and
approaching
the
same
performance
that
you
would
get
on
open.
Jdk
we've
got
some
optimization
tools
that
can
really
push
the
performance.
B
There
won't
have
time
to
talk
about
those
in
depth
in
this
talk,
but
I'll
mention
them
a
little
at
the
end.
So
key
thing
about
the
top
graph,
we're
getting
very
similar
performance,
in
fact
slightly
better
for
native
image.
The
next
graph
down.
A
Now
might
be
a
good
time
to
kind
of
to
work.
This
answer
in
are
there
any
gotchas
to
be
aware
of
given
all
of
the
improvements
I.e
reduction
in
size
of
the
jar
and
the
jdk.
B
Yes,
they're,
definitely
they
definitely
are,
and
that's
what
the
spring
native
tooling
is
kind
of
trying
is
hiding
from
you.
So
I
tell
you
what
I'll
do
eli
I'll
finish
talking
about
this
graph
and
then
I'll
I'll
I'll
talk
about
that
topic?
Actually,
I
might
actually
just
talk
about
that
at
the
end,
because
only
got
a
couple
of
slides
to
go,
but
I
think
that's
a
very
important
point.
B
So
the
so
it's
a
very
good
question.
Thank
you
for
asking
it.
So
the
next
graph
down
is
the
the
container
memory,
so
how
much
memory
resident
set
size
is
each
container
using,
and
in
this
case
really
it
would
have
been
ideal
if
I
had
kept
the
same
colors
for
the
same
containers,
but
I
haven't
I've
just
noticed
the
graviem
native
executable
is
in
green
and
that's
using
about
100
yeah
slightly
over
100
meg
116
meg
in
115
meg
in
resident
set
size.
B
The
java
application
is
using
238,
so
we're
using
half
the
memory
for
a
very
similar
performance.
The
final
graph
is
the
startup
times.
Well,
we
knew
that
they,
you
know
native
the
native
executable,
would
start
much
faster
because
we'd
seen
that
when
we
looked
at
the
command
line,
but
this
information
again
has
been
pulled
from
like
the
spring
actuator,
so
35
milliseconds
for
the
gravim
native
executable
to
start
up
and
the
java
application.
You
know
two
to
three
seconds
to
start
up
so
realistic
times
for
the
spring
application.
B
Really,
you
know
what
we
would
expect
for
a
java
spring
application
to
start
up
in
you
know,
second
time
spans
one
to
two
to
three
and
the
native
executable
is
starting
up
in
you
know
significantly
under
you
know
the
tenth
of
a
second,
so
I'm
gonna
quickly
jump
back
to
the
slides
again.
You
know
this
is
just
what
I've
shown
you
the
cont
different
ways
we
can
look
at
the
footprint
contain
a
footprint.
B
You
know
the
containers
got
smaller,
but
we
can
also
think
about
like
the
memory
usage
in
the
cloud
when
we've
deployed
that
application.
In
this
example
again,
your
mileage
may
vary
and
we
got
the
same
performance
for
half
the
memory
and
it
wasn't
that
difficult
to
make
a
native
executable
from
the
application.
B
A
B
Days
months
years,
the
graveyard
enterprise
edition
jvm
would
probably
make
sense
because
you've
got
the
jit
compiler
in
there
and
its
performance
is
going
to
be
very,
very
good,
so
very
long
running
applications.
We
you
don't
care
about
the
footprint.
So
much,
perhaps
you
know
a
traditional
jit
mode
would
make
sense.
We've
got
different.
We
support
different
garbage
collection,
garbage
collectors,
I
suppose
you'd
say
inside
native
image.
B
B
There's
no
stop
the
world
pauses
that
you
can
see
with
our
serial
gc
pgo
our
profile,
guided
optimizations
with
that
you
can
really
improve
the
throughput
and
performance
of
the
application
like
drastically.
B
We
talked
a
bit
about
static
linking
and
finally,
it's
supported
by.
You
know:
lots
of
different
frameworks,
spring
native-
that's
what
I'm
showing
you
here
but
micronaut,
which
is
an
independent
project,
helidom
from
oracle
and
quarkus
from
red
hat.
All
of
these
target
gravim
native
image
as
a
deployment
target,
they
want
to
build
a
native
executable
that
starts
fast
and
has
a
low
footprint
as
a
way
of
packaging,
their
applications.
B
So
gotchas
I'll
go
back
to
the
question
that
eli
asked.
I
think
it's
very
important
question
and
yes,
there
are
native
image
in
order
to
get
a
lot
of
these
benefits.
Native
image
makes
certain
assumptions
it
operates
under.
What's
called
the
closed
world
assumption,
so
I'm
in
a
java
is
a
very
dynamic
language.
You
can
load
classes
in
your
application.
B
You
can
build
up
the
name
of
the
class.
You
know,
programmatically,
you
can
load
resources
off
the
class
path.
There's
all
kinds
of
you
can
do
reflection.
You
can
find
out
about
oops.
Sorry,
you
can
find
out
about
the
methods
an
object
has
or
you
know
what
objects
are
available
in
a
package,
for
instance,
all
sorts
of
things.
It's
a
very
dynamic
language.
B
Native
image
comes
at
the
comes
at
this
with
the
assumption
that
it's
a
closed
world.
Imagine
that
you
can't
do
any
of
those
dynamic
things.
You
can't
load
classes.
You
know
dynamically,
you
can't
use
reflection,
etc.
You
would
think
that
you
wouldn't
really
be
able
to
generate
many
java
applications,
but
it
turns
out
that
you
can
and
the
way
we've
been
able
to
do
that
is
through
making
been
able
to
tell
basically
the
build
time
for
native
image
about
like
these
dynamic
features
of
the
language
say.
B
For
instance,
your
your
java
program
uses
reflection
to
look
up
a
certain
class
and
to
find
out
what
methods
are
available.
Well,
if
we
know
that
that's
going
to
happen,
we
can
build
configuration
files
that
tell
native
image
that
this
is
going
to
happen.
So
when
it
builds,
it
knows
that
it
happens.
It
knows
it
can
add
that
class
that's
going
to
be
accessed
reflectively
to
like
the
closed
world,
that
it's
operating
on
same
goes
for
class
loading.
B
You
know
loading
resources
of
the
class
path,
and
that
sounds
like
it
might
be
kind
of
a
laborious
process
to
build
all
this
configuration
for
yourself,
but
we
we
have
a
java
agent.
So
when
you
run
your
application,
you
run
it
as
a
java
application.
You
can
pass,
you
can
run
it
with
this
java,
the
native
image
java
agent,
that
basically
traces
your
application,
looks
for
instances
of
you.
A
B
Reflection,
you
know
dynamic
class
loading,
any
anything
like
that
serialization
and
it
saves
the
configuration
that
you
would
have
had
to
write
by
hand
automatically
directly
to
these
configuration
files.
Then,
when
you
build
these
configuration
files
are
used
to
provide
this
kind
of
missing
information
to
native
image.
Lots
of
libraries
are
packaging,
this
information
directly
with
the
the
jar
for
the
the
library,
so
that
I
mean
that's
kind
of
what
the
the
spring
native
stuff
is
doing.
It's
providing
this
missing
configuration
to
you.
B
So
when
you
run
the
application,
there's
a
step
where
the
spring
native
plug-in
looks
at
the
application,
looks
at
the
class
path,
looks
at
what's
going
on
and
builds
extra
classes
and
extra
configuration
that
your
application
will
need.
The
spring
application
will
need
in
order
to
be
turned
into
like
a
native
executable.
B
So
there's
lots
of
tooling
that's
been
put
in
place,
certainly
in
the
frameworks
that
I
mentioned
previously
spring
spring
boots,
sorry,
micron
or
helizon
and
quarkus-
to
make
this
like
as
easy
as
possible.
If
you're,
using
a
library
that
isn't
you
know
native
image
friendly,
yet
you
may
have
to
resolve
some
of
these
issues.
You
know
by
using
the
java
agent
to
generate
the
config
for
you
and
you
can
get
applications
to
work.
The
you
know
maybe
use
libraries
that
use
a
lot
of
reflection.
B
Yes,
the
gotchas
I
mean
if
anyone
has
any
further
questions,
you
know
please
feel
free
to
ask
an
eli
I'll
go
back
to
my
slide,
because
it's
better
to
look
at
really
than
this.
If
you
want
to
read
out,
if
anyone
has
any
questions,
if
not,
thank
you
very
much
for
your
time
today
attending.
I
hope
I
hope
it
made
sense.
What
I
was
talking
about,
and
you
know
the
slides
will
be
available.
All
the
code
is
available
in
a
repository
on
github
as
well.
B
A
B
At
the
moment,
I'm
not
entirely
sure
if
you
go
to
the
spring
native
site,
for
instance,
I
think
there's
documentation
on
there
that
why
don't
we
do
that?
Let's
just.
B
So
this
is
the
documentation
for
the
spring
native
site
for
the
spring
native
project.
Sorry
it
it's
pretty
good
documentation,
it's
worth
looking
through,
because
it
can
explain
in
detail
how
to
use
how
to
use
this
and
how
to
build
native
images.
I
thought
there
was
a
list
of
things
that
are
known
to
be
supported.
B
B
I'm
sure
that
if
there
are
things
that
aren't
working,
that's
also
documented
somewhere.
My
typically
also
go
to
the
spring
native.
B
B
And
in
the
samples
project,
there's
a
quite
an
exhaustive
list
of
sample
project
samples
that
are
known
to
work
so,
for
instance,
if
you're
interested
in
kafka
kafka
streams,
rabbit
mq,
you
could
let's
take
this
one,
you
could
go
into
there
and
there
should
be
a
working
project
that
shows
you
how
to
use
that
particular
spring
module
with
native
with
native
image
that
is
meaning
to
generate
like
a
native
executable.
B
A
Again
so
much
thank
you,
everyone
for
joining
us.
Everything
will
get
posted
shortly
and
we'll
see
you
next
time
for
another
live
webinar
with
cncf.