harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrey Yakushev (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HARMONY-5684) [drlvm][memory] Native memory management and tuning
Date Thu, 03 Apr 2008 11:34:25 GMT

     [ https://issues.apache.org/jira/browse/HARMONY-5684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Andrey Yakushev updated HARMONY-5684:

    Attachment: memmgr.patch

memmgr.patch is my first attempt to improve native memory management capabilities. It contains
wrapper for STD_MALLOC and STD_FREE which is switched on by _MEMMGR define. Then DRLVM could
report allocation / deallocation, check double free calling, report unfreed memory, provide
precise info about currently used memory via java.lang.management interface.

Also place for stress memory allocator was defined, but it is not implemented yet, only redirects
to standard malloc.

I checked functionality on Windows x86 revision 641753

By default all major features are switched off until performance impact wouldn't be investigated.

> [drlvm][memory] Native memory management and tuning
> ---------------------------------------------------
>                 Key: HARMONY-5684
>                 URL: https://issues.apache.org/jira/browse/HARMONY-5684
>             Project: Harmony
>          Issue Type: Improvement
>          Components: DRLVM
>            Reporter: Andrey Yakushev
>         Attachments: memmgr.patch
> There are several problems in DRLVM with native memory usage. For example:
> - Native memory usage couldn't be monitored currently in details via java.lang.management
> - No explicit way to replace system native memory allocator to other memory managers
in order to improve performance or footprint
> - Too many variants of the native memory allocations in DRLVM
> - Poor memory usage control (like leaks, double free calling, etc.)
> - Potential crash in diagnostics when OutOfMemory occur
> - Frequent native memory usage could cause OutOfMemory if GC wouldn't be timely called
> - No detail trace for the native memory usage
> Adding of some functionality to solve these would be hepful I think?

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message