Re: [Gc] How to do enable gc of prolog programs using bdw-gc

Cool.

If you can get it working both ways, and a smallish patch to the gc can
make it a lot faster than using disappearing links then you should share
that with the list.


On Fri, May 9, 2014 at 12:00 AM, Stefan Israelsson Tampe <
[email protected]> wrote:

> Err, I think you are right. I might get it to work with dissapering links.
> It will be a bit more costly to do because I can't recycle the logical
> variables, but that feature will be for the brave.
>
> Thanks!
>
>
> On Thu, May 8, 2014 at 1:52 PM, Stefan Israelsson Tampe <
> [email protected]> wrote:
>
>> Sure it's the job of the gc, but the bdw-gc are not tuned for logic
>> programs. That's the reason.you just simply need to implement som gc code
>> yourself or your smoked. Its minsucle code needed to be added to bdw-gc, to
>> actually get the needed features to do this, that's pretty cool. But I
>> don't think we can solve this with dissapearing links.
>>
>> /Stefan
>>
>>
>> On Thu, May 8, 2014 at 11:50 AM, Bruce Hoult <[email protected]> wrote:
>>
>>> Why do you need to indicate when they can't be reached from normal code?
>>> That's EXACTLY the job the GC does for you.
>>>
>>> If you need to refer to them from somewhere else, but not prevent them
>>> being GCd, then you use a "disappearing link". That's a pointer that the GC
>>> automatically sets to null when the object is collected.
>>>
>>>
>>> On Thu, May 8, 2014 at 9:28 PM, Stefan Israelsson Tampe <
>>> [email protected]> wrote:
>>>
>>>> Yep, this looks like using finaliser is not suitable to model gc of
>>>> logical variables.
>>>>
>>>> The interesting with this application is:
>>>> ==============================
>>>> Logical variables need to backtrack:
>>>> They are the located on a datastructure
>>>> They needed to be available when on the list hence protect from gc
>>>> One need to indicate when they are not reaced from normal code e.g.
>>>> ready for gc.
>>>> Then one carefully need to clean the information off the datstructure
>>>> and compress it.
>>>> Then normal gc can be done of th elogical variables (or they can be
>>>> recycled)
>>>>
>>>> So currently bdw-gc cannot support gc of logical variables. I have a
>>>> patch for it to do so, but it's not anything sanctioned.
>>>>
>>>> Cheers
>>>>
>>>>
>>>> On Thu, May 8, 2014 at 12:57 AM, Bruce Hoult <[email protected]> wrote:
>>>>
>>>>> On Thu, May 8, 2014 at 7:31 AM, Stefan Israelsson Tampe <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Wingo or anyone else. In a finalizer, if the object should not be
>>>>>> gc'ed what do I need to do? just leave it?
>>>>>> and in the case when it should be gc'ed what do I do scm_gc_free?
>>>>>>
>>>>>
>>>>> If an object should not be gc'd then how did you get into the
>>>>> finalizer for it?
>>>>>
>>>>>  In bdwgc objects with finalizers are not actually collected or
>>>>> overwritten until the GC after the GC in which the finalizer is run.
>>>>> Therefore, technically, the finalizer can prevent the object from being
>>>>> collected by putting a pointer to the object into a global or another
>>>>> gc'able object.
>>>>>
>>>>> But if you still wanted the object then why didn't you already have a
>>>>> reference to it somewhere? If there is no reference to it then it can't
>>>>> take any further part in the computation. Unless maybe you have a reference
>>>>> to it from somewhere the GC doesn't look, such as an object allocated using
>>>>> malloc instead of GC_malloc.
>>>>>
>>>>> I've never seen a situation in which resurrection-by-finalizer was the
>>>>> best solution. I'd be curious to see one. And, remember that by the time
>>>>> the finalizer is run the finalizer has been de-registered, so the
>>>>> resurrected object no longer has a finalizer.
>>>>>
>>>>> In general, very very few objects should have finalizers. Typically
>>>>> the reason is that you need to release some external, non-gc'd resource
>>>>> e.g. close a file or delete an object allocated using some foreign API from
>>>>> a library. Things like that.
>>>>>
>>>>>
>>>>
>>>> --
>>>> This message has been scanned for viruses and
>>>> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and
>>>> is
>>>> believed to be clean.
>>>>
>>>
>>>
>>
>
> --
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>

_______________________________________________
bdwgc mailing list
[email protected]
https://lists.opendylan.org/mailman/listinfo/bdwgc