[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Re: RFR: 8235772: Remove use of deprecated finalize method from PiscesRenderer and AbstractSurface
From:       Ambarish Rapte <arapte () openjdk ! java ! net>
Date:       2019-12-24 6:37:20
Message-ID: yyD8hlcbDx35EajGmbiPkrynBIsHvjC4HX8AbFBmVmA=.cdeac3c5-a77e-4379-bbf1-be10ab4bcbde () github ! com
[Download RAW message or body]

On Sat, 21 Dec 2019 18:22:44 GMT, Johan Vos <jvos@openjdk.org> wrote:

> > Hi Johan,
> > The `readAndClearMemErrorFlag()` method checks if the variable `mem_Error_Flag` \
> > is `JNI_TRUE`. A call should be made to `setMemErrorFlag()` to set \
> > `mem_Error_Flag` to `JNI_TRUE`. 
> > The methods used to dispose Surface and renderer only `free()` the allocated \
> > memory and  do not result in making a call to `setMemErrorFlag().`
> > So we do not need to check for `readAndClearMemErrorFlag()`
> > And I think it was not required before this change too.
> 
> The dispose methods indeed won't set the `mem_Error_Flag` but this flag might have \
> been set by other methods. Isn't there a probability that the flag has been set, \
> and that `readAndClearMemErrorFlag()` is not yet called since the flag has been \
> set?

Hi Johan, I did miss to verify this angle.
But have checked the code now and can confirm that, in a given function for all \
possible calls to `setMemErrorFlag()` there exists a call to \
`readAndClearMemErrorFlag()` in the same function. So it looks safe to remove the \
memory checks from `dispose()`

-------------

PR: https://git.openjdk.java.net/jfx/pull/66


[prev in list] [next in list] [prev in thread] [next in thread]