Simon Chow wrote:
Thanks George, It is very helpful!
BTW, what do SystemClasses refers to exactly? kernel classes?
I have no the exact answer. When I implemented the feature to support
Java5 it was not important for implementation.
You can track LdRef back to translator and see the byte cod
' need to be intercepted, my TauLdRef
only represents the ref loading that requires barrier.
Do you think it is reasonable?
Thanks
2008/5/19 George Timoshenko <[EMAIL PROTECTED]>:
Hi.
You are trying to work and solve problems in HLO.
What do you thing on the current write barrier im
Hi.
You are trying to work and solve problems in HLO.
What do you thing on the current write barrier implementation?
WBs appeare only in code selector. HLO knows nothing about them.
Why don't use similar approach and just implement read barriers
generation in CodeSelector?
Doing this you shoul
I also found LdInd, LdRef, LdVar
Where are they used? and What is the difference between these and TauLdInd?
LdInd: its a kind of wrapper. It can be used for load of anything from
memory. But it is not used for java AFAIR.
(For Java you always know what you are trying to load so for example for
Simon Chow wrote:
Thank you all~
so all the 'St*'s (such as StField, StStatic, StElem etc.) are translated
into TauStInd or TauStRef instruction now?
additionally, what is the exact meaning of 'Tau' prefix?
You are right
StField and similar are being translated into
addr = LdFieldAddr (LdEle
expandMemAddr is true by default.
I am not sure if it wrorks correctly in the 'false' case.
This flag is obsolet actually.
It should be removed.
Egor Pasko wrote:
On the 0x43C day of Apache Harmony Simon Chow wrote:
Hi all
I found this flag is frequently used when generating 'Store' related
in
Hi,
I will try to explain. Colleagues, please correct me if I write smth. wrong.
Op_ - opcode
Tau - this is not significant for understanding what the
instruction does.
Ld - load
VTableAddr - the address of virtual table
So the instruction loads the ad
Mikhail Fursov wrote:
Is it possible to integrate it in disabled mode with a command line option
turned off?
Sure.
Mikhail,
It is not complete.
It must be tested carefully.
One more problem: the patch is outdated.
It needs to be refreshed.
Colleagues,
I created a new JIRA issue with an improvement proposal for Jitrino.OPT.
https://issues.apache.org/jira/browse/HARMONY-5743
In compressed mode OPT always uncompress a ref just after it is loaded
from memory (from field).
So each reference is uncompressed in the managed code.
It is
Egor Pasko wrote:
But what is the reason not to?
The main value of simplifying-on-the-fly in my opinion is reducing the
number of generated instructions. Of course, they will be eliminated
later by separate "simplify", but then you get gaps in instruction ids.
Basing on quite long debuggin
Okonechnikov Konstantin wrote:
I have some good news: Simplifier and CSE removal from IRBuilder is
accomplished.
1) What is done:
- Simplifier* IrBuilder::simplifier and all connected methods are removed or
modified
- CSEHashtable IrBuilder::cseHashTable and its methods are removed
- Instruction
check works for the src operand in
resolution, or else if the same problem will occur?
Thanks a lot!
2008/3/4, George Timoshenko <[EMAIL PROTECTED]>:
That assertion in RegAlloc is not related to the register allocation
itself.
Such assertion means, that there is a use of operand that may be
That assertion in RegAlloc is not related to the register allocation itself.
Such assertion means, that there is a use of operand that may be
undefined at the point.
You need to identify the problem operand and then track the CFG state up
to the stage where the operand appears for the first tim
What is Op_TauStInd? which insts could appears before it?
This inst has arguments:
src the value to be stored
ptr the address where 'src' is being stored at
tauBaseNonNull the result of ptr null check
tauAddressInRange the slot where ptr p
Yesterday I was forced to update and rebuild classlib because of the
problem.
I do not know what is better to duplicate the code for DRLVM and
classlib or just wait until everybody beat the problem by rebuilding
fresh classlib and the problem disappeares.
The approach exploiting "locked" CMPXCHG8B is ready.
The patches attached to HARMONY-2092.
This solution is about 1.6 times slower than Jrockit in a special
microbenchmark heavily utilizing volatile variables of type long.
George Timoshenko wrote:
I had a question in the JIRA
I had a question in the JIRA about this issue: why don't we use "lock"
prefix for the atomic access?
well...
Originally we split all 64-bit memory access into 2 ones of 32-bit.
It does not have sense to set #LOCK prefix for them. (there is a gap
between)
We can only set #LOCK to some instr
Thanks a lot for your ideas.
Another patch is attached to JIRA.
As it was suggested there is a enum of 3 values instead of additional
method.
gt.
George Timoshenko wrote:
Some time ago 'vm_helper_is_gc_interruptible' method appeared in the
interface. It is used in JIT to ide
more enum
structure instead of additional method.
Thanks,
xiaofeng
On 5/15/07, George Timoshenko <[EMAIL PROTECTED]> wrote:
Some time ago 'vm_helper_is_gc_interruptible' method appeared in the
interface. It is used in JIT to identify if a helper call can be
interrupted by gc
Some time ago 'vm_helper_is_gc_interruptible' method appeared in the
interface. It is used in JIT to identify if a helper call can be
interrupted by gc for enumeration. And if a helper is interruptible in
some circumstances and is not interruptible in other cases the methods
returns TRUE, as GC
I see now. Thanks for clarification.
As we are using "merged cp" inside DRLVM, can we just not take care of
exceeding 16-bit boundary and keep cp indexes as 32-bit values?
Or we export this information somewhere...?
Pavel Pervov wrote:
In current codebase "merged" constant pool will cause m
Hello Pavel, Egor, community.
I understand what Egor has wrote.
But the idea of constant pool usage in a method is not clear for me.
Managed code does not work with constant pool at runtime, right?
All cp indexes were processed when the method was compiled.
If we are talking about objects (and
The fix was attached to JIRA.
Great thanks to Pavel Ozhdikhin and Alex Astapchuk for assistance.
Eugene,
I've updated H-2145-JIT-side-version-2.patch
There are no overlapped regions any more.
The difference is:
- POINTER_SIZE_INT methodStartAddr = methInfo->getCodeAddr();
+ POINTER_SIZE_INT methodStartAddr = litStart == litEnd ?
methInfo->getCodeAddr() : (*litStart).first;
The problem of
done
2007/1/15, Stepan Mishura <[EMAIL PROTECTED]>:
Could you attach it to HARMONY-2802?
Thanks,
Stepan.
On 1/15/07, George Timoshenko <[EMAIL PROTECTED]> wrote:
>
> Nadya, guys,
>
> please, review the patch.
>
> I'am able to build in debug with it.
>
Nadya, guys,
please, review the patch.
I'am able to build in debug with it.
2007/1/15, Vladimir Ivanov <[EMAIL PROTECTED]>:
The drlvm build on the suse 9 linux failed for me with log:
build.native.init:
[echo] ## Building native of 'vm.port'
[mkdir] Created dir:
/export/users/viv/trunk
Egor Pasko wrote:
On the 0x25B day of Apache Harmony George Timoshenko wrote:
IMHO, we should report conscequent regions of the same method as one
region. Thus, 2 passes are better. And it is NOT slow :)
Egor,
It is not possible to have 2 consequent regions. If there is no gap
between them
IMHO, we should report conscequent regions of the same method as one
region. Thus, 2 passes are better. And it is NOT slow :)
Egor,
It is not possible to have 2 consequent regions. If there is no gap
between them they must be _one_ region.
Please, clarify, if I understand your last note i
Egor Pasko wrote:
On the 0x243 day of Apache Harmony Eugene Ostrovsky wrote:
Let me propose the following design:
Compiled method load event. More precise specification for inlined methods.
1. CML event must be sent for every method compiled by JIT.
If compiled method code is disposed in severa
The second version of JIT-side changes was attached to JIRA.
Comments are highly appreciated.
Features of the version 2:
1. Inlinees are reported according to their inline depth starting from
'1'. (see comment by Ivan Popov in the mail-list thread)
inlineDepth == 1 - means that an inlinee
I've got the same recently.
The problem (As I understand) is in STL std::sprt method which works
incorrectly when gcc is of 3.3.3 version
Mikhail Fursov will, probably, provides some details.
Naveen Neelakantam wrote:
Upon Egor's suggestion, I have changed the subject line for the JIRA and
JIRA issue created:
https://issues.apache.org/jira/browse/HARMONY-2834
Fix is provided.
Great thanks to Alexander Astapchuk for his help during investigating.
George.
Mikhail Fursov wrote:
On 12/19/06, George Timoshenko <[EMAIL PROTECTED]> wrote:
What answer do you expect from me?
Can we add this API call to the list as "inlined in Jitrino HIR"?
yes, sure.
Mikhail Fursov wrote:
On 12/19/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
Mikhail,
I'd also add j.l.System.arraycopy() to the list, see HARMONY-2247
(System::arraycopy by 'rep move' instruction).
George Timoshenko is an expert in Jitrino arraycopy processing :) Le
a question:
Eugene Ostrovsky wrote:
I.e. outer.start <= inlined.start < inlined.end <= outer.end (where
method.start = code_addr , method.end = code_addr + code_size - 1)
In the described situation outer method is being reported with several
events. Do I understald correctly, that in the ineq
Egor,
thanks for clear scheme.
In your terms I'd do something like this:
* firstly - raise event for X:
CompiledMethodLoad(start=X.1.start,
method_size=X.1.size + X.2.size,
addr_loc_map=
[X.1.start -> bcoff1,
Egor, thanks for clear scheme.
In your terms I'd do something like this:
* firstly - raise event for X:
CompiledMethodLoad(start=X.1.start,
method_size=X.1.size + X.2.size,
addr_loc_map=
[X.1.start -> bcoff1,
Egor Pasko wrote:
On the 0x236 day of Apache Harmony George Timoshenko wrote:
Egor Pasko wrote:
On the 0x235 day of Apache Harmony George Timoshenko wrote:
Eugene,
I've answered in JIRA:
https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
(Summary: Everything is OK)
Egor Pasko wrote:
On the 0x235 day of Apache Harmony George Timoshenko wrote:
Eugene,
I've answered in JIRA:
https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
(Summary: Everything is OK)
For this particular testcase it is possible. But there is a general
problem:
Eugene,
I've answered in JIRA:
https://issues.apache.org/jira/browse/HARMONY-2145#action_12455313
(Summary: Everything is OK)
Eugene Ostrovsky wrote:
What should be the outer_method for methodC (A or B)?
I meant the outmost method (A).
Thanks.
Great! The patch is already in the issue
/browse/HARMONY-2145>*.
What do you think?
On 11/22/06, George Timoshenko <[EMAIL PROTECTED]> wrote:
Pavel,
thanks for your answers.
To 'answer 2' I'd like to add that we can easily replace 'MethodDesc*'
by 'Method_Handle' if it is more convenient. (Esp
MONY-2145<https://issues.apache.org/jira/browse/HARMONY-2145>.
*Could you explain what's going on?
2. How can I obtain Method_Handle from the MethodDesc* value?
3. What algorithm jit uses to inline methods? How can I create test class
which methods will be inlined.
On 11/13/06, George Ti
ations of short
methods are inlined by Jitrino.OPT until the size of a root method
exceeds a
threshold.
A simple example can be HelloWorld application where the whole sequence of
println() calls should be inlined in '-Xem:opt' mode.
On 11/13/06, George Timoshenko <[EMAIL PROTE
45 matches
Mail list logo
