Request for approval: Backport of 6781583 to hs14/OpenJDK6
Andrew John Hughes
gnu_andrew at member.fsf.org
Mon Jun 8 14:40:24 PDT 2009
2009/6/8 Kelly O'Hair <Kelly.Ohair at sun.com>:
> Someone from the hotspot team really needs to review this
Errr.... 4 of them already did:
http://hg.openjdk.java.net/jdk7/jdk7/hotspot/rev/2328d1d3f8cf
I'm not the author of this patch, I just backported it from OpenJDK7
where it's been applied for over six months. I don't remember this
patch being reviewed openly and I disliked having all the fixes rolled
into one megafix like this.
But given this had been reviewed and was in 7, it seemed better to
backport this (just a matter of hg export/import) rather than trying
to get each individual IcedTea patch through, especially as one of
ours just turns off -Werror... (to some degree anyway)
The relevant IcedTea patches are icedtea-fortify-source.patch (author:
Matthias Klose), hotspot/default/icedtea-format.patch (author: me),
icedtea-no-bcopy.patch (author: Matthias Klose),
hotspot/default/icedtea-gcc-4.3.patch (originally part of a patch by
Bernhard Rosenkraenzer according to the ChangeLog).
, but my
> observations on these changes:
>
> * Changing the typedef for jlong seemed really risky to me, but I
> investigated it more and I'm pretty sure this is the right change,
> and forces it to match the public definition from jni.h/jni_md.h.
> So it looks right.
>
It's kind of annoying it has to be defined repeatedly for each arch.
We also had to add this to Zero in IcedTea.
> * The realpath() changes in src/os/linux/vm/os_linux.cpp seem to change
> the definition of this method when an error occurs, the control
> flow has changed, and I'm not exactly sure what the return value is
> when realpath() fails. I doubt realpath() fails very often here,
> but won't the buf[] array get some arbitrary directory when realpath()
> fails? Is that ok? That jvm_path() is a bizarre little method. :^{
>
In IcedTea, an unused variable is used which isn't ideal either, but
at least doesn't change the semantics.
> * Changing the _lineno field in src/share/vm/utilities/vmError.hpp
> from an int to a size_t might seem right type wise, but sure seems
> like a waste of space. Does a lineno really need to use up 64bits of
> space?
This doesn't seem to be patched in IcedTea, so I don't know the
reasoning for the change. Increasing the size to 64 bits on x86_64
does seem wrong though.
>
> * The *PTR* changes look right.
>
Yeah, our patches are virtually identical on this :)
> * The addition of an unused local variable like in
> src/share/vm/utilities/ostream.cpp
> to avoid a warning message just seems wrong to me, and will likely
> create a new warning message about an unused local variable.
> Seems like I've had this discussion before.
> I prefer an explicit (void) cast on a function call whose return
> value is not needed and I am frustrated with GCC's inability to
> understand what that (void) cast means.
> I really like the idea of using -Werror and not allowing warnings,
> but at times like this I have to wonder if we should just remove
> the -Werror unless we know that specific version of GCC is < 4.3.
>
IcedTea does the same for this and the one above, but uses
__attribute__(unused) to avoid the warning.
> But like I said, a 'real' hotspot developer should probably review this. ;^)
>
> -kto
>
>
> Andrew John Hughes wrote:
>>
>> The following webrev:
>>
>> http://fuseyism.com/6781583/webrev.00/
>>
>> is backported from OpenJDK7. It allows hs14 to be built using GCC 4.3
>> and above. Otherwise, the build fails. IcedTea has been applying an
>> equivalent fix as three separately developed patches, two of which
>> have been there pretty much since its inception in the summer of 2007.
>>
>> Ok to commit?
>
--
Andrew :-)
Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)
Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net
PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8
More information about the jdk6-dev
mailing list