Low prio feature request: GC:able symbols, perhaps via a separate configure option --enable-gc:able-symbols
Hi!
For a lower prio than SMP feature request I wish to suggest GC:able symbols.
This would be of use to enable processing of symbols from unsafe or otherwise unknown sources such as frequently is the case in SXML and many other more or less standardized formats.
Currently in such use the Gambit process tends to be susceptible to heap overflow possibility/attacks unless there's additional complexity in the form of separate marshalling code that limits symbol import to a pre-specified set only.
Very secondarily, an extreme variant of such "unsafe formats" would be some forms of untrusted or otherwise unknown code - for running any form of untrusted code in Gambit, symbols being GC:able would be a key enabler as they'd save the untrusted code handling mechanism of the need to implement symbols<->uninterned symbol conversion in a copying proxy on start and on any passing of values between trusted and untrusted code, and also save of any weird complexity such a proxy would impose on object reference equality, cyclical references support etc.
I completely understand that probably the default non-GC:ing quality of symbols is extremely well motivated for minimalism or technical reasons, however wanted to suggest this due to the huge practical use and unifying quality this feature would bring, then as a separate configurable option I guess.
If anyone has any thought on this topic feel free to share,
Best regards, Mikael
Afficher les réponses par date
Ah, for clarity, by "GC:able symbols" I mean that ordinary symbols garbage collect i.e. that
(let loop () (let ((s (string-append "my-new-symbol-" (number->string (random-integer #x100000000))))) (string->symbol s) (read (open-input-string s)) (eval `(let ,(string->symbol s) () (void))) (loop)))
leads to no heap growth rather than infinite heap growth.
2013/9/25 Mikael mikael.rcv@gmail.com
Hi!
For a lower prio than SMP feature request I wish to suggest GC:able symbols.
This would be of use to enable processing of symbols from unsafe or otherwise unknown sources such as frequently is the case in SXML and many other more or less standardized formats.
Currently in such use the Gambit process tends to be susceptible to heap overflow possibility/attacks unless there's additional complexity in the form of separate marshalling code that limits symbol import to a pre-specified set only.
Very secondarily, an extreme variant of such "unsafe formats" would be some forms of untrusted or otherwise unknown code - for running any form of untrusted code in Gambit, symbols being GC:able would be a key enabler as they'd save the untrusted code handling mechanism of the need to implement symbols<->uninterned symbol conversion in a copying proxy on start and on any passing of values between trusted and untrusted code, and also save of any weird complexity such a proxy would impose on object reference equality, cyclical references support etc.
I completely understand that probably the default non-GC:ing quality of symbols is extremely well motivated for minimalism or technical reasons, however wanted to suggest this due to the huge practical use and unifying quality this feature would bring, then as a separate configurable option I guess.
If anyone has any thought on this topic feel free to share,
Best regards, Mikael
Hum, I might have completely misunderstood many things, from what you wrote to how symbols work, but what if I have a symbol stored as a weak reference in a table, and it gets garbage collected. If I later re-read this symbol from the network, then I won't find it in the table, will I? But wasn't I guaranteed I'd find it *because* it's a symbol and thus the table should still be containing an element EQ to the one I just got from the network?
P!
Ordinary symbols are special in that they are the only values created by Scheme code on runtime that are not garbage collected currently.
(The other ones would be any compiled code you load and ___PERM objects you allocate in C.)
Compare:
(define t (make-table weak-keys: #t weak-values: #t)) (table-set! t (string->symbol "abc") (string->symbol "def")) (table-set! t "ghi" "jkl") (table-set! t (make-uninterned-symbol "mno") (make-uninterned-symbol
"pqr"))
(##gc) (##gc) (##gc)
(table->list t)
((abc . def))
2013/9/25 Adrien Piérard pierarda@iro.umontreal.ca
Hum, I might have completely misunderstood many things, from what you wrote to how symbols work, but what if I have a symbol stored as a weak reference in a table, and it gets garbage collected. If I later re-read this symbol from the network, then I won't find it in the table, will I? But wasn't I guaranteed I'd find it *because* it's a symbol and thus the table should still be containing an element EQ to the one I just got from the network?
P!
More complete example:
(define t (make-table weak-keys: #t weak-values: #t)) (table-set! t (string->symbol "abc") (string->symbol "def")) (table-set! t "ghi" "jkl") (table-set! t (make-uninterned-symbol "mno") (make-uninterned-symbol
"pqr"))
(table-set! t 'st 'uv) (table-set! t (read (open-input-string "w")) (read (open-input-string
"x")))
(##gc) (##gc) (##gc)
(table->list t)
((st . uv) (w . x) (abc . def))
(Note that if you compile this code and load it, the "ghi" and "jkl" strings will not GC too as they're now part of the compiled code, which does not GC. Eval:ed code GC:s.)
2013/9/25 Mikael mikael.rcv@gmail.com
Ordinary symbols are special in that they are the only values created by Scheme code on runtime that are not garbage collected currently.
(The other ones would be any compiled code you load and ___PERM objects you allocate in C.)
Compare:
(define t (make-table weak-keys: #t weak-values: #t)) (table-set! t (string->symbol "abc") (string->symbol "def")) (table-set! t "ghi" "jkl") (table-set! t (make-uninterned-symbol "mno") (make-uninterned-symbol
"pqr"))
(##gc) (##gc) (##gc)
(table->list t)
((abc . def))
2013/9/25 Adrien Piérard pierarda@iro.umontreal.ca
Hum, I might have completely misunderstood many things, from what you wrote to how symbols work, but what if I have a symbol stored as a weak reference in a table, and it gets garbage collected. If I later re-read this symbol from the network, then I won't find it in the table, will I? But wasn't I guaranteed I'd find it *because* it's a symbol and thus the table should still be containing an element EQ to the one I just got from the network?
P!
this is silly. The case that the OP is worried about should really be using a hash table. Symbols are simply the wrong thing.
On 24 September 2013 23:39, Mikael mikael.rcv@gmail.com wrote:
More complete example:
(define t (make-table weak-keys: #t weak-values: #t)) (table-set! t (string->symbol "abc") (string->symbol "def")) (table-set! t "ghi" "jkl") (table-set! t (make-uninterned-symbol "mno") (make-uninterned-symbol
"pqr"))
(table-set! t 'st 'uv) (table-set! t (read (open-input-string "w")) (read (open-input-string
"x")))
(##gc) (##gc) (##gc)
(table->list t)
((st . uv) (w . x) (abc . def))
(Note that if you compile this code and load it, the "ghi" and "jkl" strings will not GC too as they're now part of the compiled code, which does not GC. Eval:ed code GC:s.)
2013/9/25 Mikael mikael.rcv@gmail.com
Ordinary symbols are special in that they are the only values created by Scheme code on runtime that are not garbage collected currently.
(The other ones would be any compiled code you load and ___PERM objects you allocate in C.)
Compare:
(define t (make-table weak-keys: #t weak-values: #t)) (table-set! t (string->symbol "abc") (string->symbol "def")) (table-set! t "ghi" "jkl") (table-set! t (make-uninterned-symbol "mno") (make-uninterned-symbol
"pqr"))
(##gc) (##gc) (##gc)
(table->list t)
((abc . def))
2013/9/25 Adrien Piérard pierarda@iro.umontreal.ca
Hum, I might have completely misunderstood many things, from what you wrote to how symbols work, but what if I have a symbol stored as a weak reference in a table, and it gets garbage collected. If I later re-read this symbol from the network, then I won't find it in the table, will I? But wasn't I guaranteed I'd find it *because* it's a symbol and thus the table should still be containing an element EQ to the one I just got from the network?
P!
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Dear Marc,
Posted as issue 44, https://github.com/feeley/gambit/issues/44: "./configure --enable-symbol-gc option ; Currently symbols don't GC, meaning you face risk of heap overflow & crash on any use of (read), SXML or other |string->symbol|-relying code w input from outside".
Within my personal frame of reference, this is the 3:rd or 2:nd highest prio for Gambit, as the current issue is almost or absolutely impossible for a Scheme user to mitigate, depending on the user problem complexity involved.
Feel free to give pointers on how the Gambit community could implement this.
Thanks, Mikael
2013/9/25 Mikael mikael.rcv@gmail.com
Hi!
For a lower prio than SMP feature request I wish to suggest GC:able symbols.
This would be of use to enable processing of symbols from unsafe or otherwise unknown sources such as frequently is the case in SXML and many other more or less standardized formats.
Currently in such use the Gambit process tends to be susceptible to heap overflow possibility/attacks unless there's additional complexity in the form of separate marshalling code that limits symbol import to a pre-specified set only.
Very secondarily, an extreme variant of such "unsafe formats" would be some forms of untrusted or otherwise unknown code - for running any form of untrusted code in Gambit, symbols being GC:able would be a key enabler as they'd save the untrusted code handling mechanism of the need to implement symbols<->uninterned symbol conversion in a copying proxy on start and on any passing of values between trusted and untrusted code, and also save of any weird complexity such a proxy would impose on object reference equality, cyclical references support etc.
I completely understand that probably the default non-GC:ing quality of symbols is extremely well motivated for minimalism or technical reasons, however wanted to suggest this due to the huge practical use and unifying quality this feature would bring, then as a separate configurable option I guess.
If anyone has any thought on this topic feel free to share,
Best regards, Mikael
-
Adrien Piérard -
David Rush -
Mikael -
Mikael More