RE: Question about "happens-before"andreordering

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

RE: Question about "happens-before"andreordering

Bjorn Antonsson
Let's just back up here a bit.

The only way for the ClassLoader constructor not to reach the
initialized assignement is to throw an exception. Either in
securityCheck() or in init(). No matter how amazingly inlining
or optimizing your jit-compiler is, it must still guarantee that
it doesn't move statements that have visible side effects before
possibly faulting instructions. That is a requirement of the
language. No matter what memory model or reordering stuff you
throw at it.

/Björn
--
If you see a nasty sig at the bottom, it has been forced upon my email
by my employer.

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf
> Of Pete Soper
> Sent: den 19 maj 2006 15:24
> To: Thomas Hawtin
> Cc: [hidden email]
> Subject: Re: [concurrency-interest] Question about
> "happens-before"andreordering
>
> Thomas Hawtin wrote:
> > Robert Kuhar wrote:
> >
> >>   Secure Coding Guidelines:
> >>     - If finalize method can be overridden, ensure partially
> >> initialized       instances are unusable
> >
> >
> > I think it's a little more subtle than that, particularly
> prior to 1.6.
> >
> >>   public class ClassLoader {
> >>     private boolean initialized = false;
> >
> >
> > I think the "= false" bit here is misleading. I certainly would not
> > want to see "= true" in a similar situation.
> >
> >>     ClassLoader() {
> >>       securityCheck(); // can throw an Exception
> >>       init();
> >>       initialized = true; // check flag in all relevant methods
> >>     }
> >>   }
> >>
> >> I asserted that they had two problems with this code.  As I
> >> understand it, the runtime is free to reorder the instructions in
> >> this constructor.  This means that initialized=true may
> occur before
> >> the calls to either
> >> securityCheck() or
> >> init().  If that is the case, its value cannot be trusted as this
> >> code stands now.
> >
> >
> > If securityCheck does throw an exception, then the
> initialized = true
> > statement must never be executed. So there is no security
> problem there.
>
> Because compilers are not free to do this kind of code
> motion? In the old 3GL days, compilers for some languages
> were free to determine if an initialized reference (or maybe
> an extremely subtle alias for the same
> storage) is possible in the called routine and, if not, hoist
> the assignment up for the sake of better instruction
> scheduling, getting it out of a loop, etc.
>
> I don't recall if it was mentioned that init is assumed to be
> a method of ClassLoader with the body judged irrelevant to
> show. If init is a method of ClassLoader, then the compiler
> (the dynamic one we typically enjoy, not javac) is free to
> determine if init can assign to initialized, I think. (If
> it's free to suck the code inline, then it's surely OK to
> treat it like just another set of statements).
>
> But it seems impossible for securityCheck to be able to
> assign to initialized by any means, as it can't have a
> reference to the object being constructed. So the init call
> is the barrier to code motion, I think. But I don't know for
> sure and the compiler writer that sits next door to me is at J1.
>
> Cliff would know.
>
> -Pete
>
> >
> > If securityCheck does not throw, then theoretically you could see a
> > non-working, partially-initialised instance. However, that would be
> > your own fault.
> >
> > Tom Hawtin
> > _______________________________________________
> > Concurrency-interest mailing list
> > [hidden email]
> > http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> _______________________________________________
> Concurrency-interest mailing list
> [hidden email]
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest