On Tue, 25 Jan 2022 16:33:10 GMT, Aleksey Shipilev wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
>> issues with it:
>> - The cache cannot disambiguate between cleared SoftReference and the
>> accidental passing of `null` value; in that case, the retry
On Tue, 25 Jan 2022 16:33:10 GMT, Aleksey Shipilev wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
>> issues with it:
>> - The cache cannot disambiguate between cleared SoftReference and the
>> accidental passing of `null` value; in that case, the retry
On Tue, 25 Jan 2022 16:12:11 GMT, Aleksey Shipilev wrote:
> > This looks good, although I don't know whether the additional check for
> > strongReferent != null is needed in clearStrong(). This is all racy code
> > and you have already got a non-null return from getStrong() in case you are
> >
> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
> issues with it:
> - The cache cannot disambiguate between cleared SoftReference and the
> accidental passing of `null` value; in that case, the retry loop would spin
> indefinitely;
> - If retry loop would spin
On Tue, 18 Jan 2022 20:07:10 GMT, Roger Riggs wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
>> issues with it:
>> - The cache cannot disambiguate between cleared SoftReference and the
>> accidental passing of `null` value; in that case, the retry loop
On Mon, 24 Jan 2022 21:32:16 GMT, Peter Levart wrote:
> This looks good, although I don't know whether the additional check for
> strongReferent != null is needed in clearStrong(). This is all racy code and
> you have already got a non-null return from getStrong() in case you are
> calling cle
On Fri, 21 Jan 2022 11:04:22 GMT, Aleksey Shipilev wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
>> issues with it:
>> - The cache cannot disambiguate between cleared SoftReference and the
>> accidental passing of `null` value; in that case, the retry
On Wed, 19 Jan 2022 13:10:55 GMT, Peter Levart wrote:
> WDYT?
I like the idea of holding to a value strongly for a brief period of time, in
order to guarantee progress! The sample code was a bit hard to follow, so I
rewrote the loop a bit with comments, see new commit. This still passes tests.
> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
> issues with it:
> - The cache cannot disambiguate between cleared SoftReference and the
> accidental passing of `null` value; in that case, the retry loop would spin
> indefinitely;
> - If retry loop would spin
On Wed, 19 Jan 2022 13:10:55 GMT, Peter Levart wrote:
> Note this matches other places we do the weak-reference loops, for example in
> `MethodType`:
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/invoke/MethodType.java#L1390-L1401
This one does not have the
On Wed, 19 Jan 2022 10:44:57 GMT, Aleksey Shipilev wrote:
> > So, this patch is fine for making ClassCache more robust as a re-usable
> > component inside JDK (checking for non-null return of computeValue). The
> > 2nd change, that apparently shields against unbounded accumulation of
> > garba
On Wed, 19 Jan 2022 08:25:55 GMT, Aleksey Shipilev wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
>> issues with it:
>> - The cache cannot disambiguate between cleared SoftReference and the
>> accidental passing of `null` value; in that case, the retry
On Wed, 19 Jan 2022 10:42:02 GMT, Peter Levart wrote:
> So, this patch is fine for making ClassCache more robust as a re-usable
> component inside JDK (checking for non-null return of computeValue). The 2nd
> change, that apparently shields against unbounded accumulation of garbage,
> might no
On Wed, 19 Jan 2022 08:25:55 GMT, Aleksey Shipilev wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
>> issues with it:
>> - The cache cannot disambiguate between cleared SoftReference and the
>> accidental passing of `null` value; in that case, the retry
On Wed, 19 Jan 2022 08:25:55 GMT, Aleksey Shipilev wrote:
>> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
>> issues with it:
>> - The cache cannot disambiguate between cleared SoftReference and the
>> accidental passing of `null` value; in that case, the retry
> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
> issues with it:
> - The cache cannot disambiguate between cleared SoftReference and the
> accidental passing of `null` value; in that case, the retry loop would spin
> indefinitely;
> - If retry loop would spin
On Tue, 18 Jan 2022 20:07:10 GMT, Roger Riggs wrote:
> It may not be worth it. If not, add the label "noreg-hard".
Added.
> It is possible for add to the test description the modules to be opened:
> ```
> * @modules java.base/java.io:open
> ```
>
> jtreg will add the appropriate command line
> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
> issues with it:
> - The cache cannot disambiguate between cleared SoftReference and the
> accidental passing of `null` value; in that case, the retry loop would spin
> indefinitely;
> - If retry loop would spin
On Fri, 14 Jan 2022 19:27:18 GMT, Aleksey Shipilev wrote:
> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
> issues with it:
> - The cache cannot disambiguate between cleared SoftReference and the
> accidental passing of `null` value; in that case, the retry loop
On Tue, 18 Jan 2022 18:22:26 GMT, Roger Riggs wrote:
> Can a test be written to verify the correct handling of nulls.
`java.io.ClassCache` is not public (for a reason), I struggle to find a way to
access it from a jtreg test...
-
PR: https://git.openjdk.java.net/jdk/pull/7092
On Fri, 14 Jan 2022 19:27:18 GMT, Aleksey Shipilev wrote:
> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
> issues with it:
> - The cache cannot disambiguate between cleared SoftReference and the
> accidental passing of `null` value; in that case, the retry loop
On Fri, 14 Jan 2022 22:26:31 GMT, Aleksey Shipilev wrote:
> > One additional improvement would be to change r.get() == null to
> > r.refersTo(null) to check for cleared reference, that avoids reviving the
> > referent, e.g. in SATB GCs. I leave that up to you.
>
> I think that does not work, b
On Fri, 14 Jan 2022 19:27:18 GMT, Aleksey Shipilev wrote:
> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
> issues with it:
> - The cache cannot disambiguate between cleared SoftReference and the
> accidental passing of `null` value; in that case, the retry loop
On Fri, 14 Jan 2022 20:50:24 GMT, Roman Kennke wrote:
> One additional improvement would be to change r.get() == null to
> r.refersTo(null) to check for cleared reference, that avoids reviving the
> referent, e.g. in SATB GCs. I leave that up to you.
I think that does not work, because we want
On Fri, 14 Jan 2022 19:27:18 GMT, Aleksey Shipilev wrote:
> JDK-8277072 introduced java.io.ClassCache, but there seem to be at least two
> issues with it:
> - The cache cannot disambiguate between cleared SoftReference and the
> accidental passing of `null` value; in that case, the retry loop
25 matches
Mail list logo
