rose00

The @IntrinsicCandidate indicates that an annotated method is recognized by vmIntrinsics.hpp and may be subject to intrinsification by the HotSpot VM (see LibraryCallKit::try_to_inline in library_call.cpp) if an intrinsic is available. Intrinsification replaces a candidate method's body, bytecode or native, with handwritten platform assembly and/or compiler IR. Many Java library methods have properties that cannot be deduced by the compiler for optimization, or can utilize specific hardware instructions not modeled by the compiler IR, making intrinsics necessary.

rose00

Cleanup coding guidelines:
  http://mail.openjdk.java.net/pipermail/jdk8-dev/2011-December/000380.html

Base revision to this patch:
  http://cr.openjdk.java.net/~dbhole/java.text-warning-cleanup/webrev.02/

diff --git a/src/share/classes/java/text/AttributedString.java b/src/share/classes/java/text/AttributedString.java
--- a/src/share/classes/java/text/AttributedString.java
+++ b/src/share/classes/java/text/AttributedString.java
@@ -160,18 +160,9 @@

rose00

import java.util.List;

/*
 * Test program to show how to remove warnings from generic array construction.
 * First step:  Remove any raw types, by adding <?> as needed.
 * Second step:  Add a cast if needed, to the specific non-wildcard type.
 * Third step:  Suppress "unchecked" warnings on the cast.
 * The point of the first step is to remove the "rawtypes" warning
 * cleanly, without resorting to an additional warning suppression.
 * Note that every use of @SuppressWarnings should have a comment.

rose00

/*
 * Test program to show that replacing wildcards by named type parameters,
 * or vice versa, is not a safe change to a public API.
 * If such a change were compatible, then the overrides below would succeed (sans "QQ").
 *
 * In fact, JLS 8.4.2 (Method Signature) defines override equivalence as
 * allowing renaming of type parameters, but not substituting type parameters
 * for wildcards.  Thus, the two kinds of type quantification are not equivalent.
 * Think of it this way:  A type parameter can be freely renamed, but only if it
 * already has a name.

rose00

JDK build from http://hg.openjdk.java.net/hsx/hotspot-main can fail.  There is a mismatched pathname, when the makefiles attempt to hand off the libsaproc built by hotspot into the import directory required by the JDK makefiles.

Here's the ending part of a failed JDK build:

/bin/cp ../../../src/solaris/bin/i586/jvm.cfg /Users/jrose/Projects/davinci/sources/build/bsd-i586/lib/i386/jvm.cfg
Begin Processing SUBDIRS:  fonts    sajdi
make[5]: Nothing to be done for `all'.
ASSEMBLY_IMPORT: /Users/jrose/Projects/davinci/sources/build/bsd-i586/lib/sa-jdi.jar
/bin/mkdir -p /Users/jrose/Projects/davinci/sources/build/bsd-i586/lib
rm -f /Users/jrose/Projects/davinci/sources/build/bsd-i586/lib/sa-jdi.jar

rose00

Introduction first; transcript and data dump is below.

The JVM_ArrayCopy bug appears in amd64 with UseCompressedOops turned on (the default).  The problem appears to be a trashed _klass field in the array for a source string (which happens to be "main", suggesting an early demise).

If you add -XX:-UseCompressedOops, you get a SEGV error outside of JVM_ArrayCopy and in resource_allocate_bytes instead.  In fact, I get the same error in resource_allocate_bytes in both 32-bit and 64-bit builds.  This routine is a low-level allocator which picks up Thread::current() and allocates bytes from a buffer on the current thread.  (The bytes are scoped inside the dynamic extent of a ResourceMark, and are usually treated as thread-local.)

In 32 bits (x86 not amd64), the immediate cause of the resource_allocate_bytes failure is unexpected NULL contents in the _sp_map array (used in threadLS_bsd_x86.cpp).  If I put a print statement in pd_set_thread I see that one or two threads declare themselves in an orderly way.  If I

rose00

diff --git a/src/share/vm/c1/c1_GraphBuilder.cpp b/src/share/vm/c1/c1_GraphBuilder.cpp
--- a/src/share/vm/c1/c1_GraphBuilder.cpp
+++ b/src/share/vm/c1/c1_GraphBuilder.cpp
@@ -1442,7 +1442,7 @@
         switch (field_type) {
         case T_ARRAY:
         case T_OBJECT:
-          if (field_val.as_object()->has_encoding()) {
+          if (field_val.as_object()->should_be_constant()) {
             constant =  new Constant(as_ValueType(field_val));

rose00

--------
	gamma -XX:+PrintAssembly -Xbatch -XX:+PrintCompilation -XX:+EnableMethodHandles -cp $BUGDIR ThrowBug
VM option '+PrintAssembly'
VM option '+PrintCompilation'
VM option '+EnableMethodHandles'
OpenJDK Server VM warning: JSR 292 invokedynamic is disabled in this JVM.  Use -XX:+EnableInvokeDynamic to enable.
  1  !b   ThrowBug::catcher (18 bytes)
Loaded disassembler from hsdis-i386.dylib
Decoding compiled method 0x090d44c8:
Code:

rose00

# source build.sh

# This script is originally derived from Stephen Bannasch's instructions:
#  http://confluence.concord.org/display/CCTR/Build+OpenJDK+Java+1.7.0+on+Mac+OS+X+10.5

# This script is placed in ../davinci/sources/ and run from there.  See also:
#  http://mail.openjdk.java.net/pipermail/mlvm-dev/2009-April/000434.html

# Works on JDK7 M3 (b59).