Meanwhile, at another vm

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Meanwhile, at another vm

Stephan Eggermont-3
Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Sven Van Caekenberghe

On 12 Apr 2011, at 16:20, Stephan Eggermont wrote:

> http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-April/002802.html

Sounds nice, but could you give some context, URLs ?
What are they talking about ?

Sven



Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

NorbertHartl

Am 12.04.2011 um 21:16 schrieb Sven Van Caekenberghe:

>
> On 12 Apr 2011, at 16:20, Stephan Eggermont wrote:
>
>> http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-April/002802.html
>
> Sounds nice, but could you give some context, URLs ?
> What are they talking about ?

I think the talk about a smalltalk implementation based on

http://www.jcp.org/en/jsr/detail?id=292

Norbert

Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Stéphane Ducasse
In reply to this post by Stephan Eggermont-3
I really interested to see if pharo would run on a JVM.
Do you know what smalltalk they are working on?

Stef

On Apr 12, 2011, at 4:20 PM, Stephan Eggermont wrote:

> http://mail.openjdk.java.net/pipermail/mlvm-dev/2011-April/002802.html
>


Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Philippe Marschall-2
On 04/13/2011 09:00 AM, Stéphane Ducasse wrote:
> I really interested to see if pharo would run on a JVM.

Probably not. I mean you all the code relying on primitives, all the
code relying on ByteString having the same memory layout as ByteArray,
all the code relying on the scheduler being non-preemptive,  all the
code relying on #become: and so forth.

Cheers
Philippe


Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Marcus Denker-4
In reply to this post by Stéphane Ducasse

On Apr 13, 2011, at 9:32 AM, Philippe Marschall wrote:

> On 04/13/2011 09:00 AM, Stéphane Ducasse wrote:
>> I really interested to see if pharo would run on a JVM.
>
> Probably not. I mean you all the code relying on primitives, all the
> code relying on ByteString having the same memory layout as ByteArray,
> all the code relying on the scheduler being non-preemptive,  all the
> code relying on #become: and so forth.
>

And does anyone really want a smalltalk without become: ?

And how do they do the thisContext magic?

        Marcus

--
Marcus Denker  -- http://www.marcusdenker.de
INRIA Lille -- Nord Europe. Team RMoD.


Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Stéphane Ducasse
In reply to this post by Philippe Marschall-2
still this can always be interesting to learn your limit and dependencies.

Stef

On Apr 13, 2011, at 9:32 AM, Philippe Marschall wrote:

> On 04/13/2011 09:00 AM, Stéphane Ducasse wrote:
>> I really interested to see if pharo would run on a JVM.
>
> Probably not. I mean you all the code relying on primitives, all the
> code relying on ByteString having the same memory layout as ByteArray,
> all the code relying on the scheduler being non-preemptive,  all the
> code relying on #become: and so forth.
>
> Cheers
> Philippe
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Philippe Marschall-2
On 04/13/2011 02:57 PM, Stéphane Ducasse wrote:
> still this can always be interesting to learn your limit and dependencies.

Sure, didn't make any judgments in any way. Just said I see some
problems on the road.

Cheers
Philippe


Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Stefan Marr-4
In reply to this post by Philippe Marschall-2

On 13 Apr 2011, at 09:32, Philippe Marschall wrote:
> Probably not. I mean you all the code relying on primitives, all the
> code relying on ByteString having the same memory layout as ByteArray,
> all the code relying on the scheduler being non-preemptive,  all the
> code relying on #become: and so forth.

"Running on the JVM" and "Running on the JVM" are two completely different things.

Just a reminder:
  http://news.squeak.org/2008/07/07/potato-version-of-jsqueak-from-hpi/


--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525


Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Mariano Martinez Peck


On Wed, Apr 13, 2011 at 4:21 PM, Stefan Marr <[hidden email]> wrote:

On 13 Apr 2011, at 09:32, Philippe Marschall wrote:
> Probably not. I mean you all the code relying on primitives, all the
> code relying on ByteString having the same memory layout as ByteArray,
> all the code relying on the scheduler being non-preemptive,  all the
> code relying on #become: and so forth.

"Running on the JVM" and "Running on the JVM" are two completely different things.



Here seems to be the same

'Running on the JVM'  = 'Running on the JVM'  -> true

