Implementing TCL/CCI commands

[Natraj]

I'm trying to implement CCI ( common command interface ) using collections as in Synposis TCL-EDA suite ( http://www.eda.org/edps/edp04/submissions/presentationDwight2.pdf)

I'm not able to think of proper memory management while using CCI ,
let me give an example

## sizeof_collection will return the collection size ( integer )
dc_shell> sizeof_collection [get_cells reset_port*]
4

## get_cells will return a pointer to a collection , actually it is an index of a collection list
dc_shell> get_cells reset_port*
0x10

## below command will give error as CCI engine has free'd up memory ( no references pointing to collection )
dc_shell>sizeof_collection 0x10
TCL ERROR

## now set the collection to a variable , collection pointer increments by one .
dc_shell> set a [get_cells reset_port*]
0x11

## Now the sizeof_collection returns correct value , i.e collection is still in memory
dc_shell> sizeof_collection $a
4
dc_shell>puts $a
0x11

## Even in this case sizeof_collection returns the correct value , as it has reference ( pointed by variable "a" )
dc_shell > sizeof_collection 0x11
4

### Clear reference pointer
dc_shell > set a ""

## Now we will get error , as the reference from a has been removed !!
dc_shell > sizeof_collection 0x11
TCL ERROR

Can you tell me know to keep track of TCL_Object and
free resources when there are no references pointing to them .

and I'm using TCL-Java where garbage collection is been done by Java.GC
this is another headache !

Regards
Nataraja G

[Tom Poindexter]

I know nothing about this interface in particular, but I'll assume that it
either uses TclBlend or Jacl (or even the newer JTcl) for Java interaction.

Basically, as long as you keep a reference to a Java object in a variable, that
object can be referenced and won't be garbage collected. From your example:

>## now set the collection to a variable , collection pointer increments by one .
>dc_shell> set a [get_cells reset_port*]
>0x11

The variable "a" contains the reference. When you later:

>### Clear reference pointer
>dc_shell > set a ""

the reference is gone, even if you try to use the object pointer value "0x11".

For more information on the TclJava interfaces, see:
http://tcljava.sourceforge.net/docs/TclJava/contents.html

especially these:
http://tcljava.sourceforge.net/docs/TclJava/JavaGC.html
and
http://tcljava.sourceforge.net/docs/TclJava/JavaRefCount.html


-Tom

Tom Poindexter
tpoi...@nyx.net

[Natraj]

Hi Tom ,
Here I'm trying to implement collections by default
we don't have this type of interface in TCL or TCLJava .

>>### Clear reference pointer
>>dc_shell > set a ""
>
>the reference is gone, even if you try to use the object pointer value >"0x11".

I've to handle this , let us take an example

Backend I'm implementing collections like below

// Golbal Variable
hashMap<String,ArrayList<objects> collectionList ;
ArrayList<my_objects> collectionObjects;
collectionObjects = new ArrayList<my_objects>() ;
collectionList.put(0x11,collectionObjects);

#when set a "" is called I've to remove this pair or
#when varaible 'a' is set to different collection .
collectionList.delete(0x11);

and then "collectionObjects" will be GC ,
my problem is how to trace this and make it happen :(


CCI interface is used an DB handle , when user queries big data sets
directly displaying them on console or if this list is passed to another command will make the entire application slow
instead we will pass a string and internally maintain DB Array which can be used of other CCI command to extend queries .


Thanks
Nataraja G

On Monday, 1 December 2014 04:43:05 UTC+5:30, tpoi...@gmail.com wrote:
> I know nothing about this interface in particular, but I'll assume that it
> either uses TclBlend or Jacl (or even the newer JTcl) for Java interaction.
>
> Basically, as long as you keep a reference to a Java object in a variable, that
> object can be referenced and won't be garbage collected. From your example:
>
> >## now set the collection to a variable , collection pointer increments by one .
> >dc_shell> set a [get_cells reset_port*]
> >0x11
>
> The variable "a" contains the reference. When you later:
>
> >### Clear reference pointer
> >dc_shell > set a ""
>
> the reference is gone, even if you try to use the object pointer value "0x11".
>
> For more information on the TclJava interfaces, see:
> http://tcljava.sourceforge.net/docs/TclJava/contents.html
>
> especially these:
> http://tcljava.sourceforge.net/docs/TclJava/JavaGC.html
> and
> http://tcljava.sourceforge.net/docs/TclJava/JavaRefCount.html
>
>
> -Tom
>
>
>
>

[Tom Poindexter]

Natraj <nataraj...@gmail.com> writes:


>and then "collectionObjects" will be GC ,
>my problem is how to trace this and make it happen :(

Sounds like you just need to use the Tcl 'trace' command.

http://www.tcl.tk/man/tcl8.6/TclCmd/trace.htm

There are example on the wiki:
http://wiki.tcl.tk/_/search?S=trace&_charset_=UTF-8
Tom Poindexter
tpoi...@nyx.net

[natar...@gmail.com]

Hi Tom ,
Thanks for pointing 'trace' .

The below example is simple enough , once variable associated with a collection is updated/written , we can delete it :)

%set a [get_ports rest*]
%trace add variable a write "unset_collection a"

Now I see somemore problems !

1) how can we know to which variable this collection is being set
( we need to bind this variable in trace command )
may be we have to peek on command stack and get the context of future command ??

2) another scenario would be nested commands ,
I have no clue on how to get around this

