Open-source News

About 3 ½ years ago, Sanath Kumar Ramesh and his wife welcomed their son, Raghav,  into the world. Like any new parents, he immediately became their everything. And, as new parents do, they threw him a 1st birthday bash where many of their friends and family were meeting Raghav for the first time. 

As Sanath was getting ready to cut the cake, he received a call from Raghav’s doctor. The doctor informed him hey received the results from a battery of tests and, “We think he has an ultra-rare genetic disease called SSMD (Spondylometaphyseal Dysplasia), but, unfortunately, we don’t know much about the disease because all of the other kids died just a few weeks after birth. Your son is lucky to be alive.”

Sanath recounts, “I was taken aback. I was standing at my son’s first of many birthday parties to come and someone was telling me that Raghav was lucky to be alive. This was a turning point in my career – in my whole life.” 

In plain English, he has a typo in his GPX4 gene. The G became A. Consequently, he can’t sit, stand, walk, or eat by mouth. 

Raghav has what is called an ultra-rare disease. Only 9 other children have been diagnosed around the world. 

He called hundreds of hospitals, doctors, researchers, etc. and found no treatments. So, he took matters into his own hands. He tried 5 different drugs and saw some improvements, but not enough to “give him the life he deserves.” Raghav did lift his head up at 13 months – something he never did before. At 3, he is still unable to sit, stand, walk, and talk, and it looks like his disease is progressing faster than they anticipated. 

While SSMD only has a handful of known patients, 400 million people around the world live with over 7,000 rare diseases and disorders. 93% have no FDA-approved treatment. 

So, Sanath began asking researchers, How do we bring treatments to all of the rare diseases? Unfortunately, there is no simple solution. The drug development process is a maze and the biology of most is a complete mystery. But the advice he got was to foster open collaboration, lower the cost, and operate at a global scale.

Source: Open Treatments Foundation

Well, that sounds exactly like the open source model – something Sanath knows well. So, in March 2021, he started the Open Treatments Foundation with the mission to, “Create a society where there is at least one treatment for all genetic diseases accessible to all patients.” That is one giant BHAG. 

They settled on four strategies: 

1. Put every disease on the map: increase disease awareness, build a robust patient community
2. Make diseases easy to work with: open source animal models, assays, and natural history data 
3. Generate more money for research: crowdfunding, incentive-based funding, etc.
4. Create more drug developers: decentralize drug development, go global

They also chose to collaborate with The Linux Foundation on the open source software and created the RareCamp project to house the source code under an Apache 2.0 license and to create and foster a community. The ball is rolling.

On a more personal level, I spent the previous five years working for individuals with rare disorders and diseases. Specifically, I worked at the National Fragile X Foundation. Fragile X syndrome is an inherited, intellectual/developmental disability and is rare (but not ultra-rare). My advocacy extended to all individuals with rare diseases/disorders through groups like the EveryLife Foundation and the Friends of the National Center for Birth Defects and Developmental Disorders – so I am especially excited to see this work. 

Our Fragile X parents would often say this isn’t the life they anticipated or hoped for, but they are better for it. I would say our world will be a better place because of sweet Raghav and all the work he is inspiring. Are you inspired? Join us! As Jim Zemlin said when Sanath spoke at the 2021 Open Source Summit, this project is about, “personal motivation and a collective response.” Can you be part of the collective response? Visit rarecamp.org.

This is just one of the many projects at The Linux Foundation that has the potential to make a major, positive impact on the world. As Jim also stated, “We are just getting started addressing huge issues like rare diseases.”

The post A Rarity in Open Source appeared first on Linux Foundation.

The folks at open-source firmware consulting firm 3mdeb have published a new blog post outlining the current state of open-source firmware on Intel Tiger Lake platforms...

Zephyr RTOS Powers T-Mobile’s First Developer Kit, Designed to Increase Developer Innovation & Make Connection to the Network Easy

SAN FRANCISCO, April 14, 2022 – Today, the Zephyr® Project announced that T-Mobile has joined as a Platinum member, leveraging the Real-Time Operating System (RTOS) to power its new Developer Kit, which gives innovators fast and easy access to build on T-Mobile’s network. The Zephyr Project is an open source project at the Linux Foundation that builds a safe, secure and flexible RTOS for resource-constrained devices. T-Mobile is the first wireless carrier to join the project.

“As a leader in the industry and our first telecom member, T-Mobile brings a unique perspective and expertise to the Zephyr ecosystem,” said Kate Stewart, Vice President of Dependable Embedded Systems at The Linux Foundation. “Zephyr’s existing wireless capabilities (Bluetooth Low Energy, Wi-Fi, and 802.15.4), coupled with DevEdge, T-Mobile’s new developer platform, will unleash innovators to create new solutions for the connected future.”

Zephyr RTOS is easy to deploy, secure, connect and manage and supports more than 350 boards running embedded microcontrollers from Arm and RISC-V to Tensilica, NIOS, and ARC as single and multicore systems. It has a growing set of software libraries that can be used across various applications and industry sectors such as Industrial IoT, wearables, machine learning and more. Zephyr is built with an emphasis on broad chipset support, security, dependability, long-term support releases and a growing open source ecosystem.

“T-Mobile is thrilled to be the first wireless provider to join the Zephyr Project. As we shared when we launched DevEdge earlier this month, we envision a future where everything that can be connected, will be. And that requires massive innovation.” said Rob Roy, SVP of Emerging Business Innovation at T-Mobile. “Zephyr’s RTOS will help T-Mobile enable developers to build better and faster, unlocking massive innovation on our network.”

T-Mobile’s new Developer Kit, which will run on Zephyr RTOS, gives developers immediate access to T-Mobile’s network – no out-of-pocket costs, no testing hardware, no lengthy build time required. And for a limited time, T-Mobile is giving away Developer Kits for free while supplies last to developers who sign up now. To learn more, and to sign-up for a kit, developers can visit devedge.t-mobile.com/solutions/iot-developer-kit.

T-Mobile joins other Platinum members including Antmicro, Baumer, Google, Intel, Meta, Nordic Semiconductor, NXP, Oticon and Qualcomm Innovation Center. T-Mobile will join the Zephyr Governing Board and its commitment to ensure balanced collaboration and feedback that meets the needs of its community.

Other Zephyr Project members include AVSystem, BayLibre, Beijing University of Posts and Telecommunications (BUPT), Eclipse Foundation, FIWARE, Foundries.io, Golioth, Infineon, Institute of Communication and Computer Systems (ICCS), Laird Connectivity, Linaro, Memfault, Northeastern University, Parasoft, Percepio, Research Institute of Sweden (RISE), RISC-V, SiFive, Silicon Labs, Synopsys, Texas Instruments and Wind River.

Zephyr Developer Summit

The Zephyr community will gather virtually and in-person at the Computer History Museum in Mountain View, California, on June 8-9. The second annual Zephyr Developer Summit will feature speakers from Antmicro, AVSystem, Bitergia, Boston Technology Law, Entropic Engineering, Circuit Dojo, Facebook/Meta, Golioth, Google, Huawei, Intel, Laird Connectivity, Lattix, Linaro, The Linux Foundation, Nordic Semiconductor, Percepio, Samsung, ST Microelectronics, Synopsys, Wind River and Zonneplan.

The Summit is open to the public with various registration rates to attend in-person or virtually. Learn more and register here: https://events.linuxfoundation.org/zephyr-developer-summit/register/.

A few of highlights of the Zephyr Developer Summit include:

• An Intro to Zephyr Day on June 7 that offer several presentations and overviews for new developers. It will also feature in-depth hands-on tutorials from Golioth and Nordic Semiconductor.
• A Mini-Conference for Testing & Traceability that features sessions about design and testing, unit tests and emulators, new framework for testing fleet of platforms, and a Birds of a Feather (BoF) for quality and testing processes for Zephyr.
• A Mini-Conference for RISC-V collaboration with presentations about SMP support, what it is currently and what lies ahead, as well as the use of the RISC-V architecture in the Zephyr ecosystem.

The complete schedule for the Summit can be found here. The Zephyr Developer Summit is made possible thanks to Diamond Sponsors Antmicro, Google and Intel; Platinum Sponsor Nordic Semiconductor; Gold Sponsor NXP; Silver Sponsors Golioth and Memfault and Session Recording Sponsor BayLibre.

