RE: RFR: 8180514: TestPrintMdo.java test fails with -XX:-TieredCompilation

[Lindenmaier, Goetz]

Hi Jesper, 

Thanks for opening that issue, if this is implemented
it will help a lot!

Best regards,
  Goetz.

> -Original Message-
> From: Jesper Wilhelmsson 
> Sent: Thursday, October 1, 2020 11:35 PM
> To: Lindenmaier, Goetz 
> Cc: Leonid Mesnik ; serviceability-
> d...@openjdk.java.net; jdk-...@openjdk.java.net
> Subject: Re: RFR: 8180514: TestPrintMdo.java test fails with -XX:-
> TieredCompilation
> 
> I filed https://bugs.openjdk.java.net/browse/SKARA-752 to encourage the
> Skara team to have the bots check this before allowing integration.
> /Jesper
> 
> > On 1 Oct 2020, at 23:06, Lindenmaier, Goetz 
> wrote:
> >
> > Hi,
> >
> > Please open up a dummy copy JBS issue without confidential
> > information if you fix a closed, internal Oracle bug.
> > I missed this before, I only saw it is closed when
> > this was pushed today.
> >
> > It is really annoying to still see closed bugs.
> > I had hoped skara would help to avoid this.
> >
> > Please find a way to fix this, so it does not happen
> > all the time!
> >
> > Best regards,
> >  Goetz
> >
> >> -Original Message-
> >> From: serviceability-dev  On
> >> Behalf Of Leonid Mesnik
> >> Sent: Thursday, October 1, 2020 12:58 AM
> >> To: serviceability-dev@openjdk.java.net
> >> Subject: Re: RFR: 8180514: TestPrintMdo.java test fails with -XX:-
> >> TieredCompilation
> >>
> >> On Wed, 30 Sep 2020 22:51:59 GMT, Leonid Mesnik
> 
> >> wrote:
> >>
> >>> Test fails with -XX:+TieredCompilation because j.l.Object hasn't been
> used
> >> enough time to trigger compilation. So it
> >>
> >> The bug is closed because contain some confidential info. So I explained
> >> issue and fix in this PR description.
> >>
> >> -
> >>
> >> PR: https://git.openjdk.java.net/jdk/pull/447

RE: RFR: 8180514: TestPrintMdo.java test fails with -XX:-TieredCompilation

[Lindenmaier, Goetz]

Hi,

Please open up a dummy copy JBS issue without confidential 
information if you fix a closed, internal Oracle bug.
I missed this before, I only saw it is closed when 
this was pushed today.

It is really annoying to still see closed bugs.
I had hoped skara would help to avoid this.

Please find a way to fix this, so it does not happen 
all the time!

Best regards,
  Goetz

> -Original Message-
> From: serviceability-dev  On
> Behalf Of Leonid Mesnik
> Sent: Thursday, October 1, 2020 12:58 AM
> To: serviceability-dev@openjdk.java.net
> Subject: Re: RFR: 8180514: TestPrintMdo.java test fails with -XX:-
> TieredCompilation
> 
> On Wed, 30 Sep 2020 22:51:59 GMT, Leonid Mesnik 
> wrote:
> 
> > Test fails with -XX:+TieredCompilation because j.l.Object hasn't been used
> enough time to trigger compilation. So it
> 
> The bug is closed because contain some confidential info. So I explained
> issue and fix in this PR description.
> 
> -
> 
> PR: https://git.openjdk.java.net/jdk/pull/447

RE: RFR: 8252837: Cleanup SAP Copyright file headers

[Lindenmaier, Goetz]

Hi Christoph, 

Looks good to me 

Best regards,
  Goetz.

-Original Message-
From: nio-dev  On Behalf Of Christoph Langer
Sent: Montag, 7. September 2020 06:22
To: hotspot-...@openjdk.java.net; net-...@openjdk.java.net; 
nio-...@openjdk.java.net; serviceability-dev@openjdk.java.net
Subject: RFR: 8252837: Cleanup SAP Copyright file headers

The format for SAP copyrights in OpenJDK headers should be like:
Copyright (c)  SAP SE. All rights reserved.
or
Copyright (c) ,  SAP SE. All rights reserved.

There should not be a comma character (",") before "SAP SE".

This is inconsistent in some files which calls for some cleanup.

Please review :)

-

Commit messages:
 - 8252837: Cleanup SAP Copyright file headers

Changes: https://git.openjdk.java.net/jdk/pull/36/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=36=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252837
  Stats: 55 lines in 55 files changed: 0 ins; 0 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk/pull/36.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/36/head:pull/36

PR: https://git.openjdk.java.net/jdk/pull/36

RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

[Lindenmaier, Goetz]

Hi Richard, 

Thanks for the new webrev. 

The small improvements are fine, too.
Reviewed from my side.

Best regards,
  Goetz.

> -Original Message-
> From: Reingruber, Richard 
> Sent: Thursday, August 27, 2020 10:33 PM
> To: Lindenmaier, Goetz ; serviceability-
> d...@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-
> runtime-...@openjdk.java.net
> Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance
> in the Presence of JVMTI Agents
> 
> Hi Goetz,
> 
> > I read through your change again. It looks good to me now.
> > The new naming and additional comments make it
> > easier to read I think, thank you.
> 
> Thanks for all your input!
> 
> > One small thing:
> > deoptimization.cpp, l. 1503
> > You don't really need the brackets. Two lines below you don't use them
> either.
> > (No webrev needed)
> 
> Thanks for providing the correct line off list. Fixed!
> 
> I prepared a new webrev, because I had to rebase after JDK-8249293 [1] and
> because I wanted to make use of JDK-8251384 [2]
> 
> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
> Delta:  http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8.inc/
> 
> The delta looks bigger than it is. Most of it is re-indentation of
> VM_GetOrSetLocal::deoptimize_objects(). You can see this if you look at
> 
> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8.inc/src/hotsp
> ot/share/prims/jvmtiImpl.cpp.udiff.html
> 
> which does not include the whitespace change.
> 
> Hope you are still ok with webrev.8. The changes are marginal. I've
> commented
> each below.
> 
> Thanks, Richard.
> 
> --- Details below ---
> 
> src/hotspot/share/prims/jvmtiImpl.cpp
> 
> @@ -425,11 +425,11 @@
>, _depth(depth)
>, _index(index)
>, _type(type)
>, _jvf(NULL)
>, _set(false)
> -  , _eb(NULL, NULL, false) // no references escape
> +  , _eb(NULL, NULL, type == T_OBJECT)
>, _result(JVMTI_ERROR_NONE)
> 
> Currently 'type' is never equal to T_OBJECT at this location, still I think it
> is better to check. The compiler will replace the compare with false.
> 
> @@ -630,11 +630,11 @@
>  }
> 
>  // Revert optimizations based on escape analysis if this is an access to a
> local object
>  bool VM_GetOrSetLocal::deoptimize_objects(javaVFrame* jvf) {
>  #if COMPILER2_OR_JVMCI
> -  if (NOT_JVMCI(DoEscapeAnalysis &&) _type == T_OBJECT) {
> +  assert(_type == T_OBJECT, "EscapeBarrier should not be active if _type !=
> T_OBJECT");
> 
> I removed the if from VM_GetOrSetLocal::deoptimize_objects(), because
> now it
> only gets called if the VM_GetOrSetLocal instance has an active
> EscapeBarrier
> which will be the case iff the local type is T_OBJECT and if either C2 escape
> analysis is enabled or Graal is used.
> 
> src/hotspot/share/runtime/deoptimization.cpp
> 
> You suggested to remove the braces. Done.
> 
> src/hotspot/share/runtime/deoptimization.hpp
> 
> Must provide definition of EscapeBarrier::barrier_active() for new call site 
> in
> VM_GetOrSetLocal::doit_prologue() if building with COMPILER2_OR_JVMCI
> not
> defined.
> 
> test/hotspot/jtreg/serviceability/jvmti/Heap/IterateHeapWithEscapeAnalysis
> Enabled.java
> 
> Make use of [2] and pass test with minimal vm.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8249293
> [2] https://bugs.openjdk.java.net/browse/JDK-8251384
> 
> -Original Message-
> From: Lindenmaier, Goetz 
> Sent: Samstag, 22. August 2020 07:46
> To: Reingruber, Richard ; serviceability-
> d...@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-
> runtime-...@openjdk.java.net
> Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance
> in the Presence of JVMTI Agents
> 
> Hi Richard,
> 
> I read through your change again. It looks good to me now.
> The new naming and additional comments make it
> easier to read I think, thank you.
> 
> One small thing:
> deoptimization.cpp, l. 1503
> You don't really need the brackets. Two lines below you don't use them
> either.
> (No webrev needed)
> 
> Best regards,
>   Goetz.

RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

[Lindenmaier, Goetz]

Hi Richard,

I read through your change again. It looks good to me now.
The new naming and additional comments make it 
easier to read I think, thank you.

One small thing:
deoptimization.cpp, l. 1503
You don't really need the brackets. Two lines below you don't use them either.
(No webrev needed)

Best regards,
  Goetz.



-Original Message-
From: Reingruber, Richard  
Sent: Dienstag, 18. August 2020 10:44
To: Lindenmaier, Goetz ; 
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; 
hotspot-runtime-...@openjdk.java.net
Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in 
the Presence of JVMTI Agents

Hi Goetz,

I have collected the changes based on your feedback in a new webrev:

Webrev.7: http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.7/
Delta:http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.7.inc/

Most of the changes are renamings, commenting, and reformatting.

Besides that ...

- I converted the native agent of the test IterateHeapWithEscapeAnalysisEnabled
  from C to C++, because this seems to be preferred by serviceability
  developers. I also re-indented the file, but excluded this from the delta
  webrev.

- I had to adapt test/jdk/com/sun/jdi/EATests.java to the fact that background
  compilation (-Xbatch) cannot be reliably disabled for JVMCI
  compilers. E.g. the compile broker will compile in the background if JVMCI is
  not yet fully initialized. Therefore it is possible that test cases are
  executed before the main test method is compiled on the highest level and then
  the test case fails. The higher the system load the higher the probability for
  this to happen. In webrev.7 I skip the compilation level check if the vm is
  configured to use the JVMCI compiler.

I also answered you inline below.

Thanks,
Richard.

-Original Message-
From: Lindenmaier, Goetz  
Sent: Donnerstag, 23. Juli 2020 16:20
To: Reingruber, Richard ; 
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; 
hotspot-runtime-...@openjdk.java.net
Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in 
the Presence of JVMTI Agents

Hi Richard, 

Thanks for your two further explanations in the other thread. 
That made the points clear to me.

> > I was not that happy with the names saying not_global_escape
> > and similar. I now agreed you have to use the terms of the escape
> > analysis (NoEscape ArgEscape= throughout the runtime code. I'm still not 
> > happy with
> > the 'not' in the term, I always try to expand the name to some
> > sentence with a negated verb, but it makes no sense.
> > For example, "has_not_global_escape_in_scope" expands to
> > "Hasn't a global escape in its scope." in my thinking, which makes
> > no sense. You probably mean
> > "Has not-global escape in its scope." or "Has {ArgEscape|NoEscape}
> > in its scope."
> 
> > C2 is using the word "non" in this context, e.g., here
> > alloc->is_non_escaping.
> 
> There is also ConnectionGraph::not_global_escape()
That talks about a single node that represents a single 
Object. An object has a single state wrt. ea.
You use the term for safepoint which tracks a set of objects.
Here, has_not_global_excape can mean
  1. None of the several objects does escape globaly.
  2. There is at least one object that escapes globaly.

> > non obviously negates the adjective 'global',
> > non-global or nonglobal even is a English term I find in the
> > net.
> > So what about "has_non_global_escape_in_scope?"
> 
> And what about has_ea_local_in_scope?
That's good. Please document somewhere that 
Ea_local == ArgEscape | NoEscape.
That's what it is, right?

> > Does jvmti specify that the same limits are used ...?
> > ok on your side.
> 
> I don't know and didn't find anything in a quick search.
Ok, not your business.

> 
> > jvmtiEnvBase.cpp  ok
> > jvmtiImpl.h|cpp  ok
> > jvmtiTagMap.cpp ok
> > whitebox.cpp ok
> 
> > deoptimization.cpp
> 
> > line 177: Please break line
> > line 246, 281: Please break line
> > 1578, 1583, 1589, 1632, 1649, 1651 Break line
> 
> > 1651: You use 'non'-terms, too: non-escaping :)
> 
> I know :) At least here it is wrong I'd say. "...has to be a not escaping 
> obj..."
> sounds better
> (hopefully not only to my german ears).
I thought the term non-escpaing makes it quite clear.
I just wanted to point out that using non above would
be similar to the wording here.

> > IterateHeapWithEscapeAnalysisEnabled.java
> 
> > line 415:
> > msg("wait until target thread has set testMethod_result");
> > while (testMethod_result == 0) {
> > Thread.sleep(50);
> > }
> > Might the t

RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

[Lindenmaier, Goetz]

Hi Richard, 

Thanks for your two further explanations in the other thread. 
That made the points clear to me.

> > I was not that happy with the names saying not_global_escape
> > and similar. I now agreed you have to use the terms of the escape
> > analysis (NoEscape ArgEscape= throughout the runtime code. I'm still not 
> > happy with
> > the 'not' in the term, I always try to expand the name to some
> > sentence with a negated verb, but it makes no sense.
> > For example, "has_not_global_escape_in_scope" expands to
> > "Hasn't a global escape in its scope." in my thinking, which makes
> > no sense. You probably mean
> > "Has not-global escape in its scope." or "Has {ArgEscape|NoEscape}
> > in its scope."
> 
> > C2 is using the word "non" in this context, e.g., here
> > alloc->is_non_escaping.
> 
> There is also ConnectionGraph::not_global_escape()
That talks about a single node that represents a single 
Object. An object has a single state wrt. ea.
You use the term for safepoint which tracks a set of objects.
Here, has_not_global_excape can mean
  1. None of the several objects does escape globaly.
  2. There is at least one object that escapes globaly.

> > non obviously negates the adjective 'global',
> > non-global or nonglobal even is a English term I find in the
> > net.
> > So what about "has_non_global_escape_in_scope?"
> 
> And what about has_ea_local_in_scope?
That's good. Please document somewhere that 
Ea_local == ArgEscape | NoEscape.
That's what it is, right?

> > Does jvmti specify that the same limits are used ...?
> > ok on your side.
> 
> I don't know and didn't find anything in a quick search.
Ok, not your business.

> 
> > jvmtiEnvBase.cpp  ok
> > jvmtiImpl.h|cpp  ok
> > jvmtiTagMap.cpp ok
> > whitebox.cpp ok
> 
> > deoptimization.cpp
> 
> > line 177: Please break line
> > line 246, 281: Please break line
> > 1578, 1583, 1589, 1632, 1649, 1651 Break line
> 
> > 1651: You use 'non'-terms, too: non-escaping :)
> 
> I know :) At least here it is wrong I'd say. "...has to be a not escaping 
> obj..."
> sounds better
> (hopefully not only to my german ears).
I thought the term non-escpaing makes it quite clear.
I just wanted to point out that using non above would
be similar to the wording here.

> > IterateHeapWithEscapeAnalysisEnabled.java
> 
> > line 415:
> > msg("wait until target thread has set testMethod_result");
> > while (testMethod_result == 0) {
> > Thread.sleep(50);
> > }
> > Might the test run into timeouts at this place?
> > The field is volatile, i.e. it will be reloaded
> > in each iteration. But will dontinline_testMethod
> > write it back to main memory in time?
> 
> You mean, the test could hang in that loop for a couple of minutes? I don't
> think so. There are cache coherence protocols in place which will invalidate
> stale data very timely.
Ok, anyways, it would only be a hanging test.
> 
> Ok. I've removed quite a lot of the occurrances.
> 
> > Also, I like full sentences in comments.
> > Especially for me as foreign speaker, this makes
> > things much more clear. I.e., I try to make it
> > a real sentence with articles, capitalized and a
> > dot at the end if there is a subject and a verb
> > in first place.
> > E.g., jvmtiEnvBase.cpp:1327
> 
> Are you referring to the following?
> (from
> http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.6/src/hots
> pot/share/prims/jvmtiEnvBase.cpp.frames.html)
> 
> 1326
> 1327   // If the frame is a compiled one, need to deoptimize it.
> 1328   if (vf->is_compiled_frame()) {
> 
> This line 1327 is preexisting.
Sorry, wrong line number again. 
I think I meant
1333 // eagerly reallocate scalar replaced objects.

But I must admit, the subject is missing. It's one of these 
imperative sentences where the subject is left out, which 
are used throughout documentation.
Bad example, but still a correct sentence, so qualifies 
for punctuation?

Best regards,
  Goetz.

RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

[Lindenmaier, Goetz]

Hi Richard,

Thanks for the quick reply.

> > >   With DeoptimizeObjectsALot enabled internal threads are started that
> > > deoptimize frames and
> > >   objects. The number of threads started are given with
> > > DeoptimizeObjectsALotThreadCountAll and
> > >   DeoptimizeObjectsALotThreadCountSingle. The former targets all
> existing
> > > threads whereas the
> > >   latter operates on a single thread selected round robin.
> > >
> > >   I removed the mode where deoptimizations were performed at every nth
> > > exit from the runtime. I never used it.
> 
> > Do I get it right? You have a n:1 and a n:all test scenario.
> >  n:1: n threads deoptimize 1 Jana threadwhere n => DOALThreadCountSingle
> >  n:m: n threads deoptimize all Java threads where n = DOALThreadCountAll?
> 
> Not quite.
> 
> -XX:+DeoptimizeObjectsALot // required
> -XX:DeoptimizeObjectsALotThreadCountAll=m
> -XX:DeoptimizeObjectsALotThreadCountSingle=n
> 
> Will start m+n threads. Each operating on all existing JavaThreads using
> EscapeBarriers. The
> difference between the 2 thread types is that one distinct EscapeBarrier
> targets either just a
> single thread or all exisitng threads at onece. If just one single thread is
> targeted per
> EscapeBarrier, then it is not always the same thread, but threads are selected
> round robin. So there
> will be n threads selecting independently single threads round robin per
> EscapeBarrier and m threads
> that target all threads in every EscapeBarrier.
Ok, yes, that is how I understood it. 
 
> > > * EscapeBarrier::sync_and_suspend_one(): use a direct handshake and
> > > execute it always independently
> > >   of is_thread_fully_suspended().
> > Is this also a performance optimization?
> 
> Maybe a minor one.
OK

> > > * JavaThread::wait_for_object_deoptimization():
> > >   - Bugfix: the last check of is_obj_deopt_suspend() must be /after/ the
> > > safepoint check! This
> > > caused issues with not walkable stacks with DeoptimizeObjectsALot.
> > OK. As I understand, there was one safepoint check in the old version,
> > now there is one in each iteration.  I assume this is intended, right?
> 
> Yes it is. The important thing here is (A) a safepoint check is needed /after/
> leaving a safe state
> (_thread_in_native, _thread_blocked). (B) Shared variables that are modified
> at safepoints or with handshakes need to be reread /after/ the safepoint 
> check.
> 
> BTW: I only noticed now that since JDK-8240918 JavaThreads themselves
> must disarm their polling
> page. Originally (before handshakes) this was done by the VM thread. With
> handshakes it was done by
> the thread executing the handshake op. This was changed for
> OrderAccess::cross_modify_fence() where
> the poll is left armed if the thread is in native and sice JDK-8240918 it is
> always left armed. So
> when a thread leaves a safe state (native, blocked) and there was a
> handshake/vm op, it will always
> call SafepointMechanism::block_if_requested_slow(), even if the
> handshake/vm operation have been
> processed already and everybody else is happyly executing bytecodes :)
Ok.

> Still (A) and (B) hold.

> > >   - Added limited spinning inspired by HandshakeSpinYield to fix 
> > > regression in
> > > microbenchmark [1]
> > Ok.  Nice improvement, nice catch!
> 
> Yes. It certainly took some time to find out.
> 
> > >
> > > I refer to some more changes answering your questions and comments
> inline
> > > below.
> > >
> > > Thanks,
> > > Richard.
> > >
> > > [1] Microbenchmark:
> > >
> http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.6.microbe
> nchmark/
> > >
> 
> 
> > > > I understand you annotate at safepoints where the escape analysis
> > > > finds out that an object is "better" than global escape.
> > > > This are the cases where the analysis identifies optimization
> > > > opportunities. These annotations are then used to deoptimize
> > > > frames and the objects referenced by them.
> > > > Doesn't this overestimate the optimized
> > > > objects?  E.g., eliminate_alloc_node has many cases where it bails
> > > > out.
> > >
> > > Yes, the implementation is conservative, but it is comparatively simple
> and
> > > the additional debug
> > > info is just 2 flags per safepoint.
> > Thanks. It also helped that you explained to me offline that
> > there are more optimizations than only lock elimination and scalar
> > replacement done based on the ea information.
> > The ea refines the IR graph with allows follow up optimizations
> > which can not easily be tracked back to the escaping objects or
> > the call sites where they do not escape.
> > Thus, if there are non-global escaping objects, you have to
> > deoptimize the frame.
> > Did I repeat that correctly?
> 
> Mostly, but there are also cases where deoptimization is required if and only
> if ea-local objects
> are passed as arguments. This is the case when values are not read directly
> from a frame, but from a callee frame.
Hmm, don't get this completely, but ok.
  

RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

[Lindenmaier, Goetz]

Hi Richard,

> I'll answer to the obvious things in this mail now.
> I'll go through the code thoroughly again and write
> a review of my findings thereafter.
As promised a detailed walk-throug, but without any major findings:

c1_IR.hpp: ok
ci_Env.h|cpp: ok
compiledMethod.cpp, nmethod.cpp: ok
debugInfoRec.h|cpp: ok
scopeDesc.h|cpp ok

compileBroker.h|cpp: 
Maybe a bit of documentation how and why you start 
the threads? I had expected there are two test
scenarios run after each other, but now I understand 'Single'
and 'All' run simultaneously.  Well, this really is a stress test!
Also good the two variants of depotimization are
stressed against each other.
Besides that really nice it's all in one place.

rootResolver.cpp: ok
jvmciCodeInstaller.cpp: ok

c2compiler.cpp: The essence of this change! Just one line :)
Great!

callnode.hpp ok
escape.h|cpp ok
macro.cpp 
I was not that happy with the names saying not_global_escape
and similar. I now agreed you have to use the terms of the escape
analysis (NoEscape ArgEscape= throughout the runtime code. I'm still not happy 
with 
the 'not' in the term, I always try to expand the name to some
sentence with a negated verb, but it makes no sense.
For example, "has_not_global_escape_in_scope" expands to 
"Hasn't a global escape in its scope." in my thinking, which makes 
no sense. You probably mean
"Has not-global escape in its scope." or "Has {ArgEscape|NoEscape} 
in its scope."

C2 is using the word "non" in this context, e.g., here 
alloc->is_non_escaping.

non obviously negates the adjective 'global',
non-global or nonglobal even is a English term I find in the 
net. 
So what about "has_non_global_escape_in_scope?"

matcher.cpp ok

output.cpp:1071
Please break the long line.

jvmtiCodeBlobEvents.cpp ok

jvmtiEnv.cpp
MaxJavaStackTraceDepth is only documented to affect
the exceptions stack trace depth, not to limit jvmti 
operations. Therefore I wondered why it is used here. 
Non of your business, but the flag should
document this in globals.hpp, too.  
Does jvmti specify that the same limits are used ...?
ok on your side.

jvmtiEnvBase.cpp  ok
jvmtiImpl.h|cpp  ok
jvmtiTagMap.cpp ok
whitebox.cpp ok

deoptimization.cpp

line 177: Please break line
line 246, 281: Please break line
1578, 1583, 1589, 1632, 1649, 1651 Break line

1651: You use 'non'-terms, too: non-escaping :)

2805, 2929, 2946ff, break lines

deoptimization.hpp

158, 174, 176 ... I would break lines too, but here you are in
good company :)

globals.hpp ok
mutexLocker.h|cpp ok
objectMonitor.cpp ok

thread.cpp 

2631 typo: sapfepont --> safepoint

thread.hpp ok
thread.inline.hpp ok
vframe.cpp ok
vframe_hp.cpp   458ff break lines
vframe_hp.hpp ok
macros.hpp ok
TEST.ROOT ok
WhiteBox.java ok

IterateHeapWithEscapeAnalysisEnabled.java

line 415:
msg("wait until target thread has set testMethod_result");
while (testMethod_result == 0) {
Thread.sleep(50);
}
Might the test run into timeouts at this place?
The field is volatile, i.e. it will be reloaded
in each iteration. But will dontinline_testMethod
write it back to main memory in time?

libIterateHeapWithEscapeAnalysisEnabled.c ok

EATests.java

This is a very elaborate test.
I found a row of test cases illustrating issues
we talked about before. Really helpful!

1311: TypeO materialize -> materialized

1640: setting local variable i triggers always deoptimization
  --> setting local variable i always triggers deoptimization

2176: dontinline_calee --> dontinline_callee
2510: poping --> popping  ... but I'm not sure here.

https://www.urbandictionary.com/define.php?term=poping
poping
Drinking large amounts of Dextromethorphan Hydrobromide (DXM)based cough syrup, 
and then embarking on an adventure while wandering around neighborhoods or 
parks all night. This is usually done while listening to Punk rock music from a 
portable jambox. 
;)
Don’t do it! 

EATestsJVMTI.java

I think you can just copy this test description into the other
test. You can have two @test comments, they will be treated
as separate tests.  The @requires will be evaluated accordingly.
For an example see 
test/hotspot/jtreg/runtime/exceptionMsgs/NullPointerException/NullPointerExceptionTest.java
which has two different compile setups for the test class (-g).

so, that's it for reading code ...


Some general remarks, maybe a bit picky ...:
I think you could use less commas ',' in comments.
As I understand, you need a comma if the relative
sentence is at the beginning, but not if it is at 
the end:
  If Corona is over, I go to the office.
but
  I go to the office if Corona is over.
I think the same holds for 'because', 'while' etc.
E.g., jvmtiEnvBase.cpp:1313, jvmtiImpl.cpp:646ff, 
vframe_hp.hpp 104ff

Also, I like full sentences in comments.  
Especially for me as foreign speaker, this makes
things much more clear. I.e., I try to make it
a real sentence with articles, capitalized and a
dot at the end if there is a subject and a verb
in first place.
E.g., jvmtiEnvBase.cpp:1327
In many 

RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

[Lindenmaier, Goetz]

Hi Richard, 

I'll answer to the obvious things in this mail now.
I'll go through the code thoroughly again and write 
a review of my findings thereafter.

> So here is the new webrev.6
> 
> Webrev.6:
> http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.6/
> Delta:
> http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.6.inc/
Thanks for the incremental webrev, it's helpful!
 
> I spent most of the time running a microbenchmark [1] I wrote to answer
> questions from your
> review. At first I had trouble with variance in the results until I found out 
> it
> was due to the NUMA
> architecture of the server I used. After that I noticed that there was a
> performance regression of
> about 5% even at low agent activity. I finally found out that it was due to 
> the
> implementation of
> JavaThread::wait_for_object_deoptimization() which is called by the target
> of the JVMTI operation to
> self suspend for object deoptimization. I fixed this by adding limited 
> spinning
> before calling
> wait() on the monitor.
> 
> The delta includes many changes in comments, renaming of names, etc. So
> I'd like to summarize
> functional changes:
> 
> * Collected all the code for the testing feature DeoptimizeObjectsALot in
> compileBroker.cpp and reworked it.
Thanks, this makes it much more compact.

>   With DeoptimizeObjectsALot enabled internal threads are started that
> deoptimize frames and
>   objects. The number of threads started are given with
> DeoptimizeObjectsALotThreadCountAll and
>   DeoptimizeObjectsALotThreadCountSingle. The former targets all existing
> threads whereas the
>   latter operates on a single thread selected round robin.
> 
>   I removed the mode where deoptimizations were performed at every nth
> exit from the runtime. I never used it.

Do I get it right? You have a n:1 and a n:all test scenario.
 n:1: n threads deoptimize 1 Jana threadwhere n = DOALThreadCountSingle
 n:m: n threads deoptimize all Java threads where n = DOALThreadCountAll?

> * EscapeBarrier::sync_and_suspend_one(): use a direct handshake and
> execute it always independently
>   of is_thread_fully_suspended().
Is this also a performance optimization?

> * Bugfix in EscapeBarrier::thread_added(): must not clear deopt flag. Found
> this testing with DeoptimizeObjectsALot.
Ok.

> * Added EscapeBarrier::thread_removed().
Ok.

> * EscapeBarrier constructors: barriers can now be entirely disabled by
> disabling DoEscapeAnalysis.
>   This effectively disables the enhancement.
Good!

> * JavaThread::wait_for_object_deoptimization():
>   - Bugfix: the last check of is_obj_deopt_suspend() must be /after/ the
> safepoint check! This
> caused issues with not walkable stacks with DeoptimizeObjectsALot.
OK. As I understand, there was one safepoint check in the old version, 
now there is one in each iteration.  I assume this is intended, right?

>   - Added limited spinning inspired by HandshakeSpinYield to fix regression in
> microbenchmark [1]
Ok.  Nice improvement, nice catch!

> 
> I refer to some more changes answering your questions and comments inline
> below.
> 
> Thanks,
> Richard.
> 
> [1] Microbenchmark:
> http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.6.microbenchmark/
> 


> > I understand you annotate at safepoints where the escape analysis
> > finds out that an object is "better" than global escape.
> > This are the cases where the analysis identifies optimization
> > opportunities. These annotations are then used to deoptimize
> > frames and the objects referenced by them.
> > Doesn't this overestimate the optimized
> > objects?  E.g., eliminate_alloc_node has many cases where it bails
> > out.
> 
> Yes, the implementation is conservative, but it is comparatively simple and
> the additional debug
> info is just 2 flags per safepoint. 
Thanks. It also helped that you explained to me offline that 
there are more optimizations than only lock elimination and scalar
replacement done based on the ea information.
The ea refines the IR graph with allows follow up optimizations 
which can not easily be tracked back to the escaping objects or 
the call sites where they do not escape. 
Thus, if there are non-global escaping objects, you have to 
deoptimize the frame.
Did I repeat that correctly?
With this understanding, a row of my proposed renamings/comments
are obsolete.


> On the other hand, those JVMTI operations
> that really trigger
> deoptimizations are expected to be comparatively infrequent such that
> switching to the interpreter
> for a few microseconds will hardly have an effect.
That sounds reasonable.

> I've done microbenchmarking to check this.
> 
> http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.6.microbe
> nchmark/
> 
> I found that in the worst case performance can be impacted by 10%. If the
> agent is extremely active
> and does relevant JVMTI calls like GetOwnedMonitorStackDepthInfo() every
> millisecond or more often,
> then the performance impact can be 

RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump

[Lindenmaier, Goetz]

HI Ralf, 

Thanks for the info.
Looks good, in my eyes ready to be pushed.

Best regards,
  Goetz.

-Original Message-
From: Schmelter, Ralf  
Sent: Montag, 8. Juni 2020 11:38
To: Lindenmaier, Goetz ; Langer, Christoph 

Cc: serviceability-dev@openjdk.java.net; hotspot-runtime-...@openjdk.java.net 
runtime ; David Holmes 
; serguei.spit...@oracle.com; Ioi Lam 

Subject: RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump

Hi Goetz,

> What kind of tests did you run?

The jdk submit repo, the JCK tests (apart from API) and the jtreg tests on 
Windows x86/64, MacOS X, linux on x86/64, ppcle, ppcbe, zarch and aarch64 and 
on AIX.

If there aren't any other concerns, I would like to commit this this change on 
Wednesday.  

Best regards,
Ralf

-Original Message-
From: Lindenmaier, Goetz  
Sent: Friday, 5 June 2020 18:02
To: Schmelter, Ralf ; Langer, Christoph 

Cc: serviceability-dev@openjdk.java.net; hotspot-runtime-...@openjdk.java.net 
runtime 
Subject: RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump

Hi Ralf, 

Thanks for the quick reply and all the fixes.
The changes to the workgroup are ok.
Reviewed.  (An incremental webrev would have helped )

What kind of tests did you run?

> Yes, the buffer is now smaller (1M) versus the original (8M). You need
> to be able to at least allocate one buffer or you get an error (this
> is handled in the CompressionBackend ctor). You then allocate
> additional buffers as needed (we want a new buffer, but there is no
> free one), until we have a buffer for every worker thread or until
> the allocation of the buffer failed. In this case some threads will
> be idle, since we cannot have a buffer for each thread.
Ok, that's what I thought. Thanks for the explanation.

> > Another question.
> > The basic dumping is done sequential, right? The comression 
> > is parallel. Is there a tradeoff in #of threads where
> > the compression is faster than writing?
> Yes. The compression and writing is done parallel. Depeding on
> the compression level and the speed of your harddrive, not all
> threads will be active all the time. But since we reuse the GC threads
> this should not matter. And the relative poor performance of
> deflate() ensures that at least 5 to 10 threads will probably always
> be active ;)
Ok, thanks.

Best regards,
  Goetz.

RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump

[Lindenmaier, Goetz]

Hi Ralf, 

Thanks for the quick reply and all the fixes.
The changes to the workgroup are ok.
Reviewed.  (An incremental webrev would have helped )

What kind of tests did you run?

> Yes, the buffer is now smaller (1M) versus the original (8M). You need
> to be able to at least allocate one buffer or you get an error (this
> is handled in the CompressionBackend ctor). You then allocate
> additional buffers as needed (we want a new buffer, but there is no
> free one), until we have a buffer for every worker thread or until
> the allocation of the buffer failed. In this case some threads will
> be idle, since we cannot have a buffer for each thread.
Ok, that's what I thought. Thanks for the explanation.

> > Another question.
> > The basic dumping is done sequential, right? The comression 
> > is parallel. Is there a tradeoff in #of threads where
> > the compression is faster than writing?
> Yes. The compression and writing is done parallel. Depeding on
> the compression level and the speed of your harddrive, not all
> threads will be active all the time. But since we reuse the GC threads
> this should not matter. And the relative poor performance of
> deflate() ensures that at least 5 to 10 threads will probably always
> be active ;)
Ok, thanks.

Best regards,
  Goetz.
____
From: Lindenmaier, Goetz <mailto:goetz.lindenma...@sap.com>
Sent: Wednesday, June 3, 2020 3:14 PM
To: Schmelter, Ralf <mailto:ralf.schmel...@sap.com>; Langer, Christoph 
<mailto:christoph.lan...@sap.com>
Cc: mailto:serviceability-dev@openjdk.java.net 
<mailto:serviceability-dev@openjdk.java.net>; 
mailto:hotspot-runtime-...@openjdk.java.net runtime 
<mailto:hotspot-runtime-...@openjdk.java.net>
Subject: RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump 
 
Hi Ralf,

I had a look at your change, webrev.3.
Thanks for contributing this!
Overall, a nicely engineered piece of work. Thus, my 
comments are mostly minor details:


diagnosticCommand.hpp
  ok.

diagnosticCommand.cpp:

l.510
I would be a bit more precise in the comment:
..."9 the slowest level with the best compression."
or maybe "strongest compression"?

l. 528
I would appreciate if you fixed the existing comment wrt. to the 
language:
  // Request a full GC before dumping the heap if _all is false.
  // This helps reduce the amount of unreachable objects in the dump


heapDumper.hpp
  ok.

heapDumper.cpp

Error messags is now recorded in _backend. ok.
Not overwriting file is moved to FileWriter, ok.

I like how you split the existing code with few
changes to distribute the work to the thread gang, nice!

l.1808
// Now we clear the global variables, so that a future dumper might run.
Is "might" correct? Isn't is "can"?

