OpenEuphoria

RE: 2.4 Official -- memory stuff

• Posted by Andy Serpa <ac at onehorseshy.com> Jul 07, 2003
• 458 views

> 
> I believe this problem is insoluble in Eu 2.4 under Win 95/98/Me--the
> problem is that heaps do not grow beyond their initial size and you can 
> get
> out of memory conditions when the heap is gone, even if you have plenty 
> of
> physical RAM--the OS can't allocate it. This issue does not occur in Win
> NT/2000/XP --these can grow heaps beyond initial size.
> 
> I ran into the same problem in a VB 6.0 app on the job which dynamically
> created a few hundred controls--always overflowed the heap on Win 98 ran
> just fine on Win 2000.
> 

I was reading something about that, but it doesn't seem to be quite the 
same problem.  There is no problem filling up tons & tons of memory.  
Works just fine.  The problem is in the re-use of memory.  The moment 
you release a significant portion of memory and start filling it up 
again is when the problems occur.  And notice there is never outright 
failure -- it just becomes REALLY slow (but no disk activity).  For 
instance, in the Diamond example of using restore_entity(), let's say 
you load in a large saved entity and assign the byte code to "x":

x = get_entity_from_file("somefile.dat")  -- mythical function

Now x is large, but is byte code, so you do:

x = restore_entity(x)

Now x is a Diamond instance handle.  But in the process, what was 
originally assigned to x is freed, and that's where the problems start 
when you start repeating that process over & over.  In other words, you 
might do this:

x = get_entity_from_file()
y = restore_entity(x)

Since x was never freed, no slow-down occurs.  That is the one constant 
in all this -- as soon as you release memory, trouble begins.  As soon 
as you start making new sequences, they have trouble getting made.  It 
is clearly in the re-allocation, clean up, or deallocation where the 
problem lies.

But obviously maintaining all memory from program start-up no matter 
what is not exactly an ideal situation, and most often not possible.

Thanks for your offer to work something out regarding Diamond, but it 
isn't really Diamond's problem.  That was just one example.  I have a 
whole class of programs where this will be an issue.  And yes, I may be 
able to come up with clever ways when loading things in so that the 
problem doesn't occur (as greatly) in one particular case, but with most 
of stuff, recycling of memory is simply fundamental to the algorithm.  
It is, as you say, insoluble.  I don't want to be jumping through a 
bunch of hoops just to load some stuff into memory.

Now then, I *am* planning on getting XP.  However, XP (along with the 
bits of new hardware I'll need to go with it) is going to cost me approx 
$300, and that was money I was planning to spend a few months down the 
line rather than this week, plus I'll have to put in a day or so just on 
the upgrade process itself when I'd much rather just finish up the 
project I'm working on.

The thing I want to make sure of is that it really is solely an OS 
issue, and that there really isn't anything that can be done about it 
Euphoria-wise (i.e. a bug).  It sounds from what Rob is saying that he 
is making an educated guess as to what is happening, but he's not quite 
sure.  Worse-case scenario is of course I spend the $300 to upgrade 
everything and the problem still persists.  That would royally suck!