6953477: review request for portability improvements to Hotspot

[David Holmes]

Hi Tom,

Thanks for the close scrutiny.

Tom Rodriguez said the following on 07/30/10 03:18:
> The print_location changes in os::print_context are interesting, if a
> little verbose.  Do you have an example of what the output will look
> like?

Internally there are some examples in the CR for 6889724. I also posted 
something below.

> You should make equivalent changes in os_windows_x86.cpp too.

Ideally yes, but at the time, as now, I had no access to Windows boxes 
for building or testing this.

> src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp:
> 
> you changed the formatting of the existing printing, with an extra
> leading ',' and a missing st->cr().

That wasn't an intentional change - not sure what happened. (This is in 
the AMD64 part of the code. )

> c1_Compilation.hpp:
> 
> Why don't you just clamp NMethodSizeLimit to 32K instead?

In general the aim is to make ARCH specific changes without affecting 
any other code. We'd have to establish that the suggested change is 
valid on all platforms.

> jniHandles.cpp:
> 
> What's the point of these changes?  They expose _block_list in
> product but don't actually enable the code that updates block_list so
> they don't do anything useful.

It was an oversight on my part that _block_list would not get updated in 
product mode. This needs to enabled in product. print_location needs 
access to JNIHandleBlock::any_contains in product, which in turn needs 
access to the _block_list. (Or we disable the JNI handle check in 
product mode inside print_location.)

Testing of print_location was limited as it was not feasible to 
orchestrate crashes where a register was known to contain an address of 
all the possible "types" that print_location would be looking for. There 
may be other places where the conversion from non-product to product 
missed something.

> os.cpp:
> 
> why was the default for _processor_count changed to 1?

I don't know, but it partially invalidates the sanity check here:

  static inline bool is_MP() {
     assert(_processor_count > 0, "invalid processor count");
     return _processor_count > 1;
   }

this would allow is_MP to be used before the processor count has been 
properly set. Such a usage might be incorrect in some contexts.

David
-----

---------------  T H R E A D  ---------------

Current thread (0x00021400):  JavaThread "main" [_thread_in_vm, 
id=28045, stack(0x406ae000,0x406fe000)]

siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), 
si_addr=0x00000000

Registers:
   r0  = 0x000b0c00
   r1  = 0x00006b70
   r2  = 0x00000000
   r3  = 0x00000064
   r4  = 0x00000000
   r5  = 0x000b0c00
   r6  = 0x000b0c00
   r7  = 0x00021400
   r8  = 0x00020638
   r9  = 0x4a650c58
   r10 = 0x00000000
   fp  = 0x406fcad4
   r12 = 0x00000001
   sp  = 0x406fca58
   lr  = 0x403e1768
   pc  = 0x40480278


Register to memory mapping:
   r0  = 0x000b0c00
"Thread-2" prio=10 tid=0x000b0c00 nid=0x7da1 initialized [0x00000000]
    java.lang.Thread.State: RUNNABLE
   r1  = 0x00006b70
0x00006b70 is pointing to unknown location
   r2  = 0x00000000
0x00000000 is pointing to unknown location
   r3  = 0x00000064
0x00000064 is pointing to unknown location
   r4  = 0x00000000
0x00000000 is pointing to unknown location
   r5  = 0x000b0c00
"Thread-2" prio=10 tid=0x000b0c00 nid=0x7da1 initialized [0x00000000]
    java.lang.Thread.State: RUNNABLE
   r6  = 0x000b0c00
"Thread-2" prio=10 tid=0x000b0c00 nid=0x7da1 initialized [0x00000000]
    java.lang.Thread.State: RUNNABLE
   r7  = 0x00021400
"main" prio=10 tid=0x00021400 nid=0x6d8d runnable [0x406fc000]
    java.lang.Thread.State: RUNNABLE
   r8  = 0x00020638
0x00020638 is pointing to unknown location
   r9  = 0x4a650c58
{method}
  - klass: {other class}
   r10 = 0x00000000
0x00000000 is pointing to unknown location
   fp  = 0x406fcad4
0x406fcad4 is pointing into the stack for thread: 0x00021400
"main" prio=10 tid=0x00021400 nid=0x6d8d runnable [0x406fc000]
    java.lang.Thread.State: RUNNABLE
   r12 = 0x00000001
0x00000001 is pointing to unknown location
   sp  = 0x406fca58
0x406fca58 is pointing into the stack for thread: 0x00021400
"main" prio=10 tid=0x00021400 nid=0x6d8d runnable [0x406fc000]
    java.lang.Thread.State: RUNNABLE
   lr  = 0x403e1768
0x403e1768: JVM_StartThread+0xe8 in 
/java/embedded/users/dh198349/1.6.0_18/builds/b06/linux-armv5-eabi-sflt-full-dev/j2sdk-image/jre/lib/arm/client/libjvm.so 
at 0x40191000
   pc  = 0x40480278
0x40480278: <offset 0x2ef278> in 
/java/embedded/users/dh198349/1.6.0_18/builds/b06/linux-armv5-eabi-sflt-full-dev/j2sdk-image/jre/lib/arm/client/libjvm.so 
at 0x40191000