Skip to content

Instantly share code, notes, and snippets.

@rose00
rose00 / gist:1440966
Created December 7, 2011 01:22
Re: Review request for java.text.** warning cleanup
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
rose00 / RawTypeArrayFix.java
Created December 2, 2011 22:05
demonstration of removing generic array warnings
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
rose00 / APICheck.java
Created December 2, 2011 20:48
demonstration of API incompatibility between wildcards vs. named type parameters
/*
* 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
rose00 / gist:1323809
Created October 28, 2011 23:06
failed libsaproc handoff in JDK build on mac
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
rose00 / gist:872165
Created March 16, 2011 07:49
resource_allocate_bytes SEGV (-d64 -XX:-UseCompressedOops)
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
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));
--------
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:
# 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).