Looks good!

Thanks,
David

On 11/11/2016 7:10 AM, Kumar Srinivasan wrote:
Hi David,

Here is the updated revision
* added back in FreeUnknowVMS
* add -client KNOWN as you suggested

delta webrev
http://cr.openjdk.java.net/~ksrini/8169001/webrev.01/webrev.delta/

full webrev (for reference):
http://cr.openjdk.java.net/~ksrini/8169001/webrev.01/

Thanks
Kumar




On 11/7/2016 3:24 PM, David Holmes wrote:
Hi Kumar,

On 8/11/2016 4:47 AM, Kumar Srinivasan wrote:

Hello,

Please review the fix for:
https://bugs.openjdk.java.net/browse/JDK-8169001

Webrev at:
http://cr.openjdk.java.net/~ksrini/8169001/webrev.00/

Overall this looks like a complete eradication of the launcher
ergonomics. A few specific comments:

src/java.base/share/native/launcher/main.c

!                    const_cpwildcard, const_javaw, 0);

Can you clarify this change with

!                    const_cpwildcard, const_javaw, 0 /* unused */);

Thanks.

---

src/java.base/share/native/libjli/java.c

 220         jint ergo                               /* unused */

I assume JLI_Launch is an exported API otherwise I'd expect this to be
deleted. The fact it is unused should also be documented in
src/java.base/share/native/libjli/java.h. But I'm also wondering where
this API change is being documented for external users?

-     FreeKnownVMs();  /* after last possible PrintUsage() */

Not clear why you no longer need to free here. But if you don't then
FreeKnownVMs() seems to be dead code now.

---

src/java.base/unix/conf/i586/jvm.cfg

I think you still need an entry for "-client KNOWN" as anyone can
build the client VM if they choose. Ditto for
src/java.base/unix/conf/sparc/jvm.cfg (though 32-bit Solaris builds
are obsolete now).

---

You have updated a number of copyright notices but not all of them.

---

I see no changes to tests, but I'm pretty sure we have a test for
server-class-machine somewhere (or we did - I recall it breaking at
some point).

Thanks,
David

Background:
Launcher ergonomics was introduced last decade to help determine
if the execution system is "Server Class", this was necessary to
choose server VM on platforms that supported both client and server
VMs (primarily for Solaris and Linux 32-bit).

The algorithm involves computing and detecting the number of CPUs
and the amount of memory on the target system. All modern computers
systems with hyper-threading cause the ergonomics to choose server.

JDK9 Platforms that have only server vm.

./linux-x64/lib/amd64/server/libjvm.so
./linux-arm64-vfp-hflt/lib/aarch64/server/libjvm.so
./solaris-sparcv9/lib/sparcv9/server/libjvm.so
./solaris-x64/lib/amd64/server/libjvm.so
./windows-x86/bin/server/jvm.dll
./windows-x64/bin/server/jvm.dll

JDK9 Platforms that have more than one vm variant:
./linux-arm32-vfp-hflt/lib/arm/client/libjvm.so (default)
./linux-arm32-vfp-hflt/lib/arm/minimal/libjvm.so

./linux-x86/lib/i386/server/libjvm.so (default)
./linux-x86/lib/i386/minimal/libjvm.so


In the cases where multiple VMs are supported the ergnomics
has no effect, and the default platforms are chosen by the
jvm.cfg. Thus the launcher ergonomics is obsolete and redundant.

Thanks
Kumar


Reply via email to