% get_pins [get_cells mydb*]

scope of get_cells returned collection will die as soon as get_pins completes its execution .

I'll continue to do research on these things ,
Please share any ideas that I can implement ...

Thanks once again .

[Andreas Leitgeb]

Hello back, from the other thread at c.l.j.p :-)

natar...@gmail.com <natar...@gmail.com> wrote:
> Thanks for pointing 'trace' .
> The below example is simple enough , once variable associated
> with a collection is updated/written , we can delete it :)
> %set a [get_ports rest*]
> %trace add variable a write "unset_collection a"
> Now I see somemore problems !
> 1) how can we know to which variable this collection is being set

> 2) another scenario would be nested commands ,
> I have no clue on how to get around this

Not to forget, that traces fire *after* the write, and by that time
you might no longer know which collection to set free. The trace
handler would need to be a bit smarter: e.g. define "_a" as backstore
of "a", and first check if $_a equals $a (then: no-op), otherwise see
if "_a" was filled (then set it free), finally fill "_a" from "a",
which already has new value.

As for setting up the traces, you'd define a procedure "setLTM" which
will check if the variable already has such a trace and if not, then
set up the trace. Usage:
% setLTM a ;# initialize variable for LTM (LifeTimeManagement)
% set a [get_ports rest*] ;# now traces do the rest.
% # unsetLTM a ;# remove traces, after cleaning up current ref.

Then object's lifetime is tied to that one variable. It could then
also be tied to another LTM'ed variable, but then it would be freed
already when *any* of the vars is overwritten, not just after *all*
are.

If that was not acceptable, then it is easy to change the traces such,
that they will use an tcl-side ref-counting mechanism to decide
what objects really are used by no LTM'ed variable anymore. References
in non-LTM'ed variables would correspond to Java's "WeakPointer".
That would bring you:
% setLTM a ;# initialize variable for LTM (LifeTimeManagement)
% set a [get_ports rest*] ;# now traces do the rest.
% setLTM b
% set b $a
% set a "" ;# object not freed, because ref-count still 1
% set b "" ;# now freed.
That's however still unsafe against looping reference chains.

What part of the plot actually generates the id's (like 0x11)
to represent the real entities? Is this on Java side, or part
of the Tcl/CCI adaption?

Will you need to implement the Tcl-versions of "get_ports",etc.,
or just use these commands and thereby take care that a ref doesn't
accidentally disappear too soon ?

PS: What are your levels in each of Tcl, Java and CCI ?

[Natraj]

Hi Andreas ,
I'm thinking about your two solutions about traces , correct me if I got it wrongly .

Sol1 ) instead of a & _a , we can define static procedures for each collection
and remove them from memory after the collection is delete ,
ofcourse it has some draw-backs but still I'll have POC .

# collection_id will be the value of 'a'
%eval "proc ::collection_scope::unset_collection_$collection_Id { unset_collection $collection_id ; rename ::collection_scope::unset_collection_$collection_Id \"\" }
%trace add variable a write "::collection_scope::unset_collection_$collection_Id "


Sol2 )

% setLTM a ;# initialize variable for LTM (LifeTimeManagement)
% set a [get_ports rest*] ;# now traces do the rest.
% # unsetLTM a ;# remove traces, after cleaning up current ref.

"setLTM a" ;# can be done in background if we know to which variable the collection is being set
I cannot use setLTM /unsetLTM because this will be burden on end-users as they have to declare CCI variables upfront .

Both the solutions trace back to my previous question , can we do this using upvar/proc level ?

>>> 1) how can we know to which variable the collection is being set

>>> ( we need to bind this variable in trace command )

>>> may be we have to peek on command stack and get the context of future ////command ??

>>> What part of the plot actually generates the id's (like 0x11)
to represent the real entities? Is this on Java side, or part
of the Tcl/CCI adaption?

actually all CCI commands just return hex decimal strings and each time the HEX value increases by one
I don't know the actual implementation as this is not open source , I'm assuming this is maintained as a Map and life-time tie to variables .

>>> Will you need to implement the Tcl-versions of "get_ports",etc.,
or just use these commands and thereby take care that a ref doesn't
accidentally disappear too soon ?

Yes I've to implement Java Versions (Jtcl) of
get_ports/get_pins/foreach_in_collection/indexof_collection/sizeof_collection/get_cells and more ....
I'm having problems in deciding LTM .

>>> PS: What are your levels in each of Tcl, Java and CCI ?

CCI is not OpenSource , hence I don't know anything about CCI API .
I just know how they have to behave :) and I'm trying to mimic this .

At frondend/App level I'm a pro when it comes to Tcl/Tk & Java
currently learning how TCL is implemented in backend for TCL/C & TCl/Java .

Thanks
Nataraja G

[Natraj]

Atlast we have solved it .
provided hooks to TclObject and left disposing to TclInterpreter only .

if (--refCount <= 0) {
if ( is_collection ) {
System.out.println("disposing collection " + this.stringRep);
collectionMap.delete(this.stringRep);
}
disposeObject();
}

Screenshot :
https://www.dropbox.com/s/g1f4i2cfwq51p7u/GoogleGroups.png?dl=0
once the variable 'b' is over-written by a new collection , older collection is disposed :) , this sums up everything .

This is a part of my EDA Tool interface
http://edatools.blogspot.in/

Regards
Nataraja G