[drlvm] Regression caused by compressed VTable pointers
8 Message(s) by 5 Author(s) originally posted in harmony developer java
| From: Eugene Ostrovsky |
Date: Friday, December 14, 2007
|
Hi all!
We've a
regression in stress test suite:
http://issues.apache.org/jira/browse/HARMONY-5047
The problem is that in compressed VTable pointers mode (which is
default for x86_64 platforms) number of
class es that VM could
load is
limited by the size of VTable
memory pool = 8 MB. VM crashes because
VT pool is overflowed when the test tries to load about 34000 classes.
(VTable for each class is >= 232 B)
It seems that we need smarter memory
management for VTables in compressed mode.
Or probably we should disable compressed VTable pointers at all.
Proposals are welcome.
Thanks,
Eugene.
| From: Xiao-Feng Li |
Date: Friday, December 14, 2007
|
wrote in message:
Hi all!
We've a regression in stress test suite:
http://issues.apache.org/jira/browse/HARMONY-5047
The problem is that in compressed VTable pointers mode (which is
default for x86_64 platforms) number of classes that VM could load is
limited by the size of VTable memory pool = 8 MB. VM crashes because
VT pool is overflowed when the test tries to load about 34000 classes.
(VTable for each class is >= 232 B)
It seems that we need smarter memory management for VTables in compressed mode.
Or probably we should disable compressed VTable pointers at all.
Eugene, agree. I guess it should be easy to have a resizable pool for
Vtables by preserving bigger
address space for it. Of course,
uncompressed vtable is also a solution.
Thanks,
xiaofeng
Proposals are welcome.
Thanks,
Eugene.
--
http://xiao-feng.blogspot.com
| From: Mikhail Loenko |
Date: Friday, December 14, 2007
|
How it worked before?
2007/12/14, Xiao-Feng Li
<xiaofeng.li@xxxxxxxxxxx>:
wrote in message:
> Hi all!
>
> We've a regression in stress test suite:
>
http://issues.apache.org/jira/browse/HARMONY-5047
>
> The problem is that in compressed VTable pointers mode (which is
> default for x86_64 platforms) number of classes that VM could load is
> limited by the size of VTable memory pool = 8 MB. VM crashes because
> VT pool is overflowed when the test tries to load about 34000 classes.
> (VTable for each class is >= 232 B)
>
> It seems that we need smarter memory management for VTables in compressed mode.
> Or probably we should disable compressed VTable pointers at all.
Eugene, agree. I guess it should be easy to have a resizable pool for
Vtables by preserving bigger address space for it. Of course,
uncompressed vtable is also a solution.
Thanks,
xiaofeng
> Proposals are welcome.
>
> Thanks,
> Eugene.
>
--
http://xiao-feng.blogspot.com
| From: Pavel Pervov |
Date: Friday, December 14, 2007
|
------=_Part_688_11750926.1197654395730
Content-Disposition: inline
I believe this isn't a regression at all. This
code existed from the very
beginning in DRLVM.
For now we can either specify bigger pool for DLRVM, or reduce stress amount
in the tests.
wrote in message:
How it worked before?
2007/12/14, Xiao-Feng Li <xiaofeng.li@xxxxxxxxxxx>:
> On Dec 14, 2007 9:39 PM, Eugene Ostrovsky <eugene.s.ostrovsky@xxxxxxxxxxx>
wrote in message:
> > Hi all!
> >
> > We've a regression in stress test suite:
> > http://issues.apache.org/jira/browse/HARMONY-5047
> >
> > The problem is that in compressed VTable pointers mode (which is
> > default for x86_64 platforms) number of classes that VM could load is
> > limited by the size of VTable memory pool = 8 MB. VM crashes because
> > VT pool is overflowed when the test tries to load about 34000 classes.
> > (VTable for each class is >= 232 B)
> >
> > It seems that we need smarter memory management for VTables in
compressed mode.
> > Or probably we should disable compressed VTable pointers at all.
>
> Eugene, agree. I guess it should be easy to have a resizable pool for
> Vtables by preserving bigger address space for it. Of course,
> uncompressed vtable is also a solution.
>
> Thanks,
> xiaofeng
>
> > Proposals are welcome.
> >
> > Thanks,
> > Eugene.
> >
>
>
>
> --
> http://xiao-feng.blogspot.com
>
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
------=_Part_688_11750926.1197654395730--
| From: Rana Dasgupta |
Date: Friday, December 14, 2007
|
------=_Part_2948_1159316.1197680987707
Content-Disposition: inline
I'd suggest reducing stress amount in the tests. This code hasn't
changed and so this isn't a regression. We should
support 64
bit vtable
refs for uncompressed mode in the next milestone and
run tests like this in
full uncompressed mode.
wrote in message:
I believe this isn't a regression at all. This code existed from the very
beginning in DRLVM.
For now we can either specify bigger pool for DLRVM, or reduce stress
amount
in the tests.
Eugene, what do you think?
wrote in message:
>
> How it worked before?
>
> 2007/12/14, Xiao-Feng Li <xiaofeng.li@xxxxxxxxxxx>:
> > On Dec 14, 2007 9:39 PM, Eugene Ostrovsky <
eugene.s.ostrovsky@xxxxxxxxxxx>
wrote in message:
> > > Hi all!
> > >
> > > We've a regression in stress test suite:
> > > http://issues.apache.org/jira/browse/HARMONY-5047
> > >
> > > The problem is that in compressed VTable pointers mode (which is
> > > default for x86_64 platforms) number of classes that VM could load
is
> > > limited by the size of VTable memory pool = 8 MB. VM crashes
because
> > > VT pool is overflowed when the test tries to load about 34000
classes.
> > > (VTable for each class is >= 232 B)
> > >
> > > It seems that we need smarter memory management for VTables in
> compressed mode.
> > > Or probably we should disable compressed VTable pointers at all.
> >
> > Eugene, agree. I guess it should be easy to have a resizable pool for
> > Vtables by preserving bigger address space for it. Of course,
> > uncompressed vtable is also a solution.
> >
> > Thanks,
> > xiaofeng
> >
> > > Proposals are welcome.
> > >
> > > Thanks,
> > > Eugene.
> > >
> >
> >
> >
> > --
> > http://xiao-feng.blogspot.com
> >
>
--
Pavel Pervov,
Intel Enterprise Solutions Software Division
------=_Part_2948_1159316.1197680987707--
| From: Mikhail Loenko |
Date: Saturday, December 15, 2007
|
I'm against simplifying tests to make them passing.
Tests are for catching bugs and failing tests indicate that a problem does exist
2007/12/15, Rana Dasgupta
<rdasgupt@xxxxxxxxxxx>:
I'd suggest reducing stress amount in the tests. This code hasn't
changed and so this isn't a regression. We should support 64 bit vtable
refs for uncompressed mode in the next milestone and run tests like this in
full uncompressed mode.
wrote in message:
> I believe this isn't a regression at all. This code existed from the very
> beginning in DRLVM.
>
> For now we can either specify bigger pool for DLRVM, or reduce stress
> amount
> in the tests.
>
> Eugene, what do you think?
>
>
wrote in message:
> >
> > How it worked before?
> >
> > 2007/12/14, Xiao-Feng Li <xiaofeng.li@xxxxxxxxxxx>:
> > > On Dec 14, 2007 9:39 PM, Eugene Ostrovsky <
> eugene.s.ostrovsky@xxxxxxxxxxx>
wrote in message:
> > > > Hi all!
> > > >
> > > > We've a regression in stress test suite:
> > > > http://issues.apache.org/jira/browse/HARMONY-5047
> > > >
> > > > The problem is that in compressed VTable pointers mode (which is
> > > > default for x86_64 platforms) number of classes that VM could load
> is
> > > > limited by the size of VTable memory pool = 8 MB. VM crashes
> because
> > > > VT pool is overflowed when the test tries to load about 34000
> classes.
> > > > (VTable for each class is >= 232 B)
> > > >
> > > > It seems that we need smarter memory management for VTables in
> > compressed mode.
> > > > Or probably we should disable compressed VTable pointers at all.
> > >
> > > Eugene, agree. I guess it should be easy to have a resizable pool for
> > > Vtables by preserving bigger address space for it. Of course,
> > > uncompressed vtable is also a solution.
> > >
> > > Thanks,
> > > xiaofeng
> > >
> > > > Proposals are welcome.
> > > >
> > > > Thanks,
> > > > Eugene.
> > > >
> > >
> > >
> > >
> > > --
> > > http://xiao-feng.blogspot.com
> > >
> >
>
>
>
> --
> Pavel Pervov,
> Intel Enterprise Solutions Software Division
>
| From: Eugene Ostrovsky |
Date: Sunday, December 16, 2007
|
I agree with Mikhail and Tim.
Stress tests are intended to make stress. A stress test that was
simplified to make him pass is useless.
wrote in message:
I guess it should be easy to have a resizable pool for Vtables by preserving bigger address space for it.
What do you mean by 'preserving'?
If we preallocate memory for a pool it can not be called 'resizable'
IMHO even if it is really huge.
How much do you propose to increase the pool? 2 times? 10 times?
Thanks,
Eugene.
wrote in message:
wrote in message:
> I'm against simplifying tests to make them passing.
> Tests are for catching bugs and failing tests indicate that a problem does exist
Yep, no need to make the test 'artificially' pass. If it is a good test
then leave it as a failing test so we know what to fix.
Regards,
Tim
| From: Rana Dasgupta |
Date: Monday, December 17, 2007
|
------=_Part_7790_33091887.1197904513296
Content-Disposition: inline
Eugene,
A stress test is intended to verify that the
system works correctly upto
the the max limits supported by the
design . In this case ~ 8MB of vtable
space which is large enough for > 30000 classes.
Any stress test can be constructed to go beyond any design constraint, it
doesn't give us much new information. I think that it makes sense to leave
it as a failing test. We can rethink if we need to support more in the next
milestone, and what's the best way to do it. A good way'd be to
investigate if an Eclipse
type scenario can be found that actually loads
more than 34000 classes.
Thanks,
Rana
On Dec 16, 2007 10:39 AM, Eugene Ostrovsky
<eugene.s.ostrovsky@xxxxxxxxxxx>
wrote in message:
I agree with Mikhail and Tim.
Stress tests are intended to make stress. A stress test that was
simplified to make him pass is useless.
wrote in message:
> I guess it should be easy to have a resizable pool for Vtables by
preserving bigger address space for it.
What do you mean by 'preserving'?
If we preallocate memory for a pool it can not be called 'resizable'
IMHO even if it is really huge.
How much do you propose to increase the pool? 2 times? 10 times?
Thanks,
Eugene.
wrote in message:
wrote in message:
> > I'm against simplifying tests to make them passing.
> > Tests are for catching bugs and failing tests indicate that a problem
does exist
>
> Yep, no need to make the test 'artificially' pass. If it is a good test
> then leave it as a failing test so we know what to fix.
>
> Regards,
> Tim
------=_Part_7790_33091887.1197904513296--
Next Message: About the loading constraint