Open-source News

Google Chrome/Chromium Experimenting With A Qt Back-End

Phoronix - Thu, 04/14/2022 - 18:00
Public code reviews started this week on Qt platform support for Google's Chromium open-source browser code...

AMDGPU Adding Support For DRM's Buddy Allocator In Linux 5.19

Phoronix - Thu, 04/14/2022 - 17:39
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 23.0 Released With Support For Intel AMX

Phoronix - Thu, 04/14/2022 - 17:26
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...

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

Phoronix - Thu, 04/14/2022 - 17:05
As anticipated the code for Mesa 22.1 has now been branched with the first release candidate imminent for this quarterly Mesa3D update...

My favorite build options for Go

opensource.com - Thu, 04/14/2022 - 15:00
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

opensource.com - Thu, 04/14/2022 - 15:00
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.

Intel Prepares To Enable Intel Arc DG2/Alchemist Compute Support On Linux

Phoronix - Thu, 04/14/2022 - 07:45
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...

Blender Cycles Rendering Support For Intel Arc Via oneAPI + SYCL Under Review

Phoronix - Thu, 04/14/2022 - 02:00
Opened up at the end of March is the work-in-progress Intel oneAPI back-end for Blender's Cycles renderer. This Intel GPU back-end focused for supporting the company's forthcoming Intel Arc graphics cards is targeting the open-source oneAPI Base Toolkit and making use of SYCL. There still is more code work needed, but it's good to see this coming together to complement Blender's NVIDIA CUDA and AMD HIP support...

The Linux Foundation Announces 1st Round of Keynotes Speakers for Open Source Summit North America 2022

The Linux Foundation - Thu, 04/14/2022 - 01:58

Premier event for open source developers and community contributors will feature visionary speakers offering insights on a range of topics: WASM, Cloud Native Computing, Diversity, Community Leadership, Linux and more.

SAN FRANCISCO, April 13, 2022 – The Linux Foundation, the nonprofit organization enabling mass innovation through open source, today announced the first round of keynote speakers taking the stage at Open Source Summit North America, June 21-24, in Austin, TX and virtually.

Open Source Summit North America is the premier event for open source developers, technologists, and community leaders to collaborate, share information, solve problems, and gain knowledge, furthering open source innovation and ensuring a sustainable open source ecosystem. It is a conference umbrella comprising 14 events covering the most important technologies and topics in open source including Linux, Embedded Systems, Supply Chain Security, AI + Data, Cloud, Community Leadership, OSPOs, Software Vulnerabilities, Diversity, IoT, Critical Systems, Containers and more.

2022 Keynote Speakers Include:

  • Alena Analeigh, Founder, Brown STEM Girl
  • Eric Brewer, Vice President of Infrastructure, Google
  • Matt Butcher, Chief Executive Officer, Fermyon Technologies
  • Taylor Dolazel, Head of Ecosystem, Cloud Native Computing Foundation
  • Melissa Evers, Vice President and General Manager of Software/Ecosystem Strategy, Intel Corporation
  • Amy Gilliland, President, General Dynamics Information Technology (GDIT)
  • Orion Jean, TIME 2021 Kid of the Year, Author and Kindness Activist
  • Todd Moore, Vice President – Open Technology and Developer Advocacy, CTO DEG, IBM
  • Melissa Smolensky, Vice President, Corporate Marketing, GitLab
  • Linus Torvalds, Creator of Linux & Git in conversation with Dirk Hohndel, Founder, DH Consulting
  • Chris Wright, Senior Vice President and Chief Technology Officer, Red Hat

The full schedule of sessions will be announced on April 21, with additional keynotes also being announced in the coming weeks.

Registration (in-person) is offered at the early price of $850 through April 26. Regisration to attend virtually is $25. Members of The Linux Foundation receive a 20 percent discount off registration and can contact events@linuxfoundation.org to request a member discount code.

Applications for diversity and need-based scholarships are currently being accepted. For information on eligibility and how to apply, please click here. The Linux Foundation’s Travel Fund is also accepting applications, with the goal of enabling open source developers and community members to attend events that they would otherwise be unable to attend due to a lack of funding. To learn more and apply, please click here.

Health and Safety
In-person attendees will be required to be fully vaccinated against the COVID-19 virus and will need to comply with all on-site health measures, in accordance with The Linux Foundation Code of Conduct. To learn more, visit the Health & Safety webpage.

Event Sponsors
Open Source Summit North America 2022 is made possible thanks to our sponsors, including Diamond Sponsors: Google and IBM, Platinum Sponsors: Cloud Native Computing Foundation, Intel and Red Hat, and Gold Sponsors: Camunda, Checkmarx, Coder, Dell Technologies, GitLab, InfluxData, Kubecost, Styra and Whitesource. For information on becoming an event sponsor, click here or email us.

Press
Members of the press who would like to request a press pass to attend should contact Kristin O’Connell.

About the Linux Foundation
Founded in 2000, the Linux Foundation is supported by more than 2,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 linuxfoundation.org.

The Linux Foundation Events are where the world’s leading technologists meet, collaborate, learn and network in order to advance innovations that support the world’s largest shared technologies.

Visit our website and follow us on TwitterLinkedin, and Facebook for all the latest event updates and announcements.

The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see its trademark usage page: www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

###

Media Contact

Kristin O’Connell
The Linux Foundation
koconnell@linuxfoundation.org

The post The Linux Foundation Announces 1st Round of Keynotes Speakers for Open Source Summit North America 2022 appeared first on Linux Foundation.

Pages