[Glass] Couple of observations/questions with out of memory situations

[Mariano Martinez Peck via Glass]

Dear all,

Let me share some thoughts after fighting an out of memory situation. I was
getting a "VM temporary object memory is full , too many failed pom_gen
scavenges"

1) As Richard pointed out, in order to get useful info for debugging this,
I had to do `export GS_DEBUG_VMGC_VERBOSE_OUTOFMEM=1`. I think the GemStone
default value should be 1. Why would not want such an info in an out of
memory situation?  If changing GemStone default value is too risky, then at
least, I would make gsDevKit_home `createStone` to add:

export GS_DEBUG_VMGC_VERBOSE_OUTOFMEM=1

In the `stone.env`

Also...note that for GS_DEBUG_VMGC_VERBOSE_OUTOFMEM, you MUST restart
netldi and hence the gems. If you can reproduce the out of memory, then
great. But it may not be easy to reproduce the situation and hence you have
no information.


2) If you want the default to continue to be 0, then why don't you add
something like "You may want to restart the stone with
GS_DEBUG_VMGC_VERBOSE_OUTOFMEM enabled and try again"

3) In the printed information when GS_DEBUG_VMGC_VERBOSE_OUTOFMEM is
enabled...where we list instances "Instances counts for generation all",
"Instances counts for generation pom" ,etc... can those be sorted by
"bytes" or "number of instances"?

4) In the printed information when GS_DEBUG_VMGC_VERBOSE_OUTOFMEM is
enabled... where you render the stack, can't we display the selectors
instead of the OOP of the selector:

1*  FaTableAccessorRowDictionary >>  (selector:168096001) *(envId 0)
@startIP   [GsNMethod 35367683841]
  nCode: 0x7f5f43f6eae8
  gsNmeth: 0x7f5f43f6ea98
              FP: 0x7f5ec4616740=StackLimit[-280] , callerFP:
StackLimit[-274]
  rcvr: 0x7f5f06aedc78 oid:57927623937 (cls:164715265
FaTableAccessorRowDictionary size:3)
2  (block, homeMethod:81257841921) @ 0x7f5f43f76a42=@natCode+0x8a
 [GsNMethod 81261597185]
  nCode: 0x7f5f43f769b8
  gsNmeth: 0x7f5f43f768c0
              FP: 0x7f5ec4616770=StackLimit[-274] , callerFP:
StackLimit[-262]
  temp 3: 0x7f5f06aedc78 oid:57927623937 (cls:164715265
FaTableAccessorRowDictionary size:3)
  temp 2: 0x7f5f1fa4ac18 (cls:52778248449
FaQuandlZacksFundamentalsDataLoader size:1)
  temp 1: 0x7f5ef1556780 (cls:134913 VariableContext size:11)
  arg 1:0x7f5f06aedc78 oid:57927623937 (cls:164715265
FaTableAccessorRowDictionary size:3)
  rcvr: 0x7f5ef1556b48 (cls:128001 ExecBlock1 size:5)
3  *SequenceableCollection >>  (selector:2336001)* (envId 0) @
0x7f5f43f1c343=@natCode+0x153  [GsNMethod 26843271937]
  nCode: 0x7f5f43f1c1f0
  gsNmeth: 0x7f5f43f1bff8
              FP: 0x7f5ec46167d0=StackLimit[-262] , callerFP:
StackLimit[-253]
  temp 8: 0x7f5ef1556b48 (cls:128001 ExecBlock1 size:5)
  temp 7: 202 (SmallInteger 25)
  temp 6: 0x7f5ef1556b88 (cls:66817 Array size:27)
  temp 5: 202 (SmallInteger 25)
  temp 4: 218 (SmallInteger 27)
  temp 3: 202 (SmallInteger 25)
  temp 2: 218 (SmallInteger 27)
  temp 1: 0x7f5ef1556b88 (cls:66817 Array size:27)
  arg 1:0x7f5ef1556b48 (cls:128001 ExecBlock1 size:5)
  rcvr: 0x7f5ef1556878 (cls:66817 Array size:27)


It's really a pain having to have a workspace opened doing "Object
_objectForOop: XXX" for every single piece of the stack you want to know.

At least, display this for the first...20 items.


Cheers,



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20160308/6c1d7891/attachment.html>