March 2009 - hotspot-gc-dev

Re: Java6 vs Java5
by Clemens Eisserer 30 Mar '09

30 Mar '09

Hi, > --- My rationale? Saving the designers from fixing problem properly :-) > I agree completely if there was some magic option to do this the end result > would be I'd be end up "reserving" (aka wasting) X amount of memory that > I would never ever use. But to what end? What problem do you intend to resolv with that? I can't imagine situations where this could help. - Clemens _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use(a)openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

1 0

hg: jdk7/hotspot-gc/hotspot: 6819891: ParNew: Fix work queue overflow code to deal correctly with +UseCompressedOops
by y.s.ramakrishna＠sun.com 29 Mar '09

29 Mar '09

Changeset: cea947c8a988 Author: ysr Date: 2009-03-28 15:47 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/cea947c8a988 6819891: ParNew: Fix work queue overflow code to deal correctly with +UseCompressedOops Summary: When using compressed oops, rather than chaining the overflowed grey objects' pre-images through their klass words, we use GC-worker thread-local overflow stacks. Reviewed-by: jcoomes, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/runtime/globals.hpp

1 0

Re: Java6 vs Java5
by Jon Masamitsu 27 Mar '09

27 Mar '09

Shaun Hennessy wrote On 03/27/09 11:20,: >A few quick questions I'm hoping someone can help me with... >(I'm running Java6u12) > >1) Is there any plans for the new option >CMSInitiatingPermOccupancyFraction (CR 6634032) >to put into Java6? (The fixed in listed as hs13(b01) - I'm not sure >what this is - Java7?) > > This change will make it to a 6 update. Probably 6u14. >2) Was there a change in the default CMS initiating occupancy from Java5 >to Java6 (68% to 92%) >when using CMS? > > Unless explicitly set on the command line the initiating occupancy is calculated from other parameters (MinHeapFreeRatio and MinHeapFreeRatio) and I don't think those latter changed between 5 and 6. Other CMS parameters changed. http://java.sun.com/javase/6/docs/technotes/guides/vm/cms-6.html >3a) If using the Throughput GC -- our old-gen will be triggered when >it's full right? There's no need >to have it go earlier as we're going to stop-the-world.... Nothing >would be different java5 vs java6? > > Yes, with the throughput collector (and indeed with all the stop the world (aka STW) collectors), a collection is started when a generation is full. >3b) - If I am going to the throughput collector, is there anyway to >force the application to keep >a certain amount of the heap free (ie -Xms=Xms=256M --) I always want to >get say 100M free >so once the free heap drop to that level trigger a GC? (Basically I >want a CmsInitiatingOccupancyFraction >but for the throughput collector) > > There is no JVM option that will allow you to request that a certain amount be kept free with the STW collectors. > > > _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use(a)openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

2 2

Re: Time stopped is much longer than corresponding Full GC
by Y.S.Ramakrishna＠Sun.COM 27 Mar '09

27 Mar '09

Hi Alex -- The bug tracking system informs me that 6546278 was fixed in 5u14 which you appear to be using here. This could be a different problem or an aspect of the original problem that was somehow not addressed by the fix in 6546278. I am cc'ing you over to the hotspot-runtime-dev alias where the necessary expertise exists to address this issue. I suggest of course checking if you can reproduce this problem with the latest 5uXX, as well as, if possible, the latest OpenJDK 7 JVM. In either event (i.e. if you can reproduce the problem with either of the latest jvm's listed) please file a bug with Sun, preferably through your official support channels for quickest resolution especially when older JDK versions are involved. The following additional information may be useful: (1) the additional JVM option -XX:+PrintSafepointStatistics for more visibility into the issue (2) whether you have lots of native/JNI code in your application. (3) It is interesting (and puzzling) that you see the issue only with the 64-bit JVM. Are all other factors equivalent between your 32 and 64-bit tests? thanks. -- ramki On 03/27/09 09:32, Alex Aisinzon wrote: > Hi all > > > > I am running tests with Sun JDK 1.5_14 32 and 64 bits. I am using > ParallelGC with 2 threads on a Dual Core Opteron 280. > > On the 64 bit one, I see instances whereby the pause times, as reported > by the “Total time for which application threads were stopped:” is much > longer than the time reported for the full GC. > > > > Here is an example of this: > > > > /{Heap before gc invocations=3693:/ > > / PSYoungGen total 2021952K, used 55892K [0x00002aabbf130000, > 0x00002aac3f130000, 0x00002aac3f130000)/ > > / eden space 1949248K, 0% used > [0x00002aabbf130000,0x00002aabbf130000,0x00002aac360c0000)/ > > / from space 72704K, 76% used > [0x00002aac3a7a0000,0x00002aac3de353b0,0x00002aac3eea0000)/ > > / to space 72576K, 0% used > [0x00002aac360c0000,0x00002aac360c0000,0x00002aac3a7a0000)/ > > / PSOldGen total 4194304K, used 4144351K [0x00002aaabf130000, > 0x00002aabbf130000, 0x00002aabbf130000)/ > > / object space 4194304K, 98% used > [0x00002aaabf130000,0x00002aabbc067c20,0x00002aabbf130000)/ > > / PSPermGen total 204800K, used 122025K [0x00002aaab2930000, > 0x00002aaabf130000, 0x00002aaabf130000)/ > > / object space 204800K, 59% used > [0x00002aaab2930000,0x00002aaaba05a578,0x00002aaabf130000)/ > > /29132.202: [Full GC [PSYoungGen: 55892K->0K(2021952K)] [PSOldGen: > 4144351K->2185260K(4194304K)] 4200243K->2185260K(6216256K) [PSPermGen: > 122025K->122025K(204800K)], 7.8002190 secs]/ > > /Heap after gc invocations=3693:/ > > / PSYoungGen total 2021952K, used 0K [0x00002aabbf130000, > 0x00002aac3f130000, 0x00002aac3f130000)/ > > / eden space 1949248K, 0% used > [0x00002aabbf130000,0x00002aabbf130000,0x00002aac360c0000)/ > > / from space 72704K, 0% used > [0x00002aac3a7a0000,0x00002aac3a7a0000,0x00002aac3eea0000)/ > > / to space 72576K, 0% used > [0x00002aac360c0000,0x00002aac360c0000,0x00002aac3a7a0000)/ > > / PSOldGen total 4194304K, used 2185260K [0x00002aaabf130000, > 0x00002aabbf130000, 0x00002aabbf130000)/ > > / object space 4194304K, 52% used > [0x00002aaabf130000,0x00002aab4473b2a8,0x00002aabbf130000)/ > > / PSPermGen total 204800K, used 122025K [0x00002aaab2930000, > 0x00002aaabf130000, 0x00002aaabf130000)/ > > / object space 204800K, 59% used > [0x00002aaab2930000,0x00002aaaba05a578,0x00002aaabf130000)/ > > /}/ > > /Total time for which application threads were stopped: 15.2489360 seconds/ > > /Application time: 7.2144290 seconds/ > > > > > > I checked on the web and see descriptions of very similar behaviors: > > * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6477891 > * http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6546278 > > > > It remains unclear whether this is fixed in a later release of Sun JDK 1.5. > > If it is indeed the “ > <http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6546278>Synchronization > problem in the pseudo memory barrier code”. It may be fixed on JDK 1.7: > http://download.java.net/jdk7/changes/jdk7-b15.html > > > > Our application is currently supported on Sun JDK 1.5 so Sun JDK 1.6 and > 1.7, when available, do not constitute good options. > > Should I try to upgrade to the latest of Sun JDK 1.5 or are there > “switches” that could make this go away, without sacrificing performance. > > The thing that surprises me most is that is, so far, it occurs only on > the 64 bit JVM version. > > > > Thanks for letting me know > > > > Alex Aisinzon > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > hotspot-gc-use mailing list > hotspot-gc-use(a)openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use(a)openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use

