Want to join: Propose again JSR 323: "Strong Mobility for, Java"? (dalibor topic)

[dalibor topic]

On 05.10.2016 13:04, Larbi Boundaoui wrote:
> Hi Dalibor,
>
>   Thanks for your reply, but I don't think this is a research project,
> it is a very concrete feature that is proposed, it's even been proposed
> before as you know, and therefore the proposed JSR is very specific.

If you look at research around strong mobility and the JVM, it seems 
that almost all of it petered out about 10 years ago. That's a long time 
ago in internet years, so some of the assumptions made in the initial 
JSR might have changed meanwhile. There seem to be no actively 
maintained open source projects of that nature, either, suggesting that 
the idea has not been embraced by mainstream developers since the 
research ended.

In addition, please consider that the original JSR 323 claims that 
"Since JVM is written in C language" something else is true, which is an 
odd thing to claim.

HotSpot, for example, is not written in the C language. Projects like 
Graal and Truffle are largely written in Java, for another example, and 
so they may (or may not) be a better starting ground for research in 
this area.

>  I believe there has never been a greater need of Strong Mobility than
> today, seen the variety of platforms, and why would the past decade of
> development in hypervisors and related technologies be in contradiction
> with the need of Strong Mobility?

In the last decade some virtualization projects and products started to 
provide live migration capabilities. See 
http://www.oracle.com/us/technologies/virtualization/ovm-server-for-x86-459312.pdf 
for an example of such a product.

That doesn't invalidate your perceived need per se, but it does raise 
the question whether a bytecode (re)translation based approach, as seems 
to be suggested by the rejected JSR, is the best way to migrate hot code 
around today in, say, a cloud running on virtualized containers.

If you watch John's VM futures talk from this year's JVM summit, the 
Stack Reification idea seems it could go a long way towards providing a 
better, JVM level facility for exploratory ideas such as yours. If you 
are interested in discussing such ideas, the right mailing list is mlvm-dev.

cheers,
dalibor topic


-- 
<http://www.oracle.com> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
<tel:+491737185961>

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment