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 |
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 |
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 > |
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 |
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. |
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 > > |
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 |
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 |
On Wed, Apr 13, 2011 at 4:21 PM, Stefan Marr <[hidden email]> wrote:
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: -- Mariano http://marianopeck.wordpress.com |
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 |
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 |
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 |
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 |
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 |
On Wed, Apr 13, 2011 at 11:06 PM, Dave Mason <[hidden email]> wrote: From: 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 -- Mariano http://marianopeck.wordpress.com |
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 |
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 > > |
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 -- Mariano http://marianopeck.wordpress.com |
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 |
Free forum by Nabble | Edit this page |