Re: Stolen: Re: [concurrency-interest] LongAdder (was: StripedAdder) and LongAdderTable

[William Louth (JINSPIRED.COM)]

Hi John,

In my blog entry this week I will present our current offering and its 
performance characteristics. But this is not driven exclusively by 
performance though it is a big factor. I want to make it extremely easy 
for counters (longs which cannot be decremented only incremented) to be 
added into code without too much mental  maintenance effort on the 
developer such as needing to create a field or a class holding fields 
representing counter names(paces) used as indices.

Incrementing a counter should be as easy as listing it on a line of code 
though we should also support value specific increments. Maybe this 
would be a whole lot easier with first class DSL support and later the 
JVM evolving to having some specific DSL awareness in its optimization 
routines if the context cannot be easily determined via the existing 
instruction execution mechanics.

With this proposal I am hoping that we can eliminate much of the 
logging/jmx abuses that exist today but at the same time provide a means 
for communication to flow upwards from callers without have to abuse 
return values (pairs, tuples,). A caller could simply make a 
savepoint and then generate a changeset and see the effects (events) as 
a result of its execution and calling similar to what we offer at the 
metering level which includes both activities and meters (mapped to 
counters).

http://opencore.jinspired.com/?page_id=3553#p23

http://williamlouth.wordpress.com/2010/01/05/user-level-metering-with-savepoints-changesets/

I also see this proposal as a means for the JVM to convey provide more 
contextual runtime diagnostics (case-and-effect rather than metric 
causality) and I think it would be a much better option for dynamic 
languages to expose runtime observation rather than having them to be in 
someway retrofit to support something akin to JVMTI. For example JRuby 
could have counters named (j)ruby.object.alloc, (j)ruby.call.count, 
which would then be visible to Java callers (from a calling thread 
specific).

William

On 02/08/2011 00:06, John Rose wrote:
 On Aug 1, 2011, at 7:14 AM, Rémi Forax wrote:

 Basically, this kind of counter already exist in the VM,
 is there a way to bubble them up in Java ?
 William and I talked about this a little at the Summit, too.

 First, a caveat:  It's interesting and useful to start with pseduocode 
 sketches of the desired functionality, along the lines of a new intrinsic 
 thread local long data type in the Java language and bytecodes.  But, it is 
 extremely rare that this turns out to be the right answer.  New bytecodes are 
 very expensive, compared to new APIs.  All less-expensive options have to be 
 exhausted first.

 The right first answer is to create a suitable Java API (usually a class), 
 and then see how to support it in the JVM with suitable optimizations.

 For example, a Java ThreadLocal.get performs about the same underlying 
 operations as a C pthread_getspecific.  When TL.get was first written, 
 microbenchmarks showed that it was much slower than the C equivalent, but it 
 was relatively simple to optimize the relevant code paths (especially 
 Thread.currentThread) in the JVM.

 In the case of thread-local counters, an abstraction like ThreadLocal is 
 almost certainly the right answer.  In fact, ThreadLocallong[]  is the 
 first thing to try.  If that cannot be optimized enough, then we can look 
 into further options.  Note that cannot be optimized enough applies only 
 after a round of compiler work.  A failing microbenchmark is not even close 
 to due diligence on this point!

 Since we don't have reified generics, ThreadLocallong  is not available; 
 wish it were.  Other starting points could be ThreadLocalLong or 
 ThreadLocalLongArray, with a suitably optimized underlying mechanism that 
 stores exactly one long[] reference in each Thread.

 But ThreadLocallong[]  is the first thing to investigate.

 -- John

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: Use of JDK interanl ASM vs external

[William Louth (JINSPIRED.COM)]

Of course this isolation does breaks down if multiple versions of the 
same library, loaded into the runtime, read/write external files such as 
config/property/cache/ files. Then there is the System Property 
instance or is this something also addressed in Java 9?


On 18/02/2015 12:29, Remi Forax wrote:


On 02/18/2015 11:26 AM, Debasish Ray Chawdhuri wrote:

So that it does not mess up with the different version of the library
that the user is trying to use.


It depends what you mean by mess up,
if you mean that your IDE is currently (jdk8) able to see different 
versions of ASM, this is fixed in 9

(because you can specify that a module doesn't re-export packages)
if you mean that your have different versions of ASM in the classpath 
that collide at runtime, this is also fixed in 9

(because you can specify that your code depend on a module version),
that said you will still have several versions at runtime but no 
collision.


Rémi



On Wed, Feb 18, 2015 at 2:10 PM, Ben Evans
benjamin.john.ev...@gmail.com wrote:

OK - I'm going to bite.

Why are we doing this? If we're shipping a general purpose bytecode
manipulation library, then why is it private?

Surely this should become an official, supported  public API?

On Tue, Feb 17, 2015 at 7:58 PM, Remi Forax fo...@univ-mlv.fr wrote:

On 02/17/2015 08:30 PM, Mark Roos wrote:

I see that jdk8 now includes a copy of ASM 
(jdk.internal.org.objectweb.asm).


Is it recommended to use that instance vs suppling a copy with my
application?

thanks
mark


Hi Mark,

These classes are not the one you are looking for :)

As the 'internal' in the package name suggest, these classes are 
intended to

be used by the JDK classes only, and not by anyone else.
BTW, these classes are not visible anymore in jdk9 (even by 
reflection).


regards,
Rémi


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev





___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev


___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: MethodHandles.Lookup and modules

[William Louth (JINSPIRED.COM)]

  
  
teleporting...reminds me of the security mechanism underlying The
Mill http://millcomputing.com/docs/security/

On 19/12/2015 00:35, John Rose wrote:


  
  FYI, we just had a useful conversation about how the
new readability
  restrictions from Jigsaw modules should affect the
MHs.Lookup API.
  Specifically, we need a couple more access modes to
represent the new
  layers of type readability (interacts with lookup
and accessibility),
  plus a special behavior (another access mode bit)
for publicLookup,
  to represent the fact that there is no longer a true
global scope.
  
  
  Given the increased complexity of access layers we
also want to
  add a (trivial) API point to directly drop access
mode bits from a Lookup.
  
  
  See http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-December/005829.html
  (copied below) and nearby messages.
  
  
  The Jigsaw guys have a charming name for what
Lookup.in does:
  It "teleports" a lookup to another location.
 Teleporting outside a module
  tends to shut down all access rights (to preserve
monotonicity of privilege),
  except for publicLookup which retains its special
globalized viewpoint.
  
  
  This is a refinement on the current Lookup
enhancement in the Jigsaw repo.
  As one consequence, the publicLookup.lookupClass can
go back to
  being Object, and is usefully teleportable
elsewhere, so that (in turn)
  it is broadly useful with the new API point
Lookup.findClass, which
  uses the lookupClass as a starting point for name
resolution.
  


— John



  Begin forwarded message:
  
  From: John Rose 

  Subject: Re: MethodHandles.Lookup
and modules

  Date: December 18, 2015 at 12:20:08 AM PST

  To: Alex Buckley 

  Cc: jigsaw-...@openjdk.java.net

  

  

  

___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev