Request for review (XL) 6990754: Use native memory and reference counting to implement SymbolTable

[Jon Masamitsu]

Volker,

On this project to move meta-data out of the perm gen,
we're actually hoping to do it incrementally - move out
some meta-data, code review it and test it, and commit that
part.  Is this the opposite of what you were hoping?

Jon

On 11/08/10 09:26, Volker Simonis wrote:
> Hi Coleen,
>
> I just want to ask for a little favor regarding this change. As it
> touches MANY files, it would be really nice if you and other hotspot
> committers could arrange their commits in a way to get as few merge
> change-sets as possible around this change and if the merge
> change-sets are unavoidable they should preferably be empty. As you
> probably all know, this can be easily achieved with various Mercurial
> extensions like 'Rebase', 'Transplant' or 'Mercurial Queues (MQ)'
>
> This would greatly simplify the process of integration this change
> into other code bases.
>
> Thank you,
> Volker
>
> PS: of course this little wish generally applies to all changesets
> because a 'linear' (or 'serialized') repository is much easier to
> handle:)
>
> On Fri, Nov 5, 2010 at 1:43 AM, Coleen Phillimore
> <coleen.phillimore at oracle.com> wrote:
>   
>> One of the ongoing projects in Hotspot is to move the VM internal data
>> structures (known as metadata) out of the Java heap (permgen) into native
>> memory.  This patch is the first step in the greater project.  For more
>> information please read the information in the bugs:
>>
>> 6964458: Reimplement class meta-data storage to use native memory
>> http://bugs.sun.com/view_bug.do?bug_id=6964468
>>
>> 6990754: Use native memory and reference counting to implement SymbolTable
>> http://bugs.sun.com/view_bug.do?bug_id=6990754
>>
>> I've had 3 detailed code reviews and contribution from internal team members
>> never, acorn, jmasa and apangin.  If you are part of the openjdk java vm
>> community we especially want to hear your comments and review.  This is a
>> very large change.
>>
>> The major changes are in the symbolTable.hpp and symbol.hpp.  These files
>> should be read FIRST.  symbolOop has been replaced with Symbol* in many of
>> the source files.  Symbol* is now a reference counted type contained in the
>> SymbolTable.  Symbol* is no longer an oop and it is not in the Java heap.
>>  The symbolHandle uses are no longer applicable.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~coleenp/6990754_3/
>>
>> You can either send your comments to me directly or the whole email list.  I
>> am not going to be working Friday or this weekend but will carefully address
>> all comments next week.
>>
>> Thanks,
>> Coleen
>>
>>