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

[Coleen Phillimore]

On 11/8/2010 3:12 PM, Tom Rodriguez wrote:
> On Nov 8, 2010, at 11:10 AM, Jon Masamitsu wrote:
>
>> 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?
> I'm guessing that he'd like us to sync all our baselines and then push the symbol changes everywhere simultaneously so that we don't have merge changesets against it from sub baselines.  Normally our changes trickle up group to main and then down to other groups and then any merges trickle back up on the next sync.  There's some merit to the idea since having to do merges against these changes might be a bear though obviously individual developers with outstanding changes will still have to merge those changes.

Volker,

Yes, I think we could arrange that these symbol changes are pushed to 
hotspot-rt, run through the nightly tests and then pushed to hotspot 
repository before the other baselines.  Maybe it should rate it's own 
integration slot.  I won't create merge change sets before pushing.

Hopefully this is okay.  Thanks for the request and any feedback that 
you have.

Coleen
> tom
>
>> 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
>>>>
>>>>