<div dir="ltr"><div dir="ltr">Hi all,<div><br></div><div>Thanks David, I pushed the webrev after re-testing the unit subtests.</div><div><br></div><div>Have all a great evening,</div><div>Jc</div><div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 17, 2018 at 3:47 PM David Holmes <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm fine with the code the way it is.<br>
<br>
Thanks,<br>
David<br>
<br>
On 18/09/2018 4:08 AM, Alex Menkov wrote:<br>
> I raised the point because I remember I saw similar issue.<br>
> Finally I found the issue it and it was about JNIEnv.<br>
> So there is no problem here (as tests creates only a single jvmtiEnv).<br>
> Anyway I think it would be better to use jvmtiEnv passed to callbacks <br>
> (then it remains correct even is other jvmtiEnv is created).<br>
> <br>
> --alex<br>
> <br>
> On 09/17/2018 09:14, JC Beyler wrote:<br>
>> Hi David,<br>
>><br>
>> I think it is fine to leave the caching in the most tests I looked <br>
>> because they want to do JVMTI calls where there is jvmtiEnv* passed <br>
>> in. Would you rather I revert the rawmonitor changes to where it is <br>
>> still using the cached one instead of the one passed in by the call?<br>
>><br>
>> Let me know,<br>
>> Jc<br>
>><br>
>> On Sun, Sep 16, 2018 at 9:15 PM David Holmes <<a href="mailto:david.holmes@oracle.com" target="_blank">david.holmes@oracle.com</a> <br>
>> <mailto:<a href="mailto:david.holmes@oracle.com" target="_blank">david.holmes@oracle.com</a>>> wrote:<br>
>><br>
>> Â Â Â  I took a look at it all and it seems okay, though the use of the <br>
>> cached<br>
>> Â Â Â  jvmtiEnv pointer did not really need to be changed. As per the spec:<br>
>><br>
>> Â Â Â  "JVM TI environments work across threads"<br>
>><br>
>> Â Â Â  The caching and its use is somewhat hard to understand without seeing<br>
>> Â Â Â  where all the call paths are for the functions that still used the<br>
>> Â Â Â  cached version.<br>
>><br>
>> Â Â Â  It would have been simpler to address the caching issue (if it <br>
>> needs to<br>
>> Â Â Â  be addressed) separately.<br>
>><br>
>> Â Â Â  Cheers,<br>
>> Â Â Â  David<br>
>><br>
>> Â Â Â  On 15/09/2018 7:30 AM, Alex Menkov wrote:<br>
>> Â Â Â Â  > Hi Jc,<br>
>> Â Â Â Â  ><br>
>> Â Â Â Â  > I looked only at rawmonitor.cpp (I suppose nothing other has been<br>
>> Â Â Â  changed).<br>
>> Â Â Â Â  > Looks good.<br>
>> Â Â Â Â  ><br>
>> Â Â Â Â  > --alex<br>
>> Â Â Â Â  ><br>
>> Â Â Â Â  > On 09/14/2018 13:50, JC Beyler wrote:<br>
>> Â Â Â Â  >> Hi Alex,<br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >> Ok I understand now what you mean. I just did a double check on<br>
>> Â Â Â  files<br>
>> Â Â Â Â  >> that had global definitions of jvmtiEnv across the tests (not<br>
>> Â Â Â  complete<br>
>> Â Â Â Â  >> but I looked at any file that has a grep for "^jvmtiEnv") and <br>
>> those<br>
>> Â Â Â Â  >> were the only case where this happens.<br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >> Here is a new version:<br>
>> Â Â Â Â  >> Webrev: <a href="http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.02/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.02/</a><br>
>> Â Â Â  <<a href="http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.02/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.02/</a>><br>
>> Â Â Â Â  >> <<a href="http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.02/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.02/</a>><br>
>> Â Â Â Â  >> Bug: <a href="https://bugs.openjdk.java.net/browse/JDK-8210700" rel="noreferrer" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8210700</a><br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >> Let me know what you think and sorry I misunderstood what you <br>
>> meant,<br>
>> Â Â Â Â  >> Jc<br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >> On Fri, Sep 14, 2018 at 10:52 AM Alex Menkov<br>
>> Â Â Â  <<a href="mailto:alexey.menkov@oracle.com" target="_blank">alexey.menkov@oracle.com</a> <mailto:<a href="mailto:alexey.menkov@oracle.com" target="_blank">alexey.menkov@oracle.com</a>><br>
>> Â Â Â Â  >> <mailto:<a href="mailto:alexey.menkov@oracle.com" target="_blank">alexey.menkov@oracle.com</a><br>
>> Â Â Â  <mailto:<a href="mailto:alexey.menkov@oracle.com" target="_blank">alexey.menkov@oracle.com</a>>>> wrote:<br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >> Â Â Â  Hi Jc,<br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >> Â Â Â  On 09/13/2018 20:05, JC Beyler wrote:<br>
>> Â Â Â Â  >> Â Â Â Â  > Thanks Alexey for the review, I fixed all the " ," issues<br>
>> Â Â Â  that<br>
>> Â Â Â Â  >> Â Â Â  the patch<br>
>> Â Â Â Â  >> Â Â Â Â  > changed but there are still at least 29 files that seem<br>
>> Â Â Â  to have<br>
>> Â Â Â Â  >> that<br>
>> Â Â Â Â  >> Â Â Â Â  > issue in the vmTestbase that were not touched by this<br>
>> Â Â Â  webrev. I<br>
>> Â Â Â Â  >> Â Â Â  imagine<br>
>> Â Â Â Â  >> Â Â Â Â  > we can do a refactoring in another webrev (want me to<br>
>> Â Â Â  file it?)<br>
>> Â Â Â Â  >> Â Â Â  or we<br>
>> Â Â Â Â  >> Â Â Â Â  > can try to handle them when we refactor the tests to move<br>
>> Â Â Â  them<br>
>> Â Â Â Â  >> Â Â Â  out of<br>
>> Â Â Â Â  >> Â Â Â Â  > vmTestbase.<br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >> Â Â Â  I don't think we need to fix this minor style issues - I<br>
>> Â Â Â  asked to fix<br>
>> Â Â Â Â  >> Â Â Â  them just because your fix touches the lines.<br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >> Â Â Â  Regarding jvmti/jvmti_env mix:<br>
>> Â Â Â Â  >> Â Â Â  Looks like you are right about<br>
>> Â Â Â  <...>/timers/JvmtiTest/JvmtiTest.cpp<br>
>> Â Â Â Â  >> Â Â Â  (actually if JNI_ENV_ARG didn't drop the 1st arg, the code<br>
>> Â Â Â  would just<br>
>> Â Â Â Â  >> Â Â Â  fail to compile as jvmti_env is undefined in some cases).<br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >> Â Â Â  But the same issues in<br>
>> Â Â Â  <...>/functions/rawmonitor/rawmonitor.cpp<br>
>> Â Â Â Â  >> needs<br>
>> Â Â Â Â  >> Â Â Â  to be fixed.<br>
>> Â Â Â Â  >> Â Â Â  As I wrote before if jvmtiEnv is used in JVMTI callback, it<br>
>> Â Â Â  should<br>
>> Â Â Â Â  >> use<br>
>> Â Â Â Â  >> Â Â Â  jvmtiEnv passed to the callback (callback may be called on a<br>
>> Â Â Â Â  >> different<br>
>> Â Â Â Â  >> Â Â Â  thread and in the case jvmti if different from jvmti_env):<br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >> Â Â Â  void JNICALL vmStart(jvmtiEnv *jvmti_env, JNIEnv *env) {<br>
>> Â Â Â Â  >> Â Â Â Â  Â  Â  Â  jvmtiError res;<br>
>> Â Â Â Â  >> Â Â Â  -  Â  res =<br>
>> Â Â Â Â  >>  Â  Â <br>
>> JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env,<br>
>> Â Â Â Â  >> Â Â Â  &main_thread));<br>
>> Â Â Â Â  >> Â Â Â  +  Â  res = jvmti->GetCurrentThread(&main_thread);<br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >> Â Â Â  should be<br>
>> Â Â Â Â  >> Â Â Â  +  Â  res = jvmti_env->GetCurrentThread(&main_thread);<br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >> Â Â Â  the same for other callbacks in rawmonitor.cpp<br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >> Â Â Â  --alex<br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  > The new webrev is here:<br>
>> Â Â Â Â  >> Â Â Â Â  > Webrev:<br>
>> Â Â Â  <a href="http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.01/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.01/</a><br>
>> Â Â Â  <<a href="http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.01/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.01/</a>><br>
>> Â Â Â Â  >> Â Â Â  <<a href="http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.01/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.01/</a>><br>
>> Â Â Â Â  >> Â Â Â Â  > <br>
>> <<a href="http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.01/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.01/</a>><br>
>> Â Â Â Â  >> Â Â Â Â  > Bug: <a href="https://bugs.openjdk.java.net/browse/JDK-8210700" rel="noreferrer" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8210700</a><br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  > Good catch on the change here:<br>
>> Â Â Â Â  >> Â Â Â Â  > -  Â  res =<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â  JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env,<br>
>> Â Â Â Â  >> Â Â Â Â  > &main_thread));<br>
>> Â Â Â Â  >> Â Â Â Â  > +  Â  res = jvmti->GetCurrentThread(&main_thread);<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  > You are right that the change from Igor introduced this <br>
>> weird<br>
>> Â Â Â Â  >> Â Â Â  part where<br>
>> Â Â Â Â  >> Â Â Â Â  > jvmti and jvmti_env are seemingly used at the same time.<br>
>> Â Â Â  Turns<br>
>> Â Â Â Â  >> Â Â Â  out that<br>
>> Â Â Â Â  >> Â Â Â Â  > for C++, JVMTI_ENV_ARG/JVMTI_ENV_PTR is transformed into:<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  > -#define JNI_ENV_PTR(x) x<br>
>> Â Â Â Â  >> Â Â Â Â  > -#define JNI_ENV_ARG(x, y) y<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  > ..<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  > -#define JVMTI_ENV_PTR JNI_ENV_PTR<br>
>> Â Â Â Â  >> Â Â Â Â  > -#define JVMTI_ENV_ARG JNI_ENV_ARG<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  > So you are right that actually it is weird but it all<br>
>> Â Â Â  works out:<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  > -  Â  res =<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â  JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env,<br>
>> Â Â Â Â  >> Â Â Â Â  > &main_thread));<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  > -> The JVMTI_ENV_PTR is JNI_ENV_PTR which is identity so<br>
>> Â Â Â Â  >> Â Â Â  JVMTI_ENV_PTR(jvmti) -> jvmti<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  > -> The JVMT_ENV_ARG ignores the first argument so<br>
>> Â Â Â Â  >> Â Â Â  JVMTI_ENV_ARG(jvmti_env, &main_thread) -> &main_thread<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  > So my transformation is correct; turns out that Igor's<br>
>> Â Â Â Â  >> Â Â Â  transformation was wrong but because things were in C++,<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  > the undeclared jvmti_env was just ignored.<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  > So apart from the case where I missed something I think<br>
>> Â Â Â  we are<br>
>> Â Â Â Â  >> Â Â Â  good. Let me know what you think,<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  > Jc<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  > On Thu, Sep 13, 2018 at 5:32 PM Alex Menkov<br>
>> Â Â Â Â  >> Â Â Â  <<a href="mailto:alexey.menkov@oracle.com" target="_blank">alexey.menkov@oracle.com</a> <mailto:<a href="mailto:alexey.menkov@oracle.com" target="_blank">alexey.menkov@oracle.com</a>><br>
>> Â Â Â  <mailto:<a href="mailto:alexey.menkov@oracle.com" target="_blank">alexey.menkov@oracle.com</a> <mailto:<a href="mailto:alexey.menkov@oracle.com" target="_blank">alexey.menkov@oracle.com</a>>><br>
>> Â Â Â Â  >> Â Â Â Â  > <mailto:<a href="mailto:alexey.menkov@oracle.com" target="_blank">alexey.menkov@oracle.com</a><br>
>> Â Â Â  <mailto:<a href="mailto:alexey.menkov@oracle.com" target="_blank">alexey.menkov@oracle.com</a>><br>
>> Â Â Â Â  >> Â Â Â  <mailto:<a href="mailto:alexey.menkov@oracle.com" target="_blank">alexey.menkov@oracle.com</a><br>
>> Â Â Â  <mailto:<a href="mailto:alexey.menkov@oracle.com" target="_blank">alexey.menkov@oracle.com</a>>>>> wrote:<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â Hi Jc,<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â Some notes:<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â <...>/MethodBind/JvmtiTest/JvmtiTest.cpp<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â and<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â <...>/StackTrace/JvmtiTest/JvmtiTest.cpp<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â have several places with extra space before comma <br>
>> like:<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â -  Â  ret =<br>
>> Â Â Â Â  >> Â Â Â  JVMTI_ENV_PTR(jvmti)->GetStackTrace(JVMTI_ENV_ARG(jvmti,<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â thr), 0, max_count , stack_buffer, &count);<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â +  Â  ret = jvmti->GetStackTrace(thr, 0, max_count ,<br>
>> Â Â Â Â  >> stack_buffer,<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â &count);<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â <...>/functions/rawmonitor/rawmonitor.cpp<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â and<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â <...>/timers/JvmtiTest/JvmtiTest.cpp<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â have several suspicious changes when JVMTI_ENV_PTR and<br>
>> Â Â Â Â  >> Â Â Â  JVMTI_ENV_ARG<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â have different arguments (that's certainly wrong, but<br>
>> Â Â Â  needs<br>
>> Â Â Â Â  >> to re<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â resolved correctly):<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â -  Â  res =<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â JVMTI_ENV_PTR(jvmti)->GetCurrentThread(JVMTI_ENV_ARG(jvmti_env,<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â &main_thread));<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â +  Â  res = jvmti->GetCurrentThread(&main_thread);<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â JVMTI_ENV_PTR(jvmti) is an address of the function <br>
>> in the<br>
>> Â Â Â Â  >> Â Â Â  vtable, and<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â JVMTI_ENV_ARG(jvmti_env, ...) is a C++ "this" pointer.<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â So I'd expect that this should be<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â +  Â  res = + <br>
>> jvmti_env->GetCurrentThread(&main_thread);<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â Looking at timers/JvmtiTest/JvmtiTest.cpp history<br>
>> Â Â Â  looks like<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  <br>
>> Â JVMTI_ENV_PTR(jvmti)-><func>(JVMTI_ENV_ARG(jvmti_env, ...<br>
>> Â Â Â Â  >> Â Â Â  changes were<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â introduced recently by the fix for "8209611: use C++<br>
>> Â Â Â Â  >> compiler for<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â hotspot tests".<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â /functions/rawmonitor/rawmonitor.cpp had such wrong<br>
>> Â Â Â Â  >> Â Â Â  statements before,<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â so they should be revised carefully.<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â AFAIU if JVMTI dunction is called from some callback<br>
>> Â Â Â  where<br>
>> Â Â Â Â  >> Â Â Â  jvmtiEnv is<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â passed, the passed value should be used.<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â --alex<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â On 09/13/2018 13:26, JC Beyler wrote:<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â  > Hi all,<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â  > We have arrived to the last webrev for removing<br>
>> Â Â Â  the JNI_ENV<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â macros from<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â  > the vmTestbase:<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â  > Webrev:<br>
>> Â Â Â Â  >> <a href="http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.00/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~jcbeyler/8210700/webrev.00/</a><br>
>> Â Â Â  <<a href="http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.00/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.00/</a>><br>
>> Â Â Â Â  >> Â Â Â  <<a href="http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.00/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.00/</a>><br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â  <br>
>> Â <<a href="http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.00/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.00/</a>><br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â  ><br>
>> Â Â Â  <<a href="http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.00/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/%7Ejcbeyler/8210700/webrev.00/</a>><br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â  > Bug: <br>
>> <a href="https://bugs.openjdk.java.net/browse/JDK-8210700" rel="noreferrer" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8210700</a><br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â  > Thanks again for the reviews,<br>
>> Â Â Â Â  >> Â Â Â Â  >  Â  Â  > Jc<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  > --<br>
>> Â Â Â Â  >> Â Â Â Â  ><br>
>> Â Â Â Â  >> Â Â Â Â  > Thanks,<br>
>> Â Â Â Â  >> Â Â Â Â  > Jc<br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >> --<br>
>> Â Â Â Â  >><br>
>> Â Â Â Â  >> Thanks,<br>
>> Â Â Â Â  >> Jc<br>
>><br>
>><br>
>><br>
>> -- <br>
>><br>
>> Thanks,<br>
>> Jc<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br></div>Thanks,<div>Jc</div></div></div>