Last year, almost 700 people registered for the first-ever virtual Zephyr Developer Summit in June. The event consisted of 5 mini-conferences, 28 sessions and 51 speakers who presented technical content, best practices, real-world use cases and more. Videos are available on the Zephyr Project YouTube Channel.

To learn more about Zephyr RTOS, visit the Zephyr website and blog.

About the Zephyr Project

The Zephyr Project is an open source, scalable real-time operating system (RTOS) supporting multiple hardware architectures. To learn more, please visit www.zephyrproject.org.

About the Linux Foundation

Founded in 2000, the Linux Foundation is supported by more than 1,000 members and is the world’s leading home for collaboration on open source software, open standards, open data, and open hardware. Linux Foundation’s projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, and more.  The Linux Foundation’s methodology focuses on leveraging best practices and addressing the needs of contributors, users and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org.

###

The post T-Mobile joins the Zephyr Project as Platinum Member appeared first on Linux Foundation.

Sophos Unveils Powerful Cloud Workload Protection Advancements with New Linux and Container Security Offerings  Yahoo Finance

Sophos Unveils Powerful Cloud Workload Protection Advancements with New Linux and Container Security Offerings  GlobeNewswire

Common Knowledge: Big tech and the digital commons  Resilience

Appdome CEO on Mobile App Security: No Developer, No Code, No Problem  LinuxInsider.com

Intel Alder Lake Users On Ubuntu 22.04 LTS Will Want To Switch To A Newer Kernel  Phoronix

Next week's Ubuntu 22.04 LTS "Jammy Jellyfish" is using Linux 5.15 by default given that the kernel is also a "Long Term Support" release. While it makes sense in theory, in practice with Linux 5.16 having been out as stable since January and Linux 5.17 out for several weeks already there is a lot of hardware improvements past the v5.15 that haven't been back-ported or otherwise picked up by Ubuntu Jammy's kernel build. The main pain point this presents is for those using the latest-generation Intel "Alder Lake" processors with a mix of performance and power efficiency cores. My testing of Alder Lake this week on the latest Ubuntu 22.04 LTS build still shows that its 5.15-based experience being less than desirable with measurable -- often very significant -- improvements if using v5.16 or later.

Google Shares Plan to Make Steam Work on Chrome OS with Linux  It's FOSS News

Public code reviews started this week on Qt platform support for Google's Chromium open-source browser code...

Going back to last October has been work by AMD developers in leveraging the DRM buddy allocator code started by Intel within their AMDGPU kernel driver. With the Linux 5.19 kernel this summer, AMDGPU is ready to finally make use of that buddy allocator...

Cloud-Hypervisor is the Rust-written, KVM-leveraging VMM started by Intel that is now developed under the Linux Foundation umbrella with Arm, Microsoft, and others also contributing to this project focused on cloud virtualization needs. Cloud-Hypervisor 23.0 is out today with the latest features for this increasingly capable open-source virtual machine monitor...

As anticipated the code for Mesa 22.1 has now been branched with the first release candidate imminent for this quarterly Mesa3D update...

Mesa 22.1 Begins Steps To Release Next Month With Vulkan Improvements, New Driver & More  Phoronix

My favorite build options for Go Gaurav Kamathe Thu, 04/14/2022 - 03:00 Up Register or Login to like.

One of the most gratifying parts of learning a new programming language is finally running an executable and getting the desired output. When I discovered the programming language Go, I started by reading some sample programs to get acquainted with the syntax, then wrote small test programs. Over time, this approach helped me get familiar with compiling and building the program.

The build options available for Go provide ways to gain more control over the build process. They can also provide additional information to help break the process into smaller parts. In this article, I will demonstrate some of the options I have used. Note: I am using the terms build and compile to mean the same thing.

Programming and development Red Hat Developers Blog Programming cheat sheets Try for free: Red Hat Learning Subscription eBook: An introduction to programming with Bash Bash shell scripting cheat sheet eBook: Modernizing Enterprise Java Getting started with Go

I am using Go version 1.16.7; however, the command given here should work on most recent versions as well. If you do not have Go installed, you can download it from the Go website and follow the instructions for installation. Verify the version you have installed by opening a prompt command and typing:

