►
Description
Through the use of technologies like CRIU support in Eclipse OpenJ9 and Liberty’s InstantOn, we’ve taken one giant leap forwards for innovation for Java and Jakarta EE applications, offering exactly this! Join this session to learn more about these innovations and how you could utilise OSS technologies to deliver highly scalable and performant applications that are optimized for today’s cloud-native environments.
This session will give attendees an insight into the CRIU and InstantOn technologies and how these can be used to enable serverless speeds with Java applications without needing to compromise on performance. As well as introductory slides we aim to show a live demo and showcase how this technology can be used by the attendees through the use of OSS cloud-native Java technologies and tools.
-
Jakarta EE gives developers a comprehensive set of vendor-neutral, open specifications that are used for developing modern, cloud native Java applications from the ground up. With Jakarta EE, technology developers and consumers can be confident they have the best technologies for developing cloud native, mission-critical applications. And they can build on decades of Java developer expertise to move existing workloads to the cloud.
Learn more: https://jakarta.ee/
Follow us on Twitter: https://twitter.com/home
Follow us on LinkedIn: https://www.linkedin.com/showcase/jakartaee/
Like us on Facebook: https://www.facebook.com/JakartaEE/
A
Hi
everyone,
and
thanks
for
joining
our
session
today,
it's
great
to
join
the
Jakarta
one
live
stream,
so
excited
to
be
here.
I
am
co-presenting
today
with
the
wonderful
Tom
Watson
and
we're
going
to
be
presenting
this
session
to
instant
on
and
Beyond,
so
looking
at
jakarti
applications
at
light
speed.
A
A
And
really,
this
all
stems
from
the
fact
that
Java
is
a
very
popular
and
well-loved
language
and
that's
down
to
a
number
of
different
reasons.
Really.
The
first
is
you
know
it's
a
language
that
is
very
easy
to
read
and
write.
We
have
a
really
vast,
Rich
ecosystem
of
various
different
apis
that
we
can
call
upon
and
utilize
when
designing
and
developing
our
applications,
but
not
only
that,
it's
also
the
community
around
this
language
as
well.
A
We've
got
such
a
fantastic
Community,
that's
really
established
and
active,
and
it
includes
you
know
jugs,
so
Java
user
groups,
you've
also
got
the
Java
Champions
sort
of
platform
or
program.
You've
also
got
specific
Java
conferences
like
this
one,
and
also
others
in
person
and
online
and
specific
Java
newsletters
podcasts
blogs
Etc.
So
it
really
is
a
really
vibrant
and
active
community
that
helps
to
keep
this
language
so
very
much
loved
and
used
within
our
industry
as
well
as
that
we
have
fantastic
libraries
and
that's
not
just
proprietary.
A
We
also
have
loads
of
Open
Source,
and
many
of
that
is
being
discussed
at
this
event
today,
including
things
like
jakarti.
So
it's
fantastic
to
have
such
a
vast
array
of
Open
Source
libraries
as
well
as
proprietary
support
as
well,
and
in
addition
to
this
things
like
platform,
Independence,
the
fact
that
it
can
run
on
various
different
operating
systems
and
it's
really
long
history
of
supporting
Enterprise
applications.
A
You
know
this
kind
of
omnipresence
of
java
and
the
fact
that
it's
still
used
very
much
throughout
things
like
Banking
and
other
large
Enterprise
organizations,
as
well
as
slightly
smaller
organizations
as
well.
Oh,
and
we
can't
obviously
forget
the
Java
virtual
machine
as
once
as
well.
So
the
fact
that
we
can
write
once
and
run
everywhere.
A
We
can
run
on
various
different
types
of
computers,
mobile
devices
without
having
to
make
any
change
in
the
input
or
having
you
know,
having
had
backwards
compatibility
having
this
kind
of
managed,
runtime
environment,
and
this
is
a
really
great
feature
when
we're
developing
and
deploying
and
using
Java
applications.
So
let's
take
a
closer
look
at
that
jvm,
so
you
know
way
back.
You
know
when
Java
was
released
back
in
sort
of
1995.
All
computer
programs
were
really
written
to
a
specific
operating
system
and
the
program
memory
was
managed
by
the
software
developer.
A
A
The
jvm
essentially
enables
us
to
be
able
to
configure
this
quality
machine
code
and
help
to
speed
up
things
like
our
processing
time,
within
that
it
usually
has
two
compilers
you've
got
the
C1
and
the
C2
C1
is
designed
really
to
run
faster
and
produce
less
kind
of
optimized
code,
while
C2
balances
that,
on
the
other
hand,
by
taking
a
little
bit
more
time
to
run
but
reducing
a
better
optimized
code.
So
we've
got
this
kind
of
balance
within
it.
A
All
of
these
key
behaviors
and
that's
why
we
get
excited
about
designing
and
developing
and
deploying
in
the
cloud,
and
so
we
get
this
excitement
of
oh
the
cloud,
but
with
the
cloud
Comes
potential
challenges
as
well
as
I
mentioned,
and
it
has
shifted
the
way
that
we
need
to
be
considering
sort
of
the
demands
that
are
placed
on
our
applications.
Next
slide,
please
Don
thanks.
A
So
some
of
those
challenges
include
the
fact
that
you
know
the
jvm
was
originally
designed
with
sort
of
portability
and
flexibility
in
mind,
but
that
meant
that
bytecodes
were
essentially
being
loaded,
lazily
and
optimized,
while
the
application
was
still
running.
The
result
of
this
was
essentially
much
slower
startup
times,
but
we
still
got
that
high
peak
throughput.
A
The
cloud,
however,
really
has
shifted
this
demand
and
shifted
that
in
the
performance
characteristics
of
jvms,
so
it's
now
changed
the
way
in
which
we
need
to
be
considering
how
we
develop
and
deploy
applications,
and
not
just
developing
and
deploying,
but
also
how
we
run
the
applications
in
the
cloud.
So,
for
example,
when
we're
running
a
microservice
architecture
in
the
cloud-
and
there
are
different
demands
on
the
jvm
as
opposed
to
running
a
more
traditional
on
on-prem
setup
kind
of
thing,
and
these
differences
can
also
have
economic
implications
as
well.
A
You
can
see
from
the
graphs
on
the
right
what
a
more
traditional
profile
would
look
like,
and
the
fact
that
we
have
this
sort
of
gap
between
the
two
really
results
in
higher
costs
for
us
when
running
it
in
the
cloud
and
what
we
really
want
is
something
more
like
the
bottom
graph
there
and
it's
led
to
our
sort
of
considering
things
like
you
know.
Oh,
do
we
need
to
go
towards
more
serverless
style
Computing?
A
How
do
we
think
about
our
Cloud
economics
in
terms
of
trying
to
be
as
economical
as
possible,
while
still
ensuring
that
throughput
and
performance
and
redesigning
our
jvms
and
our
applications
for
the
cloud
when
it
comes
to
Cloud
economics?
Really
again,
the
next
slide,
please
Tom,
please.
The
shift
to
the
cloud
has
enabled
sort
of
our
business
to
it
needs
to
focus
more
of
their
attention
on
sort
of
developing
apps
and
features,
and
we
are
now
focusing
sort
of
Less
on
the
it
infrastructure,
because
a
lot
of
this
is
often
provided
to
us
now.
A
Whilst
this
has
been
a
very
like
beneficial
move,
it
does
mean
that
we
now
have
to
optimize
for
costs
in
a
slightly
different
way.
So
typically,
pricing
models
tend
to
be
sort
of
pay,
as
you
go
based
on
sort
of
CPU
memory
and
the
time
that
it
is
used
for
as
a
result
really
to
minimize
costs,
you
need
to
be
making
sure
that
you're
only
really
paying
for
what
you
use
and
no
more
than
that-
and
this
is
where
we
need
to
be
thinking
about
sort
of
when
there's
High
load
to
our
application.
A
We
need
to
be
scaling
up
to
obviously
meet
that
demand,
but
equally,
when
there's
low
load,
we
don't
want
to
be
staying
at
those
high
amounts.
That's
at
high
demand
skill
at
high
scale.
We
need
to
be
scaling
back
down
to
be
able
to
save
on
costs.
So
it's
this
elastic
and
Dynamic
scaling
that
sort
of
becomes
very
important
and
leads
to
things
like
being
able
to
scale
to
zero
effectively
so
that
we
can
have
sort
of
very
fast
startup
times,
which
obviously
are
needed.
A
If
we're
going
to
be
having
those
scale
to
zero
and
that
Dynamic
scaling
that
we
need
and
so
startup
sort
of
becomes
part
of
the
latency
end
users
may
experience
during
increasing
demand.
So
this
is
where
we
need
to
start
thinking
about.
Okay.
How
do
we
enable
fast
startup?
How
do
we
enable
ourselves
to
have
that
very
elastic
and
dynamic
scaling
to
make
it
much
more
economical
for
us
within
the
cloud
and
that's
what
we
can
start
to
look
at
sort
of
runtimes
that
have
been
designed
with
the
cloud
in
mind,
so
Cloud
native
runtimes?
A
So
you
know
we
there
are
the
jvm.
Oh
next
slide,
please
Tom
thanks!
The
jvm
was
kind
of
originally
designed
with
the
goal
of
enabling
portability
and
flexibility
of
java
apps.
So
writing
once
running
everywhere.
As
I've
mentioned
already.
To
achieve
this,
the
jvm
was
designed
to
load
byte
codes
as
late
as
possible
and
optimize
at
runtime.
So
you
could
achieve
this
Peak
Performance
on
your
platform
and
sort
of
never
have
to
customize
your
application
for
it.
A
The
nature
of
cloud
native
demands
that
jvms
not
only
have
that
high
throughput,
but
also
that
bar
startup,
and
this
has
given
rise
to
a
whole
new
bunch
of
technologies
that
are
really
attempting
to
optimize
jvm's
for
that
cloud
native
environment,
so
enabling
us
to
sort
of
shift
in
the
performance
characteristics
of
jvms
towards
high
throughput,
but
also
fast
startup.
So
we
have
some
solutions
that
are
already
available,
for
example
like
things
like
Dynamic,
aot,
compilation
and
class
metadata
persistence
and
also
things
like
static
compilation
with
Native
images.
A
But
there
are
some
trade-offs
to
this.
So
new
class
persistence
and
dynamic
aot
compilation
they've
really
been
added
to
traditional
jdks
to
improve
startup
times,
so
they
essentially
save
class
metadata
and
reload
it
on
subsequent
runs,
so
there's
a
much
shorter
path
for
loading
classes
and
compiling
methods.
This
has
benefits
to
Startup
performance.
So
if
you
see
the
graph
that
we
got
on
the
right,
the
side
that
is
bigger,
it
shows
the
advantages.
A
So
you
can
see
that
sort
of
on
the
native
image
side
that
gravy
M
side
we've
got
a
slightly
more
on
the
right
hand,
side
in
that
startup
time.
So
there
are
benefits.
So
it's
interesting
to
see
that,
but
there
are
some
trade-offs
as
well.
Now
native
image
is
kind
of
new,
but
also
really
old
approach
where
the
entire
application
is
compiled
statically.
So
you
have
this
kind
of
closed
World
analysis.
So
there's
no
interpretation
that's
required
because
everything
is
compiled,
so
you
already
start
at
Peak
Performance.
A
So
you
get
some
really
fast
startup
times.
However,
so,
for
example,
trade-offs
with
Native
image
are
things
like
because
it
doesn't
have
a
jit.
It
can't
benefit
from
profile,
guided
optimizations
in
the
same
way
that
a
traditional
jdk
does
so.
Your
Peak
Performance
is
often
lower
than
a
traditional
jdk.
A
Additionally,
jvms
have
sort
of
tried
and
tested
Harvard
collection
policies
that
are
very
efficient
at
reclaiming
memory,
so
making
that
as
efficient
as
possible,
so
memory
footprint
might
be
under
Peak
and
it
can
often
be
measured
to
be
lower
on
traditional
jvms
in
comparison
to
Native
images.
You've
also
got
to
think
about
the
fact
that
this
is
kind
of
a
closed
World
analysis,
so
native
images
often
strip
out
the
parts
of
the
app
that
aren't
needed,
keeping
image
sizes
small.
A
But
that
being
said
with
Technologies
like,
for
example,
multi-layer
sat,
there's
sharing
when
you
have
multiple
jvms
in
a
contained
image,
so
the
jvm
map
might
be
slightly
larger.
Sharing
the
jvm
image
would
result
in
a
smaller
through
a
smaller
footprint
and,
of
course,
you've
also
got
to
think
about
the
fact
that
full
static
compilation
does
take
time.
So
you
will
experience
sort
of
longer
build
times
for
your
apps
in
comparison
to
the
traditional
jdks
and
with
the
jdk
jvm.
A
A
However,
to
be
able
to
try
and
bring
these
two
worlds
together,
there
have
been
some
sort
of
involved,
announcements
and
innovations
that
have
been
happening
in
the
jvm
space
to
try
and
bring
these
together.
So
that
includes
the
jit
server
technology.
Next
slide,
please.
So
in
Eclipse,
open
j9
there
is,
there
have
been
some
advancements
that
have
been
going
on
introducing
this
technology,
which
stands
for
it's
essentially
jit
as
a
service.
So
it's
separating
out
the
jit
from
the
sort
of
jvm
itself
next
slide.
A
Please
so
jpms
employ
this
jet
compiler,
as
I
mentioned.
It
helps
with
that
optimization
to
improve
the
throughput
of
java
applications,
but
chicken
Pilots
don't
come
for
free.
They
consume
resources
and
in
terms
of
CPU
and
memory
they
can
also
interfere
with
things
like
the
smooth
running
of
java
applications.
So
we
were
kind
of
looking
for
a
solution
of
well.
Wouldn't
it
be
nice
to
keep
all
of
the
advantages
of
dynamic
compilation
but
eliminate
some
of
its
disadvantages,
and
this
is
kind
of
where
the
jit
server
technology
came
in.
A
What
that
enables
us
to
do
is
have
sort
of
Auto
management
by
orchestrators
like,
for
example,
kubernetes
or
Docker
swarm,
and
you
can
make
sure
service
is
essentially
always
running
and
scaled
properly
to
demand.
It's
essentially
the
same
as
if
you
were
changing
a
monolithic
app
into
microservices.
We've
just
done
the
same
thing
here:
we've
just
made
the
jit,
essentially
that
kind
of
micro
service
out
of
that
kind
of
Monolithic
jvm
that
we
had
before.
A
But
it
is
worth
noting,
as
you
can
see,
on
the
diagram
here,
we
have
crossed
out
jet
on
the
left
hand
side,
but
actually
it's
not
gone.
It
can
still
be
used
if
the
remote
jet
should
become
unavailable.
So
it
can
be
very
reliable
in
that
regard,
because
you've
always
got
a
chip
available
and
it
actually
comes
with
various
different
benefits.
A
So,
for
example,
if
we
go
to
the
next
slide,
it
all
things
like
improving,
container
density
and
cost
so
container
sizing
can
be
based
solely
on
the
resource
usage
of
the
Java
application,
which
means
that
we
can.
We
can
basically
have
smaller
containers
and
increase
our
application
density,
meaning
that
we
can
reduce
our
overall
costs.
So,
as
you
can
see
here,
the
size
of
the
shape
that
we
have
in
this
diagram
essentially
indicates
its
relative
container
size.
A
You
can
see
in
the
legend
here,
we've
got
lots
of
different
applications
that
are
all
running,
and
the
number
in
the
shape
is
essentially
the
memory
limit
for
that
container.
So,
as
you
can
see
in
the
top
row,
all
three
work
into
being
used
and
the
size
of
the
containers
are
all
larger
than
the
bottom
graph,
because
essentially
we're
building
in
extra
memory
to
avoid
things
like
out
of
memory,
exceptions
and
issues
and
improve
throughput.
The
bottom
row
uses
the
jit
server.
A
So
now
we
can
condense
it
down
to
just
two
worker
nodes
instead
of
three
being
used.
So
despite
the
fact
that
the
jit
server
containers,
which
are
the
ones
shown
in
brown
here,
are
the
largest
containers
in
the
node,
there
are
savings
that
have
come
that
have
come
from
being
able
to
scale
down
each
of
the
application
nodes.
So
essentially,
the
end
result
of
this
is
being
able
to
save
33
in
cost
savings
by
using
one
less
worker
node.
A
So
some
great
savings
there
to
be
made
and
as
well
as
that,
we've
also
got
additional
benefits
in
throughput.
Compare
persons
as
well
next
slide,
please.
So.
Actually
the
orange
line
here
that
you
can
see
represents
the
top
row
from
that
previous
page.
That
we
saw-
and
the
blue
line
represents
the
bottom
row
from
the
previous
page,
which
uses
that
jit
server
and
each
graph
represents
each
of
the
applications
that
we
were.
A
We
were
taking
a
look
at
and
you
can
see
that
performance
is
pretty
even
despite
the
fact
that
the
jit
server
is
working
with
less
worker
node
CPUs,
the
small
blue,
lags,
are
kind
of
likely
caused
by
Noisy
Neighbor
effects
due
to
all
the
apps
that
are
loaded
up.
At
the
same
time,
you
can
see
the
performance
is
pretty
much
equal
with
less
costs
and
less
worker
nodes,
which
is
a
great
sort
of
benefit
to
using
this.
A
Obviously,
there
are
alternatives
that
you
can
take
a
look
at,
for
example,
like
aot
compilation.
That
I
mentioned
next
slide.
Please,
and
that's
essentially
ahead
of
time
compilation
using
native
images
next
slide.
Please-
and
this
is
kind
of
picked
up
by
things
like
gravyam,
for
example.
It's
the
approach
they
use,
and
this
is
where
you're
essentially
transforming
the
program
into
machine
code
before
you
execute,
but
as
I
mentioned,
there
are
pros
and
cons
next
slide.
A
Please
so
really
it's
about
sort
of
looking
at
the
pros
and
cons,
but
perhaps
there's
some
way
of
being
able
to
have
the
benefits
of
both.
So
is
there
a
way
in
which
just
like,
when
we
looked
at
you
know,
introducing
jit
in
the
first
place,
to
introduce
that
sort
of
faster
startup
for
jvms
in
the
first
place?
A
Is
there
a
way
that
we
could
gain
the
benefits
of
aot
whilst
not
losing
the
benefits
of
jit
and
jvm,
of
that
full
jvm
that
Dynamic
compilation
to
be
able
to
have
a
chart
that
is
sort
of
at
the
max
for
each
of
these
various
behaviors?
When
we're
looking
at
deploying
our
Cloud
native
applications
and
that's
what
we're
going
to
be
taking
a
look
at
through
Tom's
demo
today
with
the
instant
on
technology,
so
I'll
pass
it
over
to.
B
B
We
view
this
technology
to
be
very
interesting
for
doing
containerized
applications
that
are
running
in
you
know
like
the
kubernetes
environment
or
out
on
the
cloud,
so
we're
very
much
focusing
this
solution
for
that
type
of
environment.
But
criu
itself
is
a
very
general
purpose
tool
and
it
what
it
enables
is
a
snapshot
or
a
checkpoint
of
a
particular
application
or
process,
and
when
you,
when
it's
taking
a
snapshot
but
criu
does,
is
it
basically
pauses
the
execution
of
the
whole
application?
B
So
they
can
gather
up
all
of
the
state
for
that
particular
process
and
they
can
store
it
down
onto
disk
and
readable
format
and
at
a
layer
Point,
perhaps
even
on
another
machine.
Criu
can
read
this
data
and
then
restore
the
process
and
get
it
back
up
and
running
from
the
exact
point
that
it
was
when
it
took
the
deposit
and
took
the
snapshot
and
from
the
running
applications
perspective.
B
It
doesn't
actually
feel
like
or
know
that
it
was
was
stopped
or
had
that
gap
between
times
whenever
we
did
the
checkpoint
and
did
the
restore
all
of
its
state
is
there
that
was
previously
there
and
it
just
picks
up
and
can
continue
running
and
the
Cru
restores
is
quite
fast.
It
can
happen
in
as
much
as
50
to
100
milliseconds
on
a
really
complicated
application,
but
then
at
that
point
we're
up
and
running
from
that
state.
B
B
So
then,
when
we
restore
all
of
that's
there
and
we
can
get
quickly
up
and
running,
but
there
are
some
challenges
with
that,
because
anything
that's
run
before
the
checkpoint
may
contain
some
state
that
you
wouldn't
necessarily
want
to
restore
over
and
over
into
individual
instances.
So
these
are
some
of
the
challenges
that
we
were
observing
a
couple
years
back
when
we
started
thinking
about
well,
how
can
we
make
this
really
production
ready?
B
And
so
that's?
What's
the
effort
of
a
liberty
incident
on
as
well
as
simaru,
instant,
on
which
I'll
go
into
more
details
in
a
little
bit,
but
once
we
have
that
proven
and
ready
to
go,
we
can
start
thinking
about
getting
these
applications
up
and
running
in
in
a
100
or
200
milliseconds,
and
then
we
can
still
really
start
applying
that
to
these
scale
to
zero
scenarios
that
Grace
had
mentioned
earlier,
so
we
can
get
that
cost
savings.
Whenever
your
applications
have
no
traffic,
we
can
really
bring
all
those
instances.
A
B
B
So
when
we're
looking
at
performance,
our
team,
we
we
use
a
number
of
applications,
but
here's
three
of
the
typical
ones
we
use
they
range
in
complexity.
The
one
on
the
left
is
a
ping
perf.
So
this
is
a
very
simple
Jakarta
restful
service
web
service,
and
it
just
has
a
simple
endpoint
that
displays
the
the
system
properties,
but
on
on
a
liberty,
Baseline
that
can
come
up
and
serve
as
the
first
request
and
right
around
1400
milliseconds
and
using
the
Liberty
incident
on
beta.
We
can
bring
that
down
to
128
milliseconds.
B
Similarly,
the
rest
crud
is
just
a
simple
database.
Application
also
has
a
restful
web
service
in
it
as
well,
and
that
takes
just
just
over
three
seconds
to
start
up
on
the
Liberty
Baseline
and
service,
its
first
request
and
we
can
bring
that
down
to
a
213,
milliseconds
and
then
finally,
day
trader
is
we're
a
monolithic
type
application
based
a
web
profile
or
Jakarta
ee
platform
application.
B
A
B
Safe
mode,
so
that
it
can
be
persisted
safely
and
then
restored
and
be
able
to
restore
it
into
many
different
instances
that
are
distinct
from
one
another
and
behave
properly.
And
so
we
really
want
to
make
that
easy
and
usable
for
the
user
to
create
their
own
checkpoint
processes,
get
them
up
and
running
in
container,
because
we
really
view
this
as
a
container
type
technology.
B
So
the
question
becomes
on
on
where
to
checkpoint,
so
for
Liberty
incident
on
we,
we
leverage
something
called
the
simaru
runtime.
So
this
is
the
IBM
jvm.
It's
based
upon
open
j9,
which
is
the
eclipse
open
source,
open
j9
project,
and
it
really
provides
this
seamless
checkpoint
restore
solution
for
developers.
B
But
there
is
some
complexities
you
have
to
consider
whenever
you're
thinking
about
where
you're
going
to
checkpoint.
Generally
speaking,
the
later
in
your
startup
process
that
your
checkpoint
means
the
more
code
you're
going
to
run.
So
obviously,
if
you
take
the
checkpoint
later
and
then
restore
you're
saving
all
that
time,
you
don't
have
to
do
all
that
work
to
get
up
to
that
ready
state
where
you
took
the
checkpoint,
but
it
does
mean
you
ran
more
code
and
the
more
code.
B
You
run
the
more
considerations
you
have
to
take
into
account
to
make
sure
it's
safe
and
ready
and
can
be
successfully
restored
into
many
different
instances.
So
here
we
offer
a
few
different.
What
we
call
checkpoint
phases
in
open
Liberty,
so
the
very
first
one
is
called
features.
So
those
not
familiar
with
the
open
Liberty
features
is
basically
the
point
where
open
Liberty
is
loading
up
the
the
set
of
features
that
you've
configured
for
your
particular
application.
B
So
this
is
the
point
where
we've
basically
loaded
up
what
you
configured,
but
we
haven't
actually
started
processing
any
applications,
so
you
can
have
you
know
onstarted
server,
servlets
or
you
have
early
start
CDI
beans
and
other
types
of
things
that
are
offered
by
the
various
specifications
where
your
application
may
start
getting
executed.
As
soon
as
the
you
know,
the
server
context
or
the
application
scope
is
created
for
the
for
the
CDI
being.
B
This
is
where
we
start
running
application
code
and
then,
once
all
that
has
has
run
and
we
reported
the
application
started.
This
is
where
we
take
that
final
checkpoint
and
that
checkpoint
is
before
we've
opened
up
any
ports
to
take
incoming
requests.
So
we
don't
allow
any
interaction
outside
of
you
know
the
Liberty
run
time
to
happen.
While
we're
doing
this
particular
a.
B
So
with
that
understanding,
I'm
going
to
go
into
a
demo
of
building
an
application
using
Liberty,
instant
on
and
I'm
going
to
be
using
this
getting
started
guide
so
on
open
Liberty,
I
o.
So
you
can.
You
can
go
ahead
and
do
this
yourself,
but
here
I
have
it
already
I've
already
gone
through
the
guide
I'm
just
in
the
the
finished
directory,
so
the
application
is
actually
all
built.
It's
just
a
simple
rest
in
plane,
it's
similar
to
Pink
perf.
B
It
just
displays
the
system
properties,
but
it
also
enables
a
bunch
of
micro
profile,
Technologies
for
doing
the
health
and
metrics
and
so
on.
So
and
here
I
have
a
Docker
file
and
so
there's
a
Docker
file
in
the
original
guide.
But
here
I
just
changed
it
to
use
the
beta
instant
on
image
from
open
Liberty.
So
this
image
contains
all
the
prerequisites
necessary
for
criu
to
do
its
work
as
well
as
open
j9.
So
it
includes
an
open
j9.
B
You
know
similar
runtime
beta
early
access
beta
and
then
as
well
as
the
open
Liberty
beta.
That
includes
the
instant
on
support,
and
so
we've
been
working
very
closely
with
the
open
j9
team
so
that
we
can
utilize
as
much
power
out
of
the
jvm
to
get
it
into
the
state
that
we
needed
to
to
checkpoint
safely,
and
then
we
also
have
our
own
hooks
within
Liberty,
so
that
we
can
make
sure
our
stuff
on
top
of
the
jvm,
is
also
safe
and
ready
to
checkpoint.
B
So
as
you're
picking
your
different
choices,
you
know
feed
teachers
or
deployment
or
applications.
You
know
if
you're
choosing
features
the
goal.
Is
that
all
of
our
code
that
gets
up
to
that
point?
We
make
it
safe
and
ready
to
checkpoint,
and
then,
if
you
go
into
applications,
that's
obviously
gets
more
into
the
application
space.
B
So
we
gotta
make
sure
those
the
applications
are
running
are
are
safe,
I
meant
to
mention
this
earlier,
but
some
examples
of
what
may
not
be
safe
is
if
your
application,
for
example,
is
trying
to
make
remote
database
calls
in
its
early
startup
code.
These
are
things
that
you're
not
going
to
want
to
do
while
we're
doing
a
checkpoint
and
I'll
I'll
get
into
that.
In
a
little
bit
more
detail
as
I'm
running
through
the
demo.
A
B
This
is
just
the
basic
Docker
file
for
containerizing
in
Oakland
Liberty
application,
so
we're
just
configuring
copying
some
configuration
copying
in
the
war
and
then
we're
running
this
configure
script,
which
does
the
optimizations
for
Liberty.
So
none
of
that
is
actually
doing
instant
on
stuff,
so
I'm
going
to
have
a
container
created
and
now
I
can
go
ahead
and
run
this
application.
B
So
we're
going
to
see
just
you
know,
this
is
the
Baseline
for
this
particular
application
running
on
Liberty,
and
so
this
is
running
in
container
just
did
a
simple
run
and
you
know
Port
mapping,
90
80
to
90
80.,
and
you
see
it
came
up
in
right
around
five
seconds.
So
this
is
our
application
here,
Robin
running
and
it
has
some
metrics
and
the
health
and
so
on.
This
is
the
end
point
here:
that's
just
displaying
the
the
system
properties.
A
B
Layer
on
top
of
this
existing
application
container,
and
so
that
really
involves
two
steps,
so
foreign
Step
One
is
performing
the
actual
checkpoint.
So
the
way
we
do
that
is
actually
running
it
in
containers,
so
here
I'm
going
to
just
start
up
the
the
container
that
I
just
created
but
I'm,
going
to
pass
it
in
environment,
variable
checkpoint
and
I'm,
going
to
tell
it's
a
checkpoint
at
application.
So.
B
To
checkpoint
at
that
latest
point
in
time,
I
will
mention
that
I
am
using
a
privileged
container
here.
That's
just
the
the
easiest
way
to
Grant
criu
on
the
checkpoint
side.
All
the
capabilities
it
needs
to
do
the
checkpoint.
The
resulting
application,
image
and
process
that
gets
restored
doesn't
need
to
run
in
a
privileged
container
and
I'll
get
to
that
more
when
I'm
actually
running
the
end
result
foreign.
B
So
let's
go
ahead
and
run
this,
so
this
is
going
to
do.
Looks
like
he's
doing
much
the
same
as
whenever
I
was
running
the
original
image
and
in
fact,
I
am
running
the
original
image,
but
the
one
difference
is
is
once
it
gets
past
the
you
know
the
application
started
here
in
two
seconds:
it's
actually
doing
a
checkpoint.
B
So
at
this
point
Liberty,
you
know
runs
a
bunch
of
its
pre-checkpoint
hooks
to
get
itself
into
the
right
State
and
then
it's
to
ask
the
open,
j9
Cru
support
so
go
ahead
and
do
the
checkpoint.
At
that
point,
the
jvm
also
has
its
own
set
of
hooks
where
it's
fixing
up
stuff.
So
some
examples
of
things.
B
That's
it's
fixing
up
are
things
like
secure,
random
and
making
sure
that
it
can
get
those
things
all
discovered,
and
so
it
can
quickly
reseed
them
on
the
restore
side,
so
that
secure
random
remains
sufficiently
random
for
each
of
your
restored
instances.
So
that's
important
for
things
like
security,
algorithms.
B
B
Even
if
you
change
to
like
a
different
machine
and
doing
a
restore
on
a
different
machine,
it
does
other
things
like
making
sure
that
the
heat
is
getting
optimized
and
and
we
make
sure
we
don't
have
a
whole
bunch
of
excess,
excessive
amount
of
threads,
because
all
those
extra
threads
add
to
the
state
of
the
jvm.
So
at
this
point
we
really
try
to
compact
down
the
runtime
and
get
it
so
that
that
process
image
can
be
as
small
and
as
quick
as
possible
to
restore.
B
So
from
this
point,
I
have
a
stopped
container.
I
I
tagged
it
as
getting
started
checkpoint,
and
this
is
this
stops
container-
contains
the
process
data
for
that
image.
For
that
process
that
I
just
checkpointed
here.
But
it's
it's
not
a
a
runnable
application
container
image.
So
the
next
step
is
basically
to
commit
that
checkpoint
container
into
an
image.
B
A
B
How
we
run
this
so
we're
talking
about
running,
we
don't
run
it
as
a
privileged
container,
but
there
are
a
number
of
capabilities
we
have
to
grant
that
running
container.
Currently
we
require
these
three
capabilities.
I
will
say
we
have
efforts
underway
to
get
rid
of
net
admin
as
well
as
assist
P
Trace,
but
the
existing
betas
today
still
require
these
two
capabilities.
One
capability
that
we
don't
see
going
away,
though,
is
this
checkpoint
restore
capability.
This
is
a
relatively
new
capability.
B
So
if
I
run
this
you'll
notice,
it
came
up
in
right
around
359
milliseconds,
so
you
know
greater
than
10x
Improvement
and-
and
we
still
have
a
functional
application
here,
just
like
before
and
you'll
notice
that
that
I
didn't
have
to
do
any
application
changes.
I
I
just
was
able
to
get
it
up
and
running
and
and
going
quickly.
B
B
B
The
original
one,
so
what
what
needs
to
happen
is
it
it
sits
here
and
it's
waiting
and
waiting
and
it's
basically
k-native
is
doing
its
job.
But
then
it's
also
having
to
start
up
the
original
container
image
that
when
you
saw
I
ran
it
locally,
it
was
five
seconds
or
more,
and
this
environment
takes
a
bit
more
and
it
actually
took
us.
You
know
14
seconds
to.
A
B
Back
now,
I
will
say
that
at
least
three
of
that
is
is
overhead
of
K
native
in
my
particular
environment,
but
the
rest
of
that
is
that
application
having
it
come
up
and
and
run
so
you'll
notice
now
I
have
that
run
running
if
I.
If
I
invoke
the
instant
on
one
now,
this
one
is
again
it
has
to
has
that
three
second
overhead,
but
then
you'll
notice
that
it's
not
much
more
than
three
seconds,
because
the
container
was
able
to
get
up
and
running
very
very
quickly.
B
A
B
So
that
is
the
end
of
my
demos,
and
it
is
really
the
end
of
my
planned
talks,
because
I
I
was
thinking.
We
were
probably
going
to
run
out
of
time
before
I
could
display
much
else.
So
I
think
we
can
just
go
into
here
and
say
thank
you
and
Grace.
I'll
turn
it
over
to
you
for,
for
this
part
and
questions
yeah.
A
So,
just
summarize,
with
a
you
know,
if
you,
if
you're
still
in
learning
more
about
G
following
some
of
the
incident
on
what
we're
doing
or
just
learning
more
about
open
Liberty
if
you've
not
come
across
it
before
please
connect
with
us
on
social
media
share
your
thoughts
follow
us.
You
can
learn
more
about
this
news
on
either
Twitter
or
LinkedIn
and
in
case
you're
interested
in
finding
out
more.
We
also
have
some
resources
for
you
just
in
case
we
hadn't
bombarded
you
with
information
already.
A
So
if
you
are
interested,
then
check
out
some
of
these
links
here
around
cry,
you
instant,
on
the
instant
on
beta.
If
you
want
to
see
the
demo
again,
then
check
out
the
community
Keynotes
that
are
later
on
today,
because
Ian
Robinson
will
be
doing
some
more
on
this
technology
and
a
demo
there.
But
if
you
also
want
a
recorded
version,
you
can
head
to
that
YouTube
link
and
find
out
there
and
watch
it
again
and
then
there's
also
the
open
j9
link.