Sagewire Logo

[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



Programming | Sports | Autos

copyright 2006
Valid XHTML 1.0 Transitional