One of the higher systems on the list of Quicklisp downloads is the trivial-garbage system (http://www.cliki.net/trivial-garbage).
One of the things this package does is to provide 'normalized' access to object finalization functionality. I thought I'd quickly add that support (and did so in r13248). However, it seems our bootstrap compilation has now slowed down to a crawl.
So, I'm ready to revert the commit and reopen the ticket I had opened to track progress. However, are you seeing the same? Do you have any good alternatives? I'd love some discussion on this subject: supporting Quicklisp downloaded packages looks like a good way to promote ourselves.
Bye,
Erik.
On 13 March 2011 01:33, Erik Huelsmann ehuels@gmail.com wrote:
One of the higher systems on the list of Quicklisp downloads is the trivial-garbage system (http://www.cliki.net/trivial-garbage). One of the things this package does is to provide 'normalized' access to object finalization functionality. I thought I'd quickly add that support (and did so in r13248). However, it seems our bootstrap compilation has now slowed down to a crawl. So, I'm ready to revert the commit and reopen the ticket I had opened to track progress. However, are you seeing the same? Do you have any good alternatives? I'd love some discussion on this subject: supporting Quicklisp downloaded packages looks like a good way to promote ourselves.
It's not just a slowdown problem:
[java] Exception in thread "interpreter" java.lang.OutOfMemoryError: GC overhead limit exceeded [java] at java.lang.ref.Finalizer.register(Finalizer.java:72) [java] at java.lang.Object.<init>(Object.java:20) [java] at org.armedbear.lisp.LispObject.<init>(LispObject.java:39)
The build fails for me, with the culprit apparently being the finalizer stuff. It would perhaps be an idea worthy of investigating to not burden every LispObject with that support, but rather try and do it as an opt-in somehow.
In r13250, I committed a different approach which uses a collection thread (started as late as the first call to EXT:FINALIZE).
Bye,
Erik.
On Sun, Mar 13, 2011 at 12:54 AM, Ville Voutilainen ville.voutilainen@gmail.com wrote:
On 13 March 2011 01:33, Erik Huelsmann ehuels@gmail.com wrote:
One of the higher systems on the list of Quicklisp downloads is the trivial-garbage system (http://www.cliki.net/trivial-garbage). One of the things this package does is to provide 'normalized' access to object finalization functionality. I thought I'd quickly add that support (and did so in r13248). However, it seems our bootstrap compilation has now slowed down to a crawl. So, I'm ready to revert the commit and reopen the ticket I had opened to track progress. However, are you seeing the same? Do you have any good alternatives? I'd love some discussion on this subject: supporting Quicklisp downloaded packages looks like a good way to promote ourselves.
It's not just a slowdown problem:
[java] Exception in thread "interpreter" java.lang.OutOfMemoryError: GC overhead limit exceeded [java] at java.lang.ref.Finalizer.register(Finalizer.java:72) [java] at java.lang.Object.<init>(Object.java:20) [java] at org.armedbear.lisp.LispObject.<init>(LispObject.java:39)
The build fails for me, with the culprit apparently being the finalizer stuff. It would perhaps be an idea worthy of investigating to not burden every LispObject with that support, but rather try and do it as an opt-in somehow.
armedbear-devel@common-lisp.net
-
Erik Huelsmann -
Ville Voutilainen