You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Chunrong Lai (JIRA)" <ji...@apache.org> on 2007/07/19 04:12:04 UTC
[jira] Created: (HARMONY-4494) VM modification for class unloading
VM modification for class unloading
-----------------------------------
Key: HARMONY-4494
URL: https://issues.apache.org/jira/browse/HARMONY-4494
Project: Harmony
Issue Type: Sub-task
Components: VM
Environment: win32
Reporter: Chunrong Lai
The patch is not intended for commit but only for review purpose.
I did them in VM side (to SVN HEAD) to test the GCv5's CU work where the references from native heap to java heap (m_loader, m_class_handle, vtable->jIC) are enumerated as weak roots at certain time. Then GCv5 will trace the strong roots and update the weak roots.
Currently the intergated version can pass smoke test, specjbb and several other benchmarks. It also successfully unloaded the classloaders when running the test case in "Test_unloading_native_lib.zip".
There are two more issues:
(1) Attached is just an unconditional-unloading approach. Extra interfaces are needed to achieve selective unloading.
(2) Some code refinements need to be done if running in 64bits environment since GC and VM use different code conventions to compress the references. If VM use the uncompressed "ManagedObject* vtable->jIC" as in the attachment we only need enhance GC in future.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4494) VM modification for class
unloading
Posted by "Pavel Pervov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513905 ]
Pavel Pervov commented on HARMONY-4494:
---------------------------------------
I mean VTable->jlC...
> VM modification for class unloading
> -----------------------------------
>
> Key: HARMONY-4494
> URL: https://issues.apache.org/jira/browse/HARMONY-4494
> Project: Harmony
> Issue Type: Sub-task
> Components: VM
> Environment: win32
> Reporter: Chunrong Lai
> Attachments: classunloading.vm.diff
>
>
> The patch is not intended for commit but only for review purpose.
> I did them in VM side (to SVN HEAD) to test the GCv5's CU work where the references from native heap to java heap (m_loader, m_class_handle, vtable->jIC) are enumerated as weak roots at certain time. Then GCv5 will trace the strong roots and update the weak roots.
> Currently the intergated version can pass smoke test, specjbb and several other benchmarks. It also successfully unloaded the classloaders when running the test case in "Test_unloading_native_lib.zip".
> There are two more issues:
> (1) Attached is just an unconditional-unloading approach. Extra interfaces are needed to achieve selective unloading.
> (2) Some code refinements need to be done if running in 64bits environment since GC and VM use different code conventions to compress the references. If VM use the uncompressed "ManagedObject* vtable->jIC" as in the attachment we only need enhance GC in future.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4494) VM modification for class unloading
Posted by "Chunrong Lai (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chunrong Lai updated HARMONY-4494:
----------------------------------
Attachment: classunloading.vm.diff
> VM modification for class unloading
> -----------------------------------
>
> Key: HARMONY-4494
> URL: https://issues.apache.org/jira/browse/HARMONY-4494
> Project: Harmony
> Issue Type: Sub-task
> Components: VM
> Environment: win32
> Reporter: Chunrong Lai
> Attachments: classunloading.vm.diff
>
>
> The patch is not intended for commit but only for review purpose.
> I did them in VM side (to SVN HEAD) to test the GCv5's CU work where the references from native heap to java heap (m_loader, m_class_handle, vtable->jIC) are enumerated as weak roots at certain time. Then GCv5 will trace the strong roots and update the weak roots.
> Currently the intergated version can pass smoke test, specjbb and several other benchmarks. It also successfully unloaded the classloaders when running the test case in "Test_unloading_native_lib.zip".
> There are two more issues:
> (1) Attached is just an unconditional-unloading approach. Extra interfaces are needed to achieve selective unloading.
> (2) Some code refinements need to be done if running in 64bits environment since GC and VM use different code conventions to compress the references. If VM use the uncompressed "ManagedObject* vtable->jIC" as in the attachment we only need enhance GC in future.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4494) VM modification for class
unloading
Posted by "Pavel Pervov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514155 ]
Pavel Pervov commented on HARMONY-4494:
---------------------------------------
(1) Rather misleading. I'd suggest to change or to add comment here.
(3) Ah, I see now.
> VM modification for class unloading
> -----------------------------------
>
> Key: HARMONY-4494
> URL: https://issues.apache.org/jira/browse/HARMONY-4494
> Project: Harmony
> Issue Type: Sub-task
> Components: VM
> Environment: win32
> Reporter: Chunrong Lai
> Attachments: classunloading.vm.diff
>
>
> The patch is not intended for commit but only for review purpose.
> I did them in VM side (to SVN HEAD) to test the GCv5's CU work where the references from native heap to java heap (m_loader, m_class_handle, vtable->jIC) are enumerated as weak roots at certain time. Then GCv5 will trace the strong roots and update the weak roots.
> Currently the intergated version can pass smoke test, specjbb and several other benchmarks. It also successfully unloaded the classloaders when running the test case in "Test_unloading_native_lib.zip".
> There are two more issues:
> (1) Attached is just an unconditional-unloading approach. Extra interfaces are needed to achieve selective unloading.
> (2) Some code refinements need to be done if running in 64bits environment since GC and VM use different code conventions to compress the references. If VM use the uncompressed "ManagedObject* vtable->jIC" as in the attachment we only need enhance GC in future.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (HARMONY-4494) [drlvm][classloader] VM modification
for class unloading
Posted by "Gregory Shimansky (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gregory Shimansky updated HARMONY-4494:
---------------------------------------
Component/s: (was: VM)
DRLVM
Summary: [drlvm][classloader] VM modification for class unloading (was: VM modification for class unloading)
> [drlvm][classloader] VM modification for class unloading
> --------------------------------------------------------
>
> Key: HARMONY-4494
> URL: https://issues.apache.org/jira/browse/HARMONY-4494
> Project: Harmony
> Issue Type: Sub-task
> Components: DRLVM
> Environment: win32
> Reporter: Chunrong Lai
> Attachments: classunloading.vm.diff
>
>
> The patch is not intended for commit but only for review purpose.
> I did them in VM side (to SVN HEAD) to test the GCv5's CU work where the references from native heap to java heap (m_loader, m_class_handle, vtable->jIC) are enumerated as weak roots at certain time. Then GCv5 will trace the strong roots and update the weak roots.
> Currently the intergated version can pass smoke test, specjbb and several other benchmarks. It also successfully unloaded the classloaders when running the test case in "Test_unloading_native_lib.zip".
> There are two more issues:
> (1) Attached is just an unconditional-unloading approach. Extra interfaces are needed to achieve selective unloading.
> (2) Some code refinements need to be done if running in 64bits environment since GC and VM use different code conventions to compress the references. If VM use the uncompressed "ManagedObject* vtable->jIC" as in the attachment we only need enhance GC in future.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4494) VM modification for class
unloading
Posted by "Chunrong Lai (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513954 ]
Chunrong Lai commented on HARMONY-4494:
---------------------------------------
Thanks a lot.
(1) I guess "jIC" stand for javaInstanceofClass.
(2) I will fix the formatting and outdated comments in the real submission.
(3) It is more complicated to let GC update VTable->jIC because a Vtable is not reachable from jIC as in the design document. In the view of GC's tracing, some unreachable (from objects) VTables will have reachable VTable->JIC. That is why I use weak roots.
> VM modification for class unloading
> -----------------------------------
>
> Key: HARMONY-4494
> URL: https://issues.apache.org/jira/browse/HARMONY-4494
> Project: Harmony
> Issue Type: Sub-task
> Components: VM
> Environment: win32
> Reporter: Chunrong Lai
> Attachments: classunloading.vm.diff
>
>
> The patch is not intended for commit but only for review purpose.
> I did them in VM side (to SVN HEAD) to test the GCv5's CU work where the references from native heap to java heap (m_loader, m_class_handle, vtable->jIC) are enumerated as weak roots at certain time. Then GCv5 will trace the strong roots and update the weak roots.
> Currently the intergated version can pass smoke test, specjbb and several other benchmarks. It also successfully unloaded the classloaders when running the test case in "Test_unloading_native_lib.zip".
> There are two more issues:
> (1) Attached is just an unconditional-unloading approach. Extra interfaces are needed to achieve selective unloading.
> (2) Some code refinements need to be done if running in 64bits environment since GC and VM use different code conventions to compress the references. If VM use the uncompressed "ManagedObject* vtable->jIC" as in the attachment we only need enhance GC in future.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4494) VM modification for class
unloading
Posted by "Pavel Pervov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513903 ]
Pavel Pervov commented on HARMONY-4494:
---------------------------------------
1) jIC->jlC it is to change capital "i" to small "l".
2) It looks like you have outdated sources - commented code, which enumerates m_failedClasses, is _added_ in your patch.
3) something wrong with formatting in changes for root_set_enum_common.cpp.
4) As I understand it jlC should be updated by GC but not reported as root from VM.
> VM modification for class unloading
> -----------------------------------
>
> Key: HARMONY-4494
> URL: https://issues.apache.org/jira/browse/HARMONY-4494
> Project: Harmony
> Issue Type: Sub-task
> Components: VM
> Environment: win32
> Reporter: Chunrong Lai
> Attachments: classunloading.vm.diff
>
>
> The patch is not intended for commit but only for review purpose.
> I did them in VM side (to SVN HEAD) to test the GCv5's CU work where the references from native heap to java heap (m_loader, m_class_handle, vtable->jIC) are enumerated as weak roots at certain time. Then GCv5 will trace the strong roots and update the weak roots.
> Currently the intergated version can pass smoke test, specjbb and several other benchmarks. It also successfully unloaded the classloaders when running the test case in "Test_unloading_native_lib.zip".
> There are two more issues:
> (1) Attached is just an unconditional-unloading approach. Extra interfaces are needed to achieve selective unloading.
> (2) Some code refinements need to be done if running in 64bits environment since GC and VM use different code conventions to compress the references. If VM use the uncompressed "ManagedObject* vtable->jIC" as in the attachment we only need enhance GC in future.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (HARMONY-4494) [drlvm][classloader] VM modification
for class unloading
Posted by "Xiao-Feng Li (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Xiao-Feng Li closed HARMONY-4494.
---------------------------------
Resolution: Fixed
HARMONY-4477 was committed, so this is no longer needed.
> [drlvm][classloader] VM modification for class unloading
> --------------------------------------------------------
>
> Key: HARMONY-4494
> URL: https://issues.apache.org/jira/browse/HARMONY-4494
> Project: Harmony
> Issue Type: Sub-task
> Components: DRLVM
> Environment: win32
> Reporter: Chunrong Lai
> Attachments: classunloading.vm.diff
>
>
> The patch is not intended for commit but only for review purpose.
> I did them in VM side (to SVN HEAD) to test the GCv5's CU work where the references from native heap to java heap (m_loader, m_class_handle, vtable->jIC) are enumerated as weak roots at certain time. Then GCv5 will trace the strong roots and update the weak roots.
> Currently the intergated version can pass smoke test, specjbb and several other benchmarks. It also successfully unloaded the classloaders when running the test case in "Test_unloading_native_lib.zip".
> There are two more issues:
> (1) Attached is just an unconditional-unloading approach. Extra interfaces are needed to achieve selective unloading.
> (2) Some code refinements need to be done if running in 64bits environment since GC and VM use different code conventions to compress the references. If VM use the uncompressed "ManagedObject* vtable->jIC" as in the attachment we only need enhance GC in future.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.