Hi Sergey,
update: http://cr.openjdk.java.net/~ant/JDK-8145984/jdk8u/webrev.2
> On 28 Dec 2015, at 16:12, Sergey Bylokhov <sergey.bylok...@oracle.com> wrote:
>
> Hi, Anton.
> It seems that the fix does not take into account that the component can be
> recreated by the addNotify(), in this case the old(but already disposed)
> CAccessible object will be used in the AccessibleContext via nativeAXResource
> field(see CAccessible.getCAccessible()). I guess this can be verified somehow
> by the test that AXTextChangeNotifier is not called in this case.
In this case CFRetainedResource will set ‘ptr’ to 0 in super.dispose(). And
then, even with the same CAccessible instance, its native peer will be
recreated from [JavaComponentAccessibility createWithParent].
> Probably it can be simplified by the sun.java2d.Disposer.
Well, I tried that. However, there’re problems.
1) Java accessible objects are strongly referenced from the native code. This
will prevent those objects from enqueueing into the reference queue.
2) j2d Disposer by default wraps objects with PhantomReference. This means that
by the time the object will be enqueued and thus accessible for disposal, all
its WeakReferences will be cleared. So, there will be no way to get the object
‘this’ ref from the dispose method (nor via PhantomReference, which doesn’t
provide access to its referent at all). For instance, if I’m adding something
like this to CFRetainedResource.java:
private static class CFDisposerRecord implements DisposerRecord {
WeakReference<CFRetainedResource> weakThis;
CFDisposerRecord(WeakReference<CFRetainedResource> weakThis) {
this.weakThis = weakThis;
}
@Override
public void dispose() {
CFRetainedResource cf = weakThis.get();
if (cf != null) {
cf.dispose();
}
}
}
I will get null ‘cf’… (also, note that DisposerRecord can’t strongly reference
the referent, as DisposerRecord is not wrapped with a phantom/weak reference).
So, as far as I understand, j2d Disposer can’t access the victim object. Even
in Window.java where it’s passed a WeakReference(this) it doesn’t directly
access the referent. In other cases it works with primitive types, like ‘long’
native pointers.
It’s possible to rewrite CAccessible.dispose in that way, but many of the rest
CFRetainedResource extenders relies on ‘this’ in their disposal.
As a solution, I changed the related native refs to ‘weak’ and left
CFRetainedResource.finalize() as a working horse… I suspect it could be used
just because of the problem N2, originally when native refs were ‘weak’
(accessibility then came with ‘strong’ refs). However, I’ve changed only a part
of the potentially related refs (in JavaComponentAccessibility.m, CGLLayer.m).
For instance, JavaAccessibilityAction.m still uses strong refs.
Also, I encountered one more issue. It’s in [JavaComponentAccessibility
parent]. The point is that getAccessibleParent returns an owner window for
toplevels (having an owner window). But the method doesn’t expect a separate
toplevel and uses ‘fView’ in JavaComponentAccessibility creator. This is wrong,
because this ‘fView’ will be retained for that CF object, created for a
toplevel not related to that ‘fView’. This is a leak, at least. It can be
reproducible with the sample I originally provided for the bug. Run it so that
the frame is shown unfocused (quickly switch to another window after the
launch). Then make it a key window again and repeat the steps described in
JIRA. The leak is there.
I solved it by retrieving a correct ‘view’ of a toplevel.
(And yet another issue. I naively missed the fact that an Accessible is not
necessarily a Component. For those Accessibles, the original scheme I suggested
won't work. But this one will.)
The webrev I've posted is for 8u. I’ll make one for 9 when and if the fix is
approved.
Thanks & Happy New Year! =)
Anton.
>
> On 23/12/15 10:59, Anton Tarasov wrote:
>> Sure, I would also appreciate if someone could apply the fix and do a
>> sanity check on your side.
>>
>> (Yes, I’m aware that Android Studio team is working extensively on a11y
>> support. OSX issues are pending resolution indeed…)
>>
>> I’ve updated the copyrights:
>>
>> http://cr.openjdk.java.net/~ant/JDK-8145984/jdk9/webrev.1
>>
>> Thanks,
>> Anton.
>>
>>> On 23 Dec 2015, at 00:55, Pete Brunet <peter.bru...@oracle.com
>>> <mailto:peter.bru...@oracle.com>> wrote:
>>>
>>> Thanks for the reply Anton and thanks for the fix you are working on.
>>> It will be good to get at least one other set of eyes on the changes
>>> as I am not very familiar with that code (but am starting to because
>>> I'm looking into fixing some accessibility issues raised by the
>>> Andriod Studio team). -Pete
>>>
>>> On 12/22/15 3:45 PM, Anton Tarasov wrote:
>>>> Hi Pete,
>>>>
>>>> Thanks for the review!
>>>>
>>>>> On 22 Dec 2015, at 23:07, Pete Brunet
>>>>> <<mailto:peter.bru...@oracle.com>peter.bru...@oracle.com> wrote:
>>>>>
>>>>> Hi Anton, Some comments/questions:
>>>>> - Some copyright dates need updating
>>>>
>>>> Indeed, I’ll update them.
>>>>
>>>>> - Line 1112 of JavaComponentAccessibility: does the release of
>>>>> jaccessible cause a release of jparent?
>>>>
>>>> As I can see, jparent there is only a ref to jComponent, which in its
>>>> turn is a JNIGlobalRef (or anyway is a class field). So, I don’t see
>>>> the need to delete it… (or did I miss something?)
>>>>
>>>>> - Line 7155 of Component.java: is that the only place where this
>>>>> means is needed?
>>>>
>>>> If you mean to call AC.dispose() than - yes, I think so. We rather
>>>> don’t want to dispose the context until the Component goes out of the
>>>> UI hierarchy, which is when Component.removeNotify() is _always_
>>>> getting called (for hw & lw components).
>>>>
>>>> Anton.
>>>>
>>>>>
>>>>> Pete
>>>>>
>>>>> On 12/22/15 8:10 AM, Anton Tarasov wrote:
>>>>>> Hi guys!
>>>>>>
>>>>>> Could you please review the problem I’ve filed and the suggested fix?
>>>>>>
>>>>>> bug: JDK-8145984
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8145984>
>>>>>> sun.lwawt.macosx.CAccessible
>>>>>> leaks
>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8145984/jdk9/webrev.0
>>>>>> <http://cr.openjdk.java.net/%7Eant/JDK-8145984/jdk9/webrev.0>
>>>>>>
>>>>>> (This is to be addressed in 8u/9. The webrev for 8u is in JIRA,
>>>>>> it’s identical except the paths.)
>>>>>>
>>>>>> Please, find the details in JIRA.
>>>>>>
>>>>>> Thanks!
>>>>>> Anton.
>>>>>
>>>>
>>>
>>
>
>
> --
> Best regards, Sergey.