ehehhe I guess you forgot to change something or I am so stupid to understand...
 
Just a reminder:
 http://news.squeak.org/2008/07/07/potato-version-of-jsqueak-from-hpi/


--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: <a href="tel:%2B32%202%20629%202974" value="+3226292974">+32 2 629 2974
Fax:   <a href="tel:%2B32%202%20629%203525" value="+3226293525">+32 2 629 3525





--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Stefan Marr-4
Hi:

On 13 Apr 2011, at 16:44, Mariano Martinez Peck wrote:

>
> "Running on the JVM" and "Running on the JVM" are two completely different things.
> Here seems to be the same
>
> 'Running on the JVM'  = 'Running on the JVM'  -> true
>
> ehehhe I guess you forgot to change something or I am so stupid to understand...
Sorry, that was on purpose. 'Running on the JVM' is just a useless term.

Potato shows how to implement an interpreter in Java that runs on top of the JVM.
With some minor adaptations it would also be able to run Pharo.
But the question is, how useful would that be. With that model, it is not directly possible to exploit JVM mechanism like threads.
It is basically identical to the SqueakVM with just exchanging C for Java.

Even compiling Smalltalk to Java bytecode does not get you closer to leveraging the JVM.
It would be 'just' Cog, with JVM bytecodes as a target instead of x86.
You get speed, but you do not really get closer to use the JVM platform.

Best regards
Stefan

>  
> Just a reminder:
>  http://news.squeak.org/2008/07/07/potato-version-of-jsqueak-from-hpi/

PS: It would be awesome if my mail client would be able to quote your mail correctly.

--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525


Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Stephan Eggermont-3
In reply to this post by Stephan Eggermont-3
JSR 292 explicitly talks about become: (calls it hotswap) and is supposed
to make it possible to run Smalltalk efficiently on a jvm.
I don't know how complete the jsr 292 implementation is of mlvm.

I got the link in a tweet. Roos builds modular automated test equipment.

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Philippe Marschall-2-3
On 13.04.2011 19:40, Stephan Eggermont wrote:
> JSR 292 explicitly talks about become: (calls it hotswap) and is supposed
> to make it possible to run Smalltalk efficiently on a jvm.

What I know as hotswap as hot swap would not help with #become:. My
understanding is that when "they" went from an object table to direct
pointers for memory access speed that made it more complicated to
implement #become: and certainly slower.

Cheers
Philippe


Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Michael Haupt-3
In reply to this post by Stephan Eggermont-3
Stefan,

Am 13.04.2011 um 19:40 schrieb Stephan Eggermont <[hidden email]>:
> JSR 292 explicitly talks about become: (calls it hotswap)

the HotSwap I know is JVM technology introduced in Java 1.4 and is solely about changing method implementations at run-time. I haven't read the JSR, but I'd be amazed if another technology, this time for object identity exchange, would be introduced under the same name.

Best,

Michael
Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Dave Mason-3
From:
        http://www.jcp.org/en/jsr/detail?id=292

"We will also investigate support for hotswapping, the capability to modify the structure of classes at run time."

So, yes, they planned to "investigate" a version of become:

The DaVinci Machine

        http://openjdk.java.net/projects/mlvm/

has an implementation:

        http://wiki.jvmlangsummit.com/images/4/41/DaVinciMachineTalk.pdf

../Dave
Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Mariano Martinez Peck


On Wed, Apr 13, 2011 at 11:06 PM, Dave Mason <[hidden email]> wrote:
From:
"We will also investigate support for hotswapping, the capability to modify the structure of classes at run time."

So, yes, they planned to "investigate" a version of become:


How is that phrase related to #become:   ?   Modyfing the structure of a class at runtime has nothing to do with a #become:

 
The DaVinci Machine

       http://openjdk.java.net/projects/mlvm/

has an implementation:

       http://wiki.jvmlangsummit.com/images/4/41/DaVinciMachineTalk.pdf

../Dave



--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Göran Krampe
On 04/13/2011 11:15 PM, Mariano Martinez Peck wrote:
> On Wed, Apr 13, 2011 at 11:06 PM, Dave Mason <[hidden email]
>     "We will also investigate support for hotswapping, the capability to
>     modify the structure of classes at run time."
>
>     So, yes, they planned to "investigate" a version of become:
>
>
> How is that phrase related to #become:   ?   Modyfing the structure of a
> class at runtime has nothing to do with a #become:

