RFR(L): 8180032: Unaligned pointer dereference in ClassFileParser (original) (raw)
Robbin Ehn robbin.ehn at oracle.com
Thu May 18 09:59:42 UTC 2017
- Previous message: RFR(L): 8180032: Unaligned pointer dereference in ClassFileParser
- Next message: RFR(L): 8180032: Unaligned pointer dereference in ClassFileParser
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi,
On 05/17/2017 03:46 AM, Kim Barrett wrote:
On May 9, 2017, at 6:40 PM, Mikael Vidstedt <mikael.vidstedt at oracle.com> wrote:
Warning: It may be wise to stock up on coffee or tea before reading this. Bug: https://bugs.openjdk.java.net/browse/JDK-8180032 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8180032/webrev.00/hotspot/webrev/ <http://cr.openjdk.java.net/~mikael/webrevs/8180032/webrev.00/hotspot/webrev/> Not a review, just a question. ------------------------------------------------------------------------------ src/cpu/x86/vm/bytesx86.hpp 40 template 41 static inline T getnative(const void* p) { 42 assert(p != NULL, "null pointer"); 43 44 T x; 45 46 if (isptraligned(p, sizeof(T))) { 47 x = (T)p; 48 } else { 49 memcpy(&x, p, sizeof(T)); 50 } 51 52 return x; I'm looking at this and wondering if there's a good reason to not just unconditionally use memcpy here. gcc -O will generate a single move instruction for that on x8664. I'm not sure what happens on 32bit with an 8 byte value, but I suspect it will do something similarly sensible, e.g. 2 4 byte memory to memory transfers.
Unconditionally memcpy would be nice!
Are going to look into that Mikael?
/Robbin
------------------------------------------------------------------------------
- Previous message: RFR(L): 8180032: Unaligned pointer dereference in ClassFileParser
- Next message: RFR(L): 8180032: Unaligned pointer dereference in ClassFileParser
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]