[jmm-dev] finalization

[Paul Benedict]

As a novice observer on this topic, I wanted to chime in with an arm-chair
observation. There doesn't seem to be a one-size-fits-all solution, but it
does sound like people have identified several cases that look like
integrity "isolation levels" to me (sorry, I don't know what better
phrasing to use). I wonder if @Finalized should come with an option that
specifies the kind of guarantee/behavior needed? This way no one is
shoe-horned into a single solution.

@Finalized(mode=)


Cheers,
Paul


On Fri, Aug 15, 2014 at 10:19 AM, Doug Lea <dl at cs.oswego.edu> wrote:

> On 08/14/2014 09:38 PM, Hans Boehm wrote:
>
>>
>> On Thu, Aug 14, 2014 at 5:22 PM, Doug Lea <dl at cs.oswego.edu
>>
>>     I'm suggesting something slightly simpler. A reachabilityFence(x)
>>     is placed/checked after each access of @Finalized field x.r.
>>     No other JLS changes.
>>
>> I don't think that keeping it live until just after the access is good
>> enough.
>>
>
> Right; "after" doesn't necessarily mean "immediately following the
> resource field access bytecode", which would usually not be helpful.
> Even placing at end of current source-level block might not be
> conservative enough:
>  Resource s; {  Resource r = this.resource; s = r; } use(s) ...
>
> Short of requiring full dataflow analysis tracing all dependencies of the
> resource field read, the safest and probably easiest policy seems to be
> to insert upon method exit. But in some cases this would retain
> enough garbage that some programmers would want to manually override.
>
> These (and others I've mentioned) are the sorts of issues I had in mind
> in my initial "don't play if you can't win" reaction.
>
> I think we all agree that we must minimally introduce
> reachabilityFence(ref), and modify JLS 12.6.2 accordingly.
>
> Beyond that, introducing and defining the effects of @Finalized
> seems plausible, although still short of compelling because of
> limitations and the looseness of @Finalized specs that they imply.
> So any tools developed to insert or check reachabilityFences
> will need to provide enough details to be useful to programmers.
> Which suggests ceding the entire territory to tool developers.
>
> And I still don't see a compelling argument for any other
> automatic scope-widening approach.
>
> -Doug
>
>