Re: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage

[Claes Redestad]

On Mon, 13 Sep 2021 11:06:15 GMT, Сергей Цыпанов 
 wrote:

> Currently the method is implemented like
> 
> public List> parameterList() {
>   return Collections.unmodifiableList(Arrays.asList(ptypes.clone()));
> }
> 
> This seems to be excessive, as three objects are allocated here. Instead we 
> can use `List.of(ptypes)` which doesn't allocate anything for empty array and 
> for one of length 1 and 2 it allocates lightweight objects with 2 fields, 
> still copying longer arrays. This is likely to be fruitful as most of methods 
> have 0-2 parameters.
> 
> Also there is a couple of cases when `MethodType.parameterLis()` is called to 
> get its size, which is excessive either as we can use 
> `MethodType.parameterCount()` instead.

This change introduces a subtle behavior change in that `List.of` produce a 
`null`-hostile list, for example `list.contains(null)` will throw NPE. Does 
this need to be spelled out? (FTR I think such null-hostile behavior should be 
reconsidered)

-

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

Re: RFR: 8273656: Improve java.lang.invoke.MethodType.parameterList() and its usage

[John Rose]

On Sep 13, 2021, at 10:24 AM, Vladimir Ivanov 
mailto:vliva...@openjdk.java.net>> wrote:

BTW it can be improved even further by caching the immutable List view of 
parameters.

I would go further:  If I were writing MethodType.java today
I would probably use List.of as the backing store for the
parameters, instead of the private array.  So ptypes should
be List> not Class[].  I don’t think the footprint
or polymorphism effects would be dealbreakers, and the
code would (I think) be simpler overall.  But that’s a messy
change, since the array representation is dug in.

Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v6]

[David Holmes]

On Tue, 21 Sep 2021 13:10:57 GMT, Roger Riggs  wrote:

>> test/jdk/java/lang/ProcessBuilder/Basic.java line 2217:
>> 
>>> 2215: // A unique (59s) time is needed to avoid killing 
>>> other sleep processes.
>>> 2216: final String[] cmd = { "/bin/bash", "-c", 
>>> "(/bin/sleep 59)" };
>>> 2217: final String[] cmdkill = { "/bin/bash", "-c", 
>>> "(/usr/bin/pkill -f \"sleep 59\")" };
>> 
>> Maybe future RFE but why do we even need pkill here when we can get the PID 
>> of the sleep process we create and kill only that process?
>
> I thought of that too, but notice the parens "()" around that /bin/sleep; 
> that creates and extra level of forked processes and its harder to get that 
> pid. There probably is a way to traverse the hierarchy but I'll keep it as is 
> for now.

Ah right. Begs the question why we need to use bash to execute sleep? Could it 
be shell script instead of a binary?

-

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

Re: RFR: 8273546: DecimalFormat documentation contains literal HTML character references

[Lance Andersen]

On Tue, 21 Sep 2021 21:45:40 GMT, Naoto Sato  wrote:

> Simple doc fix.

Marked as reviewed by lancea (Reviewer).

-

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

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Scott Palmer]

I’ve uploaded a project that reproduces the problem to JDK-8274087 


Regards,

Scott 

> On Sep 21, 2021, at 3:49 PM, Scott Palmer  wrote:
> 
> I have discovered that I have to have my Java Agent configured  in the .cfg 
> file for it to happen:
> 
> [JavaOptions]
> java-option=-javaagent:$APPDIR\libs\MyAgent.jar
> 
> 
> The agent is needed in my real app only to get an instance of the 
> Instrumentation interface. In my test code, where I have reproduced this, it 
> is never used.  My test app just takes a URL and fetches it via a 
> HttpURLConnection with setInstanceFollowRedirects(false) so I can capture the 
> new location.  If you are still having trouble reproducing I will have the 
> code cleaned up for the bug report soon...
> 
> 
> Regards,
> 
> Scott
> 
> 
> 
>> On Sep 21, 2021, at 12:12 PM, Andy Herrick  wrote:
>> 
>> I thought I could create a reproduction scenario by using an app with 
>> "-splash:" arg then moving the jre as you did, but I have not 
>> yet been able make it fail.
>> 
>> /Andy
>> 
>> On 9/21/2021 11:43 AM, Scott Palmer wrote:
 On Sep 21, 2021, at 11:40 AM, Alan Bateman  wrote:
 
 On 21/09/2021 15:54, Andy Herrick wrote:
> I found the problem in 
> open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp
> 
> we call SetDllDirectory() with the path to the bin dir in the default 
> runtime directory, not the actual runtime directory.
> 
> since on Windows we never use other than the default runtime location - 
> we had not seen a problem, but is bug I will file and fix.
> 
 Good to see that you found it quickly. However I'm puzzled as why 
 initializingEncoding wasn't called, I would have expected the VM to blow 
 up during early startup. Would you have cycles to dig into that a bit more 
 in case something has been masked, like for example an exception being 
 swallowed.  Running with -Xlog:exceptions might reveal something.
>>> 
>>> Do you have a case that reproduces the issue?
>>> 
>>> Scott
> 

Re: RFR: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add() [v2]

[Iris Clark]

On Tue, 21 Sep 2021 22:18:07 GMT, Naoto Sato  wrote:

>> Fixing an AIOOBE on normalizing the month value.
>
> Naoto Sato has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Removed the unnecessary space

Marked as reviewed by iris (Reviewer).

-

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

Re: RFR: 8273546: DecimalFormat documentation contains literal HTML character references

[Iris Clark]

On Tue, 21 Sep 2021 21:45:40 GMT, Naoto Sato  wrote:

> Simple doc fix.

Marked as reviewed by iris (Reviewer).

-

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

Re: RFR: 8273546: DecimalFormat documentation contains literal HTML character references

[Brian Burkhalter]

On Tue, 21 Sep 2021 21:45:40 GMT, Naoto Sato  wrote:

> Simple doc fix.

Marked as reviewed by bpb (Reviewer).

-

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

Re: RFR: 8273546: DecimalFormat documentation contains literal HTML character references

[Joe Wang]

On Tue, 21 Sep 2021 21:45:40 GMT, Naoto Sato  wrote:

> Simple doc fix.

Marked as reviewed by joehw (Reviewer).

-

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

Re: RFR: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add() [v2]

[Joe Wang]

On Tue, 21 Sep 2021 22:18:07 GMT, Naoto Sato  wrote:

>> Fixing an AIOOBE on normalizing the month value.
>
> Naoto Sato has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Removed the unnecessary space

Marked as reviewed by joehw (Reviewer).

-

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

Re: RFR: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add() [v2]

[Naoto Sato]

> Fixing an AIOOBE on normalizing the month value.

Naoto Sato has updated the pull request incrementally with one additional 
commit since the last revision:

  Removed the unnecessary space

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5611/files
  - new: https://git.openjdk.java.net/jdk/pull/5611/files/92f81963..98612bf5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=5611=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5611=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5611/head:pull/5611

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

Re: RFR: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add() [v2]

[Naoto Sato]

On Tue, 21 Sep 2021 22:03:30 GMT, Joe Wang  wrote:

>> Naoto Sato has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Removed the unnecessary space
>
> src/java.base/share/classes/sun/util/calendar/BaseCalendar.java line 281:
> 
>> 279: month = 13 - (xm % 12);
>> 280: if (month == 13) {
>> 281: year ++;
> 
> Not that it matters, just happen to see it ;-). Is it more common to have no 
> space before the increment operator? Code convention seems to suggest no 
> space before increment and their operands. 
> No update needed should you decide to remove it.

Thanks. Indeed it was in the coding convention. Removed.

-

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

Re: RFR: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add()

[Joe Wang]

On Tue, 21 Sep 2021 12:47:00 GMT, Naoto Sato  wrote:

> Fixing an AIOOBE on normalizing the month value.

Marked as reviewed by joehw (Reviewer).

src/java.base/share/classes/sun/util/calendar/BaseCalendar.java line 281:

> 279: month = 13 - (xm % 12);
> 280: if (month == 13) {
> 281: year ++;

Not that it matters, just happen to see it ;-). Is it more common to have no 
space before the increment operator? Code convention seems to suggest no space 
before increment and their operands. 
No update needed should you decide to remove it.

-

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

Re: RFR: 8274075: Fix miscellaneous typos in java.base [v2]

[David Holmes]

On Tue, 21 Sep 2021 17:52:31 GMT, Brian Burkhalter  wrote:

>> We can either revert this part of the change or rephrase it. Mind you, 
>> rephrasing might prove tricky because of non-local changes it might 
>> introduce. There's one more occurrence of "wrapped exception" in this file: 
>> https://github.com/openjdk/jdk/blob/19b6f49649a317e6b255aeb810c8d533119b93bb/src/java.base/share/classes/java/lang/Throwable.java#L548-L554
>
> Instead of "common case where a wrapped exception is thrown from same method" 
> could one write "common case where an enclosing exception is thrown from the 
> same method"?

Note that we don't throw the "wrapped exception" we throw the exception that 
wraps it. The "wrapped exception" is the original cause. The wording as 
presented now is correct in that regard. You could also say "Throwing a wrapper 
exception (i.e. one that has a cause)" - I think both are grammatically correct.

The later text "where a wrapped exception is thrown from the same method" is 
again incorrect because the wrapped exception (the cause) is not what gets 
thrown. But I find that whole sentence rather jarring anyway - I'm not certain 
exactly what it means.

-

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

RFR: 8273546: DecimalFormat documentation contains literal HTML character references

[Naoto Sato]

Simple doc fix.

-

Commit messages:
 - 8273546: DecimalFormat documentation contains literal HTML character 
references

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

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

Re: Unused HashMap's in ThaiBuddhistChronology

[Roger Riggs]

Indeed, they seem unused...

Stephen, do you recall their original use?

Thanks, Roger


On 9/21/21 5:09 PM, Andrey Turbanov wrote:

Hello.
Today I discovered 3 static HashMap's in ThaiBuddhistChronology class:
ERA_NARROW_NAMES, ERA_SHORT_NAMES, ERA_FULL_NAMES

static initializer put some values into them. But their content seems
unused after that.
Do I miss something and they are used somewhere?


Andrey Turbanov

Unused HashMap's in ThaiBuddhistChronology

[Andrey Turbanov]

Hello.
Today I discovered 3 static HashMap's in ThaiBuddhistChronology class:
ERA_NARROW_NAMES, ERA_SHORT_NAMES, ERA_FULL_NAMES

static initializer put some values into them. But their content seems
unused after that.
Do I miss something and they are used somewhere?


Andrey Turbanov

Re: RFR: 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0

[Brian Burkhalter]

On Tue, 21 Sep 2021 19:33:05 GMT, Roger Riggs  wrote:

> The Mac OS specific code to determine the os.version property in 
> java_props_macosx.c is updated
> to replace the code extracting the version from the SystemVersion.plist by 
> reading the version using the hidden link:
>`/System/Library/CoreServices/.SystemVersionPlatform.plist`
> 
> Its contents are not dependent on the SYSTEM_VERSION_COMPAT environment 
> variable.
> With this change, 11.5 reports the 11.5.1 minor version and os.version 11.6 
> is correctly reported.
> The change can be backported to other versions as needed.

Marked as reviewed by bpb (Reviewer).

-

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

RFR: 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0

[Roger Riggs]

The Mac OS specific code to determine the os.version property in 
java_props_macosx.c is updated
to replace the code extracting the version from the SystemVersion.plist by 
reading the version using the hidden link:
   `/System/Library/CoreServices/.SystemVersionPlatform.plist`

Its contents are not dependent on the SYSTEM_VERSION_COMPAT environment 
variable.
With this change, 11.5 reports the 11.5.1 minor version and os.version 11.6 is 
correctly reported.
The change can be backported to other versions as needed.

-

Commit messages:
 - 8269850: Most JDK releases report macOS version 12 as 10.16 instead of 12.0

Changes: https://git.openjdk.java.net/jdk/pull/5619/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5619=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8269850
  Stats: 11 lines in 1 file changed: 1 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5619.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5619/head:pull/5619

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

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Scott Palmer]

I have discovered that I have to have my Java Agent configured  in the .cfg 
file for it to happen:

[JavaOptions]
java-option=-javaagent:$APPDIR\libs\MyAgent.jar


The agent is needed in my real app only to get an instance of the 
Instrumentation interface. In my test code, where I have reproduced this, it is 
never used.  My test app just takes a URL and fetches it via a 
HttpURLConnection with setInstanceFollowRedirects(false) so I can capture the 
new location.  If you are still having trouble reproducing I will have the code 
cleaned up for the bug report soon...


Regards,

Scott



> On Sep 21, 2021, at 12:12 PM, Andy Herrick  wrote:
> 
> I thought I could create a reproduction scenario by using an app with 
> "-splash:" arg then moving the jre as you did, but I have not yet 
> been able make it fail.
> 
> /Andy
> 
> On 9/21/2021 11:43 AM, Scott Palmer wrote:
>>> On Sep 21, 2021, at 11:40 AM, Alan Bateman  wrote:
>>> 
>>> On 21/09/2021 15:54, Andy Herrick wrote:
 I found the problem in 
 open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp
 
 we call SetDllDirectory() with the path to the bin dir in the default 
 runtime directory, not the actual runtime directory.
 
 since on Windows we never use other than the default runtime location - we 
 had not seen a problem, but is bug I will file and fix.
 
>>> Good to see that you found it quickly. However I'm puzzled as why 
>>> initializingEncoding wasn't called, I would have expected the VM to blow up 
>>> during early startup. Would you have cycles to dig into that a bit more in 
>>> case something has been masked, like for example an exception being 
>>> swallowed.  Running with -Xlog:exceptions might reveal something.
>> 
>> Do you have a case that reproduces the issue?
>> 
>> Scott

Integrated: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported

[Lance Andersen]

On Sun, 19 Sep 2021 15:34:44 GMT, Lance Andersen  wrote:

> Hi all,
> 
> Please review this patch which addresses the issue where Zip FS will throw a 
> UOE instead of returning null  when  Files.getFileAttributeView() is invoked 
> and  the view not supported.
> 
> Mach5 tiers1 - tier3 are clean.
> 
> Best
> Lance

This pull request has now been integrated.

Changeset: 161fdb4a
Author:Lance Andersen 
URL:   
https://git.openjdk.java.net/jdk/commit/161fdb4afbc6e67cc7580fe753112c4d894a9b6b
Stats: 108 lines in 4 files changed: 102 ins; 0 del; 6 mod

8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning 
null when view not supported

Reviewed-by: alanb, bpb, sgehwolf

-

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

Re: RFR: 8274003: ProcessHandleImpl.Info toString has an if check which is always true

[Iris Clark]

On Tue, 21 Sep 2021 18:14:17 GMT, Roger Riggs  wrote:

> Correct the check if any field has been appended to the StringBuilder in 
> ProcessHandleImpl.Info.toString().

Marked as reviewed by iris (Reviewer).

-

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

Re: RFR: 8274003: ProcessHandleImpl.Info toString has an if check which is always true

[Naoto Sato]

On Tue, 21 Sep 2021 18:14:17 GMT, Roger Riggs  wrote:

> Correct the check if any field has been appended to the StringBuilder in 
> ProcessHandleImpl.Info.toString().

Marked as reviewed by naoto (Reviewer).

-

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

Re: RFR: 8274003: ProcessHandleImpl.Info toString has an if check which is always true

[Brian Burkhalter]

On Tue, 21 Sep 2021 18:14:17 GMT, Roger Riggs  wrote:

> Correct the check if any field has been appended to the StringBuilder in 
> ProcessHandleImpl.Info.toString().

Marked as reviewed by bpb (Reviewer).

-

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

RFR: 8274003: ProcessHandleImpl.Info toString has an if check which is always true

[Roger Riggs]

Correct the check if any field has been appended to the StringBuilder in 
ProcessHandleImpl.Info.toString().

-

Commit messages:
 - 8274003: ProcessHandleImpl.Info toString has an if check which is always true

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

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

Re: RFR: 8274075: Fix miscellaneous typos in java.base [v2]

[Brian Burkhalter]

On Tue, 21 Sep 2021 17:39:41 GMT, Pavel Rappo  wrote:

>> Would "wrappER" be better?
>
> We can either revert this part of the change or rephrase it. Mind you, 
> rephrasing might prove tricky because of non-local changes it might 
> introduce. There's one more occurrence of "wrapped exception" in this file: 
> https://github.com/openjdk/jdk/blob/19b6f49649a317e6b255aeb810c8d533119b93bb/src/java.base/share/classes/java/lang/Throwable.java#L548-L554

Instead of "common case where a wrapped exception is thrown from same method" 
could one write "common case where an enclosing exception is thrown from the 
same method"?

-

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

Re: RFR: 8274075: Fix miscellaneous typos in java.base [v2]

[Pavel Rappo]

On Tue, 21 Sep 2021 16:56:03 GMT, Lance Andersen  wrote:

>> src/java.base/share/classes/java/lang/Throwable.java line 68:
>> 
>>> 66:  * Further, doing so would tie the API of the upper layer to the 
>>> details of
>>> 67:  * its implementation, assuming the lower layer's exception was a 
>>> checked
>>> 68:  * exception.  Throwing a "wrapping exception" (i.e., an exception 
>>> containing a
>> 
>> Are we sure that this should be "wrapping" and not "wrapped?" See also for 
>> example `java.security.cert.CertPathValidatorException.`
>
> It does seem a bit strange to say "Throwing a wrapping"

If we have two exceptions A and B, such that B is the cause of A, then A is the 
wrapping exception (the one that wraps or the wrapper) and B is the wrapped 
exception (the one that is being wrapped or the wrappee).

I noticed that the sentence was conflicting: it started with the "wrapped" 
exception, but then in the "i.e." commentary in parentheses proceeded with the 
wrappee exception. To resolve that conflict, I proposed to rephrase the first 
part of that sentence. FWIW, my original suggestion elsewhere was to use 
"wrapper".

-

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

Re: RFR: 8274075: Fix miscellaneous typos in java.base [v2]

[Pavel Rappo]

On Tue, 21 Sep 2021 17:14:31 GMT, Pavel Rappo  wrote:

>> Subjectively, "wrapping exception" would seem to be an exception in the 
>> process of wrapping something.
>
> Would "wrappER" be better?

We can either revert this part of the change or rephrase it. Mind you, 
rephrasing might prove tricky because of non-local changes it might introduce. 
There's one more occurrence of "wrapped exception" in this file: 
https://github.com/openjdk/jdk/blob/19b6f49649a317e6b255aeb810c8d533119b93bb/src/java.base/share/classes/java/lang/Throwable.java#L548-L554

-

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

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5]

[Michael McMahon]

On Tue, 21 Sep 2021 14:09:54 GMT, Julia Boes  wrote:

>> This change implements a simple web server that can be run on the 
>> command-line with `java -m jdk.httpserver`.
>> 
>> This is facilitated by adding an entry point for the `jdk.httpserver` 
>> module, an implementation class whose main method is run when the above 
>> command is executed. This is the first such module entry point in the JDK.
>> 
>> The server is a minimal HTTP server that serves the static files of a given 
>> directory, similar to existing alternatives on other platforms and 
>> convenient for testing, development, and debugging.
>> 
>> Additionally, a small API is introduced for programmatic creation and 
>> customization.
>> 
>> Testing: tier1-3.
>
> Julia Boes has updated the pull request with a new target base due to a merge 
> or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into simpleserver
>  - Merge remote-tracking branch 'origin/simpleserver' into simpleserver
>  - Merge branch 'master' into simpleserver
>  - refactor isHidden,isReadable,isSymlink checks and cleanup tests
>  - Merge branch 'master' into simpleserver
>  - check isHidden, isSymlink, isReadable for all path segments 
>  - add checks for all path segments
>  - Merge branch 'master' into componentcheck
>  - Merge branch 'master' into simpleserver
>  - improve output on startup
>  - ... and 6 more: 
> https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131

src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/SimpleFileServerImpl.java
 line 135:

> 133: var socketAddr = new InetSocketAddress(addr, port);
> 134: var server = SimpleFileServer.createFileServer(socketAddr, 
> root, outputLevel);
> 135: server.setExecutor(Executors.newSingleThreadExecutor());

I think this code has the effect of creating one thread for the selector and a 
second one for the execution of the handlers. If we want to keep thread usage 
to an absolute minimum then it might be better to not set an executor. Then, 
the selector thread executes the handlers as well.

-

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

Re: RFR: 8274075: Fix miscellaneous typos in java.base [v2]

[Pavel Rappo]