l.1819
// Write the file header - we always use 1.0.
You lost the ".2" from 1.0.2.


heapDumperCompression.hpp


Usually, in the include guards, only '/' are 
replaced by '_'.

l.31
Extra whitespace before "implementation".

l.36
Initialized --> Initializes
Return --> Returns
it initialized --> initializes

l.119
works --> WriteWorks ... I had to think about this 
a while to figure it's not a typo of 'work' but names
WriteWork instances in short. But the term is used throughout
the code, so maybe leave it as-is.

l.163
Remove "to".
l.165
returns the old --> commits the old  ... or the like.

l.210
type-o maxiumum

heapDumperCompression.cpp

It's a bit confusing that the static variable
is called gzip_func (referring to a dedicated
function), while there is a method load_gzip_func
that loads any function from the gzip library.
What about gzip_zip_func for the variable?

l.113
What's the point of increasing needed_out_size
after the call? You increment the pointer?

l.125
add "of the":
good choice of the buffer sizes

CompressionBackend():
The check not to overwrite the inital, first error is in 
set_error().  ok.

l.224
I think the comment should say "write the last remaining partially"

l.400
I had one overall question, which I think is ansered here
at least partially:
As I understand, writing the dump now needs more buffer memory, 
as there are several WriteWorks held at the same time.
Are they smaller than the buffer used before, so no additional
memory is needed, or is there a fallback if only a few can be
allocated?  Is the fallback implemented here implicitly? Just
because if there is no memory for more works, the algorithm uses the
ones it could allocate, which might result in some idle
threads as there are less works than threads?

This makes it more flexible wrt. to available memory 
than the implementation before, right?

l.441 indentation

l.458
I can't understand why this variable is named "left".
Is this past tense of to leave? Or do you mean the 
left, filled, side of the buffer?


An

RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump

[Lindenmaier, Goetz]

Hi Ralf,

I had a look at your change, webrev.3.
Thanks for contributing this!
Overall, a nicely engineered piece of work. Thus, my 
comments are mostly minor details:


diagnosticCommand.hpp
  ok.

diagnosticCommand.cpp:

l.510
I would be a bit more precise in the comment:
..."9 the slowest level with the best compression."
or maybe "strongest compression"?

l. 528
I would appreciate if you fixed the existing comment wrt. to the 
language:
  // Request a full GC before dumping the heap if _all is false.
  // This helps reduce the amount of unreachable objects in the dump


heapDumper.hpp
  ok.

heapDumper.cpp

Error messags is now recorded in _backend. ok.
Not overwriting file is moved to FileWriter, ok.

I like how you split the existing code with few
changes to distribute the work to the thread gang, nice!

l.1808
// Now we clear the global variables, so that a future dumper might run.
Is "might" correct? Isn't is "can"?

l.1819
// Write the file header - we always use 1.0.
You lost the ".2" from 1.0.2.


heapDumperCompression.hpp


Usually, in the include guards, only '/' are 
replaced by '_'.

l.31
Extra whitespace before "implementation".

l.36
Initialized --> Initializes
Return --> Returns
it initialized --> initializes

l.119
works --> WriteWorks ... I had to think about this 
a while to figure it's not a typo of 'work' but names
WriteWork instances in short. But the term is used throughout
the code, so maybe leave it as-is.

l.163
Remove "to".
l.165
returns the old --> commits the old  ... or the like.

l.210
type-o maxiumum

heapDumperCompression.cpp

It's a bit confusing that the static variable
is called gzip_func (referring to a dedicated
function), while there is a method load_gzip_func
that loads any function from the gzip library.
What about gzip_zip_func for the variable?

l.113
What's the point of increasing needed_out_size
after the call? You increment the pointer?

l.125
add "of the":
good choice of the buffer sizes

CompressionBackend():
The check not to overwrite the inital, first error is in 
set_error().  ok.

l.224
I think the comment should say "write the last remaining partially"

l.400
I had one overall question, which I think is ansered here
at least partially:
As I understand, writing the dump now needs more buffer memory, 
as there are several WriteWorks held at the same time.
Are they smaller than the buffer used before, so no additional
memory is needed, or is there a fallback if only a few can be
allocated?  Is the fallback implemented here implicitly? Just
because if there is no memory for more works, the algorithm uses the
ones it could allocate, which might result in some idle
threads as there are less works than threads?

This makes it more flexible wrt. to available memory 
than the implementation before, right?

l.441 indentation

l.458
I can't understand why this variable is named "left".
Is this past tense of to leave? Or do you mean the 
left, filled, side of the buffer?


Another question.
The basic dumping is done sequential, right? The comression 
is parallel. Is there a tradeoff in #of threads where
the compression is faster than writing?

zip_util.c

Looks good.
I appreciate the precise error message handling you are doing.
Could you please add comments that these functions are used
for heap dump compression?

HprofReader.java

ok.

Reader.java

Should you close in and in2 in case of error?

GzipRandomAccess.java

l.146
closes -> close

l.158  "the the"

This file nicely demonstrates how to read the zipped hprof.
Maybe you can add a hint in the JBS issue to this file?

HeapDumpCompressedTest.java

ok.

The other Tests:
Please merge them all into HeapDumpCompressedTest by using repeated
@test comments. You might not be aware this is 
supported by jtreg. See 
test/hotspot/jtreg/runtime/exceptionMsgs/NullPointerException/NullPointerExceptionTest.java
 for an example.
It will run each @test block sperately and evaluate the @requires as expected.

Best regards,
  Goetz.


-Original Message-
From: serviceability-dev  On 
Behalf Of Schmelter, Ralf
Sent: Montag, 18. Mai 2020 09:23
To: Langer, Christoph 
Cc: serviceability-dev@openjdk.java.net; hotspot-runtime-...@openjdk.java.net 
runtime 
Subject: [CAUTION] RE: RFR(L) 8237354: Add option to jcmd to write a gzipped 
heap dump

Hi Christoph,

I've updated the webrev: 
http://cr.openjdk.java.net/~rschmelter/webrevs/8237354/webrev.3/

The significant changes are moving most of the new compression code to its own 
file, changing to use a single option (see CSR) called -gz with a mandatory 
compression level and to load the zlib only once (analog to the new class 
loader code). Additionally I've removed some long lines.

 Best regards,
Ralf

-Original Message-
From: Langer, Christoph  
Sent: Friday, 1 May 2020 18:46
To: Schmelter, Ralf 
Cc: serviceability-dev@openjdk.java.net; hotspot-runtime-...@openjdk.java.net 
runtime ; coleen.phillim...@oracle.com
Subject: RE: RFR(L) 8237354: Add option to jcmd 

RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

[Lindenmaier, Goetz]

pe analysis only as side remark.  Also, as I understand, 
there is only one frame at given depth?
// Deoptimize frames with optimized objects. This can be omitted locks and 
// objects not allocated but replaced by scalars. In C2, these optimizations
// are based on escape analysis.
// Up to depth, deoptimize frames with any optimized objects.
// From depth to entry_frame, deoptimize only frames that
// pass optimized objects to their callees.
(First part similar for the comment above 
EscapeBarrier::deoptimize_objects_internal().)

What is the check (cur_depth <= depth) good for? Can you 
ever walk past entry_frame?  

Isn't vf->is_compiled_frame() prerequisite that "Move to next physical frame" 
is needed? You could move it into the other check.
If so, similar for deoptimize_objects_all_threads().

Syncronization: looks good. I think others had a look at this before.

EscapeBarrier::deoptimize_objects_internal()
  The method name is misleading, it is not used by 
  deoptimize_objects().
  Also, method with the same name is in Deopitmization.
  Proposal: deoptimize_objects_thread() ?

C1 stubs: this really shows you tested all configurations, great!


mutexLocker: ok.
objectMonitor.cpp: ok
stackValue.hpp   Is this missing clearing a bug?

thread.hpp

I would remove "_ea" from the flag and method names.

Renaming deferred_locals to deferred_updates is good, as well as 
adding a datastructure for it. 
(Adding this data structure might be a breakout, too.)

good.

thread.cpp

good.

vframe.cpp

Is this a bug in existing code?
Makes sense. 

vframe_hp.hpp 
(What stands _hp for? helper? The file should be named compiledVFrame ...)

not_global_escape_in_scope() ...
Again, you mention escape analysis here. Comments above hold, too.

You introduce JvmtiDeferredUpdates. Good.

vframe_hp.cpp

Changes for JvmtiDeferredUpdates, escape state accessors,

line 422:
Would an assertion assert(!info->owner_is_scalar_replaced(), ...) hold here?


macros.hpp
  Good.  


Test coding


compileBroker.h|cpp

You introduce a third class of threads handled here and 
add a new flag to distinguish it. Before, the two kinds
of threads were distinguished implicitly by passing in 
a compiler for compiler threads.
The new thread kind is only used for testing in debug.

make_thread:
You could assert (comp != NULL...) to assure previous
conditions.

line 989 indentation broken

escape.cpp

You enable the optimization in case of testruns. good.

whitebox.cpp  ok.

deoptimization.cpp

deoptimize_objects_alot_loop()  Good.

globals.hpp

Nice docu of flags, but pleas mention "for testing purposes"
or the like in DeoptimizeObjectsALot.
I would place the flags next to each other. 

interfaceSupport.cpp: good.

I'll look at the test themselves in an extra mail (learning from 
Martin )

Best regards,
  Goetz.











> -Original Message-
> From: Reingruber, Richard 
> Sent: Wednesday, April 1, 2020 8:15 AM
> To: Doerr, Martin ; 'Robbin Ehn'
> ; Lindenmaier, Goetz
> ; David Holmes ;
> Vladimir Kozlov (vladimir.koz...@oracle.com) ;
> serviceability-dev@openjdk.java.net; hotspot-compiler-
> d...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net
> Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance
> in the Presence of JVMTI Agents
> 
> Hi Martin,
> 
> > thanks for addressing all my points. I've looked over webrev.5 and I'm
> satisfied with your changes.
> 
> Thanks!
> 
> > I had also promised to review the tests.
> 
> Thanks++
> I appreciate it very much, the tests are many lines of code.
> 
> > test/jdk/com/sun/jdi/EATests.java
> > This is a substantial amount of tests which is appropriate for a such a 
> > large
> change. Skipping some subtests with UseJVMCICompiler makes sense
> because it doesn't provide the necessary JVMTI functionality, yet.
> > Nice work!
> > I also like that you test with and without BiasedLocking. Your tests will 
> > still
> be fine after BiasedLocking deprecation.
> 
> Hope so :)
> 
> > Very minor nits:
> > - 2 typos in comment above EARelockingNestedInflatedTarget: "lockes are
> ommitted" (sounds funny)
> > - You sometimes write "graal" and sometimes "Graal". I guess the capital G
> is better. (Also in EATestsJVMCI.java.)
> 
> > test/jdk/com/sun/jdi/EATestsJVMCI.java
> > EATests with Graal enabled. Nice that you support Graal to some extent.
> Maybe Graal folks want to enhance them in the future. I think this is a good
> starting point.
> 
> Will change this in the next webrev.
> 
> > Conclusion: Looks good and not trivial :-)
> > Now, you have one full review. I'd be ok with covering 2nd review by partial
> reviews.
> > Compiler and JVMTI parts are not too complicated IMHO.
> > Ru

RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents

[Lindenmaier, Goetz]

Hi,

I had a look at the progress of this change. Nothing
happened since Richard posted his update using more
handshakes [1].
But we (SAP) would appreciate a lot if this change could
be successfully reviewed and pushed.

I think there is basic understanding that this 
change is helpful. It fixes a number of issues with JVMTI,
and will deliver the same performance benefits as EA 
does in current production mode for debugging scenarios.

This is important for us as we run our VMs prepared
for debugging in production mode.

I understand that Robbin proposed to replace the usage of 
_suspend_flag with handshakes. Apparently, async handshakes
are needed to do so. We have been waiting a while for removal 
of the _suspend_flag / introduction of async handshakes [2].
What is the status here?

I think we should no longer wait, but proceed with 
this change. We will look into removing the usage of 
suspend_flag introduced here once it is possible to implement 
it with handshakes.

Also, I think it's a good point in time to push this, as 
jdk15 is at the beginning of development.

Best regards,
  Goetz.


[1] 
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-February/037984.html

[2] 
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2019-December/037533.html


> -Original Message-
> From: hotspot-runtime-dev 
> On Behalf Of Reingruber, Richard
> Sent: Dienstag, 4. Februar 2020 09:59
> To: David Holmes ; Vladimir Kozlov
> (vladimir.koz...@oracle.com) ; Robbin Ehn
> ; serviceability-dev@openjdk.java.net; hotspot-
> compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net
> Subject: [CAUTION] RE: RFR(L) 8227745: Enable Escape Analysis for Better
> Performance in the Presence of JVMTI Agents
> 
> Hi,
> 
> I have prepared webrev.4 that incorporates feedback from webrev.3 (thanks!)
> 
> Full: http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.4/
> Incremental:
> http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.4.inc/
> 
> I was not able to eliminate the additional suspend flag now. I'll take care 
> of this
> as soon as the
> existing suspend-resume-mechanism is reworked.
> 
> Testing:
> 
> Nightly tests @SAP:
> 
>   JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance
> Suite, SAP specific tests
>   with fastdebug and release builds on all platforms
> 
>   Stress testing with DeoptimizeObjectsALot running SPECjvm2008 40x parallel
> for 24h
> 
> Thanks, Richard.
> 
> 
> More details on the changes:
> 
> * Hide DeoptimizeObjectsALotThread from external view.
> 
> * Changed EscapeBarrier_lock to be a _safepoint_check_never lock.
>   It used to be _safepoint_check_sometimes, which will be eliminated sooner or
> later.
>   I added explicit thread state changes with ThreadBlockInVM to code paths
> where we can wait()
>   on EscapeBarrier_lock to become safepoint safe.
> 
> * Use handshake EscapeBarrierSuspendHandshake to suspend target threads
> instead of vm operation
>   VM_ThreadSuspendAllForObjDeopt.
> 
> * Removed uses of Threads_lock. When adding a new thread we suspend it iff
> EA optimizations are
>   being reverted. In the previous version we were waiting on Threads_lock
> while EA optimizations
>   were reverted. See EscapeBarrier::thread_added().
> 
> * Made tests require Xmixed compilation mode.
> 
> * Made tests agnostic regarding tiered compilation.
>   I.e. tc isn't disabled anymore, and the tests can be run with tc enabled or
> disabled.
> 
> * Exercising EATests.java as well with stress test options
> DeoptimizeObjectsALot*
>   Due to the non-deterministic deoptimizations some tests need to be skipped.
>   We do this to prevent bit-rot of the stress test code.
> 
> * Executing EATests.java as well with graal if available. Driver for this is
>   EATestsJVMCI.java. Graal cannot pass all tests, because it does not provide 
> all
> the new debug info
>   (namely not_global_escape_in_scope and arg_escape in scopeDesc.hpp).
>   And graal does not yet support the JVMTI operations force early return and
> pop frame.
> 
> * Removed tracing from new jdi tests in EATests.java. Too much trace output
> before the debugging
>   connection is established can cause deadlock because output buffers fill up.
>   (See https://bugs.openjdk.java.net/browse/JDK-8173304)
> 
> * Many copyright year changes and smaller clean-up changes of testing code
> (trailing white-space and
>   the like).
> 
> 
> -Original Message-
> From: David Holmes 
> Sent: Donnerstag, 19. Dezember 2019 03:12
> To: Reingruber, Richard ; serviceability-
> d...@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-
> runtime-...@openjdk.java.net; Vladimir Kozlov (vladimir.koz...@oracle.com)
> 
> Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in
> the Presence of JVMTI Agents
> 
> Hi Richard,
> 
> I think my issue is with the way EliminateNestedLocks works so I'm going
> to look into that more deeply.
> 
> Thanks for the 

RE: RFR: 8233784: ProblemList failing JVMTI scenario tests

[Lindenmaier, Goetz]

Hi David, 

thanks for adding our failures.

Best regards,
  Goetz.

> -Original Message-
> From: David Holmes 
> Sent: Donnerstag, 7. November 2019 13:24
> To: Lindenmaier, Goetz ; serviceability-dev
> ; hotspot-runtime-
> d...@openjdk.java.net
> Subject: Re: RFR: 8233784: ProblemList failing JVMTI scenario tests
> 
> Hi Goetz,
> 
> Thanks for looking at this.
> 
> On 7/11/2019 9:39 pm, Lindenmaier, Goetz wrote:
> > Hi David,
> >
> > we also see these failures in our CI. It is intermittent and on all 
> > platforms.
> > It happens since Nov 4.
> >
> > We saw the following ones you already listed:
> >
> vmTestbase/nsk/jvmti/scenarios/allocation/AP12/ap12t001/TestDescription.j
> ava
> >
> vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t005/TestDescription.jav
> a
> >
> > Further we saw this one, could you please add it, too?
> >
> vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002/TestDescription.jav
> a
> > It failed once with the same kind of message.
> 
> My latest test run just saw that one fail too.
> 
> > Besides that, the change looks good.
> >
> > Further we saw these failing, but I'm not sure it's the same issue:
> >
> vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t001/TestDescription.j
> ava
> >
> vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t002/TestDescription.j
> ava
> > with this message:
> 
> Yes this is the same issue. I've ensured both are in the list.
> 
> I now have 11 on the list, which leaves 151 that have not yet been seen
> to fail. Any test that uses the AgentThread functionality and uses a
> RawMonitorWait is potentially affected. Unfortunately there seems to be
> no easy way to actually determine all the tests affected due to the use
> of utility functions.
> 
> I'll push what I have now so that we can stem the failures.
> Unfortunately I'm out of the office tomorrow morning.
> 
> Thanks,
> David
> -
> 
> > CASE #3:
> > Allocating objects...
> > Start heap iteration thread and field modification loop
> > thread3 started.
> > - ap04t002.cpp, 346: Calling IterateOverObjectsReachableFromObject...
> > - ap04t002.cpp, 352: IterateOverObjectsReachableFromObject finished.
> > - ap04t002.cpp, 354: Iterations count: 247089
> > - ap04t002.cpp, 355: Modifications count: 14
> > - ap04t002.cpp, 358: Errors detected: 0
> > Wait for completion thread to finish
> > thread3 finished.
> > Cleaning tags and references to objects...
> > The following fake exception stacktrace is for failure analysis.
> > nsk.share.Fake_Exception_for_RULE_Creation: (jvmti_tools.cpp:683) error
> > at nsk_lvcomplain(nsk_tools.cpp:172)
> > # ERROR: jvmti_tools.cpp, 683: error
> > #   jvmti error: code=52, name=JVMTI_ERROR_INTERRUPT
> > CASE #3 finished.
> >
> > CASE #4:
> > Allocating objects...
> > --System.err:(18/4306)--
> > java.lang.AssertionError: .../jvm_14/bin/java, -Xmx768m, -
> Djava.awt.headless=true,  ... -agentlib:ap04t002=-waittime=5 -verbose,
> nsk.jvmti.scenarios.allocation.AP04.ap04t002] exit code is 52
> > at ExecDriver.main(ExecDriver.java:137)
> > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMetho
> dAccessorImpl.java:62)
> > at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin
> gMethodAccessorImpl.java:43)
> > at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> > at
> PropertyResolvingWrapper.main(PropertyResolvingWrapper.java:104)
> > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> > at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMetho
> dAccessorImpl.java:62)
> > at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delegatin
> gMethodAccessorImpl.java:43)
> > at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> > at
> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.j
> ava:127)
> > at java.base/java.lang.Thread.run(Thread.java:833)
> >
> >
> >> -Original Message-
> >> From: hotspot-runtime-dev  boun...@openjdk.java.net>
> >> On Behalf Of David Holmes
> >> Sent: Donnerstag, 7. November 2019 11:45
> >> To: serviceability-dev ; hotspot-
> runtime-
> >> d...@openjdk.java.net
> >> Subject: RFR: 8233784: ProblemList failing JVMTI scenario tests
> >

RE: RFR: 8233784: ProblemList failing JVMTI scenario tests

[Lindenmaier, Goetz]

Hi David, 

we also see these failures in our CI. It is intermittent and on all platforms.
It happens since Nov 4.

We saw the following ones you already listed:
  vmTestbase/nsk/jvmti/scenarios/allocation/AP12/ap12t001/TestDescription.java
  vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t005/TestDescription.java

Further we saw this one, could you please add it, too?
  vmTestbase/nsk/jvmti/scenarios/events/EM07/em07t002/TestDescription.java
It failed once with the same kind of message.

Besides that, the change looks good.

Further we saw these failing, but I'm not sure it's the same issue:
  vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t001/TestDescription.java
  vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t002/TestDescription.java
with this message:

CASE #3:
Allocating objects...
Start heap iteration thread and field modification loop
thread3 started.
- ap04t002.cpp, 346: Calling IterateOverObjectsReachableFromObject...
- ap04t002.cpp, 352: IterateOverObjectsReachableFromObject finished.
- ap04t002.cpp, 354: Iterations count: 247089
- ap04t002.cpp, 355: Modifications count: 14
- ap04t002.cpp, 358: Errors detected: 0
Wait for completion thread to finish
thread3 finished.
Cleaning tags and references to objects...
The following fake exception stacktrace is for failure analysis. 
nsk.share.Fake_Exception_for_RULE_Creation: (jvmti_tools.cpp:683) error
at nsk_lvcomplain(nsk_tools.cpp:172)
# ERROR: jvmti_tools.cpp, 683: error
#   jvmti error: code=52, name=JVMTI_ERROR_INTERRUPT
CASE #3 finished.

CASE #4:
Allocating objects...
--System.err:(18/4306)--
java.lang.AssertionError: .../jvm_14/bin/java, -Xmx768m, 
-Djava.awt.headless=true,  ... -agentlib:ap04t002=-waittime=5 -verbose, 
nsk.jvmti.scenarios.allocation.AP04.ap04t002] exit code is 52
at ExecDriver.main(ExecDriver.java:137)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at PropertyResolvingWrapper.main(PropertyResolvingWrapper.java:104)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
at java.base/java.lang.Thread.run(Thread.java:833)


> -Original Message-
> From: hotspot-runtime-dev 
> On Behalf Of David Holmes
> Sent: Donnerstag, 7. November 2019 11:45
> To: serviceability-dev ; hotspot-runtime-
> d...@openjdk.java.net
> Subject: RFR: 8233784: ProblemList failing JVMTI scenario tests
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8233784
> 
> Patch below.
> 
> Getting the fix tested will take a little while and we are getting
> numerous failures in our CI testing. I ran all the scenario tests
> multiple times to try and find all that fail due to this problem. It may
> not be exhaustive, so if needed I'll add more later.
> 
> Thanks,
> David
> -
> 
> iff -r bb2a436e616c test/hotspot/jtreg/ProblemList.txt
> --- a/test/hotspot/jtreg/ProblemList.txt
> +++ b/test/hotspot/jtreg/ProblemList.txt
> @@ -206,4 +206,14 @@
> 
> 
> vmTestbase/nsk/jdwp/ThreadReference/ForceEarlyReturn/forceEarlyReturn00
> 1/forceEarlyReturn001.java
> 7199837 generic-all
> 
> -
> ##
> ###
> +vmTestbase/nsk/jvmti/scenarios/allocation/AP01/ap01t001/TestDescription.
> java
> 8233549 generic-all
> +vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t002/TestDescription.
> java
> 8233549 generic-all
> +vmTestbase/nsk/jvmti/scenarios/allocation/AP04/ap04t003/TestDescription.
> java
> 8233549 generic-all
> +vmTestbase/nsk/jvmti/scenarios/allocation/AP12/ap12t001/TestDescription.
> java
> 8233549 generic-all
> +vmTestbase/nsk/jvmti/scenarios/capability/CM02/cm02t001/TestDescriptio
> n.java
> 8233549 generic-all
> +vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t002/TestDescription.ja
> va
> 8233549 generic-all
> +vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t003/TestDescription.ja
> va
> 8233549 generic-all
> +vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t005/TestDescription.ja
> va
> 8233549 generic-all
> +vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t006/TestDescription.ja
> va
> 8233549 generic-all
> +
> +#
> 

RE: RFR(S): 8228649: [PPC64] SA reads wrong slots from interpreter frames

[Lindenmaier, Goetz]

Hi Martin,

I had a look at your change. 

Thanks for explaining that you had to remove the extra
slot in the debug build so that the stack looks the same 
in both builds offline.
It probably could be distinguished in the build of SA, too, 
but this way it's probably more stable.  Also, I don't 
remember we ever ran into this stack guard.
You might want to describe in the bug how you have fixed this.

Did you check that all the StackOverflow tests still work in the 
debug build?  Like those that depend that a certain frame
causes the overflow?  With smaller frames, this might affect 
the tests.

In the ProblemList, please remove the bugids of 8211767.

@Gustavo, I don't think closing 8211767 is a good idea. It is 
still used for a row of excluded SA tests in the ProblemList, 
see also the comment further down in the bug. 

Best regards,
  Goetz.

> -Original Message-
> From: Doerr, Martin
> Sent: Freitag, 26. Juli 2019 13:02
> To: serviceability-dev@openjdk.java.net; hotspot-runtime-
> d...@openjdk.java.net; Lindenmaier, Goetz ;
> Gustavo Romero 
> Subject: RFR(S): 8228649: [PPC64] SA reads wrong slots from interpreter
> frames
> 
> Hi,
> 
> 
> 
> the jtreg test "serviceability/sa/sadebugd/DebugdConnectTest.java" fails with
> "AssertionFailure: result must >= than stack pointer" on PPC64.
> 
> The Java code doesn't read the right slots for the interpreter frame's 
> monitors.
> 
> 
> 
> I've removed the extra "reserved" slot which existed only in debug builds. It
> was used as additional frame check, but I think we can live without it.
> 
> My new proposal also initializes all relevant interpreter frame slots for 
> better
> tool support:
> 
> http://cr.openjdk.java.net/~mdoerr/8228649_PPC64_sa/webrev.00/
> 
> 
> 
> Please review.
> 
> 
> 
> Best regards,
> 
> Martin
> 
> 

RE: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace

[Lindenmaier, Goetz]

LGTM
  Goetz!

> -Original Message-
> From: Doerr, Martin
> Sent: Montag, 20. Mai 2019 17:49
> To: Lindenmaier, Goetz ; serviceability-
> d...@openjdk.java.net; JC Beyler ; Volker Simonis
> (volker.simo...@gmail.com) 
> Subject: RE: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace
> 
> Hi Götz,
> 
> thanks for reviewing it so quickly.
> 
> Thanks for pointing me to the obsolete comment. I've also fixed in on PPC64
> and also removed a redundant assertion on PPC64:
> http://cr.openjdk.java.net/~mdoerr/8224230_ppc_s390_AsyncCallTrace/webr
> ev.01/
> 
> I haven't used async profiler, but I've ran JTREG tests for hotspot runtime on
> linux PPC64 (Big and Little Endian) and s390 and all ones have passed.
> 
> Best regards,
> Martin
> 
> 
> -Original Message-
> From: Lindenmaier, Goetz
> Sent: Montag, 20. Mai 2019 17:36
> To: Doerr, Martin ; serviceability-
> d...@openjdk.java.net; JC Beyler ; Volker Simonis
> (volker.simo...@gmail.com) 
> Subject: RE: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace
> 
> Hi Martin,
> 
> the changes look good.
> 
> Please fix this comment:
>  // Forte Analyzer AsyncGetCallTrace profiling support is not implemented on
> Linux/S390x.
> I guess it's no more true.  No new webrev needed.
> 
> Did you verify that the test works, or did you also try
> async with the VM on ppc?
> 
> Best regards,
>   Goetz.
> 
> > -Original Message-
> > From: Doerr, Martin
> > Sent: Montag, 20. Mai 2019 17:32
> > To: serviceability-dev@openjdk.java.net; JC Beyler ;
> > Volker Simonis (volker.simo...@gmail.com) ;
> > Lindenmaier, Goetz 
> > Subject: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace
> >
> > Hi,
> >
> >
> >
> > please review my change which allows usage of AsyncGetCallTrace on PPC64
> > and s390.
> >
> >
> >
> > Webrev:
> >
> >
> http://cr.openjdk.java.net/~mdoerr/8224230_ppc_s390_AsyncCallTrace/webr
> > ev.00/
> >
> >
> >
> > Bug with more background information:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8224230
> >
> >
> >
> > Best regards,
> >
> > Martin
> >
> >

RE: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace

[Lindenmaier, Goetz]

Hi Martin, 

the changes look good. 

Please fix this comment:
 // Forte Analyzer AsyncGetCallTrace profiling support is not implemented on 
Linux/S390x.
I guess it's no more true.  No new webrev needed.

Did you verify that the test works, or did you also try 
async with the VM on ppc?

Best regards,
  Goetz.

> -Original Message-
> From: Doerr, Martin
> Sent: Montag, 20. Mai 2019 17:32
> To: serviceability-dev@openjdk.java.net; JC Beyler ;
> Volker Simonis (volker.simo...@gmail.com) ;
> Lindenmaier, Goetz 
> Subject: RFR(S): 8224230: [PPC64, s390] Support AsyncGetCallTrace
> 
> Hi,
> 
> 
> 
> please review my change which allows usage of AsyncGetCallTrace on PPC64
> and s390.
> 
> 
> 
> Webrev:
> 
> http://cr.openjdk.java.net/~mdoerr/8224230_ppc_s390_AsyncCallTrace/webr
> ev.00/
> 
> 
> 
> Bug with more background information:
> 
> https://bugs.openjdk.java.net/browse/JDK-8224230
> 
> 
> 
> Best regards,
> 
> Martin
> 
> 

RE: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers

[Lindenmaier, Goetz]

> > Why do you remove some checks for test failures from some tests?
> > Like
> >serviceability/sa/ClhsdbInspect.java
> > Why won't jstackOutput be null any more after your change?
> 
> I don't think it can actually be null before the change:
> ClhsdbLauncher.run calls ClhsdbLauncher.runCmd which will either throw,
> or return a non-null (put possibly empty) String.
> 
> So that seems like a simple cleanup to me.
If this holds for the other files with similar edits I listed below, too,
consider this Reviewed by me as well.

Best regards,
  Goetz.

> > Others are:
> >serviceability/sa/ClhsdbJdis.java
> >serviceability/sa/ClhsdbLongConstant.java
> >serviceability/sa/ClhsdbPrintAs.java
> >serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java
> >serviceability/sa/ClhsdbScanOops.java
> >serviceability/sa/ClhsdbThread.java
> >
> > Are these all failures that go back to the attach issue?
> >
> > Best regards,
> >Goetz.
> >
> >
> >> -Original Message-
> >> From: Lindenmaier, Goetz
> >> Sent: Donnerstag, 31. Januar 2019 12:54
> >> To: 'Jini George' ; serviceability-
> >> d...@openjdk.java.net
> >> Subject: RE: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP
> docker
> >> containers
> >>
> >> Hi Jini,
> >>
> >> I pushed it into our testing:
> >> https://ci.sapmachine.io/view/Build%20My%20Branch/job/branch-build-
> >> service/43/
> >>
> >> the build is running ...
> >>
> >> Best regards,
> >>Goetz.
> >>
> >>> -Original Message-
> >>> From: serviceability-dev 
> On
> >>> Behalf Of Jini George
> >>> Sent: Mittwoch, 30. Januar 2019 12:59
> >>> To: serviceability-dev@openjdk.java.net
> >>> Subject: RFR: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP
> >> docker
> >>> containers
> >>>
> >>> Requesting reviews for:
> >>>
> >>> BugID: https://bugs.openjdk.java.net/browse/JDK-8217473
> >>>
> Webrev:http://cr.openjdk.java.net/~jgeorge/8217473/webrev.01/index.html
> >>>
> >>> The patch includes changes to use SkippedException to skip the tests
> >>> when canPtraceAttachLinux() in Platform.java returns false.
> >>>
> >>> Thanks,
> >>> Jini.
> >

RE: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers

[Lindenmaier, Goetz]

... and the tests passed.
https://ci.sapmachine.io/job/branch-build-linux_x86_64/12/JT_20Report_20hotspot/

Unfortunately one can not see the jtr file to verify the right exception was 
thrown.  But they passed, so it's good. 

Why do you remove some checks for test failures from some tests?
Like 
  serviceability/sa/ClhsdbInspect.java
Why won't jstackOutput be null any more after your change?

Others are:
  serviceability/sa/ClhsdbJdis.java
  serviceability/sa/ClhsdbLongConstant.java
  serviceability/sa/ClhsdbPrintAs.java
  serviceability/sa/ClhsdbRegionDetailsScanOopsForG1.java
  serviceability/sa/ClhsdbScanOops.java
  serviceability/sa/ClhsdbThread.java

Are these all failures that go back to the attach issue?

Best regards,
  Goetz.


> -Original Message-
> From: Lindenmaier, Goetz
> Sent: Donnerstag, 31. Januar 2019 12:54
> To: 'Jini George' ; serviceability-
> d...@openjdk.java.net
> Subject: RE: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker
> containers
> 
> Hi Jini,
> 
> I pushed it into our testing:
> https://ci.sapmachine.io/view/Build%20My%20Branch/job/branch-build-
> service/43/
> 
> the build is running ...
> 
> Best regards,
>   Goetz.
> 
> > -Original Message-
> > From: serviceability-dev  On
> > Behalf Of Jini George
> > Sent: Mittwoch, 30. Januar 2019 12:59
> > To: serviceability-dev@openjdk.java.net
> > Subject: RFR: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP
> docker
> > containers
> >
> > Requesting reviews for:
> >
> > BugID: https://bugs.openjdk.java.net/browse/JDK-8217473
> > Webrev:http://cr.openjdk.java.net/~jgeorge/8217473/webrev.01/index.html
> >
> > The patch includes changes to use SkippedException to skip the tests
> > when canPtraceAttachLinux() in Platform.java returns false.
> >
> > Thanks,
> > Jini.

RE: HotSpot Serviceability Agent (SA) Survey

[Lindenmaier, Goetz]

Hi,

any news on this?
We get questions for the results by the people I made 
participate in this :)

Best regards,
  Goetz. 


> -Original Message-
> From: serviceability-dev  On
> Behalf Of Stephen Fitch
> Sent: Dienstag, 3. Juli 2018 14:18
> To: Per Liden ; serviceability-dev@openjdk.java.net
> Subject: Re: HotSpot Serviceability Agent (SA) Survey
> 
> Hi Per,
> 
> Sadly delayed by other things; I'll put some further solid effort
> into a published summary ASAP, ideally before the end of July, if
> not before.
> 
> It's not forgotten, but behind other priorities.
> 
> Regards,
> 
>   Stephen
> 
> On 7/3/18 1:47 AM, Per Liden wrote:
> > Hi Stephen,
> >
> > On 03/21/2018 07:14 PM, Stephen Fitch wrote:
> >> Hi,
> >>
> >> The HotSpot Serviceability Agent (SA) is a set of APIs and tools for
> >> debugging HotSpot Virtual Machine and has been a part of the JVM/JDK for
> a
> >> long time, however we don't have a lot of data about how it is used in
> >> practice, especially outside of Oracle. Therefore, we have created an 
> >> initial
> >> survey to gather more information and help us evaluate and understand
> how
> >> others are using it.
> >>
> >> If you have used, or have (support) processes that utilize the 
> >> Serviceability
> >> Agent or related APIs, then we would definitely appreciate if you would
> >> complete this survey:
> >>
> >> https://www.surveymonkey.com/r/CF3MYDL
> >>
> >> We are specifically interested in your use-cases and how SA is effective 
> >> for
> >> you in resolving JVM issues.
> >>
> >> The survey will remain open through March 31st. The results of the survey
> >> will be made public after the survey closes.
> >
> > Have the results been published yet?
> >
> > cheers,
> > Per
> >
> >>
> >> Regards, Stephen
> >>
> >>   Java Platform Group - JVM - Sustaining Engineering

