RFR(S): 8039805: Fix the signature of the global new/delete operators in allocation.cpp

Wed Apr 30 18:28:13 UTC 2014

On Wed, Apr 30, 2014 at 7:30 PM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
> Hi Volker,
>
> Thanks for your thoughts!
>
> On Wed, 2014-04-30 at 18:44 +0200, Volker Simonis wrote:
>> On Wed, Apr 30, 2014 at 3:33 PM, Severin Gehwolf <sgehwolf at redhat.com> wrote:
>> > Hi Volker,
>> >
>> > On Wed, 2014-04-30 at 19:58 +1000, David Holmes wrote:
>> >> On 30/04/2014 3:24 AM, Volker Simonis wrote:
>> >> > Hi Lois,
>> >> >
>> >> > sure, the latest webrev was:
>> >> >
>> >> > http://cr.openjdk.java.net/~simonis/webrevs/8039805.v3/
>> >> >
>> >> > As far as I understood, David recalled his concerns in his last mail
>> >> > ("..Ignore that. I just realized it is not the external linkage to
>> >> > these methods that is the main issue, but some internal hotspot code
>> >> > calling the global operator new/delete.." - see
>> >> > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-April/013523.html)
>> >> >
>> >> > @David: are you OK with the change now?
>> >>
>> >> Yes. To clarify for Lois my "Ignore that" retracted my comment that
>> >> everything in the "#ifndef ALLOW_OPERATOR_NEW_USAGE" block could be
>> >> deleted. I'm okay with getting rid of ALLOW_OPERATOR_NEW_USAGE itself.
>> >
>> > I believe removing the #ifndef ALLOW_OPERATOR_NEW_USAGE will break the
>> > shark JVM variant. Currently shark will need some more work to be
>> > useful, but a slowdebug build of shark doesn't even get past "java
>> > -version" due to those assertions. Defining it for a shark build + one
>>
>> Hi Severin,
>>
>> could you please post the stack trace of the assertion to see where
>> the operators are called from.
>
> Here is the mostly unreadable-in-email back trace:
>
> Breakpoint 1, operator new (size=16)
> at /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/hotspot/src/share/vm/memory/allocation.cpp:696
> 696       assert(false, "Should not call global operator new");
> (gdb) bt
> #0  operator new (size=16)
> at /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/hotspot/src/share/vm/memory/allocation.cpp:696
> #1  0x00007ffff6c51a3b in void*
> llvm::object_creator<llvm::sys::SmartMutex<true> >() ()
>
> from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
> #2  0x00007ffff729f255 in
> llvm::ManagedStaticBase::RegisterManagedStatic(void* (*)(), void
> (*)(void*)) const ()
>
> from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
> #3  0x00007ffff7299070 in
> llvm::sys::DynamicLibrary::AddSymbol(llvm::StringRef, void*) ()
>
> from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
> #4  0x00007ffff64c8584 in _GLOBAL__sub_I_JITMemoryManager.cpp ()
>
> from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so
> #5  0x000000388560f2ea in call_init (l=<optimized out>,
> argc=argc at entry=2, argv=argv at entry=0x7fffffffdf28,
> env=env at entry=0x7fffffffdf40) at dl-init.c:82
> #6  0x000000388560f3d3 in call_init (env=<optimized out>,
> argv=<optimized out>, argc=<optimized out>, l=<optimized out>) at
> dl-init.c:34
> #7  _dl_init (main_map=main_map at entry=0x6024a0, argc=2,
> argv=0x7fffffffdf28, env=0x7fffffffdf40) at dl-init.c:130
> #8  0x00000038856139b4 in dl_open_worker (a=a at entry=0x7fffffffaab8) at
> dl-open.c:566
> #9  0x000000388560f174 in _dl_catch_error
> (objname=objname at entry=0x7fffffffaaa8,
> errstring=errstring at entry=0x7fffffffaab0,
> mallocedp=mallocedp at entry=0x7fffffffaaa0,
>     operate=operate at entry=0x3885613620 <dl_open_worker>,
> args=args at entry=0x7fffffffaab8) at dl-error.c:177
> #10 0x000000388561309b in _dl_open (
>     file=0x7fffffffcd60
> "/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so", mode=-2147483390, caller_dlopen=0x7ffff7dd4ff1 <LoadJavaVM+57>, nsid=-2, argc=2, argv=<optimized out>, env=0x7fffffffdf40) at dl-open.c:650
> #11 0x0000003886a0102b in dlopen_doit (a=a at entry=0x7fffffffacc0) at
> dlopen.c:66
> #12 0x000000388560f174 in _dl_catch_error (objname=0x602100,
> errstring=0x602108, mallocedp=0x6020f8, operate=0x3886a00fd0
> <dlopen_doit>, args=0x7fffffffacc0) at dl-error.c:177
> #13 0x0000003886a0162d in _dlerror_run
> (operate=operate at entry=0x3886a00fd0 <dlopen_doit>,
> args=args at entry=0x7fffffffacc0) at dlerror.c:163
> #14 0x0000003886a010c1 in __dlopen (file=<optimized out>,
> mode=<optimized out>) at dlopen.c:87
> #15 0x00007ffff7dd4ff1 in LoadJavaVM (
>     jvmpath=0x7fffffffcd60
> "/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so", ifn=0x7fffffffdd60) at /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/jdk/src/solaris/bin/java_md_solinux.c:697
> #16 0x00007ffff7dced48 in JLI_Launch (argc=2, argv=0x6020d0, jargc=1,
> jargv=0x0, appclassc=1, appclassv=0x0,
>     fullversion=0x4008c8
> "1.9.0-internal-debug-sgeholf_2014_04_30_19_05-b00", dotversion=0x4008c0
> "1.9", pname=0x4008ac "java", lname=0x4008b1 "openjdk", javaargs=0
> '\000',
>     cpwildcard=1 '\001', javaw=0 '\000', ergo=0)
> at /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/jdk/src/share/bin/java.c:248
> #17 0x00000000004007dc in main (argc=2, argv=0x7fffffffdf28)
> at /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/jdk/src/share/bin/main.c:125
>
>> > other small fix will make "java -version" work.
>> >
>> > Take away: Shark code uses llvm and that in turn calls those global
>> > new/delete operators in spades. How do you suggest to work around this
>> > with this ifndef removed. Thoughts?
>> >
>>
>> I must confess that I don't know exactly how the Shark build works,
>> but if you load llvm as a shared library the llvm code shouldn't even
>> see the global HotSpot new/delete operators because we don't export
>> them and we compile with -fvisibility=hidden. Looking at the created
>> libjvm.so, this is confirmed:
>>
>> 00000000003d4442 t operator new[](unsigned long)
>> 00000000003d44b4 t operator new[](unsigned long, std::nothrow_t&)
>> 00000000003d440b t operator new(unsigned long)
>> 000000000038a986 t operator new(unsigned long, void*)
>> 00000000003d4479 t operator new(unsigned long, std::nothrow_t const&)
>
>> My only explanation for the problems you see would be if you compile
>> the llvm code right into the libjvm.so. If that's the case you should
>> either consider to build the llvm into it's own library or you should
>> flag the global operators in allocation.cpp with #ifndef SHARK".
>

OK, the stack trace shows that the llvm code is indeed compiled and
linked right into libjvm.so:

#1  0x00007ffff6c51a3b in void*
llvm::object_creator<llvm::sys::SmartMutex<true> >() ()

from /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-dev/build/linux-x86_64-normal-zeroshark-slowdebug/images/j2sdk-image/jre/lib/amd64/server/libjvm.so

That explains why it sees and uses HotSpots overloaded version of the
new operator.

Again, I don't now much about SHARK. But why is it necessary to
compile llvm right into the libjvm.so. Can't you compile it in it's
own library (i.e. llvm.so) and load that one dynamically. I think that
would solve the problem (and make you SHARK-enabled HotSpot more
modular at the same time).

> OK, thanks. I'll look into this.
>
>> By the way, I also couldn't find a place n the current makefiles where
>>  ALLOW_OPERATOR_NEW_USAGE is defined for a SHARK build. Where do you
>> currently set that define?
>
> Oh, sorry for the confusion. It's a local patch I'm using. In
> make/linux/makefiles/shark.make I have:
>
> CFLAGS += -DSHARK -DALLOW_OPERATOR_NEW_USAGE
>
> instead of the upstream version which has:
>
> CFLAGS += -DSHARK
>
> Cheers,
> Severin
>