RFS: libjboss-remoting-java 2.5.2.SP1-1

[Luke Cycon]

Hey Guys,

I am looking for sponsorship of this latest version of
libjboss-remoting-java (2.5.2.SP1-1).

It is a packaging of the latest upstream.

Here is the latest entry in the changelog:

libjboss-remoting-java (2.5.2.SP1-1) unstable; urgency=low

  * New Upstream release
  * Updated patch concurrent.diff

 -- Luke Cycon   Wed, 06 Jan 2010 15:13:37 -0800

I commited the changes to the svn repo, so you can grab it from there.

Thanks,

-- 
Luke Cycon 


signature.asc
Description: This is a digitally signed message part

Re: State of openjdk on hppa

[Andrew Haley]

On 01/06/2010 05:26 PM, Tom Rodriguez wrote:

> No I didn't see it.  If it was only on the icedtea list then I
> wouldn't have seen it as hotspot-dev is the only one of these
> aliases that I'm on.

Oh darn, my mistake.  The shiny new Reply List button on Thunderbird 3
didn't quite do what I expected...

> By the way, I restored the other aliases to my reply so they would
> get it too.  So the computation of the location of the guard pages
> is wrong because of the direction of growth?  For instance this line
> obviously won't work right:
> 
>   address low_addr = stack_base() - stack_size();

Right, that's it.

> There's also some code in os_linux_zero.cpp that does math on the
> stack that would need to take into account the real ABI direction.
> I think we probably need something like "int os::stack_direction()"
> to deal with this in shared code.  All the guard logic in Thread
> needs to check it as does is_in_stack and is_lock_owned.  There
> might be some logic in frame that needs to check it too but
> hopefully that will all be platform dependent logic.

Andrew.


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: State of openjdk on hppa

[Tom Rodriguez]

No I didn't see it.  If it was only on the icedtea list then I wouldn't have 
seen it as hotspot-dev is the only one of these aliases that I'm on.  By the 
way, I restored the other aliases to my reply so they would get it too.  So the 
computation of the location of the guard pages is wrong because of the 
direction of growth?  For instance this line obviously won't work right:

  address low_addr = stack_base() - stack_size();

There's also some code in os_linux_zero.cpp that does math on the stack that 
would need to take into account the real ABI direction.  I think we probably 
need something like "int os::stack_direction()" to deal with this in shared 
code.  All the guard logic in Thread needs to check it as does is_in_stack and 
is_lock_owned.  There might be some logic in frame that needs to check it too 
but hopefully that will all be platform dependent logic.

tom

On Jan 6, 2010, at 8:53 AM, Andrew Haley wrote:

> On 01/06/2010 04:47 PM, Tom Rodriguez wrote:
>>> I'm not 100% sure what the correct value of this would be for HPPA.
>>> The ABI stack grows upwards, but the stack Zero maintains still grows
>>> downwards.  If interpreter_frame_expression_stack_direction is used
>>> for both of these stacks then something will need changing (either a
>>> separate accessor, or Zero's stack direction changing to match the
>>> ABI stack.)
>> 
>> I don't really think hotspot cares which direction the ABI stack
>> grows.  It only cares what direction the expression stack grows and
>> that's only for frame code that it was walking over the contents of
>> the expression stack..  I was assuming that the expression stack
>> would follow the ABI but I guess there's no reason it must.  It's
>> just the responsibility of the C++ intepreter to deal with that
>> properly.  It would be nice to know what exact problem led to the
>> initial conclusion that direction of stack growth was the problem.
> 
> Did you not see my reply?  The runtime write protects the guard pages
> of the stack, and this immediately causes a segfault since the stack
> being used is now unwritable,
> 
> Andrew.


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: debian package of hadoop

[Isabel Drost]

On Monday 04 January 2010 15:46:55 Steve Loughran wrote:

> What use cases are you thinking of here?
>
> 1) developer coding against the hadoop Java and C APIs

+1


> 2) Someone setting up a small 1-5 machine cluster

+0


> 3) large production datacentre of hundreds of worker nodes
> 4) transient virtualised worker nodes

Installing Hadoop on Debian for me would mean something like providing the 
minimal installation that gives me a running Hadoop node. I would guess that 
clusters of hundreds of worker nodes are different enough from one another to 
require additional configuration work on the administrators side anyways.

If this were a wish list, I would love to be able to install a package "hdfs", 
one for "map reduce", another one for "hbase" (that itself depends on hdfs 
and map reduce). There should be one that is binary only, one for the 
development libs (as I would love to code against the Hadoop APIs), there 
will probably be one for the documentation. I would find configuration files 
where I expect them to be (somewhere at /etc/hadoop/ maybe) and data where it 
belongs (/var/hadoop?). The setup would help me to easily get Hadoop up and 
running as a newbie (something like apt-get install hadoop - maybe adjusting 
some configuration afterwards to add more nodes to the cluster). It would 
make upgrading to new Hadoop versions less painful. ;)

Isabel

