RFR(M): 8166560: [s390] Basic enablement of s390 port.

[Lindenmaier, Goetz]

Hi,

This change is part of the s390 port. It contains some basic adaptions needed 
for a full hotspot port for linux s390x. 

It defines the required macros, platform names and includes. 

The s390 port calles CodeCache::contains() in current_frame(), which is used in 
NMT. As NMT already collects stack traces before the CodeCache is initialized, 
contains() needs a check for this. 

 Wherever a row of platforms are listed, I sorted them alphabetically. 

 The jdk requires the file jvm.cfg.

Please review. I please need a sponsor.
http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/hotspot.wr01/
http://cr.openjdk.java.net/~goetz/wr16/8166560-basic_s390/jdk.wr01/

Best regards,
  Goetz.

Re: RFR 8166501 : compilation error in stackwalk.cpp on some gccs

[David Holmes]

This is the second example I've seen in two days concerning misuse of 
CHECK_ macros. They expand into an if statement after the call, so can 
not appear on calls that are part of a return statement, or a 
conditional statement, or likely a number of other places, as the if 
code either becomes unreachable or else does not do what may be expected.


David
-

On 23/09/2016 2:04 AM, Brent Christian wrote:

Hi,

Looks like my 8165372 change broke the slowdebug build.  Please review
my fix (which also breaks up a pretty long line):

--- a/src/share/vm/prims/stackwalk.cpp
+++ b/src/share/vm/prims/stackwalk.cpp
@@ -331,10 +331,12 @@
 assert (use_frames_array(mode), "Bad mode for get live frame");
 RegisterMap regMap(jt, true);
 LiveFrameStream stream(jt, );
-return fetchFirstBatch(stream, stackStream, mode, skip_frames,
frame_count, start_index, frames_array, CHECK_NULL);
+return fetchFirstBatch(stream, stackStream, mode, skip_frames,
frame_count,
+   start_index, frames_array, THREAD);
   } else {
 JavaFrameStream stream(jt, mode);
-return fetchFirstBatch(stream, stackStream, mode, skip_frames,
frame_count, start_index, frames_array, CHECK_NULL);
+return fetchFirstBatch(stream, stackStream, mode, skip_frames,
frame_count,
+   start_index, frames_array, THREAD);
   }
 }

Thanks!
-Brent

Re: [concurrency-interest] We need to add blocking methods to CompletionStage!

[Martin Buchholz]

Thanks for the lesson, James!

On Wed, Sep 21, 2016 at 3:57 PM, James Roper  wrote:

> On 22 September 2016 at 06:43, Martin Buchholz 
> wrote:
>
>> What is happening instead is API providers not using CompletionStage as
>> return values in public APIs because of the lack of convenient blocking,
>> and instead returning CompletableFuture, which is a tragic software
>> engineering failure.
>>
>
> Out of interest, which APIs are returning CompletableFuture rather than
> CompletionStage?  In the Play Framework Java API, we have embraced
> CompletionStage, we use it absolutely everywhere.  Likewise in Lagom
> Framework and the Java API for Akka streams.
>
> When it comes to blocking, we strongly advocate never blocking (in the
> threading models of these projects, blocking on a future will make you very
> prone to deadlocks).
>

I took a look at the Scala/Akka/LightBend world.  Even there, blocking
always remains a possibility, even if discouraged, e.g.
scala.concurrent.Future extends Awaitable (!), and
http://doc.akka.io/docs/akka/snapshot/general/actor-systems.html#Blocking_Needs_Careful_Management
.
And any general purpose Java API needs to be useful outside of a framework.


>   But of course, the exception is junit tests, in that case, we encourage
> the use of CompletionStage.toCompletableFuture to block.
>

We're currently fixing jdk9
CompletableFuture.minimalCompletionStage().toCompletableFuture() to be
awaitable.

To make toCompletableFuture().join() more reliable as a recommended way to
block, I think we should remove the encouragement to throw UOE from:
http://download.java.net/java/jdk9/docs/api/java/util/concurrent/CompletionStage.html#toCompletableFuture--

