Hi I have the following 3 questions: 1. Why there is ContextPart>>releaseTo: ? What will happen if I don't use it? 2. Is there a bytecode editor for Squeak? 3. Are there any issues concerning bytecode editing, contexts, closures and compiled methods I should be aware of, which may break the image/create uncollectable garbage?
Mateusz Grotek pisze:
Hi I have the following 3 questions:
- Why there is ContextPart>>releaseTo: ? What will happen if I don't
use it? 2. Is there a bytecode editor for Squeak? 3. Are there any issues concerning bytecode editing, contexts, closures and compiled methods I should be aware of, which may break the image/create uncollectable garbage?
Anyone? The first question is the most important to me. Thank you!
On 12-08-03 2:30 PM, Mateusz Grotek wrote:
Mateusz Grotek pisze:
Hi I have the following 3 questions:
- Why there is ContextPart>>releaseTo: ? What will happen if I don't
use it? 2. Is there a bytecode editor for Squeak? 3. Are there any issues concerning bytecode editing, contexts, closures and compiled methods I should be aware of, which may break the image/create uncollectable garbage?
Anyone? The first question is the most important to me. Thank you!
http://lists.squeakfoundation.org/mailman/listinfo/beginners
I think you are on the wrong list. Try the beginners' list. / /As for the first question, why don't you just delete it and see what happens?
Chris
http://lists.squeakfoundation.org/mailman/listinfo/beginners
I think you are on the wrong list. Try the beginners' list. / /As for the first question, why don't you just delete it and see what happens?
Chris
I thought these questions are a bit too advanced for the beginners list. But I can move the discussion to that list if needed.
On 04.08.2012, at 00:41, Mateusz Grotek wrote:
I think you are on the wrong list. Try the beginners' list.
I thought these questions are a bit too advanced for the beginners list. But I can move the discussion to that list if needed.
No, you were right, these are questions on-topic for squeak-dev.
[meta remark] However, the non-descript subject makes it look like a beginner's question - better use a subject that describes what your message is about. In this case, two separate messages with subjects like "ContextPart>>releaseTo:" and "Bytecode manipulation" would have been much nicer.
- Bert -
On Sun, Jul 29, 2012 at 7:56 AM, Mateusz Grotek unoduetre@poczta.onet.plwrote:
Hi I have the following 3 questions:
- Why there is ContextPart>>releaseTo: ? What will happen if I don't
use it?
releaseTo: simulates the effect of doing a method return from a block, i.e. when a return exits more than the top context. It sends singleRelease to each context exited, which sets the pc and sender to nil (and nils the stack, but this is excess to requirements). releaseTo: is actually used when a method return from a block encounters an unwind-protect and control passes up to the image to run the unwind. You don't need to use it. It is used automatically as part of running unwinds. In what situation do you think you do need to use it?
2. Is there a bytecode editor for Squeak?
See Marcus Denker's Opal compiler. This contains an assembler.
- Are there any issues concerning bytecode editing, contexts, closures
and compiled methods I should be aware of, which may break the image/create uncollectable garbage?
Invalid methods can easily crash the image, so one has to be careful to create valid methods. Both the Interpreter, and especially Cog, cache information related to methods to optimize execution. One must be careful to flush the VM caches appropriately when changing methods that are in use.
Eliot Miranda pisze:
On Sun, Jul 29, 2012 at 7:56 AM, Mateusz Grotek unoduetre@poczta.onet.plwrote:
Hi I have the following 3 questions:
- Why there is ContextPart>>releaseTo: ? What will happen if I don't
use it?
releaseTo: simulates the effect of doing a method return from a block, i.e. when a return exits more than the top context. It sends singleRelease to each context exited, which sets the pc and sender to nil (and nils the stack, but this is excess to requirements). releaseTo: is actually used when a method return from a block encounters an unwind-protect and control passes up to the image to run the unwind. You don't need to use it. It is used automatically as part of running unwinds. In what situation do you think you do need to use it?
I'm trying to implement backtracking as described in the paper: "Building a backtracking facility in Smalltalk without kernel support" by W. LaLonde and M. Van Gulik
They commented their use of releaseTo: in this way:
"aContext releaseTo: oldContext Release (by setting the temporaries in the context stack to nil) all contexts from the receiver, its sender, its sender's sender etc. up to but excluding oldContext. It is a superflous method that helps the garbage collector."
I wondered if this is an artifact of the version of Smalltalk they used when writing the paper, or it really helps the garbage collector in some way. As far as I understand it contexts are collected just like normal objects, when there are no references to them. So i don't see a point in using this method, but I'm not an expert and maybe i miss something, so I asked this question.
Thank you for the anwer.
On 4 August 2012 08:51, Mateusz Grotek unoduetre@poczta.onet.pl wrote:
Eliot Miranda pisze:
On Sun, Jul 29, 2012 at 7:56 AM, Mateusz Grotek unoduetre@poczta.onet.plwrote:
Hi I have the following 3 questions:
- Why there is ContextPart>>releaseTo: ? What will happen if I don't
use it?
releaseTo: simulates the effect of doing a method return from a block, i.e. when a return exits more than the top context. It sends singleRelease to each context exited, which sets the pc and sender to nil (and nils the stack, but this is excess to requirements). releaseTo: is actually used when a method return from a block encounters an unwind-protect and control passes up to the image to run the unwind. You don't need to use it. It is used automatically as part of running unwinds. In what situation do you think you do need to use it?
I'm trying to implement backtracking as described in the paper: "Building a backtracking facility in Smalltalk without kernel support" by W. LaLonde and M. Van Gulik
They commented their use of releaseTo: in this way:
"aContext releaseTo: oldContext Release (by setting the temporaries in the context stack to nil) all contexts from the receiver, its sender, its sender's sender etc. up to but excluding oldContext. It is a superflous method that helps the garbage collector."
I wondered if this is an artifact of the version of Smalltalk they used when writing the paper, or it really helps the garbage collector in some way. As far as I understand it contexts are collected just like normal objects, when there are no references to them. So i don't see a point in using this method, but I'm not an expert and maybe i miss something, so I asked this question.
You might be interested in a little library I wrote for delimited continuations (which is what LaLonde/Van Gulik are effectively implementing): http://ss3.gemstone.com/ss/Control.html. If I recall correctly, Chung-chieh Shan's "Shift to Control" paper shows backtracking implemented via success and failure continuations, just like in LaLonde/Gulik.
frank
Thank you for the anwer.
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Chris Cunnington -
Eliot Miranda -
Frank Shearar -
Mateusz Grotek