8278065: Refactor subclassAudits to use ClassValue #6637

rkennke · 2021-12-01T14:45:23Z

As a follow-up to #6375, this change refactors java.io.ObjectInputStream.Caches#subclassAudits and java.io.ObjectOutputStream.Caches#subclassAudits to use ClassValue instead of SoftReference, similar to what we did in #6375 for java.io.ObjectStreamClass.Caches#localDescs. Then we can now also remove the common machinery java.io.ObjectStreamClass#processQueue and java.io.ObjectStreamClass.WeakClassKey.

Testing:

tier1
tier2
tier3

Progress

Change must not contain extraneous whitespace
Commit message must refer to an issue
Change must be properly reviewed

Issue

JDK-8278065: Refactor subclassAudits to use ClassValue

Reviewers

Roger Riggs (@RogerRiggs - Reviewer) ⚠️ Review applies to 10b905c
Peter Levart (@plevart - Reviewer) ⚠️ Review applies to 6b37d52

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/6637/head:pull/6637
$ git checkout pull/6637

Update a local copy of the PR:
$ git checkout pull/6637
$ git pull https://git.openjdk.java.net/jdk pull/6637/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 6637

View PR using the GUI difftool:
$ git pr show -t 6637

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/6637.diff

…-8277072

bridgekeeper · 2021-12-01T14:46:54Z

👋 Welcome back rkennke! A progress list of the required criteria for merging this PR into pr/6375 will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2021-12-01T14:48:28Z

@rkennke The following label will be automatically applied to this pull request:

core-libs

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

mlbridge · 2021-12-01T14:53:35Z

Webrevs

RogerRiggs

Looks good.

rkennke · 2021-12-02T21:01:31Z

Looks good.

Thank you!
I believe it makes sense to also use the ClassCache here, just as I did in #6375. I'll change this PR accordingly tomorrow.

RogerRiggs · 2021-12-02T21:05:18Z

The ClassValues are simple Booleans, that won't make much of difference if there's memory pressure and the ClassCache adds more objects and overhead of processing the queue, so I don't think its beneficial.

rkennke · 2021-12-02T21:13:24Z

The ClassValues are simple Booleans, that won't make much of difference if there's memory pressure and the ClassCache adds more objects and overhead of processing the queue, so I don't think its beneficial.

Right. Ok thanks, let's wait for #6375 then.

plevart · 2021-12-08T19:07:45Z

The ClassValues are simple Booleans, that won't make much of difference if there's memory pressure and the ClassCache adds more objects and overhead of processing the queue, so I don't think its beneficial.

Right, SoftReference object has a bigger footprint than Boolean object (more fields). ObjectStreamClass was another beast. So it is actually detrimental to efficiency to keep Boolean inside SoftReference just to be able to release Boolean, since SoftReference will stay until associated Class or ClassValue goes away...

What you could do is to half the footprint of those two caches if you merge them both into a single cache with a value holding two primitive booleans. Such object has the same foorprint as Boolean (because of padding) and you only need one ClassValue instance which would halve the number of ClassValueMap entries in existence.

What do you think?

plevart · 2021-12-08T20:37:14Z

...well I tried to do that. And it is not so simple. Here's what I came up with:

public final class ClassFlags {

    private static final class AtomicByte {
        private static final VarHandle VALUE;

        static {
            try {
                VALUE = MethodHandles.lookup().findVarHandle(AtomicByte.class, "value", byte.class);
            } catch (NoSuchFieldException | IllegalAccessException e) {
                throw new InternalError(e);
            }
        }

        private volatile byte value;

        byte get() {
            return value;
        }

        byte compareAndExchange(byte expectedValue, byte newValue) {
            return (byte) VALUE.compareAndExchange(this, (byte) expectedValue, (byte) newValue);
        }
    }

    private final Predicate<? super Class<?>>[] typePredicates;
    private final ClassValue<AtomicByte> flagsCV = new ClassValue<>() {
        @Override
        protected AtomicByte computeValue(Class<?> type) {
            return new AtomicByte();
        }
    };

    @SafeVarargs
    public ClassFlags(Predicate<? super Class<?>>... typePredicates) {
        if (typePredicates.length > 4) {
            throw new IllegalArgumentException("Up to 4 flags are supported in a single ClassFlags instance");
        }
        this.typePredicates = typePredicates;
    }

