Hi Rana,
Thank you for your comments. Please, find my answers inlined.
Rana Dasgupta wrote:
Hi Alex,
This is good, thanks. Please see below...
On 11/15/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Hi all,
Among other things listed on the JIT Dev tasks, there is a need for
calling
.
--
Thanks,
Slava Shakin.
Alex Astapchuk [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Hi all,
Among other things listed on the JIT Dev tasks, there is a need for
calling convention (CC) fix-up for IA-32 [1].
Current problems are:
1. The calling convention(s) used are stack
Hi all,
Among other things listed on the JIT Dev tasks, there is a need for
calling convention (CC) fix-up for IA-32 [1].
Current problems are:
1. The calling convention(s) used are stack-based - this adds a memory
access overhead on calls.
2. The convention currently used for managed code
Geir Magnusson Jr. wrote:
Alex Astapchuk wrote:
Geir Magnusson Jr. wrote:
I've been having some problems getting some test cases to exhibit
misbehavior for DRLVM, and it turns out that jitrino is built in
release mode no matter what BUILD_CFG is set to.
Yes, this is a long-long
Geir Magnusson Jr. wrote:
Alex Astapchuk wrote:
Pavel Pervov wrote:
Hello, community,
Working through DRLVM sources I (once again) looked at organization of
jitrino code.
Actually, there are two JITs hidden inside jitrino: JET and OPT.
As far as I may observe - these two are code
Pavel Pervov wrote:
Hello, community,
Working through DRLVM sources I (once again) looked at organization of
jitrino code.
Actually, there are two JITs hidden inside jitrino: JET and OPT.
As far as I may observe - these two are code-independent from each other.
JIT-guys, could you comment?
Geir Magnusson Jr. wrote:
I've been having some problems getting some test cases to exhibit
misbehavior for DRLVM, and it turns out that jitrino is built in release
mode no matter what BUILD_CFG is set to.
Yes, this is a long-long story.
Was done as 'we-will-change-it-back-soon'
Mikhail Fursov:
On 10/28/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Aleksey,
1. Mark and scan based approach.
2. Automatic class unloading approach.
In the #2, is there any chance for other components to be notified about
unloaded classes?
Alex,
I asked Aleksey about the same
Ivan,
Ivan Volosyuk:
On 10/29/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Mikhail Fursov:
On 10/28/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Aleksey,
1. Mark and scan based approach.
2. Automatic class unloading approach.
In the #2, is there any chance for other components
Tonny,
Tonny Lau wrote:
Hi,
I want to override some specific java methods with native fast path
implementations. So I try to override them in
compile_do_compilation_jit()(vm/vmcore/src/jit/compile.cpp), that is,
I add several entries in
Tonny Lau wrote:
2006/10/30, Alex Astapchuk [EMAIL PROTECTED]:
Tonny,
Tonny Lau wrote:
Hi,
I want to override some specific java methods with native fast path
implementations. So I try to override them in
compile_do_compilation_jit()(vm/vmcore/src/jit/compile.cpp), that is,
I add
Aleksey,
1. Mark and scan based approach.
2. Automatic class unloading approach.
In the #2, is there any chance for other components to be notified about
unloaded classes?
I can imagine many scenarios when a component needs to keep some data
associated with the classes. If a class
I hope we all understand the same under lazy resolution but it would be
better if you explained a bit how it is going to work.
Let's ask Alex Astapchuk to describe it. He tried to do it in JET, so he
knows more nuances about implementation problems.
Currently, both .opt and .jet use
Mikhail Fursov wrote:
Pavel, thanks
SUN passes both tests (with -Xcomp too), BEA(1.5) crashes as
expected.Our VM
throws ClassCircularityError with both compilers and passes with
interpreter.
IMO we must add lazy resolution to both compilers in future. The reason: to
Hmm... this particular
Mikhail Fursov :
Pavel,
I do this workaround for my local needs.
The problem in your solution is dll name: gcv5
I can built my own version of GC - gcv5_plus_some_features and put it into
any directory I want (-Dvm.gc_dll ?)
Should I fix the Java sources in this case?
The possible solution could
Alex Astapchuk :
Mikhail Fursov :
Pavel,
I do this workaround for my local needs.
The problem in your solution is dll name: gcv5
I can built my own version of GC - gcv5_plus_some_features and put it
into
any directory I want (-Dvm.gc_dll ?)
Should I fix the Java sources in this case
)};
// the way to obtain an address for a method
private static native jni_getAddress(String directNativeCallName);
}
Solution: To find an address of the native call JIT can access to the
final
variable.
On 10/20/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Gregory,
Gregory Shimansky
Mikhail Fursov :
On 10/20/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Yeap.
The following addresse both your issues.
class GCv5Magics {
static {
String gcPath = System.getProperty(vm.gc_dll);
if (gcPath == null) {
System.load(gcPath);
}
else
I think a generic encoding interface exposed by a component could
return for
a given helper a mask of affected registers, description of input and
return
parameters, and should not produce any other side effects including
VM calls
As an alternative, we can simply disassemble the returned
Gregory,
Gregory Shimansky:
On Thursday 19 October 2006 09:21 Alex Astapchuk wrote:
Mikhail Fursov wrote:
On 10/19/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Pavel,
One more note.
b) About call of java method during compilation time. Jit now make
class loading during compilation
Pavel,
One more note.
b) About call of java method during compilation time. Jit now make
class loading during compilation.
It means that Jit make call of java method.
So I don't think that it's the other case.
It is different.
The JIT itself does not call Java code.
All what JIT does is
Mikhail Fursov wrote:
On 10/19/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Pavel,
One more note.
b) About call of java method during compilation time. Jit now make
class loading during compilation.
It means that Jit make call of java method.
So I don't think that it's the other case
A small correction:
Currently the IA-32 and Intel-64 CG uses calling conventions
that pass all parameters on stack.
Stack-only is about IA-32 calling convention.
Intel64 CG generates a calling convention as per SystemV ABI
recommendations [1].
This is a variant of fastcall with 6 GP
Pavel,
Though the proposal look interesting, but some things are not clear.
Could you please shed a bit of light on it?
1) The special interface MagicNativeCall should be created. The
interface has only one method CallAddress getCallAddress(String
methodName)..
An interface method
Weldon,
I'm a bit confused what to call finally...
The previous WB4J version did a call to
org/mmtk/plan/PlanLocal::writeBarrier().
The problem was with getting an instance of PlanLocal. We solved it by
adding a stub static method PlanLocal::getPlanLocal() - just for the
sake of testing
Xiaofeng,
I've just submitted http://issues.apache.org/jira/browse/HARMONY-1806.
It introduces write barriers for Java and also slightly changes the
options processing.
After the HARMONY-1806, the GC's gc_requires_barriers() will be taken
into account.
If gc_requires_barriers()==true, then
Tim Ellison wrote:
Alex Astapchuk wrote:
Hi Stepan, all,
I think the spec. statement: A LoginContext should not be used to
authenticate more than one Subject. was taken too strict: reusing
LoginContext object to get the same set of credentials seemed odd.
The decision was mostly about
Hi Stepan, all,
I think the spec. statement: A LoginContext should not be used to
authenticate more than one Subject. was taken too strict: reusing
LoginContext object to get the same set of credentials seemed odd.
The decision was mostly about resources.
Indeed, the spec does not specify
Weldon,
Weldon Washburn wrote:
The following is printing a zero instead of 0x
Address mm = Address.max();
System.out.println(Address.max() = +
Integer.toHexString(mm.toInt()) );
I changed the max() implementation according to recent
email thread, where it was stated as
Weldon,
I've updated the magics.cpp with fromLong/toLong fixed.
But I suspect other issues as well, and I'm working on it, so
please expect more commits of magics.cpp to come.
--
Thanks,
Alex
Alex Astapchuk wrote:
Weldon,
I also recently discovered what could be problem with jitrino.JET
Weldon,
I also recently discovered what could be problem with jitrino.JET
compiling OPCODE_LCMP. Jitrino.JET is core dumping. This problem
I'm looking into the issue.
Could you please share the class/method that causes assertion ?
--
Thanks,
Alex
Weldon Washburn wrote:
All,
Weldon,
I've updated the magics.cpp to reflect the changes in MMTk:
- add/sub replaced with plus/minus
- fixed constants passed to MMTk's WB code wrt
org.mmtk.utility.Constants.*WRITE_BARRIER
- Stub implementation of atomic attempt() (always succeeds currently)
- Stub (no-op) implementation for
build.bat -DCOMPONENTS=vm.jitrino
?
--
Thanks,
Alex
Weldon Washburn wrote:
On 7/10/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
Weldon,
I just commited http://issues.apache.org/jira/browse/HARMONY-816
into JIRA.
It contains the changes for Jitrino.JET:
- magics support for MMTk
. Please see
the response inline.
Weldon
On 6/27/06, Alex Astapchuk [EMAIL PROTECTED] wrote:
AFAIR from the recent thread, to implement WB for MMTk support, I have
to emit calls of
org.mmtk.plan.PlanLocal.writeBarrier(
ObjectReference src,
Address slot
or whatever).
before it makes sense to add MMTk write barrier to
jitrino.JET, we need to add intrinsics to support MMTk vmmagic
classes.
Seems the first to do are the org.vmmagic.unboxed.* ?
--
Thanks,
Alex
Weldon Washburn wrote:
Hi Alex,
Comment inline below.
On 6/27/06, Alex Astapchuk
Weldon,
Weldon Washburn wrote:
It would be really nice if jitrino.jet allowed the write barrier to be
selected at the start of jitting an individual method. Is this
possible?
Sure. Currently, jitrino.jet handles some of OpenMethodExecutionParams
flags to instrument the jitted code.
The
Ming,
The above is just a consideration for infrastructure. I have already
implemented the write barrier code in jet for some GC developed in C.
It has already been tested and attached file is the patch.
Cool ! Thanks for the patch !
I'm not too familiar with GC stuff, but seems you are
Weldon,
Weldon Washburn wrote:
A question for the folks working on Jitrino.JET. I see comments in
the source code about back branch polling. Can I use back branch
polling?
Yes. The 'back branch pooling' is turned on by default in Jitrino.JET.
It inserts a call to VM's helper
38 matches
Mail list logo