RE: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker containers

[Lindenmaier, Goetz]

Hi Jini, 

I pushed it into our testing:
https://ci.sapmachine.io/view/Build%20My%20Branch/job/branch-build-service/43/

the build is running ...

Best regards,
  Goetz.

> -Original Message-
> From: serviceability-dev  On
> Behalf Of Jini George
> Sent: Mittwoch, 30. Januar 2019 12:59
> To: serviceability-dev@openjdk.java.net
> Subject: RFR: JDK-8217473: SA: Tests using ClhsdbLauncher fail on SAP docker
> containers
> 
> Requesting reviews for:
> 
> BugID: https://bugs.openjdk.java.net/browse/JDK-8217473
> Webrev:http://cr.openjdk.java.net/~jgeorge/8217473/webrev.01/index.html
> 
> The patch includes changes to use SkippedException to skip the tests
> when canPtraceAttachLinux() in Platform.java returns false.
> 
> Thanks,
> Jini.

RE: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5

[Lindenmaier, Goetz]

Sure, I'll try to test it.

Best regards,
  Goetz.

> -Original Message-
> From: Jini George 
> Sent: Sonntag, 20. Januar 2019 17:12
> To: David Holmes ; Lindenmaier, Goetz
> ; serviceability-dev@openjdk.java.net
> Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo
> privileges to enable MacOS tests on Mach5
> 
> Thanks, Goetz for letting me know of the failure and thanks, David for
> the suggestion wrt SkippedException. Goetz, I will send you a patch
> off-list, and it would be great if you could test it again for me.
> 
> Thanks,
> Jini.
> 
> On 1/20/2019 4:18 AM, David Holmes wrote:
> > On 18/01/2019 11:30 pm, Lindenmaier, Goetz wrote:
> >> Hi Jini,
> >>
> >> we see test failing after this change arrived deeper in our
> >> infrastructure.
> >> On a linuxx86_64 docker container it does not work.
> >>
> >> This is because you now throw Error() if shouldSAAttach() returns false.
> >> I think you need this:
> >> --- a/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java    Thu
> >> Jan 03 17:30:03 2019 +0100
> >> +++ b/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java    Fri
> >> Jan 18 14:25:05 2019 +0100
> >> @@ -190,8 +190,9 @@
> >>  needPrivileges = true;
> >>  }
> >>   } else {
> >> -    System.out.println("SA attach not expected to work.
> >> Insufficient privileges.");
> >> -    throw new Error("Cannot attach.");
> >> +    // Silently skip the test if we don't have enough
> >> permissions to attach
> >> +    System.out.println("SA attach not expected to work -
> >> test skipped.");
> >> +    return null;
> >
> > We should be able to use SkippedException for this case.
> >
> > David
> >
> >>   }
> >>   }
> >>
> >> This is because canPtraceAttachLinux() in Platform.java returns false.
> >>
> >> What do you think?
> >>
> >> Best regards,
> >>    Goetz.
> >>
> >>
> >>
> >>> -Original Message-
> >>> From: serviceability-dev
> >>>  On
> >>> Behalf Of Jini George
> >>> Sent: Montag, 14. Januar 2019 06:08
> >>> To: Sharath Ballal ; JC Beyler
> >>> ; serviceability-dev@openjdk.java.net
> >>> Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo
> >>> privileges to enable MacOS tests on Mach5
> >>>
> >>> Thank you very much, Sharath, for the review. My comments inline.
> >>>
> >>> On 1/12/2019 3:38 PM, Sharath Ballal wrote:
> >>>> Hi Jini,
> >>>>
> >>>> ClhsdbLauncher.java
> >>>> 1. Is the platform check not required in case of core files ?
> >>> No, it is not needed. The permission issues don't exist.
> >>>
> >>>> -    if (!Platform.shouldSAAttach()) {
> >>>> -    // Silently skip the test if we don't have enough
> >>>> permissions to attach
> >>>> -    System.out.println("SA attach not expected to work -
> >>>> test skipped.");
> >>>> -    return null;
> >>>> -    }
> >>>> -
> >>>>
> >>>> 2. Nit: extra line at 135
> >>>
> >>> Done.
> >>>
> >>> Thanks,
> >>> Jini.
> >>>>
> >>>>
> >>>> Thanks,
> >>>> Sharath
> >>>>
> >>>>
> >>>> -Original Message-
> >>>> From: Jini George
> >>>> Sent: Friday, January 11, 2019 9:46 AM
> >>>> To: JC Beyler; serviceability-dev@openjdk.java.net
> >>>> Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo
> >>> privileges to enable MacOS tests on Mach5
> >>>>
> >>>> Thanks again, JC! :-)
> >>>>
> >>>> Folks, Could I please get one more review on this ?
> >>>>
> >>>> -Jini.
> >>>>
> >>>> On 1/11/2019 9:38 AM, JC Beyler wrote:
> >>>>> Hi Jini,
> >>>>>
> >>>>> Looks good to me now :) Thanks for handling the comments :) Jc
> >>>>>
> >>>>>
> >>>>> On Tue, Jan 8

RE: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo privileges to enable MacOS tests on Mach5

[Lindenmaier, Goetz]

Hi Jini, 

we see test failing after this change arrived deeper in our infrastructure. 
On a linuxx86_64 docker container it does not work.

This is because you now throw Error() if shouldSAAttach() returns false.
I think you need this:
--- a/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java  Thu Jan 03 
17:30:03 2019 +0100
+++ b/test/hotspot/jtreg/serviceability/sa/ClhsdbLauncher.java  Fri Jan 18 
14:25:05 2019 +0100
@@ -190,8 +190,9 @@
needPrivileges = true;
}
 } else {
-System.out.println("SA attach not expected to work. 
Insufficient privileges.");
-throw new Error("Cannot attach.");
+// Silently skip the test if we don't have enough permissions 
to attach
+System.out.println("SA attach not expected to work - test 
skipped.");
+return null;
 }
 }

This is because canPtraceAttachLinux() in Platform.java returns false.

What do you think?

Best regards,
  Goetz.



> -Original Message-
> From: serviceability-dev  On
> Behalf Of Jini George
> Sent: Montag, 14. Januar 2019 06:08
> To: Sharath Ballal ; JC Beyler
> ; serviceability-dev@openjdk.java.net
> Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo
> privileges to enable MacOS tests on Mach5
> 
> Thank you very much, Sharath, for the review. My comments inline.
> 
> On 1/12/2019 3:38 PM, Sharath Ballal wrote:
> > Hi Jini,
> >
> > ClhsdbLauncher.java
> > 1. Is the platform check not required in case of core files ?
> No, it is not needed. The permission issues don't exist.
> 
> > -if (!Platform.shouldSAAttach()) {
> > -// Silently skip the test if we don't have enough permissions 
> > to attach
> > -System.out.println("SA attach not expected to work - test 
> > skipped.");
> > -return null;
> > -}
> > -
> >
> > 2. Nit: extra line at 135
> 
> Done.
> 
> Thanks,
> Jini.
> >
> >
> > Thanks,
> > Sharath
> >
> >
> > -Original Message-
> > From: Jini George
> > Sent: Friday, January 11, 2019 9:46 AM
> > To: JC Beyler; serviceability-dev@openjdk.java.net
> > Subject: Re: RFR: JDK-8215544: SA: Modify ClhsdbLauncher to add sudo
> privileges to enable MacOS tests on Mach5
> >
> > Thanks again, JC! :-)
> >
> > Folks, Could I please get one more review on this ?
> >
> > -Jini.
> >
> > On 1/11/2019 9:38 AM, JC Beyler wrote:
> >> Hi Jini,
> >>
> >> Looks good to me now :) Thanks for handling the comments :) Jc
> >>
> >>
> >> On Tue, Jan 8, 2019 at 8:11 PM Jini George  >> > wrote:
> >>
> >>  Thank you very much for the review, JC. My comments inline:
> >>
> >>  On 1/8/2019 12:22 AM, JC Beyler wrote:
> >>   >
> >>   >
> >>
> http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/hotspot/jtreg/s
> erviceability/sa/ClhsdbLauncher.java.udiff.html
> >>   >    +                // by appending 'sudo' to it. Check now if sudo
> >>   > passes in this
> >>   >    +                // environment with a simple 'echo' command.
> >>   >       -> Really shouldn't provide implementation details about
> >>  what is
> >>   > being done by that method; if we change that, this comment will
> >>  rot :-)
> >>   > canAddPrivileges is explicit enough in my mind
> >>
> >>  Done. I have removed the comment.
> >>
> >>   >
> >>   >
> >>
> >> http://cr.openjdk.java.net/~jgeorge/8215544/webrev.03/test/lib/jdk/tes
> >> t/lib/SA/SATestUtils.java.html
> >>
> >>   >
> >>   >      -> You put some System.out.println; are they intended to
> >>  still be
> >>   > there or were they for debug?
> >>
> >>  I guess you meant this one:
> >>  System.out.println("Adding 'sudo -E' to the command.");
> >>
> >>  This one is meant to be there.
> >>
> >>   >
> >>   >
> >>   >    77         for (String val: cmdStringList) {
> >>   >    78             outStringList.add(val);
> >>   >    79         }
> >>   >
> >>   >
> >>   > Couldn't we use addAll ?
> >>
> >>  Done.
> >>  The modified webrev is at:
> >>
> >>  http://cr.openjdk.java.net/~jgeorge/8215544/webrev.04/index.html
> >>
> >>  Thanks,
> >>  Jini.
> >>
> >>
> >>
> >>
> >>
> >> --
> >>
> >> Thanks,
> >> Jc

RE: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms.

[Lindenmaier, Goetz]

Thanks Serguei!

Best regards,
  Goetz.

