Re: Do we need to do Garbage collection when using the POI

On 11/17/2015 4:13 PM, Darryl Freinkel wrote:

From my RPG code, I have no control over the Java routines. How would I get
to run SS_freeLocalRef(TempStr); on a more frequent basis.

While technically true that RPG operation codes cannot directly affect
Java internals, the point of all those Java wrappers is to let you run
Java methods by 'calling' them from RPG code via the prototypes.
Specifically, SS_freeLocalRef() is one of those wrappers. So you could
fire that off at any time you care to.

As Darren explains, Java can't tell if your RPG program is done with a
variable [like a sheet(), row() or cell()] because the RPG runtime is
the one allocating the memory, not your RPG code. So to tell the JRE
that stuff is available for garbage collection, you need to tell the RPG
runtime to let go.

Maybe the easiest way to do that is via the checkpoints Scott has coded
up: hssf_begin_object_group() and hssf_end_object_group(). You don't
have to use these only at the top and bottom of your code; you can put a
pair at the top and bottom of your 'read loop' to free up Java variables
after every read cycle.

I'm leaving Darren's reply intact because it's quite useful. Speaking
only for myself, I tend to go over this stuff quite a few times before
the Aha! happens.

from: darren@xxxxxxxxx

There is an issue with the JNI interface where if you define an object, its
not automatically marked as garbage. This is because you're programming in
RPG, not Java. There are a couple things you can do, which include marking
the object itself as obsolete, or you can define a start and end point,
where anything created within that point range is marked as garbage for the
collector.

Here are some code examples. I think these routines are in the base
service tool from Scott Klement, but we have modified them, so I don't
remember for sure:
callp hssf_begin_object_group(100);

callp hssf_end_object_group();


SS_freeLocalRef(TempStr);


One other thing you'll notice. If you're building a 50,000 row
spreadsheet, you're going to be using a lot of the available heap memory
anyway. If this becomes an issue, we switched a lot of our generation to
the SXSSF method of routines. This does require creating a couple more
java prototypes, but it allows you to create a spreadsheet of almost
unlimited size. The downside to this streaming method is that you can't
refer back to previous rows within your code...at least not very far back.