On Tue, 21 Sep 2021 17:10:02 GMT, Brian Burkhalter  wrote:

>> If we have two exceptions A and B, such that B is the cause of A, then A is 
>> the wrapping exception (the one that wraps or the wrapper) and B is the 
>> wrapped exception (the one that is being wrapped or the wrappee).
>> 
>> I noticed that the sentence was conflicting: it started with the "wrapped" 
>> exception, but then in the "i.e." commentary in parentheses proceeded with 
>> the wrappee exception. To resolve that conflict, I proposed to rephrase the 
>> first part of that sentence. FWIW, my original suggestion elsewhere was to 
>> use "wrapper".
>
> Subjectively, "wrapping exception" would seem to be an exception in the 
> process of wrapping something.

Would "wrappER" be better?

-

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

Re: RFR: 8274075: Fix miscellaneous typos in java.base [v2]

[Brian Burkhalter]

On Tue, 21 Sep 2021 17:07:45 GMT, Pavel Rappo  wrote:

>> It does seem a bit strange to say "Throwing a wrapping"
>
> If we have two exceptions A and B, such that B is the cause of A, then A is 
> the wrapping exception (the one that wraps or the wrapper) and B is the 
> wrapped exception (the one that is being wrapped or the wrappee).
> 
> I noticed that the sentence was conflicting: it started with the "wrapped" 
> exception, but then in the "i.e." commentary in parentheses proceeded with 
> the wrappee exception. To resolve that conflict, I proposed to rephrase the 
> first part of that sentence. FWIW, my original suggestion elsewhere was to 
> use "wrapper".

Subjectively, "wrapping exception" would seem to be an exception in the process 
of wrapping something.

-

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

Re: RFR: 8274071: Clean up java.lang.ref comments and documentation

[Lance Andersen]

On Tue, 21 Sep 2021 12:05:27 GMT, Pavel Rappo  wrote:

> This PR fixes an inline comment typo and reduces "overlinking" in a doc 
> comment in `java.lang.ref.Reference`. Overlinking happens because the 
> `reachabilityFence` method:
>  * Links `package-summary.html#reachability` twice.
>  * Refers to JLS 12.6 twice: once from a block tag and once from an inline 
> tag.

Marked as reviewed by lancea (Reviewer).

-

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

Re: RFR: 8274075: Fix miscellaneous typos in java.base [v2]

[Lance Andersen]

On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo  wrote:

>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Tweak wording for Throwable constructor parameters

Overall looks like a good clean up.  just not sure of "wrapping" vs. "wrapped" 
given the sentence starts with "Throwing".

-

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

Re: RFR: 8274075: Fix miscellaneous typos in java.base [v2]

[Lance Andersen]

On Tue, 21 Sep 2021 16:48:53 GMT, Brian Burkhalter  wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Tweak wording for Throwable constructor parameters
>
> src/java.base/share/classes/java/lang/Throwable.java line 68:
> 
>> 66:  * Further, doing so would tie the API of the upper layer to the details 
>> of
>> 67:  * its implementation, assuming the lower layer's exception was a checked
>> 68:  * exception.  Throwing a "wrapping exception" (i.e., an exception 
>> containing a
> 
> Are we sure that this should be "wrapping" and not "wrapped?" See also for 
> example `java.security.cert.CertPathValidatorException.`

It does seem a bit strange to say "Throwing a wrapping"

-

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

Re: RFR: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add()

[Iris Clark]

On Tue, 21 Sep 2021 12:47:00 GMT, Naoto Sato  wrote:

> Fixing an AIOOBE on normalizing the month value.

Marked as reviewed by iris (Reviewer).

-

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

Re: RFR: 8274075: Fix miscellaneous typos in java.base [v2]

[Brian Burkhalter]

On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo  wrote:

>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Tweak wording for Throwable constructor parameters

src/java.base/share/classes/java/lang/Throwable.java line 68:

> 66:  * Further, doing so would tie the API of the upper layer to the details 
> of
> 67:  * its implementation, assuming the lower layer's exception was a checked
> 68:  * exception.  Throwing a "wrapping exception" (i.e., an exception 
> containing a

Are we sure that this should be "wrapping" and not "wrapped?" See also for 
example `java.security.cert.CertPathValidatorException.`

-

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

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5]

[Michael McMahon]

On Tue, 21 Sep 2021 14:09:54 GMT, Julia Boes  wrote:

>> This change implements a simple web server that can be run on the 
>> command-line with `java -m jdk.httpserver`.
>> 
>> This is facilitated by adding an entry point for the `jdk.httpserver` 
>> module, an implementation class whose main method is run when the above 
>> command is executed. This is the first such module entry point in the JDK.
>> 
>> The server is a minimal HTTP server that serves the static files of a given 
>> directory, similar to existing alternatives on other platforms and 
>> convenient for testing, development, and debugging.
>> 
>> Additionally, a small API is introduced for programmatic creation and 
>> customization.
>> 
>> Testing: tier1-3.
>
> Julia Boes has updated the pull request with a new target base due to a merge 
> or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into simpleserver
>  - Merge remote-tracking branch 'origin/simpleserver' into simpleserver
>  - Merge branch 'master' into simpleserver
>  - refactor isHidden,isReadable,isSymlink checks and cleanup tests
>  - Merge branch 'master' into simpleserver
>  - check isHidden, isSymlink, isReadable for all path segments 
>  - add checks for all path segments
>  - Merge branch 'master' into componentcheck
>  - Merge branch 'master' into simpleserver
>  - improve output on startup
>  - ... and 6 more: 
> https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131

Changes requested by michaelm (Reviewer).

-

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

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5]

[Julia Boes]

On Tue, 21 Sep 2021 16:18:54 GMT, Daniel Fuchs  wrote:

>> The problem I was referring to was not about printing to the console. I 
>> hadn't thought about that, I agree the default locale should be used there. 
>> I was referring to `Last-modified` HTTP headers with a non-English date 
>> value, e.g.:
>> 
>> Last-modified: Di., 21 Sep. 2021 09:56:53 GMT
>> 
>> I think browsers will get confused by this. It probably isn't a big deal 
>> since I think the server doesn't implement conditional GETs (i.e. use the 
>> last-modified date in subsequent requests), but the HTTP spec is [quite 
>> strict ][1] about date formats.
>> 
>> [1]: https://datatracker.ietf.org/doc/html/rfc2616#section-3.3.1
>
> Thanks for clarifying. Yes the date should be in GMT and should not be 
> localized when sent in a `Last-Modified` / `Date` headers. Good catch!

Good catch indeed, thanks! I'll update to GMT when used in the headers.

-

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

Re: RFR: 8274075: Fix miscellaneous typos in java.base [v2]

[Iris Clark]

On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo  wrote:

>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Tweak wording for Throwable constructor parameters

Marked as reviewed by iris (Reviewer).

-

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

Re: RFR: 8274071: Clean up java.lang.ref comments and documentation

[Iris Clark]

On Tue, 21 Sep 2021 12:05:27 GMT, Pavel Rappo  wrote:

> This PR fixes an inline comment typo and reduces "overlinking" in a doc 
> comment in `java.lang.ref.Reference`. Overlinking happens because the 
> `reachabilityFence` method:
>  * Links `package-summary.html#reachability` twice.
>  * Refers to JLS 12.6 twice: once from a block tag and once from an inline 
> tag.

Marked as reviewed by iris (Reviewer).

-

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

Re: RFR: 8274071: Clean up java.lang.ref comments and documentation

[Mandy Chung]

On Tue, 21 Sep 2021 12:05:27 GMT, Pavel Rappo  wrote:

> This PR fixes an inline comment typo and reduces "overlinking" in a doc 
> comment in `java.lang.ref.Reference`. Overlinking happens because the 
> `reachabilityFence` method:
>  * Links `package-summary.html#reachability` twice.
>  * Refers to JLS 12.6 twice: once from a block tag and once from an inline 
> tag.

Marked as reviewed by mchung (Reviewer).

-

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

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5]

[Daniel Fuchs]

On Tue, 21 Sep 2021 16:03:28 GMT, Hannes Wallnöfer  wrote:

>> Hmm... When printing messages on the console don't we want a localized date? 
>> Or are you referring to other usages of the date formatter?  Worth double 
>> checking in any case.
>
> The problem I was referring to was not about printing to the console. I 
> hadn't thought about that, I agree the default locale should be used there. I 
> was referring to `Last-modified` HTTP headers with a non-English date value, 
> e.g.:
> 
> Last-modified: Di., 21 Sep. 2021 09:56:53 GMT
> 
> I think browsers will get confused by this. It probably isn't a big deal 
> since I think the server doesn't implement conditional GETs (i.e. use the 
> last-modified date in subsequent requests), but the HTTP spec is [quite 
> strict ][1] about date formats.
> 
> [1]: https://datatracker.ietf.org/doc/html/rfc2616#section-3.3.1

Thanks for clarifying. Yes the date should be in GMT and should not be 
localized when sent in a `Last-Modified` / `Date` headers. Good catch!

-

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

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8]

[Mandy Chung]

On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung  wrote:

>> This reimplements core reflection with method handles.
>> 
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation 
>> uses `MethodHandle`.  For `Field` accessor, the new implementation uses 
>> `VarHandle`.For the first few invocations of one of these reflective 
>> methods on a specific reflective object we invoke the corresponding method 
>> handle directly. After that we spin a dynamic bytecode stub defined in a 
>> hidden class which loads the target `MethodHandle` or `VarHandle` from its 
>> class data as a dynamically computed constant. Loading the method handle 
>> from a constant allows JIT to inline the method-handle invocation in order 
>> to achieve good performance.
>> 
>> The VM's native reflection methods are needed during early startup, before 
>> the method-handle mechanism is initialized. That happens soon after 
>> System::initPhase1 and before System::initPhase2, after which we switch to 
>> using method handles exclusively.
>> 
>> The core reflection and method handle implementation are updated to handle 
>> chained caller-sensitive method calls [1] properly. A caller-sensitive 
>> method can define with a caller-sensitive adapter method that will take an 
>> additional caller class parameter and the adapter method will be annotated 
>> with `@CallerSensitiveAdapter` for better auditing.   See the detailed 
>> description from [2].
>> 
>> Ran tier1-tier8 tests.   
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8013527
>> [2] 
>> https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430
>
> Mandy Chung has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   minor cleanup and more test case.

> On balance I think removing class-spinning might mean a better overall story 
> w.r.t. footprint and maintainability. 
> : 
> So I think I'm in favor of simplifying and filing a follow-up to try and win 
> back some of the performance we might be losing on corner-case micros without 
> the custom class spinning.

Great!  I'll update the PR with Peter's patch + vh2mh with removal of 
StaticFieldAccessor/InstanceFieldAccessor inner classes [2] (no significant 
performance difference between [1] and [2]).

> I wish MethodHandles obtained by unreflectGetter/unreflectSetter could be 
> less sensitive to where they are read from (constant vs. not-constant) and 
> optimize better in non-constant case. I think we should search in this 
> direction... to make MethodHandles obtained by 
> unreflectGetter/unreflectSetter more optimal in non-constant case. 

Yup, that's what the performance opportunity we should explore to improve MH/VH 
that will benefit all clients of MH/VH as well as core reflection. 

[1] http://cr.openjdk.java.net/~mchung/jep416/vh-mh.patch
[2] http://cr.openjdk.java.net/~mchung/jep416/vh-mh-2.patch

-

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

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Andy Herrick]

I thought I could create a reproduction scenario by using an app with 
"-splash:" arg then moving the jre as you did, but I have 
not yet been able make it fail.


/Andy

On 9/21/2021 11:43 AM, Scott Palmer wrote:

On Sep 21, 2021, at 11:40 AM, Alan Bateman  wrote:

On 21/09/2021 15:54, Andy Herrick wrote:

I found the problem in 
open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp

we call SetDllDirectory() with the path to the bin dir in the default runtime 
directory, not the actual runtime directory.

since on Windows we never use other than the default runtime location - we had 
not seen a problem, but is bug I will file and fix.


Good to see that you found it quickly. However I'm puzzled as why 
initializingEncoding wasn't called, I would have expected the VM to blow up 
during early startup. Would you have cycles to dig into that a bit more in case 
something has been masked, like for example an exception being swallowed.  
Running with -Xlog:exceptions might reveal something.


Do you have a case that reproduces the issue?

Scott

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5]

[Hannes Wallnöfer]

On Tue, 21 Sep 2021 15:27:12 GMT, Daniel Fuchs  wrote:

>> I just realized I commented on a test file, while the actual culprit is in 
>> `FileServerHandler.java`. But I guess it applies to all usages of this class 
>> and method.
>
> Hmm... When printing messages on the console don't we want a localized date? 
> Or are you referring to other usages of the date formatter?  Worth double 
> checking in any case.

The problem I was referring to was not about printing to the console. I hadn't 
thought about that, I agree the default locale should be used there. I was 
referring to `Last-modified` HTTP headers with a non-English date value, e.g.:

Last-modified: Di., 21 Sep. 2021 09:56:53 GMT

I think browsers will get confused by this. It probably isn't a big deal since 
I think the server doesn't implement conditional GETs (i.e. use the 
last-modified date in subsequent requests), but the HTTP spec is [quite strict 
][1] about date formats.

[1]: https://datatracker.ietf.org/doc/html/rfc2616#section-3.3.1

-

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

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5]

[Michael McMahon]

On Tue, 21 Sep 2021 14:09:54 GMT, Julia Boes  wrote:

>> This change implements a simple web server that can be run on the 
>> command-line with `java -m jdk.httpserver`.
>> 
>> This is facilitated by adding an entry point for the `jdk.httpserver` 
>> module, an implementation class whose main method is run when the above 
>> command is executed. This is the first such module entry point in the JDK.
>> 
>> The server is a minimal HTTP server that serves the static files of a given 
>> directory, similar to existing alternatives on other platforms and 
>> convenient for testing, development, and debugging.
>> 
>> Additionally, a small API is introduced for programmatic creation and 
>> customization.
>> 
>> Testing: tier1-3.
>
> Julia Boes has updated the pull request with a new target base due to a merge 
> or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into simpleserver
>  - Merge remote-tracking branch 'origin/simpleserver' into simpleserver
>  - Merge branch 'master' into simpleserver
>  - refactor isHidden,isReadable,isSymlink checks and cleanup tests
>  - Merge branch 'master' into simpleserver
>  - check isHidden, isSymlink, isReadable for all path segments 
>  - add checks for all path segments
>  - Merge branch 'master' into componentcheck
>  - Merge branch 'master' into simpleserver
>  - improve output on startup
>  - ... and 6 more: 
> https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131

test/jdk/com/sun/net/httpserver/FilterTest.java line 330:

> 328: var response = client.send(request, 
> HttpResponse.BodyHandlers.ofString());
> 329: assertEquals(response.statusCode(), 200);
> 330: assertEquals(inspectedURI.get(), URI.create("/"));

Could you make the request URI something like /foo/bar instead of just / here?

-

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

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5]

[Daniel Fuchs]

On Tue, 21 Sep 2021 14:09:54 GMT, Julia Boes  wrote:

>> This change implements a simple web server that can be run on the 
>> command-line with `java -m jdk.httpserver`.
>> 
>> This is facilitated by adding an entry point for the `jdk.httpserver` 
>> module, an implementation class whose main method is run when the above 
>> command is executed. This is the first such module entry point in the JDK.
>> 
>> The server is a minimal HTTP server that serves the static files of a given 
>> directory, similar to existing alternatives on other platforms and 
>> convenient for testing, development, and debugging.
>> 
>> Additionally, a small API is introduced for programmatic creation and 
>> customization.
>> 
>> Testing: tier1-3.
>
> Julia Boes has updated the pull request with a new target base due to a merge 
> or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into simpleserver
>  - Merge remote-tracking branch 'origin/simpleserver' into simpleserver
>  - Merge branch 'master' into simpleserver
>  - refactor isHidden,isReadable,isSymlink checks and cleanup tests
>  - Merge branch 'master' into simpleserver
>  - check isHidden, isSymlink, isReadable for all path segments 
>  - add checks for all path segments
>  - Merge branch 'master' into componentcheck
>  - Merge branch 'master' into simpleserver
>  - improve output on startup
>  - ... and 6 more: 
> https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131

src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java
 line 314:

> 312: + "\n");
> 313: try (var paths = Files.list(path)) {
> 314: paths.filter(p -> !isHiddenOrSymLink(p))

Shouldn't we filter paths that are not readable here too? There's no point in 
printing a link that will result in 404, is there?

-

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

Re: RFR: 8274075: Fix miscellaneous typos in java.base [v2]

[Joe Darcy]

On Tue, 21 Sep 2021 13:16:02 GMT, Pavel Rappo  wrote:

>> 8274075: Fix miscellaneous typos in java.base
>
> Pavel Rappo has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Tweak wording for Throwable constructor parameters

Marked as reviewed by darcy (Reviewer).

-

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

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5]

[Daniel Fuchs]

On Tue, 21 Sep 2021 15:06:09 GMT, Hannes Wallnöfer  wrote:

>> test/jdk/com/sun/net/httpserver/simpleserver/SecurityManagerTest.java line 
>> 198:
>> 
>>> 196: 
>>> 197: static final DateTimeFormatter HTTP_DATE_FORMATTER =
>>> 198: DateTimeFormatter.ofPattern("EEE, dd MMM  HH:mm:ss v");
>> 
>> I think this and other usages of `DateTimeFormatter.ofPattern` need to be 
>> called with `Locale.US` (or something similar) as second argument, otherwise 
>> the current default locale will be used. I noticed because on my laptop the 
>> `Last-modified` header contains a german date.
>
> I just realized I commented on a test file, while the actual culprit is in 
> `FileServerHandler.java`. But I guess it applies to all usages of this class 
> and method.

Hmm... When printing messages on the console don't we want a localized date? Or 
are you referring to other usages of the date formatter?  Worth double checking 
in any case.

-

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

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Scott Palmer]

> On Sep 21, 2021, at 11:40 AM, Alan Bateman  wrote:
> 
> On 21/09/2021 15:54, Andy Herrick wrote:
>> 
>> I found the problem in 
>> open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp
>> 
>> we call SetDllDirectory() with the path to the bin dir in the default 
>> runtime directory, not the actual runtime directory.
>> 
>> since on Windows we never use other than the default runtime location - we 
>> had not seen a problem, but is bug I will file and fix.
>> 
> Good to see that you found it quickly. However I'm puzzled as why 
> initializingEncoding wasn't called, I would have expected the VM to blow up 
> during early startup. Would you have cycles to dig into that a bit more in 
> case something has been masked, like for example an exception being 
> swallowed.  Running with -Xlog:exceptions might reveal something.


Do you have a case that reproduces the issue?

Scott

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8]

[Peter Levart]

On Tue, 21 Sep 2021 15:06:49 GMT, Claes Redestad  wrote:

> > If you look at "Poly" results, spinning MHInvoker/VHInvoker classes for 
> > each instance of Method/Field does not help at all.
> 
> The added indirection in the "Poly" test might cause the code to fall off the 
> inlining cliff, so that any constant folding becomes unlikely to happen. I 
> agree that this might be closer to what happens in a real app, and as a data 
> point it does show that the MHInvoker/VHInvoker optimizations might have been 
> misguided.

It is not the added indirection (I can add an indirection in the "Var" case too 
and benchmark would not change), but the variation of Method/Field instances 
used at the same call-site. When there is only one instance ("Var" case), 
delegating invocation of a MH to a MHInvoker somehow optimizes speculatively 
with a guard that just checks that the same MHInvoker class is used each time 
and further code is generated with constant MH.
Such speculative optimization does not happen with non-constant MHs 
unfortunately despite the fact that there is only one MH instance.
But in "Poly" case, generated MHInvoker classes don't help as there are 
multiple such classes and the speculative optimization falls apart (or is never 
even tried).

-

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

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Alan Bateman]

On 21/09/2021 15:54, Andy Herrick wrote:


I found the problem in 
open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp


we call SetDllDirectory() with the path to the bin dir in the default 
runtime directory, not the actual runtime directory.


since on Windows we never use other than the default runtime location 
- we had not seen a problem, but is bug I will file and fix.


Good to see that you found it quickly. However I'm puzzled as why 
initializingEncoding wasn't called, I would have expected the VM to blow 
up during early startup. Would you have cycles to dig into that a bit 
more in case something has been masked, like for example an exception 
being swallowed.  Running with -Xlog:exceptions might reveal something.


-Alan

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Andy Herrick]

I filed:     JDK-8274087: Windows DLL path not set correctly.

for this, and will work on a fix for JDK18 and backport to JDK17.0.2.

/Andy

On 9/21/2021 10:54 AM, Andy Herrick wrote:
I found the problem in 
open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp


we call SetDllDirectory() with the path to the bin dir in the default 
runtime directory, not the actual runtime directory.


since on Windows we never use other than the default runtime location 
- we had not seen a problem, but is bug I will file and fix.


Thanks.

/Andy

On 9/21/2021 10:17 AM, Scott Palmer wrote:
This is on Windows 10 Pro.  using JDK 17 for jpackage and I'm pretty 
sure for jimage  (though the image was made shortly after 17 GA and 
is being reused)..


There are no libraries directly in $APPDIR, though there are plenty 
in other sibling folders to the 'app' folder (in addition to those in 
app\libs)


I changed app.runtime to point to the (relative) path without the 
$APPDIR\.. - same problem. Tried a absolute path, same problem.


The exact same runtime folder that was failing for me was simply 
copied to the default location to make it work.  It works if I leave 
app.runtime out of the .cfg file, or if I point to $APPDIR\..\runtime


I did some more experiments and found that if I just rename the 
'runtime' folder to 'jre', but leave it at the same depth then the 
problem appears.


I suspected there must be some hardcoded reference to the 'runtime' 
folder in the app launcher.  However, if I have two copies of the 
runtime, one at the default location, and use app.runtime to point to 
the other copy it still fails. (i.e. if it is referencing some 
library from the default location it doesn't help.. I thought it 
might, being that it is all in the same process.)


The application is complex.  It has a plugin mechanism that uses an 
Agent and the Instrument class to augment the classpath at runtime.


(Older versions of the plugin mechanism used to hack the System 
classloader on JDK 8 and switching to an Agent was the fastest way to 
make it work on later versions in a supported manner. It likely 
should be using custom classloaders, but classloading issues got 
messy when I looked into that way back when we started.)


I will try to find time later this week to isolate a test case that 
can reproduce it.  For now I can work around the issue by putting the 
runtime back to the default location for this case. This is a special 
case of an application that actually includes the JRE itself as one 
of the plugins so we can upgrade the JRE after the initial deployment 
or run different jobs with different JREs.  I was trying to make a 
smaller tool/demo that used the JRE from where it would be in our 
"plugin" folder.


Regards,

Scott

On Tue, Sep 21, 2021 at 9:22 AM Andy Herrick > wrote:


    I don't see anything wrong with this offhand. the runtime should
    be able
    to be anywhere if the cfg files "app.runtime" line points to it.

    Is this on windows ? Is the the released JDK17 used both for the
    jlinked
    runtime and the jpackage tool ?

    Are there any libraries in $APPDIR (which is added to the $PATH env
    variable on windows) which could be interfering with encoding
    initialization ?

    Can you try the following experiment:

    manually edit the cfg file line:

app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre

    to contain the canonical path to
    ...\my_own_folder\where_the_jre_is_deeper\jre

    and try again ?


    /Andy

    On 9/20/2021 5:37 PM, Scott Palmer wrote:
    > This is likely not the right place to ask this (sorry).. but I'm
    trying to
    > get info to write a bug report and want to make sure I'm not doing
    > something stupid first.
    >
    > I've created a JRE image from JDK 17 with jlink.  I've made an
    > application image with jpackage.  I've moved the default
    location of the
    > runtime in the application image and modified the launcher .cfg 
file

    > accordingly by adding a line to the [Application] section
    >
    > app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre
    >
    > My application launches.  It shows a JavaFX GUI.  It does a
    bunch of stuff
    > that "works", but then one thread fails with this exception:
    >
    > Exception in thread "Reader-BG-1" java.lang.InternalError: 
platform

    > encoding not initialized
    >          at java.base/java.net
.Inet6AddressImpl.lookupAllHostAddr(Native
    > Method)
    >          at
    > java.base/java.net
.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:933)
    >          at
    > java.base/java.net

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5]

[Hannes Wallnöfer]

On Tue, 21 Sep 2021 14:59:18 GMT, Hannes Wallnöfer  wrote:

>> Julia Boes has updated the pull request with a new target base due to a 
>> merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Merge branch 'master' into simpleserver
>>  - Merge remote-tracking branch 'origin/simpleserver' into simpleserver
>>  - Merge branch 'master' into simpleserver
>>  - refactor isHidden,isReadable,isSymlink checks and cleanup tests
>>  - Merge branch 'master' into simpleserver
>>  - check isHidden, isSymlink, isReadable for all path segments 
>>  - add checks for all path segments
>>  - Merge branch 'master' into componentcheck
>>  - Merge branch 'master' into simpleserver
>>  - improve output on startup
>>  - ... and 6 more: 
>> https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131
>
> test/jdk/com/sun/net/httpserver/simpleserver/SecurityManagerTest.java line 
> 198:
> 
>> 196: 
>> 197: static final DateTimeFormatter HTTP_DATE_FORMATTER =
>> 198: DateTimeFormatter.ofPattern("EEE, dd MMM  HH:mm:ss v");
> 
> I think this and other usages of `DateTimeFormatter.ofPattern` need to be 
> called with `Locale.US` (or something similar) as second argument, otherwise 
> the current default locale will be used. I noticed because on my laptop the 
> `Last-modified` header contains a german date.

I just realized I commented on a test file, while the actual culprit is in 
`FileServerHandler.java`. But I guess it applies to all usages of this class 
and method.

-

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

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8]

[Claes Redestad]

On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung  wrote:

>> This reimplements core reflection with method handles.
>> 
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation 
>> uses `MethodHandle`.  For `Field` accessor, the new implementation uses 
>> `VarHandle`.For the first few invocations of one of these reflective 
>> methods on a specific reflective object we invoke the corresponding method 
>> handle directly. After that we spin a dynamic bytecode stub defined in a 
>> hidden class which loads the target `MethodHandle` or `VarHandle` from its 
>> class data as a dynamically computed constant. Loading the method handle 
>> from a constant allows JIT to inline the method-handle invocation in order 
>> to achieve good performance.
>> 
>> The VM's native reflection methods are needed during early startup, before 
>> the method-handle mechanism is initialized. That happens soon after 
>> System::initPhase1 and before System::initPhase2, after which we switch to 
>> using method handles exclusively.
>> 
>> The core reflection and method handle implementation are updated to handle 
>> chained caller-sensitive method calls [1] properly. A caller-sensitive 
>> method can define with a caller-sensitive adapter method that will take an 
>> additional caller class parameter and the adapter method will be annotated 
>> with `@CallerSensitiveAdapter` for better auditing.   See the detailed 
>> description from [2].
>> 
>> Ran tier1-tier8 tests.   
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8013527
>> [2] 
>> https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430
>
> Mandy Chung has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   minor cleanup and more test case.

> Frameworks that keep Method(s) etc in some collection don't fall into the 
> "Var" category of MH tests presented here, but into the "Poly" category. The 
> test that uses Jackson serialization is one such example. The "Var" class of 
> tests exhibit a use-case where there is a single instance of Method (or 
> Field) object used in a particular call-site (i.e. the Method::invoke 
> invocation in bytecode) but such Method object can't be proved by JIT to be 
> constant (it is not read from static final or @stable field). I doubt that 
> such use-cases exist in practice. Mostly they would amount to cases that were 
> meant to be "Constant" but are not because the user forgot to use "final" 
> modifier on "static" field...
> 
> If you look at "Poly" results, spinning MHInvoker/VHInvoker classes for each 
> instance of Method/Field does not help at all.

The added indirection in the "Poly" test might cause the code to fall off the 
inlining cliff, so that any constant folding becomes unlikely to happen. I 
agree that this might be closer to what happens in a real app, and as a data 
point it does show that the MHInvoker/VHInvoker optimizations might have been 
misguided.

> 
> I would try to optimize the "Poly" case further if it was possible. The 
> simplified Method/MethodHandle is practically equivalent in final "Poly" 
> performance with the generated MethodAccessor, but the Field/VarHandle or 
> Field/MethodHandle lags behind Unsafe-based accessor in "Poly" performance. 
> Nothing can beat Unsafe when access to fields is concerned. It doesn't matter 
> where the offset and base are read-from, the access is super-fast. I wish 
> MethodHandles obtained by unreflectGetter/unreflectSetter could be less 
> sensitive to where they are read from (constant vs. not-constant) and 
> optimize better in non-constant case. I think we should search in this 
> direction... to make MethodHandles obtained by 
> unreflectGetter/unreflectSetter more optimal in non-constant case. If Unsafe 
> can be better, why not MethodHandles?

Completely agree, and it makes sense to me to try and optimize MH/VH field 
access to get on par with Unsafe for these use-cases rather than revert the 
reflective implementation back to raw Unsafe use.

-

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

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5]

[Hannes Wallnöfer]

On Tue, 21 Sep 2021 14:09:54 GMT, Julia Boes  wrote:

>> This change implements a simple web server that can be run on the 
>> command-line with `java -m jdk.httpserver`.
>> 
>> This is facilitated by adding an entry point for the `jdk.httpserver` 
>> module, an implementation class whose main method is run when the above 
>> command is executed. This is the first such module entry point in the JDK.
>> 
>> The server is a minimal HTTP server that serves the static files of a given 
>> directory, similar to existing alternatives on other platforms and 
>> convenient for testing, development, and debugging.
>> 
>> Additionally, a small API is introduced for programmatic creation and 
>> customization.
>> 
>> Testing: tier1-3.
>
> Julia Boes has updated the pull request with a new target base due to a merge 
> or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into simpleserver
>  - Merge remote-tracking branch 'origin/simpleserver' into simpleserver
>  - Merge branch 'master' into simpleserver
>  - refactor isHidden,isReadable,isSymlink checks and cleanup tests
>  - Merge branch 'master' into simpleserver
>  - check isHidden, isSymlink, isReadable for all path segments 
>  - add checks for all path segments
>  - Merge branch 'master' into componentcheck
>  - Merge branch 'master' into simpleserver
>  - improve output on startup
>  - ... and 6 more: 
> https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131

test/jdk/com/sun/net/httpserver/simpleserver/SecurityManagerTest.java line 198:

> 196: 
> 197: static final DateTimeFormatter HTTP_DATE_FORMATTER =
> 198: DateTimeFormatter.ofPattern("EEE, dd MMM  HH:mm:ss v");