> -Original Message-
> From: serguei.spit...@oracle.com 
> Sent: Donnerstag, 3. Januar 2019 10:13
> To: Volker Simonis ; Lindenmaier, Goetz
> 
> Cc: serviceability-dev (serviceability-dev@openjdk.java.net)  d...@openjdk.java.net>
> Subject: Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and
> AIX platforms.
> 
> Hi Goetz,
> 
> ++LGTM
> 
> Thanks,
> Serguei
> 
> 
> On 1/3/19 00:49, Volker Simonis wrote:
> 
> 
>   Looks good to me.
> 
>   Thanks,
>   Volker
> 
> 
>   On Wed, Jan 2, 2019 at 4:48 PM Lindenmaier, Goetz
> mailto:goetz.lindenma...@sap.com> >
> wrote:
> 
> 
>   Hi Gary,
> 
>   as promised, I'll do a follow up fixing all these.
>   But all the tests you mention are either not configured for aix
> (@requires linux etc)
>   or are passing currently.  So no need for action here.
> 
>   I just want to do a fix for the nsk tests.
>   So can I consider my updated webrev as reviewed by you?
>   http://cr.openjdk.java.net/~goetz/wr18/8215975-
> nskTests/02/
> 
>   Best regards,
> Goetz.
> 
> 
>   > -Original Message-
>   > From: gary.ad...@oracle.com
> <mailto:gary.ad...@oracle.com>   <mailto:gary.ad...@oracle.com> >
>   > Sent: Montag, 31. Dezember 2018 16:59
>   > To: Lindenmaier, Goetz  <mailto:goetz.lindenma...@sap.com> >; serviceability-dev
>   > (serviceability-dev@openjdk.java.net <mailto:serviceability-
> d...@openjdk.java.net> )  <mailto:serviceability-dev@openjdk.java.net> >
>   > Subject: Re: RFR(S): 8215975: [testbug] Adapt nsk tests to
> the PPC, S390 and
>   > AIX platforms.
>   >
>   > Here are few more DYLD_LIBRARY_PATH locations that
> would be worth
>   > checking
>   >
>   > ./jdk/vm/JniInvocationTest.java:50:
> env.compute("DYLD_LIBRARY_PATH", (k,
>   > v) -> (k == null) ? libdir : v + ":" + libdir);
>   > ./jdk/tools/launcher/ExecutionEnvironment.java:66:
> ?
>   > "DYLD_LIBRARY_PATH"
>   > ./jdk/tools/launcher/JliLaunchTest.java:56:String
>   > LD_LIBRARY_PATH = Platform.isOSX() ?
> "DYLD_LIBRARY_PATH" :
>   > "LD_LIBRARY_PATH";
>   > ./jdk/sun/security/krb5/auto/BasicProc.java:311:
>   > p.env("DYLD_LIBRARY_PATH", lib.substring(0, pos));
>   >
> ./jdk/sun/security/krb5/auto/ReplayCacheTestProc.java:402:
>   > .env("DYLD_LIBRARY_PATH", libDir)
>   > ./jdk/sun/security/krb5/auto/KDC.java:1725:
> "DYLD_LIBRARY_PATH",
>   > nativePath + "/lib",
>   > ./jdk/sun/security/krb5/auto/KDC.java:1818:
> "DYLD_LIBRARY_PATH",
>   > nativePath + "/lib",
>   > ./hotspot/jtreg/vmTestbase/ExecDriver.java:122: name =
> Platform.isOSX()
>   > ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH";
>   > ./hotspot/jtreg/runtime/signal/SigTestDriver.java:72:
> (Platform.isOSX()
>   > ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH");
>   >
>   > On 12/31/18 10:19 AM, Lindenmaier, Goetz wrote:
>   > > Hi Gary,
>   > >
>   > >> Would it make sense to add a method to
>   > test/lib/jdk/test/lib/Platform.java
>   > >> similar to sharedLibraryExt() to cover the envName
> setting?
>   > > Good point. I'll post a follow up change next year ... and
> believe me,
>   > > that's not too far in the future 
>   > > I'd like to keep this out of this test fix, as I want to
> downport it to
>   > > 11 at some point and thus keep it small so that it will
> apply cleanly.
>   > >
>   > >> Are the other places DYLD_LIBRARY_PATH is set also
> need to be
>   > >> updated for AIX?
>   > > Alloc001 might need it. The other vmTestbase tests are all
> passing,
>   > > so I didn't touch them.
>   > > Webrev with alloc001:
> 

RE: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms.

[Lindenmaier, Goetz]

Hi Volker, 

thanks for looking at this. 

... I just came up with another single line I'd like to add here:
http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/03/test/hotspot/jtreg/vmTestbase/nsk/jvmti/Allocate/alloc001/TestDescription.java.udiff.html
I'd like to exclude this test as Aix does not support setting ulimit -v:

New webrev:
http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/03/

... and I'll update the copyrights before pushing ...

Sorry for the inconvenience!
  Goetz

> -Original Message-
> From: Volker Simonis 
> Sent: Donnerstag, 3. Januar 2019 09:50
> To: Lindenmaier, Goetz 
> Cc: gary.ad...@oracle.com; serviceability-dev (serviceability-
> d...@openjdk.java.net) 
> Subject: Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and
> AIX platforms.
> 
> Looks good to me.
> 
> Thanks,
> Volker
> 
> 
> On Wed, Jan 2, 2019 at 4:48 PM Lindenmaier, Goetz
> mailto:goetz.lindenma...@sap.com> >
> wrote:
> 
> 
>   Hi Gary,
> 
>   as promised, I'll do a follow up fixing all these.
>   But all the tests you mention are either not configured for aix
> (@requires linux etc)
>   or are passing currently.  So no need for action here.
> 
>   I just want to do a fix for the nsk tests.
>   So can I consider my updated webrev as reviewed by you?
>   http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/02/
> 
>   Best regards,
> Goetz.
> 
> 
>   > -Original Message-
>   > From: gary.ad...@oracle.com <mailto:gary.ad...@oracle.com>
> mailto:gary.ad...@oracle.com> >
>   > Sent: Montag, 31. Dezember 2018 16:59
>   > To: Lindenmaier, Goetz  <mailto:goetz.lindenma...@sap.com> >; serviceability-dev
>   > (serviceability-dev@openjdk.java.net <mailto:serviceability-
> d...@openjdk.java.net> )  <mailto:serviceability-dev@openjdk.java.net> >
>   > Subject: Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC,
> S390 and
>   > AIX platforms.
>   >
>   > Here are few more DYLD_LIBRARY_PATH locations that would be
> worth
>   > checking
>   >
>   > ./jdk/vm/JniInvocationTest.java:50:
> env.compute("DYLD_LIBRARY_PATH", (k,
>   > v) -> (k == null) ? libdir : v + ":" + libdir);
>   > ./jdk/tools/launcher/ExecutionEnvironment.java:66:?
>   > "DYLD_LIBRARY_PATH"
>   > ./jdk/tools/launcher/JliLaunchTest.java:56:String
>   > LD_LIBRARY_PATH = Platform.isOSX() ? "DYLD_LIBRARY_PATH" :
>   > "LD_LIBRARY_PATH";
>   > ./jdk/sun/security/krb5/auto/BasicProc.java:311:
>   > p.env("DYLD_LIBRARY_PATH", lib.substring(0, pos));
>   > ./jdk/sun/security/krb5/auto/ReplayCacheTestProc.java:402:
>   > .env("DYLD_LIBRARY_PATH", libDir)
>   > ./jdk/sun/security/krb5/auto/KDC.java:1725:
> "DYLD_LIBRARY_PATH",
>   > nativePath + "/lib",
>   > ./jdk/sun/security/krb5/auto/KDC.java:1818:
> "DYLD_LIBRARY_PATH",
>   > nativePath + "/lib",
>   > ./hotspot/jtreg/vmTestbase/ExecDriver.java:122: name =
> Platform.isOSX()
>   > ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH";
>   > ./hotspot/jtreg/runtime/signal/SigTestDriver.java:72:
> (Platform.isOSX()
>   > ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH");
>   >
>   > On 12/31/18 10:19 AM, Lindenmaier, Goetz wrote:
>   > > Hi Gary,
>   > >
>   > >> Would it make sense to add a method to
>   > test/lib/jdk/test/lib/Platform.java
>   > >> similar to sharedLibraryExt() to cover the envName setting?
>   > > Good point. I'll post a follow up change next year ... and believe
> me,
>   > > that's not too far in the future 
>   > > I'd like to keep this out of this test fix, as I want to downport 
> it to
>   > > 11 at some point and thus keep it small so that it will apply
> cleanly.
>   > >
>   > >> Are the other places DYLD_LIBRARY_PATH is set also need to be
>   > >> updated for AIX?
>   > > Alloc001 might need it. The other vmTestbase tests are all
> passing,
>   > > so I didn't touch them.
>   > > Webrev with alloc001:
>   > > http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/02/
>   > >
>   > > Best regards,
>   > >Goetz.
>   > >
>   > >
>   > >
>  

RE: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms.

[Lindenmaier, Goetz]

Hi Gary, 

as promised, I'll do a follow up fixing all these.
But all the tests you mention are either not configured for aix (@requires 
linux etc)
or are passing currently.  So no need for action here.

I just want to do a fix for the nsk tests.
So can I consider my updated webrev as reviewed by you?
http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/02/

Best regards,
  Goetz.


> -Original Message-
> From: gary.ad...@oracle.com 
> Sent: Montag, 31. Dezember 2018 16:59
> To: Lindenmaier, Goetz ; serviceability-dev
> (serviceability-dev@openjdk.java.net) 
> Subject: Re: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and
> AIX platforms.
> 
> Here are few more DYLD_LIBRARY_PATH locations that would be worth
> checking
> 
> ./jdk/vm/JniInvocationTest.java:50: env.compute("DYLD_LIBRARY_PATH", (k,
> v) -> (k == null) ? libdir : v + ":" + libdir);
> ./jdk/tools/launcher/ExecutionEnvironment.java:66:    ?
> "DYLD_LIBRARY_PATH"
> ./jdk/tools/launcher/JliLaunchTest.java:56:    String
> LD_LIBRARY_PATH = Platform.isOSX() ? "DYLD_LIBRARY_PATH" :
> "LD_LIBRARY_PATH";
> ./jdk/sun/security/krb5/auto/BasicProc.java:311:
> p.env("DYLD_LIBRARY_PATH", lib.substring(0, pos));
> ./jdk/sun/security/krb5/auto/ReplayCacheTestProc.java:402:
> .env("DYLD_LIBRARY_PATH", libDir)
> ./jdk/sun/security/krb5/auto/KDC.java:1725: "DYLD_LIBRARY_PATH",
> nativePath + "/lib",
> ./jdk/sun/security/krb5/auto/KDC.java:1818: "DYLD_LIBRARY_PATH",
> nativePath + "/lib",
> ./hotspot/jtreg/vmTestbase/ExecDriver.java:122: name = Platform.isOSX()
> ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH";
> ./hotspot/jtreg/runtime/signal/SigTestDriver.java:72: (Platform.isOSX()
> ? "DYLD_LIBRARY_PATH" : "LD_LIBRARY_PATH");
> 
> On 12/31/18 10:19 AM, Lindenmaier, Goetz wrote:
> > Hi Gary,
> >
> >> Would it make sense to add a method to
> test/lib/jdk/test/lib/Platform.java
> >> similar to sharedLibraryExt() to cover the envName setting?
> > Good point. I'll post a follow up change next year ... and believe me,
> > that's not too far in the future 
> > I'd like to keep this out of this test fix, as I want to downport it to
> > 11 at some point and thus keep it small so that it will apply cleanly.
> >
> >> Are the other places DYLD_LIBRARY_PATH is set also need to be
> >> updated for AIX?
> > Alloc001 might need it. The other vmTestbase tests are all passing,
> > so I didn't touch them.
> > Webrev with alloc001:
> > http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/02/
> >
> > Best regards,
> >Goetz.
> >
> >
> >
> >>
> >> On 12/31/18 8:48 AM, Lindenmaier, Goetz wrote:
> >>> Hi,
> >>>
> >>> Some of the nsk tests are not properly configured for the
> >>> above platforms:
> >>>
> >>>nsk/jvmti/RetransformClasses/retransform003/TestDriver.java:
> >>>
> >>
> nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/TestDriver.ja
> >> va
> >>>The tests use the path to native libraries, which is named "LIBPATH" on
> >> AIX.
> >>>nsk/share/jdi/ArgumentHandler.java
> >>>Add ppc/s390/aix which don't have a shared memory connector. This
> >> disables a row of failing tests.
> >>> Please review this change. I would like to push it to jdk12, as it is a 
> >>> mere
> >> test fix.
> >>> http://cr.openjdk.java.net/~goetz/wr18/8215975-
> nskTests/01/index.html
> >>>
> >>> Best regards,
> >>> Goetz.
> 

RE: RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms.

[Lindenmaier, Goetz]

Hi Gary,

> Would it make sense to add a method to test/lib/jdk/test/lib/Platform.java
> similar to sharedLibraryExt() to cover the envName setting?
Good point. I'll post a follow up change next year ... and believe me, 
that's not too far in the future 
I'd like to keep this out of this test fix, as I want to downport it to 
11 at some point and thus keep it small so that it will apply cleanly.

> Are the other places DYLD_LIBRARY_PATH is set also need to be
> updated for AIX?
Alloc001 might need it. The other vmTestbase tests are all passing,
so I didn't touch them.
Webrev with alloc001:
http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/02/

Best regards,
  Goetz.



> 
> 
> On 12/31/18 8:48 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > Some of the nsk tests are not properly configured for the
> > above platforms:
> >
> >   nsk/jvmti/RetransformClasses/retransform003/TestDriver.java:
> >
> nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/TestDriver.ja
> va
> >   The tests use the path to native libraries, which is named "LIBPATH" on
> AIX.
> >
> >   nsk/share/jdi/ArgumentHandler.java
> >   Add ppc/s390/aix which don't have a shared memory connector. This
> disables a row of failing tests.
> >
> > Please review this change. I would like to push it to jdk12, as it is a mere
> test fix.
> > http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/01/index.html
> >
> > Best regards,
> >Goetz.
> 

RFR(S): 8215975: [testbug] Adapt nsk tests to the PPC, S390 and AIX platforms.

[Lindenmaier, Goetz]

Hi,

Some of the nsk tests are not properly configured for the
above platforms:

 nsk/jvmti/RetransformClasses/retransform003/TestDriver.java: 
 nsk/jvmti/SetNativeMethodPrefix/SetNativeMethodPrefix002/TestDriver.java 
 The tests use the path to native libraries, which is named "LIBPATH" on AIX. 

 nsk/share/jdi/ArgumentHandler.java 
 Add ppc/s390/aix which don't have a shared memory connector. This disables a 
row of failing tests.

Please review this change. I would like to push it to jdk12, as it is a mere 
test fix.
http://cr.openjdk.java.net/~goetz/wr18/8215975-nskTests/01/index.html

Best regards,
  Goetz.

RE: 8215534: [testbug] some jfr test don't check @requires vm.hasJFR

[Lindenmaier, Goetz]

Thanks Erik!

Pushed.
Best regards,
  Goetz

> -Original Message-
> From: serviceability-dev  On
> Behalf Of Erik Gahlin
> Sent: Thursday, December 13, 2018 12:34 PM
> To: security-...@openjdk.java.net; serviceability-dev (serviceability-
> d...@openjdk.java.net) 
> Subject: Re: 8215534: [testbug] some jfr test don't check @requires
> vm.hasJFR
> 
> Looks good.
> 
> Erik
> 
> > Hi,
> >
> > These tests lack @requires vm.hasJFR, thus they are failing on AIX.
> > http://cr.openjdk.java.net/~goetz/wr18/8215334-JFR_requires/01/
> >
> > Please review.
> > I will push this to jdk12 as it is a testbug if I miss  the RDP deadline.
> >
> > Best regards,
> >Goetz.
> >

RE: 8215534: [testbug] some jfr test don't check @requires vm.hasJFR

[Lindenmaier, Goetz]

Thanks Sundar!

Best regards
  Goetz

> -Original Message-
> From: Sundararajan Athijegannathan
> 
> Sent: Thursday, December 13, 2018 9:47 AM
> To: Lindenmaier, Goetz 
> Cc: security-...@openjdk.java.net; serviceability-dev (serviceability-
> d...@openjdk.java.net) 
> Subject: Re: 8215534: [testbug] some jfr test don't check @requires
> vm.hasJFR
> 
> Looks good.
> 
> PS. I just checked that there are other tests with the same requires clause.
> 
> -Sundar
> 
> On 13/12/18, 1:20 PM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > These tests lack @requires vm.hasJFR, thus they are failing on AIX.
> > http://cr.openjdk.java.net/~goetz/wr18/8215334-JFR_requires/01/
> >
> > Please review.
> > I will push this to jdk12 as it is a testbug if I miss  the RDP deadline.
> >
> > Best regards,
> >Goetz.
> >

8215534: [testbug] some jfr test don't check @requires vm.hasJFR

[Lindenmaier, Goetz]

Hi,

These tests lack @requires vm.hasJFR, thus they are failing on AIX.
http://cr.openjdk.java.net/~goetz/wr18/8215334-JFR_requires/01/

Please review.
I will push this to jdk12 as it is a testbug if I miss  the RDP deadline.

Best regards,
  Goetz.

RE: [8u] [RFR] 8140482: Various minor code improvements (runtime)

[Lindenmaier, Goetz]

Hi Dalibor, 

thanks for the info!

Best regards,
  Goetz.

> -Original Message-
> From: dalibor topic 
> Sent: Donnerstag, 22. November 2018 11:51
> To: Lindenmaier, Goetz ; Andrew Hughes
> ; serviceability-dev  d...@openjdk.java.net>; hotspot-dev 
> Subject: Re: [8u] [RFR] 8140482: Various minor code improvements (runtime)
> 
> 
> 
> On 22.11.2018 09:51, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > Doesn't this have to be posted to jdk8u-dev?
> 
> The approval requests need to go to jdk8u-dev. The reviews can happen on
> the appropriate list, which may or may not be jd8u-dev - it typically is
> the list where the initial change was discussed.
> 
> cheers,
> dalibor topic
> 
> > I had a look at the backport.
> > Including 7127191 confused me a bit. Is it good to hide the fact that
> > this was backported in the repository?
> > In os_linux one fix is missing, is this on purpose? I don't think this is a
> > critical issue, though, so leaving it out is fine.
> >
> >> the dropping of the changes to ...
> >> src/share/vm/runtime/task.cpp  and
> >> src/os/windows/vm/attachListener_windows.cpp
> > These changes are included in the webrev ...?
> >
> > The webrev looks good to me.
> >
> > Best regards,
> >Goetz.
> >
> >
> >
> >
> >
> >> -Original Message-
> >> From: hotspot-dev  On Behalf
> Of
> >> Andrew Hughes
> >> Sent: Mittwoch, 21. November 2018 07:45
> >> To: serviceability-dev ; hotspot-dev
> >> 
> >> Subject: [8u] [RFR] 8140482: Various minor code improvements (runtime)
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8140482
> >> Original changeset:
> >> https://hg.openjdk.java.net/jdk-
> updates/jdk9u/hotspot/rev/cd86b5699825
> >> Webrev:
> >> https://cr.openjdk.java.net/~andrew/openjdk8/8140482/webrev.01/
> >>
> >> The patch largely applies as is, with some adjustment for context and
> >> the dropping of the changes to src/cpu/x86/vm/stubRoutines_x86.cpp,
> >> src/share/vm/runtime/task.cpp and
> >> src/os/windows/vm/attachListener_windows.cpp
> >> which don't exist in 8u. A clean backport of 7127191 is included, which
> >> allows the changes to agent/src/os/linux/libproc_impl.c to apply as-is.
> >>
> >> Applying the change to 8u improves the code quality there and aids
> >> in backporting other changes, such as 8210836 [0].
> >>
> >> Ok for 8u?
> >>
> >> [0] https://mail.openjdk.java.net/pipermail/serviceability-dev/2018-
> >> November/025991.html
> >>
> >> Thanks,
> >> --
> >> Andrew :)
> >>
> >> Senior Free Java Software Engineer
> >> Red Hat, Inc. (http://www.redhat.com)
> >>
> >> Web Site: http://fuseyism.com
> >> Twitter: https://twitter.com/gnu_andrew_java
> >> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> >> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
> 
> --
> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
> Phone: +494089091214  | Mobile: +491737185961
> 
> 
> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
> 
> ORACLE Deutschland B.V. & Co. KG
> Hauptverwaltung: Riesstr. 25, D-80992 München
> Registergericht: Amtsgericht München, HRA 95603
> 
> Komplementärin: ORACLE Deutschland Verwaltung B.V.
> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
> 
> <http://www.oracle.com/commitment> Oracle is committed to developing
> practices and products that help protect the environment

RE: [8u] [RFR] 8140482: Various minor code improvements (runtime)

[Lindenmaier, Goetz]

Hi,

Doesn't this have to be posted to jdk8u-dev?

I had a look at the backport. 
Including 7127191 confused me a bit. Is it good to hide the fact that
this was backported in the repository?
In os_linux one fix is missing, is this on purpose? I don't think this is a 
critical issue, though, so leaving it out is fine.

> the dropping of the changes to ... 
> src/share/vm/runtime/task.cpp  and
> src/os/windows/vm/attachListener_windows.cpp
These changes are included in the webrev ...?

The webrev looks good to me.

Best regards,
  Goetz.





> -Original Message-
> From: hotspot-dev  On Behalf Of
> Andrew Hughes
> Sent: Mittwoch, 21. November 2018 07:45
> To: serviceability-dev ; hotspot-dev
> 
> Subject: [8u] [RFR] 8140482: Various minor code improvements (runtime)
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8140482
> Original changeset:
> https://hg.openjdk.java.net/jdk-updates/jdk9u/hotspot/rev/cd86b5699825
> Webrev:
> https://cr.openjdk.java.net/~andrew/openjdk8/8140482/webrev.01/
> 
> The patch largely applies as is, with some adjustment for context and
> the dropping of the changes to src/cpu/x86/vm/stubRoutines_x86.cpp,
> src/share/vm/runtime/task.cpp and
> src/os/windows/vm/attachListener_windows.cpp
> which don't exist in 8u. A clean backport of 7127191 is included, which
> allows the changes to agent/src/os/linux/libproc_impl.c to apply as-is.
> 
> Applying the change to 8u improves the code quality there and aids
> in backporting other changes, such as 8210836 [0].
> 
> Ok for 8u?
> 
> [0] https://mail.openjdk.java.net/pipermail/serviceability-dev/2018-
> November/025991.html
> 
> Thanks,
> --
> Andrew :)
> 
> Senior Free Java Software Engineer
> Red Hat, Inc. (http://www.redhat.com)
> 
> Web Site: http://fuseyism.com
> Twitter: https://twitter.com/gnu_andrew_java
> PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
> Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

RE: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file

[Lindenmaier, Goetz]

Hi Sharath, 

I don't think you need a bug for this.  You need to flag
the other bug with "fix-request"
http://openjdk.java.net/projects/jdk-updates/approval.html
But unfortunately we need a new review because the 
patch does not apply cleanly.

Will you send the RFR?  I could do the review.

Best regards,
  Goetz.



> -Original Message-
> From: Sharath Ballal 
> Sent: Mittwoch, 3. Oktober 2018 08:03
> To: Lindenmaier, Goetz ; serviceability-dev
> 
> Subject: RE: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times
> out parsing a 4GB hprof file
> 
> Hi Goetz,
> 
> I have opened https://bugs.openjdk.java.net/browse/JDK-8211421 for the
> backport.
> 
> 
> Thanks,
> Sharath
> 
> 
> -Original Message-
> From: Lindenmaier, Goetz [mailto:goetz.lindenma...@sap.com]
> Sent: Friday, September 28, 2018 8:41 PM
> To: Sharath Ballal; serviceability-dev
> Subject: RE: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times
> out parsing a 4GB hprof file
> 
> Hi Sharath,
> 
> what do you think about bringing this fix to jdk11u?
> We run the tests there regularly and see this problem, too.
> 
> Best regards,
>   Goetz.
> 
> > -Original Message-
> > From: serviceability-dev 
> > On Behalf Of Sharath Ballal
> > Sent: Montag, 24. September 2018 05:49
> > To: serviceability-dev 
> > Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java
> > times out parsing a 4GB hprof file
> >
> > Hi,
> >
> >
> >
> > Pls review this test fix to add "-Xmx512m" to SA tests which create
> > either core file or heap dump, to avoid timeout due to large heap sizes.
> >
> >
> >
> > Bug id: https://bugs.openjdk.java.net/browse/JDK-8207745
> >
> > Webrev: http://cr.openjdk.java.net/~sballal/8207745/webrev.00/
> > <http://cr.openjdk.java.net/~sballal/8207745/webrev.00/>
> >
> >
> >
> > SA tests passed on Mach5 run.
> >
> >
> >
> > Thanks,
> >
> > Sharath
> >
> >
> >
> >

RE: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times out parsing a 4GB hprof file

[Lindenmaier, Goetz]

Hi Sharath, 

what do you think about bringing this fix to jdk11u?
We run the tests there regularly and see this problem, too.

Best regards,
  Goetz.

> -Original Message-
> From: serviceability-dev  On
> Behalf Of Sharath Ballal
> Sent: Montag, 24. September 2018 05:49
> To: serviceability-dev 
> Subject: RFR (XS) JDK-8207745: serviceability/sa/TestJmapCore.java times
> out parsing a 4GB hprof file
> 
> Hi,
> 
> 
> 
> Pls review this test fix to add "-Xmx512m" to SA tests which create either
> core file or heap dump, to avoid timeout due to large heap sizes.
> 
> 
> 
> Bug id: https://bugs.openjdk.java.net/browse/JDK-8207745
> 
> Webrev: http://cr.openjdk.java.net/~sballal/8207745/webrev.00/
> 
> 
> 
> 
> SA tests passed on Mach5 run.
> 
> 
> 
> Thanks,
> 
> Sharath
> 
> 
> 
> 

RE: JDK-8199700: SA: Enable jhsdb jtreg tests for Mac OS X

[Lindenmaier, Goetz]

Hi Jini, 

A whole bunch of tests failed on mac.  I'll send you
A jtr file off list, to avoid spamming the list.
See below the core message.

The tests passed on linuxppc64le, linuxx86_64 and solaris_sparc, the other
tests are still pending.

Best regards,
  Goetz.

--System.err:(32/1923)--
Command line: 
['/priv/jvmtests/output_sapjvm12_o_jdk-test_dbgU_darwinintel64/sapjvm_12/bin/java'
 '-Xcomp' '-cp' 
'/priv/jvmtests/output_sapjvm12_o_jdk-test_dbgU_darwinintel64/jtreg_hotspot_work/JTwork/classes/serviceability/sa/ClhsdbFindPC.d:/priv/jvmtests/output_sapjvm12_o_jdk-test_dbgU_darwinintel64/jtreg_hotspot_work/JTwork/classes/test/lib'
 'jdk.test.lib.apps.LingeredApp' '78a4a198-8a55-4684-ac1e-2d28311a0952.lck' ]
sudo: no tty present and no askpass program specified
 stdout: [];
 stderr: []
 exitValue = 1

 LingeredApp stdout: [];
 LingeredApp stderr: []
 LingeredApp exitValue = 0
java.lang.RuntimeException: Test ERROR java.lang.RuntimeException: Expected to 
get exit value of [0]

at ClhsdbFindPC.testFindPC(ClhsdbFindPC.java:95)
at ClhsdbFindPC.main(ClhsdbFindPC.java:103)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.RuntimeException: Expected to get exit value of [0]

at 
jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:396)
at ClhsdbLauncher.runCmd(ClhsdbLauncher.java:128)
at ClhsdbLauncher.run(ClhsdbLauncher.java:176)
at ClhsdbFindPC.testFindPC(ClhsdbFindPC.java:58)
... 7 more

JavaTest Message: Test threw exception: java.lang.RuntimeException: Test ERROR 
java.lang.RuntimeException: Expected to get exit value of [0]

JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: Test ERROR 
java.lang.RuntimeException: Expected to get exit value of [0]

> -Original Message-
> From: Jini George 
> Sent: Thursday, July 12, 2018 6:43 PM
> To: Lindenmaier, Goetz ; serviceability-
> d...@openjdk.java.net
> Subject: Re: JDK-8199700: SA: Enable jhsdb jtreg tests for Mac OS X
> 
> 
> >
> > I'll run the patch throuqh our nightly tests to
> > see whether they pass mac.
> 
> Thanks for this. Let me know in case there are timeouts due to there not
> being a no-password entry for the user in the /etc/sudoers list.
> 
> Thanks,
> Jini.

RE: JDK-8199700: SA: Enable jhsdb jtreg tests for Mac OS X

[Lindenmaier, Goetz]

Hi Jini,

I had a look at your change. 
It makes tests fail if shouldSAAttach returns false.

Now, these tests say "Errror: cannot attach",
while before they would terminate silently.

It is not an Error if the SA can not attach. 

You can reproduce this by just changing
Platform.shouldSAAttach() to always return false.

I'll run the patch throuqh our nightly tests to 
see whether they pass mac.

Best regards,
  Goetz.

> -Original Message-
> From: serviceability-dev [mailto:serviceability-dev-
> boun...@openjdk.java.net] On Behalf Of Jini George
> Sent: Montag, 9. Juli 2018 20:45
> To: serviceability-dev@openjdk.java.net
> Subject: RFR: JDK-8199700: SA: Enable jhsdb jtreg tests for Mac OS X
> 
> Requesting reviews for enabling SA tests on OS X for Mach5.
> 
> https://bugs.openjdk.java.net/browse/JDK-8199700
> 
> Webrev: http://cr.openjdk.java.net/~jgeorge/8199700/webrev.00/
> 
> The changes are mostly to include the addition of sudo privileges to the
> SA launchers for OSX if Platform.shouldSAAttach() fails. Some tests
> (those using clhsdb) have been refactored to use ClhsdbLauncher for ease
> of maintainence. This also avoids checks for Platform.shouldSAAttach()
> for corefile related test cases. More details have been provided in JIRA.
> 
> Thanks,
> Jini.

RE: RFR(S/M): 8205419: [testbug] TestJmapCore failing without SA: introduce @requires vm.hasSA

[Lindenmaier, Goetz]

Hi,

Thanks for reviewing!

Yes, what Jini is saying is also what I found in the comments.

Best regards,
  Goetz.

> -Original Message-
> From: Chris Plummer 
> Sent: Monday, June 25, 2018 7:02 PM
> To: Lindenmaier, Goetz ; 'Jini George'
> ; serviceability-dev (serviceability-
> d...@openjdk.java.net) 
> Subject: Re: RFR(S/M): 8205419: [testbug] TestJmapCore failing without SA:
> introduce @requires vm.hasSA
> 
> Hi Goetz,
> 
> The changes look good. Just one question though. In places where you have:
> 
>    42  * @requires vm.hasSAandCanAttach & os.family != "mac"
> 
> Do you know why these tests don't run on osx? I just wonder if it
> related to attach not working unless root, and that is now covered by
> hasSAandCanAttach(). If that is the case, the "mac" check can be removed.
> 
> thanks,
> 
> Chris
> 
> On 6/22/18 1:20 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > Ok, so I now added
> >vm.hasSA and
> >vm.hasSAandCanAttach
> > I use the first in the JMapCore tests, and in the tests that don't check
> shouldSAAttach()
> > right at the beginning.
> > Wherever the test is immediately ended after checking shouldSAAttach(), I
> > removed shouldSAAttach(), and added vm.hasSAandCanAttach.  The
> others
> > depend on  ClhsdbLauncher. Just checking vm.hasSA is on the safe side
> > if runOnCore() is changed.
> > http://cr.openjdk.java.net/~goetz/wr18/8205419-requiresHasSA/02/
> >
> > This also makes the implementation of VMProps and VMPlatform more
> clear
> > as requested by Chris.
> >
> > Best regards,
> >   Goetz.
> >
> >
> >> -Original Message-
> >> From: Jini George 
> >> Sent: Thursday, June 21, 2018 12:18 PM
> >> To: Lindenmaier, Goetz ; 'Chris Plummer'
> >> ; serviceability-dev (serviceability-
> >> d...@openjdk.java.net) 
> >> Subject: Re: RFR(S/M): 8205419: [testbug] TestJmapCore failing without
> SA:
> >> introduce @requires vm.hasSA
> >>
> >> Hi Goetz,
> >>
> >> Tests like TestJmapCore which involve only corefile debugging by SA (and
> >> not attaching to a live process) would only need to check for the
> >> presence of SA, and would not need to check for ptrace related attach
> >> permissions like what is done for Linux and OSX -- since super user
> >> privileges are not required to debug corefiles. So a single @requires
> >> catering to both these might not be desirable.
> >>
> >> Having said that, I realized that runOnCore() of ClhsdbLauncher
> >> incorrectly checks for the ptrace related attach permissions. (Will file
> >> an issue to correct this).
> >>
> >> An @requires instead of a shouldSAAttach() might help in avoiding fake
> >> passes like those on OSX when not run as "root".
> >> (https://bugs.openjdk.java.net/browse/JDK-8199700)
> >>
> >> Thanks,
> >> Jini.
> >>
> >>
> >>
> >>
> >> On 6/21/2018 1:52 AM, Lindenmaier, Goetz wrote:
> >>> Hi Chris,
> >>>
> >>> Thanks for looking at this change.
> >>>
> >>>> Can't VMProps.vmHasSA() just return Platform.shouldSAAttach()? It
> >> seems
> >>>> you are unnecessarily replicating Platform.shouldSAAttach() logic.
> >>> I think there are two things to distinguish:
> >>>- platforms that don't implement SA
> >>>- systems/setups where SA does not work.
> >>> If both can be recognized when VMProps is evaluated, shouldSAAttach()
> >>> is the one that is superfluous in the long run?!  If not, shouldSAAttach
> >>> should only return those where it is necessary to check in the test.
> >>> But this is probably too much brains in this case 
> >>>
> >>>> If you are adding "@requires vm.hasSAandCanAttach" to a test,
> shouldn't
> >>>> you remove the test's Platform.shouldSAAttach() check?
> >>> Well I asked in my mail whether I should do that. So I take this as a yes.
> >>> But it depends on whether it must be evaluated in the test.
> >>>
> >>>> Is there a reason not to take the more direct and established approach
> >>>> of just adding the Platform.shouldSAAttach() check to TestJmapCore?
> It
> >>>> would be a lot less disruptive.  I know the vm.hasSAandCanAttach
> >>>> approach has advantages in not even attempting to compile and run
> the
> >>>> test, but I

RE: RFR(S/M): 8205419: [testbug] TestJmapCore failing without SA: introduce @requires vm.hasSA

[Lindenmaier, Goetz]

Hi Jini

Thanks for reviewing again, I fixed the typo's!

Best regards,
  Goetz.

> -Original Message-
> From: Jini George 
> Sent: Monday, June 25, 2018 6:20 PM
> To: Lindenmaier, Goetz ; 'Chris Plummer'
> ; serviceability-dev (serviceability-
> d...@openjdk.java.net) 
> Subject: Re: RFR(S/M): 8205419: [testbug] TestJmapCore failing without SA:
> introduce @requires vm.hasSA
> 
> Hi Goetz,
> 
> Your changes look good, though I feel that even for the tests that use
> ClhsdbLauncher and which need an attach, an "@requires
> vm.hasSAandCanAttach" could be used, and the Platform.shouldSAAttach()
> calls can be removed from ClhsdbLauncher.
> 
> Some nits:
> 
> 1. In VMProps.java,
> 
> servicability ==> serviceability (an extra 'e')
> 
> 2. In Platform.java
> 
> reqires ==> requires
> 
> Thanks,
> Jini (Not a (R)eviewer).
> 
> On 6/22/2018 1:50 PM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > Ok, so I now added
> >vm.hasSA and
> >vm.hasSAandCanAttach
> > I use the first in the JMapCore tests, and in the tests that don't check
> shouldSAAttach()
> > right at the beginning.
> > Wherever the test is immediately ended after checking shouldSAAttach(), I
> > removed shouldSAAttach(), and added vm.hasSAandCanAttach.  The
> others
> > depend on  ClhsdbLauncher. Just checking vm.hasSA is on the safe side
> > if runOnCore() is changed.
> > http://cr.openjdk.java.net/~goetz/wr18/8205419-requiresHasSA/02/
> >
> > This also makes the implementation of VMProps and VMPlatform more
> clear
> > as requested by Chris.
> >
> > Best regards,
> >   Goetz.
> >
> >
> >> -Original Message-
> >> From: Jini George 
> >> Sent: Thursday, June 21, 2018 12:18 PM
> >> To: Lindenmaier, Goetz ; 'Chris Plummer'
> >> ; serviceability-dev (serviceability-
> >> d...@openjdk.java.net) 
> >> Subject: Re: RFR(S/M): 8205419: [testbug] TestJmapCore failing without
> SA:
> >> introduce @requires vm.hasSA
> >>
> >> Hi Goetz,
> >>
> >> Tests like TestJmapCore which involve only corefile debugging by SA (and
> >> not attaching to a live process) would only need to check for the
> >> presence of SA, and would not need to check for ptrace related attach
> >> permissions like what is done for Linux and OSX -- since super user
> >> privileges are not required to debug corefiles. So a single @requires
> >> catering to both these might not be desirable.
> >>
> >> Having said that, I realized that runOnCore() of ClhsdbLauncher
> >> incorrectly checks for the ptrace related attach permissions. (Will file
> >> an issue to correct this).
> >>
> >> An @requires instead of a shouldSAAttach() might help in avoiding fake
> >> passes like those on OSX when not run as "root".
> >> (https://bugs.openjdk.java.net/browse/JDK-8199700)
> >>
> >> Thanks,
> >> Jini.
> >>
> >>
> >>
> >>
> >> On 6/21/2018 1:52 AM, Lindenmaier, Goetz wrote:
> >>> Hi Chris,
> >>>
> >>> Thanks for looking at this change.
> >>>
> >>>> Can't VMProps.vmHasSA() just return Platform.shouldSAAttach()? It
> >> seems
> >>>> you are unnecessarily replicating Platform.shouldSAAttach() logic.
> >>> I think there are two things to distinguish:
> >>>- platforms that don't implement SA
> >>>- systems/setups where SA does not work.
> >>> If both can be recognized when VMProps is evaluated, shouldSAAttach()
> >>> is the one that is superfluous in the long run?!  If not, shouldSAAttach
> >>> should only return those where it is necessary to check in the test.
> >>> But this is probably too much brains in this case 
> >>>
> >>>> If you are adding "@requires vm.hasSAandCanAttach" to a test,
> shouldn't
> >>>> you remove the test's Platform.shouldSAAttach() check?
> >>> Well I asked in my mail whether I should do that. So I take this as a yes.
> >>> But it depends on whether it must be evaluated in the test.
> >>>
> >>>> Is there a reason not to take the more direct and established approach
> >>>> of just adding the Platform.shouldSAAttach() check to TestJmapCore?
> It
> >>>> would be a lot less disruptive.  I know the vm.hasSAandCanAttach
> >>>> approach has advantages in not even attempting to compile and run
> the
> >>&

RE: RFR(S/M): 8205419: [testbug] TestJmapCore failing without SA: introduce @requires vm.hasSA

[Lindenmaier, Goetz]

Hi,

Ok, so I now added 
  vm.hasSA and
  vm.hasSAandCanAttach
I use the first in the JMapCore tests, and in the tests that don't check 
shouldSAAttach()
right at the beginning.
Wherever the test is immediately ended after checking shouldSAAttach(), I 
removed shouldSAAttach(), and added vm.hasSAandCanAttach.  The others
depend on  ClhsdbLauncher. Just checking vm.hasSA is on the safe side
if runOnCore() is changed.
http://cr.openjdk.java.net/~goetz/wr18/8205419-requiresHasSA/02/

This also makes the implementation of VMProps and VMPlatform more clear
as requested by Chris.

Best regards,
 Goetz.


> -Original Message-
> From: Jini George 
> Sent: Thursday, June 21, 2018 12:18 PM
> To: Lindenmaier, Goetz ; 'Chris Plummer'
> ; serviceability-dev (serviceability-
> d...@openjdk.java.net) 
> Subject: Re: RFR(S/M): 8205419: [testbug] TestJmapCore failing without SA:
> introduce @requires vm.hasSA
> 
> Hi Goetz,
> 
> Tests like TestJmapCore which involve only corefile debugging by SA (and
> not attaching to a live process) would only need to check for the
> presence of SA, and would not need to check for ptrace related attach
> permissions like what is done for Linux and OSX -- since super user
> privileges are not required to debug corefiles. So a single @requires
> catering to both these might not be desirable.
> 
> Having said that, I realized that runOnCore() of ClhsdbLauncher
> incorrectly checks for the ptrace related attach permissions. (Will file
> an issue to correct this).
> 
> An @requires instead of a shouldSAAttach() might help in avoiding fake
> passes like those on OSX when not run as "root".
> (https://bugs.openjdk.java.net/browse/JDK-8199700)
> 
> Thanks,
> Jini.
> 
> 
> 
> 
> On 6/21/2018 1:52 AM, Lindenmaier, Goetz wrote:
> > Hi Chris,
> >
> > Thanks for looking at this change.
> >
> >> Can't VMProps.vmHasSA() just return Platform.shouldSAAttach()? It
> seems
> >> you are unnecessarily replicating Platform.shouldSAAttach() logic.
> > I think there are two things to distinguish:
> >   - platforms that don't implement SA
> >   - systems/setups where SA does not work.
> > If both can be recognized when VMProps is evaluated, shouldSAAttach()
> > is the one that is superfluous in the long run?!  If not, shouldSAAttach
> > should only return those where it is necessary to check in the test.
> > But this is probably too much brains in this case 
> >
> >> If you are adding "@requires vm.hasSAandCanAttach" to a test, shouldn't
> >> you remove the test's Platform.shouldSAAttach() check?
> > Well I asked in my mail whether I should do that. So I take this as a yes.
> > But it depends on whether it must be evaluated in the test.
> >
> >> Is there a reason not to take the more direct and established approach
> >> of just adding the Platform.shouldSAAttach() check to TestJmapCore? It
> >> would be a lot less disruptive.  I know the vm.hasSAandCanAttach
> >> approach has advantages in not even attempting to compile and run the
> >> test, but I'm not so sure those advantages outweigh the simplicity of
> >> just adding a Platform.shouldSAAttach() check to one test. I can go
> >> either way here. Just wondering if there are additional reasons I might
> >> not be seeing.
> > I like the @requires much more. It tells right where the test is described
> > that it does not run with SA. The other is quite hidden in the test, e.g., 
> > in
> > helper class ClhsdbLauncher.java.
> > Also, it's more easy to remember (The implementor of
> > TestJmapCore forgot it...).  And, last but not least, it seems best practice
> > nowadays. There are lots of excludes for mac, they are also done by
> @requires
> > and not as a check using Platform at runtime.
> >
> >> Sorry, I don't have an answer to your VMProps evaluation question. You
> >> might need to ask a wider audience than just svc.
> > Whom should I ask? Hotspot-dev?
> >
> > Best regards,
> >Goetz.
> >
> >
> >>
> >> thanks,
> >>
> >> Chris
> >>
> >> On 6/20/18 6:49 AM, Lindenmaier, Goetz wrote:
> >>> Hi,
> >>>
> >>> TestJmapCore is failing on aix because there jhsdb is not implemented.
> >>> So far, such tests check at runtime Platform.shouldSAAttach() which is
> >> missing
> >>> in TestJmapCore.
> >>>
> >>> Instead, I implement @requires vm.hasSAandCanAttach.
> >>> This makes jtreg skip the tests without compiling and starting them.
> >>>
> >>> I ad

RE: RFR(S/M): 8205419: [testbug] TestJmapCore failing without SA: introduce @requires vm.hasSA

[Lindenmaier, Goetz]

Hi David, 

> Obviously using "@run othervm " you can invalidate what may have
> been checked in a @require.
As I understand with othervm you can not switch the user, or even start the 
other vm on a different system.  
So in this case, where no flags are checked, it should be fine.  Even if you
Sudo the jtreg runner as proposed in JDK-8199700.

Thanks and best regards,
  Goetz


> -Original Message-
> From: David Holmes 
> Sent: Thursday, June 21, 2018 1:14 PM
> To: Lindenmaier, Goetz ; serviceability-dev
> (serviceability-dev@openjdk.java.net)  d...@openjdk.java.net>
> Subject: Re: RFR(S/M): 8205419: [testbug] TestJmapCore failing without SA:
> introduce @requires vm.hasSA
> 
> Answering VMProps question ...
> 
> On 20/06/2018 11:49 PM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > TestJmapCore is failing on aix because there jhsdb is not implemented.
> > So far, such tests check at runtime Platform.shouldSAAttach() which is
> missing
> > in TestJmapCore.
> >
> > Instead, I implement @requires vm.hasSAandCanAttach.
> > This makes jtreg skip the tests without compiling and starting them.
> >
> > I added the new property to all tests that check shouldSAAttach in jdk and
> hostpot test
> > directories.
> > This is the implementation of the new property, the rest is just repetitive
> checking it:
> > http://cr.openjdk.java.net/~goetz/wr18/8205419-
> requiresHasSA/01/test/jtreg-ext/requires/VMProps.java.udiff.html
> > webrev:
> > http://cr.openjdk.java.net/~goetz/wr18/8205419-requiresHasSA/01/
> >
> > Is it correct to assume the VMProps is evaluated on the same machine and
> with the same
> > user as used for executing the test?  canPtraceAttachLinux directly
> accesses the system.
> 
> jtreg will run the VM under test with all the VM flags specified to
> jtreg and execute VMProps to gather information about the VM under test
> before running the tests themselves.
> 
> Obviously using "@run othervm " you can invalidate what may have
> been checked in a @require.
> 
> HTH
> 
> David
> 
> 
> > (Should I remove the checks for shouldSAAttach() from the changed tests?)
> >
> > Best regards,
> >Goetz.
> >

RE: RFR(S/M): 8205419: [testbug] TestJmapCore failing without SA: introduce @requires vm.hasSA

[Lindenmaier, Goetz]

Hi Chris,

Thanks for looking at this change.

> Can't VMProps.vmHasSA() just return Platform.shouldSAAttach()? It seems
> you are unnecessarily replicating Platform.shouldSAAttach() logic.
I think there are two things to distinguish:
 - platforms that don't implement SA
 - systems/setups where SA does not work.
If both can be recognized when VMProps is evaluated, shouldSAAttach()
is the one that is superfluous in the long run?!  If not, shouldSAAttach 
should only return those where it is necessary to check in the test. 
But this is probably too much brains in this case 

> If you are adding "@requires vm.hasSAandCanAttach" to a test, shouldn't
> you remove the test's Platform.shouldSAAttach() check?
Well I asked in my mail whether I should do that. So I take this as a yes.
But it depends on whether it must be evaluated in the test.

> Is there a reason not to take the more direct and established approach
> of just adding the Platform.shouldSAAttach() check to TestJmapCore? It
> would be a lot less disruptive.  I know the vm.hasSAandCanAttach
> approach has advantages in not even attempting to compile and run the
> test, but I'm not so sure those advantages outweigh the simplicity of
> just adding a Platform.shouldSAAttach() check to one test. I can go
> either way here. Just wondering if there are additional reasons I might
> not be seeing.
I like the @requires much more. It tells right where the test is described
that it does not run with SA. The other is quite hidden in the test, e.g., in 
helper class ClhsdbLauncher.java.
Also, it's more easy to remember (The implementor of 
TestJmapCore forgot it...).  And, last but not least, it seems best practice
nowadays. There are lots of excludes for mac, they are also done by @requires
and not as a check using Platform at runtime.

> Sorry, I don't have an answer to your VMProps evaluation question. You
> might need to ask a wider audience than just svc.
Whom should I ask? Hotspot-dev?

Best regards,
  Goetz.


> 
> thanks,
> 
> Chris
> 
> On 6/20/18 6:49 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > TestJmapCore is failing on aix because there jhsdb is not implemented.
> > So far, such tests check at runtime Platform.shouldSAAttach() which is
> missing
> > in TestJmapCore.
> >
> > Instead, I implement @requires vm.hasSAandCanAttach.
> > This makes jtreg skip the tests without compiling and starting them.
> >
> > I added the new property to all tests that check shouldSAAttach in jdk and
> hostpot test
> > directories.
> > This is the implementation of the new property, the rest is just repetitive
> checking it:
> > http://cr.openjdk.java.net/~goetz/wr18/8205419-
> requiresHasSA/01/test/jtreg-ext/requires/VMProps.java.udiff.html
> > webrev:
> > http://cr.openjdk.java.net/~goetz/wr18/8205419-requiresHasSA/01/
> >
> > Is it correct to assume the VMProps is evaluated on the same machine and
> with the same
> > user as used for executing the test?  canPtraceAttachLinux directly
> accesses the system.
> >
> > (Should I remove the checks for shouldSAAttach() from the changed tests?)
> >
> > Best regards,
> >Goetz.
> 
> 

RFR(S/M): 8205419: [testbug] TestJmapCore failing without SA: introduce @requires vm.hasSA

[Lindenmaier, Goetz]

Hi,

TestJmapCore is failing on aix because there jhsdb is not implemented.
So far, such tests check at runtime Platform.shouldSAAttach() which is missing
in TestJmapCore.

Instead, I implement @requires vm.hasSAandCanAttach.
This makes jtreg skip the tests without compiling and starting them.

I added the new property to all tests that check shouldSAAttach in jdk and 
hostpot test
directories. 
This is the implementation of the new property, the rest is just repetitive 
checking it:
http://cr.openjdk.java.net/~goetz/wr18/8205419-requiresHasSA/01/test/jtreg-ext/requires/VMProps.java.udiff.html
webrev:
http://cr.openjdk.java.net/~goetz/wr18/8205419-requiresHasSA/01/ 

Is it correct to assume the VMProps is evaluated on the same machine and with 
the same
user as used for executing the test?  canPtraceAttachLinux directly accesses 
the system.

(Should I remove the checks for shouldSAAttach() from the changed tests?)

Best regards,
  Goetz.

RE: RFR(XS): 8205108: [testbug] Fix pattern matching in jstatd tests.

[Lindenmaier, Goetz]

Hi Arno, 

thanks for the 'r'eview!

Best regards,
  Goetz.

> -Original Message-
> From: Zeller, Arno
> Sent: Mittwoch, 20. Juni 2018 10:12
> To: Lindenmaier, Goetz 
> Cc: serviceability-dev (serviceability-dev@openjdk.java.net)  d...@openjdk.java.net>; Thomas Stüfe 
> Subject: RE: RFR(XS): 8205108: [testbug] Fix pattern matching in jstatd tests.
> 
> Hi Goetz,
> 
> the change looks good to me and I think the newer example output should
> be enough.
> Nevertheless, I have to point out that I am no reviewer.
> 
> Best regards,
> Arno
> 
> >-Original Message-
> >From: serviceability-dev [mailto:serviceability-dev-
> >boun...@openjdk.java.net] On Behalf Of Lindenmaier, Goetz
> >Sent: Dienstag, 19. Juni 2018 12:46
> >To: Thomas Stüfe 
> >Cc: serviceability-dev (serviceability-dev@openjdk.java.net)  >d...@openjdk.java.net>
> >Subject: [CAUTION] RE: RFR(XS): 8205108: [testbug] Fix pattern matching in
> >jstatd tests.
> >
> >Hi Thomas,
> >
> >thanks for your review!
> >
> >I think the upper example output stems from some older
> >jstatd. Probably the output got two new values added.
> >I don't feel like making up values, so I'd rather remove the
> >old output. Is that fine with you?
> >
> >Best regards,
> >  Goetz.
> >
> >> -Original Message-
> >> From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
> >> Sent: Samstag, 16. Juni 2018 19:26
> >> To: Lindenmaier, Goetz 
> >> Cc: serviceability-dev (serviceability-dev@openjdk.java.net)
>  >> d...@openjdk.java.net>
> >> Subject: Re: RFR(XS): 8205108: [testbug] Fix pattern matching in jstatd
> tests.
> >>
> >> Hi Goetz,
> >>
> >> Looks reasonable. Could you please fix up the example output above the
> >> alternative you added, it misses the columns "CGC" and "CGCT".
> >>
> >> Thanks, Thomas
> >>
> >> On Sat, Jun 16, 2018 at 9:24 AM, Lindenmaier, Goetz
> >>  wrote:
> >> > Hi,
> >> >
> >> > Please review this test fix:
> >> > http://cr.openjdk.java.net/~goetz/wr18/8205108-
> >fixJstatDTestPattern/01/
> >> >
> >> > The values for 'M' must be parsed as PERCENTAGE_OR_DASH.
> >> > The parsing of numbers should not depend on the locale.
> >> > I changed the parsing to use java.text.NumberFormat
> >> >
> >> > Best regards,
> >> >   Goetz.
> >> >

RE: RFR(XS): 8205108: [testbug] Fix pattern matching in jstatd tests.

[Lindenmaier, Goetz]

Hi Thomas, 

thanks for your review!

I think the upper example output stems from some older 
jstatd. Probably the output got two new values added.
I don't feel like making up values, so I'd rather remove the 
old output. Is that fine with you?

Best regards,
  Goetz.

> -Original Message-
> From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
> Sent: Samstag, 16. Juni 2018 19:26
> To: Lindenmaier, Goetz 
> Cc: serviceability-dev (serviceability-dev@openjdk.java.net)  d...@openjdk.java.net>
> Subject: Re: RFR(XS): 8205108: [testbug] Fix pattern matching in jstatd tests.
> 
> Hi Goetz,
> 
> Looks reasonable. Could you please fix up the example output above the
> alternative you added, it misses the columns "CGC" and "CGCT".
> 
> Thanks, Thomas
> 
> On Sat, Jun 16, 2018 at 9:24 AM, Lindenmaier, Goetz
>  wrote:
> > Hi,
> >
> > Please review this test fix:
> > http://cr.openjdk.java.net/~goetz/wr18/8205108-fixJstatDTestPattern/01/
> >
> > The values for 'M' must be parsed as PERCENTAGE_OR_DASH.
> > The parsing of numbers should not depend on the locale.
> > I changed the parsing to use java.text.NumberFormat
> >
> > Best regards,
> >   Goetz.
> >

RFR(XS): 8205108: [testbug] Fix pattern matching in jstatd tests.

[Lindenmaier, Goetz]

Hi,

Please review this test fix:
http://cr.openjdk.java.net/~goetz/wr18/8205108-fixJstatDTestPattern/01/

The values for 'M' must be parsed as PERCENTAGE_OR_DASH. 
The parsing of numbers should not depend on the locale.
I changed the parsing to use java.text.NumberFormat

Best regards,
  Goetz.

RE: RFR(S): 8204654: [testbug] Fix pattern matching in jstat tests.

[Lindenmaier, Goetz]

Hi Thomas, 

thanks for your review!
New webrev: 
http://cr.openjdk.java.net/~goetz/wr18/8204654-fixJstatTest/02/
I'll run this through our testing again and push tomorrow if all 
is green.

> consider better comment:
> -# The awk scripts parsing the output do not respect any locale
> dependent setting.
> +# The awk scripts parsing the jstat output expect it to be in en-us locale.
Fixed.

> I assume
> ([0-9])|-+
> should match a single whole number for column "FindClass", or "-"?
Yes, fixed.
 
> similar here: + misplaced:
> - ([0-9]+\.[0-9])|-+
> + ([0-9]+\.[0-9]+)|-
Also fixed. Great catch!
 
> Also, it would be helpful if you could print column name or at least
> number atop the matching sequences, in a comment, that makes the
> reading easer.
Yes, but there are a row of similar files I don't touch. Don't want to do
this for all of them.

> But this is hard to read! Any chance of splitting this expression into
> sub expressions?
Yes, this is ugly. 
But I think the whole tests should be rewritten to do the parsing in Java, 
as the jstatd tests do. I think this is out of scope here. 

Best regards,
 Goetz.



> 
> 
> Rest seems fine.
> 
> ..Thomas
> 
> On Mon, Jun 11, 2018 at 3:14 PM, Lindenmaier, Goetz
>  wrote:
> > Hi,
> >
> > please review this test fix:
> > http://cr.openjdk.java.net/~goetz/wr18/8204654-fixJstatTest/01
> >
> > gcCauseOutput1.awk:
> > The pattern scans 11 numbers, while the output contains 13. Also, more '-'
> are possible then checked.
> >
> > The other awk scripts need to check more patterns where '-' can appear.
> >
> > We have a machine with user.country=de where jstat prints ',' instead of '.'
> in numbers. Explicitly
> > start with user.country=en as already done for user.language=en.
> >
> > I also refactored the common flags to a variable in utils.sh ... so there 
> > won't
> be the need
> > to edit all these files once more :)
> >
> > Best regards,
> >   Goetz
> >
> > (Sorry for the second mail, first missed the bug text ...)

RFR(S):

[Lindenmaier, Goetz]

Hi,

please review this test fix:
http://cr.openjdk.java.net/~goetz/wr18/8204654-fixJstatTest/01

gcCauseOutput1.awk: 
The pattern scans 11 numbers, while the output contains 13. Also, more '-' are 
possible then checked. 

The other awk scripts need to check more patterns where '-' can appear. 

We have a machine with user.country=de where jstat prints ',' instead of '.' in 
numbers. Explicitly 
start with user.country=en as already done for user.language=en. 

I also refactored the common flags to a variable in utils.sh ... so there won't 
be the need
to edit all these files once more :)

Best regards,
  Goetz.

RE: RFR(S): 8200720: Print additional information in thread dump (times, allocated bytes etc.)

[Lindenmaier, Goetz]

Hi

this discussion touched a lot of points so far, which seem
to lead to different conclusions.

I think we should look at the values printed:

1. cpu=6300.65ms elapsed=123.28s
Overhead
 cpu time:
   * system calls at thread dump time
 elapsed time: 
   * 1 system call at thread creation time
   * 1 64-bit field per thread for the thread start time
   * 1 system call at thread dump time

As I understand, JDK-8143176 would have had to get the
time at each locking, which is much more time critical
than doing this during thread creation. While
the time a lock was held would be much more useful, 
the ratio here, combined with knowledge about the application, 
could lead to the conclusion that the thread is wrongly 
blocked at much lower cost.


2. pthread-id=0x109708000
Overhead: 
 * a field access at thread dump time. Negligible I would say.
 

3. allocated=242236760B defined_classes=1725 
Overhead: 
  * 1 64-bit field per thread.
  * counter increment on class creation

Especially defined_classes seems to be controversial.
As this only makes sense for Java threads, this could
be printed in a line of it's own in Threads::print_on_error()
(which already gets a flag to customize for jstack: 
print_concurrent_locks) by calling a dedicated function in Thread.
No need for flag PrintExtendedThreadInfo thus.

But I would propose to drop this information as it is 
too controversial.

This leaves the times and the pthread-id to be decided whether
they are worth the cost. If so, I think they should be printed
unconditional.

If a flag is required to avoid bloating the info in the default case, 
I would include more infos, as os_prio and nid under that flag.
As jstack is deprecated, changes to jstack could be skipped always
disabling the new printouts.

Finally, I would propose to move _allocated_bytes into
threadStatisticInfo.hpp.

Best regards,
  Goetz.




> -Original Message-
> From: serviceability-dev [mailto:serviceability-dev-
> boun...@openjdk.java.net] On Behalf Of David Holmes
> Sent: Dienstag, 5. Juni 2018 04:53
> To: Haug, Gunter ; Chris Plummer
> ; serviceability-dev  d...@openjdk.java.net>; Langer, Christoph ;
> hotspot-runtime-...@openjdk.java.net
> Subject: Re: RFR(S): 8200720: Print additional information in thread dump
> (times, allocated bytes etc.)
> 
> Hi Gunter,
> 
> On 5/06/2018 1:27 AM, Haug, Gunter wrote:
> > Hi David, Chris,
> >
> > would it be an option to unconditionally print the additional information?
> Regardless which way this is implemented it will be rather complicated and it
> only switches on/off a few field in the thread dump.
> 
> I'm not convinced this is all suitable information for a thread stack
> dump. I can see the time information being useful if using the dump to
> try and diagnoze a hang or responsiveness issue. But the allocated-bytes
> and classes-defined just doesn't seem useful in the context of a thread
> dump to me. Anyone interested in allocation stats is going to be looking
> at GC logs etc which is where this belongs. Ditto the class-stats belong
> in some kind of classloading logging IMHO.
> 
> I'm very reluctant to burden the implementation with capturing these
> kinds of stats, just to use for diagnostic purposes that may not even be
> asked for. I'm very much in the "you shouldn't pay for what you don't
> use" camp in that regard. (See my comments in JDK-8143176 referenced by
> Sean.)
> 
> The ThreadStatisticInfo adds overhead to every thread object - and I'd
> have to suspect there could be overlap with whatever flight recorder
> sticks in there too. (Thread has become even more bloated in recent time!).
> 
> Cheers,
> David
> 
> 
> > Thanks,
> > Gunter
> >
> > On 04.06.18, 01:13, "David Holmes"  wrote:
> >
> >  Hi Gunter, Chris,
> >
> >  Sorry just trying to catch up and this is only a partial look so far 
> > ...
> >
> >  BTW these changes are not limited to serviceability code so adding in
> >  runtime team as well.
> >
> >  On 2/06/2018 9:12 AM, Chris Plummer wrote:
> >  > Hi Gunter,
> >  >
> >  > On 6/1/18 3:17 AM, Haug, Gunter wrote:
> >  >> Hi Chris,
> >  >>
> >  >> thanks for looking into this!
> >  >>
> >  >> Re the synchronization: The value is stored only in a VM operation 
> > at
> >  >> a safepoint by the VM thread. I was of the opinion, that this could
> >  >> not be interrupted by a second VM operation (of the same type). Or
> am
> >  >> I missing something else?
> >  > I was really thinking more about the temporary changing of
> >  > PrintExtendedThreadInfo, not the value stored in the VMOp. You may
> be be
> >  > correct that no more than one VMOp is executing, but while it is
> >  > executing it is has changed the value of PrintExtendedThreadInfo,
> which
> >  > might have an impact on anything else that triggers printing thread 
> > info
> >  > while the VMOp is executing.
> >
> >  Even if nothing else can possibly be running during the 

