× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I'm familiar with the Pop and Push frame method of freeing up objects.
There is also a DeleteLocalRef function that I executed for every row
object I created. I could also see that maybe the cell objects would not
be cleaned up until the workbook was closed. What confuses me is things
like the java.lang.Integer not be cleaned up. If you look at my original
post, I was creating a new String object before creating a cell with
SetCellValue. Every one of these string objects was listed in my original
dump (not the one I posted), even though they were created in the Java
code. I had thought that anything I created in the Java method would be
eligible for GC. I worked around this, by moving the string creation into
the compound setCellValue statement, which seems to have helped this
situation.



From: "Dan Kimmel" <dkimmel@xxxxxxxxxxxxxxx>
To: "Java Programming on and around the iSeries / AS400"
<java400-l@xxxxxxxxxxxx>
Date: 03/31/2010 01:06 PM
Subject: RE: HSSF POI performance improvement with Java helper routine
bugged
Sent by: java400-l-bounces@xxxxxxxxxxxx




There's nothing wrong with the code you've shown, but where will you get
rid of the rows and thereby all the cells that you've created? The jvm
will keep all the objects in the heap as long as a reference exits. All
your cells will exist as long as the row exists as the references are
stored in the row.

No matter what you do, you're going to wind up with all the cells of the
spreadsheet in the heap. What you want to avoid is having multiple
copies of each cell. This method should be pretty good as the cell
object is only referenced in the row object.

Classic RPG has no way of communicating to the GC that it no longer
holds an object reference. So avoid using object references in your RPG.
That may be hard to do. It is very likely that your RPG holds a
reference to the Sheet, the Sheet holds references to all the Rows and
each Row holds references to all the Cells. You may not be able to drop
the reference from RPG to the Sheet without ending the *job* running the
program (also, thereby, ending the JVM).

Check the archives on this list and some of the documentation. RPG did
come up with a way to drop those references, but it is a little obscure.

Your dump shows 4 sheets, 30,000 rows, and 725,000 cells. Check the POI
methods. There may be a way to clear a sheet rather than making a new
one.

-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx
[mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of darren@xxxxxxxxx
Sent: Wednesday, March 31, 2010 7:34 AM
To: java400-l@xxxxxxxxxxxx
Subject: HSSF POI performance improvement with Java helper routine
bugged


I've developed the following Java code, to reduce the number of call I
make from RPG via JNI to the HSSF POI API's that I use to generate large
spreadsheets. I've seen incredible performance gains, however, when a
spreadsheet got particularly large, I started getting Java dumps. I
suspect that I may be leaking objects due to my being a Java newbie, and
was hoping someone might see my error. I'm posting the Java code, and
then the RPG prototypes used to initiate the code. Thank you in
advance, and you're certainly welcome to use the code if you find it
useful.

// The two routines within this program are intended to replace the
hssf_text and hssf_num // routines in the HSSFR4 service program. Since
they execute all the small commands in // native java, with no objects
created to RPG, it seems to improve performance // dramatically, perhaps
either through better memory management, or fewer external calls to the
JVM.
// Using these routines also seems to improve temporary storage used in
the calling program as well.


package cellutil;

import org.apache.poi.hssf.usermodel.HSSFCell;
import org.apache.poi.hssf.usermodel.HSSFCellStyle;
import org.apache.poi.hssf.usermodel.HSSFRow;
import org.apache.poi.hssf.usermodel.HSSFRichTextString;

public final class newcell {
public static void Text(HSSFRow row, int col, byte[] array,
HSSFCellStyle style ) {

HSSFCell cell = row.createCell(col);
cell.setCellType(1);
String value=new String(array);
cell.setCellValue(new HSSFRichTextString(value));
cell.setCellStyle(style);
}

public static void Num(HSSFRow row, int col, double value,
HSSFCellStyle style ) {

HSSFCell cell = row.createCell(col);
cell.setCellType(0);
cell.setCellValue(value);
cell.setCellStyle(style);
}

}



D hssf_textz...
D PR static EXTPROC(*JAVA
D :'cellutil.newcell'
D :'Text')
D peRow like(HSSFRow)
D peCol like(jint) value
D peString 128 varying const
D peStyle like(HSSFCellStyle)

D hssf_numz...
D PR static EXTPROC(*JAVA
D :'cellutil.newcell'
D :'Num')
D peRow like(HSSFRow)
D peCol like(jint) value
D peValue 8f value
D peStyle like(HSSFCellStyle)

--
This is the Java Programming on and around the iSeries / AS400
(JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/java400-l.



--
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L)
mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.




As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.