3.0 Out of memory

I have attached a dialog we are getting in our VW 3.0 image. It seems to  
me to be the typical out of memory dialog that the VM generates. However,  
I have been asked to confirm that this is what it is. It also appears that  
sometimes the dialog is not generated but the image is blown out  
nonetheless. Would that be also consistent with an out of memory  
condition? I say yes, just so low that it was not able to pull off the  
warning.

The memory policy is basically vanilla although whatever the settings are  
I have been told that they are setup to favor growth over reclamation.

I'm not handling the 3.0 product. I guess part of the consternation here  
on the part of 3.0 developer is why if the memory policy is set to favor  
growth do we get out of memory conditions in a box that seems to still  
have plenty of memory. I guess I don't know the answer. My approach in the  
past has been to not try to answer that question but instead to fiddle  
with memory policies and even look at subclassing memory policy if  
necessary.

I appreciate any feedback. I also hope that the image actually gets  
embedded into this email as oppossed to forcing folks to open the  
attachment. I use Opera and although it has many advantages they still  
don't have html formatting available for outgoing email.

thanks



--
Charles A. Monteiro

Hi Charles:

The 3.x VMs had headroom issues that are*not* mitigated by memory  
policy.  I know that on Linux, the dialog you see is often caused by  
a large number of fonts loaded.  Since I don't use Windows, I can  
only guess that the cause may be the same.

Good luck!!


On Mar 21, 2006, at 6:33 AM, Charles A. Monteiro wrote:

Thanks!!
Joseph Bacanskas [|]
--- I use Smalltalk.  My amp goes to eleven.

Charles,
Judging by the dialog picture you are using VM version 3.1.  Did you try
other releases of the 3.1 VM -- such as 3.1c or 3.1d?  It may as well
fix your problem.

My 2c.

--Mark Pirogovsky

Joseph Bacanskas wrote:

Mark Pirogovsky wrote:
> Charles,
> Judging by the dialog picture you are using VM version 3.1.  Did you try
> other releases of the 3.1 VM -- such as 3.1c or 3.1d?  It may as well
> fix your problem.


There was a thread on VW-dev recently ('fixed space has issues') that had the
same error exit. Eliot posted a fix for that particular issue on 3/3/2006 (I
would point you to the archive but http://parcplace.net seems to have
disappeared).

We have an application that shows this error exit so we ported it forward from
3.1 to 7.4 which didn't fix the problem. Applying Eliot's patch didn't help
either. We got the frequency of occurrence down a *lot* by incrementing some
headroom value in the MemoryPolicy, but I'll have to prod my colleagues
tomorrow to get the details.


R
-

One possibility: there was a problem in 3.0 with the memory policy not
reserving enough space to do a garbage collect. This led to crashes
under heavy memory loading. The following solves it:

  | mp |
  mp := MemoryPolicy new setDefaults
  contiguousSpaceSafetyMargin: 500000;
  availableSpaceSafetyMargin: 500000.
  ObjectMemory installMemoryPolicy: mp!

As Mark mentioned, you should make sure you are using the 3.1c VM on
Windows and 3.1d on Linux.

HTH,
Steve

There are a few things I've been having trouble with using Pollock.  
I'm currently up to date with Pollock 7.4 (thanks Sam and Michael!).

Running using the non-x11 Mac vm, the arrow keys do not do anything in
the TextEdit control.  Other platforms seem fine.

Sluggishness.  Pollock in general isn't snappy.  I do a lot of my work
on an older Pentium 3 so I really feel it.  There are still a lot of
these machines out there.  A lot of my customers are running on even
older machines than that.  I'm sure that Sam is aware of the situation,
but I'm just providing the feedback that I think I should.

In particular the TextEdit control is unusably slow.  On my 1.5GHz
PowerBook G4 the TextEdit control lags behind my typing, spitting out
what I type at less than a character per second.  :-/  The InputField
control is almost as slow.  Performance on my 500MHz X20 Thinkpad is
only slightly better.  It would be great to have a fix for this ASAP,
as I am demoing my software to the NYC ST group in a couple of weeks.

Placing a TextEdit control inside a tabbed form causes the Enter
keypress to be mishandled.  I have to press Shift+Enter to cause the
action to register.

For Windows 98/XP looks: 1) The sizing for tabs isn't correct in the
Windows XP look and feel.  The longer the label is, the more extra
whitespace added to the right side of the tab.  2) There is no focus
indicator for listboxes (also for Motif look).

For the Motif look:  1) The button controls aren't as tall as they
should be.  2) Scrollbars have an ugly black line on the top and left
borders.

Thanks in advance,

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com

Hello Carl, All,

Guillermo Sapaya

  The Pollock team :)

On Thu, 23 Mar 2006 08:00:13 -0500, Guillermo Sapaya <[hidden email]>  
wrote:



--
Charles A. Monteiro

Carll,

>There are a few things I've been having trouble with using Pollock.  
>I'm currently up to date with Pollock 7.4 (thanks Sam and Michael!).
>
>Running using the non-x11 Mac vm, the arrow keys do not do anything in
>the TextEdit control.  Other platforms seem fine.

