JBR-4753 Added JBR API for custom desktop actions
JBR-3511 Way to customize implementation of java.awt.Desktop.browse()
Provided Desktop.setDesktopActionsHandler() and DesktopActionsHandler
interface, which methods will be invoked instead of the standard actions
provided that DesktopActionsHandler.isSupported() is true for the
corresponding action.
After CPlatformComponent.setBounds() was changed to allow for platformWindow.getPeer() == null, a few exceptions appeared that suggest platformWindow can also be null. This commit safeguards against this situation as well.
It seems that this can only be the case if the instance is created from outside of JDK, so Objects.requireNonNull() may help to catch the perpetrator.
Align lifetime of MTLLayer and AWTView objc objects with MTLSDOps data attached to MTLSurfaceData
Added some more checks to commitCommandBuffer (in MTLContext)
The OpenGL pipeline is enabled only if all of the following is true:
- WAYLAND is detected,
- VMWare virtualization is detected,
- rendering pipeline is not a software one (llvmpipe).
As a side effect, a system property 'jbr.virtualization.information'
is set to the value of detected virtualization type. The value is the
same as provided by JFR.
The list of deferredRecords could be modified by Disposer.pollRemove()
on one thread, while being traversed by Disposer.clearDeferredRecords()
on another thread at the same time.
Such use of a non-thread-safe collection sometimes lead to a null
record retrieved from deferredRecords (which does not contain nulls),
resulting in a caught and ignored NPE. Another result was an abort()
caused by calling free() as detected by libc's built-in heap health
checks, likely triggered by free'ing the same block more than once.
After adding the set -e option, which instructs bash to immediately exit if any command has a non-zero exit status, perfcmp.sh unexpectedly exited because grep could not find an asterik. But it is expected case which means that the score is applicable
use override-redirect flag for popup menus on KDE - popup menus aren't affected by JBR-4535,
as they use an active mouse pointer grab, and marking them as override-redirect will allow to display
them over the system task bar, as https://bugs.openjdk.org/browse/JDK-6580930 requires
This also aligns the handling of the style mask with how the other settings are applied: It uses a client property now. This property is now also applied directly on peer initialization so that there is no need to re-apply, and the window directly appears in the correct configuration.
Improved RenderPerfTest:
- corrected and simplified test logic
- added timeout on low performant rendering
- used several markers to recover from missing frames
- protected measurements from multiple paint invocations
Added exception.toString() to jbr_err_* log
(cherry picked from commit 478bd6cdd7)
Added java stack of the exception to jbr_err_* log
(cherry picked from commit e97f728e93)
Also return the static string "OutOfMemoryError" in case of that
exception has been thrown in order to avoid crashing while reporting an
exception in an out-of-memory situation.
IDEA-146669 Enable Mac native file dialogs
IDEA-159507 Mac native dialogs: multiple open dialogs are possible
JBR-1784 File dialogs aren't themed on macOS
Allow Windows Path to have a trailing space despite Windows naming conventions
discouraging it. Many programs - including Explorer - successfully work
with such files or directories.
The watch service is based on FSEvents API that notifies about file
system changes at a directory level. It is possible to go back to
using the old polling watch service with -Dwatch.service.polling=true.
Features include:
- support for FILE_TREE option (recursive directory watching),
- minimum necessary I/O (no filesystem access more than once
unless needed),
- one thread ("run loop") per WatchService instance,
- changes are detected by comparing file modification times with
millisecond precision,
- a directory tree snapshot is taken at the time of WatchKey creation
and can take a long time (proportional to the number of files).
The crashes begin with the call to getDefaultConfig() in
createStatusWindow() returning garbage. With 8280468 fixed, there aren't
many reasons left for it to do so; it must be that the argument to the
call (the screen number) is out of range.
This change eliminates the possibilities to get an absolutely incorrect
screen number by checking the return values of several Xlib functions,
which, when fail, will leave their outgoing arguments uninitialized.
This, in turn, can lead to reading some random memory resulting in
equally random screen number that is later being fed to
getDefaultConfig().
Although on modern systems with Xinerama there should really be no
screen other than zero, as the last resort, this number is also
range-checked in getDefaultConfig() itself.
adjust_metod_entries_dcevm incorrectly changed the hashes of resolved
method oops stored in ResolvedMethodTable. Now all oops of old methods
are first removed, then updated and then added to table again
Detect the presence of an additional space by looking at number of spaces for the first monitor, not at the total number of spaces.
The latter is larger than one in a multi-monitor configuration, as each monitor corresponds to a separate space.
This approach should be better than the original one, but it relies on the primary (default) monitor to be mentioned first
in the plist file, which isn't known to be always true.
(cherry picked from commit 9040fd56cd)
* IDEA-283934 Top panel (toolbar, Editor tabs) hides under the Mac menu in full-screen mode
* IDEA-283934 Top panel (toolbar, Editor tabs) hides under the Mac menu in full-screen mode
* JBR-4305 IDEA-283934 Top panel (toolbar, Editor tabs) hides under the Mac menu in full-screen mode
* JBR-4305 IDEA-283934 Top panel (toolbar, Editor tabs) hides under the Mac menu in full-screen mode
JBR-4228 report HTMINBUTTON, HTMAXBUTTON, HTCLOSE, HTMENU, HTCAPTION targets via JBR API & handle corresponding non-client mouse events for windows with custom decorations
Made Robot image capture work when sun.java2d.uiScale
doesn't match the desktop scale on Linux.
Improved tests to verify that color picking is precise to the pixel
(only on Linux and Windows; Mac may not always give precise color
of the desired pixel).
Fixes the Layout_*.java tests by giving them to know the <Ctrl + key> combinations can generate KEY_TYPED event.
(cherry picked from commit eae5198b20)
Changed -pathmap option value to use "normal", Unix-style paths. Those will
be changed to Windows style by the fixpath script. But if Windows-style paths
are used, this script will wreck them by removing the backslash characters.
Passed the configure script options necessary to enable reproducible builds
on Windows. With this options, the resulting jars are reproducible, but
native executables and libraries aren't.
The Gtk API for capturing images works with unscaled coordinates and
sizes, but Robot pre-scales both even before passing the data to the
native code. This commit undoes that for Gtk3 in the native code.
Also fixed two HiDPI tests that should have been failing due to the
above bug, but didn't because they only checked one point in the middle
of a large painted area. Changed those tests to verify 5 pixels instead:
4 at the corners and one in the middle.
Also marked the relevant tests that use Robot as a color picker to
require "pure" X server on Linux so that they don't fail under XWayland.
(cherry picked from commit 93ba9e86f9)
Introduction of JBR API changed the order of modules appearing in Java
Doc. This commit updates the corresponding tests to match the current
output with JBR API.
8275849: TestZoneInfo310.java fails with tzdata2021e
8276536: Update TimeZoneNames files to follow the changes made by JDK-8275766
Reviewed-by: coffeys
* macOS: add methods to setup transparent titlebar with custom height
* make windowTransparentTitleBarHeight CPlatfromWindow property
* add windowTransparentTitleBarHeight test
* Prevent mouseUp events on the transparent header on macOS when the window is being dragged
Co-authored-by: Manuel Unterhofer <manuel.unterhofer@jetbrains.com>
Added the -XX:-IgnoreUnrecognizedVMOptions option to the test driver for
command line options, since it is often used to check that a certain
option is not supported.
If NtQueryDirectoryFile() failed with STATUS_INVALID_PARAMETER,
try again asking for less information with the FileDirectoryInformation
option as "information class". This option works on a mounted
Google Drive, but it doesn't provide file ids, which speed
up file listing. So it is used only as a fall-back solution.
(cherry picked from commit 82693aa985)
Added a separate build step that invokes the freshly-built jar that supports
the --date option on jrt-fs.jar before the latter is added to java.base.jmod.
This way both jrt-fs.jar and java.base.jmod have files timestamped with
a pre-determined date in the "reproducible build" mode.
Supplied the --disable-absolute-path-in-output option to the configure script
when building JBR. This option, however, didn't affect the generated
debug info, so added -fdebug-prefix-map to the list of C and
assembler options, which normalized debug info fully on MacOS and partly
on Linux.
On Linux, libjvm.debuginfo contained an ELF symbol of type FILE with an absolute
path name of linux_x86_64.o. This was solved by explicitly specifying
the .file assembler directive in that file and all the other asm files
without one for uniformity.
dcevm instance transformation expects increasing field's offset when
fields of class are iterated. This ordering is no more valid if
UseEmptySlotsInSupers=true.
The problem: the crashes occur in createStatusWindow() when calls like
adata->AwtColorMatch() end up going to 0x0 pc or some random inaccessible
memory. The only reason for that seems to be the
getDefaultConfig(screen) returning either NULL or garbage. That, in turn, probably
happens because of the wrong screen number provided. Before JBR-3623 was
fixed, awt_numScreens could've changed between the time the screen
number was chosen and the getDefaultConfig() call. After JBR-3623 was
fixed, this change is protected with the AWT lock, which this code
holds.
The fix: obtain the screen number via the Xlib API rather than the
ad-hoc loop though the root windows and return NULL if
getDefaultConfig() doesn't return useable data.
(cherry picked from commit 3d23e8d6a5)
Old clear mechanism of CpCacheEntry has cleared partially _flags and the
entire _f1, but both values could be later used in interpreter for
invocation. It ended up with various types of crashes. To prevent dcevm
crashes, we keep the old _f1 and _flags values until they are resolved
again. We need a new flag 'is_f1_null_dcevm_shift' indicating that _f1
is NULL (while f1 keeps old value).
There is a race condition in enhanced redefinition with C1/C2. Therefore
the patch stops C1/C2 compilation before redefinition and release after
redefinition finishing. There is no performance impact since dcevm
flushes all code cache.
jdwp keeps relation class_ptr->class_ref in jvmti tag. class_ptr is used
as a tag key, tag value is refnode. There are new class_ptrs after
redefinition, therefore jdwp redefinition method update all affected
keys in the tag map.
InstanceKlass in ClassLoaderData can be uninitialized when
ClassLoaderDataGraph::classes_do is called. Using
ClassLoaderDataGraph::dictionary_classes_do is safe but problem is still
persisting with anonymous classes.
This patch keeps compatibility with std redefinition, that does not
create a new Klass, but modifies it, then it is modified in all
dictionaries containing this class.
Removed ClassLoaderDataGraph::cld_do was cause of crashes due multiple
oop patching. ClassLoaderDataGraph::cld_do replaced in dcevm15
previously used and removed SystemDictionary:oops_do
ClassLoaderDataGraph::classes_do
ClassLoaderDataGraph::classes_do and need safepoint or lock,
find_sorted_affected_classes is not in safepoint therefore it must be
locked
ClassLoaderDataGraph::rollback_redefinition need safepoint too
+ Change log level in advanced redefinition
- Change log level for "Comparing different class ver.." to debug
- Fix adjust_method_entries_dcevm logging levels and severity
1. We need to set classRedefinitionCount on new class, not old class.
2.Fix crashes in MetadataOnStackMark::~MetadataOnSta
MetadataOnStackMark should not remove dcevm stuff. It was added
accidentaly in dcevm9 and never was part of doit() in previous versions.
3. Fix problem with nested members
Reported at :
https://stackoverflow.com/questions/53370380/hotswapagent-incompatibleclasschangeerror-type-headerpanel1-is-not-a-nest-mem
4. Use init_mark_raw()
method changed since j8 - it used init_mark()
5. Fix methodHandles and fieldHandles
6. Code cleanup
7. Fix force_forward in dead space
8. Fix check_class
9. increment_class_counter() using orig dcevm code
Probably it is cause of SISEGV on:
_
VM_EnhancedRedefineClasses::redefine_single_class->java_mirror()
10 Fix 11.0.7 compilation issues
11. Refactor ClearCpoolCacheAndUnpatch
12. not nullable oop_store_not_null() method+handle NULL in mem_name in
dmh
13. Use INCLUDE_CDS condition on "UseSharedSpaces" block from master
14. Add codecache flush optimization, but just flush all cache.
15. Cleanup
16. Use original code for adjust_method_entries in standard redefinition
17. iterate old method version only in dcevm
18. Revert code for !AllowEnhancedClassRedefinition
19. Code cleanup
20. Activate cpCache definition asserts for !dcevm
21. Skip GC runs for redefinitions without instance size change
22. This is the 2nd commit message:
23. dcevm15 - Cleanup code related to removed CMS
Windows implementation of PipeImpl (that is used in the
ServerSockerChannel implementation) probes for the availability of Unix
Domain Sockets by trying to bind to a unique temporary name. That call
throws IAE when a non-default Java file system is installed while the
probing code (PipeImpl.createListener()) only expects
UnsupportedOperationException or IOException.
The fix is to re-throw UOE instead of IAE in
UnixDomainSockets.genrateTempName(). This is more consistent with the
definition of the excpetion purpose ("requested operation is not
supported"). So with this change, a loopback network socket will be used
to implement a pipe on a non-default Java file system. Also, pipes do
not rely on the default Java file system on other platforms (Linux,
MacOS) as well.
This commits achieves almost the same build output with the same build
input on Linux. Exceptions are:
- class files timestamps differ in jrt-fs.jar (for all output),
- class files timestamps differ in all the jmod files (for
jbrsdk...tar.gz).
NB: jbrsdk...test...tar.gz does not need to be deterministic.
This was achieved mainly by
- setting several environment variables (SOURCE_DATE_EPOCH, TZ),
- providing the necessary options to the configure script,
- setting the timestamp of all files that make up the resulting
archive to SORUCE_DATE_EPOCH and normalizing the list of said
files before archiving.
Removed creation of the separate encoder depending on destination properties as we don't use this info to customize the encoder properties
Fixed incorrect addition of the values into pipeline state cache. Refactored index initialization. Removed unused flags from MTLClip.
Make C1 hotspot compiler bail out during CFG construction if there's a
cycle in the graph that isn't a natural loop and that has led to an
unexpected state of stack/locals like missing a phi function.
This is a temporary measure that lets hotspot continue working
even after encountering such bytecode patterns. The full solution
will probably involve more sophisticated CFG checks.
(cherry picked from commit aa0b61cb75)
* JBR-3926 make AwtComponent transparent for hit events by default
* [WIP] pass hittest event to frame only if custom decoration is enabled and frame ready to handle it
(cherry picked from commit c0e26ff5d5)
The slowness was the result of XWM.getInsetsFromExtents() repeated
attempts to acquire frame extents from a property that under Sway is
simply unavailable. Each attempt added at least 20ms to every re-draw.
Prior to (repeatedly) checking for NET_FRAME_EXTENTS property of a
window, check that the property is supported by the window manager.
(cherry picked from commit b40cc1c791)
This fix addresses two possible causes of crashes:
1. makeDefaultConfig() returning NULL. The fix is to die gracefully
instead of crashing in an attempt to de-reference the NULL pointer.
2. A race condition when the number of screens change (this is only an
issue with the number of xinerama screens; the number of X11 screens is
static for the duration of the X session).
The race scenario: X11GraphisDevice.makeDefaultConfiguration() is called
on EDT so the call can race with X11GraphisDevice.invalidate() that
re-sets the screen number of the device; the latter is invoked on the
"AWT-XAWT" thread from X11GraphicsEnvironment.rebuildDevices(). So by
the time makeDefaultConfiguration() makes a native call with the
device's current screen number, the x11Screens array maintained by the
native code could have become shorter. And the native methods like
Java_sun_awt_X11GraphicsDevice_getConfigColormap() assume that the
screen number passed to them is always current and valid. The AWT lock
only protects against the changes during the native methods invocation,
but does not protect against them being called with an outdated screen
number.
The fix is to eliminate the race by protecting X11GraphisDevice.screen
with the AWT lock.
(cherry picked from commit 0b53cd291f)
The deadlock occurred because one thread was holding the AWT lock and
waiting for boundsCacheLock in resetBoundsCache() and the other vice
versa stuck in pGetBounds() owning boundsCacheLock and waiting for the
AWT lock.
The solution is to get rid of boundsCacheLock altogether. It was
introduced in order to never return null from getBoundsCached() so that
resetBoundsCache() wouldn't interfere. But the same effect can be
achieved by simply using a local variable to hold a copy of the current
bounds. The worst case scenario now is that two threads update
boundsCached immediately one after another (if they both have observed
the null value there at about the same time), but that's harmless as
pGetBounds() grabs the AWT lock when necessary.
(cherry picked from commit dc6ad31524)
Lazy-initialize the static member UNNAMED of UnixDomainSockets so that this
initialization doesn't throw unless actually used. This is only
necessary when using a non-default file system.
The _NET_FRAME_EXTENTS property that is used to obtain the initial
insets of a dialog window does not immediately get its value and may be
returned as 0 if queried too soon after the window creation.
In order to avoid (incorrect) guessing of dialog's insets, make 3
attempts at getting the insets with a small but increasing pause
in between them.
Implemented gamma correction using the same approach that we did for OGL grayscale text rendering (OGLTextRenderer.c). Applied some optimisations to shader code.
1. Cached bounds and insets must be cloned before return because they
aren't immutable objects.
2. Fixed the deadlock in resetBoundsCache() by synchronizing on a dedicated
lock.
(cherry picked from commit cd5314db8b)
Fix regression introduced by Google's NIO patches:
- do not attempt to get the next entry after the directory stream has
been closed already,
- fix FaultyFileSystem that is used in StreamTest.java to throw
the right exception even when getFileAttributeView() is used instead of
readAttributes(),
- removed unnecessary type cast that caused a compilation warning.
Added a test for walking a directory with a non-latin name.
(cherry picked from commit 152a4e886d)
This new interface is similar to `BasicFileAttributeView` except it
gives implementations a hint that the fileKey() should be acquired
even at some performance cost.
`FileTreeWalker` uses this new interface to request a file key
in addition to regular file attributes so that file equality can
be efficiently performed when checking for loops during file
tree traversal.
This makes `FileTreeWalker` about 2x faster when traversing non
trivial file system trees with the FOLLOW_LINKS option.
Change-Id: I8de047c8fc241dbab9ad57c5e361118a3a94893d
(AKA JBR-3680 Cherry-pick Google's NIO patches to get faster file listing)
(cherry picked from commit 6d1c3f06c4)
Use `NtQueryDirectoryInformation` instead of `FindFirst/FindNext` to
retrieve the list of entries of a directory.
`NtQueryDirectionInformation` has 2 main benefits over
`FindFist`/`FindNext`:
* Performance is about 40% faster
* Each retrieved entry retrieved contains a 64-bit `FileId` in addition
to the usual attributes, ensuring that returned `java.nio.Path`
instances hold onto a `BasicFileAttributes` instance that exposes a
non-null `java.nio.file.attribute.BasicFileAttributes.fileKey()`.
This change also requires creating a new WindowsFileKey class, similar
to UnixFileKey class, so that
`java.nio.file.attribute.BasicFileAttributes.fileKey()` can return an
Object instance that can be used to compare files for equality.
With this change, the Windows implementation of Files.walkFileTree is
about 40% faster when the FOLLOW_LINKS option is not used, and about
2.5x faster when the FOLLOW_LINKS option is used.
When the FOLLOW_LINKS option is used, most calls to
`Files.isSameFile`, which is expensive as it requires 2 file I/O
operations, are avoided because the Path entries returned by the
new WindowsDirectoryStream implementation now contain a non-null
BasicFileAttributes.fileKey(). The remaining calls to
`Files.isSameFile` are performed when Files.walkFileTree need
to compare the initial directory with other entries.
Change-Id: Id79d89d477a6d5dcf151c63a9d6072c6f7ef43b2
(AKA JBR-3680 Cherry-pick Google's NIO patches to get faster file listing)
(cherry picked from commit 7c2d7541ba)
This patch:
- Change default behavior to ignore unrecognized options (+IgnoreUnrecognizedVMOptions)
- Store all ignored values to: "java.vm.unrecognized.options" as "+BogusOption01 +BogusOption02" (space separated), see testcase
- Explicitly set -IgnoreUnrecognizedVMOptions for couple of tests, that rely on default behavior
currently, if fails on KDE, if multiple workspaces are configured, because mouse cursor happens to be located over 'pin' button in window title bar,
and that hover causes a tooltip to be shown, which blocks mouse clicks
(cherry picked from commit ad1595b5c2)
Cache screen bounds and insets and (conservatively) reset those caches
upon any possibility of a change.
This feature can be disabled with -Dx11.cache.screen.insets=false and
-Dx11.cache.screen.bounds=false.
Based on commit accef6f21e.
Detect if we're running on a musl-based system by checking for the presence
of the libgcompat.so glibc compatibility library in the process' map.
If so, java is re-started with LD_LIBRARY_PATH set to point to the right
directory with libjvm.so. This works around the problem with the musl
dynamic library loader.
(based on commit 13a904ddb5)
Introduced logging controlled with -Dsun.awt.x11.trace.
Currently, only looks at the AWT lock and reports methods holding it
sorted by average hold time.
(based on commit 792a58ea0e)
(based on commit 770b4dc9c1)
8269301: Switch statement with a pattern, constant and default label elements crash javac
Reviewed-by: mcimadamore
(cherry picked from commit 885f7b1141)
Exclude VM error-reporting code that treats memory as a raw sequence of
bytes from address sanitizer checks. This is needed to only get true
reports when running tests against the --enable-asan build.
Added a separate pass with sending setVisible(false) to the frames holding TitledBorder references in order to get WINDOW_DEACTIVATED (to clear KeyBoardFocusManager.activeWindow field)
(cherry picked from commit 3b03c698ce)
- changed open popup shortcut from Ctrl+N to Ctrl+M, so no new explorer windows appear if desktop gets focused by error
- added a click on the main test frame, so it gets focus when running from background cygwin process on Windows, otherwise it just flashes on the taskbar
(cherry picked from commit eda8e4d50e)
fixed JBR-3127 Modal dialogs invoked from modal or floating dialogs are opened in full screen
(cherry picked from commit 0b8ff1a7e6)
JBR-3127: add possibility to load NSJavaVirtualMachine
JavaVM framework is deprecated but this class is still checked by AppKit, see https://youtrack.jetbrains.com/issue/JBR-3127#focus=Comments-27-4684465.0-0
(cherry picked from commit be6a2c4f0c)
Adopted version of "JRE-864 Multiple child windows opened and closed in sequence"
(cherry picked from commits 54bb2dd097, 68c2fd0e3b, part of 1a9838082e)
use the new invocation approach for 'makeKeyAndOrderFront' as well, as it can also cause synchronous back-calls to accessibility subsystem, and change the global call order unexpectedly
this commit fixes TypeaheadSetVisibleTest and TypeaheadToFrontTest, when they are run with AltTab active
Guard against possible deadlocks, if UI-related methods are invoked not on EDT.
Sample deadlock scenario:
* Application thread attempts to show the window, this involves calling CWrapper.NSWindow.makeKeyAndOrderFront under AWT tree lock, which blocks till 'makeKeyAndOrderFront' completes on AppKit thread
* AppKit thread, while executing 'makeKeyAndOrderFront' performs 'back-call' to CAccessibility.getFocusOwner, which waits for execution on EDT
* EDT performs some activity requiring AWT tree lock (e.g. processing of PaintEvent)
(cherry picked from commits e3aaff5db4, 09941119e1)
Implemented alpha blending in grayscale text rendering (UX-1320)
Corrected bright text thickness (smooth on), bright and dark text thickness (smooth off)
Added JVM properties for fine tuning
(cherry picked from commit c30306f779)
(cherry picked from commit c95adeb8f2)
(cherry picked from commit 269c9580fb)
(cherry picked from commit 55c7be5fe9)
(cherry picked from commit e28ff71e97)
Converted gradle JUnit test to plain java for ant and gnumake
To run the tests:
cd src/demo/share/java2d/RenderPerfTest
ant run
or
java -jar dist/RenderPerfTest.jar
or
java -jar dist/RenderPerfTest.jar testWhiteTextBubblesGray
(cherry picked from commit 356121b18f)
(cherry picked from commit 8bd8d2d132)
JBR-2412 [windows] mouse listener does not work for jcef
(cherry picked from commit 66ad6472ae)
(cherry picked from commit 04246aac57)
(cherry picked from commit b7cde4fd05)
Introduced sun.awt.osx.RobotSafeDelayMillis property to control macOS specific safe delay for Robot methods.
50 ms safe delay was initially hardcoded in 3862142d (JDK-8242174: [macos] The NestedModelessDialogTest test make the macOS unstable) which affected performance tests execution.
(cherry picked from commit 5f691bb788)
Checks that JS Query is handled in 2nd opened browser
(cherry picked from commit 404ff84565)
Refactoring + changed EDT awaiting method
(cherry picked from commit dc24658b31)
Used user home dir for jbr_err files. Removed logging with reportException method
(cherry picked from commit 2c8cdb221b)
JBR-2382 Provide detailed stack trace in crash dumps for unhandled ObjC exceptions
Used process workdir for jbr_err files. Added one more logging to reportException method
(cherry picked from commit 95a47810d5)
JBR-2382 Provide detailed stack trace in crash dumps for unhandled ObjC exceptions
Generate jbr_err_pidXX.log file with detailed stack trace of the exception
(cherry picked from commit 4c42f75021)
- added workaround for JBR-2585
- added README.md about manual test run
- made an update to close LinuxTouchScreenDevice properly
- added an error exit from linux shell script if sudo password is empty or chown fails
(cherry picked from commit 4deb3bbe61)
Update regression test after the following commits:
02fad83c: Remove public constants from KeyEvent
f4227faf: Impossible to assign cmd+ß shortcuts
(cherry picked from commit 264802cf4b)
Updated reproducer
(cherry picked from commit 529a188b8b)
JBR-2256 JEditorPane with test/html type and zero margins is not shown
Added reproducer
(cherry picked from commit 41578a40b5)
Returning devanagari subset back for ja.UTF-8 to get non-null font name from WFontConfiguration.getTextComponentFontName(). It is a regression from JDK-8208179.
(cherry picked from commit b51254a975)
- java/awt/TextArea/DisposeTest/TestDispose.java, java/awt/TextField/DisposeTest/TestDispose.java: fixed test frame disposal
- java/awt/Frame/DisposeStressTest/DisposeStressTest.java: decreased test timeout from 2h to 10 min, added minor diagnostic logging
(cherry picked from commit 7f025f4e16)
(cherry picked from commit dda7f3d871)
(cherry picked from commit bc09aadadb)
1. NSFont.familyName is faster than loading allFamilyNames
2. Prebuilt list of system fonts
3. Cleanup San Francisco family loading
4. Avoid calling expensive native getWidth on font when creating font family, load styles only when they would be used.
because requesting focus for frame-parent causes to close whole popup chain
(cherry picked from commit 7a2ccfc521)
JBR-1762: fixed review comments
(cherry picked from commit 0efbe5d9b9)
The proposed solution is to use a 'normal' font as a base for 'San Francisco' font fallback.
Most of its fallback components/candidates (provided by the OS) are expected to be normal
fonts as well, and so the resulting coverage of Unicode character repertoire should be much better.
(cherry picked from commits 9b7113a6cf, 92b00d50b5, 53489fab27)
The fix consists of two parts:
* Making CCharToGlyphMapper remember that a particular character cannot be displayed (isn't mapped to glyph with given font). Checking this repeatedly in native code is very slow.
* Make CCompositeGlyphMapper remember the results of char-to-glyph mapping, this was missing in previous implementation. This reuses caching code in CompositeGlyphMapper, extending the range of characters for which the results are cached to include Supplementary Multilingual Plane (most emoji characters belong to it).
port commit 4e0ccde2 from JBR 9
port from JBR 11 to JBR 15 (cherry picked from commit 394e055ae6)
cherry picked from commit 0db7e948af
Added -it pattern into italic detection code
Added some more patterns to bold and italic detection code
'Anka/Coder' font support
(cherry picked from commit 5119eeee12)
(cherry picked from commit ec241e4a0a)
(cherry picked from commit 251068294e)
(cherry picked from commit 08ae9ff034)
Use different family for specific font faces. Refactoring
JBR-3071 Remove naming workaround for Fira Code
(cherry picked from commits c423003bd4, aee4b48d20)
Used CFont instead of TrueTypeFont for bundled fonts on mac
Use different family for specific font faces. Refactoring
(cherry picked from commit 8c86ad3e96)
(cherry picked from commit c423003bd4)
(cherry picked from commit bcae402dc8)
Update family name for JetBrainsMono-Thin
(cherry picked from commit 0d2326ff34)
(cherry picked from commit 83843f9124)
(cherry picked from commit 2a2e1cfb36)
(cherry picked from commit 76abb69262)
When XGetImage() calls become slow in a remote X11 session, fake
XGetImage() with client-side XCreateImage() that is filled with some
background color. The color is chosen from several top left corner
pixels of the "slow" images obtained with XGetImage().
This feature activates in a remote X11 session only and is
controlled with -Dremote.x11.workaround={true|false|auto}.
Fix modality for Common Item Dialog
squash! JBR-1257 CommonItemDialog modal window has no owner
JBR-2478 java/awt/Modal/FileDialog/FileDialogNonModal7Test.java: DummyButton on Dialog did not gain focus when clicked
revert part of JBR-1271, that's related to 'old' file dialogs
Replaced [NSScreen screens] 'objectAtIndex' with 'firstObject' to get nil instead of NSRangeException. Added nil checks
(cherry picked from commit d6b98511262055c01522d9ec8024253af7e91564)
(cherry picked from commit cef970e1ba)
Increased rendering queue buffer up to 6.4 MB
(cherry picked from commit 9ef00f00a7fb6e14835393f8d3944157c6800727)
(cherry picked from commit 2a61e9e997a880a60c5acb361849205170501b91)
(cherry picked from commit 68ca9f00ded004c970b94bd047a04b9f09237047)
(cherry picked from commit 2fe5289178)
Added processing system events while waiting for OGLRenderQueue.lock
Moved getCGLConfigInfo logic execution to AppKit thread so, awt lock is
taken on one thread
(cherry picked from commit d1c8bf03e1bd41cb075aa73cc39558103af7fe1a)
(cherry picked from commit 6bf9f31986be64acf3755b34568802f9960a66ec)
(cherry picked from commit 4e21d67e0369bffac45662c63699b39946218a7a)
Moved CG api calls to AppKit thread
(cherry picked from commit fd0210f035199e8612097a2c1d42b90cfd2111f8)
(cherry picked from commit 5e99e376d9dfe477401121878704630c3c13f9f7)
(cherry picked from commit 6d73b25130)
Replaced number of CGWindowListCopyWindowInfo for each window layer with [NSWindow windowNumberAtPoint: belowWindowWithWindowNumber:]
(cherry picked from commit 2a143af4d62340acdfd9c94d876f684385febbc8)
(cherry picked from commit 6fc369e8bf)
Replaced glyph outlines with bounding boxes for glyph boundaries calculation for most common usages. Also, skipped unnecessary OGL flushes in OGL rendering queue
(cherry picked from commit c58dc052af48887338a38beb0c721eddca3af481)
(cherry picked from commit 7f6be7cfb907bbf1c3572b911df5690fa3039fde)
(cherry picked from commit c68913d82c0ba4b4c509179123f0a4bf7971f857)
(cherry picked from commit 9cfa04c93ad416a8177d9e7ca410850bd3ff880f)
(cherry picked from commit 0e930841704e4e98ecc0c888b144245e74218799)
(cherry picked from commit 8ffc190fbdb059d5a24842115c0bc3ade8b351b9)
(cherry picked from commit 0f7c26186a)
Adopted CThreading related code to OpenJDK17 source base
(cherry picked from commit 5dfb30ae68b2c54d58c98a9195709c031f823581)
(cherry picked from commit 94163bd69f64616836523e81567aa1141480d841)
Added detection of Awesome WM and handled similar to Sawfish WM
(cherry picked from commit 6742077ed198975949af567e8ef543f853397351)
(cherry picked from commit 2847be73c6)
this test failing in jtreg launch most probably indicates either some problem with the environment (e.g. some windows left open from previously launched processes) or with java.awt.Robot implementation
(cherry picked from commit 1d525a2d2f)
This changes the fonts JDK uses for font fallback on Windows. These used to be DokChampa (for Thai) and Batang/Gulim/Gulim (for Korean).
Those fonts are not available by default on Windows 10, user needs to install supplementary font language packs to get them.
Now the following fonts will be used - Tahoma (for Thai) and Malgun Gothic (for Korean). They are available by default
on Windows 7, 8 and 10.
port from JBR 11 to JBR 15 (cherry picked from commit 850653192b)
cherry picked from commit 2bf43a57ab
Throwing InvalidPipeException for incompatible surfaces
(cherry picked from commit 55dab103c24bf86cf025b9ce02b67e72508d41ba)
(cherry picked from commit 0a4fdad0f2)
Corrected rendering hints for Non-AA text rendering
(cherry picked from commit b923aa7a0729a10ea47d3438622d659fbead44c9)
(cherry picked from commit b6bdd04e41)
Added property to disable bundled font config:
java2d.font.loadFontConf=false
Do not load custom font.conf by default
Moved hints adjusting logic from code to bundled font.conf file
Applied correction only for regular fonts with platform sizes less than 12
Some fonts are not corrected at all: Consolas, Noto Sans Mono
Used family name instead of physical one in requests to Fontconfig
Removed redundant call to FcConfigBuildFonts
Added privileged access to the properties (JRE-235,JRE-235)
(cherry picked from commit 4d4c915047077ebd966b0e3be056566d56ba11a4)
(cherry picked from commit 9d6f325f72482405264852f3ee2636f5fedaeaf0)
(cherry picked from commit e7e3372bf8db539c0f6bc85db9f1093f8fa4c380)
(cherry picked from commit 3e724caed2f199be50d25d1ecb20b7819c86be2e)
(cherry picked from commit d372b35963c096a32331b05b257e26841ace5d94)
(cherry picked from commit 18a5f5de03eb107f89dca138a44b9aab2151235c)
(cherry picked from commit 9ba320efef0539f75aa93fd1b5dd80266c954d0a)
(cherry picked from commit b8c38f419972af61291953f7f452c1698f7a1624)
(cherry picked from commit debba0128e200be60adc9a339d5985590ef4e230)
(cherry picked from commit 2fa17b1bd7d6524e4b5fa4d0b3ce2bf02a8fcc78)
(cherry picked from commit 09b4f61db0d4f5beea0e16ce9136c99e2185c10b)
(cherry picked from commit 3b6782dd742f9c74a9535145db2f9f7ffaccf7c8)
(cherry picked from commit f1b68149528c13a22fa64468c130b1405bf3d081)
(cherry picked from commit db5cf5a2b9cb454630fb86783c2d58cd5446cba6)
(cherry picked from commit 32140948578bc3c2a0c5f8adb537660421efe5e7)
(cherry picked from commit b978e3d0b131ed642774c5a14a649e13f764c20b)
(cherry picked from commit c75c1ef8b2)
(cherry picked from commit a29f19e6a2)
don't apply FreeType-returned glyph advance for rotated glyphs rendered by GDI
This seems to produce a better looking text (more evenly spaced). Fractional metrics won't be respected by this code, but we can address this later if needed.
port commits c9debd5e, ed78cd00, 4c7e1619, 7aa0429c, 7bd6c17c from JBR 9
port from JBR 11 to JBR 15 (cherry picked from commits d6b588bdab, dbc15fb84e)
cherry picked from commit 2c0d6150d0
Skip FT_Library_setLcdFilter call if the symbol is not there
Cache negative FT_Library_setLcdFilter symbol lookup result
Used RTLD_DEFAULT handler for process symbols lookup
(cherry picked from commit e6f0055704)
Disable FT_LOAD_TARGET_LIGHT for fonts with FC_AUTOHINT=false (this target implicitly enables FC_AUTOHINT)
Reused setupLoadRenderFlags for all rendering cases
(cherry picked from commit f3f2667a4c)
This code is needed for "Read org.gnome.desktop.interface/scaling-factor".
Keep it until "JDK-8260270 Implement the HiDPI scale factor reading" is fixed.
This reverts commit a7c2ebc7
Was "don't fallback on fractional scale" in JBSDK9.
(cherry picked from commit 263d8641974d263075c93f11c4db6208754d7325)
(cherry picked from commit deeda6fada)
updateGC() is called from WWindowPeer.<init> though it's not applicable to the named dialogs
as they don't have native AwtWindow peer required for the method.
(cherry picked from commit 72ed9f653177e273b811cfe70c2dba102a8636e4)
(cherry picked from commit cec49aaa38)
This lets awt_Win32GraphicsEnv.cpp SetProcessDPIAwareProperty() call Win7 specific ::SetProcessDPIAware() API func.
(cherry picked from commit 5e7a766090810d839f4352d06fc2812499d766f8)
(cherry picked from commit 7d1d43bfa1)
Use the GTK method:
https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#g-object-get
to retrieve "gtk-xft-dpi" integer property of the X settings.
Add the property to JDK's GtkEngine & gtk2-interface.
Then read the property via GtkEngine from GTK LaF when "gnome.Xft/dpi" is undefined. It's assumed GTK LaF is forcedly installed.
(cherry picked from commit e05fc391ae0a3cc389e836441f882c0cf6ab3b99)
(cherry picked from commit fd615a5b45)
Used desktop DPI instead of hard-coded 72
Compensated increased glyph bitmap size by adjusting font size
Added LCD filter for sub-pixel rendering
Use fontconfig library to provide right rendering options for fonts
Corrected sizes passed to fontconfig library and hinting disabling policy
Added logging and versioned fontconfig lib loading
Resolved font rendering problem in lenses
(cherry picked from commit 0456745afb)
IDEA-152816, IDEA-152454 fix text rendering issues (text cutoff and incorrect rendering in editor fragment components)
FcMatchFont-type pattern substitutions shouldn't be invoked before specific font is selected - it can apply unrelated rules
port commit e21cd635 from JBR 9
(cherry picked from commit 5d704a963b)
partially rollback JBR-363 fix, to apply corresponding change from OpenJDK 12
(cherry picked from commit 3d7ac30072)
echo"Failure summary ($BUILD_DIR/make-support/failure-summary.log) not found"
fi
echo'```'
echo'</details>'
echo''
echo''
echo':arrow_right: To see the entire test log, click the job in the list to the left. To download logs, see the `failure-logs` [artifact above](#artifacts).'
<h3id="building-on-aarch64">Building on aarch64</h3>
<p>At a minimum, a machine with 8 cores is advisable, as well as 8 GB of RAM. (The more cores to use, the more memory you need.) At least 6 GB of free disk space is required.</p>
<p>If you do not have access to sufficiently powerful hardware, it is also possible to use <ahref="#cross-compiling">cross-compiling</a>.</p>
<h4id="branch-protection">Branch Protection</h4>
<p>In order to use Branch Protection features in the VM, <code>--enable-branch-protection</code> must be used. This option requires C++ compiler support (GCC 9.1.0+ or Clang 10+). The resulting build can be run on both machines with and without support for branch protection in hardware. Branch Protection is only supported for Linux targets.</p>
<h3id="building-on-32-bit-arm">Building on 32-bit arm</h3>
<p>This is not recommended. Instead, see the section on <ahref="#cross-compiling">Cross-compiling</a>.</p>
<h2id="operating-system-requirements">Operating System Requirements</h2>
@@ -198,7 +196,7 @@
<h3id="windows">Windows</h3>
<p>Windows XP is not a supported platform, but all newer Windows should be able to build the JDK.</p>
<p>On Windows, it is important that you pay attention to the instructions in the <ahref="#special-considerations">Special Considerations</a>.</p>
<p>Windows is the only non-POSIX OS supported by the JDK, and as such, requires some extra care. A POSIX support layer is required to build on Windows. Currently, the only supported such layers are Cygwin, Windows Subsystem for Linux (WSL), and MSYS2. (MSYS is no longer supported due to an outdated bash; While OpenJDK can be built with MSYS2, support for it is still experimental, so build failures and unusual errors are not uncommon.)</p>
<p>Windows is the only non-POSIX OS supported by the JDK, and as such, requires some extra care. A POSIX support layer is required to build on Windows. Currently, the only supported such layers are Cygwin and Windows Subsystem for Linux (WSL). (Msys is no longer supported due to a too old bash; msys2 would likely be possible to support in a future version but that would require effort to implement.)</p>
<p>Internally in the build system, all paths are represented as Unix-style paths, e.g. <code>/cygdrive/c/git/jdk/Makefile</code> rather than <code>C:\git\jdk\Makefile</code>. This rule also applies to input to the build system, e.g. in arguments to <code>configure</code>. So, use <code>--with-msvcr-dll=/cygdrive/c/msvcr100.dll</code> rather than <code>--with-msvcr-dll=c:\msvcr100.dll</code>. For details on this conversion, see the section on <ahref="#fixpath">Fixpath</a>.</p>
<h4id="cygwin">Cygwin</h4>
<p>A functioning <ahref="http://www.cygwin.com/">Cygwin</a> environment is required for building the JDK on Windows. If you have a 64-bit OS, we strongly recommend using the 64-bit version of Cygwin.</p>
@@ -216,7 +214,7 @@
<p>Unfortunately, Cygwin can be unreliable in certain circumstances. If you experience build tool crashes or strange issues when building on Windows, please check the Cygwin FAQ on the <ahref="https://cygwin.com/faq/faq.html#faq.using.bloda">"BLODA" list</a> and the section on <ahref="https://cygwin.com/faq/faq.html#faq.using.fixing-fork-failures">fork() failures</a>.</p>
<h4id="windows-subsystem-for-linux-wsl">Windows Subsystem for Linux (WSL)</h4>
<p>Windows 10 1809 or newer is supported due to a dependency on the wslpath utility and support for environment variable sharing through WSLENV. Version 1803 can work but intermittent build failures have been observed.</p>
<p>It's possible to build both Windows and Linux binaries from WSL. To build Windows binaries, you must use a Windows boot JDK (located in a Windows-accessible directory). To build Linux binaries, you must use a Linux boot JDK. The default behavior is to build for Windows. To build for Linux, pass <code>--build=x86_64-unknown-linux-gnu --openjdk-target=x86_64-unknown-linux-gnu</code> to <code>configure</code>.</p>
<p>It's possible to build both Windows and Linux binaries from WSL. To build Windows binaries, you must use a Windows boot JDK (located in a Windows-accessible directory). To build Linux binaries, you must use a Linux boot JDK. The default behavior is to build for Windows. To build for Linux, pass <code>--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu</code> to <code>configure</code>.</p>
<p>If building Windows binaries, the source code must be located in a Windows- accessible directory. This is because Windows executables (such as Visual Studio and the boot JDK) must be able to access the source code. Also, the drive where the source is stored must be mounted as case-insensitive by changing either /etc/fstab or /etc/wsl.conf in WSL. Individual directories may be corrected using the fsutil tool in case the source was cloned before changing the mount options.</p>
<p>Note that while it's possible to build on WSL, testing is still not fully supported.</p>
<h3id="macos">macOS</h3>
@@ -273,7 +271,7 @@
<tbody>
<trclass="odd">
<tdstyle="text-align: left;">Linux</td>
<tdstyle="text-align: left;">gcc 11.2.0</td>
<tdstyle="text-align: left;">gcc 10.2.0</td>
</tr>
<trclass="even">
<tdstyle="text-align: left;">macOS</td>
@@ -281,14 +279,14 @@
</tr>
<trclass="odd">
<tdstyle="text-align: left;">Windows</td>
<tdstyle="text-align: left;">Microsoft Visual Studio 2022 update 17.1.0</td>
<tdstyle="text-align: left;">Microsoft Visual Studio 2019 update 16.7.2</td>
</tr>
</tbody>
</table>
<p>All compilers are expected to be able to compile to the C99 language standard, as some C99 features are used in the source code. Microsoft Visual Studio doesn't fully support C99 so in practice shared code is limited to using C99 features that it does support.</p>
<h3id="gcc">gcc</h3>
<p>The minimum accepted version of gcc is 5.0. Older versions will generate a warning by <code>configure</code> and are unlikely to work.</p>
<p>The JDK is currently known to be able to compile with at least version 11.2 of gcc.</p>
<p>The JDK is currently known to be able to compile with at least version 10.2 of gcc.</p>
<p>In general, any version between these two should be usable.</p>
<h3id="clang">clang</h3>
<p>The minimum accepted version of clang is 3.5. Older versions will not be accepted by <code>configure</code>.</p>
@@ -300,7 +298,7 @@
<p>It is advisable to keep an older version of Xcode for building the JDK when updating Xcode. This <ahref="http://iosdevelopertips.com/xcode/install-multiple-versions-of-xcode.html">blog page</a> has good suggestions on managing multiple Xcode versions. To use a specific version of Xcode, use <code>xcode-select -s</code> before running <code>configure</code>, or use <code>--with-toolchain-path</code> to point to the version of Xcode to use, e.g. <code>configure --with-toolchain-path=/Applications/Xcode8.app/Contents/Developer/usr/bin</code></p>
<p>If you have recently (inadvertently) updated your OS and/or Xcode version, and the JDK can no longer be built, please see the section on <ahref="#problems-with-the-build-environment">Problems with the Build Environment</a>, and <ahref="#getting-help">Getting Help</a> to find out if there are any recent, non-merged patches available for this update.</p>
<p>For aarch64 machines running Windows the minimum accepted version is Visual Studio 2019 (16.8 or higher). For all other platforms the minimum accepted version of Visual Studio is 2017. Older versions will not be accepted by <code>configure</code> and will not work. For all platforms the maximum accepted version of Visual Studio is 2022.</p>
<p>The minimum accepted version of Visual Studio is 2017. Older versions will not be accepted by <code>configure</code> and will not work. The maximum accepted version of Visual Studio is 2019.</p>
<p>If you have multiple versions of Visual Studio installed, <code>configure</code> will by default pick the latest. You can request a specific version to be used by setting <code>--with-toolchain-version</code>, e.g. <code>--with-toolchain-version=2017</code>.</p>
<p>If you have Visual Studio installed but <code>configure</code> fails to detect it, it may be because of <ahref="#spaces-in-path">spaces in path</a>.</p>
<h3id="ibm-xl-cc">IBM XL C/C++</h3>
@@ -491,7 +489,7 @@
<li><code>CONF</code> and <code>CONF_NAME</code> - Selecting the configuration(s) to use. See <ahref="#using-multiple-configurations">Using Multiple Configurations</a></li>
</ul>
<h4id="test-make-control-variables">Test Make Control Variables</h4>
<p>These make control variables only make sense when running tests. Please see <strong>Testing the JDK</strong> (<ahref="testing.html">html</a>, <ahref="testing.md">markdown</a>) for details.</p>
<p>These make control variables only make sense when running tests. Please see <ahref="testing.html">Testing the JDK</a> for details.</p>
<ul>
<li><code>TEST</code></li>
<li><code>TEST_JOBS</code></li>
@@ -517,7 +515,7 @@
</ul>
<p>To execute the most basic tests (tier 1), use:</p>
<pre><code>make run-test-tier1</code></pre>
<p>For more details on how to run tests, please see <strong>Testing the JDK</strong> (<ahref="testing.html">html</a>, <ahref="testing.md">markdown</a>).</p>
<p>For more details on how to run tests, please see the <ahref="testing.html">Testing the JDK</a> document.</p>
<h2id="cross-compiling">Cross-compiling</h2>
<p>Cross-compiling means using one platform (the <em>build</em> platform) to generate output that can ran on another platform (the <em>target</em> platform).</p>
<p>The typical reason for cross-compiling is that the build is performed on a more powerful desktop computer, but the resulting binaries will be able to run on a different, typically low-performing system. Most of the complications that arise when building for embedded is due to this separation of <em>build</em> and <em>target</em> systems.</p>
<p>To be able to build, we need a "Build JDK", which is a JDK built from the current sources (that is, the same as the end result of the entire build process), but able to run on the <em>build</em> system, and not the <em>target</em> system. (In contrast, the Boot JDK should be from an older release, e.g. JDK 8 when building JDK 9.)</p>
<p>The build process will create a minimal Build JDK for you, as part of building. To speed up the build, you can use <code>--with-build-jdk</code> to <code>configure</code> to point to a pre-built Build JDK. Please note that the build result is unpredictable, and can possibly break in subtle ways, if the Build JDK does not <strong>exactly</strong> match the current sources.</p>
<h3id="specifying-the-target-platform">Specifying the Target Platform</h3>
<p>You <em>must</em> specify the target platform when cross-compiling. Doing so will also automatically turn the build into a cross-compiling mode. The simplest way to do this is to use the <code>--openjdk-target</code> argument, e.g. <code>--openjdk-target=arm-linux-gnueabihf</code>. or <code>--openjdk-target=aarch64-oe-linux</code>. This will automatically set the <code>--host</code> and <code>--target</code> options for autoconf, which can otherwise be confusing. (In autoconf terminology, the "target" is known as "host", and "target" is used for building a Canadian cross-compiler.)</p>
<p>If <code>--build</code> has not been explicitly passed to configure, <code>--openjdk-target</code> will autodetect the build platform and internally set the flag automatically, otherwise the platform that was explicitly passed to <code>--build</code> will be used instead.</p>
<p>You <em>must</em> specify the target platform when cross-compiling. Doing so will also automatically turn the build into a cross-compiling mode. The simplest way to do this is to use the <code>--openjdk-target</code> argument, e.g. <code>--openjdk-target=arm-linux-gnueabihf</code>. or <code>--openjdk-target=aarch64-oe-linux</code>. This will automatically set the <code>--build</code>, <code>--host</code> and <code>--target</code> options for autoconf, which can otherwise be confusing. (In autoconf terminology, the "target" is known as "host", and "target" is used for building a Canadian cross-compiler.)</p>
<p>You will need two copies of your toolchain, one which generates output that can run on the target system (the normal, or <em>target</em>, toolchain), and one that generates output that can run on the build system (the <em>build</em> toolchain). Note that cross-compiling is only supported for gcc at the time being. The gcc standard is to prefix cross-compiling toolchains with the target denominator. If you follow this standard, <code>configure</code> is likely to pick up the toolchain correctly.</p>
<p>The <em>build</em> toolchain will be autodetected just the same way the normal <em>build</em>/<em>target</em> toolchain will be autodetected when not cross-compiling. If this is not what you want, or if the autodetection fails, you can specify a devkit containing the <em>build</em> toolchain using <code>--with-build-devkit</code> to <code>configure</code>, or by giving <code>BUILD_CC</code> and <code>BUILD_CXX</code> arguments.</p>
@@ -810,7 +807,7 @@ ls build/linux-aarch64-server-release/</code></pre></li>
<p><ahref="http://github.com/icecc/icecream">icecc/icecream</a> is a simple way to setup a distributed compiler network. If you have multiple machines available for building the JDK, you can drastically cut individual build times by utilizing it.</p>
<p>To use, setup an icecc network, and install icecc on the build machine. Then run <code>configure</code> using <code>--enable-icecc</code>.</p>
<h3id="using-sjavac">Using sjavac</h3>
<p>To speed up compilation of Java code, especially during incremental compilations, the sjavac server is automatically enabled in the configuration step by default. To explicitly enable or disable sjavac, use either <code>--enable-javac-server</code> or <code>--disable-javac-server</code>.</p>
<p>To speed up Java compilation, especially incremental compilations, you can try the experimental sjavac compiler by using <code>--enable-sjavac</code>.</p>
<h3id="building-the-right-target">Building the Right Target</h3>
<p>Selecting the proper target to build can have dramatic impact on build time. For normal usage, <code>jdk</code> or the default target is just fine. You only need to build <code>images</code> for shipping, or if your tests require it.</p>
<p>See also <ahref="#using-fine-grained-make-targets">Using Fine-Grained Make Targets</a> on how to build an even smaller subset of the product.</p>
@@ -890,28 +887,30 @@ spawn failed</code></pre>
<p>If you need general help or advice about developing for the JDK, you can also contact the Adoption Group. See the section on <ahref="#contributing-to-openjdk">Contributing to OpenJDK</a> for more information.</p>
<p>Build reproducibility is the property of getting exactly the same bits out when building, every time, independent on who builds the product, or where. This is for many reasons a harder goal than it initially appears, but it is an important goal, for security reasons and others. Please see <ahref="https://reproducible-builds.org">Reproducible Builds</a> for more information about the background and reasons for reproducible builds.</p>
<p>Currently, it is not possible to build OpenJDK fully reproducibly, but getting there is an ongoing effort.</p>
<p>An absolute prerequisite for building reproducible is to speficy a fixed build time, since time stamps are embedded in many file formats. This is done by setting the <code>SOURCE_DATE_EPOCH</code> environment variable, which is an <ahref="https://reproducible-builds.org/docs/source-date-epoch/">industry standard</a>, that many tools, such as gcc, recognize, and use in place of the current time when generating output.</p>
<p>To generate reproducible builds, you must set <code>SOURCE_DATE_EPOCH</code> before running <code>configure</code>. The value in <code>SOURCE_DATE_EPOCH</code> will be stored in the configuration, and used by <code>make</code>. Setting <code>SOURCE_DATE_EPOCH</code> before running <code>make</code> will have no effect on the build.</p>
<p>You must also make sure your build does not rely on <code>configure</code>'s default adhoc version strings. Default adhoc version strings <code>OPT</code> segment include user name and source directory. You can either override just the <code>OPT</code> segment using <code>--with-version-opt=<any fixed string></code>, or you can specify the entire version string using <code>--with-version-string=<your version></code>.</p>
<p>This is a typical example of how to build the JDK in a reproducible way:</p>
<pre><code>export SOURCE_DATE_EPOCH=946684800
bash configure --with-version-opt=adhoc
make</code></pre>
<p>Note that regardless if you specify a source date for <code>configure</code> or not, the JDK build system will set <code>SOURCE_DATE_EPOCH</code> for all build tools when building. If <code>--with-source-date</code> has the value <code>updated</code> (which is the default unless <code>SOURCE_DATE_EPOCH</code> is found by in the environment by <code>configure</code>), the source date value will be determined at build time.</p>
<p>There are several aspects of reproducible builds that can be individually adjusted by <code>configure</code> arguments. If any of these are given, they will override the value derived from <code>SOURCE_DATE_EPOCH</code>. These arguments are:</p>
<p>Currently, it is not possible to build OpenJDK fully reproducibly, but getting there is an ongoing effort. There are some things you can do to minimize non-determinism and make a larger part of the build reproducible:</p>
<ul>
<li><p><code>--with-source-date</code></p>
<p>This option controls how the JDK build sets <code>SOURCE_DATE_EPOCH</code> when building. It can be set to a value describing a date, either an epoch based timestamp as an integer, or a valid ISO-8601 date.</p>
<p>It can also be set to one of the special values <code>current</code>, <code>updated</code> or <code>version</code>. <code>current</code> means that the time of running <code>configure</code> will be used. <code>version</code> will use the nominal release date for the current JDK version. <code>updated</code>, which means that <code>SOURCE_DATE_EPOCH</code> will be set to the current time each time you are running <code>make</code>. All choices, except for <code>updated</code>, will set a fixed value for the source date timestamp.</p>
<p>When <code>SOURCE_DATE_EPOCH</code> is set, the default value for <code>--with-source-date</code> will be the value given by <code>SOURCE_DATE_EPOCH</code>. Otherwise, the default value is <code>updated</code>.</p></li>
<li><p><code>--with-hotspot-build-time</code></p>
<p>This option controls the build time string that will be included in the hotspot library (<code>libjvm.so</code> or <code>jvm.dll</code>). When the source date is fixed (e.g. by setting <code>SOURCE_DATE_EPOCH</code>), the default value for <code>--with-hotspot-build-time</code> will be an ISO 8601 representation of that time stamp. Otherwise the default value will be the current time when building hotspot.</p></li>
<li><p><code>--with-copyright-year</code></p>
<p>This option controls the copyright year in some generated text files. When the source date is fixed (e.g. by setting <code>SOURCE_DATE_EPOCH</code>), the default value for <code>--with-copyright-year</code> will be the year of that time stamp. Otherwise the default is the current year at the time of running configure. This can be overridden by <code>--with-copyright-year=<year></code>.</p></li>
<p>This option controls some additional behavior needed to make the build reproducible. When the source date is fixed (e.g. by setting <code>SOURCE_DATE_EPOCH</code>), this flag will be turned on by default. Otherwise, the value is determined by heuristics. If it is explicitly turned off, the build might not be reproducible.</p></li>
<li>Turn on build system support for reproducible builds</li>
</ul>
<p>Add the flag <code>--enable-reproducible-build</code> to your <code>configure</code> command line. This will turn on support for reproducible builds where it could otherwise be lacking.</p>
<ul>
<li>Do not rely on <code>configure</code>'s default adhoc version strings</li>
</ul>
<p>Default adhoc version strings OPT segment include user name, source directory and timestamp. You can either override just the OPT segment using <code>--with-version-opt=<any fixed string></code>, or you can specify the entire version string using <code>--with-version-string=<your version></code>.</p>
<ul>
<li>Specify how the build sets <code>SOURCE_DATE_EPOCH</code></li>
</ul>
<p>The JDK build system will set the <code>SOURCE_DATE_EPOCH</code> environment variable during building, depending on the value of the <code>--with-source-date</code> option for <code>configure</code>. The default value is <code>updated</code>, which means that <code>SOURCE_DATE_EPOCH</code> will be set to the current time each time you are running <code>make</code>.</p>
<p>The <ahref="https://reproducible-builds.org/docs/source-date-epoch/"><code>SOURCE_DATE_EPOCH</code> environment variable</a> is an industry standard, that many tools, such as gcc, recognize, and use in place of the current time when generating output.</p>
<p>For reproducible builds, you need to set this to a fixed value. You can use the special value <code>version</code> which will use the nominal release date for the current JDK version, or a value describing a date, either an epoch based timestamp as an integer, or a valid ISO-8601 date.</p>
<p><strong>Hint:</strong> If your build environment already sets <code>SOURCE_DATE_EPOCH</code>, you can propagate this using <code>--with-source-date=$SOURCE_DATE_EPOCH</code>.</p>
<ul>
<li>Specify a hotspot build time</li>
</ul>
<p>Set a fixed hotspot build time. This will be included in the hotspot library (<code>libjvm.so</code> or <code>jvm.dll</code>) and defaults to the current time when building hotspot. Use <code>--with-hotspot-build-time=<any fixed string></code> for reproducible builds. It's a string so you don't need to format it specifically, so e.g. <code>n/a</code> will do. Another solution is to use the <code>SOURCE_DATE_EPOCH</code> variable, e.g. <code>--with-hotspot-build-time=$(date --date=@$SOURCE_DATE_EPOCH)</code>.</p>
<ul>
<li>Copyright year</li>
</ul>
<p>The copyright year in some generated text files are normally set to the current year. This can be overridden by <code>--with-copyright-year=<year></code>. For fully reproducible builds, this needs to be set to a fixed value.</p>
<h2id="hints-and-suggestions-for-advanced-users">Hints and Suggestions for Advanced Users</h2>
<h3id="bash-completion">Bash Completion</h3>
<p>The <code>configure</code> and <code>make</code> commands tries to play nice with bash command-line completion (using <code><tab></code> or <code><tab><tab></code>). To use this functionality, make sure you enable completion in your <code>~/.bashrc</code> (see instructions for bash in your operating system).</p>
<h3id="counterexamples-and-updates">Counterexamples and Updates</h3>
<p>Many of the guidelines mentioned here have (sometimes widespread) counterexamples in the HotSpot code base. Finding a counterexample is not sufficient justification for new code to follow the counterexample as a precedent, since readers of your code will rightfully expect your code to follow the greater bulk of precedents documented here.</p>
<p>Occasionally a guideline mentioned here may be just out of synch with the actual HotSpot code base. If you find that a guideline is consistently contradicted by a large number of counterexamples, please bring it up for discussion and possible change. The architectural rule, of course, is "When in Rome do as the Romans". Sometimes in the suburbs of Rome the rules are a little different; these differences can be pointed out here.</p>
<p>Proposed changes should be discussed on the <ahref="mailto:hotspot-dev@openjdk.java.net">HotSpot Developers</a> mailing list. Changes are likely to be cautious and incremental, since HotSpot coders have been using these guidelines for years.</p>
<p>Substantive changes are approved by <ahref="https://www.rfc-editor.org/rfc/rfc7282.html">rough consensus</a> of the <ahref="https://openjdk.java.net/census#hotspot">HotSpot Group</a> Members. The Group Lead determines whether consensus has been reached.</p>
<p>Editorial changes (changes that only affect the description of HotSpot style, not its substance) do not require the full consensus gathering process. The normal HotSpot pull request process may be used for editorial changes, with the additional requirement that the requisite reviewers are also HotSpot Group Members.</p>
<p>Proposed changes should be discussed on the <ahref="mailto:hotspot-dev@openjdk.java.net">HotSpot Developers</a> mailing list, and approved by <ahref="https://en.wikipedia.org/wiki/Rough_consensus">rough consensus</a> of the <ahref="https://openjdk.java.net/census#hotspot">HotSpot Group</a> Members. The Group Lead determines whether consensus has been reached. Changes are likely to be cautious and incremental, since HotSpot coders have been using these guidelines for years.</p>
<h2id="structure-and-formatting">Structure and Formatting</h2>
<h3id="factoring-and-class-design">Factoring and Class Design</h3>
<ul>
@@ -154,7 +150,7 @@
<h3id="whitespace">Whitespace</h3>
<ul>
<li><p>In general, don't change whitespace unless it improves readability or consistency. Gratuitous whitespace changes will make integrations and backports more difficult.</p></li>
<li><p>Use <ahref="https://en.wikipedia.org/wiki/Indentation_style#Variant:_1TBS_(OTBS)">One-True-Brace-Style</a>. The opening brace for a function or class is normally at the end of the line; it is sometimes moved to the beginning of the next line for emphasis. Substatements are enclosed in braces, even if there is only a single statement. Extremely simple one-line statements may drop braces around a substatement.</p></li>
<li><p>Use One-True-Brace-Style. The opening brace for a function or class is normally at the end of the line; it is sometimes moved to the beginning of the next line for emphasis. Substatements are enclosed in braces, even if there is only a single statement. Extremely simple one-line statements may drop braces around a substatement.</p></li>
<li><p>Indentation levels are two columns.</p></li>
<li><p>There is no hard line length limit. That said, bear in mind that excessively long lines can cause difficulties. Some people like to have multiple side-by-side windows in their editors, and long lines may force them to choose among unpleasant options. They can use wide windows, reducing the number that can fit across the screen, and wasting a lot of screen real estate because most lines are not that long. Alternatively, they can have more windows across the screen, with long lines wrapping (or worse, requiring scrolling to see in their entirety), which is harder to read. Similar issues exist for side-by-side code reviews.</p></li>
<li><p>Tabs are not allowed in code. Set your editor accordingly.<br> (Emacs: <code>(setq-default indent-tabs-mode nil)</code>.)</p></li>
@@ -198,7 +194,7 @@ while ( test_foo(args...) ) { // No, excess spaces around control</code></pre></
<p>Similar discussions for some other projects:</p>
<ul>
<li><p><ahref="https://google.github.io/styleguide/cppguide.html">Google C++ Style Guide</a> — Currently (2020) targeting C++17.</p></li>
<li><p><ahref="https://chromium.googlesource.com/chromium/src/+/main/styleguide/c++/c++-features.md">C++11 and C++14 use in Chromium</a> — Categorizes features as allowed, banned, or to be discussed.</p></li>
<li><p><ahref="https://chromium-cpp.appspot.com">C++11 and C++14 use in Chromium</a> — Categorizes features as allowed, banned, or to be discussed.</p></li>
<li><p><ahref="https://llvm.org/docs/CodingStandards.html">llvm Coding Standards</a> — Currently (2020) targeting C++14.</p></li>
<li><p><ahref="https://firefox-source-docs.mozilla.org/code-quality/coding-style/using_cxx_in_firefox_code.html">Using C++ in Mozilla code</a> — C++17 support is required for recent versions (2020).</p></li>
</ul>
@@ -211,7 +207,7 @@ while ( test_foo(args...) ) { // No, excess spaces around control</code></pre></
<p>Rationale: Other than to implement exceptions (which HotSpot doesn't use), most potential uses of <ahref="https://en.wikipedia.org/wiki/Run-time_type_information"title="Runtime Type Information">RTTI</a> are better done via virtual functions. Some of the remainder can be replaced by bespoke mechanisms. The cost of the additional runtime data structures needed to support <ahref="https://en.wikipedia.org/wiki/Run-time_type_information"title="Runtime Type Information">RTTI</a> are deemed not worthwhile, given the alternatives.</p>
<h3id="memory-allocation">Memory Allocation</h3>
<p>Do not use the standard global allocation and deallocation functions (operator new and related functions). Use of these functions by HotSpot code is disabled for some platforms.</p>
<p>Rationale: HotSpot often uses "resource" or "arena" allocation. Even where heap allocation is used, the standard global functions are avoided in favor of wrappers around malloc and free that support the VM's Native Memory Tracking (NMT) feature. Typically, uses of the global operator new are inadvertent and therefore often associated with memory leaks.</p>
<p>Rationale: HotSpot often uses "resource" or "arena" allocation. Even where heap allocation is used, the standard global functions are avoided in favor of wrappers around malloc and free that support the VM's Native Memory Tracking (NMT) feature.</p>
<p>Native memory allocation failures are often treated as non-recoverable. The place where "out of memory" is (first) detected may be an innocent bystander, unrelated to the actual culprit.</p>
<h3id="class-inheritance">Class Inheritance</h3>
<p>Use public single inheritance.</p>
@@ -258,7 +254,8 @@ while ( test_foo(args...) ) { // No, excess spaces around control</code></pre></
<li><p>Function argument deduction. This is always permitted, and indeed encouraged. It is nearly always better to allow the type of a function template argument to be deduced rather than explicitly specified.</p></li>
<li><p><code>auto</code> variable declarations (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1984.pdf">n1984</a>)<br> For local variables, this can be used to make the code clearer by eliminating type information that is obvious or irrelevant. Excessive use can make code much harder to understand.</p></li>
<li><p>Function return type deduction (<ahref="https://isocpp.org/files/papers/N3638.html">n3638</a>)<br> Only use if the function body has a very small number of <code>return</code> statements, and generally relatively little other code.</p></li>
<li><p>Also see <ahref="#lambdaexpressions">lambda expressions</a>.</p></li>
<li><p>Generic lambdas. Lambdas are not (yet) permitted.</p></li>
<li><p>Lambda init captures. Lambdas are not (yet) permitted.</p></li>
</ul>
<h3id="expression-sfinae">Expression SFINAE</h3>
<p><ahref="https://en.cppreference.com/w/cpp/language/sfinae"title="Substitution Failure Is Not An Error">Substitution Failure Is Not An Error</a> (SFINAE) is a template metaprogramming technique that makes use of template parameter substitution failures to make compile-time decisions.</p>
@@ -271,8 +268,8 @@ while ( test_foo(args...) ) { // No, excess spaces around control</code></pre></
<p>The underlying type of a <em>scoped-enum</em> should also be specified explicitly if conversions may be applied to values of that type.</p>
<p>Due to bugs in certain (very old) compilers, there is widespread use of enums and avoidance of in-class initialization of static integral constant members. Compilers having such bugs are no longer supported. Except where an enum is semantically appropriate, new code should use integral constants.</p>
<h3id="thread_local">thread_local</h3>
<p>Avoid use of <code>thread_local</code> (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2659.htm">n2659</a>); and instead, use the HotSpot macro <code>THREAD_LOCAL</code>, for which the initializer must be a constant expression. When <code>thread_local</code> must be used, use the Hotspot macro <code>APPROVED_CPP_THREAD_LOCAL</code> to indicate that the use has been given appropriate consideration.</p>
<p>As was discussed in the review for <ahref="https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039487.html">JDK-8230877</a>, <code>thread_local</code> allows dynamic initialization and destruction semantics. However, that support requires a run-time penalty for references to non-function-local <code>thread_local</code> variables defined in a different translation unit, even if they don't need dynamic initialization. Dynamic initialization and destruction of non-local <code>thread_local</code> variables also has the same ordering problems as for ordinary non-local variables. So we avoid use of <code>thread_local</code> in general, limiting its use to only those cases where dynamic initialization or destruction are essential. See <ahref="https://bugs.openjdk.java.net/browse/JDK-8282469">JDK-8282469</a> for further discussion.</p>
<p>Do not use <code>thread_local</code> (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2659.htm">n2659</a>); instead, use the HotSpot macro <code>THREAD_LOCAL</code>. The initializer must be a constant expression.</p>
<p>As was discussed in the review for <ahref="https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-September/039487.html">JDK-8230877</a>, <code>thread_local</code> allows dynamic initialization and destruction semantics. However, that support requires a run-time penalty for references to non-function-local <code>thread_local</code> variables defined in a different translation unit, even if they don't need dynamic initialization. Dynamic initialization and destruction of namespace-scoped threadlocal variables also has the same ordering problems as for ordinary namespace-scoped variables.</p>
<h3id="nullptr">nullptr</h3>
<p>Prefer <code>nullptr</code> (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2431.pdf">n2431</a>) to <code>NULL</code>. Don't use (constexpr or literal) 0 for pointers.</p>
<p>For historical reasons there are widespread uses of both <code>NULL</code> and of integer 0 as a pointer value.</p>
@@ -291,125 +288,6 @@ while ( test_foo(args...) ) { // No, excess spaces around control</code></pre></
<p>Although related, the use of <code>std::initializer_list</code> remains forbidden, as part of the avoidance of the C++ Standard Library in HotSpot code.</p>
<h3id="local-function-objects">Local Function Objects</h3>
<ul>
<li>Local function objects, including lambda expressions, may be used.</li>
<li>Lambda expressions must only be used as a downward value.</li>
<li>Prefer <code>[&]</code> as the capture list of a lambda expression.</li>
<li>Return type deduction for lambda expressions is permitted, and indeed encouraged.</li>
<li>An empty parameter list for a lambda expression may be elided.</li>
<li>A lambda expression must not be <code>mutable</code>.</li>
<li>Generic lambda expressions are permitted.</li>
<li>Lambda expressions should be relatively simple.</li>
<li>Anonymous lambda expressions should not overly clutter the enclosing expression.</li>
<li>An anonymous lambda expression must not be directly invoked.</li>
<li>Bind expressions are forbidden.</li>
</ul>
<p>Single-use function objects can be defined locally within a function, directly at the point of use. This is an alternative to having a function or function object class defined at class or namespace scope.</p>
<p>This usage was somewhat limited by C++03, which does not permit such a class to be used as a template parameter. That restriction was removed by C++11 (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2657.htm">n2657</a>). Use of this feature is permitted.</p>
<p>Many HotSpot protocols involve "function-like" objects that involve some named member function rather than a call operator. For example, a function that performs some action on all threads might be written as</p>
<pre><code>void do_something() {
struct DoSomething : public ThreadClosure {
virtual void do_thread(Thread* t) {
... do something with t ...
}
} closure;
Threads::threads_do(&closure);
}</code></pre>
<p>HotSpot code has historically usually placed the DoSomething class at namespace (or sometimes class) scope. This separates the function's code from its use, often to the detriment of readability. It requires giving the class a globally unique name (if at namespace scope). It also loses the information that the class is intended for use in exactly one place, and does not have any subclasses. (However, the latter can now be indicated by declaring it <code>final</code>.) Often, for simplicity, a local class will skip things like access control and accessor functions, giving the enclosing function direct access to the implementation and eliminating some boilerplate that might be provided if the class is in some outer (more accessible) scope. On the other hand, if there is a lot of surrounding code in the function body or the local class is of significant size, defining it locally can increase clutter and reduce readability.</p>
<p><aname="lambdaexpressions"></a> C++11 added <em>lambda expressions</em> as a new way to write a function object. Simple lambda expressions can be significantly more concise than a function object, eliminating a lot of boiler-plate. On the other hand, a complex lambda expression may not provide much, if any, readability benefit compared to an ordinary function object. Also, while a lambda can encapsulate a call to a "function-like" object, it cannot be used in place of such.</p>
<p>A common use for local functions is as one-use <ahref="https://en.cppreference.com/w/cpp/language/raii"title="Resource Acquisition Is Initialization">RAII</a> objects. The amount of boilerplate for a function object class (local or not) makes such usage somewhat clumsy and verbose. But with the help of a small amount of supporting utility code, lambdas work particularly well for this use case.</p>
<p>Another use for local functions is <ahref="https://en.wikipedia.org/wiki/Partial_application"title="Partial Application">partial application</a>. Again here, lambdas are typically much simpler and less verbose than function object classes.</p>
<p>Because of these benefits, lambda expressions are permitted in HotSpot code, with some restrictions and usage guidance. An anonymous lambda is one which is passed directly as an argument. A named lambda is the value of a variable, which is its name.</p>
<p>Lambda expressions should only be passed downward. In particular, a lambda should not be returned from a function or stored in a global variable, whether directly or as the value of a member of some other object. Lambda capture is syntactically subtle (by design), and propagating a lambda in such ways can easily pass references to captured values to places where they are no longer valid. In particular, members of the enclosing <code>this</code> object are effectively captured by reference, even if the default capture is by-value. For such uses-cases a function object class should be used to make the desired value capturing and propagation explicit.</p>
<p>Limiting the capture list to <code>[&]</code> (implicitly capture by reference) is a simplifying restriction that still provides good support for HotSpot usage, while reducing the cases a reader must recognize and understand.</p>
<ul>
<li><p>Many common lambda uses require reference capture. Not permitting it would substantially reduce the utility of lambdas.</p></li>
<li><p>Referential transparency. Implicit reference capture makes variable references in the lambda body have the same meaning they would have in the enclosing code. There isn't a semantic barrier across which the meaning of a variable changes.</p></li>
<li><p>Explicit reference capture introduces significant clutter, especially when lambda expressions are relatively small and simple, as they should be in HotSpot code.</p></li>
<li><p>There are a number of reasons why by-value capture might be used, but for the most part they don't apply to HotSpot code, given other usage restrictions.</p>
<ul>
<li><p>A primary use-case for by-value capture is to support escaping uses, where values captured by-reference might become invalid. That use-case doesn't apply if only downward lambdas are used.</p></li>
<li><p>By-value capture can also make a lambda-local copy for mutation, which requires making the lambda <code>mutable</code>; see below.</p></li>
<li><p>By-value capture might be viewed as an optimization, avoiding any overhead for reference capture of cheap to copy values. But the compiler can often eliminate any such overhead.</p></li>
<li><p>By-value capture by a non-<code>mutable</code> lambda makes the captured values const, preventing any modification by the lambda and making the captured value unaffected by modifications to the outer variable. But this only applies to captured auto variables, not member variables, and is inconsistent with referential transparency.</p></li>
</ul></li>
<li><p>Non-capturing lambdas (with an empty capture list - <code>[]</code>) have limited utility. There are cases where no captures are required (pure functions, for example), but if the function is small and simple then that's obvious anyway.</p></li>
<li><p>Capture initializers (a C++14 feature - <ahref="https://isocpp.org/files/papers/N3649.html">N3649</a>) are not permitted. Capture initializers inherently increase the complexity of the capture list, and provide little benefit over an additional in-scope local variable.</p></li>
</ul>
<p>The use of <code>mutable</code> lambda expressions is forbidden because there don't seem to be many, if any, good use-cases for them in HotSpot. A lambda expression needs to be mutable in order to modify a by-value captured value. But with only downward lambdas, such usage seems likely to be rare and complicated. It is better to use a function object class in any such cases that arise, rather than requiring all HotSpot developers to understand this relatively obscure feature.</p>
<p>While it is possible to directly invoke an anonymous lambda expression, that feature should not be used, as such a form can be confusing to readers. Instead, name the lambda and call it by name.</p>
<p>Some reasons to prefer a named lambda instead of an anonymous lambda are</p>
<ul>
<li><p>The body contains non-trivial control flow or declarations or other nested constructs.</p></li>
<li><p>Its role in an argument list is hard to guess without examining the function declaration. Give it a name that indicates its purpose.</p></li>
<li><p>It has an unusual capture list.</p></li>
<li><p>It has a complex explicit return type or parameter types.</p></li>
</ul>
<p>Lambda expressions, and particularly anonymous lambda expressions, should be simple and compact. One-liners are good. Anonymous lambdas should usually be limited to a couple lines of body code. More complex lambdas should be named. A named lambda should not clutter the enclosing function and make it long and complex; do continue to break up large functions via the use of separate helper functions.</p>
<p>An anonymous lambda expression should either be a one-liner in a one-line expression, or isolated in its own set of lines. Don't place part of a lambda expression on the same line as other arguments to a function. The body of a multi-line lambda argument should be indented from the start of the capture list, as if that were the start of an ordinary function definition. The body of a multi-line named lambda should be indented one step from the variable's indentation.</p>
<p>Item 4, and especially items 6 and 7, are pushing the simplicity limits for anonymous lambdas. Item 6 might be better written using a named lambda:</p>
<pre><code>c.do_entries(do_entry);</code></pre>
<p>Note that C++11 also added <em>bind expressions</em> as a way to write a function object for partial application, using <code>std::bind</code> and related facilities from the Standard Library. <code>std::bind</code> generalizes and replaces some of the binders from C++03. Bind expressions are not permitted in HotSpot code. They don't provide enough benefit over lambdas or local function classes in the cases where bind expressions are applicable to warrant the introduction of yet another mechanism in this space into HotSpot code.</p>
<p>References:</p>
<ul>
<li>Local and unnamed types as template parameters (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2657.htm">n2657</a>)</li>
<li>New wording for C++0x lambdas (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2927.pdf">n2927</a>)</li>
<p>Do not use <em>inheriting constructors</em> (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2540.htm">n2540</a>).</p>
<p>C++11 provides simple syntax allowing a class to inherit the constructors of a base class. Unfortunately there are a number of problems with the original specification, and C++17 contains significant revisions (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0136r1.html"title="p0136r1">p0136r1</a> opens with a list of 8 Core Issues). Since HotSpot doesn't support use of C++17, use of inherited constructors could run into those problems. Such uses might also change behavior in a future HotSpot update to use C++17 or later, potentially in subtle ways that could lead to hard to diagnose problems. Because of this, HotSpot code must not use inherited constructors.</p>
<p>Note that gcc7 provides the <code>-fnew-inheriting-ctors</code> option to use the <ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0136r1.html"title="p0136r1">p0136r1</a> semantics. This is enabled by default when using C++17 or later. It is also enabled by default for <code>fabi-version=11</code> (introduced by gcc7) or higher when using C++11/14, as the change is considered a Defect Report that applies to those versions. Earlier versions of gcc don't have that option, and other supported compilers may not have anything similar.</p>
@@ -427,8 +305,8 @@ while ( test_foo(args...) ) { // No, excess spaces around control</code></pre></
<li><p>Dynamic initialization and destruction with concurrency (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm">n2660</a>)</p></li>
<li><p><code>final</code> virtual specifiers for classes and virtual functions (<ahref="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2928.htm">n2928</a>), (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm">n3206</a>), (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3272.htm">n3272</a>)</p></li>
<li><p><code>override</code> virtual specifiers for virtual functions (<ahref="http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2928.htm">n2928</a>), (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm">n3206</a>), (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3272.htm">n3272</a>)</p></li>
<li><p>Local and unnamed types as template parameters (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2657.htm">n2657</a>)</p></li>
@@ -444,7 +322,7 @@ while ( test_foo(args...) ) { // No, excess spaces around control</code></pre></
<li><p>Inline namespaces (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2535.htm">n2535</a>) — HotSpot makes very limited use of namespaces.</p></li>
<li><p><code>using namespace</code> directives. In particular, don't use <code>using namespace std;</code> to avoid needing to qualify Standard Library names.</p></li>
<li><p>Propagating exceptions (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2179.html">n2179</a>) — HotSpot does not permit the use of exceptions, so this feature isn't useful.</p></li>
<li><p>Avoid non-local variables with non-constexpr initialization. In particular, avoid variables with types requiring non-trivial initialization or destruction. Initialization order problems can be difficult to deal with and lead to surprises, as can destruction ordering. HotSpot doesn't generally try to cleanup on exit, and running destructors at exit can also lead to problems.</p></li>
<li><p>Avoid namespace-scoped variables with non-constexpr initialization. In particular, avoid variables with types requiring non-trivial initialization or destruction. Initialization order problems can be difficult to deal with and lead to surprises, as can destruction ordering. HotSpot doesn't generally try to cleanup on exit, and running destructors at exit can also lead to problems.</p></li>
<li><p><code>[[deprecated]]</code> attribute (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3760.html">n3760</a>) — Not relevant in HotSpot code.</p></li>
<li><p>Avoid most operator overloading, preferring named functions. When operator overloading is used, ensure the semantics conform to the normal expected behavior of the operation.</p></li>
<li><p>Avoid most implicit conversion constructors and (implicit or explicit) conversion operators. (Note that conversion to <code>bool</code> isn't needed in HotSpot code because of the "no implicit boolean" guideline.)</p></li>
@@ -459,6 +337,7 @@ while ( test_foo(args...) ) { // No, excess spaces around control</code></pre></
<li><p>Member initializers and aggregates (<ahref="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3653.html">n3653</a>)</p></li>
<p>This creates a file named <code>jvm.vcxproj</code> in <code>ide\hotspot-visualstudio</code> subfolder of the build output folder. The file can be opened in Visual Studio via <code>File -> Open -> Project/Solution</code>.</p>
<p>The make system can generate generic native code indexing support in the form of a <ahref="https://clang.llvm.org/docs/JSONCompilationDatabase.html">Compilation Database</a> that can be used by many different IDEs and source code indexers.</p>
<p>It's also possible to generate the Compilation Database for the HotSpot source code only, which is a bit faster as it includes less information.</p>
<h3id="ide-support-for-java-code">IDE support for Java code</h3>
<h4id="intellij-idea">IntelliJ IDEA</h4>
<p>The JDK project has a script that can be used for indexing the project with IntelliJ. After configuring and building the JDK, an IntelliJ workspace can be generated by running the following command in the top-level folder of the cloned repository:</p>
<p>To use it, choose <code>File -> Open...</code> in IntelliJ and select the folder where you ran the above script.</p>
<p>Next, configure the project SDK in IntelliJ. Open <code>File -> Project Structure -> Project</code> and select <code>build/<config>/images/jdk</code> as the SDK to use.</p>
<p>In order to run the tests from the IDE, you can use the JTReg plugin. Instructions for building and using the plugin can be found <ahref="https://github.com/openjdk/jtreg/tree/master/plugins/idea">here</a>.</p>
<p>If your locale is non-US, some tests are likely to fail. To work around this you can set the locale to US. On Unix platforms simply setting <code>LANG="en_US"</code> in the environment before running tests should work. On Windows or MacOS, setting <code>JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"</code> helps for most, but not all test cases.</p>
<p>If your locale is non-US, some tests are likely to fail. To work around this you can set the locale to US. On Unix platforms simply setting <code>LANG="en_US"</code> in the environment before running tests should work. On Windows, setting <code>JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US"</code> helps for most, but not all test cases.</p>
<p>For example:</p>
<pre><code>$ export LANG="en_US"&& make test TEST=...
$ make test JTREG="VM_OPTIONS=-Duser.language=en -Duser.country=US" TEST=...</code></pre>
<optionname="notice"value="Copyright &#36;originalComment.match("Copyright (\d+)", 1, "-")&#36;today.year JetBrains s.r.o. DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. This code is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License version 2 only, as published by the Free Software Foundation. This code is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License version 2 for more details (a copy is included in the LICENSE file that accompanied this code). You should have received a copy of the GNU General Public License version 2 along with this work; if not, write to the Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA or visit www.oracle.com if you need additional information or have any questions."/>
<optionname="notice"value="Copyright 2000-&#36;today.year JetBrains s.r.o. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License."/>
AC_MSG_ERROR([No sysroot found for SDK $SDK_NAME from xcodebuild. Check your Xcode installation.])
fi
if ! test -f "$SYSROOT/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h"; then
AC_MSG_ERROR([Unable to find required framework headers, provide a path to an SDK via --with-sysroot or --with-sdk-name and be sure Xcode is installed properly])
fi
AC_MSG_NOTICE([Setting sysroot from xcodebuild with SDK $SDK_NAME])
if test $HAVE_SYSTEM_FRAMEWORK_HEADERS -eq 0; then
AC_MSG_ERROR([No xcodebuild tool and no system framework headers found, use --with-sysroot or --with-sdk-name to provide a path to a valid SDK])
fi
fi
else
# warn user if --with-sdk-name was also set
if test -n "$with_sdk_name"; then
AC_MSG_WARN([Both SYSROOT and --with-sdk-name are set, only SYSROOT will be used])
fi
fi
if test $HAVE_SYSTEM_FRAMEWORK_HEADERS -eq 0 -a -z "$SYSROOT"; then
# If no system framework headers, then SYSROOT must be set, or we won't build
AC_MSG_ERROR([Unable to determine SYSROOT and no headers found in /System/Library/Frameworks. Check Xcode configuration, --with-sysroot or --with-sdk-name arguments.])
fi
# Perform a basic sanity test
if test ! -f "$SYSROOT/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h"; then
if test -z "$SYSROOT"; then
AC_MSG_ERROR([Unable to find required framework headers, provide a path to an SDK via --with-sysroot or --with-sdk-name and be sure Xcode is installed properly])
else
AC_MSG_ERROR([Invalid SDK or SYSROOT path, dependent framework headers not found])
if test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.cygwin"; then
# The choice of file here is somewhat arbitrary, it just needs to be there
# in the source tree when configure runs
file_to_test="$TOPDIR/Makefile"
file_to_test="$TOPDIR/LICENSE"
if test `$STAT -c '%a' "$file_to_test"` -lt 400; then
AC_MSG_ERROR([Bad file permissions on src files. This is usually caused by cloning the repositories with a non cygwin hg in a directory not created in cygwin.])
--openjdk-target=TARGET cross-compile with TARGET as target platform
(i.e. the one you will run the resulting binary on).
Equivalent to --host=TARGET --target=TARGET
--build=<current platform>, or the platform you
have provided if you have explicitly passed
--build to configure
--build=<current platform>
--debug-configure Run the configure script with additional debug
logging enabled.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
