Search Results

Search found 1197 results on 48 pages for 'jvm'.

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

Page 9/48 | < Previous Page | 5 6 7 8 9 10 11 12 13 14 15 16  | Next Page >

  • Force full garbage collection when memory occupation goes beyond a certain threshold

    - by Silvio Donnini
    I have a server application that, in rare occasions, can allocate large chunks of memory. It's not a memory leak, as these chunks can be claimed back by the garbage collector by executing a full garbage collection. Normal garbage collection frees amounts of memory that are too small: it is not adequate in this context. The garbage collector executes these full GCs when it deems appropriate, namely when the memory footprint of the application nears the allotted maximum specified with -Xmx. That would be ok, if it wasn't for the fact that these problematic memory allocations come in bursts, and can cause OutOfMemoryErrors due to the fact that the jvm is not able to perform a GC quickly enough to free the required memory. If I manually call System.gc() beforehand, I can prevent this situation. Anyway, I'd prefer not having to monitor my jvm's memory allocation myself (or insert memory management into my application's logic); it would be nice if there was a way to run the virtual machine with a memory threshold, over which full GCs would be executed automatically, in order to release very early the memory I'm going to need. Long story short: I need a way (a command line option?) to configure the jvm in order to release early a good amount of memory (i.e. perform a full GC) when memory occupation reaches a certain threshold, I don't care if this slows my application down every once in a while. All I've found till now are ways to modify the size of the generations, but that's not what I need (at least not directly). I'd appreciate your suggestions, Silvio P.S. I'm working on a way to avoid large allocations, but it could require a long time and meanwhile my app needs a little stability

    Read the article

  • Java Daemon Threading with JNI

    - by gwin003
    I have a Java applet that creates a new non-daemon thread like so: Thread childThread = new Thread(new MyRunnable(_this)); childThread.setDaemon(false); childThread.start(); Then my MyRunnable object calls a native method that is implemented in C++: @Override public void run() { while (true) { if (!ran) { System.out.println("isDaemon: " + Thread.currentThread().isDaemon()); _applet.invokePrintManager(_applet.fFormType, _applet.fFormName, _applet.fPrintImmediately, _applet.fDataSet); ran = true; } } } This C++ method calls into a C# DLL that shows a form. My problem is, whenever the user navigates away from the page with a Java applet on it, JVM (and my C# form) is killed. I need the form and JVM to remain open until it is closed by the user. I tried setting my thread to be a non-daemon thread, which is working because System.out.println("isDaemon: " + Thread.currentThread().isDaemon() prints isDaemon: false. Is there something related to the way that the C# form is created (is there another thread I'm not accounting for) or something I am overlooking?? My thread is not a daemon thread, but the JVM is being killed anyways.

    Read the article

  • How to reliably take Java Heap Dumps?

    - by karlcyr
    My team is running into difficulties when trying to take good heap dumps triggered by OutOfMemoryErrors. For specific reasons we are currently taking the dumps with jmap called from a bash script instead of using the HeapDumpOnOutOfMemoryError flag. We're using a 64-bit 1.6 JVM with a heap size around 3 GB. Our heap dumps fail 90% of the time (guesstimate). Is there anything we can do to improve our odds of getting a clean heap dump we can use to troubleshoot memory problems? I have read that jmap had major issues in Java 1.4 but that those issues should be mostly addressed now.

    Read the article

  • Migrating WebLogic 10.3.0 to new host. Slow managed server startup times

    - by wadevondoom
    We are migrating our Blue Martini Commerce application (only supported on WebLogic 10.3.0) to a new host (Redhat 6.3 on a VMWare ESX vm). We are seeing extremely slow start up times for our managed server(s) that is basically 20x slower than our current production. As a for instance the Publish managed server takes ~30 - 45 seconds in current production and in the new environment it takes ~10 minutes. The setup uses the same domain structure and JVM as the current production environment. The same setup files are used. We use jdk1.6.0_33 on 64 bit architecture. We used the generic 64bit weblogic installer and used pack / unpack utilities to migrate the domain. The JAVA_OPTS to start this server are: "-d64 -Xms256m -Xmx512m -XX:PermSize=48m -XX:MaxPermSize=256m" The sysadmins have checked /etc/sysctl.conf and /etc/limits.conf to ensure we were not hitting some kind of process limit. As I am not sure what this managed server does from a Blue Martini perspective during the phase of startup I also had the DBA check to ensure that Oracle RAC (11.2.0.3) wasn't also hitting some kind of process limit or if there was a tns listener issue. The new host is quite a bit stricter with their server lock downs so there are a few differences.... Redhat 6.3 in new env, RH 5.7 in current SElinux is targeted in new env and disabled in current VM in new env and dedicated hardware in current iptables disabled in current. It was enabled in new prod but I had them disable it just in case I apologize for not being more specific. I am mostly hoping got some tips. I do not have the typical root access I would normally have in this environment. I am just hoping got a path forward. I did a few 'kill -3' to see if there are blocked threads and I got nadda. The service works for all intents and purposes it is just painfully slow. Thanks you all in advance for reading and best regards. Wade

    Read the article

  • CIL and JVM Little endian to big endian in c# and java

    - by Haythem
    Hello, I am using on the client C# where I am converting double values to byte array. I am using java on the server and I am using writeDouble and readDouble to convert double values to byte arrays. The problem is the double values from java at the end are not the double values at the begin giving to c# writeDouble in Java Converts the double argument to a long using the doubleToLongBits method , and then writes that long value to the underlying output stream as an 8-byte quantity, high byte first. DoubleToLongBits Returns a representation of the specified floating-point value according to the IEEE 754 floating-point "double format" bit layout. The Program on the server is waiting of 64-102-112-0-0-0-0-0 from C# to convert it to 1700.0 but he si becoming 0000014415464 from c# after c# converted 1700.0 this is my code in c#: class User { double workingStatus; public void persist() { byte[] dataByte; using (MemoryStream ms = new MemoryStream()) { using (BinaryWriter bw = new BinaryWriter(ms)) { bw.Write(workingStatus); bw.Flush(); bw.Close(); } dataByte = ms.ToArray(); for (int j = 0; j < dataByte.Length; j++) { Console.Write(dataByte[j]); } } public double WorkingStatus { get { return workingStatus; } set { workingStatus = value; } } } class Test { static void Main() { User user = new User(); user.WorkingStatus = 1700.0; user.persist(); } thank you for the help.

    Read the article

  • JVM Bug with JDWP

    - by Dan
    I found this bug report from Sun indicating a problem with certain Java versions and enabling a JDWP port. But that bug report doesn't indicate when or even if it was fixed. Does anyone have more up-to-date info on that? thanks

    Read the article

  • java runtime tracing library to replace system.out.println

    - by Grzegorz Oledzki
    Have you heard of any library which would allow me to set up a tracing for specific methods at runtime? Instead of adding (and removing) lots of System.out.println in my code (and having to re-compile and re-deploy) I would like to have a magic thing which would print out a line for each call of selected method without any change in the code. This would work without re-compiling, so some kind of JVM agent (or some non-standard JVM would be needed?). Sounds like a job for aspect programming? A typical scenario would be to start an application, configure the traced methods dynamically (in a separate file or similar) and then everytime a selected method is called a line with its name (and arguments) is printed out to System.out (or some log file). Naturally one could think of tens of additional features, but this basic set would be a great tool. BTW, I use Eclipse interactive debugger too, not only the System.out tracing technique, but both have some advantages and sometimes Eclipse is not enough.

    Read the article

  • Eclipse jvm.dll error when loading

    - by Dan James Palmer
    Trying to open Eclipse after a couple of months and get this error: So I checked that folder to see if it existed, and it did: I checked my PATH Was correct and it was also correct: When this error first occurred I had 3 Java installations. JRE 7 Update 10, JDK 7 Update 7 32bit and 64 bit. I uninstall ALL and restarted my machine. Eclipse then stated, as expected that I needed a JRE or a JDK. So I downloaded and installed the latest JDK and now I get this error, despite everything appearing to be correct. Any ideas?

    Read the article

  • Override Java System.currentTimeMillis

    - by Mike Clark
    Is there a way, either in code or with JVM arguments, to override the current time, as presented via System.currentTimeMillis, other than manually changing the system clock on the host machine? A little background: We have a system that runs a number of accounting jobs that revolve much of their logic around the current date (ie 1st of the month, 1st of the year, etc) Unfortunately, a lot of the legacy code calls functions such as new Date() or Calendar.getInstance(), both of which eventually call down to System.currentTimeMillis. For testing purposes, right now, we are stuck with manually updating the system clock to manipulate what time and date the code thinks that the test is being run. So my question is: Is there a way to override what is returned by System.currentTimeMillis? For example, to tell the JVM to automatically add or subtract some offset before returning from that method? Thanks in advance!

    Read the article

  • Performance implications of finalizers on JVM

    - by Alexey Romanov
    According to this post, in .Net, Finalizers are actually even worse than that. Besides that they run late (which is indeed a serious problem for many kinds of resources), they are also less powerful because they can only perform a subset of the operations allowed in a destructor (e.g., a finalizer cannot reliably use other objects, whereas a destructor can), and even when writing in that subset finalizers are extremely difficult to write correctly. And collecting finalizable objects is expensive: Each finalizable object, and the potentially huge graph of objects reachable from it, is promoted to the next GC generation, which makes it more expensive to collect by some large multiple. Does this also apply to JVMs in general and to HotSpot in particular?

    Read the article

  • JPA GeneratedValue with GenerationType.TABLE does a big jump after jvm restart

    - by joeduardo
    When I start my server and add an entry, the generated id will start with 1, 2, so on and so forth. After a restart, adding an entry would generate an id like 32,xxx. Another restart and adding of entry would generate an id like 65,xxx. I don't know why this is happening. Here's a snippet of the annotation I'm using for my id. I'm using Hibernate. @Id @GeneratedValue(strategy = GenerationType.TABLE) private Long id;

    Read the article

  • Will this be garbage collected in JVM?

    - by stjowa
    I am running the following code every two minutes via a Timer: object = new Object(this); Potentially, this is a lot of objects being created and a lot of objects being overwritten. Do the overwritten objects get garbage collected, even with a reference to itself being used in the newly created object? I am using JDK 1.6.0_13. Thanks for the help.

    Read the article

  • Using Java, can I have one JVM spawn another, and then have the original one exit?

    - by CarlG
    I have a need to have a running JVM start another JVM and then exit. I'm currently trying to do this via Runtime.getRuntime().exec(). The other JVM starts, but my original JVM won't exit until the "child" JVM process stops. It appears that using Runtime.getRuntime().exec() creates a parent-child relationship between the processes. Is there some way to de-couple the spawned process so that the parent can die, or some other mechanism to spawn a process without any relationship to the creating process? Note that this seems exactly like this question: http://stackoverflow.com/questions/2566502/using-java-to-spawn-a-process-and-keep-it-running-after-parent-quits but the accepted answer there doesn't actually work, at least not on my system (Windows 7, Java 5 and 6). It seems that maybe this is a platform-dependent behavior. I'm looking for a platform independent way to reliably invoke the other process and let my original process die.

    Read the article

  • How to make sure Solr/Lucene won't die with java.lang.OutOfMemoryError?

    - by taw
    I'm really puzzled why it keeps dying with java.lang.OutOfMemoryError during indexing even though it has a few GBs of memory. Is there a fundamental reason why it needs manual tweaking of config files / jvm parameters instead of it just figuring out how much memory is available and limiting itself to that? No other programs except Solr ever have this kind of problem. Yes, I can keep tweaking JVM heap size every time such crashes happen, but this is all so backwards. Here's stack trace of the latest such crash in case it is relevant: SEVERE: java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOfRange(Arrays.java:3209) at java.lang.String.<init>(String.java:216) at org.apache.lucene.index.TermBuffer.toTerm(TermBuffer.java:122) at org.apache.lucene.index.SegmentTermEnum.term(SegmentTermEnum.java:169) at org.apache.lucene.search.FieldCacheImpl$StringIndexCache.createValue(FieldCacheImpl.java:701) at org.apache.lucene.search.FieldCacheImpl$Cache.get(FieldCacheImpl.java:208) at org.apache.lucene.search.FieldCacheImpl.getStringIndex(FieldCacheImpl.java:676) at org.apache.lucene.search.FieldComparator$StringOrdValComparator.setNextReader(FieldComparator.java:667) at org.apache.lucene.search.TopFieldCollector$OneComparatorNonScoringCollector.setNextReader(TopFieldCollector.java:94) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:245) at org.apache.lucene.search.Searcher.search(Searcher.java:171) at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:988) at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:884) at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:341) at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:182) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619)

    Read the article

  • Java fatal error, don't know what it means

    - by Thomas King
    It happens at the same place in my code (albeit not the first time the method is executed) but I can't make head or tail of what is wrong. (Doubly so as it's code for a robot). Be most appreciative if someone can give me an idea of what kind of problem it is. I assume it's to do with threading (multi-threaded app) but I don't really know what?!? Worried as deadline for uni project is looming!!! The message: # A fatal error has been detected by the Java Runtime Environment: # SIGSEGV (0xb) at pc=0xb70f0ca7, pid=5065, tid=2145643376 # JRE version: 6.0_15-b03 Java VM: Java HotSpot(TM) Server VM (14.1-b02 mixed mode linux-x86 ) Problematic frame: V [libjvm.so+0x4c9ca7] # An error report file with more information is saved as: /home/thomas/workspace/sir13/hs_err_pid5065.log # If you would like to submit a bug report, please visit: http://java.sun.com/webapps/bugreport/crash.jsp # The log: # A fatal error has been detected by the Java Runtime Environment: # SIGSEGV (0xb) at pc=0xb70f0ca7, pid=5065, tid=2145643376 # JRE version: 6.0_15-b03 Java VM: Java HotSpot(TM) Server VM (14.1-b02 mixed mode linux-x86 ) Problematic frame: V [libjvm.so+0x4c9ca7] # If you would like to submit a bug report, please visit: http://java.sun.com/webapps/bugreport/crash.jsp # --------------- T H R E A D --------------- Current thread (0x0904ec00): JavaThread "CompilerThread1" daemon [_thread_in_native, id=5078, stack(0x7fdbe000,0x7fe3f000)] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x00000004 Registers: EAX=0x00000000, EBX=0xb733d720, ECX=0x000003b4, EDX=0x00000000 ESP=0x7fe3bf30, EBP=0x7fe3bf78, ESI=0x7fe3c250, EDI=0x7e9a7790 EIP=0xb70f0ca7, CR2=0x00000004, EFLAGS=0x00010283 Top of Stack: (sp=0x7fe3bf30) 0x7fe3bf30: 00020008 7ec8de5c 7fe3c250 00000000 0x7fe3bf40: 7f610451 00001803 7e9a7790 000003f5 0x7fe3bf50: 7e920030 7f239910 7f23b349 7f23b348 0x7fe3bf60: 7f550e35 7fe3c250 0000021b b733d720 0x7fe3bf70: 000003bc 7f23db10 7fe3bfc8 b70f0997 0x7fe3bf80: 7fe3c240 7f23db10 00000000 00000002 0x7fe3bf90: 00000000 7fe3c1b0 00000000 00000000 0x7fe3bfa0: 00004000 00000020 7ec88870 00000002 Instructions: (pc=0xb70f0ca7) 0xb70f0c97: 7d 08 8b 87 c8 02 00 00 89 c7 8b 45 c4 8b 14 87 0xb70f0ca7: 8b 42 04 8b 00 85 c0 75 22 8b 4e 04 8b 52 1c 39 Stack: [0x7fdbe000,0x7fe3f000], sp=0x7fe3bf30, free space=503k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x4c9ca7] V [libjvm.so+0x4c9997] V [libjvm.so+0x4c6e23] V [libjvm.so+0x25b75f] V [libjvm.so+0x2585df] V [libjvm.so+0x1f2c2f] V [libjvm.so+0x260ceb] V [libjvm.so+0x260609] V [libjvm.so+0x617286] V [libjvm.so+0x6108fe] V [libjvm.so+0x531c4e] C [libpthread.so.0+0x580e] Current CompileTask: C2:133 ! BehaviourLeftUnexplored.action()V (326 bytes) --------------- P R O C E S S --------------- Java Threads: ( = current thread ) 0x08fb5400 JavaThread "DestroyJavaVM" [_thread_blocked, id=5066, stack(0xb6bb0000,0xb6c01000)] 0x09213c00 JavaThread "Thread-4" [_thread_blocked, id=5085, stack(0x7eeaf000,0x7ef00000)] 0x09212c00 JavaThread "Thread-3" [_thread_in_Java, id=5084, stack(0x7f863000,0x7f8b4000)] 0x09206800 JavaThread "AWT-XAWT" daemon [_thread_in_native, id=5083, stack(0x7f8b4000,0x7f905000)] 0x091b7400 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=5082, stack(0x7f93e000,0x7f98f000)] 0x09163c00 JavaThread "Thread-0" [_thread_in_native, id=5081, stack(0x7fc87000,0x7fcd8000)] 0x09050c00 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=5079, stack(0x7fd6d000,0x7fdbe000)] =0x0904ec00 JavaThread "CompilerThread1" daemon [_thread_in_native, id=5078, stack(0x7fdbe000,0x7fe3f000)] 0x0904c000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=5077, stack(0x7fe3f000,0x7fec0000)] 0x0904a800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=5076, stack(0x7fec0000,0x7ff11000)] 0x09036c00 JavaThread "Finalizer" daemon [_thread_blocked, id=5075, stack(0x7ff57000,0x7ffa8000)] 0x09035400 JavaThread "Reference Handler" daemon [_thread_blocked, id=5074, stack(0x7ffa8000,0x7fff9000)] Other Threads: 0x09031400 VMThread [stack: 0x7fff9000,0x8007a000] [id=5073] 0x09052800 WatcherThread [stack: 0x7fcec000,0x7fd6d000] [id=5080] VM state:not at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: None Heap PSYoungGen total 46784K, used 32032K [0xae650000, 0xb3440000, 0xb3a50000) eden space 46720K, 68% used [0xae650000,0xb0588f48,0xb13f0000) from space 64K, 95% used [0xb3390000,0xb339f428,0xb33a0000) to space 384K, 0% used [0xb33e0000,0xb33e0000,0xb3440000) PSOldGen total 43008K, used 20872K [0x84650000, 0x87050000, 0xae650000) object space 43008K, 48% used [0x84650000,0x85ab2308,0x87050000) PSPermGen total 16384K, used 5115K [0x80650000, 0x81650000, 0x84650000) object space 16384K, 31% used [0x80650000,0x80b4ec30,0x81650000) Dynamic libraries: 08048000-08052000 r-xp 00000000 08:05 34708 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/bin/java 08052000-08053000 rwxp 00009000 08:05 34708 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/bin/java 08faf000-09220000 rwxp 00000000 00:00 0 [heap] 7e900000-7e9f9000 rwxp 00000000 00:00 0 7e9f9000-7ea00000 ---p 00000000 00:00 0 7ea00000-7ea41000 rwxp 00000000 00:00 0 7ea41000-7eb00000 ---p 00000000 00:00 0 7eb00000-7ebfc000 rwxp 00000000 00:00 0 7ebfc000-7ec00000 ---p 00000000 00:00 0 7ec00000-7ecf7000 rwxp 00000000 00:00 0 7ecf7000-7ed00000 ---p 00000000 00:00 0 7ed00000-7ede7000 rwxp 00000000 00:00 0 7ede7000-7ee00000 ---p 00000000 00:00 0 7eeaf000-7eeb2000 ---p 00000000 00:00 0 7eeb2000-7ef00000 rwxp 00000000 00:00 0 7ef00000-7eff9000 rwxp 00000000 00:00 0 7eff9000-7f000000 ---p 00000000 00:00 0 7f100000-7f1f6000 rwxp 00000000 00:00 0 7f1f6000-7f200000 ---p 00000000 00:00 0 7f200000-7f2fc000 rwxp 00000000 00:00 0 7f2fc000-7f300000 ---p 00000000 00:00 0 7f300000-7f4fe000 rwxp 00000000 00:00 0 7f4fe000-7f500000 ---p 00000000 00:00 0 7f500000-7f5fb000 rwxp 00000000 00:00 0 7f5fb000-7f600000 ---p 00000000 00:00 0 7f600000-7f6f9000 rwxp 00000000 00:00 0 7f6f9000-7f700000 ---p 00000000 00:00 0 7f700000-7f800000 rwxp 00000000 00:00 0 7f830000-7f836000 r-xs 00000000 08:05 241611 /var/cache/fontconfig/945677eb7aeaf62f1d50efc3fb3ec7d8-x86.cache-2 7f836000-7f838000 r-xs 00000000 08:05 241612 /var/cache/fontconfig/99e8ed0e538f840c565b6ed5dad60d56-x86.cache-2 7f838000-7f83b000 r-xs 00000000 08:05 241620 /var/cache/fontconfig/e383d7ea5fbe662a33d9b44caf393297-x86.cache-2 7f83b000-7f846000 r-xs 00000000 08:05 241600 /var/cache/fontconfig/0f34bcd4b6ee430af32735b75db7f02b-x86.cache-2 7f863000-7f866000 ---p 00000000 00:00 0 7f866000-7f8b4000 rwxp 00000000 00:00 0 7f8b4000-7f8b7000 ---p 00000000 00:00 0 7f8b7000-7f905000 rwxp 00000000 00:00 0 7f905000-7f909000 r-xp 00000000 08:05 5012 /usr/lib/libXfixes.so.3.1.0 7f909000-7f90a000 r-xp 00003000 08:05 5012 /usr/lib/libXfixes.so.3.1.0 7f90a000-7f90b000 rwxp 00004000 08:05 5012 /usr/lib/libXfixes.so.3.1.0 7f90b000-7f913000 r-xp 00000000 08:05 5032 /usr/lib/libXrender.so.1.3.0 7f913000-7f914000 r-xp 00007000 08:05 5032 /usr/lib/libXrender.so.1.3.0 7f914000-7f915000 rwxp 00008000 08:05 5032 /usr/lib/libXrender.so.1.3.0 7f915000-7f91e000 r-xp 00000000 08:05 5004 /usr/lib/libXcursor.so.1.0.2 7f91e000-7f91f000 r-xp 00008000 08:05 5004 /usr/lib/libXcursor.so.1.0.2 7f91f000-7f920000 rwxp 00009000 08:05 5004 /usr/lib/libXcursor.so.1.0.2 7f92f000-7f931000 r-xs 00000000 08:05 241622 /var/cache/fontconfig/f24b2111ab8703b4e963115a8cf14259-x86.cache-2 7f931000-7f932000 r-xs 00000000 08:05 241606 /var/cache/fontconfig/4c73fe0c47614734b17d736dbde7580a-x86.cache-2 7f932000-7f936000 r-xs 00000000 08:05 241599 /var/cache/fontconfig/062808c12e6e608270f93bb230aed730-x86.cache-2 7f936000-7f93e000 r-xs 00000000 08:05 241617 /var/cache/fontconfig/d52a8644073d54c13679302ca1180695-x86.cache-2 7f93e000-7f941000 ---p 00000000 00:00 0 7f941000-7f98f000 rwxp 00000000 00:00 0 7f98f000-7fa0e000 r-xp 00000000 08:05 34755 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/libfontmanager.so 7fa0e000-7fa19000 rwxp 0007e000 08:05 34755 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/libfontmanager.so 7fa19000-7fa1d000 rwxp 00000000 00:00 0 7fa1d000-7fa21000 r-xp 00000000 08:05 5008 /usr/lib/libXdmcp.so.6.0.0 7fa21000-7fa22000 rwxp 00003000 08:05 5008 /usr/lib/libXdmcp.so.6.0.0 7fa22000-7fa3e000 r-xp 00000000 08:05 6029 /usr/lib/libxcb.so.1.1.0 7fa3e000-7fa3f000 r-xp 0001c000 08:05 6029 /usr/lib/libxcb.so.1.1.0 7fa3f000-7fa40000 rwxp 0001d000 08:05 6029 /usr/lib/libxcb.so.1.1.0 7fa40000-7fa42000 r-xp 00000000 08:05 4997 /usr/lib/libXau.so.6.0.0 7fa42000-7fa43000 r-xp 00001000 08:05 4997 /usr/lib/libXau.so.6.0.0 7fa43000-7fa44000 rwxp 00002000 08:05 4997 /usr/lib/libXau.so.6.0.0 7fa44000-7fb6e000 r-xp 00000000 08:05 4991 /usr/lib/libX11.so.6.2.0 7fb6e000-7fb6f000 ---p 0012a000 08:05 4991 /usr/lib/libX11.so.6.2.0 7fb6f000-7fb70000 r-xp 0012a000 08:05 4991 /usr/lib/libX11.so.6.2.0 7fb70000-7fb72000 rwxp 0012b000 08:05 4991 /usr/lib/libX11.so.6.2.0 7fb72000-7fb73000 rwxp 00000000 00:00 0 7fb73000-7fb81000 r-xp 00000000 08:05 5010 /usr/lib/libXext.so.6.4.0 7fb81000-7fb82000 r-xp 0000d000 08:05 5010 /usr/lib/libXext.so.6.4.0 7fb82000-7fb83000 rwxp 0000e000 08:05 5010 /usr/lib/libXext.so.6.4.0 7fb83000-7fb84000 r-xs 00000000 08:05 241614 /var/cache/fontconfig/c05880de57d1f5e948fdfacc138775d9-x86.cache-2 7fb84000-7fb87000 r-xs 00000000 08:05 241613 /var/cache/fontconfig/a755afe4a08bf5b97852ceb7400b47bc-x86.cache-2 7fb87000-7fb8a000 r-xs 00000000 08:05 241608 /var/cache/fontconfig/6d41288fd70b0be22e8c3a91e032eec0-x86.cache-2 7fb8a000-7fb92000 r-xs 00000000 08:05 219560 /var/cache/fontconfig/e13b20fdb08344e0e664864cc2ede53d-x86.cache-2 7fb92000-7fbd5000 r-xp 00000000 08:05 34752 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/xawt/libmawt.so 7fbd5000-7fbd7000 rwxp 00043000 08:05 34752 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/xawt/libmawt.so 7fbd7000-7fbd8000 rwxp 00000000 00:00 0 7fbd8000-7fc5c000 r-xp 00000000 08:05 34750 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/libawt.so 7fc5c000-7fc63000 rwxp 00084000 08:05 34750 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/libawt.so 7fc63000-7fc87000 rwxp 00000000 00:00 0 7fc87000-7fc8a000 ---p 00000000 00:00 0 7fc8a000-7fcd8000 rwxp 00000000 00:00 0 7fcd8000-7fceb000 r-xp 00000000 08:05 34739 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/libnet.so 7fceb000-7fcec000 rwxp 00013000 08:05 34739 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/libnet.so 7fcec000-7fced000 ---p 00000000 00:00 0 7fced000-7fd6d000 rwxp 00000000 00:00 0 7fd6d000-7fd70000 ---p 00000000 00:00 0 7fd70000-7fdbe000 rwxp 00000000 00:00 0 7fdbe000-7fdc1000 ---p 00000000 00:00 0 7fdc1000-7fe3f000 rwxp 00000000 00:00 0 7fe3f000-7fe42000 ---p 00000000 00:00 0 7fe42000-7fec0000 rwxp 00000000 00:00 0 7fec0000-7fec3000 ---p 00000000 00:00 0 7fec3000-7ff11000 rwxp 00000000 00:00 0 7ff11000-7ff18000 r-xs 00000000 08:05 134616 /usr/lib/gconv/gconv-modules.cache 7ff18000-7ff57000 r-xp 00000000 08:05 136279 /usr/lib/locale/en_GB.utf8/LC_CTYPE 7ff57000-7ff5a000 ---p 00000000 00:00 0 7ff5a000-7ffa8000 rwxp 00000000 00:00 0 7ffa8000-7ffab000 ---p 00000000 00:00 0 7ffab000-7fff9000 rwxp 00000000 00:00 0 7fff9000-7fffa000 ---p 00000000 00:00 0 7fffa000-800ad000 rwxp 00000000 00:00 0 800ad000-80243000 r-xs 02fb3000 08:05 34883 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/rt.jar 80243000-80244000 ---p 00000000 00:00 0 80244000-802c4000 rwxp 00000000 00:00 0 802c4000-802c5000 ---p 00000000 00:00 0 802c5000-8034d000 rwxp 00000000 00:00 0 8034d000-80365000 rwxp 00000000 00:00 0 80365000-8037a000 rwxp 00000000 00:00 0 8037a000-804b5000 rwxp 00000000 00:00 0 804b5000-804bd000 rwxp 00000000 00:00 0 804bd000-804d5000 rwxp 00000000 00:00 0 804d5000-804ea000 rwxp 00000000 00:00 0 804ea000-80625000 rwxp 00000000 00:00 0 80625000-8064c000 rwxp 00000000 00:00 0 8064c000-8064f000 rwxp 00000000 00:00 0 8064f000-81650000 rwxp 00000000 00:00 0 81650000-84650000 rwxp 00000000 00:00 0 84650000-87050000 rwxp 00000000 00:00 0 87050000-ae650000 rwxp 00000000 00:00 0 ae650000-b3440000 rwxp 00000000 00:00 0 b3440000-b3a50000 rwxp 00000000 00:00 0 b3a50000-b3a52000 r-xs 00000000 08:05 241602 /var/cache/fontconfig/2c5ba8142dffc8bf0377700342b8ca1a-x86.cache-2 b3a52000-b3a5b000 r-xp 00000000 08:05 5018 /usr/lib/libXi.so.6.0.0 b3a5b000-b3a5c000 r-xp 00008000 08:05 5018 /usr/lib/libXi.so.6.0.0 b3a5c000-b3a5d000 rwxp 00009000 08:05 5018 /usr/lib/libXi.so.6.0.0 b3a5d000-b3a66000 rwxp 00000000 00:00 0 b3a66000-b3b1d000 rwxp 00000000 00:00 0 b3b1d000-b3d5d000 rwxp 00000000 00:00 0 b3d5d000-b6b1d000 rwxp 00000000 00:00 0 b6b1d000-b6b2c000 r-xp 00000000 08:05 34735 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/libzip.so b6b2c000-b6b2e000 rwxp 0000e000 08:05 34735 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/libzip.so b6b2e000-b6b38000 r-xp 00000000 08:05 1042 /lib/tls/i686/cmov/libnss_files-2.10.1.so b6b38000-b6b39000 r-xp 00009000 08:05 1042 /lib/tls/i686/cmov/libnss_files-2.10.1.so b6b39000-b6b3a000 rwxp 0000a000 08:05 1042 /lib/tls/i686/cmov/libnss_files-2.10.1.so b6b3a000-b6b43000 r-xp 00000000 08:05 1055 /lib/tls/i686/cmov/libnss_nis-2.10.1.so b6b43000-b6b44000 r-xp 00008000 08:05 1055 /lib/tls/i686/cmov/libnss_nis-2.10.1.so b6b44000-b6b45000 rwxp 00009000 08:05 1055 /lib/tls/i686/cmov/libnss_nis-2.10.1.so b6b45000-b6b4b000 r-xp 00000000 08:05 1028 /lib/tls/i686/cmov/libnss_compat-2.10.1.so b6b4b000-b6b4c000 r-xp 00005000 08:05 1028 /lib/tls/i686/cmov/libnss_compat-2.10.1.so b6b4c000-b6b4d000 rwxp 00006000 08:05 1028 /lib/tls/i686/cmov/libnss_compat-2.10.1.so b6b4d000-b6b54000 r-xs 00035000 08:05 304369 /home/thomas/workspace/sir13/javaclient/jars/javaclient.jar b6b54000-b6b5c000 rwxs 00000000 08:05 393570 /tmp/hsperfdata_thomas/5065 b6b5c000-b6b6f000 r-xp 00000000 08:05 1020 /lib/tls/i686/cmov/libnsl-2.10.1.so b6b6f000-b6b70000 r-xp 00012000 08:05 1020 /lib/tls/i686/cmov/libnsl-2.10.1.so b6b70000-b6b71000 rwxp 00013000 08:05 1020 /lib/tls/i686/cmov/libnsl-2.10.1.so b6b71000-b6b73000 rwxp 00000000 00:00 0 b6b73000-b6b77000 r-xp 00000000 08:05 5038 /usr/lib/libXtst.so.6.1.0 b6b77000-b6b78000 r-xp 00004000 08:05 5038 /usr/lib/libXtst.so.6.1.0 b6b78000-b6b79000 rwxp 00005000 08:05 5038 /usr/lib/libXtst.so.6.1.0 b6b79000-b6b7f000 r-xp 00000000 08:05 34723 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/native_threads/libhpi.so b6b7f000-b6b80000 rwxp 00006000 08:05 34723 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/native_threads/libhpi.so b6b80000-b6b81000 rwxp 00000000 00:00 0 b6b81000-b6b82000 r-xp 00000000 00:00 0 b6b82000-b6ba5000 r-xp 00000000 08:05 34733 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/libjava.so b6ba5000-b6ba7000 rwxp 00023000 08:05 34733 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/libjava.so b6ba7000-b6bae000 r-xp 00000000 08:05 1733 /lib/tls/i686/cmov/librt-2.10.1.so b6bae000-b6baf000 r-xp 00006000 08:05 1733 /lib/tls/i686/cmov/librt-2.10.1.so b6baf000-b6bb0000 rwxp 00007000 08:05 1733 /lib/tls/i686/cmov/librt-2.10.1.so b6bb0000-b6bb3000 ---p 00000000 00:00 0 b6bb3000-b6c01000 rwxp 00000000 00:00 0 b6c01000-b6c25000 r-xp 00000000 08:05 1016 /lib/tls/i686/cmov/libm-2.10.1.so b6c25000-b6c26000 r-xp 00023000 08:05 1016 /lib/tls/i686/cmov/libm-2.10.1.so b6c26000-b6c27000 rwxp 00024000 08:05 1016 /lib/tls/i686/cmov/libm-2.10.1.so b6c27000-b72f4000 r-xp 00000000 08:05 34724 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/server/libjvm.so b72f4000-b7341000 rwxp 006cc000 08:05 34724 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/server/libjvm.so b7341000-b7765000 rwxp 00000000 00:00 0 b7765000-b78a3000 r-xp 00000000 08:05 967 /lib/tls/i686/cmov/libc-2.10.1.so b78a3000-b78a4000 ---p 0013e000 08:05 967 /lib/tls/i686/cmov/libc-2.10.1.so b78a4000-b78a6000 r-xp 0013e000 08:05 967 /lib/tls/i686/cmov/libc-2.10.1.so b78a6000-b78a7000 rwxp 00140000 08:05 967 /lib/tls/i686/cmov/libc-2.10.1.so b78a7000-b78aa000 rwxp 00000000 00:00 0 b78aa000-b78ac000 r-xp 00000000 08:05 1014 /lib/tls/i686/cmov/libdl-2.10.1.so b78ac000-b78ad000 r-xp 00001000 08:05 1014 /lib/tls/i686/cmov/libdl-2.10.1.so b78ad000-b78ae000 rwxp 00002000 08:05 1014 /lib/tls/i686/cmov/libdl-2.10.1.so b78ae000-b78b5000 r-xp 00000000 08:05 34734 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/jli/libjli.so b78b5000-b78b7000 rwxp 00006000 08:05 34734 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/jli/libjli.so b78b7000-b78b8000 rwxp 00000000 00:00 0 b78b8000-b78cd000 r-xp 00000000 08:05 1081 /lib/tls/i686/cmov/libpthread-2.10.1.so b78cd000-b78ce000 r-xp 00014000 08:05 1081 /lib/tls/i686/cmov/libpthread-2.10.1.so b78ce000-b78cf000 rwxp 00015000 08:05 1081 /lib/tls/i686/cmov/libpthread-2.10.1.so b78cf000-b78d1000 rwxp 00000000 00:00 0 b78d1000-b78d2000 r-xs 00000000 08:05 161622 /var/cache/fontconfig/4794a0821666d79190d59a36cb4f44b5-x86.cache-2 b78d2000-b78d4000 r-xs 00000000 08:05 241610 /var/cache/fontconfig/7ef2298fde41cc6eeb7af42e48b7d293-x86.cache-2 b78d4000-b78df000 r-xp 00000000 08:05 34732 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/libverify.so b78df000-b78e0000 rwxp 0000b000 08:05 34732 /usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/libverify.so b78e0000-b78e2000 rwxp 00000000 00:00 0 b78e2000-b78e3000 r-xp 00000000 00:00 0 [vdso] b78e3000-b78fe000 r-xp 00000000 08:05 64 /lib/ld-2.10.1.so b78fe000-b78ff000 r-xp 0001a000 08:05 64 /lib/ld-2.10.1.so b78ff000-b7900000 rwxp 0001b000 08:05 64 /lib/ld-2.10.1.so bfc33000-bfc48000 rwxp 00000000 00:00 0 [stack] VM Arguments: jvm_args: -Dfile.encoding=UTF-8 java_command: Main Launcher Type: SUN_STANDARD Environment Variables: PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games USERNAME=thomas LD_LIBRARY_PATH=/usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/server:/usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386:/usr/lib/jvm/java-6-sun-1.6.0.15/jre/../lib/i386:/usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386/client:/usr/lib/jvm/java-6-sun-1.6.0.15/jre/lib/i386:/usr/lib/xulrunner-addons:/usr/lib/xulrunner-addons SHELL=/bin/bash DISPLAY=:0.0 Signal Handlers: SIGSEGV: [libjvm.so+0x650690], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGBUS: [libjvm.so+0x650690], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGFPE: [libjvm.so+0x52f580], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGPIPE: [libjvm.so+0x52f580], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGXFSZ: [libjvm.so+0x52f580], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGILL: [libjvm.so+0x52f580], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000 SIGUSR2: [libjvm.so+0x532170], sa_mask[0]=0x00000004, sa_flags=0x10000004 SIGHUP: [libjvm.so+0x531ea0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGINT: [libjvm.so+0x531ea0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGTERM: [libjvm.so+0x531ea0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 SIGQUIT: [libjvm.so+0x531ea0], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004 --------------- S Y S T E M --------------- OS:squeeze/sid uname:Linux 2.6.31-20-generic #57-Ubuntu SMP Mon Feb 8 09:05:19 UTC 2010 i686 libc:glibc 2.10.1 NPTL 2.10.1 rlimit: STACK 8192k, CORE 0k, NPROC infinity, NOFILE 1024, AS infinity load average:1.07 0.55 0.23 CPU:total 2 (2 cores per cpu, 1 threads per core) family 6 model 15 stepping 13, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3 Memory: 4k page, physical 3095836k(1519972k free), swap 1261060k(1261060k free) vm_info: Java HotSpot(TM) Server VM (14.1-b02) for linux-x86 JRE (1.6.0_15-b03), built on Jul 2 2009 15:49:13 by "java_re" with gcc 3.2.1-7a (J2SE release) time: Mon Mar 22 12:08:40 2010 elapsed time: 21 seconds

    Read the article

  • Unable to jstat WebSphere Application Server PID

    - by Nicholas Key
    Hi stackoverflow'ers, I've spent the entire day trying to find relevant resources about doing jstat on the WebSphere Process ID. I have WebSphere Application Server 7.0 installed on Windows 2003. I did this command: jstat -gcutil [PID] 1000 But I kept getting "[PID] not found" message. Any idea how to resolve this issue? Or Java's jstat utility does not probe into IBM's derivative JVM? Nicholas

    Read the article

  • Automated testing in Android development

    - by Sara
    I have an ordinary project with JUnit tests that are connected to the classes in my Android Project. I want my server to run some JUnit tests in my testproject everytime I commit my code from my Android Project. Is there a best practise to do this? So far I only managed to run the tests when they are a part of a while the JUnit tests and Android classes are separated into 2 different projects, since JUnit runs on JVM and Android in an emulator on DVM (Dalvik Virtual Machine).

    Read the article

  • Sun permgen & JRockit garbage collection

    - by Striker
    In the Sun JVM, classes that are loaded by the class loader are put in permgen space and never gc'd. (Unless the class loader goes out of scope) It's my understanding that JRockit puts that same data on the heap instead. Is that data then subject to garbage collection? Thanks.

    Read the article

  • one high-end server with one Application Server or multiple Application Servers?

    - by elgcom
    If I have a high-end server, for example with 1T memory and 8x4core CPU... will it bring more performance if I run multiple App Server (on different JVM) rather than just one App Server? On App Server I will run some services (EAR whith message driven beans) which exchange message with each other. btw, has java 64bit now no memory limitation any more? http://java.sun.com/products/hotspot/whitepaper.html#64

    Read the article

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

< Previous Page | 5 6 7 8 9 10 11 12 13 14 15 16  | Next Page >