$ go version

The response should look like this, depending on your version.

go version go1.16.7 linux/amd64
$Basic compilation and execution of Go programs

I'll start with a sample Go program that simply prints "Hello World" to the screen.

$ cat hello.go
package main

import "fmt"

func main() {
        fmt.Println("Hello World")
}
$

Before discussing more advanced options, I'll explain how to compile a sample Go program. I make use of the build option followed by the Go program source file name, which in this case is hello.go.

$ go build hello.go

If everything is working correctly, you should see an executable named hello created in your current directory. You can verify that it is in ELF binary executable format (on the Linux platform) by using the file command. You can also execute it and see that it outputs "Hello World."

$ ls
hello  hello.go
$
$ file ./hello
./hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
$
$ ./hello
Hello World
$

Go provides a handy run option in case you do not want to have a resulting binary and instead want to see if the program works correctly and prints the desired output. Keep in mind that even if you do not see the executable in your current directory, Go still compiles and produces the executable somewhere, runs it, then removes it from the system. I'll explain in a later section of this article.

$ go run hello.go
Hello World
$
$ ls
hello.go
$Under the hood

The above commands worked like a breeze to run my program with minimal effort. However, if you want to find out what Go does under the hood to compile these programs, Go provides a -x option that prints everything Go does to produce the executable.

A quick look tells you that Go creates a temporary working directory within /tmp, produces the executable, and then moves it to the current directory where the source Go program was present.

$ go build -x hello.go

WORK=/tmp/go-build1944767317
mkdir -p $WORK/b001/

<< snip >>

mkdir -p $WORK/b001/exe/
cd .
/usr/lib/golang/pkg/tool/linux_amd64/link -o $WORK \
/b001/exe/a.out -importcfg $WORK/b001 \
/importcfg.link -buildmode=exe -buildid=K26hEYzgDkqJjx2Hf-wz/\
nDueg0kBjIygx25rYwbK/W-eJaGIOdPEWgwC6o546 \
/K26hEYzgDkqJjx2Hf-wz -extld=gcc /root/.cache/go-build /cc \
/cc72cb2f4fbb61229885fc434995964a7a4d6e10692a23cc0ada6707c5d3435b-d
/usr/lib/golang/pkg/tool/linux_amd64/buildid -w $WORK \
/b001/exe/a.out # internal
mv $WORK/b001/exe/a.out hello
rm -r $WORK/b001/

This helps solve the mysteries when a program runs but no resulting executable is created within the current directory. Using -x shows that the executable file was indeed created in a /tmp working directory and was executed. However, unlike the build option, the executable did not move to the current directory, making it appear that no executable was created.

$ go run -x hello.go


mkdir -p $WORK/b001/exe/
cd .
/usr/lib/golang/pkg/tool/linux_amd64/link -o $WORK/b001 \
/exe/hello -importcfg $WORK/b001/importcfg.link -s -w -buildmode=exe -buildid=hK3wnAP20DapUDeuvAAS/E_TzkbzwXz6tM5dEC8Mx \
/7HYBzuaDGVdaZwSMEWAa/hK3wnAP20DapUDeuvAAS -extld=gcc \
/root/.cache/go-build/75/ \
7531fcf5e48444eed677bfc5cda1276a52b73c62ebac3aa99da3c4094fa57dc3-d
$WORK/b001/exe/hello
Hello WorldMimic compilation without producing the executable

Suppose you don't want to compile the program and produce an actual binary, but you do want to see all steps in the process. You can do so by using the -n build option, which prints the steps that it would normally run without actually creating the binary.

$ go build -n hello.goSave temp directories

A lot of work happens in the /tmp working directory, which is deleted once the executable is created and run. But what if you want to see which files were created in the compilation process? Go provides a -work option that can be used when compiling a program. The -work option prints the working directory path in addition to running the program, but it doesn't delete the working directory afterward, so you can move to that directory and examine all the files created during the compile process.

$ go run -work hello.go
WORK=/tmp/go-build3209320645
Hello World
$
$ find /tmp/go-build3209320645
/tmp/go-build3209320645
/tmp/go-build3209320645/b001
/tmp/go-build3209320645/b001/importcfg.link
/tmp/go-build3209320645/b001/exe
/tmp/go-build3209320645/b001/exe/hello
$
$ /tmp/go-build3209320645/b001/exe/hello
Hello World
$Alternative compilation options

What if, instead of using the build/run magic of Go, you want to compile the program by hand and end up with an executable that can be run directly by your operating system (in this case, Linux)? This process can be divided into two parts: compile and link. Use the tool option to see how it works.

First, use the tool compile option to produce the resulting ar archive file, which contains the .o intermediate file. Next, use the tool link option on this hello.o file to produce the final executable, which can then run.

$ go tool compile hello.go
$
$ file hello.o
hello.o: current ar archive
$
$ ar t hello.o
__.PKGDEF
_go_.o
$
$ go tool link -o hello hello.o
$
$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
$
$ ./hello
Hello World
$

To peek further into the link process of producing the executable from the hello.o file, you can use the -v option, which searches for the runtime.a file included in every Go executable.

$ go tool link -v -o hello hello.o
HEADER = -H5 -T0x401000 -R0x1000
searching for runtime.a in /usr/lib/golang/pkg/linux_amd64/runtime.a
82052 symbols, 18774 reachable
        1 package symbols, 1106 hashed symbols, 77185 non-package symbols, 3760 external symbols
81968 liveness data
$Cross-compilation options

Now that I've explained the compilation of a Go program, I'll demonstrate how Go allows you to build an executable targeted at different hardware architectures and operating systems by providing two environment variables—GOOS and GOARCH—before the actual build command.

Why does this matter? You can see an example when an executable produced for the ARM (aarch64) architecture won't run on an Intel (x86_64) architecture and produces an Exec format error.

These options make it trivial to produce cross-platform binaries.

$ GOOS=linux GOARCH=arm64 go build hello.go
$
$ file ./hello
./hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, not stripped
$


$ ./hello
bash: ./hello: cannot execute binary file: Exec format error
$
$ uname -m
x86_64
$

You can read my earlier blog post about my experiences with cross-compilation using Go to learn more.

View underlying assembly instructions

The source code is not directly converted to an executable, though it generates an intermediate assembly format which is then assembled into an executable. In Go, this is mapped to an intermediate assembly format rather than the underlying hardware assembly instructions.

To view this intermediate assembly format, use -gcflags followed by -S given to the build command. This command shows the assembly instructions.

$ go build -gcflags="-S" hello.go
# command-line-arguments
"".main STEXT size=138 args=0x0 locals=0x58 funcid=0x0
        0x0000 00000 (/test/hello.go:5) TEXT    "".main(SB), ABIInternal, $88-0
        0x0000 00000 (/test/hello.go:5) MOVQ    (TLS), CX
        0x0009 00009 (/test/hello.go:5) CMPQ    SP, 16(CX)
        0x000d 00013 (/test/hello.go:5) PCDATA  $0, $-2
        0x000d 00013 (/test/hello.go:5) JLS     128

<< snip >>
$

You can also use the objdump -s option, as shown below, to see the assembly instructions for an executable program that was already compiled.

$ ls
hello  hello.go
$
$
$ go tool objdump -s main.main hello
TEXT main.main(SB) /test/hello.go
  hello.go:5            0x4975a0                64488b0c25f8ffffff      MOVQ FS:0xfffffff8, CX                 
  hello.go:5            0x4975a9                483b6110                CMPQ 0x10(CX), SP                      
  hello.go:5            0x4975ad                7671                    JBE 0x497620                           
  hello.go:5            0x4975af                4883ec58                SUBQ $0x58, SP                         
  hello.go:6            0x4975d8                4889442448              MOVQ AX, 0x48(SP)                      

<< snip >>
$Strip binaries to reduce their size

Go binaries are typically large. For example, a simple Hello World program produces a 1.9M-sized binary.

$ go build hello.go
$
$ du -sh hello
1.9M    hello
$
$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
$

To reduce the size of the resulting binary, you can strip off information not needed during execution. Using -ldflags followed by -s -w flags makes the resulting binary slightly lighter, at 1.3M.

$ go build -ldflags="-s -w" hello.go
$
$ du -sh hello
1.3M    hello
$
$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped
$Conclusion

I hope this article introduced you to some handy Go build options that can help you understand the Go compilation process better. For additional information on the build process and other interesting options available, refer to the help section:

$ go help build

These handy Go build options can help you understand the Go compilation process better.

Image by:

Opensource.com

Go programming language What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

A guide to JVM parameters for Java developers Jayashree Hutt… Thu, 04/14/2022 - 03:00 Up Register or Login to like.

When you write source code, you're writing code for humans to read. Computers can't execute source code until the code is compiled into machine language, a generic term referring to any number of languages required by a specific machine. Normally, if you compile code on Linux, it runs on Linux, and if you compile code on Windows, it runs on Windows, and so on. However, Java is different. It doesn't target an actual machine. It targets something called the Java Virtual Machine (JVM), and so it can run on any machine.

More on Java What is enterprise Java programming? Red Hat build of OpenJDK Java cheat sheet Free online course: Developing cloud-native applications with microservices Fresh Java articles

Java source code gets compiled into bytecode which is run by a JVM installed on a computer. The JVM is an execution engine, but it's not one you usually interact with directly. It runs quietly, processing Java bytecode. Most people don't need to think or even know about the JVM, but it can be useful to understand how the JVM works so you can debug and optimize Java code. For example:

• In the production environment, you might find a deployed application needs a performance boost.

• If something goes wrong in an application you've written, both the developer and end-user have options to debug the problem.

• Should you want to know the details of the Java Development Kit (JDK) being used to develop or run a Java application, you can get those details by querying the JVM.

This article introduces some basic JVM parameters to help in these scenarios…

Image by:

(Jayashree Huttanagoudar CC BY-SA 4.0)

What's the difference between a JVM, JDK, and JRE?

Java has a lot of J-acronyms, including JVM, JDK, and JRE.

• A Java Developer Kit (JDK) is accessed by programmers who need development libraries to use in their code.

• The Java Runtime Environment (JRE) is employed by people who want to run a Java application.

• The Java Virtual Machine (JVM) is the component that runs Java bytecode.

The JDK contains both a JRE and a JVM, but some Java distributions provide an alternate download containing a JRE (including a JVM).

Image by:

(Jayashree Huttanagoudar CC BY-SA 4.0)

Java is open source, so different companies build and distribute JDKs. You can install more than one on your system, which can be helpful when you're working on or using different Java projects, some of which might use an old JDK.

To list the JDKs on your Linux system, you can use the alternatives command:

$ alternatives --config java
There are 2 programs that provide java.
Selection Command
-----------------------------------------------
*+ 1 java-11-openjdk.x86_64 (/usr/lib/jvm/java-11-openjdk-11.0.13.0.8-2.fc35.x86_64/bin/java)
2 java-1.8.0-openjdk.x86_64 (/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.312.b07-2.fc35.x86_64/jre/bin/java)

Enter to keep the current selection[+], or type selection number:

To switch between available JDKs, run the command again:

$ sudo alternatives --config java

Another option is to use SDKMan, which helps you download, update, and manage the JDKs on your system.

What is JVM tuning?

Tuning a JVM is the process of adjusting JVM parameters to improve the performance of the Java application. It also helps to diagnose application failure.

In general, it's important to consider these points before tuning:

• Cost : Sometimes, improving the hardware running your code can improve an application's performance. That might seem like a "cheat" but consider how much time you're willing to spend tuning the JVM parameters. Sometimes, an application requires more memory to perform as desired, and no amount of software hacking will change that.

• Desired Outcome: Stability is more important than performance in the long run. If your tuning affects the stability, it's probably better to wisely choose your tuning parameters.

• Underlying issues : Sometimes, the issue could be an underlying issue with the host operating system. Before tuning the JVM, ensure that the JVM's platform is working as expected.

• Memory leaks: If you find yourself using Garbage Collection (GC) tuning parameters, there are likely memory leaks that need to get fixed in the application code.

Types of JVM Parameters

JVM parameters are grouped under three categories: Standard options, Non-standard, and Advanced.

Standard options

All JVM implementations support standard options. Run the 'java' command in a terminal to see a list of standard options.

