To me, it sounds like @Contended, in its current form, is not quite ready for prime-time ( inclusion in Java SE 9 ). There is some concern about its implementation, and I’m not sure how the loader restriction, and the control through a -XX flag, would translate into SE spec. There is certainly some additional work, beyond my primary goal ( preparation for JEP 260 ) that is required.
It seems a reasonable compromise ( until someone can spend some quality time on it ) to support the sun.misc.Contended annotation as an alias, or similar, along with the internal Contended annotation ( required by java.base ). The changes to support such are relatively straight forward, and can easily be refactored in the future. If there is agreement, I will add @Contended to JEP 260. -Chris. > On 12 Nov 2015, at 14:15, Vitaly Davidovich <vita...@gmail.com> wrote: > > You didn't explicitly say that, but it came across like that to me; > apologies if I misread. > > So your concern, then, is that the implementation may not be 100% correct, > safe, and robust? If it were more readily available to non-JDK users, > you're likely to see more use of it and thus more "coverage" of the > feature. The disable flag can continue to exist in case something > catastrophic is discovered, and it can be disabled by default so people > have to opt-in (for now). I don't quite get how it spending more time in > internal packaging (and thus seeing limited application) will help in > shaking out bugs/exploits. > > On Thu, Nov 12, 2015 at 9:00 AM, Paul Sandoz <paul.san...@oracle.com> wrote: > >> >>> On 12 Nov 2015, at 14:48, Vitaly Davidovich <vita...@gmail.com> wrote: >>> >>> Hi Paul, >>> >>> There is a very valid concern, since @Contended changes object layout >> and increases object size, liberal use might tickle an overflow in HotSpot >> code. Hence why it has remained internal so far. >>> >>> What overflow? OOM of the heap? How is that a "very valid" concern? Why >> would it be used liberally? Why are you allowing users to allocate any >> memory whatsoever? Why not put a cap on the size of objects non-JDK code >> can allocate? :) I mean seriously, with all due respect, the occasional >> "our users are dumb and misinformed" sentiment is very off-putting. >>> >> >> Where did i say that? You are incorrectly reading between the lines. The >> concern is actually smart and well informed users that may dliberately >> exploit a bug/weakness in the VM. >> >> Paul. >> >>> If you think there are, currently, *implementation* issues with how >> @Contended is handled in the VM which cannot be addresses, I'll buy that. >> But can we please stop with the dumbing down? :) >>> >>