-- 
  |\  _,,,---,,_   Web:   
  /,`.-'`'-.  ;-;;,_  
 |,4-  ) )-,_..;\ (  `'-' 
'---''(_/--'  `-'\_) (fL)  IM:  



signature.asc
Description: This is a digitally signed message part.

Re: State of openjdk on hppa

[Tom Rodriguez]

> I'm not 100% sure what the correct value of this would be for HPPA.
> The ABI stack grows upwards, but the stack Zero maintains still grows
> downwards.  If interpreter_frame_expression_stack_direction is used
> for both of these stacks then something will need changing (either a
> separate accessor, or Zero's stack direction changing to match the
> ABI stack.)

I don't really think hotspot cares which direction the ABI stack grows.  It 
only cares what direction the expression stack grows and that's only for frame 
code that it was walking over the contents of the expression stack..  I was 
assuming that the expression stack would follow the ABI but I guess there's no 
reason it must.  It's just the responsibility of the C++ intepreter to deal 
with that properly.  It would be nice to know what exact problem led to the 
initial conclusion that direction of stack growth was the problem.

tom

> 
> Cheers,
> Gary
> 
> -- 
> http://gbenson.net/


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: State of openjdk on hppa

[Gary Benson]

Tom Rodriguez wrote:
> Someone wrote:
> > openjdk builds on hppa, but doesn't run (yet). Andrew Haley once
> > debugged it and found out at least one things which would need to
> > be fixed: the assumption in the C++ interpreter that the stack
> > always grows downwards, and not upwards as on hppa.
> > 
> > please could one of the hotspot developers sched some light on
> > this, how easy this might to be fix, and if there are other
> > assumptions?
> 
> Could you give more detail on where exactly the direction of growth
> is being assumed?  I know there's an accessor in frame that's
> supposed to describe the direction of growth of the expression stack
> which is used a few places in the code:
> 
>   // expression stack (may go up or down, direction == 1 or -1)
>  public:
>   intptr_t* interpreter_frame_expression_stack() const;
>   static  jint  interpreter_frame_expression_stack_direction();
> 
> I would think this has to be set correctly for HPPA to work.  Is it?
> It's possible that the C++ interpreter would also need to consult
> this when pushing values for it to work correctly.

I'm not 100% sure what the correct value of this would be for HPPA.
The ABI stack grows upwards, but the stack Zero maintains still grows
downwards.  If interpreter_frame_expression_stack_direction is used
for both of these stacks then something will need changing (either a
separate accessor, or Zero's stack direction changing to match the
ABI stack.)

Cheers,
Gary

-- 
http://gbenson.net/


-- 
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: State of openjdk on hppa

[Matthias Klose]

On 05.01.2010 19:13, Tom Rodriguez wrote:

openjdk builds on hppa, but doesn't run (yet). Andrew Haley once debugged it 
and found out at least one things which would need to be fixed: the assumption 
in the C++ interpreter that the stack always grows downwards, and not upwards 
as on hppa.

please could one of the hotspot developers sched some light on this, how easy 
this might to be fix, and if there are other assumptions?


Could you give more detail on where exactly the direction of growth is being 
assumed?  I know there's an accessor in frame that's supposed to describe the 
direction of growth of the expression stack which is used a few places in the 
code:

   // expression stack (may go up or down, direction == 1 or -1)
  public:
   intptr_t* interpreter_frame_expression_stack() const;
   static  jint  interpreter_frame_expression_stack_direction();

I would think this has to be set correctly for HPPA to work.  Is it?  It's 
possible that the C++ interpreter would also need to consult this when pushing 
values for it to work correctly.


thanks for the pointer. zero sets this independently of the architecture. now 
checking the obvious fix.


  Matthias


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: State of openjdk on hppa

[Carlos O'Donell]

On Tue, Jan 5, 2010 at 1:13 PM, Tom Rodriguez  wrote:
>> please could one of the hotspot developers sched some light on this, how 
>> easy this might to be fix, and if there are other assumptions?
>
> Could you give more detail on where exactly the direction of growth is being 
> assumed?  I know there's an accessor in frame that's supposed to describe the 
> direction of growth of the expression stack which is used a few places in the 
> code:

The usual problem faced by HPPA is that it is one of the few
stack-grows-up targets, therefore it is the *missing* calls to
interpreter_frame_expression_stack_direction() that a porter has to
determine. There is no easy way to know this other than debugging a
failed application and determining that a section of code is assuming
stack-grows-down and should instead call the appropriate accessor
function to determine stack growth. I don't know if there are any such
instances in the hotspot code.

>  // expression stack (may go up or down, direction == 1 or -1)
>  public:
>  intptr_t* interpreter_frame_expression_stack() const;
>  static  jint  interpreter_frame_expression_stack_direction();
>
> I would think this has to be set correctly for HPPA to work.  Is it?  It's 
> possible that the C++ interpreter would also need to consult this when 
> pushing values for it to work correctly.

Given that HPPA is a stack-grows-up target, is the value of this constant 1?

All interpreters that manually manipulate the stack must know the
direction of stack growth (and alignment of stack).

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org