$ java
Usage: java [options] <mainclass> [args...]
        (to execute a class)
   or  java [options] -jar <jarfile> [args...]
        (to execute a jar file)

 where options include:

        -cp <class search path of directories and zip/jar files>
        -classpath <class search path of directories and zip/jar files>
        --class-path <class search path of directories and zip/jar files>
                A : separated list of directories, JAR archives,
                and ZIP archives to search for class files.
        --enable-preview
                allow classes to depend on preview features of this release

To specify an argument for a long option, you can use --<name>=<value> or
--<name> <value>.

These are all standard options included with any JVM, and you can safely use them as you use any command-line option. For example, to validate command options for configuration, and create a VM and load a main class without executing the main class, use:

$ java --dry-run <classfile>Non-standard options

Non-standard options start with -X. These are for general purpose use and are specific to a particular implementation of JVM. To list these options:
 

$ java -X
-Xbatch disable background compilation
-Xbootclasspath/a:<directories and zip/jar files separated by :>
append to end of bootstrap class path
-Xinternalversion
displays more detailed JVM version information than the
-version option
-Xloggc:<file> log GC status to a file with time stamps
[...]

These extra options are subject to change without notice and are not supported by all JVM implementations.

A JVM built by Microsoft may have different options than one built by Red Hat, and so on.

To get detailed JVM version information, use the following option:
 

$ java -Xinternalversion --version
OpenJDK 64-Bit Server VM (11.0.13+8) for linux-amd64 JRE (11.0.13+8), built on Nov 8 2021 00:00:00 by "mockbuild" with gcc 11.2.1 20210728 (Red Hat 11.2.1-1)

To get the property setting use:

$ java -XshowSettings:properties --versionAdvanced options

These options are not for casual use and are used for tuning the specific areas of the Hotspot VM. These options are subject to change, and there is no guarantee that all JVM implementations will support it.

These options start with -XX. To list these options, use the following command:

$ java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version

For example, to trace the class loading then use the below command:

$ java -XX:+TraceClassLoading Hello

The Hello.java has:

$ cat Hello. java
public class Hello {
  public static void main(String[] args) {
    System.out.println("Inside Hello World!");
  }
}
 

Another common problem you might face is OOM (Out Of Memory) errors, which can happen without much debug information. To solve such a problem, you might use the debug option -XX:+HeapDumpOnOutOfMemoryError, which creates a .hprof file with debug information.
 

$ cat TestClass. java import java.util.ArrayList; import java.util.List; public class TestClass { public static void main(String[] args) { List list = new ArrayList(); for (int i = 0; i < 1000; i++) { list.add(new char[1000000]); } } } $ Javac TestClass.java $ java -XX:+HeapDumpOnOutOfMemoryError -Xms10m -Xmx1g TestClass java.lang.OutOfMemoryError: java heap space Dumping heap to java_pid444496.hprof ... Heap dump file created [1018925828 bytes in 1.442 secs] Exception in thread "main" java.lang.OutOfMemoryError: java heap space at TestClass.main(TestClass.Java:8)

There are tools to look at this .hprof file to understand what went wrong.

Conclusion

By understanding and using JVM and JVM parameters, both developers and end users can diagnose failures and improve the performance of a Java application. The next time you're working with Java, take a moment to look at the options available to you.

By understanding and using JVM and JVM parameters, both developers and end users can diagnose failures and improve the performance of a Java application.

Image by:

CC BY 3.0 US Mapbox Uncharted ERG

Java What to read next This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License. Register or Login to post a comment.

IoT and Blockchain Market Outlook: Post Covid-19 Scenario by 2030 | KrypC, Factom, The Linux Foundation, Cisco Systems – Political Beef  Political Beef

While every few days it seems like we are writing about new DG2/Alchemist graphics code being prepared for the Linux kernel or related components like Mesa -- and it's been something going on for many months now -- knowing the actual working state of Intel Arc Graphics on Linux hasn't been exactly clear given no formal announcements/communication out of Intel yet as to Linux support expectations / version requirements and not yet having any hardware access. While much of the graphics support has been squared away for Intel Arc DG2/Alchemist as covered in prior articles, it turns out the compute support is still settling but there is now a patch series pending for actually exposing it...

5 Reasons Why Fedora Feels Like the New Ubuntu  MUO - MakeUseOf