Stack reification and JIT interaction question
Locked
Stack reification and JIT interaction question
 
|
Hi
We have a deep discussion on execution stack reification and we want to know if there is a difference between the blue book and VW. Basically I wrote in a article that in Smalltalk the execution stack is causally connected and reified on demand. - causally connected because if I change the object that represents the stack the stack changes (as show by the example below) - reified on demand measn that the stack is not always a first class objects that I can access via message sends but only when thisContext is used or exceptions. Lukas told me that in Squeak this is always an object and that the blue book shows that too. So I wanted to know in VisualWorks in presence of a JIT if this is the case. My question basically is when a method is executed in the assembly, is it a smalltalk object, can we send it messages (I thought not). Is the stack reified only when using thisContext? Is this correct? Stef test 1 self test2. Transcript show: 'Called test2'; cr test2 self test3 Transcript show: 'Called test3' ;cr test3 thisContext sender: thisContext sender sender |
Re: Stack reification and JIT interaction question
|
|
See http://www.whysmalltalk.com/articles/fileone/ context_management_vw.htm R - On Jan 19, 2007, at 11:25 AM, stéphane ducasse wrote: > Hi > > We have a deep discussion on execution stack reification and we > want to know if there is > a difference between the blue book and VW. > > Basically I wrote in a article that in Smalltalk the execution > stack is causally connected and reified on demand. > - causally connected because if I change the object that > represents the stack the stack changes (as show > by the example below) > - reified on demand measn that the stack is not always a first > class objects that > I can access via message sends but only when thisContext is used > or exceptions. > > Lukas told me that in Squeak this is always an object and that the > blue book shows that too. > > So I wanted to know in VisualWorks in presence of a JIT if this is > the case. > My question basically is when a method is executed in the assembly, > is it a smalltalk object, > can we send it messages (I thought not). > Is the stack reified only when using thisContext? > > Is this correct? > > Stef > > > > test 1 > self test2. > Transcript show: 'Called test2'; cr > > test2 > self test3 > Transcript show: 'Called test3' ;cr > > test3 > thisContext sender: thisContext sender sender > > |
Re: Stack reification and JIT interaction question
|
|
In reply to this post by stéphane ducasse-2
stéphane ducasse wrote:
> Hi > > We have a deep discussion on execution stack reification and we want to > know if there is > a difference between the blue book and VW. > > Basically I wrote in a article that in Smalltalk the execution stack is > causally connected and reified on demand. > - causally connected because if I change the object that represents > the stack the stack changes (as show > by the example below) > - reified on demand measn that the stack is not always a first class > objects that > I can access via message sends but only when thisContext is used or > exceptions. > > Lukas told me that in Squeak this is always an object and that the blue > book shows that too. > > So I wanted to know in VisualWorks in presence of a JIT if this is the > case. > My question basically is when a method is executed in the assembly, is > it a smalltalk object, > can we send it messages (I thought not). > Is the stack reified only when using thisContext? I recall that in ObjectMemory in VW there is a fixed space for stack frames called Stack space. Stack frames (nonobjects) can be converted to their object representation (and back) on demand. The stack frame nonobject representation is needed to actually run the code. Object representation of stack frame is used for reflection. On demand conversion of literal stack frame happens if: * thisContext is used, * exception machinery is used, * Stack space for stack frames is full, GC "moves" some stack frames to Old space by converting them to objects. So to answer your question, I *think* that when a method is being executed, nonobject stack frame is used and *needed*. But I am not completely sure, so can someone confirm my assumption? Ladislav Lenart |
Re: Stack reification and JIT interaction question
|
|
In reply to this post by Reinout Heeck
Thanks. I will read it. This is the kind of references I was looking
for so I was not that wrong :) Stef On 19 janv. 07, at 11:41, Reinout Heeck wrote: > > See http://www.whysmalltalk.com/articles/fileone/ > context_management_vw.htm > > > R > - > > On Jan 19, 2007, at 11:25 AM, stéphane ducasse wrote: > >> Hi >> >> We have a deep discussion on execution stack reification and we >> want to know if there is >> a difference between the blue book and VW. >> >> Basically I wrote in a article that in Smalltalk the execution >> stack is causally connected and reified on demand. >> - causally connected because if I change the object that >> represents the stack the stack changes (as show >> by the example below) >> - reified on demand measn that the stack is not always a first >> class objects that >> I can access via message sends but only when thisContext is used >> or exceptions. >> >> Lukas told me that in Squeak this is always an object and that the >> blue book shows that too. >> >> So I wanted to know in VisualWorks in presence of a JIT if this is >> the case. >> My question basically is when a method is executed in the >> assembly, is it a smalltalk object, >> can we send it messages (I thought not). >> Is the stack reified only when using thisContext? >> >> Is this correct? >> >> Stef >> >> >> >> test 1 >> self test2. >> Transcript show: 'Called test2'; cr >> >> test2 >> self test3 >> Transcript show: 'Called test3' ;cr >> >> test3 >> thisContext sender: thisContext sender sender >> >> > > |
Re: Stack reification and JIT interaction question
|
|
Make sure you read the footnotes, some bluebook incompatibilities are
described there. R - On Jan 19, 2007, at 1:16 PM, stéphane ducasse wrote: > Thanks. I will read it. This is the kind of references I was > looking for so I was not that wrong :) > > Stef > > On 19 janv. 07, at 11:41, Reinout Heeck wrote: > >> >> See http://www.whysmalltalk.com/articles/fileone/ >> context_management_vw.htm >> >> >> R >> - >> >> On Jan 19, 2007, at 11:25 AM, stéphane ducasse wrote: >> >>> Hi >>> >>> We have a deep discussion on execution stack reification and we >>> want to know if there is >>> a difference between the blue book and VW. >>> >>> Basically I wrote in a article that in Smalltalk the execution >>> stack is causally connected and reified on demand. >>> - causally connected because if I change the object that >>> represents the stack the stack changes (as show >>> by the example below) >>> - reified on demand measn that the stack is not always a first >>> class objects that >>> I can access via message sends but only when thisContext is used >>> or exceptions. >>> >>> Lukas told me that in Squeak this is always an object and that >>> the blue book shows that too. >>> >>> So I wanted to know in VisualWorks in presence of a JIT if this >>> is the case. >>> My question basically is when a method is executed in the >>> assembly, is it a smalltalk object, >>> can we send it messages (I thought not). >>> Is the stack reified only when using thisContext? >>> >>> Is this correct? >>> >>> Stef >>> >>> >>> >>> test 1 >>> self test2. >>> Transcript show: 'Called test2'; cr >>> >>> test2 >>> self test3 >>> Transcript show: 'Called test3' ;cr >>> >>> test3 >>> thisContext sender: thisContext sender sender >>> >>> >> >> > > |
Re: Stack reification and JIT interaction question
|
|
In reply to this post by stéphane ducasse-2
Hi Stéphane,
Reinhout sent the relevant reference. But a more readable version is at http://wiki.cs.uiuc.edu/VisualWorks/DOWNLOAD/papers/oopsla99-contexts.pdf On 1/19/07, stéphane ducasse <[hidden email]> wrote: Hi is causally connected and reified on demand. Not in Smalltalk in general. Only (to my knowledge) BrouHaHa, PS & HPS (ParcPlace Smallalk-80, ObjectWorks & VisualWorks). e.g. in the Blue Book, Squeak, & current ObjectStudio contexts are created for all full method invocations. A la Blue Book, Squeak and ObjectStudio avoids creating contexts for primitive invocations (unless they fail) and for quick methods (returns of self or an inst var). Dolphin, VisualAge & SmalltalkAgents handle the stack differently. I can't talk to Smalltalk/X, Smalltalk-MT, Ambrai, FScript et al, but suspect thyat those that compiel to native code (e.g. Smalltalk/X, Smalltalk-MT don't provide thisContext) but I don't know for sure. - causally connected because if I change the object that represents Right. - reified on demand mean that the stack is not always a first class This point is why I've replied. Basically you can't tell. Its a hidden optimization. If you try and investigate the stack (which you can only do through thisContext) contexs get created invisibly as you traverse the context chain, and they are correctly connected, so that thisCOntxt sender points to the thisContext of the activation below, etc. So I think talking about the stack as first-class is misleading. You can't discover from within Smalltalk whether the stack exists or not. You can infer from performance, e.g. if you create a lot of processes so that a process switch would cause a stack segment flush/page" you'll notice context switch times are a lot slower. But there's nothing in thisContext that tells you whether its associated with a stack frame or residing on the heap. The VM is very careful to preserve this. Any inst var access of a context is handled by special code that computes the right value, the value that one would expect a heap context object to display for the context. Only internally is the VM able to distinguish between the three kinds of activation, volatile where the activation only exists as a stack frame, hybrid, where there's a stack frame and a thisContext, and stable, where there's only a context. So instead of stalkin abut a first-class stack, I'd say somethng like Contexts are first-class. The VM uses native stack frames whenever it can to defer creating contexts until absolutely necessary. The stack is an invisible optimization. You can stll do all the things you do with contexts in Squeak (cooutines, Seaside, Mark van Gulik's backtracking, etc, etc) but without the massive overhead of creating them fr every activation when they're needed very rarely. Let me add a few things on when reification happens. Reification doesn't need to happen for exceptions. To aoid reifying the system uses a primitive to search for unwind blocks (actually activations of marked methods, which include unwinds) without needing to reify. That's important for keeping laency low. Creating a block containing an ^-arrow return is probably the most common event that requires reification. The home context must be reified (become hybrid) to provide the block with a context it can rely on. Lukas told me that in Squeak this is always an object and that the But you can't tell. Unless you ask for thisContext how do you know an object got created. Its Schodinger's cat. It isn't important whether the cntext gets created or not, only that its there when you open the box. Its rather disappointing that Squeak is still not doing context-to-stack mapping as its a *huge* win. It avoids copying arguments from sender to receiver, it avoids creating a context object, it avoids needing to gc stack contents. Its probably worth a factor of two. So I wanted to know in VisualWorks in presence of a JIT if this is the case. The JIT makes it easier to perform the optimization cheaply. e.g. when fetching an inst var using a JIT means the question "is the receiver a context which requires special inst var access?" only gets asked at JIT-compile time, not on every inst var access. But one can do cntext-to-stack mapping wthout a JIT. e.g. read about my pre-threaded-code BrouHaHa VM: E. Miranda, "BrouHaHa - A Portable Smalltalk Interpreter", pp. 354-365, Proceedings of OOPSLA '87, vol. 22, no 12, SIGPLAN Notices, ACM, December 1987. (although that's a lot less radical than current VW). My question basically is when a method is executed in the assembly, Sort of. Execution is in machine code. There isnt any way to talk about the stack except through thisContext, so no, the stack isn't a Smalltalk object, but the thisContext of every method activation you care to ask _is_ an object. HTH But Stef, why are you having this deep discussion? Stef |
Re: Stack reification and JIT interaction question
|
|
Thanks eliot!
> Not in Smalltalk in general. Only (to my knowledge) BrouHaHa, PS & > HPS > (ParcPlace Smallalk-80, ObjectWorks & VisualWorks). e.g. in the > Blue Book, > Squeak, & current ObjectStudio contexts are created for all full > method invocations. > A la Blue Book, Squeak and ObjectStudio avoids creating contexts > for primitive > invocations (unless they fail) and for quick methods (returns of > self or an inst var). > > Dolphin, VisualAge & SmalltalkAgents handle the stack differently. > I can't talk > to Smalltalk/X, Smalltalk-MT, Ambrai, FScript et al, but suspect > thyat those that > compiel to native code (e.g. Smalltalk/X, Smalltalk-MT don't > provide thisContext) > but I don't know for sure. > > - causally connected because if I change the object that > represents > the stack the stack changes (as shown by the example below) > > > Right. > > - reified on demand mean that the stack is not always a > first class > objects that I can access via message sends but only when thisContext > is used or exceptions. > > > This point is why I've replied. Basically you can't tell. Its a > hidden optimization. > If you try and investigate the stack (which you can only do through > thisContext) > contexs get created invisibly as you traverse the context chain, > and they are > correctly connected, so that thisCOntxt sender points to the > thisContext of the > activation below, etc. So I think talking about the stack as first- > class is misleading. > You can't discover from within Smalltalk whether the stack exists > or not. You can infer > from performance, e.g. if you create a lot of processes so that a > process switch would > cause a stack segment flush/page" you'll notice context switch > times are a lot slower. > But there's nothing in thisContext that tells you whether its > associated with a stack > frame or residing on the heap. The VM is very careful to preserve > this. Any inst var > access of a context is handled by special code that computes the > right value, the value > that one would expect a heap context object to display for the > context. Only internally > is the VM able to distinguish between the three kinds of > activation, volatile where the > activation only exists as a stack frame, hybrid, where there's a > stack frame and a > thisContext, and stable, where there's only a context. > > So instead of stalkin abut a first-class stack, I'd say somethng like > Contexts are first-class. The VM uses native stack frames whenever > it can to defer > creating contexts until absolutely necessary. The stack is an > invisible optimization. > You can stll do all the things you do with contexts in Squeak > (cooutines, Seaside, > Mark van Gulik's backtracking, etc, etc) but without the massive > overhead of creating > them fr every activation when they're needed very rarely. This is really cool. So as I grew my Smalltalk with VW I never realized that the other did not have these behavior. > Let me add a few things on when reification happens. Reification > doesn't need to happen > for exceptions. To aoid reifying the system uses a primitive to > search for unwind blocks > (actually activations of marked methods, which include unwinds) > without needing to reify. > That's important for keeping laency low. Creating a block > containing an ^-arrow return is > probably the most common event that requires reification. The home > context must be > reified (become hybrid) to provide the block with a context it can > rely on. > > Lukas told me that in Squeak this is always an object and that the > blue book shows that too. > > > But you can't tell. Unless you ask for thisContext how do you know > an object got created. > Its Schodinger's cat. :) Indeed. > It isn't important whether the cntext gets created or not, only > that its > there when you open the box. Its rather disappointing that Squeak > is still not doing > context-to-stack mapping as its a *huge* win. It avoids copying > arguments from sender to > receiver, it avoids creating a context object, it avoids needing to > gc stack contents. Its probably > worth a factor of two. Lacks of money for that, I guess and may be also lack of experts. We should grow a community of new young cool smart guys there. > So I wanted to know in VisualWorks in presence of a JIT if this is > the case. > > The JIT makes it easier to perform the optimization cheaply. e.g. > when fetching an inst > var using a JIT means the question "is the receiver a context which > requires special inst > var access?" only gets asked at JIT-compile time, not on every inst > var access. But one > can do cntext-to-stack mapping wthout a JIT. e.g. read about my > pre-threaded-code > BrouHaHa VM: E. Miranda, "BrouHaHa - A Portable Smalltalk > Interpreter", pp. 354-365, > Proceedings of OOPSLA '87, vol. 22, no 12, SIGPLAN Notices, ACM, > December 1987. > (although that's a lot less radical than current VW). > > > My question basically is when a method is executed in the assembly, > is it a smalltalk object, can we send it messages (I thought not). > Is the stack reified only when using thisContext? > > Is this correct? > > > Sort of. Execution is in machine code. There isnt any way to talk > about the stack except > through thisContext, so no, the stack isn't a Smalltalk object, but > the thisContext of > every method activation you care to ask _is_ an object. Thanks from my far away view on the problem this is enough :) > HTH > > > But Stef, why are you having this deep discussion? We are writing a paper on seaside and we wanted to say that the fact that we can from within the language manipulate the stack in a causal but optimized way is good. You get the power and the flexibility. So I wrote "Causally connected on demand stack reification" and lukas a Squeaker told me that on demand was strange so we went deep :) So really thanks, I like Smalltalk because there are so much stuff I would like to learn that I hope to stay and have a lot of fun with it for again a long time. Stef happy to learn Smalltalker |
Re: Stack reification and JIT interaction question
|
|
In reply to this post by Eliot Miranda-2
Eliot Miranda wrote:
> You can't discover from within Smalltalk whether the stack exists or > not. I recall this design principle being referred to as "It's OK to cheat, just don't get caught." I'm impressed at how thoroughly uncatchable this cheating is. I've tried to detect it using things like "MethodContext allInstances" and "ObjectMemory allObjects", and even those primitives seem to maintain the illusion. Regards, -Martin |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |