Re: Weird behavior with dynamically sized arrays

It's not actually our code allocating memory...

It's in some vendor's code.

We are working with them to reduce usage...but we'll probably end up
restructuring how we make use of their code.

I'm just throwing the story out there as a cautionary tale.

Yeah 2MB static allocation for something doesn't seem like much...

But sometimes it is.

Charles


On Thu, Mar 9, 2017 at 8:32 PM, Henrik Rützou <hr@xxxxxxxxxxxx> wrote:

Sorry to say,

there is a very simple K.I.S.S solution to this if you are afraid that big
arrays takes
up to much storage in to many inactive programs:

d ArrayPtr s * Inz( *Null )
d Array s 31 0 Dim( 50000 )
d Based( ArrayPtr )

If ArrayPtr = *null,
Arrayptr = %Alloc(%Size(Array) * 50000);
else;
Arrayptr = %ReAlloc(ArrayPtr:%Size(Array) * 50000);
endif;

// do whatever you wish within the total limit in the array

when you exit the program:

Arrayptr = %ReAlloc(ArrayPtr:1);
return;





On Thu, Mar 9, 2017 at 12:37 AM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

Yes, 80K isn't that big....

But 2MB doesn't seem that big either...
Till you realize there's 11 of those 2MB memory allocations...
giving you 22MB of temporary storage usage...
In a program that ends up in every interactive user's call stack...
And you have 10,000 users...

And your temporary storage usage tops out at 1.4TB...

Needless to say, there's going to be changes...either to the 2MB

allocation

breaking up the program a bit so that the 22MB will only be allocated

when

needed and only while needed.

So think about your environment, and the life cycle of your memory
allocations.

ILE actually makes it easier to tie up memory as a program remains active
till the activation group ends.

consider ACTGRP(*NEW) if a program is called once and while...

consider actgrp(xxxxx) if a program is called repeatedly for a while,

then

is done. As you can then RCLACTGRP...

Charles



On Wed, Mar 8, 2017 at 3:56 PM, Dan <dan27649@xxxxxxxxx> wrote:

O.k., o.k., o.k. I've seen the light. Scott, thank you for reminding

me

of the context of 80k on today's Power i systems. Of course, this was

just

an example, but I'm sure most arrays in our production code aren't too

far

off that figure.

Thanks everyone!
- Dan

On Wed, Mar 8, 2017 at 3:20 PM, Scott Klement <

rpg400-l@xxxxxxxxxxxxxxxx

wrote:

Dan,

The code that makes the dump doesn't know how much memory you

have/haven't

allocated. That information is only known to YOUR code.

So when you say DIM(5000), the dump program tries to list 5000

elements.

Again, it doesn't know that you've only reserved memory for 32

elements!

You said 5000! So when it tries to read the full 5000 elements, it

runs

into an error -- and therefore prints that the data wasn't

addressable.

What frustrates me is to see someone using dynamic memory at all for
this! It's only an 80k total size array... believe me, you'll

never

in a

zillion years notice that 80k. You are wasting time and creating

headaches

by keeping tracking of allocation sizes (and from your description,

there

are bugs in that) and giving yourself headaches keeping track of it

for

WHAT, exactly?

Even if this were megabytes, it might be hard to argue that it's
worthwhile to use dynamic allocation. But for 80k?! Frankly, you're

nuts

for using dynamic memory for that.

And this is coming from someone who LIKES working with pointers!

-SK

--
This is the RPG programming on the IBM i (AS/400 and iSeries)

(RPG400-L)

mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD

--
Regards,
Henrik Rützou

http://powerEXT.com <http://powerext.com/>
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD