Skip to main content

Isolate migration

6 replies [Last post]
jonek
Offline
Joined: 2006-12-13

Hi.

I am a PhD student at the Technical University of Munich in Germany. My
main field of research are distributed virtual machines. I would like to
ask a few questions about the SquawkVM as from the latest paper [1]
about it I understand that Squawk supports Isolate migration.

I am especially interested in two details:
1. How does Squawk implement the checkpointing mentioned in the paper?
2. Where can I find the mentioned moveTo(IPAddress ip) method?

I had a quick look at the main repository [2] and the squawk-spot
repository but could not find any hints about checkpointing or moveTo().

Thanks for your help,
Johannes.

[1] http://portal.acm.org/citation.cfm?doid=1134760.1134773
[2] https://squawk.dev.java.net/svn/squawk/trunk

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
jonek
Offline
Joined: 2006-12-13

>> Is Squawk able to suspend every running thread of an
>> Isolate that is to be migrated at every arbitrary
>> point of execution?
>
> No. But this is due to thread scheduling on Squawk in general, which does not use native threads but
> schedules all Java threads on a single native thread.

Squawk is using green threads. What exactly happens to the threads' stacks during migration?

> The reschechdule points are backward branches.

Which points does Squawk use as reschedule points?

> So at the point of the hibernate call, every other thread is suspended anyway.

When an isolate is to be migrated all threads belonging to that isolate have to be suspended, right? Does this imply Squawk is waiting for all this threads to reach a reschedule point first?

Greets, Johannes.

jonek
Offline
Joined: 2006-12-13

Hi Derek,

... trying to understand the dependency between migration and the different modes you mentioned.

> DELEGATING - Squawk delegates all IO to another JVM, via JNI
...
> SOCKET - Squawk delegates all IO to another JVM, via a socket

What exactly happens when Squawk delegates "IO to another JVM" with respect to Isolates? Which other JVM is IO delegated to? (J2SE, Squawk or anything else?) Is there any special software required on that other JVM to handle IO?

Does migration in the DELEGATING mode work between Squawk instances running on the same box only? Does migration work in DELEGATING mode work at all if resources are used at migration time?

Thanks, Johannes.

derek_white
Offline
Joined: 2006-09-08

The checkpoint mechanism is called "Isolate.hibernate()" in the source code.

The "moveTo" method was experimented with, but not checked into the current repository. It is fairly simple to implement by using Isolate.save and Isolate.load on the sending and receiving processes, using Java CLDC networking code.

Look for migrateApp() in https://spots-core-libraries.dev.java.net/source/browse/*checkout*/spots... for an example.

As a warning, there are complications with migrating isolates that have references to external state (such as files or network connections). In general this works when Squawk runs "delegated" on top of an operating system with another JVM providing IO support, but not when run on the bare metal on a Sun SPOT, or even running "native" on an OS (without a JVM doing IO for it). The code to do that just hasn't been implemented yet.

jonek
Offline
Joined: 2006-12-13

Hi Derek,

thanks for the pointers! I will have a closer look on the code.

Is Squawk able to suspend every running thread of an Isolate that is to be migrated at every arbitrary point of execution?

> As a warning, there are complications with migrating isolates that have references to external state
> (such as files or network connections).

Sure. The paper suggests: "Before moving, the isolate must close all open
connections to the external world and record relevant information,
so that upon waking it can restore the connections. The waking
isolate must sense the new environment, and reconnect accordingly.
In principle, it may not be possible to successfully connect to the
new environment. Thus we expect isolate migration to be utilized
by developers in specific situations where such problems are known
to be manageable."

I think that is the most simple solution to the problem, i.e. no support for handling of external state during migration at all.

> In general this works when Squawk runs "delegated" on top of an operating system
> with another JVM providing IO support,

Can you please explain in more detail what you mean by "runs delegated"? What kind of other VM are you referring to - another Squawk instance running on the same OS?

> but not when run on the bare metal on a Sun SPOT, or even running "native" on an OS
> (without a JVM doing IO for it). The code to do that just hasn't been implemented yet.

What is the relevant difference between running "delegated" and running "native"? Is migration without using resources (and thus without external references) already possible on the bare metal?

Thanks,
Johannes.

derek_white
Offline
Joined: 2006-09-08

> Is Squawk able to suspend every running thread of an
> Isolate that is to be migrated at every arbitrary
> point of execution?

No. But this is due to thread scheduling on Squawk in general, which does not use native threads but schedules all Java threads on a single native thread. The reschechdule points are backward branches. So at the point of the hibernate call, [i]every[/i] other thread is suspended anyway.

>
> > In general this works when Squawk runs "delegated"
> on top of an operating system
> > with another JVM providing IO support,
>
> Can you please explain in more detail what you mean
> by "runs delegated"? What kind of other VM are you
> referring to - another Squawk instance running on the
> same OS?
>
> > but not when run on the bare metal on a Sun SPOT,
> or even running "native" on an OS
> > (without a JVM doing IO for it). The code to do
> that just hasn't been implemented yet.
>
> What is the relevant difference between running
> "delegated" and running "native"? Is migration
> without using resources (and thus without external
> references) already possible on the bare metal?

So between the trunk version and the squawk-native svn branch there are four modes (aka "platform types"):

PLATFORM TYPE may be one of:
BARE_METAL - Squawk runs on the bare metal, implementing interrupts, timers, etc.
DELEGATING - Squawk delegates all IO to another JVM, via JNI
NATIVE - Squawk runs on an OS, and calls native OS routines for IO, etc.
SOCKET - Squawk delegates all IO to another JVM, via a socket

BARE_METAL is used by the Sun SPOT port, among others.
DELEGATING is used in the svn "trunk" tree by default for all platforms with an OS (Mac, Windows, Solaris, linux)
NATIVE (currently only in the squawk-native branch) is used on the VxWorks port. It allows Squawk to run on smaller systems that have an OS but don't run Java SE. May become the default for platforms with an OS.
SOCKET is not used currently.

The svn "trunk" tree supports the original three modes, but in an ad-hoc fashion. That aren't named as such but are controlled by the FLASH_MEMORY build property and IOPORT option. The two trees will be merged soon however.

derek_white
Offline
Joined: 2006-09-08

> Is migration
> without using resources (and thus without external
> references) already possible on the bare metal?

Yes, migration is not bullet-proof, but should basically work on the bare-metal (SPOTs, etc).