It sounds like the Akka/LightBend World is happy with current
CompletionStage API (may I call this the "actor purist API"?), while other
users will want a bigger, more general CompletableFuture subset for
consuming future values.  Frustratingly, some of them will want cancel(),
some not; and we have no good names for any new interfaces; right now all I
can think of is CompletionStage2 and CompletionStage3 !)

The current implementation of CompletableFuture has a "memory leak problem"
in that e.g. minimalStage().toCompletableFuture().isDone() will leak a
Completion object until the source stage itself is collected.  Which
doesn't happen if e.g. a direct isDone() is provided.
JDK-8161600: Garbage retention when source CompletableFutures are never
completed
(but no one has ever complained!)

Re: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code

[Mandy Chung]

That’d be fine.

Mandy

> On Sep 22, 2016, at 11:43 AM, Sean Coffey  wrote:
> 
> Thanks Mandy. I pushed this change earlier today. If BasicImageReader.java is 
> being edited again in the near future, we might be able to make your 
> suggested edits then.
> 
> regards,
> Sean.
> 
> On 22/09/2016 19:23, Mandy Chung wrote:
>>> On Sep 21, 2016, at 8:56 AM, Seán Coffey  wrote:
>>> 
>>> Resurrecting this old review thread. After some internal discussion, I've 
>>> dropped the minor edit that was made in StackTraceElementCompositeData. It 
>>> could be noisy data for exception purposes. I've corrected the other issues 
>>> raised by Alan and Jim has long pushed the changes mentioned below.
>>> 
>>> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832.v3/webrev/
>> The change looks okay.
>> 
>> src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java
>>  189 throw new IOException("The image file \"" + name + "\" is 
>> not " +
>>  190 "the correct version. Major: " + 
>> result.getMajorVersion() +
>>  191 ". Minor: " + result.getMinorVersion());
>> 
>> One suggestion for this exception message to:
>> 
>>   throw new IOException("The image file \"" + name + "\” version “ +
>>  result.getMajorVersion() + "." + result.getMinorVersion() +
>>  “ not supported”);
>> 
>> No need for a new webrev and you can update this before you push.
>> 
>> Mandy
> 

Re: RFR 8166501 : compilation error in stackwalk.cpp on some gccs

[Dmitry Samersoff]

Brent,

Looks good for me.

-Dmitry

On 2016-09-22 19:04, Brent Christian wrote:
> Hi,
> 
> Looks like my 8165372 change broke the slowdebug build.  Please review
> my fix (which also breaks up a pretty long line):
> 
> --- a/src/share/vm/prims/stackwalk.cpp
> +++ b/src/share/vm/prims/stackwalk.cpp
> @@ -331,10 +331,12 @@
>  assert (use_frames_array(mode), "Bad mode for get live frame");
>  RegisterMap regMap(jt, true);
>  LiveFrameStream stream(jt, );
> -return fetchFirstBatch(stream, stackStream, mode, skip_frames,
> frame_count, start_index, frames_array, CHECK_NULL);
> +return fetchFirstBatch(stream, stackStream, mode, skip_frames,
> frame_count,
> +   start_index, frames_array, THREAD);
>} else {
>  JavaFrameStream stream(jt, mode);
> -return fetchFirstBatch(stream, stackStream, mode, skip_frames,
> frame_count, start_index, frames_array, CHECK_NULL);
> +return fetchFirstBatch(stream, stackStream, mode, skip_frames,
> frame_count,
> +   start_index, frames_array, THREAD);
>}
>  }
> 
> Thanks!
> -Brent
> 


-- 
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: 8151832: Improve exception messages in exceptions thrown by jigsaw code

[Sean Coffey]

Thanks Mandy. I pushed this change earlier today. If 
BasicImageReader.java is being edited again in the near future, we might 
be able to make your suggested edits then.


regards,
Sean.

On 22/09/2016 19:23, Mandy Chung wrote:

On Sep 21, 2016, at 8:56 AM, Seán Coffey  wrote:

Resurrecting this old review thread. After some internal discussion, I've 
dropped the minor edit that was made in StackTraceElementCompositeData. It 
could be noisy data for exception purposes. I've corrected the other issues 
raised by Alan and Jim has long pushed the changes mentioned below.

webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832.v3/webrev/

The change looks okay.

src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java
  189 throw new IOException("The image file \"" + name + "\" is not 
" +
  190 "the correct version. Major: " + result.getMajorVersion() 
+
  191 ". Minor: " + result.getMinorVersion());

One suggestion for this exception message to:

   throw new IOException("The image file \"" + name + "\” version “ +
  result.getMajorVersion() + "." + result.getMinorVersion() +
  “ not supported”);

No need for a new webrev and you can update this before you push.

Mandy

Re: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code

[Mandy Chung]

> On Sep 21, 2016, at 8:56 AM, Seán Coffey  wrote:
> 
> Resurrecting this old review thread. After some internal discussion, I've 
> dropped the minor edit that was made in StackTraceElementCompositeData. It 
> could be noisy data for exception purposes. I've corrected the other issues 
> raised by Alan and Jim has long pushed the changes mentioned below.
> 
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832.v3/webrev/

The change looks okay. 

src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java
 189 throw new IOException("The image file \"" + name + "\" is not 
" +
 190 "the correct version. Major: " + result.getMajorVersion() 
+ 
 191 ". Minor: " + result.getMinorVersion());

One suggestion for this exception message to:

  throw new IOException("The image file \"" + name + "\” version “ + 
 result.getMajorVersion() + "." + result.getMinorVersion() +
 “ not supported”);

No need for a new webrev and you can update this before you push.

Mandy

Re: RFR(L): 8161211: better inlining support for loop bytecode intrinsics

[John Rose]

On Sep 22, 2016, at 12:23 AM, Michael Haupt  wrote:

> thanks for your review, and thanks Vladimir! I've had another go at the 
> implementation to use a dedicated loop clause holder class with a stable 
> array; performance is roughly on par with that of the BMHs-as-arrays approach 
> (see below).
> 
> The new webrev is at http://cr.openjdk.java.net/~mhaupt/8161211/webrev.01/ 
> ; please review.

Yes, that's cleaner.

Suggestion:  Filter all loop clause functions with ".asFixedArity" when you 
wrap up the constant array.
This will do two things:  1. double-check for nulls (which @Stable doesn't 
like) and 2. allow you to
omit all asFixedArity calls from the driver function (MHI.loop).  The 
asFixedArity normalization could
move into MethodHandles.java, in fact, since that's part of the advertised 
semantics (hmm, right?).

Also (this is a nit) consider commoning (binding a temp for) the three 
expressions 'init[i]' in the driver.
I noticed that while peeking at the asFixedArity calls.  The JIT will DTRT 
here, but we might as well
make its job a bit easier.  JITs enjoy little favors like that; they are less 
likely to drop optimizations.

Reviewed!

— John

Re: RFR: 8166398: CatalogSupport tests need to be fixed -> Re: RFR: 8166220: Catalog API: JAXP XML Processor Support - add StAX test coverage

[Joe Wang]

Thanks Daniel!

I'm glad the issue was caught! I'm also making sure any the debugging 
method shall throw Exception as well :-)


Best,
Joe

On 9/22/16, 2:09 AM, Daniel Fuchs wrote:

Hi Joe,

Looks good to me.

Thanks for having taken the time to take a second look :-)

best regards,

-- daniel

On 21/09/16 17:47, Joe Wang wrote:

Hi Daniel,

Here's the fix for the test issues, a couple of errors including missing
handler in StAX test, and dtd was mistakingly typed as xsd . The root
cause is a debugging assertEquals method that printed out debugging
message without throwing Exception. I've searched the jaxp/test to make
sure this is the only case where this is used.

While fixing the tests, also refactored the code so that the use-catalog
is checked as a top condition, removed a ObjectFactory call in the 
course.


JBS: https://bugs.openjdk.java.net/browse/JDK-8166398
webrev: http://cr.openjdk.java.net/~joehw/jdk9/8166398/webrev/

Thanks,
Joe

On 9/20/16, 11:22 AM, Joe Wang wrote:



On 9/20/16, 2:20 AM, Daniel Fuchs wrote:

Hi Joe,

test/javax/xml/jaxp/unittest/catalog/CatalogSupportBase.java

 603 /**
 604  * Returns the text of the first element found by the reader.
 605  * @param streamReader the XMLStreamReader
 606  * @return the text of the first element
 607  * @throws XMLStreamException
 608  */
 609 String getText(XMLStreamReader streamReader, int type)
throws XMLStreamException {

It would be good to update the javadoc of this method (in particular
document the new 'type' parameter) so that future maintainer
can understand what that method is supposed to do.


Thanks Daniel!  I'll fix this.

As I went through the tests again, I found there's actually an error
in the StAX test where the handler was missed. I filed a new bug:
https://bugs.openjdk.java.net/browse/JDK-8166398



In particular would it be OK to encounter both CHARACTERS and
ENTITY_REFERENCE, or are these exclusive. If they are should some
exception be thrown?


They can't. At any given point, the StAX parser returns an unique
event and its event type.


I can't say I understand how the new test works, but nothing
else jumped at me in your webrev :-)


The incorrect javadoc was enough to raise an alarm, that this part of
code was copied and forgot to update. It led me to double-check the
code and found the issue (JDK-8166398). I really appreciate it!

Best,
Joe


best regards,

-- daniel


On 19/09/16 20:11, Joe Wang wrote:

Hi,

Please review an addition of StAX tests to the Catalog Support test
set.

JBS: https://bugs.openjdk.java.net/browse/JDK-8166220
webrev: http://cr.openjdk.java.net/~joehw/jdk9/8166220/webrev/

Thanks,
Joe

Re: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code

[Sean Coffey]

On 22/09/2016 14:14, Alan Bateman wrote:
This looks okay to me. You may want to change the bug message to drop 
"thrown by jigsaw code" as most of the changed files are jimage or 
other areas.

Thanks Alan - Yes - will correct that before I push then.

regards,
Sean.

Re: RFR: jsr166 jdk9 integration wave 11

[Martin Buchholz]

On Thu, Sep 22, 2016 at 5:39 AM, Chris Hegarty 
wrote:

>
> Can you please check the indentation in testCopy_normalCompletion
> and testCopy_exceptionalCompletion.
>

CompletableFutureTest.java has a unique experimental indentation style,
that is not clearly worse than the alternatives.

Re: RFR: 8151832: Improve exception messages in exceptions thrown by jigsaw code

[Alan Bateman]

On 21/09/2016 08:56, Seán Coffey wrote:

Resurrecting this old review thread. After some internal discussion, 
I've dropped the minor edit that was made in 
StackTraceElementCompositeData. It could be noisy data for exception 
purposes. I've corrected the other issues raised by Alan and Jim has 
long pushed the changes mentioned below.


webrev : http://cr.openjdk.java.net/~coffeys/webrev.8151832.v3/webrev/
This looks okay to me. You may want to change the bug message to drop 
"thrown by jigsaw code" as most of the changed files are jimage or other 
areas.


-Alan

Re: RFR: jsr166 jdk9 integration wave 11

[Chris Hegarty]

On 21 Sep 2016, at 20:33, Martin Buchholz  wrote:
> 
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/
> 
> Notable here is an attempt to make a minimal completion stage more acceptable 
> as a return value from APIs, by making 
> completableFuture.minimalCompletionStage().toCompletableFuture() useful.

Looks good.

CompletableFuture.minimalCompletionStage().toCompletableFuture(),
this is subtle. I think what you have is right. Thankfully
CS::toCompletableFuture allows this; "If this stage is already a
CompletableFuture, this method MAY return this stage itself."

Can you please check the indentation in testCopy_normalCompletion
and testCopy_exceptionalCompletion.

-Chris.

Re: We need to add blocking methods to CompletionStage!

[Chris Hegarty]

Until now CS and CF have not appeared in Java SE API signatures,
outside of the j.u.c package. They are, however, currently being
proposed for use in API signatures for Java SE 9 [1][2], namely
j.l.Process[Handle]::onExit, and more extensively in the proposed new
HTTP Client.

CF was chosen, in some cases, mainly because it provides 'join'. While
some may not like it, a large number of developers still, at some point,
want to be able to block. It was felt that CF was more convenient,
rather than the CS::toCF dance.

In some cases CF provides too many knobs and is not quite suited. For
example, the java.net.http package description has the following
paragraph [3]:

 *  {@code CompletableFuture}s returned by this API will throw
 * {@link java.lang.UnsupportedOperationException} for their {@link
 * java.util.concurrent.CompletableFuture#obtrudeValue(Object) obtrudeValue}
 * and {@link java.util.concurrent.CompletableFuture#obtrudeException(Throwable)
 * obtrudeException} methods. Invoking the {@link
 * java.util.concurrent.CompletableFuture#cancel cancel} method on a
 * {@code CompletableFuture} returned by this API will not interrupt
 * the underlying operation, but may be useful to complete, exceptionally,
 * dependent stages that have not already completed.

At a minimum adding 'join' to CS would help ( and may cause the above
usages in JDK 9 to be revisited ). If this is not acceptable, or maybe
even separately, is there any appetite for a type between CS and CF,
that would expose a select set of methods ( which methods tbd ) that are
"more suited" [*] for use in the above kind of APIs, where the platform
or library is using them as a notification mechanism ( cancel may, or
may not, be useful to notify the platform / library that the operation /
result is no longer interesting, albeit somewhat of a hint ).

-Chris.

[1] 
http://download.java.net/java/jdk9/docs/api/java/util/concurrent/class-use/CompletableFuture.html
[2] 
http://download.java.net/java/jdk9/docs/api/java/util/concurrent/class-use/CompletionStage.html
[3] 
http://hg.openjdk.java.net/jdk9/sandbox/jdk/file/1fdd889687c8/src/java.httpclient/share/classes/java/net/http/package-info.java#l46
[*] for some definition of ...

> On 21 Sep 2016, at 21:43, Martin Buchholz  wrote:
> 
> (Sorry to re-open this discussion)
> 
> The separation of a read-only CompletionStage from CompletableFuture is 
> great.  I'm a fan of the scala style Promise/Future split as described in 
> http://docs.scala-lang.org/overviews/core/futures.html, but: we need to 
> re-add (safe, read-only) blocking methods like join.  Java is not Node.js, 
> where there are no threads but there is a universal event loop.  Java 
> programmers are used to Future, where the *only* way to use a future's value 
> is to block waiting for it.  The existing CompletionStage methods are a 
> better scaling alternative to blocking all the time, but blocking is almost 
> always eventually necessary in Java.  For example, junit test methods that 
> start any asynchronous computation need to block until the computation is 
> done, before returning.
> 
> As Viktor has pointed out, users can always implement blocking themselves by 
> writing
> 
> static  CompletableFuture toCompletableFuture(CompletionStage 
> stage) {
> CompletableFuture f = new CompletableFuture<>();
> stage.handle((T t, Throwable ex) -> {
>  if (ex != null) f.completeExceptionally(ex);
>  else f.complete(t);
>  return null;
>  });
> return f;
> }
> 
> static  T join(CompletionStage stage) {
> return toCompletableFuture(stage).join();
> }
> 
> but unlike Viktor, I think it's unreasonable to not provide this for users 
> (especially when we can do so more efficiently).  What is happening instead 
> is API providers not using CompletionStage as return values in public APIs 
> because of the lack of convenient blocking, and instead returning 
> CompletableFuture, which is a tragic software engineering failure.
> 
> Re-adding join is easy.  We discourage CompletionStage.toCompletableFuture 
> from throwing UnsupportedOperationException, and implement join as:
> 
> public default T join() { return toCompletableFuture().join(); }
> 
> There is a risk of multiple-inheritance conflict with Future if we add e.g. 
> isDone(), but there are no current plans to turn those Future methods into 
> default methods, and even if we did in some future release, it would be only 
> a source, not binary incompatibility, so far less serious.

Re: RFR: 8166398: CatalogSupport tests need to be fixed -> Re: RFR: 8166220: Catalog API: JAXP XML Processor Support - add StAX test coverage

[Daniel Fuchs]

Hi Joe,

Looks good to me.

Thanks for having taken the time to take a second look :-)

best regards,

-- daniel

On 21/09/16 17:47, Joe Wang wrote:

Hi Daniel,

Here's the fix for the test issues, a couple of errors including missing
handler in StAX test, and dtd was mistakingly typed as xsd . The root
cause is a debugging assertEquals method that printed out debugging
message without throwing Exception. I've searched the jaxp/test to make
sure this is the only case where this is used.

While fixing the tests, also refactored the code so that the use-catalog
is checked as a top condition, removed a ObjectFactory call in the course.

JBS: https://bugs.openjdk.java.net/browse/JDK-8166398
webrev: http://cr.openjdk.java.net/~joehw/jdk9/8166398/webrev/

Thanks,
Joe

On 9/20/16, 11:22 AM, Joe Wang wrote:



On 9/20/16, 2:20 AM, Daniel Fuchs wrote:

Hi Joe,

test/javax/xml/jaxp/unittest/catalog/CatalogSupportBase.java

 603 /**
 604  * Returns the text of the first element found by the reader.
 605  * @param streamReader the XMLStreamReader
 606  * @return the text of the first element
 607  * @throws XMLStreamException
 608  */
 609 String getText(XMLStreamReader streamReader, int type)
throws XMLStreamException {

It would be good to update the javadoc of this method (in particular
document the new 'type' parameter) so that future maintainer
can understand what that method is supposed to do.


Thanks Daniel!  I'll fix this.

As I went through the tests again, I found there's actually an error
in the StAX test where the handler was missed. I filed a new bug:
https://bugs.openjdk.java.net/browse/JDK-8166398



In particular would it be OK to encounter both CHARACTERS and
ENTITY_REFERENCE, or are these exclusive. If they are should some
exception be thrown?


They can't. At any given point, the StAX parser returns an unique
event and its event type.


I can't say I understand how the new test works, but nothing
else jumped at me in your webrev :-)


The incorrect javadoc was enough to raise an alarm, that this part of
code was copied and forgot to update. It led me to double-check the
code and found the issue (JDK-8166398). I really appreciate it!

Best,
Joe


best regards,

-- daniel


On 19/09/16 20:11, Joe Wang wrote:

Hi,

Please review an addition of StAX tests to the Catalog Support test
set.

JBS: https://bugs.openjdk.java.net/browse/JDK-8166220
webrev: http://cr.openjdk.java.net/~joehw/jdk9/8166220/webrev/

Thanks,
Joe

Re: RFR(L): 8161211: better inlining support for loop bytecode intrinsics

[Michael Haupt]

Hi John,

thanks for your review, and thanks Vladimir! I've had another go at the 
implementation to use a dedicated loop clause holder class with a stable array; 
performance is roughly on par with that of the BMHs-as-arrays approach (see 
below).

The new webrev is at http://cr.openjdk.java.net/~mhaupt/8161211/webrev.01/; 
please review.

Thanks,

Michael




Benchmark(iterations) unpatchedpatched
CntL.Cr.cr3  N/A  16039.10815821.583
CntL.Cr.cr4  N/A  15621.95915869.730
CntL.Inv.bl3 02.8582.835
CntL.Inv.bl3 15.1255.179
CntL.Inv.bl3 10   11.887   12.005
CntL.Inv.bl3 100  67.441   67.279
CntL.Inv.bl4 02.8552.858
CntL.Inv.bl4 15.1205.210
CntL.Inv.bl4 10   11.875   12.012
CntL.Inv.bl4 100  67.607   67.296
CntL.Inv.blMH3   09.7349.722
CntL.Inv.blMH3   115.689   15.865
CntL.Inv.blMH3   10   68.912   69.098
CntL.Inv.blMH3   100  605.666  605.526
CntL.Inv.blMH4   014.561   13.274
CntL.Inv.blMH4   119.543   19.709
CntL.Inv.blMH4   10   71.977   72.446
CntL.Inv.blMH4   100  596.842  598.271
CntL.Inv.cntL3   049.339   6.311
CntL.Inv.cntL3   195.444   7.333
CntL.Inv.cntL3   10   508.746  20.930
CntL.Inv.cntL3   100  4701.808 147.383
CntL.Inv.cntL4   049.443   5.780
CntL.Inv.cntL4   198.721   7.465
CntL.Inv.cntL4   10   503.825  20.932
CntL.Inv.cntL4   100  4681.803 147.278
DoWhL.Cr.cr  N/A  7628.312 7803.187
DoWhL.Inv.bl 13.8683.869
DoWhL.Inv.bl 10   16.480   16.528
DoWhL.Inv.bl 100  144.260  144.290
DoWhL.Inv.blMH   114.434   14.430
DoWhL.Inv.blMH   10   92.542   92.733
DoWhL.Inv.blMH   100  877.480  876.735
DoWhL.Inv.doWhL  126.791   7.134
DoWhL.Inv.doWhL  10   158.985  17.004
DoWhL.Inv.doWhL  100  1391.746 133.253
ItrL.Cr.cr   N/A  13547.49913248.913
ItrL.Inv.bl  02.9732.983
ItrL.Inv.bl  16.7716.705
ItrL.Inv.bl  10   14.955   14.952
ItrL.Inv.bl  100  81.842   82.152
ItrL.Inv.blMH014.893   15.014
ItrL.Inv.blMH120.998   21.459
ItrL.Inv.blMH10   73.677   73.888
ItrL.Inv.blMH100  613.913  615.208
ItrL.Inv.itrL033.583   10.842
ItrL.Inv.itrL182.239   13.573
ItrL.Inv.itrL10   448.356  38.773
ItrL.Inv.itrL100  4189.034 279.918
L.Cr.cr  N/A  15505.97015640.994
L.Inv0.bl13.1793.186
L.Inv0.bl10   5.9525.912
L.Inv0.bl100  50.942   50.964
L.Inv0.lo146.454   5.290
L.Inv0.lo10   514.230  8.492
L.Inv0.lo100  5166.251 52.187
L.Inv1.lo134.321   5.291
L.Inv1.lo10   430.839  8.474
L.Inv1.lo100  4095.302 52.173
TF.blEx  N/A  3.0052.986
TF.blMHExN/A  166.316  165.856
TF.blMHNor   N/A  9.3379.290
TF.blNor N/A  2.6962.682
TF.crN/A  406.255  415.090
TF.invTFEx   N/A  154.121  154.826
TF.invTFNor  N/A  5.3505.328
WhL.Cr.crN/A  12214.38312112.535
WhL.Inv.bl   03.8863.931
WhL.Inv.bl   15.3795.411
WhL.Inv.bl   10   16.000   16.203
WhL.Inv.bl   100  142.066  142.127
WhL.Inv.blMH 011.028   10.915
WhL.Inv.blMH 121.269   21.419
WhL.Inv.blMH 10   97.493   98.373
WhL.Inv.blMH 100  887.579  892.955
WhL.Inv.whL  024.829   7.082
WhL.Inv.whL  146.039   8.598
WhL.Inv.whL  10   240.963  21.108
WhL.Inv.whL  100  2092.671  

Re: RFR: 8166189: Fix for Bug 8165524 breaks AIX build

[Thomas Stüfe]

Hi Kumar,


> On 9/16/2016 10:34 AM, Volker Simonis wrote:
>
>> Hi Christoph,
>>
>> I think your change is fine as a quick-fix to fix the build. But
>> you're completely right that this should be reworked in the long term.
>> I hate to see that we now have the third version of these routines in
>> the OpenJDK. Unfortunately a clean solution is not trivial.
>>
>> libjli is not linked against libjvm because libjli is actually used to
>> load libjvm. So we can not put the dladdr routines for AIX there. But
>> I think we should at least consolidate the two versions which will be
>> in the class library after your change. Initially I intentionally put
>> porting_aix.{c,h} into jdk/aix/porting with the intent to make it
>> available to ALL jdk native libraries.
>>
>> Unfortunately, with the source code reorganization due to the modular
>> changes, the common, top-level aix repository had to go away and the
>> code was moved to src/java.desktop/aix/native/libawt/porting_aix.c.
>> With the reorganized, modularized source code layout and build system
>> it is not possible to share code between modules. We somehow have to
>> fix this although I currently don't know how. IF somebody has an idea,
>> please let me know :)
>>
>
> Why doesn't AIX support a Standard C API that most other
> *nix based OS'es support ?
>
>
dladdr() is not Posix, hence it should not be used in code that wants to be
portable across Unix systems. Afaik dladdr() is a propietary Solaris API
that was adapted by the glibc and slowly spread over to some other Unices,
but by no means all of them.

