Re: [rvm-research] problems using advice with MarkCompact and Jikes-3.1.3

Hi Jennifer,

I'm not familiar with Steve's probe / replay code. Is it modifying the 
object layout at all, e.g., adding an extra header word at the beginning 
or end of each object? Such a change could violate some unstated 
assumption about how the beginning (or end?) of an object will look, 
which could mess up the ability to linearly scan over objects in a 
bump-pointer-allocated space, which MarkCompact relies on.

One easy way we found to get around assumptions about how the first word 
of an object looks, is to place MiscHeader words after the TIB instead 
of before the TIB. Here's how we changed JavaHeaderConstants:

+   // Put MiscHeader *between* JavaHeader and fields. Then the lowest 
bit of the MiscHeader word doesn't need to be 0.
+   final boolean miscHeaderAfter = true;
+
     /** Offset of array length from object reference */
     Offset ARRAY_LENGTH_OFFSET = 
Offset.fromIntSignExtend(-ARRAY_LENGTH_BYTES);
     /** Offset of the first field from object reference */
     Offset FIELD_ZERO_OFFSET = ARRAY_LENGTH_OFFSET;
     /** Offset of the Java header from the object reference */
!   Offset JAVA_HEADER_OFFSET = 
ARRAY_LENGTH_OFFSET.minus(JAVA_HEADER_BYTES + (miscHeaderAfter ? 
MISC_HEADER_BYTES : 0));
     /** Offset of the miscellaneous header from the object reference */
!   Offset MISC_HEADER_OFFSET = (miscHeaderAfter ? ARRAY_LENGTH_OFFSET : 
JAVA_HEADER_OFFSET).minus(MISC_HEADER_BYTES);
     /** Offset of the garbage collection header from the object 
reference */
!   Offset GC_HEADER_OFFSET = (miscHeaderAfter ? JAVA_HEADER_OFFSET : 
MISC_HEADER_OFFSET).minus(GC_HEADER_BYTES);
     /** Offset of first element of an array */
     Offset ARRAY_BASE_OFFSET = Offset.zero();


Or maybe the issue is related to hash codes? I think under some build 
conditions the object model will place hash codes at the end of an object?

Best,
Mike

On 09/07/2017 06:47 AM, Jennifer B. Sartor wrote:
> Thank you Erik for replying.
>
> I tried to run with 1 GC thread, but the benchmarks still fail with 
> the same error.
>
> I also couldn’t get lusearch to complete successfully without replay 
> using MarkCompact.  The error was during a regular allocation, 
> regardless of heap size used:
> Conflicting virtual address request for space "los" at 0xa4c00000
>
> Thanks for any other advice anyone has!
>
> Best,
> Jennifer
>
>
>> On 06 Sep 2017, at 7:07 PM, Erik Brangs <[email protected] 
>> <mailto:[email protected]>> wrote:
>>
>> Hi,
>>
>> On 06.09.2017 11:33, Jennifer B. Sartor wrote:
>>> However, I’m having a problem getting MarkCompact to work with 
>>> replay.  Is anyone familiar with this problem?
>>
>> I'm not familiar with this problem. I advise you to try running with 
>> only one GC thread. There's a failure on assertion-enabled 
>> MarkCompact builds that occurs only when running with multiple GC 
>> threads (see RVM-1039). If your problem is related, it should 
>> disappear when running with only one GC thread.
>>
>>
>> Kind regards,
>>
>> Erik Brangs
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org <http://slashdot.org>! 
>> http://sdm.link/slashdot
>> _______________________________________________
>> Jikesrvm-researchers mailing list
>> [email protected] 
>> <mailto:[email protected]>
>> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers
>>
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Jikesrvm-researchers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
Jikesrvm-researchers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jikesrvm-researchers