RFR (S): Issue constants to constant pool in stub code
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Tue Nov 20 04:05:21 PST 2012
Hi Vladimir,
That's the original comment, it only moved down. I understand
it as hint for the user of this method. It's not necessary for the
new method, as one could reset the cs to NULL.
All callers of end_a_const() currently check the result of the
previous start_a_const() call, so there no assertion is needed.
Best regards,
Goetz
-----Original Message-----
From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com]
Sent: Dienstag, 20. November 2012 13:20
To: Lindenmaier, Goetz
Cc: hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR (S): Issue constants to constant pool in stub code
Goetz,
+// Inform CodeBuffer that incoming code and relocation will be code
+// Should not be called if start_a_const() returned NULL
+void AbstractAssembler::end_a_const() {
+ end_a_const(code()->insts());
+}
Don't you want to add an assert to check that start_a_const() != NULL?
Best regards,
Vladimir Ivanov
On 11/20/12 1:05 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> When adding constants to the constant pool, the code_section is switched
>
> to the constant pool code_section, and then back again. It was hard coded
>
> to switch back to the code_section for code.
>
> If constants are issued in stubs, it is switched back to the wrong code
> section.
>
> I changed the code to remember the code section and switch back to the
> proper
>
> one.
>
> Further it's necessary to relocate only after copying code and stub
> section to
>
> a new location, as the relocation might affect an address in the stub
> section.
>
> You can find these changes here:
>
> http://cr.openjdk.java.net/~goetz/webrevs/webrev-const_in_stub/
>
> or in our ppc port:
>
> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/b288e82d9062
>
> Thank you and best regards,
>
> Goetz
>
More information about the hotspot-compiler-dev
mailing list