It depends. If "modify structure" means "modifying methods" then indeed
it has little to do with become:. But if it means "changing the memory
layout of the class by for example adding ivars" then it has to do with
become: because it is needed to do instance migration from the old class
to the new class.

regards, Göran

Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Nicolas Cellier
In reply to this post by Mariano Martinez Peck
Maybe if that class has living instances, you must provide a way to
mutate the instances...
The easiest way is to create a mutated clone and becomeForward.

Nicolas

2011/4/13 Mariano Martinez Peck <[hidden email]>:

>
>
> On Wed, Apr 13, 2011 at 11:06 PM, Dave Mason <[hidden email]> wrote:
>>
>> From:
>>        http://www.jcp.org/en/jsr/detail?id=292
>>
>> "We will also investigate support for hotswapping, the capability to
>> modify the structure of classes at run time."
>>
>> So, yes, they planned to "investigate" a version of become:
>>
>
> How is that phrase related to #become:   ?   Modyfing the structure of a
> class at runtime has nothing to do with a #become:
>
>
>>
>> The DaVinci Machine
>>
>>        http://openjdk.java.net/projects/mlvm/
>>
>> has an implementation:
>>
>>        http://wiki.jvmlangsummit.com/images/4/41/DaVinciMachineTalk.pdf
>>
>> ../Dave
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Mariano Martinez Peck
aha....good point guys. Thanks :)

On Wed, Apr 13, 2011 at 11:29 PM, Nicolas Cellier <[hidden email]> wrote:
Maybe if that class has living instances, you must provide a way to
mutate the instances...
The easiest way is to create a mutated clone and becomeForward.

Nicolas

2011/4/13 Mariano Martinez Peck <[hidden email]>:
>
>
> On Wed, Apr 13, 2011 at 11:06 PM, Dave Mason <[hidden email]> wrote:
>>
>> From:
>>        http://www.jcp.org/en/jsr/detail?id=292
>>
>> "We will also investigate support for hotswapping, the capability to
>> modify the structure of classes at run time."
>>
>> So, yes, they planned to "investigate" a version of become:
>>
>
> How is that phrase related to #become:   ?   Modyfing the structure of a
> class at runtime has nothing to do with a #become:
>
>
>>
>> The DaVinci Machine
>>
>>        http://openjdk.java.net/projects/mlvm/
>>
>> has an implementation:
>>
>>        http://wiki.jvmlangsummit.com/images/4/41/DaVinciMachineTalk.pdf
>>
>> ../Dave
>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
>




--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: Meanwhile, at another vm

Stefan Marr-4
In reply to this post by Göran Krampe

On 13 Apr 2011, at 23:27, Göran Krampe wrote:

> On 04/13/2011 11:15 PM, Mariano Martinez Peck wrote:
>> On Wed, Apr 13, 2011 at 11:06 PM, Dave Mason <[hidden email]
>>    "We will also investigate support for hotswapping, the capability to
>>    modify the structure of classes at run time."
>>
>>    So, yes, they planned to "investigate" a version of become:
>>
>>
>> How is that phrase related to #become:   ?   Modyfing the structure of a
>> class at runtime has nothing to do with a #become:
>
> It depends. If "modify structure" means "modifying methods" then indeed it has little to do with become:. But if it means "changing the memory layout of the class by for example adding ivars" then it has to do with become: because it is needed to do instance migration from the old class to the new class.

There is no need for guessing, Google knows the answer:
  http://download.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#RedefineClasses

"Instances of the redefined class are not affected -- fields retain their previous values. Tags on the instances are also unaffected."

"The redefinition may change method bodies, the constant pool and attributes. The redefinition must not add, remove or rename fields or methods, change the signatures of methods, change modifiers, or change inheritance. These restrictions may be lifted in future versions. "...



--
Stefan Marr
Software Languages Lab
Vrije Universiteit Brussel
Pleinlaan 2 / B-1050 Brussels / Belgium
http://soft.vub.ac.be/~smarr
Phone: +32 2 629 2974
Fax:   +32 2 629 3525


12