RE: RFR (M): 8201247: Various cleanups in the attach framework

[Lindenmaier, Goetz]

Hi Christoph, 

I'm familiar with the non-system includes in hotspot, 
there mostly a total alphabetical ordering is followed, like in 
http://hg.openjdk.java.net/jdk/hs/file/0d8ed8b2ac4f/src/hotspot/cpu/x86/c1_CodeStubs_x86.cpp
> It is. However, I have put "subdirs" first. That is, the includes from sys/*
Also, that's not true, see the first file in your webrev, which is sorted as I 
would expect:
http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/src/hotspot/os/aix/attachListener_aix.cpp.html
while this sorts as you state:
http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/src/jdk.attach/linux/native/libattach/VirtualMachineImpl.c.html

Is there a different pattern followed in hotspot and jdk coding?

In case you resort them (have fun :) ), no new webrev is needed.

Best regards,
  Goetz.


> -Original Message-
> From: Langer, Christoph
> Sent: Mittwoch, 11. April 2018 09:45
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; serviceability-
> d...@openjdk.java.net
> Cc: hotspot-...@openjdk.java.net
> Subject: RE: RFR (M): 8201247: Various cleanups in the attach framework
> 
> Hi Goetz,
> 
> thanks for the review.
> 
> > You say you are sorting the includes, but in the VirtualMachineImpl.c
> > files the order is changed, but according to which order? It's
> > not alphabetical as in other files.
> 
> It is. However, I have put "subdirs" first. That is, the includes from sys/*
> come first (in alphabetical order).
> 
> Best regards
> Christoph

RE: RFR (M): 8201247: Various cleanups in the attach framework

[Lindenmaier, Goetz]

Ah, ok, thanks for the info!

Best regards,
  Goetz.

> -Original Message-
> From: Chris Plummer [mailto:chris.plum...@oracle.com]
> Sent: Dienstag, 10. April 2018 19:31
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; Langer, Christoph
> <christoph.lan...@sap.com>; serviceability-dev@openjdk.java.net
> Cc: hotspot-...@openjdk.java.net
> Subject: Re: RFR (M): 8201247: Various cleanups in the attach framework
> 
> On 4/10/18 8:34 AM, Lindenmaier, Goetz wrote:
> > Hi Christoph,
> >
> > thanks for doing this laborious change ... comparing all these files :)
> >
> > Change looks good, just some minor comments:
> >
> > You say you are sorting the includes, but in the VirtualMachineImpl.c
> > files the order is changed, but according to which order? It's
> > not alphabetical as in other files.
> >
> > In windows VirtualMachineImpl.c, what was wrong with printing the
> > last error code?
> JNU_ThrowIOExceptionWithLastError already includes it.
> 
> Chris
> >
> > Best regards,
> >Goetz.
> >
> >
> >
> >> -Original Message-
> >> From: serviceability-dev [mailto:serviceability-dev-
> >> boun...@openjdk.java.net] On Behalf Of Langer, Christoph
> >> Sent: Freitag, 6. April 2018 17:02
> >> To: serviceability-dev@openjdk.java.net
> >> Cc: hotspot-...@openjdk.java.net
> >> Subject: [CAUTION] RFR (M): 8201247: Various cleanups in the attach
> >> framework
> >>
> >> Hi,
> >>
> >>
> >>
> >> can I please get reviews for a set of clean up changes that I came across
> >> when doing some integration work.
> >>
> >>
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8201247
> >> <https://bugs.openjdk.java.net/browse/JDK-8201247>
> >>
> >> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/
> >> <http://cr.openjdk.java.net/~clanger/webrevs/8201247.0/>
> >>
> >>
> >>
> >> Detailed comments about the changes can be found in the bug.
> >>
> >>
> >>
> >> Thanks & best regards
> >>
> >> Christoph
> >>
> >>
> >>
> >>

Re: RFR: 8189102: All tools should support -?, -h and --help

[Lindenmaier, Goetz]

Hi,

The CSR for this change is approved now.
https://bugs.openjdk.java.net/browse/JDK-8191477

If there aren't any more objections, I will push this.
Webrev rebased and with updated 2018 copyright messages:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.08/

Best regards,
  Goetz.

RE: FW: RFR(M): 8189102: All tools should support -?, -h and --help

[Lindenmaier, Goetz]

Hi,

I had to update my webrev after the javah launcher had been removed:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.07/

I would appreciate a final decision to push this.

Best regards,
  Goetz.


-Original Message-
From: serviceability-dev [mailto:serviceability-dev-boun...@openjdk.java.net] 
On Behalf Of Lindenmaier, Goetz
Sent: Tuesday, December 12, 2017 11:37 AM
To: Alan Bateman <alan.bate...@oracle.com>; core-libs-...@openjdk.java.net; 
'compiler-...@openjdk.java.net' <compiler-...@openjdk.java.net>; 
serviceability-dev (serviceability-dev@openjdk.java.net) 
<serviceability-dev@openjdk.java.net>
Subject: RE: FW: RFR(M): 8189102: All tools should support -?, -h and --help

Hi Alan,

Javadoc combines documentation and support of a flag in the
way the flag handling is implemented.  On the other side, 
it prints the help message anyways if a wrong flag is presented 
to it, so if you call it with -help you get the help message.
Therefore, in my original change where I tried to get it 
more cleaned up, I removed -help support and documentation 
from Javadoc.

I added it again and updated the table in the CSR:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.06/

Best regards,
  Goetz.

> -Original Message-
> From: Alan Bateman [mailto:alan.bate...@oracle.com]
> Sent: Montag, 11. Dezember 2017 17:53
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; core-libs-
> d...@openjdk.java.net; 'compiler-...@openjdk.java.net'  d...@openjdk.java.net>; serviceability-dev (serviceability-
> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> Subject: Re: FW: RFR(M): 8189102: All tools should support -?, -h and --help
> 
> 
> 
> On 07/12/2017 11:20, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > ... missed some lists in my first post ...
> >
> > I prepared a fifth webrev for this change.  Please review.
> >
> > It incorporates the changes requested by the CSR reviewers
> > (not to remove docuemtation of '-help' where is was documented
> > before) and the changes proposed by Kumar:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.05/
> >
> >
> Looks like it still drops -help from the javadoc usage message, I can't
> tell if you meant to do that.
> 
> -Alan.

RE: FW: RFR(M): 8189102: All tools should support -?, -h and --help

[Lindenmaier, Goetz]

Hi Alan,

Javadoc combines documentation and support of a flag in the
way the flag handling is implemented.  On the other side, 
it prints the help message anyways if a wrong flag is presented 
to it, so if you call it with -help you get the help message.
Therefore, in my original change where I tried to get it 
more cleaned up, I removed -help support and documentation 
from Javadoc.

I added it again and updated the table in the CSR:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.06/

Best regards,
  Goetz.

> -Original Message-
> From: Alan Bateman [mailto:alan.bate...@oracle.com]
> Sent: Montag, 11. Dezember 2017 17:53
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; core-libs-
> d...@openjdk.java.net; 'compiler-...@openjdk.java.net'  d...@openjdk.java.net>; serviceability-dev (serviceability-
> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> Subject: Re: FW: RFR(M): 8189102: All tools should support -?, -h and --help
> 
> 
> 
> On 07/12/2017 11:20, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > ... missed some lists in my first post ...
> >
> > I prepared a fifth webrev for this change.  Please review.
> >
> > It incorporates the changes requested by the CSR reviewers
> > (not to remove docuemtation of '-help' where is was documented
> > before) and the changes proposed by Kumar:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.05/
> >
> >
> Looks like it still drops -help from the javadoc usage message, I can't
> tell if you meant to do that.
> 
> -Alan.

FW: RFR(M): 8189102: All tools should support -?, -h and --help

[Lindenmaier, Goetz]

Hi,

... missed some lists in my first post ...

I prepared a fifth webrev for this change.  Please review.

It incorporates the changes requested by the CSR reviewers 
(not to remove docuemtation of '-help' where is was documented
before) and the changes proposed by Kumar:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.05/

See also the information in the webrev  itself, there are also patch files
with the incremental builds.

This change contains fixes for some langtool tests.
I ran the following test suites on it:
hotspot, jdk, langtools, nashorn, jaxp, most of them on 
all the platforms we build.

Best regards,
  Goetz.




> -Original Message-
> From: Lindenmaier, Goetz
> Sent: Mittwoch, 11. Oktober 2017 22:07
> To: hotspot-dev developers <hotspot-...@openjdk.java.net>
> Subject: RFR(M): 8189102: All tools should support -?, -h and --help
> 
> Hi
> 
> The tools in jdk should all show the same behavior wrt. help flags.
> This change normalizes the help flags of a row of the tools in the jdk.
> Java accepts -?, -h and --help, thus I changed the tools to support
> these, too.  Some tools exited with '1' after displaying the help message,
> I turned this to '0'.
> 
> Maybe this is not the right mailing list for this, please advise.
> 
> Please review this change. I please need a sponsor.
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.01/
> 
> In detail, this fixes the help message of the following tools:
> jar  -? -h --help;  added -?.
> jarsigner-? -h --help;  added --help. -help accepted but not documented.
> javac-?--help;  added -?. Removed -help. -h is taken for other 
> purpose
> javadoc  -? -h --help;  added -h -?. Removed -help
> javap-? -h --help;  added -h. -help accepted but no more documented.
> jcmd -? -h --help;  added -? --help. -help accepted but no more
> documented. Changed return value to '0'
> jdb  -? -h --help;  added -? -h --help. -help accepted but no more
> documented.
> jdeprscan-? -h --help;  added -?
> jinfo-? -h --help;  added -? --help. -help accepted but no more
> documented.
> jjs -h --help;  Replaced -help by --help. Adding more not straight
> forward.
> jps  -? -h --help;  added -? --help. -help accepted but no more
> documented.
> jshell   -? -h --help;  added -?
> jstat-? -h --help;  added -h --help. -help accepted but no more
> documented.
> 
> Best regards,
>   Goetz.

RE: RFR(S): 8192978: Missing checks and small fixes in jdwp library

[Lindenmaier, Goetz]

Hi Christoph,

thanks for doing this change.
I would appreciate if the coverity findings get into the codebase,
at minimum it simplifies repeated runs.
I’m not sure about the syntax cleanups, especially invoker.c,
this seems too trivial to touch the file.

Thanks for explaining inStream.c, I think it would help
documenting the number or computing it explicitly as you propose.

Best regards,
  Goetz.

From: serviceability-dev [mailto:serviceability-dev-boun...@openjdk.java.net] 
On Behalf Of Langer, Christoph
Sent: Dienstag, 5. Dezember 2017 11:52
To: Chris Plummer ; 
serviceability-dev@openjdk.java.net
Subject: RE: RFR(S): 8192978: Missing checks and small fixes in jdwp library

Hi Chris,

thanks for looking at this.

The main part of the changes are the findings of a code scan tool (coverity). 
Here are some detailed comments. I also made a small update to the webrev 
(concerning eventHelper.c): 
http://cr.openjdk.java.net/~clanger/webrevs/8192978.1/.


> shmemBase.c: seems correct, but could use explanation/example of when 
> existing code was failing.

This is a coverity finding. The correct size specification as per Microsoft’s 
doc [1] for jlong (__int64) would be I64.

VirtualMachineImpl.c: When/why is pos ever null?

This is also a coverity case. For some reason, coverity thinks that pos could 
be NULL here. But I’m with you – I also don’t see a path how that could ever 
happen. Nevertheless, this change would please converity and I don’t see it 
being performance critical so I would like to leave it. It’s also not wrong.

error_messages.c: Is there any reason not to do this fix for all platforms? Do 
you have a test case for it?

This is a Windows only issue. “vsnprintf“ would write the terminating 0. But in 
jdk.jdwp.agent/windows/native/libjdwp/util_md.h, vsnprintf is redefined to 
_vsnprintf. And this, by the Mircrosoft documentation [2], doesn’t necessarily 
write the terminating character.

error_messages.h: ok. looks like just whitespace cleanup

yes

eventHelper.c: Do you have a testcase? Also, is the "bagAdd(eventBag)" message 
going to be of use to the user?

For this one I don’t have the history. Maybe it was also the coverity tool. But 
there is no testcase. In my update I have updated 2 other places with the null 
check where bagAdd is called. I guess in case of such a null error occurring, 
it could help a little. But probably this would be something to be investigated 
by the developer rather than the debugging user.

inStream.c: inStream_init() now uses a magic number of 11. What does it 
represent? inStream_endOfInput() looks like it used to be completely broken. 
How was this not noticed? Is this related to the change inStream_init(), which 
possible was masking this error? Is there a test case for it?

I found this fix in our code base. instream_endOfInput() is obviously never 
used. At least I don’t find any references in the source code scan. Maybe I 
shall completely remove it?
As for the “magic number of 11”: This is the offset to the payload of a 
jdwpCmdPacket, see jdk.jdwp.agent/share/native/include/ jdwpTransport.h.
(sizeof(jint) /* len*/ + sizeof(jint) /* id */ + sizeof(jbyte) /* flags*/ + 
sizeof(jbyte) /* cmdSet */ + sizeof(jbyte) /*cmd */
Maybe I should write it down explicitly?
With that offset subtracted from the length field, we initialize stream->left 
with the correct value which makes the checks in readBytes (line 73) more 
correct.
But there is also no test case

invoker.c: ok: looks like just whitespace cleanup

Yes.

log_messages.c: is there any reason not to do this fix for all platforms? Do 
you have a test case for it?

Same goes as for error_messages.c.


I’m still hoping to get this change done under the hood of JDK-8192978. I will 
update the bug with some more details and also add an appropriate noreg label.

Best regards,
Christoph
[1] https://msdn.microsoft.com/en-us/library/tcxf1dw6.aspx
[2] https://msdn.microsoft.com/en-us/library/1kt27hek.aspx


From: Chris Plummer [mailto:chris.plum...@oracle.com]
Sent: Montag, 4. Dezember 2017 22:32
To: Langer, Christoph 
>; 
serviceability-dev@openjdk.java.net
Subject: Re: RFR(S): 8192978: Missing checks and small fixes in jdwp library

Hi Christoph,

Some of your changes could use explanations. Can you please elaborate on the 
problems you are fixing in the CR? Test cases, or at least explaining how to 
reproduce the issues you are fixing would also be useful.

shmemBase.c: seems correct, but could use explanation/example of when existing 
code was failing.

VirtualMachineImpl.c: When/why is pos ever null?

error_messages.c: Is there any reason not to do this fix for all platforms? Do 
you have a test case for it?

error_messages.h: ok. looks like just whitespace cleanup

eventHelper.c: Do you have a testcase? Also, is the "bagAdd(eventBag)" message 
going to be of use to the 

RE: RFR: 8189102: All tools should support -?, -h and --help

[Lindenmaier, Goetz]

Hi Kumar, 

I'm already looking at the issues from your other mail.
Detailed comments will follow.

I'll also check and fix the new tests you report. 
I think we don't run the langtool tests, i.e. I know
we didn't run them before the repos were
merged.  Obviously we should add them to our testing :)

Thanks for further testing and best regards,
  Goetz.


> -Original Message-
> From: Kumar Srinivasan [mailto:kumar.x.sriniva...@oracle.com]
> Sent: Freitag, 1. Dezember 2017 15:42
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
> Cc: core-libs-...@openjdk.java.net; 'compiler-...@openjdk.java.net'
> <compiler-...@openjdk.java.net>; serviceability-dev (serviceability-
> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> Hi,
> 
> Besides my private comments to you, there are 2-3 internal tests
> which fail.
> 
> Have you run all the langtools tests ? There are 4 Windows tests
> that fail with langtools:
> 
> jdk/javadoc/doclet/testHelpOption/TestHelpOption.java
> jdk/javadoc/tool/CheckResourceKeys.java
> jdk/javadoc/tool/ToolProviderTest.java
> tools/javap/InvalidOptions.java
> tools/jdeps/MultiReleaseJar.java
> 
> This changeset needs to be vetted thoroughly using internal build and test
> systems.
> Any Oracle engineer willing to sponsor this ?
> 
> Kumar
> 
> 
> On 11/28/2017 3:16 AM, Lindenmaier, Goetz wrote:
> 
> 
>   Hi,
> 
>   I uploaded a new webrev:
>   http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.04/
> 
>   This includes the changes
> - to jshell requested by Robert
> - to the test as requested by Kumar.
> 
>   See also incremental patch and the test output including all the
>   help messages referenced in the webrev.
> 
>   Best regards,
> Goetz.
> 
> 
>   -Original Message-----
>   From: Kumar Srinivasan
> [mailto:kumar.x.sriniva...@oracle.com]
>   Sent: Montag, 27. November 2017 17:43
>   To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
> <mailto:goetz.lindenma...@sap.com>
>   Cc: core-libs-...@openjdk.java.net <mailto:core-libs-
> d...@openjdk.java.net> ; 'compiler-...@openjdk.java.net
> <mailto:compiler-...@openjdk.java.net> '
>   <compiler-...@openjdk.java.net> <mailto:compiler-
> d...@openjdk.java.net> ; serviceability-dev (serviceability-
>   d...@openjdk.java.net <mailto:d...@openjdk.java.net> )
> <serviceability-dev@openjdk.java.net> <mailto:serviceability-
> d...@openjdk.java.net>
>   Subject: Re: RFR: 8189102: All tools should support -?, -h and -
> -help
> 
>   Hi,
> 
>   I looked at some of the components I maintain, and they look
> good.
> 
>   Wrt. the test:
> 
>   1. The local variables/fields don't comply with the coding
> conventions,
>   we have been
> following in the JDK.
> 
>   2.  Hmm, someone parked a .ini file in bin directory, later
> removed,
> perhaps on windows simply check for .exe ? Should a
> check exist
> to verify if file has executable permissions
> ?"File.canExecute".
> 
> 171 // Returns true if the file is not a tool.
> 172 static boolean notATool(String file) {
> 173 file = file.toLowerCase();
> 174 if (file.endsWith(".dll") ||
> 175 file.endsWith(".map") ||
> 176 file.endsWith(".pdb") ||
> 177 file.equals("server")) {  // server subdir on
> windows.
> 178 return true;
> 179 }
> 180 return false;
> 181 }
> 
> 
>   3.  Typo in comment
> 
>   201 // Check whether 'flag' appears in 'line' as a word of
> itself. I must not
> 
>   s/I must/It must/
> 
> 
>   4. There is a method to check for isEnglishLocale in
> TestHelper, perhaps
>   use it
>   to have the test bale out in non english locales as early as
> possible ?
> 
>   5.  Has this been tested on all platforms ? do you need help
> testing it ?
> 
>   Kumar
> 
> 
>   On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote:
> 
>   Hi,
> 
&

RE: RFR: 8189102: All tools should support -?, -h and --help

[Lindenmaier, Goetz]

Thanks, Robert!

Best regards,
  Goetz.

> -Original Message-
> From: Robert Field [mailto:robert.fi...@oracle.com]
> Sent: Mittwoch, 29. November 2017 19:31
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
> Cc: Kumar Srinivasan <kumar.x.sriniva...@oracle.com>; serviceability-dev
> (serviceability-dev@openjdk.java.net)  d...@openjdk.java.net>; compiler-...@openjdk.java.net; core-libs-
> d...@openjdk.java.net
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> Thumbs up for JShell changes.
> 
> -Robert
> 
> > On Nov 28, 2017, at 3:16 AM, Lindenmaier, Goetz
> <goetz.lindenma...@sap.com> wrote:
> >
> > Hi,
> >
> > I uploaded a new webrev:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.04/
> >
> > This includes the changes
> >  - to jshell requested by Robert
> >  - to the test as requested by Kumar.
> >
> > See also incremental patch and the test output including all the
> > help messages referenced in the webrev.
> >
> > Best regards,
> >  Goetz.
> >
> >> -Original Message-
> >> From: Kumar Srinivasan [mailto:kumar.x.sriniva...@oracle.com]
> >> Sent: Montag, 27. November 2017 17:43
> >> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
> >> Cc: core-libs-...@openjdk.java.net; 'compiler-...@openjdk.java.net'
> >> <compiler-...@openjdk.java.net>; serviceability-dev (serviceability-
> >> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> >> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> >>
> >> Hi,
> >>
> >> I looked at some of the components I maintain, and they look good.
> >>
> >> Wrt. the test:
> >>
> >> 1. The local variables/fields don't comply with the coding conventions,
> >> we have been
> >>  following in the JDK.
> >>
> >> 2.  Hmm, someone parked a .ini file in bin directory, later removed,
> >>  perhaps on windows simply check for .exe ? Should a check exist
> >>  to verify if file has executable permissions ?"File.canExecute".
> >>
> >>  171 // Returns true if the file is not a tool.
> >>  172 static boolean notATool(String file) {
> >>  173 file = file.toLowerCase();
> >>  174 if (file.endsWith(".dll") ||
> >>  175 file.endsWith(".map") ||
> >>  176 file.endsWith(".pdb") ||
> >>  177 file.equals("server")) {  // server subdir on windows.
> >>  178 return true;
> >>  179 }
> >>  180 return false;
> >>  181 }
> >>
> >>
> >> 3.  Typo in comment
> >>
> >> 201 // Check whether 'flag' appears in 'line' as a word of itself. I 
> >> must not
> >>
> >> s/I must/It must/
> >>
> >>
> >> 4. There is a method to check for isEnglishLocale in TestHelper, perhaps
> >> use it
> >> to have the test bale out in non english locales as early as possible ?
> >>
> >> 5.  Has this been tested on all platforms ? do you need help testing it ?
> >>
> >> Kumar
> >>
> >>
> >> On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote:
> >>> Hi,
> >>>
> >>> please review this change. I also filed a CSR for this:
> >>> http://cr.openjdk.java.net/~goetz/wr17/8189102-
> >> helpMessage/webrev.02/
> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >>>
> >>> See the webrev for a detailed description of the changes.
> >>>
> >>> If required, I'll make break-out changes to be reviewed separately.
> >>>
> >>> I had posted a RFR before, but improved the change to
> >>> give a more complete overview of currently supported flags
> >>> for the CSR:
> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> >> October/028615.html
> >>>
> >>> Best regards,
> >>>   Goetz.
> >>>
> >

RE: RFR: 8189102: All tools should support -?, -h and --help

[Lindenmaier, Goetz]

Hi,

I uploaded a new webrev:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.04/

This includes the changes 
  - to jshell requested by Robert
  - to the test as requested by Kumar.

See also incremental patch and the test output including all the
help messages referenced in the webrev.

Best regards,
  Goetz.

> -Original Message-
> From: Kumar Srinivasan [mailto:kumar.x.sriniva...@oracle.com]
> Sent: Montag, 27. November 2017 17:43
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
> Cc: core-libs-...@openjdk.java.net; 'compiler-...@openjdk.java.net'
> <compiler-...@openjdk.java.net>; serviceability-dev (serviceability-
> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> Hi,
> 
> I looked at some of the components I maintain, and they look good.
> 
> Wrt. the test:
> 
> 1. The local variables/fields don't comply with the coding conventions,
> we have been
>   following in the JDK.
> 
> 2.  Hmm, someone parked a .ini file in bin directory, later removed,
>   perhaps on windows simply check for .exe ? Should a check exist
>   to verify if file has executable permissions ?"File.canExecute".
> 
>   171 // Returns true if the file is not a tool.
>   172 static boolean notATool(String file) {
>   173 file = file.toLowerCase();
>   174 if (file.endsWith(".dll") ||
>   175 file.endsWith(".map") ||
>   176 file.endsWith(".pdb") ||
>   177 file.equals("server")) {  // server subdir on windows.
>   178 return true;
>   179 }
>   180 return false;
>   181 }
> 
> 
> 3.  Typo in comment
> 
> 201 // Check whether 'flag' appears in 'line' as a word of itself. I must 
> not
> 
> s/I must/It must/
> 
> 
> 4. There is a method to check for isEnglishLocale in TestHelper, perhaps
> use it
> to have the test bale out in non english locales as early as possible ?
> 
> 5.  Has this been tested on all platforms ? do you need help testing it ?
> 
> Kumar
> 
> 
> On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > please review this change. I also filed a CSR for this:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >
> > See the webrev for a detailed description of the changes.
> >
> > If required, I'll make break-out changes to be reviewed separately.
> >
> > I had posted a RFR before, but improved the change to
> > give a more complete overview of currently supported flags
> > for the CSR:
> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> October/028615.html
> >
> > Best regards,
> >Goetz.
> >

RE: RFR: 8189102: All tools should support -?, -h and --help

[Lindenmaier, Goetz]

Hi Kumar, 

Thanks for looking at my change!
 
> I looked at some of the components I maintain, and they look good.
May I ask which these are? So I can account whether all parts have been 
reviewed?

> 1. The local variables/fields don't comply with the coding conventions,
> we have been
>   following in the JDK.
Removed all '_' from fields.  Anything else?  TOOLS_NOT_TO_TEST
is formatted as the similar list in VersionCheck.java.

> 2.  Hmm, someone parked a .ini file in bin directory, later removed,
>   perhaps on windows simply check for .exe ? Should a check exist
>   to verify if file has executable permissions ?"File.canExecute".
> 
>   171 // Returns true if the file is not a tool.
>   172 static boolean notATool(String file) {
>   173 file = file.toLowerCase();
>   174 if (file.endsWith(".dll") ||
>   175 file.endsWith(".map") ||
>   176 file.endsWith(".pdb") ||
>   177 file.equals("server")) {  // server subdir on windows.
>   178 return true;
>   179 }
>   180 return false;
>   181 } 
I anyways wondered why .dll + friends are in the exe directory and 
not in the lib directory.  But a check for executable file is better
than this list. Changed.

> 3.  Typo in comment
Fixed. 

> 4. There is a method to check for isEnglishLocale in TestHelper, perhaps
> use it to have the test bale out in non english locales as early as possible ?
I added a bailout at the beginning of the test. Thanks for the advice!
But thinking about this a @requires englishLocale would be useful here.
 
> 5.  Has this been tested on all platforms ? do you need help testing it ?
Our testing is on ntamd64, linuxppc64, linuxppc64le, linuxs390x, linuxx86_64,
sun_64 and aixppc64. I run the jdk jtreg tests on these platforms. I once ran 
the change with the jdk-hs repo, where we test test/hotspot/jtreg and most jck 
tests.  All passed.
I don't think this is very platform dependent (most differences are
between unix/windows) so this platform coverage should suffice 
I think.

I'll post a new webrev later on.

Best regards,
  Goetz.


> 
> Kumar
> 
> 
> On 11/17/2017 3:23 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > please review this change. I also filed a CSR for this:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >
> > See the webrev for a detailed description of the changes.
> >
> > If required, I'll make break-out changes to be reviewed separately.
> >
> > I had posted a RFR before, but improved the change to
> > give a more complete overview of currently supported flags
> > for the CSR:
> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> October/028615.html
> >
> > Best regards,
> >Goetz.
> >

RE: 8189102: All tools should support -?, -h and --help

[Lindenmaier, Goetz]

Hi,

I prepared a new webrev trying to incorporate all change requests:
 * I removed changes to non-english property files.
 * I removed help texts from ktab, kinit, klist
 * I removed changes to corba tools
 * I added test cases for new flags to tool specific tests (to the ones I 
spotted)
 * I added -help back to javac
I left the removal of -help from Javadoc, as Javadoc just prints the help 
message
anyways. 

New webrev:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/index.html

I uploaded the parts of the patch I removed within the webrev:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/help_in_property_files.patch
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/KinitKtabKlist_help_message.patch
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.03/corba_help_message.patch

Best regards,
  Goetz.


> -Original Message-
> From: serviceability-dev [mailto:serviceability-dev-
> boun...@openjdk.java.net] On Behalf Of Lindenmaier, Goetz
> Sent: Friday, November 17, 2017 12:23 PM
> To: core-libs-...@openjdk.java.net; 'compiler-...@openjdk.java.net'
> <compiler-...@openjdk.java.net>; serviceability-dev (serviceability-
> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> Subject: RFR: 8189102: All tools should support -?, -h and --help
> 
> Hi,
> 
> please review this change. I also filed a CSR for this:
> http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> 
> See the webrev for a detailed description of the changes.
> 
> If required, I'll make break-out changes to be reviewed separately.
> 
> I had posted a RFR before, but improved the change to
> give a more complete overview of currently supported flags
> for the CSR:
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> October/028615.html
> 
> Best regards,
>   Goetz.

RE: RFR: 8189102: All tools should support -?, -h and --help

[Lindenmaier, Goetz]

OK, thanks!

Best regards,
  Goetz.

> -Original Message-
> From: Weijun Wang [mailto:weijun.w...@oracle.com]
> Sent: Wednesday, November 22, 2017 8:08 AM
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
> Cc: core-libs-...@openjdk.java.net; compiler-...@openjdk.java.net;
> serviceability-dev (serviceability-dev@openjdk.java.net)  d...@openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> Hi Goetz
> 
> I would just remove it.
> 
> Thanks
> Max
> 
> > On Nov 22, 2017, at 2:53 PM, Lindenmaier, Goetz
> <goetz.lindenma...@sap.com> wrote:
> >
> > Hi Max,
> >
> > while removing the comments from the k-tools, I saw this:
> >
> > ---
> a/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Kl
> ist.java  Tue Oct 10 14:39:45 2017 +0200
> > +++
> b/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Kl
> ist.java  Tue Nov 21 13:09:17 2017 +0100
> > @@ -356,7 +358,6 @@
> > System.out.println("\t-t \t shows keytab entry timestamps");
> > System.out.println("\t-K \t shows keytab entry key value");
> > System.out.println("\t-e \t shows keytab entry key type");
> > -System.out.println("\nUsage: java sun.security.krb5.tools.Klist " +
> > -   "-help for help.");
> > +System.out.println("\n-? -h --help print this help message and 
> > exit");
> > }
> > }
> >
> > I don't think the old comment is in the original program :) and anyways, -
> help
> > is not supported by Klist.  It prints the usage called with the flag, but 
> > just
> because
> > it prints it on any wrong flag.
> >
> > So should I replace the comment here?
> > Or at least remove it?
> >
> > Best regards,
> >  Goetz
> >
> >> -Original Message-
> >> From: Weijun Wang [mailto:weijun.w...@oracle.com]
> >> Sent: Monday, November 20, 2017 3:49 PM
> >> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
> >> Cc: core-libs-...@openjdk.java.net; compiler-...@openjdk.java.net;
> >> serviceability-dev (serviceability-dev@openjdk.java.net)  >> d...@openjdk.java.net>
> >> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> >>
> >> Hi Goetz
> >>
> >> I understand your intention.
> >>
> >> If the reason is that one day every tool will switch to this new style, 
> >> please
> at
> >> least do not include kinit, klist and ktab. These Windows-only commands
> are
> >> meant to emulate MIT krb5 tools with the same names and we need to
> keep
> >> the option (and maybe the help screen) as similar as possible.
> >>
> >> I am OK with supporting the --help option undocumented.
> >>
> >> Thanks
> >> Max
> >>
> >>> On Nov 20, 2017, at 9:46 PM, Lindenmaier, Goetz
> >> <goetz.lindenma...@sap.com> wrote:
> >>>
> >>> Hi Max,
> >>>
> >>> I think there are so many tools mixing both kinds of
> >>> options, that it's rather a gain if all at least document
> >>> the same, up to date help message, than if the documentation
> >>> is skipped for some.
> >>>
> >>> After my change, all the help messages are quite similar.
> >>> I updated them to use the same wording while trying to
> >>> keep the sentence structure in accordance with the other
> >>> documented flags, see below.
> >>>
> >>> Best regards,
> >>> Goetz.
> >>>
> >>>
> >>>
> >>> -? -h --help   display this help message
> >>> -? -h --help  display this help message
> >>> -h, --help (Print this help message.)
> >>> -?, --help   Print this help message
> >>> -? -h --help Print this help message
> >>> --help, -h, -?  Display command line options and exit
> >>> -? -h --help Print this help message
> >>> -h -? --help  Print this help message
> >>> -? -h --help
> >>> -? -h --help  : display this help message and exit
> >>> -? -h --help   :  display this help message and exit
> >>> -? -h --help  print this help message and exit
> >>> -? | -h | --help to print this help message
> >>> 

RE: RFR: 8189102: All tools should support -?, -h and --help

[Lindenmaier, Goetz]

Hi Max, 

while removing the comments from the k-tools, I saw this:

--- 
a/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java
Tue Oct 10 14:39:45 2017 +0200
+++ 
b/src/java.security.jgss/windows/classes/sun/security/krb5/internal/tools/Klist.java
Tue Nov 21 13:09:17 2017 +0100
@@ -356,7 +358,6 @@
 System.out.println("\t-t \t shows keytab entry timestamps");
 System.out.println("\t-K \t shows keytab entry key value");
 System.out.println("\t-e \t shows keytab entry key type");
-System.out.println("\nUsage: java sun.security.krb5.tools.Klist " +
-   "-help for help.");
+System.out.println("\n-? -h --help print this help message and exit");
 }
 }

I don't think the old comment is in the original program :) and anyways, -help
is not supported by Klist.  It prints the usage called with the flag, but just 
because
it prints it on any wrong flag.

So should I replace the comment here?
Or at least remove it?

Best regards,
  Goetz

