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

[Dale Henrichs via Glass]

Mariano,

Thanks for the feedback ... I've submitted internal issue 46101 (so you 
can watch for it in future release notes) as a feature request for 
internal discussion ..

With regards to your fourth point about having oops instead of 
selectors, when we print the stack for out of memory we are trying to 
avoid consuming as little memory as possible and getting the bytes for a 
symbol does end up consuming additional memory (we do print the bytes 
for the selector if the symbol has already been faulted in), but your 
points for this were included in the bug mail and we will take a second 
look at what we might be able to do in this case ..

Dale

On 03/08/2016 08:55 AM, Mariano Martinez Peck via Glass wrote:
> 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
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass

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