I think this and other usages of `DateTimeFormatter.ofPattern` need to be 
called with `Locale.US` (or something similar) as second argument, otherwise 
the current default locale will be used. I noticed because on my laptop the 
`Last-modified` header contains a german date.

-

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

Re: [External] : Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Andy Herrick]

I found the problem in 
open/src/jdk.jpackage/windows/native/applauncher/WinLauncher.cpp


we call SetDllDirectory() with the path to the bin dir in the default 
runtime directory, not the actual runtime directory.


since on Windows we never use other than the default runtime location - 
we had not seen a problem, but is bug I will file and fix.


Thanks.

/Andy

On 9/21/2021 10:17 AM, Scott Palmer wrote:
This is on Windows 10 Pro.  using JDK 17 for jpackage and I'm pretty 
sure for jimage  (though the image was made shortly after 17 GA and is 
being reused)..


There are no libraries directly in $APPDIR, though there are plenty in 
other sibling folders to the 'app' folder (in addition to those in 
app\libs)


I changed app.runtime to point to the (relative) path without the 
$APPDIR\.. - same problem. Tried a absolute path, same problem.


The exact same runtime folder that was failing for me was simply 
copied to the default location to make it work.  It works if I leave 
app.runtime out of the .cfg file, or if I point to $APPDIR\..\runtime


I did some more experiments and found that if I just rename the 
'runtime' folder to 'jre', but leave it at the same depth then the 
problem appears.


I suspected there must be some hardcoded reference to the 'runtime' 
folder in the app launcher.  However, if I have two copies of the 
runtime, one at the default location, and use app.runtime to point to 
the other copy it still fails. (i.e. if it is referencing some library 
from the default location it doesn't help.. I thought it might, being 
that it is all in the same process.)


The application is complex.  It has a plugin mechanism that uses an 
Agent and the Instrument class to augment the classpath at runtime.


(Older versions of the plugin mechanism used to hack the System 
classloader on JDK 8 and switching to an Agent was the fastest way to 
make it work on later versions in a supported manner. It likely should 
be using custom classloaders, but classloading issues got messy when I 
looked into that way back when we started.)


I will try to find time later this week to isolate a test case that 
can reproduce it.  For now I can work around the issue by putting the 
runtime back to the default location for this case.  This is a special 
case of an application that actually includes the JRE itself as one of 
the plugins so we can upgrade the JRE after the initial deployment or 
run different jobs with different JREs.  I was trying to make a 
smaller tool/demo that used the JRE from where it would be in our 
"plugin" folder.


Regards,

Scott

On Tue, Sep 21, 2021 at 9:22 AM Andy Herrick > wrote:


I don't see anything wrong with this offhand. the runtime should
be able
to be anywhere if the cfg files "app.runtime" line points to it.

Is this on windows ? Is the the released JDK17 used both for the
jlinked
runtime and the jpackage tool ?

Are there any libraries in $APPDIR (which is added to the $PATH env
variable on windows) which could be interfering with encoding
initialization ?

Can you try the following experiment:

manually edit the cfg file line:

app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre

to contain the canonical path to
...\my_own_folder\where_the_jre_is_deeper\jre

and try again ?


/Andy

On 9/20/2021 5:37 PM, Scott Palmer wrote:
> This is likely not the right place to ask this (sorry).. but I'm
trying to
> get info to write a bug report and want to make sure I'm not doing
> something stupid first.
>
> I've created a JRE image from JDK 17 with jlink.  I've made an
> application image with jpackage.  I've moved the default
location of the
> runtime in the application image and modified the launcher .cfg file
> accordingly by adding a line to the [Application] section
>
> app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre
>
> My application launches.  It shows a JavaFX GUI.  It does a
bunch of stuff
> that "works", but then one thread fails with this exception:
>
> Exception in thread "Reader-BG-1" java.lang.InternalError: platform
> encoding not initialized
>          at java.base/java.net

.Inet6AddressImpl.lookupAllHostAddr(Native
> Method)
>          at
> java.base/java.net

.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:933)
>          at
> java.base/java.net

.InetAddress.getAddressesFromNameService(InetAddress.java:1519)
>     

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v4]

[Julia Boes]

On Mon, 20 Sep 2021 16:16:10 GMT, Daniel Fuchs  wrote:

>> src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/FileServerHandler.java
>>  line 340:
>> 
>>> 338: }
>>> 339: }
>>> 340: return false;
>> 
>> This will start checking from the root of the file system. I believe we want 
>> to start checking from the root of the FileServerHandler, root excluded.
>
> Maybe these checks should be made in `mapToPath` instead since you already 
> walk the path there - and IIRC returning null from `mapToPath` will cause 
> HTTP 404.

Agreed. I refactored the handler to check `!isReadable`, `isHidden` and 
`isSymbolicLink` for each path segment from the root, excluding the root 
itself. If any of these conditions is met, a 404 response is sent. A generic 
404 response for hides potentially revealing information. The checks are 
repeated in handle() on line 375, let's keep them in there for reassurance.

-

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

Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Scott Palmer]

This is on Windows 10 Pro.  using JDK 17 for jpackage and I'm pretty sure
for jimage  (though the image was made shortly after 17 GA and is being
reused)..

There are no libraries directly in $APPDIR, though there are plenty in
other sibling folders to the 'app' folder (in addition to those in app\libs)

I changed app.runtime to point to the (relative) path without the
$APPDIR\.. - same problem. Tried a absolute path, same problem.

The exact same runtime folder that was failing for me was simply copied to
the default location to make it work.  It works if I leave app.runtime out
of the .cfg file, or if I point to $APPDIR\..\runtime

I did some more experiments and found that if I just rename the 'runtime'
folder to 'jre', but leave it at the same depth then the problem appears.

I suspected there must be some hardcoded reference to the 'runtime' folder
in the app launcher.  However, if I have two copies of the runtime, one at
the default location, and use app.runtime to point to the other copy it
still fails. (i.e. if it is referencing some library from the default
location it doesn't help.. I thought it might, being that it is all in the
same process.)

The application is complex.  It has a plugin mechanism that uses an Agent
and the Instrument class to augment the classpath at runtime.

(Older versions of the plugin mechanism used to hack the System classloader
on JDK 8 and switching to an Agent was the fastest way to make it work on
later versions in a supported manner. It likely should be using custom
classloaders, but classloading issues got messy when I looked into that way
back when we started.)

I will try to find time later this week to isolate a test case that can
reproduce it.  For now I can work around the issue by putting the runtime
back to the default location for this case.  This is a special case of an
application that actually includes the JRE itself as one of the plugins so
we can upgrade the JRE after the initial deployment or run different jobs
with different JREs.  I was trying to make a smaller tool/demo that used
the JRE from where it would be in our "plugin" folder.

Regards,

Scott

On Tue, Sep 21, 2021 at 9:22 AM Andy Herrick 
wrote:

> I don't see anything wrong with this offhand. the runtime should be able
> to be anywhere if the cfg files "app.runtime" line points to it.
>
> Is this on windows ? Is the the released JDK17 used both for the jlinked
> runtime and the jpackage tool ?
>
> Are there any libraries in $APPDIR (which is added to the $PATH env
> variable on windows) which could be interfering with encoding
> initialization ?
>
> Can you try the following experiment:
>
> manually edit the cfg file line:
>
> app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre
>
> to contain the canonical path to
> ...\my_own_folder\where_the_jre_is_deeper\jre
>
> and try again ?
>
>
> /Andy
>
> On 9/20/2021 5:37 PM, Scott Palmer wrote:
> > This is likely not the right place to ask this (sorry).. but I'm trying
> to
> > get info to write a bug report and want to make sure I'm not doing
> > something stupid first.
> >
> > I've created a JRE image from JDK 17 with jlink.  I've made an
> > application image with jpackage.  I've moved the default location of the
> > runtime in the application image and modified the launcher .cfg file
> > accordingly by adding a line to the [Application] section
> >
> > app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre
> >
> > My application launches.  It shows a JavaFX GUI.  It does a bunch of
> stuff
> > that "works", but then one thread fails with this exception:
> >
> > Exception in thread "Reader-BG-1" java.lang.InternalError: platform
> > encoding not initialized
> >  at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native
> > Method)
> >  at
> > java.base/java.net
> .InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:933)
> >  at
> > java.base/java.net
> .InetAddress.getAddressesFromNameService(InetAddress.java:1519)
> >  at
> > java.base/java.net
> .InetAddress$NameServiceAddresses.get(InetAddress.java:852)
> >  at
> > java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1509)
> >  at
> > java.base/java.net.InetAddress.getAllByName(InetAddress.java:1367)
> >  at
> > java.base/java.net.InetAddress.getAllByName(InetAddress.java:1301)
> >  at java.base/java.net
> .InetAddress.getByName(InetAddress.java:1251)
> >  at
> > java.base/java.net.InetSocketAddress.(InetSocketAddress.java:229)
> >  at java.base/sun.net
> .NetworkClient.doConnect(NetworkClient.java:178)
> >  at
> > java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:498)
> >  at
> > java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:603)
> >  at
> >
> java.base/sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:266)
> >  at
> >
> 

Re: RFR: 8274079: Cleanup unnecessary calls to Throwable.initCause() in java.base module

[Weijun Wang]

On Thu, 16 Sep 2021 19:03:26 GMT, Andrey Turbanov 
 wrote:

> Pass "cause" exception as constructor parameter is shorter and easier to read.

Looks fine. Thanks.

-

Marked as reviewed by weijun (Reviewer).

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

Re: RFR: 8245095: Implementation of JEP 408: Simple Web Server [v5]

[Julia Boes]

> This change implements a simple web server that can be run on the 
> command-line with `java -m jdk.httpserver`.
> 
> This is facilitated by adding an entry point for the `jdk.httpserver` module, 
> an implementation class whose main method is run when the above command is 
> executed. This is the first such module entry point in the JDK.
> 
> The server is a minimal HTTP server that serves the static files of a given 
> directory, similar to existing alternatives on other platforms and convenient 
> for testing, development, and debugging.
> 
> Additionally, a small API is introduced for programmatic creation and 
> customization.
> 
> Testing: tier1-3.

