From commits-return-31203-apmail-harmony-commits-archive=harmony.apache.org@harmony.apache.org Wed Mar 21 13:02:53 2007 Return-Path: Delivered-To: apmail-harmony-commits-archive@www.apache.org Received: (qmail 45740 invoked from network); 21 Mar 2007 13:02:53 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 21 Mar 2007 13:02:53 -0000 Received: (qmail 73262 invoked by uid 500); 21 Mar 2007 13:03:01 -0000 Delivered-To: apmail-harmony-commits-archive@harmony.apache.org Received: (qmail 73225 invoked by uid 500); 21 Mar 2007 13:03:00 -0000 Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@harmony.apache.org Delivered-To: mailing list commits@harmony.apache.org Received: (qmail 73212 invoked by uid 99); 21 Mar 2007 13:03:00 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Mar 2007 06:03:00 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Mar 2007 06:02:52 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 4D22071403C for ; Wed, 21 Mar 2007 06:02:32 -0700 (PDT) Message-ID: <22723481.1174482152312.JavaMail.jira@brutus> Date: Wed, 21 Mar 2007 06:02:32 -0700 (PDT) From: "Aleksey Ignatenko (JIRA)" To: commits@harmony.apache.org Subject: [jira] Commented: (HARMONY-3462) [dlrvm] new j.l.Class tracing model In-Reply-To: <29738079.1174481252417.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/HARMONY-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12482747 ] Aleksey Ignatenko commented on HARMONY-3462: -------------------------------------------- Checked with GCv4.1 and GCv5. Importent! - GCv5 specifics: GCv5 does not implement gc_add_weak_root_set_entry function (used in vm_enumerate_weak_root_reference). Therefore enumeration as weak reference is not available. For the first sight it is not to be able to work with GCv5, But drlvm redirects gc_add_weak_root_set_entry fucntion to default one which is gc_add_root_set_entry (as a result j.l.Classes are always reachable - added to rootset as strong references + traced by GC via j.l.Classloader), therefore GCv5 works fine with the patch, but class unloading is not implementable on it untill it supports gc_add_weak_root_set_entry function. > [dlrvm] new j.l.Class tracing model > ----------------------------------- > > Key: HARMONY-3462 > URL: https://issues.apache.org/jira/browse/HARMONY-3462 > Project: Harmony > Issue Type: Improvement > Components: DRLVM > Reporter: Aleksey Ignatenko > Attachments: new_class_registry_v7.patch > > > The jira introduces new model of j.l.Class referencing into drlvm. > The current model is: > all j.l.Classes (JLC) and j.l.Classloaders (JLCL) are enumerated as strong references inside drlvm. It means that all JLC and JLCL are always reachable and we can not track any referencing between classes and classloaders automatically by GC. > The new model is required by clas unloading (independent of class unloading design). Lets name term "class registry" as - JLCL refers to its JLC and JLC refer to their defining JLCL (phisically via valid references). This requirement comes from the statement that classloader and all classes loaded by it are to be unloaded at once. e.g. Robin-Salikh approach requires that only JLCL are enumerated then JLC are to be traced automatically by GC (via references in appropriate JLCL - right now there is no direct reference to JLC in JLCL and vice versa). > The patch new_class_registry_v7.patch introduces the direct references described above. Also, it changes enumeration model: from now all JLC are traced via JLCL. JLC references are enumerated as weak references now (to be updated by GC). > Also destination of m_loadedClasses and m_reportedClasses has changed. For now m_loadedClasses is responsible for weak enumeration of all loaded UserDefined j.l.Classes and m_reportedClasses is responsible for enumeration of all bootstrap classes and userdefined classes (untill they are added to class registry) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.