Native call framework prototype issues

[Vladimir Ivanov]

Thanks for trying it out, Sunny!

As you can see, VM support is *very* raw.
I was focused primarily on JDK part and didn't pay much attention to it 
except to get a trivial case (getpid()) working on my setup.

Some of these issues are known and I plan to address them once I get a 
clean JPRT build. So far, non-x86 platforms miss stub generation logic 
completely and it causes crashes in completely unrelated situations.

Thanks again for the report! I'll keep you posted about the progress.

Best regards,
Vladimir Ivanov

On 4/23/15 1:03 PM, Chan, Sunny wrote:
> Hello,
>
> I am trying to compile and run the Native call framework prototype that has been uploaded by Vladimir in February [1] but I seems to hit a few issues when I try this on Linux x86_64:
>
>
> 1)      In RTLD_DEFAULT in Linux is 0 not -2 [2]  - -2 crashes on Linux and replacing it with 0 (grep from linux header) fixed this
>
> 2)      When the JIT generate the native method wrapper, it causes this assertion:
>
>
> #  Internal Error (/local/scratch/chasun/panama/hotspot/src/cpu/x86/vm/register_x86.hpp:64), pid=23604, tid=140592728340224
>
> #  assert(is_valid()) failed: invalid register
>
>
>
> The stack trace looks like this:
>
>
>
> V  [libjvm.so+0x421f5b]  Assembler::testq(RegisterImpl*, RegisterImpl*)+0x3b
>
> V  [libjvm.so+0xd9434e]  MethodHandles::verify_klass(MacroAssembler*, RegisterImpl*, SystemDictionary::WKID, char const*)+0xce
>
> V  [libjvm.so+0xd94ae1]  MethodHandles::generate_native_call(MacroAssembler*, RegisterImpl*, bool)+0x111
>
> V  [libjvm.so+0xf8e9e2]  SharedRuntime::generate_native_wrapper(MacroAssembler*, methodHandle, int, BasicType*, VMRegPair*, BasicType)+0x5482
>
> V  [libjvm.so+0xf6fb3d]  AdapterHandlerLibrary::create_native_wrapper(methodHandle)+0x77d
>
> V  [libjvm.so+0x102641c]  SystemDictionary::find_method_handle_intrinsic(vmIntrinsics::ID, Symbol*, Thread*)+0x63c
>
> V  [libjvm.so+0xc5907e]  LinkResolver::lookup_polymorphic_method(methodHandle&, KlassHandle, Symbol*, Symbol*, KlassHandle, Handle*, Handle*, Thread*)+0x5de
>
> V  [libjvm.so+0xc59ef3]  LinkResolver::resolve_method(methodHandle&, KlassHandle, Symbol*, Symbol*, KlassHandle, bool, bool, Thread*)+0x5a3
>
> V  [libjvm.so+0xc5d5fa]  LinkResolver::linktime_resolve_static_method(methodHandle&, KlassHandle, Symbol*, Symbol*, KlassHandle, bool, Thread*)+0x8a
>
> V  [libjvm.so+0xc5dab0]  LinkResolver::resolve_static_call(CallInfo&, KlassHandle&, Symbol*, Symbol*, KlassHandle, bool, bool, Thread*)+0xa0
>
> V  [libjvm.so+0xd8d23b]  MethodHandles::resolve_MemberName(Handle, KlassHandle, Thread*)+0xecb
>
> V  [libjvm.so+0xd92620]  MHN_resolve_Mem+0x310
>
>
>                  It looks like in generate_native_call, the member_reg is set to "no_reg" and when it try to verify_klass it seems to reference to the no_reg value and hence invalid register in the testq() assembler
>
>                  Is that a known issue or caused by recent change in hotspot?
>
> [1] http://mail.openjdk.java.net/pipermail/panama-dev/2015-February/000095.html
> [2] http://hg.openjdk.java.net/panama/panama/hotspot/file/298f5197762b/src/share/vm/prims/unsafe.cpp#l776
>
>
> Sunny Chan, Executive Director, Technology
> Goldman Sachs (Asia) L.L.C. | 68th Floor | Cheung Kong Center | 2 Queens Road Central | Hong Kong
> email:  sunny.chan at gs.com | Tel: +852 2978 6481 | Fax: +852 2978 0633
>
> This message may contain information that is confidential or privileged.  If you are not the intended recipient, please advise the sender immediately and delete this message.  See http://www.gs.com/disclaimer/email for further information on confidentiality and the risks inherent in electronic communication.
>