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

[Volker Simonis]

Hi Coleen,

sounds good! Hope you can manage to do it that way.

And I forgot to mention that my request also applies to the next big
hammer change: "6989984: Use standard include model for Hotspot" which
will be even more disruptive:)

Regards,
Volker

On Mon, Nov 8, 2010 at 10:21 PM, Coleen Phillimore
<coleen.phillimore at oracle.com> wrote:
> 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
>>>>>
>>>>>
>
>