Julia Boes has updated the pull request with a new target base due to a merge 
or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' into simpleserver
 - Merge remote-tracking branch 'origin/simpleserver' into simpleserver
 - Merge branch 'master' into simpleserver
 - refactor isHidden,isReadable,isSymlink checks and cleanup tests
 - Merge branch 'master' into simpleserver
 - check isHidden, isSymlink, isReadable for all path segments 
 - add checks for all path segments
 - Merge branch 'master' into componentcheck
 - Merge branch 'master' into simpleserver
 - improve output on startup
 - ... and 6 more: https://git.openjdk.java.net/jdk/compare/6d91a3eb...fe059131

-

Changes: https://git.openjdk.java.net/jdk/pull/5505/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=5505=04
  Stats: 7162 lines in 42 files changed: 7127 ins; 15 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5505/head:pull/5505

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

Re: RFR: 8274071: Clean up java.lang.ref comments and documentation

[Kim Barrett]

On Tue, 21 Sep 2021 12:05:27 GMT, Pavel Rappo  wrote:

> This PR fixes an inline comment typo and reduces "overlinking" in a doc 
> comment in `java.lang.ref.Reference`. Overlinking happens because the 
> `reachabilityFence` method:
>  * Links `package-summary.html#reachability` twice.
>  * Refers to JLS 12.6 twice: once from a block tag and once from an inline 
> tag.

Looks good.

-

Marked as reviewed by kbarrett (Reviewer).

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

Re: RFR: 8274079: Cleanup unnecessary calls to Throwable.initCause() in java.base module

[Pavel Rappo]

On Thu, 16 Sep 2021 19:03:26 GMT, Andrey Turbanov 
 wrote:

> Pass "cause" exception as constructor parameter is shorter and easier to read.

This will need to be thoroughly tested to make sure there were no implicit 
dependencies on now-removed happens-before edges (`initCause` is synchronized). 
That said, the idea behind this clean-up looks good.

-

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

Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Alan Bateman]

On 21/09/2021 14:21, Andy Herrick wrote:
I don't see anything wrong with this offhand. the runtime should be 
able to be anywhere if the cfg files "app.runtime" line points to it.


Is this on windows ? Is the the released JDK17 used both for the 
jlinked runtime and the jpackage tool ?


Are there any libraries in $APPDIR (which is added to the $PATH env 
variable on windows) which could be interfering with encoding 
initialization ?


Can you try the following experiment:

manually edit the cfg file line:

app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre

to contain the canonical path to 
...\my_own_folder\where_the_jre_is_deeper\jre


and try again ?


The exception suggests that something is seriously broken, maybe that 
early VM initialization didn't execute correctly but I can't see what it 
didn't fail earlier. It would be great if there are steps to duplicate this.


-Alan.

RFR: 8274079: Cleanup unnecessary calls to Throwable.initCause() in java.base module

[Andrey Turbanov]

Pass "cause" exception as constructor parameter is shorter and easier to read.

-

Commit messages:
 - [PATCH] Cleanup unnecessary calls to Throwable.initCause() in java.base 
module

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

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

Re: RFR: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add()

[Roger Riggs]

On Tue, 21 Sep 2021 12:47:00 GMT, Naoto Sato  wrote:

> Fixing an AIOOBE on normalizing the month value.

Marked as reviewed by rriggs (Reviewer).

-

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

Re: RFR: 8274071: Clean up java.lang.ref comments and documentation

[Roger Riggs]

On Tue, 21 Sep 2021 12:05:27 GMT, Pavel Rappo  wrote:

> This PR fixes an inline comment typo and reduces "overlinking" in a doc 
> comment in `java.lang.ref.Reference`. Overlinking happens because the 
> `reachabilityFence` method:
>  * Links `package-summary.html#reachability` twice.
>  * Refers to JLS 12.6 twice: once from a block tag and once from an inline 
> tag.

Marked as reviewed by rriggs (Reviewer).

-

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

Re: What causes java.lang.InternalError: platform encoding not initialized ?

[Andy Herrick]

I don't see anything wrong with this offhand. the runtime should be able 
to be anywhere if the cfg files "app.runtime" line points to it.


Is this on windows ? Is the the released JDK17 used both for the jlinked 
runtime and the jpackage tool ?


Are there any libraries in $APPDIR (which is added to the $PATH env 
variable on windows) which could be interfering with encoding 
initialization ?


Can you try the following experiment:

manually edit the cfg file line:

app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre

to contain the canonical path to 
...\my_own_folder\where_the_jre_is_deeper\jre


and try again ?


/Andy

On 9/20/2021 5:37 PM, Scott Palmer wrote:

This is likely not the right place to ask this (sorry).. but I'm trying to
get info to write a bug report and want to make sure I'm not doing
something stupid first.

I've created a JRE image from JDK 17 with jlink.  I've made an
application image with jpackage.  I've moved the default location of the
runtime in the application image and modified the launcher .cfg file
accordingly by adding a line to the [Application] section

app.runtime=$APPDIR\..\my_own_folder\where_the_jre_is_deeper\jre

My application launches.  It shows a JavaFX GUI.  It does a bunch of stuff
that "works", but then one thread fails with this exception:

Exception in thread "Reader-BG-1" java.lang.InternalError: platform
encoding not initialized
 at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native
Method)
 at
java.base/java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:933)
 at
java.base/java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1519)
 at
java.base/java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:852)
 at
java.base/java.net.InetAddress.getAllByName0(InetAddress.java:1509)
 at
java.base/java.net.InetAddress.getAllByName(InetAddress.java:1367)
 at
java.base/java.net.InetAddress.getAllByName(InetAddress.java:1301)
 at java.base/java.net.InetAddress.getByName(InetAddress.java:1251)
 at
java.base/java.net.InetSocketAddress.(InetSocketAddress.java:229)
 at java.base/sun.net.NetworkClient.doConnect(NetworkClient.java:178)
 at
java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:498)
 at
java.base/sun.net.www.http.HttpClient.openServer(HttpClient.java:603)
 at
java.base/sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:266)
 at
java.base/sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:380)
 at
java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:189)
 at
java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1242)
 at
java.base/sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1128)
 at
java.base/sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:175)
 at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1665)
 at
java.base/sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1589)
 at
java.base/java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:529)
 at
java.base/sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:308)

If I keep the runtime in $APPDIR\runtime, things don't fail in this way.

Smells like a bug in the app launcher to me.. but maybe it's in the runtime?

Any assistance would be appreciated (including telling me where I should go
to ask this, if this list isn't appropriate).

Thanks,

Scott

Re: RFR: 8274075: Fix miscellaneous typos in java.base [v2]

[Pavel Rappo]

> 8274075: Fix miscellaneous typos in java.base

Pavel Rappo has updated the pull request incrementally with one additional 
commit since the last revision:

  Tweak wording for Throwable constructor parameters

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5610/files
  - new: https://git.openjdk.java.net/jdk/pull/5610/files/2db8525d..19b6f496

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=5610=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=5610=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5610.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5610/head:pull/5610

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

Re: RFR: 8272600: (test) Use native "sleep" in Basic.java [v6]

[Roger Riggs]

On Tue, 21 Sep 2021 04:54:24 GMT, David Holmes  wrote:

>> Roger Riggs has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   The switch from a Java child to /bin/sleep caused another test
>>   to fail on Linux.  The cleanup for a test used /usr/bin/pkill "sleep 60".
>>   A race between that cleanup and subsequent tests that used sleep 60 or 600
>>   could kill the sleep before the test of waitFor completed.
>>   Changing the test using pkill to use 59 seconds makes the test cleanup
>>   selective to the sleep spawned for that test.
>>   The test that was failing (lines 2626-2624) passes consistently.
>
> test/jdk/java/lang/ProcessBuilder/Basic.java line 2217:
> 
>> 2215: // A unique (59s) time is needed to avoid killing 
>> other sleep processes.
>> 2216: final String[] cmd = { "/bin/bash", "-c", "(/bin/sleep 
>> 59)" };
>> 2217: final String[] cmdkill = { "/bin/bash", "-c", 
>> "(/usr/bin/pkill -f \"sleep 59\")" };
> 
> Maybe future RFE but why do we even need pkill here when we can get the PID 
> of the sleep process we create and kill only that process?

I thought of that too, but notice the parens "()" around that /bin/sleep; that 
creates and extra level of forked processes and its harder to get that pid. 
There probably is a way to traverse the hierarchy but I'll keep it as is for 
now.

-

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

RFR: 8273924: ArrayIndexOutOfBoundsException thrown in java.util.JapaneseImperialCalendar.add()

[Naoto Sato]

Fixing an AIOOBE on normalizing the month value.

-

Commit messages:
 - 8273924: ArrayIndexOutOfBoundsException thrown in 
java.util.JapaneseImperialCalendar.add()

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

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

Re: RFR: 8274075: Fix miscellaneous typos in java.base

[Daniel Fuchs]

On Tue, 21 Sep 2021 12:26:25 GMT, Pavel Rappo  wrote:

> 8274075: Fix miscellaneous typos in java.base

Marked as reviewed by dfuchs (Reviewer).

-

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

RFR: 8274075: Fix miscellaneous typos in java.base

[Pavel Rappo]

8274075: Fix miscellaneous typos in java.base

-

Commit messages:
 - Initial commit

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

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

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8]

[Peter Levart]

On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung  wrote:

>> This reimplements core reflection with method handles.
>> 
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation 
>> uses `MethodHandle`.  For `Field` accessor, the new implementation uses 
>> `VarHandle`.For the first few invocations of one of these reflective 
>> methods on a specific reflective object we invoke the corresponding method 
>> handle directly. After that we spin a dynamic bytecode stub defined in a 
>> hidden class which loads the target `MethodHandle` or `VarHandle` from its 
>> class data as a dynamically computed constant. Loading the method handle 
>> from a constant allows JIT to inline the method-handle invocation in order 
>> to achieve good performance.
>> 
>> The VM's native reflection methods are needed during early startup, before 
>> the method-handle mechanism is initialized. That happens soon after 
>> System::initPhase1 and before System::initPhase2, after which we switch to 
>> using method handles exclusively.
>> 
>> The core reflection and method handle implementation are updated to handle 
>> chained caller-sensitive method calls [1] properly. A caller-sensitive 
>> method can define with a caller-sensitive adapter method that will take an 
>> additional caller class parameter and the adapter method will be annotated 
>> with `@CallerSensitiveAdapter` for better auditing.   See the detailed 
>> description from [2].
>> 
>> Ran tier1-tier8 tests.   
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8013527
>> [2] 
>> https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430
>
> Mandy Chung has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   minor cleanup and more test case.

