[rvm-core] Intel boot image runner forces virtual processor high nibble to be >= 3, why?

[Ian Rogers (nabble)]

Hi,

can anyone remember why in libvm.c line 640 for Intel we fail if the
high nibble of a virtual processor is <3 ? Is this some cruft we can
now remove?

Thanks,
Ian

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[R.E.Jones]

I don't know the answer to this specific question but it bit me the  
other day.
Here's the scenario:

I am running JikesRVM with GCspy, using its C++ server.
The world is stopped and the GCspy C++ server needs to extend one of  
its arrays; it calls "new short[size]" which succeeds.
But shortly after, while populating that array, libvm.c tops with an  
error message that the frame is invalid (60).

In the jconfigure days, I recall having to manually adjust the memory  
layout. My suspicion, not based on anything other than a hunch yet, is  
that JikesRVM and GCspy might be in conflict for memory.

Richard

On 26 Jan 2009, at 23:38, Ian Rogers wrote:

> Hi,
>
> can anyone remember why in libvm.c line 640 for Intel we fail if the
> high nibble of a virtual processor is <3 ? Is this some cruft we can
> now remove?
>
> Thanks,
> Ian

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers (nabble)]

2009/1/27 Richard Jones <R.E.Jones@...>:

> I don't know the answer to this specific question but it bit me the
> other day.
> Here's the scenario:
>
> I am running JikesRVM with GCspy, using its C++ server.
> The world is stopped and the GCspy C++ server needs to extend one of
> its arrays; it calls "new short[size]" which succeeds.
> But shortly after, while populating that array, libvm.c tops with an
> error message that the frame is invalid (60).
>
> In the jconfigure days, I recall having to manually adjust the memory
> layout. My suspicion, not based on anything other than a hunch yet, is
> that JikesRVM and GCspy might be in conflict for memory.
>
> Richard

We still specify the memory layout, these days we use a properties
file though. The file is in build/targets and then corresponds to your
host (assuming you're not cross compiling).

By disabling the high nibble test and changing the memory region to
start of 0x1....... rather than 0x6......., I've been able to double
the maximum supported heap for me from 1280MB to 2560MB. I think it'd
make sense that this was the default in the trunk, any opinions?

Thanks,
Ian

> On 26 Jan 2009, at 23:38, Ian Rogers wrote:
>
>> Hi,
>>
>> can anyone remember why in libvm.c line 640 for Intel we fail if the
>> high nibble of a virtual processor is <3 ? Is this some cruft we can
>> now remove?
>>
>> Thanks,
>> Ian
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Jikesrvm-core mailing list
> Jikesrvm-core@...
> https://lists.sourceforge.net/lists/listinfo/jikesrvm-core
>

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[David P Grove]

Ian Rogers <ian.rogers@...> wrote on 01/26/2009 06:38:24 PM:
> can anyone remember why in libvm.c line 640 for Intel we fail if the
> high nibble of a virtual processor is <3 ? Is this some cruft we can
> now remove?

It's an assertion that's trying to ensure that the value in the PR register is valid before we dive off and start using it.  If the Processor object is allocated in the MMTk managed spaces (and the MMTk spaces are in their usual ranges) then this should always be true.

--dave


------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core

[Ian Rogers (nabble)]

2009/1/27 David P Grove <groved@...>:

> Ian Rogers <ian.rogers@...> wrote on 01/26/2009 06:38:24 PM:
>> can anyone remember why in libvm.c line 640 for Intel we fail if the
>> high nibble of a virtual processor is <3 ? Is this some cruft we can
>> now remove?
>
> It's an assertion that's trying to ensure that the value in the PR register
> is valid before we dive off and start using it.  If the Processor object is
> allocated in the MMTk managed spaces (and the MMTk spaces are in their usual
> ranges) then this should always be true.
>
> --dave

So the code is:

unsigned int vp_hn;  /* the high nibble of the vp address value */
vp_hn = localVirtualProcessorAddress >> 28;
if (vp_hn < 3 || !inRVMAddressSpace(localVirtualProcessorAddress))

I can't see any other references that say that processors must be
allocated at addresses greater than 0x30000000. The code is doing a
sanity test of the virtual processor address other than the high
nibble test. If I remove the test I don't get any problems with images
allocated below 0x30000000. My suspicion is that the high nibble test
is a quick and dirty test that someone added. As this test inhibits
using the maximum heap space on Intel I think we should remove it.
I've opened RVM-756 to get this into 3.0.2.

Thanks,
Ian

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Jikesrvm-core mailing list
Jikesrvm-core@...
https://lists.sourceforge.net/lists/listinfo/jikesrvm-core