1 0

hg: jdk7/hotspot-gc/hotspot: 6822263: G1: JVMTI heap iteration fails
by igor.veresov＠sun.com 26 Mar '09

26 Mar '09

Changeset: 4ac7d97e6101 Author: iveresov Date: 2009-03-26 08:51 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/4ac7d97e6101 6822263: G1: JVMTI heap iteration fails Summary: Make object_iterate() traverse the perm gen Reviewed-by: apetrusenko, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp

1 0

hg: jdk7/hotspot-gc/hotspot: 6543938: G1: remove the concept of popularity
by andrey.petrusenko＠sun.com 25 Mar '09

25 Mar '09

Changeset: 96b229c54d1e Author: apetrusenko Date: 2009-03-25 13:10 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/96b229c54d1e 6543938: G1: remove the concept of popularity Reviewed-by: iveresov, tonyp ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.hpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/runtime/vm_operations.hpp

1 0

Request for review(S): 6822263 G1: JVMTI heap iteration fails
by Igor Veresov 25 Mar '09

25 Mar '09

JVMTI reachable objects iteration functions use a call to object_iterate() to clean the marking bits of the objects (it uses marking bits to track the vertices of the object graph that it visits). The semantics of the object_iterate() include iteration over the perm gen. However G1 doesn't do that. The fix is to include the perm gen objects in the iterable set. Webrev: http://cr.openjdk.java.net/~iveresov/6822263/webrev.00 Testing: Affected nsk tests

1 0

Re: Howto keep track of GC, without letting the monitored object die?
by Tony Printezis 25 Mar '09

25 Mar '09

(resending with the correct CC) Tony Printezis wrote: > Clemens, > > You can use WeakReferences. Have a look at this article: > > http://java.sun.com/developer/technicalArticles/javase/finalization/ > > In particular, the An Alternative To Finalization section. > > Tony > > Clemens Eisserer wrote: >> Hello, >> >> First of all sorry for beeing off-topic. >> I am developing a distributed object system, where I need to keep >> track wether an Object is still referenced, without actually let it >> die. >> Only if server- and client-side object are no longer referenced, they >> both may be freed by the GC. >> >> With finalizers I would be able to do something like this: >> >> class SharedObject { >> private Object gcMonitor = new Object() { >> protected void finalize() { >> RefernceManager.addStrongReference(SharedObject.this); >> Server.objectUnreferenced(SharedObject.this); >> } >> } >> } >> >> Once the server knows both parts are unreferenced, it can release all >> strong references and the object can be reclaimed by the GC. >> >> However I fear that this would really stress the jvm. Is it possible >> to archive the same using References and ReferenceQueues? >> Are there patterns which make the knowledge about the object obsolete? >> >> Thanks, Clemens >> > -- --------------------------------------------------------------------- | Tony Printezis, Staff Engineer | Sun Microsystems Inc. | | | MS UBUR02-311 | | e-mail: tony.printezis(a)sun.com | 35 Network Drive | | office: +1 781 442 0998 (x20998) | Burlington, MA 01803-2756, USA | --------------------------------------------------------------------- e-mail client: Thunderbird (Linux)

2 2

hg: jdk7/hotspot-gc/hotspot: 8 new changesets
by antonios.printezis＠sun.com 25 Mar '09

25 Mar '09

