This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
The attached application allocates large temporary int[] arrays. With M6 of the Profiler it was possible to do the following: 1. Profile the attached application. 2. Choose Monitor application, with no thread information 3. In the application window enter 100000000 (that's a 1 followed by 8 zeros). This causes the application to allocate an int[] that takes up 400MB on the heap. With M6 this works fine. With the nightly build of the Profiler that was created on 2005-06-17, the output window in NB displays: "Exception in thread "Thread-4" java.lang.OutOfMemoryError: Java heap space" Note that the runtime parms. for the application are: -Xmx512m -Xms512m -Xmn16m -XX:PermSize=4m -XX:MaxPermSize=4m -XX:+DisableExplicitGC -verbose:gc There is no error reported in the NB log file, but here's the tail end of the log file: Profiler.profileClass: ************************************************** Profiler.profileClass: profiling settings ------------------------------- name: Preset: Monitor profilingType =1 overrideGlobalSettings =false workingDir = jvmArgs: portNo =5140 javaPlatform =<project> threadsMonitoringEnabled =false cpuProfilingType =0 instrScheme =1 threadCPUTimerOn =false instrumentGetterSetterMethods =false instrumentEmptyMethods =false instrumentMethodInvoke =true instrumentSpawnedThreads =false nProfiledThreadsLimit =32 sortResultsByThreadCPUTime =false samplingInterval =10 instrumentationRootMethods =[] codeFragmentSelection =null codeRegionCPUResBufSize =1000 runGCOnGetResultsInMemoryProfiling =true objAllocStackSamplingInterval =10 objAllocStackSamplingDepth =0 selectedInstrFilter = Profiler.profileClass: session settings --------------------------------- mainClass: primenumbers.PrimeNumbers mainClassPath: J:\projects\PrimeNumbers\build\classes mainArgs: jvmArgs = workingDir =C:\Documents and Settings\gs145266 javaExecutable =C:\Program Files\Java\jdk1.5.0_04\bin\java.exe javaVersionString =jdk15 portNo =5140 Profiler.profileClass: ************************************************** Instrumentation filter: Filter type: None Filter value: *** JFluid message (Fri Jun 17 13:42:18 CDT 2005): Starting target application... C:\Program Files\Java\jdk1.5.0_04\bin\java.exe -agentpath:C:/Program Files/netbeans-4.1/profiler1/modules/profiler-ea-libs/deployed/jdk15/windows/profilerinterface.dll -Xbootclasspath/a:C:\Program Files\netbeans-4.1\profiler1\modules\profiler-ea-libs/jfluid-server.jar;C:\Program Files\netbeans-4.1\profiler1\modules\profiler-ea-libs/jfluid-server-15.jar -classpath J:\projects\PrimeNumbers\build\classes com.sun.tools.profiler.server.ProfilerServer C:/Program Files/netbeans-4.1/profiler1/modules/profiler-ea-libs/deployed/jdk15/windows 5140 primenumbers.PrimeNumbers
Created attachment 22774 [details] sample application
Self assign
Self assign for M7
Greg, a quick question: from the settings, it seems that you are not passing the JVM arguments to the app when profiling - i.e. the "-Xmx512m -Xms512m - Xmn16m -XX:PermSize=4m -XX:MaxPermSize=4m -XX:+DisableExplicitGC -verbose:gc". Did you set those as jvm arguments for the app in project?
Yes, the values are specified in the project. If I right-click the project and then choose Properties the properties dialog appears. On the left-hand side I choose Run and that causes the right-hand side to display runtime properties. The values for Xmx, etc. are specified in the VM Options entry.
I am getting OOME on PermGen space even during normal run under JDK 5.0 update 4 (build 5): init: deps-jar: compile: run: [Full GC 1318K->337K(522688K), 0.0276747 secs] [Full GC 337K->337K(522688K), 0.0248618 secs] [Full GC 600K->337K(522688K), 0.0242263 secs] [Full GC 337K->315K(522688K), 0.0312422 secs] Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: PermGen space BUILD SUCCESSFUL (total time: 1 second) If I change the JVM argument to -XX:PermSize=40m, it runs ok in both normal run and under profiler.
The problem is in the fact that during profiling the JVM arguments set in the project customizer are not used (I have no idea why it worked for me when I checked). Adjusting the summary accordingly. Will fix for M7.
Fixed in M7 post RC 1
Verification of old issues.
Closing old issues.