RFR  8140687: Move @Contended to the jdk.internal.vm.annotation package
vitalyd at gmail.com
Thu Nov 12 14:15:21 UTC 2015
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.sandoz at oracle.com> wrote:
> > On 12 Nov 2015, at 14:48, Vitaly Davidovich <vitalyd at 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.
> > 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? :)
More information about the core-libs-dev