Changeset: 6af0a709d52b Author: twisti Date: 2009-03-11 14:16 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/6af0a709d52b 6812587: Use auxv to determine SPARC hardware features on Solaris Summary: A similar function to getisax(2) should be used to determine all possible instruction set extensions. Reviewed-by: never, kvn ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/solaris/vm/os_solaris.hpp ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/includeDB_core Changeset: 660978a2a31a Author: kvn Date: 2009-03-12 10:37 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/660978a2a31a 6791178: Specialize for zero as the compressed oop vm heap base Summary: Use zero based compressed oops if java heap is below 32gb and unscaled compressed oops if java heap is below 4gb. Reviewed-by: never, twisti, jcoomes, coleenp ! agent/src/share/classes/sun/jvm/hotspot/debugger/Debugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/DebuggerBase.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/JVMDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebugger.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerClient.java ! agent/src/share/classes/sun/jvm/hotspot/debugger/remote/RemoteDebuggerServer.java ! agent/src/share/classes/sun/jvm/hotspot/memory/Universe.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/VM.java ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_64.ad ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/os/solaris/dtrace/libjvm_db.c ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_sparc/vm/globals_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/globals_linux_x86.hpp ! src/os_cpu/solaris_sparc/vm/globals_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/globals_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/globals_windows_x86.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/runtime/virtualspace.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c771b7f43bbf Author: twisti Date: 2009-03-13 11:35 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c771b7f43bbf 6378821: bitCount() should use POPC on SPARC processors and AMD+10h Summary: bitCount() should use POPC on SPARC processors where POPC is implemented directly in hardware. Reviewed-by: kvn, never ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/sparc/vm/vm_version_sparc.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/solaris_sparc/vm/vm_version_solaris_sparc.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/connode.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/runtime/globals.hpp + test/compiler/6378821/Test6378821.java Changeset: c517646eef23 Author: jrose Date: 2009-03-13 18:39 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c517646eef23 6813212: factor duplicated assembly code for general subclass check (for 6655638) Summary: Code in interp_masm, stubGenerator, c1_LIRAssembler, and AD files moved into MacroAssembler. Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/stubGenerator_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/graphKit.cpp Changeset: c3a720eefe82 Author: kvn Date: 2009-03-16 15:06 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/c3a720eefe82 6816308: Changes to allow builds with latest Windows SDK 6.1 on 64bit Windows 2003 Summary: Allow Hotspot builds with latest Windows SDK 6.1 on 64bit Windows 2003 Reviewed-by: ohair, tbell, jcoomes ! make/windows/get_msc_ver.sh ! make/windows/makefiles/compile.make ! make/windows/makefiles/sa.make ! make/windows/makefiles/sanity.make ! src/cpu/x86/vm/interpreterRT_x86_64.cpp ! src/os_cpu/windows_x86/vm/unwind_windows_x86.hpp ! src/share/vm/adlc/adlc.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/memory/blockOffsetTable.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/globalDefinitions_visCPP.hpp Changeset: 039a914095f4 Author: kvn Date: 2009-03-18 13:25 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/039a914095f4 6772368: REGRESSION:tomcat crashed twice with JDK 7 Summary: Call make_block_at() with the original handler limits. Reviewed-by: never ! src/share/vm/ci/ciMethodBlocks.cpp Changeset: bd441136a5ce Author: kvn Date: 2009-03-19 09:13 -0700 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/bd441136a5ce Merge ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/includeDB_core ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp Changeset: 59f139e8a8d1 Author: tonyp Date: 2009-03-25 10:36 -0400 URL: http://hg.openjdk.java.net/jdk7/hotspot-gc/hotspot/rev/59f139e8a8d1 Merge

1 0

Howto keep track of GC, without letting the monitored object die?
by Clemens Eisserer 25 Mar '09

25 Mar '09

Hello, First of all sorry for beeing off-topic. I am developing a distributed object system, where I need to keep track wether an Object is still referenced, without actually let it die. Only if server- and client-side object are no longer referenced, they both may be freed by the GC. With finalizers I would be able to do something like this: class SharedObject { private Object gcMonitor = new Object() { protected void finalize() { RefernceManager.addStrongReference(SharedObject.this); Server.objectUnreferenced(SharedObject.this); } } } Once the server knows both parts are unreferenced, it can release all strong references and the object can be reclaimed by the GC. However I fear that this would really stress the jvm. Is it possible to archive the same using References and ReferenceQueues? Are there patterns which make the knowledge about the object obsolete? Thanks, Clemens

1 0