"Steve Wampler" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi Frank,
>
> I finally got time to read your entire original post. I think
> your analysis of the situation is spot on, and a good explanation
> of the 'memory-leak' that can arise from co-expressions.
>
> Although I commented on the variable() function, it's my
> general feeling that its ability to access 'hidden' dynamic
> variables from within a co-expression is entirely an
> artifact of how co-expressions are currently implemented
> and *not* a language feature. There is no requirement
> that such access must exist, and I'd be willing to bet that
> no one has every made use of this feature from within
> a co-expression [and they shouldn't, since it's solely
> an implementation artifact!].
>
> So, I'm all for an experimental re-implementation of
> co-expressions where unreferenced dynamic variables are
> set to &null. If that looks good, and solves the
> memory leak problem (which I expect it will), then perhaps
> a revisit to further clean up the implementation would be
> in order.
Although a fix would certainly be desirable, it seems that it would require
a change to the Icon virtual machine. Aside from the moritbund native code
compiler and Jcon, Icon and Unicon are based on a high-level virtual
machine. The *.u* files generated by the Icon translator contains assembly
instructions for the virtual machine.
The virtual machine instruction
create Lx
creates a co-expression, using the code at label Lx as the start of the
expression, and push this new co-expression on the top of the stack.
Basically, the virtual machine code for the Icon expression
create Some_Expression
looks like this:
goto L2
lab L1
...
(Code for Some-Express)
...
lab L2
create L1
The problem with this scheme is that this scheme does not indicate which
dynamic variables are actually referenced in the co-expression. This
information is not an input to the "create" virtual instruction, so the
virtual machine cannot distinguish between the referenced and un-referenced
dynamic variables.
A way to fix this would be to add a new virtual machine instruction to allow
this distinction be made. This new interuction would have the form
covar n
Executing this instruction would mark local variable n as one that is
referenced in the next co-expression that is created. Assume that
Some_Expression does references local variable 2 and 3. Then with this new
instruction, the virtual machine code for the Icon expression
create Some_Expression
would look like this:
goto L2
lab L1
...
(Code for Some-Express)
...
lab L2
covar 2
covar 3
create L1
This would permit the virtual machine to distinguish between referenced and
unreferenced dynamic variables.
Of all the changes I've done with Icon, I have never experimented with
changing the virtual machine. Does anyone in the NG / mailing list have
experience in this area? What pitfalls should I watch out for?
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
