It is the revision from saturday, september, 23rd.
Regards,
Pavel.
On 9/25/06, Weldon Washburn <[EMAIL PROTECTED]> wrote:
Pavel,
I glanced at it. Was this patch made on an svn revision number from this
week?
On 9/23/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
>
> Created Harmony-1558 [1
Pavel,
I glanced at it. Was this patch made on an svn revision number from this
week?
On 9/23/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
Created Harmony-1558 [1] with the intention to attach all patches to it.
"Step 1" patch attached - interested parties can review.
Regards,
Pavel.
[1]
Created Harmony-1558 [1] with the intention to attach all patches to it.
"Step 1" patch attached - interested parties can review.
Regards,
Pavel.
[1] https://issues.apache.org/jira/browse/HARMONY-1558
On 7/24/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
Hello, all.
I would like to work on
2006/9/14, Pavel Pervov <[EMAIL PROTECTED]>:
>
> > > For example, private members of Method _parse_exceptions()
> > > _parse_local_vars(), _parse_line_numbers(), _parse_code() actually
> > > should be public members of respective entities.
> >
> > They should not. Nobody but Method knows nothing
On 9/14/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
> The inclusion of external header files in GC is a continual
battle. From
> a
> modularity standpoint, the external header files need to be excluded.
> During GC debug its often useful to access class name, subclass name,
etc.
> What real
The inclusion of external header files in GC is a continual battle. From
a
modularity standpoint, the external header files need to be excluded.
During GC debug its often useful to access class name, subclass name, etc.
What really needs to happen is class.h accessors need to be created.
On 9/14/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
> The problem is not parsing code itself, you know - just when someone
> does a trivial fix in LocalVarTable parsing procedure, I have to
> recompile the whole VM + GC (and maybe even JIT)! Where are you, vm
> modularity ;)
No, you don't. If so
Pavel, Alexey,
I agree on holding off cleanup of class loader until Pavel's proposal is
committed to trunk.
Pavel,
It would be great if you can open a JIRA with rough sample header files as
soon as you are comfortable. I anticipate lots of conversation on this.
The intention is to stay away fro
> > For example, private members of Method _parse_exceptions()
> > _parse_local_vars(), _parse_line_numbers(), _parse_code() actually
> > should be public members of respective entities.
>
> They should not. Nobody but Method knows nothing about local variable
tables
> and line numbers stored in
2006/9/14, Pavel Pervov <[EMAIL PROTECTED]>:
>
> 2006/9/13, Pavel Pervov <[EMAIL PROTECTED]>:
> > Not sure C++ "friend"s are good design.
> Umm, what is wrong with friends?
It's sort of breaking incapsulation ideology. Nothing more. :)
> For example, private members of Method _parse_exception
2006/9/13, Pavel Pervov <[EMAIL PROTECTED]>:
> Not sure C++ "friend"s are good design.
Umm, what is wrong with friends?
It's sort of breaking incapsulation ideology. Nothing more. :)
For example, private members of Method _parse_exceptions()
_parse_local_vars(), _parse_line_numbers(), _pars
Alexey,
It is still alive and very active. :) But I'd rather wait until 1363 applied
before making any moves in that direction.
Regards,
Pavel.
On 9/14/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
Pavel,
What happened with your initial plan (cited below)? I suggest you
proceed with it,
Pavel,
What happened with your initial plan (cited below)? I suggest you
proceed with it, I may postpone more local activities until you've
done the major part.
First thing I would like to do is to split the file into a group of files,
each of which would contain only one entity (and some close
2006/9/13, Pavel Pervov <[EMAIL PROTECTED]>:
Not sure C++ "friend"s are good design.
Umm, what is wrong with friends?
Although class format is something
one might want to localize to be known to only one entity (like
ClassFileParser), it is much better to provide "format extractor" to anybody
Alexey,
I agree with what Pavel Pervov says below. In looking at the code in
vmcore/src/class_support, creating another class adds another layer of
complexity and will make removal of unnecessary code more difficult. C++
"friends" should be used very sparingly. Can you try Pavel's suggestion
be
Not sure C++ "friend"s are good design. Although class format is something
one might want to localize to be known to only one entity (like
ClassFileParser), it is much better to provide "format extractor" to anybody
interested in its use and let them manage their content by themselves. This
is how
2006/9/11, Weldon Washburn <[EMAIL PROTECTED]>:
On 9/10/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
>
> 2006/9/10, Pavel Pervov <[EMAIL PROTECTED]>:
> > Weldon,
> >
> > one of good examples is static_method_block member variable of struct
> Class.
> > Its size if calculated, memory is allocate
On 9/10/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
2006/9/10, Pavel Pervov <[EMAIL PROTECTED]>:
> Weldon,
>
> one of good examples is static_method_block member variable of struct
Class.
> Its size if calculated, memory is allocated for it, but it is never used
> throughout the code. Roughly
2006/9/10, Pavel Pervov <[EMAIL PROTECTED]>:
Weldon,
one of good examples is static_method_block member variable of struct Class.
Its size if calculated, memory is allocated for it, but it is never used
throughout the code. Roughly 3K classes loaded in simple Eclipse usage
scenario (open Eclipse
Pavel,
I would first like to see a patch that removes all the unused variables and
cleans up comments. Once this is committed, it makes sense address the
other items you mention.
Regarding C++. I would suggest looking at doing as much as possible in
Java instead of C++. Vmmagic is mostly fun
Weldon,
one of good examples is static_method_block member variable of struct Class.
Its size if calculated, memory is allocated for it, but it is never used
throughout the code. Roughly 3K classes loaded in simple Eclipse usage
scenario (open Eclipse, create "hello, world" application, run it, e
Pavel,
In general I like the idea of cleaning up this code. Maybe the best thing
to do is post some patches so that we have examples to discuss.
Weldon
On 9/5/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
It's been long time this discussion stopped.
This may mean three things:
- first, everyone
+1 for cleanup, I could even assist you.
Please also consider possible dependency on issue #1363.
--
Regards,
Alexey
2006/9/5, Pavel Pervov <[EMAIL PROTECTED]>:
It's been long time this discussion stopped.
This may mean three things:
- first, everyone agrees this should be done and I'm ok to pr
It's been long time this discussion stopped.
This may mean three things:
- first, everyone agrees this should be done and I'm ok to provide
consecutive patches;
- second, noone clearly understand the purpose of what is suggested to do;
if this is the case, do not hesitate to ask (again?);
- third,
Pavel,
but the common root class in Java is java.lang.Object, so you propose me to
use this class as root every time I want to browse a method hierarchy?
On 7/25/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
Michail,
you can get root class set to A and iterate "all incarnations" from there.
Reg
Geir,
well, it is the argument at least for me to start thinking in this direction
and initiate this discussion.
And there are places in VM core code where only definition of members of a
class is required, but whole Class.h is included anyway. This is also about
localizing potential development
Michail,
you can get root class set to A and iterate "all incarnations" from there.
Regards,
Pavel.
On 7/24/06, Mikhail Fursov <[EMAIL PROTECTED]> wrote:
On 7/24/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
>
> Michail,
>
> If some component external to VM core has direct access to class.h,
Pavel Pervov wrote:
> On 7/24/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
>>
>> 2006/7/24, Pavel Pervov <[EMAIL PROTECTED]>:
>> > First thing I would like to do is to split the file into a group of
>> files,
>> > each of which would contain only one entity (and some closely related
>> > entit
On 7/24/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
Michail,
If some component external to VM core has direct access to class.h, this
should be eliminated shortly. AFAIU, there are none such components.
Yes there are no such components, JIT uses 'vm.h' file to access class or
methods informa
Weldon,
thank you for catching this.
1) Entities I want to make C++ classes are struct Class and constant pool of
a class.
2) Class members (fields and methods) are already C++ classes.
3) VTables are NOT going to become C++ classes.
The motivation for moving to C++ is encapsulation of access t
Michail,
If some component external to VM core has direct access to class.h, this
should be eliminated shortly. AFAIU, there are none such components.
Answering your questions:
1) It is possible to traverse class hierarchy downward using available
specialized interfaces. It is also possible to t
On 7/24/06, Pavel Pervov <[EMAIL PROTECTED]> wrote:
Hello, all.
I would like to work on cleaning the insides of Class.h header file.
This header is related to internal representation of java class inside the
VM. Currently it contains all entities for internal class representation:
class itself,
Pavel,
Class.h is also used by other modules with by of vm.h public wrappers.
Can you add more class hierarchy analysis (CHA) related methods to the
public interface of Class.h during the refactoring.
The methods I interested in
1) To iterate class hierarchy in two directions: from super to subcl
On 7/24/06, Alexey Petrenko <[EMAIL PROTECTED]> wrote:
2006/7/24, Pavel Pervov <[EMAIL PROTECTED]>:
> Hello, all.
>
> I would like to work on cleaning the insides of Class.h header file.
>
> This header is related to internal representation of java class inside
the
> VM. Currently it contains al
2006/7/24, Pavel Pervov <[EMAIL PROTECTED]>:
Hello, all.
I would like to work on cleaning the insides of Class.h header file.
This header is related to internal representation of java class inside the
VM. Currently it contains all entities for internal class representation:
class itself, consta
Hello, all.
I would like to work on cleaning the insides of Class.h header file.
This header is related to internal representation of java class inside the
VM. Currently it contains all entities for internal class representation:
class itself, constant pool, members (field, method), exceptions h
36 matches
Mail list logo
