On 2011-04-21 02:15, Dr Andrew John Hughes wrote:
On 02:07 Thu 21 Apr     , Xerxes Rånby wrote:
On 2011-04-21 00:39, Dr Andrew John Hughes wrote:
On 16:00 Wed 20 Apr     , Xerxes Rånby wrote:
Hi

hs20 uses two new internal instructions fast_aldc and fast_aldc_w.
see: openjdk/hotspot/src/share/vm/interpreter/bytecodes.hpp

This webrev fix by backporting Zero fixes from OpenJDK bug 7032458 and 7030207.
http://labb.zafena.se/openjdk/pr696-zero-fast_aldc-and-fast_aldc_w-regression-hs20/

The webrev are made against hsx20
http://hg.openjdk.java.net/hsx/hsx20/master/

I don't have a bug id for this.

Why are you merging together two different changesets?

Because they both contain parts that are needed to properly fix this
Zero regression on hs20 and prevent it from happening again.

One part that fixes the regression by making the instruction table in
sync again from 7032458, and another part from 7030207 that reveals the
error if the table gets out of sync again.

If I quote Gary:
"It two new internal instructions, _fast_aldc and _fast_aldc_w, but
it added them *before* _return_register_finalizer, which broke the
instructions table in bytecodeInterpreter.cpp.  It meant that when
the C++ interpreter saw _return_register_finalizer it would execute
opc_default, which should have thrown an error but for the piece of
the ARM interpreter which hid the error by rewriting the instruction
to a plain _return.  I didn't see it before because I was doing
debug builds, and the C++ interpreter only uses the instructions
table for product builds."
http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-March/005074.html


Are there bits of each changeset being left out?  It's just it's easier
to track if there is a 1-to-1 correspondence.

Large parts of 7032458 are left out that are unrelated to this Zero regression in hs20 (some Shark fixes and non hs20 fixes). The changeset from 7030207 are intact and can be backported by 1-to-1 correspondence if preferable.

Personally I would prefer to see this Zero hs20 regression to be tracked as a unit in a Bug ID of its own.


Cheers
Xerxes


Reply via email to