Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: Implementing lisp in Forth. Chapter 4. Date: Fri, 09 Sep 2016 13:06:00 -0700 Organization: A noiseless patient Spider Lines: 60 Message-ID: <87poockfdj.fsf@jester.gateway.pace.com> References: <87fupfo6xl.fsf@jester.gateway.pace.com> <87twdpj6uo.fsf@jester.gateway.pace.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="590ea01354cf4bcbcd857d7ebbd88128"; logging-data="7645"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18TDmFknr07PVdz9CcBNHsF" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:C/8dmMUGSICwzukKURNjZjdmk68= sha1:Sxtq1hlU1sXwX+wqPtKHegDT8xg= Xref: csiph.com comp.lang.forth:50787 albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) writes: >>2. Add a gc.fs-style conservative gc to ALLOCATE. > My marking of the pieces in use will be exact, so it is not a > conservative gc. That complicates things somewhat but you get the benefit of an exact gc, so fine. I think Guile uses conservative gc partly to make writing C extensions easier: they don't have to think about making sure intermediate values are marked or how to mark any Lisp pointer that might appear in a C structure, etc. But requiring gc-aware extensions isn't unbearable. > Then I've not given up on the idea to just free things here and there > which would work well with my allocator. Well, it's a cost (complexity) vs benefit (speed-up) trade-off unless you're worried about the gc missing stuff. > In particular there will be no fragmentation issues. Why is it that > I don't here about fragmentation in this context (of lisp) With a conservative gc you can't prevent fragmentation. The simplest and most traditional exact gc (straightforward mark and sweep) doesn't prevent fragmentation either. Emacs has used non-compacting (except for strings) mark/sweep for the past 30 years unless they changed it, and it hasn't been a significant problem afaik. If you want to defragment, the basic approaches are mark-and-compact, or stop-and-copy. Both of them relocating objects, which means any pointers to those objects have to be updated. Within those approaches there are generational schemes that can improve performance a lot. Hedgehog Lisp (https://github.com/sbp/hedgehog) has a simple 2-generation copying gc that you might examine. There are some other methods like having separate pages for each type of fixed-size object ("BIBOP", BIg Bag Of Pages) that I think have fallen into disuse. In my experience, if you have a reasonable amount of memory, gc performance isn't a big issue unless you've got a backend that generates native machine code. Otherwise your interpreter will spend most of its time running user code rather than gc. Here's a nice page about the Factor gc that I just happened to look at: http://factor-language.blogspot.com/2009/11/mark-compact-garbage-collection-for.html Factor uses a mark-compact scheme inspired by Clojure, that's also described in the 2011 Jones et al book that's been mentioned here a few times. > I'm referring to a trivial extension to Forth: if the search fails > and it is not a number, you've the option to execute some word. I think you want to be able to call a user word even if the search doesn't fail, or it's a number. E.g. you may have to treat Lisp numbers differently than Forth numbers. >>Not sure what you mean: an existing Lisp in C? > Indeed. Also about 1000 lines Which one is that, if I can ask? Is it online?