Ticket #0001889

Type	Bug	Status	submitted	Date	9-Sep-2011 17:28
Version	alpha 112	Category	Documentation	Submitted by	cyphre2
Platform	All	Severity	text	Priority	normal

Summary	GC doesn't recycle unused memory after "not enough memory" error when needed
Description	When a REBOL script alocates all available memory and "not enough memory" error! is triggered(and properly caught using TRY) any subsequent memory allocation is not possible without calling RECYCLE explicitly. The already allocated memory before the error is not returned for later rebol code usage. See example below...
Example code	recycle stats-init: stats blocks: copy [] if error? try [ n: 0 forever [ append/only blocks make block! 1000000 print [++ n stats] ] ][ print "not enough memory, recycling..." clear blocks ; Without the following recycle call it is not possible to get the allocated memory back. ; recycle print "recycling done" print [stats-init s: stats stats-init - s] ; let's try to allocate some mem again - no luck without the explicit RECYCLE though b: make block! 1000000 ]

Summary

GC doesn't recycle unused memory after "not enough memory" error when needed

Description

When a REBOL script alocates all available memory and "not enough memory" error! is triggered(and properly caught using TRY) any subsequent memory allocation is not possible without calling RECYCLE explicitly. The already allocated memory before the error is not returned for later rebol code usage.
See example below...

Example code

recycle
stats-init: stats
blocks: copy []
if error? try [
	n: 0
	forever [
		append/only blocks make block! 1000000
		print [++ n stats]
	]
][
	print "not enough memory, recycling..."
	clear blocks
;	Without the following recycle call it is not possible to get the allocated memory back.
;	recycle
	print "recycling done"
	print [stats-init s: stats stats-init - s]
;	let's try to allocate some mem again - no luck without the explicit RECYCLE though
	b: make block! 1000000 
]

Assigned to	n/a	Fixed in	-	Last Update	2-Oct-2013 23:39

Comments
(0003195) Ladislav 9-Sep-2011 17:35	The same problem is observed/observable in R2 as well.
(0004032) Ladislav 2-Oct-2013 23:37	It looks that the optimal solution to this problem is just a good documentation mentioning how to handle such situations.

Date	User	Field	Action	Change
2-Oct-2013 23:39	Ladislav	Priority	Modified	urgent => normal
2-Oct-2013 23:37	Ladislav	Category	Modified	Unspecified => Documentation
2-Oct-2013 23:37	Ladislav	Severity	Modified	major => text
2-Oct-2013 23:37	Ladislav	Comment : 0004032	Added	-
2-Oct-2013 15:45	Ladislav	Comment : 0003194	Modified	-
9-Sep-2011 17:48	cyphre2	Description	Modified	-
9-Sep-2011 17:35	Ladislav	Comment : 0003195	Added	-
9-Sep-2011 17:34	cyphre2	Description	Modified	-
9-Sep-2011 17:34	cyphre2	Code	Modified	-
9-Sep-2011 17:34	Ladislav	Comment : 0003194	Added	-
9-Sep-2011 17:28	cyphre2	Ticket	Added	-