Re: [Arch] Class unloading and VM objects reclaim
El jue, 08-09-2005 a las 15:51 +0100, Peter Edworthy escribió: (...snip...) [long version] Cleaning up Strings that are only used in a particular classloader has a slight catch; because of the 'Strings containing the same characters are the same object' clause. This requires keeping a list of all currently created String objects that is checked at String object creation time to see if a reference to an existing object should be used or a new String object created. This list has to be outside of the gc link checking or no String would be gc'ed, but the list must also be informed when a String is gc'ed so as to remove it. IIRC, the (JVM spec v2) requirement for .equals String literals to be (==)identical only holds for Strings in the same .class file, but I could be wrong. In any case, interning all VM Strings in some sort of global weak set would do the trick, as shared literals would remain referenced on classloader collection, while unreferenced ones would be eligible for collection. This is typically how symbols in lisp or smalltalk are managed (most implementations don't even bother to use a weak structure, so symbols are never collected). Basically this is what String.intern() does, and nothing impedes us to actually use it for all Strings in the VM. Regards Santiago -- VP and Chair, Apache Portals (http://portals.apache.org) Apache Software Foundation signature.asc Description: This is a digitally signed message part
Re: [arch] voluntary vs. preemptive suspension of Java threads
I was wondering what similarities on-stack replacement of JITed code have with suspension with code patching. On 9/9/05, Xiao-Feng Li [EMAIL PROTECTED] wrote: Thanks, Rodrigo and Shudo. ORP had a similar approach as code patching previously, which we called IP hijacking. We found, as you observed, it had some difficulties in maintenance and portability. I classified this approach into the preemptive category. I suspect a given thread suspension algorithm will have different performance characteristics depending on processor architecture, and garbage collection algorithm as well. It deserves more study. Since the two approaches are not much conflicting, I suggest implementing voluntary mechanism at first for its cleanness and portability for the first few releases of Harmony. Thanks, xiaofeng == Intel Managed Runtime Division On 9/1/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: From: Xiao-Feng Li [EMAIL PROTECTED] Thread suspension happens in many situations in JVM, such as for GC, for java.lang.Thread.suspend(), etc. There are various techniques to suspend a thread. Basically we can classify them into two categories: preemptive and voluntary. The preemptive approach requires the suspender, say a GC thread, suspend the execution of a target thread asynchronously with IPC mechanism or OS APIs. If the suspended thread happened to be in a region of code (Java or native) that could be enumerated, the live references were collected. This kind of region is called safe-region, and the suspended point is a safe-point. If the suspended point is not in safe-region, the thread would be resumed and stopped again until it ended up in a safe-region randomly or on purpose. Sun's HotSpot VMs patch compiled native code to stop thread at the safe points, on which a stack map is provided. It's smart but prone to causes subtle problems, an engineer working on the VM said. Kazuyuki Shudo[EMAIL PROTECTED] http://www.shudo.net/
Re: [Arch] Class unloading and VM objects reclaim
Santiago Gala wrote: IIRC, the (JVM spec v2) requirement for .equals String literals to be (==)identical only holds for Strings in the same .class file, but I could be wrong. I believe the requirement is stronger than that. Any two String literals (i.e., String constants from class files) that are the same string must be the same object (==). It doesn't matter if they come from different classes. In any case, interning all VM Strings in some sort of global weak set would do the trick, as shared literals would remain referenced on classloader collection, while unreferenced ones would be eligible for collection. This is typically how symbols in lisp or smalltalk are managed (most implementations don't even bother to use a weak structure, so symbols are never collected). Basically this is what String.intern() does, and nothing impedes us to actually use it for all Strings in the VM. This is how Classpath works. Strings are intern'd using a weak hash map and String.intern() is implemented in pure Java. The JVM does nothing special for strings, with the exception that when it creates them from class files it also interns them. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
This week on harmony-dev (Sept. 04 - Sept. 10 2005)
Mladen Turk responded to the concerns by Weldon Washburn about the light-weight native calls in the thread VM/Classlibrary Interface (take 2). He explained in more detail how he thinks those light-weight calls could work, they should avoid the overhead for native calls. Mladen and Tim Ellison then discussed what this means for the native methods which are called (for example, they would not be allowed to allocate objects on the heap). Such light-weight native calls could pontentially speed up the class library since often native calls don't need to create any objects (or use other operations which would be disallowd by the light-weight model). [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Also in the [arch] VM/Classlibrary Interface (take 2) - thread, Tim Ellison explained how the interface between their class libraries and a JVM works. These class libraries are a subset of SE and have been independently developed. They are designed to be portable across VM implementations but have been principally written against the J9 VM. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Tim Ellison posted in the thread [arch] VM/Classlibrary Interface ( VM Accessors ) that VM Accessors would be some kind of classlibrary developer's toolkit and could allow implementation of functionality in pure Java which would otherwise require a native implementation. He also mentions that the list of accessors Rana Dasgupta wrote is a blend of functional enhancements and optimization enhancements. The security concerns for these accessors could be solved by the componentization of the class library. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Sombody at roomity.com announced that GNU Classpath 0.18 has been released. In the discussion in this thread, Mark Wielaard told us that since the start of harmony the number of contributions a day to GNU Classpath have tripled and and a little bit more about the release. He also mentioned that the classpath/harmony sister projects will release an updated version soon. Robert Lougher posted that JamVM from CVS works with classpath 0.18 'out of the box' on Linux now. There was also some discussion about porting Kaffe to PSP and XBox 360, but I guess this will be continued in the Kaffe project. Dalibor Topic, Tom Tromey and I where involved in this discussion too. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Xiao-Feng Li started a thread called [Arch] Class unloading and VM objects reclaim, where he discribes 2 approaches how to unload a class. One approach would encode VM objects similar to app objects, so they can be reclaimed by the GC, the other treats class unloading specially and reclaims the memory with the class loader. Archie Cobbs said that you can have the benefits of both approaches by having a per-class loader memory area, but Xiao-Feng wrote that this looks like the second one he suggested. There was also some discussion about situations where objects (especially strings) could not be relclaimed with these approaches and how to solve this, Peter Edworthy and Santiago Gala posted some interesting facts on this topic too. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] In the thread [arch] voluntary vs. preemptive suspension of Java threads Xiao-Feng Li posted that they had some difficulties in maintenance and portability with code patching (i.e. the VM patching compiled code at save points to stop a thread). He suggests we implement both approaches (preemtive and voluntary, voluntary first) for further study since the two approaches are not much conflicting. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Regards, David. -- Read the archive of this series at http://deltalabs.at/ -- RSS feed: http://deltalabs.at/?q=taxonomy/term/8/0/feed -- Also aggregated at: http://planet.classpath.org/ -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- AUFGABEN DER PHYSIK -- QUANTENMECHANIK Gegebene Konstante: m(Kuh)=400 kg Die Kuh befinde sich auf einer Weide, die ringsum durch einen Zaun abgegrenzt ist. Der Weidezaun sie ideal gebaut, sodass die Kuh ihn (klassich gesehen) nicht passieren kann. Begrnden Sie, dass man die Kuh trotzdem mit gewisser Wahrscheinlichkeit ausserhalb der Weide antrifft.