> -Original Message-
> From: Weijun Wang [mailto:weijun.w...@oracle.com]
> Sent: Monday, November 20, 2017 3:49 PM
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
> Cc: core-libs-...@openjdk.java.net; compiler-...@openjdk.java.net;
> serviceability-dev (serviceability-dev@openjdk.java.net)  d...@openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> Hi Goetz
> 
> I understand your intention.
> 
> If the reason is that one day every tool will switch to this new style, 
> please at
> least do not include kinit, klist and ktab. These Windows-only commands are
> meant to emulate MIT krb5 tools with the same names and we need to keep
> the option (and maybe the help screen) as similar as possible.
> 
> I am OK with supporting the --help option undocumented.
> 
> Thanks
> Max
> 
> > On Nov 20, 2017, at 9:46 PM, Lindenmaier, Goetz
> <goetz.lindenma...@sap.com> wrote:
> >
> > Hi Max,
> >
> > I think there are so many tools mixing both kinds of
> > options, that it's rather a gain if all at least document
> > the same, up to date help message, than if the documentation
> > is skipped for some.
> >
> > After my change, all the help messages are quite similar.
> > I updated them to use the same wording while trying to
> > keep the sentence structure in accordance with the other
> > documented flags, see below.
> >
> > Best regards,
> >  Goetz.
> >
> >
> >
> > -? -h --help   display this help message
> > -? -h --help  display this help message
> > -h, --help (Print this help message.)
> > -?, --help   Print this help message
> > -? -h --help Print this help message
> > --help, -h, -?  Display command line options and exit
> > -? -h --help Print this help message
> > -h -? --help  Print this help message
> > -? -h --help
> > -? -h --help  : display this help message and exit
> > -? -h --help   :  display this help message and exit
> > -? -h --help  print this help message and exit
> > -? | -h | --help to print this help message
> > jmap -? -h --help  to print this help message
> > usage: jps [-? -h --help]
> > -? -h --help to print this help message
> > -? -h --help  Prints this help message.
> > -? -h --help print this help message
> > -? -h --help  Print this synopsis of standard options and exit
> > Use "keytool -? -h or --help" for all available commands
> > --helpprint this help message to the output stream
> > -?, -h, --help   Print this help message
> > -h, --help, -?Print this help message
> > -?, -h, --help   Print this help message
> > -? -h --help Print this help message and exit
> > -?, -h, --help  print this help message
> > -?, -h, --helpprint this help message
> > -? -h --help   Print this help message
> > -?, -h, --help[:compat]Give this, or optionally the compatibility, help
> > [-? -h --help]  Print this help message
> > jstatd -?|-h|--help
> >
> >
> >> -Original Message-
> >> From: Weijun Wang [mailto:weijun.w...@oracle.com]
> >> Sent: Sonntag, 19. November 2017 01:28
> >> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
> >> Cc: core-libs-...@openjdk.java.net; compiler-...@openjdk.java.net;
> >> serviceability-dev (serviceabilit

RE: RFR: 8189102: All tools should support -?, -h and --help

[Lindenmaier, Goetz]

Hi Alan, 

thanks for looking at my change.

Thanks for pointing to JEP 293. I see my change mostly
follows its ideas.
As Jon, I don't think asking for support of -help makes sense
as it's not according to the gnu style, and it's not that
hard to get it right anyways.

I'll remove the edits to the properties files.

The deprecated tools are
  orbd, 
  wsgen
  wsimport
  schemagen
Is that correct?
I'll remove them from my change.  The test has a list of tools not to test, 
I'll add them there.

Best regards,
  Goetz.



> -Original Message-
> From: Alan Bateman [mailto:alan.bate...@oracle.com]
> Sent: Samstag, 18. November 2017 09:42
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; core-libs-
> d...@openjdk.java.net; 'compiler-...@openjdk.java.net'  d...@openjdk.java.net>; serviceability-dev (serviceability-
> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> On 17/11/2017 11:23, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > please review this change. I also filed a CSR for this:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >
> > See the webrev for a detailed description of the changes.
> >
> A question for Jon Gibbons: In JEP 293 the guideline is that tools
> should support `--help`. Do you think this should be expanded to include
> `-help`, and `-?` (and maybe `-h` where it make sense)?
> 
> As regards the webrev then the changes to the localized resources can be
> dropped. As Jon noted, we don't usually edit these directly as they are
> bulk updated/replaced by translation drops that usually happen late in
> each release.
> 
> It's not clear to me that it's wroth trying to update the JAXB, JAX-WS,
> and CORBA tools. One reason the corresponding tool modules are
> deprecated-for-removal and there is a draft JEP to remove them
> completely [1]. In addition, the JAXB ad JAX-WS tools are problematic to
> change as they are owned by upstream projects on the Java EE github -
> any changes to the code in these modules needs to coordinated to avoid
> having a fork here.
> 
> -Alan
> 
> [1] http://openjdk.java.net/jeps/8189188

RE: RFR: 8189102: All tools should support -?, -h and --help

[Lindenmaier, Goetz]

Hi Robert, 

thanks for looking at my change.

I'm fine with listing the flags in a different order, but 
it's ambiguous. Java itslef lists "-? -h --help" therefore
I chose this for most of the tools, too.
But just tell me how to put it.
Below, I list all the option help messages for the 
tools on linux. --help-extra is quite consistent.

Best regards,
  Goetz.
  
  
 --help-extra, -X Print help on extra options
 --help-extra, -X
 --help-extra, -X  Print help on non-standard options and exit
 -X   print help on extra options to the output stream
 --help-extra  print help on extra options to the output stream
 --help-extra Print help on extra options   
 --help-extra   Give help on extra options


-? -h --help   display this help message
-? -h --help  display this help message
-h, --help (Print this help message.)
-?, --help   Print this help message
-? -h --help Print this help message
--help, -h, -?  Display command line options and exit
-? -h --help Print this help message
-h -? --help  Print this help message
-? -h --help
-? -h --help  : display this help message and exit
-? -h --help   :  display this help message and exit
-? -h --help  print this help message and exit
-? | -h | --help to print this help message
jmap -? -h --help  to print this help message
usage: jps [-? -h --help]
-? -h --help to print this help message
-? -h --help  Prints this help message.
-? -h --help print this help message
-? -h --help  Print this synopsis of standard options and exit
Use "keytool -? -h or --help" for all available commands
--helpprint this help message to the output stream
-?, -h, --help   Print this help message
-h, --help, -?Print this help message
-?, -h, --help   Print this help message
-? -h --help Print this help message and exit
-?, -h, --help  print this help message
-?, -h, --helpprint this help message
-? -h --help   Print this help message
-?, -h, --help[:compat]Give this, or optionally the compatibility, help
[-? -h --help]  Print this help message
jstatd -?|-h|--help


> -Original Message-
> From: Robert Field [mailto:robert.fi...@oracle.com]
> Sent: Freitag, 17. November 2017 20:07
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
> Cc: core-libs-...@openjdk.java.net; compiler-...@openjdk.java.net;
> serviceability-dev (serviceability-dev@openjdk.java.net)  d...@openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> JShell changes —
> 
> The code change is fine.
> 
> The help change in the properties file is not consistent with the other items,
> note:--help-extra, -X  Print help on…
>   so this should be:  —help, -h, -?
> Or, if there is a tool-wide standard, then the —help-extra entry should be
> changed.
> 
> The tests of “—help” should be updated to include the now documented “-
> h” and “-?”
> 
> As Jon noted, the _ja and _zh_CN properties should not be touched.
> 
> -Robert
> 
> > On Nov 17, 2017, at 3:23 AM, Lindenmaier, Goetz
> <goetz.lindenma...@sap.com> wrote:
> >
> > Hi,
> >
> > please review this change. I also filed a CSR for this:
> > http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
> > CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> >
> > See the webrev for a detailed description of the changes.
> >
> > If required, I'll make break-out changes to be reviewed separately.
> >
> > I had posted a RFR before, but improved the change to
> > give a more complete overview of currently supported flags
> > for the CSR:
> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> October/028615.html
> >
> > Best regards,
> >  Goetz.
> >

RE: RFR: 8189102: All tools should support -?, -h and --help

[Lindenmaier, Goetz]

Hi Jon, 

thanks for your feedback.

Sorry for getting the javac/Javadoc wrong, I missed that. 
The point is that the option implementation there does not have
the possibility to accept an option but not document it.

javac:
I'd like to propose to add -help again.  javac else prints:
  javac: invalid flag: -help
  Usage: javac  
  use --help for a list of possible options
Which isn't that nice.

Javadoc:
I'd prefer to remove -help because then it's not documented
which is more streamlined with the overall idea of this change. And Javadoc
behaves "friendly": Javadoc -help prints the usage but exits with 
return code '1'.  I don't think that's a major problem.

I'll update the CSR accordingly once we decide on this.

I'm happy not to edit the properties files :) I'll revert that.
(Although I would have liked to edit some of the German translations.)

I fixed the typos in the CSR.

Best regards,
  Goetz

Change to javac:

--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java   
Tue Oct 10 14:39:45 2017 +0200
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java   
Mon Nov 20 12:19:49 2017 +0100
@@ -360,7 +360,7 @@
 },
 
 // Note: -h is already taken for "native header output directory".
-HELP("-? --help", "opt.help", STANDARD, INFO) {
+HELP("-? --help -help", "opt.help", STANDARD, INFO) {
 @Override
 public void process(OptionHelper helper, String option) throws 
InvalidValueException {
 Log log = helper.getLog();






> -Original Message-
> From: Jonathan Gibbons [mailto:jonathan.gibb...@oracle.com]
> Sent: Freitag, 17. November 2017 19:30
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; core-libs-
> d...@openjdk.java.net; 'compiler-...@openjdk.java.net'  d...@openjdk.java.net>; serviceability-dev (serviceability-
> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> Subject: Re: RFR: 8189102: All tools should support -?, -h and --help
> 
> Goetz,
> 
> I understand why you might want to ensure that a basic set of help options is
> supported,
> but I don't understand why that justifies removing older options, like "-help"
> for many tools.
> 
> In addition, I notice the CSR says:
> 
> 
> 
>   Compatibility Risk Description:
> <https://bugs.openjdk.java.net/browse/JDK-8191477#> Only new flags are
> added, none removed.
> 
> 
> 
> But that is not true, since your edits for javac and javadoc remove the option
> completely.
> 
> Also, in the CSR, look for these typos:
> serveral
> deperecation
> OpenJdk (should be OpenJDK)
> 
> 
> Also, I note that you've changed localized resource files. The usual procedure
> is to never
> touch those files, since they get updated later by Oracle's localization team.
> 
> -- Jon
> 
> 
> On 11/17/2017 03:23 AM, Lindenmaier, Goetz wrote:
> 
> 
>   Hi,
> 
>   please review this change. I also filed a CSR for this:
>   http://cr.openjdk.java.net/~goetz/wr17/8189102-
> helpMessage/webrev.02/
>   Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
>   CSR: https://bugs.openjdk.java.net/browse/JDK-8191477
> 
>   See the webrev for a detailed description of the changes.
> 
>   If required, I'll make break-out changes to be reviewed separately.
> 
>   I had posted a RFR before, but improved the change to
>   give a more complete overview of currently supported flags
>   for the CSR:
>   http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-
> October/028615.html
> 
>   Best regards,
> Goetz.
> 
> 

RFR: 8189102: All tools should support -?, -h and --help

[Lindenmaier, Goetz]

Hi,

please review this change. I also filed a CSR for this:
http://cr.openjdk.java.net/~goetz/wr17/8189102-helpMessage/webrev.02/
Bug: https://bugs.openjdk.java.net/browse/JDK-8189102
CSR: https://bugs.openjdk.java.net/browse/JDK-8191477

See the webrev for a detailed description of the changes.

If required, I'll make break-out changes to be reviewed separately.

I had posted a RFR before, but improved the change to 
give a more complete overview of currently supported flags
for the CSR:
http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-October/028615.html

Best regards,
  Goetz.

RE: RFR(S): [testbug] add @requires vm.cds to CDS tests in jdk test suite

[Lindenmaier, Goetz]

Hi David, 

thanks for looking at my change!

> Should JDK-8185436 have made the changes to TEST.ROOT? I don't
> understand all the changes that have been added there. Did JDK-8185436
> make VMProps.java dependent on WhitBox API but not provide a means to
> actually build VMProps properly??
8185436 did the changes for the hotspot tests. With this change I want to 
exclude tests in the jdk test suite. When I did 8185436 there was no need
to add these lines in the jdk test suite (as now I will not add it in jaxp/test 
etc.)
because the @requires in the jdk/test suite did not yet use anything from 
VMProps.java.

When I did 8185436 I was asked by Mikhailo Seledtsov to use the @requires 
functionality.
http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-July/024072.html

As I understand, the three lines I added to TEST.ROOT, which are just copied 
from 
hotspot/test/TEST.ROOT, tell jtreg how to compile VMProps.java which is needed
to evaluate the @requires statements. 

> I think the TEST.ROOT change may need wider review than serviceability-dev.
Where should I post it to?

Best regards,
  Goetz.


> 
> Thanks,
> David
> 
> > Best regards,
> >   Goetz.
> >

RFR(S): [testbug] add @requires vm.cds to CDS tests in jdk test suite

[Lindenmaier, Goetz]

Hi,

Could I please get a review for this small fix to the tests?
http://cr.openjdk.java.net/~goetz/wr17/8186719-cdsRequires/webrev.01/

I introduces property @requires vm.cds in the hotspot test suite, and 
now identified three tests in the jdk suite that require the same.

Best regards,
 Goetz.

Re: RFR(XS): 8185112: [TESTBUG] Servicability tests cannot parse float if non US locale.

[Lindenmaier, Goetz]

Hi David,

Thanks for reviewing and sponsoring!

Best, Götz 

> Am 21.08.2017 um 04:00 schrieb David Holmes <david.hol...@oracle.com>:
> 
> Hi Goetz,
> 
>> On 18/08/2017 4:08 PM, Lindenmaier, Goetz wrote:
>> Hi,
>> Thanks Volker!
>> Could I please get a second review? I also need a sponsor please.
>> http://cr.openjdk.java.net/~goetz/wr17/8185112-macLocale/webrev.02/
> 
> This seems fine to me and I can sponsor it. But as Arno is the contributor 
> wouldn't you also be a reviewer? ;-) I'll add you anyway.
> 
> Cheers,
> David
> 
>> Thanks,
>>   Goetz.
>>> -Original Message-
>>> From: Volker Simonis [mailto:volker.simo...@gmail.com]
>>> Sent: Donnerstag, 17. August 2017 19:33
>>> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
>>> Cc: serviceability-dev (serviceability-dev@openjdk.java.net) 
>>> >> d...@openjdk.java.net>; Zeller, Arno <arno.zel...@sap.com>
>>> Subject: Re: RFR(XS): 8185112: [TESTBUG] Servicability tests cannot parse 
>>> float
>>> if non US locale.
>>> 
>>> Thanks Goetz - looks good now!
>>> 
>>> And sorry for the delay :)
>>> Volker
>>> 
>>> 
>>> On Thu, Aug 3, 2017 at 11:30 AM, Lindenmaier, Goetz
>>> <goetz.lindenma...@sap.com> wrote:
>>>> Hi Volker,
>>>> 
>>>>> OK, I don't want to unnecessarily block this change but IMO if we
>>>>> don't need the integer parsing function at all we should remove it or
>>>>> otherwise change it to use NumberFormat as well.
>>>> We need the integer parsing function.  But the intergers parsed
>>>> are not printed with formatting.  Just plain 123456. So I don't see
>>>> how the locale will interfere.
>>>> But I changed it anyways (took a while because the tests didn't run
>>>> nightly):
>>>> http://cr.openjdk.java.net/~goetz/wr17/8185112-macLocale/webrev.02/
>>>> 
>>>> Best regards,
>>>>   Goetz.
>>>> 
>>>>> -Original Message-----
>>>>> From: Volker Simonis [mailto:volker.simo...@gmail.com]
>>>>> Sent: Freitag, 28. Juli 2017 16:45
>>>>> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
>>>>> Cc: serviceability-dev (serviceability-dev@openjdk.java.net) 
>>>>> >>>> d...@openjdk.java.net>; Zeller, Arno <arno.zel...@sap.com>
>>>>> Subject: Re: RFR(XS): 8185112: [TESTBUG] Servicability tests cannot parse
>>>>> float if non US locale.
>>>>> 
>>>>> On Fri, Jul 28, 2017 at 9:30 AM, Lindenmaier, Goetz
>>>>> <goetz.lindenma...@sap.com> wrote:
>>>>>> Hi Volker,
>>>>>> 
>>>>>> thanks for looking at this change!
>>>>>> 
>>>>>>> Looks good, but don't we also need this for getIntValue() as well?
>>>>>> This class is a helper class for testing jstat. To my
>>>>>> knowledge jstat never formats integers, so the
>>>>>> current parsing should cover all possible outputs
>>>>>> to be tested.
>>>>>> 
>>>>> 
>>>>> OK, I don't want to unnecessarily block this change but IMO if we
>>>>> don't need the integer parsing function at all we should remove it or
>>>>> otherwise change it to use NumberFormat as well.
>>>>> 
>>>>> Regards,
>>>>> Volker
>>>>> 
>>>>>> Best regards,
>>>>>>   Goetz.
>>>>>> 
>>>>>>> -Original Message-
>>>>>>> From: Volker Simonis [mailto:volker.simo...@gmail.com]
>>>>>>> Sent: Thursday, July 27, 2017 11:49 AM
>>>>>>> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
>>>>>>> Cc: serviceability-dev (serviceability-dev@openjdk.java.net)
>>>>> >>>>>> d...@openjdk.java.net>; Zeller, Arno <arno.zel...@sap.com>
>>>>>>> Subject: Re: RFR(XS): 8185112: [TESTBUG] Servicability tests cannot 
>>>>>>> parse
>>>>>>> float if non US locale.
>>>>>>> 
>>>>>>> Looks good, but don't we also need this for getIntValue() as well?
>>>>>>> I.e. can't an integer be "1.234.678" (German style) as well as
>>>>>>> "1,234,678" (American style) for example ?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Volker
>>>>>>> 
>>>>>>> On Mon, Jul 24, 2017 at 9:07 AM, Lindenmaier, Goetz
>>>>>>> <goetz.lindenma...@sap.com> wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Some tests use Float.valueOf for String to float converting. If an 
>>>>>>>> other
>>>>>>>> locale than US is used the test failed. We observed this on Mac.
>>>>>>>> Changed to use NumberFormat to work with all locales.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Please review this change. I please need a sponsor.
>>>>>>>> 
>>>>>>>> http://cr.openjdk.java.net/~goetz/wr17/8185112-
>>>>> macLocale/webrev.01/
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Best regards,
>>>>>>>> 
>>>>>>>>   Goetz

RE: RFR(XS): 8185112: [TESTBUG] Servicability tests cannot parse float if non US locale.

[Lindenmaier, Goetz]

Hi,

Thanks Volker!
Could I please get a second review? I also need a sponsor please.
http://cr.openjdk.java.net/~goetz/wr17/8185112-macLocale/webrev.02/

Thanks,
  Goetz.

> -Original Message-
> From: Volker Simonis [mailto:volker.simo...@gmail.com]
> Sent: Donnerstag, 17. August 2017 19:33
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
> Cc: serviceability-dev (serviceability-dev@openjdk.java.net)  d...@openjdk.java.net>; Zeller, Arno <arno.zel...@sap.com>
> Subject: Re: RFR(XS): 8185112: [TESTBUG] Servicability tests cannot parse 
> float
> if non US locale.
> 
> Thanks Goetz - looks good now!
> 
> And sorry for the delay :)
> Volker
> 
> 
> On Thu, Aug 3, 2017 at 11:30 AM, Lindenmaier, Goetz
> <goetz.lindenma...@sap.com> wrote:
> > Hi Volker,
> >
> >> OK, I don't want to unnecessarily block this change but IMO if we
> >> don't need the integer parsing function at all we should remove it or
> >> otherwise change it to use NumberFormat as well.
> > We need the integer parsing function.  But the intergers parsed
> > are not printed with formatting.  Just plain 123456. So I don't see
> > how the locale will interfere.
> > But I changed it anyways (took a while because the tests didn't run
> > nightly):
> > http://cr.openjdk.java.net/~goetz/wr17/8185112-macLocale/webrev.02/
> >
> > Best regards,
> >   Goetz.
> >
> >> -Original Message-
> >> From: Volker Simonis [mailto:volker.simo...@gmail.com]
> >> Sent: Freitag, 28. Juli 2017 16:45
> >> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
> >> Cc: serviceability-dev (serviceability-dev@openjdk.java.net) 
> >>  >> d...@openjdk.java.net>; Zeller, Arno <arno.zel...@sap.com>
> >> Subject: Re: RFR(XS): 8185112: [TESTBUG] Servicability tests cannot parse
> >> float if non US locale.
> >>
> >> On Fri, Jul 28, 2017 at 9:30 AM, Lindenmaier, Goetz
> >> <goetz.lindenma...@sap.com> wrote:
> >> > Hi Volker,
> >> >
> >> > thanks for looking at this change!
> >> >
> >> >> Looks good, but don't we also need this for getIntValue() as well?
> >> > This class is a helper class for testing jstat. To my
> >> > knowledge jstat never formats integers, so the
> >> > current parsing should cover all possible outputs
> >> > to be tested.
> >> >
> >>
> >> OK, I don't want to unnecessarily block this change but IMO if we
> >> don't need the integer parsing function at all we should remove it or
> >> otherwise change it to use NumberFormat as well.
> >>
> >> Regards,
> >> Volker
> >>
> >> > Best regards,
> >> >   Goetz.
> >> >
> >> >> -Original Message-
> >> >> From: Volker Simonis [mailto:volker.simo...@gmail.com]
> >> >> Sent: Thursday, July 27, 2017 11:49 AM
> >> >> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
> >> >> Cc: serviceability-dev (serviceability-dev@openjdk.java.net)
> >>  >> >> d...@openjdk.java.net>; Zeller, Arno <arno.zel...@sap.com>
> >> >> Subject: Re: RFR(XS): 8185112: [TESTBUG] Servicability tests cannot 
> >> >> parse
> >> >> float if non US locale.
> >> >>
> >> >> Looks good, but don't we also need this for getIntValue() as well?
> >> >> I.e. can't an integer be "1.234.678" (German style) as well as
> >> >> "1,234,678" (American style) for example ?
> >> >>
> >> >> Thanks,
> >> >> Volker
> >> >>
> >> >> On Mon, Jul 24, 2017 at 9:07 AM, Lindenmaier, Goetz
> >> >> <goetz.lindenma...@sap.com> wrote:
> >> >> > Hi,
> >> >> >
> >> >> >
> >> >> >
> >> >> > Some tests use Float.valueOf for String to float converting. If an 
> >> >> > other
> >> >> > locale than US is used the test failed. We observed this on Mac.
> >> >> > Changed to use NumberFormat to work with all locales.
> >> >> >
> >> >> >
> >> >> >
> >> >> > Please review this change. I please need a sponsor.
> >> >> >
> >> >> > http://cr.openjdk.java.net/~goetz/wr17/8185112-
> >> macLocale/webrev.01/
> >> >> >
> >> >> >
> >> >> >
> >> >> > Best regards,
> >> >> >
> >> >> >   Goetz

RE: RFR(XS): 8185112: [TESTBUG] Servicability tests cannot parse float if non US locale.

[Lindenmaier, Goetz]

Hi Volker, 

> OK, I don't want to unnecessarily block this change but IMO if we
> don't need the integer parsing function at all we should remove it or
> otherwise change it to use NumberFormat as well.
We need the integer parsing function.  But the intergers parsed 
are not printed with formatting.  Just plain 123456. So I don't see
how the locale will interfere.
But I changed it anyways (took a while because the tests didn't run
nightly):
http://cr.openjdk.java.net/~goetz/wr17/8185112-macLocale/webrev.02/

Best regards,
  Goetz.

> -Original Message-
> From: Volker Simonis [mailto:volker.simo...@gmail.com]
> Sent: Freitag, 28. Juli 2017 16:45
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
> Cc: serviceability-dev (serviceability-dev@openjdk.java.net)  d...@openjdk.java.net>; Zeller, Arno <arno.zel...@sap.com>
> Subject: Re: RFR(XS): 8185112: [TESTBUG] Servicability tests cannot parse
> float if non US locale.
> 
> On Fri, Jul 28, 2017 at 9:30 AM, Lindenmaier, Goetz
> <goetz.lindenma...@sap.com> wrote:
> > Hi Volker,
> >
> > thanks for looking at this change!
> >
> >> Looks good, but don't we also need this for getIntValue() as well?
> > This class is a helper class for testing jstat. To my
> > knowledge jstat never formats integers, so the
> > current parsing should cover all possible outputs
> > to be tested.
> >
> 
> OK, I don't want to unnecessarily block this change but IMO if we
> don't need the integer parsing function at all we should remove it or
> otherwise change it to use NumberFormat as well.
> 
> Regards,
> Volker
> 
> > Best regards,
> >   Goetz.
> >
> >> -Original Message-
> >> From: Volker Simonis [mailto:volker.simo...@gmail.com]
> >> Sent: Thursday, July 27, 2017 11:49 AM
> >> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
> >> Cc: serviceability-dev (serviceability-dev@openjdk.java.net)
>  >> d...@openjdk.java.net>; Zeller, Arno <arno.zel...@sap.com>
> >> Subject: Re: RFR(XS): 8185112: [TESTBUG] Servicability tests cannot parse
> >> float if non US locale.
> >>
> >> Looks good, but don't we also need this for getIntValue() as well?
> >> I.e. can't an integer be "1.234.678" (German style) as well as
> >> "1,234,678" (American style) for example ?
> >>
> >> Thanks,
> >> Volker
> >>
> >> On Mon, Jul 24, 2017 at 9:07 AM, Lindenmaier, Goetz
> >> <goetz.lindenma...@sap.com> wrote:
> >> > Hi,
> >> >
> >> >
> >> >
> >> > Some tests use Float.valueOf for String to float converting. If an other
> >> > locale than US is used the test failed. We observed this on Mac.
> >> > Changed to use NumberFormat to work with all locales.
> >> >
> >> >
> >> >
> >> > Please review this change. I please need a sponsor.
> >> >
> >> > http://cr.openjdk.java.net/~goetz/wr17/8185112-
> macLocale/webrev.01/
> >> >
> >> >
> >> >
> >> > Best regards,
> >> >
> >> >   Goetz

RE: RFR(XS): 8185112: [TESTBUG] Servicability tests cannot parse float if non US locale.

[Lindenmaier, Goetz]

Hi Volker, 

thanks for looking at this change!

> Looks good, but don't we also need this for getIntValue() as well?
This class is a helper class for testing jstat. To my
knowledge jstat never formats integers, so the 
current parsing should cover all possible outputs
to be tested. 

Best regards,
  Goetz. 

> -Original Message-
> From: Volker Simonis [mailto:volker.simo...@gmail.com]
> Sent: Thursday, July 27, 2017 11:49 AM
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>
> Cc: serviceability-dev (serviceability-dev@openjdk.java.net)  d...@openjdk.java.net>; Zeller, Arno <arno.zel...@sap.com>
> Subject: Re: RFR(XS): 8185112: [TESTBUG] Servicability tests cannot parse
> float if non US locale.
> 
> Looks good, but don't we also need this for getIntValue() as well?
> I.e. can't an integer be "1.234.678" (German style) as well as
> "1,234,678" (American style) for example ?
> 
> Thanks,
> Volker
> 
> On Mon, Jul 24, 2017 at 9:07 AM, Lindenmaier, Goetz
> <goetz.lindenma...@sap.com> wrote:
> > Hi,
> >
> >
> >
> > Some tests use Float.valueOf for String to float converting. If an other
> > locale than US is used the test failed. We observed this on Mac.
> > Changed to use NumberFormat to work with all locales.
> >
> >
> >
> > Please review this change. I please need a sponsor.
> >
> > http://cr.openjdk.java.net/~goetz/wr17/8185112-macLocale/webrev.01/
> >
> >
> >
> > Best regards,
> >
> >   Goetz

RFR(XS): 8185112: [TESTBUG] Servicability tests cannot parse float if non US locale.

[Lindenmaier, Goetz]

Hi,

Some tests use Float.valueOf for String to float converting. If an other locale 
than US is used the test failed. We observed this on Mac.
Changed to use NumberFormat to work with all locales.

Please review this change. I please need a sponsor.
http://cr.openjdk.java.net/~goetz/wr17/8185112-macLocale/webrev.01/

Best regards,
  Goetz

Wrong merge after 8169232: SA: TestCpoolForInvokeDynamic.java fails with ...

[Lindenmaier, Goetz]

Hi,

I think this merge
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a28955e16c78
wrongly added
+ * @ignore 8169232
to
   TestCpoolForInvokeDynamic.java
which was fixed in
  8169232: SA: TestCpoolForInvokeDynamic.java fails with 
sun.jvm.hotspot.debugger.DebuggerException: binary search bug: should have 
found entry 1
   http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/13e6043fcdcb

Best regards,
  Goetz

RE: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

[Lindenmaier, Goetz]

Hi, 

I'm sorry for that. Our solaris builds were fine.
I saw the fix. Thanks Erik for fixing!  I thought
windows was the last platform not to support
declarations in the code.
Do you mind sharing what compiler choked on this?
Maybe we can setup our build accordingly.

And, is there a wiki page that describes which 
files are owned by which mailing list, and to which 
repo to push the corresponding changes?  I've no
idea on the jdk side where to post etc. 

Opening up jprt will be a great step forward!

Best regards,
  Goetz.



> -Original Message-
> From: David Holmes [mailto:david.hol...@oracle.com]
> Sent: Wednesday, December 14, 2016 9:55 PM
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>;
> daniel.daughe...@oracle.com; 'Dmitry Samersoff'
> <dmitry.samers...@oracle.com>; Java Core Libs  d...@openjdk.java.net>; serviceability-dev (serviceability-
> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty
> coding.
> 
> Hi Goetz,
> 
> On 14/12/2016 9:46 PM, Lindenmaier, Goetz wrote:
> >
> >> object to the change to k_standard.c for the same reason.
> > Ok, I remove that too.
> 
> I had not realized this was to be pushed directly to jdk9/dev. It broke
> builds on Solaris and so was obviously not tested.
> 
> David
> 
> > Best regards,
> >   Goetz.
> >
> >> -Original Message-----
> >> From: David Holmes [mailto:david.hol...@oracle.com]
> >> Sent: Mittwoch, 14. Dezember 2016 12:29
> >> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>;
> >> daniel.daughe...@oracle.com; 'Dmitry Samersoff'
> >> <dmitry.samers...@oracle.com>; Java Core Libs  >> d...@openjdk.java.net>; serviceability-dev (serviceability-
> >> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty
> >> coding.
> >>
> >> On 14/12/2016 9:00 PM, Lindenmaier, Goetz wrote:
> >>> Hi,
> >>>
> >>> You're right, I had removed the change to e_asin.c.
> >>
> >> You only pointed Joe to that file AFAICS. I would expect he would also
> >> object to the change to k_standard.c for the same reason.
> >>
> >>> New webrev anyways:
> >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-
> corlib_s11y/webrev.05/
> >>>
> >>> java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing.
> >>
> >> Okay. Thanks.
> >>
> >> David
> >>
> >>> Best regards,
> >>>   Goetz.
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: David Holmes [mailto:david.hol...@oracle.com]
> >>>> Sent: Mittwoch, 14. Dezember 2016 11:42
> >>>> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>;
> >>>> daniel.daughe...@oracle.com; 'Dmitry Samersoff'
> >>>> <dmitry.samers...@oracle.com>; Java Core Libs  >>>> d...@openjdk.java.net>; serviceability-dev (serviceability-
> >>>> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and
> servicabilty
> >>>> coding.
> >>>>
> >>>> On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote:
> >>>>> Hi David,
> >>>>>
> >>>>> I found "8169317: [s390] Various minor bug fixes and adaptions."
> >>>>> in jdk9/dev this morning, so I thought it has been promoted based
> >>>>> on some older change. I waited for that quite a while because tests
> >>>>> in jdk9/dev kept failing on s390.
> >>>>> How can I get the information when what was promoted? This always
> >>>>> is a wild guess for me ... as well as when what will be promoted :)
> >>>>
> >>>> Yeah there's no notification in the bug report of when hs pushes up to
> >>>> dev. The changeset email is the only record of exactly when it happens.
> >>>>
> >>>>> Do you think the promotion will happen tonight, or will it take
> >>>>> another week?
> >>>>
> >>>> hs goes through Pre-Integration Testing (PIT) before it is pushed to
> >>>> dev. There have been delays in getting that started and so a delay in it
> >>>> finishing and being analyzed. It may still be a couple of days.
> >>>>
> >>>>

RE: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

[Lindenmaier, Goetz]

> object to the change to k_standard.c for the same reason.
Ok, I remove that too.

Best regards,
  Goetz.

> -Original Message-
> From: David Holmes [mailto:david.hol...@oracle.com]
> Sent: Mittwoch, 14. Dezember 2016 12:29
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>;
> daniel.daughe...@oracle.com; 'Dmitry Samersoff'
> <dmitry.samers...@oracle.com>; Java Core Libs  d...@openjdk.java.net>; serviceability-dev (serviceability-
> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty
> coding.
> 
> On 14/12/2016 9:00 PM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > You're right, I had removed the change to e_asin.c.
> 
> You only pointed Joe to that file AFAICS. I would expect he would also
> object to the change to k_standard.c for the same reason.
> 
> > New webrev anyways:
> > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.05/
> >
> > java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing.
> 
> Okay. Thanks.
> 
> David
> 
> > Best regards,
> >   Goetz.
> >
> >
> >> -Original Message-
> >> From: David Holmes [mailto:david.hol...@oracle.com]
> >> Sent: Mittwoch, 14. Dezember 2016 11:42
> >> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>;
> >> daniel.daughe...@oracle.com; 'Dmitry Samersoff'
> >> <dmitry.samers...@oracle.com>; Java Core Libs  >> d...@openjdk.java.net>; serviceability-dev (serviceability-
> >> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty
> >> coding.
> >>
> >> On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote:
> >>> Hi David,
> >>>
> >>> I found "8169317: [s390] Various minor bug fixes and adaptions."
> >>> in jdk9/dev this morning, so I thought it has been promoted based
> >>> on some older change. I waited for that quite a while because tests
> >>> in jdk9/dev kept failing on s390.
> >>> How can I get the information when what was promoted? This always
> >>> is a wild guess for me ... as well as when what will be promoted :)
> >>
> >> Yeah there's no notification in the bug report of when hs pushes up to
> >> dev. The changeset email is the only record of exactly when it happens.
> >>
> >>> Do you think the promotion will happen tonight, or will it take
> >>> another week?
> >>
> >> hs goes through Pre-Integration Testing (PIT) before it is pushed to
> >> dev. There have been delays in getting that started and so a delay in it
> >> finishing and being analyzed. It may still be a couple of days.
> >>
> >>> I removed
> >>> -JLI_StrLen(jrepath) + JLI_StrLen(arch) + 
> >>> JLI_StrLen("/lib//jli:")
> +
> >>> +JLI_StrLen(jrepath) + JLI_StrLen(arch) + 
> >>> JLI_StrLen("/lib/jli:") +
> >>> from
> >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/
> >>
> >> With that gone that file only has the jvmpath rename - which isn't
> >> fixing anything.
> >>
> >> Joe also asked for the fdlibm changes to dropped.
> >>
> >> Thanks,
> >> David
> >>
> >>> Best regards,
> >>>   Goetz.
> >>>
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: David Holmes [mailto:david.hol...@oracle.com]
> >>>> Sent: Mittwoch, 14. Dezember 2016 11:04
> >>>> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>;
> >>>> daniel.daughe...@oracle.com; 'Dmitry Samersoff'
> >>>> <dmitry.samers...@oracle.com>; Java Core Libs  >>>> d...@openjdk.java.net>; serviceability-dev (serviceability-
> >>>> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and 
> >>>> servicabilty
> >>>> coding.
> >>>>
> >>>> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote:
> >>>>> Hi,
> >>>>>
> >>>>> 8066474 has not been promoted.
> >>>>
> >>>> hs has not been able to push up to dev yet.
> >>>>
> >>>>> I'll remove the strlen // fix for aix from thi

RE: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

[Lindenmaier, Goetz]

Hi,

You're right, I had removed the change to e_asin.c.
New webrev anyways:
http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.05/

java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing.

Best regards,
  Goetz.


> -Original Message-
> From: David Holmes [mailto:david.hol...@oracle.com]
> Sent: Mittwoch, 14. Dezember 2016 11:42
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>;
> daniel.daughe...@oracle.com; 'Dmitry Samersoff'
> <dmitry.samers...@oracle.com>; Java Core Libs  d...@openjdk.java.net>; serviceability-dev (serviceability-
> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty
> coding.
> 
> On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote:
> > Hi David,
> >
> > I found "8169317: [s390] Various minor bug fixes and adaptions."
> > in jdk9/dev this morning, so I thought it has been promoted based
> > on some older change. I waited for that quite a while because tests
> > in jdk9/dev kept failing on s390.
> > How can I get the information when what was promoted? This always
> > is a wild guess for me ... as well as when what will be promoted :)
> 
> Yeah there's no notification in the bug report of when hs pushes up to
> dev. The changeset email is the only record of exactly when it happens.
> 
> > Do you think the promotion will happen tonight, or will it take
> > another week?
> 
> hs goes through Pre-Integration Testing (PIT) before it is pushed to
> dev. There have been delays in getting that started and so a delay in it
> finishing and being analyzed. It may still be a couple of days.
> 
> > I removed
> > -JLI_StrLen(jrepath) + JLI_StrLen(arch) + 
> > JLI_StrLen("/lib//jli:") +
> > +JLI_StrLen(jrepath) + JLI_StrLen(arch) + 
> > JLI_StrLen("/lib/jli:") +
> > from
> > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/
> 
> With that gone that file only has the jvmpath rename - which isn't
> fixing anything.
> 
> Joe also asked for the fdlibm changes to dropped.
> 
> Thanks,
> David
> 
> > Best regards,
> >   Goetz.
> >
> >
> >
> >> -Original Message-
> >> From: David Holmes [mailto:david.hol...@oracle.com]
> >> Sent: Mittwoch, 14. Dezember 2016 11:04
> >> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>;
> >> daniel.daughe...@oracle.com; 'Dmitry Samersoff'
> >> <dmitry.samers...@oracle.com>; Java Core Libs  >> d...@openjdk.java.net>; serviceability-dev (serviceability-
> >> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty
> >> coding.
> >>
> >> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote:
> >>> Hi,
> >>>
> >>> 8066474 has not been promoted.
> >>
> >> hs has not been able to push up to dev yet.
> >>
> >>> I'll remove the strlen // fix for aix from this change and
> >>> push it without it. I'd like to get this done.
> >>
> >> I've lost track of what is now left in this set of changes ??
> >>
> >> David
> >>
> >>> Best regards,
> >>>   Goetz.
> >>>
> >>>> -Original Message-
> >>>> From: David Holmes [mailto:david.hol...@oracle.com]
> >>>> Sent: Donnerstag, 8. Dezember 2016 23:03
> >>>> To: daniel.daughe...@oracle.com; Lindenmaier, Goetz
> >>>> <goetz.lindenma...@sap.com>; 'Dmitry Samersoff'
> >>>> <dmitry.samers...@oracle.com>; Java Core Libs  >>>> d...@openjdk.java.net>; serviceability-dev (serviceability-
> >>>> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and 
> >>>> servicabilty
> >>>> coding.
> >>>>
> >>>> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote:
> >>>>> On 12/8/16 1:59 PM, David Holmes wrote:
> >>>>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote:
> >>>>>>> Hi David,
> >>>>>>>
> >>>>>>> thanks for looking at the change.  New webrev:
> >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-
> corlib_s11y/webrev.04/
> >>>>>>>
> >>>>>>>> src/java.base/share/native/libj

RE: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

[Lindenmaier, Goetz]

Hi David, 

I found "8169317: [s390] Various minor bug fixes and adaptions." 
in jdk9/dev this morning, so I thought it has been promoted based
on some older change. I waited for that quite a while because tests
in jdk9/dev kept failing on s390.
How can I get the information when what was promoted? This always 
is a wild guess for me ... as well as when what will be promoted :)
Do you think the promotion will happen tonight, or will it take 
another week?

I removed 
-JLI_StrLen(jrepath) + JLI_StrLen(arch) + 
JLI_StrLen("/lib//jli:") +
+JLI_StrLen(jrepath) + JLI_StrLen(arch) + 
JLI_StrLen("/lib/jli:") +
from 
http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/

Best regards,
  Goetz.



> -Original Message-
> From: David Holmes [mailto:david.hol...@oracle.com]
> Sent: Mittwoch, 14. Dezember 2016 11:04
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>;
> daniel.daughe...@oracle.com; 'Dmitry Samersoff'
> <dmitry.samers...@oracle.com>; Java Core Libs  d...@openjdk.java.net>; serviceability-dev (serviceability-
> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty
> coding.
> 
> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > 8066474 has not been promoted.
> 
> hs has not been able to push up to dev yet.
> 
> > I'll remove the strlen // fix for aix from this change and
> > push it without it. I'd like to get this done.
> 
> I've lost track of what is now left in this set of changes ??
> 
> David
> 
> > Best regards,
> >   Goetz.
> >
> >> -----Original Message-
> >> From: David Holmes [mailto:david.hol...@oracle.com]
> >> Sent: Donnerstag, 8. Dezember 2016 23:03
> >> To: daniel.daughe...@oracle.com; Lindenmaier, Goetz
> >> <goetz.lindenma...@sap.com>; 'Dmitry Samersoff'
> >> <dmitry.samers...@oracle.com>; Java Core Libs  >> d...@openjdk.java.net>; serviceability-dev (serviceability-
> >> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty
> >> coding.
> >>
> >> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote:
> >>> On 12/8/16 1:59 PM, David Holmes wrote:
> >>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote:
> >>>>> Hi David,
> >>>>>
> >>>>> thanks for looking at the change.  New webrev:
> >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/
> >>>>>
> >>>>>> src/java.base/share/native/libjli/java.c
> >>>>>> As far as I can see the existing code is working perfectly fine.
> >>>>> Ah, thanks for the explanation, now I got it!  Removed.
> >>>>>
> >>>>>> Again I'm not sure what the bug is here. On AIX the output string is
> >>>>>> expanded with:
> >>>>>> "%s/lib/%s/jli:"
> >>>>> I first edited this against jdk9/hs, where the arch is gone since
> >>>>> 8066474,
> >>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc
> >>>>> but the // was not adapted. Then I moved the change to jdk9/dev
> because
> >>>>> I thought I have to push it there. And yes, in that coding // would
> >>>>> be correct.
> >>>>> So I have to wait until hs is promoted ...
> >>>>
> >>>> So just based on the current file, the change proposed - to remove one
> >>>> / - is not correct until the arch directory is removed.
> >>>
> >>> That change is already in JDK9-hs:
> >>>
> >>> Changeset: c14f9a7b4cab
> >>> Author:erikj
> >>> Date:  2016-12-05 17:55 +0100
> >>> URL:   http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab
> >>>
> >>> 8066474: Remove the lib/ directory from Linux and Solaris images
> >>> Reviewed-by: tbell, ihse
> >>>
> >>> along with changesets in the jdk and hotspot repos along with a few
> >>> closed repos.
> >>
> >> Thanks Dan. So we need to see a webrev based on latest hs code - where
> >> removing the extra / would be correct.
> >>
> >> David
> >> -
> >>
> >>> Dan
> >>>
> >>>
> >>>
> >>>>
> >>>> David
> >

RE: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

[Lindenmaier, Goetz]

Hi, 

8066474 has not been promoted.
I'll remove the strlen // fix for aix from this change and 
push it without it. I'd like to get this done.

Best regards,
  Goetz.

> -Original Message-
> From: David Holmes [mailto:david.hol...@oracle.com]
> Sent: Donnerstag, 8. Dezember 2016 23:03
> To: daniel.daughe...@oracle.com; Lindenmaier, Goetz
> <goetz.lindenma...@sap.com>; 'Dmitry Samersoff'
> <dmitry.samers...@oracle.com>; Java Core Libs  d...@openjdk.java.net>; serviceability-dev (serviceability-
> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty
> coding.
> 
> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote:
> > On 12/8/16 1:59 PM, David Holmes wrote:
> >> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote:
> >>> Hi David,
> >>>
> >>> thanks for looking at the change.  New webrev:
> >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/
> >>>
> >>>> src/java.base/share/native/libjli/java.c
> >>>> As far as I can see the existing code is working perfectly fine.
> >>> Ah, thanks for the explanation, now I got it!  Removed.
> >>>
> >>>> Again I'm not sure what the bug is here. On AIX the output string is
> >>>> expanded with:
> >>>> "%s/lib/%s/jli:"
> >>> I first edited this against jdk9/hs, where the arch is gone since
> >>> 8066474,
> >>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc
> >>> but the // was not adapted. Then I moved the change to jdk9/dev because
> >>> I thought I have to push it there. And yes, in that coding // would
> >>> be correct.
> >>> So I have to wait until hs is promoted ...
> >>
> >> So just based on the current file, the change proposed - to remove one
> >> / - is not correct until the arch directory is removed.
> >
> > That change is already in JDK9-hs:
> >
> > Changeset: c14f9a7b4cab
> > Author:erikj
> > Date:  2016-12-05 17:55 +0100
> > URL:   http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab
> >
> > 8066474: Remove the lib/ directory from Linux and Solaris images
> > Reviewed-by: tbell, ihse
> >
> > along with changesets in the jdk and hotspot repos along with a few
> > closed repos.
> 
> Thanks Dan. So we need to see a webrev based on latest hs code - where
> removing the extra / would be correct.
> 
> David
> -
> 
> > Dan
> >
> >
> >
> >>
> >> David
> >> -
> >>
> >>>> The jvmpath -> jvm_newpath change wasn't really necessary - a
> >>>> comment on
> >>>> the strdup would have sufficed IMO.
> >>> Dmitry asked me to add it.  But I think it's ok.
> >>>
> >>> Can I consider this reviewed now?  I.e. could I push it once 8066474 is
> >>> promoted and Joe Darcy agreed?
> >>>
> >>> Best regards,
> >>>   Goetz.
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: David Holmes [mailto:david.hol...@oracle.com]
> >>>> Sent: Donnerstag, 8. Dezember 2016 09:14
> >>>> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; 'Dmitry
> Samersoff'
> >>>> <dmitry.samers...@oracle.com>; Java Core Libs  >>>> d...@openjdk.java.net>; serviceability-dev (serviceability-
> >>>> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and
> >>>> servicabilty
> >>>> coding.
> >>>>
> >>>> Hi Goetz,
> >>>>
> >>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote:
> >>>>> Hi Dmitry,
> >>>>>
> >>>>> yes, new_jvmpath is consistent with the other variables.
> >>>>> I also merged the ifs in SDE.c.
> >>>>>
> >>>>> new webrev:
> >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/
> >>>>
> >>>> src/java.base/share/native/libjli/java.c
> >>>>
> >>>> As far as I can see the existing code is working perfectly fine.
> >>>> Given a
> >>>> jvm.cfg with:
> >>>>
> >>>> -server KNOWN
> >>>> -client IGNORE
> >>>> -myvm KNOWN
> >&

RE: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

[Lindenmaier, Goetz]

Hi,

I'll post a new webrev once the hs code has been propagated to 
dev.  

Best regards,
  Goetz.

> -Original Message-
> From: David Holmes [mailto:david.hol...@oracle.com]
> Sent: Donnerstag, 8. Dezember 2016 23:03
> To: daniel.daughe...@oracle.com; Lindenmaier, Goetz
> <goetz.lindenma...@sap.com>; 'Dmitry Samersoff'
> <dmitry.samers...@oracle.com>; Java Core Libs  d...@openjdk.java.net>; serviceability-dev (serviceability-
> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty
> coding.
> 
> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote:
> > On 12/8/16 1:59 PM, David Holmes wrote:
> >> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote:
> >>> Hi David,
> >>>
> >>> thanks for looking at the change.  New webrev:
> >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/
> >>>
> >>>> src/java.base/share/native/libjli/java.c
> >>>> As far as I can see the existing code is working perfectly fine.
> >>> Ah, thanks for the explanation, now I got it!  Removed.
> >>>
> >>>> Again I'm not sure what the bug is here. On AIX the output string is
> >>>> expanded with:
> >>>> "%s/lib/%s/jli:"
> >>> I first edited this against jdk9/hs, where the arch is gone since
> >>> 8066474,
> >>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc
> >>> but the // was not adapted. Then I moved the change to jdk9/dev because
> >>> I thought I have to push it there. And yes, in that coding // would
> >>> be correct.
> >>> So I have to wait until hs is promoted ...
> >>
> >> So just based on the current file, the change proposed - to remove one
> >> / - is not correct until the arch directory is removed.
> >
> > That change is already in JDK9-hs:
> >
> > Changeset: c14f9a7b4cab
> > Author:erikj
> > Date:  2016-12-05 17:55 +0100
> > URL:   http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab
> >
> > 8066474: Remove the lib/ directory from Linux and Solaris images
> > Reviewed-by: tbell, ihse
> >
> > along with changesets in the jdk and hotspot repos along with a few
> > closed repos.
> 
> Thanks Dan. So we need to see a webrev based on latest hs code - where
> removing the extra / would be correct.
> 
> David
> -
> 
> > Dan
> >
> >
> >
> >>
> >> David
> >> -
> >>
> >>>> The jvmpath -> jvm_newpath change wasn't really necessary - a
> >>>> comment on
> >>>> the strdup would have sufficed IMO.
> >>> Dmitry asked me to add it.  But I think it's ok.
> >>>
> >>> Can I consider this reviewed now?  I.e. could I push it once 8066474 is
> >>> promoted and Joe Darcy agreed?
> >>>
> >>> Best regards,
> >>>   Goetz.
> >>>
> >>>
> >>>> -Original Message-
> >>>> From: David Holmes [mailto:david.hol...@oracle.com]
> >>>> Sent: Donnerstag, 8. Dezember 2016 09:14
> >>>> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; 'Dmitry
> Samersoff'
> >>>> <dmitry.samers...@oracle.com>; Java Core Libs  >>>> d...@openjdk.java.net>; serviceability-dev (serviceability-
> >>>> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and
> >>>> servicabilty
> >>>> coding.
> >>>>
> >>>> Hi Goetz,
> >>>>
> >>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote:
> >>>>> Hi Dmitry,
> >>>>>
> >>>>> yes, new_jvmpath is consistent with the other variables.
> >>>>> I also merged the ifs in SDE.c.
> >>>>>
> >>>>> new webrev:
> >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/
> >>>>
> >>>> src/java.base/share/native/libjli/java.c
> >>>>
> >>>> As far as I can see the existing code is working perfectly fine.
> >>>> Given a
> >>>> jvm.cfg with:
> >>>>
> >>>> -server KNOWN
> >>>> -client IGNORE
> >>>> -myvm KNOWN
> >>>> -oldvm ALIASED_TO -server
> >>>>
> >>&g

RE: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

[Lindenmaier, Goetz]

Hi David, 

thanks for looking at the change.  New webrev:
http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/

> src/java.base/share/native/libjli/java.c
> As far as I can see the existing code is working perfectly fine.
Ah, thanks for the explanation, now I got it!  Removed.

> Again I'm not sure what the bug is here. On AIX the output string is
> expanded with:
> "%s/lib/%s/jli:"
I first edited this against jdk9/hs, where the arch is gone since 8066474,
http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc
but the // was not adapted. Then I moved the change to jdk9/dev because 
I thought I have to push it there. And yes, in that coding // would be correct.
So I have to wait until hs is promoted ...

> The jvmpath -> jvm_newpath change wasn't really necessary - a comment on
> the strdup would have sufficed IMO.
Dmitry asked me to add it.  But I think it's ok.

Can I consider this reviewed now?  I.e. could I push it once 8066474 is 
promoted and Joe Darcy agreed?

Best regards,
  Goetz.


> -Original Message-
> From: David Holmes [mailto:david.hol...@oracle.com]
> Sent: Donnerstag, 8. Dezember 2016 09:14
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; 'Dmitry Samersoff'
> <dmitry.samers...@oracle.com>; Java Core Libs  d...@openjdk.java.net>; serviceability-dev (serviceability-
> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty
> coding.
> 
> Hi Goetz,
> 
> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote:
> > Hi Dmitry,
> >
> > yes, new_jvmpath is consistent with the other variables.
> > I also merged the ifs in SDE.c.
> >
> > new webrev:
> > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/
> 
> src/java.base/share/native/libjli/java.c
> 
> As far as I can see the existing code is working perfectly fine. Given a
> jvm.cfg with:
> 
> -server KNOWN
> -client IGNORE
> -myvm KNOWN
> -oldvm ALIASED_TO -server
> 
> The usage text is:
> 
>  -server   to select the "server" VM
>  -myvm to select the "myvm" VM
>  -oldvmis a synonym for the "server" VM  [deprecated]
>The default VM is server,
>because you are running on a server-class machine.
> 
> which is exactly what I would expect. Why do you think there is a bug?
> 
> ---
> 
> src/java.base/unix/native/libjli/java_md_solinux.c
> 
> Again I'm not sure what the bug is here. On AIX the output string is
> expanded with:
> 
> "%s/lib/%s/jli:"
> 
> so it needs to account for the extra "/lib//jli:" characters - and that
> is exactly what the existing code does:
> 
> + JLI_StrLen("/lib//jli:")
> 
> The jvmpath -> jvm_newpath change wasn't really necessary - a comment on
> the strdup would have sufficed IMO.
> 
> Thanks,
> David
> -
> 
> 
> 
> 
> > Best regards,
> >   Goetz.
> >
> >> -Original Message-
> >> From: Dmitry Samersoff [mailto:dmitry.samers...@oracle.com]
> >> Sent: Wednesday, December 07, 2016 2:43 PM
> >> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; Java Core Libs
> >> <core-libs-...@openjdk.java.net>; serviceability-dev (serviceability-
> >> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty
> >> coding.
> >>
> >> Goetz,
> >>
> >> SDE.c:
> >>
> >> You might combine if at ll. 260 and 263 to one but it's just matter of 
> >> test.
> >>
> >>  if (sti == baseStratumIndex || sti < 0) {
> >> return; /* Java stratum - return unchanged */
> >>  }
> >>
> >>> I'm not sure what you mean. I tried to fix it, but please
> >>> double-check the new webrev.
> >>
> >> if cnt is <= 0 loop at l.267
> >>
> >> for (; cnt-- > 0; ++fromEntry) {
> >>
> >> is never run and we effectively do
> >>
> >>  *entryCountPtr = 0;
> >>
> >> at l.283
> >>
> >> So if we you suspect that cnt may become negative or 0:
> >> (your v.01 changes)
> >>
> >>  260 if (sti < 0 && cnt > 0) {
> >>  261 return;
> >>  262 }
> >>
> >> it's better to check it early.
> >>
> >> But I'm not sure we have to care about negative/zero cnt here.
> >>
> >> -Dmitry
> &g

RE: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

[Lindenmaier, Goetz]

Ah, you're right, the 'lastslash' assignment!

Thanks,
  Goetz.

> -Original Message-
> From: David Holmes [mailto:david.hol...@oracle.com]
> Sent: Wednesday, December 07, 2016 10:32 AM
> To: Lindenmaier, Goetz <goetz.lindenma...@sap.com>; 'Dmitry Samersoff'
> <dmitry.samers...@oracle.com>; Java Core Libs  d...@openjdk.java.net>; serviceability-dev (serviceability-
> d...@openjdk.java.net) <serviceability-dev@openjdk.java.net>
> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty
> coding.
> 
> On 7/12/2016 6:37 PM, Lindenmaier, Goetz wrote:
> > Hi Dmitry,
> >
> > thanks for looking at my change!
> > Updated webrev:
> > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02
> >
> >> * src/java.base/unix/native/libjli/java_md_solinux.c
> >> Is this line correct?
> >> 519 jvmpath = JLI_StringDup(jvmpath);
> >
> > It seems pointless. Should I remove it?  (The whole file is a horror.)
> 
> Seems to me it is making a copy of the incoming char[] so that it can be
> modified in this function without affecting the original char[] in the
> caller.
> 
> David
> -
> 
> 
> >> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c
> >> It might be better to return immediately if cnt < 0,
> >> regardless of value of sti.
> >
> > I'm not sure what you mean. I tried to fix it, but please
> > double-check the new webrev.
> >
> >> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c
> >> It might be better to write
> >>   arg.l_linger = (on) ? (unsigned short)value.i : 0;
> >> and leave one copy of setsockopt() call
> >
> > Yes, looks better.
> >
> > Best regards,
> >   Goetz
> >
> >
> >>
> >> -Dmitry
> >>
> >>
> >> On 2016-12-06 16:12, Lindenmaier, Goetz wrote:
> >>> Hi,
> >>>
> >>>
> >>>
> >>> This change fixes some minor issues found in our code scans.
> >>>
> >>> I hope this correctly addresses corelib and serviceability issues.
> >>>
> >>>
> >>>
> >>> Please review:
> >>>
> >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-
> corlib_s11y/webrev.01/
> >>>
> >>>
> >>>
> >>> Best regards,
> >>>
> >>>   Goetz.
> >>>
> >>>
> >>>
> >>> Changes in detail:
> >>>
> >>>
> >>>
> >>> e_asin.c
> >>>
> >>> Code scan reports missing {}.
> >>>
> >>>
> >>> The code "if (huge+x>one) {" is only there to set the inexact flag of
> >>> the processor.
> >>> It's a way to avoid the C compiler to optimize the code away. It is
> >>> always true,
> >>> so the parenthesis of the outer else don't matter.
> >>>
> >>> Although this basically just adds the {} I would like to submit this to
> >>>
> >>> avoid anybody else spends more the 30sec on understanding these
> >>>
> >>> if statements.
> >>>
> >>>
> >>> k_standard.c
> >>>
> >>> exc.retval is returned below and thus should always be initialized.
> >>>
> >>>
> >>> imageDecompressor.cpp
> >>>
> >>> Wrong destructor is used.  Reported also by David CARLIER
> >>>
> >>>
> >>> java.c
> >>>
> >>> in line 1865 'name' was used, it should be 'alias'.
> >>>
> >>>
> >>> java_md_solinux.c
> >>>
> >>> "//" in path is useless. Further down a free is missing.
> >>>
> >>>
> >>> SDE.c
> >>>
> >>> Call to stratumTableIndex can return negative value if defaultStratumId
> >>> == null.
> >>>
> >>>
> >>> socket_md.c
> >>>
> >>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in
> >>> the macros.
> >>>
> >>>
> >>> unpack.cpp
> >>>
> >>> n.slice should not get negative argument for end, which is passed from
> >>> dollar1.
> >>> But dollar1 can get negative where it is set to the result of
> >>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1).
> >>>
> >>
> >>
> >> --
> >> Dmitry Samersoff
> >> Oracle Java development team, Saint Petersburg, Russia
> >> * I would love to change the world, but they won't give me the sources.

RE: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

[Lindenmaier, Goetz]

Hi Dmitry,

thanks for looking at my change!
Updated webrev:
http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02

> * src/java.base/unix/native/libjli/java_md_solinux.c
> Is this line correct?
> 519 jvmpath = JLI_StringDup(jvmpath);

It seems pointless. Should I remove it?  (The whole file is a horror.)
 
> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c
> It might be better to return immediately if cnt < 0,
> regardless of value of sti.

I'm not sure what you mean. I tried to fix it, but please 
double-check the new webrev.

> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c
> It might be better to write
>   arg.l_linger = (on) ? (unsigned short)value.i : 0;
> and leave one copy of setsockopt() call

Yes, looks better.

Best regards,
  Goetz


> 
> -Dmitry
> 
> 
> On 2016-12-06 16:12, Lindenmaier, Goetz wrote:
> > Hi,
> >
> >
> >
> > This change fixes some minor issues found in our code scans.
> >
> > I hope this correctly addresses corelib and serviceability issues.
> >
> >
> >
> > Please review:
> >
> > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.01/
> >
> >
> >
> > Best regards,
> >
> >   Goetz.
> >
> >
> >
> > Changes in detail:
> >
> >
> >
> > e_asin.c
> >
> > Code scan reports missing {}.
> >
> >
> > The code "if (huge+x>one) {" is only there to set the inexact flag of
> > the processor.
> > It's a way to avoid the C compiler to optimize the code away. It is
> > always true,
> > so the parenthesis of the outer else don't matter.
> >
> > Although this basically just adds the {} I would like to submit this to
> >
> > avoid anybody else spends more the 30sec on understanding these
> >
> > if statements.
> >
> >
> > k_standard.c
> >
> > exc.retval is returned below and thus should always be initialized.
> >
> >
> > imageDecompressor.cpp
> >
> > Wrong destructor is used.  Reported also by David CARLIER
> >
> >
> > java.c
> >
> > in line 1865 'name' was used, it should be 'alias'.
> >
> >
> > java_md_solinux.c
> >
> > "//" in path is useless. Further down a free is missing.
> >
> >
> > SDE.c
> >
> > Call to stratumTableIndex can return negative value if defaultStratumId
> > == null.
> >
> >
> > socket_md.c
> >
> > arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in
> > the macros.
> >
> >
> > unpack.cpp
> >
> > n.slice should not get negative argument for end, which is passed from
> > dollar1.
> > But dollar1 can get negative where it is set to the result of
> > lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1).
> >
> 
> 
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.

RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding.

[Lindenmaier, Goetz]

Hi,

This change fixes some minor issues found in our code scans.
I hope this correctly addresses corelib and serviceability issues.

Please review:
http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.01/

Best regards,
  Goetz.

Changes in detail:

e_asin.c

Code scan reports missing {}.

The code "if (huge+x>one) {" is only there to set the inexact flag of the 
processor.
It's a way to avoid the C compiler to optimize the code away. It is always true,
so the parenthesis of the outer else don't matter.

Although this basically just adds the {} I would like to submit this to
avoid anybody else spends more the 30sec on understanding these
if statements.

k_standard.c

exc.retval is returned below and thus should always be initialized.


imageDecompressor.cpp

Wrong destructor is used.  Reported also by David CARLIER


java.c

in line 1865 'name' was used, it should be 'alias'.


java_md_solinux.c

"//" in path is useless. Further down a free is missing.


SDE.c

Call to stratumTableIndex can return negative value if defaultStratumId == null.


socket_md.c

arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in the 
macros.


unpack.cpp

n.slice should not get negative argument for end, which is passed from dollar1.
But dollar1 can get negative where it is set to the result of 
lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1).

RE: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase

[Lindenmaier, Goetz]

Hi Dmitry, 

thanks fort he fixed, looks good now.

Best regards,
  Goetz.

> -Original Message-
> From: Dmitry Samersoff [mailto:dmitry.samers...@oracle.com]
> Sent: Montag, 11. Juli 2016 15:51
> To: Coleen Phillimore <coleen.phillim...@oracle.com>; serviceability-
> d...@openjdk.java.net; hotspot-runtime-dev  d...@openjdk.java.net>; hotspot-compiler-...@openjdk.java.net;
> Lindenmaier, Goetz <goetz.lindenma...@sap.com>
> Subject: Re: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires
> assert(_exception_caught == false) failed: _exception_caught is out of phase
> 
> Everybody,
> 
> Updated webrev:
> 
>   http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.02/
> 
> Testcase added. Goetz's concerns addressed.
> 
> -Dmitry
> 
> 
> On 2016-07-11 16:35, Coleen Phillimore wrote:
> > Adding hotspot-compiler-dev since the change is in opto/runtime.cpp
> >
> > Coleen
> >
> > On 7/11/16 4:22 AM, Dmitry Samersoff wrote:
> >> PING ...
> >>
> >>
> >>  Forwarded Message 
> >> Subject: RFR(S): JDK-8134434: JVM_DoPrivileged() fires
> >> assert(_exception_caught == false) failed: _exception_caught is out of
> >> phase
> >> Date: Wed, 6 Jul 2016 19:24:15 +0300
> >> From: Dmitry Samersoff <dmitry.samers...@oracle.com>
> >> To: serviceability-dev@openjdk.java.net
> >> <serviceability-dev@openjdk.java.net>
> >>
> >> Everybody,
> >>
> >> Please review the fix.
> >>
> >> http://cr.openjdk.java.net/~dsamersoff/JDK-8134434/webrev.01/
> >>
> >> All credentials belongs to Richard Reingruber, see mail thread (below)
> >> for details.
> >>
> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-
> August/019613.html
> >>
> >>
> >>
> >> -Dmitry
> >>
> >
> 
> 
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.

RE: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase

[Lindenmaier, Goetz]

Hi Dmitry,

thanks for looking at this issue.
I think your fix will crash if thread->jvmti_thread_state();
returns NULL.  Also, please add the #include with leading
directory prims/ at the proper alphabetic position.

Also, you could add the test Richard supplied, see below.

Best regards,
  Goetz.

--- /dev/null   Thu Jan 01 00:00:00 1970 +  
 
+++ b/test/serviceability/jvmti/ExceptionCaughtOutOfPhaseAssertion.java Mon Jul 
11 11:30:12 2016 +0200   
@@ -0,0 +1,55 @@
 
+/* 
 
+ * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.  
 
+ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.   
 
+ * 
 
+ * This code is free software; you can redistribute it and/or modify it
 
+ * under the terms of the GNU General Public License version 2 only, as
 
+ * published by the Free Software Foundation.  
 
+ * 
 
+ * This code is distributed in the hope that it will be useful, but WITHOUT
 
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or   
 
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License   
 
+ * version 2 for more details (a copy is included in the LICENSE file that 
 
+ * accompanied this code). 
 
+ * 
 
+ * You should have received a copy of the GNU General Public License version   
 
+ * 2 along with this work; if not, write to the Free Software Foundation,  
 
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.   
 
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+ * or visit www.oracle.com if you need additional information or have any
+ * questions.
+ */
+
+import java.security.AccessController;
+import java.security.PrivilegedAction;
+
+/*
+ * @test
+ * @bug 8134434
+ * @summary JVM_DoPrivileged() fires assert(_exception_caught == false) 
failed: _exception_caught is out of phase
+ * @run main/othervm 
-agentlib:jdwp=transport=dt_socket,address=9000,server=y,suspend=n -Xbatch 
ExceptionCaughtOutOfPhaseAssertion
+ */
+
+public class ExceptionCaughtOutOfPhaseAssertion {
+public static void main(String[] args) {
+PrivilegedAction action = new HotThrowingAction();
+System.out.println("### Warm-up");
+for(int i=0; i<11000; i++) {
+try {
+action.run(); // call run() to get it compiled
+} catch(Throwable t) { /* ignored */ }
+}
+System.out.println("### Warm-up done");
+System.out.println("### Executing privileged action");
+try {
+AccessController.doPrivileged(action);
+} catch (Error e) {
+}
+}
+public static class HotThrowingAction implements PrivilegedAction {
+public Object run() {
+throw new Error();
+}
+}
+}






> -Original Message-
> From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-
> boun...@openjdk.java.net] On Behalf Of Dmitry Samersoff
> Sent: Montag, 11. Juli 2016 10:23
> To: serviceability-dev@openjdk.java.net; hotspot-runtime-dev  runtime-...@openjdk.java.net>
> Subject: RFR(S): PING! JDK-8134434: JVM_DoPrivileged() fires
> assert(_exception_caught == false) failed: _exception_caught is out of phase
> 
> PING ...
> 
> 
>  Forwarded Message 
> Subject: RFR(S): JDK-8134434: JVM_DoPrivileged() fires
> assert(_exception_caught == false) failed: _exception_caught is out of phase
> Date: Wed, 6 Jul 2016 19:24:15 +0300
> From: Dmitry Samersoff 
> To: serviceability-dev@openjdk.java.net
> 
> 
> Everybody,
> 
> Please review the fix.
> 
> 

RE: New Serviceability Group Lead: Staffan Larsen

[Lindenmaier, Goetz]

Vote: yes

Best regards,
  Goetz.

> -Original Message-
> From: serviceability-dev [mailto:serviceability-dev-
> boun...@openjdk.java.net] On Behalf Of Daniel D. Daugherty
> Sent: Freitag, 8. Juli 2016 01:48
> To: serviceability-dev@openjdk.java.net
> Subject: CFV: New Serviceability Group Lead: Staffan Larsen
> 
> I hereby nominate Staffan Larsen to Serviceability Group Lead [1].
> 
> Staffan is a Reviewer in the jdk9 and jdk8u Projects, a member of the
> Serviceability team, and has so far committed > 145 changesets. He is the
> Serviceability architect since 2011, has been working on HotSpot for
> more than five years. Before joining the HotSpot team he worked with
> the JRockit JVM from 1999.
> 
> Votes are due by July 25, 2016 18:00 PDT.
> 
> Only current Members of the Serviceability Group [2] are eligible
> to vote on this nomination.  Votes must be cast in the open by
> replying to this mailing list.
> 
> For Simple Majority voting instructions, see [3].
> 
> Thanks,
> Daniel Daugherty
> 
> [1]: http://openjdk.java.net/bylaws#group-lead
> [2]: http://openjdk.java.net/census#serviceability
> [3]: http://openjdk.java.net/groups#lead-vote

RE: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM

[Lindenmaier, Goetz]

David, Dmitry, 

I think this is reviewed now.  Could one of you please sponsor this?
The final webrev, including a full changeset patch, is this:
http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.02/

It ran successfully through our nightly tests, tonight.

Best regards,
  Goetz.

> -Original Message-
> From: Dmitry Samersoff [mailto:dmitry.samers...@oracle.com]
> Sent: Montag, 16. November 2015 11:53
> To: Lindenmaier, Goetz; Thomas Stüfe
> Cc: David Holmes; hotspot-runtime-...@openjdk.java.net; serviceability-
> dev
> Subject: Re: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
> 
> Goetz,
> 
> Looks good for me.
> 
> Thank you for a nice cleanup.
> 
> -Dmitry
> 
> 
> On 2015-11-16 13:25, Lindenmaier, Goetz wrote:
> > Hi Thomas,
> >
> >
> >
> > thanks for looking at this.
> >
> >
> >
> >> MAX2(SIGSEGV, SIGBUS)
> >
> > I really would like to leave the code as-is.  This would be a functional
> >
> > change, while I only intend to fix issues in this change.  Also, as David
> >
> > explained, it might break for some os implementations.
> >
> >
> >
> >> the only way to initialize it is with one of sigemptyset() or sigfillset().
> >
> > I added initialization with sigemptyset().  Unfortunately, there is no
> > static
> >
> > initializer for this.
> >
> >
> >
> >> I would like to see those removed from os::Aix and put into os_aix.cpp at
> static filescope
> >
> > I moved these to static scope on the three oses.
> >
> >
> >
> > Here is the new webrev:
> >
> > http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.02/
> >
> >
> >
> > Best regards,
> >
> >   Goetz.
> >
> >
> >
> >
> >
> > *From:*Thomas Stüfe [mailto:thomas.stu...@gmail.com]
> > *Sent:* Freitag, 13. November 2015 10:54
> > *To:* Lindenmaier, Goetz
> > *Cc:* Dmitry Samersoff; David Holmes;
> > hotspot-runtime-...@openjdk.java.net; serviceability-dev
> > *Subject:* Re: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
> >
> >
> >
> > Hi Goetz,
> >
> >
> >
> > sorry for not looking at this earlier. This is a nice cleanup. Some remarks:
> >
> >
> >
> > http://cr.openjdk.java.net/~goetz/webrevs/8141529-
> NSIG/webrev.01/src/os/aix/vm/os_aix.cpp.udiff.html
> >
> >
> >
> > +if (sig > MAX2(SIGSEGV, SIGBUS) &&  // See 4355769.
> >
> > +sig < NSIG) {   // Must be legal signal and fit
> > into sigflags[].
> >
> >
> >
> > I do not like much the MAX2() construct. I would like it better to
> > explicitly check whether the SR signal is one of the "forbidden" ones
> > the VM uses.
> >
> >
> >
> > Maybe keep a mask defined centrally for each platform which contains
> > signals the VM needs for itself ?
> >
> >
> >
> > +sigset_t os::Aix::sigs = { 0 };
> >
> >
> >
> > I would not initialize the signal set this way. sigset_t is an opaque
> > type; the only way to initialize it is with one of sigemptyset() or
> > sigfillset().
> >
> >
> >
> > http://cr.openjdk.java.net/~goetz/webrevs/8141529-
> NSIG/webrev.01/src/os/aix/vm/os_aix.hpp.udiff.html
> >
> >
> >
> > +  static struct sigaction sigact[NSIG]; // saved preinstalled sigactions
> >
> > +  static sigset_t sigs; // mask of signals that have
> >
> >
> >
> > +  static int sigflags[NSIG];
> >
> >
> >
> > I know this is not in the scope of your change, but I would like to see
> > those removed from os::Aix and put into os_aix.cpp at static filescope.
> > There is no need at all to export those, and you would get rid of the
> > signal.h dependency you know have when including os_aix.hpp.
> >
> >
> >
> >
> >
> > http://cr.openjdk.java.net/~goetz/webrevs/8141529-
> NSIG/webrev.01/src/os/bsd/vm/jsig.c.udiff.html
> >
> > http://cr.openjdk.java.net/~goetz/webrevs/8141529-
> NSIG/webrev.01/src/os/bsd/vm/os_bsd.cpp.udiff.html
> >
> >
> >
> > On BSD, we have realtime signals.
> >
> >
> >
> > http://fxr.watson.org/fxr/source/sys/signal.h
> >
> > #define SIGRTMAX126
> >
> > and NSIG does not contain them:
> >
> > #define NSIG32
> >
> >
> >
> > The max. possible signal number would be 12

RE: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM

[Lindenmaier, Goetz]

Great, looks good.  Thanks a lot!

Best regards,
  Goetz.

> -Original Message-
> From: Dmitry Samersoff [mailto:dmitry.samers...@oracle.com]
> Sent: Dienstag, 17. November 2015 14:42
> To: Lindenmaier, Goetz; Thomas Stüfe
> Cc: David Holmes; hotspot-runtime-...@openjdk.java.net; serviceability-
> dev
> Subject: Re: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
> 
> Goetz,
> 
> Push done.
> Please, take a look at the changeset:
> 
> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/149cc1f9f1aa
> 
> -Dmitry
> 
> On 2015-11-17 11:35, Lindenmaier, Goetz wrote:
> > That's great, thanks a lot!
> >
> > Best regards,
> >   Goetz.
> >
> >> -Original Message-
> >> From: Dmitry Samersoff [mailto:dmitry.samers...@oracle.com]
> >> Sent: Dienstag, 17. November 2015 09:34
> >> To: Lindenmaier, Goetz; Thomas Stüfe
> >> Cc: David Holmes; hotspot-runtime-...@openjdk.java.net; serviceability-
> >> dev
> >> Subject: Re: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
> >>
> >> Goetz,
> >>
> >> I'll sponsor the push
> >>
> >> -Dmitry.
> >>
> >> On 2015-11-17 10:52, Lindenmaier, Goetz wrote:
> >>> David, Dmitry,
> >>>
> >>> I think this is reviewed now.  Could one of you please sponsor this?
> >>> The final webrev, including a full changeset patch, is this:
> >>> http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.02/
> >>>
> >>> It ran successfully through our nightly tests, tonight.
> >>>
> >>> Best regards,
> >>>   Goetz.
> >>>
> >>>> -Original Message-
> >>>> From: Dmitry Samersoff [mailto:dmitry.samers...@oracle.com]
> >>>> Sent: Montag, 16. November 2015 11:53
> >>>> To: Lindenmaier, Goetz; Thomas Stüfe
> >>>> Cc: David Holmes; hotspot-runtime-...@openjdk.java.net;
> serviceability-
> >>>> dev
> >>>> Subject: Re: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
> >>>>
> >>>> Goetz,
> >>>>
> >>>> Looks good for me.
> >>>>
> >>>> Thank you for a nice cleanup.
> >>>>
> >>>> -Dmitry
> >>>>
> >>>>
> >>>> On 2015-11-16 13:25, Lindenmaier, Goetz wrote:
> >>>>> Hi Thomas,
> >>>>>
> >>>>>
> >>>>>
> >>>>> thanks for looking at this.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> MAX2(SIGSEGV, SIGBUS)
> >>>>>
> >>>>> I really would like to leave the code as-is.  This would be a functional
> >>>>>
> >>>>> change, while I only intend to fix issues in this change.  Also, as 
> >>>>> David
> >>>>>
> >>>>> explained, it might break for some os implementations.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> the only way to initialize it is with one of sigemptyset() or 
> >>>>>> sigfillset().
> >>>>>
> >>>>> I added initialization with sigemptyset().  Unfortunately, there is no
> >>>>> static
> >>>>>
> >>>>> initializer for this.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> I would like to see those removed from os::Aix and put into
> os_aix.cpp
> >> at
> >>>> static filescope
> >>>>>
> >>>>> I moved these to static scope on the three oses.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Here is the new webrev:
> >>>>>
> >>>>> http://cr.openjdk.java.net/~goetz/webrevs/8141529-
> NSIG/webrev.02/
> >>>>>
> >>>>>
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>>   Goetz.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> *From:*Thomas Stüfe [mailto:thomas.stu...@gmail.com]
> >>>>> *Sent:* Freitag, 13. November 2015 10:54
> >>>>> *To:* Lindenmaier, Goetz
> >>>>> *Cc:* Dmitry Samersoff; David Holmes;
> >>>>> hotspot-runtime-...@openjdk.java.net; 

RE: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM

[Lindenmaier, Goetz]

That's great, thanks a lot!

Best regards,
  Goetz.

> -Original Message-
> From: Dmitry Samersoff [mailto:dmitry.samers...@oracle.com]
> Sent: Dienstag, 17. November 2015 09:34
> To: Lindenmaier, Goetz; Thomas Stüfe
> Cc: David Holmes; hotspot-runtime-...@openjdk.java.net; serviceability-
> dev
> Subject: Re: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
> 
> Goetz,
> 
> I'll sponsor the push
> 
> -Dmitry.
> 
> On 2015-11-17 10:52, Lindenmaier, Goetz wrote:
> > David, Dmitry,
> >
> > I think this is reviewed now.  Could one of you please sponsor this?
> > The final webrev, including a full changeset patch, is this:
> > http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.02/
> >
> > It ran successfully through our nightly tests, tonight.
> >
> > Best regards,
> >   Goetz.
> >
> >> -Original Message-----
> >> From: Dmitry Samersoff [mailto:dmitry.samers...@oracle.com]
> >> Sent: Montag, 16. November 2015 11:53
> >> To: Lindenmaier, Goetz; Thomas Stüfe
> >> Cc: David Holmes; hotspot-runtime-...@openjdk.java.net; serviceability-
> >> dev
> >> Subject: Re: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
> >>
> >> Goetz,
> >>
> >> Looks good for me.
> >>
> >> Thank you for a nice cleanup.
> >>
> >> -Dmitry
> >>
> >>
> >> On 2015-11-16 13:25, Lindenmaier, Goetz wrote:
> >>> Hi Thomas,
> >>>
> >>>
> >>>
> >>> thanks for looking at this.
> >>>
> >>>
> >>>
> >>>> MAX2(SIGSEGV, SIGBUS)
> >>>
> >>> I really would like to leave the code as-is.  This would be a functional
> >>>
> >>> change, while I only intend to fix issues in this change.  Also, as David
> >>>
> >>> explained, it might break for some os implementations.
> >>>
> >>>
> >>>
> >>>> the only way to initialize it is with one of sigemptyset() or 
> >>>> sigfillset().
> >>>
> >>> I added initialization with sigemptyset().  Unfortunately, there is no
> >>> static
> >>>
> >>> initializer for this.
> >>>
> >>>
> >>>
> >>>> I would like to see those removed from os::Aix and put into os_aix.cpp
> at
> >> static filescope
> >>>
> >>> I moved these to static scope on the three oses.
> >>>
> >>>
> >>>
> >>> Here is the new webrev:
> >>>
> >>> http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.02/
> >>>
> >>>
> >>>
> >>> Best regards,
> >>>
> >>>   Goetz.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> *From:*Thomas Stüfe [mailto:thomas.stu...@gmail.com]
> >>> *Sent:* Freitag, 13. November 2015 10:54
> >>> *To:* Lindenmaier, Goetz
> >>> *Cc:* Dmitry Samersoff; David Holmes;
> >>> hotspot-runtime-...@openjdk.java.net; serviceability-dev
> >>> *Subject:* Re: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
> >>>
> >>>
> >>>
> >>> Hi Goetz,
> >>>
> >>>
> >>>
> >>> sorry for not looking at this earlier. This is a nice cleanup. Some 
> >>> remarks:
> >>>
> >>>
> >>>
> >>> http://cr.openjdk.java.net/~goetz/webrevs/8141529-
> >> NSIG/webrev.01/src/os/aix/vm/os_aix.cpp.udiff.html
> >>>
> >>>
> >>>
> >>> +if (sig > MAX2(SIGSEGV, SIGBUS) &&  // See 4355769.
> >>>
> >>> +sig < NSIG) {   // Must be legal signal and fit
> >>> into sigflags[].
> >>>
> >>>
> >>>
> >>> I do not like much the MAX2() construct. I would like it better to
> >>> explicitly check whether the SR signal is one of the "forbidden" ones
> >>> the VM uses.
> >>>
> >>>
> >>>
> >>> Maybe keep a mask defined centrally for each platform which contains
> >>> signals the VM needs for itself ?
> >>>
> >>>
> >>>
> >>> +sigset_t os::Aix::sigs = { 0 };
> >>>
> >>>
> >>>
> >>> I would not initialize the signal set this way. sigset_t is an opaque

RE: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM

[Lindenmaier, Goetz]

Hi Dmitry, 

I think this is a rather complex issue which is better documented in the 
bug than in the code.  The code already references the bugID.
Also, I would have to copy the explanation into three files ...
I you don't object I'll leave the comment as is.

Best regards,
  Goetz.

-Original Message-
From: Dmitry Samersoff [mailto:dmitry.samers...@oracle.com] 
Sent: Montag, 16. November 2015 09:23
To: David Holmes; Thomas Stüfe; Lindenmaier, Goetz
Cc: serviceability-dev; hotspot-runtime-...@openjdk.java.net
Subject: Re: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM

David,

Thank you for detailed explanation. Could we put it as a comment right
into the code?

-Dmitry

On 2015-11-16 07:03, David Holmes wrote:
> On 13/11/2015 11:38 PM, David Holmes wrote:
>> On 13/11/2015 7:53 PM, Thomas Stüfe wrote:
>>> Hi Goetz,
>>>
>>> sorry for not looking at this earlier. This is a nice cleanup. Some
>>> remarks:
>>>
>>> http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.01/src/os/aix/vm/os_aix.cpp.udiff.html
>>>
>>>
>>>
>>> +if (sig > MAX2(SIGSEGV, SIGBUS) &&  // See 4355769.
>>> +sig < NSIG) {   // Must be legal signal and fit
>>> into sigflags[].
>>>
>>> I do not like much the MAX2() construct. I would like it better to
>>> explicitly check whether the SR signal is one of the "forbidden" ones
>>> the VM uses.
>>
>> I must confess I had not looked into 4355769 but this check seems rather
>> spurious. It is not at all clear to me what signals could be used here -
> 
> Okay should have looked into 4355769. The problem is how multiple
> pending signals are handled. It seems that in the past (no idea if still
> true) pending signals were handled in signal-number order (lowest
> first), not FIFO. The problem scenario is this:
> - thread accesses a null pointer in compiled Java code and the SEGV
> handler will cause NPE to be thrown
> - at the same time as the SEGV is being raised the thread is also hit
> with the SR signal to suspend it.
> - the SR signal will be delivered first and the SR handler starts to run
> - with signals unblocked.
> - the SEGV then gets delivered to the thread in the SR handler, and the
> regular signal handler is run
> - the regular signal handler tries to detect if we're running in Java
> code so it can post the NPE, but the presence of the SR handler causes
> that check to fail - so we abort thinking it is a real SEGV.
> 
> I don't know how much of that is still true today. It seems strange to
> me that a kill based directed signal can usurp a synchronous signal.
> 
> Anyway the fix, rather workaround, for that problem, was to ensure that
> the SR_signum is greater than any potential synchronous signal the VM
> cares about. Why SIGBUS was included there I don't know give that:
> 
> a) it is already a lower signal number than SIGUSR1, SIGSEGV and SIGUSR2
> b) we don't deliberately generate and use SIGBUS ... though perhaps
> unsafe-fetch needs to be considered.
> 
> A better fix in my opinion, and as mentioned in the bug, would have been
> to disable delivery of SEGV whilst the SR handler is executing. But we
> start to touch on some grey areas of the POSIX spec there, and likely
> the implementation too.
> 
> So I suggest that for this cleanup we simply leave this logic exactly as
> is.
> 
> Thanks,
> David
> 
>> other than SIGUSR1 or SIGUSR2 (if -Xrs is specified), or else a
>> real-time signal (modulo discussion below). Hijacking anything else
>> seems rather suspect.
>>
>>> Maybe keep a mask defined centrally for each platform which contains
>>> signals the VM needs for itself ?
>>
>> Such masks already exist.
>>
>>> +sigset_t os::Aix::sigs = { 0 };
>>>
>>> I would not initialize the signal set this way. sigset_t is an opaque
>>> type; the only way to initialize it is with one of sigemptyset() or
>>> sigfillset().
>>
>> Good catch - I overlooked that.
>>
>>> http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.01/src/os/aix/vm/os_aix.hpp.udiff.html
>>>
>>>
>>>
>>> +  static struct sigaction sigact[NSIG]; // saved preinstalled
>>> sigactions
>>> +  static sigset_t sigs; // mask of signals that have
>>>
>>> +  static int sigflags[NSIG];
>>>
>>> I know this is not in the scope of your change, but I would like to see
>>> those removed from os::Aix and put into os_aix.cpp at static filescope.
>>> There is no need at all to export those, and you would get rid of the
>>>

RE: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM

[Lindenmaier, Goetz]

Hi Thomas,

thanks for looking at this.

> MAX2(SIGSEGV, SIGBUS)
I really would like to leave the code as-is.  This would be a functional
change, while I only intend to fix issues in this change.  Also, as David
explained, it might break for some os implementations.

> the only way to initialize it is with one of sigemptyset() or sigfillset().
I added initialization with sigemptyset().  Unfortunately, there is no static
initializer for this.

> I would like to see those removed from os::Aix and put into os_aix.cpp at 
> static filescope
I moved these to static scope on the three oses.

Here is the new webrev:
http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.02/

Best regards,
  Goetz.


From: Thomas Stüfe [mailto:thomas.stu...@gmail.com]
Sent: Freitag, 13. November 2015 10:54
To: Lindenmaier, Goetz
Cc: Dmitry Samersoff; David Holmes; hotspot-runtime-...@openjdk.java.net; 
serviceability-dev
Subject: Re: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM

Hi Goetz,

sorry for not looking at this earlier. This is a nice cleanup. Some remarks:

http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.01/src/os/aix/vm/os_aix.cpp.udiff.html

+if (sig > MAX2(SIGSEGV, SIGBUS) &&  // See 4355769.
+sig < NSIG) {   // Must be legal signal and fit into 
sigflags[].

I do not like much the MAX2() construct. I would like it better to explicitly 
check whether the SR signal is one of the "forbidden" ones the VM uses.

Maybe keep a mask defined centrally for each platform which contains signals 
the VM needs for itself ?

+sigset_t os::Aix::sigs = { 0 };

I would not initialize the signal set this way. sigset_t is an opaque type; the 
only way to initialize it is with one of sigemptyset() or sigfillset().

http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.01/src/os/aix/vm/os_aix.hpp.udiff.html

+  static struct sigaction sigact[NSIG]; // saved preinstalled sigactions
+  static sigset_t sigs; // mask of signals that have

+  static int sigflags[NSIG];

I know this is not in the scope of your change, but I would like to see those 
removed from os::Aix and put into os_aix.cpp at static filescope. There is no 
need at all to export those, and you would get rid of the signal.h dependency 
you know have when including os_aix.hpp.


http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.01/src/os/bsd/vm/jsig.c.udiff.html
http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.01/src/os/bsd/vm/os_bsd.cpp.udiff.html

On BSD, we have realtime signals.

http://fxr.watson.org/fxr/source/sys/signal.h
#define SIGRTMAX126
and NSIG does not contain them:
#define NSIG32

The max. possible signal number would be 126, which unfortunately does not even 
fit into a 64bit mask.

So the code in jsig.c is broken for the case that someone wants to register 
realtime signals, if the VM were to ever use realtime signals itself, which now 
is not the case.

The same is true for os_bsd.cpp, where signal chaining will not work if the 
application did have handler for real time signals pre-installed before jvm is 
loaded.

Solaris:

The only platform where NSIG is missing?

Here, we calculate the max. signal number dynamically in os_solaris.cpp, 
presumably because SIGRTMAX is not a constant and can be changed using system 
configuration. But then, on Linux we have the same situation (SIGRTMAX is 
dynamic) and there we do not go through the trouble of calculating the max. 
signal number dynamically. Instead we just use NSIG=64 and rely on the fact 
that NSIG is larger than the largest possible dynamic value for SIGRTMAX.

Solaris does not seem to have NSIG defined, but I am sure there is also a max. 
possible value for SIGRTMAX (the default seems to be 48). So, one could 
probably safely define NSIG for Solaris too, so that we have NSIG defined on 
all Posix platforms.


On Thu, Nov 12, 2015 at 8:24 PM, Lindenmaier, Goetz 
<goetz.lindenma...@sap.com<mailto:goetz.lindenma...@sap.com>> wrote:
Hi David, Dmitry,

I've come up with a new webrev:
http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.01/

I hit on some more issues:
 - As proposed, I replaced MAXSIGNUM by NSIG
 - On AIX, NSIG=255.  Therefore storing bits in a word does not work.
I'm now using bitset functionality from signal.h as it's done in other 
places.
   sigset_t is >> NSIG on linux, so it's no good idea to use it there.

Why do we not do this on all platforms, provided sigset_t contains all signals 
(incl. realtime signals) ?

 - In the os files I found another bit vector that now is too small: sigs.
   I adapted that, too.  Removed the dead declaration of this on solaris.

Best regards,
  Goetz.


Kind Regards, Thomas


> -Original Message-
> From: Dmitry Samersoff 
> [mailto:dmitry.samers...@oracle.com<mailto:dmitry.samers...@oracle.com>]
> Sent: Donnerstag,

RE: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM

[Lindenmaier, Goetz]

Hi David,

thanks for looking into this issue.  I'll leave the coding as is.

Best regards,
  Goetz.

-Original Message-
From: David Holmes [mailto:david.hol...@oracle.com] 
Sent: Montag, 16. November 2015 05:04
To: Thomas Stüfe; Lindenmaier, Goetz
Cc: serviceability-dev; hotspot-runtime-...@openjdk.java.net
Subject: Re: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM

On 13/11/2015 11:38 PM, David Holmes wrote:
> On 13/11/2015 7:53 PM, Thomas Stüfe wrote:
>> Hi Goetz,
>>
>> sorry for not looking at this earlier. This is a nice cleanup. Some
>> remarks:
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.01/src/os/aix/vm/os_aix.cpp.udiff.html
>>
>>
>> +if (sig > MAX2(SIGSEGV, SIGBUS) &&  // See 4355769.
>> +sig < NSIG) {   // Must be legal signal and fit
>> into sigflags[].
>>
>> I do not like much the MAX2() construct. I would like it better to
>> explicitly check whether the SR signal is one of the "forbidden" ones
>> the VM uses.
>
> I must confess I had not looked into 4355769 but this check seems rather
> spurious. It is not at all clear to me what signals could be used here -

Okay should have looked into 4355769. The problem is how multiple 
pending signals are handled. It seems that in the past (no idea if still 
true) pending signals were handled in signal-number order (lowest 
first), not FIFO. The problem scenario is this:
- thread accesses a null pointer in compiled Java code and the SEGV 
handler will cause NPE to be thrown
- at the same time as the SEGV is being raised the thread is also hit 
with the SR signal to suspend it.
- the SR signal will be delivered first and the SR handler starts to run 
- with signals unblocked.
- the SEGV then gets delivered to the thread in the SR handler, and the 
regular signal handler is run
- the regular signal handler tries to detect if we're running in Java 
code so it can post the NPE, but the presence of the SR handler causes 
that check to fail - so we abort thinking it is a real SEGV.

I don't know how much of that is still true today. It seems strange to 
me that a kill based directed signal can usurp a synchronous signal.

Anyway the fix, rather workaround, for that problem, was to ensure that 
the SR_signum is greater than any potential synchronous signal the VM 
cares about. Why SIGBUS was included there I don't know give that:

a) it is already a lower signal number than SIGUSR1, SIGSEGV and SIGUSR2
b) we don't deliberately generate and use SIGBUS ... though perhaps 
unsafe-fetch needs to be considered.

A better fix in my opinion, and as mentioned in the bug, would have been 
to disable delivery of SEGV whilst the SR handler is executing. But we 
start to touch on some grey areas of the POSIX spec there, and likely 
the implementation too.

So I suggest that for this cleanup we simply leave this logic exactly as is.

Thanks,
David

> other than SIGUSR1 or SIGUSR2 (if -Xrs is specified), or else a
> real-time signal (modulo discussion below). Hijacking anything else
> seems rather suspect.
>
>> Maybe keep a mask defined centrally for each platform which contains
>> signals the VM needs for itself ?
>
> Such masks already exist.
>
>> +sigset_t os::Aix::sigs = { 0 };
>>
>> I would not initialize the signal set this way. sigset_t is an opaque
>> type; the only way to initialize it is with one of sigemptyset() or
>> sigfillset().
>
> Good catch - I overlooked that.
>
>> http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.01/src/os/aix/vm/os_aix.hpp.udiff.html
>>
>>
>> +  static struct sigaction sigact[NSIG]; // saved preinstalled sigactions
>> +  static sigset_t sigs; // mask of signals that have
>>
>> +  static int sigflags[NSIG];
>>
>> I know this is not in the scope of your change, but I would like to see
>> those removed from os::Aix and put into os_aix.cpp at static filescope.
>> There is no need at all to export those, and you would get rid of the
>> signal.h dependency you know have when including os_aix.hpp.
>>
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.01/src/os/bsd/vm/jsig.c.udiff.html
>>
>> http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.01/src/os/bsd/vm/os_bsd.cpp.udiff.html
>>
>>
>> On BSD, we have realtime signals.
>>
>> http://fxr.watson.org/fxr/source/sys/signal.h
>> #define SIGRTMAX 126
>> and NSIG does not contain them:
>> #define NSIG 32
>>
>> The max. possible signal number would be 126, which unfortunately does
>> not even fit into a 64bit mask.
>
> So this simply limits the signal choice to not be a real-time signal -
> same as today.
>
>

RE: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM

[Lindenmaier, Goetz]

OK I'll change it to NSIG.  That's used in other places in os_linux, too.
So it's really more consistent.

Best regards,
  Goetz

> -Original Message-
> From: Dmitry Samersoff [mailto:dmitry.samers...@oracle.com]
> Sent: Donnerstag, 12. November 2015 09:22
> To: David Holmes; Lindenmaier, Goetz; hotspot-runtime-
> d...@openjdk.java.net; serviceability-dev
> Subject: Re: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
> 
> David,
> 
> I think it's better to use NSIG (without underscore) defined in signal.h
> 
> -Dmitry
> 
> 
> On 2015-11-12 10:35, David Holmes wrote:
> > Hi Goetz,
> >
> > Adding in serviceability-dev
> >
> > On 9/11/2015 6:22 PM, Lindenmaier, Goetz wrote:
> >> Hi,
> >>
> >> The environment variable _JAVA_SR_SIGNUM can be set to a signal
> number
> >> do be used by the JVM's suspend/resume mechanism.
> >>
> >> If set, a signal handler is installed and the current signal handler
> >> is saved to an array.
> >> On linux, this array had size MAXSIGNUM=32, and _JAVA_SR_SIGNUM
> was
> >> allowed
> >> to range up to _NSIG=65. This could cause memory corruption.
> >>
> >> Further, in jsig.c, an unsinged int is used to set a bit for signals.
> >> This also
> >> is too small, as only 32 signals can be supported.  Further, the
> >> signals are mapped
> >> wrong to these bits.  '0' is not a valid signal, but '32' was.  1<<32
> >> happens to map to
> >> zero, so the signal could be stored, but this probably was not
> >> intended that way.
> >>
> >> This change increases MAXSIGNUM to 65 on linux, and to 64 on aix. It
> >> introduces
> >> proper checking of the signal read from the env var, and issues a
> >> warning if it
> >> does not use the signal set.  It adapts the data types in jisig.c
> >> properly.
> >>
> >> Please review this change.  I please need a sponsor.
> >> http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.00
> >
> > This all sounds very good to me. (I must find out why Solaris is not
> > involved here :) ).
> >
> > On Linux you didn't add the bounds check to os::Linux::set_our_sigflags.
> >
> > I'm also wondering about documenting where we are determining the
> > maximum from? Is it simply _NSIG on some/all distributions? And I see
> > _NSIG is supposed to be the biggest signal number + one. Also linux
> > defines NSIG = _NSIG so which should we be using?
> >
> > Thanks,
> > David
> >
> >> Best regards,
> >>Goetz.
> >>
> 
> 
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.

RE: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM

[Lindenmaier, Goetz]

Hi David, Dmitry,

I've come up with a new webrev:
http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.01/

I hit on some more issues:
 - As proposed, I replaced MAXSIGNUM by NSIG
 - On AIX, NSIG=255.  Therefore storing bits in a word does not work.
I'm now using bitset functionality from signal.h as it's done in other 
places.
   sigset_t is >> NSIG on linux, so it's no good idea to use it there.
 - In the os files I found another bit vector that now is too small: sigs.
   I adapted that, too.  Removed the dead declaration of this on solaris.

Best regards,
  Goetz.

> -Original Message-
> From: Dmitry Samersoff [mailto:dmitry.samers...@oracle.com]
> Sent: Donnerstag, 12. November 2015 10:05
> To: Lindenmaier, Goetz; David Holmes; hotspot-runtime-
> d...@openjdk.java.net; serviceability-dev
> Subject: Re: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
> 
> Goetz,
> 
> *BSD including OS X also defines NSIG (just checked) and if my memory is
> not bogus, AIX defines it too.
> 
> So you may consider to use NSIG on all platform.
> 
> -Dmitry
> 
> On 2015-11-12 11:36, Lindenmaier, Goetz wrote:
> > OK I'll change it to NSIG.  That's used in other places in os_linux, too.
> > So it's really more consistent.
> >
> > Best regards,
> >   Goetz
> >
> >> -Original Message-
> >> From: Dmitry Samersoff [mailto:dmitry.samers...@oracle.com]
> >> Sent: Donnerstag, 12. November 2015 09:22
> >> To: David Holmes; Lindenmaier, Goetz; hotspot-runtime-
> >> d...@openjdk.java.net; serviceability-dev
> >> Subject: Re: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
> >>
> >> David,
> >>
> >> I think it's better to use NSIG (without underscore) defined in signal.h
> >>
> >> -Dmitry
> >>
> >>
> >> On 2015-11-12 10:35, David Holmes wrote:
> >>> Hi Goetz,
> >>>
> >>> Adding in serviceability-dev
> >>>
> >>> On 9/11/2015 6:22 PM, Lindenmaier, Goetz wrote:
> >>>> Hi,
> >>>>
> >>>> The environment variable _JAVA_SR_SIGNUM can be set to a signal
> >> number
> >>>> do be used by the JVM's suspend/resume mechanism.
> >>>>
> >>>> If set, a signal handler is installed and the current signal handler
> >>>> is saved to an array.
> >>>> On linux, this array had size MAXSIGNUM=32, and _JAVA_SR_SIGNUM
> >> was
> >>>> allowed
> >>>> to range up to _NSIG=65. This could cause memory corruption.
> >>>>
> >>>> Further, in jsig.c, an unsinged int is used to set a bit for signals.
> >>>> This also
> >>>> is too small, as only 32 signals can be supported.  Further, the
> >>>> signals are mapped
> >>>> wrong to these bits.  '0' is not a valid signal, but '32' was.  1<<32
> >>>> happens to map to
> >>>> zero, so the signal could be stored, but this probably was not
> >>>> intended that way.
> >>>>
> >>>> This change increases MAXSIGNUM to 65 on linux, and to 64 on aix. It
> >>>> introduces
> >>>> proper checking of the signal read from the env var, and issues a
> >>>> warning if it
> >>>> does not use the signal set.  It adapts the data types in jisig.c
> >>>> properly.
> >>>>
> >>>> Please review this change.  I please need a sponsor.
> >>>> http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.00
> >>>
> >>> This all sounds very good to me. (I must find out why Solaris is not
> >>> involved here :) ).
> >>>
> >>> On Linux you didn't add the bounds check to os::Linux::set_our_sigflags.
> >>>
> >>> I'm also wondering about documenting where we are determining the
> >>> maximum from? Is it simply _NSIG on some/all distributions? And I see
> >>> _NSIG is supposed to be the biggest signal number + one. Also linux
> >>> defines NSIG = _NSIG so which should we be using?
> >>>
> >>> Thanks,
> >>> David
> >>>
> >>>> Best regards,
> >>>>Goetz.
> >>>>
> >>
> >>
> >> --
> >> Dmitry Samersoff
> >> Oracle Java development team, Saint Petersburg, Russia
> >> * I would love to change the world, but they won't give me the sources.
> 
> 
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.

RE: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM

[Lindenmaier, Goetz]

Hi David, 

thanks for looking at this!

> -Original Message-
> From: David Holmes [mailto:david.hol...@oracle.com]
> Sent: Donnerstag, 12. November 2015 08:35
> To: Lindenmaier, Goetz; hotspot-runtime-...@openjdk.java.net;
> serviceability-dev
> Subject: Re: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
> 
> Hi Goetz,
> 
> Adding in serviceability-dev
> 
> On 9/11/2015 6:22 PM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > The environment variable _JAVA_SR_SIGNUM can be set to a signal
> number
> > do be used by the JVM's suspend/resume mechanism.
> >
> > If set, a signal handler is installed and the current signal handler is 
> > saved to
> an array.
> > On linux, this array had size MAXSIGNUM=32, and _JAVA_SR_SIGNUM was
> allowed
> > to range up to _NSIG=65. This could cause memory corruption.
> >
> > Further, in jsig.c, an unsinged int is used to set a bit for signals. This 
> > also
> > is too small, as only 32 signals can be supported.  Further, the signals are
> mapped
> > wrong to these bits.  '0' is not a valid signal, but '32' was.  1<<32 
> > happens to
> map to
> > zero, so the signal could be stored, but this probably was not intended that
> way.
> >
> > This change increases MAXSIGNUM to 65 on linux, and to 64 on aix. It
> introduces
> > proper checking of the signal read from the env var, and issues a warning if
> it
> > does not use the signal set.  It adapts the data types in jisig.c properly.
> >
> > Please review this change.  I please need a sponsor.
> > http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.00
> 
> This all sounds very good to me. (I must find out why Solaris is not
> involved here :) ).
The mechanism is not implemented there.  Why, I don't know.

> On Linux you didn't add the bounds check to os::Linux::set_our_sigflags.
It came with 8140482 
http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/cd86b5699825

> I'm also wondering about documenting where we are determining the
> maximum from? Is it simply _NSIG on some/all distributions? And I see
> _NSIG is supposed to be the biggest signal number + one. Also linux
> defines NSIG = _NSIG so which should we be using?
I checked a row of linux distributions and Versions and always found NSIG=65.
Also, as we compile NSIG into the code, we can not react on a difference
between systems. So I guess that's fine. 
As NSIG = _NSIG, I don't really care which we use.  I chose _NSIG because
it was used before.  On the other platforms I only found NSIG in the header
files.

Best regards,
  Goetz


> 
> Thanks,
> David
> 
> > Best regards,
> >Goetz.
> >

RE: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM

[Lindenmaier, Goetz]

Hi,

I'm not sure whether it's ideal to couple an internal data size to some
constant defined on the system.  But I'll change it.
To make sure nothing breaks, I will add guard
#if (64 < NSIG-1)
#error "Not all signals can be encoded in jvmsigs. Adapt its type!"
#endif
to jsig.c.

Best regards,
  Goetz.


> -Original Message-
> From: David Holmes [mailto:david.hol...@oracle.com]
> Sent: Donnerstag, 12. November 2015 09:29
> To: Lindenmaier, Goetz; hotspot-runtime-...@openjdk.java.net;
> serviceability-dev
> Subject: Re: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
> 
> Hi Goetz,
> 
> On 12/11/2015 6:22 PM, Lindenmaier, Goetz wrote:
> > Hi David,
> >
> > thanks for looking at this!
> >
> >> -Original Message-
> >> From: David Holmes [mailto:david.hol...@oracle.com]
> >> Sent: Donnerstag, 12. November 2015 08:35
> >> To: Lindenmaier, Goetz; hotspot-runtime-...@openjdk.java.net;
> >> serviceability-dev
> >> Subject: Re: RFR(M): 8141529: Fix handling of _JAVA_SR_SIGNUM
> >>
> >> Hi Goetz,
> >>
> >> Adding in serviceability-dev
> >>
> >> On 9/11/2015 6:22 PM, Lindenmaier, Goetz wrote:
> >>> Hi,
> >>>
> >>> The environment variable _JAVA_SR_SIGNUM can be set to a signal
> >> number
> >>> do be used by the JVM's suspend/resume mechanism.
> >>>
> >>> If set, a signal handler is installed and the current signal handler is 
> >>> saved
> to
> >> an array.
> >>> On linux, this array had size MAXSIGNUM=32, and _JAVA_SR_SIGNUM
> was
> >> allowed
> >>> to range up to _NSIG=65. This could cause memory corruption.
> >>>
> >>> Further, in jsig.c, an unsinged int is used to set a bit for signals. 
> >>> This also
> >>> is too small, as only 32 signals can be supported.  Further, the signals 
> >>> are
> >> mapped
> >>> wrong to these bits.  '0' is not a valid signal, but '32' was.  1<<32 
> >>> happens
> to
> >> map to
> >>> zero, so the signal could be stored, but this probably was not intended
> that
> >> way.
> >>>
> >>> This change increases MAXSIGNUM to 65 on linux, and to 64 on aix. It
> >> introduces
> >>> proper checking of the signal read from the env var, and issues a warning
> if
> >> it
> >>> does not use the signal set.  It adapts the data types in jisig.c 
> >>> properly.
> >>>
> >>> Please review this change.  I please need a sponsor.
> >>> http://cr.openjdk.java.net/~goetz/webrevs/8141529-NSIG/webrev.00
> >>
> >> This all sounds very good to me. (I must find out why Solaris is not
> >> involved here :) ).
> > The mechanism is not implemented there.  Why, I don't know.
> >
> >> On Linux you didn't add the bounds check to os::Linux::set_our_sigflags.
> > It came with 8140482 http://hg.openjdk.java.net/jdk9/hs-
> rt/hotspot/rev/cd86b5699825
> 
> That change isn't present in your new code:
> 
> void os::Linux::set_our_sigflags(int sig, int flags) {
>assert(sig > 0 && sig < MAXSIGNUM, "vm signal out of expected range");
>sigflags[sig] = flags;
> }
> 
> does it need to be re-based?
> 
> >> I'm also wondering about documenting where we are determining the
> >> maximum from? Is it simply _NSIG on some/all distributions? And I see
> >> _NSIG is supposed to be the biggest signal number + one. Also linux
> >> defines NSIG = _NSIG so which should we be using?
> > I checked a row of linux distributions and Versions and always found
> NSIG=65.
> > Also, as we compile NSIG into the code, we can not react on a difference
> > between systems. So I guess that's fine.
> 
> So why do we need MAXSIGNUM instead of just using NSIG ?
> 
> > As NSIG = _NSIG, I don't really care which we use.  I chose _NSIG because
> > it was used before.  On the other platforms I only found NSIG in the header
> > files.
> 
> I'd switch to NSIG as Dmitry suggested as it is the public value in
> signal.h.
> 
> Thanks,
> David
> 
> > Best regards,
> >Goetz
> >
> >
> >>
> >> Thanks,
> >> David
> >>
> >>> Best regards,
> >>> Goetz.
> >>>