Process API Updates (JEP 102)

[roger riggs]

Hi,

I'm starting to work on JEP 102, Process API Updates for JDK 9.
The use cases identified include test execution and build systems such
as Jtreg and Hudson/Jenkins. And there is a use-case for using Java
to monitor the health of a more complex system where the processes
are not spawned by the same manager.

The current API of Process itself is pretty complete with the addition 
of a getPid

method to enable identification of subprocesses spawned by the application
and allow external identification.  It will not be possible to intercept 
the input,

output and error streams of an arbitrary process.

From the scope of the JEP, a fairly simple API seems sufficient.
 - Enumerate the direct children
 - The rest of the functions are similar to Process
   - to terminate a process, forcibly and normally
   - to destroy a process and all of its children recursively
   - to check if one is alive
   - to waitFor for termination and retrieve the exit status

Are there use cases for which this is insufficient?  Please comment.

Thanks, Roger

Re: RFR: 8034944: (process) Improve subprocess handling on Solaris

[roger riggs]

Hi Rob, Martin, et.al.

I've prototyped (for 9) a thread reaper[1] that uses a single thread to 
wait for exiting

processes and calling back to the process with the exit status.
the interesting part is getting the exit status back to the Process that 
needs it

It needs more testing and hardening.

I had not considered using a signal handler for SIGCHLD but that's an 
option,

though we need to be very careful about thread usage.

Roger

p.s. comments on the single thread reaper appreciated (in a new thread)
[1]  http://cr.openjdk.java.net/~rriggs/webrev-waitpid/




On 3/24/2014 12:38 AM, Rob McKenna wrote:

Hi folks,

Roger Riggs (cc'd) may want to chip in here as he's looking at the 
reaper thread arrangement in 9 at the moment.


On another note, I too support the merging of those files. I didn't 
think there was much appetite for it at the time so I must admit this 
fell down my todo list. Looking at this bug did remind me that its 
something worth trying though. As per Alan's mail, I'm going to tackle 
it separately if you folks don't mind. I'll have a look at Peter's 
changes (thanks Peter!) as soon as I can and see about getting them in.


-Rob

On 23/03/14 22:30, Martin Buchholz wrote:




On Sun, Mar 23, 2014 at 2:34 AM, Martin Buchholz > wrote:



We have also thought about whether having reaper threads is
necessary.  The Unix rule is that child processes should be
waited for, and some thread needs to do that.  There's no way to
wait for a set of child pids, or to specify a "completion
handler".  Well, you might be able to get the newish waitid() to
do what you want, but it looks like it's not sufficient when java
is running inside a process that might do independent subprocess
creation outside of the JVM.


Actually, I take it back.  With sufficient work, it looks like you 
can get SIGCHLD to give you pid information in siginfo_t si_pid, and 
that can be used to trigger the reaping.  It looks like waitpid is 
"async-signal-safe", so we can call it from our signal handler.


While we're at it we can fix SIGCHLD handling to do signal chaining, 
as with other signals.

Re: [9] Review request: new macro for conversion to jboolean

[roger riggs]

Hi,

For now I would just use the explicit ternary operator.
The macro would have a very narrow use.
Improving the ability to do static checking on JNI types would be a 
larger undertaking.


Roger



On 3/21/2014 5:38 PM, Mike Duigou wrote:

What if we just abandon adding an IS_TRUE / TO_JBOOLEAN macro for now.

I would like to address adding (jboolean) casts to jni.h which I suspect would 
help with the static analysis issues encountered.

For now just use the explicit ? JNI_TRUE : JNI_FALSE whenever a jboolean value 
is needed and we can refactor the naming of the macro, if any is required, 
later.

Mike

On Mar 21 2014, at 08:10 , roger riggs  wrote:


Hi Sergey,

I didn't see any examples of the use case in this thread.  The proposed name 
seems bulky and clumsy.

In the snippet provided, it did not seem necessary to force the cast to 
jboolean.
Both JNI_TRUE and JNI_FALSE are untyped constants.

The macro would just as useful (if I understand the cases) without the cast.

How useful is a simple definition as:

#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE)

then it would look ok to see these in sources:

  return IS_TRUE(obj);

  if (IS_TRUE(obj)) {}

  jboolean ret = IS_TRUE(obj);

The general purpose usage matches the general C conventions for
true and false and match the JNI semantics.

Roger



On 3/19/2014 7:43 PM, Sergey Bylokhov wrote:

Thanks.
So if nobody objects, the final version will be:

#define IS_NULL(obj) ((obj) == NULL)
#define JNU_IsNull(env,obj) ((obj) == NULL)
+#define TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE)


On 3/20/14 12:07 AM, roger riggs wrote:

Hi,

Well...  When JNU_RETURN was added, there was a long discussion about
NOT using JNU unless the JNI environment was an argument to the macro.

So, the simple name is preferred.

Roger

On 3/19/2014 4:08 PM, Phil Race wrote:

PS .. so maybe whilst you are touching this file you could do
#define JNU_CHECK_NULL CHECK_NULL
#define JNU_CHECK_NULL_RETURN CHECK_NULL_RETURN

so we could migrate to these (clearer) ones

-phil.

On 3/19/2014 1:05 PM, Phil Race wrote:

I think having it start with "JNU_" is a good suggestion.
I've been wondering over the last week or so if it would not have been
better to have CHECK_NULL called JNU_CHECK_NULL to reduce collision chances
and to make it clearer where it comes from ..

-phil.

On 3/19/2014 12:49 PM, Mike Duigou wrote:

Definitely a useful macro.

I too would prefer a name like TO_JBOOLEAN since it reveals the result type. 
Also all uppercase to identify it as a macro. If we are paranoid and want to 
reduce the chance of a name collision then JNU_TO_JBOOLEAN perhaps.

I would also define the macro as:

#define JNU_TO_JBOOLEAN(obj) (jboolean) ((obj) ? JNI_TRUE : JNI_FALSE)

so that the type of the result is explicit. Unfortunately jni.h doesn't define 
JNI_TRUE or false with a cast to jboolean as they probably should.

Mike

On Mar 19 2014, at 11:36 , Sergey Bylokhov  wrote:


Thanks Anthony!

Can somebody from the core-libs team take a look?

On 3/17/14 10:31 PM, Anthony Petrov wrote:

Personally, I'd call it to_jboolean(obj), but IS_TRUE(obj) sounds good to me 
too. Either way, I'm fine with the fix.

--
best regards,
Anthony

On 3/17/2014 7:01 PM, Sergey Bylokhov wrote:

Hello.
This review request is for the new macro, which simplify conversion to
jboolean. It will be useful for fixing parfait warnings.

We have a lot of places, where we cast some type to jboolean:

BOOL = retVal;
return (jboolean) retVal;

WARNING: Expecting value of JNI primitive type jboolean: mismatched
value retVal with size 32 bits, retVal used for conversion to int8 in return


+++ b/src/share/native/common/jni_util.hMon Mar 17 18:28:48 2014 +0400
@@ -277,6 +277,7 @@

  #define IS_NULL(obj) ((obj) == NULL)
  #define JNU_IsNull(env,obj) ((obj) == NULL)
+#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE)

I am not sure about the name, probably someone have a better suggestion?

The fix is for jdk9/dev.

--
Best regards, Sergey.


--
Best regards, Sergey.

RFR(S) : 8038186 : [TESTBUG] improvements of test j.l.i.MethodHandles

[Igor Ignatyev]

Hi all,

Please review the patch:

Problems:
- MethodHandlesTest::testCatchException() doesn't provide enough testing 
of j.l.i.MethodHandles::catchException().
- MethodHandlesTest contains more than 3k lines, an auxiliary code 
together w/ a test code, many methods aren't connected w/ each other, 
etc. All this leads to that it is very very hard to understand, maintain.


Fix:
- the auxiliary code was moved to testlibray
- the test code was moved to a separate subpackage
- random signature is used for target and handler
- added scenarios w/ different return types

webrev: http://cr.openjdk.java.net/~iignatyev/8038186/webrev.01/
jbs: https://bugs.openjdk.java.net/browse/JDK-8038186
--
Igor

Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

[Mike Duigou]

On Mar 24 2014, at 12:25 , Martin Buchholz  wrote:

> 
> 
> 
> On Mon, Mar 24, 2014 at 11:25 AM, Peter Levart  wrote:
> 
> On 03/24/2014 06:52 PM, Martin Buchholz wrote:
>> 
>> 
>> 
>> On Wed, Mar 12, 2014 at 1:45 AM, Peter Levart  wrote:
>> 
>> What would the following cost?
>> 
>> 
>> private transient String stringCache;
>> 
>> public String toString() {
>> String sc = stringCache;
>> if (sc == null) {
>> sc = (String) U.getObjectVolatile(this, STRING_CACHE_OFFSET);
>> if (sc == null) {
>> sc = layoutChars(true);
>> if (!U.compareAndSwapObject(this, STRING_CACHE_OFFSET, null, 
>> sc)) {
>> sc = (String) U.getObjectVolatile(this, 
>> STRING_CACHE_OFFSET);
>> }
>> }
>> }
>> return sc;
>> }
>> 
>> I feel I'm missing something.  If read -> volatile read -> CAS works, then 
>> why wouldn't read -> CAS work and be slightly preferable, because "races are 
>> unlikely"?
>> 
>>   public String toString() {
>> String sc = stringCache;
>> if (sc == null) {
>> sc = layoutChars(true);
>> if (!U.compareAndSwapObject(this, STRING_CACHE_OFFSET, null, 
>> sc)) {
>> sc = (String) U.getObjectVolatile(this, STRING_CACHE_OFFSET);
>> }
>> }
>> return sc;
>> }
> 
> ...yeah, I thought about that too. In any case, the overhead of volatile 
> re-read is negligible in this case, since it happens on slow-path and it 
> might reduce the chance of superfluos calls to layoutChars.
> 
> Hmmm OK.  I still slightly prefer my version, but I can see there is a 
> tradeoff, and the difference is very small.

The other issue here, and why this thread has gone on so long, is that we've 
been trying to establish what the best idiom is (for 2014-) for this lazy 
initialization situation so that we can reuse it with less thought and review. 
In this case the chances of race are fairly low and the cost of extra 
layoutChars is bearable. In other cases where we are likely to use the same 
idiom this is less likely true. Peter's current implementation has the 
advantage that is the best-right answer for lazy initialization even in the 
contended/expensive case. I look forward to revisiting this again when the new 
JMM primitives are available. :-)

Mike

Re: RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone()

[Stephen Colebourne]

I'm happy with this updated patch.
Stephen



On 24 March 2014 18:24, Xueming Shen  wrote:

>  Hi Stephen,
>
> The webrev has been updated accordingly.
>
> http://cr.openjdk.java.net/~sherman/8033662/webrev/
>
> Thanks!
> -Sherman
>
>
> On 03/24/2014 08:59 AM, Stephen Colebourne wrote:
>
>  I don't think think email was delivered to me. (And I think another from
> you also wasn't). The email is in the core-libs-dev archive though.
>
>  I think the approach you changed it to is fine in principal although
> whether the tidy up should be in jdk8u is a different matter.
>
> In your changes I think that toParsed() should be renamed to
> toUnresolved(). And there still seem to be instance variables for
> effectiveZone and effectiveChrono (which I thought you were trying to
> remove).
>
> thanks
> Stephen
>
>
>
>
>
> On 24 March 2014 15:00, Xueming Shen  wrote:
>
>>
>> Stephen,
>>
>> I commented on this one last week. I did not see the response, is it
>> something worth considering? or
>> you believe the original approach is the right way to go.
>>
>> Thanks!
>> -Sherman
>>
>>  Original Message   Message-ID:
>> <532b6f87.3000...@oracle.com> <532b6f87.3000...@oracle.com>  Date: Thu,
>> 20 Mar 2014 15:45:27 -0700  From: Xueming Shen 
>>   User-Agent:
>> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110414
>> Thunderbird/3.1.10  MIME-Version: 1.0  To: core-libs-dev@openjdk.java.net  
>> Subject:
>> Re: RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone()  
>> References:
>> 
>> 
>>   In-Reply-To:
>> 
>>   Content-Type:
>> text/plain; charset=ISO-8859-1; format=flowed  Content-Transfer-Encoding:
>> 7bit
>>
>> Hi Stephen,
>>
>> Given the fact that the parser context is no longer public, the parsed from 
>> the
>> formatter is either unresolved or resolved, just wonder if we really need 
>> those
>> "effective" chrono and zone fields in Parsed. It appears perfect for me to 
>> simply
>> keep these info inside the parser context and return the unresolved and 
>> resolved
>> based on the formatter's request, for example
>> http://cr.openjdk.java.net/~sherman/8033662/webrev2/
>>
>> -Sherman
>>
>> On 03/20/2014 11:24 AM, Stephen Colebourne wrote:
>> > Hi there,
>> > It would be great if I could get a review please.
>> >
>> > The patch is viewable in plain text at JIRA (for IP reasons):
>> > https://bugs.openjdk.java.net/secure/attachment/19216/ParseWithZone.patch
>>
>> >
>> > The same patch is viewable in a nice format at GitHub
>> > https://gist.github.com/jodastephen/9505761
>> >
>> > This really needs to make 8u20 IMO, so I need to get it into jdk9 first
>> > thanks
>> > Stephen
>> >
>> >
>> >
>> > On 12 March 2014 12:29, Stephen Colebourne 
>> >   wrote:
>> >> This is a request for review of this bug:
>> >> https://bugs.openjdk.java.net/browse/JDK-8033662
>> >> and the duplicate:
>> >> https://bugs.openjdk.java.net/browse/JDK-8033659
>> >>
>> >> The javadoc of the method java.time.format.DateTimeFormatter::withZone 
>> >> says:
>> >> "If no zone has been parsed, then this override zone will be included
>> >> in the result of the parse where it can be used to build instants and
>> >> date-times."
>> >> However, the implementation doesn't obey this.
>> >>
>> >> This is a very unfortunate bug that makes some date-time parsing a lot 
>> >> harder.
>> >>
>> >> A second related bug in an egde case - not properly handling a
>> >> ChronoZonedDateTime from TemporalField.resolve - is also tested for
>> >> and fixed.
>> >>
>> >>
>> >> Proposed patch:
>> >> https://gist.github.com/jodastephen/9505761
>> >> The patch includes no spec changes.
>> >> The patch includes new and refactored TCK tests. The new tests for
>> >> withZone() and withChronology() are based on the spec.
>> >>
>> >> I need a reviewer and a committer please.
>> >> thanks
>>
>>
>>
>>
>>
>
>

Re: The s.m.Unsafe representation in hotspot and method registration

[Staffan Larsen]

We have abandoned the HSX model. From JDK 8 one version of Hotspot will be tied 
to one version of the JDK. This looks like old code that has not been cleaned 
up.

/Staffan

On 24 mar 2014, at 19:13, Peter Levart  wrote:

> 
> On 03/24/2014 07:02 PM, Paul Sandoz wrote:
>> On Mar 24, 2014, at 6:37 PM, Joel Borggrén-Franck  
>> wrote:
>> 
>>> Hi Paul,
>>> 
>>> I would guess this is because of the HSX model where we could use the same 
>>> VM with different majors of the JDK. Would that make sense?
>>> 
>> I was wondering about too, but does that still apply to JDKs 1.4.0, 1.4.1, 
>> 1.5 and 1.6?
>> 
>> Paul.
> This seems very shaky. Couldn't VM find out more reliably what major JDK it 
> is running with?
> 
> Regards, Peter
> 

Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

[Peter Levart]

On 03/24/2014 06:52 PM, Martin Buchholz wrote:




On Wed, Mar 12, 2014 at 1:45 AM, Peter Levart > wrote:



What would the following cost?


private transient String stringCache;

public String toString() {
String sc = stringCache;
if (sc == null) {
sc = (String) U.getObjectVolatile(this,
STRING_CACHE_OFFSET);
if (sc == null) {
sc = layoutChars(true);
if (!U.compareAndSwapObject(this,
STRING_CACHE_OFFSET, null, sc)) {
sc = (String) U.getObjectVolatile(this,
STRING_CACHE_OFFSET);
}
}
}
return sc;
}


I feel I'm missing something.  If read -> volatile read -> CAS works, 
then why wouldn't read -> CAS work and be slightly preferable, because 
"races are unlikely"?


public String toString() {
  String sc = stringCache;
  if (sc == null) {
  sc = layoutChars(true);
  if (!U.compareAndSwapObject(this, STRING_CACHE_OFFSET, null, 
sc)) {
  sc = (String) U.getObjectVolatile(this, 
STRING_CACHE_OFFSET);

  }
  }
  return sc;
  }


...yeah, I thought about that too. In any case, the overhead of volatile 
re-read is negligible in this case, since it happens on slow-path and it 
might reduce the chance of superfluos calls to layoutChars.


Regards, Peter

Re: RFR: JDK-8033662 DateTimeFormatter parsing ignores withZone()

[Xueming Shen]

Hi Stephen,

The webrev has been updated accordingly.

http://cr.openjdk.java.net/~sherman/8033662/webrev/

Thanks!
-Sherman

On 03/24/2014 08:59 AM, Stephen Colebourne wrote:

I don't think think email was delivered to me. (And I think another from you 
also wasn't). The email is in the core-libs-dev archive though.

I think the approach you changed it to is fine in principal although whether 
the tidy up should be in jdk8u is a different matter.

In your changes I think that toParsed() should be renamed to toUnresolved(). 
And there still seem to be instance variables for effectiveZone and 
effectiveChrono (which I thought you were trying to remove).

thanks
Stephen





On 24 March 2014 15:00, Xueming Shen mailto:xueming.s...@oracle.com>> wrote:


Stephen,

I commented on this one last week. I did not see the response, is it 
something worth considering? or
you believe the original approach is the right way to go.

Thanks!
-Sherman

 Original Message 
Message-ID: <532b6f87.3000...@oracle.com> 

Date:   Thu, 20 Mar 2014 15:45:27 -0700
From:   Xueming Shen  

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) 
Gecko/20110414 Thunderbird/3.1.10
MIME-Version:   1.0
To: core-libs-dev@openjdk.java.net 

Subject:Re: RFR: JDK-8033662 DateTimeFormatter parsing ignores 
withZone()
References:  
 
 

In-Reply-To:
 

Content-Type:   text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding:  7bit



Hi Stephen,

Given the fact that the parser context is no longer public, the parsed from 
the
formatter is either unresolved or resolved, just wonder if we really need 
those
"effective" chrono and zone fields in Parsed. It appears perfect for me to 
simply
keep these info inside the parser context and return the unresolved and 
resolved
based on the formatter's request, for example

http://cr.openjdk.java.net/~sherman/8033662/webrev2/  


-Sherman