That's a Mac VM problem but I'll add an AR for it. (AR50549)

I wish it was faster too. We have a HUGE step planned for next winter dealing
with speed issues. Nothing sooner I'm afraid.

>Placing a TextEdit control inside a tabbed form causes the Enter
>keypress to be mishandled.  I have to press Shift+Enter to cause the
>action to register.

AR50550 for this one.

>For Windows 98/XP looks: 1) The sizing for tabs isn't correct in the
>Windows XP look and feel.  The longer the label is, the more extra
>whitespace added to the right side of the tab.

AR50551 for this one

>2) There is no focus indicator for listboxes (also for Motif look).

Do you mean items don't highlight? There is no other focus indicator that I'm
aware of.


>1) Motif: The button controls aren't as tall as they should be.  

I don't get what you mean here. They're as big as you make 'em. Motif Buttons do
have a 7 pixel border around the "button" part, that cut into the inner bounds.
That's the way it is... However, I've been thinking of getting rid of that all
together and just copying the Win9x look for buttons in Motif. Haven't decided
yet.

>2) Motif: Scrollbars have an ugly black line on the top and left borders.

AR50552 for this one.

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

Charles,

>  The Pollock team :)

Me, Myself and I, and sometimes Kevin :)

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

but doesn't Vassili sometimes splash around with you and the Greek :)

On Thu, 23 Mar 2006 14:41:40 -0500, Samuel S. Shuster  
<[hidden email]> <[hidden email]> wrote:



--
Charles A. Monteiro

On Mar 23, 2006, at 2:40 PM, Samuel S. Shuster <[hidden email]>
wrote:
>> There are a few things I've been having trouble with using Pollock.
>> I'm currently up to date with Pollock 7.4 (thanks Sam and Michael!).
>>
>> Running using the non-x11 Mac vm, the arrow keys do not do anything in
>> the TextEdit control.  Other platforms seem fine.
>
> That's a Mac VM problem but I'll add an AR for it. (AR50549)

No workaround?  The arrow keys work fine for Wrapper on that VM.

Can't you do anything at all?  I have to ship this by late August, or
this will have serious repercussions for my business.  :-/  Perhaps you
could make some suggestions about where the speed issue is, and I could
take a stab at it myself?  This is really important to me.

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com

Carl,

> No workaround?  The arrow keys work fine for Wrapper on that VM.

The AR is there, and I'll look into it. No workaround at this time.

Carl, Pollock is NOT optimized. It is also not Production quality.  
One of the MUST DO tasks is optimization. I will not release Pollock  
for Production until that is done. It is a task that I expect will  
take up to 3 months to do.

Unfortunately, Pollock isn't ready for optimization it... yet.

What you can do is what I will be doing in that task. Load the  
profiler, and try to figure out why it's slow.

Now, before I get hammered that I don't care, or that I'm not being  
responsive to my customers: Pollock is beta. I have no intention of  
letting this, or a hundred other issues, be ignored. Pollock will NOT  
go into production until ALL are addressed.

                                 And So It Goes
                                      Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

Carl,

> No workaround?  The arrow keys work fine for Wrapper on that VM.

The OSX VM is adding #meta to the arrow (and other) keys! Wrapper  
(actually, inappropriately) ignores it.

I'll make an AR for this tomorrow <sigh>... Actually two. One for the  
VM, the other for Pollock to deal with a workaround until which time  
the VM is fixed.

                                 And So It Goes
                                      Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

Carl Gundel wrote:

> Can't you do anything at all?  I have to ship this by late August, or
> this will have serious repercussions for my business.  :-/  Perhaps
> you could make some suggestions about where the speed issue is, and I
> could take a stab at it myself?  This is really important to me.

Hi,

I am not sure if this is still the issue, but I have reported the
Pollock slowness some time ago (about half a year ago). Its cause was in
LayoutFrame machinery. Every time you click somewhere (maybe even move
the mouse), the system has to determine on which widget you actually
clicked. This eventually leads to computing widget bounds by asking
frames to do it. And because frames do not cache them, they are computed
each time. This is problem especially with FractionalFrame and
RelationalFrame, which in order to compute their bounds have to ask its
parents and/or even neighbours... I was trying to solve it myself, but
failed, because I don't understand Pollock internals that well...

But basically all you have to do is add caching of frame bounds and
properly invalidate them when they change...

Hope this helps,

Ladislav Lenart

Charles A. Monteiro schrieb am 21.03.2006 15:33:
> I have attached a dialog we are getting in our VW 3.0 image. It seems to
> me to be the typical out of memory dialog that the VM generates.

As has already been noted, there's more than one possible reason for the
error. Make sure the latest 3.1 VM for the respective platform is used,
and that the space safety margins are set to large enough values. From
the VisualWorks Memory Management Guide, v.7.2, p.8: "Finally, a certain
portion of the free contiguous data is reserved for use by the object
engine to ensure that it can perform at least one scavenge in extreme
low-space conditions, thereby providing the system with one final
opportunity to take the appropriate action." This was true in 3.x also.

From the same manual, p. 9: "The remembered table (RT) is a special
table that contains one entry for each object in Old Space or Perm Space
that is thought to contain a reference to an object housed in New
Space." In VW 3.x these tables could overflow, resulting either in an
"out of memory" or a "remembered table overflow" error from the VM (I
saw the "remembered table overflow" message only once with no way to
reproduce it). The probability of this condition can be reduced by
making OldSpace segments and space safety margins larger (we used to set
availableSpaceSafetyMargin to 2.5 MB and contiguousSpaceSafetyMargin to
1.5 MB for an application producing large numbers of temporary objects)
and by enlarging Eden and SurvivorSpace. If you enlarge Eden and
SurvivorSpace e.g. by a factor of 10.0 to 20.0, fewer temporary objects
will be tenured from NewSpace to OldSpace, thus reducing the probability
that tenured objects reference objects in NewSpace.

If you force the image to return empty OldSpace segments to the
operating system, there can be another type of error in 3.x and some
later versions of VW. It can happen that you return all empty OldSpace
segments to the OS, and that the space safety margins were located in
one of these segments. In extreme cases, all the remaining OldSpace
segments can be full to the brim. This will lead to an out of memory
error during the next run of the scavenger. When freeing memory, you
should force the allocation of a new OldSpace segment if there is not
enough free memory in the remaining segments.

Starting with 7.0 or 7.1 (I don't remember the exact version), it seems
to be necessary that the newly introduced MemoryPolicy parameter
freeMemoryUpperBound is set to a value higher than the
preferredGrowthIncrement. It's not stated explicitly in the
documentation, and I can't actually prove this, but we had occasional
out of memory errors when we raised preferredGrowthIncrement to 10 MB,
while leaving freeMemoryUpperBound at its default 8 MB. Raising
freeMemoryUpperBound to 15 MB solved the problem.

I hope this helps. If it doesn't and you must make sure that the problem
is resolved, you might want to hire John McIntosh. It helped in our
case, and was worth every cent invested. ;-) Of course, the right
solution would be to port to VW 7.x - and hire John to tune the
MemoryPolicy... ;-)

Joachim Geidel

On Mar 23, 2006, at 2:40 PM, Samuel S. Shuster <[hidden email]>
wrote:
>> 2) There is no focus indicator for listboxes (also for Motif look).
>
> Do you mean items don't highlight? There is no other focus indicator
> that I'm
> aware of.

No, I mean there is no focus indication.  In Windows when a listbox has
input focus the selected item will have a dotted outline, and if there
is no selected item the first item will still have a dotted outline.  
As soon as you press the space bar or arrow keys the listbox will make
a selection, or you can press a character key and the first item with
that character will be selected.  Press that character again and the
next matching item will be the selection, etc.  When I try this last
thing in a Pollock listbox the whole list portion of the widget (not
the scrollbar) flashes black and then redisplays.

Well, perhaps that's all it is, that the border is stealing space from
the label.

Thanks,

-Carl

If I select some text in a TextEdit control by dragging up or down with
the mouse, and reverse direction before letting go of the mouse button
the selection doesn't get cleaned up.  It leaves a mess behind.

The same thing happens if I use Shift and up arrow or down arrow keys.

Also, I have been unable to make the accelerators work for menu items.  
For example I might define the standard Ctrl+N to make a new document
for my editor, but it does nothing.  Here's the code that defines the
menu item.  Am I doing something wrong?

     addMenuItem: ((Panda.MenuItem label: '&New File')
         keystroke: (Panda.Keystroke ctrl: $n);
         actionID: #newFile);

Thanks,

-Carl Gundel, author of Liberty BASIC
http://www.libertybasic.com

Carl Gundel,

>If I select some text in a TextEdit control by dragging up or down with
>the mouse, and reverse direction before letting go of the mouse button
>the selection doesn't get cleaned up.  It leaves a mess behind.
>
>The same thing happens if I use Shift and up arrow or down arrow keys.

AR50562 for this one.

>Also, I have been unable to make the accelerators work for menu items.  
>For example I might define the standard Ctrl+N to make a new document
>for my editor, but it does nothing.  Here's the code that defines the
>menu item.  Am I doing something wrong?
>
>     addMenuItem: ((Panda.MenuItem label: '&New File')
>         keystroke: (Panda.Keystroke ctrl: $n);
>         actionID: #newFile);


I assume you added an Action with the id #newFile somewhere. The issue is where.
If this is a MainMenu item, then it needs to be added to the Window itself.

                                And So It Goes
                                     Sames
______________________________________________________________________

Samuel S. Shuster [|]
VisualWorks Engineering, GUI Project
Smalltalk Enables Success -- What Are YOU Using?

VW 7.4 changed the directory structure of parcels, specially 'goodies'
now 'contributed'.

However, the ColorEditing parcel that used to be under 'parc' subdir in
  goodies, is not available anymore.

Is it because there is a new clever way to obtain this?

Otherwise shall I download from Cincom repository or loading a parcel
from an ealier release of VW would suffice?

TIA

--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/