Hi Claes,

> I'm not sure how to assess how minor the "Var" case really is. I wouldn't be 
> surprised if reflection-heavy frameworks hold `Method`s etc in some 
> collection, which means they wouldn't be rooted in a way that allows the JIT 
> to fold through. Thus leaning only on MH customization could be adding some 
> performance risks. Off-list Vladimir Ivanov suggested the "Var" micros have 
> some issues with inlining that make them look worse than they should, though.

Frameworks that keep Method(s) etc in some collection don't fall into the "Var" 
category of MH tests presented here, but into the "Poly" category. The test 
that uses Jackson serialization is one such example. The "Var" class of tests 
exhibit a use-case where there is a single instance of Method (or Field) object 
used in a particular call-site (i.e. the Method::invoke invocation in bytecode) 
but such Method object can't be proved by JIT to be constant (it is not read 
from static final or @Stable field). I doubt that such use-cases exist in 
practice. Mostly they would amount to cases that were meant to be "Constant" 
but are not because the user forgot to use "final" modifier on "static" field...

If you look at "Poly" results, spinning MHInvoker/VHInvoker classes for each 
instance of Method/Field does not help at all.

I would try to optimize the "Poly" case further if it was possible. The 
simplified Method/MethodHandle is practically equivalent in final "Poly" 
performance with the generated MethodAccessor, but the Field/VarHandle or 
Field/MethodHandle lags behind Unsafe-based accessor in "Poly" performance. 
Nothing can beat Unsafe when access to fields is concerned. It doesn't matter 
where the offset and base are read-from, the access is super-fast. I wish 
MethodHandles obtained by unreflectGetter/unreflectSetter could be less 
sensitive to where they are read from (constant vs. not-constant) and optimize 
better in non-constant case. I think we should search in this direction... to 
make MethodHandles obtained by unreflectGetter/unreflectSetter more optimal in 
non-constant case. If Unsafe can be better, why not MethodHandles?

> 
> On balance I think removing class-spinning might mean a better overall story 
> w.r.t. footprint and maintainability. Had we started this review using a 
> patch that looked more like what Peter is suggestion and someone had 
> suggested we spin classes to get a performance edge in a subset of cases I 
> think we'd not be looking favorably at that and instead tried reaching for 
> narrowing those performance gaps via other less intrusive means. So I think 
> I'm in favor of simplifying and filing a follow-up to try and win back some 
> of the performance we might be losing on corner-case micros without the 
> custom class spinning.

-

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

RFR: 8274071: Clean up java.lang.ref comments and documentation

[Pavel Rappo]

This PR fixes an inline comment typo and reduces "overlinking" in a doc comment 
in `java.lang.ref.Reference`. Overlinking happens because the 
`reachabilityFence` method:
 * Links `package-summary.html#reachability` twice.
 * Refers to JLS 12.6 twice: once from a block tag and once from an inline tag.

-

Commit messages:
 - Initial commit

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

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

Integrated: 8236505: Mark jdk/editpad/EditPadTest.java as @headful

[Aleksey Shipilev]

On Thu, 16 Sep 2021 09:13:15 GMT, Aleksey Shipilev  wrote:

> This is a GUI test, and it should be `@headful`.
> 
> Additional testing:
>  - [x] Test still runs in default, and does not run with `!headful`

This pull request has now been integrated.

Changeset: 7acec3f1
Author:Aleksey Shipilev 
URL:   
https://git.openjdk.java.net/jdk/commit/7acec3f161234b99da76193781296157b98d689c
Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod

8236505: Mark jdk/editpad/EditPadTest.java as @headful

Reviewed-by: jlahoda

-

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

Re: RFR: 8236505: Mark jdk/editpad/EditPadTest.java as @headful

[Aleksey Shipilev]

On Thu, 16 Sep 2021 09:13:15 GMT, Aleksey Shipilev  wrote:

> This is a GUI test, and it should be `@headful`.
> 
> Additional testing:
>  - [x] Test still runs in default, and does not run with `!headful`

Thank you!

-

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

Re: RFR: 8271820: Implementation of JEP 416: Reimplement Core Reflection with Method Handle [v8]

[Claes Redestad]

On Wed, 1 Sep 2021 01:05:32 GMT, Mandy Chung  wrote:

>> This reimplements core reflection with method handles.
>> 
>> For `Constructor::newInstance` and `Method::invoke`, the new implementation 
>> uses `MethodHandle`.  For `Field` accessor, the new implementation uses 
>> `VarHandle`.For the first few invocations of one of these reflective 
>> methods on a specific reflective object we invoke the corresponding method 
>> handle directly. After that we spin a dynamic bytecode stub defined in a 
>> hidden class which loads the target `MethodHandle` or `VarHandle` from its 
>> class data as a dynamically computed constant. Loading the method handle 
>> from a constant allows JIT to inline the method-handle invocation in order 
>> to achieve good performance.
>> 
>> The VM's native reflection methods are needed during early startup, before 
>> the method-handle mechanism is initialized. That happens soon after 
>> System::initPhase1 and before System::initPhase2, after which we switch to 
>> using method handles exclusively.
>> 
>> The core reflection and method handle implementation are updated to handle 
>> chained caller-sensitive method calls [1] properly. A caller-sensitive 
>> method can define with a caller-sensitive adapter method that will take an 
>> additional caller class parameter and the adapter method will be annotated 
>> with `@CallerSensitiveAdapter` for better auditing.   See the detailed 
>> description from [2].
>> 
>> Ran tier1-tier8 tests.   
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8013527
>> [2] 
>> https://bugs.openjdk.java.net/browse/JDK-8271820?focusedCommentId=14439430=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14439430
>
> Mandy Chung has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   minor cleanup and more test case.

I'm not sure how to assess how minor the "Var" case really is. I wouldn't be 
surprised if reflection-heavy frameworks hold `Method`s etc in some collection, 
which means they wouldn't be rooted in a way that allows the JIT to fold 
through. Thus leaning only on MH customization could be adding some performance 
risks. Off-list Vladimir Ivanov suggested the "Var" micros have some issues 
with inlining that make them look worse than they should, though.

On balance I think removing class-spinning might mean a better overall story 
w.r.t. footprint and maintainability. Had we started this review using a patch 
that looked more like what Peter is suggestion and someone had suggested we 
spin classes to get a performance edge in a subset of cases I think we'd not be 
looking favorably at that and instead tried reaching for narrowing those 
performance gaps via other less intrusive means. So I think I'm in favor of 
simplifying and filing a follow-up to try and win back some of the performance 
we might be losing on corner-case micros without the custom class spinning.

-

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

Re: RFR: 8236505: Mark jdk/editpad/EditPadTest.java as @headful

[Jan Lahoda]

On Thu, 16 Sep 2021 09:13:15 GMT, Aleksey Shipilev  wrote:

> This is a GUI test, and it should be `@headful`.
> 
> Additional testing:
>  - [x] Test still runs in default, and does not run with `!headful`

Marked as reviewed by jlahoda (Reviewer).

-

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

Re: RFR: 8236505: Mark jdk/editpad/EditPadTest.java as @headful

[Aleksey Shipilev]

On Thu, 16 Sep 2021 09:13:15 GMT, Aleksey Shipilev  wrote:

> This is a GUI test, and it should be `@headful`.
> 
> Additional testing:
>  - [x] Test still runs in default, and does not run with `!headful`

Any takers? ;)

-

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

Re: RFR: 8268764: Use Long.hashCode() instead of int-cast where applicable [v4]

[Alexander Zuev]

On Thu, 1 Jul 2021 12:19:53 GMT, Сергей Цыпанов 
 wrote:

>> In some JDK classes there's still the following hashCode() implementation:
>> 
>> long objNum;
>> 
>> public int hashCode() {
>> return (int) objNum;
>> }
>> 
>> This outdated expression should be replaced with Long.hashCode(long) as it
>> 
>> - uses all bits of the original value, does not discard any information 
>> upfront. For example, depending on how you are generating the IDs, the upper 
>> bits could change more frequently (or the opposite).
>> 
>> - does not introduce any bias towards values with more ones (zeros), as it 
>> would be the case if the two halves were combined with an OR (AND) operation.
>> 
>> See https://stackoverflow.com/a/4045083
>> 
>> This is related to https://github.com/openjdk/jdk/pull/4309
>
> Сергей Цыпанов has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   8268764: Update copy-right year

Marked as reviewed by kizune (Reviewer).

-

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

Re: RFR: 8273935: (zipfs) Files.getFileAttributeView() throws UOE instead of returning null when view not supported [v3]

[Severin Gehwolf]

On Mon, 20 Sep 2021 18:17:29 GMT, Lance Andersen  wrote:

>> Hi all,
>> 
>> Please review this patch which addresses the issue where Zip FS will throw a 
>> UOE instead of returning null  when  Files.getFileAttributeView() is invoked 
>> and  the view not supported.
>> 
>> Mach5 tiers1 - tier3 are clean.
>> 
>> Best
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   fix minor typo

Marked as reviewed by sgehwolf (Reviewer).

-

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

Integrated: 8273797: Stop impersonating "server" VM in all VM variants

[Aleksey Shipilev]

On Wed, 15 Sep 2021 10:02:19 GMT, Aleksey Shipilev  wrote:

> As the follow-up for Zero-specific JDK-8273494, we might want to clean up 
> build system logic for all VM variants: stop impersonating "server" VMs for 
> all of them. This basically leaves "core" and "custom" variants to be handled 
> with this patch.
> 
> Additional testing:
>  - [x] Linux x86_64 `core` build passes, `libjvm.so` now in `core`, `jvm.cfg` 
> mentions `-core KNOWN`
>  - [x] Linux x86_64 `custom` (+serialgc,+compiler2) build passes, `libjvm.so` 
> now in `custom`, `jvm.cfg` mentions `-custom KNOWN`

This pull request has now been integrated.

Changeset: f242cb5c
Author:Aleksey Shipilev 
URL:   
https://git.openjdk.java.net/jdk/commit/f242cb5ce0af3bacf7af51351121f9137db92931
Stats: 41 lines in 5 files changed: 3 ins; 33 del; 5 mod

8273797: Stop impersonating "server" VM in all VM variants

Reviewed-by: dholmes, erikj, ihse

-

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