JDK-7002666 : eclipse CDT projects crash with compressed oops
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs19
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2010-11-24
  • Updated: 2011-03-08
  • Resolved: 2011-03-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 Other
6u25Fixed 7Fixed OpenJDK6,hs20Fixed
Description
On Nov 24, 2010, at 12:24 PM, Dr Andrew John Hughes wrote:

I reported this on jdk6-dev
(http://mail.openjdk.java.net/pipermail/jdk6-dev/2010-November/002095.html)
but thought it best to also report it here as there's been no
response.

The hs19 stable branch crashes with Eclipse's CDT plugin:

https://bugzilla.redhat.com/show_bug.cgi?id=647737

and the same occurs with the current OpenJDK7 HotSpot tree.
(http://hg.openjdk.java.net/jdk7/hotspot/hotspot)

Disabling compressed oops by default (as was done for hs17 stable)
will work around the problem, and this is what we presently do in
IcedTea6.

Is compressed oops ready for prime time in hs19 or is turning it off
the right path to go down?  Has anyone else seen this issue or know of
anything that might fix it?


To reproduce, from the bugzilla report:

Steps to Reproduce:
1. Run Eclipse (with CDT installed) (you can use either F14's eclipse or an
eclipse cdt downloaded from eclipse.org. the bug happens in both).
2. Create a C++ project
3. Add a main.cpp
4. add one line "#include <iostream>"
5. Save the file
6. If eclipse didn't crash right after saving, right click on the project and
select Indexer->Rebuild Index
Comments
EVALUATION http://hg.openjdk.java.net/jdk7/build/hotspot/rev/4da76e32c0be
25-12-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4da76e32c0be
16-12-2010
EVALUATION 7002666: eclipse CDT projects crash with compressed oops Reviewed-by: kvn, twisti When emitting the code to zero a newly allocated object C2 attempts to identify space that's already been initialized or extra space that isn't actually part of an instance. The logic for this should only be executed for instances and never for arrays but the logic doesn't explicitly test for arrays. It's normally protected in the array case because the klass is precise and the value of layout_helper will never match zeroes_done since it's always negative for arrays. In this case the newArray is producing something that's typed as Object so the klass input of the allocation says Object and it mistakenly assumes the rest of the array doesn't need zeroing. The fix is to only execute this logic for AllocateNodes. Tested with eclipse and with new test case.
02-12-2010
EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/4da76e32c0be
01-12-2010
EVALUATION This isn't a compressed oops bug per se but an existing bug that could only trigger under the object layout that results from compressed oops. There's some logic that seeks to avoid initializing unused space at the end of instances but the tests it uses can trigger with arrays under compressed oops because we're able to shove the length into the header for arrays. The fix is not to execute the logic for array allocations.
30-11-2010
WORK AROUND -XX:-UseCompressedOops
24-11-2010