On 03/20/2014 11:24 AM, Stephen Colebourne wrote:
>  Hi there,
>  It would be great if I could get a review please.
>
>  The patch is viewable in plain text at JIRA (for IP reasons):
>  https://bugs.openjdk.java.net/secure/attachment/19216/ParseWithZone.patch
> > The same patch is viewable in a nice format at GitHub > https://gist.github.com/jodastephen/9505761 > > This really needs to make 8u20 IMO, so I need to get it into jdk9 first > thanks > Stephen 
> > > > On 12 March 2014 12:29, Stephen Colebourne  wrote: >> This is a request for review of this bug: >> 
https://bugs.openjdk.java.net/browse/JDK-8033662 >> and the duplicate: >> https://bugs.openjdk.java.net/browse/JDK-8033659 >> >> The javadoc of the method java.time.format.DateTimeFormatter::withZone 
says: >> "If no zone has been parsed, then this override zone will be included >> in the result of the parse where it can be used to build instants and >> date-times." >> However, the 
implementation doesn't obey this. >> >> This is a very unfortunate bug that makes some date-time parsing a lot harder. >> >> A second related bug in an egde case - not properly handling a >> 
ChronoZonedDateTime from TemporalField.resolve - is
also tested for >> and fixed. >> >> >> Proposed patch: >> https://gist.github.com/jodastephen/9505761 >> 
The patch includes no spec changes. >> The patch includes new and refactored TCK tests. The new tests for >> withZone() and 
withChronology() are based on the spec. >> >> I need a reviewer and a committer please. >> thanks

Re: The s.m.Unsafe representation in hotspot and method registration

[Paul Sandoz]

On Mar 24, 2014, at 6:37 PM, Joel Borggrén-Franck  
wrote:

> Hi Paul,
> 
> I would guess this is because of the HSX model where we could use the same VM 
> with different majors of the JDK. Would that make sense?
> 

I was wondering about too, but does that still apply to JDKs 1.4.0, 1.4.1, 1.5 
and 1.6?

Paul.

[9] RFR (S): 8038261: JSR292: cache and reuse typed array accessors

[Vladimir Ivanov]

http://cr.openjdk.java.net/~vlivanov/8038261/webrev.00
https://bugs.openjdk.java.net/browse/JDK-8038261
56 lines changed: 26 ins; 14 del; 16 mod

Cache typed array element getters/setters and reuse them.
Initially, it was part of 8037209, but I decided to integrate it 
separately.


Contributed-by: john.r.r...@oracle.com

Testing: jdk/java/{lang/invoke,util}, vm.mlvm.testlist, nashorn, jruby

Configs: -ea -esa -Xverify:all -D...COMPILE_THRESHOLD={0,30}

Best regards,
Vladimir Ivanov

Re: The s.m.Unsafe representation in hotspot and method registration

[Peter Levart]

On 03/24/2014 07:02 PM, Paul Sandoz wrote:

On Mar 24, 2014, at 6:37 PM, Joel Borggrén-Franck  
wrote:


Hi Paul,

I would guess this is because of the HSX model where we could use the same VM 
with different majors of the JDK. Would that make sense?


I was wondering about too, but does that still apply to JDKs 1.4.0, 1.4.1, 1.5 
and 1.6?

Paul.
This seems very shaky. Couldn't VM find out more reliably what major JDK 
it is running with?


Regards, Peter

Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

[Brian Burkhalter]

Hi Peter,

On Mar 24, 2014, at 2:21 AM, Peter Levart  wrote:

> Thanks to Aleksey for re-establishing the access, I bring you results of the 
> microbenchmark from his quad-core Cortex-A9:

Thanks to you and Aleksey for taking the initiative to test on that platform.

> ...as can be seen, the double-checked read-then-volatile-read+CAS trick is 
> about 15% faster than classic volatile-read+CAS in this case.

Just to be sure, by “double-checked read-then-volaite-read+CAS trick” you 
intend "the variant with two methods toString/toStringSlow?”

Thanks,

Brian

Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

[Brian Burkhalter]

Hi Peter,

On Mar 22, 2014, at 2:01 AM, Peter Levart  wrote:

> Looks good. Just a nit. In the following method:
> 
> 3726 private static void matchScale(BigDecimal[] val) {
I concur.

> One of 3 ifs is superfluous. Either the 1st one:
> 
> private static void matchScale(BigDecimal[] val) {
> /* if (val[0].scale == val[1].scale) {
> // return
> } else */ if (val[0].scale < val[1].scale) {
> val[0] = val[0].setScale(val[1].scale, ROUND_UNNECESSARY);
> } else if (val[1].scale < val[0].scale) {
> val[1] = val[1].setScale(val[0].scale, ROUND_UNNECESSARY);
> }
> }
I think this one. I’ll update the patch accordingly.

Thanks,

Brian

Re: The s.m.Unsafe representation in hotspot and method registration

[Joel Borggrén-Franck]

Hi Paul,

I would guess this is because of the HSX model where we could use the same VM 
with different majors of the JDK. Would that make sense?

cheers
/Joel

On 24 Mar 2014, at 17:42, Paul Sandoz  wrote:

> I started working on a patch to remove the monitor related methods on Unsafe, 
> and was thinking this is gonna be easy, it kind of is, but there is some 
> curious code for the registration of the native methods:
> 
>  
> http://hg.openjdk.java.net/jdk9/dev/hotspot/file/tip/src/share/vm/prims/unsafe.cpp#l1685
> 
> JVM_ENTRY(void, JVM_RegisterUnsafeMethods(JNIEnv *env, jclass unsafecls))
>  UnsafeWrapper("JVM_RegisterUnsafeMethods");
>  {
>ThreadToNativeFromVM ttnfv(thread);
> 
>// Unsafe methods
>{
>  bool success = false;
>  // We need to register the 1.6 methods first because the 1.8 methods 
> would register fine on 1.7 and 1.6
>  if (!success) {
>success = register_natives("1.6 methods",   env, unsafecls, 
> methods_16,  sizeof(methods_16)/sizeof(JNINativeMethod));
>  }
>  if (!success) {
>success = register_natives("1.8 methods",   env, unsafecls, 
> methods_18,  sizeof(methods_18)/sizeof(JNINativeMethod));
>  }
>  if (!success) {
>success = register_natives("1.5 methods",   env, unsafecls, 
> methods_15,  sizeof(methods_15)/sizeof(JNINativeMethod));
>  }
>  if (!success) {
>success = register_natives("1.4.1 methods", env, unsafecls, 
> methods_141, sizeof(methods_141)/sizeof(JNINativeMethod));
>  }
>  if (!success) {
>success = register_natives("1.4.0 methods", env, unsafecls, 
> methods_140, sizeof(methods_140)/sizeof(JNINativeMethod));
>  }
>  guarantee(success, "register unsafe natives");
>}
> 
> 
> And there are multiple declarations of the same methods in various arrays. 
> What is the rational for this kind of registration?
> 
> I presume when removing methods one removes entries from all arrays?
> 
> --
> 
> One a separate note i think we can also remove all methods marked with 
> @Deprecated (which according to the comments were done so in 1.4.1).
> 
> Paul.
> 
> 
> 

The s.m.Unsafe representation in hotspot and method registration

[Paul Sandoz]

I started working on a patch to remove the monitor related methods on Unsafe, 
and was thinking this is gonna be easy, it kind of is, but there is some 
curious code for the registration of the native methods:

  
http://hg.openjdk.java.net/jdk9/dev/hotspot/file/tip/src/share/vm/prims/unsafe.cpp#l1685

JVM_ENTRY(void, JVM_RegisterUnsafeMethods(JNIEnv *env, jclass unsafecls))
  UnsafeWrapper("JVM_RegisterUnsafeMethods");
  {
ThreadToNativeFromVM ttnfv(thread);

// Unsafe methods
{
  bool success = false;
  // We need to register the 1.6 methods first because the 1.8 methods 
would register fine on 1.7 and 1.6
  if (!success) {
success = register_natives("1.6 methods",   env, unsafecls, methods_16, 
 sizeof(methods_16)/sizeof(JNINativeMethod));
  }
  if (!success) {
success = register_natives("1.8 methods",   env, unsafecls, methods_18, 
 sizeof(methods_18)/sizeof(JNINativeMethod));
  }
  if (!success) {
success = register_natives("1.5 methods",   env, unsafecls, methods_15, 
 sizeof(methods_15)/sizeof(JNINativeMethod));
  }
  if (!success) {
success = register_natives("1.4.1 methods", env, unsafecls, 
methods_141, sizeof(methods_141)/sizeof(JNINativeMethod));
  }
  if (!success) {
success = register_natives("1.4.0 methods", env, unsafecls, 
methods_140, sizeof(methods_140)/sizeof(JNINativeMethod));
  }
  guarantee(success, "register unsafe natives");
}


And there are multiple declarations of the same methods in various arrays. What 
is the rational for this kind of registration?

I presume when removing methods one removes entries from all arrays?

--

One a separate note i think we can also remove all methods marked with 
@Deprecated (which according to the comments were done so in 1.4.1).

Paul.

Re: [9] RFR (M): 8037209: Improvements and cleanups to bytecode assembly for lambda forms

[Vladimir Ivanov]

Updated version:
http://cr.openjdk.java.net/~vlivanov/8037209/webrev.01/

Changes:
  - rebased to enum-based BasicType;
  - decided to integrate changes for typed array getters/setters 
separately;


Best regards,
Vladimir Ivanov

On 3/14/14 8:36 PM, Vladimir Ivanov wrote:

Doh! crossed webrevs, thanks.

Just had a quick look, this looks like a really nice improvement to
the array setter/getter support, definitely simplified. IIUC the
mh.viewAsType will now handle the appropriate casting. I believe it
might reduce the "ceremony" for array setter/getter MHs [1].

I see there is a PROFILE_LEVEL option, by default set to 0, that
results in casts not being emitted:

+if (VerifyType.isNullConversion(Object.class, pclass,
false)) {
+if (PROFILE_LEVEL > 0)
+emitReferenceCast(Object.class, arg);
+return;
+}
...
+mv.visitLdcInsn(constantPlaceholder(cls));
+mv.visitTypeInsn(Opcodes.CHECKCAST, CLS);
+mv.visitInsn(Opcodes.SWAP);
+mv.visitMethodInsn(Opcodes.INVOKESTATIC, MHI,
"castReference", CLL_SIG, false);
+if (Object[].class.isAssignableFrom(cls))
+mv.visitTypeInsn(Opcodes.CHECKCAST, OBJARY);
+else if (PROFILE_LEVEL > 0)
+mv.visitTypeInsn(Opcodes.CHECKCAST, OBJ);

Can you explain a bit the rational for that?

These casts are redundant - they aren't required for bytecode
correctness. The idea behind PROFILE_LEVEL is to provide more type
information to JIT-compiler. Right now, type profiling occurs on every
checkcast instruction. So, having these additional instructions we can
feed C2 with more accurate information about types.

Consider this as a hack to overcome some of the limitations of current
profiling implementation in VM.

Best regards,
Vladimir Ivanov


Paul.

[1] Below is an inlining trace for an array getter MH in the current
code i obtained a few weeks ago when investigating CAS-based MHs for
arrays:

Inlining _isInstance on constant Class java/lang/Class
Inlining _isInstance on constant Class [Ljava/lang/Object;
Inlining _isInstance on constant Class [Ljava/lang/String;
Inlining _isInstance on constant Class java/lang/String
 @ 12   unsafe.ArrayMHTest::get_mh_orig
(19 bytes)   inline (hot)
   @ 12
java.lang.invoke.LambdaForm$MH/924874137::invokeExact_MT (15 bytes)
inline (hot)
 @ 2
java.lang.invoke.Invokers::checkExactType (30 bytes)   inline (hot)
   @ 11
java.lang.invoke.MethodHandle::type (5 bytes)   accessor
 @ 11
java.lang.invoke.LambdaForm$MH/1980556943::convert (21 bytes)   inline
(hot)
   @ 7
java.lang.invoke.LambdaForm$MH/1892887290::getElement (20 bytes)
inline (hot)
 @ 16
java.lang.invoke.LambdaForm$MH/816943783::convert (37 bytes)   inline
(hot)
   @ 6
java.lang.invoke.LambdaForm$BMH/1350345087::reinvoke (26 bytes)
inline (hot)
 @ 12
java.lang.invoke.BoundMethodHandle$Species_LL::reinvokerTarget (8
bytes)   inline (hot)
 @ 22
java.lang.invoke.LambdaForm$DMH/1162873666::invokeStatic_LL_L (15
bytes)   inline (hot)
   @ 1
java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes)
inline (hot)
   @ 11
sun.invoke.util.ValueConversions::castReference (20 bytes)   inline (hot)
 @ 6
java.lang.Class::isInstance (0 bytes)   (intrinsic)
   @ 17
java.lang.invoke.LambdaForm$BMH/1350345087::reinvoke (26 bytes)
inline (hot)
 @ 12
java.lang.invoke.BoundMethodHandle$Species_LL::reinvokerTarget (8
bytes)   inline (hot)
 @ 22
java.lang.invoke.LambdaForm$DMH/1162873666::invokeStatic_LL_L (15
bytes)   inline (hot)
   @ 1
java.lang.invoke.DirectMethodHandle::internalMemberName (8 bytes)
inline (hot)
   @ 11
sun.invoke.util.ValueConversions::castReference (20 bytes)   inline (hot)
 @ 6
java.lang.Class::isInstance (0 bytes)   (intrinsic)
   @ 33
java.lang.invoke.MethodHandleImpl$ArrayAccessor::getElementL (10
bytes)   inline (hot)
 @ 2   java.lang.Class::cast
(27 bytes)   inline (hot)
   @ 6
java.lang.Class::isInstance (0 bytes)   (intrinsic)
   @ 17
java.lang.invoke.LambdaForm$MH/91466391::convert (23 bytes)   inline
(hot)
 @ 6
java.lang.invoke

Re: RFR (L) 8037210: Get rid of char-based descriptions 'J' of basic types

[Vladimir Ivanov]

Updated version:
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.03/

- changed the way how arrays of types are created:
static final BasicType[] ALL_TYPES = BasicType.values();
static final BasicType[] ARG_TYPES = Arrays.copyOf(ALL_TYPES, 
ALL_TYPES.length-1);


- added a test for BasicType (LambdaFormTest.testBasicType).

Best regards,
Vladimir Ivanov

On 3/22/14 2:08 AM, Vladimir Ivanov wrote:

John, thanks for the feedback.

Updated webrev:
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.02

Also moved LambdaForm.testShortenSignature() into a stand-alone unit test.

Best regards,
Vladimir Ivanov

On 3/21/14 10:54 PM, John Rose wrote:

On Mar 21, 2014, at 8:49 AM, Vladimir Ivanov
mailto:vladimir.x.iva...@oracle.com>>
wrote:


Thanks for the feedback.

What do you think about the following:
http://cr.openjdk.java.net/~vlivanov/8037210/webrev.01/


That looks nice.  Strong typing; who woulda' thunk it.  :-)

The uses of ".ordinal()" are the extra cost relative to using just small
integers.  They seem totally reasonable in the code.

I suggest either wrapping "ordinal" as something like "id" or else
changing temp names like "id" to "ord", to reinforce the use of a common
name.

Don't make the enum class public.  And especially don't make the mutable
arrays public:

+public static final BasicType[] ALL_TYPES = { L_TYPE, I_TYPE,
J_TYPE, F_TYPE, D_TYPE, V_TYPE };
+public static final BasicType[] ARG_TYPES = { L_TYPE, I_TYPE,
J_TYPE, F_TYPE, D_TYPE };

— John

P.S.  That would only be safe if we had (what we don't yet) a notion of
frozen arrays like:

+public static final BasicType final[] ALL_TYPES = { L_TYPE,
I_TYPE, J_TYPE, F_TYPE, D_TYPE, V_TYPE };
+public static final BasicType final[] ARG_TYPES = { L_TYPE,
I_TYPE, J_TYPE, F_TYPE, D_TYPE };



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

Re: Review request for 8038177 Eliminate unnecessary dependency to sun.security.action

[Alan Bateman]

On 21/03/2014 21:28, Mandy Chung wrote:
This is the second patch to eliminate the dependencies to 
sun.security.action:

   https://bugs.openjdk.java.net/browse/JDK-8038177

Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8038177/webrev.00/

It looks good to me too. The only one that I wonder about is 
ExtendedCharsets and whether this might run early in the startup on some 
locales.


-Alan.

Re: Review request for 8038177 Eliminate unnecessary dependency to sun.security.action

[Chris Hegarty]

The changes look good to me Mandy.

-Chris.

On 21/03/14 21:28, Mandy Chung wrote:

This is the second patch to eliminate the dependencies to
sun.security.action:
https://bugs.openjdk.java.net/browse/JDK-8038177

Webrev at:
http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8038177/webrev.00/

Mandy

Re: Reflection.getCallerClass() and @CallerSensitive for a constructor?

[Tom Hawtin]

On 24/03/2014 08:41, Wang Weijun wrote:

Calling Reflection.getCallerClass() needs the @CallerSensitive annotation, but 
it cannot be applied to a constructor.


Ah, I see your message from 2012-11-26 05:46.

> This is very nice but it does not mention Constructor.newInstance(). 
> In fact, I do see the following entries if I'm creating an object

> thru reflection:

And Class.newInstance. Which gives a clue to a problem. Any code that is 
using Constructor.newInstance has to be as careful with it as they are 
with Method.invoke. Slightly more so, as constructors lean on 
overloading rather than having names like all self-respecting methods. 
As we know from experience, existing code does automatically take into 
account bizarre new requirements. I think we have a sufficient quantity 
of caller-sensitive stuff without taking it into new directions.


(From reading the HotSpot sources some time ago (may have changed), in 
particular circumstances some, but not all, constructor reflection 
frames may disappear.)


Tom

Re: RFR 8037857: Methods j.u.Arrays.spliterator/stream(X[], int, int) throw IAE instead of specified AIOOBE when endIndex < startIndex

[Paul Sandoz]

On Mar 24, 2014, at 1:28 PM, Alan Bateman  wrote:

> On 24/03/2014 11:44, Paul Sandoz wrote:
>> Hi,
>> 
>> Simple patch to align code with spec for stream/spliterator factory methods 
>> on Arrays and spliterator methods on Spliterators, and make the next release 
>> of the JCK happy:
>> 
>>   
>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8037857-spliterator-aioob/webrev/
>> 
>> After 9 it should go back to 8u20.
>> 
> This looks good to me.

Thanks.


> The test looks useful too, a minor comment is that I think it's more common 
> to put the test tags at the top after the copyright header.
> 

I like to ensure the first block comment is collapsed in the IDE (as it is 
usually just the license), but that has the unfortunate effect of including any 
directly following blocks (not sure if i can configure it...). In any case i 
will move it up.

Paul.

Re: RFR 8037857: Methods j.u.Arrays.spliterator/stream(X[], int, int) throw IAE instead of specified AIOOBE when endIndex < startIndex

[Alan Bateman]

On 24/03/2014 11:44, Paul Sandoz wrote:

Hi,

Simple patch to align code with spec for stream/spliterator factory methods on 
Arrays and spliterator methods on Spliterators, and make the next release of 
the JCK happy:

   
http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8037857-spliterator-aioob/webrev/

After 9 it should go back to 8u20.

This looks good to me. The test looks useful too, a minor comment is 
that I think it's more common to put the test tags at the top after the 
copyright header.


-Alan

RFR 8037857: Methods j.u.Arrays.spliterator/stream(X[], int, int) throw IAE instead of specified AIOOBE when endIndex < startIndex

[Paul Sandoz]

Hi,

Simple patch to align code with spec for stream/spliterator factory methods on 
Arrays and spliterator methods on Spliterators, and make the next release of 
the JCK happy:

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8037857-spliterator-aioob/webrev/

After 9 it should go back to 8u20.

Paul.

Re: JDK-8036003: Add variable not to separate debug information.

[Magnus Ihse Bursie]

On 2014-03-21 09:57, David Holmes wrote:



And while, technically, you can save symbols externally, and at the same
time keep them in the binary, that does not make sense. So, in a
practical sense, you are going to do #2 if you are going to do #3.


But you can vary what is kept internally independent of what is made 
external.

While that technically is correct, not all combinations does make sense.



And you can't zip external symbols unless you create a non-zipped
version. And if you zip them, it does not make sense to keep the
non-zipped version.


zip vs non-zip is just an issue of disk space. It is not a fundamental 
configuration choice, just a variation on how external symbols are 
packaged.
So can we agree that for external symbols, there are three ways to deal 
with them:

no external symbols
unzipped external symbols
zipped external symbols
?



Can you give a more concrete example of the variations of your "aspects"
that you think my suggested solution would not capture?


I think I already have. There aren't tree simple choices here, there 
are three aspects, each of which could have different variants.


If I could draw a flow chart easily I would but basically if you 
generate debug symbols you can then select what symbols are kept 
internally (the strip policy) and what are put externally (objcopy 
options), then for the external symbol file you can choose zipped or 
unzipped.


Multiple inter-connected choices, not just three (or four if you add 
zipped)


And then there's the aspect that got this bug started, that you need to 
compile with -g to be able to have any useful symbols at all.


While technically you can compile without -g and then run strip, it's a 
combination that does not make sense.


In the end, it all boils down to a few sensible ways to handle all debug 
information.
1) The Oracle way -- copying debug information into an external format 
(that by default is zipped), and stripping the binary as much as reasonable.
2) The community way -- keep everything in the binary, and not creating 
a separate external format.

3) The hardcore way -- ignore debug information alltogether.

Instead of providing a lots of handles and knobs to configure, that will 
allow the user to configure invalid (e.g. zip-external=true, 
produce-external=false), or meaningless (compile-with-debug-flag=yes, 
strip=everything, produce-external=false), I'd rather provide a 
high-level option (or two, if it's not possible to condense into a 
single option) that allows the user to express the intent. And for all 
practical purposes, it's going to be set to either "oracle mode" or 
"community mode".


/Magnus

Re: JDK-8036003: Add variable not to separate debug information.

[Magnus Ihse Bursie]

On 2014-03-21 10:36, Dmitry Samersoff wrote:


(c) Compression mode:

1. none
2. per-section compression, SHF_GNU_COMPRESSED [1]
3. zip entire file



Is 2 something we're doing? I couldn't find any references to it in the 
code. Or is it something we're planning to do?


/Magnus

Re: [9] Review request: new macro for conversion to jboolean

[Anthony Petrov]

How does IS_JNI_TRUE sound?

--
best regards,
Anthony

On 3/23/2014 10:10 PM, Alan Bateman wrote:

On 21/03/2014 15:22, Sergey Bylokhov wrote:

On 3/21/14 7:10 PM, roger riggs wrote:

The macro would just as useful (if I understand the cases) without
the cast.

How useful is a simple definition as:

#define IS_TRUE(obj) ((obj) ? JNI_TRUE : JNI_FALSE)

then it would look ok to see these in sources:

  return IS_TRUE(obj);

  if (IS_TRUE(obj)) {}

  jboolean ret = IS_TRUE(obj);

The general purpose usage matches the general C conventions for
true and false and match the JNI semantics.

Actually that was my initial suggestion(name and usage).

I think the concern with IS_TRUE is that it's not obvious that it's a
jboolean. Also just the potential for it to easily collide with a macro
that casts to bool or (or Windows's BOOL). I can't tell from the JNI
spec if JNI_FALSE/JNI_TRUE are guaranteed to be defined as 0/1 but even
if they are then I guess there is still a concern that a jboolean is
defined as an unsigned 8 bits whereas a bool might not (and a Windows's
BOOL is an int I think). So if a macro is really needed then I think it
will need another name. I thought MIke's original proposal for
JNU_TO_JBOOLEAN wasn't too bad. I see Mike's mail about adding the cases
to the definitions but that isn't going to help with the cases that I
think you are running into where you need to go from Window's BOOL to
jboolean.

-Alan.

Re: Review request for 8035807: Convert use of sun.misc.BASE64Encoder/Decoder with java.util.Base64

[Vincent Ryan]

On 22 Mar 2014, at 03:22, Mandy Chung  wrote:

> Good catch Sherman.
> 
> Vinnie - what's your recommendation for this LDAP change having both 
> encode/decode uses the platform default charset (rather than retaining the 
> old interop issue)?  It's an incompatible change and I'll file a CCC to track 
> this.

Yes. I think that’s the right approach as the compatibility risk is low.


> 
> Mandy
> 
> On 3/21/2014 2:23 AM, Vincent Ryan wrote:
>> You’re right but we’ve never received a report of any charset interop. 
>> issues.
>> Probably such a scenario has never been encountered by customers.
>> 
>> 
>> On 21 Mar 2014, at 05:54, Xueming Shen  wrote:
>> 
>>> Obj.java:#482
>>>It appears sun.misc.BASE64Decoder.decodeBuffer(String) uses String's 
>>> deprecated
>>>String.getBytes(int srcBegin, int srcEnd, byte[] dst, int dstBegin). The 
>>> proposed change
>>>now uses the jvm's default charset. It might trigger incompatible 
>>> behavior if the default
>>>charset is not an ASCII compatible charset.  But if the "Java object in 
>>> LDAP was encoded
>>>with the platform default charset" (as the new comment suggested), the 
>>> old implementation
>>>actually did not work on platform that the default encoding is not ASCII 
>>> compatible, such
>>>as the IBM ebcdic.
>>> 
>>> -Sherman
>>> 
>>> On 3/20/14 3:48 PM, Mandy Chung wrote:
 On 3/19/14 12:28 PM, Xueming Shen wrote:
> On 03/19/2014 11:37 AM, Mandy Chung wrote:
>> https://bugs.openjdk.java.net/browse/JDK-8035807
>> 
>> Webrev at:
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.00/
>> 
>> This patch converts the last 2 references to 
>> sun.misc.BASE64Encoder/Decoder from the jdk repo with java.util.Base64.  
>>  We should also update the tests and I have filed JDK-8037873 for that.
>> 
>> Thanks
>> Mandy
> The sun.misc.BASE64En/Decoder is MIME type, so it outputs the \r\n per 76
> characters during encoding, and ignores/skip \r or \n when decoding. The 
> new
> Base64.getEncoder/Decoder() returns the "basic" Base64 coder, which it 
> never
> inserts line separator when output, and throws exception for any 
> non-base64-
> alphabet character, including \r and \n.
> 
> The only disadvantage/incompatibility (j.u.Base64.getMimeDecoer() vs
> sun.misc.BASE64Decoder) of switching to j.u.Base64 MIME type en/decoder
> is that the Base64 Mime decoder ignores/skips any non-base64-alphabet
> (including \r and \n), while sun.misc.BASE64Decoder appears to simply
> use the init value "-1" for any non-base64-alphabet character for 
> decoding.
> 
> I'm not familiar with the use scenario of ldap's Obj class, so I'm not 
> sure if
> it matters (if it ever outputs/inputs > 76 character data, or even it 
> does,if
> the difference matters).
> 
> Btw, except getMimeEncoder(int ...) all other Base64.getXXXEn/Decoder()
> returns singleton, so the de/encoder cache might not be necessary.
 Thanks Sherman.  Vinnie confirms that it should retain the current 
 behavior as there could be long-lived Java object in LDAP encoded with JDK 
 8 for example and then retrieved with JDK 9.
 
 Here is the updated webrev:
 http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8035807/webrev.01/
 
 Thanks
 Mandy
> 

Re: JDK 9 RFR of 6375303: Review use of caching in BigDecimal

[Peter Levart]

On 03/20/2014 08:49 AM, Aleksey Shipilev wrote:

On 03/20/2014 11:06 AM, Peter Levart wrote:

I was thinking about last night, for question: "Why is this
double-checked non-volatile-then-volatile trick not any faster than pure
volatile variant even on ARM platform where volatile read should have
some penalty compared to normal read?", might be in the fact that
Raspberry Pi is a single-core/single-thread "machine". Would anyone with
JVM JIT compiler expertise care to share some insight? I suspect that on
such platform, the compiler optimizes volatile accesses so that they are
performed without otherwise necessary memory fences...

Yes, at least C2 is known to not emit memory fences on uniprocessor
machines. You need to have a multicore ARM. If you are still interested,
contact me privately and I can arrange the access to my personal
quad-core Cortex-A9.

-Aleksey.


Hi,

Thanks to Aleksey for re-establishing the access, I bring you results of 
the microbenchmark from his quad-core Cortex-A9:


JDK 8 options: -client, org.openjdk.jmh.Main parameters: ".*" -i 10 -r 5 -wi 5 
-w 1 -f 1 [-t 1|max]

--- Baseline, 1-thread ---

Benchmark  Mode   Samples Mean   Mean error 
   Units
o.t.Bench6375303.testFirstToString avgt1069292.305  299.516 
   ns/op
o.t.Bench6375303.testToString  avgt10*20.003* 0.433
ns/op

--- Baseline, 4-threads ---

Benchmark  Mode   Samples Mean   Mean error 
   Units
o.t.Bench6375303.testFirstToString avgt10   100390.024 2158.132 
   ns/op
o.t.Bench6375303.testToString  avgt10*20.151* 0.677
ns/op

--- double-checked nonvolatile-then-volatile-read+CAS, 1-thread ---

Benchmark  Mode   Samples Mean   Mean error 
   Units
o.t.Bench6375303.testFirstToString avgt1069951.406  221.516 
   ns/op
o.t.Bench6375303.testToString  avgt10*19.681* 0.025
ns/op

--- double-checked nonvolatile-then-volatile-read+CAS, 4-threads ---

Benchmark  Mode   Samples Mean   Mean error 
   Units
o.t.Bench6375303.testFirstToString avgt10   104231.335 3842.095 
   ns/op
o.t.Bench6375303.testToString  avgt10*20.030* 0.595
ns/op

--- classic volatile read+CAS, 1-thread ---

Benchmark  Mode   Samples Mean   Mean error 
   Units
o.t.Bench6375303.testFirstToString avgt1069753.542  180.110 
   ns/op
o.t.Bench6375303.testToString  avgt10*23.285* 0.267
ns/op

--- classic volatile read+CAS, 4-threads ---

Benchmark  Mode   Samples Mean   Mean error 
   Units
o.t.Bench6375303.testFirstToString avgt1099664.256 1814.090 
   ns/op
o.t.Bench6375303.testToString  avgt10*23.491* 0.606
ns/op


...as can be seen, the double-checked read-then-volatile-read+CAS trick 
is about 15% faster than classic volatile-read+CAS in this case.



Regards, Peter

Re: Reflection.getCallerClass() and @CallerSensitive for a constructor?

[Wang Weijun]

Calling Reflection.getCallerClass() needs the @CallerSensitive annotation, but 
it cannot be applied to a constructor.

--Max

On Mar 24, 2014, at 16:36, Remi Forax  wrote:

> On 03/24/2014 08:43 AM, Wang Weijun wrote:
>> Reflection.getCallerClass(3) seems work but the method is deprecated.
>> 
>> Thanks
>> Max
>> 
> 
> what is your the question ?
> 
> cheers,
> Rémi
> 

Re: Reflection.getCallerClass() and @CallerSensitive for a constructor?

[Remi Forax]

On 03/24/2014 08:43 AM, Wang Weijun wrote:

Reflection.getCallerClass(3) seems work but the method is deprecated.

Thanks
Max



what is your the question ?

cheers,
Rémi

Reflection.getCallerClass() and @CallerSensitive for a constructor?

[Wang Weijun]

Reflection.getCallerClass(3) seems work but the method is deprecated.

Thanks
Max