Hi,
I've noticed a behavior of the NetRexx compiler on Mac OS X, and I thought I'd ask those that know the source to think about this. Environment: Mac OS X 10.5.8 (Leopard) Java 1.5.0_22 (32 bit) and Java 1.6.0_17 (64 bit) NetRexxC.jar V2.05, 1/14/2005 355,931 bytes When NetRexxC is run to perform a compile on an arbitrary NetRexx program (hello.nrx) and it is given a classpath, either as an environmental variable, or via the -cp command line option, and that classpath contains a classpath segment which is a directory, then the NetRexx compiler starts searching random directories all over the system, until it eventually runs out of memory. I verified this behavior by monitoring the java process using Activity Monitor, and watching as the process opened and closed files. Now I understand that at this point, this is only happening on my system. I guess I would first like other Mac users to veryify if it is happening on their systems as well. Thanks, Bruce _______________________________________________ Ibm-netrexx mailing list [hidden email] |
El 18/03/2010 15:37, Bruce Skelly escribió: > When NetRexxC is run to perform a compile on an arbitrary NetRexx > program (hello.nrx) and it is given a classpath, either as an > environmental variable, or via the -cp command line option, and that > classpath contains a classpath segment which is a directory, then the > NetRexx compiler starts searching random directories all over the > system, until it eventually runs out of memory. Bruce, Have you checked that no links exist in said directory in the classpath? As I understand the NetRexx compiler recursively reads every available class in the classpath. If there were any links in that tree the compiler might be just following them (hence, seemingly reading arbitrary locations) Now, what would happen if at some point a link pointed back to one of the already scanned locations? A plain old loop! Just an idea. Maybe you could notice the pattern with Activity Monitor if this was happening. In any case it should allow to follow the path the compiler is scanning. That said, I'll be further studying what you sent me in separate email. I'm really intrigued by now :-) --- Saludos / Kind regards. David Requena _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Ok, I'm now unable to reproduce this as a general case. I tried
setting the classpath to /System/Library/Java/, plus the classes.jar and NetRexxC.jar and it worked, so I'm not sure what is happening. I guess I need to run some more tests to try and isolate the behavior better. Bruce On Mar 18, 2010, at 9:03 AM, David Requena wrote: > > El 18/03/2010 15:37, Bruce Skelly escribió: >> When NetRexxC is run to perform a compile on an arbitrary NetRexx >> program (hello.nrx) and it is given a classpath, either as an >> environmental variable, or via the -cp command line option, and >> that classpath contains a classpath segment which is a directory, >> then the NetRexx compiler starts searching random directories all >> over the system, until it eventually runs out of memory. > > Bruce, > > Have you checked that no links exist in said directory in the > classpath? > > As I understand the NetRexx compiler recursively reads every available > class in the classpath. If there were any links in that tree the > compiler > might be just following them (hence, seemingly reading arbitrary > locations) > > Now, what would happen if at some point a link pointed back to one > of the > already scanned locations? A plain old loop! > > Just an idea. Maybe you could notice the pattern with Activity > Monitor if > this was happening. In any case it should allow to follow the path the > compiler is scanning. > > That said, I'll be further studying what you sent me in separate > email. I'm > really intrigued by now :-) > > --- > Saludos / Kind regards. > David Requena > > > _______________________________________________ > Ibm-netrexx mailing list > [hidden email] > _______________________________________________ Ibm-netrexx mailing list [hidden email] |
Free forum by Nabble | Edit this page |