On Thu, 12 Jan 2023 00:15:08 GMT, Maurizio Cimadamore
wrote:
> So, for static methods, it could go down two ways: either we don't even look
> at referenced method bodies, give up and just declare "sorry, escaping". Or,
> if we look into method bodies, and see that the relationship between inne
On Wed, 11 Jan 2023 22:40:43 GMT, Archie L. Cobbs wrote:
>
> D'oh, you're right. But if you made `returnMe()` static or private then the
> argument would still hold.
>
> > And, if the method is static, same story - you are passing ref3 somewhere
> > else, and ref3 potentially contains this.
>
On Wed, 11 Jan 2023 21:51:45 GMT, Maurizio Cimadamore
wrote:
> So, in this example though you are calling an instance method before the
> object is initialized, which would seem to me like a leak
D'oh, you're right. But if you made `returnMe()` static or private then the
argument would still
On Wed, 11 Jan 2023 21:45:20 GMT, Maurizio Cimadamore
wrote:
>> Regarding the assignment graph approach, I think that would work if the
>> references are bouncing around strictly between variables, but what if the
>> chain includes any of the more complicated stuff that is currently being
>>
On Wed, 11 Jan 2023 19:10:04 GMT, Archie L. Cobbs wrote:
>> Good idea. Looks like the difference is in the noise, at least on my Macbook:
>>
>> Builds of master (jdk-21+3-69-gc6588d5bb3f)
>> ==
>>
>> Build times:
>>
>> real 2m24.650s
>> user 13m4
On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs wrote:
>> This PR adds a new lint warning category `this-escape`.
>>
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
>> allow the JDK to continue to compile with `-Xlint:all`.
>>
>> A 'this' escape warning is gene
On Wed, 11 Jan 2023 15:59:29 GMT, Maurizio Cimadamore
wrote:
> What I'm interested in though is what incremental improvement is brought by
> the more complex analysis you have in this PR?
It's a good question. Here are some thoughts...
One meta-goal is that this analysis be conservative. In o
On Wed, 11 Jan 2023 18:44:20 GMT, Archie L. Cobbs wrote:
>> Also, looking at the loop test more closely, it seems to me that what the
>> compiler needs to do is to prove that there can be possible paths by which a
>> `this` can land into ref4.
>>
>> If we build a graph of all the assignments,
On Wed, 11 Jan 2023 16:14:24 GMT, Maurizio Cimadamore
wrote:
>> True - probably 3 * 3 can be achieved if this:
>>
>>
>> ThisEscapeLoop ref21 = ref14;
>>
>> Is replaced with
>>
>>
>> ThisEscapeLoop ref21 = this;
>>
>>
>> In which case the inner loop won't converge immediately (a
On Wed, 11 Jan 2023 14:12:46 GMT, Maurizio Cimadamore
wrote:
>> Actually I think it would take 1 + 1 + 3 iterations.
>>
>> During the first two iterations of the outer loop, nothing changes after the
>> first go round of the inner loop - i.e., the total set of possible
>> references in existe
On Wed, 11 Jan 2023 03:30:03 GMT, Archie L. Cobbs wrote:
>> This PR adds a new lint warning category `this-escape`.
>>
>> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to
>> allow the JDK to continue to compile with `-Xlint:all`.
>>
>> A 'this' escape warning is gene
On Wed, 11 Jan 2023 09:57:58 GMT, Alan Bateman wrote:
>> java.net.Socket is not specified to be thread safe but it is required to
>> support async close. If you create an unbound Socket and close it at around
>> the time that another thread is binding, connecting, or anything else that
>> crea
On Wed, 11 Jan 2023 00:22:03 GMT, Archie L. Cobbs wrote:
>> So, if the code was be like this:
>>
>>
>> ThisEscapeLoop ref11 = this;
>> ThisEscapeLoop ref12 = null;
>> ThisEscapeLoop ref13 = null;
>> ThisEscapeLoop ref14 = null;
>> for (int i = 0; i < 100; i++) {
>> ref14 = ref13;
>> ref
On Wed, 11 Jan 2023 09:57:58 GMT, Alan Bateman wrote:
>> java.net.Socket is not specified to be thread safe but it is required to
>> support async close. If you create an unbound Socket and close it at around
>> the time that another thread is binding, connecting, or anything else that
>> crea
> java.net.Socket is not specified to be thread safe but it is required to
> support async close. If you create an unbound Socket and close it at around
> the time that another thread is binding, connecting, or anything else that
> creates the underlying socket then it can leak. The simplest thi
On Wed, 11 Jan 2023 00:53:21 GMT, Jaikiran Pai wrote:
> (Leaky.java line 231 has a typo in a comment, that I think you missed, but
> that's a trivial thing)
Well spotted, I fixed the typo in another place so missed it in Leaky.
-
PR: https://git.openjdk.org/jdk/pull/11863
16 matches
Mail list logo