dladdr makes a number of assumptions about the architecture: e.g. that a C
function pointer points into the text segment of the binary instead of e.g.
a PLT, or that a loaded binary is placed continuously in memory (we only
have one dli_fbase in DL_info). So imho  it makes sense to not make this a
standard Posix API.

We (SAP) implemented dladdr atop of loadquery(), and this kind of works,
although we had to add some hacks to handle both real code addresses and C
function pointers. So the code is there, it is "just" a question of where
to place it.

Kind Regards, Thomas

Thanks
>
> Kumar
>
>
>
>> Regarding your change:
>>
>> - can you please move
>>
>> +#if defined(_AIX)
>> +#include "java_md_aix.h"
>> +#endif
>> +
>>
>> from java_md_common.c to the end of
>> java.base/unix/native/libjli/java_md.h. It will then be automatically
>> included into java_md_common.c trough java.h which includes java_md.h
>>
>> Also, this version of dladdr is inherently not thread safe. I don't
>> think that's a problem here, but it would be nice if you could quickly
>> check if that's indeed true.
>>
>> Besides that, looks good.
>>
>> Thanks for fixing,
>> Volker
>>
>>
>>
>>
>> On Fri, Sep 16, 2016 at 11:58 AM, Langer, Christoph
>>  wrote:
>>
>>> Hi,
>>>
>>> the fix for https://bugs.openjdk.java.net/browse/JDK-8165524 breaks the
>>> AIX build as function dladdr is not available on AIX.
>>>
>>> There already exist ports of that API in hotspot and awt. With the
>>> proposed change I duplicate the awt port to libjli. This is maybe only a
>>> quick fix - eventually we should think about consolidating and using the
>>> hotspot port in all places by exporting it from libjvm.so for AIX.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8166189
>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8166189.0/
>>>
>>> Thanks
>>> Christoph
>>>
>>>
>>> -Original Message-
 From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
 Behalf
 Of Kumar Srinivasan
 Sent: Montag, 12. September 2016 22:57
 To: core-libs-dev ; Mandy Chung
 ; Chris Bensen 
 Subject: RFR: 8165524: Better detect JRE that Linux JLI will be using

 Hello,

 I am sponsoring this changeset for Chris Bensen of the java packager
 team, please review  fix for the launcher to  better locate java.home.

 http://cr.openjdk.java.net/~ksrini/8165524/

 Thanks
 Kumar

>>>
>