    public boolean get(Class<?> type, int index) {
        Objects.checkIndex(index, typePredicates.length);

        AtomicByte flags = flagsCV.get(type);
        int f = flags.get() & 0xFF;
        int falseMask = 0x1 << (index + index);
        int trueMask = falseMask << 1;
        int mask = falseMask | trueMask;
        int value = 0;
        while ((f & mask) == 0) {
            if (value == 0) {
                value = typePredicates[index].test(type) ? trueMask : falseMask;
            }
            int fn = (f & ~mask) | value;
            int fv = flags.compareAndExchange((byte) f, (byte) fn) & 0xFF;
            if (fv == f) {
                f = fn;
                break;
            } else {
                f = fv;
            }
        }
        return (f & trueMask) != 0;
    }
}

So I don't know if it's worth it... Simplicity of your implementation probably out-weights the footprint savings of above code.

Regards, Peter

openjdk-notifier · 2021-12-10T16:27:40Z

The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork:

git checkout JDK-8277072
git fetch https://git.openjdk.java.net/jdk master
git merge FETCH_HEAD
# if there are conflicts, follow the instructions given by git merge
git commit -m "Merge master"
git push

erikj79 · 2021-12-10T18:11:33Z

Skara is failing to run jcheck on this PR. I think this is ultimately a bug in Skara, that gets tickled by your source branch being quite far behind jdk:master, in combination with 62a7f5d recently going in. If you merge jdk:master into your branch, I believe this will resolve itself for now.

erikj79 · 2021-12-10T18:50:54Z

Skara is failing to run jcheck on this PR. I think this is ultimately a bug in Skara, that gets tickled by your source branch being quite far behind jdk:master, in combination with 62a7f5d recently going in. If you merge jdk:master into your branch, I believe this will resolve itself for now.

I've investigated further and filed https://bugs.openjdk.java.net/browse/SKARA-1281. Once fixed you would get an error message in this PR telling you to rebase your source branch.

openjdk · 2021-12-10T21:03:46Z

@rkennke This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8278065: Refactor subclassAudits to use ClassValue

Reviewed-by: rriggs, plevart

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 258 new commits pushed to the master branch:

ece98d8: 8278461: Use Executable.getSharedParameterTypes() instead of Executable.getParameterTypes() in trusted code
525b20f: 8279676: Dubious YMM register clearing in x86_64 arraycopy stubs
4f0b650: 8278581: Improve reference processing statistics log output
bd339aa: 8277627: Fix copyright years in some jvmci files
319d230: 8277463: JFileChooser with Metal L&F doesn't show non-canonical UNC path in - Look in
13bfb49: 6496103: isFileHidingEnabled return false by default
f16f6a9: 8279821: JFR: Log warnings properly when loading a misconfigured .jfc file
1c688f4: 8279900: compiler/vectorization/TestPopCountVectorLong.java fails due to vpopcntdq is not supported
3aaa098: 8276694: Pattern trailing unescaped backslash causes internal error
36f41cb: 8279884: Use better file for cygwin source permission check
... and 248 more: https://git.openjdk.java.net/jdk/compare/61736f81fb4a20375c83d59e2b37a00aafb11107...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

openjdk · 2021-12-10T21:03:55Z

⚠️ @rkennke This pull request contains merges that bring in commits not present in the target repository. Since this is not a "merge style" pull request, these changes will be squashed when this pull request in integrated. If this is your intention, then please ignore this message. If you want to preserve the commit structure, you must change the title of this pull request to Merge <project>:<branch> where <project> is the name of another project in the OpenJDK organization (for example Merge jdk:master).

bridgekeeper · 2022-01-08T01:18:36Z

@rkennke This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

rkennke · 2022-01-10T20:43:08Z

I think we shoul

...well I tried to do that. And it is not so simple. Here's what I came up with:

public final class ClassFlags {

    private static final class AtomicByte {
        private static final VarHandle VALUE;

        static {
            try {
                VALUE = MethodHandles.lookup().findVarHandle(AtomicByte.class, "value", byte.class);
            } catch (NoSuchFieldException | IllegalAccessException e) {
                throw new InternalError(e);
            }
        }

        private volatile byte value;

        byte get() {
            return value;
        }

        byte compareAndExchange(byte expectedValue, byte newValue) {
            return (byte) VALUE.compareAndExchange(this, (byte) expectedValue, (byte) newValue);
        }
    }

