[concurrency-interest] @Contended (JEP-142)

Stanimir Simeonoff stanimir at riflexo.com
Thu Nov 29 09:31:46 EST 2012


>
> On Thu, Nov 29, 2012 at 3:06 PM, Stanimir Simeonoff <stanimir at riflexo.com>wrote:
>
>>
>>
>> On Thu, Nov 29, 2012 at 12:40 PM, Stanimir Simeonoff <
>>> stanimir at riflexo.com> wrote:
>>>
>>>> Problem w/ sun.misc is that it requires security permissions on runtime
>>>> whilst it's an absolutely harmless operation. To avoid that people will
>>>> just keep padding like it's done now - i.e. nothing achieved.
>>>>
>>>
>>>
>>>
>>>> For instance, I can live by extending j.u.c.atomics even it's ugly just
>>>> to avoid touching Unsafe itself (or the AtomicUpdaters)
>>>
>>>
>>> That doesn't address the need for padding.
>>>
>>
>> It's a similar example when you can skip resorting to the Unsafe (and
>> keep performance) - there is a way to do it even if it's ugly.
>>
>
> No, Java doesn't have MI so it only works for single-fields, which is
> extremely limiting.
>
Of course, it's limiting and of course you can't pad from the front of the
object but it's better than the FIeldUpdaters for most of the part, at
least in my experience.


> Similar fate may follow sun.misc.Contended - even now it's possible to
>> emulate padding but an attempt to improve the case by having it in sun.misc
>> is neither portable nor a security friendly approach.
>>
>
> The deal breaker for the annotation is that it breaks the program if the
> annotation doesn't exist in that version of the JVM.
>

 -Xbootclasspath/a comes to mind (although that equals access to the JVM
start-up) or classloading tricks, dynamically removing the annotation.
Bytecode enhancing ain't so hard actually but hardly worth the effort if
the JVM can be updated. Keeping both classes in the the jar is an option
too with the classloader picking the correct version. If you use custom
classloaders that's quite an easy task to implement.
Having the annotation unsupported by the JVM would likely yield bad
performance but it would not result in NoClassDefFoundError.

Stanimir



> Cheers,
>>
>
>>
>>
>> Stanimir
>>
>>
>>>
>>>>
>>>> Stanimir
>>>>
>>>>
>>>> On Thu, Nov 29, 2012 at 1:00 PM, Dr Heinz M. Kabutz <
>>>> heinz at javaspecialists.eu> wrote:
>>>>
>>>>> **
>>>>> IMHO, sun.misc.Contended is the right place for this one, as it will
>>>>> hopefully discourage people from using it, unless they really know what
>>>>> they are doing.  Next you find programmers making all their fields
>>>>> "Contended", because they read on some blog that it makes things faster.
>>>>> Then instead of your object using only 32 bytes, it gets bloated to 512
>>>>> bytes.
>>>>>
>>>>> Regards
>>>>>
>>>>> Heinz
>>>>> --
>>>>> Dr Heinz M. Kabutz (PhD CompSci)
>>>>> Author of "The Java(tm) Specialists' Newsletter"
>>>>> Sun Java Champion
>>>>> IEEE Certified Software Development Professionalhttp://www.javaspecialists.eu
>>>>> Tel: +30 69 75 595 262
>>>>> Skype: kabutz
>>>>>
>>>>>
>>>>>
>>>>> On 11/29/12 11:11 AM, Stanimir Simeonoff wrote:
>>>>>
>>>>> >>Any concrete suggestion? j.u.c.Contended? j.u.c.hints.Contended?
>>>>> j.u.c.expert.Contended?
>>>>> I'd go with "hints".
>>>>>
>>>>> Stanimir
>>>>>
>>>>>
>>>>> On Thu, Nov 29, 2012 at 11:43 AM, Aleksey Shipilev <
>>>>> aleksey.shipilev at oracle.com> wrote:
>>>>>
>>>>>> On 11/28/2012 08:42 PM, Gregg Wonderly wrote:
>>>>>> > Going down that path, makes me feel like having it in a more
>>>>>> "public"
>>>>>> > package would be a better choice.  The name "Contended" is now
>>>>>> going to
>>>>>> > be a "reserved" name for many people, when used in annotation form.
>>>>>>  So,
>>>>>> > why not just make it a publicly defined "annotation" which has
>>>>>> > appropriate implementation in appropriate environments?
>>>>>>
>>>>>>  Any concrete suggestion? j.u.c.Contended? j.u.c.hints.Contended?
>>>>>> j.u.c.expert.Contended?
>>>>>>
>>>>>> -Aleksey.
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Concurrency-interest mailing list
>>>>>> Concurrency-interest at cs.oswego.edu
>>>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>>>>
>>>>>
>>>>> ------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Concurrency-interest mailing listConcurrency-interest at cs.oswego.eduhttp://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Concurrency-interest mailing list
>>>> Concurrency-interest at cs.oswego.edu
>>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>>>>
>>>>
>>>
>>>
>>> --
>>> Viktor Klang
>>>
>>> Akka Tech Lead
>>> Typesafe <http://www.typesafe.com/> - The software stack for
>>> applications that scale
>>>
>>> Twitter: @viktorklang
>>>
>>>
>>
>
>
> --
> Viktor Klang
>
> Director of Engineering
> Typesafe <http://www.typesafe.com/> - The software stack for applications
> that scale
>
> Twitter: @viktorklang
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20121129/388d2780/attachment-0001.html>


More information about the Concurrency-interest mailing list