Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <901154.1179933916908.JavaMail.jira@brutus>
Date: Wed, 23 May 2007 08:25:16 -0700 (PDT)
From: "Chunrong Lai (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Commented: (HARMONY-3462) [dlrvm][classloader][unloading]
 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


    [ https://issues.apache.org/jira/browse/HARMONY-3462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12498267 ] 

Chunrong Lai commented on HARMONY-3462:
---------------------------------------


 I tested the patch but did not see classes are unloaded.
 I also see the j.l.Classes are reachable (marked) from j.l.Classloader via the field loadedClasses.
 Maybe you can show me an overall picture about class unloading and some test cases? I need them to understand what to implement in GC (include the weak roots support of course) to unloaded the classes.
 Thank you very much.

> [dlrvm][classloader][unloading] 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
>         Assigned To: Gregory Shimansky
>         Attachments: new_class_registry_v7.patch, new_class_registry_v8.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.