RFR(xs): 8199431: Split up class Metaspace into a static and a non-static part

Thomas Stüfe thomas.stuefe at gmail.com
Wed Mar 14 18:55:03 UTC 2018


On Wed, Mar 14, 2018 at 5:28 PM, <coleen.phillimore at oracle.com> wrote:

>
>
> On 3/14/18 12:24 PM, Thomas Stüfe wrote:
>
> Hi Andrew,
>
> On Wed, Mar 14, 2018 at 5:03 PM, Andrew Dinn <adinn at redhat.com> wrote:
>
>> On 14/03/18 13:42, Thomas Stüfe wrote:
>> > Thank you all for the feedback!
>> >
>> > New webrev to address Coleens points:
>> >
>> > complete: http://cr.openjdk.java.net/~stuefe/webrevs/8199431
>> -split-class-metaspace-into-two-parts/webrev.00/webrev/
>>
>> I think that is meant to be webrev.01 :-)
>>
>>
> Yes. Juggling more than one incremental webrev confuses me too much :)
>
> Correct link: http://cr.openjdk.java.net/~stuefe/webrevs/8199431-
> split-class-metaspace-into-two-parts/webrev.01/webrev/
>
>
>> The white space is gone but I am not clear that you have correctly
>> addresseed Coleen's second point.
>>
>> In this new version Metaspace is no longer a friend of SpaceManager but
>> ClassLoaderMetaspace has been made a friend in its place. If the last
>> version worked without the friend declaration for ClassLoaderMetaspace,
>> then why does this new version need to make ClassLoaderMetaspace a friend?
>>
>>
> Thats ok. ClassLoaderMetaspace - like the instance part of Metaspace
> before - needs access to SpaceManager private functions to access the
> expand_lock and some other stuff.
>
> In the first version of my webrev I added ClassLoaderMetaspace  as friend
> but forgot to remove friend Metaspace, I think this is what Coleen meant.
>
>
> That was what I meant but thanks for checking that ClassLoaderMetaspace is
> still needed, which is unfortunate.
>
> I filed a bug to make MetaspaceExpand_lock a global lock in
> mutexLocker.hpp.  https://bugs.openjdk.java.net/browse/JDK-8198760
> It's assigned to me but you're welcome to fix it and then maybe the friend
> declaration won't be needed anymore.
>
>
I am willing in principle but right now the bottleneck is the toolchain and
my time. I have a bit of a time adapting at the new hs-submit
way-of-doing-things, since I still work in jdk-hs with mercurial queues.
Say what you want about needing Oracle sponsors, but that at least was
convenient :P The thing I struggle most with is updating an pre-existing
test branch in submit-hs from a patch I made in jdk-hs (e.g. for a new
iteration of a patch with feedback worked-in).

Thanks, Thomas


> Thanks,
> Coleen
>
>
>
>> regards,
>>
>>
>> Andrew Dinn
>> -----------
>> Senior Principal Software Engineer
>> Red Hat UK Ltd
>> Registered in England and Wales under Company Registration No. 03798903
>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
>>
>
>
> Best Regards, Thomas
>
>
>


More information about the hotspot-runtime-dev mailing list