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

Wed Apr 30 17:30:14 UTC 2014

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, 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