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

[Volker Simonis]

Thank you Tom,

that was exactly my intention!

And for the outstanding changes of individual developers I suggested
the usage of 'Rebase' or 'Mercurial Queues (MQ)' in order to avoid
"Merge Changesets". If done that way, the process of merging (i.e.
resolving conflicts) has to be done only if there are real conflicts
(i.e. if the  "Merge Changesets" would have not been empty otherwise).
But the merging would happen locally and would not be visible as extra
changeset.

This approach isn't fully fail safe, because  there's still a small
chance that between the rebiasing and the push other developers pushed
their changes. In that case another round of pull-rebias would be
necessary. But in general this shouldn't happen too often, given the
current number of concurrent hackers:)

Regards,
Volker

On Mon, Nov 8, 2010 at 9:12 PM, Tom Rodriguez <tom.rodriguez at oracle.com> 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.
>
> 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
>>>>
>>>>
>
>