    private final Predicate<? super Class<?>>[] typePredicates;
    private final ClassValue<AtomicByte> flagsCV = new ClassValue<>() {
        @Override
        protected AtomicByte computeValue(Class<?> type) {
            return new AtomicByte();
        }
    };

    @SafeVarargs
    public ClassFlags(Predicate<? super Class<?>>... typePredicates) {
        if (typePredicates.length > 4) {
            throw new IllegalArgumentException("Up to 4 flags are supported in a single ClassFlags instance");
        }
        this.typePredicates = typePredicates;
    }

    public boolean get(Class<?> type, int index) {
        Objects.checkIndex(index, typePredicates.length);

        AtomicByte flags = flagsCV.get(type);
        int f = flags.get() & 0xFF;
        int falseMask = 0x1 << (index + index);
        int trueMask = falseMask << 1;
        int mask = falseMask | trueMask;
        int value = 0;
        while ((f & mask) == 0) {
            if (value == 0) {
                value = typePredicates[index].test(type) ? trueMask : falseMask;
            }
            int fn = (f & ~mask) | value;
            int fv = flags.compareAndExchange((byte) f, (byte) fn) & 0xFF;
            if (fv == f) {
                f = fn;
                break;
            } else {
                f = fv;
            }
        }
        return (f & trueMask) != 0;
    }
}

So I don't know if it's worth it... Simplicity of your implementation probably out-weights the footprint savings of above code.

Regards, Peter

I think I'd rather keep it simple. Can you please give it a review, too? Thanks, Roman

plevart · 2022-01-12T06:45:02Z

I think this looks good. Reviewed. Only a minor nit if you think it would be better, but not necessary if you don't. The following combo:

        Boolean result = Caches.subclassAudits.get(cl);
        assert result != null;

could be written as:

        boolean result = Caches.subclassAudits.get(cl);

...and it would give the same "message" to the reader. WDYT? No need for another round of reviews if you change this.

rkennke · 2022-01-12T11:15:42Z

I think this looks good. Reviewed. Only a minor nit if you think it would be better, but not necessary if you don't. The following combo:
        Boolean result = Caches.subclassAudits.get(cl);
        assert result != null;
could be written as:
        boolean result = Caches.subclassAudits.get(cl);
...and it would give the same "message" to the reader. WDYT? No need for another round of reviews if you change this.

Right! I changed it.

BTW, I noticed that Thread.java has a similar subclassAudits machinery with WeakClassKey, which would also benefit from using ClassValue instead. I filed JDK-8279917 to track it.

rkennke · 2022-01-12T13:45:32Z

/integrate

openjdk · 2022-01-12T13:47:36Z

Going to push as commit 8fed8ab.
Since your change was applied there have been 260 commits pushed to the master branch:

f54ce84: 8238161: use os::fopen in HS code where possible
ff0cb98: 8279536: jdk/nio/zipfs/ZipFSOutputStreamTest.java timed out
ece98d8: 8278461: Use Executable.getSharedParameterTypes() instead of Executable.getParameterTypes() in trusted code
525b20f: 8279676: Dubious YMM register clearing in x86_64 arraycopy stubs
4f0b650: 8278581: Improve reference processing statistics log output
bd339aa: 8277627: Fix copyright years in some jvmci files
319d230: 8277463: JFileChooser with Metal L&F doesn't show non-canonical UNC path in - Look in
13bfb49: 6496103: isFileHidingEnabled return false by default
f16f6a9: 8279821: JFR: Log warnings properly when loading a misconfigured .jfc file
1c688f4: 8279900: compiler/vectorization/TestPopCountVectorLong.java fails due to vpopcntdq is not supported
... and 250 more: https://git.openjdk.java.net/jdk/compare/61736f81fb4a20375c83d59e2b37a00aafb11107...master

Your commit was automatically rebased without conflicts.

openjdk · 2022-01-12T13:47:52Z

@rkennke Pushed as commit 8fed8ab.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

RogerRiggs · 2022-01-12T14:27:17Z

I would have appreciated a chance to review the latest changes.

rkennke · 2022-01-12T16:00:50Z

I would have appreciated a chance to review the latest changes.

Oh, ok, I'm sorry. I will wait some more next time that I get into a similar situation. I hope you're ok with the changes?

Roman Kennke and others added 8 commits November 12, 2021 22:42

8277072: ObjectStreamClass caches keep ClassLoaders alive

85af10d

