[Edbrowse-dev] window root

[Karl Dahlke <eklhad@comcast.net>]

> For example the JS_ValueToString function explicitly says
> that you should protect its return value with a GC root or the string is
> at risk of garbage collection at any stage.

Well edbrowse is not multithreaded.
Within the one and only thread, I immediately make that js value
a property in some other object; I immediately link it to the window tree.
That's why I made it a js string in the first place.
Thus it is referenced.
I keep thinking there should be no trouble.

> Theoretically most of our objects should be protected from GC

Theoretically all of our objects should be protected from GC, unless I did something wrong.

> Admittedly some of this rooting may be paranoia,

And that's ok, I guess, unless we are setting up excess reference counts,
and those objects never go away, even when they aren't used any more,
because the reference count never drops to 0,
and edbrowse has memory leaks.
People like me really are in edbrowse for hours at a time.
So I'm not sure we should swing the big hammer and root everything.
At an intellectual level I'd like to know why everything isn't
already rooted to jswin.

Of course you're doing all the work, not me,
and if rooting everything will get us off the ground,
and get rid of seg faults,
then we can watch for and fix memory leaks later.
I do understand that sometimes you just have to move forward.

Karl Dahlke