build crash after extending oopDesc

[Simmen David]

Thanks a lot for all the info

I moved the field to instanceOopDesc and now the build runs through again.

MfG &thx david

-----Original Message-----
From: David Holmes [mailto:david.holmes at oracle.com] 
Sent: Wednesday, June 13, 2012 4:16 AM
To: Mikael Gerdin
Cc: Simmen David; hotspot-dev at openjdk.java.net
Subject: Re: build crash after extending oopDesc

On 13/06/2012 12:09 AM, Mikael Gerdin wrote:
> Perhaps it would be easier to prepend a modified java.lang.Object with 
> the extra field to the boot class path and hijack that field from 
> inside the VM instead of trying to get around all the assumptions 
> about the object header size all over the VM.

Nope, if you try to add a field to object you just invalidate a different set of assumptions.

David

> Regards
> /mg
>
> On 2012-06-12 13:57, Simmen David wrote:
>> No matter where I put the field it always crashes at the same point
>>
>> MfG David
>>
>> -----Original Message-----
>> From: hotspot-dev-bounces at openjdk.java.net
>> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen 
>> Phillimore
>> Sent: Monday, June 11, 2012 3:19 PM
>> To: hotspot-dev at openjdk.java.net
>> Subject: Re: build crash after extending oopDesc
>>
>>
>> The entire VM knows that the _klass field is after the mark field. 
>> Try moving your new field after that.
>> Coleen
>>
>> On 6/11/2012 4:31 AM, Simmen David wrote:
>>> Hello
>>> Thanks so far your help.
>>> Moving the new field after the _mark field did not help.
>>>
>>> The error still occurs when the build process tries to link hotspot.
>>> Alltough the error message now difers a bit it occurs still at the 
>>> same place
>>>
>>> Here is the build output
>>> Linking vm...
>>> /usr/bin/objcopy --only-keep-debug libjvm.so libjvm.debuginfo 
>>> /usr/bin/objcopy --add-gnu-debuglink=libjvm.debuginfo libjvm.so 
>>> strip -g libjvm.so [ -f libjvm.debuginfo ] || ln -s libjvm.debuginfo 
>>> libjvm.debuginfo zip -q -y libjvm.diz libjvm.debuginfo 
>>> libjvm.debuginfo rm -f libjvm.debuginfo libjvm.debuginfo [ -f 
>>> libjvm.diz ] || { ln -s libjvm.diz libjvm.diz; } echo Linking 
>>> launcher...
>>> Linking launcher...
>>> gcc -m32 -march=i586 -Xlinker -O1 -Wl,--hash-style=both -Xlinker -z 
>>> -Xlinker noexecstack -m32 -march=i586 -Xlinker -export-dynamic -L 
>>> `pwd` -o gamma launcher/java_md.o launcher/jli_util.o 
>>> launcher/wildcard.o launcher/java.o -ljvm -lm -ldl -lpthread
>>> make[6]: Leaving directory
>>> `/home/jdk/openjdku4/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product'
>>>
>>> All done.
>>> make[5]: Leaving directory
>>> `/home/jdk/openjdku4/build/linux-i586/hotspot/outputdir/linux_i486_compiler2/product'
>>>
>>> cd linux_i486_compiler2/product&& ./test_gamma Using java runtime at:
>>> /usr/lib/jvm/java-6-openjdk/jre # # A fatal error has been detected 
>>> by the Java Runtime Environment:
>>> #
>>> # SIGSEGV (0xb) at pc=0x00000000, pid=6318, tid=1090440000 # # JRE
>>> version: 6.0_24-b24 # Java VM: OpenJDK Server VM (23.2-b03 mixed 
>>> mode
>>> linux-x86 ) # Problematic frame:
>>> # C 0x00000000
>>> #
>>> # Failed to write core dump. Core dumps have been disabled. To 
>>> enable core dumping, try "ulimit -c unlimited" before starting Java 
>>> again # # An error report file with more information is saved as:
>>> #
>>> /home/jdk/openjdku4/build/linux-i586/hotspot/outputdir/linux_i486_co
>>> mp
>>> iler2/product/hs_err_pid6318.log
>>> #
>>> # If you would like to submit a bug report, please visit:
>>> # http://bugreport.sun.com/bugreport/crash.jsp
>>> #
>>> Aborted (core dumped)
>>> make[4]: *** [product] Error 134
>>>
>>>
>>> and here the code
>>> class oopDesc {
>>> friend class VMStructs;
>>> private:
>>> volatile markOop _mark;
>>> jint NewField;
>>> union _metadata {
>>> wideKlassOop _klass;
>>> narrowOop _compressed_klass;
>>> } _metadata;
>>>
>>>
>>> MfG David
>>>
>>> -----Original Message-----
>>> From: hotspot-dev-bounces at openjdk.java.net
>>> [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Thomas 
>>> Wuerthinger
>>> Sent: Sunday, June 10, 2012 8:23 PM
>>> To: Remi Forax
>>> Cc: hotspot-dev at openjdk.java.net; Christian Thalinger
>>> Subject: Re: build crash after extending oopDesc
>>>
>>> Extensibility and flexibility are at least main goals of the Graal 
>>> project. We are currently doing experiments around removing the 
>>> restriction on the JIT by writing the interpreter in Java too. We 
>>> will present our results at this year's JVM Language Summit.
>>>
>>> - thomas
>>>
>>>
>>> On 10.06.2012 12:55, Remi Forax wrote:
>>>> I think Graal (the OpenJDK project) is nowadays close to the 
>>>> original hotspot in term of hackability even if it's restricted to the JIT.
>>>>
>>>> Rémi
>>>>
>>>> Sent from my Phone
>>>>
>>>> ----- Reply message -----
>>>> From: "John Rose"<john.r.rose at oracle.com>
>>>> To: "Krystal Mok"<rednaxelafx at gmail.com>
>>>> Cc: "hotspot-dev at openjdk.java.net"<hotspot-dev at openjdk.java.net>,
>>>> "Christian Thalinger"<christian.thalinger at oracle.com>
>>>> Subject: build crash after extending oopDesc
>>>> Date: Sat, Jun 9, 2012 09:37
>>>>
>>>>
>>>> On Jun 8, 2012, at 11:51 AM, Krystal Mok wrote:
>>>>
>>>>> David,
>>>>>
>>>>> If this patch [1] resembles your change, then what I saw was that
>>>> the VM would build all right, but would fail running test_gamma 
>>>> right at the end of the build process.
>>>>> The problem was caused by arrayOopDesc::length_offset_in_bytes(), 
>>>>> as
>>>> noted [2]. test_gamma runs fine if I drop a .hotspotrc file 
>>>> specifying -UseCompressedOops in it, which confirms the problem.
>>>>
>>>> Good analysis, Kris.
>>>>
>>>> What happens if you add the extraneous field after the _mark field?
>>>> I think that would be more robust, although there is still likely 
>>>> to be a bug tail.
>>>>
>>>> Here's an old war-story: When the original Hotspot team brought 
>>>> their prototype to Sun long ago, I was on the technical evaluation 
>>>> team.
>>>> One of my tests was to inject an extra field into class oopDesc.
>>>> (Specifically, the field held a string representation of the thread 
>>>> backtrace at the point of the object's allocation. A crude 
>>>> allocation
>>>> profiler!) The system worked with a few edits and no further 
>>>> adjustment. This demonstrated to me that the software architecture 
>>>> was robust and ready to evolve.
>>>>
>>>> (Things are different now. The system is more than 10x larger. It 
>>>> contains multiple platform ports, two good JITs, instrumentation, 
>>>> several GCs, and compressed pointers, none of which the prototype had.
>>>> I wish our system were still as malleable as it was when it was 
>>>> young, but it's a different engineering problem today.)
>>>>
>>>> — John
>>>>
>>>> diff --git a/src/share/vm/oops/oop.hpp b/src/share/vm/oops/oop.hpp
>>>> --- a/src/share/vm/oops/oop.hpp
>>>> +++ b/src/share/vm/oops/oop.hpp
>>>> @@ -62,6 +62,7 @@
>>>> friend class VMStructs;
>>>> private:
>>>> volatile markOop _mark;
>>>> + intptr_t _extraneous;
>>>> union _metadata {
>>>> wideKlassOop _klass;
>>>> narrowOop _compressed_klass;
>>>>
>