Fix indentation of new testcase

430f54e

Convert test to testng

8b00ba9

Use ForceGC instead of System.gc()

6f099c9

Use ClassValue to solve JDK-8277072

6e16e5e

Merge remote-tracking branch 'jdk-plevart/JDK-8277072-peter' into JDK…

2ed745b

…-8277072

Remove unused EntryFuture inner class from ObjectSteamClass

b7d53ad

8278065: Refactor subclassAudits to use ClassValue

10b905c

openjdk bot added the rfr Pull request is ready for review label Dec 1, 2021

openjdk bot added the core-libs core-libs-dev@openjdk.org label Dec 1, 2021

rkennke mentioned this pull request Dec 1, 2021

8277072: ObjectStreamClass caches keep ClassLoaders alive #6375

Closed

7 tasks

RogerRiggs approved these changes Dec 2, 2021

View reviewed changes

openjdk-notifier bot changed the base branch from pr/6375 to master December 10, 2021 16:27

Merge branch 'master' into JDK-8278065

6b37d52

openjdk bot added the ready Pull request is ready to be integrated label Dec 10, 2021

plevart approved these changes Jan 12, 2022

View reviewed changes

Roman Kennke added 2 commits January 12, 2022 12:11

Avoid assert on unboxing Boolean

046f62a

Merge remote-tracking branch 'origin/JDK-8278065' into JDK-8278065

78bda4b

openjdk bot added the integrated Pull request has been integrated label Jan 12, 2022

openjdk bot closed this Jan 12, 2022

openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels Jan 12, 2022

rkennke deleted the JDK-8278065 branch January 12, 2022 13:59

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

8278065: Refactor subclassAudits to use ClassValue #6637

8278065: Refactor subclassAudits to use ClassValue #6637

rkennke commented Dec 1, 2021 •

edited by openjdk bot

Loading

bridgekeeper bot commented Dec 1, 2021

openjdk bot commented Dec 1, 2021

mlbridge bot commented Dec 1, 2021 •

edited

Loading

RogerRiggs left a comment

rkennke commented Dec 2, 2021

RogerRiggs commented Dec 2, 2021

rkennke commented Dec 2, 2021

plevart commented Dec 8, 2021

plevart commented Dec 8, 2021

openjdk-notifier bot commented Dec 10, 2021

erikj79 commented Dec 10, 2021

erikj79 commented Dec 10, 2021

openjdk bot commented Dec 10, 2021 •

edited

Loading

openjdk bot commented Dec 10, 2021

bridgekeeper bot commented Jan 8, 2022

rkennke commented Jan 10, 2022

plevart commented Jan 12, 2022

rkennke commented Jan 12, 2022

rkennke commented Jan 12, 2022

openjdk bot commented Jan 12, 2022

openjdk bot commented Jan 12, 2022

RogerRiggs commented Jan 12, 2022

rkennke commented Jan 12, 2022

8278065: Refactor subclassAudits to use ClassValue #6637

8278065: Refactor subclassAudits to use ClassValue #6637

Conversation

rkennke commented Dec 1, 2021 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Reviewing

bridgekeeper bot commented Dec 1, 2021

openjdk bot commented Dec 1, 2021

mlbridge bot commented Dec 1, 2021 • edited Loading

Webrevs

RogerRiggs left a comment

Choose a reason for hiding this comment

rkennke commented Dec 2, 2021

RogerRiggs commented Dec 2, 2021

rkennke commented Dec 2, 2021

plevart commented Dec 8, 2021

plevart commented Dec 8, 2021

openjdk-notifier bot commented Dec 10, 2021

erikj79 commented Dec 10, 2021

erikj79 commented Dec 10, 2021

openjdk bot commented Dec 10, 2021 • edited Loading

openjdk bot commented Dec 10, 2021

bridgekeeper bot commented Jan 8, 2022

rkennke commented Jan 10, 2022

plevart commented Jan 12, 2022

rkennke commented Jan 12, 2022

rkennke commented Jan 12, 2022

openjdk bot commented Jan 12, 2022

openjdk bot commented Jan 12, 2022

RogerRiggs commented Jan 12, 2022

rkennke commented Jan 12, 2022

rkennke commented Dec 1, 2021 •

edited by openjdk bot

Loading

mlbridge bot commented Dec 1, 2021 •

edited

Loading

openjdk bot commented Dec 10, 2021 •

edited

Loading